Ed Gould ps2...@yahoo.com wrote in message
news:1315436928.60134.yahoomailmob...@web161421.mail.bf1.yahoo.com...
Interesting topic.
SMF timestamps are a little bit tricky as they are not when the record
is written but when they are created.
So a record could be in storage and not written
On Wed, 7 Sep 2011 18:26:40 -0400, Robert A. Rosenberg hal9...@panix.com
wrote:
Since each record has a time stamp in its header showing (in local
time) when it was written, I would think that if record X+1's time
stamp is an hour earlier than record X's time stamp that would be a
red flag that
Walt Farrell wrote:
The problem with the transition from daylight-saving time to standard time,
Elardus, is that the hour from 1 a.m. to 2 a.m. (0100 to 0200) happens twice:
once while you're on daylight saving time, and once when you've switched back
to standard time. (Assuming I got the
: Wednesday, 7 September 2011 4:46 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: SMF timestamps
Walt Farrell wrote:
The problem with the transition from daylight-saving time to standard time,
Elardus, is that the hour from 1 a.m. to 2 a.m. (0100 to 0200) happens twice:
once while you're on daylight
I hadn't really planned on sequential processing. That assumes that the
relative physical sequence of individual records never change. Which
implies not having been run through a sort process. Of course, we have
multiple z/OS images and we merge all the SMF data together using
DFSORT. This is done
I'm using SMF90 subtypes 1 2 to catch time and date changes from SET
commands. This has worked well so far to provide the logic necessary to
identify that the clock has been set back and there will be SMF30s and almost
every other record type with an hour duplicated due to Daylight Saving Time
Interesting topic.
SMF timestamps are a little bit tricky as they are not when the record is
written but when they are created.
So a record could be in storage and not written for as long as a week maybe
more. We had one job that lasted a week. We had to change code to allow
At 09:36 -0500 on 09/06/2011, McKown, John wrote about Re: SMF timestamps:
I should have said that I know how to convert the SMFSTAMP8 to
RCF3339 format. The problem is determining the timezone offset for a
specific date time rendered in LOCAL time. Now, for my own shop,
there is only one
The SMF timestamps in SMF records, such as reader start date time, where the
date is PL4'0cyydddF' and the time is a fullword binary number of 1/100ths of a
second past midnight. But what is confounding me is that this seems to be the
LOCAL time, not GMT/UTC (yes, I know GMT != UTC
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
McKown, John wrote:
The SMF timestamps in SMF records, such as reader start date time, where the
date is PL4'0cyydddF' and the time is a fullword binary number of 1/100ths of
a second past midnight. But what is confounding me is that this seems to be
the LOCAL time, not GMT/UTC (yes, I know
-Original Message-
From: IBM Mainframe Discussion List
[mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Elardus Engelbrecht
Sent: Tuesday, September 06, 2011 9:28 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: SMF timestamps
McKown, John wrote:
The SMF timestamps in SMF records
On Tue, 6 Sep 2011 08:23:12 -0500, McKown, John john.mck...@healthmarkets.com
wrote:
... That is, being in the US Central Timezone, when we go to Daylight Saving
time (from TIMEZONE=W.06 to TIMEZONE=W.05) at 02:00, the time range from
02:00-02:59 repeats. Is this correct? If so, I don't know
On 9/6/2011 9:37 AM, McKown, John wrote:
I should have said that I know how to convert the SMFSTAMP8 to RCF3339 format. The problem is
determining the timezone offset for a specific date time rendered in LOCAL time. Now, for my
own shop, there is only one problem: the 1 hour overlap when
John,
Barry, did a great job of explaining the issue(s). what we did with users is to
say all times are where the system (CPU) is. This simplified issues immensely.
In our case there were 2 locations one set and in Europe(and. Chicago) Both
were fine with the agreement. They were not
On 9/6/2011 11:04 AM, Richard L Peurifoy wrote:
Perhaps we need a requirement for an option to use GMT in the SMF
header, or maybe to just use TOD timestamps. It would be nice to
have the GMT offset in the records too, but this would require
changes in the record structure which will be harder
during the first 02:00-02:59 interval, and another one start at
the exact same time during the second 02:00-02:59 interval.
Am I supposed to infer from this discussion that SMF timestamps are recorded
in local time, as opposed to UTC?
What century is this, anyway? I thought it had long been
Am I supposed to infer from this discussion that SMF timestamps are recorded
in local time, as opposed to UTC?
It depends on the record/vendor, as Dr. Barry stated.
What century is this, anyway? I thought it had long been generally believed
that critical timestamps should be recorded in UTC
On Tue, 6 Sep 2011 11:31:22 -0400, Gerhard Postpischil wrote:
The easiest would be to keep existing formats, but add a new SMF
record type that would record clock information whenever that is
changed (including the daylight savings transition), and provide
the IPL settings.
Also, include
McKown, John wrote:
I should have said that I know how to convert the SMFSTAMP8 to RCF3339 format.
The problem is determining the timezone offset for a specific date time
rendered in LOCAL time.
Ok. You want to determine what the GMT/UTC is at the time of LOCAL time?
If so, sorry that I'm
On 2011-09-06 09:23, McKown, John wrote:
The SMF timestamps in SMF records, such as reader start date time, where the
date is PL4'0cyydddF' and the time is a fullword binary number of 1/100ths of a
second past midnight. But what is confounding me is that this seems to be the LOCAL
time, not GMT
On Tue, 6 Sep 2011 11:28:40 -0500, Elardus Engelbrecht
elardus.engelbre...@sita.co.za wrote:
Damn! While we are not using those daylight saving time thing, I see your
problem...
What about a table driven solution? Say for hours 1-hours 2 you use W.06,
hours 2 - hours 3 you use W.05? I admit
In 4e663cca.5070...@valley.net, on 09/06/2011
at 11:31 AM, Gerhard Postpischil gerh...@valley.net said:
The easiest would be to keep existing formats, but add a new SMF
record type
Ot new segments in the type 30.
--
Shmuel (Seymour J.) Metz, SysProg and JOAT
ISO position; see
On Tue, 6 Sep 2011 10:47:42 -0500 Paul Gilmartin wrote:
Am I supposed to infer from this discussion that SMF timestamps are
recorded in local time, as opposed to UTC?
What century is this, anyway? I thought it had long been generally
believed that critical timestamps should be recorded
24 matches
Mail list logo
