# DECram for OpenVMS User's Manual

Previous | Contents | Index

# Chapter 3
Using a DECram Disk

This chapter describes which applications benefit from using DECram disks, how to identify and locate files that can be stored on a DECram disk, and how using a DECram device can negatively affect system operation.

# 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; and 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 on a DECram disk, execution speed is improved. If the system fails or is shut down, you must re-create, reinitialize, and remount the DECram disk. The system startup file must invoke a command procedure that performs these functions.

Note If system files are installed on a DECram device, you cannot dismount that DECram device while system files are installed or open. Installed system files are open as long as they are mapped into a process.

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 were long running.

## 3.1.1 Identifying Commonly Used Images

The LIST command provided by the OpenVMS Install utility (INSTALL) identifies commonly used images that may be 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 the following output:

    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; they are 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 use a DECram disk to improve performance. Because the most commonly used images would be stored on the DECram, page faults and image activation would occur locally, rather than over Ethernet.

Another use of a DECram disk with a workstation is when the workstation application, such as a CAD/CAM (computer-aided design/computer-aided manufacturing) application, contains a large drawing. Using a DECram disk would reduce the time required to display and modify the drawing.

A workstation must have 32 MB of memory to use a DECram disk.

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

Note If the system, on which the device physically exists, fails or is taken out of service, any journal or scratch files created by the images, shareable images, and layered products listed in Table 3-1 will be permanently lost.

Table 3-1 Sources of Temporary Files
DECchart | SYS$SYSTEM:CMS.EXE
DECpresent | SYS$SYSTEM:CONVERT.EXE
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 for 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]

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

Beginning with OpenVMS VAX and OpenVMS Alpha Version 6.1, if you have stored and lost writable data, you can recover those files by using OpenVMS RMS after-image journaling (AIJ). See the RMS Journaling for OpenVMS Manual for more information on RMS after-image journaling.

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.

# 3.2 Using a Search List to Locate Files

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.

Note If you redefine system logical names and then install a product, the files that result from that installation could be stored on the DECram disk. These files will be lost if the system fails or is taken out of service.

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.

The example in Section A.1 shows the use of a 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 2.3, when run on OpenVMS Alpha Version 7.1 or higher, 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 disk and DECram disk, so that writes will take longer than reads. The advantage of Volume Shadowing for OpenVMS software writing to both 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; it 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 MSCP 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 (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.

In a served environment, this failure scenario causes OpenVMS Cluster members actively using the failed DECram disk to wait for MVTIMEOUT seconds before they are notified that the device had failed.

This condition has been addressed and corrected with Version 2.0 of DECram for OpenVMS.

### 3.4.3.1 Enhanced Operation

When an MSCP served or a shadowed DECram device has memory allocated to it (that is, it is initialized with a size of nonzero), a record of this is made in the SYS$SPECIFIC:[SYSMGR]DECRAM$RECOVER.DAT file. Conversely, when the DECram device has memory released (that is, it is initialized with a size of zero), that memory deallocation is recorded in the same file.

During system initialization, the SYS$SPECIFIC:[SYSMGR]DECRAM$RECOVER.DAT file is interrogated and 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.

# Appendix A
DECram Configurations

This appendix contains templates to configure a DECram disk on both OpenVMS VAX and OpenVMS Alpha systems, and an example on how to use the DECRAM$CONFIG command procedure.

# A.1 DECram Configuration Template for VAX Systems (VAX Only)

The following template is a sample procedure for configuring a DECram disk on an OpenVMS VAX system:

    $! Name:        DECRAM$TEMPLATE.COM
    $! Description:
    $!
    $! This template can be used as a starting point for configuring a
    $! DECram disk.  This template must be edited to fit your needs.
    $!
    $!
    $! Using SYSGEN, initialize and mount the DECram disk.
    $!
    $  run SYS$SYSTEM:SYSGEN connect MDA0/noadapter/drivername=mddriver
    $  initialize -
          /size=1000-
          /nohighwater-
          /noverified-
          /system-
          /protection=(s:rew,o:rew,g:rew,w:re)-
           MDA0: RAMdisk
    $  mount -
          /system-
          /noassist-
          /nocache-
          /nomount_verification -
           MDA0: RAMdisk RAMdisk
    $!
    $! In order to use the DECram copy of a file you will first need to
    $! find the file in its logical name search list.  This is an example
    $! for a system image where the RAMdisk MDA0: is added to the
    $! SYS$SYSROOT logical name.
    $!
    $  define/system/executive/nolog RAMdisk mda0: -
             /translation=(concealed,terminal)
    $  root = f$trnlnm("sys$specific","lnm$system")
    $  define/system/executive/nolog sys$sysroot -
          'root'/translation=(concealed,terminal),RAMdisk,SYS$COMMON
    $!
    $! Create a target directory on the RAMdisk.
    $!
    $  create/directory/protection=(s:rew,o:rew,g:rew,w:re) -
          RAMdisk:[sysexe]
    $!
    $! Here is the example file you will copy to the RAMdisk, retaining
    $! its original protection bits.
    $!
    $  filename = "SYS$SYSTEM:SET.EXE"
    $  prot = f$file(filename,"pro")
    $  file&dir = f$parse(filename,,,"directory") -
          + f$parse(filename,,,"name") + f$parse(filename,,,"type")
    $  copy/protection=('prot') 'filename' RAMdisk:'file&dir'
    $!
    $! If this file was an installed file, you need to re-install it.
    $!
    $  if f$file(filename,"known") then install replace 'filename'
    $  exit

# A.2 DECram Configuration Template for Alpha Systems (Alpha Only)

The following template is a sample procedure to configure a DECram disk on an OpenVMS Alpha system:

    $! Name:        DECRAM$TEMPLATE.COM
    $! Description:
    $!
    $! This template can be used as a starting point for configuring a
    $! DECram disk.  This template must be edited to fit your needs.
    $!
    $!
    $! Using SYSMAN, initialize and mount the DECram disk.
    $!
    $  run SYS$SYSTEM:SYSGEN io connect MDA0:/noadapter/drivername=sys$mddriver
    $  initialize -
          /size=1000-
          /nohighwater-
          /noverified-
          /system-
          /protection=(s:rew,o:rew,g:rew,w:re)-
           MDA0: RAMdisk
    $  mount -
          /system-
          /noassist-
          /nocache-
          /nomount_verification -
           MDA0: RAMdisk RAMdisk
    $!
    $! In order to use the DECram copy of a file you will first need to
    $! find the file in its logical name search list.  This is an example
    $! for a system image where the RAMdisk MDA0: is added to the
    $! SYS$SYSROOT logical name.
    $!
    $  define/system/executive/nolog RAMdisk mda0: -
             /translation=(concealed,terminal)
    $  root = f$trnlnm("sys$specific","lnm$system")
    $  define/system/executive/nolog sys$sysroot -
          'root'/translation=(concealed,terminal),RAMdisk,SYS$COMMON
    $!
    $! Create a target directory on the RAMdisk.
    $!
    $  create/directory/protection=(s:rew,o:rew,g:rew,w:re) -
          RAMdisk:[sysexe]
    $!
    $! Here is the example file you will copy to the RAMdisk, retaining
    $! its original protection bits.
    $!
    $  filename = "SYS$SYSTEM:SET.EXE"
    $  prot = f$file(filename,"pro")
    $  file&dir = f$parse(filename,,,"directory") -
          + f$parse(filename,,,"name") + f$parse(filename,,,"type")
    $  copy/protection=('prot') 'filename' RAMdisk:'file&dir'
    $!
    $! If this file was an installed file, you need to re-install it.
    $!
    $  if f$file(filename,"known") then install replace 'filename'
    $  exit

# A.3 Using the DECRAM$CONFIG Command Procedure

The DECRAM$CONFIG command procedure, which is provided in SYS$EXAMPLES, automatically creates and initializes a DECram disk. The following example shows the creation and initialization of a DECram disk of 100 blocks:

    $ @SYS$EXAMPLES:DECRAM$CONFIG

    DECram Configuration Procedure

     1.  CREATE a DECram Device.
     2.  INITIALIZE a DECram Device.
     3.  ALL of the ABOVE.
     4.  EXIT this Procedure.

If you select option 1, DECRAM$CONFIG creates the necessary I/O database structure for a DECram device.

If you select option 2, DECRAM$CONFIG allocates space for the DECram device and initializes it with the required file system structures.

If you select option 3, DECRAM$CONFIG performs both option 1 and option 2.

Select option 4 to exit from the procedure.

Enter a question mark (?) for help.

    Enter choice [3]: 3           ! Create and initialize the disk
    Enter DECram device name (ddcuu): mda8
    Enter desired Media Label: mdtst8
    Enter Size (in Blocks) for Device: 100
    DECram device MDA8 created and initialized/Label MDTST8

The responses in this example created and initialized the device MDA8. The volume label is MDTST8. Press the Return key to continue:

    DECram Configuration Procedure

     1.  CREATE a DECram Device.
     2.  INITIALIZE a DECram Device.
     3.  ALL of the ABOVE.
     4.  EXIT this Procedure.

    Enter choice [3]: 4           ! Exit from procedure
    $

Previous | Next | Contents | Index