Installation Guide

Order Number: AA-QHD2N-TE

 

Software Version	Archive Backup System for OpenVMS Version 3.2A
Required Operating System	OpenVMS VAX Version 6.2, 7.1, 7.2 and 7.3 OpenVMS Alpha Version 6.2, 7.1-2, 7.2-1 and 7.3
Required Software	Media and Device Management Services for OpenVMS Version 3.2A
	DECnet (Phase IV) or DECnet-Plus(Phase V)
	TCP/IP Services for OpenVMS

August 2001

 

© 2001 Compaq Computer Corporation

 

Compaq, the Compaq logo, VAX, and VMS Registered in U.S. Patent and trademark Office.

 

OpenVMS and Tru64 are trademarks of Compaq Information Technologies Group, L.P. in the United States and other countries.

 

Motif, and UNIX are trademarks of The Open Group in the United States and other countries.

 

All other product names mentioned herein may be trademarks of their respective companies.

 

Confidential computer software. Valid license from Compaq required for possession, use or copying. Consistent with FAR 12.211 and 12.212, Commercial Computer Software, Computer Software Documentation, and Technical Data for Commercial Items are licensed to the U.S. government under vendor's standard commercial license.

 

Compaq shall not be liable for technical or editorial errors or omissions contained herein. The information in this document is provided "as is" without warranty of any kind and is subject to change without notice. The warranties for Compaq products are set forth in the express limited warranty statements accompanying such products. Nothing herein should be construed as constituting an additional warranty.

 

Compaq service tool software, including associated documentation, is the property of and contains confidential technology of Compaq Computer Corporation. Service customer is hereby licensed to use the software only for activities directly relating to the delivery of, and only during the term of, the applicable services delivered by Compaq or its authorized service provider. Customer may not modify or reverse engineer, remove, or transfer the software or make the software or any resultant diagnosis or system management data available to other parties without Compaq's or its authorized service provider's consent. Upon termination of the services, customer will, at Compaq's or its service provider's option, destroy or return the software and associated documentation in its possession.

 

Printed in the U.S.A.

Preface xi

Intended Audience

This document is intended for storage administrators who are experienced OpenVMS system managers. This document should be used in conjunction with the Introduction to OpenVMS System Management manual.

Conventions

The following conventions are used in this document:

Related Products

The following related products may be mentioned in this document:

Associate Documents

The following documents are part of Archive Backup System for OpenVMS documentation set:

• Archive Backup System for OpenVMS Installation Guide
• Archive Backup System for OpenVMS Guide to Operations
• Archive Backup System for OpenVMS Command Reference Guide

 

Welcome To ABS

If you are installing for the first time, it is essential that you review the information presented in this chapter. If you are a current ABS customer and are upgrading, you may skip to Chapter 2, Meeting Installation Requirements.

Not all the ABS features are available with ABS-OMT license. The following lists the features that are not available for the ABS-OMT license:

· Command line interface (CLI)
· Support for remote tape drives using RDF
· Support for OpenVMS clients
· Creation of storage policies
· Creation of environment policies
· Save request scheduling options except for the following:
- On demand (ON_DEMAND)
- Weekly full/daily incremental (DAILY_FULL_WEEKLY)
- One time only (ONE_TIME_ONLY)
· Support of STK silos and DCSC jukeboxes
· Support for the following scheduling options:
- POLYCENTER Scheduler V2.1b (DECscheduler) (DECSCHEDULER)
- External scheduler (EXT_SCHEDULER)
- External queue manager (EXT_QUEUE_MANAGER)

Welcome to Archive Backup System for OpenVMS (ABS). Because you have selected ABS to help you manage your data safety needs (archive and backup operations), you have a hardware and software environment (subsequently referred to as a storage environment) that contains a set of common elements. Your storage environment also contains very specific or unique elements. The information presented in this chapter is intended to give you an "overall picture" of a typical storage environment, and to explain how ABS compliments that environment.

What Do All Storage Environments Have In Common?

All storage environments that plan to implement ABS have the following common hardware and software:

• OpenVMS? VAX? or Alpha systems
• OpenVMS software Version 6.2, 7.1, 7.2, or 7.3 for VAX and OpenVMS software Version 6.2, 7.1-2, 7.2-1 or 7.3 for Alpha systems
• Disk devices for online storage/transactions
• DECnet? Phase IV or DECnet-Plus? for VAX or Alpha systems
• Tape drives
• Removable media that is compatible with the tape drives for storing saved data

See Typical Storage Environment shows a typical storage environment.

Typical Storage Environment

 

What Makes a Storage Environment Unique?

Storage environments have some or all of the following characteristics that make them unique:

• Mixed-architecture, OpenVMS Cluster (combination of OpenVMS VAX and Alpha systems). See See Mixed Architecture Environments for details.
• Heterogeneous client systems (OpenVMS, NT, Tru64 UNIX)
• Types of tape drives (TLZ06, TZ877, and so forth)
• Types of robotic devices (jukeboxes or gravity-fed loaders)
• Types of tape drive connections (direct-connect SCSI or controller-connected)
• Location of tape drives (remote or local)
• Number of disks
• Number of tape drives

See Unique Storage Environment shows how a storage environment can be unique.

Unique Storage Environment

 

Mixed Architecture Environments

Beginning with ABS V3.0A, the installation creates new architecture specific directories under the ABS$ROOT:[SYSTEM] directory, [.VAX] and [.ALPHA].

ABS binary files which are architecture specific (VAX or ALPHA) are now placed into ABS$ROOT:[SYSTEM.{VAX|ALPHA}]. This allows for sharing the same ABS$ROOT in a cluster from nodes running either VAX or ALPHA. To share a common ABS$ROOT across a mixed architecture cluster, select the same location of ABS$ROOT during the installation on each node.

What Is The Purpose of a Managed Media and Device
Environment?

The purpose of a managed media and device environment is to maintain a logical view of the physical elements of your storage environment to serve your nearline and offline data storage needs. A managed media and device environment defines the media and defines the drives that can use the media. It also defines the locations where media is stored, the locations of the drives that are compatible with the media, and the policy that governs the use of media.

The following list summarizes the characteristics of the managed media and device environment:

• Volumes are defined as media types in MDMS. Media type definitions are stored in the MDMS volume configuration database. All managed media are known in terms of type, location, capability, availability, and authorization (who can use that media). Before you can use media in your managed storage environment, you must add the media to the MDMS volume configuration database, and initialize the media for use. Once this is done, the media is known as a "volume". ABS recognizes these media type definitions, and depending upon which media type your storage policy uses, performs the backup operation using the appropriate media type and tape drives.
• Tape drive definitions also are stored in MDMS. Tape drives are used to serve the volumes known to MDMS. The MDMS software maintains a logical link between the volumes and the compatible tape drives, both in terms of physical and logical boundaries. Volumes and tape drives can be managed logically from locations miles away from where they are physically located. ABS depends upon MDMS to select the appropriate tape drives determined by the media type. ABS storage policies associate these logical connections.
• The MDMS software enables you to set the default criteria for moving and recycling volumes. This criteria includes rotation between onsite and offsite locations for safekeeping of the volumes, and the schedule that moves the volume through its lifecycle (retention, use, and reuse). ABS enables you to set the retention criteria for data saved on volumes, while MDMS enables you to define when to move or recycle volumes.

 

Meeting Installation Requirements

To ready your OpenVMS system for either ABS server or ABS client software installation procedure, you must perform certain tasks and requirements:

OpenVMS client support is not available with an ABS-OMT license.

• If you are installing ABS for the first time, See Preinstallation Tasks For a New ABS Installation describes the tasks you must perform before installing ABS.
• If you are upgrading your version of ABS, refer to See Preinstallation Tasks For an Upgrade ABS Installation.

Preinstallation Tasks For a New ABS Installation

 

Step	Action
	Decide on which system and disk to install ABS OpenVMS server software. You must make this decision before you can perform the remaining preinstallation tasks. Refer to See Deciding Where to Install ABS/MDMS Server Software for information about ABS server software. Use the worksheet provided in See Example Installation Worksheet to record your configuration.
	Decide on which systems and disks to install ABS OpenVMS client software. Refer to See Deciding Where To Install ABS Client Software for information about ABS OpenVMS client software. Use the worksheet provided in See Required Software to record your configuration.
	Log in to the SYSTEM account and enable all privileges. Most system managers install software from the system account. See See Required Privileges for the privileges required to install ABS.
	Perform a system backup operation. COMPAQ recommends that you perform a backup operation on the system disk before installing any software. For details about performing a backup operation on a system disk, see OpenVMS System Manager's Manual.
	Verify the OpenVMS operating system subclasses. Subclasses are provided in the OpenVMS save set that contains support for the OpenVMS operating system. See Required OpenVMS Operating System Subclasses lists the OpenVMS operating system subclasses required to install ABS.
	See See Hardware, Software, and System Requirements to verify the following requirements: Hardware and software requirements System parameters Account process quotas System processes
	Meet prerequisite patches requirements.
	Configure your hardware. Before you can use ABS software, you must first install and test your hardware configuration. It is recommended that you do this prior to installing ABS and MDMS software. These tasks are described in See Overview of Hardware Installation.   Note: The Media Robot Utility (MRU) software provides you with the ability to control the operation of an automated library system or a media loader system without having to access front panel controls on the system. MRU is especially useful for installing, configuring, and testing the operation of these types of system.   COMPAQ distributes MRU software with its newest libraries and loaders. If you have recently purchased MRU software and installed it, you will have the MRU software with its newest libraries and loaders. If you are using an earlier COMPAQ library or loader and would like to use MRU software, contact your COMPAQ sales representative.
	Register ABS licenses as described in See Registering ABS Licenses.

 

See Preinstallation Tasks For an Upgrade ABS Installation describes the preinstallation tasks to upgrade an existing ABS installation.

Preinstallation Tasks For an Upgrade ABS Installation

 

Step	Action
	If you have new tape drives that you want to add to your current storage environment, follow the instructions provided in See Overview of Hardware Installation. It is recommended that you do this prior to upgrading ABS or MDMS software.
	Log in to the SYSTEM account and enable all privileges. Most system managers install software from the system account. See See Required Privileges for the privileges required to install ABS.
	Perform a system backup operation. COMPAQ recommends that you perform a backup operation on the system disk before installing any software. For details about performing a backup operation on a system disk, see OpenVMS System Manager's Manual.
	Shutdown ABS and MDMS.   If you are upgrading ABS and it is currently running, shut down ABS by entering the following command on all nodes in the OpenVMS Cluster running ABS: $ @SYS$MANAGER:ABS$SHUTDOWN.COM Shutdown MDMS by entering the following command on all nodes in the OpenVMS Cluster running MDMS: $ @SYS$STARTUP:MDMS$SHUTDOWN.COM
	Verify the OpenVMS operating system subclasses. Subclasses are provided in the OpenVMS save set that contains support for the OpenVMS operating system.   See Required OpenVMS Operating System Subclasses lists the OpenVMS operating system subclasses required to install ABS.
	See See Hardware, Software, and System Requirements to verify the following requirements: Hardware and software requirements System parameters Account process quotas System processes
	See See Steps to Convert to a New Scheduling Option to follow steps for converting to another scheduling option.

Recommended Installation

In the event of a disaster situation it is essential to know where to install ABS and its dependent products so that you can recover the affected system as quickly as possible. To ease the recovery process in the event of a disaster situation, review this information to understand the most efficient way to install ABS, MDMS, and any dependent layered products.

Consider the following important guidelines:

• You should install ABS server software on a disk with adequate disk space for ABS.
  
  This disk could be the system disk, or another disk dedicated to ABS and its dependent layered products. The advantage of placing ABS and its dependent layered products on the system disk is that a less complicated restore process is enabled. However, the system disk then requires more space for ABS catalogs, MDMS database, and so forth.
• This disk should be dedicated to ABS and its dependent layered products, not shared with other interactive processes that could impede the performance of ABS.
• The system that contains this disk must have access to a tape drive compatible with the media that will contain ABS save sets for this disk.

See Recommended Installation illustrates the recommended installation.

Recommended Installation

 

Before you begin the installation procedure, use the worksheets provided in See Installation Worksheet to identify which OpenVMS system and disk will contain ABS server software.

Deciding Where to Install ABS/MDMS Server Software

ABS and MDMS are designed upon a client server technology. Before installing ABS/MDMS software, decide which OpenVMS node or which nodes in an OpenVMS Cluster will run an ABS/MDMS servers.

ABS server software is installed on an OpenVMS node or OpenVMS Cluster system and provides the policy database for itself and for any ABS client nodes connected to it. ABS server software makes the policy database available to all ABS clients. The MDMS software will be installed on the same OpenVMS node or OpenVMS Cluster system. The MDMS software provides media management services for itself and any MDMS client nodes connected to it. MDMS Software provides MDMS volume and magazine databases.

The volume database contains definitions of all removable media known to MDMS software, and the associated tape drive definitions, such as if the tape drive is local or remote to MDMS. It also contains information about volume locations and volume pool authorization. MDMS software updates all MDMS databases when any transactions are performed against the volumes.

Requirement:
You must install ABS/MDMS server software on at least one OpenVMS node or OpenVMS Cluster system.

Although the installation procedure does not have separate kits for the client and server software, ABS server is determined by the placement of ABS policy engine. During the installation procedure, you will be prompted to supply an OpenVMS node name (or node names in an OpenVMS Cluster) where you want the ABS server to reside. This node (or nodes in a cluster) becomes the ABS server nodes. You cannot specify a cluster alias name in the node name list. This node also becomes the MDMS server node.

If your system configuration changes at some point after running the installation procedure, you can change the server node name(s) by modifying the ABS$SYSTEM:ABS$POLICY_CONFIG.DAT file and by modifying the node and server information in the MDMS database.

Deciding Where To Install ABS Client Software

OpenVMS Clients

Install ABS/MDMS OpenVMS client software on any node that can communicate with ABS/MDMS server and for which you want to create ABS save requests. ABS OpenVMS client node can communicate with an ABS server node using the DECnet software. When an ABS client node needs to perform an ABS operation, ABS client node communicates with ABS server, retrieves policy information, updates ABS policy database, and then relinquishes its communications with ABS server when the operation has completed.

MDMS OpenVMS Client nodes can communicate with an MDMS server using DECnet or TCPIP.

OpenVMS client support is not available with an ABS-OMT license.

Tru64 UNIX Clients

UNIX refers to Tru64 UNIX. UNIX clients do not require a separate client installation. However, you must transfer the GNU tar files provided by ABS software to the UNIX client system, and then you must build the executable files on the UNIX client system. Also, you must authorize access for UNIX clients on ABS server node. Instructions for these tasks are described in Chapter 3.

Both NT and UNIX clients have their backup operations occur on ABS server node, and ABS server communicates with the NT or UNIX client system for data transfer and control.

Given you have the appropriate amount of licenses and adequate resources available, any number of ABS client nodes may be connected to a single ABS server node.

Typical Client-Server Configuration

 

Using the Installation Worksheets

To help you with the installation procedure the worksheet in See Installation Worksheet provides a work area to help you previously identify where you are installing ABS OpenVMS server, client software, and MDMS software.

See Example Installation Worksheet provides an example of how to use the worksheets provided in See Installation Worksheet.

Required Privileges

To install ABS, log on to the SYSTEM account or to an account that has SETPRV or, at a minimum, has the following privileges enabled:

• CMKRNL
• WORLD
• SYSPRV
• TMPMBX
• NETMBX

Note that VMSINSTAL turns off the BYPASS privilege at the start of the installation procedure.

Required OpenVMS Operating System Subclasses

OpenVMS operating system comes with a variety of support options, or subclasses. Subclasses include such features as networking and RMS journaling. To use ABS, your system should have the following subclasses resident:

• Programming support
• Utilities
• System programming environment
• Secure user's environment
• Network support

How to verify:
For information about verifying these components, refer to either OpenVMS VAX Installation Procedures or OpenVMS Alpha Installation Procedures.

Hardware, Software, and System Requirements

To make sure that your system is ready for the installation, verify that your system meets the following requirements:

• Hardware
• Software
• System parameters
• Process account quotas
• Processes

Required Hardware

To install software, you must meet the following minimum hardware requirements:

• A VAX? system, a MicroVAX? system, a VAXstation?, or an Alpha system.
• Please refer to the OpenVMS documentation for minimum requirements of RAM memory for running OpenVMS. We recommend that you have atleast 32 MB of memory on VAX system and 128 MB of memory on Alpha systems.
• One or more tape drives if you plan to back up your data to removable media. Refer to Section for instructions about configuring your hardware.
• One disk, such as a COMPAQ RD? or RZ? series disk.
• Adequate disk space. Refer to See Required Software to make sure there is adequate disk space to install ABS.

Verify that there are enough free blocks on the disk where you are installing the software.

If you are providing remote drive support, you must answer yes to the remote drive question during MDMS installation procedure. This requires additional free disk space.

Enter the following command to show the amount of used disk space on your disk:

$ SHOW DEVICE disk-name

Disk space required during an full installation on an Alpha system is 214,500 blocks with 167,400 required after the installation. Disk space required on a VAX is 204,000 blocks with 120,000 required after the installation.

Patch Requirements

See Prerequisite Patches describes the patch requirements for MDMS:

Prerequisite Patches

Component	Operating System	Version	Patch
MDMS$SERVER	OpenVMS Alpha	V6.2	ALPY2K_062
	OpenVMS VAX	V6.2	VAXLIBR06_070
GUI	OpenVMS Alpha	V7.1 to V7.1-H2	ALPBASE02_071
		V7.1 to V7.1-H2	ALPACRT06_071
		V7.1 to V7.1-H2	ALPDCL01_071
		V7.1 to V7.1-H2	ALPSYSA01_071
		V7.1 to V7.1-H2	ALPSYSB02_071
		V7.1 to V7.1-H2	ALPTHREADS_03071
		V7.1-2 ONLY	VMS712_PTHREADS

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!

You can obtain these patches or the latest revision by contacting your Compaq representative. If the patches for the MDMS$SERVER are not installed, the server will not start but you can successfully install MDMS, then install the patches and start the server.

Optional Software

See Optional Software describes the optional software you can use with ABS software

The following ABS features are not available with the ABS-OMT license:

· Support for OpenVMS clients
· Command line interface (CLI), you must use the GUI
· Support of STK silos and DCSC jukeboxes

Optional Software

 

Software	Purpose	System
ABS NT Client Software	Provides the ability to save data from Windows NT systems to ABS OpenVMS server system using ABS software (provided with ABS, not purchased separately).	NT Client
C Compiler	Provides the ability to build the executable files on UNIX clients	UNIX Client
DCSC1(Digital Cartridge Server Component)	If you have a StorageTek Automated Cartridge Server (ACS), you must install the DCSC software.	The system where the StorageTek silo resides.
TCP/IP Services for OpenVMSa	Provides network support for NT and UNIX clients.	ABS OpenVMS Server
eXcursiona	Provides the ability to display the graphical user interface (GUI) on NT client systems.	NT client system
Media Robot Utility (MRU)	Provides library and loader testing, diagnostics, and control.	The OpenVMS system where the robotic device is physically connected
Motif for X-Windowsa	Provides graphical user interface capabilities	ABS OpenVMS server ABS OpenVMS client
Oracle Rdba for VAX or Alpha systems	Provides distributed and multi streaming capabilities.	ABS OpenVMS Server
Requirements:   If you install Oracle Rdb for ABS policy database, the version of Oracle Rdb that you select must be up and running before you install. Also, the file SYS$LIBRARY:SQL$USER.OLB or SYS$LIBRARY:SQL$USER_ n.OLB (where n is version specific) must pre exist on your system.   If you have Oracle Rdb Version 6.0, you must apply engineering change order (ECO) number 5.

Required Process Account Quotas

The account you use to install ABS (typically the SYSTEM account) must have sufficient quotas to enable you to perform the installation. If your SYSTEM account quotas are the same as or higher than the default values provided with the OpenVMS operating system, then these values should be sufficient to install the software.

See Required Installing Account Process Quotas summarizes the process quotas and the quotas that VMSINSTAL requires to perform the installation.

Required Installing Account Process Quotas

Account Quota	Minimum Value
ASTLM	200
BIOLM	10000
BYTLM	18000
DIOLM	200
ENQLM	2048
FILLM	300
PGFLQUO	10000
TQELM	200

To see your current process quotas, see the following example:

$ MCR AUTHORIZE
UAF> SHOW SMITH

Result:
This command shows all your process quotas. If you need to increase your process account quotas, see the following example:

$ MCR SYS$SYTEM:AUTHORIZE
UAF> MODIFY SMITH/ENQLM=2048
UAF> EXIT

If you are supporting NT or UNIX clients, to ensure successful save and restore operations, set the quotas to the following values from ABS OpenVMS server node:

UCX> SET PROTOCOL TCP/QUOTA=(SEND:50000,RECEIVE:50000)

If you have to reboot the machine, make sure that you reset these values after rebooting.

More information:
For detailed instructions about modifying account quotas, see the description of Authorize Utility in OpenVMS System Management Subkit.

Overview of Hardware Installation

For your storage application to work, the hardware it depends on must be installed, connected, and configured to function with the operating system. This section provides a sequence of actions that you can use to verify that storage devices are connected and operating before you install MDMS and other application.

This procedure applies to the installation of a jukebox with drives or a standalone drive.

Verify the Node is in the MDMS Database

If this installation is not the initial installation of MDMS, 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 using the following command:

$ MDMS CREATE NODE node_name_you_are_installing_on

See the Archive Backup System for OpenVMS Command Reference Guide for the qualifiers to use.

If the node you are adding is an MDMS server node, the installation procedure will create the node using the /DATABASE qualifier. In addition, 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.

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.

RDF is not available if you are installing MDMS with the ABS-OMT license.

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.

Registering ABS Licenses

To use ABS software, you must register and load the licenses before you begin the installation procedure. This information is supplied in the License PAK document which is packaged along with Archive Backup System for OpenVMS Cover Letter.

To register a license under OpenVMS, use the following procedure:

1. Log in to the system where you will be installing the software. Log in under SYSTEM account, or enable your account with the privileges described in See Prerequisite Patches.
2. Select one of the following methods to register the licenses:
3. At DCL prompt, enter the LICENSE REGISTER command with appropriate qualifiers that correspond to License PAK information. See See How to Register Your ABS Licenses Using the LICENSE REGISTER Command.
4. Invoke SYS$UPDATE:VMSLICENSE.COM procedure. When it prompts you for information, respond with data from your License PAK. See See How to Register Your ABS Licenses Using VMSLICENSE.COM.

If you plan to use ABS on more than one node in an OpenVMS Cluster, you must load the licenses on other nodes after you install ABS. See See How to Register Your ABS Licenses Using the LICENSE REGISTER Command, Step 10 for instructions.

Steps to Convert to a New Scheduling Option

If you are converting from DECSCHEDULER (default for V2.2n) to INT_QUEUE_MANAGER or EXT_QUEUE_MANAGER, you need to review your save requests before installing ABS V3.n.

Before updating ABS to V3.n, do an ABS SHOW SAVE * command.

1. If a save has a start time in the past, you may want to set the save request to the desired start time, or to NEVER using:

ABS SET SAVE request /START_TIME="time" or
ABS SET SAVE request /START_TIME = NEVER or
ABS SET SAVE request /NOSTART_TIME

1. Save requests which have an explicit time, NOW or NEVER will NOT be scheduled.
2. During ABS V3.n installation, if you choose to use the INT_QUEUE_MANAGER or EXT_QUEUE_MANAGER scheduling option, all of the ABS jobs in the POLYCENTER Scheduler are placed on hold. You may wish to delete the POLYCENTER Scheduler job using SCHEDULER DELETE request/USER=ABS.

After updating to ABS V3.n, ABS will begin scheduling the save requests at their new start time.

Information about the ABS scheduling activities is logged to the ABS$LOG:ABS$POLICY_<node_name>.LOG file. To receive additional information about scheduling in the log file, you may define a logical name:

$ DEFINE/SYSTEM ABS_SCHEDULER_LOGGING TRUE

An opcom message will automatically be sent to the TAPE operator if ABS fails to schedule a request.

Installing Archive Backup System for OpenVMS Software

Now that you have successfully installed and configured MDMS software, see See Stages of Installing ABS Software for the stages of installing and configuring ABS software.

Installing ABS OpenVMS Client Software

OpenVMS client support is not available with an ABS-OMT license.

If you select to use the INT_QUEUE_MANAGER or EXT_QUEUE_MANAGER scheduling options, you must have ABS V3.0 or greater installed on all of your ABS servers and ABS OpenVMS clients. If you are using any other scheduling option, you may do a rolling upgrade of your clients. In those cases, ABS V2.2x may be running on the clients with ABS V3.0 running on the server.

When installing ABS software, notice that ABS does not provide two separate software kits. Instead, installation of ABS OpenVMS server or client software is determined by the OpenVMS node name that you enter during the installation procedure.

See Installing ABS OpenVMS Client Software describes how to install and configure an ABS OpenVMS client.

In See Installing ABS OpenVMS Client Software, ABS server node is referred to as SVNODE::, and ABS client node is referred to as CLNODE::

Installing ABS OpenVMS Client Software

Step	Action
	Install ABS software on the OpenVMS client node as on the server node, with one exception.   When the installation procedure prompts for the node name for the server (ABS OpenVMS server node), do not accept the default node name (client node name). Instead, enter OpenVMS Cluster alias or OpenVMS node name that you entered when you installed ABS OpenVMS server software: * cluster or node list for ABS policy engine [CLNODE::] : SVNODE Result: ABS installs only the client portion of ABS software on the node named CLNODE::.
	After installing ABS software on the OpenVMS client node, create a proxy account for ABS OpenVMS server node on ABS OpenVMS client node.   On ABS OpenVMS client node (CLNODE::), enter the following set of DCL commands: $ SET DEFAULT SYS$SYSTEM $ RUN AUTHORIZE UAF> ADD/PROXY SVNODE::ABS ABS/DEFAULT UAF> EXIT Result: These commands allow CLNODE:: to submit a save or restore request from the client node.
	Create save and restore requests for OpenVMS clients as described in Archive Backup System for OpenVMS Guide to Operations .
	Create (or modify) storage and environment policies. Archive Backup System for OpenVMS Guide to Operations describes how to create those policies.
	Create system and user backup operations using the correct storage and environment policies. Archive Backup System for OpenVMS Guide to Operations , provides instructions for these tasks.

 

 

 

Configuring ABS UNIX Clients

To allow ABS to perform backup and restore operations for UNIX clients, you must configure access between the OpenVMS systems that run ABS server software and the UNIX client systems that contain the files to be backed up. The stages of installing and configuring a UNIX client is described in See Stages of Installing and Configuring an ABS UNIX Client.

There is no extra software kit provided for UNIX clients.

Stages of Installing and Configuring an ABS UNIX Client

 

Stage	Action
	Register ABS UNIX license on ABS OpenVMS server node. See Section 2.11 for instructions.
	Modify the appropriate files on the UNIX client system as described in the See Modifying the Appropriate UNIX Files.
	Transfer the gtar and gzip sources from ABS OpenVMS server node to each UNIX client system that you intend to back up using ABS. See See Transferring the UNIX Backup Agent Sources.
	Build the executables on each UNIX client system that you plan to back up using ABS as described in See Building the UNIX Executables.
	Authorize the UNIX clients as described in See Authorizing NT and UNIX Clients and Appendix A.
	Create save and restore requests for the UNIX client from the OpenVMS server node. See Archive Backup System for OpenVMS Guide to Operations and Archive Backup System for OpenVMS Command Reference Guide for instructions about creating save and restore requests for UNIX clients.

 

Modifying the Appropriate UNIX Files

See Modifying the Appropriate UNIX Files, lists the files that you need to modify on each UNIX client system that ABS is going to back up, and it describes the modifications to make for those specific files.

UNIX is a case sensitive system. Be sure to enter the commands on the UNIX client system exactly as they are shown in See Modifying the Appropriate UNIX Files and See Transferring the Backup Agent Sources.

Modifying the Appropriate UNIX Files

 

File	Modification
/.rhosts 4	Replace the ASCII readable internet address with ABS OpenVMS server nodes. The file format is: # readable ip address account node01.vms.real.node ABS #ABS on node NODE01 In this example, replace node01.vms.real.node with ABS OpenVMS server node names. The account name must stay the same (ABS), and it must be specified in capital letters. Example of /.rhosts: node01.vms.real.node ABS node02.vms.real.node ABS Requirement: You must always modify the /.rhosts file. If the file does not exist, then you must create it. Be sure that the /.rhosts file is located in the root directory and that is owned by the root account because ABS uses this directory during the backup operation.
/etc/hostsa	List the numeric internet address and the ASCII readable internet address of ABS OpenVMS server nodes. The file format is:   # Internet Address Hostname # Comments nn.nn.nn.nn node01.vms.real.node # example entry for hosts file Where:   nn.nn.nn.nn is the numeric internet address of ABS node that executes save and restore requests. node01.vms.real.node is the ASCII readable internet address of nn.nn.nn.nn. You must enter every node name on which ABS may execute. Example of /etc/hosts: 01.02.03.04 node01.vms.real.node # node01 running ABS 01.02.01.04 node02.vms.real.node # node02 running ABS Note: If ABS OpenVMS server nodes are already listed in the file /etc/hosts, you do not need to add them again.

Transferring the UNIX Backup Agent Sources

During the installation of ABS server software, the installation procedure creates a directory named ABS$ROOT:[CLIENTS.UNIX] on ABS server node. This directory contains the following two uncompressed sources that make up the UNIX backup agent:

• ABS$ROOT:[CLIENTS.UNIX]TAR-1_12.TAR
• ABS$ROOT:[CLIENTS.UNIX]GZIP-1_2_4.TAR

To configure a UNIX client, you must transfer the gtar and gzip sources to each UNIX client system that ABS is going to back up, build the executables, and place them in /usr/bin.

Refer to See Transferring the Backup Agent Sources to transfer the gtar and gzip sources from ABS server node to the UNIX client system.

Transferring the Backup Agent Sources

u_node> ftp node01 # Connect to the ABS OpenVMS Server Node
Connected to node01.vms.dec.com.
220 node01 FTP Server (Version 3.3) Ready.
Name (node01:user1): user1
331 Username USER1 requires a Password.
Password:
230 User logged in.
Remote system type is VMS.

ftp> cd abs$root:[clients.unix] # Change to the directory that contains the files
250 CWD command successful.
ftp> pwd
257 "ABS$ROOT:[CLIENTS.UNIX]" is current directory.
ftp> ls # List the files in this directory
200 PORT command successful.
150 Opening data connection for (16.82.16.75,1174)
gnu_general_public_license.txt;4
gnu_readme_where_to_get.txt;4
gzip-1_2_4.tar;4
tar-1_12.tar;4
226 NLST Directory transfer complete.

ftp> bin # set the file transfer mode to binary
200 TYPE set to IMAGE.

ftp> get # Get the sources
(remote-file) tar-1_12.tar
(local-file) tar-1_12.tar
200 PORT command successful.
150 Opening data connection for tar-1_11_8.tar (16.82.16.75,1178)
226 Transfer complete.
2662400 bytes received in 5.7 seconds (4.6e+02 Kbytes/s)

ftp> get # Get the sources
(remote-file) gzip-1_2_4.tar
(local-file) gzip-1_2_4.tar
200 PORT command successful.
150 Opening data connection for gzip-1_2_4.tar (16.82.16.75,1494)
226 Transfer complete.
798720 bytes received in 1.8 seconds (4.3e+02 Kbytes/s)

ftp> quit
221 Goodbye

Building the UNIX Executables

After you have transferred the gtar and gzip sources, you are required to build the executables on the UNIX client system. With UNIX OS version upgrade, it is mandatory to rebuild ABSgtar and ABSgzip executables on the UNIX client.

The following sections describe how to build the tar and gzip executables.

Building the tar Executable

Use the following procedure to build the tar executable:

1. Use native tar to expand the tar file
2. Change directory to the tar directory
3. Enter the command ./configure --disable-nls
4. Enter the command make to build the tar image
5. Verify the tar image was created
6. Change directory to src
7. Verify that it is an executable image
8. Change to super user
9. Copy the executable from src/tar to usr/bin/ABSgtar
10. Change the protection on the image
11. Display the complete directory
12. Exit super user
13. Perform a cleanup operation

Example of tar

u_node> tar -xvf tar-1_12.tar 1
tar-1.12/README
tar-1.12/AUTHORS
.

.

.
tar-1.12/po/sv.gmo

u_node> cd tar-1.12 2
u_node> configure --disable-nls 3
creating cache ./config.cache
checking host system type... alpha-dec-osf3.2

.

.

.
creating config.h

u_node> make 4
for subdir in doc lib intl src scripts po; do \

echo making all in $subdir; \
(cd $subdir && make CC='gcc' CFLAGS='-g -O' LDFLAGS='' LIBS=''
prefix='/usr/local' exec_prefix='/usr/local'
bindir='/usr/local/bin' libexecdir='/usr/local/libexec'
infodir='/usr/local/info' infodir='/usr/local/info'
libexecdir='/usr/local/libexec' all) || exit 1; \

done
making all in doc

.

.

.
make[1]: Leaving directory `/usr/users/user1/tar-1.11.8/po'

u_node> ls src 5
Makefile checktar.sh extract.o list.c open3.h rmt.o tar.h
.

.

.
buffer.c diffarch.o gnu.c names.c rmt.c tar 5

u_node> cd src 6
u-node> file tar 7
tar: COFF format alpha dynamically linked, demand paged
executable or object module not stripped
- version 3.11-8

u-node> su 8
Password:

# cp tar /usr/bin/ABSgtar 9
# chmod ugo+x /usr/bin/ABSgtar 10
# ls -l /usr/bin/ABSgtar 11
-rwxr-xr-x 1 root system 655794 Jan 24 11:07 ABSgtar
# exit 12

u-node> cd .. 13
u-node> rm -rf tar-1_12 13
%rm -f tar-1_12.tar 13

Building the gzip Executable

Use the following procedure to build the gzip executable:

1. Use the native tar to expand the gzip-1_2_4.tar image
2. Change directory to gzip-1.2.4
3. Enter the command ./configure
4. Enter the command make
5. Verify that the gzip file is there
6. Make sure it is an executable
7. Change to super user
8. Copy gzip file to /usr/bin/ABSgzip
9. Change the protection on the image
10. Exit super user
11. Perform a cleanup operation

Example of gzip

u_node> tar -xvf gzip-1_2_4.tar 1
gzip-1.2.4/README

.

.

.
gzip-1.2.4/primos/include/sysTypes.h

u_node> cd gzip-1.2.4 2

u_node> ./configure 3
checking for gcc

.

.

.
checking for gzip to derive installation directory prefix
chose installation directory prefix /usr/local
creating config.status
creating Makefile

u_node> make 4
gcc -c -DSTDC_HEADERS=1 -DHAVE_UNISTD_H=1 -DDIRENT=1 -O gzip.c

.

.

.
gcc -O -o gzip gzip.o zip.o deflate.o trees.o bits.o unzip.o
inflate.o util.o crypt.o lzw.o unlzw.o unpack.o unlzh.o getopt.o
/usr/ucb/ld:
Warning: Linking some objects which contain exception information sections and some which do not. This may cause fatal runtime exception handling problems (last obj encountered without exceptions was crypt.o).

rm -f gunzip zcat
ln gzip gunzip
ln gzip zcat

u_node> ls gzip 5
gzip
u_node> file gzip 6
gzip: COFF format alpha dynamically linked, demand paged executable or object module not stripped
- version 3.11-8

u-node> su 7
Password:
# cp gzip /usr/bin/ABSgzip 8
# chmod ugo+x /usr/bin/ABSgzip 9
# ls -l /usr/bin/ABSgzip
-rwxr-xr-x 1 root system 654785 Jan 24 11:08 ABSgzip
# ln -s /usr/bin/ABSgzip /usr/bin/gzip
# exit 10

u-node> cd .. 11
u-node> rm -rf gzip-1.2.4 11
u-node> rm -f gzip-1_2_4.tar 11

If you have problems transferring or building the tar or gzip files, see your UNIX system manager.

Authorizing NT and UNIX Clients

After you have registered and loaded the NT or UNIX client license on ABS server node, run the authorization executable file to authorize the NT or UNIX client node names that you intend to back up using ABS. You must authorize access on the ABS OpenVMS server system for each UNIX and NT system that you are going to back up using ABS.

See Authorizing NT and UNIX Client Nodes describes how to authorize NT and UNIX client nodes.

ABS NT and UNIX client licenses are sold in units according to the number of nodes that you want to support: 1, 5, 10, 25, 50, or 100. ABS calculates the number of nodes authorized versus the number of units the license allows. You cannot authorize more NT or UNIX clients than the number of units allowed by the NT or UNIX client license that you have purchased.

Authorizing NT and UNIX Client Nodes

Step	Action
	Enter the following command from ABS server: $ RUN ABS$SYSTEM:ABS$CLIENT_LICENSE.EXE
	Add the node names of the UNIX or NT client nodes. When prompted, specify an NT or UNIX client:   Would you like to Add/Modify/Remove/Show the Client License?: ADD Enter Node Name: CLIENT_NODE_NAME Client Node Type (UNIX or NT) [UNIX]: NT Enter TCPIP Port Number [1800]: Note: The port number is arbitrary, but it must match the port number you use when you install the NT clients.
	If the client node is an NT client, enter the port number. The default is 1800.
	Make sure that the logical named ABS$CLIENT_DB is defined as /SYSTEM/EXEC and that it translates to ABS$ROOT:[DATABASE]CLIENT_DB.DAT. This logical name should be defined during the startup procedure. You can verify that the logical name is defined correctly by entering the following command: $ SHOW LOGICAL/FULL ABS$CLIENT_DB

More Information:
For an example of adding, modifying, removing and showing NT or UNIX clients, see Appendix A.

 

Performing Postinstallation Tasks

Complete ABS/MDMS postinstallation tasks described in this chapter after you have successfully installed ABS/MDMS OpenVMS server or client software:

• See Installing ABS for the First Time describes how to initialize the ABS database if this failed during the installation.
• See Create a Node Object describes how to create a node object for MDMS.
• See Verifying ABS Installation describes how to verify the installation was successful.
• See Providing Automatic Start Up and Shut Down explains how to edit the startup and shutdown files.
• See Removing SLS/MDMS V2.x Automatic Startup describes removing the SLS/MDMS V2.x Automatic Startup.
• See Meeting OpenVMS Cluster Requirements describes the requirements for an OpenVMS Cluster installation.
• See Configure MDMS describes configuring MDMS.
• See Configure Remote Tape Drives describes configuring remote tape drives.
• See Granting the Appropriate ABS/MDMS Access Right Identifiers explains how to set up access right identifiers.
• See Modifying The ABS Default Policy Objects describes how to modify ABS default policy objects.
• See Performing a Save, Lookup, and Restore Operation explains how to test ABS installation to perform save and restore requests.
• See Verifying NT and UNIX Client Quotas explains how to set the quotas if you are supporting UNIX and NT clients.
• See Adding NT Parameter describes the need of adding NT parameter, before issuing multivolume SAVE requests.
• See Allowing ABS Access to All Files on the NT Systems describes the procedure to allow ABS to access all files on NT systems.
• See MDMS Graphical User Interface (GUI) Installation describes the MDMS graphical user interface (GUI) installation.
• See Running the GUI describes how to run the graphical user interface (GUI).

OpenVMS client support is not available with an ABS-OMT license.

Installing ABS for the First Time

If you are installing ABS as a new installation, database initialization programs may fail to run. This results in IVP failure with errors showing the storage classes and execution environments.

To initialize the database with the default storage policies and execution policies, run the following executable:

RUN ABS$SYSTEM:ABS$DB_INIT.EXE

Create a Node Object

If this is the initial installation of MDMS, you may 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

Verifying ABS Installation

If you did not execute the IVP during the installation procedure, you can execute it immediately after installing ABS/MDMS software. Enter the following command at the DCL system prompt:

$ @SYS$TEST:ABS$IVP.COM

$ @SYS$TEST:MDMS$IVP.COM

If an error occurs during the IVP, the following message is displayed:

ABS Version 3.2A Installation Verification Procedure failed.

%VMSINSTAL-E-IVPFAIL, The IVP for ABS Version 3.2A has failed.

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

• ABS is currently running
• The operating system version is incorrect
• A prerequisite software 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.

Providing Automatic Start Up and Shut Down

You must edit the startup and shutdown files to provide automatic startup and shutdown of ABS software. To make sure that ABS automatically starts up and shuts down, follow these steps:

1. Add the following command lines to the system startup file named SYS$MANAGER:SYSTARTUP_ VMS.COM:
   $ @SYS$STARTUP:MDMS$STARTUP
   $ @SYS$STARTUP:ABS$STARTUP

Removing 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 make sure you remove this line from your system's start up file:

$ @SYS$STARTUP:SLS$STARTUP

If "SYS$MANAGER:TAPESYMBOL.COM" has been included in SYS$MANAGER:SYLOGIN.COM or the User Login Command Procedure, ensure that you remove this line from the same.

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.

Meeting OpenVMS Cluster Requirements

If you installed ABS server software on an OpenVMS Cluster system, perform the steps in See Updating the DCL Tables on each node in the OpenVMS Cluster (excluding the installing node) where you want to use ABS.

Configure MDMS

Now that you have installed MDMS you need to configure the MDMS database. MDMS provides a command procedure that you can use to configure the MDMS database in a new installation. The procedure is completely self-documenting with a help facility, and all key object attributes are defined. The procedure guides you through the following configuration objects:

• The domain (defining default values for other objects)
• Locations
• Nodes and groups
• Jukeboxes and associated drives
• Standalone drives and stackers
• Volumes, media types and pools

The procedure is activated using the following command:

$ @ MDMS$SYSTEM:MDMS$CONFIGURE.COM

Please refer to the Archive Backup System for OpenVMS Guide to Operations appendix "Sample Configuration of MDMS" for an example of using this procedure. If you are upgrading from SLS or ABS V2.9x, you should use the procedure MDMS$CONVERT_V2_TO_V3 instead. Refer to the Archive Backup System for OpenVMS Guide to Operations Appendix "Converting SLS.MDMS V2.x to V3".

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

Configure Remote Tape Drives

If you installed the RDF software, you need to configure the remote tape drives. RDF is not available if you are installing MDMS with the ABS-OMT license.

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

Granting the Appropriate ABS/MDMS Access Right Identifiers

When ABS Server installation procedure is complete, the user account that performed the installation (typically the SYSTEM account) is granted the following ABS access rights identifiers:

• ABS_CREATE_STORAGE_CLASS-Users who are granted this access right identifier can create a storage class (applicable only on ABS server system).
• ABS_CREATE_EXECUTION_ENV-Users who are granted this access right identifier can create an execution environment (applicable only on ABS server system).
• ABS_SHOW_ALL-Users who are granted this access right identifier can show all ABS policy objects (applicable only on ABS server system).
• ABS_LOOKUP_ALL-Users who are granted this access right identifier can look up all ABS saved data from any catalog (applicable on any ABS node).
• ABS_CREATE_REMOTE_JOBS-Users who are granted this access right identifier can submit a save or restore request that will be executed on a remote client node (applicable only on ABS server system).
  
  Requirement:
  To create NT or UNIX save requests, the requester (creating process) must have the ABS_CREATE_REMOTE_JOBS access rights identifier enabled.
• ABS_BACKUP_JOB-Users who are granted this access right identifier can submit a save or restore request that runs under their user name (a user backup). The user must also have read and write access control to the storage policy and environment policy intended for user backups.
• ABS_BYPASS-Users who are granted this access right identifier can perform any ABS function (applicable only on ABS server system). This includes creating, deleting, modifying, or showing any ABS policy objects.

Before any user can use MDMS, you must grant MDMS rights to those users. Refer to the MDMS Rights and Privileges Appendix for an explanation of MDMS rights and how to assign them.

Enabling an Access Rights Identifier

To grant an access rights identifier to a user's account, run the AUTHORIZE utility.

Example:

$ SET DEFAULT SYS$SYSTEM
$ RUN AUTHORIZE

UAF>GRANT/IDENTIFIER ABS_LOOKUP_ALL USER1

%UAF-I-GRANTMSG, identifier ABS_LOOKUP_All granted to USER1

UAF>EXIT

Do not enable the access rights identifier by performing a SET RIGHTS_LIST at the DCL prompt.

Modifying The ABS Default Policy Objects

ABS provides a set of default policy objects so you can start using ABS for your backup operations immediately after installation.

lists ABS default policy objects that are resident on your system when the installation procedure has successfully completed.

Default Policy Object Attributes

Each of ABS default policy objects have the following attributes at the completion of the installation procedure:

• The owner of a default policy object is the user name of the account who installed the software (typically SYSTEM).
• Access to a default policy object is allowed only from ABS server node and by ABS account.

Upon completion of ABS installation procedure, ABS default objects enable you to create save and restore requests objects only from ABS server node. At this point in time, the default access controls are set to allow access only from ABS server system; you cannot create a save or restore request from an ABS client system. Attempting to run a save request from an ABS client system would cause an access violation to the default storage policies, with the exception of the USER_BACKUPS storage policy. The USER_BACKUPS storage policy default attributes allows users from ABS client systems to create save and restore requests.

OpenVMS client support is not available with an ABS-OMT license.

To enable access to the other default ABS policy objects by ABS client systems, you must modify the default policy objects as described Section

Modifying Default Policy Objects

Because the installing account has been granted ABS_BYPASS access right identifier, only this account can access ABS default policy objects at this point in time. For maintenance purposes, modify the policy objects provided by ABS as shown in See Modifying ABS Provided Policy Objects.

The command line interface is not available with an ABS-OMT license, you must use the GUI.

OMT_BACKUPS storage policy and OMT_BACKUPS_ENV environment policy are the only policies available with the ABS-OMT license.

Modifying ABS Provided Policy Objects

Step	Action
	Add the storage administrator as a user to the storage and environment policies provided by ABS, enable CONTROL access in order to modify these policy objects.   DCL Example: $ ABS SET STORAGE SYSTEM_BACKUPS - _$ /ACCESS=(USER_ID=SMITH,ACCESS="CONTROL") $ ABS SET ENVIRONMENT SYSTEM_BACKUPS_ENV - _$ /ACCESS=(USER_ID=SMITH,ACCESS="CONTROL")
	To enable access to ABS account from an ABS client system, see the following example:   DCL Example: $ ABS SET STORAGE SYSTEM_BACKUPS/ACCESS=(USER_ID=*::ABS, ACCESS="READ, WRITE") $ ABS SET ENVIRONMENT SYSTEM_BACKUPS_ENV/ACCESS=(USER_ID=*::ABS, ACCESS="READ, WRITE") Where: *:: enables any node to access the storage and environment policy. ABS is the account name allowed to access the storage and environment policy. $ ABS SET STORAGE SYSTEM_BACKUPS/ACCESS=(USER_ID=node::ABS, ACCESS="READ, WRITE") $ ABS SET ENVIRONMENT SYSTEM_BACKUPS_ENV/ACCESS=(USER_ID=node::ABS, ACCESS="READ, WRITE") Where: node is the client node.

You can modify the other policy objects provided by ABS in the same manner. See Archive Backup System for OpenVMS Guide to Operations for instructions about adding users and enabling access controls.

Before using your storage policy, you may need to modify the MDMS related information in the policy. For example, you may wish to use a different media type than the default media type from your MDMS domain. When ABS is installed, the storage policies are initialized with the defaults from the domain. Issue an MDMS SHOW DOMAIN command to see the defaults. Make sure that your storage policy contains the desired settings before executing a save request.

Performing a Save, Lookup, and Restore Operation

To make sure that you can use ABS for your backup and restore operations, use the following procedure to test your installation:

1. Log into ABS server node under the same user account where you installed the software (typically SYSTEM).
2. Create a save request for the ABS server node and specify a file name in your directory. Enter the following command:
   
   $ ABS SAVE filename/NAME=TEST_SAVE/STORAGE=SYSTEM_BACKUPS
3. Verify that the file you saved is recorded in the ABS catalog by entering ABS LOOKUP command:
   
   $ ABS LOOKUP filename
4. Restore the file back to its original location using ABS. Enter the following command:
   
   $ ABS RESTORE filename/NAME=TEST_RESTORE/STORAGE=SYSTEM_BACKUPS/-
   _$ CONFLICT_OPTIONS=NEW_VERSION

Verifying NT and UNIX Client Quotas

If you are supporting NT or UNIX clients, to ensure successful save and restore operations, set the quotas to the following values on ABS OpenVMS server node:

UCX> SET PROTOCOL TCP /QUOTA=(SEND:50000,RECEIVE:50000)

Adding NT Parameter

Issuing multivolume SAVE requests to NT client requires you to modify the Registry Path

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Sevices\Tcpip\Parameters

with the following NT parameter (20 or greater is recommended).

TcpMaxDataRetransmissions REG_DWORD 20

This change to the default built in Windows NT parameter/subkey ensures that the TCP/IP connection is not prematurely terminated with send failure.

Allowing ABS Access to All Files on the NT Systems

ABS must have access to all the files you wish to backup on your NT system. There are two ways to do this:

• Set access on the files for the SYSTEM account

To set the file access,

• Select the file from a fileview window.
• Select Properties from the File pulldown.
• Click the Security tab
• Select Permissions.
• Select Add and highlight SYSTEM. Add the type of access (full control is best, so you can restore files).
• Click the Add button.

This gives the SYSTEM account access to the files.

• Set the Account that ABS uses for the Backups

ABS, by default, uses the SYSTEM account to backup the files. If you wish to change the account used by ABS, you may do this by modifying the properties of the service:

• Click on Services in the Control Panel.
• Highlight the ABS service
• Click on Startup.
• In the Log On As section, select This Account.
• Enter the account name to be used and the password for that account.
• Click OK.

The account that you select should be a member of the Administrator group. The administrator group should be able to access all the files on your NT system, unless you set access denied for Administrator on a file.

MDMS Graphical User Interface (GUI) Installation

This section describes how to install and run the Graphical User Interface (GUI) on various platforms.
As the GUI is based on Java, you must have the Java virtual machine installed on the system you run the MDMS GUI on. If you do not have Java installed on your system, these sections describe what is needed and where to get it.

This installation procedure extracts files from the MDMS kit and places them in MDMS$ROOT:[GUI...]. You can then move the files to your Windows system and install them.

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

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

If you are installing the GUI on OpenVMS Alpha V7.1-2, then the following patches (or their latest equivalent) need to be installed on the system. Please contact your Compaq representative for obtaining these patches.

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.

1. 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. 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. 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. 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. 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. 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. 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. 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"

1. Note that this command affects all DECwindows sessions. In order to get the proper operation on both the GUI session and other DECwindows sessions, the following sequence should be employed:

$ MCR decw$utils:xmodmap -e "keysym Delete = BackSpace Delete"
$ MDMS/INTERFACE=GUI
$ MCR decw$utils:xmodmap -e "keysym Delete = Delete"

This resets the behavior of all the other windows to normal while the Java GUI still retains the earlier definition. This way, both the GUI and the other DECwindows can co-exist, both retaining the required functionality.

1. The Java kit and MDMS GUI are provided in zipped files. The Java Virtual Machine is capable of reading zipped files directly. Do not unzip any of the zipped files provided with the GUI.

Running the GUI

Now that you have installed the GUI, you have to make sure the server node is configured to accept communications from the GUI. The server node for the GUI must have:

• TCP/IP enabled
  and
• the MDMS rights enabled in the SYSUAF record for the user

To enable TCP/IP communications on the server, you have to set the TCP/IP Fullname attribute and enable the TCPIP transport. See the command reference guide for information about setting these attributes in a node.

MDMS rights for the user must be enabled in the SYSUAF record to log into the server using the GUI. Refer to the command reference guide for information about MDMS rights.

The following sections describe how to run the GUI on various platforms.

Adding Client Licenses

See Adding Client Licenses shows how to add a UNIX or NT client license

Modifying Client Licenses

See Modifying a Client License shows how to modify the port number of an NT or UNIX client license.

Showing Client Licenses

See Showing Client Licenses illustrates how to show an NT or UNIX client license.

Removing Client Licenses

See Removing Client Licenses shows how to remove NT or UNIX client licenses:

ABS File Names

See ABS Installed Files lists the names of ABS files created on your system after ABS is successfully installed.

ABS Logical Names

The following logical names are entered into the system logical name table when ABS installation procedure is complete. These names are stored in the startup file, SYS$STARTUP:ABS$STARTUP.COM. They are automatically entered into the system logical name table whenever the system reboots or whenever the software is invoked. See ABS Logical Names describes the logical names.

 

MDMS Files and Logical Names

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

MDMS File Names

See MDMS Installed Files contains the names of all MDMS files created on the system after MDMS V3.2A is successfully installed.

MDMS Logical Names

When the MDMS installation procedure is complete, logical names are entered into the system logical name table and stored in the startup file, SYS$STARTUP:MDMS$SYSTARTUP.COM. They are automatically entered into the system logical name table whenever the system reboots or whenever MDMS is started with this command:

SYS$STARTUP:MDMS$STARTUP.COM.

See MDMS Logical Namesdescribes the logical names in the system table

MDMS Rights - Types

MDMS has the following rights:

• High-level rights
• Low level rights
• ABS rights
• High Level Rights

These rights are designed for a specific kind of user, to support a typical MDMS installation, and make the assignments of rights to users easy. The three high-level MDMS rights, the default right, administrator right and the additional right are described in

High Level Rights

High level right	Allows Privileges for...
MDMS_USER	A non-privileged MDMS user who wants to use MDMS to manage tape volumes for BACKUP, ABS or HSM purposes
MDMS_APPLICATION	Main applications that MDMS supports - ABS and HSM server processes
MDMS_OPERATOR	The user responsible for day-to-day operations in the MDMS environment
Default Right A hidden high-level right	The low level rights contained in it, for users with no MDMS rights. They are additional to any specific rights a user may have been granted. It is the default right. By default, there are no low-level rights assigned to the default right. If rights are assigned to the default right, they apply to all users in the system, since every user is effectively granted the default right. The default right can be disabled with the MDMS_NO_DEFAULT identifier in a user's UAF file.
MDMS_ALL_RIGHTS Administrator Right	A system administrator to perform any operation. MDMS_ALL_RIGHTS can be enabled with the OpenVMS SYSPRV privilege.
Additional Right	All operations.

High Level Rights

You can disable the mapping of SYSPRV to MDMS_ALL_RIGHTS using a SET DOMAIN command

1. Low-level rights

Each command or command option will be tagged with one or more low-level rights that are needed to perform the operation. Where more than one right is specified, the command indicates the appropriate combination of rights needed. The MDMS administrator can assign a set of low-level rights to each high-level right. The administrator can then simply assign the high-level right to the user.
MDMS translates the high-level right to respective low-level rights while processing a command. For additional flexibility, the user can be assigned a combination of high-level and low-level rights. The result will be a sum of all rights defined.
The default set of mapping of high-level to low-level rights will be assigned at installation (by default) and stored in the domain record. However, the MDMS administrator can change these assignments by using the SET DOMAIN command.

By default a user has no rights and cannot use MDMS. The system administrator can change the `rightless' user's rights using a SET DOMAIN command. These rights can again be disabled on a per-user basis as needed.

The low-level rights are designed to be applied to operations. A given command, with a given set of qualifiers or options, requires the sum of the rights needed for the command and all supplied options. In many cases some options require more privilege than the command, and that higher privilege will be applied to the entire command if those options are specified.
The following are usable low level rights:

Default High-Level to Low-Level Mapping

This section defines the default high to low-level mapping for each high-level right.

1. MDMS_USER:

Configuration Order

Configuration - which involves the creation or definition of MDMS objects, should take place in the following order:

1. Location
2. Media type
3. Node
4. Jukebox
5. Drives
6. Pools
7. Volumes

Creating these objects in the above order ensures that the following informational message, does not appear:

%MDMS-I-UNDEFINEDREFS, object contains undefined referenced objects

This message appears if an attribute of the object is not defined in the database. The object is created even though the attribute is not defined. The sample configuration consists of the following:

• Four nodes

SMITH1 - ACCOUN cluster node
SMITH2 - ACCOUN cluster node
SMITH3 - ACCOUN cluster node
JONES - a client node

• TL826 Jukebox with robot $1$DUA560 and the following six drives:

$1$MUA560
$1$MUA561
$1$MUA562
$1$MUA563
$1$MUA564
$1$MUA565

The following examples illustrate each step in the order of configuration.

1. Configuration Step 1 Example - Defining Locations

This example lists the MDMS commands to define an offsite and onsite location for this domain.

$ !
$ ! create onsite location
$ !
$ MDMS CREATE LOCATION BLD1_COMPUTER_ROOM -
/DESCRIPTION="Building 1 Computer Room"
$ MDMS SHOW LOCATION BLD1_COMPUTER_ROOM
Location: BLD1_COMPUTER_ROOM
Description: Building 1 Computer Room
Spaces:
In Location:
$ !
$ ! create offsite location
$ !
$ MDMS CREATE LOCATION ANDYS_STORAGE -
/DESCRIPTION="Andy's Offsite Storage, corner of 5th and Main"
$ MDMS SHOW LOCATION ANDYS_STORAGE
Location: ANDYS_STORAGE
Description: Andy's Offsite Storage, corner of 5th and Main
Spaces:
In Location:

1. Configuration Step 2 Example - Defining Media Type

This example shows the MDMS command to define the media type used in the TL826.

!
$ ! create the media type
$ !
$ MDMS CREATE MEDIA_TYPE TK88K -
/DESCRIPTION="Media type for volumes in TL826 with TK88 drives" -
/COMPACTION ! volumes are written in compaction mode
$ MDMS SHOW MEDIA_TYPE TK88K
Media type: TK88K
Description: Media type for volumes in TL826 with TK88 drives
Density:
Compaction: YES
Capacity: 0
Length: 0

1. Configuration Step 3 Example - Defining Domain Attributes

This example shows the MDMS command to set the domain attributes. The reason this command is not run until after the locations and media type are defined, is because they are default attributes for the domain object. Note that the deallocation state (transition) is taken as the default. All of the rights are taken as default also.

$ !
$ ! set up defaults in the domain record
$ !
$ MDMS SET DOMAIN -
/DESCRIPTION="Smiths Accounting Domain" - ! domain name
/MEDIA_TYPE=TK88K - ! default media type
/OFFSITE_LOCATION=ANDYS_STORAGE - ! default offsite location
/ONSITE_LOCATION=BLD1_COMPUTER_ROOM - ! default onsite location
/PROTECTION=(S:RW,O:RW,G:RW,W) ! default protection for volumes
$ MDMS SHOW DOMAIN/FULL
Description: Smiths Accounting Domain
Mail: SYSTEM
Offsite Location: ANDYS_STORAGE
Onsite Location: BLD1_COMPUTER_ROOM
Def. Media Type: TK88K
Deallocate State: TRANSITION
Opcom Class: TAPES
Priority: 1536
Request ID: 2576
Protection: S:RW,O:RW,G:RW,W
DB Server Node: SPIELN
DB Server Date: 1-FEB-1999 08:18:20
Max Scratch Time: NONE
Scratch Time: 365 00:00:00
Transition Time: 14 00:00:00
Network Timeout: 0 00:02:00
ABS Rights: NO
SYSPRIV Rights: YES
Application Rights: MDMS_ASSIST
MDMS_LOAD_SCRATCH
MDMS_ALLOCATE_OWN
MDMS_ALLOCATE_POOL
MDMS_BIND_OWN
MDMS_CANCEL_OWN
MDMS_CREATE_POOL
MDMS_DEALLOCATE_OWN
MDMS_DELETE_POOL
MDMS_LOAD_OWN
MDMS_MOVE_OWN
MDMS_SET_OWN
MDMS_SHOW_OWN
MDMS_SHOW_POOL
MDMS_UNBIND_OWN
MDMS_UNLOAD_OWN
Default Rights:
Operator Rights: MDMS_ALLOCATE_ALL
MDMS_ASSIST
MDMS_BIND_ALL
MDMS_CANCEL_ALL
MDMS_DEALLOCATE_ALL
MDMS_INITIALIZE_ALL
MDMS_INVENTORY_ALL
MDMS_LOAD_ALL
MDMS_MOVE_ALL
MDMS_SHOW_ALL
MDMS_SHOW_RIGHTS
MDMS_UNBIND_ALL
MDMS_UNLOAD_ALL
MDMS_CREATE_POOL
MDMS_DELETE_POOL
MDMS_SET_OWN
MDMS_SET_POOL
User Rights: MDMS_ASSIST
MDMS_ALLOCATE_OWN
MDMS_ALLOCATE_POOL
MDMS_BIND_OWN
MDMS_CANCEL_OWN
MDMS_DEALLOCATE_OWN
MDMS_LOAD_OWN
MDMS_SHOW_OWN
MDMS_SHOW_POOL
MDMS_UNBIND_OWN
MDMS_UNLOAD_OWN

1. Configuration Step 4 Example - Defining MDMS Database Nodes

This example shows the MDMS commands for defining the three MDMS database nodes of the cluster ACCOUN. This cluster is configured to use DECnet-PLUS.

Note that a node is defined using the DECnet node name as the name of the node.

• If the node has DECnet-PLUS installed, the DECnet Fullname attribute must be the DECnet-PLUS full name.
• If the node uses TCP/IP, the TCP/IP attribute should be defined.
• If you use the GUI, you must define the TCP/IP attribute and include TCPIP in the Transports attribute.

$ !
$ ! create nodes
$ ! database node
$ MDMS CREATE NODE SMITH1 - ! DECnet node name
/DESCRIPTION="ALPHA node on cluster ACCOUN" -
/DATABASE_SERVER - ! this node is a database server
/DECNET_FULLNAME=SMI:.BLD.SMITH1 - ! DECnet-Plus name
/LOCATION=BLD1_COMPUTER_ROOM -
/TCPIP_FULLNAME=SMITH1.SMI.BLD.COM - ! TCP/IP name
$ MDMS SHOW NODE SMITH1
Node: SMITH1
Description: ALPHA node on cluster ACCOUN
DECnet Fullname: SMI:.BLD.SMITH1
TCP/IP Fullname: SMITH1.SMI.BLD.COM:2501-2510
Disabled: NO
Database Server: YES
Location: BLD1_COMPUTER_ROOM
Opcom Classes: TAPES
Transports: DECNET,TCPIP
$ MDMS CREATE NODE SMITH2 - ! DECnet node name
/DESCRIPTION="ALPHA node on cluster ACCOUN" -
/DATABASE_SERVER - ! this node is a database server
/DECNET_FULLNAME=SMI:.BLD.SMITH2 - ! DECnet-Plus name
/LOCATION=BLD1_COMPUTER_ROOM -
/TCPIP_FULLNAME=SMITH2.SMI.BLD.COM - ! TCP/IP name
/TRANSPORT=(DECNET,TCPIP) ! TCPIP used by JAVA GUI and JONES
$ MDMS SHOW NODE SMITH2
Node: SMITH2
Description: ALPHA node on cluster ACCOUN
DECnet Fullname: SMI:.BLD.SMITH2
TCP/IP Fullname: SMITH2.SMI.BLD.COM:2501-2510
Disabled: NO
Database Server: YES
Location: BLD1_COMPUTER_ROOM
Opcom Classes: TAPES
Transports: DECNET,TCPIP
$ MDMS CREATE NODE SMITH3 - ! DECnet node name
/DESCRIPTION="VAX node on cluster ACCOUN" -
/DATABASE_SERVER - ! this node is a database server
/DECNET_FULLNAME=SMI:.BLD.SMITH3 - ! DECnet-Plus name
/LOCATION=BLD1_COMPUTER_ROOM -
/TCPIP_FULLNAME=CROP.SMI.BLD.COM - ! TCP/IP name
/TRANSPORT=(DECNET,TCPIP) ! TCPIP used by JAVA GUI and JONES
$ MDMS SHOW NODE SMITH3
Node: SMITH3
Description: VAX node on cluster ACCOUN
DECnet Fullname: SMI:.BLD.SMITH3
TCP/IP Fullname: CROP.SMI.BLD.COM:2501-2510
Disabled: NO
Database Server: YES
Location: BLD1_COMPUTER_ROOM
Opcom Classes: TAPES
Transports: DECNET,TCPIP

1. Configuration Step 5 Example - Defining a Client Node

This example shows the MDMS command for creating a client node. TCP/IP is the only transport on this node.

$ !
$ ! client node
$ ! only has TCP/IP
$ MDMS CREATE NODE JONES -
/DESCRIPTION="ALPHA client node, standalone" -
/NODATABASE_SERVER - ! not a database server
/LOCATION=BLD1_COMPUTER_ROOM -
/TCPIP_FULLNAME=JONES.SMI.BLD.COM - ! TCP/IP name
/TRANSPORT=(TCPIP) ! TCPIP is used by JAVA GUI
$ MDMS SHOW NODE JONES
Node: JONES
Description: ALPHA client node, standalone
DECnet Fullname:
TCP/IP Fullname: JONES.SMI.BLD.COM:2501-2510
Disabled: NO
Database Server: NO
Location: BLD1_COMPUTER_ROOM
Opcom Classes: TAPES
Transports: TCPIP

1. Configuration Step 6 Example - Creating a Jukebox

This example shows the MDMS command for creating a jukebox

$ !
$ ! create jukebox
$ !
$ MDMS CREATE JUKEBOX TL826_JUKE -
/DESCRIPTION="TL826 Jukebox in Building 1" -
/ACCESS=ALL - ! local + remote for JONES
/AUTOMATIC_REPLY - ! MDMS automatically replies to OPCOM requests
/CONTROL=MRD - ! controled by MRD robot control
/NODES=(SMITH1,SMITH2,SMITH3) - ! nodes the can control the robot
/ROBOT=$1$DUA560 - ! the robot device
/SLOT_COUNT=176 ! 176 slots in the library
$ MDMS SHOW JUKEBOX TL826_JUKE
Jukebox: TL826_JUKE
Description: TL826 Jukebox in Building 1
Nodes: SMITH1,SMITH2,SMITH3
Groups:
Location: BLD1_COMPUTER_ROOM
Disabled: NO
Shared: NO
Auto Reply: YES
Access: ALL
State: AVAILABLE
Control: MRD
Robot: $1$DUA560
Slot Count: 176
Usage: NOMAGAZINE

1. Configuration Step 7 Example - Defining a Drive

This example shows the MDMS commands for creating the six drives for the jukebox.
This example is a command procedure that uses a counter to create the six drives. In this example it is easy to do this because of the drive name and device name. You may want to have the drive name the same as the device name. For example:

$ MDMS CREATE DRIVE $1$MUA560/DEVICE=$1$MUA560

This works fine if you do not have two devices in your domain with the same name.

$ COUNT = COUNT + 1
$ IF COUNT .LT. 6 THEN GOTO DRIVE_LOOP
$DRIVE_LOOP:
$ MDMS CREATE DRIVE TL826_D1 -
/DESCRIPTION="Drive 1 in the TL826 JUKEBOX" -
/ACCESS=ALL - ! local + remote for JONES
/AUTOMATIC_REPLY - ! MDMS automatically replies to OPCOM requests
/DEVICE=$1$MUA561 - ! physical device
/DRIVE_NUMBER=1 - ! the drive number according to the robot
/JUKEBOX=TL826_JUKE - ! jukebox the drives are in
/MEDIA_TYPE=TK88K - ! media type to allocate drive and volume for
/NODES=(SMITH1,SMITH2,SMITH3)! nodes that have access to drive
$ MDMS SHOW DRIVE TL826_D1
Drive: TL826_D1
Description: Drive 1 in the TL826 JUKEBOX
Device: $1$MUA561
Nodes: SMITH1,SMITH2,SMITH3
Groups:
Volume:
Disabled: NO
Shared: NO
Available: NO
State: EMPTY
Stacker: NO
Automatic Reply: YES
RW Media Types: TK88K
RO Media Types:
Access: ALL
Jukebox: TL826_JUKE
Drive Number: 1
Allocated: NO
:
:
:
$ MDMS CREATE DRIVE TL826_D5 -
/DESCRIPTION="Drive 5 in the TL826 JUKEBOX" -
/ACCESS=ALL - ! local + remote for JONES
/AUTOMATIC_REPLY - ! MDMS automatically replies to OPCOM requests
/DEVICE=$1$MUA565 - ! physical device
/DRIVE_NUMBER=5 - ! the drive number according to the robot
/JUKEBOX=TL826_JUKE - ! jukebox the drives are in
/MEDIA_TYPE=TK88K - ! media type to allocate drive and volume for
/NODES=(SMITH1,SMITH2,SMITH3)! nodes that have access to drive
$ MDMS SHOW DRIVE TL826_D5
Drive: TL826_D5
Description: Drive 5 in the TL826 JUKEBOX
Device: $1$MUA565
Nodes: SMITH1,SMITH2,SMITH3
Groups:
Volume:
Disabled: NO
Shared: NO
Available: NO
State: EMPTY
Stacker: NO
Automatic Reply: YES
RW Media Types: TK88K
RO Media Types:
Access: ALL
Jukebox: TL826_JUKE
Drive Number: 5
Allocated: NO
$ COUNT = COUNT + 1
$ IF COUNT .LT. 6 THEN GOTO DRIVE_LOOP

1. Configuration Step 8 Example - Defining Pools

This example shows the MDMS commands to define two pools: ABS and HSM. The pools need to have the authorized users defined.

$ !
$ ! create pools
$ !
$ mdms del pool abs
$ MDMS CREATE POOL ABS -
/DESCRIPTION="Pool for ABS" -
/AUTHORIZED=(SMITH1::ABS,SMITH2::ABS,SMITH3::ABS,JONES::ABS)
$ MDMS SHOW POOL ABS
Pool: ABS
Description: Pool for ABS
Authorized Users: SMITH1::ABS,SMITH2::ABS,SMITH3::ABS,JONES::ABS
Default Users:
$ mdms del pool hsm
$ MDMS CREATE POOL HSM -
/DESCRIPTION="Pool for HSM" -
/AUTHORIZED=(SMITH1::HSM,SMITH2::HSM,SMITH3::HSM)
$ MDMS SHOW POOL HSM
Pool: HSM
Description: Pool for HSM
Authorized Users: SMITH1::HSM,SMITH2::HSM,SMITH3::HSM
Default Users:

1. Configuration Step 9 Example - Defining Volumes using the /VISION qualifier

This example shows the MDMS commands to define the 176 volumes in the TL826 using the /VISION qualifier. The volumes have the BARCODES on them and have been placed in the jukebox. Notice that the volumes are created in the UNINITIALIZED state. The last command in the example initializes the volumes and changes the state to FREE.

$ !
$ ! create volumes
$ !
$ ! create 120 volumeS for ABS
$ ! the media type, offsite location, and onsite location
$ ! values are taken from the DOMAIN object
$ !
$ MDMS CREATE VOLUME -
/DESCRIPTION="Volumes for ABS" -
/JUKEBOX=TL826_JUKE -
/POOL=ABS -
/SLOTS=(0-119) -
/VISION
$ MDMS SHOW VOLUME BEB000
Volume: BEB000
Description: Volumes for ABS
Placement: ONSITE BLD1_COMPUTER_ROOM
Media Types: TK88K Username:
Pool: ABS Owner UIC: NONE
Error Count: 0 Account:
Mount Count: 0 Job Name:
State: UNINITIALIZED Magazine:
Avail State: UNINITIALIZED Jukebox: TL826_JUKE
Previous Vol: Slot: 0
Next Vol: Drive:
Format: NONE Offsite Loc: ANDYS_STORAGE
Protection: S:RW,O:RW,G:RW,W Offsite Date: NONE
Purchase: 1-FEB-1999 08:19:00 Onsite Loc: BLD1_COMPUTER_ROOM
Creation: 1-FEB-1999 08:19:00 Space:
Init: 1-FEB-1999 08:19:00 Onsite Date: NONE
Allocation: NONE Brand:
Scratch: NONE Last Cleaned: 1-FEB-1999 08:19:00
Deallocation: NONE Times Cleaned: 0
Trans Time: 14 00:00:00 Rec Length: 0
Freed: NONE Block Factor: 0
Last Access: NONE
$ !
$ ! create 56 volumes for HSM
$ !
$ MDMS CREATE VOLUME -
/DESCRIPTION="Volumes for HSM" -
/JUKEBOX=TL826_JUKE -
/POOL=HSM -
/SLOTS=(120-175) -
/VISION
$ MDMS SHOW VOL BEB120
Volume: BEB120
Description: Volumes for HSM
Placement: ONSITE BLD1_COMPUTER_ROOM
Media Types: TK88K Username:
Pool: HSM Owner UIC: NONE
Error Count: 0 Account:
Mount Count: 0 Job Name:
State: UNINITIALIZED Magazine:
Avail State: UNINITIALIZED Jukebox: TL826_JUKE
Previous Vol: Slot: 120
Next Vol: Drive:
Format: NONE Offsite Loc: ANDYS_STORAGE
Protection: S:RW,O:RW,G:RW,W Offsite Date: NONE
Purchase: 1-FEB-1999 08:22:16 Onsite Loc: BLD1_COMPUTER_ROOM
Creation: 1-FEB-1999 08:22:16 Space:
Init: 1-FEB-1999 08:22:16 Onsite Date: NONE
Allocation: NONE Brand:
Scratch: NONE Last Cleaned: 1-FEB-1999 08:22:16
Deallocation: NONE Times Cleaned: 0
Trans Time: 14 00:00:00 Rec Length: 0
Freed: NONE Block Factor: 0
Last Access: NONE
$ !
$ ! initialize all of the volumes
$ !
$ MDMS INITIALIZE VOLUME -
/JUKEBOX=TL826_JUKE -
/SLOTS=(0-175)
$ MDMS SHOW VOL BEB000
Volume: BEB000
Description: Volumes for ABS
Placement: ONSITE BLD1_COMPUTER_ROOM
Media Types: TK88K Username:
Pool: ABS Owner UIC: NONE
Error Count: 0 Account:
Mount Count: 0 Job Name:
State: FREE Magazine:
Avail State: FREE Jukebox: TL826_JUKE
Previous Vol: Slot: 0
Next Vol: Drive:
Format: NONE Offsite Loc: ANDYS_STORAGE
Protection: S:RW,O:RW,G:RW,W Offsite Date: NONE
Purchase: 1-FEB-1999 08:19:00 Onsite Loc: BLD1_COMPUTER_ROOM
Creation: 1-FEB-1999 08:19:00 Space:
Init: 1-FEB-1999 08:19:00 Onsite Date: NONE
Allocation: NONE Brand:
Scratch: NONE Last Cleaned: 1-FEB-1999 08:19:00
Deallocation: NONE Times Cleaned: 0
Trans Time: 14 00:00:00 Rec Length: 0
Freed: NONE Block Factor: 0
Last Access: NONE