PH08820: IMS ABENDU 3044 DB2 ABEND S04E RC00E50062 DUE TO OASN (PSB SCHEDNUMBER ) PORTION OF IMS RECOVERY TOKEN WRAPPING TO ZERO

Obtain the fix for this APAR.

APAR status

• Closed as program error.

Error description

• AbendU3044 in IMS dependent region, due to DB2 abendS04E
  RC00E50062. IMS called DB2 twice for PREPARE / PHASE I for
  the same UR, this is detected by DB2 which issues the abend
  and gives IMS a bad RC on Phase I exit call, which causes the
  U3044.
  The problem happens when the IMS system PSB schedule count
  ( BCPSKCNT, NIDOASN ) wraps to zero and the IMS dependent
  region for this schedule makes an ESS ( DB2 ) call.
  IMS maintains a chain of RREs off PSTRRE representing external
  subsystem work. At subsystem signon, a check is made for an
  existing RRE for the target subsystem, in DFSESS10, and if
  one is found, a check is made to determine if the RRE is still
  queued on the SIDX for the subsystem. If it is not, a new
  RRS is chained and initialized.
  At syncpoint, DFSFESP0 runs the chain of RREs to determine
  which need to be called for syncpoint phases.
  The check made by DFSESS10 to determine if a RRE is queued on
  the SIDX passes RREOASN, which is the IMS PSB schedule count
  from the IMS recovery token, as a parameter to DFSCBTS.
  Pass by value is used, so the actual value, not the address
  of RREOASN, is passed.
  DFSSIDX0 unfortunately checks this value for zero, on assumption
  zero means no parameter passed. However, in this case, zero
  is the actual value. The DFSCBTS call fails and DFSESS10 gets
  a new RRE, for the same DB2, and chains it off PSTRRE. This
  happens on the *next* signon after the schedule that used the
  zero value ( that UR works fine ). At as a result there are
  now two RREs for the same DB2 subsystem off PSTRRE, one
  with RREOASN zero and one with RREOASN = the current IMS
  recovery token OASN.
  At commit, DFSFESP0 will find both and call DB2 twice.
  Symptoms of this are an IMS 5600 0001 ( TPCPBCOM ) record with
  TPCPNSS= 2, and the DB2 subsystem name repeated twice after
  TPCPSOXN, and a dump / LOGREC entry for S04E RC00E50062.
  DSN1LOGP can be used to print DB2 log, it will show both
  Begin Commit Prepare and End Commit Prepare log records for
  the UR. The IMS log will show that the same IMS PST ( from
  PST number in log records previous used a recovery token where
  the OASN portion was zero, and accessed the same DB2 subsystem.
  The exposure is limited the global IMS schedule count wrap,
  and will happen only once per IMS until the count wraps
  again ( which is 4 billion schedules ).
  

Local fix

Problem summary

• ****************************************************************
  * USERS AFFECTED:                                              *
  * All users of IMS V15 with External Subsystem (ESS)           *
  * connections to DB2.                                          *
  ****************************************************************
  * PROBLEM DESCRIPTION:                                         *
  * Scenario:                                                    *
  * - An IMS system connected to DB2 had been running in a very  *
  * high transaction rate environment for an extended period of  *
  * time, about 2 months, without being cold started.            *
  * - The lack of IMS cold starts in this very busy environment  *
  * caused the IMS global PSB schedule counter to wrap back to   *
  * zero.                                                        *
  * -- Note that the IMS global PSB schedule counter is only     *
  * reset during IMS cold start.                                 *
  * - The PSB schedule counter wrapped back to zero, after       *
  * 4294967295 PSB schedules ('FFFFFFFF'x), and caused a double  *
  * PREPARE syncpoint interaction to be sent to DB2 causing DB2  *
  * to ABEND with S04E-00E50062. The DB2 ABEND caused a an IMS   *
  * dependent region to ABEND with U3044.                        *
  ****************************************************************
  * RECOMMENDATION:                                              *
  * INSTALL CORRECTIVE SERVICE FOR APAR/PTF                      *
  ****************************************************************
  When the global PSB schedule counter wrapped from 'FFFFFFFF'x to
  '00000000'x, one of the IMS dependent regions mistakenly
  generated a second Residual Recovery Element (RRE), instead of
  reusing the previously built RRE for the same DB2 subsystem,
  because the PSB schedule counter value is zero. The IMS
  dependent region interacting with DB2 encountered an ABEND U3044
  after DB2 encountered an ABEND S04E-00E50062 due to a double
  PREPARE syncpoint interaction caused by the second RRE that was
  built by mistake.
  

Problem conclusion

• GEN:
  KEYWORDS:
  MPR MPP U3044 DB2 ABEND S04E 00E50062
  
  *** END IMS KEYWORDS ***
  Logic in IMS been updated so that the schedule counter is
  intentionally set to '00000001'x when the counter wrap is
  detected. The following parts were updated:
  DFSSJBP0, DFSDASP0, DFSOBMP0, DFS3SCP1, DFSSMSC0, DFSSBMP0,
  DFSSJMP0
  

Temporary fix

Comments

APAR Information

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

  PH07560

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

  UI64965

Modules/Macros

• DFSSJBP0 DFSDASP0 DFSOBMP0 DFS3SCP1 DFSSMSC0 DFSSBMP0 DFSSJMP0
  

Fix information

• Fixed component name

  IMS V15

• Fixed component ID

  5635A0600

Applicable component levels

• R500 PSY UI64965

     UP19/08/29 P F908 ¢

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.