> TOD1 will then have the decimal TOD in microseconds. On Sat, Feb 5, 2011 at 8:59 PM, michealbutz <[email protected]> wrote: > I had to add > > TOD1 = X2D(B2X(LEFT(X2B(C2X(RAWTOD)),52))) > > Since I got the data off the Evaluate command > > Just one question why shift left 12 bits > > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf > Of Hardee, > Charles H > Sent: Thursday, February 03, 2011 2:11 PM > To: [email protected] > Subject: Re: STCK vs TIMUSED > > No, you still need to have the seconds position at a minimum for a borrow. > You're really better off subtracting the two STCK values using either the > entire binary > number or, the remaining digits after taking off the right 12 bits. > > Assuming "addr" below points to where your TOD value is, and I believe you > said something > earlier about coming from an SVC dump, so I assume for the moment that you > are in IPCS: > > "EVAL "addr" LEN(8) HEX REXX(STO(RAWTOD))" > TOD1 = X2D(B2X(LEFT(X2B(RAWTOD),52))) > > TOD1 will then have the decimal TOD in microseconds. > > Do the same for the other field, then subtract the 2 values. The result will > be in > microseconds and borrowing will be accounted for. > > 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 Micheal > Butz > Sent: Thursday, February 03, 2011 1:00 PM > To: [email protected] > Subject: Re: STCK vs TIMUSED > > Edward Jaffes calculation about shifting bits seemed like something I > would do in Assembler > > Regardless if I subtracted a formated T > TOD which is 26 bytes and just look at the microseconds portion the > last 6 digits wouldn't that be accurate as well > > > Sent from my iPhone > > On Feb 3, 2011, at 1:42 PM, Tom Harper <[email protected]> wrote: > >> Michael, >> >> Your comment doesn't seem relevant to me. Even if it takes two >> microseconds, it can span a time boundary which you are not >> including. More puzzling to me is why don't you want to get your >> calculation correct? >> >> Tom Harper >> >> -----Original Message----- >> From: IBM Mainframe Discussion List [mailto:[email protected]] On >> Behalf Of Micheal Butz >> Sent: Thursday, February 03, 2011 12:39 PM >> To: [email protected] >> Subject: Re: STCK vs TIMUSED >> >> If the code that I marking either Wall or CPU takes longer than 1 >> second there is big trouble >> >> Sent from my iPhone >> >> On Feb 3, 2011, at 1:21 PM, Sam Siegel <[email protected]> wrote: >> >>> On Thu, Feb 3, 2011 at 10:11 AM, Micheal Butz <[email protected] >>>> wrote: >>> >>>> I am doing this in Rexx exec processing a SVC dump after calling >>>> BLSUXTOD. To convert the double word to a 26 character string I use >>>> the >>>> last 6 digits I understand I can bypass this conversion and just do >>>> the >>>> subtraction as you said on the double word regardless wouldn't the >>>> results >>>> be the same. ??? >>>> >>>> By using the right most digits there can be a situation where the >>>> end-time >>> appears to occur prior to the start-time. Consider the following: >>> >>> Start time: 1 999 998 >>> End time: 2 000 003 >>> >>> When all digits are considered, end-time is greater than start- >>> time. When >>> only 6 digits are considered, start-time appears to be greater than >>> end-time. >>> >>> To get an accurate time enough digits need to be used to ensure that >>> end-time is greater than start-time when doing the subtractions. >>> >>> Using all digits as Ed has suggested pretty much guarantees end-time >>> will be >>> great than start-time. >>> >>> >>> >>>> Sent from my iPhone >>>> >>>> On Feb 3, 2011, at 11:57 AM, Edward Jaffe <[email protected] >>>>> >>>> wrote: >>>> >>>> On 2/3/2011 8:41 AM, Micheal Butz wrote: >>>>> >>>>>> I do a substr to get the last 6 digits of the date/time. The >>>>>> microseconds >>>>>> portion. And substract. Value = after - before >>>>>> >>>>> >>>>> To subtract TOD values, use unsigned binary doubleword arithmetic. >>>>> If you >>>>> want resolution to microseconds, shift both doubleword values >>>>> right by 12 >>>>> bits before subtracting. >>>>> >>>>> -- >>>>> Edward E Jaffe >>>>> Phoenix Software International, Inc >>>>> 831 Parkview Drive North >>>>> El Segundo, CA 90245 >>>>> 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 > > ---------------------------------------------------------------------- > 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 > > ---------------------------------------------------------------------- > 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 >
-- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? ---------------------------------------------------------------------- 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
