| Previous | Contents | Index |
If you are creating a bootable CD or DVD media for use with OpenVMS I64, you will want to specify the SYS$SETBOOT block size of 2048, and you will also want a disk cluster factor that is a multiple of four via INITIALIZE/CLUSTER=4 (or 8, or...), or you will want to ensure that SYS$EFI.SYS and SYS$DIAGNOSTICS.SYS are aligned to a multiple of four blocks; to a 2048 byte boundary. This alignment and this blocking is only necessary for OpenVMS I64, and only when creating optical media OpenVMS I64 for bootstraps.
The default 512-byte block setting used by SYS$SETBOOT is the correct and expected value for traditional disk bootstraps on OpenVMS I64 systems.
Once the boot files are loaded, OpenVMS I64 operates with 512-byte blocks; as is the case with ATAPI disks on OpenVMS Alpha, all application code will only see 512-byte blocks on optical media on OpenVMS I64.
OpenVMS I64 V8.2 and later are expected to have a version of SYS$SETBOOT that will flag a misaligned SYS$EFI.SYS and (if present) a misaligned SYS$DIAGNOSTICS.SYS file.
For information on SYS$SETBOOT and the SET BOOTBLOCK command, please see Section 14.3.9 and see the OpenVMS documentation. The purpose and intent of the SYS$SETBOOT.EXE image and the SET BOOTBLOCK command is analogous to the WRITEBOOT.EXE image on existing OpenVMS VAX and OpenVMS Alpha systems.
For information on CD and DVD optical media drives on OpenVMS, please
see Section 14.30.
9.8 What I/O transfer size limits exist in OpenVMS?
The maximum transfer size is an attribute of the particular I/O device, controller and driver combination; there is no inherent limit imposed by OpenVMS (other than the fact that, today, byte counts and LBNs are generally limited to 32 bits).
The maximum size of a device I/O request is limited by the value in UCB$L_MAXBCNT, which is set by the device driver based on various factors. (Also check the setting of the MAXBUF system parameter for buffered I/O transfers, and check the process quotas.)
Currently, SCSI drivers limit I/O transfers to FE00(16) bytes, 65024 bytes (decimal). The reasons for this transfer size limitation are largely historical. Similarly, DSSI devices are limited to the same value, this for hardware-specific reasons. Transfers to HSC and HSJ device controllers via the CI are limited to 1,048,576 bytes. Client MSCP-served devices are limited to 65535 bytes---to help ensure that the I/O fragmentation processing happens on the client and not on the server system.
Parts of the OpenVMS I/O subsystem are optimized for data transfers less than 64KB, because (obviously) most I/O operations are (substantially) less than that. OpenVMS can handle larger transfers, if the driver and the device can handle it.
Also see Section 9.4, Section 9.5.
9.9 Can I use ODBC to connect to OpenVMS database files?
Yes, you can use various available third-party packages that permit remote ODBC clients to access RMS files and various commercial databases via the network.
For RMS, consider acquiring one of the packages available from EasySoft, Attunity Connect (formerly known as ISG Navigator), Oracle (DB Integrator), SolutionsIQ, OpenLink Software (OpenLink Universal Data Access), and Synergex.
The unixODBC package available at http://www.unixodbc.org has variously been found to operate on OpenVMS, as well.
For specific commercial databases (other than RMS, of course), contact
the database vendor directly for assistance.
9.10 If my disks are shown as VIOC Compatible, am I using XFC?
Yes, you are using XFC caching.
Disks that are using XFC caching use communication and coordination protocols that are compatible with the older VIOC caching implementation. With the initial implementation of XFC on OpenVMS, you can use the command SHOW MEMORY/CACHE to see no disks reported in full XFC mode; all disks shown will be listed in "VIOC Compatable Mode".
If you have the OpenVMS system parameter VCC_FLAGS set to 2 and are using OpenVMS Alpha V7.3-1 or later, or are using OpenVMS Alpha V7.3 with the VMS73_XFC V2.0 ECO kit or later or with the UPDATE kits, you are using XFC.
Another confusion: the XFC product version is and remains V1.0 in all
released configurations, please do not confuse the internal XFC product
version (displayed by various commands) with the version number
associated with the various ECO kit(s). XFC V1.0 does not permit
volumes to enter full XFC caching, as displayed by the "Vols in
Full XFC mode"
portion of the DCL command SHOW MEMORY/CACHE output.
9.11 RMS Sequential Files and Platform Portability?
When working with mixed platforms, you will want to become familiar with the various RMS sequential record formats, including Variable with Fixed Control (VFC), stream, stream LF, and stream CR, among other record formats.
Switching formats uses CONVERT/FDL or SET FILE/ATTRIBUTES. The former converts files, the latter resets attributes. Text editors tend to select attributes when creating new files that may or may not meet requirements. If the default attributes do not match your requirements, create a stub file, SET FILE/ATTR, then edit the existing file. (Most editors will preserve attributes on an existing file.)
When working with Windows, stream is usually the best choice for sequential file operations. Stream LF is most commonly used with UNIX and C applications. Windows and UNIX tend not to be able to directly read files of "unexpected" sequential RMS record formats.
VFC is a common OpenVMS format, encoding the record length into the record. It is this extra data that can cause corruption-like problems when viewed without RMS; either directly via $qio or via the file system API on other operating system platforms. You will want to look at the low-level record formats, and at the RMS and the Files and Applications documentation in the OpenVMS manuals.
If transfering through other platforms, use of a current version of Zip (with the "-Vv" or "-Vv9" option) and unzip, or use of a BACKUP saveset will contain and maintain the RMS file and record attributes. (For BACKUP and its own attributes requirements, see the restoration tool.)
Please first review the OpenVMS Programming Concepts Manual and the Guide to Modular Programming manuals. Both are available within the OpenVMS documentation set, and provide details of the expected norms for OpenVMS programs.
OpenVMS provides a registry for facility prefixes and for MESSAGE message compiler codes. To request a prefix and a message facility code for a product you distributinng to other customer sites, send your request in a mail message addressed to product[-at-sign-]hylndr.sqp.zko.dec.com, requesting the submission form and details of the registration process.
Please do not request facility prefixes for products that local to your business, your site, or your system. Facility prefixes and message codes and the facility registration process are intended solely for HP products and Partner Products (and yes, even OpenVMS Freeware packages) that will be distributed across multiple OpenVMS customer sites. |
For a list of common coding bugs, please see the remainder of this section of the FAQ and specifically Section 10.22, please also see the Ask The Wizard topic (1661), and for information on debugging an OpenVMS application, please see topic (7552).
For additional information on the OpenVMS Ask The Wizard (ATW) area and
for a pointer to the available ATW Wizard.zip archive, please see
Section 3.9.
10.2 Can I have a source code example of calling...?
Please use the available SEARCH command on OpenVMS, and please remember to search the available resources, including the support databases and the newsgroup archives. Please also realize that most OpenVMS system services use similar calling sequences, meaning that an example of calling sys$getjpi can be used as an example for sys$getsyi and sys$getdvi. Students: please do not expect folks to write your homework for you. As for search resources:
OpenVMS programming documentation, including the numerous example programs found in recent versions of the OpenVMS Programming Concepts manual, is available:
As for details of argument passing, most OpenVMS system services and RTL routines pass string arguments by descriptor. Languages which support native string data types create descriptors automatically; those which do not (eg., C) require that you set them up explicitly. For further details on using descriptors and particularly for using descriptors from C, please see Section 10.13.
There is extensive information available on how to call OpenVMS system services and OpenVMS Run-Time Library routines, including examples in numerous languages. Among the best available references are:
In addition, if you are a subscriber to the HP Software Information Network (available to those with a software support contract), the support database contains hundreds of worked examples of calling system services and RTL routines, including the one that seems to trip up almost everyone, SMG$CREATE_MENU.
Arne Vajhøj has put together a collection of OpenVMS example programs. It can be found at:
Additional information and examples for OpenVMS are available via:
For additional information on the OpenVMS Ask The Wizard (ATW) area and for a pointer to the available ATW Wizard.zip archive, please see Section 3.9. and via:
If you're writing a program and want to accept arguments from a foreign command, you can use LIB$GET_FOREIGN to get the command line and parse it yourself, or if you're programming in C, use the normal argc/argv method.
To write an application which uses the normal DCL verb/qualifier/parameter syntax for invocation, see the description of the CLI$ routines in the OpenVMS Callable Utility Routines Reference Manual.
It is possible to write an application which can be used both ways; if a DCL verb isn't used to invoke the image, the application parses the command line itself. One way to do this is to call CLI$GET_VALUE for a required parameter. If it is not present (or you get an error), call LIB$GET_FOREIGN to get the command line and do the manual parse.
See also Section 8.1.
10.4 How do I get a formatted error message in a variable?
Use the SYS$PUTMSG system service with an action routine that stores
the message line(s) in the variable of your choice. Be sure the action
routine returns a "false" (low bit clear) function value so that
SYS$PUTMSG
doesn't then try to display the message (unless you want it to.) See
the description of $PUTMSG in the System Services Reference Manual for
an example of using an action routine.
10.5 How do I link against SYS$SYSTEM:SYS.STB on an Alpha system?
LINK/SYSEXE is the OpenVMS Alpha equivalent of linking against SYS.STB. This links against the base image: SYS$BASE_IMAGE.EXE
Also see Section 10.11, particularly for pointers to the details on
shareable images and shareable image creation.
10.6 How do I do a SET DEFAULT from inside a program?
The problem is that SYS$SETDDIR only changes the default directory -
NOT the default disk. The default disk is determined by the logical
SYS$DISK. If you want to change the default disk within a program, then
call LIB$SET_LOGICAL to change the logical SYS$DISK. You will need to
call both LIB$SET_LOGICAL and SYS$SETDDIR to change both default disk
and the default directory!
10.7 How do I turn my Fortran COMMON into a shareable image on Alpha?
You need to add SYMBOL_VECTOR=(<common-name>=PSECT) to your options file. On OpenVMS VAX all OVR/REL/GBL psects were automatically exported into the shareable image's Global Symbol Table. On OpenVMS Alpha you have to tell the linker that you want this done by means of the PSECT keyword in the SYMBOL_VECTOR options file statement.
This has several advantages over OpenVMS VAX. First, you don't have to worry about the address of the psect when you try to create a new, upwardly compatible version of the shareable image. Second, you can control which psects, if any, are made visible outside the shareable image.
By default, COMMON PSECTs in HP Fortran for OpenVMS Alpha (as well as most other OpenVMS Alpha compilers) are NOSHR. On VAX, the default was SHR which required you to change the attribute to NOSHR if you wanted your COMMON to be in a shareable image but not write-shared by all processes on the system. If you do want write-sharing, use:
CDEC$ PSECT common-name=SHR |
in the Fortran source code (the CDEC$ must be begin in column 1) or a linker options file PSECT_ATTR statement to set the COMMON PSECT attribute to SHR.
For further information, see the Linker manual.
10.8 How do I convert between IEEE and VAX floating data?
In OpenVMS V6.1 and later, the routine CVT$CONVERT_FLOAT is documented in the LIB$ Run-Time Library Reference Manual, and can perform floating point conversions between any two of the following floating datatypes: VAX (F,D,G,H), little-endian IEEE (single, double, quad), big-endian IEEE (single, double, quad), CRAY and IBM System\370, etc.
HP Fortran (all OpenVMS platforms) has a feature which will perform automatic conversion of unformatted data during input or output. See the HP Fortran documentation for information on "non-native data in I/O" and the CONVERT= OPEN statement keyword.
There are floating-point conversion source code packages available for various platforms.
For further floating-point related information, see:
On VAX, many programmers would use a MACRO routine which accessed the AP register of the caller to get the address of the argument list and hence the argument count. This was not guaranteed to work on VAX, but usually did. However, it doesn't work at all on OpenVMS Alpha, as there is no AP register. On Alpha systems, you must use a language's built-in function to retrieve the argument count, if any. In Fortran this is IARGCOUNT, which is also available in DEC Fortran on OpenVMS VAX.
Note that omitting arguments to Fortran routines is non-standard and is
unsupported. It will work in many cases - read the DEC Fortran release
notes for additional information.
10.10 How do I get a unique system ID for licensing purposes?
Many software developers desire to use a unique hardware ID to "lock" a given copy of their product to a specific system. Most VAX and Alpha systems do not have a unique hardware-set "system ID" that can be used for this purpose. HP OpenVMS products do not use hardware IDs in the licensing methods, as many users consider a hardware-based licensing scheme to be negative attribute when considering software purchases.
HP OpenVMS uses a software-based system called the License Management Facility (LMF). This provides for software keys (Product Authorization Keys or PAKS) which support capacity and user-based license checking. HP offers an LMF PAK Generator to CSA members---see Section 2.13.
For information on licensing, please see Section 12.5.
However, if a hardware-based method is required, the most common method is based on an Ethernet adaptor hardware address. Sample source code for implementing this is available at:
For additional information on the OpenVMS Ask The Wizard (ATW) area and
for a pointer to the available ATW Wizard.zip archive, please see
Section 3.9.
10.11 What is an executable, shareable, system or UWSS image?
Executable code in OpenVMS typically resides in an image---an image is a file---the file extension is typically .EXE---that contains this code. Common types of images include executable images, shareable images, system images, and protected (UWSS) images.
Executable images are programs that can be directly executed. These images can grant enhanced privileges, with an INSTALL of the image with /PRIVILEGE, or can grant enhanced access with the specification of a subsystem identifier on the ACL associated with the image.
Shareable images contain code executed indirectly, these images are referenced from executable images and/or from other shareable images. These images can not grant enhanced privileges, even with the use of INSTALL with /PRIVILEGE or a subsystem identifier. These shareable images can be dynamically activated (a LINK that occurs at run-time) via the LIB$FIND_IMAGE_SYMBOL run-time library (RTL) routine. (See `protected images' for information on `privileged shareable images'.)
System images are intended to run directly on the VAX or Alpha hardware---these are normally used for the kernel code that comprises an operating system.
Protected images---also refered to as User-Written System Services (UWSS), or as privileged shareable images---are similiar in some ways to a standard shareable images, but these images include a `change mode' handler, and execute in an `inner' processor mode (privileged mode; executive or kernel), and code executing in inner modes has implicit SETPRV privilege. Must be INSTALLed with /PROTECT. Note that inner-mode code has restrictions around calling library routines, around calling various system services, and around calling code located in other protected or shareable images.
Loadable images and device drivers are images that can be used to add code into the OpenVMS kernel. Pseudo-device drivers are a particularly convenient way to add executable code, with associated driver-defined data structures, into the kernel. The pseudo-device driver includes the UCB and DDB data structures, and a calling interface with support for both privileged and unprivileged access to the driver code via sys$qio[w] calls.
A cookbook approach to creating OpenVMS shareable images is available at the URL:
For additional information on the OpenVMS Ask The Wizard (ATW) area and for a pointer to the available ATW Wizard.zip archive, please see Section 3.9.
| Previous | Next | Contents | Index |