Hold on a moment. Michael, you said you had to add C2X() to the statement. Are you using an EVALUATE command requesting the data be returned in character format? If so, are you using the UNFORMATTED operand as well?
I don't remember which release of z/OS and its related IPCS implemented it, but until the UNFORMATED operand was made available, the EVALUATE command translated all data from the dump, when requested in CHARACTER format, to have unprintable characters translated to periods to avoid printing problems. If you're EVALUATE command is not using the UNFORMATED option, then you will not get accurate values for your times. That is why I showed my EVALUATE command with the conversion expression: "EVAL "addr" LEN(8) HEX REXX(STO(RAWTOD))" Notice the HEX operand. Tony is very correct in that the expression can be shortened, but this would be the correct shortened expressions: TOD1 = X2D(LEFT(RAWTOD,13)) You would only need the C2X if you are requesting EVALUATE to return CHARACTER data instead of HEX, and that can be a problem unless you also are using the UNFORMATTED operand. Hope this helps. Tony, thanks for improving on the expression. Chuck Charles Hardee CA technologies Sr Sustaining Engineer Tel: +1-952-838-1039 [email protected] -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Tony Harminc Sent: Saturday, February 05, 2011 10:18 PM To: [email protected] Subject: Re: STCK vs TIMUSED On 5 February 2011 21:59, michealbutz <[email protected]> wrote: > I had to add > > TOD1 = X2D( B2X( LEFT( X2B( C2X(RAWTOD) ),52) ) ) Whew - that's a complicated expression. But let's come back to it. > Since I got the data off the Evaluate command > > Just one question why shift left 12 bits That's equivalent to a right shift - not a left one. The reason is that the TOD clock is defined such that bit position 51 (we number the leftmost bit 0, and the rightmost 63) is incremented every microsecond. So if you think of the clock as a number comprising 64 binary digits (bits), with an implied binary point to the right of bit 51, then the first digit to the left of the point counts microseconds (henceforth uS to keep it short), the next left counts 2 x uS, the next 4 x uS, and so on. The first digit to the right of the point counts uS/2, the next uS/4, and so on. If a decimal analogue helps, imagine that I tell you there is, say, a number comprising 10 decimal digits (we can call them dits), with an implied decimal point between dits 6 and 7, and that this number represents money. Then I could tell you that the first digit to the left of the point counts dollars, and you would immediately understand that the next left counts dollars x 10, the next counts dollars x 100, and so on, and that the first digit to the right of the point counts dimes, the next one right counts cents, and the next one counts tenths of cents or mills. On any given machine model the clock may count with greater or lesser precision, but the effect is as though bit 51 were incremented every uS, just as we might increment our money counter by dollars or cents or even by 100-dollar chunks, without changing the fact that dit position 6 represents dollars. For very many (doubtless most) practical purposes, measuring elapsed time to the uS is Good Enough, and it is quite a bit easier both conceptually and practically to do decimal integer arithmetic with whole uS, then with binary fractions of uS. Now as to your REXX expression... It seems correct, but you can make it shorter, more efficient, and easier to understand. Since you want to remove the rightmost 12 bits (i.e. keep the leftmost 52), and 12 just happens (heh) to be a multiple of 4, which is the number of bits represented by a hex digit, you can avoid the conversion to REXX binary and back, and remove the rightmost three hex digits instead. TOD1 = X2D( LEFT( C2X( RAWTOD ),13 ) ) 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 ---------------------------------------------------------------------- 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
