|
HP OpenVMS Systems Documentation |
|
HP OpenVMS Version 8.3 New Features and Documentation Overview
3.1.3 Additional CTRL/T MessagesWhen 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.
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.
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:
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.
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.
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.
Table 3-1 lists the differences between Alpha and Integrity server satellites.
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.
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:
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.
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.
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.
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:
Upon first full boot, the satellite system will run AUTOGEN and reboot.
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.
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.
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.
AES encryption provides the following features and compatibility:
3.5.2 /CREATE_KEY /AES Command QualifierThe 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:
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).
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 CompressionNote 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.
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:
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:
3.5.6 ENCRYPT$DEFINE_KEY( ) APIAES 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.
A random key value can be generated with the ENCRYPT$GENERATE_KEY( ) API.
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 KeysThe following list provides information about keys:
|