PM56243: INTERMITTENT ROW NOT FOUND WHEN TRYING TO ACCESS A ROW THAT HAS BEEN DULY INSERTED AND SYNCPOINTED.

Obtain the fix for this APAR.

APAR status

• Closed as program error.

Error description

• You intermittently get an unexpected ROW NOT FOUND response
  from DB2 when trying to read a row that had earlier been
  inserted and syncpointed.  This happens in the following
  cirumstance:
  .
  1) In CICS RegionA, you have Program1 which does a DPL to
      a Program2 running in CICS RegionB.  SYNCONRETURN is not
      specified on that DPL so the recoverable work done by
      the two programs are bound together in a single unit of
      work.
  2) Program2 in CICS RegionB calls DB2 to Insert a row with, say,
      a key of XYZ.
  3) Program2 in CICS RegionB returns back to Program1 in CICS
      RegionA.
  4) Program1 in CICS RegionA does an EXEC CICS SYNCPOINT (or if
      Program1 was itself DPL'd to with SYNCONRETURN, it could
      just return back and that would cause a Syncpoint.)
  5) After Program1 gets control back from doing the EXEC CICS
      SYNCPOINT, Program1 somehow initiates a brand new unrelated
      transaction.  This new transaction DPLs to a program in
      CICS RegionB where the program does a DB2 Select where
      name=XYZ (the key of the row that was earlier inserted) and
      sometimes this will return with ROW NOT FOUND.
  .
  

Local fix

• Make sure the syncpoint is initiated in the same region that
  did the DB2 Insert.   Using the example above, you could
  1) Specify SYNCONRETURN on the DPL from Program1 to Program2
  2) Move the DB2 Insert to Program1 (rather than DPLing to
      Program2).
  3) Specify MROFSE=YES in CICS RegionA.  Specify MROLRM=YES in
      CICS RegionB.  Prepare a program called RETURN to run in
      CICS RegionB.  The program does nothing more than EXEC CICS
      RETURN. In Program1 after the EXEC CICS SYNCPOINT, DPL to
      Program RETURN in CICS RegionB.  After that returns,
      Program1 can end.
  

Problem summary

• ****************************************************************
  * USERS AFFECTED: All                                          *
  ****************************************************************
  * PROBLEM DESCRIPTION: Row-not-found returned from DB2 to a    *
  *                      client program that has previously      *
  *                      added the table entry.                  *
  ****************************************************************
  * RECOMMENDATION:                                              *
  ****************************************************************
  In a distributed UOW, it is possible for a client program to be
  told to commit as part of a syncpoint that it initiated, before
  the rest of the syncpoint has completed. If the rest of the
  syncpoint work involves committing a change to DB2 (say), then
  there is the potential for the client to try and reference this
  data in a subsequent UOW, before the commit processing has
  completed within DB2. This is because, although a syncpoint
  operation is atomic, it is not guaranteed to be synchronous.
  

Problem conclusion

• DFHRMLSO has been changed to ensure DB2 has completed its commit
  processing before the client program receives control back from
  the syncpoint operation.
  

Temporary fix

• FIX AVAILABLE BY PTF ONLY
  

Comments

APAR Information

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

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

  UK78093 UK78094

Modules/Macros

•    DESRMLS  DFHRMLSO
  

Fix information

• Fixed component name

  CICS TS Z/OS V4

• Fixed component ID

  5655S9700

Applicable component levels

• R600 PSY UK78093

     UP12/04/27 P F204

• R700 PSY UK78094

     UP12/04/27 P F204

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.