Autoload for Tape Library

[Bob Niepostyn]

How could you set up a Tape Library (TL) to auto-load next tape from a TL slot when VMS BACKUP requests the next tape?

Background.
Tape Library is a Falconstor Virtual Tape Library (VTL) and it could be an emulation of a few different types TLS, e.g. MSL, EML, ESL. This emulation of does not exist at the moment and I have to decide which one.
We are specifying a new system (3-node, multi-site cluster based on Integrity servers) that is going to use VTL in question for backups. At the moment I want to use our current Alphaserver DS20E for a Proof of Concept (PoC). My challenge is enhanced even more due to some other limitations (not enough HBAs on the current system): I can connect VTL for PoC only for one weekend.
At this stage I want to use MRU to control movement of tapes (later on I might use ABS, but it seams to be an overkill at the moment). So my pseudo command procedure looks like this:
1. MRU commands move all needed tapes to appropriate slots of VTL.
2. MRU load first tape to tape drive.
2. VMS BACKUP command

Once BACKUP command starts it will not give back control to my command procedure when it wants the next tape hence questions:
Q.1: What slots the set of tapes should be in? Subsequent? E.g. 4, 5 and 6.
Q.2: What do I need to set on VTL (say MSL8096)?

My background:
I have been VMS-ing to last 30 years and have written plenty of backup command procedures. I have used VLT TZ890 (I think) in the past and it had auto-load facility, but I do not have any experience with modern TLs and my time is very limited.

I would appreciate any help.
Bob.

[P Muralidhar Kini]

Hi Bob,

If you are using a tape loader which has the ability to automatically load volumes, then BACKUP can automatically select the volume in the next slot to continue its operation.
*11.11 Understanding Multivolume BACKUP Operations
http://h71000.www7.hp.com/doc/73final/6017/6017pro_046.html

You can also use the "/EXACT_ORDER" BACKUP qualifier in case you want to specify the exact order in which tape volumes should be selected by BACKUP.
*http://h71000.www7.hp.com/doc/83final/6048/6048pro_022.html#startsubcommand_122

Hope this helps.

Regards,
Murali

[Bob Niepostyn]

Murali,

Thank you for your comment.

My question is more about ability of Tape Library to handle tapes on multi-volume request from VMS BACKUP.

Is it from the next slot?
Can it recognise VMS tape labels and select it from any slot?

Regards, Bob.

[Shriniketan Bhagwat]

Hi,

As Murali said above, you can use /LABEL and /EXACT_ORDER qualifiers. Before to the BACKUP operation you can arrange the tapes in the appropriate next slots in the library so that the BACKUP takes them as it spans over to the next tape. This is how I have test few years back.

Regards,
Ketan

[P Muralidhar Kini]

Hi Bob,

>> Is it from the next slot?
I think this is the default behavior for tape loader. However this may not work for a tape library.

>> Can it recognise VMS tape labels and select it from any slot?
Yes, this can be done by using the "/LABEL" & "/EXACT_ORDER" BACKUP qualifiers. In your case, as you are using a Tape Library, you can use this method to ensure that BACKUP selects the desired tapes for the multi tape backup.

For your BACKUP's, first you need to decide which all tapes you want to use. These tapes can be present in any slots (need not be one after another). Then specify the label of these tapes in the "/LABEL" qualifier in the same order as what you it to be used. Also include the "/EXACT_ORDER" qualifer in your BACKUP command.

Regards,
Murali

[Bob Blunt]

Bob, there are *loaders* and *libraries* and standalone tape drives. While you can control *some* functions of a loader their flexibility is not as great as a "real" library. Real libraries have nifty features like special tape labels that identify tapes and types by bar coded information and these units *usually* spend some of their initial start-up processing sorting out what tapes go where in which slots, what type tape they are, how many of them, etc. Those units are expected to operate with the full suite of robotic commands and usually have specialized software that works with the in-library catalog and on-host robotic commands to get things setup properly.

Loaders are, generally, usually built with a much more limited magazine into which tapes are loaded. The drive is, usually, setup to sequentially load the next tape in the magazine so when an application like OpenVMS BACKUP completes writing tape A it rewinds, automatically unloads, the loader carriage grabs it and returns it to the slot from which it came, increments position of the magazine (or carriage), grabs tape A+1 and feeds it into a tape drive. Loaders, in general, don't have as many clues about what tape comes next but a properly configured BACKUP command can cause tapes to be rejected outright and skipped or request input from the operator (MGAx tape has the wrong label, overwrite, stop, etc?).

I'd start by checking with FalconStor's vendor to see exactly how their emulation will work and how it can be setup. Unless you've got the original tape drives they emulate in hand to test all of this is conjecture unless they can commit to you what to expect. If they're super excited to sell into the OpenVMS market and you're the "test case" maybe you could parlay that into a beta test with your gear in your shop. As far as insufficient HBAs in your DS20? If you're just trying to establish PoC for this setup you should be able to either test using a SCSI loader/library or "get by" by using just one path to your tape if you must test using a SAN/fabric. The general operation of a MSL, EML or ESL should be "close enough" for your proof regardless if the drive is controlled through fibre (SAN) or copper (SCSI).

bob

[Hoff]

Both tape magazine loaders and tape libraries are normally capable of operating in a sequential-access mode, and it's also usually the default mode.

The first load (without any further cartridge addressing or target media characterizations) gets the first previously-unread medium available in the magazine or library, and loads it.

Where the first tape is unloaded (dismounted) and a subsequent mount (load) request arrives, the tape drive (or the emulation) advances to and automatically selects the next cartridge in the magazine or in the library (or emulation).

I don't know off-hand if all SCSI tape devices have this behavior or if it's in the standards, but most do handle this.

And yes, it's far less practical in a library than in a loader. (I'd expect that some libraries can be programmed with a virtual magazine sequence for this case, too.)

If you (also) want to specifically emulate a library, then aim for one with MRU support (and test with MRU), as that's what many OpenVMS sites use to manage the robot.