Generally, the rule is the following:
You z/VM cannot help you for running old NON-WORKING OSes on given
machine. Note, this is not about what is supported, but what is feasible
to run on bare metal (LPAR).
So, in this case z/OS 1.10 can run on EC12, but not on z14. Use of z/VM
doesn't change
Right. I only know for a fact that all of the swans I have ever seen were
white.
I believe what is happening is that the DETACH is posting the ATTACH
completion ECB and therefore making it available to be waited upon again.
Because my ESTAEX exit code, that always WAITs on the same ECB following t
Outstanding, Peter. Just checking: do you actually want to be snide?
First Horizon Bank
Mainframe Technical Support
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Peter Relson
Sent: Saturday, August 1, 2020 8:33 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ESTAEX
an ESTAI routine passed once on a single ATTACH could potentially get
driven multiple
times as an ABEND of the parent task was propagated to various daughter
tasks?
I'd quibble about an abend being propagated to daughter tasks. I don't
think of it as "propagated" (particularly because the spe
Brian,
You said:
"> I don't know about z/VM 5.3, but running z/OS 1.10 under z/VM on a
> z13 and z14 works (and probably also on a z15), so it's likely that
> it will work on a z12."
Jim said:
"Prior to z/OS 1.12, z/OS IPL uses Dynamic Address Translation while
still in ESA/390 mode. z14 and
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
Thanks Brian and Jim for your very helpful replies.
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
