Thanks again, Peter, and all. One last question - how can I dump off the current SORT system options? For example, Peter, you said, "my shop defaults DYNALLOC to 59" - how can I see what our default setting has?

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 5:27:52 PM
Subject Re: SORTWK space usage

Billy,

If it is an internal sort then supply the FILSZ=Ennnnnnnnnnn parameter in 
DFSPARM (or $ORTPARM for Syncsort) along with the DYNALLOC parameter.

My shop defaults DYNALLOC to 59 and allows production jobs to use the max of 
255 for particularly large sorts.  Some of ours are, like yours, multiple 
hundreds of millions of relatively short records, and DYNALLOC is used all the 
time for those, no JCL SORTWK at all.

My team has a standing policy to:

(1) remove SORTWKnn from JCL and PROC's that have them when they are next 
updated
(2) add the appropriate xxxxPARM JCL if not already there
(3) add/update PARM control card(s): DYNALLOC larger than default if needed by 
testing on production volume files; for internal SORT's also add FILSZ=Ennn at 
about 1.2 times current volume unless there is known future growth anticipated
(4) enlarge too-small REGION parameters to at least 512M for large sort steps 
(internal or external) and higher if needed up to the installation-controlled 
max

Let SORT do the work for you, there is really no need to do that work yourself.

HTH

Peter

-----Original Message-----
From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On Behalf Of 
Billy Ashton
Sent: Monday, July 3, 2023 3:48 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SORTWK space usage

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

Reply via email to