Billy, Am only trying to present a possible option. The number of volumes and available space is shop dependent. Best to grab a sort manual and go through the possible option then test. The expert, Sri Kolusu many have thoughts on best practice. Is the input disk or tape ? It makes a difference.. Doug
Stay Safe > On Jul 3, 2023, at 15:48, Billy Ashton <bill00ash...@gmail.com> wrote: > > Doug, this raises a good point. If I have a COBOL program doing a SORT in > the middle of the program (I am not sure if the big file is doing this, too > or not), is using this DFSPARM the best way to force the use of 15 Dynalloc > SORTWK files, so I would not have to code SORTWK DD statements? > > Thank you and best regards, > Billy Ashton > > > ------ Original Message ------ > From "Doug" <dsh...@bellsouth.net> > To IBM-MAIN@listserv.ua.edu > Date 7/3/2023 2:45:28 PM > Subject Re: SORTWK space usage > >> Try adding this instead off sorted dd. >> //DFSPARM DD * >> OPTION DYNALLOC=(SYSDA,15),DYNSPC=768 >> /* >> >> You can add other options too. >> Regards, Doug >> >>> On Jul 3, 2023, at 14:34, Michael Oujesky <reflect...@oujesky.net> wrote: >>> >>> Just a warning, but the SORTWK specification decision depends on how SORT >>> is provided the input data. If via SORTIN, then allowing SORT to make the >>> determination should be fine. But when the incoming records are provided >>> SORT one records at a time (piping, E15 exit, etc,) then nudging SORT's >>> SORTWK decision by providing some SORTWK areas would probably be a better >>> approach. >>> >>> At 01:13 PM 7/3/2023, Billy Ashton wrote: >>> >>> Thanks everyone - these are good recommendations. >>> >>> However, the guy who came to me first has a job that sorts 450 million >>> records of 110 bytes, and I can't see how I could run SORT without >>> specifying SORTWK DD statements. Are there special configuration options I >>> can verify that we have in place to help my comfort level that I could >>> eliminate SORTWK DD? >>> >>> If the programming team are not convinced, does this look right, based on >>> the discussion - and based on a 100% Disk sort, which is not likely? >>> 450mill * 110 * 1.5 = 74250000000 = 69GB >>> so maybe SORTWK01 - SORTWK10 >>> //SORTWK01 DD UNIT=WORK,DSNTYPE=LARGE,SPACE=(CYL,(4000,1000)) >>> to >>> //SORTWK10 DD UNIT=WORK,DSNTYPE=LARGE,SPACE=(CYL,(4000,1000)) >>> >>> and this will give me 4000 + (15*1000) on each, or 40000c primary + (up to >>> 150 * 1000) secondary >>> >>> While we have been talking here, I have looked, and found some jobs with >>> //SORTWK01 DD UNIT=(WORK,5)... >>> and this will not work, is that right, Sri Kolusu? I would only get the >>> first volume anyway? >>> >>> Thank you and best regards, >>> Billy Ashton >>> >>> >>> ------ Original Message ------ >>> From "Farley, Peter" <0000031df298a9da-dmarc-requ...@listserv.ua.edu> >>> To IBM-MAIN@listserv.ua.edu >>> Date 7/3/2023 12:44:43 PM >>> Subject Re: SORTWK space usage >>> >>>> I will add on to Sri's excellent answer with my very STRONG recommendation >>>> NOT to use hard-coded SORTWK's in your JCL. Both of the major SORT >>>> vendors (IBM and Syncsort) do a far, far better job of estimating >>>> necessary SORTWK space and memory utilization than any human could hope to >>>> do. >>>> >>>> I also STRONGLY recommend that you give your JCL and program-controlled >>>> SORT steps as much memory in the REGION parameter as your installation >>>> allows for production and test jobs. Both of the major SORT programs will >>>> figure out how much of that memory to use, whether and how much of it to >>>> use in the current WLM environment, and will make VERY effective use of as >>>> much of it as they can to cut down on SORT execution and elapsed time. >>>> Memory is (relatively) cheap, don't be afraid to use all you've got >>>> available to shorten your SORT times. >>>> >>>> My basic advice is don't try to second-guess these very intelligent >>>> programs - they each have more than half a century of practice and >>>> experience that none of us can match, even those of us who have been >>>> around that long. >>>> >>>> Peter >>>> >>>> -----Original Message----- >>>> From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On Behalf >>>> Of Sri h Kolusu >>>> Sent: Monday, July 3, 2023 12:28 PM >>>> To: IBM-MAIN@LISTSERV.UA.EDU >>>> Subject: Re: SORTWK space usage >>>> >>>>>> I will only get the primary space of 5000 cylinders, and the other >>>>>> 14x2000 cylinders is never used. Is that right? >>>> >>>> Billy, >>>> >>>> No. Incorrect. DFSORT will make use of BOTH primary and secondary space >>>> allocations ( 1 primary + 15 Secondary) for a total of 16 extents. So if >>>> you allocated 1 sortwk dataset with (CYL,(5000,2000)), then DFSORT would >>>> use 5000 + 15* 2000 = 5000 + 30000 = 35,000 cylinders. Also note that the >>>> secondary extents will only come into picture ONLY when needed. >>>> >>>>>> Is there a written explanation I can forward to the programmers so they >>>>>> understand this? >>>>>> Also (since I know it will come), is there any good way to calculate how >>>>>> much DASD sortwork would be used? I know this depends on what is in >>>>>> memory at the time, but want to get a better handle on how Sort >>>>>> determines what it needs. >>>> >>>> I would suggest that you use DFSORT's Dynamic Allocation as it will >>>> allocate the required workspace optimally rather than programmers >>>> calculating it. The reason is you don't want to change the allocation >>>> every time there is an increase/decrease in the number of records to be >>>> sorted. >>>> >>>> Having said that, here is a general formula that you want to use. >>>> >>>> The amount of sortwk space required depends on the size of the file. It >>>> usually ranges from 1.3X to 1.8X of the size of the file to be sorted >>>> depending on the sorting path that DFSORT chose. >>>> >>>> Filesize = Number of records * Avg length of the record ( for Fixed length >>>> RECFM=F or FB , it is the LRECL value, or RECFM=V or RECFM=VB is the >>>> average length of the record) >>>> >>>> However, that range is applicable ONLY when the entire file is being >>>> sorted using Disk workspace. DFSORT has the capability of using memory >>>> (real and auxiliary storage) and if it runs out of it, it will then use >>>> disk workspace. >>>> >>>> >>>> Thanks, >>>> Kolusu >>>> -- >>>> >>>> This message and any attachments are intended only for the use of the >>>> addressee and may contain information that is privileged and confidential. >>>> If the reader of the message is not the intended recipient or an >>>> authorized representative of the intended recipient, you are hereby >>>> notified that any dissemination of this communication is strictly >>>> prohibited. If you have received this communication in error, please >>>> notify us immediately by e-mail and delete the message and any attachments >>>> from your system. >>>> >>>> >>>> ---------------------------------------------------------------------- >>>> For IBM-MAIN subscribe / signoff / archive access instructions, >>>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN >>> >>> ---------------------------------------------------------------------- >>> For IBM-MAIN subscribe / signoff / archive access instructions, >>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN >> >> ---------------------------------------------------------------------- >> For IBM-MAIN subscribe / signoff / archive access instructions, >> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN >> >> ---------------------------------------------------------------------- >> For IBM-MAIN subscribe / signoff / archive access instructions, >> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
