PK57726: ABEND AIPJ IN DFHISRE WHEN CICS TRANSACTION GATEWAY V7.1 ISSUES RESYNC REQUEST OVER IPIC

Obtain the fix for this APAR.

APAR status

• Closed as program error.

Error description

• When the CICS Transaction Gateway V7.1 attempts to resynchronize
  work across an IPIC connection then some attempts can fail
  because of an internal processing error . Under these
  circumstances CICS TS issues an AIPJ ABEND.
  

Local fix

Problem summary

• ****************************************************************
  * USERS AFFECTED: CICS Transaction Gateway version 7.1 users   *
  *                 communicating with CICS TS over an IPIC      *
  *                 connection.                                  *
  ****************************************************************
  * PROBLEM DESCRIPTION: An AIPJ abend occurred when the CICS    *
  *                      Transaction Gateway attempted to carry  *
  *                      out a resynchronization operation over  *
  *                      an IPIC connection into CICS TS.        *
  ****************************************************************
  * RECOMMENDATION:                                              *
  ****************************************************************
  The Gateway can issue one or more concurrent resynchronization
  messages of an IPIC connection to a CICS region. Each such
  request arriving into CICS is assigned its own receive session,
  from the session pool associated with the connection. Each
  session has its own buffer that is used to receive the Gateway's
  message into. These buffers are not cleared when the task that
  has used them ends, and they are placed back into the pool.
  
  Two types of resynchronization requests can be sent from the
  Gateway into CICS: a request to complete a named unit of work,
  and one that is asking CICS to return a list of all the known
  XIDs that are associated with indoubt and shunted units of
  work associated with the connection.
  
  A request to resynchronize a specific UOW consists of an HTTP
  body containing a number of IS message fields. The only
  mandatory fields in such a message are an IS-6 protocol field
  and an IS-12 UOW field. The other type of request has no
  mandatory fields.
  
  The logic in DFHISRE that is called to process such messages
  looks for an IS-6 field and if found assumes that the request is
  to resynchronise a named unit of work. Other tests are then
  applied to the message data and if mandatory fields are missing
  then the ABENDAIPJ is issued.
  
  DFHISRE does not take into account that the message buffer might
  contain data in it left over from the previous task that had
  used it. It should have looked for a zero length buffer and used
  that as an indicator that the request was one that was asking
  for a list of XIDs. Instead it went off looking for an IS-6,
  which may very well have been left in the buffer by an earlier
  task.
  
  While investigating this problem it was noted that on a secure
  connection a request for a list of XIDs might not be empty, and
  could instead have an IS-8 security field in it. Finding such a
  field in this message also resulted in this ABEND being issued.
  

Problem conclusion

• DFHISRE has been changed to first look for a zero length
  message, or one that only contains an IS-8 (security) field.
  If there is more data in the buffer, it checks for IS-6
  (syncpoint) and IS-12(xidrl) fields in any order
  

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:

  UK34955

Modules/Macros

•    DESISRE  DFHISRE  DFHISREA DFHISREM DFHISRET
  

Fix information

• Fixed component name

  CICSTS V3 Z/OS

• Fixed component ID

  5655M1500

Applicable component levels

• R500 PSY UK34955

     UP08/04/10 P F804

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.