Just a few thoughts on ways you might be able to reduce the sort work requirement.
Since the input is on tape, do we know if DFSORT is getting accurate file size information? Do you see DFSORT messages in the output like UNKNOWN FILE SIZE or INTERMEDIATE MERGE...? The reason I ask is that if DFSORT doesn't know the file size or incorrectly estimates, it can under allocate virtual storage which makes the sort very inefficient and causes an increase in sort work space requirements. Another option to consider would be splitting the input file, sorting each segment separately, then merging the outputs. Not ideal, but still might run faster than a single large sort using tape sort work. If you could post the DFSORT messages from the job, we might be able to offer some better suggestions. Have a nice day, Dave Betten z/OS Performance Specialist Cloud and Systems Performance IBM Corporation email: bet...@us.ibm.com IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> wrote on 06/07/2018 02:14:09 PM: > From: Jesse 1 Robinson <jesse1.robin...@sce.com> > To: IBM-MAIN@LISTSERV.UA.EDU > Date: 06/07/2018 02:15 PM > Subject: Re: SORTLIB DD > Sent by: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> > > Let me reiterate. The problem job tries to allocate more DASD work > space than *exists* on the system. SORTIN is on tape--multiple > files. We have the capability of putting more volumes online > temporarily, but this is a major PITA and requires intervention from > the Storage boys. I'm hoping that tape SORTWK will get the user over > the occasional hump for this ad hoc non-production job. It does not > have to perform well. It just has to work. > > . > . > J.O.Skip Robinson > Southern California Edison Company > Electric Dragon Team Paddler > SHARE MVS Program Co-Manager > 323-715-0595 Mobile > 626-543-6132 Office ⇐=== NEW > robin...@sce.com > > > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU > ] On Behalf Of R.S. > Sent: Thursday, June 07, 2018 2:49 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: (External):Re: SORTLIB DD > > Get rid of SORTLIB DD > Get rid of SORTWKnn DD > Use dynamic sortwork datasets, optionally set the number of datasets > via OPTION DYNALLOC Don't use tapes for sortwork > > BTW: > What is a size of input data? > How much space do you have for temp datasets? > How much memory can the job use? > > > My €0.02 > > -- > Radoslaw Skorupka > Lodz, Poland > > > > > > > W dniu 2018-06-05 o 18:31, Jesse 1 Robinson pisze: > > We have a DFSORT job that wolfs down enormous amounts of SORTWK > space. It has been exceeding the DASD capacity on the system where > it runs, so we advised the user to point SORTWK to tape instead of > DASD. Now it fails with > > > > IEC130I SORTLIB DD STATEMENT MISSING > > IEF472I CIHM373 STEP010 CIHM373 - COMPLETION CODE - SYSTEM=000 USER=0063 > > > > IBM doc indicates the need for SORTLIB with a 'tape sort'. We have > no working example to share with the user. My question: what should > DD SORTLIB point to? SMPE puts load modules into > > > > SYS1.SORTLIB > > SYS1.SICELINK > > > > Should the user specify only the first one or both? I hate to drag > them into a sysprog guessing game. > > > > . > > . > > J.O.Skip Robinson > > Southern California Edison Company > > Electric Dragon Team Paddler > > SHARE MVS Program Co-Manager > > 323-715-0595 Mobile > > 626-543-6132 Office <===== NEW > > robin...@sce.com<mailto:robin...@sce.com> > > > ---------------------------------------------------------------------- > 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
