October, 1999

Possession, use, or copying of the software described in this documentation is authorized only pursuant to a valid written license from COMPAQ, an authorized sublicenser, or the identified licenser.

While COMPAQ believes the information included in this publication is correct as of the date of publication, it is subject to change without notice.

Compaq Computer Corporation makes no representations that the interconnection of its products in the manner described in this document will not infringe existing or future patent rights, nor do the descriptions contained in this document imply the granting of licenses to make, use, or sell equipment or software in accordance with the description.

© Compaq Computer Corporation
1997, 1998, 1999. All Rights Reserved.

Printed in the United States of America.

COMPAQ, DIGITAL, DIGITAL UNIX, and the COMPAQ and DIGITAL logos Registered in U.S. Patent and Trademark Office.
DECconnect, HSZ, StorageWorks, VMS, and OpenVMS are trademarks of Compaq Computer Corporation.
AIX is registered trademark of International Business Machines Corporation.
FTP Software is a trademark of FTP SOFTWARE, INC.
HP is a registered trademark of Hewlett-Packard Company.
NT is a trademark of Microsoft Corporation.
Oracle, Oracle Rdb, and Oracle RMU are all registered trademarks of Oracle Corporation.
PostScript is a registered trademark of Adobe Systems, Inc.
RDF is a trademark of Touch Technologies, Inc.
SGI is a registered trademark of Chemical Bank.
Solaris is a registered trademark of Sun Microsystems, Inc.
StorageTek is a registered trademark of Storage Technology Corporation.
SunOS is a trademark of Sun Microsystems, Inc.
UNIX is a registered trademark in the United States and other countries, licensed exclusively through X/Open Company Ltd.
Windows and Windows NT are both trademarks of Microsoft Corporation.
All other trademarks and registered trademarks are the property of their respective holders.
This document was prepared using Adobe FrameMaker Version 5.5.

Preface v

Intended Audience v

Document Structure v

Related Documents vi

Related Products vi

Conventions vii

Determining and Reporting Problems vii

1.5.1 HSM Basic Mode Functions

HSM Basic mode provides the following functionality and features:

• · Complete HSM functionality for small to medium customer environments that can use smaller capacity tape loaders (for example, DLT loaders), standalone tape devices, and magneto-optical devices
• · A simple, integrated user interface provided completely by HSM
• · Limited media management that is not integrated with other storage management products
• · Support of up to 36 archive classes for data reliability
• · An HSM naming convention for tape volume labels
• · Local tape device support within the VMScluster? environment: the shelf server nodes must have visibility to all tape devices (this can include TMSCP-served devices)

1.5.2 HSM Plus Mode Functions

HSM Plus mode provides the following functionality and features:

• · Complete HSM functionality for medium to large customer environments that use large tape jukeboxes and for locations that already have the MDMS or SLS software installed
• · Support for large capacity nearline devices that support multiple terabytes of data, such as the TL820 and StorageTek? silos
• · Common media management with other OpenVMS storage management products through the MDMS software
• · Device and media management support provided through the MDMS command line and menu interfaces; this requires a more complex configuration process than for HSM Basic mode
• · Support of up to 9999 archive classes for data reliability
• · No fixed naming conventions for HSM tape volumes; the Storage Administrator controls volume names through MDMS
• · Tape device support within the cluster: the shelf server nodes do not require direct visibility to all tape devices within the cluster
• · Support for remote tape devices, those that are not directly connected within the cluster, through the Remote Device Facility? (RDF) portion of MDMS

1.5.3 HSM Mode Comparison Table

Table 1-1 identifies the functionality HSM for OpenVMS provides and which mode provides it.

All other functions, including HSM policies and cache, are provided in both modes.

1.5.4 Choosing HSM Modes

One of the pivotal decisions you must make before starting HSM is which mode you wish to run in - Plus or Basic.

Select Plus mode if:

• · You wish to have consolidated media management with other Storage Management products (e.g SLS, ABS...)
• · You are planning to use large multi-drive tape jukeboxes such as the TL81x, TL82x or StorageTek Silo
• · You are planning to use any kind of remote (RDF - accessed) tape drive
• · You wish to choose your tape volume labels, or use bar-coded volume labels

Select Basic mode if:

• · You do not want consolidated media management, or are using an alternative media manager
• · You are not using large multi-drive tape jukeboxes (for example, you can use single-drive TZ8xx loaders in either mode)
• · You are not planning to use tapes at all (for example, you might be using optical jukeboxes)
• · You should select the mode before continuing with any further HSM configuration.

1.5.5 HSM Mode Change Restrictions

You choose an HSM mode to operate when you install the HSM for OpenVMS software. However, you can change modes after you make the initial decision. The following restrictions apply to changing modes after installation:

• · You can always change from Basic mode to Plus mode.
• · You can change from Plus mode to Basic mode only if you have not written any shelved file information to a catalog in Plus mode. Once you write information to a catalog in Plus mode, you cannot change back to Basic mode.
• · For a change in operating mode to have effect, you must restart HSM.

1.6.1 HSM Base Licenses

A base HSM license is required to use HSM. This base license provides 20 GB of capacity. Additional capacity licenses are available as is an unlimited capacity license. The capacity is calculated according to the online storage space freed up when files are shelved. The total capacity is checked against the allowable capacity when a shelving operation occurs. If you exceed your capacity license, users will be able to unshelve data, but will not be able to shelve data until the license capacity is extended.

When you shelve a file, the amount of space freed up by the file's truncation is subtracted from the total capacity available. When you unshelve or delete the file, its allocated space is added to the capacity available. Periodically, HSM scans the volumes in the VMScluster? system and compares the amount of storage space for the shelved files to the remaining capacity. The SMU SHOW FACILITY command displays the license capacity remaining for the HSM facility (VMScluster? system).

Base licenses are available for all-VAX clusters, all-Alpha clusters, and mixed architecture clusters. These base licenses are shown in Table 1-2.

1.6.2 HSM Capacity Licenses

HSM uses an online capacity licensing strategy. Because HSM increases online capacity for active data at low cost, the license strategy attempts to capitalize on this lower cost per megabyte. HSM reduces the cost of system management by providing this functionality with a reduced amount of operator intervention.

You may increase your HSM storage capacity by purchasing additional capacity licenses. Compaq makes it easy for you by combining a base license in the same capacity license package so only one part number is needed. These licenses expand your shelving capacity by 140 GB, 280 GB, 500 GB, or 1000 GB increments of storage. Table 1-3 lists these licenses.

1.13.1 Mixed Architecture Environments

A mixed architecture OpenVMS Cluster includes at least one VAX system and at least one Alpha system.

Creating a Mixed Architecture Configuration:

If you add an Alpha system to a homogenous VAX OpenVMS Cluster, or if you are currently running a homogenous Alpha OpenVMS Cluster and inherit a VAX system, you will have a mixed architecture environment.

Before you integrate the Alpha or VAX node into the system, you should decide an approach to take for handling mixed architecture issues.

Operating a Mixed Architecture Configuration:

If you are currently operating a mixed architecture environment, and you want to add a VAX system or an Alpha system you must integrate it into your current configuration consistently with your other applications.

You should understand the particular requirements of any new application you introduce into a mixed architecture OpenVMS Cluster.

Dissolving a Mixed Architecture Configuration:

If you remove the last VAX or Alpha system, leaving a homogenous OpenVMS Cluster, you should remove any aspects of configuration that accounted for the heterogeneous nature of the mixed architecture system. This includes (but is not limited to) removing startup files, duplicate directory structures, and logical tables.

1.13.2 Principles Guiding Mixed Architecture Configuration

Hardware Limitations:

VAX systems cannot execute image files compiled on an Alpha system, and Alpha systems cannot execute image files compiled on a VAX system. Other types of files cannot be shared, including object code files (.OBJ), and user interface description files (.UID). You must place files that cannot be shared in different locations: VAX files accessible only to VAX OpenVMS Cluster nodes, and Alpha files accessible only to Alpha OpenVMS Cluster nodes.

What it Means

Data files, in most cases, must be shared between OpenVMS Cluster nodes. You should place all shared files in directories accessible by both VAX and Alpha OpenVMS Cluster nodes.

Logical names, that reference files which cannot be shared, or the directories in which they reside, must be defined differently on VAX and Alpha systems.

Files that assign logical name values must therefore be architecture specific. Such files may either reside on node-specific disks or shared only among OpenVMS Cluster nodes of the same hardware architecture.

1.13.3 Configuring Applications in a Mixed Architecture OpenVMS Cluster

This section describes three approaches to configuring applications to run in a mixed architecture OpenVMS Cluster. The one you choose depends on your existing configuration, and the needs of the particular application you are installing. These approaches are given as examples only. You should decide which you want to implement based on your own situation and style of system management.

All of these approaches have two aspects in common:

• · All shared files reside in one location
• · All files that cannot be shared reside in separate locations

1.13.4 Implementation Specific Approach

This document includes specific procedures for a recommended approach based on current product configuration and the behavior of the installation process with respect to its use of logical definitions during upgrades.
If the recommended approach is inconsistent with the way you currently manage your system, you should decide on a different approach before you begin your installation procedures.

2

Installing MDMS Software

This chapter explains how to install the Media and Device Management Services (MDMS)
Version 3.0 software. The sections in this chapter cover the 3 procedures involved in installing the software, namely:

• · pre-installation tasks
• · installation
• · post-installation tasks

If this is the initial installation of MDMS V3.0 you should install MDMS on a node that is going to be one of your MDMS server nodes.

This version of MDMS installs the system executable files into system specific directories. Because of this, there is no special consideration for mixed architecture OpenVMS cluster system installations. At a minimum, you will install MDMS twice in a mixed architecture OpenVMS Cluster system:

• · the first time for the Open VMS VAX nodes
• · a second time for the OpenVMS Alpha nodes.

2.1.1 Hardware and Software Requirements

MDMS V3.0's free disk space requirements differ during installation (peak utilization) and after installation (net utilization). As a pre-installation step please make sure that the required space is available during and post-installation respectively. Table See Disk Space Requirements shows the different space requirements.

The two installation variants are organized, and require disk space as follows:

The files for MDMS are placed in two locations:

• · system disk: for executables
• · MDMS$ROOT: for
• - Command procedures
• - Log files
• - Database files
• - GUI files for all three platforms

OpenVMS V6.2 is the minimum version of software necessary to run MDMS. OpenVMS V7.1 Alpha is the minimum version of software to run the GUI on.

2.1.2 Meet Patch Requirements

Table 1-2 describes the patch requirements for MDMS:

If the server patches are not installed, you will see the following error while trying to start the server:

09-Mar-1999 10:38:16 %MDMS-I-TEXT, "10k Day" patch not installed!

2.1.3 Install CMA Shareable Images

If you are installing MDMS on an OpenVMS V6.2 VAX system, you have to install the following three files:

• · SYS$COMMON:[SYSLIB]CMA$RTL
• · SYS$COMMON:[SYSLIB]CMA$OPEN_RTL
• · SYS$COMMON:[SYSLIB]CMA$LIB_SHR

If these images are not installed by default, include the following lines in the
SYS$STARTUP:SYSTARTUP_VMS.COM:

$!
$! Install CMA stuff for MDMS
$!
$ INSTALL = "$INSTALL/COMMAND_MODE"
$ IF .NOT. F$FILE_ATTRIBUTES("SYS$COMMON:[SYSLIB]CMA$RTL.EXE", "KNOWN")
$ THEN -
$ INSTALL ADD SYS$COMMON:[SYSLIB]CMA$RTL
$ ENDIF
$ IF .NOT. F$FILE_ATTRIBUTES("SYS$COMMON:[SYSLIB]CMA$OPEN_RTL.EXE", "KNOWN")
$ THEN
$ INSTALL ADD SYS$COMMON:[SYSLIB]CMA$OPEN_RTL
$ ENDIF
$ IF .NOT. F$FILE_ATTRIBUTES("SYS$COMMON:[SYSLIB]CMA$LIB_SHR.EXE", "KNOWN")
$ THEN
$ INSTALL ADD SYS$COMMON:[SYSLIB]CMA$LIB_SHR
$ ENDIF

2.1.4 Shutdown Previous Version of MDMS

If you have been running a version of MDMS prior to Version 3.0, you must shut it down using the following command:

$ @SLS$SYSTEM:SLS$SHUTDOWN

If you are using MDMS V3.0, use the following command to shutdown MDMS:

$ @SYS$STARTUP:MDMS$SHUTDOWN

2.1.5 Register the MDMS License

As MDMS V 3.0 does not have a separate license, you need one of the following licenses to run MDMS:

• · ABS-CLIENT-ALPHA
• · ABS-CLIENT-VAX
• · ABS-OMT
• · ABS-OMT-UPG
• · ABS-SERVER-ALPHA
• · ABS-SERVER-VAX
• · HSM-SERVER
• · SLS
• · SLS-MGR
• · SLS-REMOTE
• · SLS-REMOTE-MGR

If you do not have one of these licenses registered, please refer to the section on registering the license for ABS or HSM whichever you are installing.

2.1.6 Verify the Node is in the MDMS Database

If this installation is not the initial installation of MDMS V3.0, you need to verify that the node you are installing MDMS on is in the MDMS database. Enter the following command on a node that has MDMS already installed on it and verify that the node you are installing MDMS on is in the database:

$ MDMS SHOW NODE node_name_you_are_installing_on
%MDMS-E-NOSUCHOBJECT, specified object does not exist

If the node is not in the database, you receive the %MDMS-E-NOSUCHOBJECT error message and you should create the node. See the command reference guide for the qualifiers to use.

If the node you are adding is an MDMS server node, be sure to use the /DATABASE qualifier. If the node you are creating is to be a database server node, you need to edit all SYS$STARTUP:MDMS$SYSTARTUP.COM files in your domain and add this node to the definition of MDMS$DATABASE_SERVERS.

If the node is in the database, proceed with preinstallation tasks. The node may have been created when you converted from SLS/MDMS V2.x.

2.1.7 Consider RDF Configuration

MDMS provides RDF software to facilitate operations that require access to remote, network connected tape drives. This allows you to copy data from a local site to a remote site, or copy data from a remote site to a local site.

During the installation you will be asked questions on whether you want to install on this node, the software that will allow it to act as a server and/or client for the RDF software. You need to decide if you want the server and/or client installed on the node.

• · Install the RDF Server software on all nodes that are connected to the tape drives used for remote operations.
• · Install the RDF Client software on all nodes that initiate remote operations to tape drives on the RDF Server node.

1. load the distribution medium into a suitable device, and mount the volume

1. 2. invoke the VMSINSTAL procedure using the following command:

$ @SYS$UPDATE:VMSINSTAL MDMS030 location: OPTIONS N

Where:

location: is the device and directory that contains the software kit save set.

OPTIONS: N is an optional parameter that indicates you want to seen the question on Release Notes. If you do not include the OPTIONS:N parameter, VMSINSTAL does not ask you about the Release Notes. You should review the Release Notes before proceeding with the installation in case they contain additional information about the installation procedure.

Follow the instructions as you are prompted to complete the installation. Each question you are asked is provided with alternatives for the decision you can take and an explanation for the related decision.

Questions and decisions offered by the installation procedure vary. Subsequent installations will not prompt you for information you provided during the first installation.

2.3.1 Create a Node Object

If this is the initial installation of MDMS, you need to create the node object in the MDMS node database for this node. Use the MDMS CREATE NODE command to create this initial database node. Refer to the command reference guide for the qualifiers for this command. The following is an example:

$ MDMS CREATE NODE NABORS -
! NABORS is the DECnet Phase IV node name or a
! name you make up if you do not use DECnet
! Phase IV in your network
/DATABASE_SERVER -
! a potential database node
! must also be defined in
! in SYS$STARTUP:MDMS$SYSTARTUP.COM
/TCPIP_FULLNAME=NABORS.SITE.INC.COM -
! the TCP/IP full node name if you
! are using TCP/IP you need this if
! you are using the GUI
/DECNET_FULLNAME=INC:.SITE.NABORS -
! this is the full DECnet Phase V node name
! do not define if you do not have DECnet Phase V on this node
! be sure to define if you have DECnet Phase V installed on this node
/TRANSPORT=(DECNET,TCPIP)
! describes the transports that listeners are
! started up on

2.3.2 Provide Automatic Start Up and Shut Down

To automatically start MDMS when you initiate a system start up, at a location after the DECnet or TCP/IP start up command, add the following line in the system's start up file,
SYS$MANAGER:SYSTARTUP_VMS.COM:

$ @SYS$STARTUP:MDMS$STARTUP

To automatically stop MDMS when you initiate a system shut down, enter the following into the system's shut down file:

$ @SYS$STARTUP:MDMS$SHUTDOWN

While using MDMS V3.0 with ABS, make sure that MDMS startup is executed prior to ABS startup. ABS needs a logical name that is defined by the MDMS startup.

2.3.3 Remove SLS/MDMS V2.x Automatic Startup

If you have been using SLS/MDMS V2.x before and all your nodes running ABS and/or HSM version now support the new MDMS V3.0 make sure you remove this line from your system's start up file:

$ @SYS$STARTUP:SLS$STARTUP

If this node still needs to support clients that use SLS/MDMS V2.x refer to the Appendix SLS/MDMS V2.x Compatibility in the guide to operations. Until you have made all of the changes described in this appendix, you should not start up SLS/MDMS V2.x.

2.3.4 Configure MDMS

Now that you have installed MDMS you need to configure MDMS by creating the following objects:

• · Media types
• · Locations
• · Nodes
• · Groups
• · Jukeboxes
• · Tape Drives
• · Magazines
• · Pools
• · Volumes

Please refer to the MDMS section in the guide to operations for more information on configuration and operation.

If you upgrading from SLS/MDMS V2.x you can convert the SLS/MDMS V2.x symbols and database to the MDMS V3.0 database. Use the procedure described in the appendix of the guide to operations.

Once MDMS V3.0 is installed, and any conversions are performed, you may wish to adjust your configuration prior to performing MDMS operations

2.3.5 Configure Remote Tape Drives

If you installed the RDF software, you need to configure the remote tape drives.

For each tape drive served with RDF Server software, make sure there is a drive object record in the MDMS database that describes it. Refer to the chapters on MDMS configuration in the guide to operations and the MDMS CREATE DRIVE command in the command reference guide.

For each node connected to the tape drive, edit the file TTI_RDEV:CONFIG_node.DAT and make sure that all tape drives are represented in the file. The syntax for representing tape drives is given in the file.

During startup of MDMS, the RDF client and server are also started. The RDF images are linked on your system. If you see the following link errors on Alpha V6.2, this is not an RDF bug. The problem is caused by installed VMS patches ALPCOMPAT_062 and ALPCLUSIO01_062.

%LINK-I-DATMISMCH, creation date of 11-FEB-1997 15:16 in
shareable image SYS$COMMON:[SYSLIB]DISMNTSHR.EXE;3
differs from date of 4-MAY-1995 22:33 in shareable image library
SYS$COMMON:[SYSLIB]IMAGELIB.OLB;1
.
.
.

This is a known problem and is documented in TIMA. To correct the problem, issue the following DCL commands:

$ LIBRARY/REPLACE/SHARE SYS$LIBRARY:IMAGELIB.OLB SYS$SHARE:DISMNTSHR.EXE
$ LIBRARY/REPLACE/SHARE SYS$LIBRARY:IMAGELIB.OLB SYS$SHARE:INIT$SHR.EXE
$ LIBRARY/REPLACE/SHARE SYS$LIBRARY:IMAGELIB.OLB SYS$SHARE:MOUNTSHR.EXE

2.3.6 Grant MDMS Rights to Users

Before any user can use MDMS, you must grant MDMS rights to those users. Refer to the MDMS Rights and Privileges Appendix in the Archive/Backup System for OpenVMS Command Reference Guide for explanation of MDMS rights and how to assign them.

2.3.7 Installing the DCL tables on Nodes

To make MDMS commands available on all nodes of the cluster, you should ensure that all nodes have the latest version of DCLTABLES.EXE installed. You can do this by using
SYSMAN or by logging into each node in the cluster and enter the following command:

$ INSTALL REPLACE SYS$COMMON:[SYSLIB]DCLTABLES.EXE

2.4.1 Requirements

The GUI requires the following in order to run:

Virtual Machine

Since the MDMS GUI is a Java application, it requires the platform specific Java Virtual Machine. The availability of each Java Virtual Machine is described in the following sections. The best way of getting a Java Virtual Machine is to down load the platform-specific kit from the given URLs. If this is not possible, the MDMS package also contains a copy for your convenience. Issues concerning availability and installation of the Java Virtual Machine can be directed to:

http://www.sun.com/java/products for Windows NT and
http://www.digital.com/java/download/jdk_ovms/1.1.8/index.html for OpenVMS

A Java Virtual Machine is included in this MDMS kit for the purpose of completeness. MDMS provides both the pointers (URLs) of downloading a Java Virtual Machine and the actual files of the Java Virtual Machine in the release package. However, the downloading approach is encouraged.
Memory - The hard drive space requirement is 6 MB for Java Virtual Machine and 2 MB for MDMS GUI. The main memory space requirement for running MDMS GUI is 10 MB.

2.4.2 Installation on OpenVMS Alpha V7.1 and V7.2

The following steps describe how to install and run the MDMS GUI on OpenVMS Alpha:

Table 2-3 Patches Required for OpenVMS V7.1 for JAVA

Patch Required	For OpenVMS Version	Fix Description
ALPBASE02_071	V7.1 to V7.1-H2	Fixes needed to enable ALPACRT06_071 and ALPSYSA01_071. Must be installed first.
ALPACRT06_071	V7.1 to V7.1-H2	DECC fixes-fork, exec
ALPDCL01_071	V7.1 to V7.1-H2	Fixes for multiple kernel threading problem
ALPSYSA01_071	V7.1 to V7.1-H2	Higher-priority thread blocking
ALPSYSB02_071	V7.1 to V7.1-H2	IEEE arithmetic
ALPTHREADS_03071	V7.1 to V7.1-H2	DECthreads; support for Java, selected fixes
VMS712_PTHREADS	V7.1-2 ONLY	DECthreads; support for Java, selected fixes

These patches are not required for installation on OpenVMS Alpha V7.2.

1. 2. Extract the files for the OpenVMS Java Virtual Machine.

You may use the Java kit provided with the MDMS kit or download files from the Web. If you want to install from the MDMS kit, answer YES to the following question:

Do you want the OpenVMS Java kit extracted [NO]?

If you install from the MDMS kit, a file called:

MDMS$ROOT:[GUI.VMS]DEC-AXPVMS-JAVA-V0101-81-1.PCSI_DCX_AXPEXE

is created. Use this file to install Java as in step 4.

1. 3. In the MDMS installation, the following question is asked.

Do you want the MDMS GUI installed on Alpha OpenVMS [YES]?

Reply `Yes' to the question if you want to install the GUI on OpenVMS. Files will be moved to MDMS$ROOT:[GUI.VMS] and the GUI installation will be completed.

1. 4. Following the MDMS installation, you should install Java by first extracting the PCSI file for the Java installation using the following commands:

$ SET DEFAULT MDMS$ROOT:[GUI.VMS]

$ RUN DEC-AXPVMS-JAVA-V0101-81-1.PCSI_DCX_AXPEXE

Extract and read the Release Notes for additional information on how to use this product in an OpenVMS environment:

$ PRODUCT EXTRACT RELEASE_NOTES JAVA-
/SOURCE=[directory_where_you_put_the_PCSI_file]-
/FILE=[directory_where_you_want_it]JDK118_VMS_RELEASE_NOTES.HTML-
/BASE_SYSTEM=AXPVMS

Install the JDK1.1.8 from the .PCSI file obtained:

$ PRODUCT INSTALL JAVA-
/SOURCE=[directory_where_you_put_the_PCSI_file]/BASE_SYSTEM=AXPVMS

The following files are installed by PCSI (POLYCENTER Software Installation utility) with file attribute of ARCHIVE:

SYS$MANAGER:JAVA$SETUP.COM
SYS$MANAGER:JAVA$STARTUP.COM
SYS$SYSROOT:[JAVA.LIB]FONT.PROPERTIES
SYS$SYSROOT:[JAVA.LIB]FONT_PROPERTIES.JA

If a file having any of these names already exists on the system, the installation process renames it to a new name with the file type ending `_OLD', before loading the new copy from the kit. Only the latest version of the existing file is preserved (by being renamed to file.type_old) before PCSI deletes all remaining versions.

For example, an existing SYS$MANAGER:JAVA$SETUP.COM
is renamed to SYS$MANAGER:JAVA$SETUP.COM_OLD before the new copy is copied from the kit. If you have previously personalized any of these files, you might need to merge your personalizations with the new copy.

The JDK documentation is installed on your system at the following location:

SYS$COMMON:[SYSHLP.JAVA]INDEX.HTML

1. 5. After installation you must do the following:

$ EDIT SYS$STARTUP:JAVA$SETUP.COM

and include the following logical name definition at the end of the file:

$ DEFINE JAVA$CLASSPATH -
MDMS$ROOT:[GUI.VMS]MDMS.ZIP,-
MDMS$ROOT:[GUI.VMS]SYMANTEC.ZIP, -
MDMS$ROOT:[GUI.VMS]SWINGALL.JAR, -

SYS$COMMON:[JAVA.LIB]JDK118_CLASSES.ZIP

1. 6. Run JAVA$SETUP.COM to establish defaults for the logical names CLASSPATH and JAVA$FILENAME_CONTROLS, and to define symbols that determine whether Java will interpret commands as either foreign commands or DCL commands:

$ @SYS$MANAGER:JAVA$SETUP.COM

Add the above command line to SYS$COMMON:[SYSMGR]SYLOGIN.COM so that when users login, they will have the Java definitions.

Make sure that the logical JAVA$USE_DCL is not defined or the GUI will not work.

1. 7. The JAVA$SETUP.COM procedure calls:

SYS$SYSROOT:[SYSHLP.JAVA]JAVA$FILENAME_CONTROLS.COM

to establish the JAVA$FILENAME_CONTROLS default values. You can edit this file to see what defaults are being used and how to change them. (This information is also in the "UNIX Style Filenames on an OpenVMS System" section of the JDK release notes.)

1. 8. Rename the file SYS$COMMON:[JAVA.LIB]FONT.PROPERTIES to another name. This file remaps the fonts and makes the MDMS GUI appear incorrect. Renaming the file to another name will cause Java to use the default fonts, which are necessary to run the MDMS GUI.
2. 9. If you are running the GUI using a non-PC keyboard, for example an OpenVMS keyboard, issue the following command on the system running the GUI:

$mcr decw$utils:xmodmap -e "keysym Delete = BackSpace Delete"

2.4.3 Installation on Intel Windows NT/95/98

The following describes how to install the MDMS GUI on Intel platforms running Windows NT/95/98:

2.4.4 Installation on Alpha Windows NT

The following describes how to install the MDMS GUI on an Alpha platform running Windows NT:

2.5.1 Running the GUI on OpenVMS Alpha

To use the MDMS GUI on OpenVMS Alpha systems, use the following commands:

$ @SYS$STARTUP:JAVA$SETUP.COM
$ SET DISPLAY/CREATE/NODE=node_name/TRANSPORT=transport
$ MDMS/INTERFACE=GUI

For the SET DISPLAY command, the node_name is the name of the node on which the monitor screen exists. This allows you to use the GUI on systems other than those running OpenVMS Alpha V7.1 or higher. The transport must be a keyword of:

• · LOCAL - if you are running the GUI on the same node as the monitor
• · DECNET - if you are running the GUI on a monitor connected to another node and you wish to use DECnet protocol between the monitor node and the GUI Java node.
• · TCPIP - if you are running the GUI on a monitor connected to another node and you wish to use TCPIP protocol between the monitor node and the GUI Java node.

2.5.2 Running the GUI on Intel Windows NT/95/98

To use the MDMS GUI on Intel Windows NT/95/98 platforms, double click MDMS_GUI\MDMS_GUI.BAT.

2.5.3 Running the GUI on Alpha Windows NT

To use the MDMS GUI on Alpha Windows NT, do one the following:

3.3.1 Required for HSM Basic Mode

When HSM is used in Basic Mode, the only software required, in addition to HSM, is the OpenVMS Operating System Versions 6.1 through 7.1. Media and Device Management Services (MDMS) is required only if you wish to convert from HSM Basic Mode to HSM Plus Mode.

3.3.2 Required for HSM Plus Mode

HSM Plus mode requires the use of Media and Device Management Services for OpenVMS (MDMS) Version 2.5B or newer software for managing media and devices. MDMS software comes packaged with HSM and can be obtained from one of the following sources:

• · Off the HSM distribution kit
• · Included with Storage Management Library System for OpenVMS (SLS).
• · Included as a separate source with Archive/Backup System for OpenVMS (ABS)
  or Sequential Media File system for OpenVMS (SMF) software

3.3.3 Required for HSM Repack Function

The HSM SMU REPACK Command allows you to do an analysis of valid and obsolete data on shelf media and copy the valid data to other media, thus freeing up storage space. This Repack functionality is found in HSM Plus Mode.
The HSM Repack function requires the use of two tape drives since this is a direct tape to tape transfer process. One tape must match the media type of the source archive class and the other tape must match the media type of the destination archive class.

4

Installing HSM Software

This chapter contains instructions for installing HSM Version 3.0 software on the OpenVMS operating system.

4.1.1 The Installation Procedure

The HSM installation procedure consists of a series of questions and informational messages. Table 5-1 shows the installation procedure. For a complete example of an HSM installation and verification procedure for HSM Basic mode, see Appendix A; for HSM Plus mode, see Appendix B.

To abort the installation procedure at any time, enter Ctrl/Y. When you enter Ctrl/Y, the installation procedure deletes all files it has created up to that point and exits. You can then start the installation again.

Note that VMSINSTAL deletes or changes entries in the process symbol tables during the installation. Therefore, if you are going to continue using the system manager's account and you want to restore these symbols, you should log out and log in again.

4.1.2 Error Recovery

If errors occur during the installation procedure, VMSINSTAL displays failure messages. If the installation fails, you see the following message:

%VMSINSTAL-E-INSFAIL, The installation of HSM has failed

If the IVP fails, you see this message:

The HSM Installation Verification Procedure failed.

%VMSINSTAL-E-IVPFAIL, The IVP for HSM has failed.

Errors can occur during the installation if any of the following conditions exist:

• · The operating system version is incorrect.
• · Quotas necessary for successful installation are insufficient.
• · System parameter values for successful installation are insufficient.
• · The OpenVMS help library is currently in use.
• · The product license has not been registered and loaded.

For descriptions of the error messages generated by these conditions, see the OpenVMS documentation on system messages, recovery procedures, and OpenVMS software installation. If you are notified that any of these conditions exist, you should take the appropriate action as described in the message.

5

Getting Started with HSM

HSM comes with a set of default configuration definitions that enable you to get HSM up and running quickly. This chapter explains how to use those definitions and perform other essential configuration tasks to start using HSM. Once HSM is up and running, you can modify the configuration for optimal performance in your operational environment. Read the Customizing the HSM Environment Chapter in the HSM Guide to Operations Manual for more information on tuning.

This chapter includes the following topics:

• · A description of the default configuration installed with HSM
• · A discussion of how to make minimal adjustments to the default configuration
  for HSM to function in your operational environment
• · A description of how to set up the near-line and off-line environments for both
  Basic and Plus modes
• · Example off-line configurations for both Basic and Plus modes

5.1.1 The Default Facility

• · The facility is initially set up with the following attributes:
• · All HSM operations are enabled
• · All event logging is enabled
• · All nodes are authorized as shelf servers
• · Use of a catalog server is disabled
• · Default mode depends on whether MDMS/SLS is installed on your system

These operations and event logging defaults represent the behavior that is recommended and expected to be used most of the time that HSM is in operation.

You should customize your shelf servers to be restricted to the larger systems in your cluster and to those that have access to the desired near-line and off-line devices.

5.1.2 The Default Shelf

HSM provides a default shelf that supports all online disk volumes. The default shelf enables HSM operations.

Note that no archive classes are set up for the default shelf at initialization. To enable HSM operations to near-line and off-line devices, you need to configure the default shelf to one or more archive classes.

5.1.3 The Default Device

HSM provides a default device record, which applies when you create a device without specifying attributes for the device. The default attributes are:

• · The device is shared with other applications.
• · Shelving and unshelving operations are enabled.
• · No archive classes are associated with the device.

For the device to be used by HSM, you must at minimum associate one or more archive classes with the device. You may also choose to dedicate any device for exclusive HSM use.

5.1.4 The Default Volume

HSM provides a default volume record, which applies to all online disk volumes in the system unless a specific volume entity exists for them. The default volume contains the following attributes:

• · Explicit HSM operations (preshelving, shelving, unshelving, file faults, unpreshelving) are enabled.
• · Implicit HSM operations (policy-based operations) are disabled.
• · Contiguous files are ineligible for shelving
• · Placed files are eligible for shelving
• · The high water mark is 90 percent.

If these attributes are acceptable, no further configuration of volume records is needed.

You may change the volume attributes in one of two ways:

• · Update the default volume record, which will affect all online disk volumes associated with the default volume.
• · Create an individual volume entity for each online disk volume you want to change. This is recommended if you turn on policy-based HSM operations.

Compaq recommends you examine disk usage before enabling implicit shelving operations on your cluster. For example, enabling a high water mark criterion on the default volume could cause immediate mass shelving on all volumes if the disk usage is already above the high water mark.

Compaq also recommends that you create an individual volume record for each system disk and disable all HSM operations on those volumes.

5.1.5 The Default Policies

HSM provides three default policies as follows:

• · HSM$DEFAULT_POLICY-This is used as a template for all policy definitions, including the other two default policies.
• · HSM$DEFAULT_OCCUPANCY-This policy is used as the default reactive policy definition in the system for device full and high water mark triggers.
• · HSM$DEFAULT_QUOTA-This policy is used as the default reactive policy definition in the system for exceeded quota triggers.

At installation time, all three default policies contain the same attributes:

• · The policy is enabled for shelving (rather than preshelving).
• · The comparison date used for file selection is the expiration date, which when used in conjunction with OpenVMS volume retention time, provides an effective date of last read or write access.
• · The elapsed time is set to 180 days; This means that files that have been accessed within 180 days will not be selected for shelving.
• · The low water mark goal for the policy is 80 percent.
• · The primary policy file selection algorithm is space time working set (STWS).
• · The secondary policy file selection algorithm is least recently used (LRU).

These default policy definitions allow HSM to function effectively with the minimum of advance configuration and can be used without any modifications or additional information.

By default, all volumes use the appropriate default policies without any further configuration being required.

5.2.1 Verifying the Facility Definition

As mentioned earlier, HSM provides a default facility definition. Before you start using HSM, however, you want to verify that the default facility definition is correct for your environment.

The following example shows how to view information about the facility:

$ SMU SHOW FACILITY

HSM is enabled for Shelving and Unshelving

Facility history: Created: 22-APR-1996 12:10:37.13
Revised: 22-APR-1996 12:10:37.13
Designated servers: NODE1 NODE2
Current server: NODE1
Catalog server: Disabled
Event logging: Audit Error Exception
HSM mode: Plus
Remaining license: 20 gigabytes

The information displayed indicates:

• · Whether the facility is enabled for shelving, unshelving, or both
• · Which nodes on the cluster are designated as shelf servers
• · The current shelf server node
• - An indication of whether all catalog writes and caching operations are performed by the shelf server node
• - What log options are turned on
• - The HSM operational mode (Basic or Plus)
• - The remaining license space (in gigabytes) for the HSM facility

If any of these attributes are not correct for your facility, you need to modify them before continuing to configure HSM.

5.2.2 Defining Archive Classes for Use

To define an archive class for HSM to use, use one of the following commands depending on the mode in use. For HSM Basic Mode use:

$ SMU SET ARCHIVE n ! for Basic Mode

For HSM Plus Mode use:

$ SMU SET ARCHIVE n - _$ /MEDIA_TYPE=string - _$ /DENSITY=string - _$ /ADD_POOL=string

Where n is a list of archive class numbers from 1 to 36 (Basic mode), or 1 to 9999 (Plus mode).

In Plus mode, the DENSITY and ADD_POOL qualifiers are optional. The MEDIA_TYPE and DENSITY must exactly match the definitions in TAPESTART.COM (see Section 6.4).

5.2.3 Selecting Archive Classes for the Default Shelf

During installation, HSM creates a default shelf named HSM$DEFAULT_SHELF. To allow shelving operations, the shelf must be associated with one or more archive classes. When data is copied to the shelf, it is copied to each of the archive classes specified. Having several archive classes provides you additional safety for your shelved files. Each archive class is written to its own set of media. Compaq recommends having at least two archive classes.

Archive classes are represented in HSM by both an archive name and an archive identifier. The properties of archive classes depends on the selected HSM operational mode:

Basic Mode - Basic mode supports up to 36 archive classes named HSM$ARCHIVE01 to HSM$ARCHIVE36, with associated archive identifiers of 1 to 36 respectively. The media type for the archive class is determined by the devices associated with the archive class. It is not specifically defined.

Plus Mode - Plus mode supports up to 9999 archive classes named HSM$ARCHIVE01 to HSM$ARCHIVE9999, with associated archive identifiers of 1 to 9999 respectively. You specify the media type and (optionally) density which must exactly agree with the corresponding fields associated with off-line devices in the MDMS/SLS file TAPESTART.COM. Specifying a volume pool allows you to reserve specific volumes for HSM use.

Restore archive classes are the classes to be used when files are unshelved. HSM attempts to unshelve files from the restore archive classes in the specified order until the operation succeeds. To establish your restore archive classes, you use the /RESTORE qualifier.

The following command associates archive classes 1 and 2 with the default shelf. It also specifies that UNSHELVE operations use the restore archive classes 1 and 2. Each archive class has an associated media type.

$ SMU SET SHELF/DEFAULT/ARCHIVE_ID=(1,2)/RESTORE_ARCHIVE=(1,2)

5.2.4 Defining Devices for the Archive Classes

Now you need to specify which near-line/off-line devices you want to use for copying shelved file data to the archive classes. You must specify a minimum of one device to support near-line or off-line shelving.

Dedicating Devices

In some circumstances, it is beneficial to dedicate a device for HSM operations. You may want to dedicate a device if you expect a lot of HSM operations on that device and you do not want those operations to be interrupted by another process.

For each device definition you create, you have the option of dedicating the device or sharing the device. A dedicated device is allocated to the HSM process. A shared device is allocated to HSM only in response to a request to read or write to the media. Once the operation completes, the device is available to other applications.

The SMU SET DEVICE/DEDICATE command is used to dedicate a device, the SMU SET DEVICE/SHARE command is used to share a device. The following options are for dedicating or sharing a device:

Archive Class, Device, and Media Type

For HSM Basic mode, when you associate an archive class with a particular device, you implicitly define the media type for that archive class. HSM, in Basic mode, determines media type for a given device based on the device type.

Robot Name

In Basic mode, you must associate a Robot Name with a tape magazine loader if you wish it to be robotically controlled.

5.2.5 Initializing Tape Volumes for Each Archive Class

After setting up the devices, you must initialize each tape volume for the archive classes to be used.

For Plus mode, the tape volumes are defined by using STORAGE ADD VOLUME commands to MDMS/SLS. For jukebox loaders such as the TL81x and TL82x, it is important that the volumes names match the external volume label and bar code on the volume. You can use the OpenVMS INITIALIZE command to initialize volumes, or use the SLS Operator Menu (option 3) to do this.

HSM Basic mode uses a different approach. There are fixed labels for use in each archive class as shown in Table 6-1:

In the table, the values for xxx are as follows:

001, 002, ..., 099, 101, 102, ..., 199, 201, 202, ..., 999, A01, A02, ..., A99, B01, B02, ..., Z99

This naming convention must be adhered to for Basic Mode, allowing up to 3564 volumes per archive class. An archive class always starts with the "001" value and progresses up in order, as shown.

Use the OpenVMS INITIALIZE command to initialize the physical tape volumes for each archive class that you use.

The following examples show how to initialize two tape volumes each for archive class 1 and 2.

Archive Class ID
_ $ INITIALIZE $1$MUA100: HS0001 ! tape 1 for archive class ID 1
$ INITIALIZE $1$MUA200: HS0002 ! tape 2 for archive class ID 1
$ INITIALIZE $1$MUA100: HS1001 ! tape 1 for archive class ID 2
$ INITIALIZE $1$MUA200: HS1002 ! tape 2 for archive class ID 2 Tape volume

5.2.6 Set Volume Retention Times for Policy-Based Shelving

Each template policy uses the expiration date as the basis for selecting files for shelving. This default is intended to be used with the OpenVMS volume retention feature to provide an effective date of last access. The date of last access is the optimal way to select truly dormant files for shelving by policy.

To use the default policy effectively, you must enable volume retention on each volume used for shelving. If you do not specifically enable volume retention on a volume, expiration dates for files on the volume usually will be zero. In this case, the default policy will not select any files for shelving.

Verifying Privileges

To set volume retention, you must be allowed to enable the SYSPRV system privilege or have write access to the disk volume index file.

Setting Volume Retention

To set volume retention dates, use the following procedure. For more information about the OpenVMS command SET VOLUME/RETENTION, see the OpenVMS DCL Dictionary.

1. Enable the system privilege for your process:

$ SET PROCESS/PRIVILEGE=SYSPRV

2. Enable retention times for each disk volume on your system:

$ SET VOLUME/RETENTION=(min,[max])

For min and max, specify the minimum and maximum periods of time you want the files retained on the disk using delta time values. If you enter only one value, the system uses that value for the minimum retention period and calculates the maximum retention period as either twice the minimum or as the minimum plus seven days, whichever is less.

If you are not already using expiration dates, the following settings for retention times are suggested:

$ SET VOLUME/RETENTION=(1-, 0-00:00:00.01)

Initializing File Expiration Dates

Once you set volume retention on a volume and define a policy using expiration date as a file selection criteria, the expiration dates on files on the volume must be initialized. HSM automatically initializes expiration dates the first time a policy runs on the volume. This initializes dates for all files on the volume that do not already have an expiration date. The expiration date is set to the current date and time, plus the maximum retention time as specified in the SET VOLUME/RETENTION command.

After the expiration date has been initialized, the OpenVMS file system automatically updates the expiration date upon read or write access to the file, at a frequency based on the minimum and maximum retention times.

5.3.1 Authorizing Shelf Servers

If your cluster contains a mixture of large nodes and smaller satellite workstations, you may want to restrict shelf server operation to the larger nodes for better performance.

Use the SET FACILITY command to initially authorize your shelf server. See the SMU SET FACILITY command in the HSM Guide to Operations for detailed information on this command. In the following example, two nodes (NODE1 and NODE2) are authorized as shelf servers. By default, all shelving operations and all event logging are enabled also.

$ SMU SET FACILITY/SERVER=(NODE1,NODE2)

If you omit the /SERVER qualifier, all nodes in the cluster are authorized as shelf servers.

5.3.2 Working with a Cache

A cache provides many performance benefits for HSM operations, for example, a significant improvement in the response time during shelving operations.

If you would like to use a magneto-optical device as a shelf device instead of, or in addition to near-line /off-line devices, define the magneto-optical device as a cache.

5.3.3 An Example of Managing Online Disk Cache

A system manager has decided that approximately 250,000 blocks of online disk cache will improve application availability by reducing shelving time.

There are three user disks that contain various amounts of available storage capacity: $1$DUA13, $1$DUA14, and $1$DUA15. The three disk volumes are defined as cache devices with differing amounts of capacity:

$1$DUA13 is set to 100,000 blocks
$1$DUA14 is set to 50,000 blocks
$1$DUA15 is set to 100,000 blocks

5.3.4 Running Default Policies

HSM includes a set of default policy definitions to provide a working system upon installation. These definitions are created during the installation procedure and are immediately implemented. The definitions also are used when creating additional definitions.

Although schedules are maintained in a database, there is no supplied schedule for the default preventive policy HSM$DEFAULT_POLICY. If you want to implement a preventive policy, you must use the SMU SET SCHEDULE command as shown in the HSM Guide to Operations.

Table 6-2 lists the supplied default policy definitions that are configured for operation upon installing HSM.

5.3.5 Template Policy Definitions

The default definitions for the disk volume, shelf, and preventive policy are also template definitions. When you create new disk volume, shelf, and policy definitions, any parameters not given a value use the parameter value in the template definition.

Examples

Either of the following commands set the HSM$DEFAULT_POLICY secondary policy to STWS:

SMU> SMU SET POLICY /SECONDARY_POLICY=STWS/DEFAULT

SMU> SMU SET POLICY HSM$DEFAULT_POLICY /SECONDARY_POLICY=STWS

5.4.1 How HSM Plus Mode and MDMS Work Together

By using Media and Device Management Services for OpenVMS (MDMS) software, HSM Plus mode uses common media and device management capabilities. MDMS provides these common services for various storage management products, such as Archive Backup System (ABS) and Storage Library System for OpenVMS (SLS), as well as HSM.

5.4.2 How MDMS Supports HSM

MDMS provides the following services:

• · An integrated and shared approach to controlling access to devices
• · A shared database to media and device information
• · Common commands that allow you to manage media across storage management products

What this means for HSM is:

If you already use MDMS to support some other storage management product, you will need to do little to add functionality for HSM.

If you do not use MDMS for other storage management products now, you can start using it for HSM and add other products later without having to shift your media and device management approach.

HSM can now support more devices, including TL820s as fully robotic devices.

HSM can support gravity-controlled loading in a Digital Linear Tape (DLT) magazine loader in addition to robotically-controlled loading in a DLT.

5.4.3 MDMS Commands for HSM Plus Mode Use

For HSM to work with MDMS, there are various MDMS commands you may need to use. Table 6-3 lists the MDMS commands you may need to use for HSM Plus mode and describes what each one does. Later sections of this chapter describe how to use some of these commands. For detailed information on working with MDMS, see the Media and Device Management Services for OpenVMS Guide to Operations.

5.4.4 MDMS Configuration Tasks Required to Support HSM Plus Mode

To enable HSM to work with MDMS, you must perform the following tasks:

5.5.1 Sample TA90 Configuration

The following procedure defines a media type for a basic device (TA90), adds 50 volumes of that media type to a particular pool, authorizes HSM only to access that pool, and defines the appropriate archive classes and HSM devices for these volumes.

5.5.2 Sample TZ877 Configuration

The following procedure defines a media type and two jukeboxes for TZ877 DLT loaders, defines 14 volumes with two volume pools, authorizes HSM to access those volume pools, and defines the appropriate archive classes and HSM devices for these volumes.

5.5.3 Sample TL820 Configuration

The following procedure defines a media type and jukebox definition for a TL820 device on the local cluster, defines 50 volumes and adds them to a pool, authorizes HSM and other applications to access the volumes in this pool, and defines appropriate archive classes and devices for use. In this example, the TL820 is connected to an HSJ controller with a robot name (command disk name) of $1$DUA820:.

5.5.4 Sample RDF-served TL820 Configuration

The following procedure defines a configuration for an RDF-served TL820 device that resides on a remote node. This example also shows the client and server definitions for setting up both nodes so that a client HSM system can access the TL820.

5.6.1 TZ877 Sample Configuration

The following procedure defines archive classes 1 and 2 for HSM use. We will assign one TZ877 loader to each archive class. In this example, the magazine loaders are connected directly to a SCSI bus on node OMEGA: as such, they can only be accessed from this node.

$!
$ SMU SET ARCHIVE 1,2
$ SMU SET SHELF /DEFAULT /ARCHIVE=(1,2) /RESTORE_ARCHIVE=(1,2)
$ SMU SET DEVICE $
1$MKA100: /ARCHIVE=1 /ROBOT_NAME=$1$GKA101:
$ SMU SET DEVICE $1$MKA200: /ARCHIVE=2 /ROBOT_NAME=$1$GKA201:
$ SMU SET FACILITY /SERVER=OMEGA
$!
$! Confirm Setup
$!
$ SMU SHOW ARCHIVE

HSM$ARCHIVE01 has not been used
Identifier: 1 Media type: CompacTape III, Loader Label: HS0001 Position: 0 Device refs: 1 Shelf refs: 2

HSM$ARCHIVE02 has not been used Identifier: 1 Media type: CompacTape III, Loader Label: HS1001 Position: 0 Device refs: 1 Shelf refs: 2

$ SMU SHOW SHELF

Shelf HSM$DEFAULT_SHELF is enabled for Shelving and Unshelving
Catalog File: SYS$SYSDEVICE:[HSM$SERVER.CATALOG]HSM$CATALOG.SYS
Shelf History:
Created: 30-MAY-1996 13:16:33.79
Revised: 30-MAY-1996 13:56:00.27
Backup Verification: Off
Save Time: <none>
Updates Saved: All
Archive Classes:
Archive list:
HSM$ARCHIVE01 id: 1 HSM$ARCHIVE02 id: 2 Restore list: HSM$ARCHIVE01 id: 1 HSM$ARCHIVE02 id: 2

$ SMU SHOW DEVICE

HSM drive HSM$DEFAULT_DEVICE is enabled.
Shared access: < shelve, unshelve >
Drive status: Not configured
Media type: Unknown Type
Robot name: <none>
Enabled archives: <none>

HSM drive _$1$MKA100: is enabled.
Dedicated access: < shelve, unshelve >
Drive status: Configured
Media type: CompacTape III, Loader
Robot name: _$1$GKA101:
Enabled archives: HSM$ARCHIVE01 id: 1

HSM drive _$1$MKA200: is enabled.
Dedicated access: < shelve, unshelve >
Drive status: Configured
Media type: CompacTape III, Loader
Robot name: _$1$GKA201:
Enabled archives: HSM$ARCHIVE02 id: 2

In addition, the tape volumes in each TZ877 loader must be initialized before using HSM. Either manually (using the front panel), or by using the Media Robot Utility (MRU), load each volume and initialize it as follows:

$ ROBOT LOAD SLOT 0 ROBOT $1$GKA101
$ INITIALIZE $1$MKA100: HS0001
$ ROBOT LOAD SLOT 1 ROBOT
$1$GKA101
$ INITIALIZE 1$MKA100: HS0002
...
$ ROBOT LOAD SLOT 6 ROBOT $1$GKA101
$ INITIALIZE $1$MKA100: HS0007
$ ROBOT LOAD SLOT 0 ROBOT $1$GKA201
$ INITIALIZE $1$MKA200: HS1001
$ ROBOT LOAD SLOT 1 ROBOT $1$GKA201
$ INITIALIZE $1$MKA200: HS1002
...
$ ROBOT LOAD SLOT 6 ROBOT $1$GKA201
$ INITIALIZE $1$MKA200: HS1007

5.6.2 RW500 Example

In this example, we are configuring 8 out of 32 platters in an RW500 optical jukebox to be a permanent shelf repository for HSM. Note that the optical platters are set up as a permanent HSM cache, with no cache flushing and no specific block size restrictions. In addition, HSM shelving and unshelving operations must be specifically disabled on the cache devices and all other platters in the optical jukebox.

$ SMU SET CACHE $2$JBA0: /BLOCK=0 /NOINTERVAL /HIGHWATER=100 /NOHOLD
$ SMU SET CACHE $2$JBA1: /BLOCK=0 /NOINTERVAL /HIGHWATER=100 /NOHOLD ...
$ SMU SET CACHE $2$JBA7: /BLOCK=0 /NOINTERVAL /HIGHWATER=100 /NOHOLD
$!
$! Disable all shelving on ALL platters in the jukebox
$! $ SMU SET VOLUME $2$JBA0: /DISABLE=ALL
$ SMU SET VOLUME $2$JBA1: /DISABLE=ALL
...
$ SMU SET VOLUME $2$JBA31: /DISABLE=ALL

Note that shelving must be disabled on all platters when any of the platters are being used as an HSM cache to avoid platter load thrashing.

6.1.1 DFS Access

File faulting (and therefore file events) work as expected, with the exception of CTRL-Y/exit. Typing CTRL-Y exit during a file fault has no effect. The client side process waits until the file fault completes and the file fault is not canceled.

In addition, with DFS one can determine the shelving state of a file just as if the disk was local (i.e. DIRECTORY/SHELVED and DIRECTORY/SELECT both work correctly).

The shelve and unshelve commands do not work on files on DFS-served devices. The commands do work on the VMScluster? that has local access to the devices, however.

6.1.2 NFS Access

The normal default faulting mechanism (fault on data access), does not work for NFS-served files. The behavior is as if the file is a zero-block sequential file. Performing "cat" (or similar commands) results in no output.

However, at installation time, HSM Version 3.0 enables such access by defining a logical name that allows file faults on an OPEN of a file by the NFS process. By default, the following system and cluster wide logical name is defined:

$ DEFINE/SYSTEM HSM$FAULT_ON_OPEN "NFS$SERVER"

This definition supports access to NFS-served files upon an OPEN of a file. If you do not want NFS access to shelved files, simply de-assign the logical name as follows:

$ DEASSIGN/SYSTEM HSM$FAULT_ON_OPEN

For a permanent change, this command should be placed in:

SYS$STARTUP:HSM$LOGICALS.COM

For NFS-served files, file events (device full and user quota exceeded) occur normally with the triggering process being the NFS$SERVER process. The quota exceeded event occurs normally because the any files extended by the client are charged to the client's proxy not NFS$SERVER.

If the new logical is defined for the NFS$SERVER, the fault will occur on OPEN and appears transparent to the client, with the possible exception of messages as follows:

% cat /usr/oreo/shelve_test.txt.2
NFS2 server oreo not responding still trying NFS2 server oreo ok

The first message appears when the open doesn't complete immediately. The second message (ok) occurs when the open completes. The file contents, in the above example, are then displayed.

Typing CTRL-C during the file fault returns the user to the shell. Since the NFS server does not issue an IO$_CANCEL against the faulting I/O, the file fault is not canceled and the file will be unshelved eventually.

It is not possible from the NFS client to determine whether a given file is shelved. Further, like DFS devices, the shelve and unshelve commands are not available to NFS mounted devices.

6.1.3 PATHWORKS

Normal attempts to access a shelved file from a PATHWORKS client initiate a file fault on the server node. If the file is unshelved quickly enough (e.g. from cache), the user sees only the delay in accessing the file. If the unshelve is not quick enough, an application-defined timeout occurs and a message window pops up indicating the served disk is not responding. The timeout value varies on the application. No retry is attempted. However, this behavior can be modified by changing HSM's behavior to a file open by returning a file access conflict error, upon which most PC applications retry (or allow the user to retry) the operation after a delay. After a few retries, the file fault will succeed and the file can be accessed normally. To enable PATHWORKS access to shelved files using the retry mechanism, HSM defines the following logical name on installation:

$ DEFINE/SYSTEM HSM$FAULT_AFTER_OPEN "PCFS_SERVER, PWRK$LMSRV"

This definition supports access to PATHWORKS files upon an OPEN of a file. If you do not want PATHWORKS to access shelved files via retries, simply de-assign the logical name as follows:

$ DEASSIGN/SYSTEM HSM$FAULT_AFTER_OPEN

For a permanent change, this command should be placed in:

SYS$STARTUP:HSM$LOGICALS.COM

The decision on which access method to use depends upon the typical response time to access shelved files in your environment.

If the logical name is defined, HSM imposes a 3-second delay in responding to the OPEN request for PATHWORKS accesses only. During this time, the file may be unshelved: otherwise, a "background" unshelve is initiated which will result in a successful open after a delay and retries.

At this point, the file fault on the server node is under way and cannot be canceled.

The affect of the access on the PC environment varies according to the PC operating system. For windows 3.1 and DOS, the computer waits until the file is unshelved. For Windows NT and Windows-95, only the windows application itself waits.

File events (device full and user quota exceeded) occur normally with the triggering process being the PATHWORKS server process. The quota exceeded event occurs normally because the any files extended by the client are charged to the client's proxy not the PATHWORKS server.

It is not possible from a PATHWORKS client to determine whether a file is shelved. In addition, there is no way to shelve or unshelve files explicitly (via shelve- or unshelve-like commands). There is also no way to cancel a file fault once it has been initiated.

Most PC applications are designed to handle "file sharing" conflicts. Thus, when HSM detects the PATHWORKS server has made an access request, it can initiate unshelving action, but return "file busy". The typical PC application will continue to retry the original open, or prompt the user to retry or cancel. Once the file is unshelved, the next OPEN succeeds without shelving interaction.

6.1.4 New Logical Names for NFS and PATHWORKS Access

As just discussed, HSM supports two logical names that alter the behavior of opening a shelved file for NFS and PATHWORKS access support. These are:

• · HSM$FAULT_ON_OPEN - This logical name forces a file fault on an Open of a file for the processes listed in the equivalence name, and the open waits until the file fault is complete. Designed for use with the NFS server.
• · HSM$FAULT_AFTER_OPEN - This logical name forces a deferred file fault on the file when it is opened. If the fault completes within three seconds, the open completes successfully, otherwise it fails with "file busy", but initiates a "background" file fault. Repeated attempts to open the file will eventually succeed. Designed for use with the PATHWORKS server.

The default behavior is to perform no file fault on Open; rather the file fault occurs upon a read or write to the file.

Each logical name can take a list of process names to alter the behavior of file faults on open. For example:

$ DEFINE/SYSTEM HSM$FAULT_ON_OPEN "NFS$SERVER, USER_SERVER, SMITH"

The HSM$FAULT_ON_OPEN can also be assigned to "HSM$ALL", which will cause a file fault on open for all processes. This option is not allowed for HSM$FAULT_AFTER_OPEN.

As these logicals are defined to allow NFS and PATHWORKS access, they are not recommended for use with other processes, since they will cause many more file faults than are actually needed in a normal OpenVMS environment. When used, the logicals must be system-wide, and should be defined identically on all nodes in the VMScluster? environment.

These logical name assignments or lack thereof take effect immediately without the need to restart HSM.

A

HSM Basic Mode Installation Example

This appendix contains a sample HSM Basic mode installation on a VAX system. Upon completion of the actual installation, this example runs the IVP to determine whether the installation was correct.

HSM must be shut down using $ SMU SHUTDOWN on the installation system and all VMScluster? nodes that use the installation system's system disk before you install the new version of the HSM software, otherwise the installation fails.

$ @SYS$UPDATE:VMSINSTAL HSM022 DISK$:[DIR]
OpenVMS VAX Software Product Installation Procedure V6.1
It is 10-JAN-1997 at 14:12.
Enter a question mark (?) at any time for help.
* Are you satisfied with the backup of your system disk [YES]?
The following products will be processed:

HSM V3.0

Beginning installation of HSM V3.0 at 14:13

%VMSINSTAL - I - RESTORE, Restoring product save set A ...
%VMSINSTAL - I - RELMOVED, Product's release notes have been moved to SYS$HELP.

****************************************************************
* Hierarchical Storage Management (HSM) *
* for OpenVMS V3.0 Installation *
* *
* Copyright(c) Compaq computer Corporation 1994 - 1997. *
* All Rights Reserved. Unpublished rights reserved under the *
* copyright laws of the United States. *
****************************************************************

*Do you want to purge files replaced by this installation [YES]?
*Do you want to run the IVP after the installation [YES]?

*** HSM License ***

Correct installation and operation of this software requires that one of the following Product Authorization Keys (PAKs) reflecting your software license be present on this system:

HSM-SERVER
HSM-USER

* Does this product have an authorization key registered and loaded [YES]?

*** HSM Mode ***

With this version, HSM can operate in one of two possible modes:

BASIC - The standalone HSM product which supports a limited number of near
line and offline devices.

PLUS - The integrated HSM product, integrated with Media and Device Manage
ment Services (MDMS) which supports an expanded number of nearline
and offline devices.

NOTE: MDMS or SLS V2.5B or newer must be installed before installing HSM PLUS mode. Also, once files are shelved in PLUS mode, you may *not* change back to BASIC mode.

BASIC or PLUS to select the mode in which you want HSM to operate. the mode to install [PLUS]: BASIC Installing HSM V3.0 BASIC mode

*** HSM Account ***
A privileged account named HSM$SERVER will be created for use by HSM processes. This account will not allow interactive logins and the password will be automatically generated.

The installation procedure will not proceed until you enter a valid user identification code (UIC) for the HSM$SERVER account. The UIC must be unique and within the SYSTEM group.

Enter the UIC to be used for HSM$SERVER account [[1,22]]:

*** HSM Device ***
You will now be asked to enter a disk device specification to be used as a repository for HSM configuration databases and log files.

NOTE: *** This device must have at least 100000 free blocks and be available to all nodes in the cluster that will be running HSM ***

Enter the disk device to use for HSM files [SYS$SYSDEVICE:]:

HSM files will be placed at SYS$SYSDEVICE:[HSM$SERVER]
*Is this correct [YES]?
This installation creates an ACCOUNT named HSM$SERVER.
user record successfully added
identifier HSM$SERVER value [000001,000022]
added to rights database
This installation updates an ACCOUNT named HSM$SERVER.
user record(s) updated
This installation updates an ACCOUNT named HSM$SERVER.
user record(s) updated
This installation updates an ACCOUNT named HSM$SERVER.
user record(s) updated
This product creates system disk directory SYS$SYSDEVICE:[HSM$SERVER].
This product creates system disk directory SYS$SYSDEVICE:[HSM$SERVER.LOG]. This product creates system disk directory SYS$SYSDEVICE:[HSM$SERVER.
CATALOG].
This product creates system disk directory SYS$SYSDEVICE:[HSM$SERVER.MANAGER].
Checking for DISKQUOTAs on device SYS$SYSDEVICE:
Restoring product save set B ...

The file SYS$STARTUP:HSM$STARTUP.COM contains specific commands needed to start the HSM Software. This file should not be modified. To start the software at system startup time, add the line

$ @SYS$STARTUP:HSM$STARTUP.COM

to the system startup procedure SYS$MANAGER:SYSTARTUP_VMS.COM

The HSM Catalog and SMU Databases must be created before running HSM. This procedure can create the HSM Catalog and SMU Databases automatically for you as a post-installation task.
you want to run the database creation procedure [YES]?
The file SYS$SYSTEM:SETFILENOSHELV.COM should be executed to set all system disk files as NON-SHELVABLE. This is important to preserve the integrity of your system disk.

This procedure can submit SETFILENOSHELV.COM to a batch execution queue for you as a post-installation task.

you want to submit SETFILENOSHELV.COM [YES]?

*****************************************************************
* IMPORTANT *
*****************************************************************
* When you upgrade to a new version of VMS you should invoke *
* SYS$SYSTEM:SETFILENOSHELV.COM again. The installation of VMS *
* does not and will not automatically set your system disk *
* files to NON-SHELVABLE for you. *
*****************************************************************
No further questions will be asked during this installation.
The installation should take less than 10 minutes to complete.
This software is proprietary to and embodies the confidential technology of Compaq Computer Corporation. Possession, use, or copying of this software and media is authorized only pursuant to a valid written license from Compaq or an authorized sublicensor.
Restricted Rights: Use, duplication, or disclosure by the U.S. Government is subject to restrictions as set forth in subparagraph (c)(1)(ii) of DFARS 252.227-7013, or in FAR 52.227-19, or in FAR 52.227-14 Alt. III, as applicable.
Files will now be moved to their target directories...
executing HSM Post-Installation procedure
Creating HSM catalog
This command file creates the default HSM Catalog file.
The Catalog file is a directory of every file that was ever shelved.
It should be protected as such by controlling access to it.
You should only have to create the Catalog file once because that catalog will be used from that point on and contains a history of shelving activity and more importantly locates the offline data for the shelved files.
You should make sure that the Catalog file gets backed up on a regular basis since loss of this file could mean loss of the data for your shelved files.

HSM catalog created successfully
Creating HSM SMU database files
HSM SMU database files created successfully
setting HSM mode to BASIC SETFILENOSHELV (queue HSM$POLICY_NODE, entry 2) holding until 10-JAN-1997 14:24
HSM post-installation procedure complete
HSM for OpenVMS V3.0 Installation Verification Procedure (IVP)
*** Copyright(c) Compaq Corporation 1994 - 1997.
starting HSM shelving facility on node NODE shelf handler process started 000000AE policy execution process started 000000AF
Shelf Handler version - V2.x (BLxx), Oct 20 1997 Shelving Driver version - V2.x (BLxx), Oct 20 1997 Policy Execution version - V2.x (BLxx), Oct 20 1997 Shelf Management version - V2.x (BLxx), Oct 20 1997
for OpenVMS is enabled for Shelving and Unshelving
history: Created: 10-JAN-1997 14:19:28.26
Revised: 10-JAN-1997 14:19:41.83
servers: Any cluster member
server: NODE
server: Disabled
logging: Audit
Error Exception mode: Basic
license :Unlimited
cache device _NODE$DKB300: created
shelf HSM$DEFAULT_SHELF updated
volume_NODE$DKB300: created
file SYS$COMMON:[SYSTEST.HSM]HSM_IVP1.TMP;1
shelved file SYS$COMMON:[SYSTEST.HSM]HSM_IVP1.TMP;1
unshelved file SYS$COMMON:[SYSTEST.HSM]HSM_IVP2.TMP;1 shelved
unshelving file NODE$DKB300:[SYSCOMMON.SYSTEST.HSM]HSM_IVP2.TMP;1
policy HSM$IVP_POLICY created
scheduled policy HSM$IVP_POLICY for volume _NODE$DKB300: was created on server NODE _NODE$DKB300: (queue HSM$POLICY_NODE, entry 3) started on HSM$POLICY_NODE waiting for HSM$IVP_POLICY to execute...
waiting for HSM$IVP_POLICY to execute...
file SYS$COMMON:[SYSTEST.HSM]HSM_IVP3.TMP;1
unshelved shutting down HSM shelving facility on node NODE
waiting for HSM to shutdown... waiting for HSM to shutdown...

The IVP for HSM V3.0 was successful! ***

Storage Management (HSM) for OpenVMS, Version V3.0
Compaq Computer Corporation 1994 - 1997. All Rights Reserved.
shelf handler process started 000000B2
policy execution process started 000000B3
for OpenVMS is enabled for Shelving and Unshelving
history:
Created: 10-JAN-1997 14:19:04.15
Revised: 10-JAN-1997 14:22:03.89
servers: Any cluster member
server: NODE
server: Disabled
logging: Audit
Error Exception mode: Basic
license: Unlimited
Software has been successfully started
Installation of HSM V3.0 completed at 14:22
VMSINSTAL procedure done at 14:22

B

HSM Plus Mode Installation Example

This appendix contains a sample HSM Plus mode installation on a VAX system. In this instance, HSM Version 3.0 is installed over an existing HSM environment. Upon completion of the actual installation, this example runs the IVP to determine whether the installation was correct.

HSM must be shut down using $ SMU SHUTDOWN on the installation system and all VMScluster? nodes that use the installation system's system disk before you install the new version of the HSM software, otherwise, the installation fails.

$ @SYS$UPDATE:VMSINSTAL HSM022 DISK$:[DIR]
OpenVMS VAX Software Product Installation Procedure V6.1
It is 10-JAN-1997 at 14:40.
Enter a question mark (?) at any time for help.
* Are you satisfied with the backup of your system disk [YES]?
The following products will be processed:
HSM V3.0
Beginning installation of HSM V3.0 at 14:40
%VMSINSTAL-I-RESTORE, Restoring product save set A ...
%VMSINSTAL-I-RELMOVED, Product's release notes have been moved to SYS$HELP.
Restoring product save set A ...
Product'srelease notes have been moved to SYS$HELP.
****************************************************************
* Hierarchical Storage Management (HSM) *
* for OpenVMS V3.0 Installation *
* *
* Copyright(c) Compaq Computer Corporation 1998,1999. *
* All Rights Reserved. Unpublished rights reserved under the *
* copyright laws of the United States. *
****************************************************************
* Do you want to purge files replaced by this installation [YES]?
* Do you want to run the IVP after the installation [YES]?
*** HSM License ***
Correct installation and operation of this software requires that one
of the following Product Authorization Keys (PAKs) reflecting your
software license be present on this system:
HSM-SERVER
HSM-USER
* Does this product have an authorization key registered and loaded [YES]?
*** HSM Mode ***
With this version, HSM can operate in one of two possible modes:
BASIC - The standalone HSM product which supports a limited number of nearline and offline devices.

PLUS - The integrated HSM product, integrated with Media and Device Management Services (MDMS) which supports an expanded number of nearline and offline devices.
NOTE: MDMS or SLS V2.5B or newer must be installed before installing HSM PLUS mode. Also, once files are shelvedin PLUS mode, you may *not* change back to BASIC mode.

 

Enter BASIC or PLUS to select the mode in which you want HSM to operate.
* Enter the mode to install [PLUS]:
%HSM-I-MODE, Installing HSM V3.0 PLUS mode
%VMSINSTAL-I-ACCOUNT, This installation updates an ACCOUNT named HSM$SERVER. %UAF-I-MDFYMSG, user record(s) updated
%VMSINSTAL-I-ACCOUNT, This installation updates an ACCOUNT named HSM$SERVER.
%UAF-I-MDFYMSG, user record(s) updated
%VMSINSTAL-I-ACCOUNT, This installation updates an ACCOUNT named HSM$SERVER. %UAF-I-MDFYMSG, user record(s) updated
%HSM-I-CHKQUO, Checking for DISKQUOTAs on device SYS$SYSDEVICE:
%VMSINSTAL-I-RESTORE, Restoring product save set B ...
%HSM-I-CHKMRU, Checking version of Media Robot Utility (MRD$SHR.EXE)
%HSM-I-CHKHSD, Checking for updated version of HSDRIVER
The file SYS$STARTUP:HSM$STARTUP.COM contains specific commands needed to start the HSM Software. This file should not be modified. To start the software at system startup time, add the line
$ @SYS$STARTUP:HSM$STARTUP.COM to the system startup procedure SYS$MANAGER:SYSTARTUP_VMS.COM

The file SYS$SYSTEM:SETFILENOSHELV.COM should be executed to set all system disk files as NON-SHELVABLE. This is important to preserve the integrity of your system disk. This procedure can submit SETFILENOSHELV.COM to a batch execution queue for you as a post-installation task.
* Do you want to submit SETFILENOSHELV.COM [YES]? NO
*****************************************************************
* IMPORTANT *
*****************************************************************
* When you upgrade to a new version of VMS you should invoke *
* SYS$SYSTEM:SETFILENOSHELV.COM again. The installation of VMS *
* does not and will not automatically set your system disk *
* files to NON-SHELVABLE for you. *
*****************************************************************
%HSM-I-DONEASK, No further questions will be asked during this installation. -HSM-I-DONEASK, The installation should take less than 10 minutes to complete.
This software is proprietary to and embodies the confidential technology of Compaq Computer Corporation. Possession, use, or copying of this software and media is authorized only pursuant to a valid written license from Compaq or an authorized sublicensor. Restricted Rights: Use, duplication, or disclosure by the U.S. Government is subject to restrictions as set forth in subparagraph (c)(1)(ii) of DFARS 252.227-7013, or in FAR 52.227-19, or in FAR 52.227-14 Alt. III as applicable.
%VMSINSTAL-I-MOVEFILES, Files will now be moved to their target directories...

%HSMPOST-I-START, executing HSM Post-Installation procedure
%HSMPOST-I-SMUDBCONVERT, converting SMU databases
%SMUDBCONVERT-I-ARCHIVE, converting SMU archive database
%SMUDBCONVERT-I-CURRENT, SMU archive database conversion not required %SMUDBCONVERT-I-CACHE, converting SMU cache database
%SMUDBCONVERT-I-CURRENT, SMU cache database conversion not required
%SMUDBCONVERT-I-CONFIG, converting SMU shelf database
%SMUDBCONVERT-S-CONFIG, SMU shelf database converted
%SMUDBCONVERT-I-DEVICE, converting SMU device database
%SMUDBCONVERT-S-DEVICE, SMU device database converted
%SMUDBCONVERT-I-POLICY, converting SMU policy database
%SMUDBCONVERT-S-POLICY, SMU policy database converted
%SMUDBCONVERT-I-VOLUME, converting SMU volume database
%SMUDBCONVERT-S-VOLUME, SMU volume database converted
%HSMPOST-S-SMUDBCONVERT, SMU databases successfully converted
%HSMPOST-I-CATCONVERT, converting default catalog
%HSMPOST-I-CATCURRENT, catalog conversion not required
%HSMPOST-I-CATATTRUPD, updating catalog file attributes
%HSMPOST-S-CATATTRUPD, catalog file attributes updated
%HSMPOST-I-SETMODE, setting HSM mode to PLUS
%HSMPOST-I-DONE, HSM post-installation procedure complete
*** HSM for OpenVMS V3.0 Installation Verification Procedure (IVP) ***
Copyright(c)Compaq Computer Corporation 1998,1999
%HSM-I-IVPSTART, starting HSM shelving facility on node NODE
%SMU-S-SHP_STARTED, shelf handler process started 000000C3
%SMU-S-PEP_STARTED, policy execution process started 000000C4

HSM Shelf Handler version - V2.x (BLxx), Oct 20 1997
HSM Shelving Driver version - V2.x (BLxx), Oct 20 1997
HSM Policy Execution version - V2.x (BLxx), Oct 20 1997
HSM Shelf Management version - V2.x (BLxx), Oct 20 1997
HSM for OpenVMS is enabled for Shelving and Unshelving
Facility history:
Created: 10-JAN-1997 14:52:28.26
Revised: 10-JAN-1997 14:52:41.83
Designated servers: Any cluster member
Current server: NODE
Catalog server: Disabled
Event logging: Audit Error Exception
HSM mode: Basic
Remaining license: Unlimited
%SMU-I-CACHE_CREATED, cache device _NODE$DKB300: created
%SMU-I-SHELF_UPDATED, shelf HSM$DEFAULT_SHELF updated
%SMU-I-VOLUME_CREATED, volume _NODE$DKB300: created
%SHELVE-S-SHELVED, file SYS$COMMON:[SYSTEST.HSM]HSM_IVP1.TMP;1 shelved
%UNSHELVE-S-UNSHELVED, file SYS$COMMON:[SYSTEST.HSM]HSM_IVP1.TMP;1 unshelved
%SHELVE-S-SHELVED, file SYS$COMMON:[SYSTEST.HSM]HSM_IVP2.TMP;1 shelved
%HSM-I-UNSHLVPRG, unshelving file NODE$DKB300:[SYSCOMMON.SYSTEST.HSM]HSM_IVP2.TMP;1
%SMU-I-POLICY_CREATED, policy HSM$IVP_POLICY created
%SMU-I-SCHED_CREATED, scheduled policy HSM$IVP_POLICY for volume _NODE$DKB300: was created on server NODE Job _NODE$DKB300: (queue HSM$POLICY_NODE, entry 5) started on HSM$POLICY_NODE
%HSM-I-IVPWAIT, waiting for HSM$IVP_POLICY to execute...
%HSM-I-IVPWAIT, waiting for HSM$IVP_POLICY to execute...
%UNSHELVE-S-UNSHELVED, file SYS$COMMON:[SYSTEST.HSM]HSM_IVP3.TMP;1 unshelved
%HSM-I-IVPSHUT, shutting down HSM shelving facility on node NODE
%HSM-I-IVPSHUTWAIT, waiting for HSM to shutdown...
%HSM-I-IVPSHUTWAIT, waiting for HSM to shutdown...

*** The IVP for HSM V3.0 was successful! ***
Hierarchical Storage Management (HSM) for OpenVMS, Version V3.0
Copyright Compaq Computer Corporation 1998 - 1999. All Rights Reserved.
%SMU-S-SHP_STARTED, shelf handler process started 00000103
%SMU-S-PEP_STARTED, policy execution process started 00000104
HSM for OpenVMS is enabled for Shelving and Unshelving
Facility history:
Created: 10-JAN-1997 14:51:04.15
Revised: 10-JAN-1997 14:54:03.89
Designated servers: Any cluster member
Current server: NODE
Catalog server: Disabled
Event logging: Audit
Error Exception
HSM mode: Basic
Remaining license: Unlimited
HSM Software has been successfully started
Installation of HSM V3.0 completed at 14:55
VMSINSTAL procedure done at 14:55

 

 

 

D

E

MDMS Files and Logical Names

The HSM/MDMS installation procedure installs files and defines logical names on your system. This appendix lists the names of the files installed and logical names that are added to the system logical name -table. See MDMS File Names lists names of the files installed and See MDMS Logical Names lists the logical names that are added to the system logical names table.

They are automatically entered into these logical name tables whenever the system reboots or whenever the software is invoked. The LNM$JOB table also contains logical names that are defined when a user logs in to a system running MDMS software.

F

Table F-4 Operator Rights

1. F.2.2.1 Domain Commands for Mapping Privileges

SET DOMAIN
/[NO]ABS_RIGHTS
/ADD
/[NO]APPLICATION_RIGHTS[=(right[,...])]
/[NO]DEFAULT_RIGHTS[=(right[,...])]
/[NO]OPERATOR_RIGHTS[=(right[,...])]
/REMOVE
/[NO]SYSPRV
/[NO]USER_RIGHTS[=(right[,...])]

Example F-1

SET DOMAIN /OPERATOR_RIGHTS=MDMS_SET_PROTECTED /ADD

This command adds the MDMS_SET_PROTECTED right to the operator rights list.

A

Archive Class

default shelf 5-4

defining 5-4

Defining devices 5-4

identifier 5-4

initializing tape media 5-4

label reference table 5-4

Authorizing shelf servers 5-4

B

Basic Mode 1-3

see HSM Basic 1-3

C

Classes 5-5

correct installation problems 3-4

F

Files

HSM$STARTUP.COM 4-5

SYSTARTUP_VMS.COM. 4-5

G

GBLPAGES 3-3

GBLSECTIONS 3-3

H

How to

Register HSM License 3-5

register PAK 3-5

HSDRIVER

connecting 4-5

HSM

abort 4-6

Disk Space 3-1

Installing 4-1

Privileges 3-3

restart 4-6

start 4-5

HSM Basic

Functions 1-3

Overview 1-11

HSM Plus

Functions 1-3

HSM30.RELEASE_NOTES 3-1

HSM30_RELEASE_NOTES.PS. 3-1

I

Installation

account quotas 3-3

disk space 3-1

System Parameters 3-1

time taken 4-1

Installing

privileges 3-4

L

Licences

Capacity 1-5

License

How to register 3-5

Licenses

Base 1-5

Concurrent Use 1-5

types 1-7

P

PAK

Product Authorization Key 3-5

register 3-5

PATHWORKS 6-1

Logical Names 6-3

Plus Mode

See HSM Plus 1-3

R

Release Notes 3-1

S

shelf handler

starting 4-5

System Parameters 3-1

U

User account

quota 3-3, 3-4

V

VMSINSTAL 3-1