Re: How do you handle SMS Pools out of space
On 2009-05-22 at 07:42, concerning How do you handle SMS Pools out of space, Lizette Koehler star...@mincom wrote to IBM-Main: [snip] The pool is dedicated to DB2 Archive Logs. Normally our process [snip] works fine. [snip] when there is a runaway DB2 function or a large purge, it can fill up quite quickly. [snip] We have a couple of SMS pools that are usually 80% free all the time. However, occasionally they do fill up and I need to manually do ML2 migrations so the appls can continue to work. Lizette : I, too, have a pool for both log Image Copies. Logs have 3 day primary backups are 5 days to reduce recalls. (I think the backups could be reduced as well since they've probably only used the image copies 5 time in the last decade but...) Another item is to carry 1-2 quiesced (QuiNew) volumes in the destination pool. They will maintain a reserved space within the pool and are used when the primary allocation can't be achieved by other volumes in the pool; whether full or fragmented. (Do you compakt your heavily migrated pool(s)?) I find the overflow is often reached because an overly large primary was specified. In my daily job that FDR Moves (DSS alternative) everything in the overflow pool, most of the datasets are easily moved back to their proper location without alteration. By that time, FDR is working with the actual data size and it will usually fit. Warning: the overflow pool is preferred unless it *too* is quiesced. For example: - pool with quiesced, overflow pool enabled = 1) enabled pool volume, 2) enabled overflow volume, 3) quiesced pool volume, 4) quiesced overflow volume - pool with quiesced, overflow pool quiesced = 1) enabled pool volume, 2) quiesced pool volume, 3) overflow pool volume(s) -- signature = 6 lines follows -- Neil Duffee, Joe SysProg, U d'Ottawa, Ottawa, Ont, Canada telephone:1 613 562 5800 x4585 fax:1 613 562 5161 mailto:NDuffee of uOttawa.ca http:/ /aix1.uottawa.ca/ ~nduffee How *do* you plan for something like that? Guardian Bob, Reboot For every action, there is an equal and opposite criticism. Systems Programming: Guilty, until proven innocent John Norgauer 2004 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: How do you handle SMS Pools out of space
Just to provide a little more detail. The pool is dedicated to DB2 Archive Logs. Normally our process of a low threshold and migrating every night works fine. The pool stays about 80% free, However, when there is a runaway DB2 function or a large purge, it can fill up quite quickly. It is these emergencies I am working on. The speed at which the archive logs are written can overwhelm a spill group or extend pool. I will probably go ahead and develop the REXX for an automated migration on the pool. I have a utility from the CBT to collect the dataset names I need to issue the migrate against. By the way, my DBAs are quite happy with dasd archives and do not want to use tape for their archives. Thanks for all the suggestions. Lizette There are many ways. Creating overflow groups generally get messy over time because of the nature of the allocations. There is also Extended Storage Groups that can be defined in the DFSMS Constructs. Again, this can become messy over time. Doing aggressive migration, whether through interval migration or lower thresholds of the storage groups can create serious thrashing problems within DFHSM. Creating the REXX based on IGD messages is an option. In order to perform the migration on the correct data sets to prevent problems, you will need to access the VTOC and determine based on days unreferenced, size, and data type what to migrate, and how many. Do you migrate everything based on 14 days unreferenced, greater than 300 cylinders, and only PS data sets, or do you pick some other criteria? Do you do something additional to move more data if the first migration did not create enough free space? Also using SAS and DCOLLECT is an option, which is what I used before I got gray hair. :-) I finally got tired of maintaining the code and bought a solution from a vendor. That was almost 15 years ago. We have a couple of SMS pools that are usually 80% free all the time. However, occasionally they do fill up and I need to manually do ML2 migrations so the appls can continue to work. I am considering creating a rexx that gets kicked off by OPS/MVS to do the migration for me. I would probably monitor for IGD17216I and IGD17272I. I was just wondering what other options might be available (other than interval migration in DFHSM). How do you handle the need to migrate datasets out of a pool when it gets too full. What type of automation or manual process to you have available to you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: How do you handle SMS Pools out of space
Spencer, Mike mike_spen...@bmc.com wrote in message news:2f58a5338b1c0044abe7d99aac2b6aef3f38c45...@houccrprd01.adprod.bmc. com... There are many ways. Creating overflow groups generally get messy over time because of the nature of the allocations. There is also Extended Storage Groups that can be defined in the DFSMS Constructs. Again, this can become messy over time. I don't see anything messy in overflow groups. I use them too. Each morming the overflow pool is checked for datasets, a report is generated and sent to me that data has been allocated in the overflow pool. Subsequent dasd maintenance (we have CA-DISK) tries to move the overflown data back to its correct pool, after having archived (migrated in HSM dialect) the daily data from these pools. This way, the overflow pool creates a buffer that enables batch to continue, even over an entire weekend, but alerts us that thresholds have been reached. This way we are alerted in the morning of the situation and we have time for our first coffee, a decent evaluation and cunning solution instead of having to solve this split-second when being phoned out of our sleep in the middle of the night. Kees. ** 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. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 ** -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: How do you handle SMS Pools out of space
Kees, The messy part is the manual cleanup of the overflow pools, and having overflow data left over. As you stated, you receive a report of the data that was written, and then there is DASD maintenance (CA-Disk at your location, but DFHSM or FDR can also be used) which as you stated tries to move the overflow data back to the proper pools after the archive process. Setting the threshold to the floor limit would migrate the data if eligible based on management class attributes. The end result is that data is left in the overflow pools. The manual DASD maintenance and any leftover overflow data is the messy part. You could automate a DFDSS copy (or some other data mover) to sweep the overflow pool and reallocate the data to the correct pools, but this is extra cycles to move data based on a problem. I like everything to be where it should be based upon the management policies the first time around, and I automate everything. Just a personal opinion. Michael Spencer -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Vernooy, C.P. - SPLXM Sent: Friday, May 22, 2009 8:01 AM To: IBM-MAIN@bama.ua.edu Subject: Re: How do you handle SMS Pools out of space Spencer, Mike mike_spen...@bmc.com wrote in message news:2f58a5338b1c0044abe7d99aac2b6aef3f38c45...@houccrprd01.adprod.bmc. com... There are many ways. Creating overflow groups generally get messy over time because of the nature of the allocations. There is also Extended Storage Groups that can be defined in the DFSMS Constructs. Again, this can become messy over time. I don't see anything messy in overflow groups. I use them too. Each morming the overflow pool is checked for datasets, a report is generated and sent to me that data has been allocated in the overflow pool. Subsequent dasd maintenance (we have CA-DISK) tries to move the overflown data back to its correct pool, after having archived (migrated in HSM dialect) the daily data from these pools. This way, the overflow pool creates a buffer that enables batch to continue, even over an entire weekend, but alerts us that thresholds have been reached. This way we are alerted in the morning of the situation and we have time for our first coffee, a decent evaluation and cunning solution instead of having to solve this split-second when being phoned out of our sleep in the middle of the night. Kees. ** 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. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 ** -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: How do you handle SMS Pools out of space
Michael, CA-DISK is a functional replacement for HSM, but is technically fully different from HSM and has different features and dasd management possibilities. E.g. I don't work with sms/hsm migration limits or similar. The detecting, reporting and moving back to the correct pool is fully part of the daily storage maintenance and all done by CA-DISK and SAS. All I have to do is read the email and determine if the original storage pools need to be enlarged or that this is an acceptable incident. Kees. Spencer, Mike mike_spen...@bmc.com wrote in message news:2f58a5338b1c0044abe7d99aac2b6aef3f38c45...@houccrprd01.adprod.bmc. com... Kees, The messy part is the manual cleanup of the overflow pools, and having overflow data left over. As you stated, you receive a report of the data that was written, and then there is DASD maintenance (CA-Disk at your location, but DFHSM or FDR can also be used) which as you stated tries to move the overflow data back to the proper pools after the archive process. Setting the threshold to the floor limit would migrate the data if eligible based on management class attributes. The end result is that data is left in the overflow pools. The manual DASD maintenance and any leftover overflow data is the messy part. You could automate a DFDSS copy (or some other data mover) to sweep the overflow pool and reallocate the data to the correct pools, but this is extra cycles to move data based on a problem. I like everything to be where it should be based upon the management policies the first time around, and I automate everything. Just a personal opinion. Michael Spencer -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Vernooy, C.P. - SPLXM Sent: Friday, May 22, 2009 8:01 AM To: IBM-MAIN@bama.ua.edu Subject: Re: How do you handle SMS Pools out of space Spencer, Mike mike_spen...@bmc.com wrote in message news:2f58a5338b1c0044abe7d99aac2b6aef3f38c45...@houccrprd01.adprod.bmc. com... There are many ways. Creating overflow groups generally get messy over time because of the nature of the allocations. There is also Extended Storage Groups that can be defined in the DFSMS Constructs. Again, this can become messy over time. I don't see anything messy in overflow groups. I use them too. Each morming the overflow pool is checked for datasets, a report is generated and sent to me that data has been allocated in the overflow pool. Subsequent dasd maintenance (we have CA-DISK) tries to move the overflown data back to its correct pool, after having archived (migrated in HSM dialect) the daily data from these pools. This way, the overflow pool creates a buffer that enables batch to continue, even over an entire weekend, but alerts us that thresholds have been reached. This way we are alerted in the morning of the situation and we have time for our first coffee, a decent evaluation and cunning solution instead of having to solve this split-second when being phoned out of our sleep in the middle of the night. Kees. ** 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. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 ** -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html ** 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
Re: How do you handle SMS Pools out of space
Can HSM do interval migration more often than every hour? Greg Shirey Ben E. Keith Co. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Ted MacNEIL Sent: Thursday, May 21, 2009 3:28 PM There are many alternatives before you get to (outside HSM) automation. Two: 1. More frequent/aggressive interval migration. 2. Threshold migration. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: How do you handle SMS Pools out of space
Can HSM do interval migration more often than every hour? I honestly don't know. I've never done it less than that. Check the manual. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: How do you handle SMS Pools out of space
Well, I did check the manual (as of z/OS 1.9, it's hourly), but I'm not the one who suggested it could be done. Can't you fact-check your own suggestions? (I'm just asking) Regards, Greg -Original Message- From: IBM Mainframe Discussion List On Behalf Of Ted MacNEIL Sent: Friday, May 22, 2009 2:47 PM Can HSM do interval migration more often than every hour? I honestly don't know. I've never done it less than that. Check the manual. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: How do you handle SMS Pools out of space
Unless IBM has made a recent change (in the last few months), the lowest interval for interval migration is one hour. Michael Spencer BMC Software -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Greg Shirey Sent: Friday, May 22, 2009 4:17 PM To: IBM-MAIN@bama.ua.edu Subject: Re: How do you handle SMS Pools out of space Well, I did check the manual (as of z/OS 1.9, it's hourly), but I'm not the one who suggested it could be done. Can't you fact-check your own suggestions? (I'm just asking) Regards, Greg -Original Message- From: IBM Mainframe Discussion List On Behalf Of Ted MacNEIL Sent: Friday, May 22, 2009 2:47 PM Can HSM do interval migration more often than every hour? I honestly don't know. I've never done it less than that. Check the manual. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: How do you handle SMS Pools out of space
Well, I did check the manual (as of z/OS 1.9, it's hourly), but I'm not the one who suggested it could be done. Can't you fact-check your own suggestions? (I'm just asking) I didn't realise I had suggested more frequently than an hour. If I had, I made a mistake. I just said more frequently. Most shops I've worked at use less than 1 hour. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: How do you handle SMS Pools out of space
I meant less frequently than once an hour. The last one I worked at couldn't afford the CPU. --Original Message-- From: (yahoo) Ted MacNEIL Sender: IBM Mainframe Discussion List To: IBM Mainframe Discussion List ReplyTo: IBM Mainframe Discussion List Sent: May 22, 2009 16:32 Subject: Re: How do you handle SMS Pools out of space Well, I did check the manual (as of z/OS 1.9, it's hourly), but I'm not the one who suggested it could be done. Can't you fact-check your own suggestions? (I'm just asking) I didn't realise I had suggested more frequently than an hour. If I had, I made a mistake. I just said more frequently. Most shops I've worked at use less than 1 hour. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: How do you handle SMS Pools out of space
In order to have interval migration less than one interval, you need two hosts, and you set each one to an hour, but the second to check 30 minutes after the first host. I do not recall the PATCH syntax. It should be in the manual. At least this is how I remember it being accomplished. Michael Spencer -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Ted MacNEIL Sent: Friday, May 22, 2009 4:35 PM To: IBM-MAIN@bama.ua.edu Subject: Re: How do you handle SMS Pools out of space I meant less frequently than once an hour. The last one I worked at couldn't afford the CPU. --Original Message-- From: (yahoo) Ted MacNEIL Sender: IBM Mainframe Discussion List To: IBM Mainframe Discussion List ReplyTo: IBM Mainframe Discussion List Sent: May 22, 2009 16:32 Subject: Re: How do you handle SMS Pools out of space Well, I did check the manual (as of z/OS 1.9, it's hourly), but I'm not the one who suggested it could be done. Can't you fact-check your own suggestions? (I'm just asking) I didn't realise I had suggested more frequently than an hour. If I had, I made a mistake. I just said more frequently. Most shops I've worked at use less than 1 hour. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: How do you handle SMS Pools out of space
In order to have interval migration less than one interval, you need two hosts, and you set each one to an hour, but the second to check 30 minutes after the first host. I do not recall the PATCH syntax. It should be in the manual. At least this is how I remember it being accomplished. I remember something like that, but my point was based on (however faulty) that few shops go down to once an hour. Most cannot afford the CPU costs. We couldn't, especially during the peak. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: How do you handle SMS Pools out of space
Agreed. An hourly interval is very CPU intrusive for most shops. Setting the PATCH in ARCCMDxx to once every 4 to 6 hours is a general rule of thumb for folks who do interval migration. Michael Spencer -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Ted MacNEIL Sent: Friday, May 22, 2009 5:07 PM To: IBM-MAIN@bama.ua.edu Subject: Re: How do you handle SMS Pools out of space In order to have interval migration less than one interval, you need two hosts, and you set each one to an hour, but the second to check 30 minutes after the first host. I do not recall the PATCH syntax. It should be in the manual. At least this is how I remember it being accomplished. I remember something like that, but my point was based on (however faulty) that few shops go down to once an hour. Most cannot afford the CPU costs. We couldn't, especially during the peak. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: How do you handle SMS Pools out of space
How do you handle the need to migrate datasets out of a pool when it gets too
full. What type of automation or manual process to you have available to you.
There are many alternatives before you get to (outside HSM) automation.
Two:
1. More frequent/aggressive interval migration.
2. Threshold migration.
Of course, if you are getting into migration thrashing, there's:
3. More DASD. (8-{]}
-
Too busy driving to stop for gas!
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: How do you handle SMS Pools out of space
Hi Lizette, You could define an overflow pool in SMS. Then when your primary sotrage pool is full, allocations would automatically go to the overflow pool. Linda - Original Message - From: Lizette Koehler stars...@mindspring.com To: IBM-MAIN@bama.ua.edu Sent: Thursday, May 21, 2009 1:07:18 PM GMT -08:00 US/Canada Pacific Subject: How do you handle SMS Pools out of space We have a couple of SMS pools that are usually 80% free all the time. However, occasionally they do fill up and I need to manually do ML2 migrations so the appls can continue to work. I am considering creating a rexx that gets kicked off by OPS/MVS to do the migration for me. I would probably monitor for IGD17216I and IGD17272I. I was just wondering what other options might be available (other than interval migration in DFHSM). How do you handle the need to migrate datasets out of a pool when it gets too full. What type of automation or manual process to you have available to you. Thanks Lizette -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: How do you handle SMS Pools out of space
You could define an overflow pool in SMS. Then when your primary sotrage pool is full, allocations would automatically go to the overflow pool. Geeze! Being involved in storage management for almost 30 years, I can't believe that I forgot that one. It's an alternative, but I prefer to make it the last choice. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: How do you handle SMS Pools out of space
There are many ways. Creating overflow groups generally get messy over time because of the nature of the allocations. There is also Extended Storage Groups that can be defined in the DFSMS Constructs. Again, this can become messy over time. Doing aggressive migration, whether through interval migration or lower thresholds of the storage groups can create serious thrashing problems within DFHSM. Creating the REXX based on IGD messages is an option. In order to perform the migration on the correct data sets to prevent problems, you will need to access the VTOC and determine based on days unreferenced, size, and data type what to migrate, and how many. Do you migrate everything based on 14 days unreferenced, greater than 300 cylinders, and only PS data sets, or do you pick some other criteria? Do you do something additional to move more data if the first migration did not create enough free space? Also using SAS and DCOLLECT is an option, which is what I used before I got gray hair. :-) I finally got tired of maintaining the code and bought a solution from a vendor. That was almost 15 years ago. Michael Spencer -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Lizette Koehler Sent: Thursday, May 21, 2009 4:07 PM To: IBM-MAIN@bama.ua.edu Subject: How do you handle SMS Pools out of space We have a couple of SMS pools that are usually 80% free all the time. However, occasionally they do fill up and I need to manually do ML2 migrations so the appls can continue to work. I am considering creating a rexx that gets kicked off by OPS/MVS to do the migration for me. I would probably monitor for IGD17216I and IGD17272I. I was just wondering what other options might be available (other than interval migration in DFHSM). How do you handle the need to migrate datasets out of a pool when it gets too full. What type of automation or manual process to you have available to you. Thanks Lizette -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
