We have Syncsort, but other than that I did what you describe years ago and most x37 abends flat out disappeared. Set the default to extended/striped/multivolume, set the space allocations in the DATACLAS(s) to "lots" with rlse. Set up a DATACLAS without extended, etc. for the rare case that can't handle it. HSM migrate aggressively to virtual tape :)
Dave Gibney Information Technology Services Washington State University > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:[email protected]] > On Behalf Of John McKown > Sent: Sunday, September 09, 2012 6:40 PM > To: [email protected] > Subject: Disk data set space allocation, philosophy > > 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 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
