Improve cancel handler to avoid hang situations when ending jobs that behaves badly.

Cancel handlers can be part of the application or they can also be part of the operating system. Basically, any program can provide a cancel handler that will run when the program gets interrupted and the call stack entries are terminated by something other than a normal return. The cancel handler needs to be very careful about what it does -- it needs to quickly cleanup (ie. unlock locks, undo operations that are incomplete, cleanup temporary objects, and so on). But cancel handlers should never wait forever (ie. for a message or a socket or an event) since the sending thread may already have ended.  There is no single "cancel handler" processing point that can be "fixed" to avoid hangs. Generally, you need to capture and analyze the call stacks of the hung jobs to determine where they were hung, what they were waiting on and then make the necessary code change. If the cancel handler is an operating system program, a PTF may be required. If the cancel handler is an application program, the application needs to be fixed. 

The only thing the operating system can do is provide the "big hammer" to end the hung job, which is what ENDJOBABN command is used for.  In 7.2 and later releases we added the Abnormal End Delay Time (ABNENDDLY) parameter to the ENDSBS command that will automatically do the ENDJOBABN command for you when running in batch restricted state, and restricted state has not been reached within the Batch Time Limit (BCHTIMLMT).

Cancel handlers can be part of the application or they can also be part of the operating system. Basically, any program can provide a cancel handler that will run when the program gets interrupted and the call stack entries are terminated by something other than a normal return. The cancel handler needs to be very careful about what it does -- it needs to quickly cleanup (ie. unlock locks, undo operations that are incomplete, cleanup temporary objects, and so on). But cancel handlers should never wait forever (ie. for a message or a socket or an event) since the sending thread may already have ended. There is no single "cancel handler" processing point that can be "fixed" to avoid hangs. Generally, you need to capture and analyze the call stacks of the hung jobs to determine where they were hung, what they were waiting on and then make the necessary code change. If the cancel handler is an operating system program, a PTF may be required. If the cancel handler is an application program, the application needs to be fixed.

The only thing the operating system can do is provide the "big hammer" to end the hung job, which is what ENDJOBABN command is used for. In 7.2 and later releases we added the Abnormal End Delay Time (ABNENDDLY) parameter to the ENDSBS command that will automatically do the ENDJOBABN command for you when running in batch restricted state, and restricted state has not been reached within the Batch Time Limit (BCHTIMLMT).

Will have to agree with IBM on this one as what you're experiencing is called a wait state. You are the one that will have to modify your programs to respond to the termination signals.

Good luck, IBM design from inception!