OA51436: ABEND0E0 IN ISTITCHP WHEN MOVING DATA FROM TSCDATAA TO AN NLP TRACE ENTRY.

Obtain the fix for this APAR.

APAR status

• Closed as program error.

Error description

• Abend0E0 in ISTITCHP when moving data from TSCDATAA to an NLP
  trace entry. Just prior to the abend, ISTTSC88 issued a Discard
  for a sequence number for a certain length and then later the
  same sequence number was retransmitted for a different length.
  *** Additional Symptom ***
  Abend0c4 in ISTRPCCS during copy process of Local SND.
  

Local fix

Problem summary

• ****************************************************************
  * USERS AFFECTED:                                              *
  * All users of the IBM Communications Server                   *
  * z/OS Version 2 Release 2                                     *
  * HPR                                                          *
  ****************************************************************
  * PROBLEM DESCRIPTION:                                         *
  * Abend0E0 in module ISTITCHP                                  *
  ****************************************************************
  * RECOMMENDATION:                                              *
  * Apply PTF                                                    *
  ****************************************************************
  Sample Configuration:
  
  VTAMA==XCF==VTAMB==AHHC==VTAMC==MPC==VTAMD
   ICN         ICN          ICN         SA
   APPLA                                APPLD
  
  
  /--CNR00005--//--CNR00006--/
     Interact      Interact
  
  
  The problem is summarized as follows:
  1) A session is setup between APPLA and APPLD.
  2) This creates back to back HPR pipes (CNR00004 and CNR00005)
  to support this subarea to APPN session.
  3)) Data arrives in VTAMB over CNR00005 originating from APPLD.
  The data arrived from VTAMC over an HPDT MPC+ connection.  The
  inbound packets are deblocked by module ISTTSCDP.  This modules
  issues a ?GETTIPAC macro specifying the EE option.  The flavor
  of the GETTIPAC invocation allocates a TIPAC with a larger
  number of XBFLENTs.
  4) The inbound packet (NLP) is converted into a FID4 PIU and is
  forwarded to RTP pipe CNR00004.  CNR00004 is mapped to an XCF
  connection which is used to transport data to VTAMA/APPLA.
  5)  HPR expects to be able to use an imbedded ISTSND control
  block within the TIPAC strucutre and proceeds to do so.
  However, the ISTSND offset within  the IUTTIPAC is within the
  range of the newly defined XBFLENTs (from ISTTSCDP).  This
  creates a double use of the Tipac storage (corrupting one of the
  XBFLENTs)
  5) When VTAMB tries to trace an outbound NLP over CNR00004, this
  leads to and Abend0E0 in ISTITCHP trying to format out an NLP
  trace entry.
  

Problem conclusion

• iuttipac.plxmac - Remapped the IUTTIPAC to allow the ISTSND and
  ISTSGMNT to co-exist in the larger number of XBFLENTs.
  
  istrpcom,
  istrpcrn,
  istrpcrs,
  istrpcsg,
  istrpcrt - Have been recompiled to pick up iuttipac maco
  changes.
  

Temporary fix

Comments

APAR Information

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

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

  UA83144

Modules/Macros

• ISTRPCOM ISTRPCSG ISTRPCRT ISTRPCRS ISTRPCRN
  

Fix information

• Fixed component name

  VTAM V4 MVS/ESA

• Fixed component ID

  569511701

Applicable component levels

• R220 PSY UA83144

     UP17/01/04 P F701 Ž

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.