Mike, I used the wrong term 'reorg'. The job did a load-replace. In this case the old dataset is deleted and the new one allocated and filled. Therefor it should be able to reuse the old space, *if* SMS is aware of the new free space on the 'old' volume. Apparently it isn't. Your explanation that SMS updates its statistics when allocating a dataset (and apparently not when a dataset is deleted) explains why the new space on the 'old' volume will not be seen by SMS until the 150 sec. update cycle. Which is a pity for accurate and quick space management.
Kees. -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Mike Schwab Sent: Friday, April 11, 2014 20:10 To: [email protected] Subject: Re: How often does SMS update its free space information? When I have added volumes to a storage group, the old totals remain until a dataset is allocated on a volume, then that volume's stats were updated to the storage group. Recently, I think IBM put in logic to update the storage group's totals when a volume is varied online or offline. During the reorg, you have two copies of the dataset. The old dataset being used as a source and the new dataset being used as a target. If you don't have enough space on the active volumes, the reorg blows up at our shop and I get called on the weekend or goes onto quiescent volumes at your shop. On Wed, Apr 9, 2014 at 2:39 AM, Vernooij, CP (SPLXM) - KLM <[email protected]> wrote: > Hello group, > > We see that new datasets are being allocated by SMS on volumes, which we > cannot explain. In each storagegroup we have one or more Quiesced volumes, on > which SMS is supposed to allocate datasets only when all the enabled volumes > in the storagegroup are filled to their max (migration high percentage). This > triggers us to have a look at the storagegroup and add space to it. > > During DB2 Reorgs we see datasets being allocated on Quiesced volumes, > although space should be available on the Enabled volumes in the storage > group. Tracing in detail, we see DBM1 deleting and defining parts of the > tablespace in a very high speed. If a part of the table space has been > deleted, it makes space available for the define of the new part, but this > space is not used by SMS. Our assumption is, that SMS does not update its > administration when DBM1 has deleted a part and when DBM1 defines a new part > of the table space, SMS must look for free space based on its 'aged' > information. Considering the speed of DBM1's delete and define actions, it > appears as if space for the entire new tablespace must be found as if the old > tablespace still is fully present. When the Reorg has finished, we have a > large amount of space allocated on the Quiesced volumes, with ample space for > it available on the enabled volumes. > > At what moments or at what rate or with which other algorithm does SMS update > its free space information of the volumes of a storagegroup? I could not find > it in SMS information. > > Thanks, > 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 [email protected] with the message: INFO IBM-MAIN -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN ******************************************************** 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 [email protected] with the message: INFO IBM-MAIN
