subject:"DFSORT"


W dniu 30.07.2021 o 17:45, Radoslaw Skorupka pisze:

W dniu 30.07.2021 o 17:33, Paul Gilmartin pisze:

On Fri, 30 Jul 2021 09:54:51 -0500, Mike Schwab wrote:


Try 5 pairs of conditions?
INCLUDE COND=((5,4,CH,EQ,C'0205',AND,83,3,CH,EQ,C'YES'),
OR,(5,4,CH,EQ,C'0205',AND,88,3,CH,EQ,C'YES'),
OR,(5,4,CH,EQ,C'0205',AND,93,3,CH,EQ,C'YES'),
OR,(5,4,CH,EQ,C'0205',AND,98,3,CH,EQ,C'YES'),
OR,(5,4,CH,EQ,C'0102',AND,28,7,CH,NE,C'USE    '))


What's DFSORT's operator precedence?  Was it necessary to bracket the
conjunctions in order that they have higher precedence than
the alternations?

Are you just rewriting Radoslaw's expression according to the 
Distributive Law?

Does DFSORTT not recognize the Distributive Law?


1. Operator precedence. According to documentation AND is first. 
However parenthesis should change it and it is allow to use as many 
parenthesis as needed.


2. DFSORT should recognize the law (Rozdzielność działań in Polish)

3. I found another mystery, which seems to be APARable:

The following statement gives several test records as expected:
INCLUDE COND=(5,4,CH,EQ,C'0205',AND,(83,3,CH,EQ,C'YES',OR,
 88,3,CH,EQ,C'YES',OR,
 93,3,CH,EQ,C'YES',OR,
 98,3,CH,EQ,C'YES'))

But this statement gives zero records. Note, I added "OR" conditions, 
so it cannot narrow the output.

INCLUDE COND=(5,4,CH,EQ,C'0205',AND,(83,3,CH,EQ,C'YES',OR,
 88,3,CH,EQ,C'YES',OR,
 93,3,CH,EQ,C'YES',OR,
 99,3,CH,EQ,C'YES',OR,
    103,3,CH,EQ,C'YES',OR,
    113,3,CH,EQ,C'YES'))



"The truth is out there"
The above example work properly with OPTION VLSCMP
And in fact my previous examples should have VLSCMP, not VLSHRT.
And for 0102 record I misunderstood (not very clear) documentation - the 
field length is NOT fixed, so blank characters after 'USE' were my wrong 
assumption.


Thank you all gentlemen for help.
And special thanks to Sri Hari for the solution and explanation.


Regards
--
Radoslaw Skorupka
Lodz, Poland

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

Re: DFSORT - AND/OR mystery

2021-07-30 Thread Sri h Kolusu

> The input contains '0102' and '0205' records and simple statement with
only one type show expected output.

Radoslaw,

The given conditions should work , however you should realize that IRRDB00
output is record format V and the length of the record is stored in RDW. So
a 0102 record with  authority USE can only have a length of 26 , but you
are checking the AUTH field for a length of 7 bytes. In such cases VLSCMP
parm will be useful, however it would pad binary zeroes for short records,
which would make the 28,7,CH,BE,C'USE' as true as there are binary zeroes
after the word USE and when compared against spaces it would be a true
condition and will be included in the output. So to handle such scenario,
just do the compare on 3 bytes

I also added comments to the control cards so that it is easy to understand

//SYSINDD *
  OPTION COPY,VLSCMP
  INCLUDE COND=((05,4,CH,EQ,C'0205',AND,$ USCON_RECORD_TYPE
(83,3,CH,EQ,C'YES',OR,  $ USCON_GRP_ADSP
 88,3,CH,EQ,C'YES',OR,  $ USCON_GRP_SPECIAL
 93,3,CH,EQ,C'YES',OR,  $ USCON_GRP_OPER
 98,3,CH,EQ,C'YES')),OR,$ USCON_REVOKE
(05,4,CH,EQ,C'0102',AND,$ GPMEM_RECORD_TYPE
 28,3,CH,NE,C'USE'))$ GPMEM_AUTH
/*
This should give produce the right results

Ideally I would have used DFSORT symbols for all the fields and that way it
is easy to follow. Something like this

//SYMNOUT  DD SYSOUT=*
//SYMNAMES DD *
RDW,1,4,BI
USCON_RECORD_TYPE,5,4,CH
USCON_GRP_ADSP,83,3,CH
USCON_GRP_SPECIAL,88,3,CH
USCON_GRP_OPER,93,3,CH
USCON_REVOKE,98,3,CH
GPMEM_RECORD_TYPE,5,4,CH
GPMEM_AUTH,28,3,CH
/*

//SYSINDD *
  OPTION COPY,VLSCMP
  INCLUDE COND=((USCON_RECORD_TYPE,EQ,C'0205',AND,
(USCON_GRP_ADSP,EQ,C'YES',OR,
 USCON_GRP_SPECIAL,EQ,C'YES',OR,
 USCON_GRP_OPER,EQ,C'YES',OR,
 USCON_REVOKE,EQ,C'YES')),OR,
(GPMEM_RECORD_TYPE,EQ,C'0102',AND,
 GPMEM_AUTH,NE,C'USE'))
/*

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/OR mystery


W dniu 30.07.2021 o 17:33, Paul Gilmartin pisze:

On Fri, 30 Jul 2021 09:54:51 -0500, Mike Schwab wrote:


Try 5 pairs of conditions?
INCLUDE COND=((5,4,CH,EQ,C'0205',AND,83,3,CH,EQ,C'YES'),
  OR,(5,4,CH,EQ,C'0205',AND,88,3,CH,EQ,C'YES'),
   OR,(5,4,CH,EQ,C'0205',AND,93,3,CH,EQ,C'YES'),
   OR,(5,4,CH,EQ,C'0205',AND,98,3,CH,EQ,C'YES'),
   OR,(5,4,CH,EQ,C'0102',AND,28,7,CH,NE,C'USE'))


What's DFSORT's operator precedence?  Was it necessary to bracket the
conjunctions in order that they have higher precedence than
the alternations?

Are you just rewriting Radoslaw's expression according to the Distributive Law?
Does DFSORTT not recognize the Distributive Law?


1. Operator precedence. According to documentation AND is first. However 
parenthesis should change it and it is allow to use as many parenthesis 
as needed.


2. DFSORT should recognize the law (Rozdzielność działań in Polish)

3. I found another mystery, which seems to be APARable:

The following statement gives several test records as expected:
INCLUDE COND=(5,4,CH,EQ,C'0205',AND,(83,3,CH,EQ,C'YES',OR,
 88,3,CH,EQ,C'YES',OR,
 93,3,CH,EQ,C'YES',OR,
 98,3,CH,EQ,C'YES'))

But this statement gives zero records. Note, I added "OR" conditions, so 
it cannot narrow the output.

INCLUDE COND=(5,4,CH,EQ,C'0205',AND,(83,3,CH,EQ,C'YES',OR,
 88,3,CH,EQ,C'YES',OR,
 93,3,CH,EQ,C'YES',OR,
 99,3,CH,EQ,C'YES',OR,
    103,3,CH,EQ,C'YES',OR,
    113,3,CH,EQ,C'YES'))






--
Radoslaw Skorupka
Lodz, Poland

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

Re: DFSORT - AND/OR mystery

2021-07-30 Thread Paul Gilmartin

On Fri, 30 Jul 2021 09:54:51 -0500, Mike Schwab wrote:

>Try 5 pairs of conditions?
>INCLUDE COND=((5,4,CH,EQ,C'0205',AND,83,3,CH,EQ,C'YES'),
>  OR,(5,4,CH,EQ,C'0205',AND,88,3,CH,EQ,C'YES'),
>   OR,(5,4,CH,EQ,C'0205',AND,93,3,CH,EQ,C'YES'),
>   OR,(5,4,CH,EQ,C'0205',AND,98,3,CH,EQ,C'YES'),
>   OR,(5,4,CH,EQ,C'0102',AND,28,7,CH,NE,C'USE'))
>
What's DFSORT's operator precedence?  Was it necessary to bracket the
conjunctions in order that they have higher precedence than
the alternations?

Are you just rewriting Radoslaw's expression according to the Distributive Law?
Does DFSORTT not recognize the Distributive Law?

>On Fri, Jul 30, 2021 at 9:36 AM Radoslaw Skorupka wrote:
>> The following statement is syntactically correct:
>>
>> INCLUDE COND=((5,4,CH,EQ,C'0205',AND,(83,3,CH,EQ,C'YES',OR,
>>88,3,CH,EQ,C'YES',OR,
>>93,3,CH,EQ,C'YES',OR,
>>98,3,CH,EQ,C'YES')),
>>  OR,(5,4,CH,EQ,C'0102',AND,28,7,CH,NE,C'USE'))
>>
>> however SORTOUT contains only records '0205'.
>> The input contains '0102' and '0205' records and simple statement with
>> only one type show expected output.

-- gil

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

Re: DFSORT - AND/OR mystery

2021-07-30 Thread Mike Schwab

Try 5 pairs of conditions?
INCLUDE COND=((5,4,CH,EQ,C'0205',AND,83,3,CH,EQ,C'YES'),
  OR,(5,4,CH,EQ,C'0205',AND,88,3,CH,EQ,C'YES'),
   OR,(5,4,CH,EQ,C'0205',AND,93,3,CH,EQ,C'YES'),
   OR,(5,4,CH,EQ,C'0205',AND,98,3,CH,EQ,C'YES'),
   OR,(5,4,CH,EQ,C'0102',AND,28,7,CH,NE,C'USE'))

On Fri, Jul 30, 2021 at 9:36 AM Radoslaw Skorupka
 wrote:
>
> The following statement is syntactically correct:
>
>
> INCLUDE COND=((5,4,CH,EQ,C'0205',AND,(83,3,CH,EQ,C'YES',OR,
>88,3,CH,EQ,C'YES',OR,
>93,3,CH,EQ,C'YES',OR,
>98,3,CH,EQ,C'YES')),
>  OR,(5,4,CH,EQ,C'0102',AND,28,7,CH,NE,C'USE'))
>
> however SORTOUT contains only records '0205'.
> The input contains '0102' and '0205' records and simple statement with
> only one type show expected output.
>
> Simple statement
> INCLUDE COND=((5,4,CH,EQ,C'0102'),OR,
> (5,4,CH,EQ,C'0205'))
> show all records of both types - 0102 and 0205.
>
> However any AND inside 0205 causes only records with YES in proper field
> are returned to output. So "YES condition applies to both 0102 and 0205
> records, despite of parenthesis.
>
> --
> Radoslaw Skorupka
> Lodz, Poland
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



-- 
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

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

Re: DFSORT - compare two fields


Yes, it works as desired.
Thank you!

--
Radoslaw Skorupka
Lodz, Poland




W dniu 30.07.2021 o 14:31, S.Karthik Premnath pisze:

HTH

//RSPROF EXEC PGM=ICETOOL
//TOOLMSG DD SYSOUT=*
//DFSMSG DD SYSOUT=*
//IRRDBU00 DD DISP=SHR,DSN=
//OUTPUT DD SYSOUT=*
//TOOLIN DD *
SELECT FROM(IRRDBU00) TO(OUTPUT) USING(CTL1)
/*
//CTL1CNTL DD *
INCLUDE COND=(50,8,CH,NE,60,8,CH)
/*

Assuming 50,8 & 60,8 are offset and length of userid & groupname
respectively.


Karthik Premnath.

On Fri, Jul 30, 2021 at 4:20 PM Radoslaw Skorupka 
wrote:


The following scenario:
IRRDBU00 file, record type 0203 - this is about user to group connection.
There are fields: groupname and owner. Usually the owner is also the group.
I want to list all the record where owner is not groupname.

So the goal is to compare two (fixed) fields and include/omit records.
Of course it can be done in REXX, but I think DFSORT is more efficient.
Any clue?

--
Radoslaw Skorupka
Lodz, Poland

--



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

DFSORT - AND/OR mystery


The following statement is syntactically correct:


INCLUDE COND=((5,4,CH,EQ,C'0205',AND,(83,3,CH,EQ,C'YES',OR,
  88,3,CH,EQ,C'YES',OR,
  93,3,CH,EQ,C'YES',OR,
  98,3,CH,EQ,C'YES')),
    OR,(5,4,CH,EQ,C'0102',AND,28,7,CH,NE,C'USE    '))

however SORTOUT contains only records '0205'.
The input contains '0102' and '0205' records and simple statement with 
only one type show expected output.


Simple statement
INCLUDE COND=((5,4,CH,EQ,C'0102'),OR,
   (5,4,CH,EQ,C'0205'))
show all records of both types - 0102 and 0205.

However any AND inside 0205 causes only records with YES in proper field 
are returned to output. So "YES condition applies to both 0102 and 0205 
records, despite of parenthesis.


--
Radoslaw Skorupka
Lodz, Poland

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

Re: DFSORT - compare two fields

2021-07-30 Thread S.Karthik Premnath

HTH

//RSPROF EXEC PGM=ICETOOL
//TOOLMSG DD SYSOUT=*
//DFSMSG DD SYSOUT=*
//IRRDBU00 DD DISP=SHR,DSN=
//OUTPUT DD SYSOUT=*
//TOOLIN DD *
SELECT FROM(IRRDBU00) TO(OUTPUT) USING(CTL1)
/*
//CTL1CNTL DD *
INCLUDE COND=(50,8,CH,NE,60,8,CH)
/*

Assuming 50,8 & 60,8 are offset and length of userid & groupname
respectively.


Karthik Premnath.

On Fri, Jul 30, 2021 at 4:20 PM Radoslaw Skorupka 
wrote:

> The following scenario:
> IRRDBU00 file, record type 0203 - this is about user to group connection.
> There are fields: groupname and owner. Usually the owner is also the group.
> I want to list all the record where owner is not groupname.
>
> So the goal is to compare two (fixed) fields and include/omit records.
> Of course it can be done in REXX, but I think DFSORT is more efficient.
> Any clue?
>
> --
> Radoslaw Skorupka
> Lodz, Poland
>
> --
> 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

DFSORT - compare two fields


The following scenario:
IRRDBU00 file, record type 0203 - this is about user to group connection.
There are fields: groupname and owner. Usually the owner is also the group.
I want to list all the record where owner is not groupname.

So the goal is to compare two (fixed) fields and include/omit records.
Of course it can be done in REXX, but I think DFSORT is more efficient.
Any clue?

--
Radoslaw Skorupka
Lodz, Poland

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

Re: DFSORT and SMF date selection

2021-06-15 Thread Martin Packer

Also DFSORT gives you more record selection flexibility than IFASMFDP / 
IFASMFDL.

Cheers, Martin

Martin Packer

WW z/OS Performance, Capacity and Architecture, IBM Technology Sales

+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:   Sri h Kolusu 
To: IBM-MAIN@LISTSERV.UA.EDU
Date:   14/06/2021 22:51
Subject:[EXTERNAL] Re: DFSORT and SMF date selection
Sent by:IBM Mainframe Discussion List 



>>Why not just use IFASMFDP?

Micahel,

Probably due to fact that IFASMFDP does not give you the option of
dynamically changing the date. Tim wanted Current date - 7 days worth of
data. IFASMFDP only allows you hard coded dates for DATE parameter.  So 
Tim
has to change the control cards every time he wants to run the job. With
DFSORT you don't have to do it as it can automatically perform the Date
Arithmetic.

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




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 SMF date selection

Thank you, I think this is a better solution for me right now.

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

Re: DFSORT and SMF date selection

I am not using IFASMFDP I am doing other things in the DFSORT application.  I'm 
trying not to do all of the I/O to select the records with IFASMFDP, then read 
the selected records a second time into DFSORT to process them.

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

Re: DFSORT and SMF date selection

2021-06-14 Thread Sri h Kolusu

>>Why not just use IFASMFDP?

Micahel,

Probably due to fact that IFASMFDP does not give you the option of
dynamically changing the date. Tim wanted Current date - 7 days worth of
data. IFASMFDP only allows you hard coded dates for DATE parameter.  So Tim
has to change the control cards every time he wants to run the job. With
DFSORT you don't have to do it as it can automatically perform the Date
Arithmetic.

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 SMF date selection

2021-06-14 Thread Michael Oujesky


Why not just use IFASMFDP?

Michael

At 02:32 PM 6/14/2021, Tim Hare wrote:

The brain  is just not working today I guess.  I want to use DFSORT 
to select some SMF records for a week;  I'm getting myself confused 
in the DFSORT application programming guide


Do I want to use

INCLUDE COND=(11,4,PD,GE,)

or

INCLUDE COND=(11,4,Y4U,GE,)

or have I missed something entirely.   The point is to have the job 
be scheduled weekly,  after our last SMF dump at midnight and 
subsequent accumulation of SMF records so today's date minus 7 gives 
us yesterday and the 6 days previous.  I'm just not sure of the 
right way to do this with SMF dates which are right now x'0121165F'


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

Re: DFSORT and SMF date selection

2021-06-14 Thread Sri h Kolusu

>>since I am not interested in dates in the 20th century,  could I use
COND=(12,3,Y2U,GE,) ?

Tim,

If you are input data is always going to 20th century then you use Y2U
format in the form Y'string' . Something like this

INCLUDE COND=(12,3,Y2U,GE,Y'DATE3'-7)

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 SMF date selection

Thanks for the solution.  I am wondering, though:  since I am not interested in 
dates in the 20th century,  could I use COND=(12,3,Y2U,GE,) ?  The 
rightmost 3 bytes of the SMF date would seem to satisfy Y2U and as long as my 
offset of -7 doesn't take me to a previous century I should be OK, right?

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

Re: DFSORT and SMF date selection

2021-06-14 Thread Sri h Kolusu

>>The point is to have the job  be scheduled weekly,  after our last SMF
dump at midnight and
> subsequent accumulation of SMF records so today's date minus 7 gives

Tim,

The SMFDATE format is NOT your typical Date format. A 4-byte SMF date value
in the form P'cyyddd' (X'0cyydddF')  where c= century and YY current year
and DDD = Day of the year.

If C=0 then century=19
if C=1 then century=20
If C=2 then century=21

You need to generate the constant as C=1  YY=21 and DDD = current year day
of the year - 7 = 165 - 7 =158

So the INCLUDE COND would be INCLUDE COND=(11,4,PD,GE,121158)

You can generate the constant dynamically.  Use the following JCL


// EXPORT SYMLIST=*
// SET DAYOFSET=7
/*
//***
//* Generate a symbol in SMF date format subtract the day offset*
//***
//STEP0100 EXEC PGM=SORT
//SYSOUT   DD SYSOUT=*
//SORTIN   DD *
ABC
//SORTOUT  DD DSN=&,DISP=(,PASS),SPACE=(TRK,(1,0),RLSE)
//SYSINDD *,SYMBOLS=JCLONLY
  OPTION COPY
  INREC BUILD=(DATE3-)
  OUTREC OVERLAY=(01,02,ZD,SUB,+19,EDIT=(TT))
  OUTFIL REMOVECC,NODETAIL,BUILD=(80X),
  HEADER1=(C'PICKDATE,',1,7)
/*
//***
//* Use the symbol to pick the desired smf records  *
//***
//STEP0200 EXEC PGM=SORT
//SYSOUT   DD SYSOUT=*
//SYMNAMES DD DISP=(OLD,PASS),DSN=&
//SYMNOUT  DD SYSOUT=*
//SORTIN   DD DISP=SHR,DSN=Your SMF dataset
//SORTOUT  DD DSN=Your output dataset,
//DISP=(NEW,CATLG,DELETE),
//SPACE=(CYL,(X,Y),RLSE)
//SYSINDD *
  OPTION COPY
  INCLUDE COND=(11,4,PD,GE,PICKDATE)
/*


Check the SYMNOUT dataset to see the value of PICKDATE

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

DFSORT and SMF date selection

The brain  is just not working today I guess.  I want to use DFSORT to select 
some SMF records for a week;  I'm getting myself confused in the DFSORT 
application programming guide

Do I want to use 

INCLUDE COND=(11,4,PD,GE,) 

or

INCLUDE COND=(11,4,Y4U,GE,)

or have I missed something entirely.   The point is to have the job be 
scheduled weekly,  after our last SMF dump at midnight and subsequent 
accumulation of SMF records so today's date minus 7 gives us yesterday and the 
6 days previous.  I'm just not sure of the right way to do this with SMF dates 
which are right now x'0121165F'

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

Re: SORTWK allocations for DFSORT vs Syncsort

2021-04-01 Thread Sri h Kolusu

Robert,

DFSORT has the ability of recovering from B37 abends. Please send the
complete joblog to my id and it will be helpful to diagnose the problem.

Thanks,
Kolusu
DFSORT Development
IBM Corporation


IBM Mainframe Discussion List  wrote on
04/01/2021 01:49:29 PM:

> From: Robert Hahne 
> To: IBM-MAIN@LISTSERV.UA.EDU
> Date: 04/01/2021 01:49 PM
> Subject: [EXTERNAL] SORTWK allocations for DFSORT vs Syncsort
> Sent by: IBM Mainframe Discussion List 
>
> Greetings ,
>
>   I recently noticed the way syncsort handles dynamic allocation for
> SORTWK datasets and they appear to be avoiding B37 abends better
> than DFSORT and I am assuming thats because syncsort allocates
> SORTWK datasets on "as needed" basis where as DFSORT tries to
> allocate all of them ahead according to the value specified in
> DYNALOC ICEOPTS . Any suggestions on how to fine tune DFSORT dynamic
> SORTWK allocations  ?
>
> Regards,
> Robert Hahne
>
> --
> 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

SORTWK allocations for DFSORT vs Syncsort

2021-04-01 Thread Robert Hahne

Greetings ,

  I recently noticed the way syncsort handles dynamic allocation for SORTWK 
datasets and they appear to be avoiding B37 abends better than DFSORT and I am 
assuming thats because syncsort allocates SORTWK datasets on "as needed" basis 
where as DFSORT tries to allocate all of them ahead according to the value 
specified in DYNALOC ICEOPTS . Any suggestions on how to fine tune DFSORT 
dynamic SORTWK allocations  ?

Regards,
Robert Hahne

--
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

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

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   Curren

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

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  . . . : PS Current Utilization  
  Record format . . . : U   Used megabytes  . . : 15
  Record length . . . : 0   Used extents  . . . : 1 
  Block size  . . . . : 32760   
  1st extent megabytes: 1500

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

DFSORT and SAS

2021-01-19 Thread Gibney, Dave

I recently switched to DFSORT. Hopefully this is the last glitch. My weekly MXG 
(SAS) job failed in the TRNDDSNS step. I am not yet familiar with DFSORT 
messages.
The step has REGION=0M and I have no special memory exits.
The SAS SORT options are:
DYNALLOC
SORTDEV=3390
SORTBLKMODE
SORTDEVWARN

If I need to, I can ask my MFaaS provider open SR with IBM, but I thought I'd 
try here first.
DFSORT messages:
ICE805I 0 JOBNAME: SYS802   , STEPNAME: TRNDDSNS
ICE802I 0 BLOCKSET TECHNIQUE IN CONTROL
ICE906I 0 ST=ABOVE,SR=6291456,RC=0
ICE907I 0 ST=ABOVE,SA=6291440,NF=1,LF=6291440,SF=6291440
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 1
ICE751I 0 C5-I58435 C6-BASE   C7-I58435 C8-I58435 E4-I64607 C9-BASE   E5-I58435 
E6-I58435 C4-BASE   E7-I58377
ICE750I 0 DC 0 TC 0 CS DSVVV KSZ 48 VSZ 48
ICE887I 0 CSES 0,0,0 ES 0,0,0
ICE886I 0 SYS 0 TSTG 0 FS 0 INIT 0 MAX 0 LEN 0
ICE752I 0 FSZ=0 RE  IGN=0 C  AVG=188 0  WSP=0 E  DYN=2313 16352
ICE915I 0 MOFSZ=16,MOSZ=0,MOSYS=900(5),MOSTG=900,MEML=17592186039798(3)
ICE916I 0 MOFR=0402,MOVR=VV
ICE996I 0 
ESM=460862,ESO=230431,ESR=46086,ESP=4096,ESS=16384,CES=847104,HSZ=16777216
ICE997I 0 HWSP=0,HMAX=0,MOMAX=230400,ASV=230431,EQ=I3,HN=1
ICE898I 0 
OMAX=0,NMAX=460862,ENQT=230431,CMAX=24576,HU=98,BUN=16352,MD=NK,M2,DU=83,DR=0,HN=1
ICE880I 0 QP=5 QA=5 HI=57 LI=53 MI=57 TZ=17439 N1=16384 N2=16384 SZ=7 HN=1
ICE889I 0 CT=MAX , SB=3, L=0, D=, CCW=1MAM
ICE901I 0 W 02NP15 04NP15 03NP15 01NP11
ICE906I 1 ST=ABOVE,SR=6234096,RC=0
ICE907I 1 ST=ABOVE,SA=6234080,NF=1,LF=6234080,SF=6234080
ICE906I 1 ST=BELOW,SR=47872,RC=0
ICE907I 1 ST=BELOW,SA=39664,NF=1,LF=39664,SF=39664
ICE996I 1 
ESM=433457,ESO=216728,ESR=43345,ESP=4096,ESS=16384,CES=847104,HSZ=16777216
ICE897I 0 AVAL=0,BVAL=433457,ENQT=204800,ASV=216728,HSZ=24576,HM=MH,HN=2
ICE880I 0 QP=4 QA=7 HI=50 LI=47 MI=53 TZ=16384 N1=16384 N2=16384 SZ=7 HN=2
ICE996I 1 
ESM=418628,ESO=209314,ESR=41862,ESP=4096,ESS=16384,CES=847104,HSZ=16777216
ICE897I 0 AVAL=0,BVAL=418628,ENQT=180224,ASV=209314,HSZ=24576,HM=MH,HN=3
ICE880I 0 QP=4 QA=12 HI=44 LI=41 MI=52 TZ=16384 N1=16384 N2=16384 SZ=7 HN=3
ICE996I 1 
ESM=393981,ESO=196990,ESR=39398,ESP=4096,ESS=16384,CES=847104,HSZ=16777216
ICE897I 0 AVAL=0,BVAL=393981,ENQT=155648,ASV=196990,HSZ=24576,HM=MH,HN=4
ICE880I 0 QP=4 QA=15 HI=38 LI=35 MI=49 TZ=16384 N1=16384 N2=16384 SZ=7 HN=4
ICE996I 1 
ESM=365424,ESO=182712,ESR=36542,ESP=4096,ESS=16384,CES=847104,HSZ=16777216
ICE897I 0 AVAL=0,BVAL=365424,ENQT=131072,ASV=182712,HSZ=24576,HM=MH,HN=5
ICE880I 0 QP=4 QA=17 HI=32 LI=29 MI=45 TZ=16384 N1=16384 N2=16384 SZ=7 HN=5
ICE996I 1 
ESM=334897,ESO=167448,ESR=33489,ESP=4096,ESS=16384,CES=847104,HSZ=16777216
ICE897I 0 AVAL=0,BVAL=334897,ENQT=106496,ASV=167448,HSZ=24576,HM=MH,HN=6
ICE880I 0 QP=4 QA=19 HI=26 LI=23 MI=41 TZ=16384 N1=16384 N2=16384 SZ=7 HN=6
ICE996I 1 
ESM=311364,ESO=155682,ESR=31136,ESP=4096,ESS=16384,CES=847104,HSZ=16777216
ICE897I 0 AVAL=0,BVAL=311364,ENQT=81920,ASV=155682,HSZ=24576,HM=MH,HN=7
ICE880I 0 QP=4 QA=23 HI=20 LI=17 MI=39 TZ=16384 N1=16384 N2=16384 SZ=7 HN=7
ICE996I 1 
ESM=289082,ESO=144541,ESR=28908,ESP=4096,ESS=16384,CES=847104,HSZ=16777216
ICE897I 0 AVAL=0,BVAL=289082,ENQT=57344,ASV=144541,HSZ=24576,HM=MH,HN=8
ICE880I 0 QP=4 QA=26 HI=14 LI=11 MI=36 TZ=16384 N1=16384 N2=16384 SZ=7 HN=8
ICE996I 1 
ESM=264237,ESO=132118,ESR=26423,ESP=4096,ESS=16384,CES=847104,HSZ=16777216
ICE897I 0 AVAL=0,BVAL=264237,ENQT=32768,ASV=132118,HSZ=24576,HM=MH,HN=9
ICE880I 0 QP=4 QA=29 HI=8 LI=5 MI=33 TZ=16384 N1=16384 N2=16384 SZ=7 HN=9
ICE996I 1 
ESM=236273,ESO=118136,ESR=23627,ESP=4096,ESS=16384,CES=847104,HSZ=16777216
ICE897I 0 AVAL=0,BVAL=236273,ENQT=8192,ASV=118136,HSZ=8192,HM=MH,HN=10
ICE880I 0 QP=2 QA=29 HI=2 LI=1 MI=29 TZ=8192 N1=8192 N2=8192 SZ=3 HN=10
ICE996I 1 
ESM=228076,ESO=114038,ESR=22807,ESP=4096,ESS=16384,CES=847104,HSZ=16777216
ICE897I 0 AVAL=0,BVAL=228076,ENQT=0,ASV=114038,HSZ=0,HM=M1,HN=11
ICE046A 0 SORT CAPACITY EXCEEDED - RECORD COUNT 6956799

SAS messages:
ERROR: SORT DID NOT COMPLETE SUCCESSFULLY. SEE MESSAGES ON THE JOB CONSOLE LOG 
OR //SYSOUT DATA SET.
ERROR: HOST SORT CANNOT BE USED
NOTE: THE VIEW WORK.MXGSUM1.VIEW USED THE FOLLOWING RESOURCES:
  CPU TIME - 00:00:07.17

  ELAPSED TIME - 00:00:18.87
  EXCP COUNT   - 22756
  TASK  MEMORY - 3631K (176K DATA, 3455K PROGRAM)
  TOTAL MEMORY - 20622K (7200K DATA, 13422K PROGRAM)
NOTE: THE ADDRESS SPACE HAS USED A MAXIMUM OF 1644K BELOW THE LINE AND 27296K 
ABOVE THE LINE.

NOTE: THERE WERE 343993 OBSERVATIONS READ FROM THE DATA SET WEEK.DATASETS.
NOTE: THERE WERE 6612827 OBSERVATIONS READ FROM THE DATA SET TREND.TRNDDSNS.
NOTE: THE SAS SYSTEM STOPPED PROCESSING THIS STEP BECAUSE OF ERRORS.

Dave Gibney
Information Technology Services
Washington State University


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

Re: Bug in DFSORT? [WAS: Merging multiple records using DFSORT]

2021-01-15 Thread Sri h Kolusu

> And that's the way IBM nowadays treats it's customers?

Customer? If you are a customer you would have gone thru proper channels of
opening a PMR and Level 2 would answer your questions. Please do that.

>Too bad I don't have the
> email address of Arvind Krishna, I would have loved to CC: this reply to
him!

Wow. Is that a threat?

>>As for the product you're responsible for? In 1964 IBM developed a
programming
language, PL/I, without keywords also being reserved words, alleviating the
need
to ever having to change programs when new keywords were introduced. Why
can't
you do that for SORT?

If you want something done, there are proper channels for requesting it.
RFE is one of it

https://www.ibm.com/developerworks/rfe/


> Using an adblocker is too hard? Ask yourself, would Frank Yaeger have
been
> deterred by ads when supporting an IBM product?

I use adblocker in addition to Umatrix. Thanks for your suggestion.

> especially item 4!
> And more ramblings of a nobody?

Good for you. well I don't have boast about what I did or how much I help
on this board and other helpboards.

Either way this will be my last and final reply to you and your posts.

Thanks,
Kolusu

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

Re: Bug in DFSORT? [WAS: Merging multiple records using DFSORT]

2021-01-15 Thread Seymour J Metz

> I'm sure others here have looked and looked and looked at code they wrote,
> absolutely sure that it was OK, only to be informed by a colleague, after 
> he/she
> looked at it for about 42 milliseconds, that they missed out on another
> "Purloined Letter"...

Sometimes, 42 ms after I explain what the code is supposed to do I get a "duh" 
moment before he has time to spot it.

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Robert Prins [rob...@prino.org]
Sent: Friday, January 15, 2021 2:57 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Bug in DFSORT? [WAS: Merging multiple records using DFSORT]

On 2021-01-15 16:22, Sri h Kolusu wrote:
>>
>> Please don't patronise me with high "coding standards", you banned
>> me from your
>> forum when I commented on the fact that you suggested using UNSPEC()
>> to look at
>> the internal representation of z/OS HEX FLOAT values in order top
>> print them in
>> a PL/I program, and then deleted the postings to hide your own
> incompetence!
>
>
> Robert,
>
> Ya right ! And you had the audacity to call it a bug in the product even
> though you are data owner and mere checking of the data would have answered
> your own question.  I should have gone with my first instinct of just
> ignoring your rambling. That is the only thing you do.

And that's the way IBM nowadays treats it's customers? Too bad I don't have the
email address of Arvind Krishna, I would have loved to CC: this reply to him!

Then again, maybe the "Heart to Heart" program still exists, it used to
guarantee that a letter to the CEO was only read by the CEO.

And it actually worked in a grey past: after having been shoved around for
months not receiving the updates for OS/2 I was entitled to, a "Heart to Heart"
letter to Mr Palmisano did the trick,  I was contacted by a personal assistant
of the managing director of IBM UK, and two weeks later a big box with all OS/2
updates arrived!

Maybe you should have a look at
<https://secure-web.cisco.com/1iKkzjhX3DhkxVKtwzuOOXESTUuOsbSgksr38EUwRZ82okrw_MiTlqzdtaw043sUF_VpfwDaoy8en7XEdn8WrAvKFZHqz76yqtobf1OAq3970vrWonUVVY3MkBk7EzbQNHgvfuZCoN1c4HiYR8Y-zVZT_j_DBS_BPnu3MR2CfzPzFcf9dKXKl1Ed48YST5XuJkGTuU-VQNZj3iUknjxd_ikvL5RCdZXeSaXL6_cZn9qFXcOsYVihSqmlBdtknZBfupvNxfqa6GiEHmxWkLtNaQFBBlB30O2RSszd-51M0x8FqH47TUNEsU0A4ImBp7P8M__80P44NkjjtBsi86dA9OmTogzZgYILM-oGJ9_5oLWu5So1WzO388I2ew_Rpz1as4imLi-OR1BHgL4pjEBdefb-ZizPdNb8ZoSXUi0yMkW8yGOhdQFTzhxKMHCuCthOBNUcYIdOAjXDHLa-PSHE-RA/https%3A%2F%2Fwww.joelonsoftware.com%2F2007%2F02%2F19%2Fseven-steps-to-remarkable-customer-service%2F>,
especially item 4!

I'm sure others here have looked and looked and looked at code they wrote,
absolutely sure that it was OK, only to be informed by a colleague, after he/she
looked at it for about 42 milliseconds, that they missed out on another
"Purloined Letter"...

And more ramblings of a nobody?

https://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe_ID=147579
(Given the last IBM comment, not unlikely that it will be delivered)

https://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe_ID=100073
(Delivered)

https://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe_ID=31632
(Delivered)

https://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe_ID=84512
(Delivered)

https://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe_ID=145001
(Planned for future release)

https://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe_ID=147550
(Under consideration)

As for the product you're responsible for? In 1964 IBM developed a programming
language, PL/I, without keywords also being reserved words, alleviating the need
to ever having to change programs when new keywords were introduced. Why can't
you do that for SORT?

>> And did you actually read the "...and ***someone*** came up with a
>> really very
>> elegant way of performing this task, ..." (Emphasis added...) You should
> have
>> seen, as you're also on that forum, that the solution was provided by
> Jörg
>> Findeisen!
>
> I stopped browsing that forum ever since they forced ads.

Using an adblocker is too hard? Ask yourself, would Frank Yaeger have been
deterred by ads when supporting an IBM product?

> Kudos to Jorg > findeisen for coding a solution. And the degree of elegance 
> depends. So if
> you are happy with the solution stick with it
>
>>>> And that saves? 1 nanosecond?
>
> The question is NOT only about saving CPU cycles. The elegance you boast
> isn't seen when you code such statements.
>
>> Which is really important for something that processes 209 lines of
>> input, and
>> might at some stage process as many as

Re: Bug in DFSORT? [WAS: Merging multiple records using DFSORT]

2021-01-15 Thread Robert Prins


On 2021-01-15 16:22, Sri h Kolusu wrote:


Please don't patronise me with high "coding standards", you banned
me from your
forum when I commented on the fact that you suggested using UNSPEC()
to look at
the internal representation of z/OS HEX FLOAT values in order top
print them in
a PL/I program, and then deleted the postings to hide your own

incompetence!


Robert,

Ya right ! And you had the audacity to call it a bug in the product even
though you are data owner and mere checking of the data would have answered
your own question.  I should have gone with my first instinct of just
ignoring your rambling. That is the only thing you do.


And that's the way IBM nowadays treats it's customers? Too bad I don't have the 
email address of Arvind Krishna, I would have loved to CC: this reply to him!


Then again, maybe the "Heart to Heart" program still exists, it used to 
guarantee that a letter to the CEO was only read by the CEO.


And it actually worked in a grey past: after having been shoved around for 
months not receiving the updates for OS/2 I was entitled to, a "Heart to Heart" 
letter to Mr Palmisano did the trick,  I was contacted by a personal assistant 
of the managing director of IBM UK, and two weeks later a big box with all OS/2 
updates arrived!


Maybe you should have a look at 
, 
especially item 4!


I'm sure others here have looked and looked and looked at code they wrote, 
absolutely sure that it was OK, only to be informed by a colleague, after he/she 
looked at it for about 42 milliseconds, that they missed out on another 
"Purloined Letter"...


And more ramblings of a nobody?

https://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe_ID=147579
(Given the last IBM comment, not unlikely that it will be delivered)

https://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe_ID=100073 
(Delivered)


https://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe_ID=31632
(Delivered)

https://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe_ID=84512
(Delivered)

https://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe_ID=145001
(Planned for future release)

https://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe_ID=147550
(Under consideration)

As for the product you're responsible for? In 1964 IBM developed a programming 
language, PL/I, without keywords also being reserved words, alleviating the need 
to ever having to change programs when new keywords were introduced. Why can't 
you do that for SORT?



And did you actually read the "...and ***someone*** came up with a
really very
elegant way of performing this task, ..." (Emphasis added...) You should

have

seen, as you're also on that forum, that the solution was provided by

Jörg

Findeisen!


I stopped browsing that forum ever since they forced ads.  


Using an adblocker is too hard? Ask yourself, would Frank Yaeger have been 
deterred by ads when supporting an IBM product?



Kudos to Jorg > findeisen for coding a solution. And the degree of elegance 
depends. So if
you are happy with the solution stick with it


And that saves? 1 nanosecond?


The question is NOT only about saving CPU cycles. The elegance you boast
isn't seen when you code such statements.


Which is really important for something that processes 209 lines of
input, and
might at some stage process as many as 300 lines on input, and it's part

of a

job that runs for about a minute, so saving a fraction of a second? And

when

SORT is invoked by the viewer, the result is usually displayed when
my finger is
still next to the Enter key.


As I said earlier I wouldn't have bothered to answer the questions from YOU
if you hadn't called an user error a bug in the product.


I guess the question marks didn't make it to your side...

Robert
--
Robert AH Prins
robert(a)prino(d)org
The hitchhiking grandfather - https://prino.neocities.org/indez.html
Some REXX code for use on z/OS - https://prino.neocities.org/zOS/zOS-Tools.html

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

Re: Bug in DFSORT? [WAS: Merging multiple records using DFSORT]

2021-01-15 Thread Sri h Kolusu

>
> Please don't patronise me with high "coding standards", you banned
> me from your
> forum when I commented on the fact that you suggested using UNSPEC()
> to look at
> the internal representation of z/OS HEX FLOAT values in order top
> print them in
> a PL/I program, and then deleted the postings to hide your own
incompetence!


Robert,

Ya right ! And you had the audacity to call it a bug in the product even
though you are data owner and mere checking of the data would have answered
your own question.  I should have gone with my first instinct of just
ignoring your rambling. That is the only thing you do.

> And did you actually read the "...and ***someone*** came up with a
> really very
> elegant way of performing this task, ..." (Emphasis added...) You should
have
> seen, as you're also on that forum, that the solution was provided by
Jörg
> Findeisen!

I stopped browsing that forum ever since they forced ads.  Kudos to Jorg
findeisen for coding a solution. And the degree of elegance depends. So if
you are happy with the solution stick with it

>>> And that saves? 1 nanosecond?

The question is NOT only about saving CPU cycles. The elegance you boast
isn't seen when you code such statements.

> Which is really important for something that processes 209 lines of
> input, and
> might at some stage process as many as 300 lines on input, and it's part
of a
> job that runs for about a minute, so saving a fraction of a second? And
when
> SORT is invoked by the viewer, the result is usually displayed when
> my finger is
> still next to the Enter key.

As I said earlier I wouldn't have bothered to answer the questions from YOU
if you hadn't called an user error a bug in the product.

Thanks,
Kolusu


IBM Mainframe Discussion List  wrote on
01/15/2021 10:53:50 AM:

> From: Robert Prins 
> To: IBM-MAIN@LISTSERV.UA.EDU
> Date: 01/15/2021 08:54 AM
> Subject: [EXTERNAL] Re: Bug in DFSORT? [WAS: Merging multiple
> records using DFSORT]
> Sent by: IBM Mainframe Discussion List 
>
> On 2021-01-15 11:50, Sri h Kolusu wrote:
> >> So what's so special about 80? 9, 41 and 44 are unique in the entire
set
> > of >sort control statements, and 80 also doesn't appear, yet replacing
44
> > by 80 >results in incorrect output.
> >
> >> I've gone over it again and again, but I'm totally clueless, unless
this
> > is >one of those bugs that nobody's encountered before(*).
> >> So, if someone can confirm the problem, or that this is a case of
Edgar
> >> Allan Poe's "The Purloined Letter", i.e. so obvious that it hides in
plain
> >> sight, please reply to this post!
> >
> > Robert,
> >
> > Let me start off with "It is NOT a BUG" and the obvious is right in
front
> > of you. As a data owner you SHOULD be in a better position to tell as
to
> > what is so special about the data at position 80.
>
> Yes, as I already wrote, it's probably a case of "The Purloined
Letter"...
>
> > To explain what is so special about 80. Open the input dataset in
> > browse/edit mode
> >
> > Issue the command F '+' 44 ALL then make a note of where exactly you
are
> > finding the specified character. Also Make a note of the number of
times
> > the character is found. (5 times)
> >
> > Hint : It is found on the FIRST line of the boxed data skipping the
first
> > set of data
> >
> > Now issue the same command but changing the position to 80
> >
> > F '+' 80 ALL
> >
> > Also make a note of how many number of times the character is found (9
> > times)
> >
> > Hint : It is found on the FIRST/SECOND/THIRD line of the boxed data
> > starting with the first set of data.
> >
> > DFSORT is merely doing what you wanted it to do. So I am not sure
comparing
> > a 5 time found data with 9 times found data is correct.
> >
> > Btw the control cards can be optimized and I am not even sure as to why
you
> > need a numeric conversion for simply sticking a constant value of
0120 ?
> > Not sure how it passed your high "coding standards"
>
> Please don't patronise me with high "coding standards", you banned
> me from your
> forum when I commented on the fact that you suggested using UNSPEC()
> to look at
> the internal representation of z/OS HEX FLOAT values in order top
> print them in
> a PL/I program, and then deleted the postings to hide your own
incompetence!
>
> And did you actually read the "...and ***someone*** came up with a
> really very
> elegant way of performing this task, ..." (Emphasis added...) You should
have
> seen, as you're also on that forum, that the solution was provide

Re: Bug in DFSORT? [WAS: Merging multiple records using DFSORT]

2021-01-15 Thread Robert Prins

On 2021-01-15 11:50, Sri h Kolusu wrote:

So what's so special about 80? 9, 41 and 44 are unique in the entire set

of >sort control statements, and 80 also doesn't appear, yet replacing 44
by 80 >results in incorrect output.

I've gone over it again and again, but I'm totally clueless, unless this

is >one of those bugs that nobody's encountered before(*).

So, if someone can confirm the problem, or that this is a case of Edgar
Allan Poe's "The Purloined Letter", i.e. so obvious that it hides in plain
sight, please reply to this post!

Robert,

Let me start off with "It is NOT a BUG" and the obvious is right in front
of you. As a data owner you SHOULD be in a better position to tell as to
what is so special about the data at position 80.

Yes, as I already wrote, it's probably a case of "The Purloined Letter"...

To explain what is so special about 80. Open the input dataset in
browse/edit mode

Issue the command F '+' 44 ALL then make a note of where exactly you are
finding the specified character. Also Make a note of the number of times
the character is found. (5 times)

Hint : It is found on the FIRST line of the boxed data skipping the first
set of data

Now issue the same command but changing the position to 80

F '+' 80 ALL

Also make a note of how many number of times the character is found (9
times)

Hint : It is found on the FIRST/SECOND/THIRD line of the boxed data
starting with the first set of data.

DFSORT is merely doing what you wanted it to do. So I am not sure comparing
a 5 time found data with 9 times found data is correct.

Btw the control cards can be optimized and I am not even sure as to why you
need a numeric conversion for simply sticking a constant value of 0120 ?
Not sure how it passed your high "coding standards"

Please don't patronise me with high "coding standards", you banned me from your
forum when I commented on the fact that you suggested using UNSPEC() to look at
the internal representation of z/OS HEX FLOAT values in order top print them in
a PL/I program, and then deleted the postings to hide your own incompetence!

And did you actually read the "...and ***someone*** came up with a really very
elegant way of performing this task, ..." (Emphasis added...) You should have
seen, as you're also on that forum, that the solution was provided by Jörg
Findeisen!

INREC IFTHEN=(WHEN=INIT,OVERLAY=(364:+120,ZD,LENGTH=4)),

should be as simple as

INREC IFTHEN=(WHEN=INIT,OVERLAY=(364:C'0120')),

And that saves? 1 nanosecond?

Similarly when using the substring format and searching for multiple
characters, it is advisable to have a comma so that it is easy to
understand and maintain.

(44,1,SS,EQ,C'+|') should be (44,1,SS,EQ,C'+,|')

And how much extra time does this add to parsing the string? Sheesh...

This is explained in the 2nd bullet here

https://www.ibm.com/support/knowledgecenter/SSLTBW_2.4.0/com.ibm.zos.v2r4.icea100/substr.htm

And just for the record, the job can be optimized and can be done easily.

Which is really important for something that processes 209 lines of input, and
might at some stage process as many as 300 lines on input, and it's part of a
job that runs for about a minute, so saving a fraction of a second? And when
SORT is invoked by the viewer, the result is usually displayed when my finger is
still next to the Enter key.

Robert
--
Robert AH Prins
robert(a)prino(d)org
The hitchhiking grandfather - https://prino.neocities.org/indez.html
Some REXX code for use on z/OS - https://prino.neocities.org/zOS/zOS-Tools.html

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

Re: Bug in DFSORT? [WAS: Merging multiple records using DFSORT]

2021-01-15 Thread Sri h Kolusu

>So what's so special about 80? 9, 41 and 44 are unique in the entire set
of >sort control statements, and 80 also doesn't appear, yet replacing 44
by 80 >results in incorrect output.

>I've gone over it again and again, but I'm totally clueless, unless this
is >one of those bugs that nobody's encountered before(*).
>So, if someone can confirm the problem, or that this is a case of Edgar
>Allan Poe's "The Purloined Letter", i.e. so obvious that it hides in plain
>sight, please reply to this post!

Robert,

Let me start off with "It is NOT a BUG" and the obvious is right in front
of you. As a data owner you SHOULD be in a better position to tell as to
what is so special about the data at position 80.

To explain what is so special about 80. Open the input dataset in
browse/edit mode

Issue the command F '+' 44 ALL then make a note of where exactly you are
finding the specified character. Also Make a note of the number of times
the character is found. (5 times)

Hint : It is found on the FIRST line of the boxed data skipping the first
set of data

Now issue the same command but changing the position to 80

F '+' 80 ALL

Also make a note of how many number of times the character is found (9
times)

Hint : It is found on the FIRST/SECOND/THIRD line of the boxed data
starting with the first set of data.

DFSORT is merely doing what you wanted it to do. So I am not sure comparing
a 5 time found data with 9 times found data is correct.

INREC IFTHEN=(WHEN=INIT,OVERLAY=(364:+120,ZD,LENGTH=4)),

should be as simple as

INREC IFTHEN=(WHEN=INIT,OVERLAY=(364:C'0120')),

Similarly when using the substring format and searching for multiple
characters, it is advisable to have a comma so that it is easy to
understand and maintain.

(44,1,SS,EQ,C'+|') should be (44,1,SS,EQ,C'+,|')

This is explained in the 2nd bullet here

https://www.ibm.com/support/knowledgecenter/SSLTBW_2.4.0/com.ibm.zos.v2r4.icea100/substr.htm

And just for the record, the job can be optimized and can be done easily.

Thanks,
Kolusu

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

Bug in DFSORT? [WAS: Merging multiple records using DFSORT]

2021-01-14 Thread Robert Prins


On 2021-01-12 16:12, Robert Prins wrote:

I'm currently using this...


I've posted the question to , 
and someone came up with a really very elegant way of performing this task, but 
his solution, unlike the one I posted in the start of this thread, cannot handle 
data in a legacy format, which is a must, as the code to look at older results 
automagically invokes sort to convert members that contain split (into chunks of 
121 bytes) members into merged ones.


So I added some additional code that correctly processes the old data, but then 
I realised that instead of using my hack, it would be more useful to select a 
unique column in the second table that does not appear in the same format in the 
same place in the legacy data.


Fow what it's worth, and for those not willing to access the above post, the JCL 
I use is below:


//PRINOSOR JOB (PRINO),
// 'Test LW merge',
// CLASS=A,
// MSGCLASS=H,
// MSGLEVEL=(2,0),
// NOTIFY=
//*
//MERGELW EXEC PGM=SORT
//*
//SYSOUTDD SYSOUT=*
//*
//SORTINDD DSN=@@121.TEXT,  /* FB(121)
// DISP=SHR
//*
//SORTOUT   DD SYSOUT=*
//*
//SYSIN DD *
* Merge the LW file
*
* See: https://ibmmainframes.com/viewtopic.php?t=68044

  OPTION COPY
* 
* Put '0120' in columns 364-367

  INREC IFTHEN=(WHEN=INIT,OVERLAY=(364:+120,ZD,LENGTH=4)),

* Whatever   0120
* 
* Test column 9 for '+' or '|' OR column 41 for '+' or '|'
* - copy 365 ('1') to 364
* - add seqno to 367, for two records

IFTHEN=(WHEN=GROUP,BEGIN=(9,1,SS,EQ,C'+|',OR,41,1,SS,EQ,C'+|'),
  PUSH=(364:365,1,367:SEQ=1),RECORDS=2),

* T-1 / P-1  1121
* T-1 / P-2  1122
* 
* Test column 44 for '+' or '|'
* - copy 366 ('2') to 364
* - add seqno to 367, for three records

*!! CHANGE 44 below to 80 and things go wrong!!

IFTHEN=(WHEN=GROUP,BEGIN=(44,1,SS,EQ,C'+|'),
  PUSH=(364:366,1,367:SEQ=1),RECORDS=3),

* T-2 / P-1  2121
* T-2 / P-2  2122
* T-2 / P-3  2123
* 
* Test column column 367 for '1'
* - add columns 1-121 at column 122

IFTHEN=(WHEN=GROUP,BEGIN=(367,1,ZD,EQ,+1),
  PUSH=(122:1,121)),

* Whatever   0120
* T-1 / P-1 T-1 / P-11121
* T-1 / P-2 T-1 / P-11122
* Whatever  T-1 / P-10120
* T-2 / P-1 T-2 / P-12121
* T-2 / P-2 T-2 / P-12122
* T-2 / P-3 T-2 / P-12123
* Whatever  T-2 / P-10120
* 
* Test column column 367 for '2'
* - add columns 1-121 at column 243

IFTHEN=(WHEN=GROUP,BEGIN=(367,1,ZD,EQ,+2),
  PUSH=(243:1,121))

* Whatever   0120  x 0...: 1,121
* T-1 / P-1 T-1 / P-11121
* T-1 / P-2 T-1 / P-1 T-1 / P-2  1122
* t-1 / P-1 t-1 / P-1 T-1 / P-2  1121  x 1..1: 122,1+1,121
* t-1 / P-2 t-1 / P-1 t-1 / P-1  1122
* Whatever  t-1 / P-1 t-1 / P-1  0120  x 0...: 1,121
* T-2 / P-1 T-2 / P-1 t-1 / P-1  2121
* T-2 / P-2 T-2 / P-1 T-2 / P-2  2122
* T-2 / P-3 T-2 / P-1 T-2 / P-2  2123  x 2..3: 122,121+243,121+1,121
* 

  OUTFIL FNAMES=(SORTOUT),
INCLUDE=((364,1,ZD,EQ,+0),OR,
 (364,1,ZD,EQ,+1,AND,367,1,ZD,EQ,+2),OR,
 (364,1,ZD,EQ,+2,AND,367,1,ZD,EQ,+3)),

FTOV,VLTRIM=C' ',

IFTHEN=(WHEN=(364,1,ZD,EQ,+0),BUILD=(1,121)),

IFTHEN=(WHEN=(364,1,ZD,EQ,+1,AND,367,1,ZD,EQ,+2),
  BUILD=(122,121,1,121)),

IFTHEN=(WHEN=(364,1,ZD,EQ,+2,AND,367,1,ZD,EQ,+3),
  BUILD=(122,121,243,121,1,121))

The input file (@@121.text) is included (I hope) as a plain-text (58 lines, no 
trailing spaces) attachment, or can be scraped from 
 (with the JCL and 
expected output)


Paste it into an FB(121) dataset, paste the JCL, and submit it, and SYSOUT from 
SORT will show two merged tables, so far so good.


If you look at the input or, to make things a bit easier, the output, and then 
look at the second and third IFTHEN statements, the second tests for a '+'or '|' 
in columns 9 & 41, the third just checks for the same two characters in column 44.


I've not (yet) checked why the second IFTHEN uses two columns and the third 
IFTHEN only one column as the three columns checked are mutually exclusive, but...


column 44 is also present in the legacy data, so I thought, "Why not change that 
one into 80?" which is the next column in the second table that only contains 
'+' and '|', or even

Merging multiple records using DFSORT

2021-01-12 Thread Robert Prins


I'm currently using this

* Merge the LW file
*
* These sort commands can handle both the old, it's left unchanged, as
* well as the new, records are merged, LW output file.
***
 OPTION COPY
 INREC  IFTHEN=(WHEN=(1,1,CH,EQ,C'1',OR, ASA
114,1,CH,EQ,C'+',OR, Old eol
114,1,CH,EQ,C'|'),   Old eol
   OVERLAY=(122:C' ')),
IFTHEN=(WHEN=NONE,
   OVERLAY=(122:SEQNUM,8,ZD,122:122,8,ZD,MOD,+2,M11,LENGTH=1))
*
 OUTREC IFTHEN=(WHEN=GROUP,BEGIN=(122,1,CH,EQ,C'1'),
  PUSH=(123:1,121))
*
 OUTFIL FTOV,VLTRIM=C' ',
  OMIT=(122,1,CH,EQ,C'1'),
IFTHEN=(WHEN=(122,1,CH,EQ,C'0'),BUILD=(123,121,1,121)),
IFTHEN=(WHEN=(122,1,CH,EQ,C' '),BUILD=(1,121))

which works like a charm.

However, the input file is about to change, and as we're still not willing to 
update the regression testing framework to cater for files other than FB(121), 
the above has to change for additional input records, which means another 
ifthen-when group. I guess it's not a problem to change the current overlay to a 
fixed '1' followed by the current seqnum logic (Correct me if I'm wrong!) and 
add another with a fixed '2' plus a mod +3 sequence number, the new records need 
to be assembled from three records. (Yes, sigh...)


However, can I use multiple "PUSH"es? The manual tells me

You can use the following in PUSH:
c: Specifies the output position (column) to be overlaid. If you do not
specify c: for the first item, it defaults to 1:. If you do not specify c:
for any other item, it starts after the previous item. You can specify
items in any order and overlap output columns. c can be 1 to
32752.
If you specify an item that extends the output record beyond the
end of the input record, the record length is automatically
increased to that length, and blanks are filled in on the left as
needed. For variable-length records, the RDW length is increased
to correspond to the larger record length after all of the items are
processed. Missing bytes in specified input fields are replaced with
blanks so the padded fields can be processed.
p,m
***Specifies a field in the ***first input record*** of each group to be
propagated to every record of the group.*** p specifies the starting
position of the field in the input record and m specifies its length.
A field must not extend beyond position 32752.
ID=n
Specifies a ZD identifier of length n is to be added to every record
of each group. The identifier starts at 1 for the first group and is
incremented by 1 for each subsequent group. n can be 1 to 15.
SEQ=n
Specifies a ZD sequence number of length n is to be added to
every record of each group. The sequence number starts at 1 for
the first record of each group and is incremented by 1 for each
subsequent record of the group. n can be 1 to 15.[/quote]

Emphasis (***) added, which seems that I can only merge data from the first 
record?

Or do I have to resort to something more exotic, like 
?


Robert
--
Robert AH Prins
robert.ah.prins(a)gmail.com
The hitchhiking grandfather - https://prino.neocities.org/
Some REXX code for use on z/OS - https://prino.neocities.org/zOS/zOS-Tools.html

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

Re: DFSORT Header + Detail count match

2020-12-14 Thread Ron Thomas

Thanks a lot Kolusu. It worked great .

Regards
Ron T

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

Re: DFSORT Header + Detail count match

2020-12-11 Thread Sri h Kolusu

> I coded the below DFSORT job , but it is not working . Could some
> one please let me know where the issue is ?

There are couple of issues with your job.

1.  COUNT-n field is limited to 15 digits and you are creating a 17 byte
field which would have 2 spaces to the left of the count making the symbol
definition invalid
2.  You created a display-able 17 byte count which is Zoned Decimal count
field  , but you comparing that symbol using BINARY . The comparison will
be false
3.  You do realize that coding RC16=ABE will make the job abend with U0206
abend if the counts do not match?

So change  STEP01  SYSIN  to use an EDIT mask insted of M11 mask.  See
below

  TRAILER1=('DATA_COUNT,+',COUNT-1=(EDIT=(T)))

Change STEP02 sysin to have ZD instead of BI

 INCLUDE COND=(01,17,ZD,EQ,DATA_COUNT)


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

DFSORT Header + Detail count match

2020-12-11 Thread Ron Thomas

Hi,

We are getting 1 3rd part file with the layout as follows. Here in header 1-17 
bytes is the count followed by Pipe & Date. The Rest of the lines is the detail 
lines .

The process should not proceed if the count in header is not matching with  the 
detail line count.

7|2020-12-09
980012589|04937|03448
980010506|04937|02698
980001772|04937|03288
000276258|04937|03788
980012589|04936|03448
980010506|04936|02698
980001772|04936|03288

I coded the below DFSORT job , but it is not working . Could some one please 
let me know where the issue is ?

//SYSOUT DD SYSOUT=*
//SORTIN DD DSN=PNS2S3.T1.F1.F1,DISP=SHR
//SORTOUT  DD DSN=&K,DISP=(,PASS),SPACE=(TRK,(1,1),RLSE)
//SYSIN DD *
  SORT FIELDS=COPY
  OUTFIL REMOVECC,NODETAIL,BUILD=(80X),
  TRAILER1=('DATA_COUNT,+',COUNT-1=(M11,LENGTH=17))
/*
//STEP02   EXEC PGM=SORT,PARM='RC16=ABE'
//SYSOUT   DD SYSOUT=*
//SYMNAMES DD DSN=&K,DISP=SHR
//SORTIN   DD DSN=PNS2S3.T1.F1.F1,DISP=SHR
//SORTOUT  DD SYSOUT=*
//SYSINDD *
  OPTION COPY,NULLOUT=RC16,STOPAFT=1
  INCLUDE COND=(01,17,BI,EQ,DATA_COUNT)
//*

Regards
Ron T

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

Re: SFTP Sortcard creating using DFSORT

2020-12-09 Thread Ron Thomas

Thanks a lot Kolusu ..

Regards
Ron

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

Re: SFTP Sortcard creating using DFSORT

2020-12-09 Thread Sri h Kolusu

> Could you please help me to understand the below card as to how it
> is picking the store_nbr and create

Ron,

The job is parsing the input for the delimiter "}". Since we don't care
about the first 2 fields, they can be ignored.  REPEAT=v can be used with %
to specify v identically defined consecutive parsed fields to be ignored. v
can be 2 to 1000. For example, to ignore five consecutive comma delimited
fields, you
can use:

%=(ENDBEFR=C',',REPEAT=5),

which is equivalent to using:

%=(ENDBEFR=C','),
%=(ENDBEFR=C','),
%=(ENDBEFR=C','),
%=(ENDBEFR=C','),
%=(ENDBEFR=C','),

and then we parsed the store number with %01 and then used Justify (JFY) to
the parsed store number to add _ at the beginning using LEAD and the .CSV
at the end using TRAIL keywords.


If you're not familiar with DFSORT and DFSORT's ICETOOL, I'd suggest
reading through "z/OS DFSORT: Getting Started". It's an excellent tutorial,
with lots of examples, that will show you how to use DFSORT, DFSORT's
ICETOOL and DFSORT Symbols. You can access it online, along with all of the
other DFSORT books, from:

http://www.ibm.com/support/docview.wss?rs=114=isg3T780

In your case look up for PARSE= and JFY=


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: SFTP Sortcard creating using DFSORT

2020-12-09 Thread Ron Thomas

Thanks a lot Kolusu.. it worked like a charm !

Could you please help me to understand the below card as to how it is picking 
the store_nbr and create 


NREC PARSE=(%=(REPEAT=2,ENDAT=C'}'),
   %01=(ENDBEFR=C'{',
ENDBEFR=C' ',
FIXLEN=8)),
BUILD=(C' SPUT  ''',
   C'K01.BB.RST.PTEM.FUTR.RTLDTA.REPT01''',
   C' FUTRETAIL_',
   DATE1(-)-1,
   %01,JFY=(SHIFT=LEFT,
 LEAD=C'_',
TRAIL=C'.CSV',
LENGTH=16))


Regards
Ron T

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

Re: SFTP Sortcard creating using DFSORT

2020-12-08 Thread Sri h Kolusu

> but the issue is the store_nbrs are of different length, the .csv is
> not getting created correctly . Could some one let me know how we
> can append the .csv also when the store is of variable length
>

Ron,

Try this DFSORT JCL

//STEP0100 EXEC PGM=SORT
//SYSOUT   DD SYSOUT=*
//SORTIN   DD *
 ITEM_NBR   }  ITEM_DESC1  }  STORE_NBR   }
+1+2+3+4+5+-
 500849599 }ENT MASSA TORTA 2 KG }33
 500878286 }CAST DE CAJU TS 120G }331
 500862526 }MTR MASS LASANH SECA }3
 500877131 }PERU INTEIR C MIUDOS }3323
 500034169 }ACUC FIT UNIAO   }3311
 500832360 }AMPOLA PANTENE UNIDA }33
//SORTOUT  DD SYSOUT=*
//SYSINDD *
  OPTION COPY,SKIPREC=1
  INREC PARSE=(%=(REPEAT=2,ENDAT=C'}'),
   %01=(ENDBEFR=C'{',
ENDBEFR=C' ',
FIXLEN=8)),
BUILD=(C' SPUT  ''',
   C'K01.BB.RST.PTEM.FUTR.RTLDTA.REPT01''',
   C' FUTRETAIL_',
   DATE1(-)-1,
   %01,JFY=(SHIFT=LEFT,
 LEAD=C'_',
TRAIL=C'.CSV',
LENGTH=16))

/*


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

SFTP Sortcard creating using DFSORT

2020-12-08 Thread Ron Thomas

Hello-

I am creating a dynamic SFTP sortcard using DFSORT, here in the Input file the 
Store_nbr is at position 40. I need the file to created as 

SPUT 'K01.BB.RST.PTEM.FUTR.RTLDTA.REPT01' FUTRETAIL_2020-12-07_33.csv


but the issue is the store_nbrs are of different length, the .csv is not 
getting created correctly . Could some one let me know how we can append the 
.csv also when the store is of variable length


Input File 

---+1+2+3+4+
 Top of Data
 ITEM_NBR   }  ITEM_DESC1  }  STORE_NBR   }
 500849599 }ENT MASSA TORTA 2 KG }33
 500878286 }CAST DE CAJU TS 120G }331
 500862526 }MTR MASS LASANH SECA }3
 500877131 }PERU INTEIR C MIUDOS }3323
 500034169 }ACUC FIT UNIAO   }3311
 500832360 }AMPOLA PANTENE UNIDA }33


output card generated 

SPUT 'K01.BB.RST.PTEM.FUTR.RTLDTA.REPT01' FUTRETAIL_2020-12-07_33
SPUT 'K01.BB.RST.PTEM.FUTR.RTLDTA.REPT01' FUTRETAIL_2020-12-07_331
SPUT 'K01.BB.RST.PTEM.FUTR.RTLDTA.REPT01' FUTRETAIL_2020-12-07_3
SPUT 'K01.BB.RST.PTEM.FUTR.RTLDTA.REPT01' FUTRETAIL_2020-12-07_3323
SPUT 'K01.BB.RST.PTEM.FUTR.RTLDTA.REPT01' FUTRETAIL_2020-12-07_3311
SPUT 'K01.BB.RST.PTEM.FUTR.RTLDTA.REPT01' FUTRETAIL_2020-12-07_33


Control Card used 

SORT FIELDS=COPY
OUTREC BUILD=(1:C'SPUT ',
6:C,7:C'K01.BB.RST.PTEM.FUTR.RTLDTA.REPT01',
41:C,
43:C'FUTRETAIL_',
53:DATE1(-)-1,63:C'_',64:40,4,21X)


Regards
Ron T

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

Re: How to get CEEDUMP with DFSORT?

I have hat set per the instructions. I really am now leaning towards my 
programmers wouldn't have got the CEEDUMP in this case, has they still been 
using the other sort product.
But, since DFSORT is new, it is a viable culprit. And, really, the program's 
diagnostic messages should have been sufficient for them to solve their issue 
without the CEEDUMP anyway.

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Sri h Kolusu
> Sent: Wednesday, November 18, 2020 5:15 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: How to get CEEDUMP with DFSORT?
> 
> > In the case my programmers found, there was a call for a user abend
> > with value of 36.  As I think on this, I have no idea for sure that
> > behavior from Syncsort would have been different.
> 
> Dave,
> 
> I believe I sent out the migration documents which lists the equivalent
> parms for DFSORT. In this particular case if you want DFSORT to behave like
> the other product , then please refer to sdniopt.txt file and the parm you
> are looking for is ERET parm. It is equivalent for PGMRC16/NORC16/RC16
> 
> 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: How to get CEEDUMP with DFSORT?

2020-11-18 Thread Sri h Kolusu

> In the case my programmers found, there was a call for a user abend
> with value of 36.  As I think on this, I have no idea for sure that
> behavior from Syncsort would have been different.

Dave,

I believe I sent out the migration documents which lists the equivalent
parms for DFSORT. In this particular case if you want DFSORT to behave like
the other product , then please refer to sdniopt.txt file and the parm you
are looking for is ERET parm. It is equivalent for PGMRC16/NORC16/RC16

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: How to get CEEDUMP with DFSORT?

Thank you and understood about the different environments.

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Sri h Kolusu
> Sent: Wednesday, November 18, 2020 3:56 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: How to get CEEDUMP with DFSORT?
> 
> > Thank you, I had read this. I expect that doing this will return me
> > to the CEEDUMP behavior I had the other sort product. I was hoping
> > for an option where the DFSORT termination would continue on to the
> > LE termination. That was my specific question. Will, or can I get the
> CEEDUMP?
> 
> Dave,
> 
> Generally if you have an error in COBOL , then Language environment  SPIE
> takes over and generates the CEEDUMP.  So if your shop has IBM-supplied
> default  TRAP(ON,SPIE) , you would get CEEDUMP.
> 
> > I still think I am better off setting ESTAE=NO as a default. I would
> > rather my programmers can fix the error from the first run, rather
> > than needing another failing run with debug options.
> 
> If you intend to go with turning of ESTAE , then make sure that you only do
> it for ICEAM2 environment so that only program invoked sorts have their
> ESTAE disabled. Please do not turn it off for ICEAM1 environment.
> 
> 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: How to get CEEDUMP with DFSORT?

In the case my programmers found, there was a call for a user abend with value 
of 36.  As I think on this, I have no idea for sure that behavior from Syncsort 
would have been different.  I have no idea when the last time this condition 
occurred such that the program on question issued the error.
As Seymour points out, this wasn't a program check.

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Seymour J Metz
> Sent: Wednesday, November 18, 2020 4:34 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: How to get CEEDUMP with DFSORT?
> 
> ESPIE only catches program checks, it doesn't catch ABENDs. A COBOL
> program can get an ABEND not related to a program check.
> 
> 
> --
> Shmuel (Seymour J.) Metz
> https://urldefense.com/v3/__http://mason.gmu.edu/*smetz3__;fg!!JmPEg
> BY0HMszNaDT!4a5aKwIYxypubpSNbCni7fJq78ixXIwCgmamg2e3Cm9TZN2OD
> Z0G--UwaQggKA$
> 
> 
> 
> From: IBM Mainframe Discussion List  on
> behalf of Sri h Kolusu 
> Sent: Wednesday, November 18, 2020 6:55 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: How to get CEEDUMP with DFSORT?
> 
> > Thank you, I had read this. I expect that doing this will return me
> > to the CEEDUMP behavior I had the other sort product. I was hoping
> > for an option where the DFSORT termination would continue on to the
> > LE termination. That was my specific question. Will, or can I get the
> CEEDUMP?
> 
> Dave,
> 
> Generally if you have an error in COBOL , then Language environment  SPIE
> takes over and generates the CEEDUMP.  So if your shop has IBM-supplied
> default  TRAP(ON,SPIE) , you would get CEEDUMP.
> 
> > I still think I am better off setting ESTAE=NO as a default. I would
> > rather my programmers can fix the error from the first run, rather
> > than needing another failing run with debug options.
> 
> If you intend to go with turning of ESTAE , then make sure that you only do
> it for ICEAM2 environment so that only program invoked sorts have their
> ESTAE disabled. Please do not turn it off for ICEAM1 environment.
> 
> 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: How to get CEEDUMP with DFSORT?

2020-11-18 Thread Clark Morris

[Default] On 18 Nov 2020 15:56:00 -0800, in bit.listserv.ibm-main
skol...@us.ibm.com (Sri h Kolusu) wrote:

>> Thank you, I had read this. I expect that doing this will return me
>> to the CEEDUMP behavior I had the other sort product. I was hoping
>> for an option where the DFSORT termination would continue on to the
>> LE termination. That was my specific question. Will, or can I get the
>CEEDUMP?

The normal setup for SYNCSORT used to the if invoked by JCL the SORT
would abend upon error while if invoked by a program it would quit
with a return code of 16 (in COBOL the code would be in SORT-RETURN. I
am fairly certain given the COBOL manual the same is true for DFSORT.
One simple way to see what would happen is to set up a simple COBOL
program to sort a file on a signed packed decimal field and have
invalid data in the test file.  The program should test SORT-RETURN
for 16 and abend if found.

Clark Morris
>
>Dave,
>
>Generally if you have an error in COBOL , then Language environment  SPIE
>takes over and generates the CEEDUMP.  So if your shop has IBM-supplied
>default  TRAP(ON,SPIE) , you would get CEEDUMP.
>
>> I still think I am better off setting ESTAE=NO as a default. I would
>> rather my programmers can fix the error from the first run, rather
>> than needing another failing run with debug options.
>
>If you intend to go with turning of ESTAE , then make sure that you only do
>it for ICEAM2 environment so that only program invoked sorts have their
>ESTAE disabled. Please do not turn it off for ICEAM1 environment.
>
>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: How to get CEEDUMP with DFSORT?

2020-11-18 Thread Seymour J Metz

ESPIE only catches program checks, it doesn't catch ABENDs. A COBOL program can 
get an ABEND not related to a program check.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3



From: IBM Mainframe Discussion List  on behalf of Sri 
h Kolusu 
Sent: Wednesday, November 18, 2020 6:55 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: How to get CEEDUMP with DFSORT?

> Thank you, I had read this. I expect that doing this will return me
> to the CEEDUMP behavior I had the other sort product. I was hoping
> for an option where the DFSORT termination would continue on to the
> LE termination. That was my specific question. Will, or can I get the
CEEDUMP?

Dave,

Generally if you have an error in COBOL , then Language environment  SPIE
takes over and generates the CEEDUMP.  So if your shop has IBM-supplied
default  TRAP(ON,SPIE) , you would get CEEDUMP.

> I still think I am better off setting ESTAE=NO as a default. I would
> rather my programmers can fix the error from the first run, rather
> than needing another failing run with debug options.

If you intend to go with turning of ESTAE , then make sure that you only do
it for ICEAM2 environment so that only program invoked sorts have their
ESTAE disabled. Please do not turn it off for ICEAM1 environment.

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: How to get CEEDUMP with DFSORT?

2020-11-18 Thread Sri h Kolusu

> Thank you, I had read this. I expect that doing this will return me
> to the CEEDUMP behavior I had the other sort product. I was hoping
> for an option where the DFSORT termination would continue on to the
> LE termination. That was my specific question. Will, or can I get the
CEEDUMP?

Dave,

Generally if you have an error in COBOL , then Language environment  SPIE
takes over and generates the CEEDUMP.  So if your shop has IBM-supplied
default  TRAP(ON,SPIE) , you would get CEEDUMP.

> I still think I am better off setting ESTAE=NO as a default. I would
> rather my programmers can fix the error from the first run, rather
> than needing another failing run with debug options.

If you intend to go with turning of ESTAE , then make sure that you only do
it for ICEAM2 environment so that only program invoked sorts have their
ESTAE disabled. Please do not turn it off for ICEAM1 environment.

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: How to get CEEDUMP with DFSORT?

Thank you, I had read this. I expect that doing this will return me to the 
CEEDUMP behavior I had the other sort product. I was hoping for an option where 
the DFSORT termination would continue on to the LE termination. That was my 
specific question. Will, or can I get the CEEDUMP?

I still think I am better off setting ESTAE=NO as a default. I would rather my 
programmers can fix the error from the first run, rather than needing another 
failing run with debug options.

In, what I think  far more unlikely event of an actual issue with DFSORT, I can 
use debug to turn it back on during a re-run.

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Sri h Kolusu
> Sent: Wednesday, November 18, 2020 12:55 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: How to get CEEDUMP with DFSORT?
> 
> >Would setting DFSORT ESTAE=NO let the CEEDUMP happen. I see the
> > odds of having an application data error to be much larger that an
> > actual problem with DFSORT
> 
> Dave,
> 
> You can use NOESTAE to turn off DFSORT ESTAE processing.
> 
> //DFSPARM DD *
>   DEBUG NOABEND,NOESTAE
> /*
> 
> Check this link which explains in detail about DEBUG statement
> 
> https://urldefense.com/v3/__https://www.ibm.com/support/knowledgece
> nter/SSLTBW_2.3.0/com.ibm.zos.v2r3.icea100/debcst.htm__;!!JmPEgBY0HM
> szNaDT!6VeI0seG5oOxO7NGRT0Ou_uqBdrfQoKGUqwV4hcW7D2_hMzPvok
> bAJx0zRG2tQ$
> 
> 
> 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: How to get CEEDUMP with DFSORT?

2020-11-18 Thread Sri h Kolusu

>Would setting DFSORT ESTAE=NO let the CEEDUMP happen. I see the
> odds of having an application data error to be much larger that an
> actual problem with DFSORT

Dave,

You can use NOESTAE to turn off DFSORT ESTAE processing.

//DFSPARM DD *
  DEBUG NOABEND,NOESTAE
/*

Check this link which explains in detail about DEBUG statement

https://www.ibm.com/support/knowledgecenter/SSLTBW_2.3.0/com.ibm.zos.v2r3.icea100/debcst.htm


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

How to get CEEDUMP with DFSORT?