| Previous | \Contents | ^Index |
C OpenVMS can generate the %xA4 character code used for the E Euro, and the DECwindows DECterm can display the glyph. Please check E with the vendor of your terminal or terminal emulator for additional details. } 2.10 OpenVMS Ports? Itanium? Ports to IA-32, EM64T or AMD64 systems?
E OpenVMS has been ported to and is operational on four architectures: D VAX, Alpha, IA-64, and IA-32. The first three have available native D ports of OpenVMS, the fourth is available via emulation. VAX is the D oldest architecture, and limited to 32-bit virtual and up to 34-bit G physical addressing. The Alpha and IA-64 architectures are both 64-bit G architectures, with 64-bit virtual addressing available. The available H IA-32 emulation is provided for the OpenVMS VAX and other VAX operating ? systems, and provides a 32-bit VAX environment. For additional ] information on the emulation, please see Section 13.14.
B As for (the lack of) a native port for IA-32, OpenVMS Engineering D presently and continues to believe that there would be insufficient F market (read: profit, customer interest) to justify the cost involved = in a native port of OpenVMS to systems using the Intel IA-32 G architecture. In addition to the direct costs involved in any port and H in addition to the substantial effort involved in moving backwards from F a 64-bit environment on Alpha and on IA-64 to a 32-bit platform (such F as IA-32), and the exceedingly non-trivial device qualification costs F and the costs in moving backwards into older PCI and I/O environments D (IA-32 systems more than a few years old have equivalently aged I/O D support and buses), each organization and each person maintaining a ? product or a package for OpenVMS will have to justify a port to F "OpenVMS IA-32", "OpenVMS EM64T" or "OpenVMS H AMD64", akin to the decisions and the effort involved in porting a C product from OpenVMS VAX to OpenVMS Alpha, the port to OpenVMS I64.
H Platform ports of many of the various products can be easy, and many of @ the ports of applications using documented OpenVMS features are F expected to require little more than a source rebuild. Other products E can and do depend on platform-specific or undocumented features, and @ the associated ports can be more involved. Regardless, ports of < operating systems are very large and involved projects. The G prerequisite product requirements for an OpenVMS operating system port F are also non-trivial, as well---compilers in particular are obviously H required, and the suite of compilers provided must maintain a very high G degree of source-level compatibility across the platforms. In the case of the HP Integrity G port, OpenVMS I64 V8.0 used cross-compilers and cross-tools operating D on OpenVMS Alpha systems, while V8.2 and later have various native compilers available.
D The OpenVMS I64 port was centrally built using the existing OpenVMS A Alpha environment and around the work and the knowledge from the ? OpenVMS Alpha port, and OpenVMS Engineering fully expects that C customers and ISVs will use and will continue to use OpenVMS Alpha ? systems to assist with their own ports to OpenVMS I64. OpenVMS D Engineering fully expects to see customers using mixed-architecture 0 clusters and fully shared file systems, as well.
E OpenVMS Engineering is well aware of the AMD AMD64 (64-bit) platform A and processors. (At least one of the available VAX emulators can F reportedly utilize parts of the AMD64 instruction set, please contact G the VAX emulator vendor(s) or maintainer(s) for assistance and details H on their products.) OpenVMS Engineering is also well aware of the Intel EM64T platform and processors. G There are no plans to provide a native port of HP OpenVMS for A any systems based on the AMD AMD64 nor Intel EM64T architectures.
F As part of the work leading to the Itanium port, senior engineers had C extensively evaluated the products and the architectures available A across the high-end 64-bit computing space, and chosen to target > Itanium for 64-bit environments---this while under the Compaq D organization. This included looking at IA-32. HP (a co-developer of F Itanium with Intel) had seperately chosen to target Intel Itanium for D its high-end computer products. Compaq then announced plans for the future of Alpha H through EV7-series products and platforms, and HP (entirely seperately) announced plans for PA-RISC @ products and platforms. The Itanium target has been maintained F consistently since the Itanium port was announced by Compaq, and has F also been consistently maintained by HP and by the combined company. C For those folks prefering to follow the schedules and the product I deliveries, OpenVMS Engineering had OpenVMS I64 V8.0 ready (internally) I ahead of schedule---and with more features available within the release G than had been originally planned for the release. (For information on E and for schedules of future OpenVMS releases, please see the roadmap + that is available at the OpenVMS website.)
E OpenVMS I64 itself does not require and does not plan to utilize the F Itanium IA-32 32-bit environment for the operation of OpenVMS itself. A OpenVMS I64 V8.0 and later run natively on the Itanium processor F family, with no use of IA-32 instructions. While OpenVMS can and does G support 32-bit OpenVMS applications and addressing on Itanium, this is E done with sign-extension addressing techniques entirely analogous to E what was done with 32-bit applications operating in the 64-bit Alpha H environment. Both OpenVMS 32-bit and 64-bit applications operate within H the native Itanium instruction set and run-time environment, and do not " use the Itanium IA-32 environment.
G But yes, a native IA-32 port or a native AMD AMD64 or Intel EM64T port H of OpenVMS would certainly be nice to have---this, of course, following G the traditional Linux preference for having a Linux port available for H most (all?) computer architectures known, and even for certain high-end E refrigerators and toasters, and similar appliance-like devices. (The H downside of this all-encompassing approach: this requires near-infinite E engineering and support costs from the various vendors involved, and H the qualification efforts and costs of most everything---everywhere. Or E reduced or eliminated testing and support efforts. Or an unfortunate A combination of these two. These costs are huge, and the benefits H derived from the work are comparatively small when given the comparable E costs of more targeted (and thus supported and supportable) hardware @ configurations---the platform targets are and must be carefully C selected and considered by each vendor. Put another way, there are E no plans to provide a native port of HP OpenVMS for systems H based on Intel IA-32 processors, nor for systems based on AMD AMD64 nor ) Intel EM64T architecutres and processors.
E All this material having been written, have you looked at the system G configurations and pricing of the available HP Integrity Intel Itanium systems? D Low-end computer hardware is clearly a commodity product, and the J systems are priced, serviced, upgraded, and replaced accordingly. Intel D Itanium is a commodity microprocessor presently used in platforms J available from various hardware vendors, including (obviously) from HP. F Further, Itanium is a microprocessor available from and supported by A Intel, a semiconductor vendor known for exceedingly high-volume @ microprocessor fabrication process and production capabilities.
F For information on supported platforms and processors, please see the . OpenVMS Software Product Description (SPD) at:
\ Please see Section 14.4.5 for Intel Itanium terminology. m 2.11 Are there any network-accessible OpenVMS systems?
2 Yes, though various restrictions can and do apply.
H For information on supported platforms, please see the OpenVMS Software @ Product Description (SPD) for the particular OpenVMS version of interest.
H For a table of the minimum and (as applicable) maximum OpenVMS versions F required for various platforms, please see the hardware support chart D at HP OpenVMS website and (as available) the following (potentially volatile; intra-website) link:
H For information on the Multia, related Alpha single-board computers, or i other officially unsupported systems, please see Section 14.4.1 and 7 Section 14.4.2.1.
G The following is a rule-of-thumb for Alpha platform support. The table i Table 2-5 contains the earliest OpenVMS Alpha release with support 5 for a particular series of Alpha microprocessors:
| Generic | 4Microprocessor Generation | *OpenVMS Version | +General Comments |
|---|---|---|---|
| EV4 | 21064 | V1.0 | < few systems; most EV4 require later; upgrade available |
| EV5 | 21164 | V6.2 | " subsequent upgrade available |
| EV56 | 21164A | V6.2-1H3 | * subsequent upgrade to V7.1 and later |
| EV6 | 21264 | V7.1-2 | 5 subsequent upgrade typically to V7.2-1 or later |
| EV67 | 21264A | V7.1-2 | 5 subsequent upgrade typically to V7.2-1 or later |
| EV68 | 21264B, C and D | V7.2-1 | = believed/probable; currently an unconfirmed expectation |
= For the guidelines and submission info, please visit the URL:
H To order the current OpenVMS Freeware CD-ROM kit (shipping and handling 7 charges apply), please request part number QA-6KZAA-H8. \ 2.14 Porting applications to OpenVMS?
D Porting can range from simple to rather complex, and depends on the ' features used on the original platform.
C This section covers generic porting, and porting among OpenVMS VAX D OpenVMS Alpha, and OpenVMS I64. (Porting among OpenVMS VAX, OpenVMS E Alpha and OpenVMS I64 is often quite simple and involves little more F than rebuilding from source, though a few applications using features G specific to the platform or the architecture, or using undocumented or C unsupported interfaces can and likely will require some additional effort to port.)
A Several manuals on porting from OpenVMS VAX to OpenVMS Alpha are E available in the OpenVMS documentation set, including information on F porting VAX Macro32 assembler code to the Macro32 compiler on OpenVMS D Alpha, on management differences, on upgrading privileged code, and application migration:
> Documentation on porting to OpenVMS I64 is available, as well.
: Details on the C programming environment are available at:
6 Details on porting VAX C to HP C are are available at:
+ An OpenVMS Porting Library is available at:
B Information on the Enterprise Toolkit, a Visual-based development F environment for developing applications for OpenVMS using a Microsoft platform, is available at:
? Details on DCE, CORBA, BridgeWorks, and COM/DCOM middleware is available at:
1 Information on the COE standards is available at:
C A wide variety of programming development tools and middleware are < available as commercial products (eg: DECset, IBM WebSphere A MQ---formerly MQseries), and various tools are also available as E shareware or as Freeware. Please see other sections of this FAQ, and please see:
xH The HP Developer and Software Product Partner (DSPP) program is open to D and intended to support and to assist HP OpenVMS software partners, # consultants, and service providers:
H DSPP provides members with various benefits, please see the website for details.
F For those not familiar with the DSPP program or with its history, the H DIGITAL Association of Software and Application Partners (ASAP) program D and the DIGITAL Independent Software Vendors Network (ISVN) program G were incorporated into the Compaq CSA program, and the CSA program has 8 subsequently been incorporated into the HP DSPP program.
k Please see Section 2.8.3 for additional details on the DSPP program. | 2.16 memory management, resource management, process scheduling, etc?
@ So you have been instructed to write a school research paper on F OpenVMS, and you need technical content on the OpenVMS Virtual Memory G System, on any memory segmentation, on OpenVMS Resource Management, on < the OpenVMS File System, on the OpenVMS user interface, etc.
G Invariably, your professor/instructor/teacher will ask you a series of E questions. Most commonly, the questions will request descriptions of D one or more of the following items, and at varying levels of detail:
B Any particular presentation or research paper, and particularly a B scholastic presentation, can have many different potential target F audiences, and very different presentation levels. Further, the usual G underlying reason for scholastic presentations and scholastic research G projects really has little to do with the subject matter, it is a task G specifically intended to teach the student(s) (eg: you) how to perform A the research. The instructor already knows most of (all of?) the 0 information that you have been asked to collect.
F For very technical details on OpenVMS and OpenVMS internals, the book G you want is the Internals and Data Structures Manual (IDSM), available E in your school or computing center library, and the IDSM can also be H purchased. Additional technical details of the Alpha microprocessor are H available in the Alpha Architecture Reference Manual documentation that F is available for download. (Pointers to Alpha technical documentation T are available in Section 14.6, and elsewhere.)
E For higher-level (less technical) details, the OpenVMS documentation H set is available on-line. The Programming Concepts and the File Systems E manual are probably the best manuals to start with, depending on the 1 particular level of detail the research requires.
E And please understand the hesitation of various folks to provide you G with a completely-written research report on your topic. Why? We might C have to work with you after you graduate---you need to know how to E perform at least basic research on your own, regardless of the topic. W 2.17 Basic Units of Measurement?
E OpenVMS and the underlying hardware use various units of measurement F for disk and memory storage, and related abbreviations also typically E exist. This section covers the most common units, and the associated abbreviations. H 2.17.1 How many bytes are in a disk block?
G A disk block is the minimum unit of disk storage allocation in OpenVMS.
C Under OpenVMS VAX and OpenVMS Alpha, the disk volume block size is 1 consistent, with each block containing 512 bytes.
E The minimum disk allocation granularity actually permissible (in the ? ODS-2 and ODS-5 volume structures commonly used on OpenVMS) is > determined on a per-volume basis, and is typically based on a H combination of the total number blocks on the disk volume and the total G size of the volume storage bitmap. The allocation granularity is known C as the volume cluster factor---the cluster factor is the number of G blocks in a disk cluster, and it is the smallest number of blocks that - can be allocated on a particular disk volume.
B Prior to OpenVMS V7.2, the maximum permissible size of the bitmap H requires larger cluster factors as volume sizes increase. Starting with D V7.2, the bitmap can be larger, and cluster factors as small as one block can be used.
C The number of bytes in a file can be determined by multiplying the G number of blocks allocated for the file times the number of bytes in a D block. For sequential files (only), the FFB (XAB$W_FFB, in the File ? Header XAB) value can be used to find out how much of the last ? (XAB$L_EBK) block is used. FFB and EBK are meaningful only for @ sequential files, and only in a limited context---partial block F allocations are not permitted. For other file formats, the EOF marker is not meaningful.
D Disk allocations always occur only in units of the cluster factors, E which can be from one block up to (potentially) clusters of eighteen F blocks or more, depending on the volume cluster factor. (OpenVMS V7.2 G and later optionally provide for a cluster factor of one up to volumes of approximately 137 gigabytes.)
B OpenVMS assumes that the device driver and the underlying storage F device will present the file system with addressable units of storage E of 512 bytes in size, or the appearance of same. Various third-party F CD-ROM devices, for instance, support only 2048 byte blocks, and such B devices are incompatible with the standard OpenVMS device drivers.
C To determine the number of bytes required for a file from DCL, one H option uses the f$file_attributes item EOF, multiplied by the size of a H block in bytes (512). This does not account for the unused space in the > last block of a sequential file, but it also does not have to 0 differentiate sequential files from other files. I 2.17.2 How many bytes are in a memory page?
H A memory page is the minimum unit of memory allocation in OpenVMS. With E OpenVMS VAX, the memory page size matches the disk block size: it is always 512 bytes.
G With OpenVMS Alpha, the memory page size is variable, and it can range E from 8192 bytes (8 kilobytes) up to 64 kilobytes. The current system G page size can be determined using the sys$getsyi or f$getsyi PAGE_SIZE E item. Programs with hardcoded constants for the memory page size (or A page alignment) should always assume a page size of 64 kilobytes.
D On OpenVMS I64, the memory page size is also variable, ranging from H 4096 bytes (4 kilobytes) up to 256 megabytes (MB) and potentially up to E 4 gigabytes (GB). As with OpenVMS Alpha, sys$getsyi and f$getsyi and G the PAGE_SIZE itemcode can and should be used to determine the current D system page size. In general, OpenVMS I64 will use a page size of 8 kilobytes, or larger.
B On OpenVMS Alpha and on OpenVMS I64, a 512 byte area of memory--- G equivalent in size to an OpenVMS VAX memory page---is often refered to as a "pagelet".
| Previous | YNext | \Contents | ^Index |