Re: Trying to Parse a LISTCAT with SORT

[Sri h Kolusu]

>> But:  With  decimal point? without decimal point?

Gil,

DFSORT can process with or without the decimal point. Using the format UFF we 
strip off the decimal point.  UFF (unsigned free form numeric) format extracts 
decimal digits (0-9) from right to left anywhere in the field to form a 
positive number. Any
combination of characters is valid, but characters other than 0-9 are ignored.  
So, I first removed the decimal point using 58,08,UFF,M11,LENGTH=7,  and then 
converted the date to Gregorian format

>> 4-digit year? 2-digit year?

DFSORT can convert both 4 digit and 2 digit years. Here is the table which 
shows the TOJUL and TOGREG output date fields

https://www.ibm.com/docs/en/zos/2.5.0?topic=statements-outfil-control#oufcst__tatodf

>> Sliding window centered on current year?

DFSORT prints a message ICE168I about the sliding window when processing the 2 
digit years.

https://www.ibm.com/docs/en/zos/2.5.0?topic=messages-ice168i

We also provide a runtime option to override it called Y2PAST which can set the 
sliding year

https://www.ibm.com/docs/en/zos/2.5.0?topic=ssc-example-6


Thanks,
Kolusu

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

Re: Variable Sort Parsing

[Billy Ashton]

Kolusu, this worked great! I went with the Version 2 selection, and 
replaced the pipe delimiter with just a simple space.


Thanks again - one day, I hope to be able to do these simple things 
myself!


Thank you and best regards,
Billy Ashton


-- Original Message --

From "Sri h Kolusu" 

To IBM-MAIN@listserv.ua.edu
Date 10/20/2022 12:15:22 AM
Subject Re: Variable Sort Parsing


2. The input is a FB file of 150, and these records are just space padded. The 
other log records in the file are of all different lengths, with some using the 
whole 150.



Billy,

It is quite simple to parse out the contents.  I am going to 2 show different 
versions.

Version 1 : will Parse ALL fields and then we pick and choose which fields we 
need
Version 2 : Will Parse ONLY specific fields of interest.

FIXLEN is the parm which determines the length of the parsed field, so adjust 
it according to your needs.

I added a Delimiter of '|' to distinguish the fields. You can remove it if you 
don't need it

Version 1 :

//STEP0100 EXEC PGM=SORT
//SYSOUT   DD SYSOUT=*
//SORTIN   DD DISP=SHR,DSN=your Input FB 150 byte file
//SORTOUT  DD SYSOUT=*
//SYSINDD *
 OPTION COPY
 INCLUDE COND=(001,150,SS,EQ,C'MSG004CI')
 INREC IFTHEN=(WHEN=INIT,
BUILD=(001,150,SQZ=(SHIFT=LEFT,MID=C' '))),
   IFTHEN=(WHEN=INIT,
PARSE=(%01=(ENDBEFR=BLANKS,FIXLEN=08),  # Job Time
   %02=(ENDBEFR=BLANKS,FIXLEN=08),  # Job num
   %03=(ENDBEFR=BLANKS,FIXLEN=08),  # Job name
   %04=(ENDBEFR=BLANKS,FIXLEN=08),  # Msg number
   %05=(STARTAFT=C'PARM ',
 ENDBEFR=C': ',FIXLEN=15),  # Prog parm
   %06=(ENDBEFR=C',',FIXLEN=08),# Job Date
   %07=(STARTAFT=C'(',
 ENDBEFR=C') ',FIXLEN=10),  # Run Type
   %08=(ENDBEFR=BLANKS,FIXLEN=15),  # Location
   %09=(ENDBEFR=BLANKS,FIXLEN=06)), # Indicator

BUILD=(%03, # Job name
   C'|',# Delimiter
   %05, # Prog Parm
   C'|',# Delimiter
   %06, # Job Date
   C'|',# Delimiter
   %07, # Run Type
   C'|',# Delimiter
   %08, # Location
   C'|',# Delimiter
   %09, # Indicator
   C'|'))   # Delimiter
/*
The output from this is

PAYW015A|SCHEDULED  |20221008|WEEKLY|ALLSITES   |10.4  |
PAYW052X|REQUEST|20221012|DAILY |OH03   |10.6  |
BILLW015|new|20221016|hourly|ASH01  |10.2  |

Version 2:  Notice the ignored fields with % and pay attention to FIXLEN parm

//SYSINDD *
 OPTION COPY
 INCLUDE COND=(001,150,SS,EQ,C'MSG004CI')
 INREC IFTHEN=(WHEN=INIT,
BUILD=(001,150,SQZ=(SHIFT=LEFT,MID=C' '))),
   IFTHEN=(WHEN=INIT,
PARSE=(%=(ENDBEFR=BLANKS),  # Job Time
   %=(ENDBEFR=BLANKS),  # Job num
   %03=(ENDBEFR=BLANKS,FIXLEN=08),  # Job name
   %=(ENDBEFR=BLANKS),  # Msg number
   %05=(STARTAFT=C'PARM ',
 ENDBEFR=C': ',FIXLEN=03),  # Prog parm
   %06=(ENDBEFR=C',',FIXLEN=08),# Job Date
   %07=(STARTAFT=C'(',
 ENDBEFR=C') ',FIXLEN=01),  # Run Type
   %08=(ENDBEFR=BLANKS,FIXLEN=15),  # Location
   %09=(ENDBEFR=BLANKS,FIXLEN=06)), # Indicator

BUILD=(%03, # Job name
   C'|',# Delimiter
   %05, # Prog Parm
   C'|',# Delimiter
   %06, # Job Date
   C'|',# Delimiter
   %07, # Run Type
   C'|',# Delimiter
   %08, # Location
   C'|',# Delimiter
   %09, # Indicator
   C'|'))   # Delimiter
/*

The output from this is

PAYW015A|SCH|20221008|W|ALLSITES   |10.4  |
PAYW052X|REQ|20221012|D|OH03   |10.6  |
BILLW015|new|20221016|h|ASH01  |10.2  |

Thanks,
Kolusu
DFSORT Development
IBM Corporation




--
For IBM-MAIN subscribe / signoff / archive access instructions,

Re: Trying to Parse a LISTCAT with SORT

[Paul Gilmartin]

On Sat, 22 Oct 2022 04:09:43 +, Sri h Kolusu  wrote:
>...
>  %03=(ENDBEFR=C'.',FIXLEN=8),   # Node 3
> ...
Thanks.  I've wished for something line FIXLEN in regular expressions.


On Sat, 22 Oct 2022 04:17:59 +, Sri h Kolusu wrote:
>...
>It is quite simple to convert the Julian date to Gregorian date using DFSORT.
>All you need is another IFHTEN statement to process the julian date
>
>IFTHEN=(WHEN=(42,10,CH,EQ,C'CREATION--'),
> OVERLAY=(165:58,08,UFF,M11,LENGTH=7,
>  175:165,07,Y4T,TOGREG=Y4T))
>
But:
With  decimal point?
without decimal point?
4-digit year?
2-digit year?
Sliding window centered on current year?

So: 
(It's fairly unbiased -- almost everyone doesn't use it.)

-- 
gil

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

FW: Integrated Catalog record layout

[Barry Merrill]

Resent, first one with prior email included went to junk.

It should be, but it's not:

Change 23.219  The ICF Catalog 05 record variable GATGEN should have
VMAC6156   been input as , instead of one byte, and variable
VMACCTLG   GATWRAP='Y' is now set if the first bit of GATGEN is on,
Aug 29, 2005   to mark that this GDG member has "wrapped"; i.e., its
   generation number has exceeded .  If GATWRAP is on,
   GATGEN=GATGEN-32768 to contain the correct Gen number.
   This discovery was precipitated by IGD07001I ABENDs in
   production, which occurred when a GDG that had GATWRAP
   on for some members, and GATWRAP off for others, when
   that GDG generation number goes from 999 to 1000.
 Normally, when all members of a GDG have wrapped, the
 next catalog action turns off the wrap bit in all of
 the catalog records.  For a "normal" GDG, that should
 happen when the +256th gen is created after wrap, as
 only 255 members can exist in the catalog.  But this
 site had had a very old application that originally
 created +1 thru +5 each day, and then deleted +1 thru
 +4, leaving only +5 in the catalog.  However, back when
 Clinton was President, an application change was made
 that created only +1 thru +3 and deleted only +1 & +2,
 so there were 2 old GVoo's left in the catalog.
 When the GDG wrapped, and when the create of +1 would
 have created G1000V00, those old GVoo's still had
 their wrap bit off, and the production job failed:
   IGD07001I; GDG ROLL IN ERROR - RETURN CODE 140 REASON 122
 Return Code 140:
   Inconsistent or conflicting arguments were provided.
 Reason Code 122:
   Catalog G1000Vxx will cause the GDG to exceed the
   limit of 10,999.
 Programmer Response:
   Clean up the GDG in error then catalog G1000Vxx.
   The site found Information APAR II07276, which explained
   how wrap works, but it says to 'see the "Z" page for
   internal details of the wrap bit interface'.

   So the site asked IBM Support: "We need to identify other
   GDGs that have the same exposure to causing ABENDs.  Can
   I look at the 'Z' page?  Does the 'wrap bit' appear in
   SMF 61, 65, 66 ICF Catalog records?"

   IBM Level 2 Catalog Support refused to answer the quite
   valid question, with this answer:
 "Unfortunately, the 'Z' page in our info APARs refer to
 information meant for IBM eyes only, for helping us get
 to problem determination quicker.  We are not at
 liberty to discuss any control block internals that are
 not provided in our published manuals.  As for
 information in SMF records relating to this, this info
 would be included in the updated record portion
 of the SMF record, however we cannot discuss offsets
 for those either.  I am sorry I cannot be more helpful.
 Please let me know if there are any other questions
 that I can answer for you."

   Even escalation to my IBM Poughkeepsie z/OS support did
   not convince IBM Level 2 Catalog Support to identify
   which bit is the "GATWRAP" bit.  The ICF Support and
   Developers hid behind "OCO", Object Code Only, as the
   reason they could not provide catalog record
   documentation (but DSECTS are NOT CODE!).

   So I suggested the site could create a GDG and force it
   to wrap, and by examining SMF records, we concluded that
   first bit of GATGEN was the GATWRAP bit.

   Then, I remembered I still had lots of archaic printed
   manuals, and located the very old "MVS/XA Catalog
   Diagnosis Reference for DFP Release 1.2", which confirmed
   that the GATWRAP bit was indeed the first bit of the
   GATGEN field in the 05 Catalog Record!

Herbert W “Barry” Merrill, PHD
President-Programmer
Merrill Consultants
MXG Software
10717 Cromwell Drive
Dallas, TX 75229
www.mxg.com
214 351 1966 

ad...@mxg.com for business questions
supp...@mxg.com for technical questions
ba...@mxg.com  



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

Re: Integrated Catalog record layout

[Barry Merrill]

It should be, but it's not:

Change 23.219  The ICF Catalog 05 record variable GATGEN should have
VMAC6156   been input as , instead of one byte, and variable
VMACCTLG   GATWRAP='Y' is now set if the first bit of GATGEN is on,
Aug 29, 2005   to mark that this GDG member has "wrapped"; i.e., its
   generation number has exceeded .  If GATWRAP is on,
   GATGEN=GATGEN-32768 to contain the correct Gen number.
   This discovery was precipitated by IGD07001I ABENDs in
   production, which occurred when a GDG that had GATWRAP
   on for some members, and GATWRAP off for others, when
   that GDG generation number goes from 999 to 1000.
 Normally, when all members of a GDG have wrapped, the
 next catalog action turns off the wrap bit in all of
 the catalog records.  For a "normal" GDG, that should
 happen when the +256th gen is created after wrap, as
 only 255 members can exist in the catalog.  But this
 site had had a very old application that originally
 created +1 thru +5 each day, and then deleted +1 thru
 +4, leaving only +5 in the catalog.  However, back when
 Clinton was President, an application change was made
 that created only +1 thru +3 and deleted only +1 & +2,
 so there were 2 old GVoo's left in the catalog.
 When the GDG wrapped, and when the create of +1 would
 have created G1000V00, those old GVoo's still had
 their wrap bit off, and the production job failed:
   IGD07001I; GDG ROLL IN ERROR - RETURN CODE 140 REASON 122
 Return Code 140:
   Inconsistent or conflicting arguments were provided.
 Reason Code 122:
   Catalog G1000Vxx will cause the GDG to exceed the
   limit of 10,999.
 Programmer Response:
   Clean up the GDG in error then catalog G1000Vxx.
   The site found Information APAR II07276, which explained
   how wrap works, but it says to 'see the "Z" page for
   internal details of the wrap bit interface'.

   So the site asked IBM Support: "We need to identify other
   GDGs that have the same exposure to causing ABENDs.  Can
   I look at the 'Z' page?  Does the 'wrap bit' appear in
   SMF 61, 65, 66 ICF Catalog records?"

   IBM Level 2 Catalog Support refused to answer the quite
   valid question, with this answer:
 "Unfortunately, the 'Z' page in our info APARs refer to
 information meant for IBM eyes only, for helping us get
 to problem determination quicker.  We are not at
 liberty to discuss any control block internals that are
 not provided in our published manuals.  As for
 information in SMF records relating to this, this info
 would be included in the updated record portion
 of the SMF record, however we cannot discuss offsets
 for those either.  I am sorry I cannot be more helpful.
 Please let me know if there are any other questions
 that I can answer for you."

   Even escalation to my IBM Poughkeepsie z/OS support did
   not convince IBM Level 2 Catalog Support to identify
   which bit is the "GATWRAP" bit.  The ICF Support and
   Developers hid behind "OCO", Object Code Only, as the
   reason they could not provide catalog record
   documentation (but DSECTS are NOT CODE!).

   So I suggested the site could create a GDG and force it
   to wrap, and by examining SMF records, we concluded that
   first bit of GATGEN was the GATWRAP bit.

   Then, I remembered I still had lots of archaic printed
   manuals, and located the very old "MVS/XA Catalog
   Diagnosis Reference for DFP Release 1.2", which confirmed
   that the GATWRAP bit was indeed the first bit of the
   GATGEN field in the 05 Catalog Record!

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Joe 
Monk
Sent: Saturday, October 22, 2022 8:17 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Integrated Catalog record layout

The mapping macro should be in SYS1.MACLIB.

Joe

On Sat, Oct 22, 2022 at 7:26 AM Willy Jensen 
wrote:

> I'm ok wth the layout of the SMF record as such, what I am looking for 
> is the layout of the field SMF61CRC.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send 
> email to lists...@listserv.ua.edu with 

Re: Integrated Catalog record layout

[Joe Monk]

The mapping macro should be in SYS1.MACLIB.

Joe

On Sat, Oct 22, 2022 at 7:26 AM Willy Jensen 
wrote:

> I'm ok wth the layout of the SMF record as such, what I am looking for is
> the layout of the field SMF61CRC.
>
> --
> 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: Integrated Catalog record layout

[Willy Jensen]

I'm ok wth the layout of the SMF record as such, what I am looking for is the 
layout of the field SMF61CRC.

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

Re: Integrated Catalog record layout

[Joe Monk]

SMF record layouts are in the MVS SMF manual ...
https://www.ibm.com/docs/en/zos/2.5.0?topic=mvs-zos-system-management-facilities-smf

The record layout is here:
https://www.ibm.com/docs/en/zos/2.5.0?topic=rm-headerself-defining-section-51

When SMF61TYP = "A", that is a non-vsam record. The DSN is in SMF61ENM. The
Catalog is in SMF61CNM, which you can read to get the volser.

Joe

On Sat, Oct 22, 2022 at 4:50 AM Willy Jensen 
wrote:

> Hi, anybody knows where to find the mapping of Integrated Catalog records?
> I am looking at SMF type 61 and at the end it says 'New catalog record for
> defined entry', but doesn't say where to find the mapping. I am primarily
> looking for volser information for non-vsam datasets. I have found the
> position by printing a few records and eye-balling the result, but I would
> like something a bit more official. I did look at the CSI interface
> returned info, but it doesn't match up with what I see in the SMF record.
> I couldn't find any IBM documentation nor anything in the internet in
> general.
>
> --
> 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

Integrated Catalog record layout

[Willy Jensen]

Hi, anybody knows where to find the mapping of Integrated Catalog records?
I am looking at SMF type 61 and at the end it says 'New catalog record for 
defined entry', but doesn't say where to find the mapping. I am primarily 
looking for volser information for non-vsam datasets. I have found the position 
by printing a few records and eye-balling the result, but I would like 
something a bit more official. I did look at the CSI interface returned info, 
but it doesn't match up with what I see in the SMF record.
I couldn't find any IBM documentation nor anything in the internet in general.

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