This could also occur when you checkin a scratch tape, without setting the status to scratch. However, as I remember it, you only have to update the library volume using upd libvol "library_name" "volume_name" status='scratch' to have the tape back to the scratch pool.
Best Regards Daniel Sparrman ----------------------------------- Daniel Sparrman Exist i Stockholm AB Propellervägen 6B 183 62 HÄGERNÄS Växel: 08 - 754 98 00 Mobil: 070 - 399 27 51 "Cook, Dwight E" <[EMAIL PROTECTED]> Sent by: "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]> 2002-08-27 13:30 Please respond to "ADSM: Dist Stor Manager" To: [EMAIL PROTECTED] cc: Subject: Re: baffling tape, 3584 HW compression, and stgpool design Tapes like this generally become this way due to some error such as not being able to read the volume's internal label when mounted to fill a scratch request. There is some TSM message that is along the lines of "... making volume private to prevent further access..." Now this doesn't mean the volume is ~bad~, might have been a drive problem. Check the tape out, check it back in with a "checklabel=yes", if it can't read the label, attempt to relabel it, if that fails, toss the tape... Dwight E. Cook Software Application Engineer III Science Applications International Corporation 509 S. Boston Ave. Suite 220 Tulsa, Oklahoma 74103-4606 Office (918) 732-7109 -----Original Message----- From: Dan Foster [mailto:[EMAIL PROTECTED]] Sent: Tuesday, August 27, 2002 3:34 AM To: [EMAIL PROTECTED] Subject: baffling tape, 3584 HW compression, and stgpool design Couple unrelated questions: 1. When I query a 3570 library, there's one tape that baffles me: adsm> q libvol 3570lib1 Library Name Volume Name Status Last Use Home Element ------------ ----------- ----------------- --------- ------------ 3570LIB1 133060 Private 34 I can't do anything with it -- ie, I can't discard the data on it because ADSM says it doesn't belong to a storage pool, and yet, no indication that it's a DbBackup. All other tapes in the library are sane and belongs to either scratch, a storage pool, or a dbbackup. So what could it be, and how do I wipe that lone offending tape and change its status to scratch? (This is with ADSM 3.1+patches) 2. How do I enable hardware compression for LTO tapes? Some sort of device class or drive definition parameter? (This is with TSM 4.2.2+patches) I've looked through docs set and not finding anything that addresses this. I'm currently using: tsm> DEFINE DEVCLASS 3584_DEVCLASS1 DEVTYPE=LTO FORMAT=DRIVE- MOUNTLIMIT=10 MOUNTWAIT=60 MOUNTRETENTION=0 LIBRARY=3584LIB1 tsm> DEFINE DEVCLASS 3584_DEVCLASS2 DEVTYPE=LTO FORMAT=DRIVE- MOUNTLIMIT=2 MOUNTWAIT=60 MOUNTRETENTION=0 LIBRARY=3584LIB1 The mountlimit of 10 and 2 is to put an hard upper bound on number of drives that the backups (10) and offsite copying (2) can use. The mountwait of 60 minutes is to avoid having jobs fail if they're sitting there, waiting for a particularly huge 300GB job to finish and free up a drive for it to use. Mountretention=0 is because this is a fast automated library (3584 with 12 drives); I can see setting it to 10 or so if it was a smaller human operated library or requiring operator tape swaps like the 3570 library. 3584LIB1 refers to the library, obviously. ;) (device /dev/smc0, etc) As I understand it, FORMAT=DRIVE means it uses the drive's compression settings. I haven't seen any explicit mention of what this defaults to nor how to adjust it in either the 3584 or TSM docs. Or would I use something like DEVTYPE=LTOC...? 3. Is there really a reason to use multiple storage pools for the same tape repository? Ie: the TSM 4.2 docs suggests an out-of-box default setup such as DISKDIRS, DISKDATA that then migrates to TAPEDATA, which then copies to OFFDIRS and OFFDATA (offsite copy pool tapes). This makes sense. (I understand the purpose for each and every one of them, and how they're organized.) Is there a good reason why someone might want to split up diskdata and tapedata into multiple stgpools? I ask because I've heard references to other folks having multiple stgpools, and wondering what I'm missing here. That's the only thing I think that eludes my understanding in preparing the new design, at this point. Any insight or comments much appreciated. Thanks! -Dan