On a typical UNIX platform, the operating system enforces the rule that
signal #9 cannot be blocked, and that a process that receives
that signal will be removed from the process table (and thus "killed".)
I've been setting up a BPX signal handler in some ASM code; using the BPX
mvssigsetup() function, writing a SIR, etc...
What I have discovered is that there seems to be nothing in z/OS that
enforces the "signal #9 can't be intercepted" rule... my routines can't
block that signal, but they are totally happy to receive it, ignore it
and return back to the executing program. The program isn't summarily
"killed".
I can't seem to find any particular documentation on the point, but I
suppose
in the event my program receives signal #9 - it's up to the program itself
to die (perhaps horribly?) and it's not a function of the operating system?
Because I'm not processing signal #9 and just returning to the point
of the signal; I've essentially created an unkillable process... which could
be a denial-of-service if nothing else. Seems like you could easily fork()
(which can create an unassociated task) and just catch signal #9 all day
long. I suppsoe the operator can still cancel the task somehow... You can
send my process a signal #9 all day long, and merrily continues on.
But - a UNIX programmer would certainly be quite "flummoxed" at this
behavior.
Does anyone have any pointers about this?
And - on receipt of signal #9 - what is the "good and proper" way to
terminate
the program? BPX _exit() or something else?
- Thanks -
- Dave Rivers -
--
riv...@dignus.com Work: (919) 676-0847
Get your mainframe programming tools at http://www.dignus.com
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
