IBM Support

PI95676: IN USE COUNT CAN BE WRONG AFTER APAR PI77049 - CAUSING ABEND=00DC3000 RSNCODE=0A150001

Subscribe

You can track all active APARs for this component.

 

APAR status

  • Closed as program error.

Error description

  • An ABENDDC3 REASONCODE=0A150001 indicates that a starting
    server is requesting to update the level of code of its
    NODE but the current NODE level code is still in-use.  In this
    case, there is no longer any active server using the NODE level
    code in question.  This "in-use" indication is like a reference
    count.  As each user of the NODE level code (server)
    initializes it increments the reference count.  As the server
    terminates--it decrements the "in-use" count.
    
    The NODE level code contains routines that are used by both the
    Controller and Servant.  The "in-use" of the NODE level code is
    partly managed by RESMGR routines (routines that run at
    end-of-memory of an address space). Decrementing the "in-use"
    count occurs within the RESMGR routines.   In the case were a
    server has servants, its the roll of the last address space
    terminating to decrement in the server's "in-use" count for the
    NODE level code.
    
    APAR PI77049 was taken to fix a problem where the code
    mistakenly decremented the "in-use" count when a server was
    starting with new NODE level code when an existing server of
    the NODE was still running (it was still "in-use").   The
    attempt to start the server failed the first time, but the
    "in-use" count was decremented and if attempted again the
    server would be allowed to replaced the current NODE level code
    while the 1 existing server was still using it.
    
    The fix for PI77049 went into levels WAS 8.5.5.12 and WAS
    9.0.0.4.
    
    If a Daemon is running with PI77049 and a server is running
    pre-PI77049 then there is an exposure that could result in
    skipping the decrement of the NODE level code "in-use" count.
    The problem happens if the server has servants and a servant
    address space is the last address space of the server to
    terminate.   On normal termination of the server (stop command)
    this will not happen.    The servant may be the last address
    space to terminate for the server if the Controller terminated
    abnormally, was cancelled, or forced.    If this is the case,
    then RESMGR code that PI77049 updated is driven for the
    servant, but the decrement of the NODE level "in-use" count is
    skipped because part of fix in based on "current" NODE level
    code which is pre-PI77049 in this scenario.
    
    This will cause the ABENDDC3,RSN=0A150001 when the server
    attempts to change its level of code.
    
    VERIFICATION STEPS:
    From a dump of the system, use this IPCS command to scan all
    the active Address spaces and dump the related WebSphere node
    name if present:
    ip runarray addr(00F9DA70) length(4) dimension(x'2164') exec((l
    x?+150?+1AC?+240 l(8)))
    
    The address above is from the ASVT's first slot:
    ASVT:=V(V(10)+22C)+1E0
    FirstSlot:=ASVT+30
    
    If the node name for the problem server doesn't show up, there
    are no active servers in that node.
    

Local fix

  • Do not cancel or force the control region while the Daemon is
    at level APAR PI77049  and the node is not.
    The use count is kept a control block that is allocated when
    the first server in the cell is started.  So if the use count
    is bad, to get out of this issue you need to IPL.  If this is
    not an option, open a pmr asking for a tool that can be run
    (with all servers in the cell down) that cleans up this control
    block so when the first server is started in the cell, the
    control block is re-allocated.
    

Problem summary

  • ****************************************************************
    * USERS AFFECTED:  All users of IBM WebSphere                  *
    *                  Application Server for z/OS V8.5            *
    ****************************************************************
    * PROBLEM DESCRIPTION: On WebSphere Application Server for     *
    *                      z/OS an abend DC3 reason code 0A150001  *
    *                      can occur when starting a server even   *
    *                      though there are no other servers or    *
    *                      daemon up using the node level code.    *
    ****************************************************************
    * RECOMMENDATION:                                              *
    ****************************************************************
    When the daemon has been migrated to 8.5.5.12 or 8.5.5.13 and
    the controller of a server running at a level lower than
    8.5.5.12 is canceled or forced, a subsequent start of the
    server to a level that is different than the servers current
    level will get an ABENDDC3/ABENDSDC3 reason code 0A150001.
    This is because the code level in use count for the node does
    not get decremented when a servant of the down level server
    goes thru the address space level resource manager after the
    controller. This is also true for a daemon that has been
    migrated to 9.0.0.4 thru 9.0.0.7.
    The reason for the missed decrement is because a flag added
    by PI77049 and checked by the address space level resource
    does not get set in a down level servant.
    

Problem conclusion

  • Changed the code in the address space level resource manager to
    decrement the node level in use count when a servant of a
    canceled or forced down level server is the last address space
    to terminate.
    
    The fix for this APAR is currently targeted for inclusion in
    fix packs 8.5.5.14 and 9.0.0.8.  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

    PI95676

  • Reported component name

    WEBSPHERE FOR Z

  • Reported component ID

    5655I3500

  • Reported release

    850

  • Status

    CLOSED PER

  • PE

    NoPE

  • HIPER

    NoHIPER

  • Special Attention

    NoSpecatt / Xsystem

  • Submitted date

    2018-03-23

  • Closed date

    2018-05-18

  • Last modified date

    2018-05-24

  • 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

    WEBSPHERE FOR Z

  • Fixed component ID

    5655I3500

Applicable component levels

  • R850 PSY

       UP

[{"Business Unit":{"code":"BU059","label":"IBM Software w\/o TPS"},"Product":{"code":"SS7K4U","label":"WebSphere Application Server for z\/OS"},"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"850","Line of Business":{"code":"LOB45","label":"Automation"}}]

Document Information

Modified date:
06 December 2021