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
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
ssage-
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 conditi
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@LISTS
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" AT
(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
termin
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
.
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 A
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
@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 u
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
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-pro
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
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 beat
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
t 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 fro
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.
on 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).
&g
o: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 iteration
;:>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/
:>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
:>>
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
STSERV.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, wi
is, 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" ATT
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
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: &quo
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 p
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
, 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.
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
-
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 h
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
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-0
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
.
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
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
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" AT
, 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 unles
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
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
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 -
--
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
(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
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
44 matches
Mail list logo
