On 2020-08-01 18:47, Charles Mills wrote:
I only know for a fact that all of the swans I have ever seen were
white.
At least on the side of the swans that you saw.
--
Regards, Gord Tomlin
Action Software International
(a division of Mazda Computer Corporation)
Tel: (905) 470-7113, Fax: (905)
---
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Peter Relson
Sent: Saturday, August 1, 2020 5:33 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ESTAEX exit WAIT question
I know for a fact that DETACH causes (via some route) the ECB to be
posted.
To be s
: ESTAEX exit WAIT question
[External Email. Exercise caution when clicking links or opening attachments.]
I know for a fact that DETACH causes (via some route) the ECB to be posted.
To be snide, I'd say that you know for a fact that in all the cases you've seen
DETACH causes the ECB to be posted
I know for a fact that DETACH causes (via some route) the ECB to be
posted.
To be snide, I'd say that you know for a fact that in all the cases you've
seen DETACH causes the ECB to be posted.
That's not the same as "know for a fact". Fortunately, it is a fact.
DETACH processing "steals" the
AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ESTAEX exit WAIT question
And you probably always got a 13E abend message on the console. :) The
normal thing to do is to tell the subtask to end (usually by posting
an ECB the subtask can wait on) and when the ATTACH ECB is posted,
the parent wak
the WAIT is harmless at worst so I think I
> will leave it in place.
> Charles
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Peter Relson
> Sent: Friday, July 31, 2020 7:15 AM
> To: IBM-MAIN@LISTSERV.UA.ED
it in place.
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Peter Relson
Sent: Friday, July 31, 2020 7:15 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ESTAEX exit WAIT question
If I remember correctly, DETACH of a subtask does
If I remember correctly, DETACH of a subtask does not return to the
invoker until that task has completely terminated (and I mean completely
-- all resmgrs have run, the TCB is freemained). If so, there is no reason
to have an ECB to wait upon. In fact I think the ATTACH ECB is not even
used
@LISTSERV.UA.EDU
Subject: Re: ESTAEX exit WAIT question
Taking these two posts together, I think you should look at
BPX1SDD/BPX4SDD a.k.a. set_dub_default(). If you set the value to
DUBPROCESS in the job step, before ATTACHing your subtask, the subtask
will be a separate process and should clean up at its
20 4:06 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ESTAEX exit WAIT question
OK, great. I was surprised you can ATTACH from your ESTAE recovery routine
at all... so I picked up something new.
--
For IBM-MAIN subscribe / signoff
On 2020-07-30 12:59, Charles Mills wrote:
Thanks @Peter. I wondered about an ATTACH RMTR.
I was fishing a bit when I wrote the OP. I understand the problem now:
I have a non-authorized batch program. I have complete control over the
logic. It runs a UNIX program as a subtask. I have no control
OK, great. I was surprised you can ATTACH from your ESTAE recovery routine
at all... so I picked up something new.
sas
On Thu, Jul 30, 2020 at 6:53 PM Charles Mills wrote:
> I think I have it. I call mvsprocclp (BPX1MPC, BPX4MPC) — Clean up kernel
> resources from the main task and that
for the suggestions.
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Tony Harminc
Sent: Thursday, July 30, 2020 11:44 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ESTAEX exit WAIT question
On Thu, 30 Jul 2020 at 12:59, Charles M
I believe an ESTAI recovery runs on the subtask as well. Can't say which
is better.
Either may obviate the need to re-attach it, which would be good, because
you might find more problems with that.
sas
On Thu, Jul 30, 2020 at 2:44 PM Tony Harminc wrote:
> On Thu, 30 Jul 2020 at 12:59,
On Thu, 30 Jul 2020 at 12:59, Charles Mills wrote:
>
> (I can't clean up the signal registration myself with BPX1MSD() -- that
> fails because the running main task does not own the signal registration,
> the terminated subtask does.)
>
> Any thoughts or suggestions?
>
Could you use a task
On Behalf
Of Steve Smith
Sent: Thursday, July 30, 2020 11:10 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ESTAEX exit WAIT question
If I understand what you're saying, you want to treat being CANCELed like a
message to recycle your subtask. That will not work. An ESTAE recovery
routine isn
If I understand what you're saying, you want to treat being CANCELed like a
message to recycle your subtask. That will not work. An ESTAE recovery
routine isn't allowed to retry for a CANCEL. All sorts of things happen
with RTM for a cancel, and trying to continue running isn't a viable
option.
ng in task termination.
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Charles Mills
Sent: Thursday, July 30, 2020 10:00 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ESTAEX exit WAIT question
Thanks @Peter. I wondered about an ATTACH
Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Peter Relson
Sent: Thursday, July 30, 2020 8:47 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ESTAEX exit WAIT question
Another "option" you could consider: use an RMTR for your ATTACH and have
the RMTR post an ECB
Another "option" you could consider: use an RMTR for your ATTACH and have
the RMTR post an ECB that is not the ECB specified on ATTACH (if using an
RMTR you probably wouldn't use an ECB on ATTACH at all).
Oops. ETXR not RMTR
Those darn "4 letter words"...
Peter Relson
z/OS Core Technology
>Is it legal for the ESTAEX exit code to WAIT on one of those ECBs?
Any code in a suitable environment (e.g., it can't be disabled) can wait
on anything that is of a suitable key and is not already waiting. If
already waiting, wait abends.
> Is it possible to cancel a WAIT?
I call that "post".
21 matches
Mail list logo
