Put out to Pasture ? - Programming Languages

"CG" <carl.gehr.RemoveThis@ThisToo.attglobal.net> wrote in message
news:99a2d$446774c3$d066072d$15721@FUSE.NET...
[color=blue]
> The first IBM PL/I compiler written in PL/I was the PL/I for
> OS/2 compiler.[/color]

That's right. Most of the code was written in PL/I.
There was a small amount written in C.

robin wrote:[color=blue]
> "CG" <carl.gehr.RemoveThis@ThisToo.attglobal.net> wrote in message
> news:80594$44677043$d066072d$25916@FUSE.NET...[color=green]
>> robin wrote:[color=darkred]
>>> It is worthwhile pointing out that IBM PL/I has almost always
>>> had features in advance of COBOL, and in particular
>>> IBM's millenium language extensions were available in
>>> IBM PL/I well ahead of COBOL[/color]
>> Actually, both the COBOL and PL/I MLEs were announced on the
>> same day: April 7, 1998[/color]
>
> Dates of announcement aren't relevant.
> At the time I observed that COBOL MLE was available
> six months after that for PL/I.[/color]

Do you have trouble with your eyes? I provided the "GA dates" for you
below in my post. [I even provided the IBM announcement letter numbers
which contain the GA dates.] "GA" means: GENERAL AVAILABILITY. COBOL
was actually FOURTEEN DAYS PRIOR TO the PL/I support.

Note that the GA date for COBOL was only THREE DAYS after the
announcement date. [Why three days? Because in most cases [for the
last 15 or 20 years], announcements are made on TUESDAY and availability
dates have almost always been on FRIDAY going back about 40 years. Go
find a 1998 calendar and you'll see how this fits, and that the PL/I
date was also on a Friday, exactly two weeks later.]

I do not consider that two week period do be in any way a significant
advantage or disadvantage for either language. Six month, under the
pressures of Y2K deadlines [which I started working on in January 1995]
would have been significant. Fact: It DID NOT HAPPEN THAT WAY!
[color=blue]
>[color=green]
>> PL/I Announcement Letter Number: 298-106
>> COBOL Announcement Letter Number: 298-098
>> * GA for PL/I was: April 24, 1998
>> * GA for COBOL was: April 10, 1998
>>[color=darkred]
>>> More recently, IBM's PL/I compiler has had a number of enhancements
>>> including the high-speed XML parser and support.[/color]
>> And, likewise for XML support, V3.1 of both Enterprise compilers
>> were announced on November 27, 2001. The GA for both was also
>> on the same day: November 30, 2001,
>>
>> Now, various enhancements did come out on a slightly different
>> schedule for later V3.x releases. But that was mostly a matter
>> of they were on a different development/release schedule. The
>> underlying code for both compilers is the same, It is just a
>> difference in the source syntax. Functionally, therefore, both
>> are essentially the same. Most of the differences in the
>> release schedule is due to other functions, requirements, etc.
>>
>> I guess what I am trying to point out is:
>> Both languages are essentially equal in the way
>> they are treated and considered by IBM. Neither
>> is getting slighted nor favored as the rumor mill
>> would have you believe.[/color]
>
> That has not been the case.
> Throughout the years, IBM PL/I has been ahead on features
> since the first PL/I back on 1966.[/color]
Oh, so that is why COBOL/370 was announced as an LE conforming compiler
with the original LE announcement on 11-Sep-1991, and GA on 20-Dec-1991,
but PL/I for MVS and VM was not announced until 23-Feb-1993 and was GA
on 30-Apr-1993. As I read the calendars, PL/I was one year and four
months LATER than the comparable COBOL product.

Robin, with all due respect, just because you wish it were so and likely
honestly believe your comments to be true, does not make them fact.
Again, I was there! I prepared parts of the IBM announcement materials
for LE and the COBOL compiler. And, before I quote dates [as I have
above and as you just seem not to want to believe], I EXTRACT THEM from
the IBM announcement and product history materials. I am NOT making
these up.

Yes, there are times when PL/I is ahead, but the opposite has also been
true. It has been like a game of leap frog. But, over the years, both
frogs have ended up in about the same puddle at about the same time.

Now, if you want to only talk about 'features' then I guess PL/I will
always be ahead. But not because of any marketing or development
actions on IBM's part. Rather it is simply inherent in the language.
And, even if some year in the far distant future [long past my horizon
of speculation], IBM were to stop providing a compiler, PL/I language
features will likely still be ahead.

Of course, if you'd like to widen your perspective, you can look over at
the COBOL NG and you will see discussions that the COBOL Standards
organization is in danger of imploding on itself. MY perception of why
[aside from the official reason that they no longer have a leader]: The
group continued to push COBOL to the point of trying to be "PL/I with
Periods" and the user community is not interested in the result. While
I know little about the details, FORTRAN is probably in the same box.
But, this is a subject for a totally different thread that is going on
elsewhere.
[color=blue]
> The OS/2 compiler was a major upgrade on
> features in 1994 - a development that has continued
> since, and has been ported to the mainframe, AIX, etc.[/color]

Gee! From my earlier post in response to Tom, I said:[color=blue]
> That compiler is also the base for the
> Windows, AIX, VA PL/I for OS/390 and the Enterprise PL/I
> for z/OS compilers.[/color]

John W. Kennedy wrote:[color=blue]
> CG wrote:[color=green][color=darkred]
>>> In fact, if such a compiler was proposed, it was dropped
>>> in order to deliver IBM's PL/I Optimising Compiler and the
>>> Checkout compiler in 1970.[/color]
>> No, not true. The Optimizer and Checkout compiler
>> came later.[/color]
>
> Although the Optimizer and Checker obviously recycled the three-letter
> prefixes IEL and IEN that had once been allocated to the PL/I (E) and
> (H) compilers.[/color]
Sorry, never was a PL/I(E). There was a PL/I(D) on the DOS operating
system. (D) was a subset that was replaced by the DOS Optimizer. The
DOS Optimizer was/is essentially identical to the OS Optimizer [now
known as 'OS PL/I'] except for the points where it had to interface with
the operating system. Of course, there were also some features that
were not implemented in the DOS product because the operating system did
not support then. The most obvious example was multitasking.

And, regarding (H), I think we've already explained why it never arrived
on the scene.

Since the Optimizers and the PL/I for MVS and VM products are all just
bumps on top of the original Optimizer, they all share the same prefix
of IEL for the compiler and IBM for the run-time support.

Actually, the IBM prefix is still used for the PL/I unique functions in
LE. Rather strange, though, was the decision to use IBMZPLI as the name
for the Enterprise PL/I Compiler.

Just to be complete: The PL/I(F) compiler used IEMxxxxx.
[color=blue]
> I have always wondered whether the eventually delivered Assembler H was
> based on the Assembler H that had been decommitted at the same time.
>[/color]

Actually, I suspect that the Assembler that you are referring to, while
it has an 'H' in the acronym [HLASM] is actually the "High Level
Assembler" not an 'H-Level' Assembler.

The HLASM was driven by a very insistent group of people in the GUIDE
User Group who [circa 1990] virtually demanded that IBM implement a
bunch of enhancements that had been discussed for years, but never
implemented. The effort spilled over to the SHARE User Group where an
equally persistent group took up the cause. They finally got IBM's
attention and an IBMer at Santa Teresa who was willing to take up their
cause. The result was the HLASM product that was announced 05-May-1992
and V1.0 was delivered [GA] 26-Jun-1992. HLASM is now at V1.5.

The HLASM product was actually built on the "System Assembler" that was
packaged with and delivered as an integral part of the operating system.
So, relatively speaking, it is a rather new product.

Most of the changes and enhancements were in diagnostics and human
factors. Macro features were also received major attention. When you
get right down to it, Assembler is still Assembler. Except for macros
and new hardware instructions, you still write one instruction at a
time. But, I do not want to minimize the new functions in the
diagnostics and human factors in the way macros and directives are
handled. They are MAJOR new enhancements; well worth obtaining for any
serious Assembler programmer.

robin wrote:[color=blue]
> "CG" <carl.gehr.RemoveThis@ThisToo.attglobal.net> wrote in message
> news:c9616$446750eb$d066072d$26669@FUSE.NET...[color=green]
>> robin wrote:
>>[color=darkred]
>>> There has been no withdrawal of support.[/color]
>> That is EXACTLY what I said![/color]
>
> I was confirming/emphasising that.
>[color=green][color=darkred]
>>>> These rumors have been around since the late 1960s when IBM
>>>> 'decommitted' the PL/I(H) compiler. [Yes, there was one announced and
>>>> never produced.] It did not happen then,
>>> Did it?[/color]
>> ???? Did what?[/color]
>
> [decommit the H comoiler
>[color=green]
>> Yes there was an H-level compiler
>> announced with the S/360 on 07-Apr-1964.[/color]
>
> That was before the machine had been produced.[/color]

That date is the announcement date of the original S/360 and all the
related software. A lot of that stuff was never shipped; both hardware
and software.
[color=blue][color=green]
>> Yes, it
>> was 'decommitted' [a term coined then for several
>> originally announced products that were dropped.
>> Was PL/I dropped from the IBM product line? Obviously
>> NOT...
>>[color=darkred]
>>> In fact, if such a compiler was proposed, it was dropped
>>> in order to deliver IBM's PL/I Optimising Compiler and the
>>> Checkout compiler in 1970.[/color]
>> No, not true. The Optimizer and Checkout compiler
>> came later.[/color]
>
> I know it came later. I gave the date. 1970.
> It was a natural development after the F-compiler
> (which did IIRC do optimisation).[/color]

The Optimizer and Checkout compilers were not built on the (F) compiler.
They were totally new, start from scratch compilers. [Actually, the
'Checkout Compiler' was not, strictly speaking, a 'compiler. It was a
'translator' and an 'interpreter' as it did not compile into S/360
machine language. The Checkout generated a stylized interpretive text
that was fed to the interpreter for execution.

Well, yes, (F) did do *some* optimization. But its original intent was
NOT to do any optimization. As I recall, the initial release of the
compiler did not even have a compiler option to request optimization.

There were five 'versions' of (F):

* V1: Just get something out that would prove there was a PL/I. One of
my accounts wanted to install their first S/360-40 with PL/I V1, but the
performance was totally unacceptable, primarily due to having only
STREAM I/O. Performance dictated that my account wait for V2 to compile
the I/O. A few shops in town shared some Assembler routines to do I/O
until V2. We did initial testing with these routines and then replaced
them with RECORD I/O when it became available in Dec-1966. The system
was installed in Jun-1967.

* V2: Added RECORD I/O, without which no commercial shop would touch
the language. Don't forget, COBOL was already the accepted standard
language for commercial programming.

* V3: The major focus of this release was to provided improved performance.
* V4 and V5: Performance and function in both of these, but V4 was
mostly performance and V5 was primarily function.

[color=blue]
> However, the compiler wan't produced in an instant
> by magic.
> It had a significant development time.
> Perhaps three to four years, which puts
> it in the ballpark of being initiated when
> the H compiler was being considered.[/color]
I hate to keep repeating myself. H was announced in 1964 and withdrawn
early to mid-1965 during all of the turmoil when OS/360 was delayed and
the Tape Operating System [TOS] two Basic Operating Systems [8K BOS and
16K BOS] were announced as 'interim solutions' for early installers of
the 360. The TOS was not well received and used almost only for demos
because it had no disk support of any kind. The 8K DOS system did not
last very long because it did not have any tape support. The 16K BOS
became the Disk Operating System until virtual storage was announced and
it became first DOS/VS and later VSE. OS/360 went through eleven
releases from its original very controlled distributions [BCP: Basic
Control Program] in late 1965 until the end of 1966 including variations
called MFT [Multiprogramming with a Fixed number of Tasks; i.e.,
partitions, later to become E-MFT] and MVT [Multiprogramming with a
Variable number of Tasks; i.e., regions].
[color=blue]
>
> For this timescale, you need to bear in mind that
> based variables and multitasking did not see implementation
> until the fourth version of the F-compiler in about 1968.[/color]

I'd have to look back at my notes, but I believe both of those were not
available until V5. And, yes, it was in 1968. I started teaching
classes on V5 in 1Q-1968.
[color=blue]
>
> And based variable facilities were not *designed*
> until the fourth version of the compiler.
> So writing another compiler [H] (albeit an optimizing
> compiler) when they had not even finished even
> one full compiler - would scarcely be a priority.[/color]

Quite the contrary, getting a good performing, high function PL/I was a
high priority. The Optimizers were announced 23-Jun-1969 as part of the
unbundling announcement and delivered to beta accounts in Dec-1970.
[color=blue]
>[color=green][color=darkred]
>>> Are you sure that you are not confusing the H compiler (never heard of it)
>>> with the PL/I Optimising compiler?[/color]
>> *I* am not confusing anything. [FWIW, I was there when
>> it happened.][/color]
>
> It was just a question.
>[color=green]
>> There were basically two reasons for dropping the H
>> compiler. But, first a little background:
>>
>> * PL/I(F) was supposed to be a quick and dirty [just generate something
>> that will compile the code and give answers] compiler.[/color]
>
> Well, it was actually more than that. It was a real compiler.
> And you could get work done with it.[/color]

Oh, it was certainly a 'real' compiler. But, it was not usable as a
production compiler until V2. And, even then, it was V3 before
performance became tolerable. By V5 it was not too bad. But, by that
point it was also doing things the INITIAL design was never intended to do.
[color=blue]
>[color=green]
>> Sort of a
>> debugging tool, if you will, but it was primarily a 'get something out
>> to prove the language is real' product.
>> * PL/I(H) was supposed to be the 'optimizing' compiler for the
>> language. This was intended to be the 'production' compiler.[/color]
>
> It could not have been. Many machines could not have
> run it. Ours couldn't.[/color]

ONE of the reasons it never saw the light of day! But, you must also
understand the original design specs for the OS/360. The MINIMUM system
was to be 64K [no typo: 'K' is correct, real memory.] The 'fixed'
storage for the OS was to be 16K, with the rest of storage allocated
dynamically [via scatter load] to user programs in 4K chunks. No
regions, no partitions; just scatter 4K blocks around. The 'F' design
was actually to represent a '44K' design point. 'G' was a 96K design to
run on a 128K system. [e.g., FORTRAN-G] 'H' was a 200K design for a
256K system. There was also a FORTRAN-E that would run in 32K.

Don't forget that the maximum storage in the original S/360 was a 'huge'
512K system. "Who could ever use all that storage? We've only got an
8K 1401!"]
[color=blue]
>[color=green]
>> It was
>> anticipated that the compile time would be too long for general
>> development use because of the extra work required by the optimization.
>> Also, because it was going to require 200K of REAL memory [There was
>> no 'virtual storage in OS/360] it was a concern that it would be
>> unacceptable for normal work.[/color]
>
> Then that would have been no different from the FORTRAN H compiler.[/color]

Yep! But, FORTRAN is a much smaller language so the storage required
for the compiler code would be a lot smaller. And, the FORTRAN-H
compiler did not hit the marked until much later than the first S/360s.
FORTRAN-G was the most common FORTRAN compiler for a long time.
[color=blue]
> But for the FORTRAN H compiler, optimizing
> techniques had already been developed.
> They would not have needed to repeat the
> development for an optimizing PL/I compiler.[/color]

But the original FORTRAN H optimization was not as good as the
Optimizer. The original FORTRAN H was not a real hit. FORTRAN-H V2
[the one written in FORTRAN] was significantly better and used some of
the techniques from the Optimizer. Later, serious FORTRAN users moved
to a PRPQ compiler using optimization techniques from Palo Alto Research
that was often referred to as FORTRAN-Q. VS FORTRAN V1 was based on an
enhanced FORTRAN-Q that exploited virtual storage. VS FORTRAN was also
required for the Vector Facility. But, now we're in the mid to late
1980s.
[color=blue]
>[color=green]
>> [The 'H' implied 200K. But, that a different bit of history.]
>> * There was a severe strain on all development resources, primarily
>> because OS/360 was a bigger task than had been anticipated. [Ref: "The
>> Mythical Man-Month"] Resources [and funding] that were originally to go
>> to PL/I in Hursley were diverted to Poughkeepsie and other labs to get
>> the essentials out to the customers. The operating system was obviously
>> more critical. But, even these tactics did not totally work, thus the
>> interim TOS and BOS [the 8K version; the 16K version eventually became
>> the 'original' DOS: a.k.a., DOS/360].
>> * The first release of the PL/I(F) compiler did not have a lot of the
>> critical language.
>> The most notable missing piece was RECORD I/O.[/color]
>
> Record I/O was not a critical component.[/color]
You could not have been in a commercial account in 1966-1967. Large
1410/7010/7070/7074 shops could never have gotten started with only
STREAM I/O.
[color=blue]
> (Neither was BASED, which was not available until later.)
> However, all the essentials of the language were there.[/color]

Maybe if you were in an academic or scientific environment. As someone
who job was to 'sell' PL/I, I guarantee that w/o RECORD I/O, PL/I was
DOA; a complete non-starter with commercial accounts. LOCATE mode I/O
using BASED reduced CPU enough to make up for the poor performance of
the rest of the code.
[color=blue]
>[color=green]
>> PL/I(F) was, in fact, a fast compiler.[/color]
>
> well, fast enough, but not fast.
> WATFOR was like a rocket compared to PL/I-F.
> PL/C was a fast compiler, being some ten times faster than PL/I-F.[/color]

And, of course, both of the examples you cite were processing a full
feature language like PL/I and generating production quality code...
Don't think so... Oh, and what was the year of these compilers? Again,
remember, PL/I(F) was required to execute in NO MORE than 44K of REAL
storage.
[color=blue]
>[color=green]
>> But, the resulting code was
>> awful![/color]
>
> Don't recall it being particularly slow.[/color]

What version of (F) were you using?
[color=blue]
>[color=green]
>> The second release added more language, including RECORD I/O,
>> and then some work was begun in trying to optimize the code generated by
>> the compiler until a real optimizing compiler to replace the hole left
>> by the missing (H) could be developed. By the time (F) Version 5 came
>> out, the code was at least acceptable.[/color]
>
> The code was OK with the first release. Yes, it had some
> bugs.[/color]
Back then, just running was considered successful.
[color=blue]
>[color=green]
>> * During this period, research on code optimization was being done by
>> IBM in Boulder.[/color]
>
> The research had already been done. The FORTRAN H compiler was out.[/color]

See above! Your time-line is all out of kilter!
[color=blue]
>[color=green]
>> It was that research base that was used for the
>> Optimizing Compiler, although all the development work was still done it
>> Hursley. Hursley also did the Checkout development. But, this was not
>> even a glimmer in someone's eye at the time of the S/360 and the
>> original announcement of "NPL" which was renamed PL/I.
>>[/color][/color]

CG wrote:
[color=blue]
> robin wrote:
>[color=green]
>>
>> [...]
>> well, fast enough, but not fast.
>> WATFOR was like a rocket compared to PL/I-F.
>> PL/C was a fast compiler, being some ten times faster than PL/I-F.[/color]
>
>
> And, of course, both of the examples you cite were processing a full
> feature language like PL/I and generating production quality code...
> Don't think so... Oh, and what was the year of these compilers? Again,
> remember, PL/I(F) was required to execute in NO MORE than 44K of REAL
> storage.
>[/color]
Actually, both WATFOR (and later WATFIV and WATFIV-S) and PL/C supported
full-featured languages.

There were some differences between the language supported by WATFIV (I
never used WATFOR or WATFIV-S) and by FORTRAN IV (1966 standard) in that
WATFIV supported several features (e.g., CHARACTER type and, IIRC, some
format specifications that were not supported in any released version of
IBM FORTRAN).

The differences between the languages supported by PL/C and PL/I were in
the other direction: PL/C did not support all of the features of PL/I.
For example, PL/C used reserved words. When reading someone else's PL/I
source code I could always tell which compiler they used first. If all
the variable names were misspelled English words, then they had learned
PL/I using PL/C first (either that or they had graduated from U.S.
public schools :-)). Also, IIRC, PL/C did not support AREAs or OFFSETs.
I don't remember whether PL/C supported PICTURE format or DECIMAL
variable types. Nevertheless, the language supported by PL/C was fairly
robust.

However, as CG suggests, neither compiler generated production-quality
code. In fact, I don't recall either compiler generating a useful
object file. I believe they were both compile-and-go implementations.
I know they both produced object code with a _lot_ of overhead designed
to make debugging easier.

For example, WATFIV reserved certain values for various data types to
indicate "uninitialized" and would generate a run-time error message
when a program attempted to use the value of an uninitialized variable.
This produced some amusing results for LOGICAL variables. WATFIV
defined 3 LOGICAL values: ".TRUE.", ".FALSE.", and "<uninitialized>"
but, since the smallest LOGICAL variable was one byte, that left at
least 253 other possible bit patterns with no defined value. In those
days, IBM FORTRAN did not have a CHARACTER type or an INTEGER*1 type,
but it did have a LOGICAL*1 type and arrays of LOGICAL*1 were often used
to store characters -- typically initialized in a type statement
("declaration statement" in any other language) or DATA statement -- and
this was one way those non-standard 253 values could end up in a
LOGICAL*1 variable. Sometimes these FORTRAN programs were compiled and
run using WATFIV in order to get fast compile-and-run times for
debugging purposes. I've forgotten how IBM FORTRAN handled those
non-standard LOGICAL values, but WATFIV implemented .AND., .OR., and
..NOT. as bitwise operations on their arguments. When WATFIV printed a
LOGICAL value using L format, it printed one of 4 characters: "T" for
".TRUE.", "F" for ".FALSE.", "U" for "<uninitialized>", and "J" for any
of the other 253+ bit patterns. I never did figure out how they picked "J".

Anyhow, IIRC, both WATFIV and PL/C produced run-time messages whenever
an attempt was made to use the value of an uninitialized variable and
each generated a bunch of other overhead used for detecting other
run-time errors. The objective was to compile source code as quickly as
possible into something that would be easy to debug. I believe both
were originally only intended for use in teaching so the source programs
would typically be small and run fast after compiling quickly. But they
were also very useful for debugging production code. Neither made any
attempt at optimization because that would have defeated the objectives
of fast compilation and easy debuggability.


Bob Lidral
lidral at alum dot mit dot edu

CG wrote:
[color=blue]
> Yep! But, FORTRAN is a much smaller language so the storage required
> for the compiler code would be a lot smaller. And, the FORTRAN-H
> compiler did not hit the marked until much later than the first S/360s.
> FORTRAN-G was the most common FORTRAN compiler for a long time.[/color]

FORTRAN (G), however, came after FORTRAN (H), in response to customer
complaints that FORTRAN (E) was inadequate and FORTRAN (H) too heavyweight.
[color=blue]
> But the original FORTRAN H optimization was not as good as the
> Optimizer. The original FORTRAN H was not a real hit. FORTRAN-H V2
> [the one written in FORTRAN][/color]

The original FORTRAN (H) was written in FORTRAN; FORTRAN H (Extended)
was just an upgrade.

--
John W. Kennedy
"The blind rulers of Logres
Nourished the land on a fallacy of rational virtue."
-- Charles Williams. "Taliessin through Logres: Prelude"

On Sun, 14 May 2006 20:08:23 -0700, robin <robin_v@bigpond.com> wrote:
[color=blue]
> "Tom Linden" <tom@kednos.com> wrote in message
> newsp.s9j1o6hnzgicya@hyrrokkin...[color=green]
>> On Sun, 14 May 2006 11:19:47 -0700, CG
>> <carl.gehr.RemoveThis@ThisToo.attglobal.net> wrote:
>>[color=darkred]
>> >> Was the H compiler written in PL/I?
>> >
>> > I believe there was some thought that this might be done,
>> > but I think the project was totally dropped before any
>> > real work was done. I don't think the first line of actual
>> > code was ever written. The effort was on making the (F)
>> > compiler into a production level tool.
>> >
>> > The Optimizer and the Checkout compilers were written using
>> > some highly customized macros and PL/S.[/color]
>>
>> There was an effort, which I think started around 1980 to write a new
>> compiler written in PL/I. It was under contract with Intermetrics and
>> was managed by St. Thersa, the names Steve Weiss (?) and Dave Klausner
>> from the labs spring to mind. It was ultimately cancelled a couple of
>> years
>> later after having spent $11M. IBM subsequently came knocking at my
>> door
>> because we had a solid full ansi compiler which was successfully running
>> on almost all the 'other'computers. IBM wanted a turnkey project[/color]
>
> Why would they want that? as they already had the PL/I
> optimising & checkout compilers - and for the full
> language.
>
>[/color]
I was told they wanted an ANSI compliant compiler writtem in PL/I that
was easier to maintain and extensible.

On Sun, 14 May 2006 22:22:12 -0700, CG
<carl.gehr.RemoveThis@ThisToo.attglobal.net> wrote:
[color=blue]
> The OS/2 compiler was a major upgrade on
> features in 1994 - a development that has continued
> since, and has been ported to the mainframe, AIX, etc.
> Gee! From my earlier post in response to Tom, I said:[color=green]
>> That compiler is also the base for the
>> Windows, AIX, VA PL/I for OS/390 and the Enterprise PL/I
>> for z/OS compilers.[/color]
>[/color]
Carl, What I never really understood is why IBM didn't use PL/I for
implementation, Multics PL/I was bootstrapped in 1967 and certainly the
folks at IBM knew what was going on.

CG wrote:[color=blue]
> John W. Kennedy wrote:[color=green]
>> CG wrote:[color=darkred]
>>>> In fact, if such a compiler was proposed, it was dropped
>>>> in order to deliver IBM's PL/I Optimising Compiler and the
>>>> Checkout compiler in 1970.
>>> No, not true. The Optimizer and Checkout compiler
>>> came later.[/color]
>>
>> Although the Optimizer and Checker obviously recycled the three-letter
>> prefixes IEL and IEN that had once been allocated to the PL/I (E) and
>> (H) compilers.[/color]
> Sorry, never was a PL/I(E).[/color]

At least one magazine at the time (Datamation, perhaps) reported it has
having been decommitted along with PL/I (H). (Perhaps it was simply a
projected OS/360 version of PL/I (D), just as with COBOL (D) and COBOL (E).)
[color=blue][color=green]
>> I have always wondered whether the eventually delivered Assembler H
>> was based on the Assembler H that had been decommitted at the same time.[/color][/color]
[color=blue]
> Actually, I suspect that the Assembler that you are referring to, while
> it has an 'H' in the acronym [HLASM] is actually the "High Level
> Assembler" not an 'H-Level' Assembler.[/color]

HLASM replaced Assembler (H). Assembler (H) (IEV90) was one of the very
first Program Products, ca. 1969, and was, incidentally, required for
assembling the Optimizer and Checker source. It offered one-pass
processing (with look-forward where necessary) and quite a few
extensions to the macro-definition language.
[color=blue]
> The HLASM product was actually built on the "System Assembler" that was
> packaged with and delivered as an integral part of the operating system.[/color]

It does not seem to be. All the artifacts I can detect in the Language
Reference and the Programmer's Guide suggest that it was either written
de-novo or based on Assembler (H).

--
John W. Kennedy
"The blind rulers of Logres
Nourished the land on a fallacy of rational virtue."
-- Charles Williams. "Taliessin through Logres: Prelude"