V8.2

The User Environment Test Package (UETP) can be used with the following cautions:

• During the load phase, there are sporadic access violations in UETMEMY01. This does not terminate execution or really affect the validity of the run. UETP is still useable and produces valid results.
• The device phase currently does not complete execution due to an access violation.
• The DECnet phase runs fine. The cluster phase is still being tested. It appears to execute properly, but there are some concerns, and the output does not show other system names properly.

Permanent Restriction

Virtual I/O Cache (VIOC) --- also known as VAX Cluster Cache (VCC) --- is not available on OpenVMS I64. On I64 systems, setting the SYSGEN parameter VCC_FLAGS to 1 is equivalent to setting VCC_FLAGS to 0 or not loading caching at all.

HP recommends Extended File Cache (XFC) as the preferred method for caching on both Alpha and I64 systems. For more information about XFC, refer to the HP OpenVMS System Manager's Manual.

In a future release of OpenVMS Alpha, support for VIOC will be removed.

4.23 Volume Shadowing for OpenVMS

The following release notes pertain to HP Volume Shadowing for OpenVMS, also known as host-based volume shadowing (HBVS).

4.23.1 Device Name Requirement

V7.3-2

Volume Shadowing for OpenVMS supports device names whose ddc portion of the full device name of $alloclass$ddcu: is three characters.

Prior to this release, it was possible to create device names whose ddc portion of the full device name was longer, such as $1$DECRAM10:, and these devices mounted successfully. However, mounting such devices as part of a shadow set caused operational problems, such as %MOUNT-F-XSMBRS errors when other disks were added to the shadow set.

Starting with OpenVMS Alpha Version 7.3-2, the Mount utility enforces this three-character requirement for the ddc portion of the full device name during the initial attempt to mount the device. If you attempt to mount a device whose name does not conform to this requirement, the following error message is displayed:

MOUNT-F-NOTSHDWDEV, not a valid shadow set member

4.23.2 Warning About Using SET SHADOW and SHOW SHADOW in DCL Command Procedures

V7.3-2

The new DCL commands SET SHADOW and SHOW SHADOW will continue to evolve. In a future release, the default display and implementation of a SHOW SHADOW/FULL display will change the current formatting. Therefore, HP advises customers not to rely on parsing the current format of output in DCL command procedures to obtain information about the shadow set. Instead, consider using the F$GETDVI lexical function to obtain many of the items displayed by the SHOW SHADOW command.

Furthermore, the behavior of the SET SHADOW command will also change. In addition to other new qualifiers, a new /ALL qualifier will be required if SET SHADOW is used to set characteristics in all shadow sets on a system at the same time.

Please keep these changes in mind if you are writing DCL command procedures that use these new commands.

4.23.3 Write Bitmaps and Dissimilar Device Shadowing (DDS) Caution

V7.3-2

An interaction occurs between write bitmaps and dissimilar device shadowing (DDS) when Volume Shadowing for OpenVMS is used.

DDS, a new feature in OpenVMS Version 7.3-2, allows you to construct shadow sets of disk devices that are of dissimilar sizes. (For details about DDS, refer to the HP OpenVMS Alpha Version 7.3--2 New Features and Documentation Overview manual and HP Volume Shadowing for OpenVMS.)

Write bitmaps keep track of application writes made to a shadow set virtual unit so that a member can be returned to that virtual unit without the overhead of a full copy. A write bitmap is created when the user issues a DISMOUNT/POLICY=MINICOPY command for a shadow set member or mounts a shadow set using the MOUNT/POLICY=MINICOPY command. When this bitmap is created, its size depends on the current size of the volume.

When a shadow set is mounted, the logical size of the shadow set virtual unit is set to the size of the smallest member unit. When a member of the shadow set is removed, the logical size of the virtual unit is recomputed based on the sizes of the remaining members of the set. Consequently, the logical size of the virtual unit may increase.

When a write bitmap is created for a shadow set, its size is determined by the current size of the shadow set virtual unit. If the virtual unit's size subsequently increases, the bitmap will not cover the entire virtual unit. If the bitmap is then used to bring back a shadow set member with a minicopy operation, the portion of the virtual unit that is not covered by the bitmap will be copied with a full copy operation.

The following example illustrates this problem:

• Shadow set DSA1: consists of these three members:

  $1$DGA20: (18 GB)
  $1$DGA21: (36 GB)
  $1$DGA22: (36 GB)

• $1$DGA22: is removed from the shadow set with a minicopy bitmap using the following command:

  $ DISMOUNT/POLICY=MINICOPY $1$DGA22:

  
  The write bitmap is sized for 18 GB, the current size of the shadow set virtual unit.

• $1$DGA20: is removed from the shadow set. To allow the file system to utilize the entire 36 GB of the remaining member, use the following command:

  $ SET VOLUME/SIZE DSA1

  
  $1$DGA20 can no longer be used in this shadow set because it is smaller than the new volume size.

• $1$DGA22: is returned to the shadow set using this command

  $ MOUNT/SYSTEM DSA1:/SHADOW=$1$DGA22: label

  
  The logical size of DSA1: remains at 36 GB; however, the bitmap covers only the first 18 GB.

• The first 18 GB of $1$DGA22: are copied using the minicopy bitmap; the remaining 18 GB are copied using a full copy operation.

If the removal of a smaller shadow set member is planned, removing it before removing a larger member with a minicopy bitmap will cause a larger bitmap to be created and will avoid the performance impact of a short bitmap. (In the preceding example, you would remove $1$DGA20: before removing $1$DGA22:.)

4.23.4 KZPDC (Smart Array 5300) Restrictions

Permanent Restriction

Volume Shadowing for OpenVMS can be used with the KZPDC controller (Smart Array 5300) subject to the restriction that all shadow set members are formed using devices composed of fault-tolerant devices, such as the following:

• RAID 1, also known as controller-based mirroring
• RAID 5, which is striping with parity
• RAID ADG (Advanced Data Guarding), which is striping with multiple parity devices

A fault-tolerant device on the KZPDC (Smart Array 5300) controller is one that can repair data errors when the media yields errors on one of the underlying LUNs.

OpenVMS Alpha Version 7.3-2 and higher supports shadow sets with members whose total block count varies. This new feature is known as dissimilar device shadowing (DDS). DDS allows a KZPDC device to be shadowed with a device from any supported controller.

For all prior OpenVMS versions, all devices must report the same number of total blocks for HBVS to create a multiple-member shadow set. The configuration utility sets the total number of blocks on a KZPDC or MSA1000 device to the closest match that it can make to the requested size. Because the KZPDC and the MSA1000 use the same calculation, a device created on both with the same requested size will be set to the same size. This allows HBVS to create multiple-member shadow sets.

V7.3-2

During an unassisted shadow set merge operation, read I/O performance available to applications is reduced by two factors:

• The need to perform data consistency checks on all read I/Os
• Contention for I/O bandwidth by the shadow set merge operation

The shadow set merge operation employs a throttling mechanism to limit the impact of merge I/O on applications. The merge process is throttled by introducing a delay between merge I/Os when system load is detected. The logic for computing this delay has been redesigned for OpenVMS Alpha Version 7.3-2. With the new merge delay computation, the default parameter settings will result in faster merge rates for some I/O controllers, such as the HSG-80. For more information, refer to the HP Volume Shadowing for OpenVMS manual.

4.23.6 Dismount of Shadow Set Member Using /MINICOPY

V7.3

In a single site or in a multiple-site OpenVMS Cluster configuration, if you issue a DISMOUNT command with the /MINICOPY qualifier from a client system to dismount a shadow set member, the command might fail.

Workaround

If the first DISMOUNT command fails, repeat the command, as shown in the following example:

$! The following commands are NOT executed on the WILD3 system. $ $ SHOW DEVICE DSA5555 Device Device Error Volume Free Trans Mnt Name Status Count Label Blocks Count Cnt DSA5555: Mounted 0 $80$DKA107: 7994646 1 18 $80$DKA107: (WILD3) ShadowSetMember 0 (member of DSA5555:) $80$DKA302: (WILD3) ShadowSetMember 0 (member of DSA5555:) $80$DKA303: (WILD3) ShadowSetMember 0 (member of DSA5555:) $ $ $ DISMOUNT/POLICY=MINICOPY $80$DKA302: %DISM-W-CANNOTDMT, $80$DKA302: cannot be dismounted %DISM-F-SRCMEM, only source member of shadow set cannot be dismounted $ $ $ DISMOUNT/POLICY=MINICOPY $80$DKA302: $

This problem will be corrected in a future release.

4.24 Authentication and Credential Management Extension (ACME)

V8.3

Following are new and changed features in Version 8.3.

• ACME_SERVER restart changes
  In previous releases, the ACME_SERVER process recorded all configuration commands in a staging file, SYS$SYSTEM:ACME$SERVER_CONFIG.TMP. Upon restart, the server used this file to create a data file, SYS$SYSTEM:ACME$SERVER_RESTART.DAT, which contained selected configuration information from the staging file to be processed during restart.
  This method of restoring the server's configuration state following a restart is no longer used and is replaced by a site-specific startup procedure, SYS$MANAGER:ACME$START.COM. The executive-mode logical name ACME$START is used to locate this file.
  SYS$MANAGER:ACME$START.COM is run as a result of one of the following conditions:
  • SET SERVER ACME/START=AUTO command is issued.
  • SET SERVER ACME/RESTART command is issued.
  • Unexpected condition causes an automatic server restart.
  
  The SYS$MANAGER:ACME$START.LOG file contains any information produced during restart in the event of problems.
  Users can modify the SYS$MANAGER:ACME$START.COM file to define which agents are configured during a restart as well as any other server configuration options. This file is not replaced during system upgrades. The SYS$MANAGER:ACME$START.TEMPLATE file contains the HP version of the file.
• New SET SERVER ACME/START[=AUTO] keyword
  The optional keyword AUTO causes the server to startup and configure itself using the SYS$MANAGER:ACME$START.COM procedure. By default, the server starts with only the OpenVMS ACME agent configured.
• SET SERVER ACME/CONFIG=THREAD_MAX ignored on Integrity servers
  The SET SERVER ACME/CONFIG=THREAD_MAX command is ignored on Integrity servers for this release. Only one worker thread is active.
• Optional kit for SYS$ACM-enabled LOUGINOUT.EXE and SETP0.EXE Images
  SYS$ACM-enabled LOGINOUT.EXE and SETP0.EXE (SET PASSWORD) images are available as an optional installation kit. When used with non-OpenVMS ACME agents, these images provide additional authentication features for sites that require them.
  For information about the operational requirements for this kit and a list of supported ACME agents, please refer to SYS$HELP:ACME_DEV_README.TXT.

V8.3

The default settings for starting the OpenVMS ACME agents allow logins to function normally. If the default order of startup for the OpenVMS and Kerberos ACME agents is changed so that the Kerberos ACME is started first, accounts that are not in the Kerberos realm might not be able to log in. Changing the default order of startup is not supported in this release of OpenVMS.

If the startup order is changed, you can change it back to the default order by performing the following procedure.

Edit SYS$MANAGER:ACME$START.COM to search for the section (near the end of the command procedure) where you can specify the desired agent ordering. Change the last line (beginning with AGENT_LIST) so that it appears in the procedure.

$! A specific agent ordering can be specified in AGENT_LIST. $! $! If the list is empty, the agents will be enabled in the order that $! they were configured. Some agent startup procedures may alter $! the agent order. You can override that ordering here. Consult the $! agent documentation you are using to ensure that the ordering you $! specify is supported by that agent. $! $! For example $! $! AGENT_LIST = "VMS,MSV1_0" $! $! will enable the VMS and MSV1_0 agents (and only those agents) in $! that order. $! $ AGENT_LIST = "VMS,ACME_KRB_DOI"

4.26 Traceback API Problem Fixed

In OpenVMS I64 Version 8.2, an error occurred when the pc_rel (relative PC value) or image_desc (image name string descriptor) arguments were specified as zero. The Traceback facility now correctly ignores these arguments and continues Traceback processing.

4.27 WBEM Services for OpenVMS Version 2.0 Release Notes

The following release notes address late-breaking information about Version 2.0 of WBEM Services for OpenVMS.

4.27.1 Based on OpenPegasus 2.5

WBEM Services for OpenVMS Version 2.0 is based on the OpenPegasus 2.5 code stream of the The Open Group's Pegasus open source project.

4.27.2 Supports nPartitions and iCAP

Version 2.0 supports local nPartitions and iCAP providers. Only the functions and capabilities needed by these providers are supported.

4.27.3 Not Designed for Homogeneous Clusters

Pegasus, a UNIX-based product, is not designed for homogeneous clusters. To have the cimserver run on more than one node on a cluster common system disk, install the product on separate roots so that the repository, trace, and log file directories do not conflict.

4.27.4 Restart cimserver.exe to Unload Providers on OpenVMS

After entering the cimprovider -r command, you must stop and restart the cimserver to complete the process of replacing a provider. (OpenVMS does not support unloading a dynamically loaded image.)

4.27.5 Use Quotes Around Command Line Options

Be sure to use quotes around a command line option to preserve its case. For example,
Correct:
$ cimmofl "-E" "--xml"
Incorrect:
$ cimmof -E -xml

4.27.6 Clean Up WBEMCIM Repository Directory Tree After Uninstall

The DCL command PRODUCT REMOVE WBEMCIM does not remove the repository directory tree that WBEM_SERVICES$SETUP.EXE creates after installation. You need to delete SYS$COMMON:[WBEM_SERVICES.VAR...]*.*;* by hand.

If you do not delete the directory tree, when you upgrade or reinstall WBEM, multiple "File already exists" errors are reported when you run WBEM_SERVICES$SETUP.EXE.

4.28 Missing $SIGNAL_ARRAY_64 System Service on I64

V8.3

The system service $SIGNAL_ARRAY_64 is missing on I64. Whe you call this service on I64, you receive a return status of SS$_NOT_LOADED (4026 decimal) . This service will be added in a future release of OpenVMS on I64.

To work around this problem, you can find the address of the 64-bit signal array in the mechanism array at offset chf$ph_mch_sig64_addr . For example, in C, you can replace the following statement:

status = sys$signal_array_64(mech_array, &sig64_array);

with the following statement:

sig64_array = ((CHFDEF2 *)mech_array)->chf$ph_mch_sig64_addr;

4.29 HP OpenVMS System Analysis Tools Manual

V8.3

The following corrections pertain to the HP OpenVMS System Analysis Tools Manual. This manual was not updated for OpenVMS Version 8.3, but the corrections noted here and the additions described in the HP OpenVMS Version 8.3 New Features and Documentation Overview are included in online help for the SDA utility and in related commands for ANALYZE and System Services logging:

4.29.1 Definitions of Bits in DUMPSTYLE

4.29.2 Saving System Dumps

When a dump is being analyzed, it is useful to have data available that cannot be written to the dump file at the time of the system crash. This data includes the full file specification associated with a file identification and, on I64 systems, the unwind data for images activated in processes.

If the dump is being analyzed on the system where it was originally written, this data can be collected for use in the current SDA session using the COLLECT command. If the dump is being copied for analysis elsewhere, the COPY/COLLECT command may be used to collect the data and append it to the copy being written. If the COPY/COLLECT command is used after a COLLECT command, the data already collected is appended to the dump copy.

By default, a copy of the original dump, as written at the time of the system crash, includes collection. You can use COPY/NOCOLLECT to override this. Conversely, a copy of a dump previously copied by SDA without collection (COPY/NOCOLLECT) does not include collection. You can use COPY/COLLECT to override this.

Copying a dump that already contains an appended collection always includes that collection.

For all file and unwind data to be collected successfully, all disks that were mounted at the time of the system crash should be remounted and accessible to the process running SDA. If SDA is started early during startup to save the contents of the dump (for example, using CLUE$SITE_PROC; see Section 2.2.3), but disks are not mounted until a batch job is run, then the COPY/NOCOLLECT command should be used in the CLUE$SITE_PROC command procedure. Once all disks are mounted, a COPY/COLLECT can be used to save file and/or unwind data.

If the COPY and the COLLECT operations cannot be done as a single step, entering the COLLECT/SAVE command writes the collection to a separate file that can be used later in conjunction with the dump file. A later copy combines the two files.

4.29.3 Invoking SDA When Rebooting the System

You might need to include the /NOCOLLECT qualifier to the COPY command. For more information, see the preceding section for details.

4.29.4 SDA CONTEXT

In Section 2.5, in the first list of the SET PROCESS and SHOW PROCESS commands, the SHOW PROCESS/SYSTEM and SHOW PROCESS/NEXT lines should be juxtaposed, and the following lines should be added to the list:

VALIDATE PROCESS/POOL process-name VALIDATE PROCESS/POOL/ADDRESS=pcb-address VALIDATE PROCESS/POOL/INDEX=nn VALIDATE PROCESS/POOL/NEXT VALIDATE PROCESS/POOL/SYSTEM

At the end of the section, the following lines should be added to the bottom of the list of SET PROCESS and SHOW PROCESS commands:

VALIDATE PROCESS/POOL process-name VALIDATE PROCESS/POOL/ADDRESS=pcb-address VALIDATE PROCESS/POOL/INDEX=nn VALIDATE PROCESS/POOL/NEXT