Re: Spill processing please help - lowering LOWMIG
On Mon, 29 Oct 2001 09:55:59 -0500, it was written: >The backups WILL go back to the disk pool if there is space - but AFTER >processing the one file that required the media mount. TSM looks for space >for each object as it comes in, and decides for that one object which pool >to use. And let me add that the state of the diskpool is not reported to the server until after the migration is finished; thus, the client backup isn't aware of the diskpool empty space until that point. One more reason not to set the diskpool's low-water mark too low... -- Mark Stapleton ([EMAIL PROTECTED])
Re: Spill processing please help - lowering LOWMIG
Hi Eric, I know this behavior and am trying both to warn John (the initial poster) and to clarify what Alan wrote. As far as I know (and have seen many times) a file goes direct to tape if it is greater than "Maximum Size Threshold" of the storage pool. Next file smaller than the threshold goes again to disk (as expected). After the pool becomes 100% full the clients stop waiting migration to finish NOT just to free enough space for the file. And if the next pool is collocated the migration of small files can take too long (as discussed recently). As a conclusion - lowering LOWMIG can help but the value have to be chosen thoughtfully. Otherwise the result might be worse. Zlatko Krastev IT Consultant "Loon, E.J. van - SPLXM" <[EMAIL PROTECTED]> on 29.10.2001 15:45:09 Please respond to "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] cc: Subject:Re: Spill processing please help - lowering LOWMIG Hi Zlatko! This is 'normal behavior'. When backups go to a 100% full diskpool TSM tries to allocate storage in the nextstgpool defined for your diskpool, which is probably your primary tapepool. So all backups are going to wait for mountpoint in the tapepool. That's why the client backups seem to 'hang'. Although migration kicks in and frees the diskpool, these clients will never switch back to the diskpool. You should always try to prevent a 100% full diskpool. I agree that this is not always possible, unless you have a very large one. I have run into this situation numerous times, which can result in very nasty problems (Oracle databases stop working, because the archive logfiles are not backed up). Kindest regards, Eric van Loon KLM Royal Dutch Airlines -Original Message- From: Zlatko Krastev/ACIT [mailto:[EMAIL PROTECTED]] Sent: Monday, October 29, 2001 10:55 To: [EMAIL PROTECTED] Subject: Re: Spill processing please help - lowering LOWMIG On our test installation (TSM 4.1.4.1, AIX 4.3.3ML6) we've seen a strange behavior: 1. Client backups to disk pool 2. Migration starts after HIGHMIG limit is passed 3. Client fills the pool faster than migration frees it 4. Reaching disk pool 100% full client pauses indicating "waiting for mount of offline media" 5. Migration process commits a migration transaction freeing space in disk pool. Client does NOT resume. 6. Migration process finishes (it's a lng process). Client wakes up and continues backup. 7. Administrator reduces disk pool deleting some volumes (to produce more pool fills) 8. Client fills the pool again and blocks 9. Migration finishes. Client again resumes. 8. ... 9. ... 8. ... 9. ... (many times) I do not know is this a bug in the release we are using or a feature of all releases but test this on your platform. If you lower significantly LOWMIG threshold and something like this happens you can see long waits and backup can go out the backup window. Zlatko Krastev IT Consultant Alan Davenport <[EMAIL PROTECTED]> on 26.10.2001 18:03:38 Please respond to "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] cc: Subject:Re: Spill processing please help + -Original Message- + From: Doherty, John (ANFIS) [mailto:[EMAIL PROTECTED]] + Sent: Friday, October 26, 2001 10:21 AM + To: [EMAIL PROTECTED] + Subject: Re: Spill processing please help + + + Thanks Alan, this looks good. This is very similar to the + problem we have. + For example I run migration on our 3 disk pools to clear them + down at 18:00, + 21:00 and 22:00 respectively. they finish at 18:32, 21:30 and 22:30 + respectively. Can I assume any migration after 22:30 would + indicate spill + processing is occurring ?? Yes, that is exactly what I was trying to say. Any migration that you didn't trigger yourself is due to your pool hitting the HIGHMIGPCT limit. If your pool is filling up too often here is a little trick you may want to try. Set your LOW migration threshold to 10% or so but leave your high migration threshold at 90%. If tape contention with other users is not an issue this will nearly empty the pool if any unscheduled migration is to occur. (Setting low migration to ZERO during the backup window is not recommended because as SOON as a file hits the disc pool it will migrate causing lots of tape mounts!) + + Also I may utilize the 1 GB file limit, but I assume that + every time a file + is greater than 1 GB then a tape mount would be requested ??? Yes, it will. But if you are using collocation like I am the amount of tape mounts will be much less for the over sized files than if triggered migration were to occur. Setting a max file size on the disc pool is one way of reducing the frequency of triggered migration. In a perfect world our disc pools would be large enough to hold everything from a backup window but we all know that's not always possible. I'm afraid the DASD
Re: Spill processing please help - lowering LOWMIG
Just a minor quibble here, Eric -- The backups WILL go back to the disk pool if there is space - but AFTER processing the one file that required the media mount. TSM looks for space for each object as it comes in, and decides for that one object which pool to use. Tom Kauffman NIBCO, Inc > -Original Message- > From: Loon, E.J. van - SPLXM [mailto:[EMAIL PROTECTED]] > Sent: Monday, October 29, 2001 8:45 AM > To: [EMAIL PROTECTED] > Subject: Re: Spill processing please help - lowering LOWMIG > > > Hi Zlatko! > This is 'normal behavior'. When backups go to a 100% full > diskpool TSM tries > to allocate storage in the nextstgpool defined for your > diskpool, which is > probably your primary tapepool. So all backups are going to wait for > mountpoint in the tapepool. That's why the client backups > seem to 'hang'. > Although migration kicks in and frees the diskpool, these > clients will never > switch back to the diskpool. > You should always try to prevent a 100% full diskpool. I > agree that this is > not always possible, unless you have a very large one. I have > run into this > situation numerous times, which can result in very nasty > problems (Oracle > databases stop working, because the archive logfiles are not > backed up). > Kindest regards, > Eric van Loon > KLM Royal Dutch Airlines > > > -Original Message- > From: Zlatko Krastev/ACIT [mailto:[EMAIL PROTECTED]] > Sent: Monday, October 29, 2001 10:55 > To: [EMAIL PROTECTED] > Subject: Re: Spill processing please help - lowering LOWMIG > > > On our test installation (TSM 4.1.4.1, AIX 4.3.3ML6) we've > seen a strange > behavior: > 1. Client backups to disk pool > 2. Migration starts after HIGHMIG limit is passed > 3. Client fills the pool faster than migration frees it > 4. Reaching disk pool 100% full client pauses indicating > "waiting for mount > of offline media" > 5. Migration process commits a migration transaction freeing > space in disk > pool. Client does NOT resume. > 6. Migration process finishes (it's a lng process). > Client wakes up and > continues backup. > 7. Administrator reduces disk pool deleting some volumes (to > produce more > pool fills) > 8. Client fills the pool again and blocks > 9. Migration finishes. Client again resumes. > 8. ... > 9. ... > 8. ... > 9. ... (many times) > I do not know is this a bug in the release we are using or a > feature of all > releases but test this on your platform. If you lower > significantly LOWMIG > threshold and something like this happens you can see long > waits and backup > can go out the backup window. > > Zlatko Krastev > IT Consultant > > > > > > Alan Davenport <[EMAIL PROTECTED]> on 26.10.2001 18:03:38 > Please respond to "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > cc: > > Subject:Re: Spill processing please help > > + -Original Message- > + From: Doherty, John (ANFIS) [mailto:[EMAIL PROTECTED]] > + Sent: Friday, October 26, 2001 10:21 AM > + To: [EMAIL PROTECTED] > + Subject: Re: Spill processing please help > + > + > + Thanks Alan, this looks good. This is very similar to the > + problem we have. > + For example I run migration on our 3 disk pools to clear them > + down at 18:00, > + 21:00 and 22:00 respectively. they finish at 18:32, 21:30 and 22:30 > + respectively. Can I assume any migration after 22:30 would > + indicate spill > + processing is occurring ?? > > Yes, that is exactly what I was trying to say. Any migration that you > didn't > trigger yourself is due to your pool hitting the HIGHMIGPCT limit. > > If your pool is filling up too often here is a little trick > you may want to > try. Set your LOW migration threshold to 10% or so but leave your high > migration threshold at 90%. If tape contention with other > users is not an > issue this will nearly empty the pool if any unscheduled > migration is to > occur. (Setting low migration to ZERO during the backup window is not > recommended because as SOON as a file hits the disc pool it > will migrate > causing lots of tape mounts!) > + > + Also I may utilize the 1 GB file limit, but I assume that > + every time a file > + is greater than 1 GB then a tape mount would be requested ??? > > Yes, it will. But if you are using collocation like I am the > amount of tape > mounts will be much less for the over sized files than if triggered > migration were to occur. Setting a max file size on the disc > pool is one > way > of reducing the frequency of triggered migration. > > In a perfect world our disc pool
Re: Spill processing please help - lowering LOWMIG
Hi Zlatko! This is 'normal behavior'. When backups go to a 100% full diskpool TSM tries to allocate storage in the nextstgpool defined for your diskpool, which is probably your primary tapepool. So all backups are going to wait for mountpoint in the tapepool. That's why the client backups seem to 'hang'. Although migration kicks in and frees the diskpool, these clients will never switch back to the diskpool. You should always try to prevent a 100% full diskpool. I agree that this is not always possible, unless you have a very large one. I have run into this situation numerous times, which can result in very nasty problems (Oracle databases stop working, because the archive logfiles are not backed up). Kindest regards, Eric van Loon KLM Royal Dutch Airlines -Original Message- From: Zlatko Krastev/ACIT [mailto:[EMAIL PROTECTED]] Sent: Monday, October 29, 2001 10:55 To: [EMAIL PROTECTED] Subject: Re: Spill processing please help - lowering LOWMIG On our test installation (TSM 4.1.4.1, AIX 4.3.3ML6) we've seen a strange behavior: 1. Client backups to disk pool 2. Migration starts after HIGHMIG limit is passed 3. Client fills the pool faster than migration frees it 4. Reaching disk pool 100% full client pauses indicating "waiting for mount of offline media" 5. Migration process commits a migration transaction freeing space in disk pool. Client does NOT resume. 6. Migration process finishes (it's a lng process). Client wakes up and continues backup. 7. Administrator reduces disk pool deleting some volumes (to produce more pool fills) 8. Client fills the pool again and blocks 9. Migration finishes. Client again resumes. 8. ... 9. ... 8. ... 9. ... (many times) I do not know is this a bug in the release we are using or a feature of all releases but test this on your platform. If you lower significantly LOWMIG threshold and something like this happens you can see long waits and backup can go out the backup window. Zlatko Krastev IT Consultant Alan Davenport <[EMAIL PROTECTED]> on 26.10.2001 18:03:38 Please respond to "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] cc: Subject:Re: Spill processing please help + -Original Message- + From: Doherty, John (ANFIS) [mailto:[EMAIL PROTECTED]] + Sent: Friday, October 26, 2001 10:21 AM + To: [EMAIL PROTECTED] + Subject: Re: Spill processing please help + + + Thanks Alan, this looks good. This is very similar to the + problem we have. + For example I run migration on our 3 disk pools to clear them + down at 18:00, + 21:00 and 22:00 respectively. they finish at 18:32, 21:30 and 22:30 + respectively. Can I assume any migration after 22:30 would + indicate spill + processing is occurring ?? Yes, that is exactly what I was trying to say. Any migration that you didn't trigger yourself is due to your pool hitting the HIGHMIGPCT limit. If your pool is filling up too often here is a little trick you may want to try. Set your LOW migration threshold to 10% or so but leave your high migration threshold at 90%. If tape contention with other users is not an issue this will nearly empty the pool if any unscheduled migration is to occur. (Setting low migration to ZERO during the backup window is not recommended because as SOON as a file hits the disc pool it will migrate causing lots of tape mounts!) + + Also I may utilize the 1 GB file limit, but I assume that + every time a file + is greater than 1 GB then a tape mount would be requested ??? Yes, it will. But if you are using collocation like I am the amount of tape mounts will be much less for the over sized files than if triggered migration were to occur. Setting a max file size on the disc pool is one way of reducing the frequency of triggered migration. In a perfect world our disc pools would be large enough to hold everything from a backup window but we all know that's not always possible. I'm afraid the DASD Czar would come after me with sharp objects if I were to try to get any more packs this month. (: Take care, Al Alan Davenport Senior Storage Administrator Selective Insurance [EMAIL PROTECTED] (973)948-1306 ** 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. **
Re: Spill processing please help - lowering LOWMIG
On our test installation (TSM 4.1.4.1, AIX 4.3.3ML6) we've seen a strange behavior: 1. Client backups to disk pool 2. Migration starts after HIGHMIG limit is passed 3. Client fills the pool faster than migration frees it 4. Reaching disk pool 100% full client pauses indicating "waiting for mount of offline media" 5. Migration process commits a migration transaction freeing space in disk pool. Client does NOT resume. 6. Migration process finishes (it's a lng process). Client wakes up and continues backup. 7. Administrator reduces disk pool deleting some volumes (to produce more pool fills) 8. Client fills the pool again and blocks 9. Migration finishes. Client again resumes. 8. ... 9. ... 8. ... 9. ... (many times) I do not know is this a bug in the release we are using or a feature of all releases but test this on your platform. If you lower significantly LOWMIG threshold and something like this happens you can see long waits and backup can go out the backup window. Zlatko Krastev IT Consultant Alan Davenport <[EMAIL PROTECTED]> on 26.10.2001 18:03:38 Please respond to "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] cc: Subject:Re: Spill processing please help + -Original Message- + From: Doherty, John (ANFIS) [mailto:[EMAIL PROTECTED]] + Sent: Friday, October 26, 2001 10:21 AM + To: [EMAIL PROTECTED] + Subject: Re: Spill processing please help + + + Thanks Alan, this looks good. This is very similar to the + problem we have. + For example I run migration on our 3 disk pools to clear them + down at 18:00, + 21:00 and 22:00 respectively. they finish at 18:32, 21:30 and 22:30 + respectively. Can I assume any migration after 22:30 would + indicate spill + processing is occurring ?? Yes, that is exactly what I was trying to say. Any migration that you didn't trigger yourself is due to your pool hitting the HIGHMIGPCT limit. If your pool is filling up too often here is a little trick you may want to try. Set your LOW migration threshold to 10% or so but leave your high migration threshold at 90%. If tape contention with other users is not an issue this will nearly empty the pool if any unscheduled migration is to occur. (Setting low migration to ZERO during the backup window is not recommended because as SOON as a file hits the disc pool it will migrate causing lots of tape mounts!) + + Also I may utilize the 1 GB file limit, but I assume that + every time a file + is greater than 1 GB then a tape mount would be requested ??? Yes, it will. But if you are using collocation like I am the amount of tape mounts will be much less for the over sized files than if triggered migration were to occur. Setting a max file size on the disc pool is one way of reducing the frequency of triggered migration. In a perfect world our disc pools would be large enough to hold everything from a backup window but we all know that's not always possible. I'm afraid the DASD Czar would come after me with sharp objects if I were to try to get any more packs this month. (: Take care, Al Alan Davenport Senior Storage Administrator Selective Insurance [EMAIL PROTECTED] (973)948-1306
Re: Spill processing please help
If you are using collocation then you may come across what I've seen. I find setting the LOW migration to a very low number causes the system to take an 'inverse proportional' amount of time to empty. (or whatever ... (I like to call these things 'approaching the speed of light' problem.) What I mean is the lower you get in the threshold 'floor' the more fragmented and smaller the user amount of data to be dumped is. You spend more time with the mount / demounts and not much time with the writing on tapes. I have 3590s. If I'm desperate to empty the diskpool, like for a big change, then I usually wait until my patience has run out (a technical parameter?) and restart migrations with the collocation turned off. ... joe.f. Joseph A Faracchio, Systems Programmer, UC Berkeley Private mail on any topic should be directed to : [EMAIL PROTECTED] (510)642-7638 (w) (209)483-JOEF (M) 5633 163 days until retirement
Re: Spill processing please help
+ -Original Message- + From: Doherty, John (ANFIS) [mailto:[EMAIL PROTECTED]] + Sent: Friday, October 26, 2001 10:21 AM + To: [EMAIL PROTECTED] + Subject: Re: Spill processing please help + + + Thanks Alan, this looks good. This is very similar to the + problem we have. + For example I run migration on our 3 disk pools to clear them + down at 18:00, + 21:00 and 22:00 respectively. they finish at 18:32, 21:30 and 22:30 + respectively. Can I assume any migration after 22:30 would + indicate spill + processing is occurring ?? Yes, that is exactly what I was trying to say. Any migration that you didn't trigger yourself is due to your pool hitting the HIGHMIGPCT limit. If your pool is filling up too often here is a little trick you may want to try. Set your LOW migration threshold to 10% or so but leave your high migration threshold at 90%. If tape contention with other users is not an issue this will nearly empty the pool if any unscheduled migration is to occur. (Setting low migration to ZERO during the backup window is not recommended because as SOON as a file hits the disc pool it will migrate causing lots of tape mounts!) + + Also I may utilize the 1 GB file limit, but I assume that + every time a file + is greater than 1 GB then a tape mount would be requested ??? Yes, it will. But if you are using collocation like I am the amount of tape mounts will be much less for the over sized files than if triggered migration were to occur. Setting a max file size on the disc pool is one way of reducing the frequency of triggered migration. In a perfect world our disc pools would be large enough to hold everything from a backup window but we all know that's not always possible. I'm afraid the DASD Czar would come after me with sharp objects if I were to try to get any more packs this month. (: Take care, Al Alan Davenport Senior Storage Administrator Selective Insurance [EMAIL PROTECTED] (973)948-1306
Re: Spill processing please help
John, Maybe the summary table can help. A simple "select start_time, end_time, entity from summary where activity='MIGRATION'" will give you some idea on the migration processes that hav been running. Hope this helps, Michel "Doherty, John (ANFIS)" <[EMAIL PROTECTED]> on 10/26/2001 12:56:17 PM Please respond to "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] cc: (bcc: Michel Engels/BE/Devoteam) Subject: Spill processing please help Hi folks I am back on the newsgroup because I desperately would like some information. We currently run TSM 3.1 on an MVS 390 mainframe. As you are aware definition of the disk storage pools contain an option to migrate to the next storage pool (in our case cartridge) if the disk pool exceeds a specified value. In our case we have these migration thresholds set at high 90% low 70% this means when the disk pool exceeds 90% migrate data until it reaches 70% and then stop. I believe this is different from a forced migration where you empty the storage pool in preparation for the next backup process. The question I have been asked is how do I know if we are spilling into this cartridge pool, i.e. how often is the disk pool exceeding 90% and forcing migration. This being the case we will incur extra processing and require to increase the size of the DASD pool. Can anyone tell me how to find out if this spill process is occurring. I.e. does anyone have a script, batch job etc. on how to determine when (if) this is happening. Even what I should be looking for to determine if this is happening would be helpful. Await your replies Thanks John > John Doherty > Technical Specialist > Storage Management > Email: [EMAIL PROTECTED] > Tel: +44 (0) 141 275 7793 > Fax: +44 (0) 141 275 9199 > > > Email communications are not necessarily secure and may be intercepted or > changed after they are sent. Abbey National Financial and Investment > Services does not accept liability for any such changes. If you wish to > confirm the origin or content of this communication, please contact the > sender using an alternative means of communication. This communication > does not create or modify any contract. If you are not the intended > recipient of this communication you should destroy it without copying, > disclosing or otherwise using its contents. Please notify the sender > immediately of the error. > > ABBEY NATIONAL FINANCIAL AND INVESTMENT SERVICES plc > Registered Office Abbey National House 287 St Vincent Street > Glasgow G2 5NB United Kingdom Registered in Scotland No 159852 >
Re: Spill processing please help
Thanks Alan, this looks good. This is very similar to the problem we have. For example I run migration on our 3 disk pools to clear them down at 18:00, 21:00 and 22:00 respectively. they finish at 18:32, 21:30 and 22:30 respectively. Can I assume any migration after 22:30 would indicate spill processing is occurring ?? Also I may utilise the 1 GB file limit, but I assume that every time a file is greater than 1 GB then a tape mount would be requested ??? > -- > From: Alan Davenport[SMTP:[EMAIL PROTECTED]] > Reply To: ADSM: Dist Stor Manager > Sent: 26 October 2001 13:23 > To: [EMAIL PROTECTED] > Subject: Re: Spill processing please help > > Hello John. I'm in the same situation except that getting extra 3390 DASD > devices for my pool is like pulling hens teeth! (: > Our client backup window starts at 20:00 and in the morning I do this > command from an admin command line: > > Q AC BEGINT=20:00 BEGIND=-1 S=MIGRATION > > This will show me if migration has kicked in during the backup window. > > Also, you can limit the size of the files that go to the disc pool. I have > my limit set at 1GB to prevent large files from filling the pool. The > command to do this is: > > UPD STG poolname MAXSIZE=1G NEXTSTGPOOL=your_tape_pool_name > > If you use the MAXSIZE parm, in this case, any file larger than 1GB will > go > directly to tape bypassing the disc pool. > > Hope this helps! > > Take care, > Al > > Alan Davenport > Senior Storage Administrator > Selective Insurance > [EMAIL PROTECTED] > (973)948-1306 > > > + -Original Message- > + From: Doherty, John (ANFIS) [mailto:[EMAIL PROTECTED]] > + Sent: Friday, October 26, 2001 7:56 AM > + To: [EMAIL PROTECTED] > + Subject: Spill processing please help > + > + > + Hi folks I am back on the newsgroup because I desperately > + would like some > + information. We currently run TSM 3.1 on an MVS 390 > + mainframe. As you are > + aware definition of the disk storage pools contain an option > + to migrate to > + the next storage pool (in our case cartridge) if the disk > + pool exceeds a > + specified value. In our case we have these migration > + thresholds set at high > + 90% low 70% this means when the disk pool exceeds 90% migrate > + data until it > + reaches 70% and then stop. I believe this is different from a forced > + migration where you empty the storage pool in preparation for the next > + backup process. > + > + The question I have been asked is how do I know if we are > + spilling into this > + cartridge pool, i.e. how often is the disk pool exceeding 90% > + and forcing > + migration. This being the case we will incur extra > + processing and require > + to increase the size of the DASD pool. > + > + Can anyone tell me how to find out if this spill process is > + occurring. I.e. > + does anyone have a script, batch job etc. on how to determine > + when (if) this > + is happening. Even what I should be looking for to determine > + if this is > + happening would be helpful. > + > + Await your replies > + > + Thanks John > + > + > + > John Doherty > + > Technical Specialist > + > Storage Management > + > Email: [EMAIL PROTECTED] > + > Tel: +44 (0) 141 275 7793 > + > Fax: +44 (0) 141 275 9199 > + > > + > > + > Email communications are not necessarily secure and may be > + intercepted or > + > changed after they are sent. Abbey National Financial and > + Investment > + > Services does not accept liability for any such changes. > + If you wish to > + > confirm the origin or content of this communication, please > + contact the > + > sender using an alternative means of communication. This > + communication > + > does not create or modify any contract. If you are not the intended > + > recipient of this communication you should destroy it > + without copying, > + > disclosing or otherwise using its contents. Please notify > + the sender > + > immediately of the error. > + > > + > ABBEY NATIONAL FINANCIAL AND INVESTMENT SERVICES plc > + > Registered Office Abbey National House 287 St Vincent Street > + > Glasgow G2 5NB United Kingdom Registered in > + Scotland No 159852 > + > > + >
Re: Spill processing please help
Thanks Arnaud what is the xx(hours) what value do I enter ?? > -- > From: PAC Brion Arnaud[SMTP:[EMAIL PROTECTED]] > Reply To: ADSM: Dist Stor Manager > Sent: 26 October 2001 13:30 > To: [EMAIL PROTECTED] > Subject: Re: Spill processing please help > > Hi John, > > why don't you just do it the easyest way : q act begint=-xx(hours) > s=migration > This will tell you immediately when your migration processes are > occuring ! > Cheers. > Arnaud > > -Original Message- > From: Doherty, John (ANFIS) [mailto:[EMAIL PROTECTED]] > Sent: Freitag, 26. Oktober 2001 13:56 > To: [EMAIL PROTECTED] > Subject: Spill processing please help > > > Hi folks I am back on the newsgroup because I desperately would like > some > information. We currently run TSM 3.1 on an MVS 390 mainframe. As you > are > aware definition of the disk storage pools contain an option to migrate > to > the next storage pool (in our case cartridge) if the disk pool exceeds a > specified value. In our case we have these migration thresholds set at > high > 90% low 70% this means when the disk pool exceeds 90% migrate data until > it > reaches 70% and then stop. I believe this is different from a forced > migration where you empty the storage pool in preparation for the next > backup process. > > The question I have been asked is how do I know if we are spilling into > this > cartridge pool, i.e. how often is the disk pool exceeding 90% and > forcing > migration. This being the case we will incur extra processing and > require > to increase the size of the DASD pool. > > Can anyone tell me how to find out if this spill process is occurring. > I.e. > does anyone have a script, batch job etc. on how to determine when (if) > this > is happening. Even what I should be looking for to determine if this is > happening would be helpful. > > Await your replies > > Thanks John > > > > John Doherty > > Technical Specialist > > Storage Management > > Email: [EMAIL PROTECTED] > > Tel: +44 (0) 141 275 7793 > > Fax: +44 (0) 141 275 9199 > > > > > > Email communications are not necessarily secure and may be intercepted > or > > changed after they are sent. Abbey National Financial and Investment > > Services does not accept liability for any such changes. If you wish > to > > confirm the origin or content of this communication, please contact > the > > sender using an alternative means of communication. This > communication > > does not create or modify any contract. If you are not the intended > > recipient of this communication you should destroy it without copying, > > disclosing or otherwise using its contents. Please notify the sender > > immediately of the error. > > > > ABBEY NATIONAL FINANCIAL AND INVESTMENT SERVICES plc > > Registered Office Abbey National House 287 St Vincent Street > > Glasgow G2 5NB United Kingdom Registered in Scotland No 159852 > > >
Re: Spill processing please help
Do a search through the activity log and key in on migration or the pool name ou suspect is migrating. "Doherty, John (ANFIS)" <[EMAIL PROTECTED]>@VM.MARIST.EDU> on 10/26/2001 07:56:17 AM Please respond to "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]> Sent by: "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] cc: Subject: Spill processing please help Hi folks I am back on the newsgroup because I desperately would like some information. We currently run TSM 3.1 on an MVS 390 mainframe. As you are aware definition of the disk storage pools contain an option to migrate to the next storage pool (in our case cartridge) if the disk pool exceeds a specified value. In our case we have these migration thresholds set at high 90% low 70% this means when the disk pool exceeds 90% migrate data until it reaches 70% and then stop. I believe this is different from a forced migration where you empty the storage pool in preparation for the next backup process. The question I have been asked is how do I know if we are spilling into this cartridge pool, i.e. how often is the disk pool exceeding 90% and forcing migration. This being the case we will incur extra processing and require to increase the size of the DASD pool. Can anyone tell me how to find out if this spill process is occurring. I.e. does anyone have a script, batch job etc. on how to determine when (if) this is happening. Even what I should be looking for to determine if this is happening would be helpful. Await your replies Thanks John > John Doherty > Technical Specialist > Storage Management > Email: [EMAIL PROTECTED] > Tel: +44 (0) 141 275 7793 > Fax: +44 (0) 141 275 9199 > > > Email communications are not necessarily secure and may be intercepted or > changed after they are sent. Abbey National Financial and Investment > Services does not accept liability for any such changes. If you wish to > confirm the origin or content of this communication, please contact the > sender using an alternative means of communication. This communication > does not create or modify any contract. If you are not the intended > recipient of this communication you should destroy it without copying, > disclosing or otherwise using its contents. Please notify the sender > immediately of the error. > > ABBEY NATIONAL FINANCIAL AND INVESTMENT SERVICES plc > Registered Office Abbey National House 287 St Vincent Street > Glasgow G2 5NB United Kingdom Registered in Scotland No 159852 >
Re: Spill processing please help
Hi John, why don't you just do it the easyest way : q act begint=-xx(hours) s=migration This will tell you immediately when your migration processes are occuring ! Cheers. Arnaud -Original Message- From: Doherty, John (ANFIS) [mailto:[EMAIL PROTECTED]] Sent: Freitag, 26. Oktober 2001 13:56 To: [EMAIL PROTECTED] Subject: Spill processing please help Hi folks I am back on the newsgroup because I desperately would like some information. We currently run TSM 3.1 on an MVS 390 mainframe. As you are aware definition of the disk storage pools contain an option to migrate to the next storage pool (in our case cartridge) if the disk pool exceeds a specified value. In our case we have these migration thresholds set at high 90% low 70% this means when the disk pool exceeds 90% migrate data until it reaches 70% and then stop. I believe this is different from a forced migration where you empty the storage pool in preparation for the next backup process. The question I have been asked is how do I know if we are spilling into this cartridge pool, i.e. how often is the disk pool exceeding 90% and forcing migration. This being the case we will incur extra processing and require to increase the size of the DASD pool. Can anyone tell me how to find out if this spill process is occurring. I.e. does anyone have a script, batch job etc. on how to determine when (if) this is happening. Even what I should be looking for to determine if this is happening would be helpful. Await your replies Thanks John > John Doherty > Technical Specialist > Storage Management > Email: [EMAIL PROTECTED] > Tel: +44 (0) 141 275 7793 > Fax: +44 (0) 141 275 9199 > > > Email communications are not necessarily secure and may be intercepted or > changed after they are sent. Abbey National Financial and Investment > Services does not accept liability for any such changes. If you wish to > confirm the origin or content of this communication, please contact the > sender using an alternative means of communication. This communication > does not create or modify any contract. If you are not the intended > recipient of this communication you should destroy it without copying, > disclosing or otherwise using its contents. Please notify the sender > immediately of the error. > > ABBEY NATIONAL FINANCIAL AND INVESTMENT SERVICES plc > Registered Office Abbey National House 287 St Vincent Street > Glasgow G2 5NB United Kingdom Registered in Scotland No 159852 >
Re: Spill processing please help
Hello John. I'm in the same situation except that getting extra 3390 DASD devices for my pool is like pulling hens teeth! (: Our client backup window starts at 20:00 and in the morning I do this command from an admin command line: Q AC BEGINT=20:00 BEGIND=-1 S=MIGRATION This will show me if migration has kicked in during the backup window. Also, you can limit the size of the files that go to the disc pool. I have my limit set at 1GB to prevent large files from filling the pool. The command to do this is: UPD STG poolname MAXSIZE=1G NEXTSTGPOOL=your_tape_pool_name If you use the MAXSIZE parm, in this case, any file larger than 1GB will go directly to tape bypassing the disc pool. Hope this helps! Take care, Al Alan Davenport Senior Storage Administrator Selective Insurance [EMAIL PROTECTED] (973)948-1306 + -Original Message- + From: Doherty, John (ANFIS) [mailto:[EMAIL PROTECTED]] + Sent: Friday, October 26, 2001 7:56 AM + To: [EMAIL PROTECTED] + Subject: Spill processing please help + + + Hi folks I am back on the newsgroup because I desperately + would like some + information. We currently run TSM 3.1 on an MVS 390 + mainframe. As you are + aware definition of the disk storage pools contain an option + to migrate to + the next storage pool (in our case cartridge) if the disk + pool exceeds a + specified value. In our case we have these migration + thresholds set at high + 90% low 70% this means when the disk pool exceeds 90% migrate + data until it + reaches 70% and then stop. I believe this is different from a forced + migration where you empty the storage pool in preparation for the next + backup process. + + The question I have been asked is how do I know if we are + spilling into this + cartridge pool, i.e. how often is the disk pool exceeding 90% + and forcing + migration. This being the case we will incur extra + processing and require + to increase the size of the DASD pool. + + Can anyone tell me how to find out if this spill process is + occurring. I.e. + does anyone have a script, batch job etc. on how to determine + when (if) this + is happening. Even what I should be looking for to determine + if this is + happening would be helpful. + + Await your replies + + Thanks John + + + > John Doherty + > Technical Specialist + > Storage Management + > Email: [EMAIL PROTECTED] + > Tel: +44 (0) 141 275 7793 + > Fax: +44 (0) 141 275 9199 + > + > + > Email communications are not necessarily secure and may be + intercepted or + > changed after they are sent. Abbey National Financial and + Investment + > Services does not accept liability for any such changes. + If you wish to + > confirm the origin or content of this communication, please + contact the + > sender using an alternative means of communication. This + communication + > does not create or modify any contract. If you are not the intended + > recipient of this communication you should destroy it + without copying, + > disclosing or otherwise using its contents. Please notify + the sender + > immediately of the error. + > + > ABBEY NATIONAL FINANCIAL AND INVESTMENT SERVICES plc + > Registered Office Abbey National House 287 St Vincent Street + > Glasgow G2 5NB United Kingdom Registered in + Scotland No 159852 + > +
Spill processing please help
Hi folks I am back on the newsgroup because I desperately would like some information. We currently run TSM 3.1 on an MVS 390 mainframe. As you are aware definition of the disk storage pools contain an option to migrate to the next storage pool (in our case cartridge) if the disk pool exceeds a specified value. In our case we have these migration thresholds set at high 90% low 70% this means when the disk pool exceeds 90% migrate data until it reaches 70% and then stop. I believe this is different from a forced migration where you empty the storage pool in preparation for the next backup process. The question I have been asked is how do I know if we are spilling into this cartridge pool, i.e. how often is the disk pool exceeding 90% and forcing migration. This being the case we will incur extra processing and require to increase the size of the DASD pool. Can anyone tell me how to find out if this spill process is occurring. I.e. does anyone have a script, batch job etc. on how to determine when (if) this is happening. Even what I should be looking for to determine if this is happening would be helpful. Await your replies Thanks John > John Doherty > Technical Specialist > Storage Management > Email: [EMAIL PROTECTED] > Tel: +44 (0) 141 275 7793 > Fax: +44 (0) 141 275 9199 > > > Email communications are not necessarily secure and may be intercepted or > changed after they are sent. Abbey National Financial and Investment > Services does not accept liability for any such changes. If you wish to > confirm the origin or content of this communication, please contact the > sender using an alternative means of communication. This communication > does not create or modify any contract. If you are not the intended > recipient of this communication you should destroy it without copying, > disclosing or otherwise using its contents. Please notify the sender > immediately of the error. > > ABBEY NATIONAL FINANCIAL AND INVESTMENT SERVICES plc > Registered Office Abbey National House 287 St Vincent Street > Glasgow G2 5NB United Kingdom Registered in Scotland No 159852 >
