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 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
