06.11.2014 Views

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

SHOW MORE
SHOW LESS

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

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 />

B.2.3.7<br />

Locations<br />

Jukeboxes now have a “LOCATION” attribute, which is used in Opcom messages related <strong>to</strong><br />

moving volumes in<strong>to</strong> and out of the jukebox. When moving volumes in<strong>to</strong> a jukebox and if they<br />

are not already available in that particular location, you will first be prompted <strong>to</strong> move them <strong>to</strong><br />

the jukebox location and then <strong>to</strong> the actual location. Likewise, when moving volumes out of the<br />

jukebox, they will first be moved <strong>to</strong> the jukebox location and then <strong>to</strong> the actual location. The reason<br />

being that it is more efficient <strong>to</strong> move all the volumes from their source (wherever they are)<br />

<strong>to</strong> the jukebox location and then move all the volumes <strong>to</strong> the final destination.<br />

One of the most important aspects of jukeboxes is whether you will be using the jukebox<br />

with/without magazines. As described in the Section B.2.3.9, “Magazines”, MDMS V3 treats<br />

magazines as a set of volumes within a physical magazine that share a common placement and<br />

move schedule. Unlike MDMS V2, it is not necessary <strong>to</strong> relate volumes <strong>to</strong> magazines just<br />

because they reside in a physical magazine, although you can. It is equally valid <strong>for</strong> volumes <strong>to</strong><br />

be moved directly and individually in and out of jukeboxes regardless of whether/not they reside<br />

in a magazine within the jukebox. It is the preferred method when it is expected that the volumes<br />

will be moved independently in and out of the jukebox.<br />

If you decide <strong>to</strong> <strong>for</strong>mally use magazines, you should set the jukebox usage <strong>to</strong> magazine. In addition,<br />

if the jukebox can potentially hold multiple magazines at once (example - TL820 style<br />

jukebox), you can optionally define a <strong>to</strong>pology field that represents the physical <strong>to</strong>pology of the<br />

jukebox (<strong>to</strong>wers, faces, levels and slots). If you define a <strong>to</strong>pology field, Opcom messages relating<br />

<strong>to</strong> magazines movement in<strong>to</strong> and out of the jukebox will contain a magazine position in the<br />

jukebox, rather than a start slot <strong>for</strong> the magazine. Use of <strong>to</strong>pology and position are optional, but<br />

they make it easier <strong>for</strong> opera<strong>to</strong>rs <strong>to</strong> identify the appropriate magazine <strong>for</strong> movement.<br />

Importing and exporting volumes (or magazines) in<strong>to</strong> and out of a jukebox is replaced by a common<br />

MOVE command, which specifies a destination parameter. The direction of movement is<br />

determined depending on whether the destination is a jukebox, a location or a magazine. Unlike<br />

previous versions, you can use a single command <strong>to</strong> move multiple volumes. The Opcom messages<br />

will contain all the volumes <strong>to</strong> be moved, which have a common source and destination<br />

location. If the jukebox supports ports or caps, all available ports and caps will be used. The<br />

movement is flexible, in the sense you can place volumes in the ports/caps in any order when<br />

importing, and all the ports will be used when exporting volumes. All port/cap oriented jukeboxes<br />

support au<strong>to</strong>matic reply on Opcom messages. It means that the messages need not be<br />

acknowledged <strong>for</strong> the move <strong>to</strong> complete.<br />

The concept of locations have been greatly expanded from SLS/MDMS V2, where a copy of<br />

TAPESTART.COM had a single "ONSITE" location defined in the “LOC” symbol and a single<br />

"OFFSITE" location defined in the “VAULT” symbol.<br />

With MDMS V3, locations are now separate objects with the object names having a maximum<br />

of 31 characters. Locations can be arranged in a hierarchy allowing them <strong>to</strong> be grouped within<br />

other locations. For example, you can define “BOSTON_CAMPUS” as a location with<br />

“BUILDING_1” and “BUILDING_2” located in it and “ROOM_100” and “ROOM_200”<br />

located in “BUILDING_1”. Locations that have common roots are regarded as compatible locations<br />

and are used <strong>for</strong> allocating drives, and volumes.<br />

Example: When allocating a volume that is available in “ROOM_200” location , if you specify<br />

the location as “BUILDING_1”, then the two locations are considered compatible. However, if<br />

you had specified the location as “BUILDING_2”, then they would not be considered compatible<br />

as “ROOM_200” is located in “BUILDING_1”.<br />

Locations are not officially designated as “ONSITE” or “OFFSITE” as they can be both in some<br />

cases. However, each volume and magazine have onsite and offsite location attributes that must<br />

be set <strong>to</strong> valid location objects.<br />

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

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

Saved successfully!

Ooh no, something went wrong!