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@;JHUAPL.EDU] Sent: Friday, October 25, 2002 2:04 PM To: [EMAIL PROTECTED] 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 [EMAIL PROTECTED] "Intelligence has much less practical application than you'd think" - Scott Adams/Dilbert ************************************************************************ -----Original Message----- From: Matt Simpson [mailto:msimpson@;UKY.EDU] Sent: Friday, October 25, 2002 11:17 AM To: [EMAIL PROTECTED] 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@;uky.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.