The OpenVMS Frequently Asked Questions (FAQ)


Previous Contents Index

While folks have had success getting PC-based CD-R/RW or DVD-R/RW or DVD+R/RW tools to work with OpenVMS partitions, it is far easier and more reliable to use the OpenVMS-based versions of these tools and directly-attached devices. If you use a Windows-based tool, you will want to specifically select its raw mode, image mode, or block-copy mode, depending on the terminology within the particular tool. The transfer mode and selections is variously refered to as a disk-at-once (DAO) 2048-byte block ISO Mode 1 raw/image/block data disk recording mode.

More details: Creation of CD recordable or DVD recordable media under OpenVMS typically involves one of two approaches: the use of the optional CD-R (`Scribe') capabilities available for the InfoServer or other "offline" hardware packages (PC-based packages will be included in this), or the use of a host-based package such as the CDRECORD or COPY/RECORDABLE_MEDIA (V8.3 and later) or other utilities, including OpenVMS ports of common open-source tools made available by Dr. Eberhard Heuser-Hofmann and various others. Commercial packages and options are also available. Dr. Heuser-Hofmann has DVDwrite , a commercial package which can record DVD media. (

OpenVMS can read ODS-2, ODS-5, and ISO-9660 format CD-ROMs and DVD-ROMs directly. (If you are very careful, you can create a dual-format CD-R; a CD-R with both ODS-2 and ISO-9660 or both ODS-5 and ISO-9660 or both.)

OpenVMS does not support ISO-9660:1999, nor the Joliet or Rock Ridge extensions to ISO-9660, nor can OpenVMS decrypt copy-protected video DVDs.

InfoServer hardware configurations are no longer available from HP, but may potentially be acquired through other means; as used equipment. InfoServer support also has very specific CD-R recording device prerequisites, and these recording devices are no longer generally available.

Packages related to the use of DVD archiving are also available, see the multi-volume capabilities of the DVDarchive/restore Freeware.



 http://www.geocities.com/SiliconValley/Lakes/9999/vmscdwri.html  

Additional information is available at the following sites:

U.S. Design offers a package that includes the tools necessary to create a CD or DVD-R with either ISO-9660 or ODS-2 format, for standalone CD-R/RW, DVD-R, or DVD+R/RW drives, for recent OpenVMS versions. Details are available at:

Also see Section 9.7.2 for details on access to recorded media on older CD-ROM drives.

9.7.1 CD and DVD notation, terminology?

CD-ROM is pre-recorded Compact Disk media, and is the original and oldest CD format. The original CD media was physically stamped, a recording process that is now largely reserved to the highest-volume media reproduction requirements.

CD-R is CD Recordable, a write-once storage medium that can be read by all but the oldest of CD drives; a format which can be read and often even recorded by most CD-RW drives.

CD-RW is CD ReWritable, a format which is readable by many CD drives and by most CD-R drives, and with media that can be recorded and re-recorded by CD-RW drives.

CD media recording speeds are listed as multiples of 150 kilobytes per second, so a 10X drive records at 1500 kilobytes (1.5 megabytes) per second. 600 MB (70 minutes) and 700 MB (80 minutes) recording capacities are both widely available. The minutes designation is derived from the traditional audio-format recording capacity of the particular media.

DVD-R/RW is the older of two common Digital Versatile Disk recording formats, and the DVD-R Recordable or DVD-RW ReWritable media can be read by many DVD drives. As with CD-R formats in older CD drives, older DVD and particularly first-generation DVD players may have problems reading this media format.

DVD+R/RW is the newer of the two common Digital Versatile Disk recording formats, and the DVD+R Recordable or DVD+RW ReWritable media can be read by many DVD drives. Akin to DVD-R/RW media, older and particularly first-generation DVD drives can have problems reading this media format.

The DVD Plus-series drives and media tend to record faster than Minus drives, as (as of this writing) the Plus (+) drives do not require an initial media formatting pass and the Minus (-) drives do. While the appropriate Plus (+) or Minus (-) DVD raw media must be chosen for the particular DVD recorder (and DVD recording drives that are compatible with and capable of using both Plus and Minus media are available), the resulting recorded media is generally readable (playable) in all recent DVD drives and DVD players, regardless of type. (Compatibility is best within the same media-series devices of course, but be certain to verify compatibility across devices regardless of the particular device or particular recording media chosen.)

Presently Plus (+) media is slightly more expensive than Minus (-), but with the prices of all CD and all DVD media continuing to consistently fall, the differences in DVD media costs are becoming irrelevent for all but the production of huge volumes of DVD media.

The rated DVD recording speeds are in multiples of 1353 kilobytes per second, thus a DVD 1X drive is roughly equivalent to a CD 9X drive in I/O requirements and transfer speed.

DVD drive recording speed can and does vary. DVD disk drive recording speed is limited by the rated recording speed of the media used, so the slower (and cheaper) DVD media will not record any more quickly in a faster drive. A 2.4X DVD drive loaded with 1X media will record at 1X.

9.7.2 Use of RRD42 and other older (embossed-media) CD drives?

The RRD42 series SCSI CD-ROM drive is sufficiently old that it can have problems processing CD-R and CD-RW media. Other very old CD drives can have equivalent media compatibility problems when attempting to read (much) newer CD media and newer CD media technologies. These older CD drives are generally intended for use with the so-called embossed media, rather than with non-embossed recorded (recordable) media now in common circulation.

Please consider using a slightly-less-ancient CD-ROM or CD-R or CD-RW drive when working with non-embossed recorded CD media.

To paraphrase one knowledgable---though deliberately nameless---storage engineer, "The RRD42 drive is just past the drooling idiot stage".

9.7.3 Creating Bootable OpenVMS I64 CD or DVD Media? SYS$SETBOOT?

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.29. For additional related information on creating bootable OpenVMS media, please see Ask The Wizard topic (9820).

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 "-V" 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.)

9.12 How to read locked files?

Files can be locked by applications, and various approaches including CONVERT/SHARE and DUMP/ALLOCATED can be used, as can the following command sequence:


$ open/read/share=write x lockedfile.txt 
$ type x 

If you can rebuild the application from source, details related to file sharing are in Section 10.17.


Chapter 10
OpenVMS Programming Information

If you are searching for something here, please consider using the text-format FAQ.

10.1 Modular Programming, Facility Prefixes and Symbol Naming?

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.

Note

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.8. ATW has been superceded (for new questions) by the ITRC discussion forums; the area remains available for reference.

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, you can also locate answers, source code examples and related discussions in the James Search Assistant (formerly NLSA (Natural Language Search Assistant), itself formerly known as Ask Compaq (AskQ)) database:

In this area, you will find the source code of programming examples for calls to many of the OpenVMS system services (and from various programming languages), including calls to core services sys$getjpi[w], sys$getsyi[w] and sys$qio[w], as well as source code examples for calls to many other system services and run-time library routines, and examples of one of the more difficult calling interfaces found on OpenVMS systems, that of the smg$create_menu routine.

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.8. ATW has been superceded (for new questions) by the ITRC discussion forums; the area remains available for reference. and via:

10.3 How do I get the arguments from the command line?

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.2.

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.


Previous Next Contents Index