David, Good hint for Interval and Dinterval. I found the following: INTERVAL(nnn) SMS on the command-issuing system is to allow nnn seconds (1 to 999) to pass before synchronizing with the other SMS subsystems running on other MVS systems in the complex. The default value from SMS initialization is 15 seconds. This parameter applies only to the system issuing the command. DINTERVAL(nnn) Directs SMS to allow nnn seconds (1 to 999) to elapse between reading device statistics from a 3990-3 control unit. The default is 150 seconds.
15 seconds is the interval for updating the commds (I suppose) to inform other members. 150 seconds is the interval to update the volume statistics. It seems, that if DBM1 deletes a dataset from a volume, SMS will not be informed of the new free space info of that volume. In this scenario, with large tablespaces, we could need extra space on other volumes for the entire tablespace, just because SMS is not aware of the fact that DBM1 just made space available for the new allocation. SRM and lists are not relevant here. All enabled volumes are on the same, well performing, DS8800 and therefor in the primary list, so they are all equal, but SMS still selects from the secondary list. This can only be the case if all volumes in the primary list are above their thresholds. We are z/OS 1.13. I was warned by my DB2 colleague about my wording: i.s.o Reorg I should have written Load-Replace. This deletes a part of the table space, allocates it again and fills it. So the space can be reused. Thanks, Kees. -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of David Devine Sent: Wednesday, April 09, 2014 15:21 To: [email protected] Subject: Re: How often does SMS update its free space information? Hi Kees, if you issue a d sms,options command it'll display your current settings and dinterval is the one in to look for; it probably has the default setting of 150 seconds. However i think your issue is more fundamental. From dfsms implementing System-managed storage "SMS interfaces with the system resource manager (SRM) to select from the eligible volumes in the primary volume list. SRM uses device delays as one of the criteria for selection and does not prefer a volume if it is already allocated in the jobstep. This is useful for batch processing when the data set is accessed immediately after creation. It is, however, not useful for database data that is reorganized at off-peak hours." Which implies that if you are reorging a tablespace with multiple physical datasets, extents or partitions and these are allocated to you reorg job, it wont touch the packs they are on even if they have enough freespace. Info on primary, secondary, tertiary volume lists are in the same manual. I believe that quiesced volumes go into the secondary pool. B.T.W what z/os version are you on? I seem to recall that older versions used to treat enabled and quiesced volumes the same. And finally there is the way your reorgs run. My underatanding is that the reorg allocates a copy dataset, populates it, applies any updates, "flips" it over to become the true dataset (also renaming the original) and if the flip is succesful, then deletes the original. It sounds like you are expecting to reuse space that has been deleted by the first successful partition reorg and so on for further reorgs and if the allocation remains on the pack until step end, then it wont happen. hope this is of use. kind regards, Dave ********************************************************************************************************************************************************************************************** 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 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
