Discussion:
Sort Question
(too old to reply)
Pfister, Nathan
2017-10-02 13:38:30 UTC
Permalink
Raw Message
List;

I have a question dealing with a DFSORT job which I am hoping to get some guidance on.

We have a COBOL program which inconsistently gets a SORT CAPACITY EXCEEDED error. They've changed their cards several times with several different options to try and get this to work. Depending on the month sometimes it works and sometimes it doesn't, with their typical OPTION DYNSPC=1024,DYNALLOC=(SYSDA,59)

The latest run, we added FILSZ=E60000000

In every run it seems to exceed the sort capacity.
+ICE046A 5 PRSPM175.J05 SORT CAPACITY EXCEEDED - RECORD COUNT 58081219

And the following error as well. Not sure

ICE278I 1 59 WORK DATA SETS WERE INSUFFICIENT TO COMPLETE THIS SORT SO 44 ADDITIONAL WERE USED

The funny thing is, this has worked with a DYNALLOC of 24...there is nothing else in the system at the time this was running, and plenty of DASD. Obviously I am overlooking some key piece of information.

Here's the COBOL for the Sort, which doesn't mean too much to me as I am not a COBOL programmer, so I am sure I am missing parts of the sort call, but this is what I was given...

SD S1-SORT-FILE
RECORDING MODE IS F
DATA RECORDS ARE S10-SORT-REC
RECORD CONTAINS 49 CHARACTERS.
01 S10-SORT-REC.
05 S20-SORT-KEY.
10 S20-KEY-LOCATION PIC X(2).
10 S20-KEY-MCO PIC X(2).
10 S20-KEY-PCO PIC X(2).
10 S20-KEY-TREATY PIC X(4).
10 S20-KEY-AS-LINE1 PIC 9(3).
10 S20-KEY-AS-LINE REDEFINES S20-KEY-AS-LINE1
PIC 9(2)V9(1).
05 S20-BREAK-KEY-R1 REDEFINES S20-SORT-KEY.
10 S20-TREATY-BREAK PIC X(10).
10 FILLER PIC X(3).
05 S20-BREAK-KEY-R2 REDEFINES S20-SORT-KEY.
10 S20-PCO-BREAK PIC X(6).
10 FILLER PIC X(7).
05 S20-BREAK-KEY-R3 REDEFINES S20-SORT-KEY.
10 S20-MCO-BREAK PIC X(4).
10 FILLER PIC X(9).
05 S30-SORT-BODY.
10 S30-LINE-TYPE PIC 9(1).
10 S30-MONTHLY-WRITTEN PIC S9(7)V9(2) COMP-3.
10 S30-TO-DATE-WRITTEN PIC S9(7)V9(2) COMP-3.
10 S30-NEW-MONTH PIC S9(7)V9(2) COMP-3.
10 S30-THIS-MONTH-EARNED PIC S9(7)V9(2) COMP-3.
10 S30-INFORCE-TO-DATE PIC S9(7)V9(2) COMP-3.
10 S30-LA-COMMISSION PIC S9(7)V9(2) COMP-3.
10 S30-TOT-COMMISSION PIC S9(7)V9(2) COMP-3.
EJECT

SORT S1-SORT-FILE
ASCENDING KEY
S20-SORT-KEY

If anyone could point me in the right direction on this, I would appreciate it!

Nathan Pfister
Systems Programmer
Donegal Insurance Group

E-MAIL CONFIDENTIALITY NOTICE: This e-mail from Donegal Insurance Group may contain CONFIDENTIAL and legally protected information. If you are not an intended recipient, please do not copy, use or disclose this email or its contents to others; and please notify us by calling toll free (800) 877-0600 x7880 or by replying to this message, and then delete it from your system. Delivery of this email to an unintended recipient is not a waiver of any attorney-client or other applicable privilege.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Vernooij, Kees - KLM , ITOPT1
2017-10-02 13:46:27 UTC
Permalink
Raw Message
Apparently your sortwk's are that small, that many more are needed.

Post your sortparameter, displayable with this job:
//LISTDEF EXEC PGM=ICETOOL
//TOOLMSG DD SYSOUT=*
//DFSMSG DD SYSOUT=*
//SHOWDEF DD SYSOUT=*
//TOOLIN DD *
DEFAULTS LIST(SHOWDEF)
/*

Post the full DFSORT output and the JCL of the step with the error.

This info must give a clue.

Kees.
-----Original Message-----
Behalf Of Pfister, Nathan
Sent: 02 October, 2017 15:40
Subject: Sort Question
List;
I have a question dealing with a DFSORT job which I am hoping to get some guidance on.
We have a COBOL program which inconsistently gets a SORT CAPACITY
EXCEEDED error. They've changed their cards several times with several
different options to try and get this to work. Depending on the month
sometimes it works and sometimes it doesn't, with their typical OPTION
DYNSPC=1024,DYNALLOC=(SYSDA,59)
The latest run, we added FILSZ=E60000000
In every run it seems to exceed the sort capacity.
+ICE046A 5 PRSPM175.J05 SORT CAPACITY EXCEEDED - RECORD COUNT 58081219
And the following error as well. Not sure
ICE278I 1 59 WORK DATA SETS WERE INSUFFICIENT TO COMPLETE THIS SORT SO
44 ADDITIONAL WERE USED
The funny thing is, this has worked with a DYNALLOC of 24...there is
nothing else in the system at the time this was running, and plenty of
DASD. Obviously I am overlooking some key piece of information.
Here's the COBOL for the Sort, which doesn't mean too much to me as I am
not a COBOL programmer, so I am sure I am missing parts of the sort
call, but this is what I was given...
SD S1-SORT-FILE
RECORDING MODE IS F
DATA RECORDS ARE S10-SORT-REC
RECORD CONTAINS 49 CHARACTERS.
01 S10-SORT-REC.
05 S20-SORT-KEY.
10 S20-KEY-LOCATION PIC X(2).
10 S20-KEY-MCO PIC X(2).
10 S20-KEY-PCO PIC X(2).
10 S20-KEY-TREATY PIC X(4).
10 S20-KEY-AS-LINE1 PIC 9(3).
10 S20-KEY-AS-LINE REDEFINES S20-KEY-AS-LINE1
PIC 9(2)V9(1).
05 S20-BREAK-KEY-R1 REDEFINES S20-SORT-KEY.
10 S20-TREATY-BREAK PIC X(10).
10 FILLER PIC X(3).
05 S20-BREAK-KEY-R2 REDEFINES S20-SORT-KEY.
10 S20-PCO-BREAK PIC X(6).
10 FILLER PIC X(7).
05 S20-BREAK-KEY-R3 REDEFINES S20-SORT-KEY.
10 S20-MCO-BREAK PIC X(4).
10 FILLER PIC X(9).
05 S30-SORT-BODY.
10 S30-LINE-TYPE PIC 9(1).
10 S30-MONTHLY-WRITTEN PIC S9(7)V9(2) COMP-3.
10 S30-TO-DATE-WRITTEN PIC S9(7)V9(2) COMP-3.
10 S30-NEW-MONTH PIC S9(7)V9(2) COMP-3.
10 S30-THIS-MONTH-EARNED PIC S9(7)V9(2) COMP-3.
10 S30-INFORCE-TO-DATE PIC S9(7)V9(2) COMP-3.
10 S30-LA-COMMISSION PIC S9(7)V9(2) COMP-3.
10 S30-TOT-COMMISSION PIC S9(7)V9(2) COMP-3.
EJECT
SORT S1-SORT-FILE
ASCENDING KEY
S20-SORT-KEY
If anyone could point me in the right direction on this, I would appreciate it!
Nathan Pfister
Systems Programmer
Donegal Insurance Group
E-MAIL CONFIDENTIALITY NOTICE: This e-mail from Donegal Insurance Group
may contain CONFIDENTIAL and legally protected information. If you are
not an intended recipient, please do not copy, use or disclose this
email or its contents to others; and please notify us by calling toll
free (800) 877-0600 x7880 or by replying to this message, and then
delete it from your system. Delivery of this email to an unintended
recipient is not a waiver of any attorney-client or other applicable
privilege.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
********************************************************
For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message.

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286
********************************************************

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Lizette Koehler
2017-10-02 13:51:32 UTC
Permalink
Raw Message
If possible, post the entire DFSORT output.

There are many elements in the various messages that will help understanding the
issue. I am interesting in the parms being passed to sort, the rec in/out info
and a few other pieces

The Cobol code not so much

Any changes to the program recently like LRECL or increase in records being
processed?



Also, if you did not know this, you can email the dfsort team directly for
assistance.

***@us.ibm.com

Lizette
-----Original Message-----
Behalf Of Vernooij, Kees (ITOPT1) - KLM
Sent: Monday, October 02, 2017 6:47 AM
Subject: Re: Sort Question
Apparently your sortwk's are that small, that many more are needed.
//LISTDEF EXEC PGM=ICETOOL
//TOOLMSG DD SYSOUT=*
//DFSMSG DD SYSOUT=*
//SHOWDEF DD SYSOUT=*
//TOOLIN DD *
DEFAULTS LIST(SHOWDEF)
/*
Post the full DFSORT output and the JCL of the step with the error.
This info must give a clue.
Kees.
-----Original Message-----
On Behalf Of Pfister, Nathan
Sent: 02 October, 2017 15:40
Subject: Sort Question
List;
I have a question dealing with a DFSORT job which I am hoping to get some guidance on.
We have a COBOL program which inconsistently gets a SORT CAPACITY
EXCEEDED error. They've changed their cards several times with
several different options to try and get this to work. Depending on
the month sometimes it works and sometimes it doesn't, with their
typical OPTION
DYNSPC=1024,DYNALLOC=(SYSDA,59)
The latest run, we added FILSZ=E60000000
In every run it seems to exceed the sort capacity.
+ICE046A 5 PRSPM175.J05 SORT CAPACITY EXCEEDED - RECORD COUNT 58081219
And the following error as well. Not sure
ICE278I 1 59 WORK DATA SETS WERE INSUFFICIENT TO COMPLETE THIS SORT SO
44 ADDITIONAL WERE USED
The funny thing is, this has worked with a DYNALLOC of 24...there is
nothing else in the system at the time this was running, and plenty of
DASD. Obviously I am overlooking some key piece of information.
Here's the COBOL for the Sort, which doesn't mean too much to me as I
am not a COBOL programmer, so I am sure I am missing parts of the sort
call, but this is what I was given...
SD S1-SORT-FILE
RECORDING MODE IS F
DATA RECORDS ARE S10-SORT-REC
RECORD CONTAINS 49 CHARACTERS.
01 S10-SORT-REC.
05 S20-SORT-KEY.
10 S20-KEY-LOCATION PIC X(2).
10 S20-KEY-MCO PIC X(2).
10 S20-KEY-PCO PIC X(2).
10 S20-KEY-TREATY PIC X(4).
10 S20-KEY-AS-LINE1 PIC 9(3).
10 S20-KEY-AS-LINE REDEFINES S20-KEY-AS-LINE1
PIC 9(2)V9(1).
05 S20-BREAK-KEY-R1 REDEFINES S20-SORT-KEY.
10 S20-TREATY-BREAK PIC X(10).
10 FILLER PIC X(3).
05 S20-BREAK-KEY-R2 REDEFINES S20-SORT-KEY.
10 S20-PCO-BREAK PIC X(6).
10 FILLER PIC X(7).
05 S20-BREAK-KEY-R3 REDEFINES S20-SORT-KEY.
10 S20-MCO-BREAK PIC X(4).
10 FILLER PIC X(9).
05 S30-SORT-BODY.
10 S30-LINE-TYPE PIC 9(1).
10 S30-MONTHLY-WRITTEN PIC S9(7)V9(2) COMP-3.
10 S30-TO-DATE-WRITTEN PIC S9(7)V9(2) COMP-3.
10 S30-NEW-MONTH PIC S9(7)V9(2) COMP-3.
10 S30-THIS-MONTH-EARNED PIC S9(7)V9(2) COMP-3.
10 S30-INFORCE-TO-DATE PIC S9(7)V9(2) COMP-3.
10 S30-LA-COMMISSION PIC S9(7)V9(2) COMP-3.
10 S30-TOT-COMMISSION PIC S9(7)V9(2) COMP-3.
EJECT
SORT S1-SORT-FILE
ASCENDING KEY
S20-SORT-KEY
If anyone could point me in the right direction on this, I would appreciate it!
Nathan Pfister
Systems Programmer
Donegal Insurance Group
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Pfister, Nathan
2017-10-02 13:56:31 UTC
Permalink
Raw Message
Sorry for the long post, but here's all the info.

Here's the sort parameters:

ITEM JCL (ICEAM1) VALUE INV (ICEAM2) VALUE TSO (ICEAM3) VALUE TSOINV (ICEAM4) VALUE
---------- -------------------- -------------------- -------------------- ---------------------
ENABLE TD1 NONE TD1 NONE
* NONE * NONE

ABCODE MSG MSG MSG MSG
ALTSEQ SEE BELOW SEE BELOW SEE BELOW SEE BELOW
ARESALL 0 0 0 0
ARESINV NOT APPLICABLE 0 NOT APPLICABLE 0
CFW YES YES YES YES
CHALT NO NO NO NO
CHECK YES YES YES YES
CINV YES YES YES YES
COBEXIT COB2 COB2 COB2 COB2
DIAGSIM NO NO NO NO
DSA 128 128 128 128
DSPSIZE MAX MAX MAX MAX
DYNALOC (SYSDA,12) (SYSDA,12) (SYSDA,8) (SYSDA,8)
* (SYSDA,4) * (SYSDA,4) * (SYSDA,4) * (SYSDA,4)
DYNAPCT 75 75 10 10
* 10 * 10
DYNAUTO YES YES YES YES
DYNSPC 1024 1024 256 256
* 256 * 256
EFS NONE NONE NONE NONE
EQUALS YES YES YES YES
* VLBLKSET * VLBLKSET * VLBLKSET * VLBLKSET
ERET ABEND ABEND RC16 RC16
* RC16 * RC16
ESTAE YES YES YES YES
EXITCK STRONG STRONG STRONG STRONG
EXPMAX MAX MAX MAX MAX
EXPOLD 50% 50% 50% 50%
EXPRES 10% 10% 10% 10%
FSZEST NO NO NO NO
GENER NOT APPLICABLE IEBGENR NOT APPLICABLE IEBGENR
GNPAD NOT APPLICABLE RC0 NOT APPLICABLE RC0
GNTRUNC NOT APPLICABLE RC0 NOT APPLICABLE RC0
HIPRMAX OPTIMAL OPTIMAL OPTIMAL OPTIMAL
IDRCPCT NONE NONE NONE NONE
IEXIT NO NO NO NO
IGNCKPT YES YES YES YES
IOMAXBF 35651584 35651584 35651584 35651584
LIST YES YES YES YES
LISTX YES YES YES YES
LOCALE NONE NONE NONE NONE
MAXLIM 2097152 2097152 2097152 2097152
* 1048576 * 1048576 * 1048576 * 1048576
MINLIM 450560 1048576 450560 1048576
* 450560 * 450560
MOSIZE MAX MAX MAX MAX
MOWRK YES YES YES YES
MSGCON CRITICAL CRITICAL NONE NONE
* NONE * NONE
MSGDDN SYSOUT SYSOUT SYSOUT SYSOUT
MSGPRT ALL ALL ALL ALL
NOMSGDD QUIT QUIT QUIT QUIT
NULLOFL RC0 RC0 RC0 RC0
NULLOUT RC0 RC0 RC0 RC0
ODMAXBF 2097152 2097152 2097152 2097152
OUTREL YES YES YES YES
OUTSEC YES YES YES YES
OVERRGN 65536 16384 65536 16384
OVFLO RC0 RC0 RC0 RC0
PAD RC0 RC0 RC0 RC0
PARMDDN DFSPARM DFSPARM DFSPARM DFSPARM
RESALL 4096 4096 4096 4096
RESET YES YES YES YES
RESINV NOT APPLICABLE 49152 NOT APPLICABLE 49152
* 0 * 0
SDB INPUT INPUT INPUT INPUT
SDBMSG NO NO NO NO
SIZE MAX MAX MAX MAX
SMF NO NO NO NO
SOLRF YES YES YES YES
SORTLIB PRIVATE PRIVATE PRIVATE PRIVATE
SPANINC RC16 RC16 RC16 RC16
SVC 218 218 218 218
* 109 * 109 * 109 * 109
SZERO YES YES YES YES
TEXIT NO NO NO NO
TMAXLIM 6291456 6291456 6291456 6291456
TRUNC RC0 RC0 RC0 RC0
TUNE STOR STOR STOR STOR
VERIFY NO NO NO NO
VIO NO NO NO NO
VLLONG NO NO NO NO
VLSCMP NO NO NO NO
VLSHRT NO NO NO NO
VSAMBSP OPTIMAL OPTIMAL OPTIMAL OPTIMAL
VSAMEMT YES YES YES YES
VSAMIO NO NO NO NO
WRKREL YES YES YES YES
WRKSEC YES YES YES YES
Y2PAST 80 80 80 80
ZDPRINT YES YES YES YES

Here's the jobs output:

ICE201I 1 RECORD TYPE IS F - DATA STARTS IN POSITION 1
ICE751I 0 C5-BASE C6-BASE C7-I31999 C8-I29500 E4-BASE C9-BASE E5-I29500 E6-I31999 C4-I31999 E7-I31999
ICE143I 0 BLOCKSET SORT TECHNIQUE SELECTED
ICE250I 0 VISIT http://www.ibm.com/storage/dfsort FOR DFSORT PAPERS, EXAMPLES AND MORE
ICE000I 0 - CONTROL STATEMENTS FOR 5650-ZOS, Z/OS DFSORT V2R2 - 09:09 ON MON OCT 02, 2017 -
OPTION DYNSPC=1024,DYNALLOC=(SYSDA,59),FILSZ=E60000000
ICE140I 0 END OF PARAMETERS FROM DFSPARM - SYSIN OR SORTCNTL/PARAMETER LIST CONTROL STATEMENTS FOLLOW
OPTION EQUALS 00010000
ICE146I 0 END OF STATEMENTS FROM SORTCNTL - PARAMETER LIST STATEMENTS FOLLOW
SORT FIELDS=(0001,0013,CH,A)
RECORD TYPE=F,LENGTH=(000049,,)
OPTION MAINSIZE=00128000
ICE193I 0 ICEAM2 INVOCATION ENVIRONMENT IN EFFECT - ICEAM2 ENVIRONMENT SELECTED
ICE252I 1 PARMLIB OPTIONS WERE MERGED WITH INSTALLATION MODULE DEFAULTS
ICE089I 1 PRSPM175.J05 .P10 , INPUT LRECL = 49, TYPE = F
ICE092I 0 MAIN STORAGE = (128000,1048576,1048576)
ICE156I 0 MAIN STORAGE ABOVE 16MB = (590271,590271)
ICE127I 0 OPTIONS: OVFLO=RC0 ,PAD=RC0 ,TRUNC=RC0 ,SPANINC=RC16,VLSCMP=N,SZERO=Y,RESET=Y,VSAMEMT=Y,DYNSPC=1024
ICE128I 0 OPTIONS: SIZE=1048576,MAXLIM=2097152,MINLIM=1048576,EQUALS=Y,LIST=Y,ERET=ABEND,MSGDDN=SYSOUT
ICE129I 0 OPTIONS: VIO=N,RESDNT=ALL ,SMF=NO ,WRKSEC=Y,OUTSEC=Y,VERIFY=N,CHALT=N,DYNALOC=(SYSDA ,059),ABCODE=MSG
ICE130I 0 OPTIONS: RESALL=0,RESINV=0,SVC=218 ,CHECK=Y,WRKREL=Y,OUTREL=Y,CKPT=N,COBEXIT=COB2
ICE131I 0 OPTIONS: TMAXLIM=6291456,ARESALL=0,ARESINV=0,OVERRGN=16384,CINV=Y,CFW=Y,DSA=0
ICE132I 0 OPTIONS: VLSHRT=N,ZDPRINT=Y,IEXIT=N,TEXIT=N,LISTX=N,EFS=NONE ,EXITCK=S,PARMDDN=DFSPARM ,FSZEST=N
ICE133I 0 OPTIONS: HIPRMAX=OPTIMAL,DSPSIZE=MAX ,ODMAXBF=0,SOLRF=Y,VLLONG=N,VSAMIO=N,MOSIZE=MAX
ICE235I 0 OPTIONS: NULLOUT=RC0
ICE236I 0 OPTIONS: DYNAPCT=75 ,MOWRK=Y,TUNE=STOR,EXPMAX=MAX ,EXPOLD=50% ,EXPRES=10%
ICE750I 0 DC 0 TC 0 CS DSVVV KSZ 17 VSZ 17
ICE752I 0 FSZ=60000000 RE IGN=0 C AVG=56 0 WSP=4364062 E DYN=16461 12256

************************************************
***** DATE ON SYSTEM DATE FILE = 09/30/17 *****
************************************************


****RESERVE MASTER READ COMPLETE ******

********** TOTAL RECORDS READ ---------- 002434065 **********
********** TOTAL RECORDS RETURNED ------ 002434065 **********

ICE247I 0 INTERMEDIATE MERGE ENTERED - PERFORMANCE MAY BE DEGRADED
ICE805I 0 JOBNAME: PRSPM175 , STEPNAME: J05
ICE802I 0 BLOCKSET TECHNIQUE IN CONTROL
ICE906I 0 ST=ABOVE,SR=1048576,RC=0
ICE907I 0 ST=ABOVE,SA=1048560,NF=1,LF=1048560,SF=1048560
ICE906I 0 ST=BELOW,SR=1024000,RC=0
ICE907I 0 ST=BELOW,SA=1023984,NF=1,LF=1023984,SF=1023984
ICE992I 0 RA 0 WR 0 TR 44
ICE887I 0 CSES 0,0,0 ES 0,0,0
ICE886I 0 SYS 0 TSTG 0 FS 0 INIT 0 MAX 0 LEN 0
ICE915I 0 MOFSZ=4120,MOSZ=0,MOSYS=46973(5),MOSTG=46973,MEML=1048004(1)
ICE916I 0 MOFR=0402,MOVR=VV
ICE996I 0 ESM=13361357,ESO=232815,ESR=1336135,ESP=7168,ESS=16384,CES=14438400,HSZ=16777216
ICE997I 0 HWSP=2050781,HMAX=0,MOMAX=12025088,ASV=12025222,EQ=I3,HN=1
ICE898I 0 OMAX=12895727,NMAX=13361357,ENQT=12025222,CMAX=1204224,HU=99,BUN=12256,MD=NK,M0,DU=83,DR=0,HN=1
ICE880I 0 QP=3 QA=3 HI=1678 LI=1676 MI=1678 TZ=18822 N1=16384 N2=16384 SZ=169 HN=1
ICE889I 0 CT=MAX , SB=3, L=0, D=0000, CCW=1MBI
ICE901I 0 W 01PP15 53PP15 44PP15 1APP15 12PP15 67PP15 27PP15 34PP15
ICE901I 0 W 2FPP15 66PP15 45PP15 0BPP15 2BPP15 32PP15 26PP15 06PP15
ICE901I 0 W 22PP15 1FPP15 3EPP15 2EPP15 1BPP15 05PP15 4APP15 46PP15
ICE901I 0 W 65PP15 04PP15 07PP15 4BPP15 09PP15 30PP15 36PP15 59PP15
ICE901I 0 W 3APP11 18PP11 03NP11 0ANP11 3DNP11 4FNP11 31NP11 21NP11
ICE901I 0 W 54NP11 4ENP11 1DNP11 16NP11 4CNP11 3CNP11 17NP11 08NP11
ICE901I 0 W 11NP11 56NP11 57NP11 15NP11 39NP11 1CNP11 49NP11 62NP11
ICE901I 0 W 0DNP11 19NP11 60NP11 14NP11 25NP11 13NP11 3FNP11 40NP11
ICE901I 0 W 41NP11 42NP11 43NP11 23NP11 0CNP11 1ENP11 47NP11 48NP11
ICE901I 0 W 37NP11 35NP11 2CNP11 2DNP11 4DNP11 2ANP11 0FNP11 50NP11
ICE901I 0 W 51NP11 52NP11 02NP11 29NP11 55NP11 0ENP11 33NP11 58NP11
ICE901I 0 W 20NP11 5ANP11 5BNP11 5CNP11 5DNP11 5ENP11 5FNP11 3BNP11
ICE901I 0 W 61NP11 38NP11 63NP11 64NP11 28NP11 24NP11 10NP11
SARPAGE 6
ICE906I 1 ST=ABOVE,SR=590271,RC=0
ICE907I 1 ST=ABOVE,SA=590248,NF=1,LF=590248,SF=590248
ICE906I 1 ST=BELOW,SR=452737,RC=0
ICE907I 1 ST=BELOW,SA=444528,NF=1,LF=444528,SF=444528
ICE046A 5 SORT CAPACITY EXCEEDED - RECORD COUNT 58081219
ICE253I 0 RECORDS SORTED - PROCESSED: 58081219, EXPECTED: 60000000
ICE753I 1 FWK=(59,16461) SWK=(0,0) TWK=(0,0) RWK=(44,176) TOTAL=(103,16637) BLK=12256
ICE278I 1 59 WORK DATA SETS WERE INSUFFICIENT TO COMPLETE THIS SORT SO 44 ADDITIONAL WERE USED
ICE751I 1 DE-BASE D5-I29741 D3-BASE E1-BASE D6-BASE C4-I31999 C4-I31999 C4-I31999 C4-I31999 C4-I31999 C4-I31999
ICE751I 1 C4-I31999 C4-I31999 C4-I31999 C4-I31999 C4-I31999 C4-I31999 C4-I31999 C4-I31999 C4-I31999 C4-I31999 C4-I31999
ICE751I 1 C4-I31999 C4-I31999 C4-I31999 C4-I31999 C4-I31999 C4-I31999 C4-I31999 C4-I31999 C4-I31999 C4-I31999 C4-I31999
ICE751I 1 C4-I31999 C4-I31999 C4-I31999 C4-I31999 C4-I31999 C4-I31999 C4-I31999 C4-I31999 C4-I31999 C4-I31999 C4-I31999
ICE751I 1 C4-I31999 C4-I31999 C4-I31999 C4-I31999 C4-I31999 C4-I31999 E8-I29741
ICE052I 0 END OF DFSORT
CEE3250C The system or user abend U 046 R=NULL was issued.
From compile unit D314DC2A at entry point D314DC2A at compile unit offset +000017AA at entry offset +000017AA
at address 0B4017AA.
<> LEAID ENTERED (LEVEL 02/26/2016 AT 17.55)
<> LEAID LEAID109 ABEND-AID PROCESSING IGNORED. ABEND SPECIFIED NO DUMP
<> LEAID PROCESSING COMPLETE. RC=4

JCL:
//*********************************************************************
//* P10 - D314DC2A - HOME OFFICE ACCOUNT
//*********************************************************************
//P10 EXEC PGM=D314DC2A,
// COND=(0,LT)
//*
//DATEFLE DD DSN=&SYS..RS.MDBC.DATEFLE(0),
// DISP=SHR
//*
//GTAMLIB DD DSN=&SYS..PM.RVOM.GTAMLIB, 0
// DISP=SHR
//*
//RESVIND DD DSN=&SYS..RS.MDBM.D311DA2R(0), 000
// DISP=SHR
//*
//SORTCNTL DD DSN=&SYS..ENDEVOR.CCARDS(&L.SORTCNT),
// DISP=SHR
//*
//DFSPARM DD DSN=&SYS..ENDEVOR.CCARDS(&L.RS17510),
// DISP=SHR
//*
//SYSIN DD DUMMY
//*
//PRINTER DD SYSOUT=(B,&L.RSM1752)
//*
//SYSOUT DD SYSOUT=*
//SYSPRINT DD SYSOUT=*
//SYSUDUMP DD SYSOUT=*
//SYSABEND DD SYSOUT=*
//*
//*
//*
//*********************************************************************
//* END OF PROC PRSPM175
//*********************************************************************

The PARM currently is:
OPTION DYNSPC=1024,DYNALLOC=(SYSDA,59),FILSZ=E60000000



-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Vernooij, Kees (ITOPT1) - KLM
Sent: Monday, October 02, 2017 9:47 AM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: Sort Question

Apparently your sortwk's are that small, that many more are needed.

Post your sortparameter, displayable with this job:
//LISTDEF EXEC PGM=ICETOOL
//TOOLMSG DD SYSOUT=*
//DFSMSG DD SYSOUT=*
//SHOWDEF DD SYSOUT=*
//TOOLIN DD *
DEFAULTS LIST(SHOWDEF)
/*

Post the full DFSORT output and the JCL of the step with the error.

This info must give a clue.

Kees.
-----Original Message-----
On Behalf Of Pfister, Nathan
Sent: 02 October, 2017 15:40
Subject: Sort Question
List;
I have a question dealing with a DFSORT job which I am hoping to get some guidance on.
We have a COBOL program which inconsistently gets a SORT CAPACITY
EXCEEDED error. They've changed their cards several times with
several different options to try and get this to work. Depending on
the month sometimes it works and sometimes it doesn't, with their
typical OPTION
DYNSPC=1024,DYNALLOC=(SYSDA,59)
The latest run, we added FILSZ=E60000000
In every run it seems to exceed the sort capacity.
+ICE046A 5 PRSPM175.J05 SORT CAPACITY EXCEEDED - RECORD COUNT 58081219
And the following error as well. Not sure
ICE278I 1 59 WORK DATA SETS WERE INSUFFICIENT TO COMPLETE THIS SORT SO
44 ADDITIONAL WERE USED
The funny thing is, this has worked with a DYNALLOC of 24...there is
nothing else in the system at the time this was running, and plenty of
DASD. Obviously I am overlooking some key piece of information.
Here's the COBOL for the Sort, which doesn't mean too much to me as I
am not a COBOL programmer, so I am sure I am missing parts of the sort
call, but this is what I was given...
SD S1-SORT-FILE
RECORDING MODE IS F
DATA RECORDS ARE S10-SORT-REC
RECORD CONTAINS 49 CHARACTERS.
01 S10-SORT-REC.
05 S20-SORT-KEY.
10 S20-KEY-LOCATION PIC X(2).
10 S20-KEY-MCO PIC X(2).
10 S20-KEY-PCO PIC X(2).
10 S20-KEY-TREATY PIC X(4).
10 S20-KEY-AS-LINE1 PIC 9(3).
10 S20-KEY-AS-LINE REDEFINES S20-KEY-AS-LINE1
PIC 9(2)V9(1).
05 S20-BREAK-KEY-R1 REDEFINES S20-SORT-KEY.
10 S20-TREATY-BREAK PIC X(10).
10 FILLER PIC X(3).
05 S20-BREAK-KEY-R2 REDEFINES S20-SORT-KEY.
10 S20-PCO-BREAK PIC X(6).
10 FILLER PIC X(7).
05 S20-BREAK-KEY-R3 REDEFINES S20-SORT-KEY.
10 S20-MCO-BREAK PIC X(4).
10 FILLER PIC X(9).
05 S30-SORT-BODY.
10 S30-LINE-TYPE PIC 9(1).
10 S30-MONTHLY-WRITTEN PIC S9(7)V9(2) COMP-3.
10 S30-TO-DATE-WRITTEN PIC S9(7)V9(2) COMP-3.
10 S30-NEW-MONTH PIC S9(7)V9(2) COMP-3.
10 S30-THIS-MONTH-EARNED PIC S9(7)V9(2) COMP-3.
10 S30-INFORCE-TO-DATE PIC S9(7)V9(2) COMP-3.
10 S30-LA-COMMISSION PIC S9(7)V9(2) COMP-3.
10 S30-TOT-COMMISSION PIC S9(7)V9(2) COMP-3.
EJECT
SORT S1-SORT-FILE
ASCENDING KEY
S20-SORT-KEY
If anyone could point me in the right direction on this, I would appreciate it!
Nathan Pfister
Systems Programmer
Donegal Insurance Group
E-MAIL CONFIDENTIALITY NOTICE: This e-mail from Donegal Insurance
Group may contain CONFIDENTIAL and legally protected information. If
you are not an intended recipient, please do not copy, use or disclose
this email or its contents to others; and please notify us by calling
toll free (800) 877-0600 x7880 or by replying to this message, and
then delete it from your system. Delivery of this email to an
unintended recipient is not a waiver of any attorney-client or other
applicable privilege.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send
********************************************************
For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message.

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286
********************************************************

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email to ***@listserv.ua.edu<mailto:***@listserv.ua.edu> with the message: INFO IBM-MAIN

E-MAIL CONFIDENTIALITY NOTICE: This e-mail from Donegal Insurance Group may contain CONFIDENTIAL and legally protected information. If you are not an intended recipient, please do not copy, use or disclose this email or its contents to others; and please notify us by calling toll free (800) 877-0600 x7880 or by replying to this message, and then delete it from your system. Delivery of this email to an unintended recipient is not a waiver of any attorney-client or other applicable privilege.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
David Betten
2017-10-02 15:43:44 UTC
Permalink
Raw Message
I see a couple things the DFSORT output

The reason for the small mainsize and DSA=0 is because the program is
passing MAINSIZE=00128000

ICE146I 0 END OF STATEMENTS FROM SORTCNTL - PARAMETER LIST STATEMENTS
FOLLOW

 SORT FIELDS=(0001,0013,CH,A)

 RECORD TYPE=F,LENGTH=(000049,,)

 OPTION MAINSIZE=00128000



The small mainsize is leading to an intermediate merge.

ICE247I 0 INTERMEDIATE MERGE ENTERED - PERFORMANCE MAY BE DEGRADED


An intermediate merge happens when the sortworks are so fragmented, DFSORT
must do an intermediate merge before it can do the final merge to SORTOUT.
This greatly increases the sort work requirement as well as the elapsed
time. So the earlier recommendation of passing MAINSIZE=MAX via SORTCNTL
or DFSPARM should resolve this.


Have a nice day,
Dave Betten
z/OS Performance Specialist
Cloud and Systems Performance
IBM Corporation
Date: 10/02/2017 03:57 PM
Subject: Re: Sort Question
Sorry for the long post, but here's all the info.
ITEM JCL (ICEAM1) VALUE INV (ICEAM2) VALUE TSO
(ICEAM3) VALUE TSOINV (ICEAM4) VALUE
---------- -------------------- --------------------
-------------------- ---------------------
ENABLE TD1 NONE TD1
NONE
* NONE * NONE
ABCODE MSG MSG MSG
MSG
ALTSEQ SEE BELOW SEE BELOW SEE
BELOW SEE BELOW
ARESALL 0 0 0
0
ARESINV NOT APPLICABLE 0 NOT APPLICABLE 0
CFW YES YES YES
YES
CHALT NO NO NO
NO
CHECK YES YES YES
YES
CINV YES YES YES
YES
COBEXIT COB2 COB2
COB2 COB2
DIAGSIM NO NO NO
NO
DSA 128 128 128
128
DSPSIZE MAX MAX MAX
MAX
DYNALOC (SYSDA,12) (SYSDA,12)
(SYSDA,8) (SYSDA,8)
* (SYSDA,4) * (SYSDA,4) *
(SYSDA,4) * (SYSDA,4)
DYNAPCT 75 75 10
10
* 10 * 10
DYNAUTO YES YES YES
YES
DYNSPC 1024 1024 256
256
* 256 * 256
EFS NONE NONE
NONE NONE
EQUALS YES YES YES
YES
* VLBLKSET * VLBLKSET *
VLBLKSET * VLBLKSET
ERET ABEND ABEND
RC16 RC16
* RC16 * RC16
ESTAE YES YES YES
YES
EXITCK STRONG STRONG
STRONG STRONG
EXPMAX MAX MAX MAX
MAX
EXPOLD 50% 50% 50%
50%
EXPRES 10% 10% 10%
10%
FSZEST NO NO NO
NO
GENER NOT APPLICABLE IEBGENR NOT
APPLICABLE IEBGENR
GNPAD NOT APPLICABLE RC0 NOT
APPLICABLE RC0
GNTRUNC NOT APPLICABLE RC0 NOT
APPLICABLE RC0
HIPRMAX OPTIMAL OPTIMAL
OPTIMAL OPTIMAL
IDRCPCT NONE NONE
NONE NONE
IEXIT NO NO NO
NO
IGNCKPT YES YES YES
YES
IOMAXBF 35651584 35651584
35651584 35651584
LIST YES YES YES
YES
LISTX YES YES YES
YES
LOCALE NONE NONE
NONE NONE
MAXLIM 2097152 2097152
2097152 2097152
* 1048576 * 1048576 *
1048576 * 1048576
MINLIM 450560 1048576
450560 1048576
* 450560 *
450560
MOSIZE MAX MAX MAX
MAX
MOWRK YES YES YES
YES
MSGCON CRITICAL CRITICAL
NONE NONE
* NONE * NONE
MSGDDN SYSOUT SYSOUT
SYSOUT SYSOUT
MSGPRT ALL ALL ALL
ALL
NOMSGDD QUIT QUIT
QUIT QUIT
NULLOFL RC0 RC0 RC0
RC0
NULLOUT RC0 RC0 RC0
RC0
ODMAXBF 2097152 2097152
2097152 2097152
OUTREL YES YES YES
YES
OUTSEC YES YES YES
YES
OVERRGN 65536 16384
65536 16384
OVFLO RC0 RC0 RC0
RC0
PAD RC0 RC0 RC0
RC0
PARMDDN DFSPARM DFSPARM
DFSPARM DFSPARM
RESALL 4096 4096
4096 4096
RESET YES YES YES
YES
RESINV NOT APPLICABLE 49152 NOT
APPLICABLE 49152
* 0
* 0
SDB INPUT INPUT
INPUT INPUT
SDBMSG NO NO NO
NO
SIZE MAX MAX MAX
MAX
SMF NO NO NO
NO
SOLRF YES YES YES
YES
SORTLIB PRIVATE PRIVATE
PRIVATE PRIVATE
SPANINC RC16 RC16
RC16 RC16
SVC 218 218 218
218
* 109 * 109 *
109 * 109
SZERO YES YES YES
YES
TEXIT NO NO NO
NO
TMAXLIM 6291456 6291456
6291456 6291456
TRUNC RC0 RC0 RC0
RC0
TUNE STOR STOR
STOR STOR
VERIFY NO NO NO
NO
VIO NO NO NO
NO
VLLONG NO NO NO
NO
VLSCMP NO NO NO
NO
VLSHRT NO NO NO
NO
VSAMBSP OPTIMAL OPTIMAL
OPTIMAL OPTIMAL
VSAMEMT YES YES YES
YES
VSAMIO NO NO NO
NO
WRKREL YES YES YES
YES
WRKSEC YES YES YES
YES
Y2PAST 80 80 80
80
ZDPRINT YES YES YES
YES
ICE201I 1 RECORD TYPE IS F - DATA STARTS IN POSITION 1
ICE751I 0 C5-BASE C6-BASE C7-I31999 C8-I29500 E4-BASE C9-BASE
E5-I29500 E6-I31999 C4-I31999 E7-I31999
ICE143I 0 BLOCKSET SORT TECHNIQUE SELECTED
ICE250I 0 VISIT http://www.ibm.com/storage/dfsort FOR DFSORT PAPERS, EXAMPLES AND MORE
09 ON MON OCT 02, 2017 -
OPTION DYNSPC=1024,DYNALLOC=(SYSDA,59),FILSZ=E60000000
ICE140I 0 END OF PARAMETERS FROM DFSPARM - SYSIN OR SORTCNTL/
PARAMETER LIST CONTROL STATEMENTS FOLLOW
OPTION EQUALS
00010000
ICE146I 0 END OF STATEMENTS FROM SORTCNTL - PARAMETER LIST STATEMENTS FOLLOW
SORT FIELDS=(0001,0013,CH,A)
RECORD TYPE=F,LENGTH=(000049,,)
OPTION MAINSIZE=00128000
ICE193I 0 ICEAM2 INVOCATION ENVIRONMENT IN EFFECT - ICEAM2
ENVIRONMENT SELECTED
ICE252I 1 PARMLIB OPTIONS WERE MERGED WITH INSTALLATION MODULE DEFAULTS
ICE089I 1 PRSPM175.J05 .P10 , INPUT LRECL = 49, TYPE = F
ICE092I 0 MAIN STORAGE = (128000,1048576,1048576)
ICE156I 0 MAIN STORAGE ABOVE 16MB = (590271,590271)
ICE127I 0 OPTIONS: OVFLO=RC0 ,PAD=RC0 ,TRUNC=RC0
,SPANINC=RC16,VLSCMP=N,SZERO=Y,RESET=Y,VSAMEMT=Y,DYNSPC=1024
SIZE=1048576,MAXLIM=2097152,MINLIM=1048576,EQUALS=Y,LIST=Y,ERET=ABEND,MSGDDN=SYSOUT
ICE129I 0 OPTIONS: VIO=N,RESDNT=ALL ,SMF=NO
,WRKSEC=Y,OUTSEC=Y,VERIFY=N,CHALT=N,DYNALOC=(SYSDA ,059),ABCODE=MSG
ICE130I 0 OPTIONS: RESALL=0,RESINV=0,SVC=218
,CHECK=Y,WRKREL=Y,OUTREL=Y,CKPT=N,COBEXIT=COB2
TMAXLIM=6291456,ARESALL=0,ARESINV=0,OVERRGN=16384,CINV=Y,CFW=Y,DSA=0
VLSHRT=N,ZDPRINT=Y,IEXIT=N,TEXIT=N,LISTX=N,EFS=NONE
,EXITCK=S,PARMDDN=DFSPARM ,FSZEST=N
ICE133I 0 OPTIONS: HIPRMAX=OPTIMAL,DSPSIZE=MAX
,ODMAXBF=0,SOLRF=Y,VLLONG=N,VSAMIO=N,MOSIZE=MAX
ICE235I 0 OPTIONS: NULLOUT=RC0
ICE236I 0 OPTIONS: DYNAPCT=75 ,MOWRK=Y,TUNE=STOR,EXPMAX=MAX
,EXPOLD=50% ,EXPRES=10%
ICE750I 0 DC 0 TC 0 CS DSVVV KSZ 17 VSZ 17
ICE752I 0 FSZ=60000000 RE IGN=0 C AVG=56 0 WSP=4364062 E DYN=16461 12256
************************************************
***** DATE ON SYSTEM DATE FILE = 09/30/17 *****
************************************************
****RESERVE MASTER READ COMPLETE ******
********** TOTAL RECORDS READ ---------- 002434065 **********
********** TOTAL RECORDS RETURNED ------ 002434065 **********
ICE247I 0 INTERMEDIATE MERGE ENTERED - PERFORMANCE MAY BE DEGRADED
ICE805I 0 JOBNAME: PRSPM175 , STEPNAME: J05
ICE802I 0 BLOCKSET TECHNIQUE IN CONTROL
ICE906I 0 ST=ABOVE,SR=1048576,RC=0
ICE907I 0 ST=ABOVE,SA=1048560,NF=1,LF=1048560,SF=1048560
ICE906I 0 ST=BELOW,SR=1024000,RC=0
ICE907I 0 ST=BELOW,SA=1023984,NF=1,LF=1023984,SF=1023984
ICE992I 0 RA 0 WR 0 TR 44
ICE887I 0 CSES 0,0,0 ES 0,0,0
ICE886I 0 SYS 0 TSTG 0 FS 0 INIT 0 MAX 0 LEN 0
ICE915I 0 MOFSZ=4120,MOSZ=0,MOSYS=46973(5),MOSTG=46973,MEML=1048004(1)
ICE916I 0 MOFR=0402,MOVR=VV
ICE996I 0
ESM=13361357,ESO=232815,ESR=1336135,ESP=7168,ESS=16384,CES=14438400,HSZ=16777216
ICE997I 0 HWSP=2050781,HMAX=0,MOMAX=12025088,ASV=12025222,EQ=I3,HN=1
ICE898I 0
OMAX=12895727,NMAX=13361357,ENQT=12025222,CMAX=1204224,HU=99,BUN=12256,MD=NK,M0,DU=83,DR=0,HN=1
ICE880I 0 QP=3 QA=3 HI=1678 LI=1676 MI=1678 TZ=18822 N1=16384
N2=16384 SZ=169 HN=1
ICE889I 0 CT=MAX , SB=3, L=0, D=0000, CCW=1MBI
ICE901I 0 W 01PP15 53PP15 44PP15 1APP15 12PP15 67PP15 27PP15 34PP15
ICE901I 0 W 2FPP15 66PP15 45PP15 0BPP15 2BPP15 32PP15 26PP15 06PP15
ICE901I 0 W 22PP15 1FPP15 3EPP15 2EPP15 1BPP15 05PP15 4APP15 46PP15
ICE901I 0 W 65PP15 04PP15 07PP15 4BPP15 09PP15 30PP15 36PP15 59PP15
ICE901I 0 W 3APP11 18PP11 03NP11 0ANP11 3DNP11 4FNP11 31NP11 21NP11
ICE901I 0 W 54NP11 4ENP11 1DNP11 16NP11 4CNP11 3CNP11 17NP11 08NP11
ICE901I 0 W 11NP11 56NP11 57NP11 15NP11 39NP11 1CNP11 49NP11 62NP11
ICE901I 0 W 0DNP11 19NP11 60NP11 14NP11 25NP11 13NP11 3FNP11 40NP11
ICE901I 0 W 41NP11 42NP11 43NP11 23NP11 0CNP11 1ENP11 47NP11 48NP11
ICE901I 0 W 37NP11 35NP11 2CNP11 2DNP11 4DNP11 2ANP11 0FNP11 50NP11
ICE901I 0 W 51NP11 52NP11 02NP11 29NP11 55NP11 0ENP11 33NP11 58NP11
ICE901I 0 W 20NP11 5ANP11 5BNP11 5CNP11 5DNP11 5ENP11 5FNP11 3BNP11
ICE901I 0 W 61NP11 38NP11 63NP11 64NP11 28NP11 24NP11 10NP11
SARPAGE 6
ICE906I 1 ST=ABOVE,SR=590271,RC=0
ICE907I 1 ST=ABOVE,SA=590248,NF=1,LF=590248,SF=590248
ICE906I 1 ST=BELOW,SR=452737,RC=0
ICE907I 1 ST=BELOW,SA=444528,NF=1,LF=444528,SF=444528
ICE046A 5 SORT CAPACITY EXCEEDED - RECORD COUNT 58081219
ICE253I 0 RECORDS SORTED - PROCESSED: 58081219, EXPECTED: 60000000
ICE753I 1 FWK=(59,16461) SWK=(0,0) TWK=(0,0) RWK=(44,176)
TOTAL=(103,16637) BLK=12256
ICE278I 1 59 WORK DATA SETS WERE INSUFFICIENT TO COMPLETE THIS SORT
SO 44 ADDITIONAL WERE USED
ICE751I 1 DE-BASE D5-I29741 D3-BASE E1-BASE D6-BASE C4-
I31999 C4-I31999 C4-I31999 C4-I31999 C4-I31999 C4-I31999
ICE751I 1 C4-I31999 C4-I31999 C4-I31999 C4-I31999 C4-I31999 C4-
I31999 C4-I31999 C4-I31999 C4-I31999 C4-I31999 C4-I31999
ICE751I 1 C4-I31999 C4-I31999 C4-I31999 C4-I31999 C4-I31999 C4-
I31999 C4-I31999 C4-I31999 C4-I31999 C4-I31999 C4-I31999
ICE751I 1 C4-I31999 C4-I31999 C4-I31999 C4-I31999 C4-I31999 C4-
I31999 C4-I31999 C4-I31999 C4-I31999 C4-I31999 C4-I31999
ICE751I 1 C4-I31999 C4-I31999 C4-I31999 C4-I31999 C4-I31999 C4-
I31999 E8-I29741
ICE052I 0 END OF DFSORT
CEE3250C The system or user abend U 046 R=NULL was issued.
From compile unit D314DC2A at entry point D314DC2A at
compile unit offset +000017AA at entry offset +000017AA
at address 0B4017AA.
<> LEAID ENTERED (LEVEL 02/26/2016 AT 17.55)
<> LEAID LEAID109 ABEND-AID PROCESSING IGNORED. ABEND SPECIFIED NO DUMP
<> LEAID PROCESSING COMPLETE. RC=4
//*********************************************************************
//* P10 - D314DC2A - HOME OFFICE ACCOUNT
//*********************************************************************
//P10 EXEC PGM=D314DC2A,
// COND=(0,LT)
//*
//DATEFLE DD DSN=&SYS..RS.MDBC.DATEFLE(0),
// DISP=SHR
//*
//GTAMLIB DD DSN=&SYS..PM.RVOM.GTAMLIB, 0
// DISP=SHR
//*
//RESVIND DD DSN=&SYS..RS.MDBM.D311DA2R(0), 000
// DISP=SHR
//*
//SORTCNTL DD DSN=&SYS..ENDEVOR.CCARDS(&L.SORTCNT),
// DISP=SHR
//*
//DFSPARM DD DSN=&SYS..ENDEVOR.CCARDS(&L.RS17510),
// DISP=SHR
//*
//SYSIN DD DUMMY
//*
//PRINTER DD SYSOUT=(B,&L.RSM1752)
//*
//SYSOUT DD SYSOUT=*
//SYSPRINT DD SYSOUT=*
//SYSUDUMP DD SYSOUT=*
//SYSABEND DD SYSOUT=*
//*
//*
//*
//*********************************************************************
//* END OF PROC PRSPM175
//*********************************************************************
OPTION DYNSPC=1024,DYNALLOC=(SYSDA,59),FILSZ=E60000000
-----Original Message-----
] On Behalf Of Vernooij, Kees (ITOPT1) - KLM
Sent: Monday, October 02, 2017 9:47 AM
Subject: Re: Sort Question
Apparently your sortwk's are that small, that many more are needed.
//LISTDEF EXEC PGM=ICETOOL
//TOOLMSG DD SYSOUT=*
//DFSMSG DD SYSOUT=*
//SHOWDEF DD SYSOUT=*
//TOOLIN DD *
DEFAULTS LIST(SHOWDEF)
/*
Post the full DFSORT output and the JCL of the step with the error.
This info must give a clue.
Kees.
-----Original Message-----
On Behalf Of Pfister, Nathan
Sent: 02 October, 2017 15:40
Subject: Sort Question
List;
I have a question dealing with a DFSORT job which I am hoping to get some guidance on.
We have a COBOL program which inconsistently gets a SORT CAPACITY
EXCEEDED error. They've changed their cards several times with
several different options to try and get this to work. Depending on
the month sometimes it works and sometimes it doesn't, with their
typical OPTION
DYNSPC=1024,DYNALLOC=(SYSDA,59)
The latest run, we added FILSZ=E60000000
In every run it seems to exceed the sort capacity.
+ICE046A 5 PRSPM175.J05 SORT CAPACITY EXCEEDED - RECORD COUNT 58081219
And the following error as well. Not sure
ICE278I 1 59 WORK DATA SETS WERE INSUFFICIENT TO COMPLETE THIS SORT SO
44 ADDITIONAL WERE USED
The funny thing is, this has worked with a DYNALLOC of 24...there is
nothing else in the system at the time this was running, and plenty of
DASD. Obviously I am overlooking some key piece of information.
Here's the COBOL for the Sort, which doesn't mean too much to me as I
am not a COBOL programmer, so I am sure I am missing parts of the sort
call, but this is what I was given...
SD S1-SORT-FILE
RECORDING MODE IS F
DATA RECORDS ARE S10-SORT-REC
RECORD CONTAINS 49 CHARACTERS.
01 S10-SORT-REC.
05 S20-SORT-KEY.
10 S20-KEY-LOCATION PIC X(2).
10 S20-KEY-MCO PIC X(2).
10 S20-KEY-PCO PIC X(2).
10 S20-KEY-TREATY PIC X(4).
10 S20-KEY-AS-LINE1 PIC 9(3).
10 S20-KEY-AS-LINE REDEFINES S20-KEY-AS-LINE1
PIC 9(2)V9(1).
05 S20-BREAK-KEY-R1 REDEFINES S20-SORT-KEY.
10 S20-TREATY-BREAK PIC X(10).
10 FILLER PIC X(3).
05 S20-BREAK-KEY-R2 REDEFINES S20-SORT-KEY.
10 S20-PCO-BREAK PIC X(6).
10 FILLER PIC X(7).
05 S20-BREAK-KEY-R3 REDEFINES S20-SORT-KEY.
10 S20-MCO-BREAK PIC X(4).
10 FILLER PIC X(9).
05 S30-SORT-BODY.
10 S30-LINE-TYPE PIC 9(1).
10 S30-MONTHLY-WRITTEN PIC S9(7)V9(2) COMP-3.
10 S30-TO-DATE-WRITTEN PIC S9(7)V9(2) COMP-3.
10 S30-NEW-MONTH PIC S9(7)V9(2) COMP-3.
10 S30-THIS-MONTH-EARNED PIC S9(7)V9(2) COMP-3.
10 S30-INFORCE-TO-DATE PIC S9(7)V9(2) COMP-3.
10 S30-LA-COMMISSION PIC S9(7)V9(2) COMP-3.
10 S30-TOT-COMMISSION PIC S9(7)V9(2) COMP-3.
EJECT
SORT S1-SORT-FILE
ASCENDING KEY
S20-SORT-KEY
If anyone could point me in the right direction on this, I would appreciate it!
Nathan Pfister
Systems Programmer
Donegal Insurance Group
E-MAIL CONFIDENTIALITY NOTICE: This e-mail from Donegal Insurance
Group may contain CONFIDENTIAL and legally protected information. If
you are not an intended recipient, please do not copy, use or disclose
this email or its contents to others; and please notify us by calling
toll free (800) 877-0600 x7880 or by replying to this message, and
then delete it from your system. Delivery of this email to an
unintended recipient is not a waiver of any attorney-client or other
applicable privilege.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send
with the message: INFO IBM-MAIN
********************************************************
https://urldefense.proofpoint.com/v2/url?
u=http-3A__www.klm.com&d=DwIFAg&c=jf_iaSHvJObTbx-
siA1ZOg&r=Ae5kuKdL4c910EvfgxokfP66Pm216FnhUBn6gZrM7hw&m=eqeibEw0l0cCuikkdn5VXr0MvBo6ppDwNzEGZ1aTTLc&s=ZEJImDzmqtCV7zJgH5fUvKmdagrwyJSyO4UCFQK9_OE&e=
. This e-mail and any attachment may contain confidential and
privileged material intended for the addressee only. If you are not
the addressee, you are notified that no part of the e-mail or any
attachment may be disclosed, copied or distributed, and that any
other action related to this e-mail or attachment is strictly
prohibited, and may be unlawful. If you have received this e-mail by
error, please notify the sender immediately by return e-mail, and
delete this message.
Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/
or its employees shall not be liable for the incorrect or incomplete
transmission of this e-mail or any attachments, nor responsible for
any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal
Dutch Airlines) is registered in Amstelveen, The Netherlands, with
registered number 33014286
********************************************************
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send
with the message: INFO IBM-MAIN
E-MAIL CONFIDENTIALITY NOTICE: This e-mail from Donegal Insurance
Group may contain CONFIDENTIAL and legally protected information. If
you are not an intended recipient, please do not copy, use or
disclose this email or its contents to others; and please notify us
by calling toll free (800) 877-0600 x7880 or by replying to this
message, and then delete it from your system. Delivery of this email
to an unintended recipient is not a waiver of any attorney-client or
other applicable privilege.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Farley, Peter x23353
2017-10-02 16:00:10 UTC
Permalink
Raw Message
And for your COBOL programmers, if they do not use DFSPARM / $ORTPARM DD statements in the JCL to control SORT parameters, there are two COBOL-defined "special registers" that can be used to specify storage values.

Below is a copy of the definition of those data areas from the COBOL V5.2 manual.

HTH

Peter

SORT-CORE-SIZE
The SORT-CORE-SIZE special register is the name of a binary data item that you
can use to specify the number of bytes of storage available to the sort utility.
Restriction: The SORT-CORE-SIZE special register is not applicable to sorting a
table with the format 2 SORT statement.
The SORT-CORE-SIZE special register has the implicit definition:
01 SORT-CORE-SIZE GLOBAL PICTURE S9(8) USAGE BINARY VALUE ZERO.
When used in nested programs, this special register is implicitly defined with the
global attribute in the outermost program.
SORT-CORE-SIZE can be used in place of the MAINSIZE or RESINV control
statements in the sort control file:
-- The 'MAINSIZE=' option control statement keyword is equivalent to
SORT-CORE-SIZE with a positive value.
-- The 'RESINV=' option control statement keyword is equivalent to
SORT-CORE-SIZE with a negative value.
-- The 'MAINSIZE=MAX' option control statement keyword is equivalent to
SORT-CORE-SIZE with a value of +999999 or +99999999.
You can specify the SORT-CORE-SIZE special register in a function wherever an
integer argument is allowed.

SORT-FILE-SIZE
The SORT-FILE-SIZE special register is the name of a binary data item that you can
use to specify the estimated number of records in the sort input file, file-name-1.
Restriction: The SORT-FILE-SIZE special register is not applicable to sorting a
table with the format 2 SORT statement.
The SORT-FILE-SIZE special register has the implicit definition:
01 SORT-FILE-SIZE GLOBAL PICTURE S9(8) USAGE BINARY VALUE ZERO.
When used in nested programs, this special register is implicitly defined with the
global attribute in the outermost program.
SORT-FILE-SIZE is equivalent to the 'FILSZ=Ennn' control statement in the sort
control file.
You can specify the SORT-FILE-SIZE special register in a function wherever an
integer argument is allowed.

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of David Betten
Sent: Monday, October 02, 2017 11:45 AM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: Sort Question

I see a couple things the DFSORT output

The reason for the small mainsize and DSA=0 is because the program is
passing MAINSIZE=00128000

ICE146I 0 END OF STATEMENTS FROM SORTCNTL - PARAMETER LIST STATEMENTS
FOLLOW

 SORT FIELDS=(0001,0013,CH,A)

 RECORD TYPE=F,LENGTH=(000049,,)

 OPTION MAINSIZE=00128000



The small mainsize is leading to an intermediate merge.

ICE247I 0 INTERMEDIATE MERGE ENTERED - PERFORMANCE MAY BE DEGRADED


An intermediate merge happens when the sortworks are so fragmented, DFSORT
must do an intermediate merge before it can do the final merge to SORTOUT.
This greatly increases the sort work requirement as well as the elapsed
time. So the earlier recommendation of passing MAINSIZE=MAX via SORTCNTL
or DFSPARM should resolve this.


Have a nice day,
Dave Betten
z/OS Performance Specialist
Cloud and Systems Performance
IBM Corporation
Date: 10/02/2017 03:57 PM
Subject: Re: Sort Question
Sorry for the long post, but here's all the info.
ITEM JCL (ICEAM1) VALUE INV (ICEAM2) VALUE TSO
(ICEAM3) VALUE TSOINV (ICEAM4) VALUE
---------- -------------------- --------------------
-------------------- ---------------------
ENABLE TD1 NONE TD1
NONE
* NONE * NONE
ABCODE MSG MSG MSG
MSG
ALTSEQ SEE BELOW SEE BELOW SEE
BELOW SEE BELOW
ARESALL 0 0 0
0
ARESINV NOT APPLICABLE 0 NOT APPLICABLE 0
CFW YES YES YES
YES
CHALT NO NO NO
NO
CHECK YES YES YES
YES
CINV YES YES YES
YES
COBEXIT COB2 COB2
COB2 COB2
DIAGSIM NO NO NO
NO
DSA 128 128 128
128
DSPSIZE MAX MAX MAX
MAX
DYNALOC (SYSDA,12) (SYSDA,12)
(SYSDA,8) (SYSDA,8)
* (SYSDA,4) * (SYSDA,4) *
(SYSDA,4) * (SYSDA,4)
DYNAPCT 75 75 10
10
* 10 * 10
DYNAUTO YES YES YES
YES
DYNSPC 1024 1024 256
256
* 256 * 256
EFS NONE NONE
NONE NONE
EQUALS YES YES YES
YES
* VLBLKSET * VLBLKSET *
VLBLKSET * VLBLKSET
ERET ABEND ABEND
RC16 RC16
* RC16 * RC16
ESTAE YES YES YES
YES
EXITCK STRONG STRONG
STRONG STRONG
EXPMAX MAX MAX MAX
MAX
EXPOLD 50% 50% 50%
50%
EXPRES 10% 10% 10%
10%
FSZEST NO NO NO
NO
GENER NOT APPLICABLE IEBGENR NOT
APPLICABLE IEBGENR
GNPAD NOT APPLICABLE RC0 NOT
APPLICABLE RC0
GNTRUNC NOT APPLICABLE RC0 NOT
APPLICABLE RC0
HIPRMAX OPTIMAL OPTIMAL
OPTIMAL OPTIMAL
IDRCPCT NONE NONE
NONE NONE
IEXIT NO NO NO
NO
IGNCKPT YES YES YES
YES
IOMAXBF 35651584 35651584
35651584 35651584
LIST YES YES YES
YES
LISTX YES YES YES
YES
LOCALE NONE NONE
NONE NONE
MAXLIM 2097152 2097152
2097152 2097152
* 1048576 * 1048576 *
1048576 * 1048576
MINLIM 450560 1048576
450560 1048576
* 450560 *
450560
MOSIZE MAX MAX MAX
MAX
MOWRK YES YES YES
YES
MSGCON CRITICAL CRITICAL
NONE NONE
* NONE * NONE
MSGDDN SYSOUT SYSOUT
SYSOUT SYSOUT
MSGPRT ALL ALL ALL
ALL
NOMSGDD QUIT QUIT
QUIT QUIT
NULLOFL RC0 RC0 RC0
RC0
NULLOUT RC0 RC0 RC0
RC0
ODMAXBF 2097152 2097152
2097152 2097152
OUTREL YES YES YES
YES
OUTSEC YES YES YES
YES
OVERRGN 65536 16384
65536 16384
OVFLO RC0 RC0 RC0
RC0
PAD RC0 RC0 RC0
RC0
PARMDDN DFSPARM DFSPARM
DFSPARM DFSPARM
RESALL 4096 4096
4096 4096
RESET YES YES YES
YES
RESINV NOT APPLICABLE 49152 NOT
APPLICABLE 49152
* 0
* 0
SDB INPUT INPUT
INPUT INPUT
SDBMSG NO NO NO
NO
SIZE MAX MAX MAX
MAX
SMF NO NO NO
NO
SOLRF YES YES YES
YES
SORTLIB PRIVATE PRIVATE
PRIVATE PRIVATE
SPANINC RC16 RC16
RC16 RC16
SVC 218 218 218
218
* 109 * 109 *
109 * 109
SZERO YES YES YES
YES
TEXIT NO NO NO
NO
TMAXLIM 6291456 6291456
6291456 6291456
TRUNC RC0 RC0 RC0
RC0
TUNE STOR STOR
STOR STOR
VERIFY NO NO NO
NO
VIO NO NO NO
NO
VLLONG NO NO NO
NO
VLSCMP NO NO NO
NO
VLSHRT NO NO NO
NO
VSAMBSP OPTIMAL OPTIMAL
OPTIMAL OPTIMAL
VSAMEMT YES YES YES
YES
VSAMIO NO NO NO
NO
WRKREL YES YES YES
YES
WRKSEC YES YES YES
YES
Y2PAST 80 80 80
80
ZDPRINT YES YES YES
YES
ICE201I 1 RECORD TYPE IS F - DATA STARTS IN POSITION 1
ICE751I 0 C5-BASE C6-BASE C7-I31999 C8-I29500 E4-BASE C9-BASE
E5-I29500 E6-I31999 C4-I31999 E7-I31999
ICE143I 0 BLOCKSET SORT TECHNIQUE SELECTED
ICE250I 0 VISIT http://www.ibm.com/storage/dfsort FOR DFSORT PAPERS, EXAMPLES AND MORE
09 ON MON OCT 02, 2017 -
OPTION DYNSPC=1024,DYNALLOC=(SYSDA,59),FILSZ=E60000000
ICE140I 0 END OF PARAMETERS FROM DFSPARM - SYSIN OR SORTCNTL/
PARAMETER LIST CONTROL STATEMENTS FOLLOW
OPTION EQUALS
00010000
ICE146I 0 END OF STATEMENTS FROM SORTCNTL - PARAMETER LIST STATEMENTS FOLLOW
SORT FIELDS=(0001,0013,CH,A)
RECORD TYPE=F,LENGTH=(000049,,)
OPTION MAINSIZE=00128000
ICE193I 0 ICEAM2 INVOCATION ENVIRONMENT IN EFFECT - ICEAM2
ENVIRONMENT SELECTED
ICE252I 1 PARMLIB OPTIONS WERE MERGED WITH INSTALLATION MODULE DEFAULTS
ICE089I 1 PRSPM175.J05 .P10 , INPUT LRECL = 49, TYPE = F
ICE092I 0 MAIN STORAGE = (128000,1048576,1048576)
ICE156I 0 MAIN STORAGE ABOVE 16MB = (590271,590271)
ICE127I 0 OPTIONS: OVFLO=RC0 ,PAD=RC0 ,TRUNC=RC0
,SPANINC=RC16,VLSCMP=N,SZERO=Y,RESET=Y,VSAMEMT=Y,DYNSPC=1024
SIZE=1048576,MAXLIM=2097152,MINLIM=1048576,EQUALS=Y,LIST=Y,ERET=ABEND,MSGDDN=SYSOUT
ICE129I 0 OPTIONS: VIO=N,RESDNT=ALL ,SMF=NO
,WRKSEC=Y,OUTSEC=Y,VERIFY=N,CHALT=N,DYNALOC=(SYSDA ,059),ABCODE=MSG
ICE130I 0 OPTIONS: RESALL=0,RESINV=0,SVC=218
,CHECK=Y,WRKREL=Y,OUTREL=Y,CKPT=N,COBEXIT=COB2
TMAXLIM=6291456,ARESALL=0,ARESINV=0,OVERRGN=16384,CINV=Y,CFW=Y,DSA=0
VLSHRT=N,ZDPRINT=Y,IEXIT=N,TEXIT=N,LISTX=N,EFS=NONE
,EXITCK=S,PARMDDN=DFSPARM ,FSZEST=N
ICE133I 0 OPTIONS: HIPRMAX=OPTIMAL,DSPSIZE=MAX
,ODMAXBF=0,SOLRF=Y,VLLONG=N,VSAMIO=N,MOSIZE=MAX
ICE235I 0 OPTIONS: NULLOUT=RC0
ICE236I 0 OPTIONS: DYNAPCT=75 ,MOWRK=Y,TUNE=STOR,EXPMAX=MAX
,EXPOLD=50% ,EXPRES=10%
ICE750I 0 DC 0 TC 0 CS DSVVV KSZ 17 VSZ 17
ICE752I 0 FSZ=60000000 RE IGN=0 C AVG=56 0 WSP=4364062 E DYN=16461 12256
************************************************
***** DATE ON SYSTEM DATE FILE = 09/30/17 *****
************************************************
****RESERVE MASTER READ COMPLETE ******
********** TOTAL RECORDS READ ---------- 002434065 **********
********** TOTAL RECORDS RETURNED ------ 002434065 **********
ICE247I 0 INTERMEDIATE MERGE ENTERED - PERFORMANCE MAY BE DEGRADED
ICE805I 0 JOBNAME: PRSPM175 , STEPNAME: J05
ICE802I 0 BLOCKSET TECHNIQUE IN CONTROL
ICE906I 0 ST=ABOVE,SR=1048576,RC=0
ICE907I 0 ST=ABOVE,SA=1048560,NF=1,LF=1048560,SF=1048560
ICE906I 0 ST=BELOW,SR=1024000,RC=0
ICE907I 0 ST=BELOW,SA=1023984,NF=1,LF=1023984,SF=1023984
ICE992I 0 RA 0 WR 0 TR 44
ICE887I 0 CSES 0,0,0 ES 0,0,0
ICE886I 0 SYS 0 TSTG 0 FS 0 INIT 0 MAX 0 LEN 0
ICE915I 0 MOFSZ=4120,MOSZ=0,MOSYS=46973(5),MOSTG=46973,MEML=1048004(1)
ICE916I 0 MOFR=0402,MOVR=VV
ICE996I 0
ESM=13361357,ESO=232815,ESR=1336135,ESP=7168,ESS=16384,CES=14438400,HSZ=16777216
ICE997I 0 HWSP=2050781,HMAX=0,MOMAX=12025088,ASV=12025222,EQ=I3,HN=1
ICE898I 0
OMAX=12895727,NMAX=13361357,ENQT=12025222,CMAX=1204224,HU=99,BUN=12256,MD=NK,M0,DU=83,DR=0,HN=1
ICE880I 0 QP=3 QA=3 HI=1678 LI=1676 MI=1678 TZ=18822 N1=16384
N2=16384 SZ=169 HN=1
ICE889I 0 CT=MAX , SB=3, L=0, D=0000, CCW=1MBI
ICE901I 0 W 01PP15 53PP15 44PP15 1APP15 12PP15 67PP15 27PP15 34PP15
ICE901I 0 W 2FPP15 66PP15 45PP15 0BPP15 2BPP15 32PP15 26PP15 06PP15
ICE901I 0 W 22PP15 1FPP15 3EPP15 2EPP15 1BPP15 05PP15 4APP15 46PP15
ICE901I 0 W 65PP15 04PP15 07PP15 4BPP15 09PP15 30PP15 36PP15 59PP15
ICE901I 0 W 3APP11 18PP11 03NP11 0ANP11 3DNP11 4FNP11 31NP11 21NP11
ICE901I 0 W 54NP11 4ENP11 1DNP11 16NP11 4CNP11 3CNP11 17NP11 08NP11
ICE901I 0 W 11NP11 56NP11 57NP11 15NP11 39NP11 1CNP11 49NP11 62NP11
ICE901I 0 W 0DNP11 19NP11 60NP11 14NP11 25NP11 13NP11 3FNP11 40NP11
ICE901I 0 W 41NP11 42NP11 43NP11 23NP11 0CNP11 1ENP11 47NP11 48NP11
ICE901I 0 W 37NP11 35NP11 2CNP11 2DNP11 4DNP11 2ANP11 0FNP11 50NP11
ICE901I 0 W 51NP11 52NP11 02NP11 29NP11 55NP11 0ENP11 33NP11 58NP11
ICE901I 0 W 20NP11 5ANP11 5BNP11 5CNP11 5DNP11 5ENP11 5FNP11 3BNP11
ICE901I 0 W 61NP11 38NP11 63NP11 64NP11 28NP11 24NP11 10NP11
SARPAGE 6
ICE906I 1 ST=ABOVE,SR=590271,RC=0
ICE907I 1 ST=ABOVE,SA=590248,NF=1,LF=590248,SF=590248
ICE906I 1 ST=BELOW,SR=452737,RC=0
ICE907I 1 ST=BELOW,SA=444528,NF=1,LF=444528,SF=444528
ICE046A 5 SORT CAPACITY EXCEEDED - RECORD COUNT 58081219
ICE253I 0 RECORDS SORTED - PROCESSED: 58081219, EXPECTED: 60000000
ICE753I 1 FWK=(59,16461) SWK=(0,0) TWK=(0,0) RWK=(44,176)
TOTAL=(103,16637) BLK=12256
ICE278I 1 59 WORK DATA SETS WERE INSUFFICIENT TO COMPLETE THIS SORT
SO 44 ADDITIONAL WERE USED
ICE751I 1 DE-BASE D5-I29741 D3-BASE E1-BASE D6-BASE C4-
I31999 C4-I31999 C4-I31999 C4-I31999 C4-I31999 C4-I31999
ICE751I 1 C4-I31999 C4-I31999 C4-I31999 C4-I31999 C4-I31999 C4-
I31999 C4-I31999 C4-I31999 C4-I31999 C4-I31999 C4-I31999
ICE751I 1 C4-I31999 C4-I31999 C4-I31999 C4-I31999 C4-I31999 C4-
I31999 C4-I31999 C4-I31999 C4-I31999 C4-I31999 C4-I31999
ICE751I 1 C4-I31999 C4-I31999 C4-I31999 C4-I31999 C4-I31999 C4-
I31999 C4-I31999 C4-I31999 C4-I31999 C4-I31999 C4-I31999
ICE751I 1 C4-I31999 C4-I31999 C4-I31999 C4-I31999 C4-I31999 C4-
I31999 E8-I29741
ICE052I 0 END OF DFSORT
CEE3250C The system or user abend U 046 R=NULL was issued.
From compile unit D314DC2A at entry point D314DC2A at
compile unit offset +000017AA at entry offset +000017AA
at address 0B4017AA.
<> LEAID ENTERED (LEVEL 02/26/2016 AT 17.55)
<> LEAID LEAID109 ABEND-AID PROCESSING IGNORED. ABEND SPECIFIED NO DUMP
<> LEAID PROCESSING COMPLETE. RC=4
//*********************************************************************
//* P10 - D314DC2A - HOME OFFICE ACCOUNT
//*********************************************************************
//P10 EXEC PGM=D314DC2A,
// COND=(0,LT)
//*
//DATEFLE DD DSN=&SYS..RS.MDBC.DATEFLE(0),
// DISP=SHR
//*
//GTAMLIB DD DSN=&SYS..PM.RVOM.GTAMLIB, 0
// DISP=SHR
//*
//RESVIND DD DSN=&SYS..RS.MDBM.D311DA2R(0), 000
// DISP=SHR
//*
//SORTCNTL DD DSN=&SYS..ENDEVOR.CCARDS(&L.SORTCNT),
// DISP=SHR
//*
//DFSPARM DD DSN=&SYS..ENDEVOR.CCARDS(&L.RS17510),
// DISP=SHR
//*
//SYSIN DD DUMMY
//*
//PRINTER DD SYSOUT=(B,&L.RSM1752)
//*
//SYSOUT DD SYSOUT=*
//SYSPRINT DD SYSOUT=*
//SYSUDUMP DD SYSOUT=*
//SYSABEND DD SYSOUT=*
//*
//*
//*
//*********************************************************************
//* END OF PROC PRSPM175
//*********************************************************************
OPTION DYNSPC=1024,DYNALLOC=(SYSDA,59),FILSZ=E60000000
-----Original Message-----
] On Behalf Of Vernooij, Kees (ITOPT1) - KLM
Sent: Monday, October 02, 2017 9:47 AM
Subject: Re: Sort Question
Apparently your sortwk's are that small, that many more are needed.
//LISTDEF EXEC PGM=ICETOOL
//TOOLMSG DD SYSOUT=*
//DFSMSG DD SYSOUT=*
//SHOWDEF DD SYSOUT=*
//TOOLIN DD *
DEFAULTS LIST(SHOWDEF)
/*
Post the full DFSORT output and the JCL of the step with the error.
This info must give a clue.
Kees.
-----Original Message-----
On Behalf Of Pfister, Nathan
Sent: 02 October, 2017 15:40
Subject: Sort Question
List;
I have a question dealing with a DFSORT job which I am hoping to get some guidance on.
We have a COBOL program which inconsistently gets a SORT CAPACITY
EXCEEDED error. They've changed their cards several times with
several different options to try and get this to work. Depending on
the month sometimes it works and sometimes it doesn't, with their
typical OPTION
DYNSPC=1024,DYNALLOC=(SYSDA,59)
The latest run, we added FILSZ=E60000000
In every run it seems to exceed the sort capacity.
+ICE046A 5 PRSPM175.J05 SORT CAPACITY EXCEEDED - RECORD COUNT 58081219
And the following error as well. Not sure
ICE278I 1 59 WORK DATA SETS WERE INSUFFICIENT TO COMPLETE THIS SORT SO
44 ADDITIONAL WERE USED
The funny thing is, this has worked with a DYNALLOC of 24...there is
nothing else in the system at the time this was running, and plenty of
DASD. Obviously I am overlooking some key piece of information.
Here's the COBOL for the Sort, which doesn't mean too much to me as I
am not a COBOL programmer, so I am sure I am missing parts of the sort
call, but this is what I was given...
SD S1-SORT-FILE
RECORDING MODE IS F
DATA RECORDS ARE S10-SORT-REC
RECORD CONTAINS 49 CHARACTERS.
01 S10-SORT-REC.
05 S20-SORT-KEY.
10 S20-KEY-LOCATION PIC X(2).
10 S20-KEY-MCO PIC X(2).
10 S20-KEY-PCO PIC X(2).
10 S20-KEY-TREATY PIC X(4).
10 S20-KEY-AS-LINE1 PIC 9(3).
10 S20-KEY-AS-LINE REDEFINES S20-KEY-AS-LINE1
PIC 9(2)V9(1).
05 S20-BREAK-KEY-R1 REDEFINES S20-SORT-KEY.
10 S20-TREATY-BREAK PIC X(10).
10 FILLER PIC X(3).
05 S20-BREAK-KEY-R2 REDEFINES S20-SORT-KEY.
10 S20-PCO-BREAK PIC X(6).
10 FILLER PIC X(7).
05 S20-BREAK-KEY-R3 REDEFINES S20-SORT-KEY.
10 S20-MCO-BREAK PIC X(4).
10 FILLER PIC X(9).
05 S30-SORT-BODY.
10 S30-LINE-TYPE PIC 9(1).
10 S30-MONTHLY-WRITTEN PIC S9(7)V9(2) COMP-3.
10 S30-TO-DATE-WRITTEN PIC S9(7)V9(2) COMP-3.
10 S30-NEW-MONTH PIC S9(7)V9(2) COMP-3.
10 S30-THIS-MONTH-EARNED PIC S9(7)V9(2) COMP-3.
10 S30-INFORCE-TO-DATE PIC S9(7)V9(2) COMP-3.
10 S30-LA-COMMISSION PIC S9(7)V9(2) COMP-3.
10 S30-TOT-COMMISSION PIC S9(7)V9(2) COMP-3.
EJECT
SORT S1-SORT-FILE
ASCENDING KEY
S20-SORT-KEY
If anyone could point me in the right direction on this, I would appreciate it!
Nathan Pfister
Systems Programmer
Donegal Insurance Group
E-MAIL CONFIDENTIALITY NOTICE: This e-mail from Donegal Insurance
Group may contain CONFIDENTIAL and legally protected information. If
you are not an intended recipient, please do not copy, use or disclose
this email or its contents to others; and please notify us by calling
toll free (800) 877-0600 x7880 or by replying to this message, and
then delete it from your system. Delivery of this email to an
unintended recipient is not a waiver of any attorney-client or other
applicable privilege.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send
with the message: INFO IBM-MAIN
********************************************************
https://urldefense.proofpoint.com/v2/url?
u=http-3A__www.klm.com&d=DwIFAg&c=jf_iaSHvJObTbx-
siA1ZOg&r=Ae5kuKdL4c910EvfgxokfP66Pm216FnhUBn6gZrM7hw&m=eqeibEw0l0cCuikkdn5VXr0MvBo6ppDwNzEGZ1aTTLc&s=ZEJImDzmqtCV7zJgH5fUvKmdagrwyJSyO4UCFQK9_OE&e=
. This e-mail and any attachment may contain confidential and
privileged material intended for the addressee only. If you are not
the addressee, you are notified that no part of the e-mail or any
attachment may be disclosed, copied or distributed, and that any
other action related to this e-mail or attachment is strictly
prohibited, and may be unlawful. If you have received this e-mail by
error, please notify the sender immediately by return e-mail, and
delete this message.
Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/
or its employees shall not be liable for the incorrect or incomplete
transmission of this e-mail or any attachments, nor responsible for
any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal
Dutch Airlines) is registered in Amstelveen, The Netherlands, with
registered number 33014286
********************************************************
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send
with the message: INFO IBM-MAIN
E-MAIL CONFIDENTIALITY NOTICE: This e-mail from Donegal Insurance
Group may contain CONFIDENTIAL and legally protected information. If
you are not an intended recipient, please do not copy, use or
disclose this email or its contents to others; and please notify us
by calling toll free (800) 877-0600 x7880 or by replying to this
message, and then delete it from your system. Delivery of this email
to an unintended recipient is not a waiver of any attorney-client or
other applicable privilege.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
R D Boenig
2017-10-05 16:14:47 UTC
Permalink
Raw Message
Thanx Dave!




From: David Betten <***@US.IBM.COM>
To: IBM-***@LISTSERV.UA.EDU
Date: 10/02/2017 09:45 AM
Subject: Re: Sort Question
Sent by: IBM Mainframe Discussion List <IBM-***@LISTSERV.UA.EDU>



I see a couple things the DFSORT output

The reason for the small mainsize and DSA=0 is because the program is
passing MAINSIZE=00128000

ICE146I 0 END OF STATEMENTS FROM SORTCNTL - PARAMETER LIST STATEMENTS
FOLLOW

 SORT FIELDS=(0001,0013,CH,A)

 RECORD TYPE=F,LENGTH=(000049,,)

 OPTION MAINSIZE=00128000



The small mainsize is leading to an intermediate merge.

ICE247I 0 INTERMEDIATE MERGE ENTERED - PERFORMANCE MAY BE DEGRADED


An intermediate merge happens when the sortworks are so fragmented, DFSORT
must do an intermediate merge before it can do the final merge to SORTOUT.
This greatly increases the sort work requirement as well as the elapsed
time. So the earlier recommendation of passing MAINSIZE=MAX via SORTCNTL
or DFSPARM should resolve this.


Have a nice day,
Dave Betten
z/OS Performance Specialist
Cloud and Systems Performance
IBM Corporation
Date: 10/02/2017 03:57 PM
Subject: Re: Sort Question
Sorry for the long post, but here's all the info.
ITEM JCL (ICEAM1) VALUE INV (ICEAM2) VALUE TSO
(ICEAM3) VALUE TSOINV (ICEAM4) VALUE
---------- -------------------- --------------------
-------------------- ---------------------
ENABLE TD1 NONE TD1
NONE
* NONE * NONE
ABCODE MSG MSG MSG
MSG
ALTSEQ SEE BELOW SEE BELOW SEE
BELOW SEE BELOW
ARESALL 0 0 0
0
ARESINV NOT APPLICABLE 0 NOT APPLICABLE 0
CFW YES YES YES
YES
CHALT NO NO NO
NO
CHECK YES YES YES
YES
CINV YES YES YES
YES
COBEXIT COB2 COB2
COB2 COB2
DIAGSIM NO NO NO
NO
DSA 128 128 128
128
DSPSIZE MAX MAX MAX
MAX
DYNALOC (SYSDA,12) (SYSDA,12)
(SYSDA,8) (SYSDA,8)
* (SYSDA,4) * (SYSDA,4) *
(SYSDA,4) * (SYSDA,4)
DYNAPCT 75 75 10
10
* 10 * 10
DYNAUTO YES YES YES
YES
DYNSPC 1024 1024 256
256
* 256 * 256
EFS NONE NONE
NONE NONE
EQUALS YES YES YES
YES
* VLBLKSET * VLBLKSET *
VLBLKSET * VLBLKSET
ERET ABEND ABEND
RC16 RC16
* RC16 * RC16
ESTAE YES YES YES
YES
EXITCK STRONG STRONG
STRONG STRONG
EXPMAX MAX MAX MAX
MAX
EXPOLD 50% 50% 50%
50%
EXPRES 10% 10% 10%
10%
FSZEST NO NO NO
NO
GENER NOT APPLICABLE IEBGENR NOT
APPLICABLE IEBGENR
GNPAD NOT APPLICABLE RC0 NOT
APPLICABLE RC0
GNTRUNC NOT APPLICABLE RC0 NOT
APPLICABLE RC0
HIPRMAX OPTIMAL OPTIMAL
OPTIMAL OPTIMAL
IDRCPCT NONE NONE
NONE NONE
IEXIT NO NO NO
NO
IGNCKPT YES YES YES
YES
IOMAXBF 35651584 35651584
35651584 35651584
LIST YES YES YES
YES
LISTX YES YES YES
YES
LOCALE NONE NONE
NONE NONE
MAXLIM 2097152 2097152
2097152 2097152
* 1048576 * 1048576 *
1048576 * 1048576
MINLIM 450560 1048576
450560 1048576
* 450560 *
450560
MOSIZE MAX MAX MAX
MAX
MOWRK YES YES YES
YES
MSGCON CRITICAL CRITICAL
NONE NONE
* NONE * NONE
MSGDDN SYSOUT SYSOUT
SYSOUT SYSOUT
MSGPRT ALL ALL ALL
ALL
NOMSGDD QUIT QUIT
QUIT QUIT
NULLOFL RC0 RC0 RC0
RC0
NULLOUT RC0 RC0 RC0
RC0
ODMAXBF 2097152 2097152
2097152 2097152
OUTREL YES YES YES
YES
OUTSEC YES YES YES
YES
OVERRGN 65536 16384
65536 16384
OVFLO RC0 RC0 RC0
RC0
PAD RC0 RC0 RC0
RC0
PARMDDN DFSPARM DFSPARM
DFSPARM DFSPARM
RESALL 4096 4096
4096 4096
RESET YES YES YES
YES
RESINV NOT APPLICABLE 49152 NOT
APPLICABLE 49152
* 0
* 0
SDB INPUT INPUT
INPUT INPUT
SDBMSG NO NO NO
NO
SIZE MAX MAX MAX
MAX
SMF NO NO NO
NO
SOLRF YES YES YES
YES
SORTLIB PRIVATE PRIVATE
PRIVATE PRIVATE
SPANINC RC16 RC16
RC16 RC16
SVC 218 218 218
218
* 109 * 109 *
109 * 109
SZERO YES YES YES
YES
TEXIT NO NO NO
NO
TMAXLIM 6291456 6291456
6291456 6291456
TRUNC RC0 RC0 RC0
RC0
TUNE STOR STOR
STOR STOR
VERIFY NO NO NO
NO
VIO NO NO NO
NO
VLLONG NO NO NO
NO
VLSCMP NO NO NO
NO
VLSHRT NO NO NO
NO
VSAMBSP OPTIMAL OPTIMAL
OPTIMAL OPTIMAL
VSAMEMT YES YES YES
YES
VSAMIO NO NO NO
NO
WRKREL YES YES YES
YES
WRKSEC YES YES YES
YES
Y2PAST 80 80 80
80
ZDPRINT YES YES YES
YES
ICE201I 1 RECORD TYPE IS F - DATA STARTS IN POSITION 1
ICE751I 0 C5-BASE C6-BASE C7-I31999 C8-I29500 E4-BASE C9-BASE
E5-I29500 E6-I31999 C4-I31999 E7-I31999
ICE143I 0 BLOCKSET SORT TECHNIQUE SELECTED
ICE250I 0 VISIT http://www.ibm.com/storage/dfsort FOR DFSORT PAPERS, EXAMPLES AND MORE
09 ON MON OCT 02, 2017 -
OPTION DYNSPC=1024,DYNALLOC=(SYSDA,59),FILSZ=E60000000
ICE140I 0 END OF PARAMETERS FROM DFSPARM - SYSIN OR SORTCNTL/
PARAMETER LIST CONTROL STATEMENTS FOLLOW
OPTION EQUALS
00010000
ICE146I 0 END OF STATEMENTS FROM SORTCNTL - PARAMETER LIST STATEMENTS FOLLOW
SORT FIELDS=(0001,0013,CH,A)
RECORD TYPE=F,LENGTH=(000049,,)
OPTION MAINSIZE=00128000
ICE193I 0 ICEAM2 INVOCATION ENVIRONMENT IN EFFECT - ICEAM2
ENVIRONMENT SELECTED
ICE252I 1 PARMLIB OPTIONS WERE MERGED WITH INSTALLATION MODULE DEFAULTS
ICE089I 1 PRSPM175.J05 .P10 , INPUT LRECL = 49, TYPE = F
ICE092I 0 MAIN STORAGE = (128000,1048576,1048576)
ICE156I 0 MAIN STORAGE ABOVE 16MB = (590271,590271)
ICE127I 0 OPTIONS: OVFLO=RC0 ,PAD=RC0 ,TRUNC=RC0
,SPANINC=RC16,VLSCMP=N,SZERO=Y,RESET=Y,VSAMEMT=Y,DYNSPC=1024
SIZE=1048576,MAXLIM=2097152,MINLIM=1048576,EQUALS=Y,LIST=Y,ERET=ABEND,MSGDDN=SYSOUT
ICE129I 0 OPTIONS: VIO=N,RESDNT=ALL ,SMF=NO
,WRKSEC=Y,OUTSEC=Y,VERIFY=N,CHALT=N,DYNALOC=(SYSDA ,059),ABCODE=MSG
ICE130I 0 OPTIONS: RESALL=0,RESINV=0,SVC=218
,CHECK=Y,WRKREL=Y,OUTREL=Y,CKPT=N,COBEXIT=COB2
TMAXLIM=6291456,ARESALL=0,ARESINV=0,OVERRGN=16384,CINV=Y,CFW=Y,DSA=0
VLSHRT=N,ZDPRINT=Y,IEXIT=N,TEXIT=N,LISTX=N,EFS=NONE
,EXITCK=S,PARMDDN=DFSPARM ,FSZEST=N
ICE133I 0 OPTIONS: HIPRMAX=OPTIMAL,DSPSIZE=MAX
,ODMAXBF=0,SOLRF=Y,VLLONG=N,VSAMIO=N,MOSIZE=MAX
ICE235I 0 OPTIONS: NULLOUT=RC0
ICE236I 0 OPTIONS: DYNAPCT=75 ,MOWRK=Y,TUNE=STOR,EXPMAX=MAX
,EXPOLD=50% ,EXPRES=10%
ICE750I 0 DC 0 TC 0 CS DSVVV KSZ 17 VSZ 17
ICE752I 0 FSZ=60000000 RE IGN=0 C AVG=56 0 WSP=4364062 E DYN=16461 12256
************************************************
***** DATE ON SYSTEM DATE FILE = 09/30/17 *****
************************************************
****RESERVE MASTER READ COMPLETE ******
********** TOTAL RECORDS READ ---------- 002434065 **********
********** TOTAL RECORDS RETURNED ------ 002434065 **********
ICE247I 0 INTERMEDIATE MERGE ENTERED - PERFORMANCE MAY BE DEGRADED
ICE805I 0 JOBNAME: PRSPM175 , STEPNAME: J05
ICE802I 0 BLOCKSET TECHNIQUE IN CONTROL
ICE906I 0 ST=ABOVE,SR=1048576,RC=0
ICE907I 0 ST=ABOVE,SA=1048560,NF=1,LF=1048560,SF=1048560
ICE906I 0 ST=BELOW,SR=1024000,RC=0
ICE907I 0 ST=BELOW,SA=1023984,NF=1,LF=1023984,SF=1023984
ICE992I 0 RA 0 WR 0 TR 44
ICE887I 0 CSES 0,0,0 ES 0,0,0
ICE886I 0 SYS 0 TSTG 0 FS 0 INIT 0 MAX 0 LEN 0
ICE915I 0 MOFSZ=4120,MOSZ=0,MOSYS=46973(5),MOSTG=46973,MEML=1048004(1)
ICE916I 0 MOFR=0402,MOVR=VV
ICE996I 0
ESM=13361357,ESO=232815,ESR=1336135,ESP=7168,ESS=16384,CES=14438400,HSZ=16777216
ICE997I 0 HWSP=2050781,HMAX=0,MOMAX=12025088,ASV=12025222,EQ=I3,HN=1
ICE898I 0
OMAX=12895727,NMAX=13361357,ENQT=12025222,CMAX=1204224,HU=99,BUN=12256,MD=NK,M0,DU=83,DR=0,HN=1
ICE880I 0 QP=3 QA=3 HI=1678 LI=1676 MI=1678 TZ=18822 N1=16384
N2=16384 SZ=169 HN=1
ICE889I 0 CT=MAX , SB=3, L=0, D=0000, CCW=1MBI
ICE901I 0 W 01PP15 53PP15 44PP15 1APP15 12PP15 67PP15 27PP15 34PP15
ICE901I 0 W 2FPP15 66PP15 45PP15 0BPP15 2BPP15 32PP15 26PP15 06PP15
ICE901I 0 W 22PP15 1FPP15 3EPP15 2EPP15 1BPP15 05PP15 4APP15 46PP15
ICE901I 0 W 65PP15 04PP15 07PP15 4BPP15 09PP15 30PP15 36PP15 59PP15
ICE901I 0 W 3APP11 18PP11 03NP11 0ANP11 3DNP11 4FNP11 31NP11 21NP11
ICE901I 0 W 54NP11 4ENP11 1DNP11 16NP11 4CNP11 3CNP11 17NP11 08NP11
ICE901I 0 W 11NP11 56NP11 57NP11 15NP11 39NP11 1CNP11 49NP11 62NP11
ICE901I 0 W 0DNP11 19NP11 60NP11 14NP11 25NP11 13NP11 3FNP11 40NP11
ICE901I 0 W 41NP11 42NP11 43NP11 23NP11 0CNP11 1ENP11 47NP11 48NP11
ICE901I 0 W 37NP11 35NP11 2CNP11 2DNP11 4DNP11 2ANP11 0FNP11 50NP11
ICE901I 0 W 51NP11 52NP11 02NP11 29NP11 55NP11 0ENP11 33NP11 58NP11
ICE901I 0 W 20NP11 5ANP11 5BNP11 5CNP11 5DNP11 5ENP11 5FNP11 3BNP11
ICE901I 0 W 61NP11 38NP11 63NP11 64NP11 28NP11 24NP11 10NP11
SARPAGE 6
ICE906I 1 ST=ABOVE,SR=590271,RC=0
ICE907I 1 ST=ABOVE,SA=590248,NF=1,LF=590248,SF=590248
ICE906I 1 ST=BELOW,SR=452737,RC=0
ICE907I 1 ST=BELOW,SA=444528,NF=1,LF=444528,SF=444528
ICE046A 5 SORT CAPACITY EXCEEDED - RECORD COUNT 58081219
ICE253I 0 RECORDS SORTED - PROCESSED: 58081219, EXPECTED: 60000000
ICE753I 1 FWK=(59,16461) SWK=(0,0) TWK=(0,0) RWK=(44,176)
TOTAL=(103,16637) BLK=12256
ICE278I 1 59 WORK DATA SETS WERE INSUFFICIENT TO COMPLETE THIS SORT
SO 44 ADDITIONAL WERE USED
ICE751I 1 DE-BASE D5-I29741 D3-BASE E1-BASE D6-BASE C4-
I31999 C4-I31999 C4-I31999 C4-I31999 C4-I31999 C4-I31999
ICE751I 1 C4-I31999 C4-I31999 C4-I31999 C4-I31999 C4-I31999 C4-
I31999 C4-I31999 C4-I31999 C4-I31999 C4-I31999 C4-I31999
ICE751I 1 C4-I31999 C4-I31999 C4-I31999 C4-I31999 C4-I31999 C4-
I31999 C4-I31999 C4-I31999 C4-I31999 C4-I31999 C4-I31999
ICE751I 1 C4-I31999 C4-I31999 C4-I31999 C4-I31999 C4-I31999 C4-
I31999 C4-I31999 C4-I31999 C4-I31999 C4-I31999 C4-I31999
ICE751I 1 C4-I31999 C4-I31999 C4-I31999 C4-I31999 C4-I31999 C4-
I31999 E8-I29741
ICE052I 0 END OF DFSORT
CEE3250C The system or user abend U 046 R=NULL was issued.
From compile unit D314DC2A at entry point D314DC2A at
compile unit offset +000017AA at entry offset +000017AA
at address 0B4017AA.
<> LEAID ENTERED (LEVEL 02/26/2016 AT 17.55)
<> LEAID LEAID109 ABEND-AID PROCESSING IGNORED. ABEND SPECIFIED NO DUMP
<> LEAID PROCESSING COMPLETE. RC=4
//*********************************************************************
//* P10 - D314DC2A - HOME OFFICE ACCOUNT
//*********************************************************************
//P10 EXEC PGM=D314DC2A,
// COND=(0,LT)
//*
//DATEFLE DD DSN=&SYS..RS.MDBC.DATEFLE(0),
// DISP=SHR
//*
//GTAMLIB DD DSN=&SYS..PM.RVOM.GTAMLIB, 0
// DISP=SHR
//*
//RESVIND DD DSN=&SYS..RS.MDBM.D311DA2R(0), 000
// DISP=SHR
//*
//SORTCNTL DD DSN=&SYS..ENDEVOR.CCARDS(&L.SORTCNT),
// DISP=SHR
//*
//DFSPARM DD DSN=&SYS..ENDEVOR.CCARDS(&L.RS17510),
// DISP=SHR
//*
//SYSIN DD DUMMY
//*
//PRINTER DD SYSOUT=(B,&L.RSM1752)
//*
//SYSOUT DD SYSOUT=*
//SYSPRINT DD SYSOUT=*
//SYSUDUMP DD SYSOUT=*
//SYSABEND DD SYSOUT=*
//*
//*
//*
//*********************************************************************
//* END OF PROC PRSPM175
//*********************************************************************
OPTION DYNSPC=1024,DYNALLOC=(SYSDA,59),FILSZ=E60000000
-----Original Message-----
] On Behalf Of Vernooij, Kees (ITOPT1) - KLM
Sent: Monday, October 02, 2017 9:47 AM
Subject: Re: Sort Question
Apparently your sortwk's are that small, that many more are needed.
//LISTDEF EXEC PGM=ICETOOL
//TOOLMSG DD SYSOUT=*
//DFSMSG DD SYSOUT=*
//SHOWDEF DD SYSOUT=*
//TOOLIN DD *
DEFAULTS LIST(SHOWDEF)
/*
Post the full DFSORT output and the JCL of the step with the error.
This info must give a clue.
Kees.
-----Original Message-----
On Behalf Of Pfister, Nathan
Sent: 02 October, 2017 15:40
Subject: Sort Question
List;
I have a question dealing with a DFSORT job which I am hoping to get some guidance on.
We have a COBOL program which inconsistently gets a SORT CAPACITY
EXCEEDED error. They've changed their cards several times with
several different options to try and get this to work. Depending on
the month sometimes it works and sometimes it doesn't, with their
typical OPTION
DYNSPC=1024,DYNALLOC=(SYSDA,59)
The latest run, we added FILSZ=E60000000
In every run it seems to exceed the sort capacity.
+ICE046A 5 PRSPM175.J05 SORT CAPACITY EXCEEDED - RECORD COUNT 58081219
And the following error as well. Not sure
ICE278I 1 59 WORK DATA SETS WERE INSUFFICIENT TO COMPLETE THIS SORT SO
44 ADDITIONAL WERE USED
The funny thing is, this has worked with a DYNALLOC of 24...there is
nothing else in the system at the time this was running, and plenty of
DASD. Obviously I am overlooking some key piece of information.
Here's the COBOL for the Sort, which doesn't mean too much to me as I
am not a COBOL programmer, so I am sure I am missing parts of the sort
call, but this is what I was given...
SD S1-SORT-FILE
RECORDING MODE IS F
DATA RECORDS ARE S10-SORT-REC
RECORD CONTAINS 49 CHARACTERS.
01 S10-SORT-REC.
05 S20-SORT-KEY.
10 S20-KEY-LOCATION PIC X(2).
10 S20-KEY-MCO PIC X(2).
10 S20-KEY-PCO PIC X(2).
10 S20-KEY-TREATY PIC X(4).
10 S20-KEY-AS-LINE1 PIC 9(3).
10 S20-KEY-AS-LINE REDEFINES S20-KEY-AS-LINE1
PIC 9(2)V9(1).
05 S20-BREAK-KEY-R1 REDEFINES S20-SORT-KEY.
10 S20-TREATY-BREAK PIC X(10).
10 FILLER PIC X(3).
05 S20-BREAK-KEY-R2 REDEFINES S20-SORT-KEY.
10 S20-PCO-BREAK PIC X(6).
10 FILLER PIC X(7).
05 S20-BREAK-KEY-R3 REDEFINES S20-SORT-KEY.
10 S20-MCO-BREAK PIC X(4).
10 FILLER PIC X(9).
05 S30-SORT-BODY.
10 S30-LINE-TYPE PIC 9(1).
10 S30-MONTHLY-WRITTEN PIC S9(7)V9(2) COMP-3.
10 S30-TO-DATE-WRITTEN PIC S9(7)V9(2) COMP-3.
10 S30-NEW-MONTH PIC S9(7)V9(2) COMP-3.
10 S30-THIS-MONTH-EARNED PIC S9(7)V9(2) COMP-3.
10 S30-INFORCE-TO-DATE PIC S9(7)V9(2) COMP-3.
10 S30-LA-COMMISSION PIC S9(7)V9(2) COMP-3.
10 S30-TOT-COMMISSION PIC S9(7)V9(2) COMP-3.
EJECT
SORT S1-SORT-FILE
ASCENDING KEY
S20-SORT-KEY
If anyone could point me in the right direction on this, I would appreciate it!
Nathan Pfister
Systems Programmer
Donegal Insurance Group
E-MAIL CONFIDENTIALITY NOTICE: This e-mail from Donegal Insurance
Group may contain CONFIDENTIAL and legally protected information. If
you are not an intended recipient, please do not copy, use or disclose
this email or its contents to others; and please notify us by calling
toll free (800) 877-0600 x7880 or by replying to this message, and
then delete it from your system. Delivery of this email to an
unintended recipient is not a waiver of any attorney-client or other
applicable privilege.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send
with the message: INFO IBM-MAIN
********************************************************
https://urldefense.proofpoint.com/v2/url?
u=http-3A__www.klm.com&d=DwIFAg&c=jf_iaSHvJObTbx-
siA1ZOg&r=Ae5kuKdL4c910EvfgxokfP66Pm216FnhUBn6gZrM7hw&m=eqeibEw0l0cCuikkdn5VXr0MvBo6ppDwNzEGZ1aTTLc&s=ZEJImDzmqtCV7zJgH5fUvKmdagrwyJSyO4UCFQK9_OE&e=
. This e-mail and any attachment may contain confidential and
privileged material intended for the addressee only. If you are not
the addressee, you are notified that no part of the e-mail or any
attachment may be disclosed, copied or distributed, and that any
other action related to this e-mail or attachment is strictly
prohibited, and may be unlawful. If you have received this e-mail by
error, please notify the sender immediately by return e-mail, and
delete this message.
Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/
or its employees shall not be liable for the incorrect or incomplete
transmission of this e-mail or any attachments, nor responsible for
any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal
Dutch Airlines) is registered in Amstelveen, The Netherlands, with
registered number 33014286
********************************************************
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send
with the message: INFO IBM-MAIN
E-MAIL CONFIDENTIALITY NOTICE: This e-mail from Donegal Insurance
Group may contain CONFIDENTIAL and legally protected information. If
you are not an intended recipient, please do not copy, use or
disclose this email or its contents to others; and please notify us
by calling toll free (800) 877-0600 x7880 or by replying to this
message, and then delete it from your system. Delivery of this email
to an unintended recipient is not a waiver of any attorney-client or
other applicable privilege.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN





----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Elardus Engelbrecht
2017-10-02 14:12:23 UTC
Permalink
Raw Message
Post by Pfister, Nathan
Sorry for the long post, but here's all the info.
ICE092I 0 MAIN STORAGE = (128000,1048576,1048576)
ICE156I 0 MAIN STORAGE ABOVE 16MB = (590271,590271)
It is looking small for me, at least for me. What is your job REGION? Is that REGION limited by SMFPRMxx or IEFUSI exit?

Consider adding these OPTION SIZE=E999999999,MAINSIZE=MAX just to tell DFSORT there is a large workset waiting for it.

Or you can add a good handfull of these SORTWKxx, which I had to use at one stage to handle a Galaxy sized sort work:

//SORTWK01 DD DISP=(NEW,DELETE,DELETE),SPACE=(CYL,(1000,500,0)),
// UNIT=3390

HTH!

Please let us know if you got a solution!

Groete / Greetings
Elardus Engelbrecht

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Lizette Koehler
2017-10-02 14:16:22 UTC
Permalink
Raw Message
Some interesting sections from DFSORT messages

1) DSA is set to 128 in parms but DSA=0 is in the sort message output
2) DFSORT at failure says an additional 44 WORK volumes were needed

There is a way to pass parms to DFSORT using DFSPARM DD statement

For our larger sorts I have coded

//DFSPARM DD *
DSA=128,FILESZ=50000000,UNIT=(SYSDA,32)


Maybe the DFSORT team will chime in

Lizette
-----Original Message-----
Behalf Of Elardus Engelbrecht
Sent: Monday, October 02, 2017 7:14 AM
Subject: Re: Sort Question
Post by Pfister, Nathan
Sorry for the long post, but here's all the info.
ICE092I 0 MAIN STORAGE = (128000,1048576,1048576) ICE156I 0 MAIN
STORAGE ABOVE 16MB = (590271,590271)
It is looking small for me, at least for me. What is your job REGION? Is that
REGION limited by SMFPRMxx or IEFUSI exit?
Consider adding these OPTION SIZE=E999999999,MAINSIZE=MAX just to tell DFSORT
there is a large workset waiting for it.
Or you can add a good handfull of these SORTWKxx, which I had to use at one
//SORTWK01 DD DISP=(NEW,DELETE,DELETE),SPACE=(CYL,(1000,500,0)),
// UNIT=3390
HTH!
Please let us know if you got a solution!
Groete / Greetings
Elardus Engelbrecht
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Pfister, Nathan
2017-10-02 15:12:53 UTC
Permalink
Raw Message
Lizette;

Thanks for that suggestion. For now, I looked at what you have and I will give some similar cards a shot. Also, I didn't realize I could reach out to the DFSORT team directly, so thanks for that!

Eldarus;

I hadn't thought about the region, it is limited by the IEFUSI exit.

If the parameters I put in based on Lizettes don’t' work, I will suggest coding of the SORTWK statements.


-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Lizette Koehler
Sent: Monday, October 02, 2017 10:17 AM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: Sort Question

Some interesting sections from DFSORT messages

1) DSA is set to 128 in parms but DSA=0 is in the sort message output
2) DFSORT at failure says an additional 44 WORK volumes were needed

There is a way to pass parms to DFSORT using DFSPARM DD statement

For our larger sorts I have coded

//DFSPARM DD *
DSA=128,FILESZ=50000000,UNIT=(SYSDA,32)


Maybe the DFSORT team will chime in

Lizette
-----Original Message-----
On Behalf Of Elardus Engelbrecht
Sent: Monday, October 02, 2017 7:14 AM
Subject: Re: Sort Question
Post by Pfister, Nathan
Sorry for the long post, but here's all the info.
ICE092I 0 MAIN STORAGE = (128000,1048576,1048576) ICE156I 0 MAIN
STORAGE ABOVE 16MB = (590271,590271)
It is looking small for me, at least for me. What is your job REGION?
Is that REGION limited by SMFPRMxx or IEFUSI exit?
Consider adding these OPTION SIZE=E999999999,MAINSIZE=MAX just to tell
DFSORT there is a large workset waiting for it.
Or you can add a good handfull of these SORTWKxx, which I had to use
//SORTWK01 DD DISP=(NEW,DELETE,DELETE),SPACE=(CYL,(1000,500,0)),
// UNIT=3390
HTH!
Please let us know if you got a solution!
Groete / Greetings
Elardus Engelbrecht
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
E-MAIL CONFIDENTIALITY NOTICE: This e-mail from Donegal Insurance Group may contain CONFIDENTIAL and legally protected information. If you are not an intended recipient, please do not copy, use or disclose this email or its contents to others; and please notify us by calling toll free (800) 877-0600 x7880 or by replying to this message, and then delete it from your system. Delivery of this email to an unintended recipient is not a waiver of any attorney-client or other applicable privilege.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Farley, Peter x23353
2017-10-02 15:28:34 UTC
Permalink
Raw Message
With respect to the REGION size, remember that SORT (both IBM and its competitors) is most efficient the more memory you can let him have. I have found this especially true for COBOL-based SORT's.

Consider using a region of at least 500M for large-volume sorts, and be sure to tell SORT he can use (most of) it via the SORT parameters. The more memory he has available the fewer SORTWK's and SORTWK I/O's he will need to use.

Also "buffer up" all of your high-volume input files with high BUFNO (QSAM) or AMP='BUFND=XXXX,BUFNI=YYYY,RMODE31=ALL' (VSAM) parameters (as appropriate). Consider using SUBSYS=BLSR or SMB parameters for high-volume VSAM inputs as well.

Memory is (relatively) inexpensive, so use it to your advantage. Your SLA's will appreciate it.

HTH

Peter

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Pfister, Nathan
Sent: Monday, October 02, 2017 11:14 AM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: Sort Question

Lizette;

Thanks for that suggestion. For now, I looked at what you have and I will give some similar cards a shot. Also, I didn't realize I could reach out to the DFSORT team directly, so thanks for that!

Eldarus;

I hadn't thought about the region, it is limited by the IEFUSI exit.

If the parameters I put in based on Lizettes don’t' work, I will suggest coding of the SORTWK statements.


-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Lizette Koehler
Sent: Monday, October 02, 2017 10:17 AM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: Sort Question

Some interesting sections from DFSORT messages

1) DSA is set to 128 in parms but DSA=0 is in the sort message output
2) DFSORT at failure says an additional 44 WORK volumes were needed

There is a way to pass parms to DFSORT using DFSPARM DD statement

For our larger sorts I have coded

//DFSPARM DD *
DSA=128,FILESZ=50000000,UNIT=(SYSDA,32)


Maybe the DFSORT team will chime in

Lizette
-----Original Message-----
On Behalf Of Elardus Engelbrecht
Sent: Monday, October 02, 2017 7:14 AM
Subject: Re: Sort Question
Post by Pfister, Nathan
Sorry for the long post, but here's all the info.
ICE092I 0 MAIN STORAGE = (128000,1048576,1048576) ICE156I 0 MAIN
STORAGE ABOVE 16MB = (590271,590271)
It is looking small for me, at least for me. What is your job REGION?
Is that REGION limited by SMFPRMxx or IEFUSI exit?
Consider adding these OPTION SIZE=E999999999,MAINSIZE=MAX just to tell
DFSORT there is a large workset waiting for it.
Or you can add a good handfull of these SORTWKxx, which I had to use
//SORTWK01 DD DISP=(NEW,DELETE,DELETE),SPACE=(CYL,(1000,500,0)),
// UNIT=3390
HTH!
Please let us know if you got a solution!
Groete / Greetings
Elardus Engelbrecht
--


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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Paul Gilmartin
2017-10-02 16:22:26 UTC
Permalink
Raw Message
Post by Farley, Peter x23353
With respect to the REGION size, remember that SORT (both IBM and its competitors) is most efficient the more memory you can let him have. I have found this especially true for COBOL-based SORT's.
But does this contend adversely with concurrent jobs?
Post by Farley, Peter x23353
Consider using a region of at least 500M for large-volume sorts, and be sure to tell SORT he can use (most of) it via the SORT parameters. The more memory he has available the fewer SORTWK's and SORTWK I/O's he will need to use.
REGION=0K?
Post by Farley, Peter x23353
Also "buffer up" all of your high-volume input files with high BUFNO (QSAM) or AMP='BUFND=XXXX,BUFNI=YYYY,RMODE31=ALL' (VSAM) parameters (as appropriate). Consider using SUBSYS=BLSR or SMB parameters for high-volume VSAM inputs as well.
I would hope (wish) that DFSORT would supply optimum defaults. But can
an application discern in OPEN exit whether the options were supplied in
JCL or as OS defaults?

Does DFSORT rely on QSAM or on idiosyncratic EXCP? I'd expect that in
the era of oscillating merge it relied on EXCP.
Post by Farley, Peter x23353
Memory is (relatively) inexpensive, so use it to your advantage. Your SLA's will appreciate it.
-- gil

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Farley, Peter x23353
2017-10-02 16:47:32 UTC
Permalink
Raw Message
-----Original Message-----
Sent: Monday, October 02, 2017 12:24 PM
Subject: Re: Sort Question
Post by Farley, Peter x23353
With respect to the REGION size, remember that SORT (both IBM and its competitors) is most efficient the more memory you can let him have. I have found this especially true for COBOL-based SORT's.
But does this contend adversely with concurrent jobs?
IMHO it is the job of the Capacity and Performance team to tell the application programming teams when application jobs are contending for memory and causing paging, especially if it causes SLA's to be missed or near-missed.
Post by Farley, Peter x23353
Consider using a region of at least 500M for large-volume sorts, and be sure to tell SORT he can use (most of) it via the SORT parameters. The more memory he has available the fewer SORTWK's and SORTWK I/O's he will need to use.
REGION=0K?
Only if allowed by IEFUSI. Many large shops do not allow it except with special dispensation and approval, specifically because of the issue you raised above about memory contention.
Post by Farley, Peter x23353
Also "buffer up" all of your high-volume input files with high BUFNO (QSAM) or AMP='BUFND=XXXX,BUFNI=YYYY,RMODE31=ALL' (VSAM) parameters (as appropriate). Consider using SUBSYS=BLSR or SMB parameters for high-volume VSAM inputs as well.
I would hope (wish) that DFSORT would supply optimum defaults. But can an application discern in OPEN exit whether the options were supplied in JCL or as OS defaults?
Does DFSORT rely on QSAM or on idiosyncratic EXCP? I'd expect that in the era of oscillating merge it relied on EXCP.
Of course SORT uses his own EXCP (or OCO media manager interfaces) where possible, as it is far more efficient than QSAM. I was referring to the OP's original COBOL source for this SORT question. My reply concerned application-read input files, not directly-read-by-SORT files. For JCL sorts I always let SORT decide how to optimize his files, but COBOL SORT's act as E15 and/or E35 exits, so COBOL I/O can and often is being used for those I/O's, whether directly for the file to be sorted or a multiplicity of inputs used to construct the SORT input and output records.
Post by Farley, Peter x23353
Memory is (relatively) inexpensive, so use it to your advantage. Your SLA's will appreciate it.
Peter
--

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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Vernooij, Kees - KLM , ITOPT1
2017-10-03 06:41:52 UTC
Permalink
Raw Message
Post by Paul Gilmartin
But does this contend adversely with concurrent jobs?
DFSORT communicates with RSM in order to utilize memory efficiently, without overloading it.

Kees.
********************************************************
For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message.

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286
********************************************************

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Paul Gilmartin
2017-10-02 17:00:10 UTC
Permalink
Raw Message
Does DFSORT rely on QSAM or on idiosyncratic EXCP? I'd expect that in the era of oscillating merge it relied on EXCP.
Of course SORT uses his own EXCP (or OCO media manager interfaces) where possible, as it is far more efficient than QSAM. ...
I'd expect this for PDSE; perhaps less so for allocated OMVS files.

Binder arrogantly ignores "DD FILEDATA=...". I'd hope for better from DFSORT.

-- gil

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Elardus Engelbrecht
2017-10-02 18:01:13 UTC
Permalink
Raw Message
Paul Gilmartin wrote:

You have made good points, thanks.
Post by Paul Gilmartin
Post by Farley, Peter x23353
With respect to the REGION size, remember that SORT (both IBM and its competitors) is most efficient the more memory you can let him have. I have found this especially true for COBOL-based SORT's.
But does this contend adversely with concurrent jobs?
Uhm, with same or different sort input and/or output for all these concurrent jobs?


AFAIK, COBOL has its own internal SORT functions, but if I want to sort something big or complex, I would terminate my COBOL program, let sort it with DFSORT or SyncSort and do same or other COBOL program to process the sorted data.

If it is not too big or complex to sort, I can let COBOL call DFSORT and wait for sorted data to come back.
Post by Paul Gilmartin
I would hope (wish) that DFSORT would supply optimum defaults.
AFAIK, those defaults are the best DFSORT can offer, but of course, only you know if those defaults are working or not.
Post by Paul Gilmartin
Does DFSORT rely on QSAM or on idiosyncratic EXCP? I'd expect that in the era of oscillating merge it relied on EXCP.
AFAIK, DFSORT has its own OCO access method(s) just like RACF has its own OCO way to access the RACF database.

Just my 3 cents, not 2, because of tax/inflation and a terrible mother-in-law... ;-)

Groete / Greetings
Elardus Engelbrecht

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Clark Morris
2017-10-02 19:17:59 UTC
Permalink
Raw Message
[Default] On 2 Oct 2017 11:01:13 -0700, in bit.listserv.ibm-main
Post by Elardus Engelbrecht
You have made good points, thanks.
Post by Paul Gilmartin
Post by Farley, Peter x23353
With respect to the REGION size, remember that SORT (both IBM and its competitors) is most efficient the more memory you can let him have. I have found this especially true for COBOL-based SORT's.
But does this contend adversely with concurrent jobs?
Uhm, with same or different sort input and/or output for all these concurrent jobs?
AFAIK, COBOL has its own internal SORT functions, but if I want to sort something big or complex, I would terminate my COBOL program, let sort it with DFSORT or SyncSort and do same or other COBOL program to process the sorted data.
IBM COBOL programs invoke the installation SORT program - DFSORT or
SYNCSORT. The MAINSIZE of 000128000 seems small if that is in bytes.
I would look at the COBOL compile for that program, the SORT defaults
for invoked (as opposed to JCL) sorts, any override JCL and all of the
installation COBOL compiler options to see what is generating that
size.

Clark Morris
Post by Elardus Engelbrecht
If it is not too big or complex to sort, I can let COBOL call DFSORT and wait for sorted data to come back.
Post by Paul Gilmartin
I would hope (wish) that DFSORT would supply optimum defaults.
AFAIK, those defaults are the best DFSORT can offer, but of course, only you know if those defaults are working or not.
Post by Paul Gilmartin
Does DFSORT rely on QSAM or on idiosyncratic EXCP? I'd expect that in the era of oscillating merge it relied on EXCP.
AFAIK, DFSORT has its own OCO access method(s) just like RACF has its own OCO way to access the RACF database.
Just my 3 cents, not 2, because of tax/inflation and a terrible mother-in-law... ;-)
Groete / Greetings
Elardus Engelbrecht
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Pfister, Nathan
2017-10-02 19:21:46 UTC
Permalink
Raw Message
I'm working with the app team to get some changes in place for memory utilization based on some things given me here.

That said, by setting MOSIZE to 0...it fixed the issue as was with no other changes. Right, wrong, or indifferent.

I do thank everyone for their input on this!

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Clark Morris
Sent: Monday, October 02, 2017 3:19 PM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: Sort Question
Post by Elardus Engelbrecht
You have made good points, thanks.
Post by Paul Gilmartin
Post by Farley, Peter x23353
With respect to the REGION size, remember that SORT (both IBM and its competitors) is most efficient the more memory you can let him have. I have found this especially true for COBOL-based SORT's.
But does this contend adversely with concurrent jobs?
Uhm, with same or different sort input and/or output for all these concurrent jobs?
AFAIK, COBOL has its own internal SORT functions, but if I want to sort something big or complex, I would terminate my COBOL program, let sort it with DFSORT or SyncSort and do same or other COBOL program to process the sorted data.
IBM COBOL programs invoke the installation SORT program - DFSORT or SYNCSORT. The MAINSIZE of 000128000 seems small if that is in bytes.
I would look at the COBOL compile for that program, the SORT defaults for invoked (as opposed to JCL) sorts, any override JCL and all of the installation COBOL compiler options to see what is generating that size.

Clark Morris
Post by Elardus Engelbrecht
If it is not too big or complex to sort, I can let COBOL call DFSORT and wait for sorted data to come back.
Post by Paul Gilmartin
I would hope (wish) that DFSORT would supply optimum defaults.
AFAIK, those defaults are the best DFSORT can offer, but of course, only you know if those defaults are working or not.
Post by Paul Gilmartin
Does DFSORT rely on QSAM or on idiosyncratic EXCP? I'd expect that in the era of oscillating merge it relied on EXCP.
AFAIK, DFSORT has its own OCO access method(s) just like RACF has its own OCO way to access the RACF database.
Just my 3 cents, not 2, because of tax/inflation and a terrible
mother-in-law... ;-)
Groete / Greetings
Elardus Engelbrecht
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
E-MAIL CONFIDENTIALITY NOTICE: This e-mail from Donegal Insurance Group may contain CONFIDENTIAL and legally protected information. If you are not an intended recipient, please do not copy, use or disclose this email or its contents to others; and please notify us by calling toll free (800) 877-0600 x7880 or by replying to this message, and then delete it from your system. Delivery of this email to an unintended recipient is not a waiver of any attorney-client or other applicable privilege.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
David W Noon
2017-10-02 19:40:00 UTC
Permalink
Raw Message
On Mon, 2 Oct 2017 13:02:24 -0500, Elardus Engelbrecht
(***@SITA.CO.ZA) wrote about "Re: Sort Question" (in
<***@listserv.ua.edu>):

[snip]
Post by Elardus Engelbrecht
AFAIK, COBOL has its own internal SORT functions,
It does not. Both PL/I and COBOL use the SORT or ICEMAN module from the
linklist for their sort interfaces.
Post by Elardus Engelbrecht
but if I want to sort something big or complex, I would terminate my
COBOL program, let sort it with DFSORT or SyncSort and do same or
other COBOL program to process the sorted data.
If it is not too big or complex to sort, I can let COBOL call DFSORT
and wait for sorted data to come back.
Unless your COBOL code is huge, it makes little difference to the
performance of the sort. Just use the SORT verb in COBOL or the
PLISRTx() subroutines in PL/I; they will perform just the same as a
separate sort step. You need to remember to set the appropriate memory
parameters in PLSIRTx() or set the COBOL special registers so that the
sort can use as much memory as it needs. These compiler language
interfaces have all the facilities of DF/SORT available, including the
SORTPARM DD card stream.
Post by Elardus Engelbrecht
Post by Paul Gilmartin
Does DFSORT rely on QSAM or on idiosyncratic EXCP? I'd expect
that in the era of oscillating merge it relied on EXCP.
AFAIK, DFSORT has its own OCO access method(s) just like RACF has
its own OCO way to access the RACF database.
DF/SORT has used EXCP since it was called SORT/360.
Note that if SORTIN or SORTOUT is a VSAM cluster, it will use normal
VSAM for reading or writing, but SORTWKxx spill files are accessed by
raw channel programs (at least when the default BLOCKSET algorithm is used).
--
Regards,

Dave [RLU #314465]
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
***@googlemail.com (David W Noon)
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*

 

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Elardus Engelbrecht
2017-10-02 19:32:04 UTC
Permalink
Raw Message
Post by Pfister, Nathan
That said, by setting MOSIZE to 0...it fixed the issue as was with no other changes. Right, wrong, or indifferent.
Interesting. You changed to 0 from MOSIZE = MAX (from you earlier post where you listed the sort parameters)?

Hmmm, interesting, but thanks. Good to know about it.

Groete / Greetings
Elardus Engelbrecht

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Pfister, Nathan
2017-10-02 19:47:21 UTC
Permalink
Raw Message
Yes, the MOSIZE went from MAX to 0. This was based on an APAR from V1R10 which the app prog saw and decided to try. I honestly was shocked it worked.

Here's the APAR for reference:
http://www-01.ibm.com/support/docview.wss?uid=isg1PM23527#more



-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Elardus Engelbrecht
Sent: Monday, October 02, 2017 3:33 PM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: Sort Question
Post by Pfister, Nathan
That said, by setting MOSIZE to 0...it fixed the issue as was with no other changes. Right, wrong, or indifferent.
Interesting. You changed to 0 from MOSIZE = MAX (from you earlier post where you listed the sort parameters)?

Hmmm, interesting, but thanks. Good to know about it.

Groete / Greetings
Elardus Engelbrecht

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
E-MAIL CONFIDENTIALITY NOTICE: This e-mail from Donegal Insurance Group may contain CONFIDENTIAL and legally protected information. If you are not an intended recipient, please do not copy, use or disclose this email or its contents to others; and please notify us by calling toll free (800) 877-0600 x7880 or by replying to this message, and then delete it from your system. Delivery of this email to an unintended recipient is not a waiver of any attorney-client or other applicable privilege.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Paul Gilmartin
2017-10-03 13:27:07 UTC
Permalink
Raw Message
Post by Vernooij, Kees - KLM , ITOPT1
Post by Paul Gilmartin
But does this contend adversely with concurrent jobs?
DFSORT communicates with RSM in order to utilize memory efficiently, without overloading it.
Then might installations' second-guessing result in imposing static resource
limits that thwart DFSORT's optimization and actually degrade performance?

-- gil

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Vernooij, Kees - KLM , ITOPT1
2017-10-03 13:49:30 UTC
Permalink
Raw Message
-----Original Message-----
Behalf Of Paul Gilmartin
Sent: 03 October, 2017 15:28
Subject: Re: Sort Question
Post by Vernooij, Kees - KLM , ITOPT1
Post by Paul Gilmartin
But does this contend adversely with concurrent jobs?
DFSORT communicates with RSM in order to utilize memory efficiently,
without overloading it.
Then might installations' second-guessing result in imposing static resource
limits that thwart DFSORT's optimization and actually degrade
performance?
-- gil
AFAIK, one can only make DFSORT run worse, not better than it would do by itself. E.g. we had several problems with users that were experimenting with number and sizes of SORTWKs and other parameters in order to get jobs running reliably and these problems were usually solved by allowing DFSORT to make its own calculations of memory, memobjects, hiper/dataspaces and sortwks.

I hope David Betten cares to elaborate on this.

Kees
********************************************************
For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message.

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286
********************************************************


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Tim Hare
2017-10-11 03:17:34 UTC
Permalink
Raw Message
I know I am late to this, but I see no BLOCK CONTAINS 0 RECORDS in the COBOL. I'm not totally current on COBOL releases, but
A) is that still required to use block size from the JCL
B) is it even relevant in this instance - COBOL will use the block size value of the dataset that's input, yes?

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Farley, Peter x23353
2017-10-11 12:33:46 UTC
Permalink
Raw Message
It depends on the version of COBOL in use. COBOL V4.2 and earlier default to BLOCK CONTAINS 1 if the phrase is not specified in the FD, which is why most sensible z/OS shop standards call for always using BLOCK CONTAINS 0. I can't speak for VM or VSE shop standards, I haven't worked in either of those environments for quite a long time.

COBOL V5+ have a new compiler option, BLOCK0, which changes the default to BLOCK CONTAINS 0, though the option is off by default for compatibility with earlier releases.

HTH

Peter

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Tim Hare
Sent: Tuesday, October 10, 2017 11:19 PM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: Sort Question

I know I am late to this, but I see no BLOCK CONTAINS 0 RECORDS in the COBOL. I'm not totally current on COBOL releases, but
A) is that still required to use block size from the JCL
B) is it even relevant in this instance - COBOL will use the block size value of the dataset that's input, yes?

--


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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Clark Morris
2017-10-12 00:24:14 UTC
Permalink
Raw Message
[Default] On 11 Oct 2017 05:33:46 -0700, in bit.listserv.ibm-main
Post by Farley, Peter x23353
It depends on the version of COBOL in use. COBOL V4.2 and earlier default to BLOCK CONTAINS 1 if the phrase is not specified in the FD, which is why most sensible z/OS shop standards call for always using BLOCK CONTAINS 0. I can't speak for VM or VSE shop standards, I haven't worked in either of those environments for quite a long time.
COBOL V5+ have a new compiler option, BLOCK0, which changes the default to BLOCK CONTAINS 0, though the option is off by default for compatibility with earlier releases.
If a block count other than zero for a QSAM file is either defaulted
to or explicitly stated (BLOCK 10 for example), then COBOL will
require that no more than that number of blocks is on the input file
and abend if it isn't (I'm not certain how it would handle consecutive
short blocks) unless STATUS-CODE is specified for the file. On output
the blocksize would be determined by the number of blocks specified if
not zero.

VSAM files never have had block count specified and have always used
the CISIZE defined.

Clark Morris
Post by Farley, Peter x23353
HTH
Peter
-----Original Message-----
Sent: Tuesday, October 10, 2017 11:19 PM
Subject: Re: Sort Question
I know I am late to this, but I see no BLOCK CONTAINS 0 RECORDS in the COBOL. I'm not totally current on COBOL releases, but
A) is that still required to use block size from the JCL
B) is it even relevant in this instance - COBOL will use the block size value of the dataset that's input, yes?
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Paul Gilmartin
2017-10-11 03:21:15 UTC
Permalink
Raw Message
Post by Tim Hare
I know I am late to this, but I see no BLOCK CONTAINS 0 RECORDS in the COBOL. I'm not totally current on COBOL releases, but
A) is that still required to use block size from the JCL
Even better, it will use the block size supplied by SDB.
Post by Tim Hare
B) is it even relevant in this instance - COBOL will use the block size value of the dataset that's input, yes?
-- gil

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Loading...