PM28592: ABENDU0757 SC901 IN DFSQRH00 AND OTHER ABENDS DUE TO YTIB BEING USED BY TWO PROCESSES AFTER A DEADLOCK ABEND.

Obtain the fix for this APAR.

APAR status

• Closed as program error.

Error description

• Abendu0757, abendU0519, and abend0c4 were each received after
  a deadlock U0777 condition. This happens when an OTMA
  transactionis running on a BE IMS system and suffers a
  deadlock from a DB2 timeout. DFSFXC30 detects the deadlock
  condition and makes a call to Abortcon processing in DFSYLUS0
  before calling DFSFXC40.  Abortcon releases the YTIB in
  anticipation of the Transaction being rescheduled.
     When DFSFXC40 calls the exit DFSNDXM0. This exit returns
  indicating that the U0777 should be treated as a real abend
  and the message should be discarded.  During the process of
  sending the DFS555I message the code continues to use the YTIB
  that has been freed and is now being used for a new message.
  This leads to these abends.
     If an abend does not occur it is also possible that this
  dual usage of the Ytib can result in the DFS555I being built
  with an incorrect qname of blanks with affinity to the BE
  system.
  

Local fix

Problem summary

• ****************************************************************
  * USERS AFFECTED: All IMS V11 APPC and/or OTMA Shared Queues   *
  *                 users.                                       *
  ****************************************************************
  * PROBLEM DESCRIPTION: This service addresses the following    *
  *                      reported problems:                      *
  *                                                              *
  *                      1. ABENDU0757 SC901, ABENDU0519, and/or *
  *                         ABENDS0C4 in module DFS6LUS2 can     *
  *                         result after an application          *
  *                         ABENDU0777 deadlock condition has    *
  *                         occurred. This problem is            *
  *                         applicable only to IMS OTMA/APPC     *
  *                         users that have the DFSNDMX0 user    *
  *                         exit installed, which elects to have *
  *                         the input message discarded for a    *
  *                         U0777 condition.                     *
  *                                                              *
  *                      2. Inflight URs are not cleaned up in   *
  *                         RRS after an application ABENDU0777  *
  *                         deadlock condition has occurred.     *
  *                         This problem is applicable only to   *
  *                         IMS APPC users that have the         *
  *                         DFSNDMX0 user exit installed, which  *
  *                         elects to have the input message     *
  *                         discarded for a U0777 condition.     *
  *                                                              *
  *                      3. ABENDS0C4 occurs in module DFSYLUS0  *
  *                         while trying to update the YTIB      *
  *                         after it has been freed.             *
  *                         This problem is applicable only to   *
  *                         IMS OTMA users.                      *
  ****************************************************************
  * RECOMMENDATION: INSTALL CORRECTIVE SERVICE FOR APAR/PTF      *
  ****************************************************************
  Problem 1
  ---------
  
  A message driven application program running in an IMS Back End
  shared queues environment, after having processed APPC or OTMA
  input, encounters an ABENDU777 (deadlock) condition.
  
  As part of abend processing, IMS normally treats the U777 in one
  of two ways:
  
    1. if the IMS Non-Discardable Message user exit (DFSNDMX0) is
       non-operational or is installed but does not specify for
       IMS to discard the input message in the case of an
       ABENDU0777, IMS will requeue the input message so that it
       can be reprocessed. If the input message originated from
       an APPC or OTMA client, the associated client conversation
       is continued.
  
    2. if the IMS Non-Discardable Message user exit (DFSNDMX0) is
       operational and specifies that the input message should
       not be requeued, IMS proceeds to discard the input message.
       If the input message originated from an APPC or OTMA
       client, the associated client conversation is terminated.
       Additionally, provided DFSNDMX0 does not also stipulate
       that it not be sent, IMS will send message DFS555I to the
       APPC or OTMA client.
  
  In the reported error scenario, the conditions described in
  item 2 above were present. During IMS syncpoint processing for
  the U777 abend, prior to calling module DFSFXC40 where the
  pertinent DFSNDMX0 determinations are made, a DFSLUMIF
  FUNC=ABORTCON request was initiated by module DFSFXC30 to allow
  the OTMA client conversation (in this case) to continue in
  preparation of the input message being requeued by DFSFXC40. As
  part of ABORTCON processing in an IMS Back End Shared Queues
  system, the OTMA YTIB block is freed making it available for
  reuse.
  
  During subsequent DFSFXC40 processing, DFSNDMX0 gets called and
  directs IMS to discard the input message but to still send
  DFS555I. IMS, however, attempts to use the same YTIB,
  previously released during ABORTCON processing but since reused,
  to send the DFS555I message. This double usage of the YTIB
  leads to the potential ABENDU0757 SC901, ABENDU0519, and
  ABEND0C4 that have been reported.
  
  An additional symptom of this problem has been reported where an
  abend does not occur. In this particular case, the DFS555I
  message was sent using an incorrect qname of blanks with
  affinity to the Back End IMS system.
  
  The underlying cause of all of the symptoms reported in this
  particular problem are due to the fact that IMS incorrectly
  issued a DFSLUMIF FUNC=ABORTCON request to have the APPC/OTMA
  client conversation continued. The correct IMS action should
  have been to issue a DFSLUMIF FUNC=ABORTTER request, after the
  DFS555I message had been sent, to terminate the APPC/OTMA client
  conversation.
  
  
  Problem 2
  ---------
  
  This error scenario is identical to that outlined in problem 1
  above with the exception being that the input message originated
  from an APPC client instead of OTMA.
  
  In the case of APPC, when determining if the DFS555I message
  should be send to the originating APPC device as well as the
  Master Terminal, module DFSFXC40 checks field PSTTPI to see if
  the client APPC Conversation is still active. Since PSTTPI was
  cleared earlier by DFSFXC30 at the conclusion of the ABORTCON
  request, the DFS555I message is never delivered to the Front End
  IMS where the input message from the APPC client was initially
  received. Hence, the Inflight threads residing in RRS never get
  cleaned up.
  
  The underlying cause of this particular problem is due to the
  fact that IMS incorrectly issued a DFSLUMIF FUNC=ABORTCON
  request to have the APPC/OTMA client conversation continued.
  The correct IMS action should have been to issue a DFSLUMIF
  FUNC=ABORTTER request, after the DFS555I message had been sent,
  to terminate the APPC/OTMA client conversation.
  
  
  Problem 3
  ---------
  
  This error scenario too is also identical to that outlined in
  problem 1 above and pertains strictly to IMS OTMA.
  
  During the DFSLUMIF FUNC=ABORTCON request that is initiated by
  module DFSFXC30, an ABEND0C4 can occur in the AbortCon_Service
  routine in module DFSYLUS0. The potential for this abend to
  happen is due to code at the conclusion of the AbortCon_Service
  routine that attempts to update the YTIB block after having just
  released it. Should the already freed YTIB get immediately
  reused prior to DFSYLUS0 trying to re-access it, an ABENDS0C4
  can result.
  
  
  Additional Keywords: 0C4 S0C4 MSGDFS555I 555I U757 U0757
                       U0519 U519 SC 901 SC-901
  

Problem conclusion

• GEN:
  KEYWORDS:
  
  *** END IMS KEYWORDS ***
  Problems 1 and 2
  ----------------
  
  For IMS syncpoint ABORT and ABTERM functions, the determination
  as to whether an APPC or OTMA conversation should be continued
  or terminated, has been moved from module DFSFXC30 to DFSFXC40.
  
  The supporting code and subroutines used to initiate the
  requests to the IMS APPC/OTMA AbortCon_Service and
  AbortTer_Service routines have been added to module DFSFXC40 and
  the related retriable type abend checks in DFSFXC30 have been
  removed.
  
  The specific action that IMS will take will now be determined
  after the role of DFSNDMX0 has been assessed. This will ensure
  that the DFSLUMIF FUNC=ABORTCON and FUNC=ABORTTER requests will
  be performed for their appropriate specific situations.
  
  
  Problem 3
  ---------
  
  Code in the AbortCon_Service routine in module DFSYLUS0 has
  been modified not to update the YIB block after it has been
  released.
  

Temporary fix

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

Comments

APAR Information

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

  PM26220

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

  PM31015 UK67524

Modules/Macros

• DFSFXC30
  DFSFXC40
  DFSYLUS0
  

Fix information

• Fixed component name

  IMS V11

• Fixed component ID

  5635A0200

Applicable component levels

• R100 PSY UK67524

     UP11/05/12 P F105

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.