I using ICETOOL for an SMF report but am having difficulty getting the CPU TIME fields to display. The DATE and TIME fields print fine with the DT1 and TM1 mask respectively but I cannot get the remaining fields to print. I thought TC1 would be the right mask but I get 00:00:00.
Can someone help me please?
Regards,
Tim
HEADER('DATE') ON(1,4,DT1,E'9999-99-99') -
HEADER('TIME') ON(5,4,TM1,E'99:99:99') -
HEADER('TASK CPU TIME') ON(13,8,TC1,E'99:99:99') -
HEADER('DATABASE CPU TIME') ON(17,8,TC1,E'99:99:99') -
HEADER('NETWORK CPU TIME') ON(25,8,TC,E'99:99:99') -
HEADER('OTHER CPU TIME') ON(33,8,TC1,E'99:99:99') -
Here are the field definitions:
1 SMFHDATE PL4 DATE RECORD WAS WRITTEN (0CYYDDDF)
5 SMFHTIME BL4 TIME RECORD WAS WRITTEN (TIME BIN)
9 SMO2CLCP CL8 CLIENT TASK CPU TIME (TOD FORMAT)
17 SMO2DBCP CL8 DATABASE CPU TIME USED OUT OF TOTAL CPU TIME (SMO2CLCP)
25 SMO2NTCP CL8 NETWORK CPU TIME USED OUT OF TOTAL CPU TIME (SMO2CLCP)
33 SMO2OHCP CL8 OTHER CPU TIME USED OUT OF TOTAL CPU TIME (SMO2CLCP).
THIS IS CPUTIME NOT ASSOCIATED WITH ANY OTHER OPERATION.
Vendor manual explanation of its UNITS OF TIME format:
Quote:
SMF data is expressed in time-of-day (TOD) format, which is an unsigned 64-bit fixed point number where bit 51 is the equivalent to 1 microsecond. The TOD clock is a binary counter where the bit positions of the clock are numbered 0 to 63. This corresponds to the bit positions of a 64-bit unsigned binary integer.
In the basic form, the TOD clock is incremented by adding a 1 in bit position 51 every microsecond. In models with a higher or lower resolution, a different bit position is incremented at a frequency where 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.
Joined: 15 Feb 2005 Posts: 7129 Location: San Jose, CA
TC1 is the DFSORT format for displaying a proper TOD value as hhmmss. You have 13,8 instead of 9,8 and TC instead of TC1 for 25,8. If you clean this up to:
Code:
HEADER('DATE') ON(1,4,DT1,E'9999-99-99') -
HEADER('TIME') ON(5,4,TM1,E'99:99:99') -
HEADER('TASK CPU TIME') ON(9,8,TC1,E'99:99:99') -
HEADER('DATABASE CPU TIME') ON(17,8,TC1,E'99:99:99') -
HEADER('NETWORK CPU TIME') ON(25,8,TC1,E'99:99:99') -
HEADER('OTHER CPU TIME') ON(33,8,TC1,E'99:99:99')
all of the CPU times do come out to 00:00:00. So either these are not valid TOD values or all of the values are actually less than the minimum value displayed by TC1.
Interestingly, if I use TE4, E'99:99:99.99', which displays more precision, rather than TC1, I get the following CPU times:
Joined: 15 Feb 2005 Posts: 7129 Location: San Jose, CA
Tim,
For closure, I posted the following to your question about this in ibm-main:
Quote:
Despite the vendor documentation above, they state that these
particular time fields are in MSEC8 format.
MSEC8 FORMAT
00000000 2647041A = 0.156784 sec
METHOD 1
1) TREAT THIS AS BINARY INT CONVERT TO DECIMAL
2) / 4096 = NUMBER OF MICROSECONDS (6 DIGITS OVER TO GET SECONDS)
METHOD 2
1) SHIFT RIGHT 12 BITS or 3 hex digits (THIS IS DIVIDING BY 4096)
2) CONVERT AS BINARY INT TO DECIMAL (6 DIGITS OVER TO GET SECONDS)
Is there a way to do this conversion with ICETOOL/DFSort?
You can do the conversion with DFSORT by dividing by 4096. Then you can use an edit mask to convert to something like dddd.dddddd. For example:
You could do that in one pass if you use DFSORT's OUTFIL reporting features.
If you want to do it with DFSORT's ICETOOL DISPLAY, you can do a COPY with an INREC statement to divide each value by +4096. Then edit each resulting value, e.g. something like:
