Page 1 of 1
Detecting bad SMF date/timestamps in INCLUDE= Statement
Posted:
Wed Jul 21, 2010 6:39 pm
by BillMeany
I was wondering if anyone had a code snippet they could share that can be used to test a date/timestamp field that is in SMF Header format, that is in the form CCYYDDDF. I am currently taking this field and breaking it into its components. I test the CC field to see if it contains X00' or X'01'. I then look at the YY field to see if it is GE than X'00' AND LE X'99'. Finally I look at the first DD of the DDDF field and see if it is GE X'00' and LE X'36'. This is working for me, but not not seem to be a very elegant approach. Any suggestions, or directions to the appropriate documentation would be appreciated.
Bill
Re: Detecting bad SMF date/timestamps in INCLUDE= Statement
Posted:
Wed Jul 21, 2010 7:13 pm
by Bill Dennis
I'm curious. Why the need to check for invalid date fields? What process is creating these bad SMF records?
Re: Detecting bad SMF date/timestamps in INCLUDE= Statement
Posted:
Wed Jul 21, 2010 7:26 pm
by BillMeany
I am working with DCOLLECT data, and have multiple record types combined in a flat collection file. Not all of the records are from DCOLLECT, but from other sources. It is this collection of records that is causing the issue. When I read the file and look to select a certain record type, say a DASD record, I need to examine the record a little deeper to make sure it is what I am after. Checking the date/time to make sure it is in the correct format has proven to be effective. It is a self created situation. If I was not aggregating a lot of different records into the single file, I would not be looking at the date/time stamps.
Bill
Re: Detecting bad SMF date/timestamps in INCLUDE= Statement
Posted:
Wed Jul 21, 2010 11:27 pm
by skolusu
Billmeany ,
With z/OS DFSORT V1R5 PTF UK51706 or z/OS DFSORT V1R10 PTF UK51707 (Nov, 2009), you can use the new date conversion function TOGREG/TOJUL like shown below to validate the date fields. All the invalid dates will have astericks.
//STEP0100 EXEC PGM=SORT
//SYSOUT DD SYSOUT=*
//SORTIN DD *
2010000 - INVALID DAY OF YEAR
0000021 - INVALID YEAR
2009366 - INVALID DAY OF YEAR FOR NON LEAP
2008366 - VALID DAY OF YEAR FOR LEAP YEAR
2010060 - MARCH 1ST FOR NON LEAP YEAR
2008060 - FEB 29TH FOR NON LEAP YEAR
//SORTOUT DD SYSOUT=*
//SYSIN DD *
SORT FIELDS=COPY
INREC OVERLAY=(50:1,7,Y4T,TOGREG=Y4T(-))
//*
The output from this job is
2010000 - INVALID DAY OF YEAR **********
0000021 - INVALID YEAR **********
2009366 - INVALID DAY OF YEAR FOR NON LEAP **********
2008366 - VALID DAY OF YEAR FOR LEAP YEAR 2008-12-31
2010060 - MARCH 1ST FOR NON LEAP YEAR 2010-03-01
2008060 - FEB 29TH FOR NON LEAP YEAR 2008-02-29
Re: Detecting bad SMF date/timestamps in INCLUDE= Statement
Posted:
Thu Jul 22, 2010 7:58 pm
by BillMeany
The suggestion to use the INREC statement to check the date is valid. If I understand the way DFSORT processes data, the INCLUDE processing phase occurs before the INREC phase. If I use the INREC statement to detect the bad dates, then I would need to pass the output from the INREC to another pass with the INCLUDE. Certainly a doable approach, but I pay the cost of another pass through the data. Was hoping for a neat trick to catch the bad dates in the INCLUDE processing.
I appreciate the information.
Bill
Re: Detecting bad SMF date/timestamps in INCLUDE= Statement
Posted:
Thu Jul 22, 2010 9:43 pm
by skolusu
BillMeany wrote:The suggestion to use the INREC statement to check the date is valid. If I understand the way DFSORT processes data, the INCLUDE processing phase occurs before the INREC phase. If I use the INREC statement to detect the bad dates, then I would need to pass the output from the INREC to another pass with the INCLUDE. Certainly a doable approach, but I pay the cost of another pass through the data. Was hoping for a neat trick to catch the bad dates in the INCLUDE processing.
I appreciate the information.
Bill
BillMeany,
NOT really. You don't need another pass to eliminate the bad date records . You can use an INCLUDE on OUTFIL and filter the records. It also gives you an option to write all the bad date records into another file.
try this job
//STEP0100 EXEC PGM=SORT
//SYSOUT DD SYSOUT=*
//SORTIN DD *
2010000 - INVALID DAY OF YEAR
0000021 - INVALID YEAR
2009366 - INVALID DAY OF YEAR FOR NON LEAP
2008366 - VALID DAY OF YEAR FOR LEAP YEAR
2010060 - MARCH 1ST FOR NON LEAP YEAR
2008060 - FEB 29TH FOR NON LEAP YEAR
//GOOD DD SYSOUT=*
//BAD DD SYSOUT=*
//SYSIN DD *
SORT FIELDS=COPY
INREC OVERLAY=(50:1,7,Y4T,TOGREG=Y4T(-))
OUTFIL FNAMES=BAD,INCLUDE=(50,1,CH,EQ,C'*')
OUTFIL FNAMES=GOOD,SAVE
//*
Re: Detecting bad SMF date/timestamps in INCLUDE= Statement
Posted:
Fri Jul 23, 2010 1:26 am
by BillMeany
skolusu,
Thank you. What you are suggesting will indeed work. I appreciate your help with this.
Bill