I would sort 1 tape at a time then merge them. Or split by the first character of the key, sort each file, then concatenate by the first character of the key. On Sat, Jun 9, 2018 at 12:52 PM Jesse 1 Robinson <[email protected]> wrote: > > In one failing job, we get > > ICE046A E SORT CAPACITY EXCEEDED - RECORD COUNT 41,235,203 > ICE046A E SORT CAPACITY EXCEEDED - RECORD COUNT 41,235,203 > ICE253I 0 RECORDS SORTED - PROCESSED: 41,235,203, EXPECTED: 310,580,760 <== > note very high expectation > > As to how much DASD space is available, I have no idea. Not a storage guy. > Virtual memory is whatever it is at z/OS 2.1. > User tried tape sort but had the job cancelled after 24 hours. Unfortunately > canceler apparently purged job as well, so nothing to look at. > As for why specify SORTLIB DD: DFSORT requires it. Job will not run without > it. > > . > . > 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 > [email protected] > > > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:[email protected]] On > Behalf Of R.S. > Sent: Friday, June 08, 2018 2:33 AM > To: [email protected] > Subject: (External):Re: SORTLIB DD > > Let me ask again: > What is the size of input data? > How much space do you have for temp datasets? > How much memory can the job use? > > > BTW: While sortworks on tape can be justified in case of lack of DASD space, > I still see no reason to specify SORTLIB DD. > > -- > Radoslaw Skorupka > Lodz, Poland > > > > > > > W dniu 2018-06-07 o 20:14, Jesse 1 Robinson pisze: > > 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 > > [email protected] > > > > > > -----Original Message----- > > From: IBM Mainframe Discussion List [mailto:[email protected]] On > > Behalf Of R.S. > > Sent: Thursday, June 07, 2018 2:49 AM > > To: [email protected] > > 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 > >> [email protected]<mailto:[email protected]> > > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN
-- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
