Good point. A Unix EPOC time value is a signed integer, relative to midnight Jan 1, 1970. So STCK values between 1900 and 1970 would be negative after subtracting the 1900-1970 offset value, and a SRDL instruction would not be appropriate.
Kirk Wolf Dovetailed Technologies http://dovetail.com On Thu, Jul 20, 2017 at 3:57 PM, Blaicher, Christopher Y. < [email protected]> wrote: > 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 > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
