I didn't follow the whole discussion, but I now got interested because
of the challenge and
then I looked (again) at the original solution. IMO, the original
solution is very elegant and
solves the problem. I don't see any problem with it.
In contrast, at a former customer of mine, where we had to support
ASSEMBLER (without LE),
PL/1 and C modules, static and dynamic linkage and different AMODEs, we
replaced all standard
CALLs by site specific CALL macros (xxxCALL) and inserted special
(ASSEMBLER) interface modules
into the calling hierarchy, which examined the AMODE of the module to be
called, and then acted accordingly.
This worked, too, but it was very complicated. Of course, the interfaces
could do many more good things,
for example write messages on first call (name and version info of the
module to be called; name of the library,
where it has been found) and compute call statistics (call counts, cpu
and elapsed time for the module called),
if desired. Very interesting in dialog environments (IMS/DC in our
case), but also valid in batch.
The interfaces only added about 1 or 2 percent to the overall CPU load,
although they were heavily used in
some situations (for example: a call hierarchy of 50 levels of "normal"
modules in PL/1, C or ASSEMBLER,
involving 49 recursive calls of the interfaces; BTW: there were 2
different interfaces,
depending on the language of the caller; IIRC: the same for PL/1 and C).
Side effect: the interfaces made the co-existence of modules compiled
with different compiler versions easy
(no big-bang compile of the whole software needed); problems are handled
at the interface level.
There is much more interesting things to tell about this technique:
- error recovery
- language independent interface (parameter) definition using a repository
- supporting different versions of interfaces at the same time
- support of testing (test automation)
if you want to know more, you could contact me offline.
HTH, kind regards
Bernd
Am 15.08.2020 um 00:23 schrieb Tony Thigpen:
I have been reading all the "that is not a good way to do it" posts,
so here it the challenge to all those nay-sayers.
It's time to 'put-up' or 'shut-up'.
Under the following conditions, just how would you code it?
Rules:
1) You are coding the entry and exit for a called subroutine. For this
exercise, you will not be the main program called by a JCL EXEC card.
2) The way the caller is calling you can not be regulated.
3) The caller may be Assembler or Cobol.
4) Existing older code, that can not be changed, calls using a BALR.
5) Existing newer code calls using BASSM. And, it can not be changed.
6) It is known that some programs calling via BALR will call in 31bit.
7) It is know that some programs calling via BALR will call in 24bit.
8) Your code needs to perform some functions that require 31bit.
9) You must return to the caller is such a way that the callers mode
prior to the call and after the call is the same.
10) 64bit support is not required.
11) You must be callable from both a non-LE environment and an LE
environment.
12) LE support is not only not required, you just can't use it.
13) You must be LE-tolerant is. If you are called by LE you can't mess
up the LE environment, but you don't have to exploit it.
14) And to make it even more challenging, the code *must* run in a
older processor that does not support branch-retaliative nor BAKR/PR
instructions. Yes, this code is from a real-live vendor product that
is still being used by customers on machines that don't support those
instructions.
And, before you complain, this is *exactly* the requirements that the
original coder was facing, and still faces with this code.
The requirements of this challenge is that you show everybody on the
list the code you would write for these requirements.
Tony Thigpen
