IBM Support

PI19090: MAXSOCKET LIMIT WHEN SOCKET POOLING USED IN CICS

A fix is available

Subscribe

You can track all active APARs for this component.

 

APAR status

  • Closed as program error.

Error description

  • You see a large increase in the number of sockets being used.
    The AF_INET socket usage might increase to over 90%.
    It may hit the MAXSOCKET limit.
      The biggest contributor is:   DFHKETCB
    A look at a CICS region's
            Number of open files for this process:
    may exceed 15,000 and still be growing.
    .
      A dump of the CICS region,
    in the SO (sockets) domain,
    under the    ===SO: SOCKETS DOMAIN - SUMMARY
            Owned Sockets:
    might show a large number of sockets, as seen above.
    .
    But, the tokens and other information for each socket is zeros,
    except the number of tasks that have been involved with it.
    For example:
    ---------------------------------------------------------------
    TOKEN    FLAGS  Send ECB Recv ECB I/O   Dom  Gate Remote
    00000000        00000000 00000000          0    0
    .
       IPAddr        Port  Task
                       0    1
    ---------------------------------------------------------------
    .
      The problem is caused by a WEB-OPEN request in a CICS task.
    This causes a SOCKET create to be issued.
      When SOCKET pooling is used
    the CICS SOCKET TOKEN does not get re-used.
      So after many thousands of WEB OPEN requests
    all the SOCKET token get used
    and there is none on the FREE chain.
      From that point on, the next WEB OPEN will cause
    a SOCKET to be obtain from TCPIP via the SOCK CREATE.
    This returns a SOCK TOKEN of 0.
      DFHWBCL then does a SOCKET CONNECT passing the SOCKET token.
    The CONNECT failed because the token is 0.
      WBCL then tries to tidy up by doing a SOCKET CLOSE.
    This also fails, resulting in the SOCKET being orphaned.
    After a while, all the SOCKETs in TCPIP will get consumed.
    .
    Additional keywords:
    KIXREVxxx
    

Local fix

  • Do not use SOCKET Pooling until this problem has been resolved.
    

Problem summary

  • ****************************************************************
    * USERS AFFECTED: All CICS users.                              *
    ****************************************************************
    * PROBLEM DESCRIPTION: CICS TCP/IP socket usage continually    *
    *                      grows when using HTTP outbound          *
    *                      connection pooling.                     *
    ****************************************************************
    * RECOMMENDATION:                                              *
    ****************************************************************
    CICS is using outbound HTTP connection pooling. When a socket is
    removed from the pool to be reused the state of the connection
    is checked to ensure it is still active. If the connection has
    now been closed by the remote system the socket is closed by
    CICS and the CICS control blocks freed.
    
    As part of this process DFHSOMG should set the current socket
    token to be unused. DFHSOMG is specifying an incorrect value
    forthe socket token. This leaves the actual socket token still
    marked as in use. A new socket is created and it gets allocated
    the next available token.
    
    Eventually all possible socket tokens are marked as allocated
    and DFHSOMG allocates a token of 0 to all future sockets. This
    token is invalid and the caller is unable to perform any socket
    functions using this token. This means that the caller is unable
    to indicate that the socket should be closed. The socket control
    blocks and the actual TCP/IP socket are never freed.
    
    Over time the CICS region can end up at the MAXSOCKETS limit
    even though no (or very few) sockets are actually in use.
    

Problem conclusion

  • DFHSOMG has been changed to release the correct socket token
    when closing a pooled socket.
    

Temporary fix

  • FIX AVAILABLE BY PTF ONLY
    

Comments

APAR Information

  • APAR number

    PI19090

  • Reported component name

    CICS TS Z/OS V4

  • Reported component ID

    5655S9700

  • Reported release

    700

  • Status

    CLOSED PER

  • PE

    NoPE

  • HIPER

    NoHIPER

  • Special Attention

    NoSpecatt

  • Submitted date

    2014-06-02

  • Closed date

    2014-07-03

  • Last modified date

    2014-08-04

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

    PI18455

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

    UI19446

Modules/Macros

  • DFHSOAD  DFHSOCK  DFHSODM  DFHSODUF DFHSOIS  DFHSOL   DFHSOLI
    DFHSOLS  DFHSOLX  DFHSOM01 DFHSOM02 DFHSOM03 DFHSOPL  DFHSORD
    DFHSOSE  DFHSOST  DFHSOS00 DFHSOS01 DFHSOS02 DFHSOS03 DFHSOS04
    DFHSOS05 DFHSOS06 DFHSOS07 DFHSOS08 DFHSOS09 DFHSOS10 DFHSOS11
    DFHSOS12 DFHSOS13 DFHSOS14 DFHSOS15 DFHSOS16 DFHSOS17 DFHSOS18
    DFHSOS19 DFHSOS20 DFHSOS21 DFHSOS22 DFHSOS23 DFHSOTB  DFHSOTI
    DFHSOTRI DFHSOUE  DFHSOXM
    

Fix information

  • Fixed component name

    CICS TS Z/OS V4

  • Fixed component ID

    5655S9700

Applicable component levels

  • R700 PSY UI19446

       UP14/07/17 P F407

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.

[{"Business Unit":{"code":"BU058","label":"IBM Infrastructure w\/TPS"},"Product":{"code":"SSGMGV","label":"CICS Transaction Server"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"4.2","Edition":"","Line of Business":{"code":"LOB35","label":"Mainframe SW"}},{"Business Unit":{"code":"BU054","label":"Systems w\/TPS"},"Product":{"code":"SG19M","label":"APARs - z\/OS environment"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"4.2","Edition":"","Line of Business":{"code":"","label":""}}]

Document Information

Modified date:
04 August 2014