Re: MI as the MI language of the as400. -- MI400

Just a few "final remarks" on this whole ILE vs OPM debate...
 (parting shots?)

 Who says there was no such thing as a "linker" or "binder" on
OS/400 prior to ILE?

 It may be of interest to note that there were several 3rd party
 products, notably ASNA's Diploma/C, that provided the ability
to separately compile separate C routines, and then "bind" them
together into a single, larger, composite *PGM object, all within
 the confines of the OPM world, as it then existed (circa 1991).

 How did they do that? ASNA just wrote their own C compiler,
which generated "intermediate" text files (containing MI source),
and they wrote their own "linker" or "binder" that could be used
 to combine the separate "text" files into a single larger composite
program.  I believe ASNA also had a special syntax that allowed
you to "embed" MI assembler statements right in the middle of
 your C programs...

IBM ToroLabs also came up with APTA - the "Application
Performance Tuning Aid," that allowed you to "bind" together
multiple separately-compiled EPM *PGMs into a single, larger
EPM "bound" *PGM (you could even combine Pascal and C
*PGMs into one bound *PGM), turning CALLX into CALLI
to improve performance. (Remember this was on the old IMPI
machines, where CALLX was much slower...)  IBM originally
developed APTA for "internal use only" but eventually made
it available to IBM business partners, etc., circa 1992 -- APTA
was used to build much of the infrastructure for ILE, which
was largely written in C, and so the EPM C/400 compiler was
used to "bootstrap" ILE/C.

And IBM Rochester LABs also developed "FreeStanding C",
which got released as a PRPQ called "System/C", circa 1993,
that basically did much of what ASNA's Diploma/C did -- you
compile small C routines separately, and then bind them all into
a single *PGM object. But, System/C had no "I/O" library --
the intent was to use System/C for "systems programming" for
the kind of things that used to require writing in MI assembler.
In fact, System/C introduced the idea of "embedding" MI
instructions as "built-in" functions.  And, System/C also had its
own "binder" to combine the intermediate objects into a single
large OPM *PGM.

By the way, OS/400 V2R3 actually was the first release that
supported and used ILE internally, and ILE C/400 was first
released under V2R3. This is because V2R3 was used as the
"bootstrap" release, and so, the (then new) ILE C/400 compiler
was used under OS/400 V2R3 to develop ILE RPG-IV and
ILE COBOL compilers for the eventual V3R1 and V3R6
releases.  Now, V2R3 was still an IMPI-only CISC release,
so there was no "magic" translator yet; all the OPM *PGMs
still ran "natively" as they had always done. It was not until
you got to V3R6 that the "magic" translator comes into play...

 Hence, none of these concepts like "binding" or "linking" of
 separately compiled "modules" was really "new" under OS/400,
and this may lend some credence to the earlier remarks about a
"Second System Effect" from Brooks' "Mythical Man Month".

 My main "gripe" with ILE and the way it was implemented is that
IBM made an (artificial) "division" between OPM and NPM (ILE),
 and made it difficult to "share" and easily "cross" that boundary
(at least, in the OPM-to-NPM direction).

 For example, OPM programs are converted by the "Magic" (MX)
translator to run on RISC machines, and in a sense, they become
"quasi"-ILE programs, but they MUST run in the "*DEFAULT"
activation group, which is really a "compatibility mode" for OPM
programs to run in  (while "real" ILE programs can run in any
 activation group, either "named" or *CALLER, etc.)

It seems too bad IBM decided not to truly integrate the OPM
and ILE "worlds" into one.  For example, how hard would it
really have been to add CALLPP, CALLBP, etc. instructions
(for ILE) into the OPM MI, and perhaps a "special" resolve
instruction to resolve to an "entry point" within a bound ILE
*SRVPGM, so that OPM MI programs could simply issue
a call to a "bound procedure", etc.?  I think this functionality
would address most, if not all, of the various "requirements"
that have been debated here over the past several days/weeks,
or even going back to some of the "threads" from last July.

("More sins are committed in the name of compatibility"
in Computer Science, alas.)

 Final thoughts:
==========
A curious thing is, after IBM made this huge investment in ILE,
with a "binder", etc., it turns out that the RISC-based AS/400
or iSeries machines are SO fast that there is no longer a large
"penalty" for using full "Dynamic Call", so, late-bound, dynamic
CALLX is just "not so bad" any more. And consider also how
many modern languages (like Java) seem to be returning to this
concept of dynamically loading on demand; makes you wonder...

This may have been one reason why it took so long for vendors
and users to begin converting from the old RPG/400 to the new
ILE RPG-IV... the old RPG/400 code runs "pretty darn fast" on
the new RISC-based AS/400s, so, "If it ain't broke, why fix it?".
It was only after Y2K was behind us, and RPG-IV started adding
more "compelling" features, that people started converting to it,
en masse...