HP OpenVMS systems documentation

V7.3-2

The server management process, SMHANDLER, now starts automatically on Alpha systems that support it. System managers should remove references to the obsolete startup file, SYS$STARTUP:SYS$SMHANDLER_STARTUP.COM, from SYSTARTUP_VMS.COM or other site-specific startup files. This reference has been removed from SYSTARTUP_VMS.TEMPLATE.

Background: What is SMHANDLER?

On certain Alpha systems, the server management process is started to assist the system firmware in reporting and responding to imminent hardware failures. Failure conditions vary but typically include over-temperature conditions, fan failures, or power supply failures. SMHANDLER may report warning conditions to OPCOM, and may initiate a shutdown of OpenVMS if system firmware is about to power off a failing system. In most situations, a controlled shutdown of OpenVMS would be less disruptive than abrupt loss of system power.

To ensure the longest possible up time, system managers can set the POWEROFF system parameter to 0. This prevents SMHANDLER from shutting down OpenVMS on a failing system but does not prevent system firmware from powering off the system.

4.20 SYSGEN: Security Auditing Fixed

V7.3-2

Previously, enabling SYSGEN audits, or alarms, did not provide any audits or alarms with information about the parameters being modified. As of OpenVMS Version 7.3-2, this problem is corrected. Audits or alarms now provide a list of the changed parameters along with their old and new values.

4.21 SYSMAN Utility

The following release notes pertain to the SYSMAN utility.

4.21.1 DUMP_PRIORITY LOAD Command

V7.3-2

When you use the SYSMAN command DUMP_PRIORITY LOAD to load the contents of the System Dump Priority registry into memory, any entries with a UIC specification of [group-id,*] (for example, [TCPIP$AUX,*]) are ignored --- even though the specification is correct. This will be fixed in a remedial kit for OpenVMS Alpha Version 7.3-2.

Workaround:

You can work around this problem by using the SYSMAN command DUMP_PRORITY MODIFY to remove ",*" from the System Dump Priority registry entry. For example:

SYSMAN> DUMP_PRIORITY MODIFY TCPIP$*/UIC=[TCPIP$AUX,*]/NEWUIC=[TCPIP$AUX]

This workaround creates the identical in-memory contents during a DUMP_PRORITY LOAD command. Any subsequent DUMP_PRIORITY SHOW command displays it as [group-id,*].

The workaround will continue to work even after the remedial kit is installed.

4.21.2 XP LUNs Can Fail to Autoconfigure

V7.3-2

The SYSMAN IO AUTOCONFIGURE command does not configure LUNs on an XP port when a Fibre Channel adapter on a booted host is given access to those LUNs. This problem occurs because of the way the XP array implements selective storage presentation.

You could configure the LUNs by rebooting the host, but any of the following safe, less disruptive workarounds will do the job and can be performed prior to executing SYSMAN IO AUTOCONFIGURE:

• Reset the switch port to which the XP port is connected.
  Depending on the switch type and the access available to it, this might require executing portDisable and portEnable commands or by using a web-based GUI to reset the link.
• Remove and replace either end of the Fibre Channel cable between the XP array and the switch port to which it's connected.
• Generate a link event on each host Fibre Channel adapter that has been given access to the LUNs. Do this by running SYS$ETC:FC$CP for the FGx0 device in the following suggested sequence:
  1. Run FC$CP once for the adapter to see what the current "enables" value is set to.
  2. Run FC$CP again to set a different value for "enables". (The application will not reset the link unless necessary --- and it is not necessary unless the value of "enables" is changed.)
  3. Run FC$CP a third time to restore the original value of "enables".

The first two options have the benefit of being seen by all host Fibre Channel adapters on the fabric that have been given access to the LUNs. However, these options also briefly block access to all other LUNs on the XP port and cause mounted volumes to go through Mount Verify.

The last option limits the disruption to those LUNs whose current path is through the affected Fibre Channel adapter --- even those that are not on the affected XP port --- but the process must be performed for individual adapters.

4.22 System Parameters

The following sections contain notes related to system parameters.

4.22.1 New System Parameters

V7.3-2

The following system parameters are new in OpenVMS Alpha Version 7.3-2:

MVSUPMSG_INTVL
MVSUPMSG_NUM
RMS_CONPOLICY
SHADOW_REC_DLY
SHADOW_SITE_ID

Refer to online help for the definitions of these new parameters.

4.22.2 Modified System Parameters

V7.3-2

Definitions of the following system parameters have been modified in OpenVMS Alpha Version 7.3-2:

CLUSTER_CREDITS
CRD_CONTROL
DUMPSTYLE
FAST_PATH_PORTS
GH_RES_DATA
GH_RSRVPGCNT
LAN_FLAGS
MSCP_CREDITS
MSCP_LOAD
NPAG_BAP_*
RSRVPAGCNT
SCH_CTLFLAGS
SCSNODE
SECURITY_POLICY
SHADOW_MAX_UNIT
TTY_RSPEED
TTY_SPEED

Refer to online help for changes in the definitions of these parameters.

4.22.3 Obsolete System Parameters

V7.3-2

The following system parameters have been removed in OpenVMS Alpha Version 7.2-3:

SHADOW_REMOVE_1
SHADOW_REMOVE_2

V7.3-2

Previously, the documented maximum size of 6 characters for the SYSGEN parameter SCSNODE was not strictly enforced. You could set SCSNODE to a name containing 8 characters, which could lead to device names being too long and producing undesirable effects.

The documented maximum of 6 characters is now strictly enforced. The value of SCSNODE will be truncated by SYSBOOT if the size is set to more than 6 characters in the system parameter file.

4.22.5 AlphaServer GS Series: NPAGERAD System Parameter Default Behavior

V7.3-1

On AlphaServer GS series processors on OpenVMS systems prior to Version 7.3-1, system managers frequently saw pool expansion that increasing NPAGEDYN did not reduce. This problem was caused by leaving NPAGERAD at its default value of 0.

Starting with OpenVMS Version 7.3-1, when NPAGERAD is 0 (the default), the system calculates a value to use for NPAGERAD with the following formula:

Base RAD memory NPAGEDYN * (1- --------------- ) Total memory

This calculation gives more pool to the nonbase RADs than before and so reduces the expansion of nonbase RAD pool.

4.23 Terminal Fallback Facility (TFF)

On OpenVMS Alpha systems, the Terminal Fallback Facility (TFF) includes a fallback driver (SYS$FBDRIVER.EXE), a shareable image (TFFSHR.EXE), a terminal fallback utility (TFU.EXE), and a fallback table library (TFF$MASTER.DAT).

To start TFF, invoke the TFF startup command procedure located in SYS$MANAGER, as follows:

$ @SYS$MANAGER:TFF$SYSTARTUP.COM

To enable fallback or to change fallback characteristics, invoke the Terminal Fallback Utility (TFU), as follows:

$ RUN SYS$SYSTEM:TFUTFU>

To enable default fallback to the terminal, enter the following DCL command:

$ SET TERMINAL/FALLBACK

OpenVMS Alpha TFF differs from OpenVMS VAX TFF in the following ways:

• On Alpha systems, the TFF fallback driver is named SYS$FBDRIVER.EXE. On VAX systems, the TFF fallback driver is named FBDRIVER.EXE.
• On Alpha systems, TFF is capable of handling 16-bit character fallback. The OpenVMS Alpha fallback table library (TFF$MASTER.DAT) contains four more 16-bit character tables than the VAX library. Table 4-2 describes these additional tables.

  Table 4-2 TFF Character Fallback Tables

  Table Name	Base	Description
  BIG5_HANYU	BIG5	BIG5 for CNS 11643 (SICGCC) terminal/printer
  HANYU_BIG5	CNS	CNS 11643 (SICGCC) for BIG5 terminal/printer
  HANYU_TELEX	CNS	CNS 11643 for MITAC TELEX-CODE terminal
  HANGUL_DS	KS	KS for DOOSAN 200 terminal

  
  These tables are used mainly by the Asian region. Also, the table format was changed due to the support of 16-bit character fallback.

• On Alpha systems, the TFU command SHOW STATISTICS does not display the size of the fallback driver (SYS$FBDRIVER.EXE).

RT terminals are not supported by TFF.

For more information about the Terminal Fallback Facility, refer to the OpenVMS Terminal Fallback Utility Manual. You can access this manual on the OpenVMS Documentation CD-ROM (in the archived manuals directory).

4.24 UETP: Error With DEGPA Device

V7.3-2

The User Environment Test Package (UETP) does not currently support DEGPA network devices. If you get an unsupported device error when running UETP and you have a DEGPA device, edit the UETPSUPDEV.DAT file in the SYSTEST directory, and add the following line just before the last line in the file:

20 5D UETUNAS00.EXE ! DEGPA

Then rerun UETP. The device should now test properly.

4.25 VMSINSTAL: NOBROADCAST Option

V7.3-2

Previously, if HELPLIB was in use during a VMSINSTAL installation, messages were automatically sent to all users. VMSINSTAL has been modified to check for logical name VMSINSTAL_NOBROADCAST. If the logical name is set, VMSINSTAL will not send a reply to all users when HELPLIB is in use.

4.26 Volume Shadowing for OpenVMS

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

4.26.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.26.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.26.3 Dissimilar Device Shadowing (DDS): Restriction on Adding First Dissimilar Member

V7.3-2

Dissimilar device shadowing (DDS) is a new feature introduced in OpenVMS Version 7.3-2. This note describes a temporary restriction on when it is advisable to add the first dissimilar member to a shadow set that is currently mounted in the cluster.

A dissimilar member is added to an existing shadow set by using the MOUNT command. For example, the following command adds $1$DGA221 to shadow set DSA22:

$ MOUNT DSA22:/SHADOW=($1$DGA221) VOL22

HP advises that a dissimilar device should be added to an existing non-DDS shadow set only from a node on which the shadow set is currently mounted and only under one of the following conditions:

• The shadow set is currently mounted on only a single node.
• The dissimilar member is added by executing the MOUNT command on the system that was the first to mount the shadow set for its current mount lifetime.

Once a shadow set has dissimilar members, it can safely be mounted or remounted on any other Version 7.3-2 system in the cluster. (Version 7.3-2 is required to access a shadow set with dissimilar members.) Once one dissimilar member has been added to a given shadow set in its current mount lifetime, dissimilar members can be added or removed without restriction as long as that shadow set remains mounted.

Failure to adhere to this restriction results in a continuous level of OpenVMS distributed locking activity between the nodes that currently have the shadow set mounted. Once started, this locking activity will not cease until the shadow set is dismounted from all nodes or from all but one node. This locking activity can interfere with your ability to mount the shadow set on additional nodes and it also consumes system resources. However, this problem does not put your on-disk data at risk.

HP expects to correct this problem in a remedial kit for Version 7.3-2.

4.26.4 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 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.26.5 KZPDC (Smart Array 5300) Restrictions

V7.3-2

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 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

If you attempt to display a bitmap of a shadow set that is no longer mounted on the local node, you may get a SYSTEM-F-INTDIV error if minicopy bitmaps were being used by this shadow set.

To avoid this error, do not attempt to display bitmap information unless the shadow set is mounted. Alternatively, you can try executing the command from another node in the cluster.

This restriction will be removed in a future release of OpenVMS.

4.26.7 SHOW DEVICE/BITMAP Requires LOG_IO Privilege

V7.3-2

In OpenVMS Version 7.3-2, you must have LOG_IO privilege to execute the SHOW DEVICE/BITMAP command. If you do not have LOG_IO privilege, the command shows no bitmaps active.

This temporary restriction will be corrected with a patch in the near future.

4.26.8 Changes in Shadow Set Merge Delay Computation

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.