On 8/11/2018 3:06 AM, Paul Gilmartin wrote:
On Wed, 7 Nov 2018 20:19:43 +1100, Andrew Rowley wrote:
This means that (if your system follows the rules for DST changes) ...
Why should any system choose *not* to "follow the rules"?
z/OS has a weird culture.
I guess some sites change times manually, via IPL or at a time that is
more convenient than the official time. I added the disclaimer because
someone, when I talked about time zones, mentioned they had a Java
application that had problems when it encountered times that didn't
exist in the timezone they had set.
I believe the "built in Java time zone rules" are those available as IANA
tzdata.
So if z/OS doesn't conform to IANA tzdata it's inconsistent with one of its own
components.
z/OS has worked with times a probably a lot longer than the tzdata has
existed. Time is such a fundamental part of so many applications that it
would be very difficult to make significant changes to how it behaves. A
long time ago I was on the periphery of a project to change to UTC=UTC
from UTC=LOCAL, where local was 10 hours ahead of UTC. This was a major
project due to the overlap.
Even now, I would expect there are sites that IPL for the change and
stay down for an hour when the time moves backward. The effect of a
change of local time for z/OS components is well understood, but that is
not necessarily the case for in-house developed applications.
Are SMF timestamps guaranteed to appear in chronological order?
I could imagine concurrent processes' not writing SMF records in
the same order in which they obtained the time.
Can the SMF log be sorted into chronlogical order? Given the diversity of
formats, this presents a challenge. But DFSORT has shown a surprising
ability to meet such challenges.
SMF timestamps are not guaranteed to be in chronological order. You can
easily sort them with DFSORT, the SMF header has a time that is always
the same format. Unfortunately, it is only recorded in hundredths of a
second, you can't easily determine order more accurately than that.
I was disappointed that the SMF header changes in 2.3 didn't find some
way to add a more accurate timestamp to all SMF records.
--
Andrew Rowley
Black Hill Software
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
