A fix is available
APAR status
Closed as program error.
Error description
You recycled your CMAS and on restart, some of the MASes failed to Topology Connect to the CMAS. The following message is issued in the CMAS: . EYUTS0002E applid TOPOLOGY CONNECT FOR masname FAILED . In the trace we see the following exception entries for the TSSC task: . Mtd Prev Tran Obj Level Pt-ID Debug UOW CMAS/Usr Envr XSRA XCLR TSSC SRV Excp 5 RESIHELD CPSM cmasname CMAS XCLR XCLL TSSC CHE Excp 27 RESACQF CPSM cmasname CMAS TSRA TSSC TSSC TOP Excp 7 TSRAXCLR CPSM cmasname CMAS TSSC XLOP TSSC TOP Excp 15 TSSCTSRA CPSM cmasname CMAS . In this RESIHELD and RESACQF failure, we went to get a lock on a resource and found we already had it SHARED but now we want it EXCLUSIVE. The XCLR RESACQF trace indicates we are trying to do a DELETE_ELEMENT request for a TranClass and need exclusive control of the cache list lock. However this task already has shared control of the lock out of XCLL so the resource acquire failed resulting in the Topology connect for the MAS to fail. Additional Symptom(s) Search Keyword(s): KIXREVGJT
Local fix
Problem summary
**************************************************************** * USERS AFFECTED: All CICSPlex SM V4R2M0 Users * **************************************************************** * PROBLEM DESCRIPTION: - When a CMAS is recycled while a MAS * * connected to it remains active, * * Topology Connect to the MAS may fail * * with message EYUTS0002E, if while * * the CMAS was down, a transaction * * class resource that was previously * * installed in the MAS through BAS * * (TRNCLDEF) is discarded from the * * MAS. * * * * The text of the message will be * * similar to the following: * * * * EYUTS0002E Topology Connect for * * <masname> Failed - * * APPLID(<masappl>) * * CICSplex(<plexname>). * * * * Examination of the CMAS's auxtrace * * datasets will show the following * * trace records: * * * * Method Caller TPID Debug text * * ------ ------ ---- ---------- * * XSRA XCLR 5 RESIHELD * * XCLR XCLL 27 RESACQF * * TSRA TSSC 7 TSRAXCLR * * TSSC XLOP 15 TSSCTSRA * * * * - When the Topology connect process * * fails, and the CMAS issues the * * EYUTS0002E error message, the MAS * * may not recognize this until the * * MASINITWAIT EYUPARM time has * * expired. * * * * If this occurs during CICS * * initialization of the MAS, and the * * MASPLTWAIT EYUPARM is set to YES, * * then the MAS will delay the PLT * * process until the MASINITIME has * * expired. * * * * Until the MASINITIME has expired, it * * is not possible to issue the COLM * * transaction to retry the MAS * * connect. * * * * Finally, when the MASINITIME has * * expired, the MAS will issue message * * EYUNL0901I indicating that * * termination has been initiated, but * * there is no indication that * * termination was initiated because * * Topology connect failed. * **************************************************************** * RECOMMENDATION: After applying the PTF that resolves this * * APAR, all CMASes must be restarted. Note * * that the restarts do not need to occur at * * the same time. * **************************************************************** - When a CMAS is recycled while a MAS that was connected to it remains active, the CMAS will attempt to re-connect to the MAS. During this process, method EYU0TSRA (TSRA), running under a TSSC task in the CMAS, will synchronize the BAS install list for the MAS, a list of all CICS resources installed in the MAS through BAS, removing entries for resources which are no longer installed in the MAS. To synchronize the list for transaction class resources, TSRA calls method EYU0XCLL (XCLL) to compare the BAS install list with a list of the installed transaction class resources in the MAS. If XCLL finds an entry in the BAS list which is no longer installed in the MAS, it calls method EYU0XCLR (XCLR) to remove the entry from the BAS install list. When XCLL is called, it requests a shared lock for the BAS install list. If it calls XCLR, that lock request is still active. XCLR will then request the lock exclusive. This conflicting request is not allowed, and the XCLR lock request is failed. This is propagated back to TSRA, which will fail the connect request. - As part of the Topology connect process, method EYU0TSSC (TSSC) will send a request to run method EYU0NLGT (NLGT) in the MAS through a communications request to collect information on all CICS resources installed in the MAS. If Topology connect fails, the CMAS will attempt to send a shutdown request to the MAS, so that it terminates the connect process immediately. It does this by having method TSSC send a request to run method EYU0NLSD (NLSD) in the MAS through a communications request. Since TSSC can only have one active communications request to the MAS, there is a check in TSSC to determine if the NLGT request is still active when the connect process fails, and if so, to bypass sending the NLSD request to the MAS. However, the check performed by TSSC is invalid if the NLGT request was sent to the MAS and has returned. Finally, if TSSC sends an NLSD request to the MAS, it does not indicate that this is because the CMAS is failing the connect process.
Problem conclusion
- Instead of calling XCLR to remove a transaction class resource that is no longer installed, XCLL will write the BAS install list key information for the resource to a work queue. When XCLL has completed the list compare, it will free the lock and return to TSRA. TSRA will then read the work queue, and call XCLR for each entry in the queue. - TSSC has been updated to recognize when the NLGT request has completed, so that subsequent failures during the Topology connect process will result in NLSD being sent to the MAS. Additionally, when TSSC sends the NLSD request to the MAS, it will indicate in the request that the CMAS has initiated the shutdown request. This will result in message EYUNL0906E being issued by the MAS. The text of this message will be similar to the following: EYUNL0906E The CMAS has initiated a shutdown of the MAS agent. See the CMAS job log for additional information.
Temporary fix
FIX AVAILABLE BY PTF ONLY
Comments
APAR Information
APAR number
PI11306
Reported component name
CICS TS Z/OS V4
Reported component ID
5655S9700
Reported release
70M
Status
CLOSED PER
PE
NoPE
HIPER
NoHIPER
Special Attention
NoSpecatt
Submitted date
2014-02-07
Closed date
2014-02-26
Last modified date
2014-03-03
APAR is sysrouted FROM one or more of the following:
APAR is sysrouted TO one or more of the following:
PI11792 UI15476
Modules/Macros
EYU0TSRA EYU0TSSC
Fix information
Fixed component name
CICS TS Z/OS V4
Fixed component ID
5655S9700
Applicable component levels
R70M PSY UI15476
UP14/02/28 P F402
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":"4.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":"4.2","Edition":"","Line of Business":{"code":"","label":""}}]
Document Information
Modified date:
03 March 2014