This chapter provides information about new features for all users of the HP OpenVMS Integrity servers and OpenVMS Alpha systems.

2.1 Operating Environments

With this release, the operating environments (OEs) providing OpenVMS elements have been changed:

• The three tier Operating Environment model which consisted of Foundation Operating Environment (FOE), Enterprise Operating Environment (EOE) and Mission Critical Operating Environment (MCOE) is replaced with a two tier Operating Environment model consisting of Base Operating Environment (BOE) and High Availability Operating Environment (HA-OE) in OpenVMS Version 8.4.
• BOE license includes all components of FOE and two components from EOE. The following products that were formerly part of the EOE are now part of the BOE:
  • DECram for OpenVMS
  • HP OpenVMS Management Station
• HA-OE license includes four components of EOE, all components of MCOE, and Global Work Load Manager (gWLM). The following products that were formerly part of the EOE are now part of the HA-OE:
  • HP Availability Manager
  • OpenView Performance Agent (OVPA) for OpenVMS
  • RMS Journaling for OpenVMS
  • HP Volume Shadowing for OpenVMS
• The FOE Licenses automatically upgrades to BOE and EOE or MCOE licenses automatically upgrades to HA-OE, up on upgrading to OpenVMS Version 8.4.

HP products deliver on "trustworthy and reliable" brand promise. The electronic cryptographic "signature" created for HP code (software, firmware, drivers, applications, patches, solutions, and so forth) provides you an industry standard method to verify the integrity and authenticity of the code you have received from HP before deployment.

Digitally signed code helps you manage the security vulnerability risk from using non-HP versions of our product's software and firmware, which may fail to meet expectations and, worse, may harbor malicious code (such as a virus or a worm).

Further to comply with the other markets, such as mobile code, firmware in FIPS compliant devices, and increased threats posed by standard firmware interfaces HP products are delivered with this digital sign.

Earlier, OpenVMS followed its own signing mechanism based on Common Data Security Architecture (CDSA). During the installation of the kits, PCSI used the CDSA Validator to verify the signature. Kits created in either sequential (*.PCSI) or compressed (*.PCSI$COMPRESSED) formats were signed. Kits using VMSINSTAL for installation were not signed.

All new OpenVMS kits, which are updated for Version 8.4, including PCSI and VMSINSTAL based kits are signed using HP Code Signing Service (HPCSS). A new companion file, <full kit name>_HPC is created and is provided along with the kit. The kit is then verified using the companion file.

From OpenVMS Version 8.4, a new product, HPBinarychecker, will get installed on OpenVMS systems to validate the kits signed using HPCSS. VMSINSTAL and PCSI are enhanced to use the validator. HP supplied Layered Products that use VMSINSTAL will be signed the way in which the PCSI kits were signed.

To validate the signed kit with the _HPC file extension, use the HPBinaryChecker executable. If the HPBinaryChecker is not available, PCSI displays that the HPBinaryChecker is not loaded and prompts you to install the Product. If the _ESW manifest file is present and no _HPC file is present, PCSI uses CDSA to validate the kit. CDSA validation will not be retired.

CDSA signing for OpenVMS Version 8.4 and beyond will be discontinued. For more information on installing the signed kit, see HP OpenVMS Version 8.4 Upgrade and Installation Manual.

2.3 DCL Commands and Lexical Functions

Table 2-1 and Table 2-2 summarizes the new and changed DCL commands, qualifiers, and lexical functions for OpenVMS Version 8.4. The new features related to DCL usage are described in the following sections. For more information, see the HP OpenVMS DCL Dictionary.

Table 2-1 Updates to DCL Commands

DCL Commands	Description
DELETE	New /TREE qualifier added to delete all the files and sub directories recursively excluding the parent directory.
SET PROCESS	New /KERNEL_THREAD_LIMIT qualifier can be used to specify the maximum number of kernel threads that a process can use.
SEARCH/STATISTICS	New OUTPUT and SYMBOLS keywords can be used with SEARCH /STATISTICS.
SET VOLUME	New /CACHE qualifier added to the SET VOLUME command along with the new keywords DATA, NODATA and CLEAR_DATA. Using this qualifier, you can dynamically enable or disable or clear XFC caching for the volume.
MOUNT/CACHE	New DATA and NODATA keywords added and can be used with the MOUNT/CACHE command.
BACKUP	New BACKUP/DATA_FORMAT=COMPRESS=[DEFLATE] qualifier added to create a compressed save set.

Table 2-2 Updates to DCL Lexicals

DCL Lexical	Description
F$GETDVI	New item codes added. For more information about F$GETDVI, see Section 2.3.5.

2.3.1 New Keywords for SEARCH/STATISTICS

You can use the following keywords with the SEARCH/STATISTICS qualifier:

Keyword	Description
OUTPUT	Writes the statistic output lines into the output file in addition to the standard SYS$OUTPUT device. The default is /NOSTATISTICS=OUTPUT.
SYMBOLS	Defines the symbol to hold statistic values. The default value is /STATISTICS=SYMBOLS. Following are the symbol names: SEARCH$CHARACTERS_SEARCHED - Displays the number of characters searched. SEARCH$FILES_SEARCHED - Displays the number of files searched. SEARCH$LINES_PRINTED - Displays the number of lines printed. SEARCH$RECORDS_MATCHED - Displays the number of records matched. SEARCH$RECORDS_SEARCHED - Displays the number of records searched.

2.3.2 BACKUP Compression Support

The OpenVMS BACKUP utility is enhanced to create and restore a compressed save set. The compressed save set can be created on disks and magnetic tapes. The compression ratio depends on the data content in the files.

A new BACKUP/DATA_FORMAT=COMPRESS=[algorithm] qualifier is added to support data compression. Where: algorithm is the compression algorithm name that has to be specified. By default, DEFLATE is the compression algorithm used, which is provided by the ZLIB library.

2.3.3 Support up to Sixteen Parameters as Command Line Input with DCL Command Procedures

DCL supports up to 16 optional parameters as input to a command procedure. To specify the optional parameters, set the bit 3 of DCL_CTLFLAGS to 1. The symbols, P1, P2, . . . P16, are assigned character string values in the order of entry. Similarly, you can specify sixteen optional parameters when using CALL to a subroutine. Clearing the bit 3 of DCL_CTLFLAGS, sets the default parameters to P1, P2, . . . P8.

2.3.4 F$CUNITS Lexical Enhancement

In addition to Blocks to Bytes conversion, F$CUNITS supports additional conversion units, such as B, KB, MB, GB, and TB. You can specify Blocks, B, KB, MB, GB, and TB as keywords for the "from-units" and "to-units" units. The result is rounded to 2 decimal places for conversions using new units.

The new keyword "B" is added for non scaled conversion to Bytes. This is to ensure the backward compatibility of auto scaling when "BYTES" keyword is specified.

Format - F$CUNITS(number [,from-units, to-units])

Where;

number - Specifies a 32-bit (or smaller) number to convert.

from-units - Specifies the unit of measure from which to convert. When only first argument present, the default option for this field is BLOCKS. Supported options for this field are BLOCKS, B, KB, MB, GB, and TB.

to-units - Specifies the unit of measure to which to convert. When only first argument is present, or the second argument is BLOCKS, the default option for this field is BYTES and result gets rounded off to appropriate "to-unit". Supported options for this field are BLOCKS, BYTES, B, KB, MB, GB, and TB.

Examples:

• The following example converts 1024 Blocks to equivalent in KB and the result is 512 KB.

  $ WRITE SYS$OUTPUT F$CUNITS(1024,"BLOCKS","KB") 512KB

• The following example converts 1024 Blocks to Bytes and auto scales the output supporting backward compatibility.

  $ WRITE SYS$OUTPUT F$CUNITS(1024,"BLOCKS","BYTES") 512KB

• The following example converts 1024 Blocks to non scaled Bytes value.

  $ WRITE SYS$OUTPUT F$CUNITS(1024,"BLOCKS","B") 524288B

"CONFLICT" warning message is displayed when the "BYTES" keyword is used for other than "BLOCKS" to "BYTES" conversion.
For example:

$ WRITE SYS$OUTPUT F$CUNITS (512,"BYTES","BLOCKS") %DCL-W-CONFLICT, illegal combination of command elements - check documentation \BYTES\ $ WRITE SYS$OUTPUT F$CUNITS (10,"KB","BYTES") %DCL-W-CONFLICT, illegal combination of command elements - check documentation \BYTES\

Correct syntax:

$ WRITE SYS$OUTPUT F$CUNITS (512,"B", "BLOCKS") 1BLOCKS $ WRITE SYS$OUTPUT F$CUNITS (10,"KB","B") 10240B

For more information about handling numeric values outside the range of DCL integer representation using DCL, see the HP OpenVMS DCL Dictionary.

2.3.5 F$GETDVI Lexical Function: New Item Codes

The F$GETDVI lexical function is enhanced with two new item codes NOCACHE_ON_VOLUME and NOXFCCACHE_ON_VOLUME. Specifying NOCACHE_ON_VOLUME with F$GETDVI returns TRUE or FALSE to indicate whether high-water marking is disabled on the volume. Specifying NOXFCCACHE_ON_VOLUME with F$GETDVI returns TRUE or FALSE to indicate whether the XFC caching is disabled on the volume.

2.3.5.1 F$GETDVI Lexical Function: Handling Numeric Values Outside the Range of DCL Integer Representation

The F$GETDVI lexical function items MAXBLOCK, FREEBLOCKS, EXPSIZE, and VOLSIZE are typically used to return information that depends on the target disk size. On OpenVMS Version 8.4, if the target disk size exceeds 1 TiB, these F$GETDVI items can return apparently negative numbers. This is because DCL does 32-bit signed integer arithmetic and comparisons. Command procedures that use F$GETDVI( ) with these item codes may need to be modified to work with volumes larger than 1 TiB.

For more information about handling numeric values outside the range of DCL integer representation using DCL, see the HP OpenVMS DCL Dictionary.

2.4 2 TiB Volume Support

OpenVMS Version 8.4 adds support for SCSI disk volumes of size up to 2 TiB. The precise new maximum volume size is given by:

(65534 * 255 * 255) blocks = 4,261,348,350 blocks, which is about 1.98 TiB.

Applications that have calculations or comparisons involving logical or virtual block numbers (LBN or VBN) must be inspected for use with volumes larger than 1 TiB. Unmodified applications will continue to work as before on volumes smaller than 1 TiB.

For more information about handling numeric values outside the range of DCL integer representation using DCL, see the HP OpenVMS DCL Dictionary.

With OpenVMS Version 8.4, support for disks greater than 1 TiB is available only with SCSI disks.

2.4.1 2 TiB Restrictions

With OpenVMS versions prior to version 8.4, there is no support for volumes larger than 1 TiB in size or for mounting of volumes larger than 1 TiB. To prevent accidental mounts on earlier versions of OpenVMS, the latest patches for MOUNT will explicitly disallow mounting of volumes larger than 1 TiB on such systems.

The OpenVMS BACKUP utility is extended to support volume size up to 2 TiB.

For more information, see the HP OpenVMS System Management Utilities Reference Manual.

2.5 Per-Process Kernel Thread Limit

This feature is added to limit the number of kernel threads that can be created in a process. It allows you to set a value that is lower or equal to the current value of the SYSGEN parameter, MULTITHREAD. OpenVMS is enhanced to control the kernel-thread limit on a per-process basis.

Per-process kernel thread limit can be controlled using one of the following methods:

• Using DCL, for example:

  $ SET PROCESS/KERNEL_THREAD_LIMIT=n $ RUN/KERNEL_THREAD_LIMIT=n $ SPAWN/KERNEL_THREAD_LIMIT=n

• Using the $CREPRC system service. A new argument, PRC$M_KT_LIMIT is added to stsflg, which assigns the specified kernel thread limit to the created process. Set the PRC$M_KT_LIMIT flag and add the optional "kt_limit" argument.
• Using the $SET_PROCESS_PROPERTIESW system service. Set the PPROP$C_KERNEL_THREAD_LIMIT property for the process, and specify the number in the "value" argument.

Per-process kernel thread limit can be viewed using one of the following methods:

• $ SHOW PROCESS
• $ F$GETJPI("pid", "KT_LIMIT")
• $GETJPI system service by using the JPI$_KT_LIMIT item code
• LIB$GETJPI runtime library routine by using the JPI$_KT_LIMIT item code.

OpenVMS Version 8.4 has been enhanced to dynamically enable or disable data cache (XFC) for mounted volumes. In the earlier versions, XFC caching attributes of the volume were specified when the volume was mounted. Therefore, to modify the XFC caching attributes, the volume had to be dismounted and mounted again with the appropriate XFC caching attributes.

OpenVMS now allows XFC caching attribute of the volume to be dynamically modified without dismounting the volume. The SET VOLUME command is enhanced to allow modifications to the XFC caching attributes of the volume. For example:

• SET VOL V1/CACHE=DATA
  This command enables XFC caching for the volume V1. The contents of volume V1 available in the cache are not affected.
• SET VOL V1/CACHE=NODATA
  This command disables XFC caching for the volume V1. The contents of volume V1 available in the cache are not affected.
• SET VOL V1/CACHE=CLEAR_DATA
  This command clears contents of volume V1 available in the cache. The caching attributes of the volume V1 are not affected.
• SET VOL V1/CACHE=(DATA,CLEAR_DATA)
  This command enables XFC caching for the volume V1 and clears contents of volume V1 available in the cache.
• SET VOL V1/CACHE=(NODATA,CLEAR_DATA)
  This command disables XFC caching for the volume V1 and clears contents of volume V1 available in the cache.

Prior to OpenVMS Version 8.4, mounting a disk with /CACHE or /NOCACHE qualifier enabled or disabled both the data cache, that is, XFC and meta data cache (XQP).

With OpenVMS Version 8.4, XFC cache can be enabled or disabled independent of XQP cache. The /CACHE qualifier of the MOUNT command now accepts two new values, DATA and NODATA to enable and disable the XFC cache.

The following are some examples for enabling and disabling the XFC cache:

• The following command enables XFC on a disk. The /CACHE=DATA qualifier is the default value for the basic MOUNT command

  $ MOUNT/CACHE=DATA- _$ $1$DGA0: FILES WORK %MOUNT-I-MOUNTED, FILES mounted on $1$DGA0: (NODE_NAME)

• The following command disables XFC on a disk. The /NOCACHE also implies /CACHE=NODATA. Note that the new qualifier does not affect the behavior of metadata (XQP) cache.

  $ MOUNT/CACHE=NODATA- _$ $1$DGA0: FILES WORK %MOUNT-I-MOUNTED, FILES mounted on $1$DGA0: (NODE_NAME)

• The following command disables data, that is XFC and metadata XQP cache. /NOCACHE qualifier implies /CACHE=NODATA.

  $ MOUNT/NOCACHE- _$ $1$DGA0: FILES WORK %MOUNT-I-MOUNTED, FILES mounted on $1$DGA0: (NODE_NAME)

The new values DATA and NODATA with the /CACHE qualifier are not supported in the earlier versions of OpenVMS. In a mixed-version OpenVMS cluster, an attempt to mount a volume with /CLUSTER and /CACHE=[NO]DATA from an OpenVMS Version 8.4 system fails on the earlier versions of OpenVMS systems (%MOUNT-W-RMTMNTFAIL) with the MOUNT-F-BADPARAM error.

2.8 Mail Utility Enhancements

This section describes the mail enhancements in OpenVMS Version 8.4.

2.8.1 Support for More Than 255 Characters in Mail Headers

Support for more than 255 characters in mail headers has been added, as per the RFC 2822 standard. The headers include attributes such as Subject, To, CC, and From fields. You can now send and receive messages with headers up to 998 characters.

2.8.2 Mail Forwarding Entry Limit Increased

The forward username string length has been increased from 31 to 255 characters. To utilize this long username string, set bit 4 of the DCL_CTLFLAGS system parameter. After this bit is set, the username length is set to a maximum length of 255 characters. Even if this bit is cleared, the behavior remains unchanged, that is, the username length with 255 characters is still supported. Note that the character length cannot be reset to 31 characters.

2.9 High Precision Time

The High Precision Time ($GETTIM_PREC) system service returns the current system time in 64-bit format. The quadword is the number of 100 nanoseconds since November 17, 1858.

On Integrity servers and Alpha systems, the frequency at which system time is updated varies among platforms. Generally, the system time is updated approximately once in a millisecond. $GETTIM_PREC returns the system time after accounting for the time elapsed since the last one millisecond update of the system time on Integrity servers.

The argument to the service is identical to that of the existing system service SYS$GETTIM. There is an additional status return, SS$_LOWPREC, which indicates that the high precision time could not be obtained and only the 1ms resolution time is returned.

On Alpha systems, this service is equivalent to $GETTIM service and returns the last updated system time. On successful completion, the status of the service on Alpha is SS$_LOWPREC.