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

Fellow MI geeks and geekettes:

Earlier in this thread, somebody mentioned that the relative lack of
development tools for the AS/400 was connected with a certain "not a
real computer" sentiment directed against it. Certainly the AS/400 is
the target of more than its share of that, almost as much as the
Macintosh gets.

It's actually not difficult to see the sources of this. Consider the
origins of the AS/400. In its original IMPI incarnation, it was, after
all, just a very slightly altered S/38. Thus, like the S/38, it has the
S/36 as a cousin, and the S/34, S/32, and S/3 "Bionic Desk" as its
ancestors, and IBM Rochester as its creator.

At the time the S/3 was created, IBM Rochester was where
plugboard-programmable unit record machines, machines that processed
decks of Hollerith cards, came from: more complicated and flexible than
dedicated sorters and tabulators, but definitely NOT real computers. As
I understand it, IBM Rochester was under orders to develop a better unit
record machine, NOT a "real computer." At the time, IBM mainframes were
already facing stiff competition from DEC, and the last thing IBM felt
it needed was to compete with itself.

Rochester kept quiet about how what they were building actually WAS a
"real computer," and since it was still intended only as a "better unit
record machine," they chose the relatively obscure RPG as the primary
user language of the beast because its syntax, rather than being based
on algebra (as in Fortran) or business English (as in COBOL), was based
on, you guessed it, unit record machine plugboards. That way, with
minimal training, the mailroom kid who knew how to wire plugboards could
write whatever software was needed, and (because of RPG's specialized
nature) the machine would not be much competition for the mainframes
that were still IBM's bread and meat. Thus, Rochester was actually
CULTIVATING "not a real computer" sentiment within IBM.

Of course, since the IBM "midrange" family was set up around RPG,
instead of BASIC or FORTRAN, and because it lacked a true assembler
language and broad-based language support, it tended to be the object of
a great deal of scorn among university-trained "mainstream" programmers,
who tended to have their earliest training on DEC "minicomputers" and/or
"UNIX boxes," as well as from old-line mainframe programmers, and
eventually also from the kids starting out in Altair BASIC, Applesoft
BASIC, Pet BASIC, and Pascal on those newfangled gizmos called
microcomputers. Most non-COBOL-specialists tend to look down on COBOL
(and many on BASIC as well), but even COBOL and BASIC specialists look
down on RPG. Thus, another source of "not a real computer" sentiment,
this time mainly from outside IBM.

****

Practically all programming languages (other than totally self-contained
ones that use either direct interpretation or an interpretive runtime,
and don't allow any sort of external calls, e.g., GWBASIC) use SOME SORT
of linkage. Either they use a linkage editor, or they use a linking
loader, or they use dynamic (i.e. runtime) linking, or they use some
combination of any or all of these forms of linkage. The IBM mainframe I
learned BASIC on in high school (a 370/135 running McGill University
MUSIC 2.3) used an interpretive runtime for VS-BASIC, which could not
make any sort of external calls whatsoever; FORTRAN programs could be
run directly from object "decks" using a linking loader, or they could
be run through a linkage editor to produce a "load module" (which was
generally too big for an ordinary file, and had to be stored in a
pre-allocated "user data set"). While many early microcomputer
assemblers and compilers did produce directly executable code, it was
generally found far more flexible to compile to an object format, then
use a linkage editor (some of which could also function as linking
loaders) to build an executable. Thus, programmers were already used to
having a "static linkage" step between compilation and execution,
whether it was explicit or implicit. The sort of dynamic linkage
inherent in OPM external calls was very much the exception outside of
the IBM midrange world, something one did only with costly "shell-out"
calls, and most high-level languages, except RPG and primitive BASIC,
were set up around static linkage of a sort that wasn't even provided in
OPM. Moreover, when dynamic linkage began to appear in the form of
Windoze DLLs and Amiga shared libraries, that, too, was something almost
completely foreign to the sort of dynamic linkage usually practiced on
the AS/400.

****

Then, also, since MI was rarely used directly even by IBM itself, IBM
was caught off-guard when outsiders began to write in it. They quickly
learned that it exposed security holes, and much of the early evolution
of program creation (the suppression of direct manipulation of object
type; the birth, and subsequent change to privileged status, of the
"CRTPG" MI instruction, and creation of the "MI compilation" API) was
directed at plugging those holes.

****

Another thing to remember is that even at the time the S/38 evolved into
the first AS/400, "commodity" software from third-party vendors was not
exactly common. If you had an IBM mainframe, you either wrote your own
software or obtained it from IBM. If you had a TRS-80, you bought any
canned software you needed from Radio Shack. Then somebody upset the
apple cart. Somebody wrote a calculation program based on an
accountant's worksheet, that recalculated itself automatically. Then
they decided others might want it. So they marketed it as VisiCalc.
Somebody else decided that the word processor they'd written for
internal use would make a good product, and published WordStar. IBM
wasn't expecting this to happen at all, much less to make its way into
the midrange and mainframe markets.

****

Also, it's my understanding that much of the motivation behind ILE was
not so much to bring languages that depended on static linkage to the
AS/400 (remember, EPM managed to do that while sitting atop OPM), as to
provide them with a way to use the same source (and object) code on
multiple platforms. Sort of the same thing that had allowed Infocom to
bring out the same "interactive fiction" games simultaneously on a dozen
platforms at once, and the same idea that motivated Sun to invent Java.

****

Now, I'm off to Disneyland, an hour later than I'd planned.

--
James H. H. Lampert
Professional Dilettante
http://www.hb.quik.com/jamesl
http://members.hostedscripts.com/antispam.html
http://www.thehungersite.com

Read My Lips: No More Atrocities!