Re: [TUHS] Book Recommendation

Re: [TUHS] Book Recommendation

[Douglas McIlroy]

The following remark stirred old memories. Apologies for straying off
the path of TUHS.

> I have gotten the impression that [PL/I] was a language that was beloved by no one.

As I was a designer of PL/I, an implementer of EPL (the preliminary
PL/I compiler used to build Multics), and author of the first PL/I
program to appear in the ACM Collected Algorithms, it's a bit hard to
admit that PL/I was "insignificant". I'm proud, though, of having
conceived the SIGNAL statement, which pioneered exception handling,
and the USES and SETS attributes, which unfortunately sank into
oblivion. I also spurred Bud Lawson to invent -> for pointer-chasing.
The former notation C(B(A)) became A->B->C. This was PL/I's gift to C.

After the ACM program I never wrote another line of PL/I.
Gratification finally came forty years on when I met a retired
programmer who, unaware of my PL/I connection, volunteered that she
had loved PL/I above all other programming languages.

Doug

Re: [TUHS] Book Recommendation

[Richard Salz]

[-- Attachment #1: Type: text/plain, Size: 159 bytes --]

> The former notation C(B(A)) became A->B->C. This was PL/I's gift to C.
>

You seem to have a gift for notation. That's rare.  Curious what you think
of APL?

[-- Attachment #2: Type: text/html, Size: 396 bytes --]

Re: [TUHS] Book Recommendation

[Ron Natalie]

PL/I was my introduction to structured programming (though it took a 
somewhat loose approach to that).   I always
Over my early years I spent time on a couple of implementations and 
always had been amused by its somewhat COBOLish IO scheme
and spent a little time dabbling in variants such as the IBM PL/S, 
UNIVAC PLUS, and the UofM interpretted PLUM.

Then I got introduced to C and it was all downhill from there :)


------ Original Message ------
From: "Douglas McIlroy" <douglas.mcilroy@dartmouth.edu>
To: "TUHS main list" <tuhs@minnie.tuhs.org>
Sent: 11/16/2021 9:57:55 AM
Subject: Re: [TUHS] Book Recommendation

>The following remark stirred old memories. Apologies for straying off
>the path of TUHS.
>
>>  I have gotten the impression that [PL/I] was a language that was beloved by no one.
>
>As I was a designer of PL/I, an implementer of EPL (the preliminary
>PL/I compiler used to build Multics), and author of the first PL/I
>program to appear in the ACM Collected Algorithms, it's a bit hard to
>admit that PL/I was "insignificant". I'm proud, though, of having
>conceived the SIGNAL statement, which pioneered exception handling,
>and the USES and SETS attributes, which unfortunately sank into
>oblivion. I also spurred Bud Lawson to invent -> for pointer-chasing.
>The former notation C(B(A)) became A->B->C. This was PL/I's gift to C.
>
>After the ACM program I never wrote another line of PL/I.
>Gratification finally came forty years on when I met a retired
>programmer who, unaware of my PL/I connection, volunteered that she
>had loved PL/I above all other programming languages.
>
>Doug

Re: [TUHS] Book Recommendation

[Mary Ann Horton]

PL/I was my favorite mainframe programming language my last two years as 
an undergrad. I liked how it incorporated ideas from FORTRAN, ALGOL, and 
COBOL. My student job was to enhance a PL/I package for a History professor.

As a grad student in 1976, my first job as a TA was to teach PL/I to 
undergrads. There were a lot of business students in the class. We 
thought PL/I was likely to be the future of business programming, as a 
better alternative to COBOL.

I was turned on to V6 UNIX and C in 1977, and I forgot all about PL/I.

     Mary Ann

On 11/16/2021 6:57 AM, Douglas McIlroy wrote:
> The following remark stirred old memories. Apologies for straying off
> the path of TUHS.
>
>> I have gotten the impression that [PL/I] was a language that was beloved by no one.
> As I was a designer of PL/I, an implementer of EPL (the preliminary
> PL/I compiler used to build Multics), and author of the first PL/I
> program to appear in the ACM Collected Algorithms, it's a bit hard to
> admit that PL/I was "insignificant". I'm proud, though, of having
> conceived the SIGNAL statement, which pioneered exception handling,
> and the USES and SETS attributes, which unfortunately sank into
> oblivion. I also spurred Bud Lawson to invent -> for pointer-chasing.
> The former notation C(B(A)) became A->B->C. This was PL/I's gift to C.
>
> After the ACM program I never wrote another line of PL/I.
> Gratification finally came forty years on when I met a retired
> programmer who, unaware of my PL/I connection, volunteered that she
> had loved PL/I above all other programming languages.
>
> Doug

Re: [TUHS] Book Recommendation

[Henry Bent]

[-- Attachment #1: Type: text/plain, Size: 541 bytes --]

On Mon, 22 Nov 2021 at 21:31, Mary Ann Horton <mah@mhorton.net> wrote:

> PL/I was my favorite mainframe programming language my last two years as
> an undergrad. I liked how it incorporated ideas from FORTRAN, ALGOL, and
> COBOL. My student job was to enhance a PL/I package for a History
> professor.
>

What language were the PL/I compilers written in?

Wikipedia claims that IBM is still developing a PL/I compiler, which I
suppose I have no reason to disbelieve, but I'm very curious as to who is
using it and for what purpose.

-Henry

[-- Attachment #2: Type: text/html, Size: 884 bytes --]

Re: [TUHS] Book Recommendation

[arnold]

Henry Bent <henry.r.bent@gmail.com> wrote:

> On Mon, 22 Nov 2021 at 21:31, Mary Ann Horton <mah@mhorton.net> wrote:
>
> > PL/I was my favorite mainframe programming language my last two years as
> > an undergrad. I liked how it incorporated ideas from FORTRAN, ALGOL, and
> > COBOL. My student job was to enhance a PL/I package for a History
> > professor.
> >
>
> What language were the PL/I compilers written in?
>
> Wikipedia claims that IBM is still developing a PL/I compiler, which I
> suppose I have no reason to disbelieve, but I'm very curious as to who is
> using it and for what purpose.
>
> -Henry

PL/1 compiler for Linux: http://www.iron-spring.com/

PL/1 front end for GCC (looks dead): pl1gcc.sourceforge.net

:-)

Arnold

Re: [TUHS] Book Recommendation

[Henry Bent]

[-- Attachment #1: Type: text/plain, Size: 1656 bytes --]

On Tue, 23 Nov 2021 at 03:10, <arnold@skeeve.com> wrote:

> Henry Bent <henry.r.bent@gmail.com> wrote:
>
> > On Mon, 22 Nov 2021 at 21:31, Mary Ann Horton <mah@mhorton.net> wrote:
> >
> > > PL/I was my favorite mainframe programming language my last two years
> as
> > > an undergrad. I liked how it incorporated ideas from FORTRAN, ALGOL,
> and
> > > COBOL. My student job was to enhance a PL/I package for a History
> > > professor.
> > >
> >
> > What language were the PL/I compilers written in?
> >
> > Wikipedia claims that IBM is still developing a PL/I compiler, which I
> > suppose I have no reason to disbelieve, but I'm very curious as to who is
> > using it and for what purpose.
> >
> > -Henry
>
> PL/1 compiler for Linux: http://www.iron-spring.com/
>
> PL/1 front end for GCC (looks dead): pl1gcc.sourceforge.net


"Expect some more releases soon" and the last release was 0.0.whatever, in
2007.  I think that speaks volumes as to how popular PL/I is today.  That
being said, the Linux compiler does appear to be actively developed, and I
suppose I shouldn't be surprised that the two platforms for active
development are Linux and OS/2 (!).

I have a vague recollection of installing and playing with a PL/I compiler
demo for Ultrix, but I figured that the language was essentially dead at
that point.  I suppose I shouldn't be too surprised that there are still
people using it, as this is the world of "we wrote the specifications in
1975 and there's no reason to update them," but I have a hard time
imagining those companies being truly competitive, and an even harder time
imagining them attracting talent under retirement age.

-Henry

[-- Attachment #2: Type: text/html, Size: 2417 bytes --]

Re: [TUHS] Book Recommendation

[Adam Thornton]

[-- Attachment #1: Type: text/plain, Size: 450 bytes --]

On Tue, Nov 23, 2021 at 1:00 AM Henry Bent <henry.r.bent@gmail.com> wrote:
What language were the PL/I compilers written in?

Wikipedia claims that IBM is still developing a PL/I compiler, which I
suppose I have no reason to disbelieve, but I'm very curious as to who is
using it and for what purpose.



I have a vague recollection that PL/X was a PL/I variant used for internal
development on VM/CMS.  Does that ring any bells for anyone?

Adam

>

[-- Attachment #2: Type: text/html, Size: 905 bytes --]

Re: [TUHS] Book Recommendation

[Ron Natalie]

[-- Attachment #1: Type: text/plain, Size: 579 bytes --]



> On Nov 23, 2021, at 12:31, Adam Thornton <athornton@gmail.com> wrote:
> 
> 
> 
>> On Tue, Nov 23, 2021 at 1:00 AM Henry Bent <henry.r.bent@gmail.com> wrote:
>> What language were the PL/I compilers written in?
>> 
>> Wikipedia claims that IBM is still developing a PL/I compiler, which I suppose I have no reason to disbelieve, but I'm very curious as to who is using it and for what purpose.
>> 
>> 
>> 
>> I have a vague recollection that PL/X was a PL/I variant used for internal development on VM/CMS.  Does that ring any bells for anyone?
>> 
>> Adam

[-- Attachment #2: Type: text/html, Size: 1253 bytes --]

Re: [TUHS] Book Recommendation

[Al Kossow]

On 11/23/21 10:54 AM, Ron Natalie wrote:

>> I have a vague recollection that PL/X was a PL/I variant used for internal development on VM/CMS.

PL/S

Re: [TUHS] Book Recommendation

[Ron Natalie]

[-- Attachment #1: Type: text/plain, Size: 582 bytes --]

Tpl

> On Nov 23, 2021, at 12:31, Adam Thornton <athornton@gmail.com> wrote:
> 
> 
> 
>> On Tue, Nov 23, 2021 at 1:00 AM Henry Bent <henry.r.bent@gmail.com> wrote:
>> What language were the PL/I compilers written in?
>> 
>> Wikipedia claims that IBM is still developing a PL/I compiler, which I suppose I have no reason to disbelieve, but I'm very curious as to who is using it and for what purpose.
>> 
>> 
>> 
>> I have a vague recollection that PL/X was a PL/I variant used for internal development on VM/CMS.  Does that ring any bells for anyone?
>> 
>> Adam

[-- Attachment #2: Type: text/html, Size: 1252 bytes --]

Re: [TUHS] Book Recommendation

[Lawrence Stewart]

> On 2021, Nov 23, at 2:04 PM, Al Kossow <aek@bitsavers.org> wrote:
> 
> On 11/23/21 10:54 AM, Ron Natalie wrote:
> 
>>> I have a vague recollection that PL/X was a PL/I variant used for internal development on VM/CMS.
> 
> PL/S

PL/S also led to PL.8 which was used for the first IBM Risc

Re: [TUHS] Book Recommendation

[Thomas Paulsen]

Hi,

I remember that PL-1 was regarded in the 70-80ths as a superior programming language, incorporating the best concepts of the languages Mary enumerated. There even was a PL-1 inspired SPL language by siemens for the bs2000 mainframe os including bit fields etc. for system programming like C. Large parts of the start-amadeus ticketing-software were written in SPL. Thus PL-1 and its derivates were very high-ranked in the 70ths and 80ths, regarded as the ultimate ratio of the programming languages by many mainframe experts in those days.
I mean we are now entering the mainframe horizon, totally different to our UNIX and C mini computer, workstation and PC world we all are firm with.

---------------------------------------------------------------------------------------------
PL/I was my favorite mainframe programming language my last two years as

an undergrad. I liked how it incorporated ideas from FORTRAN, ALGOL, and

COBOL. My student job was to enhance a PL/I package for a History professor.


As a grad student in 1976, my first job as a TA was to teach PL/I to 
undergrads. There were a lot of business students in the class. We 
thought PL/I was likely to be the future of business programming, as a 
better alternative to COBOL.

I was turned on to V6 UNIX and C in 1977, and I forgot all about PL/I.

     Mary Ann

On 11/16/2021 6:57 AM, Douglas McIlroy wrote:
> The following remark stirred old memories. Apologies for straying off

> the path of TUHS.
>
>> I have gotten the impression that [PL/I] was a language that was
beloved by no one.
> As I was a designer of PL/I, an implementer of EPL (the preliminary

> PL/I compiler used to build Multics), and author of the first PL/I
> program to appear in the ACM Collected Algorithms, it's a bit hard
to
> admit that PL/I was "insignificant". I'm proud, though, of
having
> conceived the SIGNAL statement, which pioneered exception handling,

> and the USES and SETS attributes, which unfortunately sank into
> oblivion. I also spurred Bud Lawson to invent -> for pointer-chasing.

> The former notation C(B(A)) became A->B->C. This was PL/I's gift
to C.
>
> After the ACM program I never wrote another line of PL/I.
> Gratification finally came forty years on when I met a retired
> programmer who, unaware of my PL/I connection, volunteered that she

> had loved PL/I above all other programming languages.
>
> Doug

Re: [TUHS] Book Recommendation

[Richard Salz]

[-- Attachment #1: Type: text/plain, Size: 491 bytes --]

I asked my pal Barry Shein, who many of you know, if he had his PL/1 syntax
horror lying around, and he did.  He said: "this was tested on the Iron
Spring Software PL/1 compiler running on openSuSe Linux (
http://www.iron-spring.com/)"

IBM still uses PL/1.  Remember, the main definition of "legacy" is
"revenue-producing."

TRY:PROC OPTIONS(MAIN);
   DCL (IF,THEN,ELSE) FIXED BINARY (31);

   IF = 1;
   THEN = 2;
   ELSE = 3;

   IF IF = THEN THEN THEN = IF ; ELSE ELSE = THEN;

END TRY;

[-- Attachment #2: Type: text/html, Size: 748 bytes --]

Re: [TUHS] Book Recommendation

[Larry McVoy]

Say hi to Barry for me, I knew him back in the UUCP days, he was always
pleasant.

That bit of PL/1 is nuts but funny.

On Wed, Nov 24, 2021 at 10:18:56AM -0500, Richard Salz wrote:
> I asked my pal Barry Shein, who many of you know, if he had his PL/1 syntax
> horror lying around, and he did.  He said: "this was tested on the Iron
> Spring Software PL/1 compiler running on openSuSe Linux (
> http://www.iron-spring.com/)"
> 
> IBM still uses PL/1.  Remember, the main definition of "legacy" is
> "revenue-producing."
> 
> TRY:PROC OPTIONS(MAIN);
>    DCL (IF,THEN,ELSE) FIXED BINARY (31);
> 
>    IF = 1;
>    THEN = 2;
>    ELSE = 3;
> 
>    IF IF = THEN THEN THEN = IF ; ELSE ELSE = THEN;
> 
> END TRY;

-- 
---
Larry McVoy            	     lm at mcvoy.com             http://www.mcvoy.com/lm 

Re: [TUHS] Book Recommendation

[Rich Morin]

Speaking of Barry and IBM, I've always loved his snark on AIX:  "It will remind you of Unix."

-r

P.S.  My guess is that this code sets ELSE to 2.  True? 

> On Nov 24, 2021, at 07:18, Richard Salz <rich.salz@gmail.com> wrote:
> 
> I asked my pal Barry Shein, who many of you know, if he had his PL/1 syntax horror lying around, and he did.  He said: "this was tested on the Iron Spring Software PL/1 compiler running on openSuSe Linux (http://www.iron-spring.com/)"
> 
> IBM still uses PL/1.  Remember, the main definition of "legacy" is "revenue-producing."
> 
> TRY:PROC OPTIONS(MAIN);
>    DCL (IF,THEN,ELSE) FIXED BINARY (31);
> 
>    IF = 1;
>    THEN = 2;
>    ELSE = 3;
> 
>    IF IF = THEN THEN THEN = IF ; ELSE ELSE = THEN;
> 
> END TRY;

Re: [TUHS] Book Recommendation

[Larry McVoy]

On Wed, Nov 24, 2021 at 10:34:08AM -0800, Rich Morin wrote:
> Speaking of Barry and IBM, I've always loved his snark on AIX:  "It will remind you of Unix."

Barely.  I think after SCO, AIX is the Unix I loved the least.

SMIT - just say no.

Re: [TUHS] Book Recommendation

[Clem Cole]

[-- Attachment #1: Type: text/plain, Size: 1665 bytes --]

On Wed, Nov 24, 2021 at 1:43 PM Larry McVoy <lm@mcvoy.com> wrote:

> SMIT - just say no.

There were a number of things IBM did well with AIX so I'm not quite so
glib knocking everything from them.

But I agree that SMIT was the not so well thought out piece and never fully
understood why it ended up being such a bad example of systems SW. ... but
 .... I always suspected that SMIT was an example of what IT managers
running mainframe thought of UNIX.  The folks at IBM set out (and did) a
thorough and well thought out requirements study IBM style ... and then ...
they only talked to Mainframe IT folks, not people that actually had
experience in running UNIX in a production setting from their (like on a
BSD or Ultrix based Vax or SunOS - i.e. instead of talking to the folks
that came to a USENIX LISA, they talked to customers that came to a SHARE
meeting).  So they solved the wrong set of problems.  SMIT was a force fit
of UNIX to mainframe shop and never was quite right for either group.  I'm
not sure the IT folks really liked it much better than the UNIX folks, but
at least for them it used their terminology and their concepts (*e.g.* DASD
*vs.* DISK).

BTW:  HP, I thought had a similar issue and they did not really understand
the UNIX user.   DEC parts of so got it/parts did not.  Many DECies wanted
Ultrix == VMS (and really wanted Unix to go away since VMS and RXS were
really better in their hearts), but at least there were a ton of folks
inside of DEC doing the Unix work that 'got it.'

As I have said before, it was always interesting having all of them as
customers at LCC.  You got to see the good and bad of all the systems
vendors.

[-- Attachment #2: Type: text/html, Size: 3022 bytes --]

Re: [TUHS] Book Recommendation

[Larry McVoy]

HP was much better than AIX, you could ignore their admin crud and
just edit the /etc files and stuff worked.  With AIX, I never figured
out how to not use SMIT, it was pretty intertwined with everything.
It was super annoying, I'm not saying it didn't work, it did, but it was
very clunky and you couldn't just go edit /etc/fstab and make stuff work
(well, I couldn't, maybe there is someone who could).  I hated it.

On Wed, Nov 24, 2021 at 02:39:19PM -0500, Clem Cole wrote:
> On Wed, Nov 24, 2021 at 1:43 PM Larry McVoy <lm@mcvoy.com> wrote:
> 
> > SMIT - just say no.
> 
> There were a number of things IBM did well with AIX so I'm not quite so
> glib knocking everything from them.
> 
> But I agree that SMIT was the not so well thought out piece and never fully
> understood why it ended up being such a bad example of systems SW. ... but
>  .... I always suspected that SMIT was an example of what IT managers
> running mainframe thought of UNIX.  The folks at IBM set out (and did) a
> thorough and well thought out requirements study IBM style ... and then ...
> they only talked to Mainframe IT folks, not people that actually had
> experience in running UNIX in a production setting from their (like on a
> BSD or Ultrix based Vax or SunOS - i.e. instead of talking to the folks
> that came to a USENIX LISA, they talked to customers that came to a SHARE
> meeting).  So they solved the wrong set of problems.  SMIT was a force fit
> of UNIX to mainframe shop and never was quite right for either group.  I'm
> not sure the IT folks really liked it much better than the UNIX folks, but
> at least for them it used their terminology and their concepts (*e.g.* DASD
> *vs.* DISK).
> 
> BTW:  HP, I thought had a similar issue and they did not really understand
> the UNIX user.   DEC parts of so got it/parts did not.  Many DECies wanted
> Ultrix == VMS (and really wanted Unix to go away since VMS and RXS were
> really better in their hearts), but at least there were a ton of folks
> inside of DEC doing the Unix work that 'got it.'
> 
> As I have said before, it was always interesting having all of them as
> customers at LCC.  You got to see the good and bad of all the systems
> vendors.

-- 
---
Larry McVoy            	     lm at mcvoy.com             http://www.mcvoy.com/lm 

Re: [TUHS] Book Recommendation

[arnold]

Richard Salz <rich.salz@gmail.com> wrote:

> I asked my pal Barry Shein, who many of you know, if he had his PL/1 syntax
> horror lying around, and he did.  He said: "this was tested on the Iron
> Spring Software PL/1 compiler running on openSuSe Linux (
> http://www.iron-spring.com/)"
>
> IBM still uses PL/1.  Remember, the main definition of "legacy" is
> "revenue-producing."
>
> TRY:PROC OPTIONS(MAIN);
>    DCL (IF,THEN,ELSE) FIXED BINARY (31);
>
>    IF = 1;
>    THEN = 2;
>    ELSE = 3;
>
>    IF IF = THEN THEN THEN = IF ; ELSE ELSE = THEN;
>
> END TRY;

Re: [TUHS] Book Recommendation

[Rob Pike]

I thought it was

TRY:PROC OPTIONS(MAIN);
   DCL (IF,THEN,ELSE) FIXED BINARY (31);

   IF = 1;
   THEN = 2;
   ELSE = 3;

   IF IF = THEN THEN THEN = IF ; ELSE ELSE IF = THEN = ELSE;

END TRY;

But yeah.

Best to Barry.

-rob

On Thu, Nov 25, 2021 at 2:23 AM Richard Salz <rich.salz@gmail.com> wrote:
>
> I asked my pal Barry Shein, who many of you know, if he had his PL/1 syntax horror lying around, and he did.  He said: "this was tested on the Iron Spring Software PL/1 compiler running on openSuSe Linux (http://www.iron-spring.com/)"
>
> IBM still uses PL/1.  Remember, the main definition of "legacy" is "revenue-producing."
>
> TRY:PROC OPTIONS(MAIN);
>    DCL (IF,THEN,ELSE) FIXED BINARY (31);
>
>    IF = 1;
>    THEN = 2;
>    ELSE = 3;
>
>    IF IF = THEN THEN THEN = IF ; ELSE ELSE = THEN;
>
> END TRY;
>

Re: [TUHS] Book Recommendation

[Will Senn]

Since we're all recommending books, I'd like to recommend:

Richard Fitzpatrick's translation of J. L. Heiberg's Euclid's Elements 
of Geometry. It's fantastic, and without Euclid, we'd prolly not have 
unix...

Will

On 11/24/21 2:13 PM, arnold@skeeve.com wrote:
> Richard Salz <rich.salz@gmail.com> wrote:
>
>> I asked my pal Barry Shein, who many of you know, if he had his PL/1 syntax
>> horror lying around, and he did.  He said: "this was tested on the Iron
>> Spring Software PL/1 compiler running on openSuSe Linux (
>> http://www.iron-spring.com/)"
>>
>> IBM still uses PL/1.  Remember, the main definition of "legacy" is
>> "revenue-producing."
>>
>> TRY:PROC OPTIONS(MAIN);
>>     DCL (IF,THEN,ELSE) FIXED BINARY (31);
>>
>>     IF = 1;
>>     THEN = 2;
>>     ELSE = 3;
>>
>>     IF IF = THEN THEN THEN = IF ; ELSE ELSE = THEN;
>>
>> END TRY;

Re: [TUHS] Book Recommendation

[joe mcguckin]

[-- Attachment #1: Type: text/plain, Size: 1205 bytes --]

In PL/I, language keywords are not reserved. Makes for interesting work when writing the lex scanner.


Joe McGuckin
ViaNet Communications

joe@via.net
650-207-0372 cell
650-213-1302 office
650-969-2124 fax



> On Nov 24, 2021, at 12:15 PM, Rob Pike <robpike@gmail.com> wrote:
> 
> I thought it was
> 
> TRY:PROC OPTIONS(MAIN);
>   DCL (IF,THEN,ELSE) FIXED BINARY (31);
> 
>   IF = 1;
>   THEN = 2;
>   ELSE = 3;
> 
>   IF IF = THEN THEN THEN = IF ; ELSE ELSE IF = THEN = ELSE;
> 
> END TRY;
> 
> But yeah.
> 
> Best to Barry.
> 
> -rob
> 
> On Thu, Nov 25, 2021 at 2:23 AM Richard Salz <rich.salz@gmail.com> wrote:
>> 
>> I asked my pal Barry Shein, who many of you know, if he had his PL/1 syntax horror lying around, and he did.  He said: "this was tested on the Iron Spring Software PL/1 compiler running on openSuSe Linux (http://www.iron-spring.com/)"
>> 
>> IBM still uses PL/1.  Remember, the main definition of "legacy" is "revenue-producing."
>> 
>> TRY:PROC OPTIONS(MAIN);
>>   DCL (IF,THEN,ELSE) FIXED BINARY (31);
>> 
>>   IF = 1;
>>   THEN = 2;
>>   ELSE = 3;
>> 
>>   IF IF = THEN THEN THEN = IF ; ELSE ELSE = THEN;
>> 
>> END TRY;
>> 


[-- Attachment #2: Type: text/html, Size: 3578 bytes --]

Re: [TUHS] Book Recommendation

[Rob Pike]

Also isn't it PROCEDURE? I don't remember PROC.

-rob

On Thu, Nov 25, 2021 at 7:15 AM Rob Pike <robpike@gmail.com> wrote:
>
> I thought it was
>
> TRY:PROC OPTIONS(MAIN);
>    DCL (IF,THEN,ELSE) FIXED BINARY (31);
>
>    IF = 1;
>    THEN = 2;
>    ELSE = 3;
>
>    IF IF = THEN THEN THEN = IF ; ELSE ELSE IF = THEN = ELSE;
>
> END TRY;
>
> But yeah.
>
> Best to Barry.
>
> -rob
>
> On Thu, Nov 25, 2021 at 2:23 AM Richard Salz <rich.salz@gmail.com> wrote:
> >
> > I asked my pal Barry Shein, who many of you know, if he had his PL/1 syntax horror lying around, and he did.  He said: "this was tested on the Iron Spring Software PL/1 compiler running on openSuSe Linux (http://www.iron-spring.com/)"
> >
> > IBM still uses PL/1.  Remember, the main definition of "legacy" is "revenue-producing."
> >
> > TRY:PROC OPTIONS(MAIN);
> >    DCL (IF,THEN,ELSE) FIXED BINARY (31);
> >
> >    IF = 1;
> >    THEN = 2;
> >    ELSE = 3;
> >
> >    IF IF = THEN THEN THEN = IF ; ELSE ELSE = THEN;
> >
> > END TRY;
> >

Re: [TUHS] Book Recommendation

[Richard Salz]

[-- Attachment #1: Type: text/plain, Size: 1274 bytes --]

Yeah PROCEDURE is the official word, but if you're gonna low DCL heresy,
might as well throw in PROC.

On Wed, Nov 24, 2021 at 3:28 PM Rob Pike <robpike@gmail.com> wrote:

> Also isn't it PROCEDURE? I don't remember PROC.
>
> -rob
>
> On Thu, Nov 25, 2021 at 7:15 AM Rob Pike <robpike@gmail.com> wrote:
> >
> > I thought it was
> >
> > TRY:PROC OPTIONS(MAIN);
> >    DCL (IF,THEN,ELSE) FIXED BINARY (31);
> >
> >    IF = 1;
> >    THEN = 2;
> >    ELSE = 3;
> >
> >    IF IF = THEN THEN THEN = IF ; ELSE ELSE IF = THEN = ELSE;
> >
> > END TRY;
> >
> > But yeah.
> >
> > Best to Barry.
> >
> > -rob
> >
> > On Thu, Nov 25, 2021 at 2:23 AM Richard Salz <rich.salz@gmail.com>
> wrote:
> > >
> > > I asked my pal Barry Shein, who many of you know, if he had his PL/1
> syntax horror lying around, and he did.  He said: "this was tested on the
> Iron Spring Software PL/1 compiler running on openSuSe Linux (
> http://www.iron-spring.com/)"
> > >
> > > IBM still uses PL/1.  Remember, the main definition of "legacy" is
> "revenue-producing."
> > >
> > > TRY:PROC OPTIONS(MAIN);
> > >    DCL (IF,THEN,ELSE) FIXED BINARY (31);
> > >
> > >    IF = 1;
> > >    THEN = 2;
> > >    ELSE = 3;
> > >
> > >    IF IF = THEN THEN THEN = IF ; ELSE ELSE = THEN;
> > >
> > > END TRY;
> > >
>

[-- Attachment #2: Type: text/html, Size: 2092 bytes --]

Re: [TUHS] Book Recommendation

[Charles Anthony]

[-- Attachment #1: Type: text/plain, Size: 570 bytes --]

On Wed, Nov 24, 2021 at 7:23 AM Richard Salz <rich.salz@gmail.com> wrote:

> ....
>

          Compiled by: Multics PL/I Compiler, Release 33f, of February 11,
2017
          Compiled at: Installation and location
          Compiled on: 11/24/21  1411.5 pst Wed
              Options: table list

        1 try:proc options(main);
        2    dcl (if,then,else) fixed binary (31);
        3
        4    if = 1;
        5    then = 2;
        6    else = 3;
        7
        8    if if = then then then = if; else else = then;
        9
       10 end try;

-- Charles

[-- Attachment #2: Type: text/html, Size: 1124 bytes --]

[TUHS] PL/I stuff - was: Book Recommendation

[Will Senn]

[-- Attachment #1: Type: text/plain, Size: 1058 bytes --]

Here, lemme see if I can help more directly... Hopefully, this will help 
move this PL/I stuff thread off the book recommendation thread. If not, 
someone with more List knowhow, please help.

In line with the new subject,  What, if any, features does PL/I have 
that are not realized in a modern language?

Thanks,

Will

On 11/24/21 4:19 PM, Charles Anthony wrote:
>
>
> On Wed, Nov 24, 2021 at 7:23 AM Richard Salz <rich.salz@gmail.com> wrote:
>
>     ....
>
>
>           Compiled by: Multics PL/I Compiler, Release 33f, of February 
> 11, 2017
>           Compiled at: Installation and location
>           Compiled on: 11/24/21  1411.5 pst Wed
>               Options: table list
>
>         1 try:proc options(main);
>         2    dcl (if,then,else) fixed binary (31);
>         3
>         4    if = 1;
>         5    then = 2;
>         6    else = 3;
>         7
>         8    if if = then then then = if; else else = then;
>         9
>        10 end try;
>
> -- Charles

[-- Attachment #2: Type: text/html, Size: 2461 bytes --]

Re: [TUHS] PL/I stuff - was: Book Recommendation

[Rob Pike]

Far too many semicolons, no keywords, and adjustable integer sizes.

-rob

On Thu, Nov 25, 2021 at 9:31 AM Will Senn <will.senn@gmail.com> wrote:
>
> Here, lemme see if I can help more directly... Hopefully, this will help move this PL/I stuff thread off the book recommendation thread. If not, someone with more List knowhow, please help.
>
> In line with the new subject,  What, if any, features does PL/I have that are not realized in a modern language?
>
> Thanks,
>
> Will
>
> On 11/24/21 4:19 PM, Charles Anthony wrote:
>
>
>
> On Wed, Nov 24, 2021 at 7:23 AM Richard Salz <rich.salz@gmail.com> wrote:
>>
>> ....
>
>
>           Compiled by: Multics PL/I Compiler, Release 33f, of February 11, 2017
>           Compiled at: Installation and location
>           Compiled on: 11/24/21  1411.5 pst Wed
>               Options: table list
>
>         1 try:proc options(main);
>         2    dcl (if,then,else) fixed binary (31);
>         3
>         4    if = 1;
>         5    then = 2;
>         6    else = 3;
>         7
>         8    if if = then then then = if; else else = then;
>         9
>        10 end try;
>
> -- Charles
>
>

Re: [TUHS] PL/I stuff - was: Book Recommendation

[Richard Salz]

[-- Attachment #1: Type: text/plain, Size: 283 bytes --]

On Wed, Nov 24, 2021 at 6:03 PM Rob Pike <robpike@gmail.com> wrote:

> Far too many semicolons, no keywords, and adjustable integer sizes.
>
>
I don't know if this falls into Rob's list or not, but the PL/1 macro
language is powerful; https://en.wikipedia.org/wiki/PL/I_preprocessor

[-- Attachment #2: Type: text/html, Size: 701 bytes --]

Re: [TUHS] PL/I stuff - was: Book Recommendation

[Nelson H. F. Beebe]

Will Senn asks on Wed, 24 Nov 2021 16:29:27 -0600:

>> What, if any, features does PL/I have that are not realized 
>> in a modern language?

One that I exploited heavily was the "ON ENDPAGE" trap: I wrote code
that we used from both PL/I and Fortran to attach running page
headers/footers, with a job name, timestamp, and page number.  This
mattered to us a lot when our nightly outputs sometimes ran to a box
of z-fold paper (1K or 2K sheet? my memory is hazy).

In Unix, of course, we would just run

	myprog | pr > myprog.lst

but IBM mainframes of the 1960s and 1970s did not have anything
remotely like that at academic customer sites.

Alas, all of my PL/I code archives were lost to a dumpster some 30
years ago: we lacked the disk space to make copies of a couple of
thousand 9-track tapes, and with the retirement of our DEC mainframes,
we no longer had 9-track tape drives to read the tapes.  I have long
regretted our action, but budgets, and the limited technology of the
time, gave us no option.

-------------------------------------------------------------------------------
- Nelson H. F. Beebe                    Tel: +1 801 581 5254                  -
- University of Utah                    FAX: +1 801 581 4148                  -
- Department of Mathematics, 110 LCB    Internet e-mail: beebe@math.utah.edu  -
- 155 S 1400 E RM 233                       beebe@acm.org  beebe@computer.org -
- Salt Lake City, UT 84112-0090, USA    URL: http://www.math.utah.edu/~beebe/ -
-------------------------------------------------------------------------------

Re: [TUHS] PL/I stuff - was: Book Recommendation

[George Michaelson]

I have a relative who is an archivist, the sister-discipline to
librarians (Mike Lesk was at heart I think, in the library most the
time time. I say this, because I always think about Mike when the
topic of data and libraries comes up. He was nice to me at UCL and I
have a soft spot for anyone who was nice to me.)

Anyway, She tells me that the primary role of archivists is to help
people throw things away.

As a (sometime) scientist in (mostly) data, I know I have serial
hoarding disease. But I also know that NASA and other agencies only
found some things, by going back into the stacks to re-read old tapes,
without the "noise reduction filter" which had taken signal out.

So I feel your pain, loosing the tapes will have hurt. But I also know
along the path in time, Somebody had a role to play, curating the data
into the modern era. You're not alone, the BBC had this problem in
spades, re-using Umatic tape to save money. Ephemeral content which
turns out to be in some cases the probably only copy of what is data
to us now, but was junk to them then.

-G

Re: [TUHS] Book Recommendation

[arnold]

What I meant to write here, before my ssh connection dropped, was
that FORTRAN also did not reserve keywords.

Arnold

arnold@skeeve.com wrote:

> Richard Salz <rich.salz@gmail.com> wrote:
>
> > I asked my pal Barry Shein, who many of you know, if he had his PL/1 syntax
> > horror lying around, and he did.  He said: "this was tested on the Iron
> > Spring Software PL/1 compiler running on openSuSe Linux (
> > http://www.iron-spring.com/)"
> >
> > IBM still uses PL/1.  Remember, the main definition of "legacy" is
> > "revenue-producing."
> >
> > TRY:PROC OPTIONS(MAIN);
> >    DCL (IF,THEN,ELSE) FIXED BINARY (31);
> >
> >    IF = 1;
> >    THEN = 2;
> >    ELSE = 3;
> >
> >    IF IF = THEN THEN THEN = IF ; ELSE ELSE = THEN;
> >
> > END TRY;

Re: [TUHS] Book Recommendation

[Tom Ivar Helbekkmo via TUHS]

Larry McVoy <lm@mcvoy.com> writes:

> SMIT - just say no.

I remember it being useful for one thing: when I was unsure of the
correct way to do some AIX specific operation, I could enter SMIT, get
to where it was ready to do it for me, and it would show me the command
line it was about to run.  Then I could reread the man page for that
command, knowing which options and parameters SMIT would use.  So as a
learning tool it wasn't all bad.

-tih
-- 
Most people who graduate with CS degrees don't understand the significance
of Lisp.  Lisp is the most important idea in computer science.  --Alan Kay

[TUHS] AIX/SMIT (was Re: Book Recommendation)

[Stuart Remphrey]

[-- Attachment #1: Type: text/plain, Size: 927 bytes --]

On Thu, 25 Nov 2021, 18:35 Tom Ivar Helbekkmo via TUHS, <
tuhs@minnie.tuhs.org> wrote:

> Larry McVoy <lm@mcvoy.com> writes:
>
> > SMIT - just say no.
> ... it would show me the command
> line it was about to run.


Ditto. The only SMIT or AIX feature I used/liked.
Oh, that and mksysb.
*maybe* the volume manager, if none was the alternative.

Eventually got to understand (some of) the AIX  stanza files &
interactions, though also always hated them -- and no software
worked/ported easily. Then I mercifully escaped AIX, after Wang went ch.11
-- a former manager/colleague had hired me into Wang Australia when they
started selling HP, IBM & MIPS boxen along with PC office networks to avoid
going broke, but weren't quick-footed enough.


---

> Lisp is the most important idea in computer science.  --Alan Kay
>

Unless you're a postfix lover?!
Long live RPN, postscript, forth,...
(ducks behind desk; exits, stage right)

[-- Attachment #2: Type: text/html, Size: 2217 bytes --]

Re: [TUHS] PL/I stuff - was: Book Recommendation

[Clem Cole]

[-- Attachment #1: Type: text/plain, Size: 902 bytes --]

On Wed, Nov 24, 2021 at 9:06 PM George Michaelson <ggm@algebras.org> wrote:

> I have a relative who is an archivist, the sister-discipline to librarians
> ....
>
> Anyway, She tells me that the primary role of archivists is to help people
> throw things away.

George, thank you for the smile both for me and my wife.

I am married to a former public director - *a.k.a.* a librarian with the
formal degrees to prove it ;-).  She always says weeding the collection is
the most important part of the job.  The key is knowing what you can
toss, what is being used.  For any library, there is* never a enough space
to keep everything, but the problem is you can never fully know what will
be valuable in the future.*

Anyway, she has been on my case for probably 20 years to 'weed' my
collection of things.  A basement flood thanks to Hurricane Elsa this
spring has finally forced it.

Thanks again,
Clem

[-- Attachment #2: Type: text/html, Size: 2535 bytes --]

Re: [TUHS] AIX/SMIT (was Book Recommendation)

[Greg A. Woods]

[-- Attachment #1: Type: text/plain, Size: 1169 bytes --]

At Wed, 24 Nov 2021 12:02:25 -0800, Larry McVoy <lm@mcvoy.com> wrote:
Subject: Re: [TUHS] Book Recommendation
>
> HP was much better than AIX, you could ignore their admin crud and
> just edit the /etc files and stuff worked.  With AIX, I never figured
> out how to not use SMIT, it was pretty intertwined with everything.

SMIT was really just a front end to the underlying commands and the
files they edited; and as such a useful agent to help one figure out the
IBM way of things.  Under the hood it was all command-line and files and
databases, and SMIT could be configured to tell you exactly what it was
doing, and once you learned what to do you could easily avoid it
entirely.  It was basically created so that the office manager could
also be the system manager.

AIX though was like a lot of more enterprisy Unixes -- too much Not
Invented Here Syndrome affecting their additions to the basic system,
and as a result everything beyond what we now call POSIX was unique to
it.

--
					Greg A. Woods <gwoods@acm.org>

Kelowna, BC     +1 250 762-7675           RoboHack <woods@robohack.ca>
Planix, Inc. <woods@planix.com>     Avoncote Farms <woods@avoncote.ca>

[-- Attachment #2: OpenPGP Digital Signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [TUHS] PL/I stuff - was: Book Recommendation

[Alan Glasser]

[-- Attachment #1: Type: text/plain, Size: 1525 bytes --]

My mom was a librarian, my wife was a librarian, my father-in-law was a librarian and my son is a librarian. 

What I liked most about “weeding” was when one of my family brought me a “discard/destroy” weeded book. 

Unfortunately, since I retired I’ve been weeding my stuff. And I think I’ve discarded a bunch of (Bell Labs term) Technical Memoranda that I wrote, the contents of which would likely (possibly?) be of interest to TUHS. I was unaware of its existence until recently. 

 - Alan

> On Nov 25, 2021, at 9:50 AM, Clem Cole <clemc@ccc.com> wrote:
> 
> 
> 
> 
>> On Wed, Nov 24, 2021 at 9:06 PM George Michaelson <ggm@algebras.org> wrote:
>> I have a relative who is an archivist, the sister-discipline to librarians ....
>> 
>> Anyway, She tells me that the primary role of archivists is to help people throw things away.
> George, thank you for the smile both for me and my wife.
> 
> I am married to a former public director - a.k.a. a librarian with the formal degrees to prove it ;-).  She always says weeding the collection is the most important part of the job.  The key is knowing what you can toss, what is being used.  For any library, there is never a enough space to keep everything, but the problem is you can never fully know what will be valuable in the future.
> 
> Anyway, she has been on my case for probably 20 years to 'weed' my collection of things.  A basement flood thanks to Hurricane Elsa this spring has finally forced it.
> 
> Thanks again,
> Clem

[-- Attachment #2: Type: text/html, Size: 3481 bytes --]

Re: [TUHS] PL/I stuff - was: Book Recommendation

[Alan Glasser]

In my experience 9 track tapes were not guaranteed to be readable after some interval. In fact, a standard operations procedure was to copy important tapes to new media periodically. 

I distinctly remember a rather catastrophic error in the AT&T Worldnet ISP mail system. It was running a third party email server product on a large cluster of big Sun boxes. A new release was installed. It had bugs and curdled all of the customers’ data. It got backed out and a huge restore from backup effort began, only to find that a bunch of recently written tapes were unreadable.  Needless to say, we had unhappy customers and, if I remember correctly, some very negative press in the WSJ and the NY Times. 

 - Alan

> On Nov 24, 2021, at 9:06 PM, George Michaelson <ggm@algebras.org> wrote:
> 
> I have a relative who is an archivist, the sister-discipline to
> librarians (Mike Lesk was at heart I think, in the library most the
> time time. I say this, because I always think about Mike when the
> topic of data and libraries comes up. He was nice to me at UCL and I
> have a soft spot for anyone who was nice to me.)
> 
> Anyway, She tells me that the primary role of archivists is to help
> people throw things away.
> 
> As a (sometime) scientist in (mostly) data, I know I have serial
> hoarding disease. But I also know that NASA and other agencies only
> found some things, by going back into the stacks to re-read old tapes,
> without the "noise reduction filter" which had taken signal out.
> 
> So I feel your pain, loosing the tapes will have hurt. But I also know
> along the path in time, Somebody had a role to play, curating the data
> into the modern era. You're not alone, the BBC had this problem in
> spades, re-using Umatic tape to save money. Ephemeral content which
> turns out to be in some cases the probably only copy of what is data
> to us now, but was junk to them then.
> 
> -G

Re: [TUHS] PL/I stuff - was: Book Recommendation

[Dennis Boone]

 > In my experience 9 track tapes were not guaranteed to be readable after
 > some interval.  In fact, a standard operations procedure was to copy
 > important tapes to new media periodically.

There are always ways in which your backups can go wrong and not be
readable, and I'm not arguing that here.

But 9 track tapes have turned out to be pretty spectacularly long-lived.
I've personally read tapes that were stored for 30+ years in
unconditioned spaces.

De

Re: [TUHS] PL/I stuff - was: Book Recommendation

[Larry McVoy]

On Fri, Nov 26, 2021 at 07:23:07PM -0500, Dennis Boone wrote:
>  > In my experience 9 track tapes were not guaranteed to be readable after
>  > some interval.  In fact, a standard operations procedure was to copy
>  > important tapes to new media periodically.
> 
> There are always ways in which your backups can go wrong and not be
> readable, and I'm not arguing that here.
> 
> But 9 track tapes have turned out to be pretty spectacularly long-lived.
> I've personally read tapes that were stored for 30+ years in
> unconditioned spaces.

Contrast that with the write only exabyte tapes.  I lost some stuff to those.

Re: [TUHS] PL/I stuff - was: Book Recommendation

[Charles H. Sauer]

I haven't done anything with 9 track tapes for a long time, but I used 
to help my father with his statistical research, processing what at the 
time seemed massive census and similar data sets on 9 track tape (using 
PL/I on 370s at U. MO Columbia). Some of his tapes were quite old, 
stored in his basement and then his garage, but I don't recall problems 
reading any of them.

IMNSHO, it all depends on the brand/formulation of the tape. I've been 
going through old audio tapes and digitizing them 
(https://notes.technologists.com/notes/2021/08/21/making-private-1960s-and-70s-recordings-public/). 
Some are over 50 years old and still seem as good to me as when they 
were recorded. Others, I can anticipate from the brand/formulation that 
they are going to be trouble, if salvageable at all. Most surprisingly, 
unbranded and similar budget tapes have survived as well or better than 
some of the high-priced stuff. A few days ago I tried a reel from 1968. 
I was dismayed by how many times it had been spliced, but replace the 
splicing tape and found it viable.

I have dozens of DDS-2, 3 & 4 cartridges from the 90s that I 
occasionally try to read. I don't recall any of them failing.

(We probably should be COFFing this up.)

Charlie

On 11/26/2021 6:30 PM, Larry McVoy wrote:
> On Fri, Nov 26, 2021 at 07:23:07PM -0500, Dennis Boone wrote:
>>   > In my experience 9 track tapes were not guaranteed to be readable after
>>   > some interval.  In fact, a standard operations procedure was to copy
>>   > important tapes to new media periodically.
>>
>> There are always ways in which your backups can go wrong and not be
>> readable, and I'm not arguing that here.
>>
>> But 9 track tapes have turned out to be pretty spectacularly long-lived.
>> I've personally read tapes that were stored for 30+ years in
>> unconditioned spaces.
> 
> Contrast that with the write only exabyte tapes.  I lost some stuff to those.
> 

-- 
voice: +1.512.784.7526       e-mail: sauer@technologists.com
fax: +1.512.346.5240         Web: https://technologists.com/sauer/
Facebook/Google/Twitter: CharlesHSauer

Re: [TUHS] PL/I stuff - was: Book Recommendation

[Warner Losh]

[-- Attachment #1: Type: text/plain, Size: 827 bytes --]

On Fri, Nov 26, 2021, 5:32 PM Larry McVoy <lm@mcvoy.com> wrote:

> On Fri, Nov 26, 2021 at 07:23:07PM -0500, Dennis Boone wrote:
> >  > In my experience 9 track tapes were not guaranteed to be readable
> after
> >  > some interval.  In fact, a standard operations procedure was to copy
> >  > important tapes to new media periodically.
> >
> > There are always ways in which your backups can go wrong and not be
> > readable, and I'm not arguing that here.
> >
> > But 9 track tapes have turned out to be pretty spectacularly long-lived.
> > I've personally read tapes that were stored for 30+ years in
> > unconditioned spaces.
>
> Contrast that with the write only exabyte tapes.  I lost some stuff to
> those.
>

There is a reason that exabyte no longer exists. It used to take up a big
swath of central Boulder.

Warner

>

[-- Attachment #2: Type: text/html, Size: 1445 bytes --]

Re: [TUHS] PL/I stuff - was: Book Recommendation

[Alan Glasser]

On second thought, given that the Worldnet outage was late 1996, it was most likely that the backups were to 8mm tape. Exabyte?!

 - Alan

> On Nov 26, 2021, at 8:10 PM, Charles H. Sauer <sauer@technologists.com> wrote:
> 
> I haven't done anything with 9 track tapes for a long time, but I used to help my father with his statistical research, processing what at the time seemed massive census and similar data sets on 9 track tape (using PL/I on 370s at U. MO Columbia). Some of his tapes were quite old, stored in his basement and then his garage, but I don't recall problems reading any of them.
> 
> IMNSHO, it all depends on the brand/formulation of the tape. I've been going through old audio tapes and digitizing them (https://notes.technologists.com/notes/2021/08/21/making-private-1960s-and-70s-recordings-public/). Some are over 50 years old and still seem as good to me as when they were recorded. Others, I can anticipate from the brand/formulation that they are going to be trouble, if salvageable at all. Most surprisingly, unbranded and similar budget tapes have survived as well or better than some of the high-priced stuff. A few days ago I tried a reel from 1968. I was dismayed by how many times it had been spliced, but replace the splicing tape and found it viable.
> 
> I have dozens of DDS-2, 3 & 4 cartridges from the 90s that I occasionally try to read. I don't recall any of them failing.
> 
> (We probably should be COFFing this up.)
> 
> Charlie
> 
>> On 11/26/2021 6:30 PM, Larry McVoy wrote:
>>> On Fri, Nov 26, 2021 at 07:23:07PM -0500, Dennis Boone wrote:
>>>  > In my experience 9 track tapes were not guaranteed to be readable after
>>>  > some interval.  In fact, a standard operations procedure was to copy
>>>  > important tapes to new media periodically.
>>> 
>>> There are always ways in which your backups can go wrong and not be
>>> readable, and I'm not arguing that here.
>>> 
>>> But 9 track tapes have turned out to be pretty spectacularly long-lived.
>>> I've personally read tapes that were stored for 30+ years in
>>> unconditioned spaces.
>> Contrast that with the write only exabyte tapes.  I lost some stuff to those.
> 
> -- 
> voice: +1.512.784.7526       e-mail: sauer@technologists.com
> fax: +1.512.346.5240         Web: https://technologists.com/sauer/
> Facebook/Google/Twitter: CharlesHSauer

Re: [TUHS] PL/I stuff - was: Book Recommendation

[Paul Winalski]

On 11/26/21, George Michaelson <ggm@algebras.org> wrote:
>
>Burroughs by comparison had (I am
> told, I didn't use them) shit hot code, the kernel was in a ci/cd
> deployment framework with smarts. And DEC had the decus tapes and
> everything in VMS was on microfiche.

Originally on the S/360 IBM software was free (the DECUS tapes model)
as well, and the source code was available on microfiche.  There were
some successful third party software products.  For example, a lot of
very big data centers shelled out the $$$ for SyncSort because it was
so much better and faster than the (free) IBM sort/merge program.

Then, as part of the settlement for one of the antitrust lawsuits, IBM
was forced to unbundle software from hardware.  IBM made lemonade out
of this bunch of lemons by marketing its software licenses on a
subscription basis vs. selling a license for a one-time charge (the
model that DEC used, and that is most common in the PC market).
Microsoft seems to be trending that way with Windows 10/11.

-Paul W.

Re: [TUHS] PL/I stuff - was: Book Recommendation

[Charles H Sauer]

On 11/27/2021 9:25 AM, Noel Chiappa wrote:
>      > From: "Charles H. Sauer"k <sauer@technologists.com>
> 
>      > I haven't done anything with 9 ktrack tapes for a long time ...
>      > I don't recall problems reading any of them. ...
>      > IMNSHO, it all depends on the brand/formulation of the tape. I've been
>      > going through old audio tapes and digitizing them
> 
> The vintage computer community has considerable experience with old tapes; in
> fact Chuck Guzis has a business reading them (which often includes converting
> old file formats to something modern software can grok).
> 
> We originally depended heavily on the work of the vintage audio community, who
> pioneered working with old tapes, including the discovert of 'baking' them to
> improve their mechanical playability. ("the binder used to adhere the magnetic
> material to the backing ... becomes unstable" - playing such a tape will
> transfer much of the magnetic material to the head, destroying the tape's
> contents.)

The notion of "baking" is slightly misleading. When done with audio 
tapes, the practice is to use a dehydrating oven at about 130F for about 
24 hours.

> It's amazing how bad a tape can be, and still be readable. I had a couple of
> dump tapes of the CSR PWB1 machine at MIT, which I had thoughtlessly stored in
> my (at one period damp) basement, and they were covered in mold - and not just
> on the edges! Chuck had to build a special fixture to clean off the mold, but
> we read most of the first tape. (I had thoughtfully ade a second copy, which
> read perfectly.)
> 
> Then I had to work out what the format was - it turned out that even though
> the machine had a V6 filesystem, my tape was a 'dd' of a BSD4.1c filesystem
> (for reasons I eventually worked out, but won't bore you all with). Dave
> Bridgham managed to mount that under Linux, and transform it into a TAR
> file. That was the source of many old treasures, including the V6 NCP UNIX.
> 
>        Noel
> 

-- 
voice: +1.512.784.7526       e-mail: sauer@technologists.com
fax: +1.512.346.5240         Web: https://technologists.com/sauer/
Facebook/Google/Twitter: CharlesHSauer

Re: [TUHS] PL/I stuff - was: Book Recommendation

[Noel Chiappa]

    > From: "Charles H. Sauer"k <sauer@technologists.com>

    > I haven't done anything with 9 ktrack tapes for a long time ...
    > I don't recall problems reading any of them. ...
    > IMNSHO, it all depends on the brand/formulation of the tape. I've been 
    > going through old audio tapes and digitizing them 

The vintage computer community has considerable experience with old tapes; in
fact Chuck Guzis has a business reading them (which often includes converting
old file formats to something modern software can grok).

We originally depended heavily on the work of the vintage audio community, who
pioneered working with old tapes, including the discovert of 'baking' them to
improve their mechanical playability. ("the binder used to adhere the magnetic
material to the backing ... becomes unstable" - playing such a tape will
transfer much of the magnetic material to the head, destroying the tape's
contents.)

It's amazing how bad a tape can be, and still be readable. I had a couple of
dump tapes of the CSR PWB1 machine at MIT, which I had thoughtlessly stored in
my (at one period damp) basement, and they were covered in mold - and not just
on the edges! Chuck had to build a special fixture to clean off the mold, but
we read most of the first tape. (I had thoughtfully ade a second copy, which
read perfectly.)

Then I had to work out what the format was - it turned out that even though
the machine had a V6 filesystem, my tape was a 'dd' of a BSD4.1c filesystem
(for reasons I eventually worked out, but won't bore you all with). Dave
Bridgham managed to mount that under Linux, and transform it into a TAR
file. That was the source of many old treasures, including the V6 NCP UNIX.

      Noel

Re: [TUHS] PL/I stuff - was: Book Recommendation

[George Michaelson]

[-- Attachment #1: Type: text/plain, Size: 1821 bytes --]

I've always felt a huge disconnect between the decus tape philosophy of
code, and the IBM approach of "this software feature costs you more" about
things like language extensions and -O(n) flags (to use modern c compiler
mental models)

I did find the hardware trick of detuning the clock to sell more boxes and
charging to remove the resistors also a bit iffy but I kind of understood
it. But, being asked by some major client (defence) to implement recursion
support and then charging everyone feels like the business model designed
to kick start people cutting their own code to stop depending in yours -and
I believe this is somewhat the story of university multi access systems on
IBM and these seven dwarf competitors. Burroughs by comparison had (I am
told, I didn't use them) shit hot code, the kernel was in a ci/cd
deployment framework with smarts. And DEC had the decus tapes and
everything in VMS was on microfiche.

On Sat, 27 Nov 2021, 7:24 am John Cowan, <cowan@ccil.org> wrote:

>
>
> On Fri, Nov 26, 2021 at 3:32 PM Tom Ivar Helbekkmo via TUHS <
> tuhs@minnie.tuhs.org> wrote:
>
> Is there any relationship, other than pure coincidence, between this
>> naming scheme and DEC's F, G, and H floating point number formats?
>>
>
> I don't think so.  The System/360 letters referred specifically to the
> amount of memory available, so a D compiler would run on a D machine with
> 256K, and E/F/G were 512K/1M/2M.
>
> The DEC floats were an extension of Fortran's exponent letters:  D=double,
> E=generic, F=single.  G is a variant of F with a different
> mantissa/exponent balance, and H is double double.   S and T floats came
> later and were bit-for-bit compatible with IEEE binary32 and binary64
> formats.  Lisp went a different way: to D, E, F they added S for small
> floats and L for large floats.
>

[-- Attachment #2: Type: text/html, Size: 2925 bytes --]

Re: [TUHS] PL/I stuff - was: Book Recommendation

[John Cowan]

[-- Attachment #1: Type: text/plain, Size: 791 bytes --]

On Fri, Nov 26, 2021 at 3:32 PM Tom Ivar Helbekkmo via TUHS <
tuhs@minnie.tuhs.org> wrote:

Is there any relationship, other than pure coincidence, between this
> naming scheme and DEC's F, G, and H floating point number formats?
>

I don't think so.  The System/360 letters referred specifically to the
amount of memory available, so a D compiler would run on a D machine with
256K, and E/F/G were 512K/1M/2M.

The DEC floats were an extension of Fortran's exponent letters:  D=double,
E=generic, F=single.  G is a variant of F with a different
mantissa/exponent balance, and H is double double.   S and T floats came
later and were bit-for-bit compatible with IEEE binary32 and binary64
formats.  Lisp went a different way: to D, E, F they added S for small
floats and L for large floats.

[-- Attachment #2: Type: text/html, Size: 1577 bytes --]

Re: [TUHS] PL/I stuff - was: Book Recommendation

[Tom Ivar Helbekkmo via TUHS]

Paul Winalski <paul.winalski@gmail.com> writes:

> Back in the pre-virtual-memory days of the System/360, IBM offered its
> compilers in at least three variants:  F, G, and H.  They differed in
> the amount of memory required and in features and especially the
> sophistication of the optimizations they performed.  IBM PL/I H
> required the most memory and performed the highest levels of
> optimization.

Is there any relationship, other than pure coincidence, between this
naming scheme and DEC's F, G, and H floating point number formats?

-tih
-- 
Most people who graduate with CS degrees don't understand the significance
of Lisp.  Lisp is the most important idea in computer science.  --Alan Kay

Re: [TUHS] PL/I stuff - was: Book Recommendation

[Paul Winalski]

Back in the pre-virtual-memory days of the System/360, IBM offered its
compilers in at least three variants:  F, G, and H.  They differed in
the amount of memory required and in features and especially the
sophistication of the optimizations they performed.  IBM PL/I H
required the most memory and performed the highest levels of
optimization.

There were some source language features to aid in optimization.

My shop used PL/I F on DOS/360.  It had one optimization-related
source feature:  the RECURSIVE  and REORDER keywords on the PROCEDURE
statement.

A procedure that may be called recursively, either directly or
indirectly, must have the RECURSIVE attribute.  This tells the
compiler to allocate local variables and temporaries on a call stack
as opposed to statically.  The ABIs for modern OSes always maintain a
stack for procedure calls--not so with S/360/70 OS and DOS.

The REORDER attribute tells the compiler that it is permitted to
execute statements or pieces of statements in an order other than that
explicitly specified in the program, as long as the end result has the
same semantics.  This is taken as a given in modern compilers.

The higher-optimizing versions of IBM S/360 PL/I also had two
PROCEDURE attributes USES and SETS that allowed the programmer to warn
the compiler of side effects.  The USES attribute lists identifiers
global to the procedure that the procedure may read from, either
explicitly or implicitly.  The SETS attribute similarly lists
identifiers that may be modified by the procedure.  If USES is
specified, the compiler can assume that no other global data are
accessed, ans similarly if SETS is specified the compiler can assume
that no other global data will be modified.

Modern compilers perform global data flow analysis for all parts of
the program accessible to the current compilation.  While USES and
SETS even today can potentially be helpful in describing obscure side
effects, they were a very error-prone feature in their day and a real
maintenance nightmare.  They never made it into the ANSI standard and
I think they've been dropped from modern IBM PL/I compilers.

-Paul W.

Re: [TUHS] PL/I stuff - was: Book Recommendation

[Steve Nickolas]

On Thu, 25 Nov 2021, Paul Winalski wrote:

> 2. The DEFAULT statement.  This was Forran's IMPLICIT on steroids.  It
> let you say things like "data items with names beginning with A-G are
> decimal, I-N are binary, and O-Z are decimal".  There could also be
> overlap between DEFAULT declarations.  So in addition to the rule I
> just mentioned, you could say "A-J are fixed point and K-Z are
> floating point."  With both of these rules in effect, identifier FOO
> would be implicitly "fixed decimal", J would be "fixed biary, and KOOL
> would be "float binary".

This reminds me of DEFINT, DEFSNG, DEFDBL, DEFSTR in MBASIC and its 
descendants and DEFLNG in QBASIC.  A lot of QBASIC code used "DEFINT A-Z" 
for a slight speed boost.

(Not sure if these work in the Xenix version of MBASIC)

-uso.

Re: [TUHS] PL/I stuff - was: Book Recommendation

[Paul Winalski]

On 11/24/21, Douglas McIlroy <douglas.mcilroy@dartmouth.edu> wrote:
>> What, if any, features does PL/I have that are not realized in a modern
>> language?
>
> 7. Astonishingly complete set of implicit data conversions. E.g. if X
> is floating-point and S is a string, the assignment X = S works when S
> = "2" and raises an exception (not PL/I terminology) when S =  "A".

This could definitely be a buzz saw without safety shields.  Some of
the implicit conversion rules, particularly those dealing with fixed
point decimal arithmetic of mixed precision, had edge conditions that
yielded non-intuitive results.

I had a bug once that was due to a typo causing an unwanted implicit
conversion.  I had meant to type "IF A ~= B" (I'm using ~ here in
place of the PL/I "not" operator--the EBCDIC angle character), meaning
"IF A is not equal to B".  What I actually typed is "IF A =~ B". (if A
equals not-B).  Both A and B were character strings.  To apply the NOT
operator, B was converted to a bit string with '0' converted to a zero
bit and '1' to a one bit.  The NOT was performed, then the bit string
was converted back to a character string so that it could be compared
to A.  My clue as to the bug was a warning diagnostic from the
compiler:  "data conversion will be done by subroutine call".  This
almost always meant you'd accidentally invoked some kinky implicit
type conversion, as was the case here.

Here are some other PL/I features you don't see in modern languages.
Some of these were present in the early IBM PL/I compilers but dropped
from the ANSI standard:

1. Sterling pictures.  These provided a convenient way to do math on
and to display numbers representing pre-decimal British currency.
They had pounds, shillings, and pence fields.  This feature was
dropped even from the IBM compilers some years after the Commonwealth
nations all went decimal.

2. The DEFAULT statement.  This was Forran's IMPLICIT on steroids.  It
let you say things like "data items with names beginning with A-G are
decimal, I-N are binary, and O-Z are decimal".  There could also be
overlap between DEFAULT declarations.  So in addition to the rule I
just mentioned, you could say "A-J are fixed point and K-Z are
floating point."  With both of these rules in effect, identifier FOO
would be implicitly "fixed decimal", J would be "fixed biary, and KOOL
would be "float binary".

At our PL/I shop we considered DEFAULT to be a toxic language feature
that was banned.  The problem is that in the presence of a complicated
nest of DEFAULTs, when you see the declaration for an identifier it
can be next to impossible to tell what its complete data type actually
is.

3. PL/I declarations cover the entire scope of the innermost BEGIN/END
block that contains them, regardless of where within that block the
declaration occurs.  Thus you can use variables before they are
declared.  This was mildly useful if you were composing a program at
the keypunch.  Some programmers would write down the declarations for
their variables as they punched the cards, then when they came to the
END statement for a block they would punch out the declarations.  At
our shop this, again, was considered a toxic language feature--we
required all declarations to be at the start of their containing
block.

-Paul W.

[TUHS] PL/I stuff - was: Book Recommendation

[Douglas McIlroy]

> What, if any, features does PL/I have that are not realized in a modern language?

Here are a few dredged from the mental cranny where they have
mouldered for 50+ years.

1. Assignment by name. If A and B are structs (not official PL/I
terminology), then A + B A = B copies similarly named fields of B to
corresponding fields in A.

2. Both binary and decimal data with arithmetic rounded to any
specified precision.

3. Bit strings of arbitrary length, with bitwise Boolean operations
plus substr and catenation.

4. A named array is normally passed by reference, as in F(A). But if
the argument is not a bare name, as in F((A)), it is passed by value.

5. IO by name. On input this behaves like assignment from a constant,
with appropriate type conversion.

6. A SORT statement.

7. Astonishingly complete set of implicit data conversions. E.g. if X
is floating-point and S is a string, the assignment X = S works when S
= "2" and raises an exception (not PL/I terminology) when S =  "A".

 My 1967 contribution to ACM collected algorithms exploited 3 and 4. I
don't know another language in which that algorithm is as succinct.

Doug