Thank you very much, I'll take a look at all that.
Kind regards
Bernd
Am 30.03.2012 19:55, schrieb Steve Comstock:
On 3/30/2012 9:15 AM, Bernd Oppolzer wrote:
Am 30.03.2012 14:45, schrieb Steve Comstock:
My notes seem to indicate that using LINK from Assembler to
a PL/I main creates a nested enclave, which I guess is what
you are seeing. I don't see anyway to call a PL/I main without
the main creating an enclave.
I also see this note:
"PL/I fetchable main cannot be dynamically called by COBOL, C,
C++, FORTRAN, nor LE-conforming Assembler"
do you recall where this note comes from? If this is really a
restriction
confirmed by IBM books etc., I simply would accept it and don't try
it any more.
Maybe we find another solution to our problem; there is no absolute need
to call the test object within another enclave, if the test object is
a PL/1 main.
It's the way it works at the moment, but it could be changed; at least
I think so.
Well, in the pdf version of the LE Programming Guide (for 1.13), page
573,
we see:
-----------
In Language Environment, you can use the following methods to create a
child
enclave:
.
.
.
* Under z/OS, the PL/I FETCH and CALL to any of the following PL/I
routines with PROC OPTIONS(MAIN) specified:
– Enterprise PL/I for z/OS
.
.
.
Such a routine, called a fetchable main in this book, can only be
introduced by a FETCH and CALL from a PL/I routine. COBOL cannot
dynamically call a PL/I main and C cannot issue a fetch() against
a PL/I main. In addition, a fetchable main cannot be dynamically
loaded using the CEELOAD macro. The routine performing the FETCH
and CALL must be compiled with the Enterprise PL/I for z/OS or
the PL/I for MVS & VM compiler, or be a relinked OS PL/I routine.
-----------------------
Then the next page begins a section titled "Determining the behavior
of child enclaves" that has a section for each of the ways to create
a nested enclave; for PL/I we find a little information, including
a table on the behavior of the construct with unhandled conditions
under various combinations of the TRAP run time parameter for the
caller and the callee.
Is that definitive enough? If not, perhaps you should peruse the
PL/I docs.
Perhaps CEEPIPI would work for you? (Apologies if this has
already been suggested.)
See above. The problem is that the existing enclave is damaged,
when we try to call the PL/1 main. It doesn't matter how the existing
enclave
has been constructed. So we didn't consider CEEPIPI so far. If the
nesting of the enclaves (with PL/1 mains) is indeed a problem, I would
prefer to terminate the first enclave before calling the PL/1 main.
My question
to you and to the list was, if there are experiences with this, that
is, if the
calling of PL/1 mains in a nested enclave is indeed a problem, or if
it could
be done, if the PL/1 main is called via LINK, for example. Anyway, I
will try it -
but not this week, because it's Friday afternoon now. Have a nice
weekend ...
and thank you so far.
Kind regards
Bernd
I would definitely look at CEEPIPI; however, this involves non-LE
Assembler
invoking a routine to set up one or more LE environments then running
either
a main or a subroutine under those environments. It's not clear if
that kind
of structure works for what you are trying to do.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
