Page 1 of 1

Detecting bad SMF date/timestamps in INCLUDE= Statement

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

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

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

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

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

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

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