PM40586: ABENDS0C4 DFSYLUS0 PREREL_SERVICE AFTER /STO REG ABDUMP COMMAND AGAINST IFP REGION IN OTMA CM1 ACK WAIT, WHICH TIMES OUT.

Obtain the fix for this APAR.

APAR status

• Closed as program error.

Error description

• IFP region processing OTMA CM1 input message and in mixed
  mode due to FF DB update, sends response message to OTMA
  client and waits for ACK ( SYNCLVL CONFIRM ).
  The OTMA client ( IMS Connect TCP/IP Client ) does not
  respond within the OTMA Send ACK Timeout period.
  This period was 2 minutes. During this two minutes a
  /STO REG ABDUMP command was entered as the IFP was holding
  locks impacting other processing.
  The ABDUMP command was deferred as the region was in syncpoint
  processing. The timeout occurred. IFP handles this via
  DBFGHU10 -> syncpoint trash request -> DBFSYN00 ->DFSTMS00
  ( FUNC=BACKTRM, PSTFUNCT=FUNCROLB )
  DFSTMS00 -> TMSFF000 -> DFSFXC30 -> LUMABRTT
  Here the input YTIB is released, which releases the OTMA
  prefix.
  DFSTMS00 around TMSFF375 finds PSTFUNCT=FUNCROLB and does
  not clear PSTCB62P.
  Control returns to DBFIRC10 and the pending U0474 is setup
  and issued.
  Backout for the U0474 now runs with PSTCB62P pointing to an
  already released OTMA Prefix in LUMP pool.
  DFSFXC40 calls DFSYLUS0 to release the prefix again, and part
  of this logic attempts to retrieve the LUMBLK ( YTIB ) address
  out of the prefix to locate the TPIPE in order to decrement a
  counter. The LUMP storage has been re-used and the LUMBLK
  address is bad, causing a S0C4. A U0729 might also be expected
  if the LUMBLK storage had been addressable.
  

Local fix

• Don't issue /STO REG ABDUMP commands against IFP regions
  in WAIT-SYNCPT status.
  

Problem summary

• ****************************************************************
  * USERS AFFECTED: All IMS V10 Fastpath users that run APPC     *
  *                 and/or OTMA transactions.                    *
  ****************************************************************
  * PROBLEM DESCRIPTION: IMS control region ABENDS0C4 occurs     *
  *                      in the PREREL_SERVICE routine, within   *
  *                      module DFSYLUS0, while attempting       *
  *                      to retrieve the LUMBLK (YTIB) address.  *
  ****************************************************************
  * RECOMMENDATION: INSTALL CORRECTIVE SERVICE FOR APAR/PTF      *
  ****************************************************************
  After retrieving commit mode 1 (CM1 - synchronous) OTMA input
  and performing an IMS full function database update,
  an application program, running in an IFP region, issued a
  syncpoint Commit request.
  
  However, during early syncpoint processing, while attempting to
  deliver its response message to the OTMA client, the OTMA client
  times out causing the SEND request to fail. IMS Fastpath
  processing handles the SEND failure by initiating a ROLB
  request to backout out the inflight work, but also stipulates
  that the active OTMA conversation must be terminated.
  
  Coincidentally, during BACKOUT syncpoint processing, a /STOP
  REGION ABDUMP command is issued to abnormally terminate the IFP
  region because it was believed to be holding resource locks that
  other work needed. This action remains pending until in-progress
  ROLB processing completes.
  
  When the active OTMA CM1 conversation is terminated during ROLB
  processing, the YTIB block along with its associated prefix
  block, pointed to by field PSTCB62P, are both logically released
  (storage is not freed) so that they are made available for re-
  use. In this particular instance, both were immediately
  reassociated with new incoming OTMA work. Furthermore, in this
  instance of ROLB processing, field PSTCB62P is not cleared even
  though the OTMA prefix block it points to has been re-associated
  with a completely different unit of work.
  
  When abnormal termination of the IFP region is invoked under the
  IMS control region, due the deferred /STO REG ABDUMP command,
  since the contents of field PSTCB62P are non-zero, module
  DFSFXC40 initiates a call to the PREREL_SERVICE routine
  (DFSYLUS0) to free the prefix storage. However, since this
  storage was reassociated with a different unit of work, the
  LUMBLK address used by the PREREL_SERVICE is no longer
  addressable, resulting in an ABEND0C4 of the IMS control region
  instead of the expected ABENDU0474 of the IFP region. Should
  the LUMBLK address been addressable, an ABENDU0729 would have
  likely occured instead.
  
  
  Additional Keywords: cmdSTO REG U474 U729
  

Problem conclusion

• GEN:
  KEYWORDS:
  
  *** END IMS KEYWORDS ***
  Code has been added to syncpoint modules DFSFXC30 and DFSTMS00,
  within the subroutines which issue the DFSLUMIF FUNC=ABORTTER
  request to release the LU62 block and prefix, to now clear field
  PSTCB62P if the LU62 conversation is synchronous (CM1).
  

Temporary fix

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

Comments

APAR Information

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

  PM37739

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

  UK70021

Modules/Macros

• DFSFXC30 DFSTMS00
  

Fix information

• Fixed component name

  IMS V10

• Fixed component ID

  5635A0100

Applicable component levels

• R010 PSY UK70021

     UP11/07/26 P F107 Ž

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.