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
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
- Page 166 and 167: System Backup to Tape for Oracle Da
- Page 168 and 169: System Backup to Tape for Oracle Da
- Page 170 and 171: System Backup to Tape for Oracle Da
- Page 172 and 173: System Backup to Tape for Oracle Da
- Page 174 and 175: Virtual Library System (VLS) 10.3 Q
- Page 176 and 177: Architecture 11.1 The Server Proces
- Page 178 and 179: Architecture 11.2 Scheduler Interfa
- Page 180 and 181: Architecture 11.3 Catalogs Example
- Page 182 and 183: Architecture 11.4 Coordinator 11.4.
- Page 184 and 185: Troubleshooting 12.2 Media Manageme
- Page 186 and 187: Troubleshooting 12.2 Media Manageme
- Page 188 and 189: Troubleshooting 12.4 ABS Catalogs 1
- Page 190 and 191: Troubleshooting 12.5 Windows and Un
- Page 192 and 193: Troubleshooting 12.6 RDF (Remote De
- Page 195 and 196: A Configuration Example Getting ABS
- Page 197 and 198: Configuration Example * Magazine -
- Page 199 and 200: Configuration Example Configuring s
- Page 201 and 202: Configuration Example If you comple
- Page 203 and 204: Configuration Example Assist: YES C
- Page 205 and 206: B Migrating from SLS/MDMS V2.X to A
- Page 207 and 208: Migrating from SLS/MDMS V2.X to ABS
- Page 209 and 210: Table B-1 SBK Symbols in ABS Termin
- Page 211 and 212: Migrating from SLS/MDMS V2.X to ABS
- Page 213 and 214: Migrating from SLS/MDMS V2.X to ABS
- Page 215: Migrating from SLS/MDMS V2.X to ABS
- Page 219 and 220: Migrating from SLS/MDMS V2.X to ABS
- Page 221 and 222: Migrating from SLS/MDMS V2.X to ABS
- Page 223 and 224: Migrating from SLS/MDMS V2.X to ABS
- Page 225 and 226: Migrating from SLS/MDMS V2.X to ABS
- Page 227 and 228: Migrating from SLS/MDMS V2.X to ABS
- Page 229 and 230: Migrating from SLS/MDMS V2.X to ABS
- Page 231 and 232: Migrating from SLS/MDMS V2.X to ABS
- Page 233 and 234: Migrating from SLS/MDMS V2.X to ABS
- Page 235 and 236: Migrating from SLS/MDMS V2.X to ABS
- Page 237 and 238: Migrating from SLS/MDMS V2.X to ABS
- Page 239 and 240: Migrating from SLS/MDMS V2.X to ABS
- Page 241 and 242: Migrating from SLS/MDMS V2.X to ABS
- Page 243 and 244: $ WRITE EpilogComFile - Migrating f
- Page 245 and 246: Table B-6 Execution Environment Par
- Page 247 and 248: • SAVE Migrating from SLS/MDMS V2
- Page 249 and 250: Migrating from SLS/MDMS V2.X to ABS
- Page 251 and 252: Migrating from SLS/MDMS V2.X to ABS
- Page 253 and 254: Migrating from SLS/MDMS V2.X to ABS
- Page 255 and 256: Solution - Follow these steps: Migr
- Page 257 and 258: C Prev3 Support Prev3 Support is pr
- Page 259 and 260: Prev3 Support C.2 Using SLS as the
- Page 261: Prev3 Support C.2 Using SLS as the
- Page 264 and 265: Upgrading from ABS V2.X/V3.X to V4.
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