Fixes are available
9.0.0.8: WebSphere Application Server traditional V9.0 Fix Pack 8
8.5.5.14: WebSphere Application Server V8.5.5 Fix Pack 14
9.0.0.9: WebSphere Application Server traditional V9.0 Fix Pack 9
9.0.0.10: WebSphere Application Server traditional V9.0 Fix Pack 10
8.5.5.15: WebSphere Application Server V8.5.5 Fix Pack 15
9.0.0.11: WebSphere Application Server traditional V9.0 Fix Pack 11
9.0.5.0: WebSphere Application Server traditional Version 9.0.5 Refresh Pack
9.0.5.1: WebSphere Application Server traditional Version 9.0.5 Fix Pack 1
9.0.5.2: WebSphere Application Server traditional Version 9.0.5 Fix Pack 2
8.5.5.17: WebSphere Application Server V8.5.5 Fix Pack 17
9.0.5.3: WebSphere Application Server traditional Version 9.0.5 Fix Pack 3
9.0.5.4: WebSphere Application Server traditional Version 9.0.5 Fix Pack 4
9.0.5.5: WebSphere Application Server traditional Version 9.0.5 Fix Pack 5
WebSphere Application Server traditional 9.0.5.6
9.0.5.7: WebSphere Application Server traditional Version 9.0.5 Fix Pack 7
9.0.5.8: WebSphere Application Server traditional Version 9.0.5.8
8.5.5.20: WebSphere Application Server V8.5.5.20
8.5.5.18: WebSphere Application Server V8.5.5 Fix Pack 18
8.5.5.19: WebSphere Application Server V8.5.5 Fix Pack 19
9.0.5.9: WebSphere Application Server traditional Version 9.0.5.9
9.0.5.10: WebSphere Application Server traditional Version 9.0.5.10
8.5.5.16: WebSphere Application Server V8.5.5 Fix Pack 16
8.5.5.21: WebSphere Application Server V8.5.5.21
9.0.5.11: WebSphere Application Server traditional Version 9.0.5.11
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
Document Information
Modified date:
04 May 2022