There are MANY datetime values in SMF records, and in MANY formats.
The 8-byte "SMFSTAMP" format with time to 2 decimals and Julian date
is used not only in the standard timestamp in the SMF header bytes 3-10,
which is ALWAYS on the LOCAL time zone, but SMFSTAMP8 is used for many
other datetime values, especially in the job-related records, like the
READTIME. However, some of the job event records contain only the
four-byte time so their datetime values must be inferred from the
Date part of READTIME or SMFTIME (notable, INITTIME and ALOCTIME in
the 30s are only provided as LOCAL times without a date).
There are 634 datetime fields that are input with SMFSTAMP8 in MXG Software).
I believe all of these SMFSTAMP instances in SMF records are on the LOCAL
time zone, although any vendor can write any SMF record with any value in that
format.
However, there are many other instances of datetime values that are
written in 8-byte "TODSTAMP" format, (1145 instances in MXG) and I
believe they are all on the GMT/UTC Time Zone, although there are
instances of two TODSTAMP values in some records, with one on LOCAL
and the other on GMT.
And there are some really strange-looking character date and time
and datetime values scattered throughout SMF data, especially for
newer records that may come from opensystems sources.
In many SMF records, the GMT Offset value (CVTTZ) is provided, but
by no means is it always present; in some records, there may be two
datetimestamps for the same event that can be compared to determine
the GMT offset, but that can require fuzzy logic, for example in
the SMF 30s, since SMF30IST is in SMFSTAMP8 format, rounded, and
with 10 millisecond resolution, while it's GMT event counterpart,
SMF30ISS is in TODSTAMP format with microsecond resolution.
And, SMF30ISS only exists in the Subtype 2 and 3 Interval Records.
And, SMF30IST does NOT exist in the "MULTI-DD" records, which contain
only the ID and EXCP segments (for steps/intervals with more DDs
that will fit in a single 32K SMF record).
And, some SMF vendor-created records have only GMT fields, and
in the long past, there were user-written records with the
header SMFTIME in GMT, but I've not seen that in the current
millennium.
So, it "ain't simple", and each record can only be examined for
its specific contents.
Merrilly yours,
Barry Merrill
Herbert W. Barry Merrill, PhD
President-Programmer
Merrill Consultants
MXG Software
10717 Cromwell Drive
Dallas TX 75229
214 351 1966 tel
214 350 3695 fax
www.mxg.com
P.S. Long ago, I had discussions with IBM SMF developer Bill Richardson
for a proposed extension to every SMF record precisely to contain
the GMT OFFSET, since expanding the SMF header would have been
a VERY incompatible change to the many programs that read SMF with
expected fixed field locations, but because many records do not
contain a version number, causing the length of the record to be
required to determine version (e.g., JES 26 records), that extension
was never implemented.
P.P.S But there is currently a SHARE Requirement in development that is
looking at a suite of fields that are needed for all JOB-related
records, for cost-recovery, including JCTJOBID, ACCOUNTn, and
SYSPLEX, so the addition of the GMT Offset might be a future
consideration, if IBM reviews that requirement in a favorable light.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
