Defering to indefinite is probably the same as ignore... https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3.bpxb100/bpx2cr_Delayed_signal_delivery.htm
-----Original Message----- From: John McKown <john.archie.mck...@gmail.com> To: IBM-MAIN <IBM-MAIN@LISTSERV.UA.EDU> Sent: Tue, Feb 27, 2018 10:05 PM Subject: Re: BPX mvssigsetup, the SIR, and ignoring Signal #9 (SIGKILL) On Tue, Feb 27, 2018 at 2:39 PM, Thomas David Rivers <<a href="mailto:riv...@dignus.com";>riv...@dignus.com</a>> wrote: > 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? > How about some more confusion. On this page about mvssigsetup()" <a href="https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3.bpxb100/mss.htm"; target="_blank">https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3.bpxb100/mss.htm</a> [quote] Default_override_signal_setSupplied parameterType:Character stringCharacter set:No restrictionLength:8 bytes The name of an 8-byte area containing a 64-bit mask of signals that the SIR processes when their respective default actions take place. The leftmost bit represents signal number 1, and the rightmost bit represents signal number 64. The signals SIGSTOP, SIGDUMP, and SIGTRACE cannot be intercepted. The bit positions that represent these signals are ignored. [/quote] On this page about BPXYSIGH <a href="https://www.ibm.com/support/knowledgecenter/SSLTBW_2.3.0/com.ibm.zos.v2r3.bpxb100/ysigh.htm"; target="_blank">https://www.ibm.com/support/knowledgecenter/SSLTBW_2.3.0/com.ibm.zos.v2r3.bpxb100/ysigh.htm</a> [quote] BPXYSIGH , ** BPXYSIGH: Component signal definition ** Used By: KIL SIA SPM ********************************************************************* * Signals with default action ABNORMAL TERMINATION SIGKILL# EQU 9 Termination (cannot be caught or ignored) SIGDUMP# EQU 39 Take a SYSMDUMP * Signals with default action STOP SIGSTOP# EQU 7 Stop (cannot be caught or ignored) SIGTHSTOP# EQU 34 Thread stop (cannot be caught or blocked or SIGTHCONT# EQU 35 Thread continue (cannot be caught or blocked or * ignored) [/quote] The two pages disagree on what cannot be caught or ignored. > > And - on receipt of signal #9 - what is the "good and proper" way to > terminate > the program? BPX _exit() or something else? > "good and proper"? I don't really know. How about the old stand by ABEND ? To be really nasty, CALLRTM TYPE=MEMTERM > - Thanks - > - Dave Rivers - > > -- > <a href="mailto:riv...@dignus.com";>riv...@dignus.com</a> > Work: (919) 676-0847 > Get your mainframe programming tools at <a href="http://www.dignus.com"; > target="_blank">http://www.dignus.com</a> > > -- I have a theory that it's impossible to prove anything, but I can't prove it. Maranatha! <>< John McKown ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to <a href="mailto:lists...@listserv.ua.edu";>lists...@listserv.ua.edu</a> with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
