ADSM-L

Re: drm operator scripts

2002-10-25 16:01:10
Subject: Re: drm operator scripts
From: "Hoang, Michael D CONT (NETS)" <Michael.Hoang AT NETS.NEMAIS.NAVY DOT MIL>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Fri, 25 Oct 2002 15:59:20 -0400
Jim,

Can you please send me the script for the report?  My guys would love to
have it.

Thanks.

-Michael

-----Original Message-----
From: Jim Taylor [mailto:jtaylor AT ENLOGIX DOT COM]
Sent: Friday, October 25, 2002 3:33 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: drm operator scripts


I think order of operations is important here.

This is what I do for tape returns:

1. Tapes that are in 'vaultretrieve' state are requested back.
2. Those tapes are changed to 'courierretrieve' state.
3. Daily, and prior to our offsite run, we run a checkin with search = yes
and status = private.
4. During our daily offsite run, we do a query of the library to see if it
finds the tapes that were requested back.
5. If the tape is found in the library it is changed to 'onsiter' state. At
this time the tape becomes scratch and available.
   If the tape is not found in the library it remains on the list of tapes
to be returned from offsite and continues to hold the 'courierretrieve'
state.

I have this all built into a script that makes it real pretty and generates
nice reports and everything.  Here is a sample report:

   ______________________________________________________________________
  |
  |          {COMPANY NAME}   Daily Offsite Tape Movement Report
  |     ===============================================================
  |
  |                Time Stamp is 2002/10/25 @ 07:47
  |          This job was initiated by user known as {operator name}
  |
  | The following 6 tape(s) are to be sent offsite:
  |
  | C00214 C00251 C00259 C00272 C00368 C00016
  |
  |___________________________________________________________________
  | The following 1 tape(s) may now be returned from offsite:
  |
  | C00260
  |________________________________________________________________
  | The following 3 previously requested tape(s) have not been detected
  | in the library as returned.
  |
  | Volume     Date originally requested back
  | ======     ==============================
  | C00063     2002/10/23
  | C00071     2002/10/23
  | C00111     2002/09/13
  |
  | If there is any problems or discrepancies with todays offsite run
  | Please contact: {system admin name}
  |         Phone: {phone number}
  |          Cell: {fax number}
  |
  |       This report printed to {printer id} at the {data center name}
  |_______________________________________________________________________

We have been running this script daily for over a year with monthly tape
audits and have not lost track of a single tape, to date.

I hope this helps.
Also, if anyone sees a problem with this process I sure would like to know
before I do get bit.

Thanks JT

-----Original Message-----
From: Prather, Wanda [mailto:Wanda.Prather AT JHUAPL DOT EDU]
Sent: Friday, October 25, 2002 2:04 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: drm operator scripts


I have worked on this problem a LOT, and as far as I know there is nothing
in TSM, DRM, or Autovault that deals with the situation you describe,

We also do a lot of tape movement due to vaulting, and there is inevitably a
case where someone bring back tape ABC221 instead of ABC211, etc.

The opposite problem can also occur :  If a PHYSICAL eject fails for a tape
going to the vault, and the operator responsible doesn't notice that he/she
has only 10 tapes to take to the vault instead of 11, you have a tape that
is checked out as far as TSM knows, but is still left in the robot when it
should be in the vault.

And the bigger your TSM server, the more tapes you move, and the more of
these errors you get.

If it isn't a really common problem, the cheapest/simplest way to resolve it
is to have an ops do a MANUAL AUDIT of your vault periodically - say once a
quarter.  It's easy to generate a list of everything that SHOULD be in the
vault for them to compare to, and note any discrepancies for you to track
down.

If it's a BIG problem, I have had to write my own RECONCILE scripts.
Depending on the TSM server host and the type of library and your scripting
preference, you can use TSM SELECTs and a combination of PERL or shell
scripts to generate and compare multiple lists:  All the tapes that SHOULD
BE IN THE VAULT ( a list of DBB tapes and COPYPOOL tapes, for example)
compared to all the tapes that SHOULD BE in the robot to all the tapes that
are CHECKED IN  compared to all the tapes that EXIST, and you can eventually
get a list of (1) tapes that should be in the vault but are in the robot,
and (2) tapes that aren't accounted for (and therefore are usually in the
vault but shouldn't be).  And while you're at it, check for tapes that are
checked in PRIVATE but should really be SCRATCH.

I've done this in several forms, and have never come up with scripts that
are generic enough to post.  There are too many variables depending on site
practices, what classes of tapes you vault, and the type of library (not to
mention my perl is pretty primitive!)

I guess the other thing you could do, would be to take the list of tapes in
VAULTRETRIEVE status, generate commands to check them in as PRIVATE , THEN
compare the list of LIBVOLS against the list still in VAULTRETRIEVE to make
sure they all got back.  THEN move them to ONSITE RETRIEVE.  But that will
require some pretty messy scripting, also.

Maybe the folks at Autovault or TSMMANager or Servergraph can come up with a
better solution!

************************************************************************
Wanda Prather
The Johns Hopkins Applied Physics Lab
443-778-8769
wanda_prather AT jhuapl DOT edu

"Intelligence has much less practical application than you'd think" -
Scott Adams/Dilbert
************************************************************************




-----Original Message-----
From: Matt Simpson [mailto:msimpson AT UKY DOT EDU]
Sent: Friday, October 25, 2002 11:17 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: drm operator scripts


At 9:37 AM -0500 10/25/02, Mark Stapleton wrote:
>         UPDATE STG <stgpool_name> REUSEDELAY=<number_of_days>
>
>Tape volumes in the storage pool will now go to PENDING status when they
are
>moved to ONSITERETRIEVE status. You won't be able to check them in as
>scratch tapes until the reusedelay period of time expires.

That's not exactly the problem I'm trying to solve. I want to check
them in as scratch tapes. I just don't want them to disappear out of
the database before that happens.

Example. We generate a list of all tapes in VAULTRETRIEVE status, and
give that to a human and tell him to bring all those tapes back from
the vault.  We move all the tapes on the list to ONSITERETRIEVE
status.  Human brings tapes back from the vault. We load them into
the bulk entry door and issue the CHECKIN command to check them in as
scratch.  All is OK if human retrieves all the right tapes.  But if
one doesn't get retrieved for some reason, there is no longer any
record that the tape exists and isn't where it belongs.  I'd like to
have it left in the database in some status, VAULTRETRIEVE or
COURIERRETRIEVE or anything that would indicate that it exists and
needs to be returned to the library.
--


Matt Simpson --  OS/390 Support
219 McVey Hall  -- (859) 257-2900 x300
University Of Kentucky, Lexington, KY 40506
<mailto:msimpson AT uky DOT edu>
mainframe --   An obsolete device still used by thousands of obsolete
companies serving billions of obsolete customers and making huge obsolete
profits for their obsolete shareholders.  And this year's run twice as fast
as last year's.

<Prev in Thread] Current Thread [Next in Thread>