(Originally posted 2005-02-18.)
It’s going to sound like the only thing I talk about is DFSORT. While that isn’t entirely true I am currently updating my “What’s New With DFSORT?” foils. And it made me think about processing SMF data…
In our internal analysis processes we chuck SMF data around quite a bit, whether subsetting it or actually mangling the records. In this entry I want to talk about subsetting – as most people have some other means of doing the actual mangling.
For a while you’ve been able to use the TMx and DTx formats to extract meaningful information from SMF Timestamp fields.
(Actually our process hasn’t caught up with this – we still have a REXX Exec that creates DFSORT statements from human-readable timestamps. But I digress.)
So you could code something like:
//SYMNAMES DD *
RDW,1,4,BI
SKIP,1
RECTYPE,*,1,BI
SMFTIME,*,4
SMFDATE,*,4
//SYSIN DD *
OPTION COPY
INREC FIELDS=(RDW,SMFDATE,DT1,SMFTIME,TM4, ...)
Although the above is a reformatting it illustrates a couple of points:
- You can use DFSORT Symbols to map (the front of) SMF records
- You can process the timestamp fields into something a little more readable.
- The SMFDATE field will be reformatted as DT1 (Z’yyyymmdd’) field, which you can post-process.
- The SMFTIME field will be reformatted as a TM4 (Z’hhmmssxx’)field.
One of our bugbears with IFASMFDP has been that if you want to specify a time range it applies to all the output destinations. We might want, for example, to send all the RMF data (SMF 70-79) to one data set and only a single day’s worth of CICS CMF data (SMF 110) to another data set. While I think you could do it with an exit it’s cumbersome.
With DFSORT OUTFIL you could write to two separate destinations, specifying totally different conditions…
//SYMNAMES DD *
*
* Syms mapping original record
RDW,1,4,BI
SKIP,1
RECTYPE,*,1,BI
SMFTIME,*,4
SMFDATE,*,4
*
* Syms for use after INREC
POSITION,1
_RDW,1,4,BI
_RECTYPE,*,1,BI
_SMFTIME,*,4
_SMFDATE,*,4
_ORIGINAL The original record stuck after the prefix
OPTION COPY
INREC FIELDS=(RDW,RECTYPE,SMFTIME,SMFDATE,5)
OUTFIL FNAMES=TYPE7X,INCLUDE=(_SMFDATE,GE,+20050213,
AND,_SMFDATE,LE,+20050217),
AND,(_RECTYPE,GE,+70,AND,_RECTYPE,LE,+79)),
OUTREC=(_RDW,_ORIGINAL)
OUTFIL FNAMES=TYPE110,INCLUDE=(_SMFDATE,EQ,+20050217,AND,
_RECTYPE,EQ,+110),
OUTREC=(_RDW,_ORIGINAL)
OUTFIL FNAMES=OTHER,SAVE,OUTREC=(_RDW,_ORIGINAL)
The final OUTFIL statement uses the SAVE parameter to ensure all the records thrown away by the previous OUTFIL statements are written to the "OTHER" DD.
This example looks much more complicated because to use the SMF D/T values you have to reformat them. I've stuck them into a "prefix" which the OUTFIL statements strip off. So really long records won't work with this technique. (So you have to treat the date and time as BI and PD instead.)
The underscored symbols map the record after INREC has been used to apply the prefix. I use this convention to make it easier to handle INREC "invalidating" the original symbols: The fields move but the symbols don't change to handle that.
Actually I can't resist telling you about one "mangling" feature of the latest PTFs (UQ95213 and UQ95214):
In a lot of records, whether GTF or some of the timing fields in DB2 Accounting Trace (SMF 101), the values are stored as 8-byte STCK values. You can format these using new types. In fact when designing this I suggested both STCK and STCKE (the new format). So using DCn, TCn, DEn and TEn formats you can extract STCK Date, STCK Time, STCKE Date and STCKE Time, respectively.
In the first instance I think this is going to be more useful for formatting GTF records (as their timestamps use STCK format). (Actually I have some prototyping code that flattens SMF records out so DFSORT can process the data fields and so I may well be using STCK formats in prototype analysis, particularly if records are sent to me broken.)
Mainframe, Performance, Topics 