After I received this message, I started investigating my TSM server tape utilization.
I have to agree that I think this should be called a "bug" not WAD. I found 128 tapes in FILLING status when I only have 80-nodes (of which 15 go to a non-collocated pool). Since yesterday, I have been checking every tape in FILLING status, only to find dozens that are barely used (< 5%) and haven't been used in many months. I have started randomly picking these tapes and performing MOVE DATA on them, to the same stgpool. I have gone from 128 to 99 tape in FILLING status, this morning and am still checking/moving data ! I am not going to press this issue since my server is a little behind (z/OS 5.1.8.3) and will be updating to the latest, soon, hopefully finding something along the way that will adress this issue ! "Loon, E.J. van - SPLXM" <[EMAIL PROTECTED]> Sent by: "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]> 09/27/2004 10:23 AM Please respond to "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]> To [EMAIL PROTECTED] cc Subject Re: Weird tape utilization (the story continues...) About two weeks ago I asked on this list how TSM could have more than one filling tape for a collocated node. We indeed discovered that when TSM cannot append to an existing filling tape ((during migration, because the client is backing up directly to that tape or because a client restore is running) TSM will allocate a new tape and it will not use the 'old' filling tape anymore. Even when the new one is full, it will not continue to use the 'old' filling one. Well, I have tried convincing IBM support that this is a bug, but I keep on receiving the answer that this behavior is 'working as designed'. So, although you think you have an automated backup application, you will have to monitor it periodically, because you will waist perfectly good tapes, which will hang around in you system forever (or at least until ALL files on it expire, which can take a VERY long time. The SQL statement Neil created (below) will certainly be useful in this situation. Thank you all for your help! Kindest regards, Eric van Loon KLM Royal Dutch Airlines -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 08, 2004 22:58 To: [EMAIL PROTECTED] Cc: Loon, E.J. van - SPLXM Subject: Re: Weird tape utilization Eric Good luck with your PMR. In the meantime, below is a script that I wrote when I realised that we were suffering the "tape leak" that Richard describes. It works on the premise that with collocation turned on, there should only be one filling read-write volume in each storage pool per node/filespace. The select statements list the filling volumes by node for each storage pool collocated by node, and the filling volumes by filespace for each storage pool collocated by filespace. Each node/filespace should be listed only once per storage pool in the output. Scan down the output and if a node/filespace appears more than once it means you are using more tapes than necessary. In this case, pick one of the volumes (ideally the least utilised), update its access-mode to read-only and issue a MOVE DATA on it. You should see one of the other filling volumes listed be mounted as the destination. I usually run the script once a month or so. It may take a while, but is worth it for the tapes you get back. Now if only TSM could take care of this itself ... Regards Neil Schofield Yorkshire Water Services Ltd. select volumeusage.node_name, volumeusage.stgpool_name, volumeusage.volume_name from volumeusage, volumes where volumeusage.volume_name=volumes.volume_name and volumes.status='FILLING' and volumes.access='READWRITE' and volumeusage.stgpool_name in (select stgpool_name from stgpools where collocate='YES') group by volumeusage.node_name, volumeusage.stgpool_name, volumeusage.volume_name order by stgpool_name select volumeusage.node_Name, volumeusage.filespace_name, volumeusage.stgpool_name, volumeusage.volume_name from volumeusage, volumes where volumeusage.volume_name=volumes.volume_name and volumes.status ='FILLING' and volumes.access='READWRITE' and volumeusage.stgpool_name in (select stgpool_name from stgpools where collocate='FILESPACE') group by volumeusage.node_name, volumeusage.filespace_name, volumeusage.stgpool_name, volumeusage.volume_name order by stgpool_name Find out about our new Icytonic drink at http://www.yorkshirewater.com The information in this e-mail is confidential and may also be legally privileged. The contents are intended for recipient only and are subject to the legal notice available at http://www.keldagroup.com/email.htm Yorkshire Water Services Limited Registered Office Western House Halifax Road Bradford BD6 2SZ Registered in England and Wales No 2366682 ********************************************************************** For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. **********************************************************************
