HP Archive Backup System for OpenVMS Guide to Operations

HP Archive Backup System for OpenVMS Guide to Operations HP Archive Backup System for OpenVMS Guide to Operations

h71000.www7.hp.com
from h71000.www7.hp.com More from this publisher
06.11.2014 Views

Migrating from SLS/MDMS V2.X to ABS/MDMS V4.X B.2 SLS/MDMS V2.x to ABS/MDMS V4.x Migration It is also equally valid to name the drive after the OpenVMS device name as long as it is unique within the domain. Specify nodes for drives using the NODES or GROUPS attributes. You must specify all nodes or groups that have direct access to the drive. Note Do not specify a node or group name in the drive name or the OpenVMS device name. Consider two drives named “$1$MUA500”, one on cluster “BOSTON” and the other on cluster “HUSTON”, and you want to use a single MDMS domain. You can set up the drives as follows: $ MDMS CREATE DRIVE BOS_MUA500/DEVICE=$1$MUA500/GROUP=BOSTON $ MDMS CREATE DRIVE HUS_MUA500/DEVICE=$1$MUA500/GROUP=HUSTON B.2.3.6 Jukeboxes The new ACCESS attribute can limit use of the drive to be either local or remote access. Local access is defined as access by any of the nodes in the NODES attribute or any of the nodes defined in the group object (in the GROUP attributes). Remote access is defined as access from any other node. By default, both local and remote accesses are allowed. With MDMS V3, drives can be defined as being jukebox controlled, stacker controlled or standalone. • Jukebox Controlled: A drive is jukebox controlled when it resides in a jukebox, and you want random-access loads/unloads of any volume in the jukebox. Define a jukebox name, control mechanism (MRD or DCSC), and drive number for a MRD jukebox. The drive number is the number MRD uses to refer to the drive and starts from zero. • Stacker Controlled: A drive can be defined as a stacker when it resides in a jukebox and you want sequential loading of volumes, or if the drive supports a stacker loading system. In such cases, do not define a jukebox name but set the “STACKER” attribute. • Stand-alone: If the drive is stand-alone (loadable only by an operator), do not define a jukebox and also clear the “STACKER” attribute. Set the “AUTOMATIC_REPLY” attribute if you want Opcom requests on the drive to be completed without operator intervention. It enables a polling scheme that automatically cancels the request when the requested condition is satisfied. In MDMS V2, jukeboxes were differentiated as libraries, loaders and ACS devices, each with their own commands and functions. With MDMS V3, all automatic loading devices are grouped under the jukebox object. Jukeboxes can be controlled by one of the following two subsystems. They can also have unique names comprising a maximum of 31 characters: • MRD used for most of the SCSI jukeboxes including some StorageTek silos • DCSC used for most of the existing and older StorageTek silos The new “ACCESS” attribute can limit use of the jukebox to be either local or remote access. Local access is defined as access by any of the nodes in the “NODES” attribute or any of the nodes defined in the group object (in the GROUP attributes). Remote access is access from any other node. By default, both local and remote accesses are allowed. For MRD jukeboxes, the robot name is the name of the device that MRD accesses for jukebox control. It is equivalent to the device name that is listed first in the old TAPE_JUKEBOXES definition in the TAPESTART.COM (but without the node name). As with drives, nodes for the jukebox must be specified using the “NODES” or the “GROUPS” attributes. B–12 Migrating from SLS/MDMS V2.X to ABS/MDMS V4.X

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.7 Locations Jukeboxes now have a “LOCATION” attribute, which is used in Opcom messages related to moving volumes into and out of the jukebox. When moving volumes into a jukebox and if they are not already available in that particular location, you will first be prompted to move them to the jukebox location and then to the actual location. Likewise, when moving volumes out of the jukebox, they will first be moved to the jukebox location and then to the actual location. The reason being that it is more efficient to move all the volumes from their source (wherever they are) to the jukebox location and then move all the volumes to the final destination. One of the most important aspects of jukeboxes is whether you will be using the jukebox with/without magazines. As described in the Section B.2.3.9, “Magazines”, MDMS V3 treats magazines as a set of volumes within a physical magazine that share a common placement and move schedule. Unlike MDMS V2, it is not necessary to relate volumes to magazines just because they reside in a physical magazine, although you can. It is equally valid for volumes to be moved directly and individually in and out of jukeboxes regardless of whether/not they reside in a magazine within the jukebox. It is the preferred method when it is expected that the volumes will be moved independently in and out of the jukebox. If you decide to formally use magazines, you should set the jukebox usage to magazine. In addition, if the jukebox can potentially hold multiple magazines at once (example - TL820 style jukebox), you can optionally define a topology field that represents the physical topology of the jukebox (towers, faces, levels and slots). If you define a topology field, Opcom messages relating to magazines movement into and out of the jukebox will contain a magazine position in the jukebox, rather than a start slot for the magazine. Use of topology and position are optional, but they make it easier for operators to identify the appropriate magazine for movement. Importing and exporting volumes (or magazines) into and out of a jukebox is replaced by a common MOVE command, which specifies a destination parameter. The direction of movement is determined depending on whether the destination is a jukebox, a location or a magazine. Unlike previous versions, you can use a single command to move multiple volumes. The Opcom messages will contain all the volumes to be moved, which have a common source and destination location. If the jukebox supports ports or caps, all available ports and caps will be used. The movement is flexible, in the sense you can place volumes in the ports/caps in any order when importing, and all the ports will be used when exporting volumes. All port/cap oriented jukeboxes support automatic reply on Opcom messages. It means that the messages need not be acknowledged for the move to complete. The concept of locations have been greatly expanded from SLS/MDMS V2, where a copy of TAPESTART.COM had a single "ONSITE" location defined in the “LOC” symbol and a single "OFFSITE" location defined in the “VAULT” symbol. With MDMS V3, locations are now separate objects with the object names having a maximum of 31 characters. Locations can be arranged in a hierarchy allowing them to be grouped within other locations. For example, you can define “BOSTON_CAMPUS” as a location with “BUILDING_1” and “BUILDING_2” located in it and “ROOM_100” and “ROOM_200” located in “BUILDING_1”. Locations that have common roots are regarded as compatible locations and are used for allocating drives, and volumes. Example: When allocating a volume that is available in “ROOM_200” location , if you specify the location as “BUILDING_1”, then the two locations are considered compatible. However, if you had specified the location as “BUILDING_2”, then they would not be considered compatible as “ROOM_200” is located in “BUILDING_1”. Locations are not officially designated as “ONSITE” or “OFFSITE” as they can be both in some cases. However, each volume and magazine have onsite and offsite location attributes that must be set to valid location objects. Migrating from SLS/MDMS V2.X to ABS/MDMS V4.X B–13

Migrating from SLS/MDMS V2.X <strong>to</strong> ABS/MDMS V4.X<br />

B.2 SLS/MDMS V2.x <strong>to</strong> ABS/MDMS V4.x Migration<br />

It is also equally valid <strong>to</strong> name the drive after the <strong>OpenVMS</strong> device name as long as it is unique<br />

within the domain. Specify nodes <strong>for</strong> drives using the NODES or GROUPS attributes. You must<br />

specify all nodes or groups that have direct access <strong>to</strong> the drive.<br />

Note<br />

Do not specify a node or group name in the drive name or the <strong>OpenVMS</strong> device name.<br />

Consider two drives named “$1$MUA500”, one on cluster “BOSTON” and the other on cluster<br />

“HUSTON”, and you want <strong>to</strong> use a single MDMS domain. You can set up the drives as follows:<br />

$ MDMS CREATE DRIVE BOS_MUA500/DEVICE=$1$MUA500/GROUP=BOSTON<br />

$ MDMS CREATE DRIVE HUS_MUA500/DEVICE=$1$MUA500/GROUP=HUSTON<br />

B.2.3.6<br />

Jukeboxes<br />

The new ACCESS attribute can limit use of the drive <strong>to</strong> be either local or remote access. Local<br />

access is defined as access by any of the nodes in the NODES attribute or any of the nodes<br />

defined in the group object (in the GROUP attributes). Remote access is defined as access from<br />

any other node. By default, both local and remote accesses are allowed.<br />

With MDMS V3, drives can be defined as being jukebox controlled, stacker controlled or standalone.<br />

• Jukebox Controlled: A drive is jukebox controlled when it resides in a jukebox, and you<br />

want random-access loads/unloads of any volume in the jukebox. Define a jukebox name,<br />

control mechanism (MRD or DCSC), and drive number <strong>for</strong> a MRD jukebox. The drive<br />

number is the number MRD uses <strong>to</strong> refer <strong>to</strong> the drive and starts from zero.<br />

• Stacker Controlled: A drive can be defined as a stacker when it resides in a jukebox and you<br />

want sequential loading of volumes, or if the drive supports a stacker loading system. In<br />

such cases, do not define a jukebox name but set the “STACKER” attribute.<br />

• Stand-alone: If the drive is stand-alone (loadable only by an opera<strong>to</strong>r), do not define a jukebox<br />

and also clear the “STACKER” attribute.<br />

Set the “AUTOMATIC_REPLY” attribute if you want Opcom requests on the drive <strong>to</strong> be completed<br />

without opera<strong>to</strong>r intervention. It enables a polling scheme that au<strong>to</strong>matically cancels the<br />

request when the requested condition is satisfied.<br />

In MDMS V2, jukeboxes were differentiated as libraries, loaders and ACS devices, each with<br />

their own commands and functions. With MDMS V3, all au<strong>to</strong>matic loading devices are grouped<br />

under the jukebox object.<br />

Jukeboxes can be controlled by one of the following two subsystems. They can also have unique<br />

names comprising a maximum of 31 characters:<br />

• MRD used <strong>for</strong> most of the SCSI jukeboxes including some S<strong>to</strong>rageTek silos<br />

• DCSC used <strong>for</strong> most of the existing and older S<strong>to</strong>rageTek silos<br />

The new “ACCESS” attribute can limit use of the jukebox <strong>to</strong> be either local or remote access.<br />

Local access is defined as access by any of the nodes in the “NODES” attribute or any of the<br />

nodes defined in the group object (in the GROUP attributes). Remote access is access from any<br />

other node. By default, both local and remote accesses are allowed.<br />

For MRD jukeboxes, the robot name is the name of the device that MRD accesses <strong>for</strong> jukebox<br />

control. It is equivalent <strong>to</strong> the device name that is listed first in the old TAPE_JUKEBOXES definition<br />

in the TAPESTART.COM (but without the node name). As with drives, nodes <strong>for</strong> the<br />

jukebox must be specified using the “NODES” or the “GROUPS” attributes.<br />

B–12 Migrating from SLS/MDMS V2.X <strong>to</strong> ABS/MDMS V4.X

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!