Re: SQL to determine what offsite volumes are needed for move data
Hi Bill - I am way behind on the list, but I think I can help you. First there isn't any sql I know of that will do what you want. But, the old query content command will give you the answer, you just need to post process the output. The steps are 1. make a macro file of 'q con' commands for all the tapes you are interested in; You can use sql to do this. For example - q content 02 count=-1 f=d q content 02 count=1 f=d q content 06 count=-1 f=d q content 06 count=1 f=d 2. Next run dsmadmc and capture the output, for example dsmadmc -id=your id -password=your pw macro C:\tsmmacs\qcon.mac qcon.lst 3. process qcon.lst (no example here) and sort it by filename. You should be able to see all the start and end tape sequences. Hope this helps, Bill Colwell At 09:54 AM 10/16/2003, you wrote: Hi, We're running TSM server 5.1.6.2 on z/OS. One of the (many) resources we're short on is tape drives. Consequently, I'm always looking to streamline processes that use these drives. Here's the problem I'm currently looking at: Our tape copy pools are kept offsite. Reclamation for these pools is handled by leaving the TSM reclamation threshhold at 100% so that he never does reclaims on his own. On a regular basis, we run a job that queries the server for copy pool tapes with a reclamation threshhold greater than 'n' percent. This list of tapes is used by the operators to go and fetch the tapes to be brought onsite. They then run a job that updates those tapes to access=readwrite, and issues a 'move data' command for each tape. Now the problem. Some of these 'move data' processes treat the volume that is being emptied as 'offsite', even though the volume has been loaded into the library and its access updated to readwrite. I'm pretty sure the reason for this is that the volumes in question have files at the beginning and/or end that span to other copy pool volumes which are themselves still offsite. If the volume being emptied is treated as 'onsite', then the move data runs pretty quickly - the copy pool volume is mounted for input, the data is copied, and the volume goes pending. However, if the volume being emptied is treated as 'offsite', TSM will perform the move data by mounting for input *all* of the primary pool tapes that have data on this copy pool tape. Since our primary tape pools are collocated, while our copy pools are not, this results in dozens of tape mounts for primary pool volumes to use as input. The move data process can take hours in this case, tying up tape drives much longer than necessary. For the moment, I'll ignore the question of whether TSM should be smart enough to mount only the one or two primary pool volumes that contain the spanned files, and use the single copy pool volume that's being emptied for all the other data. The way I've been handling this is rather cumbersome. These are the steps I take: - after the move data's have started, issue a 'q proc' command - cancel all of the move data's that are treating their input volume as 'offsite' - issue an 'audit v' command for each of the copy pool volumes being treated as 'offsite' - each audit volume process fails with the following message: ANR2456E AUDIT VOLUME: Unable to access associated volume NN - access mode is set to offsite. - this tells me which additional copy pool volume needs to be brought onsite in order to make a move data process treat the original volume to be emptied as an onsite volume - go get the additional offsite volumes needed, load them into the library, update their access to readwrite, and issue move data commands for the original volumes being treated as offsite by TSM Then, of course, the entire process has to be repeated because the 'audit volume' command will only tell me *one* offsite volume that might be needed; if a volume has files that span from both the beginning and end of the tape, I won't know that until the 2nd round of 'move data' commands is issued. As you can see, this is a laborious, difficult-to-automate process. Things would be greatly simplified if we could tell right up front which copy pool volumes were going to be treated as offsite, and which additional copy pool volumes would be needed to be brought onsite in order to make the move data's all run as 'onsite'. Having this information up front would allow me to build a list of *all* tapes needing to be brought onsite, requiring only one trip to the offsite location, saving all the hassle of canceling/auditing/etc. I *know* that the information about which offsite volumes are needed must be easy/quick to retrieve, because the 'audit volume' commands fail instantly with the message telling me what offsite volume is needed. So, here's my question (finally!): can anyone provide SQL that could be used to tell me, given a copy pool volume, are there files on that volume that span to other copy pool volumes, and, if so, what are those other copy pool volumes? Or
Re: SQL to determine what offsite volumes are needed for move data
-- This list of tapes is used by the operators to go and fetch the tapes to be brought onsite. I cannot figure it out! For what a reason you prefer to add more risk to your offsite copies by bringing them onsite? Before new copies reach the vault you are having *no* offsite copies (or your copies are less than designed). I can accept Richard's suggestion assuming he is doing delete and subsequent stgpool backup *before* to retrieve the volumes onsite. But in that scenario tracking what to be retrieved might be error prone process. Yes, TSM is having rather complicated handling of offsite copies, but this is done so intentionally!! Zlatko Krastev IT Consultant Richard Sims [EMAIL PROTECTED] Sent by: ADSM: Dist Stor Manager [EMAIL PROTECTED] 16.10.2003 18:34 Please respond to ADSM: Dist Stor Manager To: [EMAIL PROTECTED] cc: Subject:Re: SQL to determine what offsite volumes are needed for move data ... Our tape copy pools are kept offsite. Reclamation for these pools is handled by leaving the TSM reclamation threshhold at 100% so that he never does reclaims on his own. On a regular basis, we run a job that queries the server for copy pool tapes with a reclamation threshhold greater than 'n' percent. This list of tapes is used by the operators to go and fetch the tapes to be brought onsite. They then run a job that updates those tapes to access=readwrite, and issues a 'move data' command for each tape. Now the problem. Some of these 'move data' processes treat the volume that is being emptied as 'offsite', even though the volume has been loaded into the library and its access updated to readwrite. I'm pretty sure the reason for this is that the volumes in question have files at the beginning and/or end that span to other copy pool volumes which are themselves still offsite. ... Bill - I gather that you are not using DRM. I started out doing much the same as you, in our non-DRM offsite work. Then I realized that I was making it much more complicated that it need be... You can greatly simplify the task and eliminate the problems you are experiencing with the inevitable spanning issue by just doing DELete Volume ... DISCARDdata=Yes The next Backup Stgpool will automatically regenerate an offsite volume with that data, and pack it much fuller than Move Data can. It's a win all around. Richard Sims http://people.bu.edu/rbs
Re: SQL to determine what offsite volumes are needed for move data
... Our tape copy pools are kept offsite. Reclamation for these pools is handled by leaving the TSM reclamation threshhold at 100% so that he never does reclaims on his own. On a regular basis, we run a job that queries the server for copy pool tapes with a reclamation threshhold greater than 'n' percent. This list of tapes is used by the operators to go and fetch the tapes to be brought onsite. They then run a job that updates those tapes to access=readwrite, and issues a 'move data' command for each tape. Now the problem. Some of these 'move data' processes treat the volume that is being emptied as 'offsite', even though the volume has been loaded into the library and its access updated to readwrite. I'm pretty sure the reason for this is that the volumes in question have files at the beginning and/or end that span to other copy pool volumes which are themselves still offsite. ... Bill - I gather that you are not using DRM. I started out doing much the same as you, in our non-DRM offsite work. Then I realized that I was making it much more complicated that it need be... You can greatly simplify the task and eliminate the problems you are experiencing with the inevitable spanning issue by just doing DELete Volume ... DISCARDdata=Yes The next Backup Stgpool will automatically regenerate an offsite volume with that data, and pack it much fuller than Move Data can. It's a win all around. Richard Sims http://people.bu.edu/rbs
Re: SQL to determine what offsite volumes are needed for move data
On Thu, 16 Oct 2003, Richard Sims wrote: Now the problem. Some of these 'move data' processes treat the volume that is being emptied as 'offsite', even though the volume has been loaded into the library and its access updated to readwrite. I'm pretty sure the reason for this is that the volumes in question have files at the beginning and/or end that span to other copy pool volumes which are themselves still offsite. ... You can greatly simplify the task and eliminate the problems you are experiencing with the inevitable spanning issue by just doing DELete Volume ... DISCARDdata=Yes The next Backup Stgpool will automatically regenerate an offsite volume with that data, and pack it much fuller than Move Data can. It's a win all around. But isn't that just going to mean that all those primary pool tape mounts will have to occur during the next stgpool backup? Or would there possibly be fewer extra tape mounts during stgpool backup due to different processing logic in the server (e.g., mount a primary pool volume once, read all the needed data off of it)? Our daily process to backup the primary tape pools usually has little to do, and few input volumes to mount, since we back up the disk pools just before migrating. My goal here is to minimize the number of tape mounts and the time that the tape drives are tied up, whether it's in 'move data' processing or 'backup stgpool' processing. Thanks, Bill Bill Kelly Auburn University 334-844-9917
