On Sun, 23 Jul 2017 21:21:43 -0400, Tony Harminc wrote:
>On 22 July 2017 at 14:08, Paul Gilmartin
><000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
>
>> How many digits for the year? Geologists routinely discuss 45 BCE;
>> astrophysicists 137 BCE; cosmologists ponder
On 22 July 2017 at 14:08, Paul Gilmartin
<000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
> How many digits for the year? Geologists routinely discuss 45 BCE;
> astrophysicists 137 BCE; cosmologists ponder 10**100 CE. Does
> this argue for a variable-length format?\
More
On Sat, 22 Jul 2017 08:45:31 -0500, Joel C. Ewing wrote:
>
>But arguing that the z-architecture clock format should support dates
>prior to 1900 CE implies that storing date-time values in a
>machine-specific time-stamp format would be desirable.
>
Doesn't the same argument apply to dates after
On 07/20/2017 10:04 PM, Paul Gilmartin wrote:
> On Thu, 20 Jul 2017 16:58:11 -0700, Charles Mills wrote:
>
>> Far be it from me to try to interpret the POSIX standards. It's definitely
>> signed on z/OS.
>>
>> typedef long time_t;
>>
>> Why waste a bit if you are not going to support negative?
On 21/07/2017 6:43 AM, Paul Gilmartin wrote:
On Thu, 20 Jul 2017 14:33:58 -0700, Charles Mills wrote:
Yes, negative UNIX times are legal and generally work.
I had understood that negative time_t values are illegal but generally work.
The closest I can find in POSIX is:
On 21/07/2017 1:11 AM, Kirk Wolf wrote:
As usual, the knowledge and helpfulness of those on this list is
astonishing.
I'm actually writing this in Java (to 64-bit java "long" epoch seconds,
from both STCK and STCKE inputs), but the sample IBM assembler code
initially puzzled me.
I had to do
On 20 July 2017 at 22:13, Bill Godfrey wrote:
> There are 17 leap days from 1900 to 1970, not 16. Just write them out
> starting at 1904, 1908... and count them.
>
> That would make the results one day later than they should be.
>
Dang... Obi-Wan error. I just tried it on
On Thu, 20 Jul 2017 16:58:11 -0700, Charles Mills wrote:
>Far be it from me to try to interpret the POSIX standards. It's definitely
>signed on z/OS.
>
>typedef long time_t;
>
>Why waste a bit if you are not going to support negative? Making it unsigned
>would have put off the Year 2038
There are 17 leap days from 1900 to 1970, not 16. Just write them out starting
at 1904, 1908... and count them.
That would make the results one day later than they should be.
The microseconds value should be 22089888, which in hex is
7d91048bca000, and after shifting that 12 bits to
On Behalf
Of Paul Gilmartin
Sent: Thursday, July 20, 2017 3:43 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Curious about IBM time conversion example program
On Thu, 20 Jul 2017 14:33:58 -0700, Charles Mills wrote:
>Yes, negative UNIX times are legal and generally work.
>
I had understo
On Thu, 20 Jul 2017 14:33:58 -0700, Charles Mills wrote:
>Yes, negative UNIX times are legal and generally work.
>
I had understood that negative time_t values are illegal but generally work.
The closest I can find in POSIX is:
: Curious about IBM time conversion example program
Not following all this too closely, but if UNIX is a signed value, can it go
prior to 1900 and that is why they did math rather than shifting?
Just a question.
Chris Blaicher
Technical Architect
Mainframe Development
P: 201-930-8234 | M: 512-627
f Syncsort.
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Kirk Wolf
> Sent: Thursday, July 20, 2017 4:53 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Curious about IBM time conversion example prog
Right Charles. SECS_PER_TOD_UNIT is an bad (inverted) name.
Kirk Wolf
Dovetailed Technologies
http://dovetail.com
On Thu, Jul 20, 2017 at 3:53 PM, Kirk Wolf wrote:
> X'7A12' is 1 million * 4096 / 2.
>
> There are 0x1000 TOD units in a microsecond; 1 million * 0x1000 in
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Curious about IBM time conversion example program
X'7A12' is 1 million * 4096 / 2.
There are 0x1000 TOD units in a microsecond; 1 million * 0x1000 in a second.
So if you use 64 bit arithmetic, there is nothing wrong with:
stck -= TOD_EPOC_OFFSET; // 1900
X'7A12' is 1 million * 4096 / 2.
There are 0x1000 TOD units in a microsecond; 1 million * 0x1000 in a second.
So if you use 64 bit arithmetic, there is nothing wrong with:
stck -= TOD_EPOC_OFFSET; // 1900 to 1970 offset: 0x7D91048BCA00L
long epoc_secs = stck / SECS_PER_TOD_UNIT;//
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Curious about IBM time conversion example program
On 20 July 2017 at 13:11, Kirk Wolf <k...@dovetail.com> wrote:
> I'm actually writing this in Java (to 64-bit java "long" epoch
> seconds, from both STCK and STCKE inputs), but the s
On 20 July 2017 at 13:11, Kirk Wolf wrote:
> I'm actually writing this in Java (to 64-bit java "long" epoch seconds,
> from both STCK and STCKE inputs), but the sample IBM assembler code
> initially puzzled me.
I must admit I remain confused by both the sample code and its
As usual, the knowledge and helpfulness of those on this list is
astonishing.
I'm actually writing this in Java (to 64-bit java "long" epoch seconds,
from both STCK and STCKE inputs), but the sample IBM assembler code
initially puzzled me.
Kirk Wolf
Dovetailed Technologies
http://dovetail.com
>-Original Message-
>From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
>Behalf Of Steve Smith
>Sent: Wednesday, July 19, 2017 2:59 PM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: Re: Curious about IBM time conversion example program
>
>Bill's suggesti
: Wednesday, July 19, 2017 2:59 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Curious about IBM time conversion example program
Bill's suggestion is a vast improvement. But I can't understand why IBM
publishes examples that seem to be written (by a student) for System/360.
Not to mention that actually
On Wed, 19 Jul 2017 17:58:47 -0400, Steve Smith wrote:
>Bill's suggestion is a vast improvement. But I can't understand why IBM
>publishes examples that seem to be written (by a student) for System/360.
>Not to mention that actually dividing by 2 was naive even then.
>
That's what I was
Bill's suggestion is a vast improvement. But I can't understand why IBM
publishes examples that seem to be written (by a student) for System/360.
Not to mention that actually dividing by 2 was naive even then.
Convert the code to use this new thing, 64-bit registers, and you'll need
half the
The number of seconds per TOD unit is too large to be represented in a signed
fullword, but half the number of seconds is not too large.
So they break the computation into 2 divides.
When the STCK value is hex ba9a048bca00 (January 10 2004 13:37:05) or
larger, the value after subtracting
Oh I get it now - Unix epoch second times are 32 bit *signed* integers.
So, they are doing SLR 14,14 prior to dividing by two to truncate at a
(signed) 31-bit integer.
0x7FFF is Jan 19, 2038 (UTC), the latest time that can be represented
as a 32-bit signed integer seconds.
Kirk Wolf
Dear ibm-mainers,
I have a need to do something like this example:
https://www.ibm.com/support/knowledgecenter/SSLTBW_1.13.0/com.ibm.zos.r13.bpxb500/bpxzb5c076.htm
I'm curious about one part - perhaps I am missing something in the details
of the code. I would appreciate any insight.
This
26 matches
Mail list logo