IBM Support

PM06314: TELNET S0C4 IN GSK_SECURE_SOCKET_INIT AFTER TELNET SSL TASK RESTARTED

A fix is available

Subscribe

You can track all active APARs for this component.

 

APAR status

  • Closed as program error.

Error description

  • An abend in Telnet's SSL task occurred, causing Telnet to
    reattach the SSL task.  When Telnet tried to start new
    secure connections on the task, each connection abended in
    gsk_secure_socket_init +29C trying to use an invalid pointer to
    the getpeername function.
    The following messages were seen showing the original error
    and the errors after the SSL task was reattached:
    EZZ6005I TELNET SSL TASK TERMINATED, RSN =    0.
    EZZ6005I TELNET SSL TASK RESTART ATTEMPTED, RSN =    0.
    EZZ4215I TELNET ABEND - DUMPING
    EZZ6034I TELNET CONN 00001607 LU **N/A** CONN DROP 6002
      IP..PORT: xxx.xx.xxx.xxx..3349               EZBTTSMT
    .
    There may also be a CEEDUMP for a U4094 produced with message
    CEE3204S The system detected a protection exception (System
    Completion
    Code=0C4)
    From entry point gsk_secure_socket_init at compile unit offset
    +0000029C
    at entry offset +0000029C at address 0EC59F34.
    

Local fix

Problem summary

  • ****************************************************************
    * USERS AFFECTED: All users of Communications Server for       *
    *                 z/OS Version 1 Release 9,                    *
    *                 z/OS Version 1 Release 10, and               *
    *                 z/OS Version 1 Release 11 IP Telnet          *
    *                 facilities using SSL.                        *
    ****************************************************************
    * PROBLEM DESCRIPTION: CEEDUMP reports an abend0c4 in          *
    *                      routine gsk_secure_socket_init at       *
    *                      offset x'29C' following reattach        *
    *                      of the Telnet SSL task.                 *
    ****************************************************************
    * RECOMMENDATION:                                              *
    ****************************************************************
    The problem is summarized as follows:
    
    1. A Telnet server was started using a configuration which
       specified a SECUREPORT.
    
    2. At some point in time, a U4088 abend occurred during SSL
       processing.  Documentation was not available to determine
       the reason for this abend.  Telnet recovery processing
       reattached the SSL task (EZBTTSSL).  Subsequent
       connections to the secure port, however, resulted in
       an abend0c4 in routine gsk_secure_socket_init.  This
       abend was diagnosed from a CEEDUMP.
    
    4. The abend in gsk_secure_socket_init occurred because of
       a residual pointer.  When the Telnet SSL task was
       reattached, pointers associated with the GSKSSL load
       module were not reset and still referred to the old
       instance of the load module.
    +-------------------------------------------------------------+
    + 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

  • To resolve this problem, Telnet will be modified to
    associate the GSKSSL load module with the EZBTZMST task.
    The GSKSSL load module is loaded by EZBTZMST during
    Telnet initialization, and will now be unloaded when
    the EZBTZMST task terminates (Telnet is ended).  The
    Telnet SSL task,  EZBTTSSL, will no longer load GSKSSL.
    
    * Cross Reference between External and Internal Names
    

Temporary fix

Comments

APAR Information

  • APAR number

    PM06314

  • Reported component name

    TCP/IP V3 MVS

  • Reported component ID

    5655HAL00

  • Reported release

    190

  • Status

    CLOSED PER

  • PE

    NoPE

  • HIPER

    NoHIPER

  • Special Attention

    NoSpecatt / Xsystem

  • Submitted date

    2010-01-29

  • Closed date

    2010-03-02

  • Last modified date

    2010-04-03

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

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

    UK54819 UK54820 UK54821

Modules/Macros

  • EZBTZMST
    

Fix information

  • Fixed component name

    TCP/IP V3 MVS

  • Fixed component ID

    5655HAL00

Applicable component levels

  • R1A0 PSY UK54819

       UP10/03/31 P F003

  • R1B0 PSY UK54820

       UP10/03/31 P F003

  • R190 PSY UK54821

       UP10/03/31 P F003

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":"BU054","label":"Systems w\/TPS"},"Product":{"code":"SG19M","label":"APARs - z\/OS environment"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"190","Edition":"","Line of Business":{"code":"","label":""}},{"Business Unit":{"code":"BU054","label":"Systems w\/TPS"},"Product":{"code":"SSCY4DZ","label":"DO NOT USE"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"190","Edition":"","Line of Business":{"code":"","label":""}}]

Document Information

Modified date:
03 April 2010