I didn't make clear in the original posting that this is an IEFACTRT component. I had thought in the beginning that the code was based 'AN OLD VERSION OF CODE NOW SUPPLIED IN SYS1.SAMPLIB(IEEACTRT)' (per a comment in the usermod) but scouring SAMPLIB for the particular lines in question yielded nothing. This code has worked for years through thick and thin, but we've never focused on this situation before, which for all I know has been happening forever.
The tricky part is developing and testing for (what appears to be) a rare case. In the overwhelming majority of cases, EXCP counts show up in the first or only record section. BTW this exit component also prints out the BLKSIZE for each DDNAME. In an earlier post, I asked (then answered) how to find BLKSIZE > 32K. That field is SMF30XBS in the same record segment. However, since SMF30XBS is XL8 rather than 4, the instruction also needed changing to pick up the low order 4 bytes: ICM R1,B'1111',SMF30XBS+4 MAX BLKSIZE (LOW ORDER BYTES) . . JO.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile [email protected] From: William Richardson <[email protected]> To: [email protected], Date: 12/16/2013 10:22 AM Subject: Re: EXCP Counts in SMF Exit Sent by: IBM Mainframe Discussion List <[email protected]> Skip, Sorry for the delayed response (I am using the Summary 'Digest' notification here); a couple of general questions about your original note on this thread ...... your note refers to using an 'exit' are you actually referring to an SMF IEFACTRT Step/Job Termination exit that gets control during step and job term to format the data in question or just an SMF Type 30 analysis program ??? In either case your "exit" needs to be able to handle (as noted previously) "Chained" SMF type 30 records and especially if you are interested in detailed EXCP data (each entry represents the counts and dev connect time for A DEVICE associated with each DD used in the reporting period) AND since there can be LOTS of them (more than can fit on a 32K byte record) this data can span multiple physical records. This is where the "triplet" (or in some cases the "quadlet"??) comes in as you reported on your original note. Specificity, SMF30EON is he number of EXCP sections on the CURRENT record and SMF30EOS (the additional/new 4 byte field) reports the number of EXCP sections on "subsequent" records. To see and process ALL the EXCP entries you MUST take into account BOTH numbers; and note that the "first" SMF Type 30 record might actually have '0' EXCP entries (SMF30EON) BUT there is EXCP data on the 'subsequent' records for the job/sytep (NON-ZERO SMF30EOS). Background: SMF 30 Record Structure: - Standard Header - Triplets Section (watch for "Quads") - ID Section - FIXED Section-S (ie. Performance, etc) - Variable/Repeating Sections(s) ..... including EXCP (but there are others!) The 'first' SMF 30 record has "all" the section (but maybe not ALL "variable") and the "subsequent" ONLY has 'Header', Triplets, ID section and needed variable sections. You have to IGNORE "fixed" (data) sections on 'chained' records because they don't exist (their 'number' triplet field is '0'). There are a number of possible reasons (specifics are not really important) that an SMF Type 30 "first" record has NO EXCP sections but does have EXCP entries on "subsequent" (ie. Chained records). Hope that helps clarify things a bit ..... as noted by other there are a multitude of ways to view/process this data post-real time to check this out. There are many SMF 30 processing functions/exits that do not totally handle this and can get weird results if not properly prepare when this event (ie. multiple 30's for an event) occurs!!! Bill.... IBM z/OS System Software development (Former SMF Component Owner) ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
