Bob,
Yes - your way seems to make the whole process very easy - thanks for
taking the time to document and send it out.
I really feel it necessary to once again thank all of the participants
on this list. Sometimes I feel guilty about not having responded to a
posted question in a timely manner (when I may have been able to help). I
receive the messages in the digested version, once per day, and sometimes
there are days that go by before I can get a chance to go back and take a
look. Anyway - enough confession - just want to say that I've gotten so
much more detailed and very valuable assistance on ADSM from this group
than I will probably ever see from the vendor, and I really appreciate it!
Have a great weekend!
Ginny
---------------------- Forwarded by Virginia L Hysock/HI/CSC on 06/04/99
08:16 AM ---------------------------
08:16 AM ---------------------------
(Embedded image moved to file: PIC12914.PCX)
Virginia L Hysock/HI/CSC
06/04/99 08:15 AM
To: Virginia L Hysock/GIS/CSC@CSC
cc:
Subject: DRM on AIX
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.
|
