PK18077: ISSUING ASKTIME IN TWO CICS CONNECTED VIA MRO IN SAME MVS, THE SECOND CICS GENERATE A SMALLER ABSOLUTE TIME VALUE

Obtain the fix for this APAR.

APAR status

• Closed as program error.

Error description

• Cust has CICS1 and CICS2 connected thru MRO in the same MVS.
  Tx1 in CICS1 wil perform the following:-
        EXEC CICS ASKTIME ABSTIME (CUR-TIME1)
        EXEC CICS START (Tx2) from (CUR-TIME1)sysid
  ...
  Tx2 in CICS2 will issue another ASKTIME ABSTIME (CUR-TIME2)
  It is found that CUR-TIME2 is smaller than CUR-TIME1.  These pgm
  are written in high-level assembler.
  

Local fix

Problem summary

• ****************************************************************
  * USERS AFFECTED: All.                                         *
  ****************************************************************
  * PROBLEM DESCRIPTION: ABSTIME value of the EXEC CICS ASKTIME  *
  *                      can be wrong by 10 msecs.               *
  ****************************************************************
  * RECOMMENDATION:                                              *
  ****************************************************************
  Using two MRO connected CICS, in the first CICS a transaction
  issued an EXEC CICS ASKTIME command and passed the resulting
  ABSTIME value to a transaction running in the other CICS. The
  same command was issued and the ABSTIME value was compared with
  that passed to it. Occasionally, it was found that the later
  ASKTIME was returned a lower value in ABSTIME than that returned
  to the first ASKTIME.
  The ASKTIME ABSTIME calculation is performed in DFHEIDTI. It
  uses CSABASCL (base time in 4.096 msec units) and CSABASTU (base
  time of day in 3.333 msec units) to manipulate the result from
  the STCK instruction to determine the current local time of day.
  The RESET routine of DFHICP sets up CSABASCL and CSABASTU at
  CICS start up, midnight and when CEMT PERFORM RESET is used.
  CSABASCL is derived from a STCK instruction.
  CSABASTU is derived from the TIME TU macro.
  There is an inaccuracy when calculating these values. They
  should represent the same time but may not, depending upon the
  gap between the STCK and TIME TU and errors introduced when
  converting from 4.096 msec to 3.333 msec units.
  

Problem conclusion

• DFHTAJP has been changed to use new field CSABACL2 which is the
  last local midnight in 4.096 msec units.  For consistency
  reasons, the old fields CSABASCL and CSABASTU are still
  maintained.
  
  DFHEIDTI, DFHDSCSA and DFHICP have been changed to use CSABACL2
  instead of CSABASCL and CSABASTU at this release.
  
  In the CICS Transaction Server for z/OS R3V1 CICS Data Areas
  manual (LY33-6107-00), the existing field at offset 168 in the
  CSA Dsect (CSAPIEA) has been replaced by new field CSABACL2
  as follows:
  
  (168) FULLWORD  4 CSABACL2 BASE (LAST LOCAL MIDNIGHT) TOD CLOCK
                             VALUE(4.096 MILLISECONDS RESOLUTION)
  

Temporary fix

• FIX AVAILABLE BY PTF ONLY
  

Comments

APAR Information

• APAR is sysrouted FROM one or more of the following:

  PK11773

• APAR is sysrouted TO one or more of the following:

  UK14506

Modules/Macros

•    DFHCSAD  DFHCSAPS DFHDSCSA DFHEIDTI DFHICP
  DFHTAJP
  

Fix information

• Fixed component name

  CICSTS 3.1 Z/OS

• Fixed component ID

  5655M1500

Applicable component levels

• R400 PSY UK14506

     UP06/05/22 P F605

Fix is available

• Select the PTF appropriate for your component level. You will be required to sign in. Distribution on physical media is not available in all countries.