Re: ESPIE question (does ESPIE "cover" ATTACH'd sub-tasks)
My recollection is that catching '10'X and '11'X was only for ESPIE and was intended for use by IBM. One plausible use that comes to mind is guard pages for segmented stacks. I don't think they had such things when those ESPIE options were made available, although perhaps the concepts had been implemented. It is true that those options could only be set by authorized programs (and the ESPIE itself would still apply only to problem state). I meant "ABEND" in the sense I hear it usually used: to abnormally end, to blow up I'm sure many don't want their programs to end abnormally. I had asked because that's an argument for having recovery, not an argument for (E)SPIE vs (E)STAE(X). Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ESPIE question (does ESPIE "cover" ATTACH'd sub-tasks)
On Sun, 5 Apr 2020 12:24:40 -0700, Charles Mills wrote: >Don't want to beat this thing to death but FWIW I meant "ABEND" in the sense >I hear it usually used: to abnormally end, to blow up, to go kaput. When >someone says "payroll ABENDed last night" they typically in my experience >don't mean it took an ESTAE exit and recovered transparently. They mean it >went ka-boom. That is the sense in which I meant "ABEND not acceptable to >management." I did not mean that they would care one way or the other >whether the program used ESTAE and a recovery routine internally and fairly >transparently. > Yes, but some OCD-afflicted IS managers employ wonks to: o Discover ABENDs logged then recovered by ESTAE to investigate as process failures. o Accesses routinely prohibited by RACF to investigate as intrusion attempts. At one point, in Rexx on CMS, I tried an operation requiring a privileged class, falling back to limited operation on failure. I was investigated. o Investigate RC=4 from SMP/E utilities. And Sx37 retry. Etc. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ESPIE question (does ESPIE "cover" ATTACH'd sub-tasks)
Don't want to beat this thing to death but FWIW I meant "ABEND" in the sense I hear it usually used: to abnormally end, to blow up, to go kaput. When someone says "payroll ABENDed last night" they typically in my experience don't mean it took an ESTAE exit and recovered transparently. They mean it went ka-boom. That is the sense in which I meant "ABEND not acceptable to management." I did not mean that they would care one way or the other whether the program used ESTAE and a recovery routine internally and fairly transparently. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Peter Relson Sent: Sunday, April 5, 2020 7:01 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ESPIE question (does ESPIE "cover" ATTACH'd sub-tasks) Let's posit that ABENDing on the first such condition is not acceptable to user management. That is a bad thing to posit. That is an insane design in the absence of other information, unless by ABEND you also include "and the task terminates" (and I am assuming you are including "program check" as part of "ABEND"). And any type of recovery can be used to avoid task termination due to abend (ignoring CALLRTM with RETRY=NO or things like cancel). As has been said, it comes down to performance and diagnosis. Your needs might vary. Program-check with resume (for ESPIE) or with retry without recording (for ESTAE) are pretty much invisible, aside from cycles consumed and system trace entries, so most would not care if they happened because they would do no damage aside from consuming cycles. I think that (E)SPIE was created for compiler-based exception handlers (e.g., ON conditions in PL/I). (E)SPIE did accept program interrupt codes for x'10' (segment fault) and x'11' (page fault). Perhaps Shmuel knows/remembers of some rationale, because we don't -- we cannot think of any rational scenario in a machine that supports paging where a compiler could generate code to do something useful based on getting a segment fault or page fault when that would bypass the system's processing to page in valid virtual storage that was simply paged out. I'm doubting that the compiler would be generating code to do some sort of VSMLOC/VSMLIST to ascertain if the area is truly valid. Peter Relson z/OS Core Technology Design -- 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: ESPIE question (does ESPIE "cover" ATTACH'd sub-tasks)
Eat more fibre. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Charles Mills [charl...@mcn.org] Sent: Sunday, April 5, 2020 3:21 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ESPIE question (does ESPIE "cover" ATTACH'd sub-tasks) But what about the TP shortage? Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Saturday, April 4, 2020 5:12 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ESPIE question (does ESPIE "cover" ATTACH'd sub-tasks) On Sat, 4 Apr 2020 23:54:58 +, Seymour J Metz wrote: >If I expected a lot of bad data, I might use TP. But if I expected them to be >rare, I'd probably set an (E)SPIE. > Performance? Do the pertinent exceptions set testable condition codes with maskable interrupts? Anything but a cache fault is cheap, and TP won't throw a cache fault unless one was about to happen anyway. > >From: Ed Jaffe >Sent: Saturday, April 4, 2020 2:03 PM > >On 4/4/2020 10:29 AM, Charles Mills wrote: >> Let's say you were writing a report generator. You are processing data of >> unknown quality using field definitions generated by inexperienced >> programmers, and report programs written by non-programmers. You might >> expect a fair number of arithmetic operations on packed fields that >> contained invalid data, and a fair number of divisions by zero. Let's posit >> that ABENDing on the first such condition is not acceptable to user >> management. >> >> Would you use ESPIE to trap S0C7's and S0C9's, or would you validate the >> data with explicit "hand-coded" tests before every arithmetic operation? > >The TP (TEST DECIMAL) instruction comes in handy here... -- gil -- 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: ESPIE question (does ESPIE "cover" ATTACH'd sub-tasks)
But what about the TP shortage? Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Saturday, April 4, 2020 5:12 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ESPIE question (does ESPIE "cover" ATTACH'd sub-tasks) On Sat, 4 Apr 2020 23:54:58 +, Seymour J Metz wrote: >If I expected a lot of bad data, I might use TP. But if I expected them to be >rare, I'd probably set an (E)SPIE. > Performance? Do the pertinent exceptions set testable condition codes with maskable interrupts? Anything but a cache fault is cheap, and TP won't throw a cache fault unless one was about to happen anyway. > >From: Ed Jaffe >Sent: Saturday, April 4, 2020 2:03 PM > >On 4/4/2020 10:29 AM, Charles Mills wrote: >> Let's say you were writing a report generator. You are processing data of >> unknown quality using field definitions generated by inexperienced >> programmers, and report programs written by non-programmers. You might >> expect a fair number of arithmetic operations on packed fields that >> contained invalid data, and a fair number of divisions by zero. Let's posit >> that ABENDing on the first such condition is not acceptable to user >> management. >> >> Would you use ESPIE to trap S0C7's and S0C9's, or would you validate the >> data with explicit "hand-coded" tests before every arithmetic operation? > >The TP (TEST DECIMAL) instruction comes in handy here... -- gil -- 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: ESPIE question (does ESPIE "cover" ATTACH'd sub-tasks)
My recollection is that catching '10'X and '11'X was only for ESPIE and was intended for use by IBM. One plausible use that comes to mind is guard pages for segmented stacks. BTW, what is the status if you do a LINK while a SPIE is active? The documentation has several references to RBs. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Peter Relson [rel...@us.ibm.com] Sent: Sunday, April 5, 2020 10:00 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ESPIE question (does ESPIE "cover" ATTACH'd sub-tasks) Let's posit that ABENDing on the first such condition is not acceptable to user management. That is a bad thing to posit. That is an insane design in the absence of other information, unless by ABEND you also include "and the task terminates" (and I am assuming you are including "program check" as part of "ABEND"). And any type of recovery can be used to avoid task termination due to abend (ignoring CALLRTM with RETRY=NO or things like cancel). As has been said, it comes down to performance and diagnosis. Your needs might vary. Program-check with resume (for ESPIE) or with retry without recording (for ESTAE) are pretty much invisible, aside from cycles consumed and system trace entries, so most would not care if they happened because they would do no damage aside from consuming cycles. I think that (E)SPIE was created for compiler-based exception handlers (e.g., ON conditions in PL/I). (E)SPIE did accept program interrupt codes for x'10' (segment fault) and x'11' (page fault). Perhaps Shmuel knows/remembers of some rationale, because we don't -- we cannot think of any rational scenario in a machine that supports paging where a compiler could generate code to do something useful based on getting a segment fault or page fault when that would bypass the system's processing to page in valid virtual storage that was simply paged out. I'm doubting that the compiler would be generating code to do some sort of VSMLOC/VSMLIST to ascertain if the area is truly valid. Peter Relson z/OS Core Technology Design -- 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: ESPIE question (does ESPIE "cover" ATTACH'd sub-tasks)
Let's posit that ABENDing on the first such condition is not acceptable to user management. That is a bad thing to posit. That is an insane design in the absence of other information, unless by ABEND you also include "and the task terminates" (and I am assuming you are including "program check" as part of "ABEND"). And any type of recovery can be used to avoid task termination due to abend (ignoring CALLRTM with RETRY=NO or things like cancel). As has been said, it comes down to performance and diagnosis. Your needs might vary. Program-check with resume (for ESPIE) or with retry without recording (for ESTAE) are pretty much invisible, aside from cycles consumed and system trace entries, so most would not care if they happened because they would do no damage aside from consuming cycles. I think that (E)SPIE was created for compiler-based exception handlers (e.g., ON conditions in PL/I). (E)SPIE did accept program interrupt codes for x'10' (segment fault) and x'11' (page fault). Perhaps Shmuel knows/remembers of some rationale, because we don't -- we cannot think of any rational scenario in a machine that supports paging where a compiler could generate code to do something useful based on getting a segment fault or page fault when that would bypass the system's processing to page in valid virtual storage that was simply paged out. I'm doubting that the compiler would be generating code to do some sort of VSMLOC/VSMLIST to ascertain if the area is truly valid. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ESPIE question (does ESPIE "cover" ATTACH'd sub-tasks)
A TP followed by a conditional branch is more expensive then having no instruction there. So it depends on exactly what you're doing and the percent of bad data which approach is least expensive. OTOH, an inexperienced programmer is more likely to get it right with TP. From: IBM Mainframe Discussion List on behalf of Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu> Sent: Saturday, April 4, 2020 8:12 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ESPIE question (does ESPIE "cover" ATTACH'd sub-tasks) On Sat, 4 Apr 2020 23:54:58 +, Seymour J Metz wrote: >If I expected a lot of bad data, I might use TP. But if I expected them to be >rare, I'd probably set an (E)SPIE. > Performance? Do the pertinent exceptions set testable condition codes with maskable interrupts? Anything but a cache fault is cheap, and TP won't throw a cache fault unless one was about to happen anyway. > >From: Ed Jaffe >Sent: Saturday, April 4, 2020 2:03 PM > >On 4/4/2020 10:29 AM, Charles Mills wrote: >> Let's say you were writing a report generator. You are processing data of >> unknown quality using field definitions generated by inexperienced >> programmers, and report programs written by non-programmers. You might >> expect a fair number of arithmetic operations on packed fields that >> contained invalid data, and a fair number of divisions by zero. Let's posit >> that ABENDing on the first such condition is not acceptable to user >> management. >> >> Would you use ESPIE to trap S0C7's and S0C9's, or would you validate the >> data with explicit "hand-coded" tests before every arithmetic operation? > >The TP (TEST DECIMAL) instruction comes in handy here... -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ESPIE question (does ESPIE "cover" ATTACH'd sub-tasks)
On Sat, 4 Apr 2020 23:54:58 +, Seymour J Metz wrote: >If I expected a lot of bad data, I might use TP. But if I expected them to be >rare, I'd probably set an (E)SPIE. > Performance? Do the pertinent exceptions set testable condition codes with maskable interrupts? Anything but a cache fault is cheap, and TP won't throw a cache fault unless one was about to happen anyway. > >From: Ed Jaffe >Sent: Saturday, April 4, 2020 2:03 PM > >On 4/4/2020 10:29 AM, Charles Mills wrote: >> Let's say you were writing a report generator. You are processing data of >> unknown quality using field definitions generated by inexperienced >> programmers, and report programs written by non-programmers. You might >> expect a fair number of arithmetic operations on packed fields that >> contained invalid data, and a fair number of divisions by zero. Let's posit >> that ABENDing on the first such condition is not acceptable to user >> management. >> >> Would you use ESPIE to trap S0C7's and S0C9's, or would you validate the >> data with explicit "hand-coded" tests before every arithmetic operation? > >The TP (TEST DECIMAL) instruction comes in handy here... -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ESPIE question (does ESPIE "cover" ATTACH'd sub-tasks)
No, I would use (E)SPIE to trap the interrupt, assuming that I didn't have to keep tearing it down between data, and use ESTAE to trap ABENDS. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Charles Mills [charl...@mcn.org] Sent: Saturday, April 4, 2020 1:29 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ESPIE question (does ESPIE "cover" ATTACH'd sub-tasks) Let's say you were writing a report generator. You are processing data of unknown quality using field definitions generated by inexperienced programmers, and report programs written by non-programmers. You might expect a fair number of arithmetic operations on packed fields that contained invalid data, and a fair number of divisions by zero. Let's posit that ABENDing on the first such condition is not acceptable to user management. Would you use ESPIE to trap S0C7's and S0C9's, or would you validate the data with explicit "hand-coded" tests before every arithmetic operation? Or ... ? Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Peter Relson Sent: Saturday, April 4, 2020 5:49 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ESPIE question (does ESPIE "cover" ATTACH'd sub-tasks) ESPIE beats everything. That's the point. If (a.) all you need to trap is program checks; and (b.) you expect a bunch of them -- use ESPIE. I'd say "If ...you expect a bunch of them" then make every effort to redesign your application. Because "no program check" can be thought to beat ESPIE by even more than ESPIE beats other forms of recovery. I'd also say "if you're actually interested in debugging, you're much more likely not to want to use ESPIE". ESPIE was intended for -- 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: ESPIE question (does ESPIE "cover" ATTACH'd sub-tasks)
If I expected a lot of bad data, I might use TP. But if I expected them to be rare, I'd probably set an (E)SPIE. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Ed Jaffe [edja...@phoenixsoftware.com] Sent: Saturday, April 4, 2020 2:03 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ESPIE question (does ESPIE "cover" ATTACH'd sub-tasks) On 4/4/2020 10:29 AM, Charles Mills wrote: > Let's say you were writing a report generator. You are processing data of > unknown quality using field definitions generated by inexperienced > programmers, and report programs written by non-programmers. You might > expect a fair number of arithmetic operations on packed fields that > contained invalid data, and a fair number of divisions by zero. Let's posit > that ABENDing on the first such condition is not acceptable to user > management. > > Would you use ESPIE to trap S0C7's and S0C9's, or would you validate the > data with explicit "hand-coded" tests before every arithmetic operation? The TP (TEST DECIMAL) instruction comes in handy here... -- Phoenix Software International Edward E. Jaffe 831 Parkview Drive North El Segundo, CA 90245 https://secure-web.cisco.com/1NRbNP_JrO-xHMrX9Mrw7tfJ8bTGmmjYKPM3g_K-TiLsrdwv2kf1FbFJ06L7ka2s1htiB1KLDYMTkGfvutXeGYBrfOyAVDlpNbNtDEonI5jiOs1OItzpPvDiNaDdf1lrNe1EpNXAiHA5FGjLkG55EUQK7zZwblzpj1FK49AoTCcWZnmvFALMwsYe4FDx_ocuU4dS4Kag1Aiez5yBBXVJIAkBFHSYTHkj-5FELNuNLKLEMQs6-2ohseVJtUFLwEj-lSseX5NTto87TojlCMdzCXvvUVCpPMiiKmvG-rIz8UxgH5_Znn6skIHuU5zKNb9JLGo6FlWlfdiM9K7KamIafakSib8C7Lh8rM-gjvmw7HeEygUzYZ5Dr-8YtFiqL5yEDOmVuqd7g83xYNy7g9d8nmuStSig3aArIkcZTVLYcfVO9jIHS68_qlcxUK8jhTpvY/https%3A%2F%2Fwww.phoenixsoftware.com%2F This e-mail message, including any attachments, appended messages and the information contained therein, is for the sole use of the intended recipient(s). If you are not an intended recipient or have otherwise received this email message in error, any use, dissemination, distribution, review, storage or copying of this e-mail message and the information contained therein is strictly prohibited. If you are not an intended recipient, please contact the sender by reply e-mail and destroy all copies of this email message and do not otherwise utilize or retain this email message or any or all of the information contained therein. Although this email message and any attachments or appended messages are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by the sender for any loss or damage arising in any way from its opening or use. -- 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: ESPIE question (does ESPIE "cover" ATTACH'd sub-tasks)
Nice! They sneak these new instruction in while I'm not looking. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Ed Jaffe Sent: Saturday, April 4, 2020 11:04 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ESPIE question (does ESPIE "cover" ATTACH'd sub-tasks) On 4/4/2020 10:29 AM, Charles Mills wrote: > Let's say you were writing a report generator. You are processing data of > unknown quality using field definitions generated by inexperienced > programmers, and report programs written by non-programmers. You might > expect a fair number of arithmetic operations on packed fields that > contained invalid data, and a fair number of divisions by zero. Let's posit > that ABENDing on the first such condition is not acceptable to user > management. > > Would you use ESPIE to trap S0C7's and S0C9's, or would you validate the > data with explicit "hand-coded" tests before every arithmetic operation? The TP (TEST DECIMAL) instruction comes in handy here... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ESPIE question (does ESPIE "cover" ATTACH'd sub-tasks)
On 4/4/2020 10:29 AM, Charles Mills wrote: Let's say you were writing a report generator. You are processing data of unknown quality using field definitions generated by inexperienced programmers, and report programs written by non-programmers. You might expect a fair number of arithmetic operations on packed fields that contained invalid data, and a fair number of divisions by zero. Let's posit that ABENDing on the first such condition is not acceptable to user management. Would you use ESPIE to trap S0C7's and S0C9's, or would you validate the data with explicit "hand-coded" tests before every arithmetic operation? The TP (TEST DECIMAL) instruction comes in handy here... -- Phoenix Software International Edward E. Jaffe 831 Parkview Drive North El Segundo, CA 90245 https://www.phoenixsoftware.com/ This e-mail message, including any attachments, appended messages and the information contained therein, is for the sole use of the intended recipient(s). If you are not an intended recipient or have otherwise received this email message in error, any use, dissemination, distribution, review, storage or copying of this e-mail message and the information contained therein is strictly prohibited. If you are not an intended recipient, please contact the sender by reply e-mail and destroy all copies of this email message and do not otherwise utilize or retain this email message or any or all of the information contained therein. Although this email message and any attachments or appended messages are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by the sender for any loss or damage arising in any way from its opening or use. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ESPIE question (does ESPIE "cover" ATTACH'd sub-tasks)
Let's say you were writing a report generator. You are processing data of unknown quality using field definitions generated by inexperienced programmers, and report programs written by non-programmers. You might expect a fair number of arithmetic operations on packed fields that contained invalid data, and a fair number of divisions by zero. Let's posit that ABENDing on the first such condition is not acceptable to user management. Would you use ESPIE to trap S0C7's and S0C9's, or would you validate the data with explicit "hand-coded" tests before every arithmetic operation? Or ... ? Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Peter Relson Sent: Saturday, April 4, 2020 5:49 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ESPIE question (does ESPIE "cover" ATTACH'd sub-tasks) ESPIE beats everything. That's the point. If (a.) all you need to trap is program checks; and (b.) you expect a bunch of them -- use ESPIE. I'd say "If ...you expect a bunch of them" then make every effort to redesign your application. Because "no program check" can be thought to beat ESPIE by even more than ESPIE beats other forms of recovery. I'd also say "if you're actually interested in debugging, you're much more likely not to want to use ESPIE". ESPIE was intended for -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ESPIE question (does ESPIE "cover" ATTACH'd sub-tasks)
ESPIE beats everything. That's the point. If (a.) all you need to trap is program checks; and (b.) you expect a bunch of them -- use ESPIE. I'd say "If ...you expect a bunch of them" then make every effort to redesign your application. Because "no program check" can be thought to beat ESPIE by even more than ESPIE beats other forms of recovery. I'd also say "if you're actually interested in debugging, you're much more likely not to want to use ESPIE". ESPIE was intended for FWIW, as Binyamin noted, ESPIE can be used only for problem state programs. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ESPIE question (does ESPIE "cover" ATTACH'd sub-tasks)
Watch out - ARR has been ... pirated ... Thank You, Chris Hoelscher| Lead Database Administrator | IBM Global Technical Services| T 502.476.2538 or 502.407.7266 -Original Message- From: IBM Mainframe Discussion List On Behalf Of Jim Mulder Sent: Thursday, April 2, 2020 8:46 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [IBM-MAIN] ESPIE question (does ESPIE "cover" ATTACH'd sub-tasks) ARR, ESTAE, and ESTAEX are all RTM2, so recovering from an event and retrying are pretty much the same processing. Establishing and deleting an ARR is considerably faster than establishing and deleting an ESTAE or ESTAEX. Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. Poughkeepsie NY > What's the timing on ARR? > -- > Shmuel (Seymour J.) Metz > https://nam03.safelinks.protection.outlook.com/?url=http:%2F%2Fmason.g > mu.edu%2F~smetz3data=02%7C01%7Cchoelscher%40humana.com%7Cca76ea76 > a7474e2ac5cf08d7d76892fe%7C56c62bbe85984b859e511ca753fa50f2%7C1%7C0%7C > 637214716450807351sdata=5aPAm4%2BEpwEyF42MI1FjqwfdZgnlpbdceEnvKZr > ChqI%3Dreserved=0 > From: IBM Mainframe Discussion List on > behalf of Jim Mulder > Sent: Thursday, April 2, 2020 8:28 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: ESPIE question (does ESPIE "cover" ATTACH'd sub-tasks) > These are my results from a benchmark I did 4 years ago: > Testcases which loop recovering/retrying from an operation exception. > Using default system trace size - 1MB per CPU, with > 20 CPUs, so 20MB of data to snap) > z13 machine > RecoveryIterations CPU seconds Ratio > -- --- - > ESPIE x'20' 3.531.0 > FRR x'20' 45.66 12.9 > ESTAEX (no SNAPTRC) x' 2' 98.95 28.0 > ESTAEX (SNAPTRC)x' 1000'102.83 14,914.7 > Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. > Poughkeepsie NY > (845) 435-4741 > D10JHM1@PLPSC (MVS) JMULDER@S390VM (VM) > > From: "Lennie Dymoke-Bradshaw" > > To: IBM-MAIN@LISTSERV.UA.EDU > > Date: 04/02/2020 08:13 PM > > Subject: Re: ESPIE question (does ESPIE "cover" ATTACH'd sub-tasks) > > Sent by: "IBM Mainframe Discussion List" > > > > I think the reason that handling interrupts in ESPIE is faster than > > ESTAE is simply that ESPIE sets an exit to the FLIH, whereas ESTAE > > sets an exit to the SLIH. > > > > Lennie Dymoke-Bradshaw | Security Lead | RSM Partners Ltd > > Web: > > https://nam03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fsecure-web.cisco.com%2Fdata=02%7C01%7Cchoelscher%40humana.com%7Cca76ea76a7474e2ac5cf08d7d76892fe%7C56c62bbe85984b859e511ca753fa50f2%7C1%7C0%7C637214716450807351sdata=bgEqET4XWGpCx691NcY0f7YeH1Zd8x8Zur15ssuafZM%3Dreserved=0 > 14zIVesGm0rwFithty33lbnIE3Scbd3DRMIpuywMf4rb2a2nixu-0JGkumv6EwxHI0zp_uFI9IoHhsUJIko1X3bWcGlsX1l7WeRGXPHUcjoz8IMmG2xonI19xycCnUkPdFGfBV- > xJG6rGG2rSWvjBd3VtkYrb19Q4HFaMRr_amD_P9iA6ERmLecY-5qnCrai05W7nEfFTrjho > - > twyYM5Vv6EQ0f27Qe0_yOcRgqDGCiMDNWe3qSzmuH44hdTaV5vmW1ArAX25swG4LZP6dGV9Asqe1xE8mJPqoZriCy21EbqSbomQlDjLtyzCq_WnbDu1n- > PhqGKo_H_4YR9vSI4WfMbti79f7Rcxw8Hk3fXJ2riMSL1DM8T- > g5KXXA7h9PxqJAZthsXJz1atRR1d67_9_hdSDX9t0yOrF7cpZoneheUAlK4XbzwSv07YwlmFZwLl/ > http%3A%2F%2Fwww.rsmpartners.com > > Dance like no one is watching. Encrypt like everyone is. > > > > -Original Message- > > From: IBM Mainframe Discussion List On > > Behalf Of Charles Mills > > Sent: 02 April 2020 20:59 > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: [IBM-MAIN] ESPIE question (does ESPIE "cover" ATTACH'd > sub-tasks) > > > > As Peter seems to imply, ESPIE interrupts are apparently noticeably > > lower overhead than ESTAE interrupts. If data or addressing > > exceptions were expected I definitely *would* use ESPIE. I would > > save ESTAE for unexpected (well, expected unexpected) conditions. My > > opinion: no benchmarks, no source code. > > > > 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: ESPIE question (does ESPIE "cover" ATTACH'd sub-tasks)
Hmmm. I hear you. (But the number of iterations is actually only 1/16, right? X'2' is 1/16 of X'20', right?) Here is the data extrapolated out to a constant number of iterations. (The ratio for ESTAEX no SNAPTRC appears to be wrong in Jim's numbers.) RecoveryIterations CPU seconds Ratio -- --- - ESPIE x'20' 3.531.0 FRR x'20' 45.66 12.9 ESTAEX (no SNAPTRC) x'20' 1583.20 448.5 (28.0 is apparently wrong) ESTAEX (SNAPTRC)x'20' 52648.96 14,914.7 Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tom Marchant Sent: Friday, April 3, 2020 9:36 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ESPIE question (does ESPIE "cover" ATTACH'd sub-tasks) I saw the Ratio column. comparing lines 2 and 3 of the chart, the ratio doesn't make sense if the number of iterations for ESTAEX is only 1/10 of the number for FRR, yet it took over twice as long. Perhaps Jim will clarify. On Fri, 3 Apr 2020 09:12:56 -0700, Charles Mills wrote: >Look at the Ratio column for "normalized" numbers. > >ESPIE beats everything. That's the point. If (a.) all you need to trap is >program checks; and (b.) you expect a bunch of them -- use ESPIE. > >Charles > > >-Original Message- >From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On >Behalf Of Tom Marchant >Sent: Friday, April 3, 2020 8:10 AM >To: IBM-MAIN@LISTSERV.UA.EDU >Subject: Re: ESPIE question (does ESPIE "cover" ATTACH'd sub-tasks) > >The data presented shows that FRR is a lot better than ESTAE(X). >Perhaps you overlooked the number of iterations. > >-- >Tom Marchant > >On Fri, 3 Apr 2020 10:23:33 +0300, Binyamin Dissen wrote: > >>Interesting numbers. >> >>But I looked at the current doc and it still appears to be problem state only. >> >>Also, do you numbers include setup or just program check handling? I figured >>FRRs would be a lot better than ESTAE(X). >> >>On Thu, 2 Apr 2020 19:28:13 -0500 Jim Mulder wrote: >> >>:> These are my results from a benchmark I did 4 years ago: >>:> >>:>Testcases which loop recovering/retrying from an >>:>operation exception. >>:>Using default system trace size - 1MB per CPU, with >>:>20 CPUs, so 20MB of data to snap) >>:>z13 machine >>:> >>:>RecoveryIterations CPU seconds Ratio >>:>-- --- - >>:>ESPIE x'20' 3.531.0 >>:>FRR x'20' 45.66 12.9 >>:>ESTAEX (no SNAPTRC) x' 2' 98.95 28.0 >>:>ESTAEX (SNAPTRC)x' 1000'102.83 14,914.7 -- 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: ESPIE question (does ESPIE "cover" ATTACH'd sub-tasks)
I saw the Ratio column. comparing lines 2 and 3 of the chart, the ratio doesn't make sense if the number of iterations for ESTAEX is only 1/10 of the number for FRR, yet it took over twice as long. Perhaps Jim will clarify. On Fri, 3 Apr 2020 09:12:56 -0700, Charles Mills wrote: >Look at the Ratio column for "normalized" numbers. > >ESPIE beats everything. That's the point. If (a.) all you need to trap is >program checks; and (b.) you expect a bunch of them -- use ESPIE. > >Charles > > >-Original Message- >From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On >Behalf Of Tom Marchant >Sent: Friday, April 3, 2020 8:10 AM >To: IBM-MAIN@LISTSERV.UA.EDU >Subject: Re: ESPIE question (does ESPIE "cover" ATTACH'd sub-tasks) > >The data presented shows that FRR is a lot better than ESTAE(X). >Perhaps you overlooked the number of iterations. > >-- >Tom Marchant > >On Fri, 3 Apr 2020 10:23:33 +0300, Binyamin Dissen wrote: > >>Interesting numbers. >> >>But I looked at the current doc and it still appears to be problem state only. >> >>Also, do you numbers include setup or just program check handling? I figured >>FRRs would be a lot better than ESTAE(X). >> >>On Thu, 2 Apr 2020 19:28:13 -0500 Jim Mulder wrote: >> >>:> These are my results from a benchmark I did 4 years ago: >>:> >>:>Testcases which loop recovering/retrying from an >>:>operation exception. >>:>Using default system trace size - 1MB per CPU, with >>:>20 CPUs, so 20MB of data to snap) >>:>z13 machine >>:> >>:>RecoveryIterations CPU seconds Ratio >>:>-- --- - >>:>ESPIE x'20' 3.531.0 >>:>FRR x'20' 45.66 12.9 >>:>ESTAEX (no SNAPTRC) x' 2' 98.95 28.0 >>:>ESTAEX (SNAPTRC)x' 1000'102.83 14,914.7 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ESPIE question (does ESPIE "cover" ATTACH'd sub-tasks)
Look at the Ratio column for "normalized" numbers. ESPIE beats everything. That's the point. If (a.) all you need to trap is program checks; and (b.) you expect a bunch of them -- use ESPIE. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tom Marchant Sent: Friday, April 3, 2020 8:10 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ESPIE question (does ESPIE "cover" ATTACH'd sub-tasks) The data presented shows that FRR is a lot better than ESTAE(X). Perhaps you overlooked the number of iterations. -- Tom Marchant On Fri, 3 Apr 2020 10:23:33 +0300, Binyamin Dissen wrote: >Interesting numbers. > >But I looked at the current doc and it still appears to be problem state only. > >Also, do you numbers include setup or just program check handling? I figured >FRRs would be a lot better than ESTAE(X). > >On Thu, 2 Apr 2020 19:28:13 -0500 Jim Mulder wrote: > >:> These are my results from a benchmark I did 4 years ago: >:> >:>Testcases which loop recovering/retrying from an >:>operation exception. >:>Using default system trace size - 1MB per CPU, with >:>20 CPUs, so 20MB of data to snap) >:>z13 machine >:> >:>RecoveryIterations CPU seconds Ratio >:>-- --- - >:>ESPIE x'20' 3.531.0 >:>FRR x'20' 45.66 12.9 >:>ESTAEX (no SNAPTRC) x' 2' 98.95 28.0 >:>ESTAEX (SNAPTRC)x' 1000'102.83 14,914.7 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ESPIE question (does ESPIE "cover" ATTACH'd sub-tasks)
The data presented shows that FRR is a lot better than ESTAE(X). Perhaps you overlooked the number of iterations. -- Tom Marchant On Fri, 3 Apr 2020 10:23:33 +0300, Binyamin Dissen wrote: >Interesting numbers. > >But I looked at the current doc and it still appears to be problem state only. > >Also, do you numbers include setup or just program check handling? I figured >FRRs would be a lot better than ESTAE(X). > >On Thu, 2 Apr 2020 19:28:13 -0500 Jim Mulder wrote: > >:> These are my results from a benchmark I did 4 years ago: >:> >:>Testcases which loop recovering/retrying from an >:>operation exception. >:>Using default system trace size - 1MB per CPU, with >:>20 CPUs, so 20MB of data to snap) >:>z13 machine >:> >:>RecoveryIterations CPU seconds Ratio >:>-- --- - >:>ESPIE x'20' 3.531.0 >:>FRR x'20' 45.66 12.9 >:>ESTAEX (no SNAPTRC) x' 2' 98.95 28.0 >:>ESTAEX (SNAPTRC)x' 1000'102.83 14,914.7 >:> >:> >:>Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. >:>Poughkeepsie NY >:>(845) 435-4741 >:>D10JHM1@PLPSC (MVS) JMULDER@S390VM (VM) >:> >:>> From: "Lennie Dymoke-Bradshaw" >:>> To: IBM-MAIN@LISTSERV.UA.EDU >:>> Date: 04/02/2020 08:13 PM >:>> Subject: Re: ESPIE question (does ESPIE "cover" ATTACH'd sub-tasks) >:>> Sent by: "IBM Mainframe Discussion List" >:>> >:>> I think the reason that handling interrupts in ESPIE is faster than >:>> ESTAE is simply that ESPIE sets an exit to the FLIH, whereas ESTAE >:>> sets an exit to the SLIH. >:>> >:>> Lennie Dymoke-Bradshaw | Security Lead | RSM Partners Ltd >:>> Web: www.rsmpartners.com >:>> �Dance like no one is watching. Encrypt like everyone is.� >:>> >:>> -Original Message- >:>> From: IBM Mainframe Discussion List On >:>> Behalf Of Charles Mills >:>> Sent: 02 April 2020 20:59 >:>> To: IBM-MAIN@LISTSERV.UA.EDU >:>> Subject: Re: [IBM-MAIN] ESPIE question (does ESPIE "cover" ATTACH'd >:>sub-tasks) >:>> >:>> As Peter seems to imply, ESPIE interrupts are apparently noticeably >:>> lower overhead than ESTAE interrupts. If data or addressing >:>> exceptions were expected I definitely *would* use ESPIE. I would >:>> save ESTAE for unexpected (well, expected unexpected) conditions. My >:>> opinion: no benchmarks, no source code. >:>> >:>> Charles >:> >:> >:> >:>-- >:>For IBM-MAIN subscribe / signoff / archive access instructions, >:>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > >-- >Binyamin Dissen >http://www.dissensoftware.com > >Director, Dissen Software, Bar & Grill - Israel > > >Should you use the mailblocks package and expect a response from me, >you should preauthorize the dissensoftware.com domain. > >I very rarely bother responding to challenge/response systems, >especially those from irresponsible companies. > >-- >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: ESPIE question (does ESPIE "cover" ATTACH'd sub-tasks)
Interesting numbers. But I looked at the current doc and it still appears to be problem state only. Also, do you numbers include setup or just program check handling? I figured FRRs would be a lot better than ESTAE(X). On Thu, 2 Apr 2020 19:28:13 -0500 Jim Mulder wrote: :> These are my results from a benchmark I did 4 years ago: :> :>Testcases which loop recovering/retrying from an :>operation exception. :>Using default system trace size - 1MB per CPU, with :>20 CPUs, so 20MB of data to snap) :>z13 machine :> :>RecoveryIterations CPU seconds Ratio :>-- --- - :>ESPIE x'20' 3.531.0 :>FRR x'20' 45.66 12.9 :>ESTAEX (no SNAPTRC) x' 2' 98.95 28.0 :>ESTAEX (SNAPTRC)x' 1000'102.83 14,914.7 :> :> :>Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. :>Poughkeepsie NY :>(845) 435-4741 :>D10JHM1@PLPSC (MVS) JMULDER@S390VM (VM) :> :>> From: "Lennie Dymoke-Bradshaw" :>> To: IBM-MAIN@LISTSERV.UA.EDU :>> Date: 04/02/2020 08:13 PM :>> Subject: Re: ESPIE question (does ESPIE "cover" ATTACH'd sub-tasks) :>> Sent by: "IBM Mainframe Discussion List" :>> :>> I think the reason that handling interrupts in ESPIE is faster than :>> ESTAE is simply that ESPIE sets an exit to the FLIH, whereas ESTAE :>> sets an exit to the SLIH. :>> :>> Lennie Dymoke-Bradshaw | Security Lead | RSM Partners Ltd :>> Web: www.rsmpartners.com :>> Dance like no one is watching. Encrypt like everyone is. :>> :>> -Original Message----- :>> From: IBM Mainframe Discussion List On :>> Behalf Of Charles Mills :>> Sent: 02 April 2020 20:59 :>> To: IBM-MAIN@LISTSERV.UA.EDU :>> Subject: Re: [IBM-MAIN] ESPIE question (does ESPIE "cover" ATTACH'd :>sub-tasks) :>> :>> As Peter seems to imply, ESPIE interrupts are apparently noticeably :>> lower overhead than ESTAE interrupts. If data or addressing :>> exceptions were expected I definitely *would* use ESPIE. I would :>> save ESTAE for unexpected (well, expected unexpected) conditions. My :>> opinion: no benchmarks, no source code. :>> :>> Charles :> :> :> :>-- :>For IBM-MAIN subscribe / signoff / archive access instructions, :>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Binyamin Dissen http://www.dissensoftware.com Director, Dissen Software, Bar & Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ESPIE question (does ESPIE "cover" ATTACH'd sub-tasks)
On 2020-04-03 1:56 AM, Gord Tomlin wrote: On 2020-04-02 11:03, David Crayford wrote: In that case why does LE use ESPIE in condition handling? An irreverent take would be that they enjoy obfuscating abends by transforming program checks into U4xxx abends. The ESPIE can be eliminated using TRAP=(ON,NOSPIE), and we have not seen any adverse effects upon LE recovery from running that way. We do that too! Most of the hatred towards LE from assembler programmers is the condition handling! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ESPIE question (does ESPIE "cover" ATTACH'd sub-tasks)
ARR, ESTAE, and ESTAEX are all RTM2, so recovering from an event and retrying are pretty much the same processing. Establishing and deleting an ARR is considerably faster than establishing and deleting an ESTAE or ESTAEX. Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. Poughkeepsie NY > What's the timing on ARR? > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > From: IBM Mainframe Discussion List on > behalf of Jim Mulder > Sent: Thursday, April 2, 2020 8:28 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: ESPIE question (does ESPIE "cover" ATTACH'd sub-tasks) > These are my results from a benchmark I did 4 years ago: > Testcases which loop recovering/retrying from an > operation exception. > Using default system trace size - 1MB per CPU, with > 20 CPUs, so 20MB of data to snap) > z13 machine > RecoveryIterations CPU seconds Ratio > -- --- - > ESPIE x'20' 3.531.0 > FRR x'20' 45.66 12.9 > ESTAEX (no SNAPTRC) x' 2' 98.95 28.0 > ESTAEX (SNAPTRC)x' 1000'102.83 14,914.7 > Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. > Poughkeepsie NY > (845) 435-4741 > D10JHM1@PLPSC (MVS) JMULDER@S390VM (VM) > > From: "Lennie Dymoke-Bradshaw" > > To: IBM-MAIN@LISTSERV.UA.EDU > > Date: 04/02/2020 08:13 PM > > Subject: Re: ESPIE question (does ESPIE "cover" ATTACH'd sub-tasks) > > Sent by: "IBM Mainframe Discussion List" > > > > I think the reason that handling interrupts in ESPIE is faster than > > ESTAE is simply that ESPIE sets an exit to the FLIH, whereas ESTAE > > sets an exit to the SLIH. > > > > Lennie Dymoke-Bradshaw | Security Lead | RSM Partners Ltd > > Web: http://secure-web.cisco.com/ > 14zIVesGm0rwFithty33lbnIE3Scbd3DRMIpuywMf4rb2a2nixu-0JGkumv6EwxHI0zp_uFI9IoHhsUJIko1X3bWcGlsX1l7WeRGXPHUcjoz8IMmG2xonI19xycCnUkPdFGfBV- > xJG6rGG2rSWvjBd3VtkYrb19Q4HFaMRr_amD_P9iA6ERmLecY-5qnCrai05W7nEfFTrjho- > twyYM5Vv6EQ0f27Qe0_yOcRgqDGCiMDNWe3qSzmuH44hdTaV5vmW1ArAX25swG4LZP6dGV9Asqe1xE8mJPqoZriCy21EbqSbomQlDjLtyzCq_WnbDu1n- > PhqGKo_H_4YR9vSI4WfMbti79f7Rcxw8Hk3fXJ2riMSL1DM8T- > g5KXXA7h9PxqJAZthsXJz1atRR1d67_9_hdSDX9t0yOrF7cpZoneheUAlK4XbzwSv07YwlmFZwLl/ > http%3A%2F%2Fwww.rsmpartners.com > > Dance like no one is watching. Encrypt like everyone is. > > > > -Original Message- > > From: IBM Mainframe Discussion List On > > Behalf Of Charles Mills > > Sent: 02 April 2020 20:59 > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: [IBM-MAIN] ESPIE question (does ESPIE "cover" ATTACH'd > sub-tasks) > > > > As Peter seems to imply, ESPIE interrupts are apparently noticeably > > lower overhead than ESTAE interrupts. If data or addressing > > exceptions were expected I definitely *would* use ESPIE. I would > > save ESTAE for unexpected (well, expected unexpected) conditions. My > > opinion: no benchmarks, no source code. > > > > 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: ESPIE question (does ESPIE "cover" ATTACH'd sub-tasks)
What's the timing on ARR? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Jim Mulder Sent: Thursday, April 2, 2020 8:28 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ESPIE question (does ESPIE "cover" ATTACH'd sub-tasks) These are my results from a benchmark I did 4 years ago: Testcases which loop recovering/retrying from an operation exception. Using default system trace size - 1MB per CPU, with 20 CPUs, so 20MB of data to snap) z13 machine RecoveryIterations CPU seconds Ratio -- --- - ESPIE x'20' 3.531.0 FRR x'20' 45.66 12.9 ESTAEX (no SNAPTRC) x' 2' 98.95 28.0 ESTAEX (SNAPTRC)x' 1000'102.83 14,914.7 Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. Poughkeepsie NY (845) 435-4741 D10JHM1@PLPSC (MVS) JMULDER@S390VM (VM) > From: "Lennie Dymoke-Bradshaw" > To: IBM-MAIN@LISTSERV.UA.EDU > Date: 04/02/2020 08:13 PM > Subject: Re: ESPIE question (does ESPIE "cover" ATTACH'd sub-tasks) > Sent by: "IBM Mainframe Discussion List" > > I think the reason that handling interrupts in ESPIE is faster than > ESTAE is simply that ESPIE sets an exit to the FLIH, whereas ESTAE > sets an exit to the SLIH. > > Lennie Dymoke-Bradshaw | Security Lead | RSM Partners Ltd > Web: > http://secure-web.cisco.com/14zIVesGm0rwFithty33lbnIE3Scbd3DRMIpuywMf4rb2a2nixu-0JGkumv6EwxHI0zp_uFI9IoHhsUJIko1X3bWcGlsX1l7WeRGXPHUcjoz8IMmG2xonI19xycCnUkPdFGfBV-xJG6rGG2rSWvjBd3VtkYrb19Q4HFaMRr_amD_P9iA6ERmLecY-5qnCrai05W7nEfFTrjho-twyYM5Vv6EQ0f27Qe0_yOcRgqDGCiMDNWe3qSzmuH44hdTaV5vmW1ArAX25swG4LZP6dGV9Asqe1xE8mJPqoZriCy21EbqSbomQlDjLtyzCq_WnbDu1n-PhqGKo_H_4YR9vSI4WfMbti79f7Rcxw8Hk3fXJ2riMSL1DM8T-g5KXXA7h9PxqJAZthsXJz1atRR1d67_9_hdSDX9t0yOrF7cpZoneheUAlK4XbzwSv07YwlmFZwLl/http%3A%2F%2Fwww.rsmpartners.com > ‘Dance like no one is watching. Encrypt like everyone is.’ > > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Charles Mills > Sent: 02 April 2020 20:59 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: [IBM-MAIN] ESPIE question (does ESPIE "cover" ATTACH'd sub-tasks) > > As Peter seems to imply, ESPIE interrupts are apparently noticeably > lower overhead than ESTAE interrupts. If data or addressing > exceptions were expected I definitely *would* use ESPIE. I would > save ESTAE for unexpected (well, expected unexpected) conditions. My > opinion: no benchmarks, no source code. > > 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: ESPIE question (does ESPIE "cover" ATTACH'd sub-tasks)
I meant to also mention that ESPIE requires an SRB dispatch and and 2 TCB dispatches for each iteration, so there is uncaptured dispatcher time to consider when comparing performance. Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. Poughkeepsie NY > > These are my results from a benchmark I did 4 years ago: > > Testcases which loop recovering/retrying from an > operation exception. > Using default system trace size - 1MB per CPU, with > 20 CPUs, so 20MB of data to snap) > z13 machine > > RecoveryIterations CPU seconds Ratio > -- --- - > ESPIE x'20' 3.531.0 > FRR x'20' 45.66 12.9 > ESTAEX (no SNAPTRC) x' 2' 98.95 28.0 > ESTAEX (SNAPTRC)x' 1000'102.83 14,914.7 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ESPIE question (does ESPIE "cover" ATTACH'd sub-tasks)
These are my results from a benchmark I did 4 years ago: Testcases which loop recovering/retrying from an operation exception. Using default system trace size - 1MB per CPU, with 20 CPUs, so 20MB of data to snap) z13 machine RecoveryIterations CPU seconds Ratio -- --- - ESPIE x'20' 3.531.0 FRR x'20' 45.66 12.9 ESTAEX (no SNAPTRC) x' 2' 98.95 28.0 ESTAEX (SNAPTRC)x' 1000'102.83 14,914.7 Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. Poughkeepsie NY (845) 435-4741 D10JHM1@PLPSC (MVS) JMULDER@S390VM (VM) > From: "Lennie Dymoke-Bradshaw" > To: IBM-MAIN@LISTSERV.UA.EDU > Date: 04/02/2020 08:13 PM > Subject: Re: ESPIE question (does ESPIE "cover" ATTACH'd sub-tasks) > Sent by: "IBM Mainframe Discussion List" > > I think the reason that handling interrupts in ESPIE is faster than > ESTAE is simply that ESPIE sets an exit to the FLIH, whereas ESTAE > sets an exit to the SLIH. > > Lennie Dymoke-Bradshaw | Security Lead | RSM Partners Ltd > Web: www.rsmpartners.com > ‘Dance like no one is watching. Encrypt like everyone is.’ > > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Charles Mills > Sent: 02 April 2020 20:59 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: [IBM-MAIN] ESPIE question (does ESPIE "cover" ATTACH'd sub-tasks) > > As Peter seems to imply, ESPIE interrupts are apparently noticeably > lower overhead than ESTAE interrupts. If data or addressing > exceptions were expected I definitely *would* use ESPIE. I would > save ESTAE for unexpected (well, expected unexpected) conditions. My > opinion: no benchmarks, no source code. > > Charles -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ESPIE question (does ESPIE "cover" ATTACH'd sub-tasks)
Having a SPIE exit doesn't require them to mangle the dump. They do that pour le sport. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Gord Tomlin Sent: Thursday, April 2, 2020 1:56 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ESPIE question (does ESPIE "cover" ATTACH'd sub-tasks) On 2020-04-02 11:03, David Crayford wrote: > In that case why does LE use ESPIE in condition handling? An irreverent take would be that they enjoy obfuscating abends by transforming program checks into U4xxx abends. The ESPIE can be eliminated using TRAP=(ON,NOSPIE), and we have not seen any adverse effects upon LE recovery from running that way. -- Regards, Gord Tomlin Action Software International (a division of Mazda Computer Corporation) Tel: (905) 470-7113, Fax: (905) 470-6507 Support: https://secure-web.cisco.com/1bIa5wBBg20RuLBWAzomV6eVKZcIkoQWycYrgdnCR8mBQ4GGfUKutxVeuc4NaxxmNPwdtjOdDWzJVkJqVq5mPYbfZJw8NIibHb_4IbTY_1d6yJ8FKwbDV2zgEVFPF3F4so3CXC44N7ROxcYVBMLgbkoMWWFYeerYLcHGYVOdZURH7CkuOrvdcAie2FlintY_ilGOEHUUSPAg7P4u6PQWA2UtkL93OPKTIGIJr1SLU2ApU1w4etL9i08KN9RV7Mny1nrJFipj7eptoGUZGJUscn758z5YWCIwwKJ25MS7eiwDznRubwTqvLpy04mK5D4cn8QA2vOTSxXnqNE4-KjXIthbyYhd5bMphXrNFwdUGkrqyPdBeszJcPIIzqyWJ-4AjAgETg7mwjJMBaE_ozCwLPUk2dgPhPHyJkD5AeAjRH_NFYm-otdYLcK2VaTBgdNmA/https%3A%2F%2Factionsoftware.com%2Fsupport%2F -- 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: ESPIE question (does ESPIE "cover" ATTACH'd sub-tasks)
Of course dispatching a SPIE exit from the Program SLIH is less overhead than calling ABTERM schedule ABEND, processing the ABEND and dispatching an (E)STA(E|I). -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Charles Mills Sent: Thursday, April 2, 2020 3:58 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ESPIE question (does ESPIE "cover" ATTACH'd sub-tasks) As Peter seems to imply, ESPIE interrupts are apparently noticeably lower overhead than ESTAE interrupts. If data or addressing exceptions were expected I definitely *would* use ESPIE. I would save ESTAE for unexpected (well, expected unexpected) conditions. My opinion: no benchmarks, no source code. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Gord Tomlin Sent: Thursday, April 2, 2020 12:33 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ESPIE question (does ESPIE "cover" ATTACH'd sub-tasks) On 2020-04-02 14:14, Charles Mills wrote: > I had the same observation. Sending every condition through the same handler > was advantageous for me. Same here. > > You would want to keep the SPIE if program checks were expected: perhaps a > report generator where you anticipated that users might declare fields to be > packed when they were not always valid. You can also recover program checks from ESTAE(X). "You would want" -> "You might want". -- Regards, Gord Tomlin Action Software International (a division of Mazda Computer Corporation) Tel: (905) 470-7113, Fax: (905) 470-6507 Support: https://secure-web.cisco.com/1dQ8bhXNpmvLa4NVcjmC2fB982Tui0X9JlHunCUBPv_aClibXfM6TLhPQP2WT5DcrTnQBpFc0RhGwxsaeDIpogh-Km5NukF3RJomWV60Bm0ZyCEwb8CbrnxZO2x6bpAn2IQV8S6w2Iw9_BBrpXVA80_V-Kt6hkUQbW-W0xsDYQTce0UBQV6ca459Hsl_V_LPlgAdwkyjMV6TMsAVD9lG1uVOfZOUBKoYEW_RzD6u2LObCFzRRPVd1V7Bo_M8SqE9czxV3GfpcwXX_vgio5vhQ03-IITFjOQ2ZFrrL1Hxosb4PreDIA5uDdPSQnVIn6BBvVnYdrAkLPaSRVe5LbKgF-etZhF-b2Cm3Zd42Q_5ZdF0HINGKX-2Tq0VgdbVzQgQ4XlZJ8W6j927m5XSfpo9acR5CpuqNwMDwzqOBUae9IMGvB_SZn9HHL0NGg73ZtFlL/https%3A%2F%2Factionsoftware.com%2Fsupport%2F -- 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: ESPIE question (does ESPIE "cover" ATTACH'd sub-tasks)
That insanity dates all the way back to the Fortran runtime in OS/360. It used to make ABEND-AID output useless. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Mike Shaw Sent: Thursday, April 2, 2020 5:28 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ESPIE question (does ESPIE "cover" ATTACH'd sub-tasks) On 4/2/2020 1:56 PM, Gord Tomlin wrote: > An irreverent take would be that they enjoy obfuscating abends by > transforming program checks into U4xxx abends. Good one Gord. I always wondered why LE did that. It makes_no_sense to me. Mike Shaw MVS/QuickRef Support Group Chicago-Soft, Ltd -- 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: ESPIE question (does ESPIE "cover" ATTACH'd sub-tasks)
On Thu, 2 Apr 2020 17:28:05 -0400 Mike Shaw wrote: :>On 4/2/2020 1:56 PM, Gord Tomlin wrote: :> :>> An irreverent take would be that they enjoy obfuscating abends by :>> transforming program checks into U4xxx abends. :> :>Good one Gord. I always wondered why LE did that. It makes_no_sense to me. Much worse when they attempt to percolate via ABEND X'0C?',DUMP,,,SYSTEM and it takes a while until I see that it is a fake abend. -- Binyamin Dissen http://www.dissensoftware.com Director, Dissen Software, Bar & Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ESPIE question (does ESPIE "cover" ATTACH'd sub-tasks)
I think the reason that handling interrupts in ESPIE is faster than ESTAE is simply that ESPIE sets an exit to the FLIH, whereas ESTAE sets an exit to the SLIH. Lennie Dymoke-Bradshaw | Security Lead | RSM Partners Ltd Web: www.rsmpartners.com ‘Dance like no one is watching. Encrypt like everyone is.’ -Original Message- From: IBM Mainframe Discussion List On Behalf Of Charles Mills Sent: 02 April 2020 20:59 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [IBM-MAIN] ESPIE question (does ESPIE "cover" ATTACH'd sub-tasks) As Peter seems to imply, ESPIE interrupts are apparently noticeably lower overhead than ESTAE interrupts. If data or addressing exceptions were expected I definitely *would* use ESPIE. I would save ESTAE for unexpected (well, expected unexpected) conditions. My opinion: no benchmarks, no source code. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Gord Tomlin Sent: Thursday, April 2, 2020 12:33 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ESPIE question (does ESPIE "cover" ATTACH'd sub-tasks) On 2020-04-02 14:14, Charles Mills wrote: > I had the same observation. Sending every condition through the same handler > was advantageous for me. Same here. > > You would want to keep the SPIE if program checks were expected: perhaps a > report generator where you anticipated that users might declare fields to be > packed when they were not always valid. You can also recover program checks from ESTAE(X). "You would want" -> "You might want". -- Regards, Gord Tomlin Action Software International (a division of Mazda Computer Corporation) Tel: (905) 470-7113, Fax: (905) 470-6507 Support: https://actionsoftware.com/support/ -- 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: ESPIE question (does ESPIE "cover" ATTACH'd sub-tasks)
On 4/2/2020 1:56 PM, Gord Tomlin wrote: An irreverent take would be that they enjoy obfuscating abends by transforming program checks into U4xxx abends. Good one Gord. I always wondered why LE did that. It makes_no_sense to me. Mike Shaw MVS/QuickRef Support Group Chicago-Soft, Ltd -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ESPIE question (does ESPIE "cover" ATTACH'd sub-tasks)
As Peter seems to imply, ESPIE interrupts are apparently noticeably lower overhead than ESTAE interrupts. If data or addressing exceptions were expected I definitely *would* use ESPIE. I would save ESTAE for unexpected (well, expected unexpected) conditions. My opinion: no benchmarks, no source code. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Gord Tomlin Sent: Thursday, April 2, 2020 12:33 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ESPIE question (does ESPIE "cover" ATTACH'd sub-tasks) On 2020-04-02 14:14, Charles Mills wrote: > I had the same observation. Sending every condition through the same handler > was advantageous for me. Same here. > > You would want to keep the SPIE if program checks were expected: perhaps a > report generator where you anticipated that users might declare fields to be > packed when they were not always valid. You can also recover program checks from ESTAE(X). "You would want" -> "You might want". -- Regards, Gord Tomlin Action Software International (a division of Mazda Computer Corporation) Tel: (905) 470-7113, Fax: (905) 470-6507 Support: https://actionsoftware.com/support/ -- 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: ESPIE question (does ESPIE "cover" ATTACH'd sub-tasks)
On 2020-04-02 14:14, Charles Mills wrote: I had the same observation. Sending every condition through the same handler was advantageous for me. Same here. You would want to keep the SPIE if program checks were expected: perhaps a report generator where you anticipated that users might declare fields to be packed when they were not always valid. You can also recover program checks from ESTAE(X). "You would want" -> "You might want". -- Regards, Gord Tomlin Action Software International (a division of Mazda Computer Corporation) Tel: (905) 470-7113, Fax: (905) 470-6507 Support: https://actionsoftware.com/support/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ESPIE question (does ESPIE "cover" ATTACH'd sub-tasks)
I had the same observation. Sending every condition through the same handler was advantageous for me. You would want to keep the SPIE if program checks were expected: perhaps a report generator where you anticipated that users might declare fields to be packed when they were not always valid. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Gord Tomlin Sent: Thursday, April 2, 2020 10:56 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ESPIE question (does ESPIE "cover" ATTACH'd sub-tasks) On 2020-04-02 11:03, David Crayford wrote: > In that case why does LE use ESPIE in condition handling? An irreverent take would be that they enjoy obfuscating abends by transforming program checks into U4xxx abends. The ESPIE can be eliminated using TRAP=(ON,NOSPIE), and we have not seen any adverse effects upon LE recovery from running that way. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ESPIE question (does ESPIE "cover" ATTACH'd sub-tasks)
On 2020-04-02 11:03, David Crayford wrote: In that case why does LE use ESPIE in condition handling? An irreverent take would be that they enjoy obfuscating abends by transforming program checks into U4xxx abends. The ESPIE can be eliminated using TRAP=(ON,NOSPIE), and we have not seen any adverse effects upon LE recovery from running that way. -- Regards, Gord Tomlin Action Software International (a division of Mazda Computer Corporation) Tel: (905) 470-7113, Fax: (905) 470-6507 Support: https://actionsoftware.com/support/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ESPIE question (does ESPIE "cover" ATTACH'd sub-tasks)
Because Peter didn't write LE? Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of David Crayford Sent: Thursday, April 2, 2020 8:04 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ESPIE question (does ESPIE "cover" ATTACH'd sub-tasks) In that case why does LE use ESPIE in condition handling? > On 2 Apr 2020, at 9:53 pm, Peter Relson wrote: > > I'd say that no one should use ESPIE unless they have a valid performance > reason to do so. 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: ESPIE question (does ESPIE "cover" ATTACH'd sub-tasks)
One obvious use is to detect conditions for which there is an active ON unit. It's much easier with (E)SPIE. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of David Crayford Sent: Thursday, April 2, 2020 11:03 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ESPIE question (does ESPIE "cover" ATTACH'd sub-tasks) In that case why does LE use ESPIE in condition handling? > On 2 Apr 2020, at 9:53 pm, Peter Relson wrote: > > I'd say that no one should use ESPIE unless they have a valid performance > reason to do so. > > > And no clean way to percolate. > > As of z/OS 1.12 there is: you can set EPIEPERC > > (E)STAI is the only recovery mechanism that comes to mind that applies to > other work unit(s). > > Peter Relson > z/OS Core Technology Design > > > -- > 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: ESPIE question (does ESPIE "cover" ATTACH'd sub-tasks)
In that case why does LE use ESPIE in condition handling? > On 2 Apr 2020, at 9:53 pm, Peter Relson wrote: > > I'd say that no one should use ESPIE unless they have a valid performance > reason to do so. > > > And no clean way to percolate. > > As of z/OS 1.12 there is: you can set EPIEPERC > > (E)STAI is the only recovery mechanism that comes to mind that applies to > other work unit(s). > > Peter Relson > z/OS Core Technology Design > > > -- > 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: ESPIE question (does ESPIE "cover" ATTACH'd sub-tasks)
I'd say that no one should use ESPIE unless they have a valid performance reason to do so. And no clean way to percolate. As of z/OS 1.12 there is: you can set EPIEPERC (E)STAI is the only recovery mechanism that comes to mind that applies to other work unit(s). Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ESPIE question (does ESPIE "cover" ATTACH'd sub-tasks)
Binyamin Dissen wrote: What advantage do you see in an ESPIE over an ESTAE? IIRC, there are quite a few conditions where it doesn't get control. And no clean way to percolate. Mostly - catching an error (bad memory reference) in an ESTAE exit... - Dave Rivers - -- riv...@dignus.comWork: (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
Re: ESPIE question (does ESPIE "cover" ATTACH'd sub-tasks)
What advantage do you see in an ESPIE over an ESTAE? IIRC, there are quite a few conditions where it doesn't get control. And no clean way to percolate. On Tue, 31 Mar 2020 18:21:46 -0400 Thomas David Rivers wrote: :>I'm sure many on this list will know the answer to this, :>and I've been reading various manuals trying to find it... :> :>But - if a primary task issues an ESPIE SET to establish :>a ESPIE exit on a particular event, does that ESPIE exit :>get control if an ATTACH'd sub-task triggers the event? :> :>In my casual testing it didn't seem to (the attached sub-tasks :>were actually BPX pthread_create'd tasks, if that matters.) :> :>That is - if my initial task issues an ESPIE, does that ESPIE :>"cover" my sub-tasks as well, or would each sub-task need :>its own ESPIE. :> :>What seems to be happening is that some bad memory is :>referenced in my sub-task, but my ESPIE exit (in the parent :>task) is not being driven... :> :> - Thanks - :>- Dave Rivers - -- Binyamin Dissen http://www.dissensoftware.com Director, Dissen Software, Bar & Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ESPIE question (does ESPIE "cover" ATTACH'd sub-tasks)
(E)SPIE is associated only with the task issuing it. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Thomas David Rivers Sent: Tuesday, March 31, 2020 6:21 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: ESPIE question (does ESPIE "cover" ATTACH'd sub-tasks) I'm sure many on this list will know the answer to this, and I've been reading various manuals trying to find it... But - if a primary task issues an ESPIE SET to establish a ESPIE exit on a particular event, does that ESPIE exit get control if an ATTACH'd sub-task triggers the event? In my casual testing it didn't seem to (the attached sub-tasks were actually BPX pthread_create'd tasks, if that matters.) That is - if my initial task issues an ESPIE, does that ESPIE "cover" my sub-tasks as well, or would each sub-task need its own ESPIE. What seems to be happening is that some bad memory is referenced in my sub-task, but my ESPIE exit (in the parent task) is not being driven... - Thanks - - Dave Rivers - -- riv...@dignus.comWork: (919) 676-0847 Get your mainframe programming tools at http://secure-web.cisco.com/1KX_y3WLZVSc5WQN-JD6bm-mIX4ZwoQ5VFiuqmMlUMqjRMTUdAYqid5Gentve45PhtYA0rK8hEdvPOZdya4BQoAWi4RF03VXT18S2gTsszhPMEsOHyu6hmR_Jn5x4aQbp5gpV4ws3rY4GMLSDoQkJmoDHisfcmtdygOey_8xLUOQIH2RiXm9zlDUy5QQl0VWzudXLvR1EjHnQuNBd33kWkl7TLmYq7ReCHnOdeeItEKLhOzu0Jo5Vyj9qcC7P6ddGAWKuhtgr8JigTci3eA9uxSZG3a7juUXma7KnTv61_dGTq8yZvLJEuGshMafOIy_A0Q9r4f0vBKnmZzfs2VcLtDey_PRop1k8UU649Nd6LxevEE--Uncfi1tfGTCJgxPaLiVFR8wwv0OB9zscwBq5CR6lSXaPBZiM_XZsFx9mXRNfC__gqUB72JQ9IbM4EIB5/http%3A%2F%2Fwww.dignus.com -- 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: ESPIE question (does ESPIE "cover" ATTACH'd sub-tasks)
I wouldnt think so. Normally ATTACH creates a boundary, and only certain things can cross that boundary, like for instance, an ESTAI. Joe On Wed, Apr 1, 2020 at 1:26 PM Thomas David Rivers wrote: > I'm sure many on this list will know the answer to this, > and I've been reading various manuals trying to find it... > > But - if a primary task issues an ESPIE SET to establish > a ESPIE exit on a particular event, does that ESPIE exit > get control if an ATTACH'd sub-task triggers the event? > > In my casual testing it didn't seem to (the attached sub-tasks > were actually BPX pthread_create'd tasks, if that matters.) > > That is - if my initial task issues an ESPIE, does that ESPIE > "cover" my sub-tasks as well, or would each sub-task need > its own ESPIE. > > What seems to be happening is that some bad memory is > referenced in my sub-task, but my ESPIE exit (in the parent > task) is not being driven... > > - Thanks - > - Dave Rivers - > > -- > riv...@dignus.comWork: (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 > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
ESPIE question (does ESPIE "cover" ATTACH'd sub-tasks)
I'm sure many on this list will know the answer to this, and I've been reading various manuals trying to find it... But - if a primary task issues an ESPIE SET to establish a ESPIE exit on a particular event, does that ESPIE exit get control if an ATTACH'd sub-task triggers the event? In my casual testing it didn't seem to (the attached sub-tasks were actually BPX pthread_create'd tasks, if that matters.) That is - if my initial task issues an ESPIE, does that ESPIE "cover" my sub-tasks as well, or would each sub-task need its own ESPIE. What seems to be happening is that some bad memory is referenced in my sub-task, but my ESPIE exit (in the parent task) is not being driven... - Thanks - - Dave Rivers - -- riv...@dignus.comWork: (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
