Example of Mastering Optical Media

The following sequence of commands shows how to create a 600 MB CD-R media recording on a CD-capable recording device, using an LD disk LDA600:. Its storage copy file is stored on the device DISK$SCRATCH:. The sequence assumes that a blank CD-R disk is loaded into the target DQA0: drive. A directory is created, and the user's LOGIN.COM file is copied into the directory. After recording is complete, the recorded media contains a single OpenVMS directory called [DATA].

$ @SYS$STARTUP:LD$STARTUP $ LD CREATE DISK$SCRATCH:[000000]CD600.ISO/SIZE=1200000 $ LD CONNECT DISK$SCRATCH:[000000]CD600.ISO LDA600: $ INITIALIZE/ERASE/SYSTEM LDA600: CDDATA $ MOUNT/SYSTEM LDA600: CDDATA $ CREATE/DIRECTORY LDA600:[DATA] $ COPY SYS$LOGIN:LOGIN.COM LDA600:[DATA] $ DISMOUNT LDA600: $ COPY/RECORDABLE_MEDIA LDA600: DQA0:/VERIFY/BELL $ LD DISCONNECT LDA600: $ DELETE DISK$SCRATCH:[000000]CD600.ISO;

Example of Formatting and Recording Data onto a DVD

The following example shows how to format and then record the data stored on a LDA600: disk master onto a DVD+RW drive and its associated DVD+RW media. This media is located on device DQA0:.

$ COPY/RECORDABLE_MEDIA LDA600: DQA0:/FORMAT HP OpenVMS CD-R/RW and DVD+R/RW Utility, V1.0-1 Copyright 1976, 2006 Hewlett-Packard Development Company, L.P. Output device vendor: HL-DT-ST Output device product name: DVD+RW GCA-4040N Output device revision: 1.15 Commencing media format operation Formatting may require up to an hour Output medium format: DVD+RW Input data from: LDA600: Writing data to: DQA0: Input data size: 1200000 blocks Starting operation at: 08:48:17 16 sectors written 30000 sectors written; estimated completion in 00:07:36; at 08:56:44 37000 sectors written; estimated completion in 00:07:37; at 08:56:57 46000 sectors written; estimated completion in 00:07:15; at 08:56:50 57000 sectors written; estimated completion in 00:06:43; at 08:56:34 71000 sectors written; estimated completion in 00:06:33; at 08:56:48 88000 sectors written; estimated completion in 00:05:56; at 08:56:39 110000 sectors written; estimated completion in 00:05:23; at 08:56:42 137000 sectors written; estimated completion in 00:04:37; at 08:56:41 171000 sectors written; estimated completion in 00:03:33; at 08:56:33 213000 sectors written; estimated completion in 00:02:23; at 08:56:32 266000 sectors written; estimated completion in 00:00:59; at 08:56:36 300000 sectors written; operation completed Operation completed at: 08:56:32 Elapsed time for operation: 00:08:14 Synchronizing with output device cache Processing completed $

This chapter describes new features relating to application and system programming in this version of the HP OpenVMS operating system.

5.1 C Run-Time Library Enhancements

The following sections describe the C Run-Time Library (RTL) enhancements included in OpenVMS Version 8.3. These enhancements provide improved UNIX portability, standards compliance, and the flexibility of additional user-controlled feature selections. New C RTL functions are also included. For more details, refer to the HP C Run-Time Library Reference Manual for OpenVMS Systems.

5.1.1 Symbolic Link and POSIX-Compliant Pathname Support

OpenVMS Version 8.3 and higher provides Open Group-compliant symbolic-link support and POSIX-compliant pathname support. This support is intended to help partners and customers who port UNIX and LINUX applications to OpenVMS or who use a UNIX style development environment to reduce the application development costs and complexity previously associated with such porting efforts.

Although this support is present, it does not guarantee 100% compatibility of UNIX files on OpenVMS systems. There may be some cases where developers still need to make modifications to UNIX or LINUX applications when porting them to OpenVMS.

The following OpenVMS features are provided to support symbolic links and POSIX pathname processing:

• The following Open Group compliant symbolic-link functions are added to the C Run-Time Library:

  symlink readlink unlink realpath lchown lstat

• Existing C RTL functions such as creat , open , delete , and remove , now behave in accordance with Open Group specifications for symbolic links.
• RMS allows the C RTL to implement the above-mentioned functions. RMS routines such as SYS$OPEN, SYS$CREATE, SYS$PARSE, and SYS$SEARCH now support symbolic links.
• The contents of symbolic links on OpenVMS are interpreted as POSIX pathnames when encountered during pathwalks and searches. POSIX pathnames are now supported in OpenVMS and are usable through C RTL and RMS interfaces.
• A new feature logical DECC$POSIX_COMPLIANT_PATHNAMES is added to the C RTL to indicate that an application is operating in a POSIX-compliant mode.
• The DCL command CREATE/SYMLINK is used to create a symbolic link.
• The DCL command SET ROOT is provided to create the system POSIX root.
• Two GNV utilities, mnt and umnt , are provided to set mount points.
• DCL commands and utilities are modified to behave appropriately when acting on and encountering symbolic links.
• The TCP/IP Services for OpenVMS Network File System (NFS) client and server are enhanced to support symbolic links on ODS5 volumes.
• Relevant GNV utilities such as ln (which can create a symbolic link) and ls (which can display the contents of a symbolic link) are updated to provide access to and management of symbolic links.

For more information on symbolic links and POSIX pathname processing, see Chapter 12 of the HP C Run-Time Library Reference Manual.

5.1.2 Byte-Range Locking

The C RTL supports byte-range file locking using the F_GETLK, F_SETLK, and F_SETLKW commands of the fcntl function, as defined in the X/Open specification. The OpenVMS lock manager is used to implement this feature. Byte-range file locking is allowed across clusters. You can only use offsets that fit into 32-bit unsigned integers. For more information, see the fcntl function in the HP C Run-Time Library Reference Manual.

5.1.3 New C RTL Functions

In addition to the symbolic link functions listed in Section 5.1.1, the following new functions based on the X/Open specification have been added to the C RTL:

crypt setkey encrypt fchmod

5.1.4 C RTL TCP/IP Header File Updates

The CRTL ships header files for users to call TCP/IP. These headers have had numerous problems, making some of them unusable for anything beyond trivial TCP/IP programming.

Previously, corrected headers have shipped with several releases of TCP/IP in their examples area. This enhancement to the C RTL now places those corrected headers in the C RTL header library (DECC$RTLDEF.TLB). For more information, see the C RTL section of the OpenVMS Version 8.3 Release Notes.

5.2 CDSA for OpenVMS and Secure Delivery

CDSA Version 2.2 for OpenVMS is based on the CDSA open source project. In addition, the CDSA implementation on OpenVMS is based on the Intel V2.0 Release 3 reference platform. New features in CDSA Version 2.2 for OpenVMS include Secure Delivery and support for HRS (Human Recognition Service Standard). These features are described in the following list.

• Support for HRS (Human Recognition Service Standard)
  CDSA Version 2.2 for OpenVMS contains support for HRS (Human Recognition Service). HRS is a CSSM (Common Security Services Manager) EMM (Elective Module Manager). It provides a generic authentication service that is suited for use with any form of human authentication (biometrics) for operation with CDSA.
  The HRS is designed for use by both application developers and biometric technology developers. It covers the basic functions of enrollment, verification, and identification, and includes a database interface to allow a biometric service provider (BSP) to manage the identification population for optimum performance.
• Secure Delivery
  Secure Delivery uses public key and digital signature technology to implement a system that provides OpenVMS users with the ability to authenticate and validate files from OpenVMS and third-party OpenVMS vendors.
  Secure Delivery allows you to create digital signatures for files, so that the file and associated manifest can be delivered over an unsecured channel such as the Internet or CD/DVD media. Once the files are in place on the target system, the manifest is used to authenticate the originator and validate the contents of the target file. If the target file or manifest has been tampered with in any way, the validation process fails. If the certificates used to sign the file have been revoked, the validation process fails.
  Secure Delivery has been integrated into PCSI, which automatically ensures that software installed on OpenVMS was not tampered with prior to installation. PCSI checks for the existence of a manifest for any kits that are being installed. If no manifest is found, PCSI issues a warning and asks if you want to proceed. If a manifest is found but does not match the kit, the installation is aborted. The PCSI database contains an indication as to whether a kit used Secure Delivery on installation.
  Most kits included on the OpenVMS Version 8.3 distribution media have been signed using Secure Delivery. On OpenVMS I64, layered product kits that have a manifest and are installed during or after the OpenVMS upgrade are validated. On OpenVMS Alpha, layered product kits that have a manifest and are installed after the OpenVMS upgrade are validated.
  Kits created before the Secure Delivery process was enabled in OpenVMS Version 8.3 can be installed on OpenVMS Version 8.3. These kits will be marked as unsigned, rather than as a validated kit in the PCSI history file. Products installed before Version 8.3 will have a blank validation status in the PCSI history.

For more information, refer to HP Open Source Security for OpenVMS, Volume 1: Common Data Security Architecture.

For additional information about CDSA, see the Common Data Security Architecture Web site at the following location:

OpenVMS V8.3 now supports the ability for a process to declare a sub-second deadlock wait time for the lock manager. This can be done with the $SET_PROCESS_PROPERTIES system service and the new item code PPROP$C_DEADLOCK_WAIT. The sub-second deadlock wait time overrides the system parameter DEADLOCK_WAIT time. In addition, the $GETJPI system service and F$GETJPI lexical function allow the retrieval of this time by using the item codes of JPI$_DEADLOCK_WAIT and DEADLOCK_WAIT. See the HP OpenVMS System Services Reference Manual and HP OpenVMS DCL Dictionary for more information on the usage.

The system parameter DEADLOCK_WAIT is in second units, so the smallest value you can set is 1 second. The sub-second deadlock wait time set via the system service $SET_PROCESS_PROPERTIES is valid only for the current image and is cleared during image rundown. The parameter passed is in 100nsec units and cannot exceed 1 sec. If the value is too small, then it is increased to a minimum value of 10msec. You can also call this system service to clear a previously set sub-second value by passing a parameter value of zero. Note the following example:

[...] #define TEN_MSEC 100000 uint64 dead_wait; uint64 prev_value; // // Set a 0.5 second deadlock wait time for the current process // dead_wait = 50 * TEN_MSEC; status = sys$set_process_properties ( 0, 0, 0, PPROP$C_DEADLOCK_WAIT, dead_wait, &prev_value ); [...]

5.4 Debugger New Features

The following sections describe new features of the OpenVMS Debugger on OpenVMS Version 8.3.

5.4.1 Improved C++ Support for Operator Names

Support has been improved for C++ operator names, now on Alpha systems as well as Integrity server systems. In particular, user-defined operator names are now supported. Prior to this change, you would have to enclose an operator name in %NAME.

For example:

DBG> SHOW SYMBOL /FULL operator == routine C::operator== type signature: bool operator==(C) code address: 198716, size: 40 bytes procedure descriptor address: 65752 DBG> SET BREAK operator==

5.4.2 Use of SET MODULE Command is Now Optional

Now available on Alpha systems as well as I64 systems, the OpenVMS Debugger can now set modules automatically, making use of an explicit SET MODULE command optional. There are two reasons for this feature:

• The debugger recognizes global symbol names and can determine from the symbol the module in which it is declared.
• The debugger automatically loads the module information when you specify the module name in a debugger command. For example, if you type:

  DBG> SET BREAK X\Y

  
  the debugger ensures that the module information for module X is loaded and then it locates the information for the routine named Y. Previously, the debugger complained that the information in module X was not loaded, whereas now, the debugger loads it automatically.

Now on Alpha systems as well as Integrity server systems, the SHOW STACK command accepts a /START_LEVEL=n qualifier that directs SHOW STACK to begin displaying stack information at call frame level n.

For example, to see the stack information for only frame 3, type the following command:

DBG> SHOW STACK/START=3 1

To see the details for the 4th and 5th stack frames, type the following command:

DBG> SHOW STACK/START=4 2

5.4.4 Change to Default Data Type for Untyped Storage Locations

Now on Alpha systems as well as Integrity server systems, the default data type for untyped storage locations has been changed from longword (32 bits) to quadword (64 bits). Note that storage locations with data type information will continue to be displayed according to the related type.

5.4.5 Improved Overloaded Symbol Support in SHOW SYMBOL Command

Now on Alpha systems as well as Integrity server systems, the SHOW SYMBOL command has been enhanced to recognize overloaded symbol names. Previously, it just printed the various overloaded names. With the enhancement, it now prints each name and the associated information with that name. For example:

DBG> show symbol/full g overloaded name C::g routine C::g(char) type signature: void g(char) address: 132224, size: 128 bytes routine C::g(long) type signature: void g(long) address: 132480, size: 96 bytes

5.4.6 GNAT Pro (Ada 95) Compiler Support Now Available on Integrity Server Systems (I64 Only)

The GNAT Pro (Ada 95) compiler is now supported on OpenVMS for Integrity servers systems. For information on this product, contact AdaCore directly.

Note that HP is not porting the HP Ada (Ada 83) compiler from OpenVMS Alpha to OpenVMS for Integrity servers.

5.4.7 Debugging Programs Loaded into P2 Space Now Supported

The OpenVMS Version 8.3 Debugger now allows you to debug programs loaded into P2 space.

5.4.8 SET WATCH Command Has Been Improved

Watchpoints on a location in memory (called static watchpoints) sometimes fail to notice writes by asynchronous system services and on occasion, might even cause failures of writes by asynchronous system services. For example, an asynchronous write by SYS$QIO to its IOSB output parameter may fail if that IOSB is being watched directly or even if it simply lives on the same page as an active static watchpoint.

The debugger now attempts to notice this condition. When it suspects a problem, the debugger warns the user about potential collisions between static watchpoints and asynchronous system services. For example:

DBG> g %DEBUG-I-ASYNCSSWAT, possible asynchronous system service and static watchpoint collision break at LARGE_UNION\main\%LINE 24192+60 DBG> sho call module name routine name line rel PC abs PC *LARGE_UNION main 24192 00000000000003A0 00000000000303A0 *LARGE_UNION __main 24155 0000000000000110 0000000000030110 FFFFFFFF80B90630 FFFFFFFF80B90630 DBG> ex/sour %line 24192 module LARGE_UNION 24192: sstatus = sys$getsyi (EFN$C_ENF, &sysid, 0, &syi_ile, &myiosb, 0, 0);

Type HELP MESSAGE ASYNCSSWAT in the debugger to learn more about the actions to take when this condition is detected.

5.4.9 Not a Thing (NaT) Support for Integer Registers

Previously, the debugger did not inform the user when an integer register's NaT bit was set. The user had to examine the register's bit in the %GRNAT0 register to learn this information. In the following example, integer registers R9 and R10 have their NaT bits set:

DBG> ex %r9:%r12 TEST\%R9: 0000000000000000 TEST\%R10: 0000000000000000 TEST\%R11: 0000000000000000 TEST\%SP: 000000007AC8FB70 DBG> ex/bin grnat0 <9,4,0> TEST\%GRNAT0+1: 0110 DBG>

The debugger now displays the string "NaT" when the integer register's NaT bit is set. For example:

DBG> ex %r9:%r12 TEST\%R9: 0000000000000000 TEST\%R10: NaT TEST\%R11: NaT TEST\%SP: 000000007AC8FB70 DBG> ex/bin grnat0 <9,4,0> TEST\%GRNAT0+1: 0110 DBG>

Users can still see the actual physical value in a NaT register by specifying a type override. For example:

DBG> ex %r10 TEST\%R10: NaT DBG> ex/quad %r10 TEST\%R10: 0000000000000000 DBG>

5.4.10 Improved Debugger Usability: Automatic Module Loading Now Available

The debugger now automatically loads the symbol table for a module when the module names appear in a path name. Previously, a command like SET BREAK M\R, for example, would fail with an "unknown symbol R" error if the symbols for module M were not loaded. Now, the command succeeds; the debugger loads the symbols for module M first and is then able to locate the symbol R.

5.4.11 Improved Support for C++ Destructors

The debugger now recognizes C++ destructor names. Previously, the user was required to enclose the destructor name with the %NAME lexical. This is no longer required. The following example shows the new behavior:

DBG> examine C::~C C::~C: alloc r35 = ar.pfs, 3F, 01, 00 DBG> DBG> ex/source ~C module CXXDOCEXAMPLE 37: ~C() {}

5.4.12 Support for C++ Template Names

DBG> e Map<string, int>::operator[] Map<string, int>::operator[]: alloc r34 = ar.pfs, 1E, 05, 00

5.4.13 Improved Support for Ada Programs

The debugger now provides partial support for programs written in Ada. The debugger understands most Ada constructs, including packages, child units, procedures, variables, simple data types, and modular types. Support for more complicated data types, such as tagged types and pointers to unconstrained arrays, is expected in a future release.

5.5 Kerberos for OpenVMS

Kerberos Version 3.0 for OpenVMS is based on MIT Kerberos V5 Release 1.4.1. (The previous version of Kerberos, Version 2.1, was based on MIT Kerberos V5 Release 1.2.6.)

New features in Kerberos Version 3.0 are described in the following list.

• Upgrade to MIT Kerberos V5 Release 1.4.1
  Kerberos for OpenVMS Version 3.0 upgrades the code base to MIT Kerberos V5 Release 1.4.1. For a list of major and minor changes in each release of MIT Kerberos, see the Readme file for each release available from the following Web site:
  http://web.mit.edu.kerberos/historical.html
• Kerberos ACME Agent
  Kerberos for OpenVMS Version 3.0 includes the Kerberos ACME agent as part of an Advanced Developer's Kit (ADK). (This support is an addition to the existing Kerberos authentication provided by the Kerberos utilities that are a standard part of MIT Kerberos. It provides functionality similar to the pam_krb5 utility on UNIX systems using Kerberos.)
  In previous versions of OpenVMS, Kerberos for OpenVMS users were required to perform multiple login steps: once to log in to OpenVMS itself, and once to obtain Kerberos credentials. These steps worked with separate principal, or user, names and with separate passwords.
  To use the Kerberos ACME agent, install and setup the ACME Login Advanced Developer's Kit. See the SYS$HELP:ACME_DEV_README.TXT file for information about installation and set up. See the HP Open Source Security for OpenVMS, Volume 3: Kerberos for information about how to configure the Kerberos ACME agent.
  The user authentication will be processed against Kerberos’s KDC database instead of the OpenVMS UAF (User Authorization File). This new feature will give OpenVMS system managers additional flexibility: it will be possible to consolidate user databases so that multiple OpenVMS systems and clusters can be configured to automatically use a single KDC for user authentication.
• Support for AES Encryption
  Kerberos for OpenVMS now includes support for AES (Advanced Encryption Standard). AES is a symmetric key encryption technique which replaces the commonly used Data Encryption Standard (DES). In June 2003 the U.S. Government (NSA) announced that AES is secure enough to protect classified information up to the top secret level, which is the highest security level.
• Support for Kerberized SSH
  Kerberos for OpenVMS supports the Kerberized SSH functionality enabled in HP TCP/IP Services Version 5.6 for OpenVMS. Kerberized SSH allows you to use Kerberos credentials with your SSH (secure shell) connection. (SSH allows you to log into another computer over a network, to execute commands in a remote machine, and to move files from one machine to another.)
• TCP Support in Client Libraries
  Kerberos for OpenVMS includes TCP support in client libraries. This is a Microsoft interoperability enhancement for tickets with a great deal of PAC data.
• Thread-safe KRB5 Libraries
• RPCSEC_GSS Authentication in the Kerberos RPC Library

Kerberos performs authentication as a trusted third-party authentication service by using conventional (shared secret key) cryptography. Kerberos provides a means of verifying the identities of principals, without relying on authentication by the host operating system, without basing trust on host addresses, without requiring physical security of all the hosts on the network, and under the assumption that packets traveling along the network can be read, modified, and inserted at will. After a client and server have used Kerberos to prove their identity, they can also encrypt all of their communications to assure privacy and data integrity.

For more detailed information, refer to HP Open Source Security for OpenVMS, Volume 3: Kerberos.

For information about downloading the latest version of Kerberos for OpenVMS, see the following Web site:

For additional information about Kerberos, see the MIT Kerberos Web site at the following location: