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
