-------------------------------<snip>----------------------
Does anybody know why the people who designed SMF decided to encode the
date and time as FL4'hundredths of seconds after midnight' plus
PL4'0cyyddd'? Why not just put in the STCK value? STCK is guaranteed to
be unique on a system (and on a sysplex). I ask because I want to relate
all the SMF records generated by a specific job together. Unfortunately,
I have some people who submit 4 or 5 jobs with the same name which end
up with the same SMF "joblog" value (they are basically IEFBR14 jobs).
If SMF used STCK, then the STCK value alone could be used to guarantee
uniqueness.
-----------------------------<unsnip>-----------------------
I can think of two reasons:
1. STCK instruction didn't exist when SMF was designed. All we had was
the interval timer and the TIME macro only returned DEC, TU and BIN
values. (IIRC a TU value was timer units and a timer unit was between 26
and 27 microseconds.)
2. I know of NO guarantee that TOD values are unique across ANY LPAR or
CEC boundaries. To assure uniqueness across those boundaries, AFAIK,
you'll have to program some value into the programmable field of the
ETOD, and use THAT value. Are you prepared to rewrite SMF and related
system processing? Not to mention all the hundreds of thousands of
programs designed to gather, consolidate and report on SMF data?
--------------------------------<snip>------------------
And, continuing the whine, why did the RMF people decide to use a
different format from the SMF people? It doesn't appear to be any more
accurate! If fact, it is less granular. Huh?
-------------------------------<unsnip>------------------
Much of RMF data is of a statistical nature, rather than being based on
actual measurements of individual events. Being too granular can be a
definite disadvantage, since the once-per-period spike might tend to
distort the true picture too much. A single event, among hundreds of
thousands, is insignificant in this context because, in many cases, the
best picture is presented by averages. Lots of variables here, but
excessive granularity might serve only to cloud the overall picture. Not
to mention the time required to do all the math.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
