IBM Support

PK95491: USING CICS SOCKET INTERFACE (TCPIPSERVICE) SOCKETS ARE LEFT IN CLOSEWAIT STATUS IN TCPIP. CICS IS NOT CLOSING THE SOCKETS

A fix is available

Subscribe

You can track all active APARs for this component.

 

APAR status

  • Closed as program error.

Error description

  • You are running CICS Transaction Server 3.2 using CICS web
    support.  When issuing a NETSTAT command you notice many sockets
    in status: ClosWait.
    A dump taken of CICS shows there are corresponding SOCKET
    OBJECT control blocks that are orphaned.  They indicate they
    are in 'closed' status, but CICS has not performed the close on
    them.
    Further investigation found a correlation between these sockets
    in ClosWait status, and a security violation that occurred.
    Here is an example of a security violation message:
    ICH408I USER(DFLTUSER) GROUP(xxxxxxxx) NAME(CICS DEFAULT USER )
            CWBA CL(TCICSTRN) INSUFFICIENT ACCESS AUTHORITY
            FROM *.CWBA (G)
            ACCESS INTENT(READ ) ACCESS ALLOWED(NONE )
    These orphaned sockets count towards MAXSOCKETS and eventually
    you could run out of sockets if you have many of these errors.
    It turns out sockets will be left in CLOSWAIT status whenever
    any deferred abend occurs during the INIT phase of
    initialising a web alias task, when that abend wasn't issued
    by DFHWBXM.
    Additional keywords: closewait tcpip socket object
    soso_notify_socket_closed
    KIXREVCEW
    

Local fix

Problem summary

  • ****************************************************************
    * USERS AFFECTED: All CICS Users                               *
    ****************************************************************
    * PROBLEM DESCRIPTION: CICS sockets are left in CLOSEWAIT      *
    *                      status in TCPIP. CICS is not closing    *
    *                      the sockets after a security failure.   *
    ****************************************************************
    * RECOMMENDATION:                                              *
    ****************************************************************
    CICS receives an HTTP request. CWXN attaches the alias task and
    selects the userid that the task will run under. The socket is
    then reserved for the alias task to use. The alias task starts
    up and DFHWBXM is driven for INIT_XM_CLIENT. This performs an
    ADD_USER_WITHOUT_PASSWORD call, the userid is valid so the call
    is successful. After the INIT phase has completed transaction
    manager issues a DFHXSRC CHECK_RESOURCE_ACCESS call as the XTRAN
    SIT parameter is not set to NO and SEC=YES has been specified.
    The userid is checked and found to NOT have access to run the
    alias task. The consequent ABEND is deferred.
    DFHWBXM subsequently runs for BIND_XM_CLIENT and, on finding the
    deferred ABEND, issues a message and sends an error response
    back to the client. DFHWBXM then calls WebRequest_tidyup to
    clean up all the web storage. A new async receive gets issued
    and the task ends.
    This processing fails to issue a DFHSOCK ESTABLISH call to tell
    sockets domain that a task is using the socket. Not doing the
    ESTABLISH has left the earlier RESERVE done by CWXN outstanding.
    When the alias task ends the socket does not get relinquished.
    This means that when the socket is finally closed by the client
    it will still exist in CICS because sockets domain believes
    there is still a task waiting to start up that wants to use the
    socket.
    These orphaned sockets count towards MAXSOCKETS, so if the
    problem persists CICS can potentially run out of sockets.
    
    Additional keywords: ICH408I MSGICH408I ICH408 MSGICH408
                         DFHWB0361 MSGDFHWB0361 ACF2 ABENDACF2
    

Problem conclusion

  • DFHWBXM has been changed to issue a DFHSOCK ESTABLISH call to
    inform sockets domain that the alias task is using the socket.
    When the alias task ends the socket will now get relinquished.
    

Temporary fix

  • FIX AVAILABLE BY PTF ONLY
    

Comments

APAR Information

  • APAR number

    PK95491

  • Reported component name

    CICSTS V3 Z/OS

  • Reported component ID

    5655M1500

  • Reported release

    500

  • Status

    CLOSED PER

  • PE

    NoPE

  • HIPER

    NoHIPER

  • Special Attention

    NoSpecatt

  • Submitted date

    2009-09-04

  • Closed date

    2009-10-14

  • Last modified date

    2009-11-04

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

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

    PK97630 UK51011

Modules/Macros

  •    DESWBAP  DESWBDM  DESWBRQ  DESWBRQF DESWBSR
    DESWBXM  DFHWBAP  DFHWBAPF DFHWBDM  DFHWBRQD DFHWBRQS DFHWBSR
    DFHWBXM
    

Fix information

  • Fixed component name

    CICSTS V3 Z/OS

  • Fixed component ID

    5655M1500

Applicable component levels

  • R500 PSY UK51011

       UP09/10/20 P F910

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":"3.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":"3.2","Edition":"","Line of Business":{"code":"","label":""}}]

Document Information

Modified date:
04 November 2009