SKIP:
Carry over code is easy to just carry over without realizing you are
carrying over bad code .
It nice to sit back and think "Done" no more to worry about.
I have done this myself.
I was in a installation and found that the author just copied code
and (from an old IPO no less) bing picked up bad ipo code.
Its easy to say blame it on IBM when they did the copying.
I have looked at a few IEFACTRT's over the years (from vendors and
IPO's and etc etc) and I have learned a few tricks on how to do things.
It still comes down to the sysprog not watching where they get the
code and propagating code going forward.
I got caught when SMF changed one of their exits and me not reading
the FM.
You learn from then on to read the FM on every release.
And the boss doesn't understand why sometimes our heads are reading
manuals all the time.
Ed
On Dec 16, 2013, at 4:31 PM, Skip Robinson wrote:
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 <IBM-
[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
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
