To add some information:
in fact, when calling one module from another, we always have so-called
interface modules
between them, which do such things like: load the target module, if it
is not already in storage,
look for the amode of the new module and set it accordingly, clean first
bytes of parameter addresses,
if 24 bit addresses are passed to a 31 bit module etc. (no more
necessary today), set the environment
for LE languages (if calling from ASSEMBLER), and many such things more.
Using this technique, we were able to do multi-level dynamic calls at a
time when PL/1 didn't yet
support this, and the migrations from 24 to 31 bit or from non-LE to LE
worked like a charm.
Also compiler or OS release changes never were a problem, because we
always were able
to adopt the framework and the architecture by doing the proper changes
to the interface modules.
The interface modules also support component tests and performance
reports on a per-module base.
Drawback: you have to spend between 0.5 and 2 percent of CPU power which
is used in the interfaces,
but you get much flexibility.
I recall that a neighbour site had to compile all their 5000 PL/1
modules when migrating to EP PL/1
(and several months test time on a seperate machine) and they had to
switch all modules "at once",
whereas we did it with coexistence of "new" and "old" modules, due to
the interfaces modules,
without explicit test machine and no large test time.
Kind regards
Bernd
Am 19.09.2012 16:48, schrieb Paul Gilmartin:
On Wed, 19 Sep 2012 01:29:06 +0200, Bernd Oppolzer wrote:
Another example for the restrictions imposed by the architecture: the parameter
passing mechanisms are also limited, for example, no PL/1 descriptors. This was
a deliberate design decision in 1980 - the architects then wanted to make sure
that
all modules can call each other, regardless of language, and that a caller
needs not
know the language of the module he or she is calling...
This would seem to pretty much preclude 64-bit exploitation, and
even might have caused problems at a 31-bit conversion.
... The descriptions of the module
interfaces are written in a language independent way (in a data dictionary),
and the
language specific definitions (normally structure definitions in macros or
include files)
are generated from there - for all three languages.
Excellent. And I suspect some of the assembler wizards hereabouts would
be able to bypass a generative step and parse the structure definitions
directly with an assembler macro. (Would similar work for PL/I? I know
it's far beyond the ability of the C preprocessor.)
-- gil
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
