I can't give specific recommendations without knowing more about these sorts being executed and the environment. But perhaps I can offer a little info that will be useful.
The reason the JCL SORTWKxx data sets get reallocated to SORTDKxx is because VIO=NO is in effect. This is the installation default we recommend. So when the work data sets are allocated to VIO, DFSORT attempts to re-allocate them to SORTDKxx data sets using a different unit name in hopes they will be directed to disk instead of VIO. Unfortunately, VIO cannot be specified as a run time option so you cannot change it for just this job. But perhaps you can code JCL SORTWKs using a unit that is not directed to VIO. I don't know how your ACS routines are set up but usually a VIO storage class is assigned based on the primary space allocation size. So perhaps if you allocated 1 or 2 SORTWK dds with a larger storage size, they'd be assigned to disk and thus DFSORT would not try to re-allocate them. When no JCL sortwks are present, then DFSORT's dynamic allocation is used. Usually, even if the sort is expected to complete in memory, work data sets are still allocated since we can't be entirely sure of the file size being passed. You could at least reduce the number of work data sets being passed by using an OPTION statement with DYNALLOC=(,2) which would reduce the number of work data sets allocated. There might be some other options we can come up with if we had more info. Perhaps you can send the entire joblog from an execution of this program to our DFSORT hot line, dfs...@us.ibm.com and we can take a look. Have a nice day, Dave Betten DFSORT Development, Performance Lead IBM Corporation email: bet...@us.ibm.com DFSORT/MVSontheweb at http://www.ibm.com/storage/dfsort/ IBM Mainframe Discussion List <IBM-MAIN@bama.ua.edu> wrote on 02/20/2012 12:22:44 PM: > [image removed] > > was: Abend S0C4 in an internal sort > > Staffan Tylen > > to: > > IBM-MAIN > > 02/20/2012 12:23 PM > > Sent by: > > IBM Mainframe Discussion List <IBM-MAIN@bama.ua.edu> > > Please respond to IBM Mainframe Discussion List > > I wish to continue this thread as it's related. I'm now running my > program with internal calls to DFSORT and it works fine except for > one issue that I have, namely that I get a lot of job log messages > generated as a result of dynamic allocation of VIO sortwork files. > DFSORT is invoked 1000's of times by the program (yes, I know but > there is nothing I can do about that) and each time it creates a > bunch of job log messages for VIO allocations. For performance I > want all sorting to be performed in memory, and I don't really care > at the moment whether it's in hiperspace or dataspace or whatever. I > successfully used the FILSZ=Ennn parameter until I ran out of space, > so I increased the value to match the reality and since then I > cannot get rid of the dynamic allocation messages. I've tried > DYNALLOC=OFF, HIPRMAX=0, DSPSIZE=0, DSA=0, FILSZ=U0, you name it! in > all sorts of combinations in an attempt to prevent dynamic > allocation of work files, all in vain. I've tried region sizes far! > too big including REGION=0M. I've also tried preallocating > SORTWKxx to VIO data sets, but DFSORT then allocates its own > SORTDKxx data sets instead :( > > So how can I successfully sort my records in storage without using > dynamic allocation with all the rubbish job log messages as a result? > > Many thanks, > Staffan > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
