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

[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

[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

[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] 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] 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] 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

[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

[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

[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

[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] 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] 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

[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

[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 --]