Hacked Script

[hpuxrox]

Howdy HPUX Gurus,

I have a very bad way to find out were a tape is located within my Surestore E tape lib.

It currently consistes of three scripts and a few files. I was wondering, Is there a better way to do this without all the mess. Maybe just all in one script. My scripts are as follows,

uma script
-------------------
#! /bin/sh
/opt/omni/lbin/uma -ioctl /dev/rac/tl1robot -barcode -device /dev/rmt/tl1d0 /dev
/rmt/tl1d1 /dev/rmt/tl1d2 /dev/rmt/tl1d3 /dev/rmt/tl1d4 /dev/rmt/tl1d5 /dev/rmt/
tl1d6 /dev/rmt/tl1d7

collect script
-----------------
#! /bin/sh
/opt/omniback/lbin/runuma < ./commands > drive_slots

commands file
---------------
stat d
stat x
stat s

Then I just grep the tape ID from the drive_slots file to find what slot or drive my tape is in.

[Duncan Edmonstone]

For the purposes of determining tape locations you don't need to tell uma about all your tape drives, so you could try something like this:

/opt/omni/lbin/uma -ioctl /dev/rac/tl1robot -barcode << EOF
stat d
stat x
stat s
EOF


or you could just use mc:

mc -p /dev/rac/tl1robot -r IDSM
HTH

Duncan

[A. Clay Stephenson]

Since you are using uma, you must be an OB2 user. A much easier method is simply
omnimm -repository "Library_Name". You can then pipe this output to awk or Perl to get whatever format you like. You don't have to worry about device paths since this is part of the OB2 device database. Moreover, OB2 commands are much safer than uma because there is no chance of confusing OB2's database.

[hpuxrox]

Thanks,

But the main ression I check with uma is because OB2 was reporting that a drive is somewhere that it is really not. So, I must use uma to find the real location.

Pleace

[A. Clay Stephenson]

In that case, use:
omnimm -repository_barcode_scan "Library_Name"

This will return the data AND fix the database - something that you would need to do in any case.

[hpuxrox]

Thanks,

So what would happen if it turns out that a tape in a drive? Will OB2 try to eject that tape to the correct slot?

[A. Clay Stephenson · Accepted solution]

No, barcode scan will simply try to read those barcode labels which are in the slots and update the database. Media which is in a drive will show up as 'Empty'. If you have media hung in drives then things are more complicated. Now you have to use uma but you must also list the drives in correct order as well. The problem is that often the drives are not all connected to the same host and they must be connected to the same host that uma is running on in order to use the 'offl' command. If you must use the 'offl' command prior to running 'move' and the drive and robitics are on different hosts then your only real option is to manually move the media within the library. You must then still run the barcode scan to 'sync up' the OB2 media database.

In my case, I outbushwhack this by making sure that each drive is physically connected to two hosts. I then have two OB2 logical drives and one physical drive. I can then use uma on the cell server to offl any hung drives. In the SCSI world it's done like this:

HostA SCSI ID7 ------ Drive SCSI ID 1 ------ HostB SCSI ID6. The terminators are enabled on both controllers. The two OB2 logical drives should share a common lock name to prevent simultaneous use.

[hpuxrox]

Thanks guys,

I have one last question for 10 points

Can these commands affect anything by running them?
Ie. Cause a backup to fail or something

mc -p /dev/rac/tl1robot -r IDSM
omnimm -repository "Library_Name???
omnimm -repository_barcode_scan "Library_Name"

[A. Clay Stephenson]

As long as your are using the mc command for inquiry only (which your above example does) then it is quite safe. The omnimm commands will always be safe; in the worst case the OB2 commands will block or simply timeout until it is safe to execute. This is true of all the OB2 commands.

The real answer to your problem is to find out why tapes are being left in drives. This occasionally happens in a busy backup environment but these occurences should be very infrequent (on the order of 1 every few weeks - mechanical systems sometimes fail) but should in no way be happening on a routine basis. If you fix this problem then everything becomes moot. You need to address the real problems rather than the symptoms.

[hpuxrox]

Thank Clay,

We don???t have tapes stuck in our drives very often. I realize that thing are mechanical and I should expect it to happened from time to time. (We do have a very busy backup environment). So, I???m just trying to get my thoughts together and find the best way to resolve the issue when it does happen.

Any other pointers feel free to post.

-Yates