Re: Relationship of C signals to z/OS terminology?
Sent from my MetroPCS 4G Android deviceCharles Mills charl...@mcn.org wrote:I have looked in the manuals but I can't find this. Is there anywhere any documentation mapping the relationship between z/OS events as we have known and loved them for years, and C signals? I have figured out that SIGILL = S0C1 and SIGEGV = S0C4. SIGFPE is pretty obvious. But what exactly in the z/OS world does SIGABND catch? Not every ABEND -- I've figured that out. What does a console CANCEL command cause? SIGTERM? It would seem like this must be documented somewhere but I don't see it. Charles -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu 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
Re: Relationship of C signals to z/OS terminology?
Hey Scott g yes I have. Did I miss something? Do you see anywhere that they say S0C1 = SIGILL, Operator CANCEL = Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Scott Ford Sent: Friday, July 13, 2012 7:43 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Relationship of C signals to z/OS terminology? Hey Charles, I assume you have been here http://publib.boulder.ibm.com/infocenter/zos/v1r12/index.jsp?topic=%2Fcom.ib m.zos.r12.cbcpx01%2Ferrhndl.htm Scott ford www.identityforge.com On Jul 13, 2012, at 9:06 AM, Charles Mills charl...@mcn.org wrote: I have looked in the manuals but I can't find this. Is there anywhere any documentation mapping the relationship between z/OS events as we have known and loved them for years, and C signals? I have figured out that SIGILL = S0C1 and SIGEGV = S0C4. SIGFPE is pretty obvious. But what exactly in the z/OS world does SIGABND catch? Not every ABEND -- I've figured that out. What does a console CANCEL command cause? SIGTERM? It would seem like this must be documented somewhere but I don't see it. Charles -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Relationship of C signals to z/OS terminology?
Charles, Not exactly, yeah I know that's the point .I am surprised its not in some diagnostic guide. Let me dig .. Scott ford www.identityforge.com On Jul 13, 2012, at 10:53 AM, Charles Mills charl...@mcn.org wrote: Hey Scott g yes I have. Did I miss something? Do you see anywhere that they say S0C1 = SIGILL, Operator CANCEL = Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Scott Ford Sent: Friday, July 13, 2012 7:43 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Relationship of C signals to z/OS terminology? Hey Charles, I assume you have been here http://publib.boulder.ibm.com/infocenter/zos/v1r12/index.jsp?topic=%2Fcom.ib m.zos.r12.cbcpx01%2Ferrhndl.htm Scott ford www.identityforge.com On Jul 13, 2012, at 9:06 AM, Charles Mills charl...@mcn.org wrote: I have looked in the manuals but I can't find this. Is there anywhere any documentation mapping the relationship between z/OS events as we have known and loved them for years, and C signals? I have figured out that SIGILL = S0C1 and SIGEGV = S0C4. SIGFPE is pretty obvious. But what exactly in the z/OS world does SIGABND catch? Not every ABEND -- I've figured that out. What does a console CANCEL command cause? SIGTERM? It would seem like this must be documented somewhere but I don't see it. Charles -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu 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
Re: Relationship of C signals to z/OS terminology?
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:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Friday, July 13, 2012 9:11 AM To: IBM-MAIN@LISTSERV.UA.EDU 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Relationship of C signals to z/OS terminology?
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 Mightn't that be sigILL, as in Illegal? That sounds like a reasonable match to a program check 1. Yes, and it is. I wrote and meant SIGILL (= S0c1). Gil either is talking about something else or mis-read what I wrote. Gil said KILL but he meant ILL -- sounds like Dr. Seuss. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tony Harminc Sent: Friday, July 13, 2012 9:44 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Relationship of C signals to z/OS terminology? On 13 July 2012 12:10, Paul Gilmartin paulgboul...@aim.com wrote: 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. Mightn't that be sigILL, as in Illegal? That sounds like a reasonable match to a program check 1. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Relationship of C signals to z/OS terminology?
I stand corrected about SIGKILL vs. SIGILL. On Fri, 13 Jul 2012 09:45:00 -0700, Charles Mills wrote: BTW, this is z/OS batch (STC actually). Does operator CANCEL generate a SIGKILL? Or ...? I once suggested that for compatibility with existing UNIX conventions z/OS system shutdown should send SIGTERM to all dubbed processes so they could perform orderly shutdown. The suggestion wasn't very popular. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Relationship of C signals to z/OS terminology?
If you are a partner with IBM you could go to a development group and ask for clarification, I think. I though IBM had development forums for these kinds of questions. Lizette I sure don't see any mapping whatsoever of C library/UNIX signals to or from traditional z/OS terminology: S0C1, CANCEL, etc. The fragmentation of information between the C books and the LE books does not help. Charles -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Relationship of C signals to z/OS terminology?
On 7/13/2012 11:42 AM, Charles Mills wrote: I sure don't see any mapping whatsoever of C library/UNIX signals to or from traditional z/OS terminology: S0C1, CANCEL, etc. Hmm. P. 226 doesn't help get you at least part way there? The fragmentation of information between the C books and the LE books does not help. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Steve Comstock Sent: Friday, July 13, 2012 10:26 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Relationship of C signals to z/OS terminology? On 7/13/2012 9:39 AM, Charles Mills wrote: I mean, gee, SIGILL is documented as Invalid object module (hardware and software). Does that say S0C1 to you? In one sense, I suppose every program error is an invalid object program. But neglecting that, many S0C1's are not invalid object modules as I would interpret the phrase. S0C1 can be from using a perfectly valid instruction -- it's just perfectly valid for a newer processor model. Is that an invalid object module? S0C1 can be from bad linkage or logic that puts a zero in R15 before a BALR R14,R15. Is than an invalid object module? (Not intended to be an exhaustive list of S0C1 causes.) Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Scott Ford Sent: Friday, July 13, 2012 8:13 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Relationship of C signals to z/OS terminology? Charles, Not exactly, yeah I know that's the point .I am surprised its not in some diagnostic guide. Let me dig .. Scott ford www.identityforge.com On Jul 13, 2012, at 10:53 AM, Charles Mills charl...@mcn.org wrote: Perhaps the Language Environment Programming Guide can help. Get the pdf version for z/OS 1.13 and look at page 302 in particular but chapters 15-18 in general. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Kind regards, -Steve Comstock The Trainer's Friend, Inc. 303-355-2752 http://www.trainersfriend.com * Special promotion: 15% off on all DB2 training classes scheduled by September 1, taught by year end 2011 * Check out our entire DB2 curriculum at: http://www.trainersfriend.com/DB2_and_VSAM_courses/DB2curric.htm -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Relationship of C signals to z/OS terminology?
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:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Friday, July 13, 2012 9:11 AM To: IBM-MAIN@LISTSERV.UA.EDU 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 lists...@listserv.ua.edu 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
Re: Relationship of C signals to z/OS terminology?
Thanks! That is indeed part of it. My SIGABND was *not* driven for an operator CANCEL, however. No answer for what signal if any might be driven by an operator CANCEL. I guess I am going to have to experiment. Annoying. I will have to build something just to test this because my real program is too likely to make a mess if cancelled (as it currently stands). Not directed at you, Steve, but just in general: it is so easy to respond to these questions with RTFM but it's a heck of a lot easier to point out information that you already know than to find answers that you don't know. I searched on signal and cancel, signal and s0c1, etc., etc. The page you cite of course has the S0c1 answer, but all the searching in the world won't find s0c1 on that page. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Steve Comstock Sent: Friday, July 13, 2012 10:51 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Relationship of C signals to z/OS terminology? On 7/13/2012 11:42 AM, Charles Mills wrote: I sure don't see any mapping whatsoever of C library/UNIX signals to or from traditional z/OS terminology: S0C1, CANCEL, etc. Hmm. P. 226 doesn't help get you at least part way there? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Relationship of C signals to z/OS terminology?
In CAArMM9TAObiJu1BvHCumRYfGXvyo+=ccm-_4tzcd0itldx6...@mail.gmail.com, on 07/13/2012 at 12:43 PM, Tony Harminc t...@harminc.net said: FORCE is most certainly not just a stronger form of CANCEL He may be thinking of FORCE ARM. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2http://patriot.net/~shmuel We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Relationship of C signals to z/OS terminology?
On Fri, 13 Jul 2012 09:45:00 -0700, Charles Mills charl...@mcn.org wrote: . . . 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? For what you are doing, a MEMTERM resource manager is probably a good idea. That can be set up with the RESMGR macro, TYPE=ADDRSPC. The specified routine runs in ASID 1, and you can't access anything in the terminating address space, but you can free CSA and maybe do some other clean up there. I know close to zilch about all this SIGxxx stuff, but I suspect there may not be an equivalent to RESMGR TYPE=ADDRSPC. While you are about it you could also look at RESMGR TYPE=TASK. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
