PK88885: S0C4 ABEND IN EZBTCUTL AFTER OBEYFILE FOR SHAREPORT

Obtain the fix for this APAR.

APAR status

• Closed as program error.

Error description

• A server application that uses the Pascal API (such as SMTP or
  LPSERVE) is started that opens a listen socket for a specific
  port.  Later, an OBEYFILE is processed that changes the PORT
  reservation statement to add the SHAREPORT keyword.  Then a
  second application is started to listen on that same port.
  Under some conditions, this can cause the following sequence to
  occur within 60 seconds of the second listener starting:
  
   - An S0C4 ABEND in EZBTCUTL (offset A48C for UK35463, offset
     will vary for other releases or PTF levels).
  
   - EZZ9670E tcpname   SYSPLEX PROCESSING HAS ENCOUNTERED A
     NONRECOVERABLE ERROR 000C4000 - 00000004
  
   - EZZ9676E SYSPLEX PROBLEM DETECTION CLEANUP HAS SUCCEEDED FOR
     tcpname
  
  At this point, the stack has left the sysplex group.  Even if
  rejoined (either manually or automatically), neither SHAREPORT
  distribution nor sysplex distribution will work properly for
  this stack.
  
  OTHER SYMPTOMS:
  
  S0C4 ABEND in EZBTCUTL each time a new client attempts to
  connect to the affected port.
  

Local fix

• When adding SHAREPORT on a port reservation via OBEYFILE,
  recycle the server application that is listening on that port
  before starting a second application.
  
  If this ABEND occurs, the stack will need to be recycled to
  fully recover.
  
  
  Keywords:
  
  ABEND00C4  ABENDS0C4  TCP_calc_SEF  SHAREPORTWLM  PORTRANGE
  XFCVT_WLM_TID  EZBXFWTM   EZBTCSBL   SYN
  

Problem summary

• ****************************************************************
  * USERS AFFECTED: All users of the IBM Communication Server    *
  *                 for z/OS Version 1 Release 11 IP: Pascal     *
  *                 API including SMTP                           *
  ****************************************************************
  * PROBLEM DESCRIPTION: Under certain conditions, the TCPIP     *
  *                      address space may abend S0C4 after      *
  *                      SHAREPORT has been added to a PORT      *
  *                      statement via an obeyfile.              *
  ****************************************************************
  * RECOMMENDATION:                                              *
  ****************************************************************
  TCPIP is started with a particular port reserved for some
  application. The application, which uses the Pascal API, is
  started, and listens on the specified port. Then the
  TCPIP profile is updated via obeyfile to reserve the same
  port for another job and SHAREPORT is specified to allow
  multiple address spaces to use the same port. Within a minute
  of starting the second address space, TCPIP will abend 0C4.
  
  If part of a sysplex, TCPIP may leave the sysplex group.
  If the stack rejoins the group, sysplex distribution and
  shareport distribution may not work properly. Recycling the
  TCPIP address space will clear the condition.
  
  The listen processing for a Pascal application may occur
  during bind processing. If SHAREPORT was not specified for
  the first Pascal application that listens on a given port, then
  the TCB for that application will not have a TCB extension
  (TCBEXT). Later, if SHAREPORT is specified, any SHAREPORT
  processing against the original TCB (without the TCBEXT) is
  likely to result in an 0C4 abend.
  +-------------------------------------------------------------+
  + Please check our Communications Server for OS/390 homepages +
  + for common networking tips and fixes.  The URL for these    +
  + homepages can be found in Informational APAR II11334.       +
  +-------------------------------------------------------------+
  

Problem conclusion

• The listener processing performed during bind processing for
  the Pascal API in module EZBTCNET has been amended to always
  allocate a TCBEXT.
  
  * Cross Reference between External and Internal Names
  

Temporary fix

Comments

APAR Information

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

  PK80472

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

  UK47557

Modules/Macros

• EZBTCNET
  

Fix information

• Fixed component name

  TCP/IP V3 MVS

• Fixed component ID

  5655HAL00

Applicable component levels

• R1B0 PSY UK47557

     UP09/08/21 P F908

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.