In
cae1xxdegehhtqobec5d5aa9ge-jc8cpfrpjqgdb1e-8qmbz...@mail.gmail.com,
on 06/07/2013
at 02:58 PM, John Gilmore jwgli...@gmail.com said:
I suspect that you two will continue in your naif views, but let me
try one more time, taking first Mr Gilmartin and then Dr Merrill.
It is quaint for one
I am a little weary of correcting misapprehensions.
Who asked you to?
-
Ted MacNEIL
eamacn...@yahoo.ca
Twitter: @TedMacNEIL
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to
Did you notice the z/OS 1.13 enhancement in SMS, where the creation time
is also stored in the new F9 DSCB? Currently only for datasets that
create a F9 DSCB.
Kees.
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Charles Mills
Sent:
On 6/6/2013 11:39 PM, Vernooij, CP - SPLXM wrote:
Did you notice the z/OS 1.13 enhancement in SMS, where the creation time
is also stored in the new F9 DSCB? Currently only for datasets that
create a F9 DSCB.
DS9JOBNAME DS CL8 Job name used to create the
*
On Thu, 6 Jun 2013 23:48:46 -0700, Ed Jaffe wrote:
... the creation time is also stored in the new F9 DSCB
...
DS9TIME DS XL6 Number of microseconds since
* midnight, local time, that the data
* set
I am not sure I understand Paul Gilmartin's last post.
XL6 specifies a target, assembled length of six bytes. There are 6 x
8 = 48 bits available in these 6 bytes.
A 24-hour day contains 60 x 60 x 24 x 1,000,000 = 29,664,400,000,000 µsec
2^48 - 1 = 281,474,976,710,655
These six bytes are
John Gilmore wrote:
These six bytes are thus entirely adequate to contain any unsigned elapsed- µ
- sec value in a 24-hour day.
Agreed. Only if all users of that 6 bytes are still using it as *un-signed*
value.
There must be a reason, why such precision is needed? Any one willing to share
I'd say first: there must be a reason to store the creation time. What was the
reason?
So if IBM decided to store the creation time rounded only to minutes or
seconds, people would complain that it should be more accurate. If so, it is a
wise decision to store it accurate enough for now and
IMO, if IBM were to store the creation date time, then the only logical
value to store is the STCKE value taken somewhere within the allocation
process. It is 16 bytes in length and cannot be made any more accurate
because the hardware doesn't support a greater accuracy. It is not human
readable,
Pedantry follows:
John McKown wrote of an STCKE value it is 16 bytes in length . . . ,
and this is literally true, but the rightmost two-byte
programmable-field value is not part of the TOD value.
The leftmost 14-byte/112-bit substring is the TOD value.
John Gilmore, Ashland, MA 01721 - USA
On Fri, 7 Jun 2013 07:29:09 -0500, John McKown wrote:
IMO, if IBM were to store the creation date time, then the only logical
value to store is the STCKE value taken somewhere within the allocation
process. It is 16 bytes in length and cannot be made any more accurate
because the hardware
The sequence of both STCK and STCKE values is a unique, monotone
ascending ones, so that even two successive STCK[E] instructions
executed on the same CP yield such values. The programmable field
serves a different purpose. It identifies which TOD clock in a
multiclock SYSPLEX provided a
On Thu, 6 Jun 2013 23:48:46 -0700, Ed Jaffe wrote:
DS9TIME DS XL6 Number of microseconds since
* midnight, local time, ...
Did I fail to read this correctly previously? Now that I look more
carefully, it seems to be saying that the field
Nicely avoiding DST problems and leaving them to the customer.
The leapsecond is added after 23:59:59, so before midnight. No confusion there.
Kees.
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Paul Gilmartin
Sent: Friday, June
On 2013-06-07, at 08:09, Vernooij, CP - SPLXM wrote:
Nicely avoiding DST problems and leaving them to the customer.
Indeed.
The leapsecond is added after 23:59:59, so before midnight. No confusion
there.
Is it well specified whether the leap second is added after
23:59:59 UTC or after
https://en.wikipedia.org/wiki/Leap_second
Time of day adjustments occur on the last second of any day of any
month, but so far have only occurred on Dec 31 or Jun 30.
You could skip 23:59:59 or add 23:59:60 UTC, simultaneously around the world.
On Fri, Jun 7, 2013 at 9:32 AM, Paul Gilmartin
Leap seconds increment a seconds counter (or a surrogate for one).
The appropriate conversion routine then produces a Gregorian date or
the like from this value.
Never, never try to increment or decrement a calendar date
programmatically: that way madness lies. Conceptial confusion lies
there
On 6/7/2013 5:29 AM, John McKown wrote:
IMO, if IBM were to store the creation date time, then the only logical
value to store is the STCKE value taken somewhere within the allocation
process. It is 16 bytes in length and cannot be made any more accurate
because the hardware doesn't support a
:: -Original Message-
:: From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
:: Behalf Of John Gilmore
:: Sent: Friday, June 07, 2013 4:52 AM
:: To: IBM-MAIN@LISTSERV.UA.EDU
:: Subject: Re: Age of datasets in hours, not days?
::
:: I am not sure I understand Paul
On 6/7/2013 9:25 AM, retired mainframer wrote:
:: A 24-hour day contains 60 x 60 x 24 x 1,000,000 = 29,664,400,000,000
:: µsec
Your calculator broken or are using a base other than 10?
Should be 86,400,000,000 µsec.
--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive
Of course, for 100% coverage of all possible usage scenarios, time stamps
should contain both UTC and local time
One timestamp and the GMT offset takes less space and is IMO all that is needed.
Barry Merrill
Herbert W. “Barry” Merrill, PhD
President-Programmer
MXG Software
Merrill Consultants
I am or was then, I hope temporarily, the thing broken.
The correct value is: 86,400,000,000 µsec
Fortunately/serendipitously my argument is unimpaired.
John Gilmore, Ashland, MA 01721 - USA
--
For IBM-MAIN subscribe / signoff
On Fri, 7 Jun 2013 12:12:01 -0400, John Gilmore wrote:
Never, never try to increment or decrement a calendar date
programmatically: that way madness lies. Conceptial confusion lies
there too: there is no xx.xx.60 UTC
From:
Splain why a database is needed if the GMT offset value is the correct delta,
that
is, of course, reset when times are changed between GMT and offset value.
Or explain why the second datetime stamp, which would have the same delta as the
offset in effect, adds anything?
Barry
-Original
In 51b2083c.3060...@phoenixsoftware.com, on 06/07/2013
at 09:20 AM, Ed Jaffe edja...@phoenixsoftware.com said:
Of course, for 100% coverage of all possible usage scenarios, time
stamps should contain both UTC and local time.
I'd prefer UTC and local offset.
--
Shmuel (Seymour J.)
On 6/7/2013 9:34 AM, Barry Merrill wrote:
One timestamp and the GMT offset takes less space and is IMO all that is needed.
That would suffice.
Of course, one must remember to save the offset, then issue STCK[E], and
then compare the saved offset against the current offset. If any change
It may be that Dr Merrill and I have different objectives.
My interest is only incidentally in this instant's STCKE value. It is
in the use of such values as date-time values in both the post-1900
past and the not too remote future.
John Gilmore, Ashland, MA 01721 - USA
On Fri, 7 Jun 2013 14:58:01 -0400, John Gilmore wrote:
Precession very gradually brings UTC (and other lunisolar calendars
too) out of alignment with the seasons on earth. Leap seconds correct
for this precession, keeping UTC seasonally aligned, or nearly so.
That's the purpose of leap years.
The rotation is not constant, and is too slow. It takes (a very little) more
than 24 hours for the earth to make one rotation.
What have I started!?! All I wanted to know was whether LISTCAT or the like
supported dataset age granularity finer than one day!
Charles
-Original Message-
On Fri, 7 Jun 2013 15:28:21 -0700, Charles Mills wrote:
The rotation is not constant, and is too slow. It takes (a very little) more
than 24 hours for the earth to make one rotation.
What have I started!?! All I wanted to know was whether LISTCAT or the like
supported dataset age granularity
Microseconds? Milliseconds? Who cares? They're both too small to be much
concerned with.
I'd settle for AM/PM at this point. It would be an improvement in granularity
on local calendar days.
Charles
-Original Message-
From: IBM Mainframe Discussion List
Julian-calendar leap years are defined very simply as those that have
serial numbers divisible by 4, those in the doubly infinite sequence
. . . -12, -8, -4, 0, +4, +8, +12 . . .
A four-year Julian-calendar cycle thus contains a mean of
(3 x 365 + 1 x 366)/4 = 365.25 days.
This is
Leap seconds deal with accumulating precession that is not dealt with
effectively by the definition of the Gregorian calendar.
I don't *think* so. I think they deal with the rotation of the earth on its
axis taking more than 24 hours, as opposed to a rotation around the sun
taking more than 365
Here I was dealing with the precession of the vernal equinox. The
position of the sun at the time of the vernal equinox is slowly
shifting westward in the sky. This is a standard, not at all arcane
usage.
I don't think Charles Mills knows much about what he is talking
about in this case, but I
At 08:03 -0500 on 06/07/2013, Paul Gilmartin wrote about Re: Age of
datasets in hours, not days?:
On Fri, 7 Jun 2013 07:29:09 -0500, John McKown wrote:
IMO, if IBM were to store the creation date time, then the only logical
value to store is the STCKE value taken somewhere within the
At 14:58 -0400 on 06/07/2013, John Gilmore wrote about Re: Age of
datasets in hours, not days?:
The arithmetic of multiple moduli and several simultaneous cycles
used to convert counter values into calendar dates always numbers
seconds in the sequence
0, 1, 2, . . . , 59
It knows nothing
At 07:09 -0500 on 06/07/2013, Elardus Engelbrecht wrote about Re: Age
of datasets in hours, not days?:
John Gilmore wrote:
These six bytes are thus entirely adequate to contain any unsigned
elapsed- µ - sec value in a 24-hour day.
Agreed. Only if all users of that 6 bytes are still using
At 08:32 -0600 on 06/07/2013, Paul Gilmartin wrote about Re: Age of
datasets in hours, not days?:
Is it well specified whether the leap second is added after
23:59:59 UTC or after 23:59:59 local time if the two happen to
differ?
It is added just after 23:59:59 UTC (making the next second
At 09:20 -0700 on 06/07/2013, Ed Jaffe wrote about Re: Age of
datasets in hours, not days?:
As a software developer, I have had multiple occasions to process
event times stored as all or part of a TOD value. For obvious
reasons, end users prefer everything displayed to them in local
time.
Charles,
You should know by now that what you ask for is not always what you get!
Eric Bielefeld
z/OS Systems Programmer
Milwaukee, Wisconsin
414-475-7434
- Original Message -
From: Charles Mills charl...@mcn.org
Subject: Re: Age of datasets in hours, not days?
The rotation is not
:: -Original Message-
:: From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
:: Behalf Of Charles Mills
:: Sent: Friday, June 07, 2013 3:28 PM
:: To: IBM-MAIN@LISTSERV.UA.EDU
:: Subject: Re: Age of datasets in hours, not days?
::
:: The rotation is not constant, and is
AFAIK, w/o a usermod.. NO
AFAIK MVS does not keep track of creation time.
The information requested can be obtained after the fact from the SMF 14/15
records.
HTH.
snip
For conventional MVS datasets, LISTCAT ... CREATION(n) gives me all datasets
with a creation date of n days ago.
Is there
I think the SMF records for non vsam is the only way to know time. The
time/date the SMF record was created should be close to the time/date the
dataset was created/touched.
I think for VSAM it is in the LISTC entry. I am not at work so I cannot
validate this statement.
Lizette
Of course, if you want date/time stamps the other option (not my favorite)
is to bury it in the DSN if you need real-time like information. If you
can wait for the SMF data, you can pull from there.
HLQ.Ttime.Ddate.etc
Or create a meta database in your app that when you create a dataset,
Thanks, all. Yeah, I know about putting a code into the name. There are of
course complications to doing that.
I really want something like LISTCAT so SMF is not the answer. I will
pursue other approaches.
(Yes, I should have said non-VSAM.)
Charles
-Original Message-
From: IBM
TSF (Total Storage Facility) from Estorian will provide that function.
On the other hand if you merely want to track the life of a dataset, DAF from
the CBT tape is a good option.
Thank You,
Dave O'Brien
NIH Contractor
From: Lizette Koehler
On Thu, 6 Jun 2013 11:59:13 -0400, Charles Mills wrote:
For conventional MVS datasets, LISTCAT ... CREATION(n) gives me all
datasets with a creation date of n days ago.
Is there any way -- not apparently with LISTCAT, but *any* way -- to get a
list of conventional datasets with a creation of n
I think all is local. Like race horses on January 1, all datasets appear to
have a birthday at midnight local. A dataset created at 23:59 is one day old at
00:01.
Charles
Composed on a mobile: please excuse my brevity
Paul Gilmartin paulgboul...@aim.com wrote:
On Thu, 6 Jun 2013 11:59:13
On 06/06/2013 12:06 PM, Paul Gilmartin wrote:
On Thu, 6 Jun 2013 11:59:13 -0400, Charles Mills wrote:
For conventional MVS datasets, LISTCAT ... CREATION(n) gives me all
datasets with a creation date of n days ago.
Is there any way -- not apparently with LISTCAT, but *any* way -- to get a
49 matches
Mail list logo
