The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
* [TUHS] PL/I stuff - was: Book Recommendation
@ 2021-11-24 23:54 Douglas McIlroy
  2021-11-25 16:35 ` Paul Winalski
  0 siblings, 1 reply; 23+ messages in thread
From: Douglas McIlroy @ 2021-11-24 23:54 UTC (permalink / raw)
  To: TUHS main list

> 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

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [TUHS] PL/I stuff - was: Book Recommendation
  2021-11-24 23:54 [TUHS] PL/I stuff - was: Book Recommendation Douglas McIlroy
@ 2021-11-25 16:35 ` Paul Winalski
  2021-11-25 18:15   ` Steve Nickolas
  2021-11-26 16:59   ` Paul Winalski
  0 siblings, 2 replies; 23+ messages in thread
From: Paul Winalski @ 2021-11-25 16:35 UTC (permalink / raw)
  To: Douglas McIlroy; +Cc: TUHS main list

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.

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [TUHS] PL/I stuff - was: Book Recommendation
  2021-11-25 16:35 ` Paul Winalski
@ 2021-11-25 18:15   ` Steve Nickolas
  2021-11-26 16:59   ` Paul Winalski
  1 sibling, 0 replies; 23+ messages in thread
From: Steve Nickolas @ 2021-11-25 18:15 UTC (permalink / raw)
  To: Paul Winalski; +Cc: TUHS main list, Douglas McIlroy

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.

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [TUHS] PL/I stuff - was: Book Recommendation
  2021-11-25 16:35 ` Paul Winalski
  2021-11-25 18:15   ` Steve Nickolas
@ 2021-11-26 16:59   ` Paul Winalski
  2021-11-26 20:30     ` Tom Ivar Helbekkmo via TUHS
  1 sibling, 1 reply; 23+ messages in thread
From: Paul Winalski @ 2021-11-26 16:59 UTC (permalink / raw)
  To: Douglas McIlroy; +Cc: TUHS main list

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.

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [TUHS] PL/I stuff - was: Book Recommendation
  2021-11-26 16:59   ` Paul Winalski
@ 2021-11-26 20:30     ` Tom Ivar Helbekkmo via TUHS
  2021-11-26 21:22       ` John Cowan
  0 siblings, 1 reply; 23+ messages in thread
From: Tom Ivar Helbekkmo via TUHS @ 2021-11-26 20:30 UTC (permalink / raw)
  To: Paul Winalski; +Cc: TUHS main list, Douglas McIlroy

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

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [TUHS] PL/I stuff - was: Book Recommendation
  2021-11-26 20:30     ` Tom Ivar Helbekkmo via TUHS
@ 2021-11-26 21:22       ` John Cowan
  2021-11-27  0:01         ` George Michaelson
  0 siblings, 1 reply; 23+ messages in thread
From: John Cowan @ 2021-11-26 21:22 UTC (permalink / raw)
  To: Tom Ivar Helbekkmo; +Cc: TUHS main list, Douglas McIlroy

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

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [TUHS] PL/I stuff - was: Book Recommendation
  2021-11-26 21:22       ` John Cowan
@ 2021-11-27  0:01         ` George Michaelson
  2021-11-27 16:12           ` Paul Winalski
  0 siblings, 1 reply; 23+ messages in thread
From: George Michaelson @ 2021-11-27  0:01 UTC (permalink / raw)
  To: TUHS main list

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

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [TUHS] PL/I stuff - was: Book Recommendation
  2021-11-27  0:01         ` George Michaelson
@ 2021-11-27 16:12           ` Paul Winalski
  0 siblings, 0 replies; 23+ messages in thread
From: Paul Winalski @ 2021-11-27 16:12 UTC (permalink / raw)
  To: George Michaelson; +Cc: TUHS main list

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.

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [TUHS] PL/I stuff - was: Book Recommendation
  2021-11-27 15:25 Noel Chiappa
@ 2021-11-27 15:53 ` Charles H Sauer
  0 siblings, 0 replies; 23+ messages in thread
From: Charles H Sauer @ 2021-11-27 15:53 UTC (permalink / raw)
  To: tuhs

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

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [TUHS] PL/I stuff - was: Book Recommendation
@ 2021-11-27 15:25 Noel Chiappa
  2021-11-27 15:53 ` Charles H Sauer
  0 siblings, 1 reply; 23+ messages in thread
From: Noel Chiappa @ 2021-11-27 15:25 UTC (permalink / raw)
  To: tuhs; +Cc: jnc

    > 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

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [TUHS] PL/I stuff - was: Book Recommendation
  2021-11-27  0:47                   ` Charles H. Sauer
@ 2021-11-27  2:43                     ` Alan Glasser
  0 siblings, 0 replies; 23+ messages in thread
From: Alan Glasser @ 2021-11-27  2:43 UTC (permalink / raw)
  To: Charles H. Sauer; +Cc: tuhs

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

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [TUHS] PL/I stuff - was: Book Recommendation
  2021-11-27  0:30                 ` Larry McVoy
  2021-11-27  0:47                   ` Charles H. Sauer
@ 2021-11-27  0:56                   ` Warner Losh
  1 sibling, 0 replies; 23+ messages in thread
From: Warner Losh @ 2021-11-27  0:56 UTC (permalink / raw)
  To: Larry McVoy; +Cc: TUHS main list

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

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [TUHS] PL/I stuff - was: Book Recommendation
  2021-11-27  0:30                 ` Larry McVoy
@ 2021-11-27  0:47                   ` Charles H. Sauer
  2021-11-27  2:43                     ` Alan Glasser
  2021-11-27  0:56                   ` Warner Losh
  1 sibling, 1 reply; 23+ messages in thread
From: Charles H. Sauer @ 2021-11-27  0:47 UTC (permalink / raw)
  To: tuhs

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

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [TUHS] PL/I stuff - was: Book Recommendation
  2021-11-27  0:23               ` Dennis Boone
@ 2021-11-27  0:30                 ` Larry McVoy
  2021-11-27  0:47                   ` Charles H. Sauer
  2021-11-27  0:56                   ` Warner Losh
  0 siblings, 2 replies; 23+ messages in thread
From: Larry McVoy @ 2021-11-27  0:30 UTC (permalink / raw)
  To: Dennis Boone; +Cc: tuhs

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.

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [TUHS] PL/I stuff - was: Book Recommendation
  2021-11-25  2:03             ` George Michaelson
  2021-11-25 14:47               ` Clem Cole
  2021-11-26 22:33               ` Alan Glasser
@ 2021-11-27  0:23               ` Dennis Boone
  2021-11-27  0:30                 ` Larry McVoy
  2 siblings, 1 reply; 23+ messages in thread
From: Dennis Boone @ 2021-11-27  0:23 UTC (permalink / raw)
  To: tuhs

 > 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

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [TUHS] PL/I stuff - was: Book Recommendation
  2021-11-25  2:03             ` George Michaelson
  2021-11-25 14:47               ` Clem Cole
@ 2021-11-26 22:33               ` Alan Glasser
  2021-11-27  0:23               ` Dennis Boone
  2 siblings, 0 replies; 23+ messages in thread
From: Alan Glasser @ 2021-11-26 22:33 UTC (permalink / raw)
  To: George Michaelson; +Cc: tuhs

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

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [TUHS] PL/I stuff - was: Book Recommendation
  2021-11-25 14:47               ` Clem Cole
@ 2021-11-26 22:20                 ` Alan Glasser
  0 siblings, 0 replies; 23+ messages in thread
From: Alan Glasser @ 2021-11-26 22:20 UTC (permalink / raw)
  To: Clem Cole; +Cc: tuhs

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

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [TUHS] PL/I stuff - was: Book Recommendation
  2021-11-25  2:03             ` George Michaelson
@ 2021-11-25 14:47               ` Clem Cole
  2021-11-26 22:20                 ` Alan Glasser
  2021-11-26 22:33               ` Alan Glasser
  2021-11-27  0:23               ` Dennis Boone
  2 siblings, 1 reply; 23+ messages in thread
From: Clem Cole @ 2021-11-25 14:47 UTC (permalink / raw)
  To: George Michaelson; +Cc: tuhs

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

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [TUHS] PL/I stuff - was: Book Recommendation
  2021-11-25  1:48           ` Nelson H. F. Beebe
@ 2021-11-25  2:03             ` George Michaelson
  2021-11-25 14:47               ` Clem Cole
                                 ` (2 more replies)
  0 siblings, 3 replies; 23+ messages in thread
From: George Michaelson @ 2021-11-25  2:03 UTC (permalink / raw)
  To: Nelson H. F. Beebe; +Cc: tuhs

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

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [TUHS] PL/I stuff - was: Book Recommendation
  2021-11-24 22:29         ` [TUHS] PL/I stuff - was: " Will Senn
  2021-11-24 23:00           ` Rob Pike
@ 2021-11-25  1:48           ` Nelson H. F. Beebe
  2021-11-25  2:03             ` George Michaelson
  1 sibling, 1 reply; 23+ messages in thread
From: Nelson H. F. Beebe @ 2021-11-25  1:48 UTC (permalink / raw)
  To: Will Senn; +Cc: tuhs

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/ -
-------------------------------------------------------------------------------

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [TUHS] PL/I stuff - was: Book Recommendation
  2021-11-24 23:00           ` Rob Pike
@ 2021-11-24 23:13             ` Richard Salz
  0 siblings, 0 replies; 23+ messages in thread
From: Richard Salz @ 2021-11-24 23:13 UTC (permalink / raw)
  To: Rob Pike; +Cc: TUHS main list

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

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [TUHS] PL/I stuff - was: Book Recommendation
  2021-11-24 22:29         ` [TUHS] PL/I stuff - was: " Will Senn
@ 2021-11-24 23:00           ` Rob Pike
  2021-11-24 23:13             ` Richard Salz
  2021-11-25  1:48           ` Nelson H. F. Beebe
  1 sibling, 1 reply; 23+ messages in thread
From: Rob Pike @ 2021-11-24 23:00 UTC (permalink / raw)
  To: Will Senn; +Cc: TUHS main list

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

^ permalink raw reply	[flat|nested] 23+ messages in thread

* [TUHS] PL/I stuff - was:  Book Recommendation
  2021-11-24 22:19       ` Charles Anthony
@ 2021-11-24 22:29         ` Will Senn
  2021-11-24 23:00           ` Rob Pike
  2021-11-25  1:48           ` Nelson H. F. Beebe
  0 siblings, 2 replies; 23+ messages in thread
From: Will Senn @ 2021-11-24 22:29 UTC (permalink / raw)
  To: tuhs

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

^ permalink raw reply	[flat|nested] 23+ messages in thread

end of thread, other threads:[~2021-11-27 16:13 UTC | newest]

Thread overview: 23+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-11-24 23:54 [TUHS] PL/I stuff - was: Book Recommendation Douglas McIlroy
2021-11-25 16:35 ` Paul Winalski
2021-11-25 18:15   ` Steve Nickolas
2021-11-26 16:59   ` Paul Winalski
2021-11-26 20:30     ` Tom Ivar Helbekkmo via TUHS
2021-11-26 21:22       ` John Cowan
2021-11-27  0:01         ` George Michaelson
2021-11-27 16:12           ` Paul Winalski
  -- strict thread matches above, loose matches on Subject: below --
2021-11-27 15:25 Noel Chiappa
2021-11-27 15:53 ` Charles H Sauer
2021-11-16 14:57 [TUHS] " Douglas McIlroy
2021-11-23  2:28 ` Mary Ann Horton
2021-11-23 21:54   ` Thomas Paulsen
2021-11-24 15:18     ` Richard Salz
2021-11-24 22:19       ` Charles Anthony
2021-11-24 22:29         ` [TUHS] PL/I stuff - was: " Will Senn
2021-11-24 23:00           ` Rob Pike
2021-11-24 23:13             ` Richard Salz
2021-11-25  1:48           ` Nelson H. F. Beebe
2021-11-25  2:03             ` George Michaelson
2021-11-25 14:47               ` Clem Cole
2021-11-26 22:20                 ` Alan Glasser
2021-11-26 22:33               ` Alan Glasser
2021-11-27  0:23               ` Dennis Boone
2021-11-27  0:30                 ` Larry McVoy
2021-11-27  0:47                   ` Charles H. Sauer
2021-11-27  2:43                     ` Alan Glasser
2021-11-27  0:56                   ` Warner Losh

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).