I use the following procedures to move tapes to and from our offsite vault.
To move offsite, I use the following sequence:
1) "move drm * wherest=mountable tostate=notmountable"
2) "q drm * wherest=notmountable" (to get a report)
3) "move drm * wherest=notmountable tostate=vault"
I use the multi-step approach above as it is "self-recovering".  That is, if I
experience a failure at any point and tapes get "pinned" in the notmountable
state, then steps 2 and 3 of the next run clear everything up.
To return from the vault, I use this sequence:
1) "q drm * wherest=vaultretrieve" (to get a report)
2) "move drm * wherest=vaultretrieve tostate=onsiteretrieve"
3) Give the report to the courier and wait a day for the courier to return the
tapes
4) Insert any and all tapes returned by the courier into the ATL (IBM 3494).
5) "checkin libv 3590tape search=yes devtype=3590 status=scratch checklabel=no"
There is no time lag between steps 1 and 2, so the odds of a tape expiring
between the two steps is virtually zero.  That is to say, the report from step
1 should always be accurate.  There is a 1 (or more) day lag between steps 2
and 5, but ADSM doesn't care about that.  We don't use cmd= on the checkin
since the search=yes function takes only a couple of seconds on a 3494, and
we'd rather checkin only what the 3494 actually sees as being in insert-status
vs. a cmdfile which (for some reason) might not be 100% accurate.  Technically,
this has proved out to be a very good procedure for us.  Operationally, we
instruct our operators to verify all tapes against all reports coming and
going, and to immediately raise a red flag if there are any discrepancies.  I
hope our approach is of value to you.

Bob Brazner
Johnson Controls, Inc.