True, use of 'vmoprcmd -d ds' (I use 'ds' because you dont need the 
extended infor) and robtest is the easiest way to get this info.  Might as 
well let the 'avrd' process tell you which drive it is in.  In my case, I 
tend to run the 'vmoprcmd' command in a loop in one window while I use 
'robtest' in another.  The loop is fairly simple (Bourne/Korn shell):

        while true ; do clear; date ; vmoprcmd -d ds ; sleep 10 ; done

One other thing to keep in mind when dealing with a SAN is to make sure 
you persistently bind you're targets unless you can be ABSOLUTELY sure 
they will not move.  If your library is, say, a StorageTek L-700 with 9840 
or LTO drivers (drives that man be native fibre  [i.e. they can attach 
directly to a fibre switch without the need for a SCSI-Fibre bridge]) and 
the server accesses the drives via a switch which the tape drives are 
directly attached to, if you let the server assign the SCSI targets at 
boot time, you could end up with drives "moving" (i.e. getting assigned 
different SCSI targets) on each boot.  There is no guarantee that a drive 
will get the same SCSI target on each boot and in most (if not all) cases 
the server OS has configured itself [or a system admin has configured it] 
to map a particular tape device (by 'tape device' I mean something like 
'/dev/rmt/0') to a particular SCSI target.   If the SCSI targets get 
reassigned, so do the tape drives.   Persistent binding assigns the tape 
drive to the same SCSI target on each reboot so it won't move.

-- Tony Guzzi
Sr. Solutions Engineer, AssuredRestore team
Storability, Inc.



From: "Cornely, David" <David_Cornely AT intuit DOT com>
To: "'Prasad Chalikonda'" <prasadchalikonda AT yahoo DOT com>,
        veritas-bu <veritas-bu AT mailman.eng.auburn DOT edu>
Subject: RE: [Veritas-bu] Ensuring drives are mapped correctly in a SAN en
                 v.
Date: Sun, 18 Nov 2001 07:08:25 -0800

Prasad,

This is one way of doing it.  I did have a problem once where mt just 
didn't
return any status so you can also do the following:

1) Use tpconfig to map your drives intitially (yes, it will be incorrect 
but
you'll fix it later)
2) load your tape in the drive with robtest, noting the robotic drive 
number
3) Use vmoprcmd -d to display the drives and it will show you what drive
index currently has the tape you just loaded.
4) Correlate this index to the initial drive mapping and you now know what
device file corresponds to what robotic drive.
5) Do this for all the drives and then reconfigure your drives properly 
with
tpconfig.

Hope this helps.

-Dave

-----Original Message-----
From: Prasad Chalikonda [mailto:prasadchalikonda AT yahoo DOT com]
Sent: Saturday, November 17, 2001 2:48 PM
To: veritas-bu
Subject: [Veritas-bu] Ensuring drives are mapped correctly in a SAN env.


Is there a recommended procedure to ensure drives in a Unix env. with 
SSO are mapped correctly?

Let's say my Library has 10 drives, and the device files on my Master go 
from 0cbn to 9cbn.
My strategy is:
1. Manually load a tape in to each drive in the Library.
2. From the server, do an   "mt   -f   /dev/rmt/0cbn offline", and note 
the drive# the tape is ejected from.
3. Let's say it was Drive 1 in the Library. Drives in the Library for 
NBU go from 1 on up, right? In NBU Drive Configuration, I make sure when 
I type the device file as "/dev/rmt/0cbn", the drive is "Drive 1".
4. Repeat step 2 for each drive and note down correspong the Drive # 
which ejects the tape.

Is this a good and sufficient test to ensure everything will work 
properly? Does anyone have a better way of doing this?

Thanks very much.
Prasad