Move drm for bringing back volumes creates a command file which is essentially
a macro containing the commands you would like to be executed on the return of
a volume.
Withihn this command is substituted the volume name.
For example, our return volumes script is as follows:
Dsmadmc -server=servername -id=opid -passsword=pwd <drmscript
Drmscript is:
MOVE DRM * WHEREST=VAULTR S=DBS TOST=ONSITER CMDF=/opt/tivoli/checkin.mac -
wait=yes CMD="checkin libv britanica &vol stat=scr checkl=no devt=3592
mountw=90"
macro /opt/tivoli/checkin.mac
Quit
If you have other questions, ask away.
Gary Lee
Senior System Programmer
Ball State University
phone: 765-285-1310
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Nick Laflamme
Sent: Sunday, July 18, 2010 6:31 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: [ADSM-L] MOVE DRM & CHECKIN LIBVOL
It's fairly well documented that MOVE DRMEDIA will execute CHECKOUT LIBVOLUME
under the covers to make "safe" any copypool volumes and DB backup volumes that
are allegedly on their way off-site.
Is it documented anywhere if MOVE DRM will execute CHECKIN LIBVOL commands?
At the root of my question is a discussion several of us are having at work.
We're painfully aware that in some TSM 5.5 and TSM 6.1 levels, there's a
deadlock related to DELETE VOLHISTORY fighting with LABEL LIBVOL. As we run
with our virtual tape libraries set for RELABELSCRATCH=YES, we sometimes see an
nearly spontaneous LABEL LIBVOL as volumes are released from storage pools or
are no longer needed as DB backups.
What's less agreed upon is whether we have to check in the returning volumes
before executing a MOVE DRM FROMST=VAULTR TOST=ONSITER to trigger the bug or
not. One colleague is adamant that MOVE DRM will find -- and relabel -- a
volume that's sitting in the VTL even if it doesn't show up in a QUERY LIBVOL
before we do the MOVE DRM. My own expectation is that if we do the MOVE DRM
command before the volumes are checked back in the library, the automatic
volume relabeling won't go on its own.
Because the price of failure is a TSM server hang, we're a bit leary about
playing with different permutations until we map out the various scenarios and
outcomes. But, if we can convince ourselves that in some cases, MOVE DRM
doesn't trigger an implicit LABEL LIBVOL if a library is set for
RELABELSCRATCH=YES, we could return to checking in our "off-site" volumes and
then, say, running manual LABEL LIBVOL OVERWRITE=YES to have the same effect.
So, does anyone know about safe or unsafe sequences of MOVE DRM with or without
CHECKIN LIBVOL when a library is set for RELABELSCRATCH=YES?
Thanks,
Nick
|
