Document revision date: 19 July 1999

This section contains notes pertaining to the OpenVMS file system.

4.15.1 Changes and Enhancements

OpenVMS Version 7.2 introduces significant changes in the way the file system handles the storage bitmap and index file bitmap. These files are in the OpenVMS master file directory (MFD).

The following sections contain notes related to these changes. Also see the OpenVMS System Manager's Manual for information on increases in the limits of storage and index file bitmaps.

4.15.1.1 Performance and Configuration Requirements of Large Bitmaps

V7.2

Although a small cluster factor and a large storage bitmap allow more efficient allocation of small files, they exact a price in potential performance and configuration requirements. To allocate space, the file system scans the storage bitmap sequentially. With a very large storage bitmap, file creation and extension can become very slow when a volume becomes nearly full and, as a result, the file system must work harder to find free space.

Certain file utilities such as MOUNT, SET VOLUME/REBUILD, BACKUP, and ANALYZE/DISK_STRUCTURE allocate virtual memory to hold copies of the index file and storage bitmaps. With larger bitmaps, the virtual memory requirements of these utilities increase correspondingly. To use these utilities on volumes with large bitmaps, you might need to increase your page file quota. On OpenVMS VAX systems, you might also need to increase the system parameter VIRTUALPAGECNT.

Virtual memory requirements for the bitmaps are shown in the following table. Sizes are shown as VAX pages (or Alpha 512-byte pagelets) per block of bitmap. Note that the size of the index file bitmap in blocks is the maximum number of files divided by 4096.

Utility	Virtual Memory Requirement
MOUNT and SET VOLUME /REBUILD	Equal to the sum of the sizes of all index file bitmaps and storage bitmaps on the volume set. This requirement applies to MOUNT only if you rebuild a volume.
BACKUP	Equal to the sum of the sizes of all index file bitmaps on the volume set. (Note that this memory requirement is in addition to the BACKUP utility's substantial buffer pool.)
ANALYZE /DISK_STRUCTURE	Sum of the following across the entire volume set: 3 times all the storage bitmaps plus the largest bitmap in the volume set. 117 times the index file bitmaps. An additional 96 times the index file bitmaps if /USAGE was requested. Approximately 600 pages of additional fixed scratch space.

4.15.1.2 Changing Disk Cluster Factor Can Create Incompatibilities

V7.2

Starting with OpenVMS Version 7.2, the limit on the size of a volume's storage bitmap has increased from 255 to 65535, allowing small cluster factors on all volumes. However, volumes with a storage bitmap larger than 255 blocks cannot be mounted on OpenVMS systems running versions prior to Version 7.2. Doing so results in the following error:

%MOUNT-F-FILESTRUCT, unsupported file structure level

The default behavior of the INITIALIZE command for ODS-2 disks is to limit the bitmap to 255 blocks. The default behavior for the BACKUP command is to limit an ODS-2 bitmap to 255 blocks if the bitmap on the input volume was 255 blocks or smaller. If you specify a cluster factor using INITIALIZE/CLUSTER_SIZE=n or specify BACKUP/NOINITIALIZE, you can create a volume with a bitmap larger than 255 blocks.

You can compute the cluster factor that yields a 255-block bitmap by using the following formula:

Round up fractions to the next whole unit.

For more information about increased bitmap limits, see the System Management chapter in the OpenVMS Version 7.2 New Features Manual. Also see online help or the OpenVMS DCL Dictionary for details about the INITIALIZE and BACKUP commands.

4.15.1.3 Storage Bitmap Might Be Smaller Than Volume Requires

V7.2

The INITIALIZE and BACKUP/IMAGE/INITIALIZE commands have always sized the storage bitmap to correspond to the entire physical volume. This behavior has not changed in OpenVMS Version 7.2. However, beginning with OpenVMS Version 7.2, the file system correctly handles a volume whose storage bitmap is smaller than required. The space on the volume available for allocation is the space the bitmap describes; as a result, if the bitmap is smaller than the volume requires, not all the volume is available for file allocation. A SHOW DEVICE /FULL command continues to display the actual physical volume size; however, the free blocks displayed are the number of blocks actually available for allocation.

The ANALYZE/DISK utility reports a short bitmap with this message:

SHORTBITMAP, storage bitmap on RVN 'n' does not cover the entire device

Do not expect to see this message on Version 7.2 systems. Including support for short bitmaps is done in anticipation of future file system development; no OpenVMS Version 7.2 software causes a disk to have a short storage bitmap.

A volume with a short bitmap functions correctly on OpenVMS Version 7.2 systems. However, do not mount such volumes on OpenVMS Version 7.1 and earlier systems. Older versions of OpenVMS do not handle short bitmaps correctly and might crash if you mount such a volume and attempt to create files on it. Future enhancements to OpenVMS that create volumes with short bitmaps will be limited to Files-11 structure level 5 volumes, which you cannot mount on Version 7.1 and earlier systems.

4.16 POLYCENTER Software Installation Utility

The release notes in this section pertain to the POLYCENTER Software Installation utility. Also see Section 5.18 for notes about this utility that are of interest to programmers.

4.16.1 Changes and Enhancements

This section describes changes to the POLYCENTER Software Installation utility and the DCL interface for the PRODUCT command.

4.16.1.1 DECwindows Motif Interface Retired

V7.2

Beginning with OpenVMS Version 7.2, you can no longer use the PRODUCT/INTERFACE=DECWINDOWS command to invoke the Motif interface for the POLYCENTER Software Installation utility. Although the Motif interface is no longer available, the default character cell interface for the PRODUCT command continues to be fully functional and has been enhanced for Version 7.2.

4.16.2 Problems and Restrictions

Notes in this section pertain to problems and restrictions with using the POLYCENTER Software Installation utility to install, remove, and reconfigure software products. Problems and restrictions of interest to programmers are described in Section 5.18.1.

4.16.2.1 PRODUCT Command Lacks Options to Control Output

V6.2

Commands such as PRODUCT FIND and PRODUCT SHOW that can display more than a screen of text do not provide qualifiers such as /PAGE to control scrolling or /OUTPUT to redirect output to a file. As a result, information can scroll off the screen. Compaq expects to enhance these commands in a future release.

4.16.2.2 Product Removal Restrictions

V6.1

Removing a product using the POLYCENTER Software Installation utility results in the removal of accounts created for that product. This happens regardless of whether the SYSUAF.DAT file is shared by another system disk.

The same problem exists with rights identifiers and the file RIGHTSLIST.DAT.

4.17 RMS Journaling

The following release notes pertain to RMS Journaling for OpenVMS.

4.17.1 Changes and Enhancements

The following note describes a change to RMS Journaling for OpenVMS.

4.17.1.1 Modified Journal File Creation

V7.2

Prior to Version 7.2, recovery unit (RU) journals were created temporarily in the [SYSJNL] directory on the same volume as the file that was being journaled. The file name for the recovery unit journal had the form RMS$process_id (where process_id is the hexadecimal representation of the process ID) and a file type of RMS$JOURNAL.

The following changes have been introduced to RU journal file creation in OpenVMS Version 7.2:

• The files are created in node-specific subdirectories of the [SYSJNL] directory.
• The file name for the recovery unit journal has been shortened to the form: YYYYYYYY, where YYYYYYYY is the hexadecimal representation of the process ID in reverse order.

These changes reduce the directory overhead associated with journal file creation and deletion.

The following example shows both the previous and current versions of journal file creation:

• Previous versions: [SYSJNL]RMS$214003BC.RMS$JOURNAL;1
• Current version: [SYSJNL.NODE1]CB300412.;1

If RMS does not find either the [SYSJNL] directory or the node-specific directory, RMS creates them automatically.

4.17.2 Problems and Restrictions

The following notes describe restrictions to RMS Journaling for OpenVMS.

4.17.2.1 After-Image (AI) Journaling

V7.2

After-image (AI) journaling can be used to recover a data file that becomes unusable or inaccessible. AI recovery uses the AI journal file to roll forward a backup copy of the data file to produce a new copy of the data file at the point of failure.

In the case of a process deletion or system crash, an update can be written to the AI journal file, but not make it to the data file. If only AI journaling is in use, the data file and journal are not automatically made consistent. If additional updates are made to the data file and are recorded in the AI journal, a subsequent roll forward operation could produce an inconsistent data file.

If Recovery Unit (RU) journaling is used in combination with AI journaling, the automatic transaction recovery restores consistency between the AI journal and the data file.

Under some circumstances, an application that uses only AI journaling can take proactive measures to guard against data inconsistencies after process deletions or system crashes. For example, a manual roll forward of AI-journaled files ensures consistency after a system crash involving an unshared AI application (single accessor) or a shared AI application executing on a standalone system.

However, in a shared AI application, there may be nothing to prevent further operations from being executed against a data file that is out of synchronization with the AI journal file after a process deletion or system crash in a cluster. Under these circumstances, consistency among the data files and the AI journal file can be provided by using a combination of AI and RU journaling.

4.17.2.2 Remote Access of Recovery Unit Journaled Files in an OSI Environment

V6.1

OSI nodes that host recovery unit journaled files that are to be accessed remotely from other nodes in the network must define SYS$NODE to be a Phase IV-style node name. The node name specified by SYS$NODE must be known to any remote node attempting to access the recovery unit journaled files on the host node. It must also be sufficiently unique for the remote node to use this node name to establish a DECnet connection to the host node. This restriction applies only to recovery unit journaled files accessed across the network in an OSI or mixed OSI and non-OSI environment.

4.17.2.3 VFC Format Sequential Files

VAX V5.0
Alpha V1.0

You cannot update variable fixed-length control (VFC) sequential files when using before-image or recovery unit journaling. The VFC sequential file format is indicated by the symbolic value FAB$C_VFC in the FAB$B_RFM field of the FAB.

4.18 Security

This section contains release notes pertaining to system security.

4.18.1 Changes and Enhancements

This section describes changes and enhancements to system security.

4.18.1.1 DETACH Privilege Renamed to IMPERSONATE

V7.1

The DETACH privilege has been renamed IMPERSONATE. The power of this privilege has increased over time so that a user with this privilege can now perform a general impersonation of another user.

Some ways that the IMPERSONATE privilege can be used are as follows:

• You can use the DCL command RUN/DETACH/UIC to create a detached process running under another user's identity. (Refer to the OpenVMS DCL Dictionary for details.)
• You can use the $PERSONA_CREATE system service to create a security profile that an application can use to impersonate another user's identity. (See the OpenVMS System Services Reference Manual for details.)

V7.1

In OpenVMS Version 7.1 and later, if you execute the DCL command DIRECTORY/SECURITY or DIRECTORY/FULL for files that contain PATHWORKS access control entries (ACEs), the hexadecimal representation for each PATHWORKS ACE is no longer displayed. Instead, the total number of PATHWORKS ACEs encountered for each file is summarized in this message: "Suppressed n PATHWORKS ACE." To display the suppressed PATHWORKS ACEs, use the DUMP/HEADER command.

4.19 Show Cluster Utility

The notes in this section pertain to the Show Cluster (SHOW CLUSTER) utility.

4.19.1 Documentation Changes and Corrections

The following note describes a change to the SHOW CLUSTER documentation.

4.19.1.1 OpenVMS System Management Utilities Reference Manual: M--Z

V7.2

In earlier releases, the descriptions were incomplete for the EXPECTED_VOTES and QUORUM fields in the MEMBERS class for the ADD (Field) command. The documentation has been updated for this release. The complete descriptions for these fields are as follows:

Field Name	Description
EXPECTED_VOTES	Maximum number of votes that an individual node can encounter. Used as an initial estimate for computing CL_EXPECTED_VOTES. The cluster manager sets this number using the EXPECTED_VOTES system parameter. It is possible for this field to display a number smaller than the EXPECTED_VOTES system parameter setting if the REMOVE_NODE option was used to shut down a cluster member or if the SET CLUSTER/EXPECTED_VOTES DCL command was used since this node was last rebooted. The dynamic value for EXPECTED_VOTES used clusterwide is the CL_EXPECTED_VOTES field, which is described in the CLUSTER class category of ADD (Field).
QUORUM	Derived from EXPECTED_VOTES and calculated by the connection manager. It represents an initial value for the minimum number of votes that must be present for this node to function. The dynamic QUORUM value is the CL_QUORUM field, which is described in the CLUSTER class category of ADD (Field).

4.20 SYS$EXAMPLES

This section contains release notes pertaining to SYS$EXAMPLES.

4.20.1 Changes and Enhancements

The following release note describes a change to SYS$EXAMPLES.

4.20.1.1 SET PREFERRED_PATH Command Replaces PREFER.MAR and PREFER.CLD

V7.2

PREFER.MAR and PREFER.CLD have been removed from SYS$EXAMPLES. However, even though these files no longer ship on the operating system, they are not deleted from an existing system during an upgrade. You can delete them or save them.

The new DCL command SET PREFERRED_PATH replaces the functionality formerly provided by PREFER.MAR and PREFER.CLD. Refer to online help or the OpenVMS DCL Dictionary for details about the SET PREFERRED_PATH command.

	privacy and legal statement
6534PRO_010.HTML