A job the is having trouble might be unable to end normally. The ENDJOBABN command is intended to help with that condition for such jobs, but that should be thought of as a next-to-last resort.

Normally, ENDSBS QINTER OPTION(*CNTRLD) DELAY(30) should give sufficient time to expect that jobs that watched for a shutdown request would have responded. After 30 seconds elapsed, the remaining jobs would be sent a signal as if ENDJOB OPTION(*IMMED) was sent to each of them. Each may take a few seconds to run the end-of-job processes such as converting messages in the job’s external message queue into a spooled joblog. (Under extreme circumstances, a job can take quite a few minutes simply getting that done.)

After some delay (usually determined by experience on that system), the subsystem status can retrieved to see if it’s finished shutting down. That might indicate looping back for one or more additional delays and status tests.

At some point, logic determines that things have taken too long. This might be when the list of still-active jobs is retrieved from the subsystem. Each job on the list might then be processed with ENDJOBABN. Be aware of the ENDJOBABN help text; for example “The ENDJOBABN command cannot be issued against a job until 10 minutes have passed following the request for immediate ending.” Additional considerations are noted in the help text, particularly for possible effects that may need attention at the next IPL.

In short, it can take some programming if you want to cover unusual conditions. Or you can have an operator sit while waiting.

One of the most troublesome parts is getting a subsystem restarted when it gets stuck going down.

Tom

You can lead a horse to water, but you can not make it drink.