I don't , and I think it will not help. If SMS skips a volume because it (thinks it) is over the limit, and says so, I still don't know if this is based on the actual volume status or on SMS's administration, which is running behind the real situation.
Do you have an answer to the question: how often does SMS updates its administration? Kees. -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Greg Shirey Sent: Wednesday, April 09, 2014 14:50 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: How often does SMS update its free space information? Were you aware of the SETSMS VOLSELMSG command? The description is below. It could help in understanding what is happening. "The SMS command, SETSMS VOLSELMSG(ON) can be used to request summarized and detailed analysis messages on volume selection, if volume selection is not prematurely terminated by an error. These analysis messages can assist the user to perform problem diagnosis on volume selection. " HTH, Greg Shirey Ben E. Keith Company -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Vernooij, CP (SPLXM) - KLM Sent: Wednesday, April 09, 2014 2:39 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: How often does SMS update its free space information? 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. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN