IBM Support

PI83503: WebSphere Liberty servers with zOS connect failing to start with abend 0c4 in wolanativeutils.ntv_activatewolaregistration

Subscribe

You can track all active APARs for this component.

 

APAR status

  • Closed as program error.

Error description

  • Javacore at the time of the startup failure shows:
    
    Java callstack:
    4XESTACKTRACE                at
    com/ibm/ws/zos/channel/wola/internal/natv/WOLANativeUtils.nt
    v_ac
    tivateWolaRegistration(Native Method)
    4XESTACKTRACE                at
    com/ibm/ws/zos/channel/wola/internal/natv/WOLANativeUtils.ac
    tiva
    teWolaRegistration(WOLANativeUtils.java:160)
    4XESTACKTRACE                at
    com/ibm/ws/zos/channel/wola/internal/WOLAChannel.start(WOLAC
    hann
    el.java:108)
    

Local fix

  • n/a
    

Problem summary

  • ****************************************************************
    * USERS AFFECTED:  All users of IBM WebSphere Application      *
    *                  Server Liberty for z/OS                     *
    ****************************************************************
    * PROBLEM DESCRIPTION: An ABEND0C4/ABENDS0C4 occurs during     *
    *                      Liberty startup while activating WOLA   *
    ****************************************************************
    * RECOMMENDATION:                                              *
    ****************************************************************
    When a Liberty server starts, it activates its WOLA
    registration.  The WOLA registration allows clients to find and
    communicate with this Liberty server instance.  The Liberty
    server locates its registration on the WOLA registration queue
    using the server's three part WOLA name.  If the queue of WOLA
    registrations is very long, the task traversing the registration
    queue can exhaust its C stack and begin trying to use the guard
    page of storage immediately following the C stack.  This results
    in an ABEND0C4/ABENDS0C4.
    
    The queue of WOLA registrations was long because client
    processes were not removing themselves from the WOLA
    registration queue during client termination.  Client
    registrations can be removed by calling the BBOA1URG service.
    However if a client does not call the BBOA1URG service,
    outstanding registrations are cleaned up when the WOLA RESMGR
    runs at client termination.  In some cases, the WOLA RESMGR is
    not able to clean up registrations for a client that was
    terminating.  This can lead to the registration queue becoming
    long.
    

Problem conclusion

  • Code was added to prevent the Liberty server from exhausting its
    C stack while traversing the WOLA registration queue.
    Code was added to clean up outstanding client WOLA registrations
    when a client address space terminates.
    
    The fix for this APAR is currently targeted for inclusion in fix
    pack 17.0.0.3.  Please refer to the Recommended Updates page for
    delivery information:
    http://www.ibm.com/support/docview.wss?rs=180&uid=swg27004980
    

Temporary fix

Comments

APAR Information

  • APAR number

    PI83503

  • Reported component name

    LIBERTY PROF -

  • Reported component ID

    5655W6514

  • Reported release

    CD0

  • Status

    CLOSED PER

  • PE

    NoPE

  • HIPER

    NoHIPER

  • Special Attention

    NoSpecatt / Xsystem

  • Submitted date

    2017-06-26

  • Closed date

    2017-08-10

  • Last modified date

    2017-08-10

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

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

Fix information

  • Fixed component name

    LIBERTY PROF -

  • Fixed component ID

    5655W6514

Applicable component levels

  • RCD0 PSY

       UP

[{"Business Unit":{"code":"BU011","label":"Systems - zSystems software"},"Product":{"code":"SG19M"},"Platform":[{"code":"PF054","label":"z/OS"}],"Version":"CD0"}]

Document Information

Modified date:
16 June 2021