If there is some irony in your statement, I want to try to
explain it:
A (LE) calls Interface1 calls B (non-LE) calls Interface2 calls C (LE)
if the Interface1 is able to promote all the LE information in a proper way
to Interface2, then it appears to LE as if C had be called directly from A.
This is what we try to accomplish. So the only problem is to get it done
it the right way. Interface1 needs to store the needed LE environment
and Interface2 needs to reconstruct it. It works at the moment for the
current LE, and if we have any problems with future releases of LE,
I'm quite sure we will manage to change our interfaces accordingly,
if needed with help of IBM support.
Of course, this is the short story. The long story includes such things as:
- all calls in the PL/1, ASSEMBLER and C modules have to be done not
by normal CALL statements, but by home grown macros, which call the
interfaces instead (normal CALL is forbidden - this has to be controlled
during CCM processes)
- the parameter passing mechanisms have to be normalized, so that
there are no errors due to different techniques, for examples PL/1
descriptors
- it is necessary that the interfaces recognize the type of the module to
be called (what language?, CEEFETCH/WSA needed or not, AMODE 24 or 31 -
doesn't exist any more, but this was a problem until some years ago)
- the some hundred developers must be instructed, not only the internals,
but also the externals (India!)
- etc. etc. etc.
Kind regards
Bernd
Am 31.03.2012 14:39, schrieb Steve Comstock:
[top posting]
Yikes! And I thought Colorado was the wild, wooly west. But noooo!
You win.
On 3/31/2012 5:45 AM, Bernd Oppolzer wrote:
Furthermore, you can call non-LE programs from LE programs and later
call LE programs from these non-LE programs, if you do the following:
- propagate R12 to the lower LE program
- take care of the values in the locations after offset 72 in the
savearea (NAB
etc.);
if you pass these values correctly to the lower save area, the lower
LE program
will
pick up the LE areas of the higher save area.
This is working for us, although I'm not quite sure, if it is
recommended by IBM.
But we did it this way, because otherwise we would have to change some
several thousand ASSEMBLER modules (making them LE compliant). By
doing it this way, we only had to change two interface modules which
support the
control transfer between dynamically loaded modules. These interface
modules
were in place since the 1970s and only had to be extended to support LE.
We were able to support DLLs, too, by using these interface modules.
If the
module to be called is a DLL, the interface issues the CEEFETCH,
which it
does not, if the module is a "normal" load module. In the mid 1980s,
the interfaces
did the necessary AMODE switch etc., when we migrated to MVS-XA.
We always have to pay about 1 percent of the overall CPU which is
spended in
the interfaces, but this is payed back by the flexibility we have
when we have
system changes, for example new compilers, new systems or migration
to LE,
for example. Such things can almost always be handled in the
interfaces. And:
the interfaces support the multi-language approach (at the moment:
ASSEMBLER,
PL/1 and C).
Another goodie: the interfaces are perfect for setting up tests and
for CPU
measurements etc. (special versions of the interfaces, which produce
accounting data, for example).
Kind regards
Bernd
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
