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-3803 E: [email protected] Syncsort Incorporated 2 Blue Hill Plaza #1563 Pearl River, NY 10965 www.syncsort.com Data quality leader Trillium Software is now a part of Syncsort. -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Kirk Wolf Sent: Thursday, July 20, 2017 4:53 PM To: [email protected] Subject: Re: Curious about IBM time conversion example program X'7A120000' 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: 0x7D91048BCA000000L long epoc_secs = stck / SECS_PER_TOD_UNIT; // 0x1000 * 1000000; or in assembler I think it would be: LG R3,STCK SG R3,TOD_EPOC_OFF XL8'7D91048BCA000000' DSG R2,SECS_PER_TOD_UNIT FD'4096000000' STG R3,EPOC_SECS Kirk Wolf Dovetailed Technologies http://dovetail.com On Thu, Jul 20, 2017 at 3:10 PM, Tony Harminc <[email protected]> wrote: > On 20 July 2017 at 13:11, Kirk Wolf <[email protected]> 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 comments. > The the notion of "seconds per tod unit" is an odd one. This is a very > small number (about 0.000000000244140625), and it makes little sense > to be dividing anything by it. And certainly the constant EPOCST DC > X'7A120000' > isn't it. > > This is code I wrote in 1999 to do this. I must also admit I had not > considered that the Unix representation was signed, and so it > doubtless produces incorrect output for input dates between 2038 and > 2042. But of course any code does so by definition, so it's a matter > of which failure mode you prefer. > > I like to think this is easy to read and understand. I think of the > algorithm this way: > > Convert the TOD value into microseconds since Jan 1 1900. Why? Because > it's trivial and fast, it well fits the architected definition of the > TOD clock (bit 51 - 1 uS), and it guarantees that this intermediate > value does not have its high bit on. > > Subtract the (constant) difference in microseconds between Jan 1 1900 > and Jan 1 1970. I hand calculated this by thinking (70 years * 365 > days/year = > 25550 days, + (70/4)-1 [-1 because 1900 was not a leap year] = 16 leap > days > ) = 25566 days ) * 1440 min/day *60 seconds/minute = 2208902400 > seconds * > 1000000 = 2208902400000000 microseconds. I hope I was right... > > So here's my old code: > STCK WORK_DWORD > LM R14,R15,WORK_DWORD TOD CLOCK UNITS > SRDL R14,12 MICROSECONDS SINCE JAN 1, 1900 > SL R15,=FL8'2208902400000000'+4 - RIGHT HALF > BC 11,*+6 BRANCH ON NO BORROW > BCTR R14,R0 -1 FOR BORROW > SL R14,=FL8'2208902400000000' - LEFT HALF > D R14,=F'1000000' SECONDS SINCE JAN 1, 1970 > > As others have pointed out, using the 32-bit registers and checking > for borrow would be strange for code written in 2017, but of course it > still works. Using a G register with the appropriate G Load, Shift, > and Subtract would eliminate 3 instructions. > > > - good assembler programmer > > - XLC/C++ compiler > > - IBM sample code in a manual > > - bad assembler programmer > > Heh - a colleague is writing his first ever, very simple, TSO command. > The "IBM sample code in a manual" has meant it's taken him about a > week more than it should've. > > Tony H. > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, send > email to [email protected] with the message: INFO IBM-MAIN > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN ________________________________ ATTENTION: ----- The information contained in this message (including any files transmitted with this message) may contain proprietary, trade secret or other confidential and/or legally privileged information. Any pricing information contained in this message or in any files transmitted with this message is always confidential and cannot be shared with any third parties without prior written approval from Syncsort. This message is intended to be read only by the individual or entity to whom it is addressed or by their designee. If the reader of this message is not the intended recipient, you are on notice that any use, disclosure, copying or distribution of this message, in any form, is strictly prohibited. If you have received this message in error, please immediately notify the sender and/or Syncsort and destroy all copies of this message in your possession, custody or control. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
