Document ID : KB000097709
Last Modified Date : 23/05/2018
Show Technical Document Details
We are using SYSVIEW to try to cancel CICS transactions that reach certain CPUTIME threshold limits.
Recently it looks like SYSVIEW tried to cancel a transaction and for whatever reason, the trans didn't come down.
17.23.45 STC64243 GSVC157I (SDCS) Tran D110 Task 5775 to be cancelled by threshold. 876 876 Jobname ZSANCMU Metric CPUTIME Rsce1 = Rsce2 = 876 CanLimit 00:03:00 Policy=002A3210
17.23.45 STC64243 GSVC101I (SDCS) GSVCSDCS has issued a CANCEL for the transaction D110 5775 ZSANCMU
17.23.45 STC64243 GSVC102I (SDCS) CANCEL Tran D110 Task 5775 WaitType WAITING WaitName DISPATCHABLE Jobname ZSANCMU 17.23.47 STC64243 +GSVC150W (GSVI) Function NORMAL_CANCEL Response 02 EXCEPTION Reason 03 INVALID_STATE
I'm curious what the GSVC150W Response 02 EXCEPTION Reason 03 INVALID_STATE. (manual didn't show anything else) 
The cancel was not executed by CICS probably due to the state of the transaction.
The thing to keep in mind for any of these cancel requests is that the transaction is running under the control of CICS. SYSVIEW is simply asking CICS to perform some flavor of cancel against the transaction, but it is still CICS that is in control of if/when any action will be taken.
Similar to the MVS CANCEL and FORCE commands; you are asking MVS to take an action against an address space and sometimes he can and sometimes he can't, depending on the state of the address space.
The only way to know why the NORMAL_CANCEL failed, or why the transaction was in the INVALID_STATE, is to talk to CICS support.
There may be a reasonable explanation, but I cannot provide it.
SYSVIEW can request the action but CICS is the one that must carry it out.