HP Archive Backup System for OpenVMS Guide to Operations

Migrating from SLS/MDMS V2.X to ABS/MDMS V4.X
B.2 SLS/MDMS V2.x to ABS/MDMS V4.x Migration
B.2.3.4
MDMS Domain
In addition, a Guru right is enabled that allows any command to be executed. The OpenVMS
privilege SYSPRV can optionally be used instead of the Guru right. This mechanism replaces the
six SLS/MDMS V2 rights defined in the TAPESTART.COM and the OPER privilege.
See HP ABS/HSM Command Reference Guide, Chapter 3, MDMS Rights and Privileges for a
complete description of the rights.
B.2.3.5
Drives
There was no real concept of a domain in SLS/MDMS V2. The scope of operations within SLS
varied according to what was being considered.
For example, attributes defined in TAPESTART.COM were applicable to all nodes using that
version of the file, normally from one node to a cluster. By contrast, volumes, magazines and
pools had scope across clusters and were administered by a single database process running elsewhere
in the environment.
MDMS V3 formally defines a domain object. The domain object contains default attribute values
that can be applied to any object where they are not specifically defined. MDMS V3 formally
supports a single domain, which inturn supports a single database. All objects like the
jukeboxes, drives, volumes, nodes, magazines are defined within the domain.
This method of defining objects introduces a level of incompatibility with the previous versions,
especially with respect to the parameters stored in TAPESTART.COM. Since TAPE-
START.COM can potentially be different on every node, default parameters like MAXS-
CRATCH can have different values on every node. With MDMS V3, the approach is towards
defining default attribute values at the domain level, but also allowing you to override some of
these at a specific object level (example - OPCOM classes for nodes). In other cases, values such
at LOC and VAULT defined in TAPESTART.COM are now separate objects.
After installing MDMS V3, you have to convert each TAPESTART.COM available in your
domain. If the TAPESTART.COM files on every node are compatible (not necessarily identical,
but not conflicting either), then the SLS/MDMS V2 to ABS/MDMS V3 conversion will be automatic.
However, if there are conflicts, then they are flagged in a separate conversion log file, and
need to be manually resolved.
Example: Assuming there are two drives named “$1$MUA500” on different nodes, then one or
both need to be renamed for use in the new MDMS environment.
It is possible to support multiple domains with MDMS V3, but ensure that objects defined are
local to their domain. Each domain has its own database and is independent of other domains
and their respective databases.
Example: Your company might have two autonomous groups with their own computer
resources, labs and personnel. It is reasonable for each group to operate within the boundaries of
their domain and also realize that nodes, jukeboxes, and volumes cannot be shared among the
two groups. If there is a need to share certain resources (example - the jukebox), it is possible to
utilize a single domain and separate certain resources by specifying unique attributes.
The drive object in MDMS V3 is similar in concept to a drive object in MDMS V2. However,
the naming convention for drives in MDMS V3 is different from MDMS V2. In MDMS V2,
drives were named after the OpenVMS device name, optionally qualified by a node.
In MDMS V3, drives are named like most other objects; their name must be unique within the
domain and can comprise a maximum of 31characters. So, you can specify a drive as DRIVE_1
rather than “$1$MUA510” and specify the OpenVMS device name using the DEVICE_NAME
attribute.
Migrating from SLS/MDMS V2.X to ABS/MDMS V4.X B–11