You can handle a STOP command by having a separate TCB within your
address space act as an operator interface. You can configure your TCB
structure such that the TCB receiving the STOP command can tell the
worker TCB to quit. You can DETACH the worker TCB if it does not end on
its own in a reasonable amount of time. In such a scenario, you can
cause your cleanup code to run in several ways including, but not
limited to, an ETXR for the worker TCB.
--
Regards, Gord Tomlin
Action Software International
(a division of Mazda Computer Corporation)
Tel: (905) 470-7113, Fax: (905) 470-6507
On 2012-07-13 12:45, Charles Mills wrote:
Here's where I am on this:
- STOP requires that the program "notice" the command. STOP won't stop a loop, either an endless
loop from a program logic error, or perhaps some process that "takes a long time" and where the
programmer neglects to check the "stop flag."
- So CANCEL has a role that STOP does not fill. For programs that allocate system
resources of some sort -- CSA in my case -- I have tentatively made the decision that the
ability to clean up after myself in a CANCEL situation outweighs the illogic of "you
cancelled me ... but wait! There's a little more I want to do."
Yeah, in a perfect world there would be no bugs. But I had a bug in the field
(the first in 18 months!) that resulted in a loop, a CANCEL, and a modest mess
in CSA.
Yes, I will fix the root cause bug. Yes, I resolve to be more careful in the
future -- maybe one error in the field every 36 months. But if this should
happen again ...
Your suggestion for how to proceed?
BTW, this is z/OS batch (STC actually). Does operator CANCEL generate a
SIGKILL? Or ...?
Charles
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf
Of Paul Gilmartin
Sent: Friday, July 13, 2012 9:11 AM
To: [email protected]
Subject: Re: Relationship of C signals to z/OS terminology?
On Fri, 13 Jul 2012 08:39:37 -0700, Charles Mills wrote:
I mean, gee, SIGILL is documented as "Invalid object module (hardware
and software)."
I didn't know that! SIGKILL is routinely used from command lines as an
unconditional cancel, because SIGKILL can't be caught. Don't trouble yourself
with writing a handler for it.
And there's this strange escalation of MVS operator commands. At first, the
S222 from a CANCEL command couldn't be caught. But someone saw a requirement
to catch CANCEL (what's wrong with MODIFY or STOP?) So, now S222 can be
caught. So they had to invent FORCE for programs that ignored CANCEL (and
other reasons).
FORCE can't be caught. I'm waiting breathlessly for the next round.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
