HP OpenVMS Version 8.3 New Features and Documentation Overview


Previous Contents Index

3.1.3 Additional CTRL/T Messages

When you use BACKUP to back up or restore data interactively, you can press Ctrl/T to display the progress of the operation. In OpenVMS Version 8.3, this information is increased in one of the following situations:

The additional information now displayed is the following:

You can use the new /PROGRESS_REPORT qualifier to send the expanded message to the current output device.

3.1.4 New /PROGRESS_REPORT Qualifier

When you include the new /PROGRESS_REPORT qualifier while performing the BACKUP operations described in Section 3.1.3, a message indicating the progress of the BACKUP operation is sent to the output device.

3.1.5 New /IO_LOAD Qualifier

In OpenVMS Version 8.3, BACKUP is optimized to work more efficiently with new storage controllers. You can use the /IO_LOAD qualifier to increase or decrease the number of simultaneous READ I/Os that occur on your system.

The format of the command and qualifier is the following:


BACKUP /IO_LOAD=n

where n is an integer whose value can be between 1 and the process AST limit. The default value is 8, which is used if the /IO_LOAD qualifier is omitted from the command line.

3.2 CD and DVD Optical-Media Recording Tools

OpenVMS Version 8.3 supports new tools for recording CD and DVD optical media. These tools permit OpenVMS users to easily and directly record locally mastered disk volumes or disk image files onto a CD-R, CD-RW, DVD+R, or DVD+RW optical-media recording device. The resulting optical-media data disks generated by the recording tools can be used as part of data-archiving operations, mastering software distribution, and similar tasks.

The COPY/RECORDABLE_MEDIA command and related tools and diagnostics are intended to supplement and to eventually replace existing uses of the SYS$MANAGER:CDRECORD.COM CD optical-media recording tool.

For the COPY/RECORDABLE_MEDIA command, see the HP OpenVMS System Management Utilities Reference Manual and for support requirements and capabilities, see Chapter 4 in this manual.

3.3 OpenVMS for Integrity Servers Cluster Satellite Support

OpenVMS Version 8.3 supports cluster satellite booting for OpenVMS for Integrity server (I64) systems. The manner and requirements for I64 satellite systems differs greatly from those for Alpha. Read this section thoroughly before attempting to add an I64 system to your cluster.

3.3.1 Differences between Alpha and I64 Satellites

Table 3-1 lists the differences between Alpha and Integrity server satellites.

Table 3-1 Differences Between Alpha and Integrity Server Satellites
  Alpha Integrity Servers
Boot Protocol MOP PXE (BOOTP/DHCP/TFTP)
Crash Dumps May crash to remote system disk or to local disk via Dump Off the System Disk (DOSD) Requires DOSD. Crashing to the remote disk is not possible.
Error Log Buffers Always written to the remote system disk. Error log buffers are written to the same disk as DOSD.
File protections No different than standard system disk. Requires that all loadable execlets are W:RE (the default case) and that certain files have ACL access via the VMS$SATELLITE_ACCESS identifier.

Satellite

Any OpenVMS Version 8.3 system or a nPartition of a cell-based system can be used as a satellite. Support for nPartitions may require a firmware upgrade.

Satellite boot is supported over the core I/O LAN adapters only. All satellite systems must contain at least one local disk to support crash dumps and saving of the error log buffers across reboots. Diskless systems will not be able to take crash dumps in the event of abnormal software termination.

Boot Server

All Integrity server systems supported by OpenVMS Version 8.3 are supported as boot servers. At this time, HP does not support cross-architecture booting for Integrity server satellite systems, so any cluster containing Integrity server satellite systems must have at least one Integrity server system to act as a boot node as well.

Required Software

As with other satellite systems, the system software is read off of a disk served by one or more nodes to the cluster. The satellite system disk may be the same as the boot server’s system disk but need not be. Unlike with Alpha satellites, where it was recommended but not required that the system disk be mounted on the boot server, I64 satellite systems require that the system disk be mounted on the boot server.

TCP/IP must be installed on the boot server’s system disk. OpenVMS Version 8.3 must be installed on both the boot server’s system disk and the satellite’s system disk if different.

TCP/IP must be configured with BOOTP, TFTP and one or more interfaces enabled. At least one configured interface must be connected to a segment visible to the satellite systems. The boot server and all satellite systems will require an IP address. Please see the HP TCP/IP Services for OpenVMS Version 5.6 Installation and Configuration for details about configuring TCP/IP Services for OpenVMS.

3.3.2 Collecting Information from the Satellite System

If the satellite has a local disk with a version of OpenVMS installed, log in. If not, you may boot the installation DVD and select option 8 (Execute DCL commands and procedures) and execute the following commands:


$ LANCP :== $LANCP 
$ LANCP SHOW CONFIG 


 LAN Configuration: 
 Device Parent Medium/User Version Link Speed Duplex Size  MAC Address       Current Address   Type 
 ------ ------ ----------- ------- ---- ----- ------ ----  ----------------  ----------------  ---- 
 EIB0          Ethernet    X-16    Up   1000  Full   1500  00-13-21-5B-86-49 00-13-21-5B-86-49 UTP i82546 
 EIA0          Ethernet    X-16    Up   1000  Full   1500  00-13-21-5B-86-48 00-13-21-5B-86-48 UTP i82546 

Record the MAC address for the adapter you will use for booting. You will need it when defining the satellite system to the boot server. If the current address differs from the MAC address, use the MAC address.

3.3.3 Setting up the Satellite System for Booting and Crashing

If the satellite has a local disk with a version of OpenVMS installed, log in. If not, you may boot the installation DVD and select option 8 (Execute DCL commands and procedures.) Use SYS$MANAGER:BOOT_OPTIONS.COM to add a boot menu option for the network adapter from which you are booting. The procedure will ask you if this network entry is for a satellite boot and if so, it will set the Memory Disk boot option flag (0x200000) for that boot menu entry. The memory disk flag is required for satellite boot.

If you intended to use the system primarily for satellite boot, place the network boot option at position 1. The satellite system also requires DOSD (Dump Off the System Disk) for crash dumps and saving the unwritten error log buffers across reboots and crashes. BOOT _OPTIONS.COM may also be used to manage the DOSD device list. You may wish to create the DOSD device list at this time. See the HP OpenVMS System Manager's Manual, Volume 2: Tuning, Monitoring, and Complex Systems for information about setting up a DOSD device list.

3.3.4 Defining the Satellite System to the Boot Server

I64 Satellite systems boot via the PXE protocol. On OpenVMS, PXE is handled by BOOTP from the TCPIP product. If you are using more than one I64 boot server in your cluster, be sure the BOOTP database is on a common disk. See the TCPIP documentation for information on configuring TCPIP components. TCPIP must be installed, configured and running before attempting to define a satellite system.

On an I64 boot server, log in to the system manager’s or other suitably privileged account. Execute the command procedure SYS$MANAGER:CLUSTER_CONFIG_LAN.COM. (CLUSTER_CONFIG.COM, which configures satellite nodes using DECnet, does not support I64 systems. It will, however, automatically invoke CLUSTER_CONFIG_LAN for I64 systems.) CLUSTER_CONFIG_LAN is a menu-driven command procedure designed to help you configure satellite systems. The menus are context-sensitive and may vary depending on architecture and installed products. If you are unfamiliar with the procedure, please see refer to the System Management documentation for a more extensive overview of CLUSTER_CONFIG_LAN.

The essential information required to add an I64 satellite includes the node’s SCS node name, SCS system ID, and hardware address. In addition, you will need to know the satellite’s IP address, network mask, and possibly gateway addresses. If you are unfamiliar with these concepts, please refer to the TCPIP documentation. The procedure will create a system root for the satellite.

CLUSTER_CONFIG_LAN should perform all steps required to make the satellite system bootable. If you choose local paging and swapping files, you will be prompted to boot the satellite system into the cluster so that the files may be created. If not, paging and swapping files will be created on the served system disk and you may boot the satellites at your convenience.

3.3.5 Booting the Satellite

If you have previously added an option to the boot menu, select that option. If you haven't, please see your hardware documentation for the steps required to boot from a network adapter. Be sure to set the environment variable VMS_FLAGS to include the memory disk boot flag (0x200000). The system will detail boot progress in the form of a system message when VMS_LOADER is obtained from the network, followed by one period character written to the console device for every file downloaded to start the boot sequence and last by a message indicating that IPB (the primary bootstrap image) has been loaded.

Note the following example:


Loading.: Satellite Boot EIA0 Mac(00-13-21-5b-86-48) 
Running LoadFile() 
 
CLIENT MAC ADDR: 00 13 21 5B 86 48 
CLIENT IP: 16.116.43.79  MASK: 255.255.248.0  DHCP IP: 0.240.0.0 
 
TSize.Running LoadFile() 
 
Starting: Satellite Boot EIA0 Mac(00-13-21-5b-86-48) 
Loading memory disk from IP 16.116.43.78 
............................................................................ 
Loading file: $13$DKA0:[SYS10.SYSCOMMON.SYSEXE]IPB.EXE from IP 16.116.43.78 
%IPB-I-SATSYSDIS, Satellite boot from system device $13$DKA0: 
 
 
    HP OpenVMS Industry Standard 64 Operating System, Version V8.3 
    © Copyright 1976-2006 Hewlett-Packard Development Company, L.P. 
 

Upon first full boot, the satellite system will run AUTOGEN and reboot.

3.3.6 Additional Tasks on the Satellite System

If you had not done so previously, create the dump file for DOSD at this time. Edit the SYS$STARTUP:SYCONFIG.COM file and add commands to mount the DOSD device. In order for the error log buffers to be recovered, the DOSD device must be mounted in SYCONFIG.

3.4 Dynamic Lock Remastering---LOCKRMWT

The method by which OpenVMS makes decisions to remaster lock trees is updated for OpenVMS Version 8.3. Prior to Version 8.3, the decision-making method was based on the system parameter LOCKDIRWT. Lock trees migrated to nodes with higher LOCKDIRWT values. If nodes had the same value of LOCKDIRWT, then lock trees migrated to the node with higher activity---the amount of higher activity was an extremely small hard-coded threshold and often resulted in lock trees thrashing between nodes.

Version 8.3 implements a new system parameter, lock master weight (LOCKRMWT). This parameter has a range of zero (0) to 10 and a default value of 5. The value of this parameter indicates the weight of the node's willingness to master lock trees. The larger the weight, the greater the likelihood of a tree moving to the node. The values of 0 and 10 are special. A zero indicates that a node does not want to master trees unless the node is the only node with any locks on the resource tree. Any trees mastered on a node with a zero are moved to an interested node as long as the interested node has a LOCKRMWT greater than 0. The value of 10 indicates that a node always wants to master lock trees. If a node with a LOCKRMWT lower than 10 masters a lock tree and a node with a value of 10 is interested, the lock tree remasters to the node with a value of 10.

In other cases, the difference between the current master and the remote node's LOCKRMWT is computed. The larger the difference, the greater the likelihood of the tree being remastered. In the case of nodes having the same LOCKRMWT, the tree is remastered when there is approximately 13% more activity on the remote node. If the remote node had an 8 and the current master a 5, the difference is 3 in this case, the lock tree would move to the remote node at about 2% more activity. In the case of the remote node having a 1 and the current master a 9, then the difference is -8. In this particular case, the lock tree is remastered to the remote node even if doing about 200% more activity than the current master.

The new LOCKRMWT parameter is dynamic and thus can be changed with SYSGEN on the running system. In addition, lock remastering still honors the PE1 system parameter) where a lock tree with more locks than the value in PE1 is not remastered. The LOCKDIRWT parameter no longer controls any aspects of dynamic lock remastering. This parameter now only determines the likelihood of the node managing resource directory entries.

In a mixed-version cluster, the interaction between Version 8.3 nodes and nodes prior to Version 8.3 (which do not have a LOCKRMWT system parameter, still follows the old rules of using LOCKDIRWT. To avoid the situation of a lock tree constantly moving around the cluster, there is one exception to the above rule. A Version 8.3 master node never remasters a lock tree to a pre-Version 8.3 node if an interested node with a higher LOCKDIRWT value exists. This exception is necessary because the pre-Version 8.3 nodes immediately remaster the lock tree to the node with the higher LOCKDIRWT.

The SHOW CLUSTER utility is enhanced to display the LOCKRMWT system parameter for the nodes in the cluster. To view LOCKRMWT, use the command ADD RM_WT or ADD MEMBERS/ALL. For pre-Version 8.3 nodes, this field is displayed as **** to indicate these nodes do not have a LOCKRMWT system parameter.

3.5 Encryption for OpenVMS

OpenVMS Version 8.3 integrates the former Encryption for OpenVMS software product into the operating system. This eliminates the requirement for a separate product installation and product license. In addition, OpenVMS Version 8.3 now includes support for the Advanced Encryption Standard (AES) algorithm, which allows OpenVMS users, system managers, security managers, or programmers to secure their files, save sets, or application data with AES encryption.

Encryption is used to convert sensitive or otherwise private data to an unintelligible form called cipher text. This is done for the purpose of data confidentiality. Decryption reverses this process, taking the unintelligible cipher text and converting the data back into its original form, called plain text. Encryption and decryption are also known as encipher and decipher.

3.5.1 AES Features

AES encryption provides the following features and compatibility:

3.5.2 /CREATE_KEY /AES Command Qualifier

The AES keys (as well as DES keys) are created with the ENCRYPT command-line qualifier /CREATE_KEY. However, for AES keys, the /AES qualifier must be added:


$ ENCRYPT /CREATE_KEY keyname "This is my secret key" / AES 

This currently generates an AES key with a key length of 21 characters. You can specify any length key as long as it meets the key-length minimum requirement and does not exceed Encrypt's maximum number of characters (approximately 240).

3.5.3 AES Key-Length Requirements

The AES key requirements are the actual number of bits used for each of the AES modes. This is actually the minimum number of bytes needed for the encryption or decryption operation. The minimum required key sizes are as follows:

3.5.4 Literal Key Values and ASCII Compression

Note that literal key values are not normally compressed and are passed as is to the encryption algorithm. Literal key values can be ASCII, HEX, or binary. However, ASCII DES key values are compressed if the descriptor data type is of data type DSC$K_TYPE_T, DSC$K_TYPE_VT or DSC$K_TYPE_VT. AES keys are not compressed. Other descriptor data types allow the DES literal key value to not be compressed and to pass through unchanged.

Literal keys values are specified at the command line with the /HEX qualifier or with the literal key flag to the ENCRYPT$DEFINE _KEY() routine. Literal key values can also be passed directly to the ENCRYPT$INIT() routine using the key-type argument and passing the value in the key-name descriptor. DES ASCII key values specified at the command line are subject to compression whether they are quoted or not quoted.

3.5.5 XOR Key Flag, or Key Folding

Encrypt will XOR any extra characters within a key to fold the bytes onto themselves, creating the number of bytes for the algorithm and key size for AES (or DES). This means that the maximum number of bytes (240) can be specified for a key value, but only 32 bytes are stored for AES and only 8 bytes are stored for DES when the key is created.

When this key is used, the original key is recovered, decrypted from storage. But only an 8-byte (folded) key are used for DES, and only 16-, 24-, or a 32-byte (folded) keys are used for AES, depending on the selected AES key size for the cypher operation.

The key size is specified as part of the algorithm-name parameter. For example, "AESCBC256" is specified to one of the following APIs or in the /DATA_ALGORITHM or /KEY_ALGORITHM qualifier to the file ENCRYPT and DECRYPT command:

Creating an AES Key Example

The following example creates a 32-byte AES key. The key is encrypted with AES (currently AESCBC128) and is stored under the name ENCRYPT$KEY$MY_KEY in the process logical name table (by default). The key is flagged as an AES key to distinguish it from a DES key:


$  encrypt/create MY_KEY "This is a sample ASCII key value" /aes/log
%ENCRYPT-S-KEYDEF, key defined for key name = MY_KEY

3.5.6 ENCRYPT$DEFINE_KEY( ) API

AES and DES keys can also be created with the Encrypt application program interface (API), ENCRYPT$DEFINE_KEY( ). The key flags are used to distinguish the type of key (name or literal key value), and the logical name table to store the key.

There is also an AES key flag mask ENCRYPT$M_KEY_AES, and value ENCRYPT$V_KEY_AES, that is used to create an AES key.


ENCRYPT$DEFINE_KEY ( key-name , key-value , key-flags ) 

A random key value can be generated with the ENCRYPT$GENERATE_KEY( ) API.


ENCRYPT$GENERATE_KEY (algorithm-name , key-length              [,factor-a] [,factor-b] [,factor-c]              [,key buffer]) 

AES Key Flag

The following AES mask can be used in addition to (OR with) other flags for the key-flags parameter (as a longword by reference). An associated AES key value can be used for testing the bit within the program. Use the KEY_AES key flag to specify an AES key with the ENCRYPT$DEFINE_KEY( ), ENCRYPT$DELETE_KEY( ), and ENCRYPT$GENERATE_KEY( ) APIs:

3.5.7 Notes on Keys

The following list provides information about keys:


Previous Next Contents Index