Re: Subtracting TOD-CLOCK values to get duration.
Bit 51 in the TOD clock is the microsecond bit. Everything to the right of that is something less than a microsecond. If you have 64 bit register capability, just load one register with a TOD value, then another with the other TOD, and subtract to get the difference. You can then shift out everything beyond bit 51, and you have the number of microseconds. Leave it without the shift, and call STCKCONV, and it will give you the time value formatted in what you have specified on the call. Don't forget that the 8 byte TOD is unsigned, so bit zero is part of the value, not the sign. You will need to use the subtract logical form to get the right answer without playing bit-shifting games, even in a 64 bit register. CC -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Subtracting TOD-CLOCK values to get duration.
On Tue, 4 Sep 2007 09:44:55 -0400, Craddock, Chris wrote: Don't forget that the 8 byte TOD is unsigned, so bit zero is part of the value, not the sign. You will need to use the subtract logical form to get the right answer without playing bit-shifting games, even in a 64 bit register. o The sign bit of the TOD last changed in 1971; it next changes in 2042. Within the interior of that interval, either the logical or the algebraic form works. o Unless integer overflow is enabled in the program mask, or the programmer is concerned with the condition code, the logical and algebraic forms give identical results. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Subtracting TOD-CLOCK values to get duration.
Craddock, Chris wrote: Don't forget that the 8 byte TOD is unsigned, so bit zero is part of the value, not the sign. You will need to use the subtract logical form to get the right answer without playing bit-shifting games, even in a 64 bit register. Ummm. Remember, the only difference between logical and arithmetic binary add/subtract operations is the way the condition code is set (and lack of overflow interrupt for logical instructions -- which I almost never use) The bits in the register(s) -- including any so-called sign bit -- are treated *identically* in either case. (That's the beauty of representing negative numbers using two's complement form.) After the following code fragment runs, the contents of R0 R1 will be identical: STCK TOD L R0,TOD L R1,TOD S R0,=X'7FFF' SLR1,=X'7FFF' -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Subtracting TOD-CLOCK values to get duration.
On Sep 4, 2007, at 9:58 AM, Paul Gilmartin wrote: On Tue, 4 Sep 2007 09:44:55 -0400, Craddock, Chris wrote: Don't forget that the 8 byte TOD is unsigned, so bit zero is part of the value, not the sign. You will need to use the subtract logical form to get the right answer without playing bit-shifting games, even in a 64 bit register. o The sign bit of the TOD last changed in 1971; it next changes in 2042. Within the interior of that interval, either the logical or the algebraic form works. Gil, You bring up an interesting question (to me). I wonder if anyone did during the Y2K testing try a date later that 2042. Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Subtracting TOD-CLOCK values to get duration.
To go beyond 2042, you'd have to use the ETOD (128 bit) format, but even with that, it didn't work as of, maybe, z/OS 1.6, which is where I last tried it. I think it was the TIME macro that returned an error if I asked for an STCKE value for any year greater than 2042. --Art At 03:53 PM 9/4/2007, Ed Gould wrote: [...snip...] You bring up an interesting question (to me). I wonder if anyone did during the Y2K testing try a date later that 2042. == Art Celestini Celestini Development Services Phone: 201-670-1674Wyckoff, NJ = http://celestini.com = Mail sent to the From address used in this post will be rejected by our server. Please send off- list email to: ibmmainat-signcelestinidotcom. == -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Subtracting TOD-CLOCK values to get duration.
In a message dated 9/4/2007 3:31:06 P.M. Central Daylight Time, [EMAIL PROTECTED] writes: tried it. I think it was the TIME macro that returned an error if I asked for an STCKE value for any year greater than 2042. ?? Do any of the CLOCK simulators do it correctly? ** Get a sneak peek of the all-new AOL at http://discover.aol.com/memed/aolcom30tour -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Subtracting TOD-CLOCK values to get duration.
Ed Gould wrote: You bring up an interesting question (to me). I wonder if anyone did during the Y2K testing try a date later that 2042. STCKE/ETOD etc. are architected to allow TOD clock values beyond 2042. But, the TOD clock itself has not yet been extended on the left. Bit position 51 is still incremented every microsecond. See Timing - Time-of-Day Clock - Format in POP: [IBM Documentation] The TOD clock is a 104-bit register. It is a binary counter with the format shown in the following illustration. [nice picture snipped out for text-based post] The TOD clock nominally is incremented by adding a one in bit position 51 every microsecond.In models having a higher or lower resolution, a different bit position is incremented at such a frequency that the rate of advancing the clock is the same as if a one were added in bit position 51 every microsecond.The resolution of the TOD clock is such that the incrementing rate is comparable to the instruction-execution rate of the model. [/IBM Documentation] -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Subtracting TOD-CLOCK values to get duration.
I don't know about any clock simulators, Ed, but I went and found the code that was involved and it was the CONVTOD macro that accepted a maximum date of September 17, 2042. Ed Jaffe pointed out that the hardware does not yet support higher dates, but I might argue that the software (CONVTOD) still could, at least when using the STCKE/ETOD format. To support retention periods beyond what CONVTOD would allow, I had to write my own code which was based, somewhat, on the calendar conversion work of Peter Baum, which is documented at http://vsg.cape.com/~pbaum/index.htm. However, I only had to be accurate to a few minutes, so I didn't try to include support for leap seconds beyond 2042. At 04:37 PM 9/4/2007, Ed Finnell wrote: In a message dated 9/4/2007 3:31:06 P.M. Central Daylight Time, [EMAIL PROTECTED] writes: tried it. I think it was the TIME macro that returned an error if I asked for an STCKE value for any year greater than 2042. ?? Do any of the CLOCK simulators do it correctly? == Art Celestini Celestini Development Services Phone: 201-670-1674Wyckoff, NJ = http://celestini.com = Mail sent to the From address used in this post will be rejected by our server. Please send off- list email to: ibmmainat-signcelestinidotcom. == -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Subtracting TOD-CLOCK values to get duration.
On Tue, 4 Sep 2007 17:19:27 -0400, Art Celestini wrote: I don't know about any clock simulators, Ed, but I went and found the code that was involved and it was the CONVTOD macro that accepted a maximum date of September 17, 2042. Ed Jaffe pointed out that the hardware does not yet support higher dates, but I might argue that the software (CONVTOD) still could, at least when using the STCKE/ETOD format. Could. But how much foresight did systems show in anticipating Y2K? Would you expect preparation for Y2.042K 35 years in advance? And do we know how the hardware will employ the higher bits in the future? Of course, it's pretty hard (but not impossible) to verify the hardware limitation without waiting until 2042 to see whether it carries into the next bit. Hardware available at that time probably will. To support retention periods beyond what CONVTOD would allow, I had to write my own code which was based, somewhat, on the calendar conversion work of Peter Baum, which is documented at http://vsg.cape.com/~pbaum/index.htm. However, I only had to be accurate to a few minutes, so I didn't try to include support for leap seconds beyond 2042. Ummm. There's no way as of this writing that you can correctly account for leap seconds on or beyond January 31, 2008. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Subtracting TOD-CLOCK values to get duration.
On Tue, 4 Sep 2007 16:35:45 -0500, Paul Gilmartin [EMAIL PROTECTED] wrote: On Tue, 4 Sep 2007 17:19:27 -0400, Art Celestini wrote: I don't know about any clock simulators, Ed, but I went and found the code that was involved and it was the CONVTOD macro that accepted a maximum date of September 17, 2042. Ed Jaffe pointed out that the hardware does not yet support higher dates, but I might argue that the software (CONVTOD) still could, at least when using the STCKE/ETOD format. Could. But how much foresight did systems show in anticipating Y2K? Would you expect preparation for Y2.042K 35 years in advance? The TOD epoch was original 1960-01-01, and was changed to 1900 only later, doubtless because the 1960 base didn't allow for a sufficient range of dates in the past. If you overlook the failure to consider past dates, a clock with much better than microsecond resolution that wouldn't expire until 2102 doesn't seem to lack so much foresight. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Subtracting TOD-CLOCK values to get duration.
Paul Gilmartin wrote: On Tue, 4 Sep 2007 17:19:27 -0400, Art Celestini wrote: I don't know about any clock simulators, Ed, but I went and found the code that was involved and it was the CONVTOD macro that accepted a maximum date of September 17, 2042. Ed Jaffe pointed out that the hardware does not yet support higher dates, but I might argue that the software (CONVTOD) still could, at least when using the STCKE/ETOD format. Could. But how much foresight did systems show in anticipating Y2K? Would you expect preparation for Y2.042K 35 years in advance? And do we know how the hardware will employ the higher bits in the future? Ummm. For about the last decade, POP has stated the following: At some time in the future, new models will use a carry from bit position 0 of the TOD clock to increment an additional eight-bit binary counter. STORE CLOCK EXTENDED will store the contents of this counter in byte position 0 of its storage operand. A variation of SET CLOCK will set the counter, as well as the TOD clock. Variations of SET CLOCK COMPARATOR and STORE CLOCK COMPARATOR will manipulate a comparable byte at the left of the clock comparator. These actions will allow the TOD clock to continue to measure time within the standard epoch after the current 143-year limit caused by a carry from bit position 0 has been exceeded, and they will allow continued use of the clock comparator. It may be desired to have programs that process 16-byte STORE CLOCK EXTENDED operands take these future developments into account. -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Subtracting TOD-CLOCK values to get duration.
Indeed, Ed. I was about to point out that the STCKE *format* defines 8 more bits on the left -- enough to cover things through the year and beyond. Considering that the software was upgraded to support this long clock format, I was disappointed that it wasn't similarly updated to support those new high-order bits in its date/time conversions (and saving me from having to write the code myself). It seems to me that while the hardware may not yet use those bits, there's no reason why the software couldn't support them. At 06:14 PM 9/4/2007, Edward Jaffe wrote: Ummm. For about the last decade, POP has stated the following: At some time in the future, new models will use a carry from bit position 0 of the TOD clock to increment an additional eight-bit binary counter. STORE CLOCK EXTENDED will store the contents of this counter in byte position 0 of its storage operand. A variation of SET CLOCK will set the counter, as well as the TOD clock. Variations of SET CLOCK COMPARATOR and STORE CLOCK COMPARATOR will manipulate a comparable byte at the left of the clock comparator. These actions will allow the TOD clock to continue to measure time within the standard epoch after the current 143-year limit caused by a carry from bit position 0 has been exceeded, and they will allow continued use of the clock comparator. It may be desired to have programs that process 16-byte STORE CLOCK EXTENDED operands take these future developments into account. == Art Celestini Celestini Development Services Phone: 201-670-1674Wyckoff, NJ = http://celestini.com = Mail sent to the From address used in this post will be rejected by our server. Please send off- list email to: ibmmainat-signcelestinidotcom. == -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Subtracting TOD-CLOCK values to get duration.
Art Celestini wrote: Indeed, Ed. I was about to point out that the STCKE *format* defines 8 more bits on the left -- enough to cover things through the year and beyond. Considering that the software was upgraded to support this long clock format, I was disappointed that it wasn't similarly updated to support those new high-order bits in its date/time conversions (and saving me from having to write the code myself). It seems to me that while the hardware may not yet use those bits, there's no reason why the software couldn't support them. Since the long TOD design was delivered with 9672 G5 -- prior to z/Architecture and its new grande and N3 logical instructions but no *so* long before that they were unaware of the upcoming revolution -- the developers might have decided to wait until a richer, easier to use instruction set became available for dealing with such humongous numbers -- especially, since there wasn't any apparent immediate need for date processing beyond 2042. Given similar conditions, I probably would have done the same thing. -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Subtracting TOD-CLOCK values to get duration.
Ah, but then along came Sarbanes-Oxley which changed the rules for a lot of end users. There is at least one such compliant storage device out there that takes an expiration period in units of seconds -- and the field is 64 bits wide. Customers are actually looking for retention periods of 50 and 100 years to be enforced by the storage hardware. (Obviously, the data could never live in this one device for that long, but the manufacturer has convinced customers that there will be a migration path down the road and that all of the metadata like retention period will migrate along with the data in a secure way.) I wasn't surprised that CONVTOD didn't support dates beyond 2042; it would have just saved me a lot of work if it had. I understand the reasoning that the developers likely went through, as you suggest, and I too would have probably came to the same decision given the same circumstances. At 07:04 PM 9/4/2007, Edward Jaffe wrote: Since the long TOD design was delivered with 9672 G5 -- prior to z/Architecture and its new grande and N3 logical instructions but no *so* long before that they were unaware of the upcoming revolution -- the developers might have decided to wait until a richer, easier to use instruction set became available for dealing with such humongous numbers -- especially, since there wasn't any apparent immediate need for date processing beyond 2042. Given similar conditions, I probably would have done the same thing. == Art Celestini Celestini Development Services Phone: 201-670-1674Wyckoff, NJ = http://celestini.com = Mail sent to the From address used in this post will be rejected by our server. Please send off- list email to: ibmmainat-signcelestinidotcom. == -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Subtracting TOD-CLOCK values to get duration.
Hi, I need to subtract two TOD times to find elapsed time. Currently I convert the two TOD times with STCKCONV and determine the elaped time individually, and then compute the difference. This works. However I thought I could optimize the conversion, a little bit and I was wondering why not subtract the two TOD times to begin with. As I understand TOD time is the number of mic seconds elapsed since midnight of 1900-01-01. So when I subtract one TOD value from another the duration must be in micro seconds. For example, TOD1 is X'C0E608EF7409002E' ===2007196, 16.59.58,745744 TOD2 is X'C1E608EF7409002E' 2008035, 7.43.04.790160 If I subtract the two TOD values, it is binary as in (x'0100'). If I convert to a packed decimal value, I get a decimal value of 72057594037927936. (sign bit not shown here) Now I can't seem to figure the actual elapsed time based on the derived micro seconds. If I just treat the above value as a mic seconds then I end up with 2284.93 years which is gloriously incorrect while the actual elapsed days are 204 days ignoring the time part. I am sure I am missing something here. Can someone please help. Regards, Ludmil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Subtracting TOD-CLOCK values to get duration.
In a message dated 9/3/2007 6:38:18 P.M. Central Daylight Time, [EMAIL PROTECTED] writes: As I understand TOD time is the number of mic seconds elapsed since midnight of 1900-01-01. Partially correct. Bit 51 of the 64-bit TOD clock is the number of microseconds since... etc. But there are 12 more bits to the right of bit 51, so the right-most bit of the 8-byte TOD clock is 4096 times the number of microseconds since... etc. So when I subtract one TOD value from another the duration must be in micro seconds. For example, TOD1 is X'C0E608EF7409002E' ===2007196, 16.59.58,745744 TOD2 is X'C1E608EF7409002E' 2008035, 7.43.04.790160 If I subtract the two TOD values, it is binary as in (x'0100'). If I convert to a packed decimal value, I get a decimal value of 72057594037927936. (sign bit not shown here) Now I can't seem to figure the actual elapsed time based on the derived micro seconds. If I just treat the above value as a mic seconds then I end up with 2284.93 years which is gloriously incorrect while the actual elapsed days are 204 days ignoring the time part. Divide that decimal number by 4096, and you will have the number of microseconds in the interval. Since your original interval in hexadecimal (what you call binary) ends in a long string of zeroes, a simple, exact way to divide by 4096 is to remove the right-most three zeroes. And since one million microseconds = one second, and since one million is very close to two to the 20th power (or 16 to the 5th), you can approximate the number of seconds in the interval by removing 5 more of the right-most zeroes (each zero = another power of 16). This is probably not accurate enough for your real work, but it will give you a quick reality check on your math. After removing a total of eight zeroes from the right end, you are left with X'0100', which is the number of microseconds in your interval. This is equal to ca. 16 million seconds (I am rounding off some more), which is ca. 185.2 days. After all the rounding off I did, I claim that my math passes my reality check. Do it all again with no rounding and you should get your answer of 204 days. Bill Fairchild Plainfield, IL ** Get a sneak peek of the all-new AOL at http://discover.aol.com/memed/aolcom30tour -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Subtracting TOD-CLOCK values to get duration.
Ludmila, Bit 51 in the TOD clock is the microsecond bit. Everything to the right of that is something less than a microsecond. If you have 64 bit register capability, just load one register with a TOD value, then another with the other TOD, and subtract to get the difference. You can then shift out everything beyond bit 51, and you have the number of microseconds. Leave it without the shift, and call STCKCONV, and it will give you the time value formatted in what you have specified on the call. --Dave Day - Original Message - From: Ludmila Koganer [EMAIL PROTECTED] Newsgroups: bit.listserv.ibm-main To: IBM-MAIN@BAMA.UA.EDU Sent: Monday, September 03, 2007 6:38 PM Subject: Subtracting TOD-CLOCK values to get duration. Hi, I need to subtract two TOD times to find elapsed time. Currently I convert the two TOD times with STCKCONV and determine the elaped time individually, and then compute the difference. This works. However I thought I could optimize the conversion, a little bit and I was wondering why not subtract the two TOD times to begin with. As I understand TOD time is the number of mic seconds elapsed since midnight of 1900-01-01. So when I subtract one TOD value from another the duration must be in micro seconds. For example, TOD1 is X'C0E608EF7409002E' ===2007196, 16.59.58,745744 TOD2 is X'C1E608EF7409002E' 2008035, 7.43.04.790160 If I subtract the two TOD values, it is binary as in (x'0100'). If I convert to a packed decimal value, I get a decimal value of 72057594037927936. (sign bit not shown here) Now I can't seem to figure the actual elapsed time based on the derived micro seconds. If I just treat the above value as a mic seconds then I end up with 2284.93 years which is gloriously incorrect while the actual elapsed days are 204 days ignoring the time part. I am sure I am missing something here. Can someone please help. Regards, Ludmil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
