The allocation of space on a mainframe was one of my earliest challenges. I would estimate the space required, call for a primary that would take 90% of the data set and then call for secondary extents that were 10% of the final size.
If sufficient space is available on the VolSer assigned, then in theory this should give you 90 + ( 15 * 10)% of the required space. The glitch in this estimation is that the primary must be assigned in five or fewer logical extents, or the assignment will fail. The second issue is that sufficient space exists to make the allocation required. In the above calculation, that means up to 240% of the expected file size. These assumptions are often premature as jobs fail reasonably late in the step due to space issues.
Try increasing your primary or secondary allocation sizes, and if your allocations are controlled by SMS, then pick a larger assignment pattern.
It may be that you cannot do either of these things, so a third option is to reduce the space stress by loading your memory a little with a request to compress the output data set. The following untested code will demonstrate the idea.
Data PERIOD( Compress = Yes);
The Compress option may be added to any output data set statement including those in statistical procedures and the sort procedure.
In Bob's case, there is a SAS proc titled SAS913, that takes a WORK= parameter.
That may or may not be available with your installation.
SAS has a temporary data library called "WORK".
Years ago, when I ran SAS on a mainframe, I had to be able to use more space than a single 3390 could hold, so I spanned WORK across many volumes. Of course, since I not there anymore, and it's been years, I can't give you the nitty gritty details.
What we did at that place, for general SAS use on the mainframe, was to create a named group of 3390-10's = SASDS. SASDS consisted of 10 DASD volumes, and WORK for any job could exist on any one of them. We used a generic specification of (273,273) for primary and secondary extent allocations. This kept all the space in same sized chunks for more efficient usage of storage. 273 was used because 273*16 = 4368 was just less than the maximum allocatable space of the disk (4369?), due to ???? limitations (I don't remember all the exact details). I think we used CYL for the allocation unit.
You can span WORK across at most 6 DASD volumes.
It is accomplished by creating 6 DSN's and then concatenating them together
something like the following.
I expect I'm missing something somewhere, but this should get you started, if you need it.