I wonder if I can get an initial report from my 3494 library and then use the VOLUMES table for TIMES_MOUNTED and the SUMMARY table for LAST_USE to at least get a close guess. Then just do an incremental report from then on. I also like the ksh idea of grabbing actlog entries. I just wish I could count writes and reads definitively. The main reason I'm doing this is that we're hearing here that there is a safety lifespan of tape media and it depends not only on the number of mounts but it's weighted (apparently, I'm still a little skeptical myself) towards writing. So after, say, 200 writes to the tape, it should be scrapped and and replaced with a shiny new one. But if it's primarily a read only tape, then it could stay in rotation for 700 reads. (The names and numbers are made up to protect my ignorance!)
Regards, Thomas Walker 212-408-8311 Unix Admin/TSM Admin EMI Recorded Music, NA -----Original Message----- From: Bill Boyer [mailto:[EMAIL PROTECTED]] Sent: Friday, September 20, 2002 2:29 PM To: [EMAIL PROTECTED] Subject: Re: SQL to find # of mounts for tapes? Depending on your TSM level, you can get this information from the SUMMARY table. The column ACTIVITY will be "TAPE MOUNT" and there are columes for VOLUME_NAME, DRIVE_NAME, LIBRARY_NAME and LAST_USE. It won't tell you whether it was mounted for input or output, but the LAST_USE field could give you some hints: DbBackup - I would assume OUTPUT Backupset - I would also assume OUTPUT Data - ???? couldn't tell. The END_TIME minus START_TIME will give you an elapsed time of how long the tape was mounted. This is one of my dream-graphs...to show each drive and it's total useage over a 24-hour period. the TSMManager package produces this graph. Plus you'll only be able to get these stats for however long your SUMMARYRETENTION options is set for. If you're an OS/390 user, don't bother... That information isn't kept in the summary table. Bill Boyer DSS, Inc. -----Original Message----- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED]]On Behalf Of Mahesh Tailor Sent: Friday, September 20, 2002 2:11 PM To: [EMAIL PROTECTED] Subject: Re: SQL to find # of mounts for tapes? Here's what I do from a ksh script . . . /usr/bin/dsmadmc -id=myuid -pass=mypasswd q actlog msgno=8337 begint=00:00 begind=-1 endd=-1 endt=23:59 | \ /usr/bin/grep -c ANR8337 This gives me a count of the number of tape mounts yesterday. I execute this script, log the output to a file, and then generate a graph using gnuplot to show the drive mounts over time. Mahesh >>> [EMAIL PROTECTED] 09/20/02 01:36PM >>> The VOLUMES table has the information so long as the tape does not go scratch. Once it scratches it and reenters the counters are all reset. Do this Select to see what is there. The accounting log may have information that is permanently kept, but you will have to write your own code to process it. SELECT * from volumes where volume_name='vvvvvv' Paul D. Seay, Jr. Technical Specialist Naptheon Inc. 757-688-8180 -----Original Message----- From: Walker, Thomas [mailto:[EMAIL PROTECTED]] Sent: Friday, September 20, 2002 12:31 PM To: [EMAIL PROTECTED] Subject: SQL to find # of mounts for tapes? Hi there, I need the gurus help on this. I know my 3494 library keeps track of how many mounts each 3590 tape endures, but I was wondering if there was a way through tsm to find that out as well, most likely I assume through TSM/SQL. I'm looking for: Number of mounts for each tape Number of writing sessions to each tape (ie a backup or archive session, or reclamation write) Number of reading sessions from each tape (ie a restore session or a reclamation read) Any help would be greatly appreciated! I'm currently running Server Version 4.1.5 on AIX 4.3.3 however I will soon be migrating to 5.1.x Thanks in advance, Thomas Walker 212-408-8311 Unix Admin/TSM Admin EMI Recorded Music, NA This e-mail including any attachments is confidential and may be legally privileged. If you have received it in error please advise the sender immediately by return email and then delete it from your system. The unauthorized use, distribution, copying or alteration of this email is strictly forbidden. This email is from a unit or subsidiary of EMI Recorded Music, North America