Re: Curious about IBM time conversion example program

2017-07-23 Thread Paul Gilmartin
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

Re: Curious about IBM time conversion example program

2017-07-23 Thread Tony Harminc
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

Re: Curious about IBM time conversion example program

2017-07-22 Thread Paul Gilmartin
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

Re: Curious about IBM time conversion example program

2017-07-22 Thread Joel C. Ewing
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?

Re: Curious about IBM time conversion example program

2017-07-20 Thread David Crayford
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:

Re: Curious about IBM time conversion example program

2017-07-20 Thread David Crayford
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

Re: Curious about IBM time conversion example program

2017-07-20 Thread Tony Harminc
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

Re: Curious about IBM time conversion example program

2017-07-20 Thread Paul Gilmartin
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

Re: Curious about IBM time conversion example program

2017-07-20 Thread Bill Godfrey
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

Re: Curious about IBM time conversion example program

2017-07-20 Thread Charles Mills
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

Re: Curious about IBM time conversion example program

2017-07-20 Thread Paul Gilmartin
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:

Re: Curious about IBM time conversion example program

2017-07-20 Thread Charles Mills
: 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

Re: Curious about IBM time conversion example program

2017-07-20 Thread Kirk Wolf
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

Re: Curious about IBM time conversion example program

2017-07-20 Thread Kirk Wolf
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

Re: Curious about IBM time conversion example program

2017-07-20 Thread Blaicher, Christopher Y.
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

Re: Curious about IBM time conversion example program

2017-07-20 Thread Kirk Wolf
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;//

Re: Curious about IBM time conversion example program

2017-07-20 Thread Charles Mills
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

Re: Curious about IBM time conversion example program

2017-07-20 Thread Tony Harminc
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

Re: Curious about IBM time conversion example program

2017-07-20 Thread Kirk Wolf
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

Re: Curious about IBM time conversion example program

2017-07-19 Thread Bill Godfrey
>-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

Re: Curious about IBM time conversion example program

2017-07-19 Thread Charles Mills
: 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

Re: Curious about IBM time conversion example program

2017-07-19 Thread Paul Gilmartin
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

Re: Curious about IBM time conversion example program

2017-07-19 Thread Steve Smith
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

Re: Curious about IBM time conversion example program

2017-07-18 Thread Bill Godfrey
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

Re: Curious about IBM time conversion example program

2017-07-18 Thread Kirk Wolf
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

Curious about IBM time conversion example program

2017-07-18 Thread 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