On 10/18/2012 07:48 AM, Staller, Allan wrote:
It sounds like you are not using Dynamic Volume Count or Partial Space release.
Dynamic volume count allocates the 1st extent on the 1st volume and dynamically
adds volumes to the list, up to the architectural max of 59. It is not
necessary to specify (for example) 10 volumes in JCL. It is specified in the
DATACLAS assigned to the dataset.
Partial Space Release will release unused space with a sequential file at dfHSM
Primary Space Management time. This is specified in the MGMTCLAS assigned to
the dataset.
You might also check and see if the Guaranteed Space is specified in the
STORCLAS assigned to this dataset...
Check the fine manuals for dfSMS or the online help for further details.
HTH,
<snip>
I have an application that may have to write DASD files very variable in size.
These files are dynamically allocated as SMS managed files (using DALSTCL,
DALMGCL and DALDACL) and with text unit DALRLSE (equivalent of the RLSE JCL
keyword) so that unused space is released from the allocation when closing the
file after writing it.
This works well with mono-volume data sets, but is it possible to make it work
for multi-volume data sets too ??
After testing a bit, it looks like:
- At the time of allocation , the primary space amount is allocated on
EACH of the volumes if the volume count (DALVLCNT) is greater than 1.
- At the time of CLOSE, the unused space is released on the current
volume (the last one that was written to). But, and this is my problem, the
allocations on the (unused) next volume(s) if any, are NOT freed !!!
Is it possible to specify something (in SMS ?) so that it would free ALL unused
space ?
</snip>
Doesn't have to be "guaranteed space" - can get the same effect with an
Extended Sequential SMS dataset with Storage Constraint Relief enabled
if your primary allocation exceeds the space available on one volume.
Yes, of course you can allocate a smaller space at initial allocation
and let the data set dynamically allocate to additional volumes; but if
you do this there is also no guarantee that the space will actually be
available on some candidate volume when you need it. There is then the
possibility that a very expensive job step may fail on insufficient DASD
space and have to be repeated simply because the secondary allocation
doesn't mesh well with the available space and fragmentation on
potential candidate volumes at the instant when additional allocation is
required. Being able to allocate adequate multi-volume space before the
job step starts reduces the odds of wasting CPU and I/O resources on an
expensive, potentially-failing job step and is a much more efficient
solution in such cases; but then you run into this other trade-off of
being unable to easily free space on unused volumes when the output file
size is much smaller than the worst case and some allocated volumes are
not used. It must not be a trivial thing to fix or IBM would have done
so by now.
--
Joel C. Ewing, Bentonville, AR jcew...@acm.org
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
