" 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. "
Agreed. However, it seems like that might be influencing the initial allocation.... <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. </snip> ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
