Letting DFSORT figure out how much SORTWK it needs is a good idea, much better than hard coding yourself. However, DFSORT can only make a good decision when it knows the input dataset(disk or tape), because it gets the record count, and other DCB info to do the estimate. If doing some kind of called sort(like COBOL internal, or the like) where records get passed to SORT one at a time, then there is no way for SORT to know how much dynamic space to allocate, unless you pass SORT an estimated record count. DB2 utilities do this, but not many home grown apps do this, and this is what causes the problem.
_________________________________________________________________ Dave Jousma Assistant Vice President, Mainframe Services david.jou...@53.com 1830 East Paris, Grand Rapids, MI 49546 MD RSCB2H p 616.653.8429 f 616.653.2717 -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Dennis Gush Sent: Monday, September 10, 2012 9:38 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Disk data set space allocation, philosophy For very large sorts we place SYSWK files on model 27 volumes as follows:- //SORTWK01 DD UNIT=3390,VOL=SER=??????,SPACE=(CYL,32700),DSNTYPE=LARGE . . . . -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John McKown Sent: 10 September 2012 03:40 AM To: IBM-MAIN@LISTSERV.UA.EDU 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN Disclaimer: This message and/or attachment(s) may contain privileged, confidential and/or personal information. If you are not the intended recipient you may not disclose or distribute any of the information contained within this message. In such case you must destroy this message and inform the sender of the error. T-Systems does not accept liability for any errors, omissions, information and viruses contained in the transmission of this message. Any opinions, conclusions and other information contained within this message not related to T-Systems' official business is deemed to be that of the individual only and is not endorsed by T-Systems. This message and/or attachment(s) may contain privileged or confidential information. If you are not the intended recipient you may not disclose or distribute any of the information contained within this message. In such case you must destroy this message and inform the sender of the error. T-Systems does not accept liability for any errors, omissions, information and viruses contained in the transmission of this message. Any opinions, conclusions and other information contained within this message not related to T-Systems' official business is deemed to be that of the individual only and is not endorsed by T-Systems. T-Systems - Business Flexibility ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
