A fix is available
APAR status
Closed as program error.
Error description
CICS tasks are hung in LMQUEUE suspends due to a deadlock or deadly embrace between 2 tasks. One task owns the SMLOCK and needs a Subpool lock, while the 2nd task owns the Subpool lock and needs the SMLOCK. The needed Subpool lock is for the APDWE domain. (You can determine which subpool lock is needed by using the Lock Token for the Subpool lock in Lock Manager's Allocated Locks summary. The Lock token will point within the SCA control block for the APDWE subpool in the SM domain). . The deadlock can occur when 2 tasks are simultaneously trying to get the APDWE subpool lock, running on different TCBs. The problem is in DFHICP, in the ICGETDWE routine. The DFHSMGFI macro includes a domain call to Lock Manager for an UNLOCK request, but the request expects R3 to point to DFHICP's static area. However, R3 has been used to save R2 and is currently pointing to DFHICP's stack. This causes the UNLOCK request to fail and the task ends up never releasing the Subpool lock. . Additional Symptom(s) Search Keyword(s): KIXREVSCB DWE SUBLOCK_GET START TSLOCK DFHTSPT HANG HUNG
Local fix
Problem summary
**************************************************************** * USERS AFFECTED: All CICS users. * **************************************************************** * PROBLEM DESCRIPTION: Multiple tasks become suspended in * * LMQUEUE suspends, waiting for a lock on * * the APDWE storage subpool. * **************************************************************** * RECOMMENDATION: * **************************************************************** DFHICP needs to get a lock on the APDWE storage subpool in order to getmain a DWE. It successfully gets the lock, and performs the getmain. Meanwhile, another task also needs the APDWE subpool lock, and adds itself as a waiter for that lock. In the first task, DFHICP needs to perform a domain call to lock manager to release the lock, but due to a register conflict, that domain call is made with invalid data in the domain call parameter list. In the reported case, this led to the lock manager domain call incorrectly setting the LMLM_OWNER_TOKEN_X existence bit, and lock manager replying with an LMLM_EXCEPTION, reason code LMLM_NOT_LOCK_OWNER. The lock was not released, causing all future tasks requiring that lock to wait. . Additional Keywords: DFHSM0002 031E
Problem conclusion
The register conflict in DFHICP has been corrected, thereby enabling the APDWE storage subpool to be released correctly.
Temporary fix
********* * HIPER * ********* FIX AVAILABLE BY PTF ONLY
Comments
APAR Information
APAR number
PI39408
Reported component name
CICS TS Z/OS V5
Reported component ID
5655Y0400
Reported release
900
Status
CLOSED PER
PE
NoPE
HIPER
YesHIPER
Special Attention
NoSpecatt
Submitted date
2015-04-20
Closed date
2015-05-08
Last modified date
2015-06-01
APAR is sysrouted FROM one or more of the following:
APAR is sysrouted TO one or more of the following:
UI27598
Modules/Macros
DFHICP
Fix information
Fixed component name
CICS TS Z/OS V5
Fixed component ID
5655Y0400
Applicable component levels
R900 PSY UI27598
UP15/05/22 P F505 ½
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":"BU058","label":"IBM Infrastructure w\/TPS"},"Product":{"code":"SSGMGV","label":"CICS Transaction Server"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"5.2","Edition":"","Line of Business":{"code":"LOB35","label":"Mainframe SW"}},{"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":"5.2","Edition":"","Line of Business":{"code":"","label":""}}]
Document Information
Modified date:
01 June 2015