10. MODIFICATION › 10.3 Program Modifications to the Assembler Routines › 10.3.2 CPU Time Validation Modifications

10.3.2 CPU Time Validation Modifications

 
 There are several IMS product maintenance issues that cause
 the CPU time field (DLRTIME) of the IMS log type 7 record to
 become corrupted.  It is possible to cause CA MICS processing
 to ignore these corrupted values by modifying the appropriate
 Log Data Reduction (LDR) processing routines (listed in
 section 10.3).
 
 Note: None of the material in this section applies to
 processing CA MICS IMS data collected by BMC MAINVIEW for IMS
 Online Event Collector.  Also, none of the material here
 discusses the specifics of IBM IMS APARs or maintenance that
 explains or cures the problems with CPU time measurements.
 Consult INFO/MVS or IBMLINK for authorized information on
 these specifics.
 
 
 DLRTIME FIELD CORRUPTION
 
 DLRTIME is a fullword value of CPU time at offset X'18' in
 the type 7 IMS log record.  The value is given in timer units
 where, for example:
 
     X'00000001' = .00002604166667 seconds
     X'10000000' =  6990.5067 seconds =  1:56:30.51 (hhmmssth)
     X'40000000' = 27962.0267 seconds =  7:46:02.03
     X'4FFFFFFF' = 34951.6385 seconds =  9:42:31.63
     X'C0000000' = 83886.08   seconds = 23:18:06.08
     X'F0000000' = 104K       seconds = 29:07:37.60
 
 Although several problems have been reported with CPU time
 measures, the contents of the DLRTIME field typically become
 corrupted in one of the following two ways.
 
 First, DLRTIME may contain a value in the spectrum of 24
 hours, due to confused use of STIMER/TTIMER.  In this case,
 DLRTIME will have a value greater than X'C0000000'.
 
 Second, DLRTIME's collection area may be overlaid (this is
 regardless of the bit flags defined by IBM in the high order
 byte).  Types of collection area overlays that have been
 observed include, but are not limited to, the Transaction
 Code or PSB Name due to a problem in Automated Operator
 Initiation or other processing routines.  In this case, the
 contents of DLRTIME will be determined by the names given to
 transactions and PSBs at your site.
 
 o  If these names can be less than five bytes long, DLRTIME
    will contain X'40404040'.
 
 o  If the names are always five bytes long or more, DLRTIME
    may contain the EBCDIC value of characters 5-8 of the
    name.  For example, transaction name "AZP142" overlaid
    into DLRTIME will produce a DLRTIME value of X'F4F24040'.
 
 DLRTIME is defined as a signed algebraic data item,
 therefore, the value of the field cannot exceed X'4FFFFFFF'.
 
 The object of modifying the LDR program is to correct
 DLRTIME before bad values get into the CA MICS IMS database.
 Usually, this means setting DLRTIME to zero because an
 algorithm to find the real CPU time used is not available.
 
 Determine the possible contents of the corrupted DLRTIME
 field from IBM APARs or by examining the records.  Also,
 determine the maximum reasonable DLRTIME value that could
 represent actual data.  It is safe to set DLRTIME to zero if
 both of these are true:
 
 o  if DLRTIME takes a value greater than X'40000000'
 
 o  if it is reasonable to assume that no properly operating
    IMS MPP or BMP could use more than 7 hours and 46 minutes
    of CPU time during a single schedule
 
 Such a reasonableness test may depend on your site's use of a
 multi-engine CPU complex.  It would hardly be expected that
 small, single-threaded inquiry transactions would exceed 7
 hours of CPU time in a schedule.  However, a multitasking
 stress analysis program running under IMS may keep two or
 more processors very busy, especially considering the length
 of a schedule or BMP execution.
 
 
 MODIFICATIONS FOR CPU TIME ADJUSTMENT
 
 You can insert logic to examine criteria for recognizing
 corrupted contents of the DLRTIME field and to set the CPU
 time value CA MICS accepts for the transaction into the LDR
 program(s).  It is not always practical to test the validity
 of data in the DLRTIME field in any SAS logic after a LDR
 program (listed in section 10.3) has apportioned CPU time
 over all transactions in a schedule.
 
 Before making modifications, follow these steps:
 
 1.  Make a complete record of your modifications.
 
 2.  Copy the program code from sharedprefix.MICS.ASM to
     sharedprefix.MICS.LOCALMOD.CNTL to save an original copy
     of the logic.
 
 3.  Review any further CA MICS IMS maintenance for changes to
     the LDR program(s) that may interfere with these
     modifications.  Resolve any line collision issues with
     help from CA Technical Support.
 
 The CPU time validation criteria check is located by browsing
 the LDR program(s) and finding the character string
 CPUVALIDATION.  The check is of the form:
 
 *       CLI   LOG07CPU,X'80'      CHECK FOR BAD CPU TIME
 *       BL    CPUOK               CPU TIME PROBABLY NOT BAD
         MVC   LOG07CPU,=F'0'      ZERO OUT BAD CPU TIME
 
 Examining and resetting CPU time can be modified.  Reset the
 CPU time saved in the apportionment staging variable LOG07CPU
 to the value intended if your conditions are met.
 
 
 o  Example 1:  Enable the check by un-commenting the lines.
 
       CLI   LOG07CPU,X'80'      CHECK FOR BAD CPU TIME
       BL    CPUOK               CPU TIME PROBABLY NOT BAD
       MVC   LOG07CPU,=F'0'      ZERO OUT BAD CPU TIME
 
 o  Example 2:  Set CPU time to 1 timer unit if the DLRTIME
                field is larger than X'40000000':
 
        CLC   LOG07CPU,=A(X'40000000')
        BL    CPUOK
        MVC   LOG07CPU,=F'1'
 
 After modifying the LDR program(s), reassemble using the
 CA MICS IMSASM job.