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