SORTWK does not use secondary extents. Gradully change the SMS SPACE default toward 1/16th of a volume (up to 64K Cylinders) for primary and secondary. That would allow it to fill up an empty volume before going to the next volume.
Actually, if they could look at the size of their dataset after a test run, they should be able to put that into the production JCL. Perhaps 110% primary, 20% secondary. On Sun, Sep 9, 2012 at 8:40 PM, John McKown <[email protected]> wrote: > I decided to ask this forum about a "problem" we have were I work. In > summary, the programmers don't want to be forced to specify SPACE > parameters in the JCL (or IDCAMS DEFINEs). They also don't want to be > forced to use SORTWKnn allocations or do specify any SIZE type > parameters in the controls. This latter works for JCL invoked DFSORTs. I > have set the default so high that it can sort almost anything in the > shop. I say "almost" because we had a job abend SE37-08 in an internal > sort. My solution was to tell the person responsible for the job to > change it to include about 30 SORTWKnn DD statements with > SPACE=(CYL,(2000,100)). The only reason that I said so "over the top" > was to be 99.9% sure that would be enough. But I will bet that the > programmer will complain. > > They, basically, just want the system to handle space allocations. We do > not have, and WILL NOT ACQUIRE any software such as SRS. We only use > what is available with DFSMS and DFSORT. The previous storage > administrator set up every DISK DATACLAS with a Dynamic Volume Count of > 59, which is the max, and told the programmers to use > SPACE=(CYL,(500,100)) for everything, unless they thought that they > needed more. The tape DATACLAS is set up to make the default 190 tapes, > instead of the "normal" 5, because "it would take too much work to make > JCL changes". This latter I can understand because 90% of the work is > putting in Change Control paperwork (no, this will not change). > > I have tried everything that I can think of to basically tell SMS to > allow "unlimited" allocations. Have I missed some SMS parameter? Should > I make all sequential data sets "extended format" so that they can have > 123 extents per volume instead of only 16? Is there any negative to > this? More CPU, slower I/O, anything? Does it work with DFSORT SORTWKnn > DDs, the DFSORT manual seems to say that it does. > > If you noticed from previous messages, IT management is anti-z/OS so > they basically just don't work to be bothered with it. Like because > MS-Windows is such a POS that they need to concentrate on it. Makes me > wonder why they adore it. > > -- > John McKown > Maranatha! <>< > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
