PM10375: ABEND AIPD WHEN TRYING TO ESTABLISH IPIC CONNECTION AFTER A WARM OR EMERGENCY RESTART

Obtain the fix for this APAR.

APAR status

• Closed as program error.

Error description

• After migrating to CICS TS V4.1
  2 regions on same LPAR successfully connect via IPIC.
  RegB gets canceled.
  RegA ends normally.
  RegA restarts
  RegB then restarts.
    From this point on the IPIC connection fails.
  RegA gets
  .
  DFHDU0203I A transaction dump was taken for dumpcode: AIPD
  DFHAC2236  Transaction CISS abend AIPD in program DFHISCOP...
  .
    In the trace in the dump,
  transaction CSOL accepted a request and started tranid CISS.
  But, this trace entry shows the source of the problem:
  .
       XM 1002 XMIQ  EXIT  -
   FUNCTION(INQUIRE_TRANSACTION)
   RESPONSE(OK)
   PRIMARY_CLIENT_TYPE(SOCKET)
   START_CODE(C)
   ATTACH_PARMS(193C16B0 , 00000000 , 0000000C)   =060848=
  .
       ISCOP *EXC* INVALID_ATTACH_PARMS           =060849=
  .
  The ATTACH_PARMS at 193C16B0 for x'C' are
  x'00000000 00000000 00000000'
  .
    This was caused by a special URIMAP
  with a host name of 000.000.000.000:xxxx.
  where xxxx is the port number.
  A product uses this just to get the port number.
  .
    In CTS v3.2, a hostname of all zeros was valid.
    In CTS v4.1 it apparently is not.
  Changing the value to 111.111.111.111:xxxx
  corrects the problem.
  .
    This was similar to another issue, where a TCPSERVICE
  had an ipaddress of 0.0.0.0
  that was valid in v3.2 but not in v4.1.
  The sockets domain failed to start
  until the address was changed to ANY.
  .
    The change between CTS 3.2 to CTS 4.1 that introduce the
  change of behavior was the support for Ipv6 IP addressing.
  At CTS 4.1 it is now invalid to have a HOST (HostName)
  with a value of:
  0.0.0.0
  ::0.0.0.0
  ::0
  See the INTERNET GUIDE manual under IP Addresses
  for further information.
  .
    During an WARM or EMER restart,
  the URIMAPs are recovered from the global catalog
  and re-instated during the WEB domain initialization.
    At CTS 4.1 the HOST attribute is checked.
  If it is not valid, an error is issued
  and the WEB initialization is stopped at that point
  without issuing any message.
  This leave the WEB domain in an unusable state.
  .
    Later when the listener task gets driven
  with a NOTIFY request for IPIC, an XMAT ATTACH is issued
  with primary_client_type of SOCKET (the default) instead of IPIC
  for transaction CISS.
    Transaction CISS starts.
  DFHISCOP retrieves the ATTACH_PARMS which are invalid
  and abend AIPD is issued.
  .
    IPIC is only a victim of the fact that
  the WB domain failed to be initialized
  during a WARM or an EMER restart.
  

Local fix

• Provide nonzero values for the HOST (HostName).
  

Problem summary

• ****************************************************************
  * USERS AFFECTED: All CICS users.                              *
  ****************************************************************
  * PROBLEM DESCRIPTION: Transaction CISS abends with code AIPD  *
  *                      when establishing an IPIC connection    *
  *                      during a CICS warm or emergency         *
  *                      restart.                                *
  ****************************************************************
  * RECOMMENDATION:                                              *
  ****************************************************************
  The problem occurs when a URIMAP definition, with a HOST
  attribute containing a zero IPv4 address, is installed on a
  CICS TS 4.1 region and the region is then shut down and
  restarted.
  
  During restart processing to recover the installed
  URIMAPs, host records are read from the CICS global catalog
  and the record for a definition with a zero IPv4
  address has invalid contents. This causes a failure in
  Web Domain initialization. As Web Domain intialization
  does not complete, the functions to support a
  subsequent attempt to recover an IPIC connection
  are not available and the AIPD abend is issued.
  
  The catalog record contains low-values for the hostname,
  rather than a zero IPv4 address, because from CICS TS 4.1
  it is invalid to create definitions for
  URIMAPs, TCPIPSERVICEs, IPCONNs or CORBASERVERs
  with zero IPv4 addresses. At the point of cataloguing the
  URIMAP hostname, the ipaddress is expected to be
  valid because it is checked when adding or modifying the
  definition. This does not cover the case when a definition
  was validly created on a pre-4.1 release and it being installed
  from the CSD: in that case a response of invalid_ipaddress is
  returned and the hostname is incorrectly catalogued as
  low-values.
  
  Additional Keywords: ABENDAIPD MSGDFHAC2236 DFHAC2236
                       IPv6 INET_NTOP INET_PTON
  

Problem conclusion

• wbrp_catalog_host is changed to check for a uvh_host_name
  containing a zero ipaddress. In this case it bypasses
  the calls to INET_PTON and INET_NTOP and sets the
  uvhc_hostname, in the catalog record, to be the value
  in uvh_host_name.
  

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:

  UK58208

Modules/Macros

• DESWBRP  DFHWBRP  DFHWBTT
  

Fix information

• Fixed component name

  CICS TS Z/OS V4

• Fixed component ID

  5655S9700

Applicable component levels

• R600 PSY UK58208

     UP10/06/29 P F006

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.