PI79890: ABENDC78 BECAUSE EZBSOMIE INVALIDLY TRIES TO FREE AN AIOCB

Obtain the fix for this APAR.

APAR status

• Closed as program error.

Error description

• An application starts by doing an EZASMI TYPE=INIAPI with the
  ASYNC=ECB option.  This causes a pool of AioCb structures to
  be allocated.  The application creates a UDP socket and connects
  to a remote IP address.
  The application later issues an asynchronous READ for that
  socket.  The EZASMI API obtains an AioCb from the cell pool and
  issues a BPX4AIO call.
  The PFS fast read routine in EZBPFRDW is called for asyncio
  processing.  It calls CommonRead which calls the UDP fast read
  routine in EZBUDWRT.  EZBUDWRT issues an ?itEvent WAIT causing
  asyncio2 processing to be scheduled, LRetval to be set to -1 and
  LRetCode to be set to EASYNC.  Meanwhile, An ICMP I_Unitdata_Ind
  is received causing SCBSoError to be set to ECONNREFUSED and
  SCBSoErrorJr to be set to JRPrevSockError in the SCB that
  represents the UDP Socket.
  Upon return from EZBUDWRT, CommonRead sees that the UDP socket
  is connected (SCBIsConnected is on) and copies SCBSoError over
  LRetCode.  Upon return from CommonRead, EZBPFRDW sees that
  LRetCode is not EASYNC and therefore returns LRetval (-1) as the
  retval rather than 0.  This causes the BPX4AIO call to complete
  with a retval of -1 which causes the AioCb to be freed (because
  the EZASMI interface thinks that no asyncio2 is scheduled).
  However, asyncio2 was actually scheduled.  Therefore, EZASOMAE
  gets called and calls EZBSOMIE.  EZBSOMIE tries to free the
  AioCb which causes the C78 ABEND since the AioCb already has
  been freed.
  

Local fix

Problem summary

• ****************************************************************
  * USERS AFFECTED:                                              *
  * All users of the IBM Communications Server for z/OS Version  *
  * 2 Releases 2 and 3 IP: asynchronous EZASMI API and UDP       *
  * sockets                                                      *
  ****************************************************************
  * PROBLEM DESCRIPTION:                                         *
  * Asynchronous EZASMI processing of UDP sockets fails with     *
  * ABENDC78.                                                    *
  ****************************************************************
  * RECOMMENDATION:                                              *
  * Apply PTF.                                                   *
  ****************************************************************
  An application program first does an EZASMI TYPE=INITAPI with
  the ASYNC=ECB option.  This causes the creation of a cell pool
  for AioCb structures.  The application program opens a UDP
  socket and starts receiving data via asynchronous EZASMI calls.
  An asynchronous EZASMI call causes an AioCb structure to be
  allocated from the cell pool.  If the EZASMI call is scheduled
  to complete asynchronously, then the AioCb should not be freed
  until the asynchronous completion.  Otherwise, the AioCb is
  freed immediately.  With UDP sockets, there is a window where an
  asynchronous error causes the AioCb to be freed immediately even
  though asynchronous completion of the EZASMI call has already
  been scheduled.  Therefore, the asynchronous completion results
  in a C78 ABEND when the aysnchronous completion program,
  EZASOMIE, invalidly attempts to free the AioCb.  This happens
  because the PFS common read procedure incorrectly overwrites
  local return code with the asynchronous errno value.  In this
  case, the asynchronous errno value was ECONNREFUSED due to an
  ICMP directive being received.  If the local return code had
  been properly preserved, then it would have been EASYNC which
  indicates that the asynchronous completion was scheduled.
  

Problem conclusion

• The PFS common read procedure has been amended to preserve the
  local return code if the asynchronous completion has already
  been scheduled.
  

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:

  UI49025 UI49027

Modules/Macros

• EZBPFSRM EZBPFRWV EZBPFSDR EZBPFFSM EZBPFFSR EZBPFRDW EZBPFANR
  EZBPFFSF EZBPFSRF
  

Fix information

• Fixed component name

  TCP/IP MVS

• Fixed component ID

  5655HAL00

Applicable component levels

• R220 PSY UI49025

     UP18/01/10 P F801

• R230 PSY UI49027

     UP18/01/10 P F801

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.