Re: DFSORT and SAS

2021-01-25 Thread Gibney, Dave
That Weekly TREND file has been growing, probably a couple decades. It is quite 
possible that my former SORT product was due to fail for the same general 
reasons.

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Scott Barry
> Sent: Monday, January 25, 2021 2:45 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: DFSORT and SAS
> 
> It appears that you are managing the //TREND PDB as a SAS sequential-
> format (indicated with RECFM=U, and as you mention with prior TMM-
> deployment - also getting zEDC benefit, hopefully) and I expect that SAS
> does not detect the observation/row/record count which is why you see the
> ICE118I  message.  This is clearly a SAS-limitation situation, what with the
> tape-format SAS data library.
> 
> Regards,
> Scott Barry
> SBBTech LLC
> 
> 
> On Mon, 25 Jan 2021 21:04:58 +, Gibney, Dave 
> wrote:
> 
> >I am sure the ICE118I showed up because of the //SORTDIAG
> >My Tape management is CA-7. But, all datasets are on disk.
> >JCL follows:
> >//TRNDDSNS EXEC MXGSAS,WORK='5000,1000'
> >//**
> >//* DO MXG WEEKLY DATASET TRENDING PROCESSING
> >//**
> >//WEEK DD  DSN=MXG.DATASETS.WEEK(+0),DISP=OLD
> >//TRENDDD  DSN=MXG.DATASETS.TREND,DISP=OLD
> >//SYSINDD  *
> > %INCLUDE SOURCLIB(SYS802C);
> >//SORTDIAG DD DUMMY
> >//DFSPARM  DD *
> >OPTION FILSZ=E1800
> >
> >My Tape management is CA-7. But, all datasets are on disk.
> >
> >/* COPYRIGHT (C) 1993,1994 MERRILL CONSULTANTS DALLAS TEXAS USA
> */
> > /* LAST UPDATED: JUL 1, 1994*/
> > /*  */
> > /*  THIS MEMBER IS A PART OF THE ALL-YOUR-DATA-SETS-TRACKING-
> SYSTEM */
> > /*  SEE ADOCDSNS FOR DESCRIPTION OF ITS OTHER COMPONENTS*/
> > /*  */
> > /*CHANGE LOG*/
> > /*06/03/94 UPDATED FOR NEW VMXGSUM LOGIC*/
> >
> /**
> **/
> >OPTIONS NODSNFERR NOVNFERR;
> >%VMXGSUM(INVOKEBY=TRNDDSNS,
> >  INDATA=  WEEK.DATASETS
> >   TREND.TRNDDSNS,
> >  OUTDATA= TREND.TRNDDSNS,
> >  DSNLABEL=TRND DSNS: TREND 1415/64 DATASETS,
> >  SUMBY=   DSNAME,
> >  MIN= FIRST,
> >  MAX= LAST LASTPRI LASTLV1 LASTLV2 LASTBKP LASTTMS,
> >  SUM= ACTIVE SPACE1-SPACE6 DAYS1-DAYS6 BACKUPS VOLUMES TAPES,
> >  OUTCODE=
> >   %INCLUDE SOURCLIB(IMACZDAT); /* SET ZDATE=TODAY() */
> >OPTIONS   DSNFERR   VNFERR;
> >
> >A I understand this, it is just a sort or merge of the newly updated TREND
> with the previous week into a new generation.
> >I don't know why SAS is not informing DFSORT of the data volume. It should
> know the new record count precisely. And should be able to see the raw size
> of the previous generation..
> >
> >The main dataset is a SAS dataset:
> >Data Set Name . . . . : MXG.DATASETS.TREND
> >General Data   Current Allocation
> > Management class . . : MCRSRC01Allocated tracks  . : 84,226
> > Storage class  . . . : SCRSRC  Allocated extents . : 7
> >  Volume serial . . . : RSRC10 +
> >  Device type . . . . : 3390
> > Data class . . . . . : BIG
> >  Organization  . . . : PS Current Utilization
> >  Record format . . . : FS  Used tracks . . . . : 83,488
> >  Record length . . . : 27648   Used extents  . . . : 7
> >  Block size  . . . . : 27648
> >  1st extent tracks . : 49218
> >  Secondary tracks  . : 1000   Dates
> >  Data set name type  : Creation date . . . : 2002/03/25
> >Referenced date . . : 2021/01/25
> >Expiration date . . : ***None***
> >  SMS Compressible  . : NO
> >The other is sequential, but still SAS and many years ago, would have been
> tape be for we did the SMS Tape Mount Management stuff:
> >Data Set Name . . . . : MXG.DATASETS.WEEK.G0979V00
> >
> >General Data   Current Allocation
> > Management class . . : ATMBKUPSAllocated megabytes : 3,000
> > Storage class  . . . : SCDSKTAPAllocated extents . : 2
> >  Volume serial . . . : PTAP40 +
> >  Device type . . . . : 3390
> > Data class . . . . . : TMBKUPLG
> >  Organization 

Re: DFSORT and SAS

2021-01-25 Thread Scott Barry
t Allocation   
> Management class . . : ATMBKUPSAllocated megabytes : 3,000 
> Storage class  . . . : SCDSKTAPAllocated extents . : 2 
>  Volume serial . . . : PTAP40 +
>  Device type . . . . : 3390
> Data class . . . . . : TMBKUPLG
>  Organization  . . . : PS Current Utilization  
>  Record format . . . : U   Used megabytes  . . : 15
>  Record length . . . : 0   Used extents  . . . : 1 
>  Block size  . . . . : 32760   
>  1st extent megabytes: 1500
>  Secondary megabytes : 2500   Dates
>  Data set name type  : EXTENDEDCreation date . . . : 2021/01/11
>Referenced date . . : 2021/01/25
>Expiration date . . : ***None***
>  SMS Compressible  . : YES            
>  
>
>> -Original Message-
>> From: IBM Mainframe Discussion List  On
>> Behalf Of Sri h Kolusu
>> Sent: Monday, January 25, 2021 12:29 PM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: Re: DFSORT and SAS
>> 
>> >> OPTION
>> SORTDD=SASS,MSGDDN=SYSOUT,MAINSIZE=MAX,MSGPRT=CRITICAL,NOLIS
>> T
>> 
>> Dave,
>> 
>> What type of dataset is the input dataset(ddname SASSIN)?   Is it a tape
>> dataset? If so what kind of tape management system do you have? RMM ?
>> CA-1 ?
>> 
>> PS: Your latest joblog shows that you indeed received ICE118I message (4th
>> line in the Sortdiag file)
>> 
>> 
>> Thanks,
>> Kolusu
>> DFSORT Development
>> IBM Corporation
>> 
>> 
>> 
>> 
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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


Re: DFSORT and SAS

2021-01-25 Thread Sri h Kolusu
> But, all datasets are on disk.

Dave,

If the files are on DISK , DFSORT should be able to get the stats. Can you
please send me the COMPLETE joblog to my email offline? I want to check
allocation messages for the ddname SASSIN.

> My Tape management is CA-7

I guess you meant CA-1(Tape management) where as  CA-7 is a job scheduling
software.  CA-1 implements the ICETPEX exit which would be called by DFSORT
to get the attributes of the tape file.



Thanks,
Kolusu
DFSORT Development
IBM Corporation



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


Re: DFSORT and SAS

2021-01-25 Thread Gibney, Dave
  Secondary megabytes : 2500   Dates
  Data set name type  : EXTENDEDCreation date . . . : 2021/01/11
Referenced date . . : 2021/01/25
Expiration date . . : ***None***
  SMS Compressible  . : YES 


> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Sri h Kolusu
> Sent: Monday, January 25, 2021 12:29 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: DFSORT and SAS
> 
> >> OPTION
> SORTDD=SASS,MSGDDN=SYSOUT,MAINSIZE=MAX,MSGPRT=CRITICAL,NOLIS
> T
> 
> Dave,
> 
> What type of dataset is the input dataset(ddname SASSIN)?   Is it a tape
> dataset? If so what kind of tape management system do you have? RMM ?
> CA-1 ?
> 
> PS: Your latest joblog shows that you indeed received ICE118I message (4th
> line in the Sortdiag file)
> 
> 
> Thanks,
> Kolusu
> DFSORT Development
> IBM Corporation
> 
> 
> 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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


Re: DFSORT and SAS

2021-01-25 Thread Sri h Kolusu
>> OPTION SORTDD=SASS,MSGDDN=SYSOUT,MAINSIZE=MAX,MSGPRT=CRITICAL,NOLIST

Dave,

What type of dataset is the input dataset(ddname SASSIN)?   Is it a tape
dataset? If so what kind of tape management system do you have? RMM ?
CA-1 ?

PS: Your latest joblog shows that you indeed received ICE118I message (4th
line in the Sortdiag file)


Thanks,
Kolusu
DFSORT Development
IBM Corporation




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


Re: DFSORT and SAS

2021-01-25 Thread Gibney, Dave
I let this week's run fail and have attached the results with //SORTDIAG DD 
DUMMY and a SAS PROC OPTIONS;
I am not sure I'll open an issue with SAS. My site is working towards shutting 
down later this year or so, and I have a working solution with the DFSORT 
option on this job. This job is the only failing job (so far) following my 
shift to DFSORT.
Other things are probably more important to us than pursuing this further.

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Scott Barry
> Sent: Tuesday, January 19, 2021 4:36 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: DFSORT and SAS
> 
> SAS application programs often invoke multiple PROC SORT requests (some
> thru SQL-type invocations, or otherwise) and so there really should not be an
> OPTION FILESZ=Ennn necessary, given the SAS program-invoked
> method (i.e., SAS generates the OPTION and SORT statements.)
> 
> And so you should see evidence in SORT diagnostic output messages where
> the SAS/DFSORT request is invoked where you really should see the SORT
> statement and any preceding OPTION statement which is where you would
> see the file-size (estimated) directive.
> 
> So, if the OP codes a //SORTDIAG DD DUMMY statement and if there is no
> OPTION statement followed by the SORT FIELDS=()  invocation directive,
> then you need to open a SAS support TRACK and be ready to provide the
> entire job-output along with the SASLOG, also to include your PROC
> OPTIONS; output for their review/diagnosis.  Something is not right with the
> SAS/DFSORT invocation diagnostics output contributed in this IBM-MAIN
> group post.
> 
> Regards,
> 
> Scott Barry
> SBBTech LLC
> 
> 


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
1PROC OPTIONS;
 SAS (R) PROPRIETARY SOFTWARE RELEASE 9.01.01M3P11032004
  
 PORTABLE OPTIONS:
  
  _LAST_=_NULL_ LAST SAS DATA SET CREATED
  APPLETLOC=LOCATION OF JAVA APPLETS
  ARMAGENT= ARM AGENT TO USE TO COLLECT ARM RECORDS
  ARMLOC=ARMLOC.LOG IDENTIFY LOCATION WHERE ARM RECORDS ARE TO BE WRITTEN
  ARMSUBSYS=(ARM_NONE)
ENABLE/DISABLE ARMING OF SAS SUBSYSTEMS
  ASYNCHIO  ENABLE ASYNCHRONOUS INPUT/OUTPUT
  AUTOSAVELOC=  IDENTIFIES THE LOCATION WHERE PROGRAM EDITOR CONTENTS ARE 
AUTO SAVED
  NOAUTOSIGNON  SAS/CONNECT REMOTE SUBMIT WILL NOT AUTOMATICALLY ATTEMPT TO 
SIGNON
  NOBATCH   DO NOT USE THE BATCH SET OF DEFAULT VALUES FOR SAS SYSTEM 
OPTIONS
  BINDING=DEFAULT   CONTROLS THE BINDING EDGE FOR DUPLEXED OUTPUT
  BOTTOMMARGIN=0.000
BOTTOM MARGIN FOR PRINTED OUTPUT
  BUFNO=2   NUMBER OF BUFFERS FOR EACH SAS DATA SET
  BUFSIZE=0 SIZE OF BUFFER FOR PAGE OF SAS DATA SET
  BYERR SET THE ERROR FLAG IF A NULL DATA SET IS INPUT TO THE SORT 
PROCEDURE
  BYLINEPRINT THE BY-LINE AT THE BEGINNING OF EACH BY-GROUP
  BYSORTED  REQUIRE SAS DATA SET OBSERVATIONS TO BE SORTED FOR BY 
PROCESSING
  NOCAPSDO NOT TRANSLATE SOURCE INPUT TO UPPERCASE
  CARDIMAGE PROCESS SAS SOURCE AND DATA LINES AS 80-BYTE RECORDS
  CATCACHE=0NUMBER OF SAS CATALOGS TO KEEP IN CACHE MEMORY
  CBUFNO=1  NUMBER OF BUFFERS TO USE FOR EACH SAS CATALOG
  CENTERCENTER SAS PROCEDURE OUTPUT
  NOCHARCODEDO NOT USE CHARACTER COMBINATIONS AS SUBSTITUTE FOR SPECIAL 
CHARACTERS NOT ON THE KEYBOARD
  CLEANUP   ATTEMPT RECOVERY FROM OUT-OF-RESOURCES CONDITION
  NOCMDMAC  DO NOT SUPPORT COMMAND-STYLE MACROS
  CMPLIB=   IDENTIFY PREVIOUSLY COMPILED LIBRARIES OF CMP SUBROUTINES 
TO USE WHEN LINKING
  CMPOPT=(NOEXTRAMATH NOMISSCHECK NOPRECISE NOGUARDCHECK)
ENABLE SAS COMPILER PERFORMANCE OPTIMIZATIONS
  NOCOLLATE DO NOT COLLATE MULTIPLE COPIES OF PRINTED OUTPUT
  COLORPRINTING PRINT IN COLOR IF PRINTER SUPPORTS COLOR
  COMAMID=XMS   SPECIFIES THE COMMUNICATION ACCESS METHOD TO BE USED FOR 
SAS DISTRIBUTED PRODUCTS
  COMPRESS=YES  SPECIFIES WHETHER TO COMPRESS OBSERVATIONS IN OUTPUT SAS 
DATA SETS
  CONNECTPERSISTPERSIST CONNECTION TO REMOTE SESSION
  CONNECTREMOTE=REMOTE SESSION ID USED BY SAS/CONNECT SOFTWARE
  CONNECTSTATUS SHOW THE CURRENT STATUS OF A SAS/CONNECT UPLOAD OR DOWNLOAD 
TRANSFER
  CONNECTWAIT   WAIT FOR A SAS/CONNECT RSUBMIT TO FINISH BEFORE ALLOWING 
FURTHER PROCESSING TO OCCUR
  COPIES=1  NUMBER OF COPIES TO MAKE WHEN PRINTING
  CPUCOUNT=6NUMBER OF PROCESSORS AVAILABLE.
  CPUID PRINT CPU INFORMATION AT BEGINNING OF LOG
  DATASTMTCHK=COREKEYWORDS
CONTROL WHETHER KEYWORDS SUCH AS SET, MERGE, ETC. ARE 
ACCEPTED AS ONE-LEVEL DATASET NAMES IN THE DATA STATEMENT

Re: DFSORT and SAS

2021-01-19 Thread Scott Barry
SAS application programs often invoke multiple PROC SORT requests (some thru 
SQL-type invocations, or otherwise) and so there really should not be an OPTION 
FILESZ=Ennn necessary, given the SAS program-invoked method (i.e., SAS 
generates the OPTION and SORT statements.)

And so you should see evidence in SORT diagnostic output messages where the 
SAS/DFSORT request is invoked where you really should see the SORT statement 
and any preceding OPTION statement which is where you would see the file-size 
(estimated) directive.

So, if the OP codes a //SORTDIAG DD DUMMY statement and if there is no OPTION 
statement followed by the SORT FIELDS=()  invocation directive, then you 
need to open a SAS support TRACK and be ready to provide the entire job-output 
along with the SASLOG, also to include your PROC OPTIONS; output for their 
review/diagnosis.  Something is not right with the SAS/DFSORT invocation 
diagnostics output contributed in this IBM-MAIN group post.

Regards,

Scott Barry
SBBTech LLC


On Tue, 19 Jan 2021 21:23:21 +, Gibney, Dave  wrote:

>Seem like something that SAS should do without being told
>My checking of SAS options didn't find the settings other than the ones I 
>mentioned in original note.
>
>> -Original Message-
>> From: IBM Mainframe Discussion List  On
>> Behalf Of Martin Packer
>> Sent: Tuesday, January 19, 2021 1:09 PM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: Re: DFSORT and SAS
>> 
>> I'd ask over on MXG-L if there are methods for SAS to pass the record
>> count and average record length estimate to DFSORT.
>> 
>> Cheers, Martin
>> 
>> Martin Packer
>> 
>> Systems Investigator & Performance Troubleshooter, IBM
>> 
>> +44-7802-245-584
>> 
>> email: martin_pac...@uk.ibm.com
>> 
>> Twitter / Facebook IDs: MartinPacker
>> 
>> Blog:
>> https://urldefense.com/v3/__https://mainframeperformancetopics.com__;
>> !!JmPEgBY0HMszNaDT!-
>> jCPCp1oJgGvSG9Dtcsgk0O8m66pT5PMrB2L1_5At3l0h-ggJZr4QQ7JjmRfNQ$
>> 
>> Mainframe, Performance, Topics Podcast Series (With Marna Walle):
>> https://urldefense.com/v3/__https://anchor.fm/marna-
>> walle__;!!JmPEgBY0HMszNaDT!-
>> jCPCp1oJgGvSG9Dtcsgk0O8m66pT5PMrB2L1_5At3l0h-ggJZr4QQ5GMlQQ6Q$
>> 
>> Youtube channel:
>> https://urldefense.com/v3/__https://www.youtube.com/channel/UCu_65
>> HaYgksbF6Q8SQ4oOvA__;!!JmPEgBY0HMszNaDT!-
>> jCPCp1oJgGvSG9Dtcsgk0O8m66pT5PMrB2L1_5At3l0h-ggJZr4QQ5uyw0NKQ$
>> 
>> 
>> 
>> From:   "Gibney, Dave" 
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Date:   19/01/2021 20:14
>> Subject:[EXTERNAL] Re: DFSORT and SAS
>> Sent by:IBM Mainframe Discussion List 
>> 
>> 
>> 
>> Thank you. Adding the suggested parm allowed my job to succeed.
>> Ultimately, there where 15,890,801 records.
>> I looked again and there was not an ICE118I issued in the original job.
>> I really don't know how, or what controls SAS (v9) passes to the HOST SORT
>> 
>> Thanks again for the assistance.
>> 
>> > -Original Message-
>> > From: IBM Mainframe Discussion List  On
>> > Behalf Of Sri h Kolusu
>> > Sent: Tuesday, January 19, 2021 11:37 AM
>> > To: IBM-MAIN@LISTSERV.UA.EDU
>> > Subject: Re: DFSORT and SAS
>> >
>> > > ICE752I 0 FSZ=0 RE  IGN=0 C  AVG=188 0  WSP=0 E  DYN=2313 16352
>> >
>> > Dave,
>> >
>> > When DFSORT is invoked via  program, it needs to know how many records
>> it
>> > is sorting so that it can optimally allocate resources needed to sort
>> that
>> > data. Since the program is feeding the records DFSORT does not have a
>> clue
>> > and the resources allocated are not enough to complete the sort and
>> hence
>> > the message ICE046A 0 SORT CAPACITY EXCEEDED - RECORD COUNT
>> 6956799
>> >
>> > Generally, DFSORT can automatically determine the input file size.
>> However,
>> > in a few cases, such as when an E15 supplies all of the input records or
>> > when information about a tape data set is not available from a tape
>> > management system, DFSORT cannot determine an accurate file size.
>> >
>> > Your joblog does not show one of the important message.  You should
>> have
>> > gotten an ICE118I message
>> >
>> > ICE118I UNKNOWN FILE SIZE - RECOMMEND SPECIFYING FILSZ=EN TO
>> > REDUCE RISK OF
>> > FAILURE OR DEGRADED PERFORMANCE
>> >
>> > INVALID URI REMOVED
>> >
>> nter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3.icem100/mb00083.htm__;!!JmPEg

Re: DFSORT and SAS

2021-01-19 Thread Gibney, Dave
Seem like something that SAS should do without being told
My checking of SAS options didn't find the settings other than the ones I 
mentioned in original note.

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Martin Packer
> Sent: Tuesday, January 19, 2021 1:09 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: DFSORT and SAS
> 
> I'd ask over on MXG-L if there are methods for SAS to pass the record
> count and average record length estimate to DFSORT.
> 
> Cheers, Martin
> 
> Martin Packer
> 
> Systems Investigator & Performance Troubleshooter, IBM
> 
> +44-7802-245-584
> 
> email: martin_pac...@uk.ibm.com
> 
> Twitter / Facebook IDs: MartinPacker
> 
> Blog:
> https://urldefense.com/v3/__https://mainframeperformancetopics.com__;
> !!JmPEgBY0HMszNaDT!-
> jCPCp1oJgGvSG9Dtcsgk0O8m66pT5PMrB2L1_5At3l0h-ggJZr4QQ7JjmRfNQ$
> 
> Mainframe, Performance, Topics Podcast Series (With Marna Walle):
> https://urldefense.com/v3/__https://anchor.fm/marna-
> walle__;!!JmPEgBY0HMszNaDT!-
> jCPCp1oJgGvSG9Dtcsgk0O8m66pT5PMrB2L1_5At3l0h-ggJZr4QQ5GMlQQ6Q$
> 
> Youtube channel:
> https://urldefense.com/v3/__https://www.youtube.com/channel/UCu_65
> HaYgksbF6Q8SQ4oOvA__;!!JmPEgBY0HMszNaDT!-
> jCPCp1oJgGvSG9Dtcsgk0O8m66pT5PMrB2L1_5At3l0h-ggJZr4QQ5uyw0NKQ$
> 
> 
> 
> From:   "Gibney, Dave" 
> To: IBM-MAIN@LISTSERV.UA.EDU
> Date:   19/01/2021 20:14
> Subject:[EXTERNAL] Re: DFSORT and SAS
> Sent by:IBM Mainframe Discussion List 
> 
> 
> 
> Thank you. Adding the suggested parm allowed my job to succeed.
> Ultimately, there where 15,890,801 records.
> I looked again and there was not an ICE118I issued in the original job.
> I really don't know how, or what controls SAS (v9) passes to the HOST SORT
> 
> Thanks again for the assistance.
> 
> > -Original Message-----
> > From: IBM Mainframe Discussion List  On
> > Behalf Of Sri h Kolusu
> > Sent: Tuesday, January 19, 2021 11:37 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: DFSORT and SAS
> >
> > > ICE752I 0 FSZ=0 RE  IGN=0 C  AVG=188 0  WSP=0 E  DYN=2313 16352
> >
> > Dave,
> >
> > When DFSORT is invoked via  program, it needs to know how many records
> it
> > is sorting so that it can optimally allocate resources needed to sort
> that
> > data. Since the program is feeding the records DFSORT does not have a
> clue
> > and the resources allocated are not enough to complete the sort and
> hence
> > the message ICE046A 0 SORT CAPACITY EXCEEDED - RECORD COUNT
> 6956799
> >
> > Generally, DFSORT can automatically determine the input file size.
> However,
> > in a few cases, such as when an E15 supplies all of the input records or
> > when information about a tape data set is not available from a tape
> > management system, DFSORT cannot determine an accurate file size.
> >
> > Your joblog does not show one of the important message.  You should
> have
> > gotten an ICE118I message
> >
> > ICE118I UNKNOWN FILE SIZE - RECOMMEND SPECIFYING FILSZ=EN TO
> > REDUCE RISK OF
> > FAILURE OR DEGRADED PERFORMANCE
> >
> > INVALID URI REMOVED
> >
> nter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3.icem100/mb00083.htm__;!!JmPEg
> >
> BY0HMszNaDT!9_LGpASIz6lgFy3pDduAe2DC4jQhXQBtSHYnTd10a0weZdx0ie
> > 4mdHNVwnuilA$
> >
> > DFSORT failed after processing about 6,956,799 . So if you know how many
> > records you are going to process, then you can pass an estimated
> filesize
> > via DFSPARM like this
> >
> > //DFSPARM  DD *
> >   OPTION FILSZ=E1000
> > /*
> >
> > Since DFSORT already processed about 6.9 million records, I just
> estimated
> > that you have 10 million records. You can change that number depending
> on
> > your input file.
> >
> >
> > Further if you have any questions please let me know
> >
> > Thanks,
> > Kolusu
> > DFSORT Development
> > IBM Corporation
> >
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> 
> 
> 
> 
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
> 3AU
> 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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


Re: DFSORT and SAS

2021-01-19 Thread Martin Packer
I'd ask over on MXG-L if there are methods for SAS to pass the record 
count and average record length estimate to DFSORT.

Cheers, Martin

Martin Packer

Systems Investigator & Performance Troubleshooter, IBM

+44-7802-245-584

email: martin_pac...@uk.ibm.com

Twitter / Facebook IDs: MartinPacker

Blog: https://mainframeperformancetopics.com

Mainframe, Performance, Topics Podcast Series (With Marna Walle): 
https://anchor.fm/marna-walle

Youtube channel: https://www.youtube.com/channel/UCu_65HaYgksbF6Q8SQ4oOvA



From:   "Gibney, Dave" 
To: IBM-MAIN@LISTSERV.UA.EDU
Date:   19/01/2021 20:14
Subject:    [EXTERNAL] Re: DFSORT and SAS
Sent by:IBM Mainframe Discussion List 



Thank you. Adding the suggested parm allowed my job to succeed. 
Ultimately, there where 15,890,801 records.
I looked again and there was not an ICE118I issued in the original job.
I really don't know how, or what controls SAS (v9) passes to the HOST SORT

Thanks again for the assistance.

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Sri h Kolusu
> Sent: Tuesday, January 19, 2021 11:37 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: DFSORT and SAS
> 
> > ICE752I 0 FSZ=0 RE  IGN=0 C  AVG=188 0  WSP=0 E  DYN=2313 16352
> 
> Dave,
> 
> When DFSORT is invoked via  program, it needs to know how many records 
it
> is sorting so that it can optimally allocate resources needed to sort 
that
> data. Since the program is feeding the records DFSORT does not have a 
clue
> and the resources allocated are not enough to complete the sort and 
hence
> the message ICE046A 0 SORT CAPACITY EXCEEDED - RECORD COUNT 6956799
> 
> Generally, DFSORT can automatically determine the input file size. 
However,
> in a few cases, such as when an E15 supplies all of the input records or
> when information about a tape data set is not available from a tape
> management system, DFSORT cannot determine an accurate file size.
> 
> Your joblog does not show one of the important message.  You should have
> gotten an ICE118I message
> 
> ICE118I UNKNOWN FILE SIZE - RECOMMEND SPECIFYING FILSZ=EN TO
> REDUCE RISK OF
> FAILURE OR DEGRADED PERFORMANCE
> 
> INVALID URI REMOVED
> nter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3.icem100/mb00083.htm__;!!JmPEg
> BY0HMszNaDT!9_LGpASIz6lgFy3pDduAe2DC4jQhXQBtSHYnTd10a0weZdx0ie
> 4mdHNVwnuilA$
> 
> DFSORT failed after processing about 6,956,799 . So if you know how many
> records you are going to process, then you can pass an estimated 
filesize
> via DFSPARM like this
> 
> //DFSPARM  DD *
>   OPTION FILSZ=E1000
> /*
> 
> Since DFSORT already processed about 6.9 million records, I just 
estimated
> that you have 10 million records. You can change that number depending 
on
> your input file.
> 
> 
> Further if you have any questions please let me know
> 
> Thanks,
> Kolusu
> DFSORT Development
> IBM Corporation
> 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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




Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU


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


Re: DFSORT and SAS

2021-01-19 Thread Sri h Kolusu
> Thank you. Adding the suggested parm allowed my job to succeed.

Dave,

Glad to hear that the job is successful.

> Ultimately, there where 15,890,801 records.

May be you should pass 18 million as estimated filesize to account for
future growth.


Thanks,
Kolusu
DFSORT Development
IBM Corporation



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


Re: DFSORT and SAS

2021-01-19 Thread Gibney, Dave
Thank you. Adding the suggested parm allowed my job to succeed. Ultimately, 
there where 15,890,801 records.
I looked again and there was not an ICE118I issued in the original job.
I really don't know how, or what controls SAS (v9) passes to the HOST SORT

Thanks again for the assistance.

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Sri h Kolusu
> Sent: Tuesday, January 19, 2021 11:37 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: DFSORT and SAS
> 
> > ICE752I 0 FSZ=0 RE  IGN=0 C  AVG=188 0  WSP=0 E  DYN=2313 16352
> 
> Dave,
> 
> When DFSORT is invoked via  program, it needs to know how many records it
> is sorting so that it can optimally allocate resources needed to sort that
> data. Since the program is feeding the records DFSORT does not have a clue
> and the resources allocated are not enough to complete the sort and hence
> the message ICE046A 0 SORT CAPACITY EXCEEDED - RECORD COUNT 6956799
> 
> Generally, DFSORT can automatically determine the input file size. However,
> in a few cases, such as when an E15 supplies all of the input records or
> when information about a tape data set is not available from a tape
> management system, DFSORT cannot determine an accurate file size.
> 
> Your joblog does not show one of the important message.  You should have
> gotten an ICE118I message
> 
> ICE118I UNKNOWN FILE SIZE - RECOMMEND SPECIFYING FILSZ=EN TO
> REDUCE RISK OF
> FAILURE OR DEGRADED PERFORMANCE
> 
> https://urldefense.com/v3/__https://www.ibm.com/support/knowledgece
> nter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3.icem100/mb00083.htm__;!!JmPEg
> BY0HMszNaDT!9_LGpASIz6lgFy3pDduAe2DC4jQhXQBtSHYnTd10a0weZdx0ie
> 4mdHNVwnuilA$
> 
> DFSORT failed after processing about 6,956,799 . So if you know how many
> records you are going to process, then you can pass an estimated filesize
> via DFSPARM like this
> 
> //DFSPARM  DD *
>   OPTION FILSZ=E1000
> /*
> 
> Since DFSORT already processed about 6.9 million records, I just estimated
> that you have 10 million records. You can change that number depending on
> your input file.
> 
> 
> Further if you have any questions please let me know
> 
> Thanks,
> Kolusu
> DFSORT Development
> IBM Corporation
> 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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


Re: DFSORT and SAS

2021-01-19 Thread Sri h Kolusu
> ICE752I 0 FSZ=0 RE  IGN=0 C  AVG=188 0  WSP=0 E  DYN=2313 16352

Dave,

When DFSORT is invoked via  program, it needs to know how many records it
is sorting so that it can optimally allocate resources needed to sort that
data. Since the program is feeding the records DFSORT does not have a clue
and the resources allocated are not enough to complete the sort and hence
the message ICE046A 0 SORT CAPACITY EXCEEDED - RECORD COUNT 6956799

Generally, DFSORT can automatically determine the input file size. However,
in a few cases, such as when an E15 supplies all of the input records or
when information about a tape data set is not available from a tape
management system, DFSORT cannot determine an accurate file size.

Your joblog does not show one of the important message.  You should have
gotten an ICE118I message

ICE118I UNKNOWN FILE SIZE - RECOMMEND SPECIFYING FILSZ=EN TO REDUCE RISK OF
FAILURE OR DEGRADED PERFORMANCE

https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3.icem100/mb00083.htm

DFSORT failed after processing about 6,956,799 . So if you know how many
records you are going to process, then you can pass an estimated filesize
via DFSPARM like this

//DFSPARM  DD *
  OPTION FILSZ=E1000
/*

Since DFSORT already processed about 6.9 million records, I just estimated
that you have 10 million records. You can change that number depending on
your input file.


Further if you have any questions please let me know

Thanks,
Kolusu
DFSORT Development
IBM Corporation


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