PK37962: UPDATE DATA APPLIED OUT OF SEQUENCE BY DPROP MQ-ASYNC

APAR status

• Closed as program error.

Error description

• We are testing IMS to IMS replication using DPROP MQ Async.
  We found that update segment data was applied out of sequence.
  ----------------------------------------------------------------
  Case-1: DEDB case
  < PST1 >                     < PST2 >
    GHU/REPL to update CI (A)
     (hold CI lock)
    SYNC
      5950
      5937
      . ---/                   GHU call to same segment in same CI
      .   /-> OTHREAD             ( waiting on CI lock )
      .         release CI locks --->
      delay before DPROP SYNC PH2 ( CI lock request was resumed )
      .                        REPL to update same segment (B)
      .                          SYNC
      .                            5950
      .                            5937
      .                              --//--> OTHREAD
      .                            DPROP SYNC PH2 --> B applied
      .                            ....
      DPROP SYNC PH2 --> A applied after B !
  ----------------------------------------------------------------
  In this IMS, above segment in source DB has 'B'.
  But target DB in other IMS has 'A' in same segment.
  If we delay scheduling of OTHREAD after DPROP SYNC PH2 completed
  then we will be able to bypass this problem.
  Same situation can happen in Full Function DB too.
  ----------------------------------------------------------------
  Case-2: Full Function DB case
  < PST1 >                     < PST2 >
    GHU/REPL to segment (A)
     (hold locks)
    SYNC                       GHU call to same segment
      PH1                         ( waiting on locks)
      PH2
       37 log
       ->DFSFXC50 (release all locks) -->
      delay before DPROP SYNC PH2 ( lock request was resumed )
      .                        REPL to update same segment (B)
      .                        SYNC
      .                          37 log
      .                          ->DFSFXC50 (release all locks)
      .                          DPROP SYNC PH2 --> B applied
      .
      DPROP SYNC PH2 --> A applied after B !
  ----------------------------------------------------------------
  if we move release lock after DPROP SYNC PH2 has completed,
  we will be able to bypass this problem.
  

Local fix

Problem summary

• ****************************************************************
  * USERS AFFECTED: Users of IMSFP R910 DEDBs using DPROP        *
  *                 MQ Async.                                    *
  ****************************************************************
  * PROBLEM DESCRIPTION: Update segment data was applied out     *
  *                      of sequence by DPROP MQ-Async causing   *
  *                      database integrity failure.             *
  ****************************************************************
  * RECOMMENDATION: INSTALL CORRECTIVE SERVICE FOR APAR/PTF      *
  ****************************************************************
  Phase 2 process for RMs(Resource managers :IMS DB,MQ) are
  executed independently causing a potential timing hole for
  UPDATE data to be applied out of order.
  Currently DB CI locks are released in Phase 2 IMS OTHREAD
  processing. This exposes possible DB integrity failures
  in the case of MQ executing asynchronously with IMS.
  Holding the DB CI lock until the completion of the Phase
  2 commit process of MQ would bypass this integrity exposure.
  This means IMS DEDB OTHREAD processing should not be scheduled
  until DPROP SYNC PH2 completes.
  

Problem conclusion

• AIDS: RIDS/FP RIDS/CNTRL FP CNTRL
    DEP: NONE
    GEN:
  
  *** END IMS KEYWORDS ***
  OTHREAD processing is now delayed until MQ Phase 2 completes.
  The database lock is held until the completion of Phase 2
  commit process of MQ. Incoming transactions for the same CI
  are suspended by the DB lock preventing database integrity
  exposure.
  
  Code has been added to the following modules/macro to
  facilitate proper timing of UPDATE data for DPROP:
  
  
  DBFEPST  - A flag is defined in the EPST that shows there is
             data for DPROP. Also, an area is defined to save
             the DMHR chain for OTHREAD processing.
  
  DBFDCAP0 - Turns on the flag when a DL/I Call is issued
             against a DEDB.
  
  DBFSLG20 - Checks for SYNC Phase-2 complete and the flag is
             ON showing data for DPROP. If so, the DMHR Chain
             for OTHREAD is removed from the 5937 log and is
             saved at EPSTAWE0. The flag is cleared upon exit
             from DBFSLG20.
  
  DFSFESP0 - If a DMHR is saved at EPSTWAEO, an OTHREAD AWE is
             scheduled. If Pseudo abend occurs when there is a
             DMHR at EPSTWAE0, OTHREAD is not scheduled. The IMS
             CTL region will U0113 ABEND later.
  
  DBFATRM0 - If the dependent region terminates abnormally when
             the DMHR is saved in the EPSTAWE0, the IMS CTL
             region will U0113 ABEND.
  

Temporary fix

• *********
  * HIPER *
  *********
  

Comments

APAR Information

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

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

  PK41368 UK23042

Modules/Macros

• DBFATRM0 DBFDCAP0 DBFEPST  DBFSLG20 DFSFESP0
  

Fix information

• Fixed component name

  IMS V9

• Fixed component ID

  5655J3800

Applicable component levels

• R900 PSY UK23042

     UP07/03/23 P F703 Ž