OA40383: GIVESOCKET/TAKESOCKET CALLS IS NOT BEING CLEANED UP WHEN THE NOBODY TAKES IT

A fix is available

Subscribe

You can track all active APARs for this component.

APAR status

  • Closed as program error.

Error description

  • It appears that the underlying problem is a control structure
    associated with the REXX sockets use of GIVESOCKET/TAKESOCKET
    calls is not being cleaned up when the nobody takes it (and the
    giving task goes away).  I will be discussing this aspect with
    the developers, but I doubt there will be anything done about
    this in the current release.
    
    There are two suggestions I would make that would help avoid
    this scenario:
    
     - I can see that the giving task does a SELECT waiting on the
    EXCEPTION for the given socket.  I assume that when the SELECT
    times out without the exception occurring that this exec has an
    error path here (possibly producing a message).  If so, add
    performing a TAKESOCKET to retrieve what was given, then CLOSE
    both copies of that socket    (the original and the result of
    the TAKESOCKET).  This is the recommended practice when using
    the GIVESOCKET call, anyway.
    
     - Use different subtask IDs on every INITIALIZE call.  I
    already  mentioned this recommendation so that each active REXX
    environment has a unique identifier.  But if the main task could
    calculate a 'random' name (like including the time as a part of
    it), that would  significantly reduce the possibility of a
    stranded entry being a match.
    

Local fix

  • n/a
    

Problem summary

  • ****************************************************************
    * USERS AFFECTED: All Tivoli Event Pump for z/OS users.        *
    ****************************************************************
    * PROBLEM DESCRIPTION: Tivoli Event Pump for z/OS hangs after  *
    *                      PURGE operator command and can be       *
    *                      stopped only by issuing CANCEL command. *
    *                      System log contains GTM5428E message    *
    *                      indicating TAKESOCKET issue for         *
    *                      internal Tivoli Event Pump for z/OS     *
    *                      HTTP server.                            *
    ****************************************************************
    * RECOMMENDATION: Apply the PTF.                               *
    ****************************************************************
    Tivoli Event Pump for z/OS generates the following error message
    in system log:
    
        GTM5428E HTTP SERVER : TAKESOCKET FOR SOCKET 2 FAILED WITH
        RC = 22, RS = EINVAL Invalid argument
    
    Any attempt to stop the Tivoli Event Pump for z/OS address space
    leads to hang of the application. CANCEL command can be used to
    stop hanged address space. The following abends can occure
    during the processing of the CANCEL command:
    
    IEA995I SYMPTOM DUMP OUTPUT  176
    SYSTEM COMPLETION CODE=0C4  REASON CODE=00000004
     TIME=18.04.12  SEQ=08017  CPU=0000  ASID=00FC
     PSW AT TIME OF ERROR  478D0000   C0147286  ILC 2  INTC 04
       ACTIVE LOAD MODULE          ADDRESS=40146F18  OFFSET=0000036E
       NAME=GTMAOP16
       DATA AT PSW  40147280 - 181F18E3  0E0E18F4  12FF4780
       AR/GR 0: 00000000/4200D000   1: 00000000/FFFF47BE
             2: 01FF0028/FFFFC65E   3: 00000000/09C03E58
             4: 00000000/00005840   5: 00000000/09C004B6
             6: 00000000/00000000   7: 00000000/41C37E58
             8: 00000000/401578F0   9: 00000000/40221CE0
             A: 00000000/401574B8   B: 00000000/C0146F18
             C: 00000000/40147F18   D: 00000000/41C37EAC
             E: 00000000/09C0BCF8   F: 00000C05/FFFF47BE
     END OF SYMPTOM DUMP
    BPXP018I THREAD 4062A00000000002, IN PROCESS 67633175, ENDED 184
    WITHOUT BEING UNDUBBED WITH COMPLETION CODE 040C4000
    , AND REASON CODE 00000004.
    BPXP018I THREAD 40656A000000000C, IN PROCESS 67633175, ENDED 210
    WITHOUT BEING UNDUBBED WITH COMPLETION CODE 040C4000
    , AND REASON CODE 00000004.
    IEA995I SYMPTOM DUMP OUTPUT  213
    SYSTEM COMPLETION CODE=0C4  REASON CODE=00000011
     TIME=18.04.14  SEQ=08068  CPU=0000  ASID=00FC
     PSW AT TIME OF ERROR  478D0000   89C31F56  ILC 4  INTC 11
       NO ACTIVE MODULE FOUND
       NAME=UNKNOWN
       DATA AT PSW  09C31F50 - 30074770  81665550  40004740
       AR/GR 0: 008E5DB4/42021284   1: 00000000/001015B0
             2: 00000000/8B000000   3: 00000000/4200B000
             4: 00000000/04F07170   5: 00000000/424DB421
             6: 00000000/41F23000   7: 00000000/00000001
             8: 00000000/89C31EA6   9: 00000000/424DB420
             A: 00000000/42023040   B: 00000000/00000200
             C: 00000000/09C2F8B0   D: 00000000/42021598
             E: 00000000/89C2FA56   F: 00000000/42023040
     END OF SYMPTOM DUMP
    IEA995I SYMPTOM DUMP OUTPUT  214
    SYSTEM COMPLETION CODE=0C4  REASON CODE=00000004
     TIME=18.04.14  SEQ=08068  CPU=0000  ASID=00FC
     PSW AT TIME OF ERROR  478D1000   89BFAC8E  ILC 4  INTC 04
       NO ACTIVE MODULE FOUND
       NAME=UNKNOWN
       DATA AT PSW  09BFAC88 - 06904490  C86A18E5  5EE0B198
       GR 0: 42022C90   1: 422E16E4
          2: 42023CB8   3: 00000001
          4: 00000000   5: 000000B4
          6: 00000004   7: 00000000
          8: 00000000   9: 0000003B
          A: 0000003C   B: 422E1560
          C: 09BFA460   D: 422E1560
          E: 42023CB4   F: 09BFA460
     END OF SYMPTOM DUMP
    BPXP018I THREAD 4062C2000000000A, IN PROCESS 67633175, ENDED 215
    WITHOUT BEING UNDUBBED WITH COMPLETION CODE 940C4000
    , AND REASON CODE 00000004.
    
    There is a problem with a control structure associated with the
    REXX sockets use of GIVESOCKET/TAKESOCKET calls which is not
    being cleaned up when the nobody takes it. HTTP server main task
    does not perform TAKESOCKET cleanup call when child tasks don't
    take given socket. HTTP server always uses the same subtask ID
    in socket set INITIALIZE call for a  different instances of
    child tasks. This can lead to incorrect selection of given
    sockets from a socket sets assotiated with Tivoli Event Pump
    for z/OS address space.
    

Problem conclusion

  • TAKESOCKET call was added to parent task of HTTP server for
    cases when child tasks don't perform GIVESOCKET for a passed
    socket. This condition is considered as an error state and leads
    to stop HTTP server. Every socket set in a child task is
    initialized with unique subtask ID. This significantly reduce
    the possibility of issues reported in this APAR.
    

Temporary fix

Comments

APAR Information

  • APAR number

    OA40383

  • Reported component name

    EVENT PUMP FOR

  • Reported component ID

    5698B3400

  • Reported release

    422

  • Status

    CLOSED PER

  • PE

    NoPE

  • HIPER

    NoHIPER

  • Special Attention

    NoSpecatt

  • Submitted date

    2012-09-17

  • Closed date

    2012-10-16

  • Last modified date

    2013-03-04

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

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

    UA66930

Modules/Macros

  • GTMIPCRH GTMIPSRV
    

Fix information

  • Fixed component name

    EVENT PUMP FOR

  • Fixed component ID

    5698B3400

Applicable component levels

  • R422 PSY UA66930

       UP13/02/27 P F302

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

Add comments

Document information


More support for:

Tivoli Event Pump for z/OS

Software version:

422

Reference #:

OA40383

Modified date:

2013-03-04

Translate my page

Machine Translation

Content navigation