In
,
on 06/07/2013
at 02:58 PM, John Gilmore 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 who engages in spelling flames to confuse a noun
with an adjective; it is even more q
> 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 lists...@listserv.ua.e
:>: -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
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"
Subject: Re: Age of datasets in hours, not days?
The rotation is not con
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 23
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
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: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
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
Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of John Gilmore
> Sent: Friday, June 07, 2013 4:25 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Age of datasets in hours, not days?
>
> Julian-calendar leap years are defined very simply as those that have
> serial
the axis slowly traces out a cone."
-- http://en.wikipedia.org/wiki/Precession#Astronomy
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of John Gilmore
Sent: Friday, June 07, 2013 4:25 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject:
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 unsatisfactor
[mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Paul Gilmartin
Sent: Friday, June 07, 2013 4:04 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Age of datasets in hours, not days?
On Fri, 7 Jun 2013 15:28:21 -0700, Charles Mills wrote:
>The rotation is not constant, and is "too slow." It takes (
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 granula
al Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Tom Marchant
Sent: Friday, June 07, 2013 2:33 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Age of datasets in hours, not days?
On Fri, 7 Jun 2013 14:58:01 -0400, John Gilmore wrote:
>Precession v
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.
On 06/07/2013 09:05 AM, Paul Gilmartin wrote:
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
care
Steve,
Thank you for that elucidation of 'Splain'. I am old enough, but I
just did not watch ILL.
John Gilmore, Ashland, MA 01721 - USA
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@l
From: John Gilmore
Date: 06/07/2013 02:58 PM
'Splain' is presumably subliterate folksy for 'Explain', but there
does not seem to me to be anything to much to explain.
I have not been following this particular thread much because I get tired
of certain arguments.
Meanwhile, if I under
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
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.
The basic sequence, reference standard, is TAI. UTC is a derived quantity.
The alignment of civil dates with the seasons is a desideratum.
Precession very gradual
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
dete
In <51b2083c.3060...@phoenixsoftware.com>, on 06/07/2013
at 09:20 AM, Ed Jaffe 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.) Metz, SysProg and JOAT
Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of John Gilmore
Sent: Friday, June 07, 2013 11:53 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Age of datasets in hours, not days?
Barry Merrill wrote:
| One timestamp and the GMT offset takes less space and
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:
http://datacenter.iers.org/somos/rest/document/body/tx13iers.
Barry Merrill wrote:
| One timestamp and the GMT offset takes
| less space and is IMO all that is needed.
but Edward Jaffe is correct; unless that offset is supplemented by a
database of historical and current information about locale-specific
daylight-saving/summer/official/... time in-effect in
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
-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Ed Jaffe
Sent: Friday, June 07, 2013 11:20 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Age of datasets in hours, not days?
On 6/7/2013 5:29 AM, John McKown wrote:
> IMO, if IBM were to store the creation date &am
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 N
:>: -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
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 g
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 too
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 wrote
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 af
07, 2013 16:05
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Age of datasets in hours, not days?
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
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 s
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 particul
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 do
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
-
day, June 07, 2013 14:10
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: 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 us
.UA.EDU
Subject: 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 it as *un-signed*
value.
There must
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
w
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 thu
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
>*
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
*
: Thursday, June 06, 2013 18:38
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Age of datasets in hours, not days?
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 a
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
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 wrote:
>On Thu, 6 Jun 2013 11:59:13 -0400, Charles Mills w
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 creatio
stars...@mindspring.com]
Sent: Thursday, June 06, 2013 12:22 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Age of datasets in hours, not days?
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 fo
riginal Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Lizette Koehler
Sent: Thursday, June 06, 2013 12:23 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Age of datasets in hours, not days?
Of course, if you want date/time stamps the other option (not
@LISTSERV.UA.EDU
Subject: Re: Age of datasets in hours, not days?
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
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Charles Mills
Sent: Thursday, June 06, 2013 8:59 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Age of datasets in hours, not days?
For conventional "MVS" datasets, LISTCAT ... CREATION(n) gi
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.
For conventional "MVS" datasets, LISTCAT ... CREATION(n) gives me all datasets
with a creation date of "n" days ago.
Is there a
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" *hours* ago? Does MVS
keep the time of creation, or o
55 matches
Mail list logo
