iBM System/3 FORTRAN for engineering/science work?

529 views
Skip to first unread message

undefined Hancock-4

unread,
Jun 16, 2021, 2:59:13 PM6/16/21
to
Even the low-end models of IBM's System/360 proved too expensive for small business, so in 1969 IBM introduced the budget priced System/3. Notable was the tiny 96 column punched card.

According to the manual (on Bitsavers), the IBM System/3 did support a Fortran compiler. However, I think the hardware did not have floating point and was only oriented toward business processing. My _guess_ is that the System/3 would run Fortran programs rather slowly and Fortran or sci/eng work was rarely done.

Would anyone have any experience or knew of System/3 sites that used Fortran? If so, how did it work out for them? The impression I got was the vast majority of S/3 sites used RPG II developed for it.

I'm pretty sure the System/3 supported BASIC. While BASIC wasn't as good as Fortran, it could handle some number crunching work. That was certainly adequate for some users.

My guess is that extremely few customers bought a System/3 to do sci/eng work--there were too many other better choices available at the time. But it's certainly possible that some sites, while doing primarily business work, might have a eng/sci application here and there and may have run them, albeit slowly. Heck, they have the machine on site already, so use it.

IBM ads 1970-71 (Hard to believe this was 50 years ago):
https://archive.org/details/Nations-Business-1970-01/page/n17/mode/2up

https://archive.org/details/Nations-Business-1971-01/page/n29/mode/2up

https://archive.org/details/Nations-Business-1971-02/page/n5/mode/2up

https://archive.org/details/Nations-Business-1971-03/page/n13/mode/2up


(I don't know about the later S/34, S/36, and S/38 running Fortran or sci/eng applications. As more powerful machines, they may have had more capability, so it may not have been an issue.)

J. Clarke

unread,
Jun 16, 2021, 4:08:19 PM6/16/21
to
I don't know if it was true for System/3, but at least some AS/400
sites just used packaged applications. I have a working AS/400
downstairs (or at least it was working 20 years ago--I haven't tried
to run it in a long time--something about lugging the terminal down a
flight of narrow stairs) and to my annoyance it did not have RPG or
BASIC or any other programming language installed.

Rich Alderson

unread,
Jun 18, 2021, 2:31:18 PM6/18/21
to
undefined Hancock-4 <hanc...@bbs.cpcn.com> writes:

> Would anyone have any experience or knew of System/3 sites that used Fortra=
> n? If so, how did it work out for them? The impression I got was the vast=
> majority of S/3 sites used RPG II developed for it.

RPG III. RPG II is the System/360 version.

--
Rich Alderson ne...@alderson.users.panix.com
Audendum est, et veritas investiganda; quam etiamsi non assequamur,
omnino tamen proprius, quam nunc sumus, ad eam perveniemus.
--Galen

Dan Espen

unread,
Jun 18, 2021, 4:00:37 PM6/18/21
to
Rich Alderson <ne...@alderson.users.panix.com> writes:

> undefined Hancock-4 <hanc...@bbs.cpcn.com> writes:
>
>> Would anyone have any experience or knew of System/3 sites that used Fortra=
>> n? If so, how did it work out for them? The impression I got was the vast=
>> majority of S/3 sites used RPG II developed for it.
>
> RPG III. RPG II is the System/360 version.

Not the way I remember it, and Wikipedia agrees with me.
RPG II on S/3, S/34, S/36

RPG III on S/38, AS/400.

RPG IV for OS/400.

I had to rescue a failing RPG project on a Sys/34.
One of the first things we did was order the COBOL compiler.
I don't have any impression of the speed of the processor, just
that it was always fast enough for our application.

--
Dan Espen

undefined Hancock-4

unread,
Jun 26, 2021, 3:40:24 PM6/26/21
to
While the AS/400 evolved from the S/3 midrange product line, it was a very different machine. There were other machines in between like the S/36 series.

Note, unlike the original S/3 and the S/360 et al, which had a defined architecture and instruction set (to this day), the AS/400 used something vague called Licensed Internal Code. One model could vary from the next.

The instruction set of the original System/3 is available on bitsavers. Not sure how many people bothered to program that machine in assembler since it was intended for smaller shops and easy to use. My impression was that most S/3 sites used RPG II or even canned routines. But the IBM literature said Fortran was available. How much it was used or how well it ran I don't know. Sometimes IBM would offer something that in reality didn't run very well on a given machine and got little use.

undefined Hancock-4

unread,
Jun 26, 2021, 3:47:46 PM6/26/21
to
On Friday, June 18, 2021 at 4:00:37 PM UTC-4, Dan Espen wrote:
> Rich Alderson <ne...@alderson.users.panix.com> writes:
>
> > undefined Hancock-4 <hanc...@bbs.cpcn.com> writes:
> >
> >> Would anyone have any experience or knew of System/3 sites that used Fortra=
> >> n? If so, how did it work out for them? The impression I got was the vast=
> >> majority of S/3 sites used RPG II developed for it.
> >
> > RPG III. RPG II is the System/360 version.
> Not the way I remember it, and Wikipedia agrees with me.
> RPG II on S/3, S/34, S/36
>
> RPG III on S/38, AS/400.
>
> RPG IV for OS/400.

Yes.

Then they came out with a Visual RPG.

I don't know what is done these days on the i series machines or whatever has succeeded the AS/400. Indeed, IBM's website is very vague about their product lines, now talking about "solutions". Makes and models are very vague. (Cars are like that too, these days, Toyota offers a Corolla, but then they offer many trim lines that are confusing. Same with Camry).



> I had to rescue a failing RPG project on a Sys/34.
> One of the first things we did was order the COBOL compiler.
> I don't have any impression of the speed of the processor, just
> that it was always fast enough for our application.

I think the COBOL language on the AS/400 was nice. But I'm not sure how well it ran. We had COBOL on a AS/400 but it ran very slow. It may have been the machine was just underpowered for what we wanted to do on it, I didn't get into the details.

I was not a big fan of the AS/400 line. But I must admit its users loved it. There used to be a magazine, Midrange Computing, almost a cult following. And I must guess that setting up a new installation cold was probably easier with an AS/400 from a Z series, probably a lot of stuff was automated, and far less configuration and system programming was needed. Of course, if the site got big enough, then performance may have become an issue--large sites have do need some configuration to keep things orderly. (And there was an AS/400 Performance Manual).







Dan Espen

unread,
Jun 26, 2021, 4:40:26 PM6/26/21
to
This same company with the S/34 had a pretty large mainframe.
Every month the mainframe would do a manufacturing cost calculation.
This run was well known for taking forever to complete. Sometimes
a day or 2.

I implemented my own costing algorithms on the S/34 and we'd
complete the calculation in 15 or 20 minutes. I think I just had a
better algorithm but I never considered the machine slow.

I was not a fan of the direction the AS/400 (and S/38) went off in.
I liked the S/34 because of it's simplicity. The AS/400 retained the
good parts but had too much stuff you'd only find on an AS/400.

I once ported a load of S/34 code to a Wang/VS system. Easy.
If I was starting with an AS/400 it might not have been so easy.

The COBOL compiler was a dream. Never once did I confront a dump.

We put S/34s in 4 plants and a central office.
The existing clerical staff was able to do everything the system needed for
day to day operation. Nothing like a mainframe.

--
Dan Espen

Grant Taylor

unread,
Jun 26, 2021, 5:14:50 PM6/26/21
to
On 6/26/21 1:40 PM, undefined Hancock-4 wrote:
> Note, unlike the original S/3 and the S/360 et al, which had a
> defined architecture and instruction set (to this day), the AS/400
> used something vague called Licensed Internal Code. One model could
> vary from the next.

I'm quite sure that the same concept, if not the same thing, was used on
many different IBM systems. I've heard tell of some S/360s implementing
instructions via microcode, a.k.a. Licensed Internal Code ~> LIC, that
other S/360s had in hardware.

I know that my P/390-E requires LIC to run. I've heard tell that
ES/9000s (a line of mainframes) required LIC to run.

I hear discussion of LIC on modern z/Series systems.

The LIC functions as a line / family specific abstraction layer that
allows the underlying hardware to fulfil the API (if you will allow me
the analogy) that the LIC provided to OS & other software running on the
system.



--
Grant. . . .
unix || die

Grant Taylor

unread,
Jun 26, 2021, 5:20:01 PM6/26/21
to
On 6/26/21 2:40 PM, Dan Espen wrote:
> The existing clerical staff was able to do everything the system
> needed for day to day operation. Nothing like a mainframe.

Yep. IMHO AS/400s a.k.a. i/Series were notorious for putting them in
offices, connect a number of terminals and mostly forgetting about them.

State Farm had an AS/400 in every single agent's office in the U.S.A.
from the mid '90s through at least 2010. (I don't know about after
that.) They would link back to mainframes in multi (many) state
regional offices via leased line and / or dial up connections. My
understanding is that the '400s were almost set them and forget them.

John Levine

unread,
Jun 26, 2021, 9:27:05 PM6/26/21
to
According to Grant Taylor <gta...@tnetconsulting.net>:
>On 6/26/21 1:40 PM, undefined Hancock-4 wrote:
>> Note, unlike the original S/3 and the S/360 et al, which had a
>> defined architecture and instruction set (to this day), the AS/400
>> used something vague called Licensed Internal Code. One model could
>> vary from the next.
>
>I'm quite sure that the same concept, if not the same thing, was used on
>many different IBM systems. I've heard tell of some S/360s implementing
>instructions via microcode, a.k.a. Licensed Internal Code ~> LIC, that
>other S/360s had in hardware.

Sort of. The s/3, s/34, and s/36 were small commercial machines with conventional architectures.

The s/38 had a virtual instruction set which was translated to machine code the first time a progrm ran.
The as/400 and later i series were upward compatible with that virtual instruction set, despite having
very different underlying hardware.

The various models of s/360 all had the same instruction set visible to the programmer (give or take
the decimal and floating point features which were optional on small models), again with very different
hardware. The 360/30 was a heavily microcoded 8 bit machine, the /65 was a microcoded 32 bit machine,
the /75 was hard wired. On the microcoded models there were options to emulate 1400 and 709x machines.
Other than the emulators I don't think there was any licensed microcode.

In later years they did have licensed microcode accelerators and a variety of licensing games like
a Linux applcation processor which was a regular processor minus an instruction or two but didn't
count as a CPU for software licenses.

--
Regards,
John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

Dennis Boone

unread,
Jun 27, 2021, 5:00:08 PM6/27/21
to
> State Farm had an AS/400 in every single agent's office in the U.S.A.
> from the mid '90s through at least 2010. (I don't know about after
> that.) They would link back to mainframes in multi (many) state
> regional offices via leased line and / or dial up connections. My
> understanding is that the '400s were almost set them and forget them.

Last I was in my agent's office (year and a half? covid...), they were
still using 5250 emulation for at least some applications, but I don't
know where it connected.

De

Anne & Lynn Wheeler

unread,
Jun 27, 2021, 7:40:32 PM6/27/21
to
"Kerr-Mudd, John" <ad...@127.0.0.1> writes:
> Does anyone recall these computers?
> https://en.wikipedia.org/wiki/IBM_8100

communication group greatly underpowered line of UC processors ... also
used in 37x5 boxes (science center had tried to get them to use
significantly better peachtree processor developed for series/1 in 37x5
boxes). Later, at one point Evans asks my wife to audit 8100 ... short
time later, 8100 was "decommitted".

--
virtualization experience starting Jan1968, online at home since Mar1970

Peter Flass

unread,
Jun 28, 2021, 8:28:45 PM6/28/21
to
A lot of times to meet a customer (government) specification that
required, e.g. FORTRAN, even though the customer probably never used it.

--
Pete

Peter Flass

unread,
Jun 28, 2021, 8:28:46 PM6/28/21
to
undefined Hancock-4 <hanc...@bbs.cpcn.com> wrote:
> On Friday, June 18, 2021 at 4:00:37 PM UTC-4, Dan Espen wrote:
>> Rich Alderson <ne...@alderson.users.panix.com> writes:
>>
>>> undefined Hancock-4 <hanc...@bbs.cpcn.com> writes:
>>>
>>>> Would anyone have any experience or knew of System/3 sites that used Fortra=
>>>> n? If so, how did it work out for them? The impression I got was the vast=
>>>> majority of S/3 sites used RPG II developed for it.
>>>
>>> RPG III. RPG II is the System/360 version.
>> Not the way I remember it, and Wikipedia agrees with me.
>> RPG II on S/3, S/34, S/36
>>
>> RPG III on S/38, AS/400.
>>
>> RPG IV for OS/400.
>
> Yes.
>
> Then they came out with a Visual RPG.
>
> I don't know what is done these days on the i series machines or whatever
> has succeeded the AS/400. Indeed, IBM's website is very vague about
> their product lines, now talking about "solutions". Makes and models are
> very vague. (Cars are like that too, these days, Toyota offers a
> Corolla, but then they offer many trim lines that are confusing. Same with Camry).
>

This is an unfortunate trend that the remaining computer manufacturers
started some years ago. At one point I was looking for some documentation
from UNISYS, and it was like an archeological dig to find it.

--
Pete

Peter Flass

unread,
Jun 28, 2021, 8:28:47 PM6/28/21
to
But, if I remember correctly, the “architecture specification” for System i
is about the level of P-code, and is completely interpreted on every model.

--
Pete

Peter Flass

unread,
Jun 28, 2021, 8:28:48 PM6/28/21
to
Kerr-Mudd, John <ad...@127.0.0.1> wrote:
> Does anyone recall these computers?
> https://en.wikipedia.org/wiki/IBM_8100
>

Vaguely recall reading about it, never worked on it. Sounded like a real
fog to me, I think you had to compile its programs on the mainframe.

--
Pete

undefined Hancock-4

unread,
Jun 29, 2021, 3:55:26 PM6/29/21
to
On Saturday, June 26, 2021 at 5:14:50 PM UTC-4, Grant Taylor wrote:


> I'm quite sure that the same concept, if not the same thing, was used on
> many different IBM systems. I've heard tell of some S/360s implementing
> instructions via microcode, a.k.a. Licensed Internal Code ~> LIC, that
> other S/360s had in hardware.

From what I saw on the AS/400, I don't think "LIC" was comparable to microcode.

I think microcode was at a very low level. As far as I know, an application programmer never touched it,
if it was even accessible. Application programmers stuck with assembler. I don't think even specialty
developers touched it since each microcode was different for each model, which would create incompatibilities.

In contrast, I remember fiddling with settings on the AS/400 and getting to see the LIC that was generated
from my compilation. Accordingly, while LIC was still low level, I think it was at a higher level than S/360
microcode and not comparable.

undefined Hancock-4

unread,
Jun 29, 2021, 4:04:19 PM6/29/21
to
On Monday, June 28, 2021 at 8:28:45 PM UTC-4, Peter Flass wrote:
> undefined Hancock-4 <hanc...@bbs.cpcn.com> wrote:

> > The instruction set of the original System/3 is available on bitsavers.
> > Not sure how many people bothered to program that machine in assembler
> > since it was intended for smaller shops and easy to use. My impression
> > was that most S/3 sites used RPG II or even canned routines. But the IBM
> > literature said Fortran was available. How much it was used or how well
> > it ran I don't know. Sometimes IBM would offer something that in reality
> > didn't run very well on a given machine and got little use.
> >
> A lot of times to meet a customer (government) specification that
> required, e.g. FORTRAN, even though the customer probably never used it.

Yes, govt specs mandated a lot of unnecessary stuff*.

Sometimes a customer, or perhaps a consultant, would get the 'bright idea' of
using a non standard language to do some funky task. For example, Fortran in
an otherwise business environment (or COBOL in an eng/sci site).

I've seen lots of people try to run Fortran on their S/360 only to discover it
didn't have the universal instruction set and they had to find a machine that
did (often that turned out to be our site).

Anyway, people would have these exotic funky programs that usually proved
to be far too abstract and poorly written to be practical and accomplish anything.

For whatever reason, high management would be enamored with these funky
proposals and insist on trying them out, even if their IT staff studied it and
advised against it.

My guess is that that S/3 got Fortran for that reason in addition to govt specs.


* One frustration was COBOL on the IBM mainframe. IBM had a lot of extensions
that while officially non standard, were basically standard since everyone used them
(like COMP-3). But some govt specs required 'standard' ANSI COBOL and no IBM
extensions. That meant programmers had to get up to speed on unfamiliar stuff
and often the code ran slower.

I know of one site that for years stuck with 'standard' COBOL and finally bit the
bullet and used the IBM extensions that everyone else used. Productivity was
substantially improved.

Charlie Gibbs

unread,
Jun 29, 2021, 5:34:28 PM6/29/21
to
On 2021-06-29, undefined Hancock-4 <hanc...@bbs.cpcn.com> wrote:

> On Monday, June 28, 2021 at 8:28:45 PM UTC-4, Peter Flass wrote:
>
>> A lot of times to meet a customer (government) specification that
>> required, e.g. FORTRAN, even though the customer probably never used it.
>
> Yes, govt specs mandated a lot of unnecessary stuff*.

The Univac 9300 had a totally useless COBOL compiler for that reason.

Politics made for strange hardware situations too. At one government
office, someone was taking visitors on a tour and proudly proclaimed,
"...and here is our computer room," and threw the door open on a room
that was totally empty. So they got a computer to fill the room,
where it sat unused until the shop I was working at picked it up
for a song.

> * One frustration was COBOL on the IBM mainframe. IBM had a lot of
> extensions that while officially non standard, were basically standard
> since everyone used them (like COMP-3). But some govt specs required
> 'standard' ANSI COBOL and no IBM extensions. That meant programmers
> had to get up to speed on unfamiliar stuff and often the code ran
> slower.
>
> I know of one site that for years stuck with 'standard' COBOL and
> finally bit the bullet and used the IBM extensions that everyone
> else used. Productivity was substantially improved.

Mind you, you had to know when to use the extensions. I was once
called in to figure out why a COBOL program was running so slowly.
It did a lot of subscripting, and the genius who wrote it declared
all subscripts as COMP-3. Almost wore out the CVB instruction. :-)
Changing all subscripts to COMP-4 knocked 30% off the execution time.

--
/~\ Charlie Gibbs | They don't understand Microsoft
\ / <cgi...@kltpzyxm.invalid> | has stolen their car and parked
X I'm really at ac.dekanfrus | a taxi in their driveway.
/ \ if you read it the right way. | -- Mayayana

John Levine

unread,
Jun 29, 2021, 6:47:25 PM6/29/21
to
According to Peter Flass <peter...@yahoo.com>:
>> The LIC functions as a line / family specific abstraction layer that
>> allows the underlying hardware to fulfil the API (if you will allow me
>> the analogy) that the LIC provided to OS & other software running on the
>> system.
>
>But, if I remember correctly, the “architecture specification” for System i
>is about the level of P-code, and is completely interpreted on every model.

It's not interpreted, it's compiled to machine code the first time a program
is run, but they go to great effort to make that invisible to the programmer.
I gather you can debug at the architecture instruction level.

Peter Flass

unread,
Jun 30, 2021, 2:44:31 PM6/30/21
to
undefined Hancock-4 <hanc...@bbs.cpcn.com> wrote:
> On Monday, June 28, 2021 at 8:28:45 PM UTC-4, Peter Flass wrote:
>> undefined Hancock-4 <hanc...@bbs.cpcn.com> wrote:
>
>>> The instruction set of the original System/3 is available on bitsavers.
>>> Not sure how many people bothered to program that machine in assembler
>>> since it was intended for smaller shops and easy to use. My impression
>>> was that most S/3 sites used RPG II or even canned routines. But the IBM
>>> literature said Fortran was available. How much it was used or how well
>>> it ran I don't know. Sometimes IBM would offer something that in reality
>>> didn't run very well on a given machine and got little use.
>>>
>> A lot of times to meet a customer (government) specification that
>> required, e.g. FORTRAN, even though the customer probably never used it.
>
> Yes, govt specs mandated a lot of unnecessary stuff*.
>
> Sometimes a customer, or perhaps a consultant, would get the 'bright idea' of
> using a non standard language to do some funky task. For example, Fortran in
> an otherwise business environment (or COBOL in an eng/sci site).

We were a COBOL shop, but there was one funky stat program in FORTRAN to
analyze employee data or something. I think it was at least a tray of
cards. I don’t know who wrote it, or when, or even if it was ever run while
I was there, but it was the Director’s pet.

>
> I've seen lots of people try to run Fortran on their S/360 only to discover it
> didn't have the universal instruction set and they had to find a machine that
> did (often that turned out to be our site).

I’m surprised someone didn’t write FP emulation routines and distribute
them thru SHARE or something. I know this was later done for the Intel 386.

>
> Anyway, people would have these exotic funky programs that usually proved
> to be far too abstract and poorly written to be practical and accomplish anything.
>
> For whatever reason, high management would be enamored with these funky
> proposals and insist on trying them out, even if their IT staff studied it and
> advised against it.

I wrote a bunch of PL/I programs, but never convinced anyone to do any
production stuff in it.

>
> My guess is that that S/3 got Fortran for that reason in addition to govt specs.
>


--
Pete

Peter Flass

unread,
Jun 30, 2021, 2:44:32 PM6/30/21
to
At least they didn’t code (or default) them USAGE IS DISPLAY, which I saw
from rime romtime.

Almost wore out the CVB instruction. :-)
> Changing all subscripts to COMP-4 knocked 30% off the execution time.
>



--
Pete

Rich Alderson

unread,
Jun 30, 2021, 3:56:42 PM6/30/21
to
Peter Flass <peter...@yahoo.com> writes:

> I wrote a bunch of PL/I programs, but never convinced anyone to do any
> production stuff in it.

Prior to moving into systems programming, I was a programmer/analyst in the
Financial Systems group for the University of Chicago Computation Center. The
accounting system was a suite of COBOL programs purchased from a commercial
vendor which ran on SVS (= OS/VS2 v1) on an Amdahl 470.

Our standard was to make mods for localization in COBOL, but to write any
external utilities in PL/I using the optimizing compiler. That's what got me
in the door: I had been writing PL/1 for 10 years already when I got the job.

(NB: When I first started programming, the language was called "PL/1" in the
IBM manuals; by the time I started using it professionally, years before the
UChicago job, they had gone to the "PL/I" version of the name.)

Bob Eager

unread,
Jun 30, 2021, 6:15:12 PM6/30/21
to
On Wed, 30 Jun 2021 15:56:40 -0400, Rich Alderson wrote:

> (NB: When I first started programming, the language was called "PL/1"
> in the
> IBM manuals; by the time I started using it professionally, years
> before the UChicago job, they had gone to the "PL/I" version of the
> name.)

One of my colleagues did his Ph.D. in the 1960s. He had also worked for
IBM. Part of his research was the construction of a general purpose macro
language and processor.

As a piss take of IBM, he called it ML/I. (Macro Language 1)

http://www.ml1.org.uk



--
Using UNIX since v6 (1975)...

Use the BIG mirror service in the UK:
http://www.mirrorservice.org

Louis Krupp

unread,
Jun 30, 2021, 7:58:36 PM6/30/21
to
Once upon a time, Harris Corporation made minicomputers designed for
number-crunching. One day, their management decided to get into the data
processing business, so they got a company that wrote academic
administrative software to agree to sell their package only with a
Harris computer. The computer's instruction set wasn't designed for data
processing, and the Harris COBOL compiler generated library calls to do
basically everything -- moves, arithmetic, etc -- except for branches.
The resulting runtime performance was bad.

One of my favorite projects was writing a Harris assembler program to
read and print Burroughs printer backup tapes. As an offline printer,
the machine did well.

And it had the coolest lights on the operator's console.

Louis

Robin Vowels

unread,
Jun 30, 2021, 9:10:28 PM6/30/21
to
.
Yes. IBM did it for PL/I for OS/2, namely, emulate floating-point for the 386
when it did not have the Math coprocessor.

Robin Vowels

unread,
Jun 30, 2021, 9:23:20 PM6/30/21
to
On Thursday, July 1, 2021 at 5:56:42 AM UTC+10, Rich Alderson wrote:
> Peter Flass <peter...@yahoo.com> writes:
>
> > I wrote a bunch of PL/I programs, but never convinced anyone to do any
> > production stuff in it.
> Prior to moving into systems programming, I was a programmer/analyst in the
> Financial Systems group for the University of Chicago Computation Center. The
> accounting system was a suite of COBOL programs purchased from a commercial
> vendor which ran on SVS (= OS/VS2 v1) on an Amdahl 470.
>
> Our standard was to make mods for localization in COBOL, but to write any
> external utilities in PL/I using the optimizing compiler. That's what got me
> in the door: I had been writing PL/1 for 10 years already when I got the job.
>
> (NB: When I first started programming, the language was called "PL/1" in the
> IBM manuals;
.
No, IBM always called it "PL/I", even from the first manuals for PL/I-F,
with one exception, I think for AS400.
.
Before the 360 compilers, it was transiently named FORTRAN V and NPL among others.
.

Thomas Koenig

unread,
Jul 1, 2021, 1:12:07 AM7/1/21
to
Bob Eager <news...@eager.cx> schrieb:

> One of my colleagues did his Ph.D. in the 1960s. He had also worked for
> IBM. Part of his research was the construction of a general purpose macro
> language and processor.
>
> As a piss take of IBM, he called it ML/I. (Macro Language 1)
>
> http://www.ml1.org.uk

Seems far more readable than m4 (which is the serious programming
language that I would consier most unreadable).

Or are there others? Joke languages like Intercal need not apply :-)

Bob Eager

unread,
Jul 1, 2021, 2:28:28 AM7/1/21
to
There really aren't many others. I learned it in 1971, and still use it.
But ther is not much call for general purpose macro processors these
days. A few years ago I used it to process some files where others in a
Usenet group had all failed.

Ahem A Rivet's Shot

unread,
Jul 1, 2021, 8:30:03 AM7/1/21
to
On Thu, 1 Jul 2021 05:12:05 -0000 (UTC)
Thomas Koenig <tko...@netcologne.de> wrote:

> Seems far more readable than m4 (which is the serious programming
> language that I would consier most unreadable).

XSLT and sendmail.cf are both less readable IMHO - XSLT control
flow is essentially come-from with wildcards.

--
Steve O'Hara-Smith | Directable Mirror Arrays
C:\>WIN | A better way to focus the sun
The computer obeys and wins. | licences available see
You lose and Bill collects. | http://www.sohara.org/

Peter Flass

unread,
Jul 1, 2021, 2:25:41 PM7/1/21
to
IBM’s PL/I preprocessor is fairly general-purpose. The macros are written
in an interpreted subset of PL/I.

--
Pete

undefined Hancock-4

unread,
Jul 1, 2021, 2:34:01 PM7/1/21
to
On Thursday, July 1, 2021 at 2:25:41 PM UTC-4, Peter Flass wrote:


> IBM’s PL/I preprocessor is fairly general-purpose. The macros are written
> in an interpreted subset of PL/I.

How popular was PL/I in its heyday? I knew of a few programmers who really loved
it and pushed it, but it never seemed to catch on that much.

How popular is it today? The people who liked it at my site have retired and its faded away.

IBM devoted a lot of scarce resources it didn't have to developing it as part of S/360.

undefined Hancock-4

unread,
Jul 1, 2021, 2:36:49 PM7/1/21
to
On Wednesday, June 30, 2021 at 2:44:31 PM UTC-4, Peter Flass wrote:


> We were a COBOL shop, but there was one funky stat program in FORTRAN to
> analyze employee data or something. I think it was at least a tray of
> cards. I don’t know who wrote it, or when, or even if it was ever run while
> I was there, but it was the Director’s pet.

That was very common. I think almost every site had a situation like that. "Director's
pet" as you say. Frustrating for the rest of us.

(I used to wonder how a Director or Asst Director, who probably were crackerjack
programmers in their day, could latch on to some dingbat scheme.)

undefined Hancock-4

unread,
Jul 1, 2021, 2:40:14 PM7/1/21
to
On Tuesday, June 29, 2021 at 5:34:28 PM UTC-4, Charlie Gibbs wrote:

> Mind you, you had to know when to use the extensions. I was once
> called in to figure out why a COBOL program was running so slowly.
> It did a lot of subscripting, and the genius who wrote it declared
> all subscripts as COMP-3. Almost wore out the CVB instruction. :-)
> Changing all subscripts to COMP-4 knocked 30% off the execution time.

OMG, that CVB (and the inverse) were killers. I had exclusive use of the
machine over the weekend and experimented with a program. COMP-3
was terrible as a subscript. (As someone noted, DISPLAY was even worse).

The opposite was true, too. Binary was not good for business processing
since that slow conversion was necessary for all I/O.

Bob Eager

unread,
Jul 1, 2021, 4:22:55 PM7/1/21
to
Indeed. He mentions that in one of the write-ups. But ML/I does rather
more and is highly portable.

Peter Flass

unread,
Jul 1, 2021, 6:56:47 PM7/1/21
to
undefined Hancock-4 <hanc...@bbs.cpcn.com> wrote:
> On Thursday, July 1, 2021 at 2:25:41 PM UTC-4, Peter Flass wrote:
>
>
>> IBM’s PL/I preprocessor is fairly general-purpose. The macros are written
>> in an interpreted subset of PL/I.
>
> How popular was PL/I in its heyday? I knew of a few programmers who really loved
> it and pushed it, but it never seemed to catch on that much.

It came along a little later than the S/360 COBOL compiler, it required
more resources, and some programmers were already familiar with COBOL from
earlier machines, so it was never as popular. I think it did somewhat
better in Europe than in North America. In its heyday it was supported by
quite a fre mainframe manufacturers.
.
>
> How popular is it today? The people who liked it at my site have retired
> and its faded away.

I think it’s mostly “legacy” today. There are at least three compilers for
personal computers. I’d like to see it get more use, it’s a powerful
language, even in comparison with more recent languages.

>
> IBM devoted a lot of scarce resources it didn't have to developing it as part of S/360.
>

Yes, one system/one language for all purposes.


--
Pete

Rich Alderson

unread,
Jul 1, 2021, 7:00:02 PM7/1/21
to
TECO macros, especially the MIT PDP-10 dialect of TECO in which the original
version of EMACS was written. Looks like line noise...

Old .sig:

Rich Alderson Last LOTS Tops-20 Systems Programmer, 1984-1991
Current maintainer, MIT TECO EMACS (v. 170)
last name @ XKL dot COM Customer Interface, XKL LLC

Robin Vowels

unread,
Jul 1, 2021, 11:57:14 PM7/1/21
to
On Friday, July 2, 2021 at 8:56:47 AM UTC+10, Peter Flass wrote:
> undefined Hancock-4 <hanc...@bbs.cpcn.com> wrote:
> > On Thursday, July 1, 2021 at 2:25:41 PM UTC-4, Peter Flass wrote:
> >
> >
> >> IBM’s PL/I preprocessor is fairly general-purpose. The macros are written
> >> in an interpreted subset of PL/I.
> >
> > How popular was PL/I in its heyday? I knew of a few programmers who really loved
> > it and pushed it, but it never seemed to catch on that much.
> It came along a little later than the S/360 COBOL compiler, it required
> more resources,
.
I do not have information on the resources required by IBM COBOL,
but PL/I-F ran in as little as 64K. I think that IBM PL/I-DOS
required a 32K machine.
DR PL/I ran in 64K byte PC.
.
Compared to FORTRAN in 1966, PL/I ran rings around it.
PL/I had superior syntax, superior error handling, and superior
debugging facilities.
Yet some FORTRAN users persisted in running programs that
crashed without any indication of where they crashed;
Multiple re-runs would be needed to track down the cause of an error.
With PL/I-F the cause of an error and the statement number where it
occurred were printed out. Furthermore, the values of variables
could also be printed.
.
When it came to production runs, PL/I had the ability to continue after
encountering bad data, carrying on to completion, without the need for
a call in the early hours to patch the program.
.
The ability to catch integer overflow (whether decimal or binary),
division by zero, floating-point overflow, subscript errors, and character
string errors is an important part of the language.
.
> and some programmers were already familiar with COBOL from
> earlier machines, so it was never as popular. I think it did somewhat
> better in Europe than in North America. In its heyday it was supported by
> quite a fre mainframe manufacturers.
> .
> > How popular is it today? The people who liked it at my site have retired
> > and its faded away.
> I think it’s mostly “legacy” today. There are at least three compilers for
> personal computers. I’d like to see it get more use, it’s a powerful
> language, even in comparison with more recent languages.
.
...

Charlie Gibbs

unread,
Jul 2, 2021, 7:29:34 PM7/2/21
to
Not all of them were crackerjack programmers. And hell hath no fury
like a director who sees what you've done to his precious spaghetti code.

Charlie Gibbs

unread,
Jul 2, 2021, 7:29:34 PM7/2/21
to
On 2021-07-02, Robin Vowels <robin....@gmail.com> wrote:

> I do not have information on the resources required by IBM COBOL,
> but PL/I-F ran in as little as 64K. I think that IBM PL/I-DOS
> required a 32K machine.
> DR PL/I ran in 64K byte PC.
>
> Compared to FORTRAN in 1966, PL/I ran rings around it.

FSVO "ran rings". My only contact with PL/I was at university,
where everything ran under MTS. Admittedly, we were more
concerned with compile time rather than execution time, but
when it came to compilations PL/I was a pig, eating up more
CPU time and memory (and funny money in our student accounts)
than any other language processor (although Assembler G came
close). Fortran G compiled like lightning. Forget about COBOL -
to the CS weenies, uttering its name was an even worse profanity
than GOTO. There wasn't even a COBOL compiler on the system.
(If you were desperate, you could submit a compile request for
overnight batch, where the operators would run it under OS/360
emulation.) Needless to say, RPG did not exist. Period.

>>> How popular is it today? The people who liked it at my site
>>> have retired and its faded away.
>>
>> I think it’s mostly “legacy” today. There are at least three
>> compilers for personal computers. I’d like to see it get more
>> use, it’s a powerful language, even in comparison with more
>> recent languages.

Apparently the Insurance Corporation of British Columbia
(set up by the incoming NDP government in the 1970s to take
over all motor vehicle insurance from the private sector)
had all their brand-new software written in PL/I on a
"cost is no object" basis. Of course, being the provincial
government, it was subject to the usual 100% overruns...

John Levine

unread,
Jul 2, 2021, 9:19:40 PM7/2/21
to
According to Ahem A Rivet's Shot <ste...@eircom.net>:
>On Thu, 1 Jul 2021 05:12:05 -0000 (UTC)
>Thomas Koenig <tko...@netcologne.de> wrote:
>
>> Seems far more readable than m4 (which is the serious programming
>> language that I would consier most unreadable).
>
> XSLT and sendmail.cf are both less readable IMHO - XSLT control
>flow is essentially come-from with wildcards.

Um, sendmail.cf uses m4, which is why it's opaque.

Back in the day Trac (the macro language, not the bug tracker) was somewhat popular
but it's basically dead now.

Robin Vowels

unread,
Jul 2, 2021, 9:26:15 PM7/2/21
to
On Saturday, July 3, 2021 at 9:29:34 AM UTC+10, Charlie Gibbs wrote:
> On 2021-07-02, Robin Vowels <robin....@gmail.com> wrote:
>
> > I do not have information on the resources required by IBM COBOL,
> > but PL/I-F ran in as little as 64K. I think that IBM PL/I-DOS
> > required a 32K machine.
> > DR PL/I ran in 64K byte PC.
> >
> > Compared to FORTRAN in 1966, PL/I ran rings around it.
> FSVO "ran rings". My only contact with PL/I was at university,
> where everything ran under MTS. Admittedly, we were more
> concerned with compile time rather than execution time, but
> when it came to compilations PL/I was a pig, eating up more
> CPU time and memory (and funny money in our student accounts)
> than any other language processor (although Assembler G came
> close). Fortran G compiled like lightning.
.
What??!! IBM's FORTRAN G compiled at about the same speed as their PL/I-F
compiler.
FORTRAN H took about twice as long as FORTRAN G, and in addition
required 4 times as much memory as PL/I-F.
.
Link time for PL/I-F took slightly longer than FORTRAN G.
.
WATFOR and PL/C were both high-speed compilers & were
available for S/360 -- and much faster than the corresponding
IBM products.

Ahem A Rivet's Shot

unread,
Jul 3, 2021, 5:30:07 AM7/3/21
to
On Sat, 3 Jul 2021 01:19:39 -0000 (UTC)
John Levine <jo...@taugh.com> wrote:

> According to Ahem A Rivet's Shot <ste...@eircom.net>:
> >On Thu, 1 Jul 2021 05:12:05 -0000 (UTC)
> >Thomas Koenig <tko...@netcologne.de> wrote:
> >
> >> Seems far more readable than m4 (which is the serious programming
> >> language that I would consier most unreadable).
> >
> > XSLT and sendmail.cf are both less readable IMHO - XSLT control
> >flow is essentially come-from with wildcards.
>
> Um, sendmail.cf uses m4, which is why it's opaque.

Er no, there's an m4 generator for sendmail.cf these days to
*simplify* it,

gareth evans

unread,
Jul 3, 2021, 5:32:17 AM7/3/21
to
On 03/07/2021 00:28, Charlie Gibbs wrote:
>
> Not all of them were crackerjack programmers. And hell hath no fury
> like a director who sees what you've done to his precious spaghetti code.
>

Took a job once where the self-taught "software engineer" was leaving,
leaving a mixture of GOTO and structures but none of it indented and all
tucked in to the LHS margin.

Typically, over 90 procedures without comments per module.

When a bug surfaced, it could take several hours to unravel the code,
resulting in the complaint by the non-computer-competent MD that the
person who left could fix any fault within a few minutes, but you
can't be much good of it takes you more than a day.

My advice; if you have a self-taught boy wonder who wishes to move on,
then double or triple his salary to keep him, for that will be cheaper
for you in the long run!


Niklas Karlsson

unread,
Jul 3, 2021, 6:43:11 AM7/3/21
to
On 2021-07-03, Ahem A Rivet's Shot <ste...@eircom.net> wrote:
> On Sat, 3 Jul 2021 01:19:39 -0000 (UTC)
> John Levine <jo...@taugh.com> wrote:
>
>> According to Ahem A Rivet's Shot <ste...@eircom.net>:
>> >On Thu, 1 Jul 2021 05:12:05 -0000 (UTC)
>> >Thomas Koenig <tko...@netcologne.de> wrote:
>> >
>> >> Seems far more readable than m4 (which is the serious programming
>> >> language that I would consier most unreadable).
>> >
>> > XSLT and sendmail.cf are both less readable IMHO - XSLT control
>> >flow is essentially come-from with wildcards.
>>
>> Um, sendmail.cf uses m4, which is why it's opaque.
>
> Er no, there's an m4 generator for sendmail.cf these days to
> *simplify* it,

Right - sendmail.mc.

Niklas
--
For a time, I wrote data analysis code in C on VMS. I drank a lot of
tequila during that time.
-- Mark 'Kamikaze' Hughes in asr

Peter Flass

unread,
Jul 3, 2021, 9:40:37 PM7/3/21
to
Charlie Gibbs <cgi...@kltpzyxm.invalid> wrote:
> On 2021-07-02, Robin Vowels <robin....@gmail.com> wrote:
>
>> I do not have information on the resources required by IBM COBOL,
>> but PL/I-F ran in as little as 64K. I think that IBM PL/I-DOS
>> required a 32K machine.
>> DR PL/I ran in 64K byte PC.
>>
>> Compared to FORTRAN in 1966, PL/I ran rings around it.
>
> FSVO "ran rings". My only contact with PL/I was at university,
> where everything ran under MTS. Admittedly, we were more
> concerned with compile time rather than execution time, but
> when it came to compilations PL/I was a pig, eating up more
> CPU time and memory (and funny money in our student accounts)
> than any other language processor (although Assembler G came
> close).

I think FORTRAN G was the compiler that did everything via subroutine
calls. PL/I runtimes could be terrible if you used the wrong features.
Worse than COBOL with its DISPLAY/COMP-3 vs. binary. I’ve got to figure out
a way to make CONTROLLED storage more efficient.

Fortran G compiled like lightning. Forget about COBOL -
> to the CS weenies, uttering its name was an even worse profanity
> than GOTO. There wasn't even a COBOL compiler on the system.
> (If you were desperate, you could submit a compile request for
> overnight batch, where the operators would run it under OS/360
> emulation.) Needless to say, RPG did not exist. Period.
>
>>>> How popular is it today? The people who liked it at my site
>>>> have retired and its faded away.
>>>
>>> I think it’s mostly “legacy” today. There are at least three
>>> compilers for personal computers. I’d like to see it get more
>>> use, it’s a powerful language, even in comparison with more
>>> recent languages.
>
> Apparently the Insurance Corporation of British Columbia
> (set up by the incoming NDP government in the 1970s to take
> over all motor vehicle insurance from the private sector)
> had all their brand-new software written in PL/I on a
> "cost is no object" basis. Of course, being the provincial
> government, it was subject to the usual 100% overruns...
>



--
Pete

Peter Flass

unread,
Jul 3, 2021, 9:40:38 PM7/3/21
to
gareth evans <headst...@yahoo.com> wrote:
> On 03/07/2021 00:28, Charlie Gibbs wrote:
>>
>> Not all of them were crackerjack programmers. And hell hath no fury
>> like a director who sees what you've done to his precious spaghetti code.
>>
>
> Took a job once where the self-taught "software engineer" was leaving,
> leaving a mixture of GOTO and structures but none of it indented and all
> tucked in to the LHS margin.
>
> Typically, over 90 procedures without comments per module.
>
> When a bug surfaced, it could take several hours to unravel the code,
> resulting in the complaint by the non-computer-competent MD that the
> person who left could fix any fault within a few minutes, but you
> can't be much good of it takes you more than a day.

The first thing I’d do if I had to pick up code like that would be to
comment it, at least to mark the procedures, and indent it.

>
> My advice; if you have a self-taught boy wonder who wishes to move on,
> then double or triple his salary to keep him, for that will be cheaper
> for you in the long run!
>

We had a guy like that (still see his name in Linkedin occasionally). He
claimed to be an assembler programmer, but I think all he knew about it was
how to spell it. He worked for months on a fairly simple project, and when
he left we scrapped it and rewrote it in a couple of days.

>

--
Pete

gareth evans

unread,
Jul 4, 2021, 4:13:37 AM7/4/21
to
On 04/07/2021 02:40, Peter Flass wrote:
>
> He worked for months on a fairly simple project, and when
> he left we scrapped it and rewrote it in a couple of days.

Reminds me of one contract client where I ended up staying
for 4 years, off and on.

Person leaving had spent 6 weeks unsuccessfully trying to
implement a serial port driver on Windows using C. At the
interview I queried this and said that it was a matter of a few minutes
to achieve the same thing in Visual Basic, and I did that
at the interview!

Despite my background in electronics and computing, with a
strong interest in assembler and machine-orientation (qv :-) )
as opposed
to application-orientation, if a client had a project
involving disks, printer, serial port and keyboard, I'd
always recommend Visual Basic to them.

IMHO Microsoft went off the rails after VB6 by changing
VB to be .NET compliant so destroying the ease of use.

Anne & Lynn Wheeler

unread,
Jul 5, 2021, 7:39:24 PM7/5/21
to

Robin Vowels <robin....@gmail.com> writes:
> What??!! IBM's FORTRAN G compiled at about the same speed as their PL/I-F
> compiler.
> FORTRAN H took about twice as long as FORTRAN G, and in addition
> required 4 times as much memory as PL/I-F.
> .
> Link time for PL/I-F took slightly longer than FORTRAN G.
> .
> WATFOR and PL/C were both high-speed compilers & were
> available for S/360 -- and much faster than the corresponding
> IBM products.

I took two semester hr intro to fortran/computers, univ. ran 709
tape->tape with tapes moved between 709 and 1401 that ran as front-end
for unit record (card->tape, tape->printer/punch). Student fortran jobs
(30-60 cards) ran under second elapsed time.

Univ. was sold 360/67 originally for tss/360, but never quite came to
production fruition and so ran as 360/65 with os/360. within year of
taking intro class, I was hired fulltime responsible for the ibm
mainframe.

Initially student jobs ran well over a minute three step fortran G,
compile, link-edit, go/execute. I then installed HASP which cut elapsed
time about in half (nearly all job step overhead and file
open/close). First os/360 sysgen I did was release 9.5. I then started
tearing apart stage2 sysgen and reorganizing the cards to optimize
placement of files and PDS members for arm seek and PDS directory
multi-track search which improved student jobs by nearly another 2/3rds
... 12.9sec elapsed ... approx. 4.3sec/job-step.

It wasn't until installed single step, batch WATFOR monitor that student
jobs ran faster than 709. WATFOR ran approx. 20,000 card(statements) per
min (333/sec) on 360/65. Typically a card tray (2000+ cards, 30-60
student jobs) would be batched in single step ... 4.3sec/single-step +
2000/333 secs ... 10.3sec elapsed for batching 30-60 student jobs
... around .2secs/job. WATFOR would have still been slower than 709
(i.e. 4.5sec/job) if it wasn't for batching multiple jobs per
single-step execution (and w/o my careful sysgen and hasp, it would be
more like 20secs if ran single student job per invokation).

One of the guys up at IBM palo alto science center (that had done much
of the work for the 370/145 APL microcode assist ... got APL throughput
up close to 370/168) ... did a lot of optimization work on Fortran H
that originally was available inside IBM as Fortran Q ... and eventually
released to customers as Fortran HX.

--
virtualization experience starting Jan1968, online at home since Mar1970

undefined Hancock-4

unread,
Jul 7, 2021, 3:46:09 PM7/7/21
to
On Saturday, July 3, 2021 at 9:40:38 PM UTC-4, Peter Flass wrote:

> > When a bug surfaced, it could take several hours to unravel the code,
> > resulting in the complaint by the non-computer-competent MD that the
> > person who left could fix any fault within a few minutes, but you
> > can't be much good of it takes you more than a day.

> The first thing I’d do if I had to pick up code like that would be to
> comment it, at least to mark the procedures, and indent it.

Yes, that was typical procedure when faced with spaghetti.
Of course, if it was 6,000 lines of mush, it took a while and
wasn't easy, but all the more reason.

By the way, 'structured programming' was touted as the way to eliminate
the mess of too many crazy GO TOs. But structured programming could
be poorly written too, with all sorts of excessive crazy calls to subroutines.
Too many layers or overlays is just as bad as GO TOs.

Back in the 1960s and 1970s there was a shortage of programmers.
Management, desperate to automate some function, made use of
unskilled or untalented people, leaving a mess for others to untangle.
Undecipherable field names was another problem. What does K3X mean?
K5X? K4Z?




gareth evans

unread,
Jul 7, 2021, 4:19:32 PM7/7/21
to
I think that is symptomatic of someone who might have a year's
experience, but consisting of only one week's real experience
then repeated a further 51 times.



J. Clarke

unread,
Jul 7, 2021, 5:06:19 PM7/7/21
to
And management, not understanding the importance of such things,
insists that "outdated" docs be archived never to be seen again or
tossed, so you have to back into the damned things.

Charlie Gibbs

unread,
Jul 8, 2021, 1:16:54 AM7/8/21
to
On 2021-07-07, undefined Hancock-4 <hanc...@bbs.cpcn.com> wrote:

> On Saturday, July 3, 2021 at 9:40:38 PM UTC-4, Peter Flass wrote:
>
>>> When a bug surfaced, it could take several hours to unravel the code,
>>> resulting in the complaint by the non-computer-competent MD that the
>>> person who left could fix any fault within a few minutes, but you
>>> can't be much good of it takes you more than a day.
>>
>> The first thing I’d do if I had to pick up code like that would be to
>> comment it, at least to mark the procedures, and indent it.
>
> Yes, that was typical procedure when faced with spaghetti.
> Of course, if it was 6,000 lines of mush, it took a while and
> wasn't easy, but all the more reason.

Make that 4,000 lines of mush; once I started to make sense of
what the code was doing, I'd typically throw out 30% of it.
(In extreme cases, 50%.)

> By the way, 'structured programming' was touted as the way to
> eliminate the mess of too many crazy GO TOs. But structured
> programming could be poorly written too, with all sorts of
> excessive crazy calls to subroutines. Too many layers or
> overlays is just as bad as GO TOs.

This is something the zealots never realized. They seemed to take
the number of subroutine calls as some sort of figure of merit.
Since a subroutine call is just a GOTO paired with a "come from",
a maze of calls to tiny (sometimes one-line!) subroutines is still
spaghetti code; you're just running double strands.

As I would point out, the undisciplined use of subroutine calls
is nearly as bad as the undisciplined use of GOTOs.

I heard of virtual memory systems thrashing themselves to death
because of the complete lack of locality of code - especially if
overlays were involved.

> Back in the 1960s and 1970s there was a shortage of programmers.
> Management, desperate to automate some function, made use of
> unskilled or untalented people, leaving a mess for others to untangle.
> Undecipherable field names was another problem. What does K3X mean?
> K5X? K4Z?

To be completely fair, it can be a bit hard when you're working with
an assembler that only supports 4-character labels. In my first job
I discovered that it was a bit of a standard to use labels like A100,
A110, etc. (The convention was to keep the labels in sequence.)
I quickly outgrew that - it was easy enough to come up with something
a bit more mnemonic. The breaking point, though, was when I had to
move a large block of code, which would have required renumbering
all those labels. I decided enough was enough.

Years later I came across COBOL programs (and textbooks) which
advocated putting such prefixes in front of labels - a practice
which I steadfastly avoided.

Quadibloc

unread,
Jul 8, 2021, 5:51:50 PM7/8/21
to
On Friday, July 2, 2021 at 5:29:34 PM UTC-6, Charlie Gibbs wrote:
> Forget about COBOL -
> to the CS weenies, uttering its name was an even worse profanity
> than GOTO. There wasn't even a COBOL compiler on the system.
> (If you were desperate, you could submit a compile request for
> overnight batch, where the operators would run it under OS/360
> emulation.) Needless to say, RPG did not exist. Period.

Although it's unfortunate that the PL/I compiler was not efficient,
you have just given here the best argument for PL/I's existence.

PL/I was a lot easier to learn for programmers used to FORTRAN
than COBOL was, yet it could also do the things that COBOL and
RPG could do, but FORTRAN could not.

So if IBM had only implemented a decent PL/I compiler, that
language could have fulfilled the plans IBM had for it.

John Savard

Peter Flass

unread,
Jul 8, 2021, 6:01:12 PM7/8/21
to
My first FORTRAN stuff in college was like that. They were all (actual)
one-shots: spend a week writing, run once or twice to get output, and then
toss it, so the names didn’t matter. My first programming job everyone
emphasized using long(ish) meaningful variable names.

Of course FORTRAN used, what, six-character names, so it was hard to be too
meaningful.

--
Pete

Peter Flass

unread,
Jul 8, 2021, 6:01:13 PM7/8/21
to
Ah yes, the dreaded 010-READ-INPUT-FILE paragraphs and suchlike.

--
Pete

Peter Flass

unread,
Jul 8, 2021, 6:06:08 PM7/8/21
to
They apparently still haven’t, although hardware has now grown powerful
enough that no one notices.

Here I am struggling to get the Iron Spring compiler to generate reasonably
efficient code. I wanted to look at IBM’s compiler to see how they handled
this particular situation. I looked at their generated “assembler” and just
about choked on my morning coffee.

--
Pete

Dan Espen

unread,
Jul 8, 2021, 7:39:38 PM7/8/21
to
Great stuff.

I once decided to fix a large C program by changing all the little
function names into the "a100_initialize" pattern. Then, of course,
rearranging the functions into called order.

I expected the owning C programmer to object but he was happy with
the change. He couldn't navigate the code either.

--
Dan Espen

Quadibloc

unread,
Jul 8, 2021, 8:19:48 PM7/8/21
to
On Thursday, July 8, 2021 at 4:06:08 PM UTC-6, Peter Flass wrote:

> Here I am struggling to get the Iron Spring compiler to generate reasonably
> efficient code. I wanted to look at IBM’s compiler to see how they handled
> this particular situation. I looked at their generated “assembler” and just
> about choked on my morning coffee.

In any case, thank you for providing this valuable tool for Linux and OS/2
users.

John Savard

Robin Vowels

unread,
Jul 10, 2021, 10:33:00 AM7/10/21
to
On Friday, July 9, 2021 at 7:51:50 AM UTC+10, Quadibloc wrote:
> On Friday, July 2, 2021 at 5:29:34 PM UTC-6, Charlie Gibbs wrote:
> > Forget about COBOL -
> > to the CS weenies, uttering its name was an even worse profanity
> > than GOTO. There wasn't even a COBOL compiler on the system.
> > (If you were desperate, you could submit a compile request for
> > overnight batch, where the operators would run it under OS/360
> > emulation.) Needless to say, RPG did not exist. Period.
.
> Although it's unfortunate that the PL/I compiler was not efficient,
.
Some have claimed this, and have compared run times for various
languages including FORTRAN and PL/I. A. B. Tucker ("Programming
Languages") is one.
Unfortunately, he omitted to provide the REORDER keyword
for the PROCEDURE statement in the case of IBM's PL/I compiler.
The PL/I programs ran slower than they should have.
.
I investigated claims by D. J. Kewley, who compared run times of FORTRAN,
Pascal, and PL/I programs. The PL/I version did not use COMPLEX data types,
whereas the FORTRAN version did. Modifying the PL/I version program to use
COMPLEX and REORDER gave a 47% increase in execution speed.
.
P. J. Jaliks compared COBOL and PL/I. His PL/I version ran slower by
2-3 times of because of inappropriate variable declarations and
failure to disable fixed-point interrupts.
.

Robin Vowels

unread,
Jul 10, 2021, 10:41:16 AM7/10/21
to
R. H. Prins criticized IBM's Enterprise PL/I compiler for
optimising poorly. He subsequently retracted that criticism when
he discovered that he had been compiling the program with OPT(0) --
that is, with no optimisation !

Dan Espen

unread,
Jul 10, 2021, 1:30:26 PM7/10/21