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
