PM90124: ABENDS378 RC14 IN IGVVSERR, CALLED BY EZBSORM2, ON TCPIP TERMINATION 13/05/30 PTF PECHANGE

Obtain the fix for this APAR.

APAR status

• Closed as program error.

Error description

• TCPIP has APAR PM82694 applied.   A sockets application is
  running and TCPIP is then terminated.  The TCPIP socket resource
  manager EZBSORM2 is entered to free storage.  When it invokes
  STORAGE (RELEASE) to release storage, an abend378 occurs in MVS
  module IGVVSERR.
  

Local fix

• Terminate the sockets application before terminating TCPIP
  

Problem summary

• ****************************************************************
  * USERS AFFECTED: All users of the IBM Communications Server   *
  *                 for z/OS Version 1 Release(s) 13, IP:        *
  *                 SOCKET API                                   *
  ****************************************************************
  * PROBLEM DESCRIPTION: Subpool 0 key 8 storage allocated by    *
  *                      EZBSOH03 not freed when application     *
  *                      subtask terminates without issuing      *
  *                      TERMAPI call.                           *
  *                      The orphaned storage eyecatcher in      *
  *                      the dump looks  as follows:             *
  *                      EZBSOH03 DYNAREA CELL PO.               *
  *                                                              *
  ****************************************************************
  * RECOMMENDATION:                                              *
  ****************************************************************
  Module EZBSOH03 is called by an application subtask as part
  of TCPIP socket processing (e.g. EZASMI or EZASOKET). EZBSOH03
  proceeds to allocate a dynamic storage area in subpool 0
  key 8. This storage area remains allocated until the subtask
  issues a TERMAPI call. If the subtask is attached with the
  SZERO parameter (subpool 0 storage shared), and the subtask
  detaches without first issuing a TERMAPI call, then the
  EZBSOH03 dynamic storage area does not get freed until the
  application main socket API task is terminated.  This can
  lead to a slow growth of subpool 0 key 8 storage over time.
  +-------------------------------------------------------------+
  + 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.       +
  +-------------------------------------------------------------+
  
  This APAR is routed to 2.1  under PM94040
  

Problem conclusion

• Changes have been made to the sockets API modules to release
  user autodata storage when the task terminates.
  
  
  * Cross Reference between External and Internal Names
  

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:

  UK95347

Modules/Macros

• EZBSOH03 EZBSOMIS EZBSORM2 EZBZSDST EZB2SDST
  

Fix information

• Fixed component name

  TCP/IP V3 MVS

• Fixed component ID

  5655HAL00

Applicable component levels

• R1D0 PSY UK95347

     UP13/09/19 P F309

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.