This chapter describes applications that may benefit the most from using DECram disks, how to identify and locate files that can be stored on a DECram disk, and how using a DECram device might adversely affect system operations.

3.1 Recommended Applications for a DECram Disk

There are two general classes of applications that benefit substantially from using a DECram disk:

• Applications that frequently use system images
• Modular applications that produce temporary, transient files

Applications that frequently use system images execute a DCL command file in response to a user command. By placing the images and their associated libraries as well as heavily accessed data files on a DECram disk, execution speed improves. While it is possible to install some of the shared images as resident and thereby improve performance, the DECram disk can be used for data access, command procedures, or any other files that you simply want to run faster.

If the system fails or is shut down, you must reinitialize and then remount the local DECram disk. The system startup file must invoke a command procedure that can perform these functions. Shared disks are automatically created. A system startup file can mount the shared DECram disk for immediate use of saved data.

Modular applications often accept input files, perform operations on the data, and write output files. These output files are then read by another program that produces other files, and so on. The application runs with greater efficiency if these intermediate input and output files are stored on a DECram disk. If the system fails or is shut down, it is necessary to restart the application from the beginning, or from a checkpoint if the application was a long-running continuous process.

3.1.1 Identifying Commonly Used Images

You can use the LIST command provided by the OpenVMS Install Utility (INSTALL) to identify commonly used images that may benefit from being stored on a DECram device. INSTALL tracks the number of times an image was accessed since installation.

By executing the INSTALL LIST command periodically and examining the output, you can determine the most frequently used images, as shown in the following example:

$ INSTALL LIST/FULL

This command produces output that is similar to what follows:

DISK$DUA0:<SYS0.SYSCOMMON.SYSEXE>.EXE ANALIMDMP;1 Prv Entry access count = 0 Privileges = CMKRNL CMEXEC AUTHORIZE;1 Prv Entry access count = 0 Privileges = CMKRNL CDU;1 Open Hdr Prv Entry access count = 0 Current / Maximum shared = 0 / 0 Privileges = CMEXEC COPY;1 Open Hdr Shar Entry access count = 12 Current / Maximum shared = 0 / 2 Global section count = 1 DCL;1 Open Hdr Shar Lnkbl Entry access count = 21 Current / Maximum shared = 0 / 3 Global section count = 1

The output shows that only the COPY.EXE and DCL.EXE files, as indicated by the entry access count, have been accessed since the last installation. This indicates that they might be potential candidates for storage on a DECram device.

3.1.2 Using DECram Disks with a Workstation

Diskless workstations that access conventional disks over Ethernet can also use a DECram disk to improve performance. Because the most commonly used images are stored on the DECram disk, page faults and image activation occur locally, rather than over the Ethernet. While products such as XFC (a dynamic cluster caching product) can adjust over time to provide a high hit rate for frequently accessed images, only DECram can provide you with a 100 percent hit rate.

3.1.3 Storing SYS$SCRATCH Files on a DECram Disk

You can significantly improve system performance by using a DECram disk to hold scratch files produced by OpenVMS images, shareable images, and layered products.

Table 3-1 lists some of the OpenVMS images, shareable images, and layered products that open temporary files on SYS$SCRATCH.

Table 3-1 Sources of Temporary Files

SYS$LIBRARY:ADARTL.EXE	SYS$SYSTEM:DTM.EXE
SYS$LIBRARY:CMS$$MAILSHRP.EXE	SYS$SYSTEM:EDT.EXE
SYS$LIBRARY:CONVSHR.EXE	SYS$SYSTEM:MAIL.EXE
SYS$LIBRARY:EDTSHR.EXE	SYS$SYSTEM:NOTES.EXE
SYS$LIBRARY:MAILSHRP.EXE	SYS$SYSTEM:PCA.EXE
SYS$LIBRARY:NOTES$MAILSHRP.EXE	SYS$SYSTEM:SORTMERGE.EXE
SYS$LIBRARY:PPLSHR.EXE	SYS$SYSTEM:VERIFY.EXE
SYS$LIBRARY:SMGSHR.EXE	SYS$SYSTEM:VMSTAILOR.EXE
SYS$LIBRARY:SORTSHR.EXE

To access SYS$SCRATCH files that are sent to a DECram disk, each user must have a directory on the DECram disk and define the logical name SYS$SCRATCH to point to that directory.

You can create a directory by using the following format at the DCL command CREATE/DIRECTORY:

$ CREATE/DIRECTORY MDA0:[directory]

You must define the logical name SYS$SCRATCH to point to the directory on the DECram disk by using the following format:

$ DEFINE SYS$SCRATCH MDA0:[directory]

where MDA0 represents the name of the DECram disk, and directory represents the name of the user's directory on the DECram disk.

3.1.4 Recovering Writable DECram Files

Compaq recommends that you store only small, frequently accessed files, such as temporary (scratch) files or read-only files, because data can be permanently lost if the node on which it exists fails or if the DECram device is reinitialized.

If you have stored and lost writable data, you can recover those files by using OpenVMS RMS after-image journaling (AIJ). This is a layered product and requires a usage license. It can be used to recover critical, writable files stored on the DECram device. See the RMS Journaling for OpenVMS Manual (available on the OpenVMS documentation CD-ROM) for more information on RMS after-image journaling.

3.2 Using a Search List to Locate Files

You can use a search list to move a subset of files from a conventional disk to a DECram disk. A search list instructs the operating system to look for files on the DECram disk first, before looking for the files on a conventional disk. A search list is a logical name that has more than one translation, as shown in the following example:

$ DEFINE WORKFILE [WILSON.NOTES],[WILSON.WORK] $ SHOW LOGICAL WORKFILE "WORKFILE" = "[WILSON.NOTES]" (LNM$PROCESS_TABLE) = "[WILSON.WORK]"

If you use the logical name CONSTRUCTION to point to the directory SYS$SYSDEVICE:[CONSTRUCTION], and you have moved only a subset of the files in that directory to the DECram disk, redefine the logical name CONSTRUCTION as a search list, as shown in the following example:

$ DEFINE/SYSTEM CONSTRUCTION "MDA0:[CONSTRUCTION]", - _$ "SYS$SYSDEVICE:[CONSTRUCTION]"

Once the logical name has been redefined, any file lookup that uses the search list will examine each translation of the logical name to find the file. In this example, the CONSTRUCTION directory on the DECram disk will always be searched first. Defining a search list allows you to place a subset of the files addressed by a logical name on a DECram disk, while leaving the other files on the conventional disk. Any new file creations that use the search list will be created on the DECram disk because it is the first translation of the search list.

To prevent this loss, redefine the search list back to its former definition before installing the product. This deletes the DECram disk from the search list, as shown in the following example:

$ DEFINE/SYSTEM CONSTRUCTION "SYS$SYSDEVICE:[CONSTRUCTION]" $ SHOW LOGICAL CONSTRUCTION - _$ "CONSTRUCTION" = "SYS$SYSDEVICE:[CONSTRUCTION]"

After the software installation completes, redefine the logical name to add the DECram disk back to the search list.

3.3 Shadow Sets of DECram Devices

Compaq recommends that shadow sets of DECram devices consist of at least two members. A volume shadow set consisting of a single member that is a DECram device is subject to the failure scenario detailed in Section 3.4.3.

Starting with DECram Version 3.0 software, DECram devices can be shadowed to real physical disks or partitions. This is useful for applications that rely on data integrity and also require enhanced performance. The Volume Shadowing for OpenVMS software will read from the DECram device, rather than from the physical device, thereby providing a performance advantage.

The Volume Shadowing for OpenVMS software will write to both the physical disk and DECram disk, so those writes will take longer than reads. The advantage of Volume Shadowing for OpenVMS software writing to both the physical disk and DECram disk is that data integrity is preserved. If a node fails, all data on the physical disk or a partition is still available and is not lost.

3.4 DECram Limitations

This section describes how using a DECram device can have a negative effect on system operation.

3.4.1 Impact to Paging and Swapping

Using DECram disks reduces the size of the free page list. This may affect paging and swapping because of reduced available memory and could reduce or eliminate any performance gain in the I/O speed.

Some applications may require changing the values for the following system parameters for DECram disk memory requirements:

• FREELIM
• GROWLIM
• FREEGOAL

The following system parameters may need to be increased if you move installed images onto the DECram disk and reinstall them:

• GBLSECTIONS
• GBLPAGES

See the OpenVMS System Management Utilities Reference Manual: M--Z for information on system parameters.

3.4.2 I/O Delay Characteristics Affecting DECram Use

Using a DECram disk alters the execution characteristics of the system and of the applications that use DECram disks for I/O operations. I/O operations that use DECram disks are CPU intensive; the I/O is essentially a movement of data from system memory to user memory that executes in the system context. Therefore, applications that implicitly rely on I/O delay characteristics are not recommended for DECram disk use.

In some cases, applications that do not consume large quantities of CPU resources because they are limited by I/O delay throughput will suddenly become very CPU-bound. The applications become CPU-bound because there is no waiting for I/O operations to complete. This change in CPU consumption could then affect other users on the system.

3.4.3 Implications of Local Served and Shadowed DECram Devices

The failure characteristics of a DECram disk present an interesting problem in a served environment. The failure characteristics of a DECram disk are as follows:

• When the controller for the CPU where the memory allocated to the DECram disk resides fails, the media is destroyed as well.
• When the controller is reinitialized, the DECram disk devices that existed prior to system failure are no longer present.

When any DECram device has memory allocated to it (that is, it is initialized with a size of non-zero), a record of this is made in the SYS$COMMON:[SYSMGR]MDRECOVER.DAT file. Conversely, when the DECram device has memory released (that is, it is initialized to a size of zero), that memory deallocation is recorded in the same file.

During system initialization the SYS$COMMON:[SYSMGR]MDRECOVER.DAT file is interrogated. If any records of DECram devices that had memory allocated to them are found, the I/O database for those devices is restored.

When the MOUNT verification process on the other OpenVMS Cluster members interrogates these restored DECram devices, the MOUNT verification terminates and the applications currently using the devices receive an error status for any outstanding I/Os. No further use of these devices, such as dismounting them clusterwide and reinitializing them on the serving OpenVMS Cluster member, can be made.