PM82694: EZBSOH03 DYNAREA CELL POOL STORAGE ORPHANED IN SUBPOOL 0 KEY 8 AFTER SUBTASKS TERMINATE. FINREVERSAL PM39441

A fix is available

Subscribe

You can track all active APARs for this component.

APAR status

  • Closed as program error.

Error description

  • This APAR is a logical route of FIN APAR PM39441.
    
    Subpool 0 key 8 storage allocated by EZBSOH03 not freed when
    application subtask terminates without issuing TERMAPI call.
    

Local fix

  • Issue TERMAPI before terminating the subtask.
    

Problem summary

  • ****************************************************************
    * USERS AFFECTED: All users of the IBM Communications Server   *
    *                 for z/OS Version 1 Release(s) 13 IP:         *
    *                 Sockets 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.       +
    +-------------------------------------------------------------+
    

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

  • ž**** PE13/05/30 FIX IN ERROR. SEE APAR PM90124  FOR DESCRIPTION
    

APAR Information

  • APAR number

    PM82694

  • Reported component name

    TCP/IP V3 MVS

  • Reported component ID

    5655HAL00

  • Reported release

    1D0

  • Status

    CLOSED PER

  • PE

    NoPE

  • HIPER

    NoHIPER

  • Special Attention

    NoSpecatt

  • Submitted date

    2013-02-13

  • Closed date

    2013-03-27

  • Last modified date

    2013-06-24

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

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

    UK93278

Modules/Macros

  • EZBSOH03 EZBSOMIS EZBSORM2 EZBZSDST
    

Fix information

  • Fixed component name

    TCP/IP V3 MVS

  • Fixed component ID

    5655HAL00

Applicable component levels

  • R1D0 PSY UK93278

       UP13/05/10 P F305

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.



Rate this page:

(0 users)Average rating

Document information


More support for:

z/OS family

Software version:

1D0

Operating system(s):

z/OS

Reference #:

PM82694

Modified date:

2013-06-24

Translate my page

Machine Translation

Content navigation