2 Aug
2021
2 Aug
'21
8:11 a.m.
Thanks for feedback and offers to assist. I received the tape from
one of the maintainers of Schoonship at CERN, and it was probably made
around 1978 at SLAC.
For some background, Tini Veltman developed Schoonship in the 1960's
at CERN on the CDC 6600. My understanding is that he more or less
insisted on coding in assembly since he thought FORTRAN or other high
level languages would just get in the way and slow things down. The
code was maintained by Veltman and Strubbe well into the 1970's, but
its future was held back by being so closely tied to CDC hardware.
In the mid 1970's, Strubbe began a conversion of Schoonschip to IBM
S/360 and S/370. It was sort of a curious technique, as far as I
gathered. The idea was to first translate CDC COMPASS source to an
intermediate PL/I like language. But then, instead of using the IBM
PL/I compiler, a bunch of macros were developed to implement the PL/I
like language in IBM assembly. This conversion was never fully
completed for reasons unknown to me.
Later on, when Tini joined the University of Michigan (that's where
I'm located), he realized that Schoonschip needed to be updated. But
the update was ... instead of CDC assembly he decided on m68k
assembly. (At this time, in the early 1980's, C probably would have
been the natural language of choice.) Moreover, he insisted on
developing his own toolchain (assembler, linker, etc). This was
before my time at Michigan, but basically he ported Schoonschip to
just about all the m68k machines of that era (Sun, Atari, Amiga, Mac,
NeXT, and others I am not familiar with). We have a pretty good
collection of m68k code
(http://www-personal.umich.edu/~williams/Vsys/index.html), but nothing
earlier.
Getting back to the tape, I'm pretty sure it has Strubbe's PL/I like
code as it is an archive of the PL/I conversion. It may also have CDC
source, but that is less obvious until we can see the contents. The
CDC source is historically the most relevant, and I am hoping it
exists on the tape.
- jim
--
James T. Liu, Professor of Physics
3409 Randall Laboratory, 450 Church Street, Ann Arbor, MI 48109-1040
Tel: 734 763-4314 Fax: 734 763-2213 Email: jimliu at umich.edu
2 Aug
2 Aug
9:19 a.m.
On Aug 2, 2021, at 11:11 AM, James Liu via cctech
<cctech at classiccmp.org> wrote:
Thanks for feedback and offers to assist. I received the tape from
one of the maintainers of Schoonship at CERN, and it was probably made
around 1978 at SLAC.
For some background, Tini Veltman developed Schoonship in the 1960's
at CERN on the CDC 6600. My understanding is that he more or less
insisted on coding in assembly since he thought FORTRAN or other high
level languages would just get in the way and slow things down.
Depending on what he was trying to do that may well be a valid assessment. CDC Fortran
was known to be pretty good, but Fortran is not the obvious answer for implementing
interpreters or other language processors, which this sounds like.
...
Getting back to the tape, I'm pretty sure it has Strubbe's PL/I like
code as it is an archive of the PL/I conversion. It may also have CDC
source, but that is less obvious until we can see the contents. The
CDC source is historically the most relevant, and I am hoping it
exists on the tape.
Just to make sure you're aware of this: if it is CDC source code, you can run that on
the DtCyber emulator. That's a full 6000 / 170 series machine emulator which can run
almost all CDC 6000 series software and operating systems. Not a 180 (for NOS/VE) system,
nor an implementation of the 7600 architecture, but I assume you're not dealing with
peripheral processor code anyway. DtCyber is open source; a fork of it has been running
the PLATO system for over 10 years now. Copies of NOS are also openly available (by
permission of the owners, not bootleg copies).
paul
1:14 p.m.
On 8/2/21 12:19 PM, Paul Koning via cctalk wrote:
Some might argue with you about that. PL/M was done in Fortran IV.
bill
On Aug 2, 2021, at 11:11 AM, James Liu via cctech
<cctech at classiccmp.org> wrote:
Thanks for feedback and offers to assist. I received the tape from
one of the maintainers of Schoonship at CERN, and it was probably made
around 1978 at SLAC.
For some background, Tini Veltman developed Schoonship in the 1960's
at CERN on the CDC 6600. My understanding is that he more or less
insisted on coding in assembly since he thought FORTRAN or other high
level languages would just get in the way and slow things down.
Depending on what he was trying to do that may well be a valid assessment. CDC Fortran
was known to be pretty good, but Fortran is not the obvious answer for implementing
interpreters or other language processors, which this sounds like.
1:16 p.m.
On Aug 2, 2021, at 4:14 PM, Bill Gunshannon via cctalk
<cctalk at classiccmp.org> wrote:
On 8/2/21 12:19 PM, Paul Koning via cctalk wrote:
Some might argue with you about that. PL/M was done in Fortran IV.
Interesting. So was IBM Fortran H, if I remember right. And I talked to a DEC engineer
who built an expression parser in COBOL. Still, these are not the usual case.
paul
On Aug 2,
2021, at 11:11 AM, James Liu via cctech <cctech at classiccmp.org> wrote:
Thanks for feedback and offers to assist. I received the tape from
one of the maintainers of Schoonship at CERN, and it was probably made
around 1978 at SLAC.
For some background, Tini Veltman developed Schoonship in the 1960's
at CERN on the CDC 6600. My understanding is that he more or less
insisted on coding in assembly since he thought FORTRAN or other high
level languages would just get in the way and slow things down.
Depending on what
he was trying to do that may well be a valid assessment. CDC Fortran was known to be
pretty good, but Fortran is not the obvious answer for implementing interpreters or other
language processors, which this sounds like. 
1:42 p.m.
On Mon, 2 Aug 2021, Bill Gunshannon via cctalk wrote:
Some might argue with you about that. PL/M was done
in Fortran IV.
A REAL programmer can write a FORTRAN program in any language.
A REAL programmer can write any program in FORTRAN. (although, it is
often the wrong tool for the job, possibly resulting in too much work and
poorer performance.)
3:48 p.m.
On 8/2/21 4:42 PM, Fred Cisin wrote:
On Mon, 2 Aug 2021, Bill Gunshannon via cctalk wrote:
I don't remember if it was Ryan-McFarland or an early MicroFocus but
"back in the day" there was a COBOL compiler written in COBOL.
bill
Some might argue with you about that.? PL/M was
done in Fortran IV.
A REAL programmer can write a FORTRAN program in any language.
A REAL programmer can write any program in FORTRAN.? (although, it is
often the wrong tool for the job, possibly resulting in too much work
and poorer performance.)
4:07 p.m.
New subject: Compilers and languages (Was: Help reading a 9 track tape
>> Some might argue with you about that.? PL/M
was done in Fortran IV.
> A REAL programmer can write a FORTRAN program in any language.
> A REAL programmer can write any program in FORTRAN.? (although, it is
> often the wrong tool for the job, possibly resulting in too much work and
> poorer performance.)
On Mon, 2 Aug 2021, Bill Gunshannon wrote:
I don't remember if it was Ryan-McFarland or an
early MicroFocus but
"back in the day" there was a COBOL compiler written in COBOL.
Not surprising.
One of the rites of passage (not necessarily the only one) in "computer
science" education is that every grad student invents a new language, and
writes a compiler. The compiler is not considered finished until the
current iteration of that compiler was written in that language and
compiled by that iteration of the compiler.
One of my heresies is that I believe that each language has some things
that it does well, and some not so well.
Certainly it is usually, and should be, possible with a "general purpose"
language, but it would seem that it would make sense to use a language
appropriate for the task.
IS the specialty of the language WRITING COMPILERS? If not, it would seem
that a better compiler for that language would be written in a language
best suited for writing compilers (strong string/text handling and
parsing, suitable tree structures, pattern matching, and optimization,for
example). But, it seems that the specialties of languages and compilers
are compromised for the sake of writing a compiler for writing compilers.
"The language/compiler that I created is SO versatile that the compiler is
written in that language and compiled with that compiler." Good. But
does that mean that the language was optimized for THAT, instead of the
specialty for which it was intended?
--
Grumpy Ol' Fred cisin at xenosoft.com
6 p.m.
New subject: Compilers and languages (Was: Help reading a 9 track tape
On Mon, Aug 2, 2021 at 6:07 PM Fred Cisin via cctalk
<cctalk at classiccmp.org> wrote:
One of the rites of passage (not necessarily the only
one) in "computer
science" education is that every grad student invents a new language, and
writes a compiler. The compiler is not considered finished until the
current iteration of that compiler was written in that language and
compiled by that iteration of the compiler.
It's an interesting language classification as to whether the primary
/ reference implementation of the language is written in itself or
not. For example, the primary Python implementation is CPython written
primarily in C, and Java is primarily C++ (certainly both have
substantial libraries that are written in the language however, and
there exist implementations of both that are written in themselves I
believe like PyPy for Python).
For languages that aren't written in themselves it means that some of
the core language developers may primarily be C/C++ programmers which
might have some impact on the language's design and/or implementation.
Another interesting question is whether the currently shipping version
of a language written in itself was compiled using the same version of
itself or the previous version. I recall HP compilers generally being
built with the previous version (at least the last time I looked which
was probably in another century).
3 Aug
3 Aug
1:33 a.m.
New subject: Compilers and languages (Was: Help reading a 9 track tape
m?n 2021-08-02 klockan 20:00 -0500 skrev Gavin Scott via cctalk:
Another interesting question is whether the currently shipping
version
of a language written in itself was compiled using the same version
of
itself or the previous version. I recall HP compilers generally being
built with the previous version (at least the last time I looked
which
was probably in another century).
GNAT itself was written in Ada from the beginning, though the backend
is part of gcc so partly rewritten to support some Ada constructs
(which also benefitted C++).
From the beginning I believe they used the Alsys
compiler until
GNAT was able to compile itself.
7:04 a.m.
New subject: Compilers and languages (Was: Help reading a 9 track tape
Recompiling Forth was always such a trivial process, there was no reason to not recompile
itself using itself. It was also a good check of the output. One could compare the output
and check any differences to ensure that they were intended. One could run it twice again
as a check as well.
It wouldn't always ensure that it had no errors but would validate that only the
intended changes were there. Some of the early Forths had bugs in some of the math
operations.
I recall reading about such errors in the groups and recompiling the version I had to fix
such errors.
Dwight
________________________________
From: cctalk <cctalk-bounces at classiccmp.org> on behalf of Stefan Skoglund via
cctalk <cctalk at classiccmp.org>
Sent: Tuesday, August 3, 2021 1:33 AM
To: Gavin Scott <gavin at learn.bio>; General Discussion: On-Topic and Off-Topic
Posts <cctalk at classiccmp.org>; Fred Cisin <cisin at xenosoft.com>
Subject: Re: Compilers and languages (Was: Help reading a 9 track tape
m?n 2021-08-02 klockan 20:00 -0500 skrev Gavin Scott via cctalk:
Another interesting question is whether the currently shipping
version
of a language written in itself was compiled using the same version
of
itself or the previous version. I recall HP compilers generally being
built with the previous version (at least the last time I looked
which
was probably in another century).
GNAT itself was written in Ada from the beginning, though the backend
is part of gcc so partly rewritten to support some Ada constructs
(which also benefitted C++).
From the beginning I believe they used the Alsys
compiler until
GNAT was able to compile itself.
9:46 a.m.
New subject: Compilers and languages (Was: Help reading a 9 track tape
On 2021-08-02 5:07 p.m., Fred Cisin via cctalk wrote:
IS the specialty of the language WRITING COMPILERS??
If not, it would
seem that a better compiler for that language would be written in a
language best suited for writing compilers (strong string/text handling
and parsing, suitable tree structures, pattern matching, and
optimization,for example).? But, it seems that the specialties of
languages and compilers are compromised for the sake of writing a
compiler for writing compilers.
How many languages are defined to be simple to
parse or compile.
Recursive decent parses programs nicely,but does not generate a 'correct'
parse tree with inner nodes evaluated 1st.
How about being able to bootstrap as important feature.
Simple is good too. With object oriented programming, I have no idea
just what is done at a low level.
--
Grumpy Ol' Fred???????????? cisin at xenosoft.com
Hardware makes software interesting, or is it the other way around?
With C being developed on a PDP 11, you had no decimal operations,
but IBM had PL/I that did. Every thing was binary floating point
since then, until the latest standard of floating point for
hardware and software came out. Decimal is BACK Now things are more
confusing than ever with operating systems changing CPU's with the
latest marketing gimmick.
Ben.
11:44 a.m.
New subject: Compilers and languages (Was: Help reading a 9 track tape
On 8/3/21 9:46 AM, ben via cctalk wrote:
Hardware makes software interesting, or is it the
other way around?
With C being developed on a PDP 11, you had no decimal operations,
but IBM had PL/I that did. Every thing was binary floating point
since then, until the latest standard of floating point for
hardware and software came out. Decimal is BACK Now things are more
confusing than ever with operating systems changing CPU's with the
latest marketing gimmick.
You don't need decimal hardware to do decimal arithmetic. CDC 6000 COBOL
killed IBM S/360 COBOL, even though the latter had hardware decimal
features and the former did not--the big CDC iron was never really sold
as a COBOL cruncher, even though it did quite well at it.
Using numbers in their 6-bit display code representation (33->44 octal),
it's a simple matter to perform 10 digit decimal addition and
subtraction in just a few instructions. I'll leave it as an exercise
to those who are curious (I'll give a hint that octal 25 25 25 25...
plays a part).
Also note that display "0' = 33 octal and display "9" = 44 octal, so
that nines' complement of a display number is the same as the ones'
complement, so subtraction follows quite naturally.
The CDC 6000 has only one addressing granularity--60 bit word. There's
no CPU hardware for handling bytes (6 or 8 bit). Yet character
manipulation isn't very difficult at all.
The wonders of RISC. Do a few things, but do them quickly.
--Chuck
11:58 a.m.
New subject: Compilers and languages (Was: Help reading a 9 track tape
On Aug 3, 2021, at 2:44 PM, Chuck Guzis via cctalk
<cctalk at classiccmp.org> wrote:
On 8/3/21 9:46 AM, ben via cctalk wrote:
Similarly, think of all the machines that did floating point arithmetic without benefit of
floating point hardware. Or integer division without a divide instruction.
Hardware makes software interesting, or is it the
other way around?
With C being developed on a PDP 11, you had no decimal operations,
but IBM had PL/I that did. Every thing was binary floating point
since then, until the latest standard of floating point for
hardware and software came out. Decimal is BACK Now things are more
confusing than ever with operating systems changing CPU's with the
latest marketing gimmick.
You don't need decimal hardware to do decimal arithmetic. CDC 6000 COBOL
killed IBM S/360 COBOL, even though the latter had hardware decimal
features and the former did not--the big CDC iron was never really sold
as a COBOL cruncher, even though it did quite well at it. Using numbers in their 6-bit display code
representation (33->44 octal),
it's a simple matter to perform 10 digit decimal addition and
subtraction in just a few instructions. I'll leave it as an exercise
to those who are curious (I'll give a hint that octal 25 25 25 25...
plays a part).
Also note that display "0' = 33 octal and display "9" = 44 octal, so
that nines' complement of a display number is the same as the ones'
complement, so subtraction follows quite naturally.
I didn't realize that. Interesting. Probably a coincidence, but one wonders.
The CDC 6000 has only one addressing granularity--60
bit word. There's
no CPU hardware for handling bytes (6 or 8 bit). Yet character
manipulation isn't very difficult at all.
Mostly true; some machines had the "compare-move unit" which would do what it
says -- move or compare string of 6-bit characters". But nothing fancier.
The wonders of RISC. Do a few things, but do them
quickly.
One of the classic bits of character magic without character instructions is the famous
"wod" library function -- convert a 60 bit integer to its 20 digit octal
representation, in two words of 10 6-bit display code characters each (by C. R. Willis, U.
of Minnesota). 35 lines of straight code, no loops.
paul
12:28 p.m.
New subject: Compilers and languages (Was: Help reading a 9 track tape
On 8/3/21 11:58 AM, Paul Koning wrote:
Mostly true; some machines had the "compare-move
unit" which would do what it says -- move or compare string of 6-bit
characters". But nothing fancier.
I think the CMU arrived with the CYBER 7x line--I don't recall seeing a
6400 with one. Of course, you couldn't get it on the Cyber 74 or 76.
The CMU appropriated the no-op opcode (46xxx), which was likely safe
because it always assembled by COMPASS as 46000. Before the CYBER 170,
you could devise a test for a CMU by coding a CMU move in the first two
parcels of a word, followed by a jump in the lower 30 bits (I'm glossing
over details a bit). If the CMU existed, the jump wouldn't be taken.
This got bollixed up in the 170 where anything but a 46000 on the
non-CMU systems would cause an illegal instruction fault. Broke some
code, it did.
NOS used it in the CMTR storage move routine, if available.
One of my favorite 6000 bits of code was the register save and restore
routines (not using CEJ). It was a favorite interview question for
those job seekers claiming to be proficient in COMPASS.
--Chuck
2 Aug
2 Aug
1:47 p.m.
Depending on
what he was trying to do that may well be a valid
assessment. CDC Fortran was
known to be pretty good, but Fortran is not
the obvious answer for implementing interpreters or other language
processors, which this sounds like.
bill
Dave
3:50 p.m.
On 8/2/21 4:47 PM, Dave Wade G4UGM via cctalk wrote:
Some might argue with you about that. PL/M was done in Fortran IV.
I will argue with that. If you wanted code that was pretty portable you used FORTRAN (or
COBOL if you had masochistic tendencies).
You were almost certain to be able to find a FORTRAN compiler for most any machine.
"We" wrote X.25 networking software in FORTRAN 77 because every machine sold to
a UK university had to have FORTRAN 77.
Salford University even wrote a FORTRAN 77 compiler!. In the UK University machines had
to come with 10 years of hardware and software support.
Salford originally had an ICL1900 which ICL actually replaced with a 2900 because it
was so old and they ran out of spares but they would not upgrade the software so we/they
were stuck with FORTRAN 66 under DME (1900 emulation)
As there was no money for upgrades from ICL but there was research money Salford wrote a
FORTRAN77 compiler for ICL 1900.
It was intended to be a stop-gap, to be discarded when the ICL was replaced with PR1ME.
However the PR1ME was benchmarked with Fortran 66.
When Pr1me Fortran 77 was delivered its performance was "pants" so the
"stop gap" ICL compiler was ported to PR1ME...
.. later it was ported to MSDOS... More info here
https://www.silverfrost.com/53/ftn77_personal_edition.aspx
Smart Prime sites had that Salford Compiler you were talking about. :-)
bill
Depending
on what he was trying to do that may well be a valid
assessment. CDC Fortran was
known to be pretty good, but Fortran is not
the obvious answer for implementing interpreters or other language
processors, which this sounds like.
bill
Dave
3 Aug
3 Aug
1:31 p.m.
It was intended to be a stop-gap, to be discarded when
the ICL was
replaced with PR1ME. However the PR1ME was benchmarked with Fortran 66.
When Pr1me Fortran 77 was delivered its performance was "pants" so the
"stop gap" ICL compiler was ported to PR1ME...
Wish we could find that Prime compiler. I think there were one or
two others, as well.
De
1:51 p.m.
-----Original Message-----
From: cctalk <cctalk-bounces at classiccmp.org> On Behalf Of Dennis Boone
via cctalk
Sent: 03 August 2021 21:31
To: cctalk at classiccmp.org
Subject: Re: Help reading a 9 track tape
Well you could ask Silverfrost who now own it. I think a lot of Salford
Pr1me software was lost.
I wish I could find the X.25 software we wrote...
It was intended to be a stop-gap, to be discarded
when the ICL was >
replaced with PR1ME. However the PR1ME was benchmarked with
Fortran
66.
When Pr1me Fortran 77 was delivered its
performance was "pants" so the
"stop gap" ICL compiler was ported to PR1ME...
Wish we could find that Prime compiler. I think there were one or two
others, as well.
De
Dave
1:59 p.m.
Well you could ask Silverfrost who now own it. I
think a lot of Salford
Pr1me software was lost.
Vague memory suggests that someone did, and that they don't have it any
more. When I asked Rob Jung, ex-Primate, if he still had the Prime
version of his ARJ compressor, he didn't have that either. So many
ex-things...
There was a 2550 on ebay some years back that came from Salford, and I
had hoped that someone would get it running so we could see if anything
interesting was on its disks, but it dropped out of sight.
I wish I could find the X.25 software we wrote...
That'd be interesting too. At least we have the Prime X.25.
De
4:18 p.m.
On 8/3/21 4:51 PM, Dave Wade G4UGM via cctalk wrote:
A lot of third-party software that ran on Pr1me has been lost.
EDv Editor was nice. Written in Fortran. A really good version
of APL. The best and most complete version of The Software Tools
Virtual Operating System from GA Tech. And others I can not recall
the names of at the moment. When I was doing Pr1mes we had all of
it. I even did a port of The UNaXcess BBS system as an interface
to USENET.
People have talked about porting other old OSes to modern hardware
if the sources hadn't been lost. I would love to have a shot at
porting Primos to run on x86-64 or even ARM.
bill
-----Original
Message-----
From: cctalk <cctalk-bounces at classiccmp.org> On Behalf Of Dennis Boone
via cctalk
Sent: 03 August 2021 21:31
To: cctalk at classiccmp.org
Subject: Re: Help reading a 9 track tape
Well you could ask Silverfrost who now own it. I think a lot of Salford
Pr1me software was lost.
I wish I could find the X.25 software we wrote...
It was intended to be a stop-gap, to be discarded
when the ICL was >
replaced with PR1ME. However the PR1ME was benchmarked with
Fortran
66.
When Pr1me Fortran 77 was delivered its
performance was "pants" so the
"stop gap" ICL compiler was ported to PR1ME...
Wish we could find that Prime compiler. I think there were one or two
others, as well.
2 Aug
2 Aug
5:45 p.m.
On 8/2/21 8:11 AM, James Liu via cctech wrote:
Thanks for feedback and offers to assist.
Happy to contirubte.
For some background, Tini Veltman developed Schoonship
in the 1960's
at CERN on the CDC 6600. My understanding is that he more or less
insisted on coding in assembly since he thought FORTRAN or other high
level languages would just get in the way and slow things down. The
code was maintained by Veltman and Strubbe well into the 1970's, but
its future was held back by being so closely tied to CDC hardware.
Which CDC FORTRAN? RUN, maybe--but FTN extended was pretty darned good
in optimizing and scheduling instructions. A lot of work went into that one.
As a matter of fact, when we COMPASS scriveners came up against a nasty
loop that we wanted to optimize for the 6600, one approach was to code
it in FORTRAN to see what the compiler would do with it and then work
from there. Some of the optimizations were quite
startling,
particularly with the "UO" option selected.
If you've never written and hand-optimized 6600 code, it could be a
daunting task.
Did you know that parts of FTN are written in FTN? I recall the
COMMON/EQUIVALENCE processor written as a mess of assigned GOTO
statements (state machine) and being utterly bereft of commentary."Don't
touch it--you might break something!"
FORTRAN was CDC's bread-and-butter language for years, as it was the
universal choice of number-crunchers everywhere during the 60s through
80s. And CDC excelled at number-crunching.
My .02 for what it's worth.
--Chuck
5:53 p.m.
On Aug 2, 2021, at 8:45 PM, Chuck Guzis via cctech
<cctech at classiccmp.org> wrote:
On 8/2/21 8:11 AM, James Liu via cctech wrote:
He did say "in the 1960s" so it may have been an early one without the high
quality optimizations that grew over time.
Thanks for feedback and offers to assist.
Happy to contirubte.
For some background, Tini Veltman developed
Schoonship in the 1960's
at CERN on the CDC 6600. My understanding is that he more or less
insisted on coding in assembly since he thought FORTRAN or other high
level languages would just get in the way and slow things down. The
code was maintained by Veltman and Strubbe well into the 1970's, but
its future was held back by being so closely tied to CDC hardware.
Which CDC FORTRAN? RUN, maybe--but FTN extended was pretty darned good
in optimizing and scheduling instructions. A lot of work went into that one. As a matter of fact, when we COMPASS scriveners came
up against a nasty
loop that we wanted to optimize for the 6600, one approach was to code
it in FORTRAN to see what the compiler would do with it and then work
from there. Some of the optimizations were quite startling,
particularly with the "UO" option selected.
If you've never written and hand-optimized 6600 code, it could be a
daunting task.
So I learned, having to do it on a 6400 -- which is quite a lot easier. But I learned a
lot from reading the OS source code, stuff like the analog of memcpy that used both the
boolean and shift units for transfer operations so it could do two of them one cycle
apart.
paul
6:10 p.m.
On 8/2/21 5:53 PM, Paul Koning wrote:
He did say "in the 1960s" so it may have
been an early one without the high quality optimizations that grew over time.
FTN was spawned during the 1960s. Bitsavers has the GIM from 1966:
http://bitsavers.org/pdf/cdc/cyber/lang/fortran/60176400_FTN_Extd_Inf_Oct66…
RUN was sort of a cheap-and-quick compiler. CDC kept around both, as
FTN compilation time was considerably longer (for obvious reasons).
RUN started out to be the do-everything compiler. You could stack decks
of FORTRAN and COMPASS in the same job and RUN would invoke the
assembler as needed and invoke the loader load-and-go at the end. The
JCL for that was simply "RUN."
--Chuck
4 Aug
4 Aug
7:25 a.m.
James, I am located in Madison WI. I would need to fire up my SCSI 9
Track drive (software on Linux) and test it as I have not used in a
couple of years, but I have done recovery of old tapes from this era
before, and have a primitive setup for "baking" tapes before trying to
read them.
Assuming my HP 9 track is still happy, I can produce AWS format tape
images, raw block files and extract individual files (translated into
ASCII if that is desirable).
I don't remember exactly the time period when tape coatings were such
that reading them without "baking" them is very risky - this might be
before that era - Al Kossow would probably know - so I'd likely "bake"
it first before trying to read it.
Given the name "IEBUPDTX" this tape was certainly intended to be used on
a 360 or 370, as you described below (IBM has a utility IEBUPDTE).
So, if you haven't found somebody to read this thing yet, feel free to
contact me.
JRJ
On 8/2/2021 10:11 AM, James Liu via cctech wrote:
Thanks for feedback and offers to assist. I received
the tape from
one of the maintainers of Schoonship at CERN, and it was probably made
around 1978 at SLAC.
For some background, Tini Veltman developed Schoonship in the 1960's
at CERN on the CDC 6600. My understanding is that he more or less
insisted on coding in assembly since he thought FORTRAN or other high
level languages would just get in the way and slow things down. The
code was maintained by Veltman and Strubbe well into the 1970's, but
its future was held back by being so closely tied to CDC hardware.
In the mid 1970's, Strubbe began a conversion of Schoonschip to IBM
S/360 and S/370. It was sort of a curious technique, as far as I
gathered. The idea was to first translate CDC COMPASS source to an
intermediate PL/I like language. But then, instead of using the IBM
PL/I compiler, a bunch of macros were developed to implement the PL/I
like language in IBM assembly. This conversion was never fully
completed for reasons unknown to me.
Later on, when Tini joined the University of Michigan (that's where
I'm located), he realized that Schoonschip needed to be updated. But
the update was ... instead of CDC assembly he decided on m68k
assembly. (At this time, in the early 1980's, C probably would have
been the natural language of choice.) Moreover, he insisted on
developing his own toolchain (assembler, linker, etc). This was
before my time at Michigan, but basically he ported Schoonschip to
just about all the m68k machines of that era (Sun, Atari, Amiga, Mac,
NeXT, and others I am not familiar with). We have a pretty good
collection of m68k code
(http://www-personal.umich.edu/~williams/Vsys/index.html), but nothing
earlier.
Getting back to the tape, I'm pretty sure it has Strubbe's PL/I like
code as it is an archive of the PL/I conversion. It may also have CDC
source, but that is less obvious until we can see the contents. The
CDC source is historically the most relevant, and I am hoping it
exists on the tape.
- jim
1:11 p.m.
Paul Pierce <prp at teleport.com> read some 7-track and 9-track tapes for
me about twenty years ago. He was in Portland, OR at the time. His
"lab" was on the east side of the Willamette river, so maybe it didn't
get burned down.
I don't know whether he still has a setup to read tapes. His software
would read blocks forward and backward, including the parity frames,
and make corrections.
Van Snyder
On Wed, 2021-08-04 at 09:25 -0500, Jay Jaeger via cctech wrote:
James, I am located in Madison WI. I would need to
fire up my SCSI 9
Track drive (software on Linux) and test it as I have not used in a
couple of years, but I have done recovery of old tapes from this era
before, and have a primitive setup for "baking" tapes before trying
to read them.
Assuming my HP 9 track is still happy, I can produce AWS format tape
images, raw block files and extract individual files (translated into
ASCII if that is desirable).
I don't remember exactly the time period when tape coatings were such
that reading them without "baking" them is very risky - this might be
before that era - Al Kossow would probably know - so I'd likely
"bake" it first before trying to read it.
Given the name "IEBUPDTX" this tape was certainly intended to be used
on a 360 or 370, as you described below (IBM has a utility IEBUPDTE).
So, if you haven't found somebody to read this thing yet, feel free
to contact me.
JRJ
On 8/2/2021 10:11 AM, James Liu via cctech wrote:
> Thanks for feedback and offers to assist. I received the tape
> fromone of the maintainers of Schoonship at CERN, and it was
> probably madearound 1978 at SLAC.
> For some background, Tini Veltman developed Schoonship in the
> 1960'sat CERN on the CDC 6600. My understanding is that he more or
> lessinsisted on coding in assembly since he thought FORTRAN or
> other highlevel languages would just get in the way and slow things
> down. Thecode was maintained by Veltman and Strubbe well into the
> 1970's, butits future was held back by being so closely tied to CDC
> hardware.
> In the mid 1970's, Strubbe began a conversion of Schoonschip to
> IBMS/360 and S/370. It was sort of a curious technique, as far as
> Igathered. The idea was to first translate CDC COMPASS source to
> anintermediate PL/I like language. But then, instead of using the
> IBMPL/I compiler, a bunch of macros were developed to implement the
> PL/Ilike language in IBM assembly. This conversion was never
> fullycompleted for reasons unknown to me.
> Later on, when Tini joined the University of Michigan (that's
> whereI'm located), he realized that Schoonschip needed to be
> updated. Butthe update was ... instead of CDC assembly he decided
> on m68kassembly. (At this time, in the early 1980's, C probably
> would havebeen the natural language of choice.) Moreover, he
> insisted ondeveloping his own toolchain (assembler, linker,
> etc). This wasbefore my time at Michigan, but basically he ported
> Schoonschip tojust about all the m68k machines of that era (Sun,
> Atari, Amiga, Mac,NeXT, and others I am not familiar with). We
> have a pretty goodcollection of m68k code(
> http://www-personal.umich.edu/~williams/Vsys/index.html), but
> nothingearlier.
> Getting back to the tape, I'm pretty sure it has Strubbe's PL/I
> likecode as it is an archive of the PL/I conversion. It may also
> have CDCsource, but that is less obvious until we can see the
> contents. TheCDC source is historically the most relevant, and I
> am hoping itexists on the tape.
> - jim
2:14 p.m.
Whoever does it, I have a few suggestions when it comes to 40+ year old
tapes.
1) Bake the thing at 58C for a day or two. It might just prevent you
from staring at a tape stuck to the head and a pile of
brown dust at the
bottom of the drive. (Before you start, make note of the brand
and type
of tape; some are much worse than others). If you're uncertain, check
back here and I'll tell you what I know.
2) If you're determined to use a SCSI drive, initially turn off
automatic retries (shoe-shining). With sticky tape, you can do a lot
of damage to the tape. Retries can come later when you're confident
about the condition of the tape.
3) Should the tape turn out to be sticky, don't try to clean it--it
will only foul up the cleaning equipment (I'm assuming a tape cleaning
machine here). Coat the tape with cyclomethicone. At least it won't
stick to anything and you'll get a chance to do a good read.
4) If you have a choice of read speeds, use the lowest speed to start
with. Make sure that you can deal with tape errors.
5) Forget using a streamer--they're just not suited to dealing with
fragile tape.
If you're not equipped to deal with this, don't attempt it. A tape
written 10 years ago, is not the same as one written 40-60 years ago.
The 1980s, in particular, were responsible for some truly wretched
stock. I thank my lucky stars that cellulose acetate never made it as
computer tape base. Curiously, tapes from the 1960s and 70s can be less
of a problem than those from the 80s and 90s.
My .02 for what it's worth.
--Chuck
5 Aug
5 Aug
8:23 a.m.
Some thoughts
On 8/4/2021 4:14 PM, Chuck Guzis via cctech wrote:
Whoever does it, I have a few suggestions when it
comes to 40+ year old
tapes.
1) Bake the thing at 58C for a day or two. It might just prevent you
from staring at a tape stuck to the head and a pile of brown dust at the
bottom of the drive. (Before you start, make note of the brand and type
of tape; some are much worse than others). If you're uncertain, check
back here and I'll tell you what I know.
I have found that generally baking more than 12 hours has not made much
additional difference. I have been baking mine at 120F/50C.
2) If you're determined to use a SCSI drive,
initially turn off
automatic retries (shoe-shining). With sticky tape, you can do a lot
of damage to the tape. Retries can come later when you're confident
about the condition of the tape.
Good idea. Also, if one notices it is sticking or squealing, STOP and
evaluate the situation before letting it go further.
3) Should the tape turn out to be sticky, don't
try to clean it--it
will only foul up the cleaning equipment (I'm assuming a tape cleaning
machine here). Coat the tape with cyclomethicone. At least it won't
stick to anything and you'll get a chance to do a good read.
Folks are also doing that with floppies, though so few of my floppies
have stuck (and those that did didn't have anything that wasn't already
archived earlier file by file rather than image) that I haven't had to
resort to that.
4) If you have a choice of read speeds, use the lowest
speed to start
with. Make sure that you can deal with tape errors.
5) Forget using a streamer--they're just not suited to dealing with
fragile tape.
My HP 88780B is a streamer, but also has a feed side tension arm. I
generally read good tapes end to end without any stopping. I have had
no problems with breaking or stretching tape - in the rare case where a
tape did stick badly to a head even after baking (1980's era tape or two
- they were just awful), the drive stopped immediately when it "overfed"
from the feed side which stopped the drive, just as a
"standard" drive
(two tension arms or vacuum columns) would.
If you're not equipped to deal with this, don't attempt it. A tape
written 10 years ago, is not the same as one written 40-60 years ago.
The 1980s, in particular, were responsible for some truly wretched
stock. I thank my lucky stars that cellulose acetate never made it as
computer tape base. Curiously, tapes from the 1960s and 70s can be less
of a problem than those from the 80s and 90s.
That timeframe has been my experience as well (but I'd add that the
early to mid 1970's tapes have generally been no problem at all),
generally, but I don't think that is curious at all. It was a result of
the coatings used during those latter eras by some manufacturers.
Before that, those coatings were not used. Somewhere I kept a record of
which brands and series I found to be problematic, but I seem to have
lost track of it.
My .02 for what it's worth.
--Chuck
Also, before starting (after baking and cool-down) I unspool maybe 25
feet of tape onto a clean surface to make sure it isn't sticking. If it
does, I let it sit for a few hours, and then bake it again. Have not
had to bake for additional time very often, and in those cases, it ended
up not helping as much as one might like.
JRJ
9:21 a.m.
On 8/5/21 8:23 AM, Jay Jaeger via cctech wrote:
Also, before starting (after baking and cool-down) I unspool maybe 25
feet of tape onto a clean surface to make sure it isn't sticking.? If it
does, I let it sit for a few hours, and then bake it again.? Have not
had to bake for additional time very often, and in those cases, it ended
up not helping as much as one might like.
...and think twice before you attempt recovering data from 80's Wabash
tape (or floppies). Pure agony.
--Chuck
11:20 a.m.
On 8/4/21 4:14 PM, Chuck Guzis via cctalk wrote:
5) Forget using a streamer--they're just not
suited to dealing with
fragile tape.
I may differ on this one.? CDC Keystone (92181 and 92185)
drives are really gentle on tape.
They have air bearing "hubs" that the tape wraps over, and
nothing but the tape head and cleaner blades touch the oxide
side of the tape.? But, they can still suffer from tape
sticking to the heads.
I agree that some other streamers like Digi-Data were pretty
horrible contraptions.
Jon
11:55 a.m.
On 8/5/21 11:20 AM, Jon Elson via cctalk wrote:
They have air bearing "hubs" that the tape
wraps over, and nothing but
the tape head and cleaner blades touch the oxide side of the tape.? But,
they can still suffer from tape sticking to the heads.
...which is where the tape ends up sticking, no matter the drive.
--Chuck
12:04 p.m.
On Aug 5, 2021, at 2:55 PM, Chuck Guzis via cctalk
<cctalk at classiccmp.org> wrote:
On 8/5/21 11:20 AM, Jon Elson via cctalk wrote:
Does anything other than (real) DECtape arrange for an air cushion between tape and head?
Would it be possible to tweak a tape drive -- streaming or otherwise -- to do that?
paul
They have air bearing "hubs" that the
tape wraps over, and nothing but
the tape head and cleaner blades touch the oxide side of the tape. But,
they can still suffer from tape sticking to the heads.
...which is where the tape ends up sticking, no matter the drive.
--Chuck
5:39 a.m.
I know Paul well (we were contemporaries at U. WI). He does not do that
very often. He did not indicate any issue with a fire at the building
that contains his collection when I last spoke with him.
He does not actually read "blocks". He reads the tape in an *analog*
fashion, and then processes the results with software. That is how he
recovered the IBM 1410 system tapes and diagnostics, for example.
To be honest, I doubt that this content would be such that he would be
likely to volunteer.
JRJ
On 8/4/2021 3:11 PM, Van Snyder wrote:
Paul Pierce <prp at teleport.com <mailto:prp at
teleport.com>> read some
7-track and 9-track tapes for me about twenty years ago. He was in
Portland, OR at the time. His "lab" was on the east side of the
Willamette river, so maybe it didn't get burned down.
I don't know whether he still has a setup to read tapes. His software
would read blocks forward and backward, including the parity frames, and
make corrections.
Van Snyder
On Wed, 2021-08-04 at 09:25 -0500, Jay Jaeger via cctech wrote:
> James, I am located in Madison WI. I would need to fire up my SCSI 9
> Track drive (software on Linux) and test it as I have not used in a
> couple of years, but I have done recovery of old tapes from this era
> before, and have a primitive setup for "baking" tapes before trying to
> read them.
>
> Assuming my HP 9 track is still happy, I can produce AWS format tape
> images, raw block files and extract individual files (translated into
> ASCII if that is desirable).
>
> I don't remember exactly the time period when tape coatings were such
> that reading them without "baking" them is very risky - this might be
> before that era - Al Kossow would probably know - so I'd likely "bake"
> it first before trying to read it.
>
> Given the name "IEBUPDTX" this tape was certainly intended to be used on
> a 360 or 370, as you described below (IBM has a utility IEBUPDTE).
>
> So, if you haven't found somebody to read this thing yet, feel free to
> contact me.
>
> JRJ
>
> On 8/2/2021 10:11 AM, James Liu via cctech wrote:
>> Thanks for feedback and offers to assist. I received the tape from
>> one of the maintainers of Schoonship at CERN, and it was probably made
>> around 1978 at SLAC.
>>
>> For some background, Tini Veltman developed Schoonship in the 1960's
>> at CERN on the CDC 6600. My understanding is that he more or less
>> insisted on coding in assembly since he thought FORTRAN or other high
>> level languages would just get in the way and slow things down. The
>> code was maintained by Veltman and Strubbe well into the 1970's, but
>> its future was held back by being so closely tied to CDC hardware.
>>
>> In the mid 1970's, Strubbe began a conversion of Schoonschip to IBM
>> S/360 and S/370. It was sort of a curious technique, as far as I
>> gathered. The idea was to first translate CDC COMPASS source to an
>> intermediate PL/I like language. But then, instead of using the IBM
>> PL/I compiler, a bunch of macros were developed to implement the PL/I
>> like language in IBM assembly. This conversion was never fully
>> completed for reasons unknown to me.
>>
>> Later on, when Tini joined the University of Michigan (that's where
>> I'm located), he realized that Schoonschip needed to be updated. But
>> the update was ... instead of CDC assembly he decided on m68k
>> assembly. (At this time, in the early 1980's, C probably would have
>> been the natural language of choice.) Moreover, he insisted on
>> developing his own toolchain (assembler, linker, etc). This was
>> before my time at Michigan, but basically he ported Schoonschip to
>> just about all the m68k machines of that era (Sun, Atari, Amiga, Mac,
>> NeXT, and others I am not familiar with). We have a pretty good
>> collection of m68k code
>> (
>> http://www-personal.umich.edu/~williams/Vsys/index.html
>> <http://www-personal.umich.edu/~williams/Vsys/index.html>
>> ), but nothing
>> earlier.
>>
>> Getting back to the tape, I'm pretty sure it has Strubbe's PL/I like
>> code as it is an archive of the PL/I conversion. It may also have CDC
>> source, but that is less obvious until we can see the contents. The
>> CDC source is historically the most relevant, and I am hoping it
>> exists on the tape.
>>
>> - jim
>>
6:14 a.m.
Perhaps the work could be split up: reading the track waveforms is the one step that
requires special hardware (and the skill to handle the tape with minimal damage). Given a
collection of recovered waveforms, the data recovery can then be done by anyone.
paul
On Aug 5, 2021, at 8:39 AM, Jay Jaeger via cctech
<cctech at classiccmp.org> wrote:
I know Paul well (we were contemporaries at U. WI). He does not do that very often. He
did not indicate any issue with a fire at the building that contains his collection when I
last spoke with him.
He does not actually read "blocks". He reads the tape in an *analog* fashion,
and then processes the results with software. That is how he recovered the IBM 1410
system tapes and diagnostics, for example.
To be honest, I doubt that this content would be such that he would be likely to
volunteer.
JRJ
On 8/4/2021 3:11 PM, Van Snyder wrote:
> Paul Pierce <prp at teleport.com <mailto:prp at teleport.com>> read some
7-track and 9-track tapes for me about twenty years ago. He was in Portland, OR at the
time. His "lab" was on the east side of the Willamette river, so maybe it
didn't get burned down.
> I don't know whether he still has a setup to read tapes. His software would read
blocks forward and backward, including the parity frames, and make corrections.
> Van Snyder
> On Wed, 2021-08-04 at 09:25 -0500, Jay Jaeger via cctech wrote:
>> James, I am located in Madison WI. I would need to fire up my SCSI 9
>> Track drive (software on Linux) and test it as I have not used in a
>> couple of years, but I have done recovery of old tapes from this era
>> before, and have a primitive setup for "baking" tapes before trying to
>> read them.
>>
>> Assuming my HP 9 track is still happy, I can produce AWS format tape
>> images, raw block files and extract individual files (translated into
>> ASCII if that is desirable).
>>
>> I don't remember exactly the time period when tape coatings were such
>> that reading them without "baking" them is very risky - this might be
>> before that era - Al Kossow would probably know - so I'd likely
"bake"
>> it first before trying to read it.
>>
>> Given the name "IEBUPDTX" this tape was certainly intended to be used
on
>> a 360 or 370, as you described below (IBM has a utility IEBUPDTE).
>>
>> So, if you haven't found somebody to read this thing yet, feel free to
>> contact me.
>>
>> JRJ
>>
>> On 8/2/2021 10:11 AM, James Liu via cctech wrote:
>>> Thanks for feedback and offers to assist. I received the tape from
>>> one of the maintainers of Schoonship at CERN, and it was probably made
>>> around 1978 at SLAC.
>>>
>>> For some background, Tini Veltman developed Schoonship in the 1960's
>>> at CERN on the CDC 6600. My understanding is that he more or less
>>> insisted on coding in assembly since he thought FORTRAN or other high
>>> level languages would just get in the way and slow things down. The
>>> code was maintained by Veltman and Strubbe well into the 1970's, but
>>> its future was held back by being so closely tied to CDC hardware.
>>>
>>> In the mid 1970's, Strubbe began a conversion of Schoonschip to IBM
>>> S/360 and S/370. It was sort of a curious technique, as far as I
>>> gathered. The idea was to first translate CDC COMPASS source to an
>>> intermediate PL/I like language. But then, instead of using the IBM
>>> PL/I compiler, a bunch of macros were developed to implement the PL/I
>>> like language in IBM assembly. This conversion was never fully
>>> completed for reasons unknown to me.
>>>
>>> Later on, when Tini joined the University of Michigan (that's where
>>> I'm located), he realized that Schoonschip needed to be updated. But
>>> the update was ... instead of CDC assembly he decided on m68k
>>> assembly. (At this time, in the early 1980's, C probably would have
>>> been the natural language of choice.) Moreover, he insisted on
>>> developing his own toolchain (assembler, linker, etc). This was
>>> before my time at Michigan, but basically he ported Schoonschip to
>>> just about all the m68k machines of that era (Sun, Atari, Amiga, Mac,
>>> NeXT, and others I am not familiar with). We have a pretty good
>>> collection of m68k code
>>> (
>>> http://www-personal.umich.edu/~williams/Vsys/index.html
>>> <http://www-personal.umich.edu/~williams/Vsys/index.html>
>>> ), but nothing
>>> earlier.
>>>
>>> Getting back to the tape, I'm pretty sure it has Strubbe's PL/I like
>>> code as it is an archive of the PL/I conversion. It may also have CDC
>>> source, but that is less obvious until we can see the contents. The
>>> CDC source is historically the most relevant, and I am hoping it
>>> exists on the tape.
>>>
>>> - jim
>>>
8:25 a.m.
Yeah, well, the first part is the hard part - setting it all up and
making recording. The second part is more or less trivial, once the
software was done.
One of the 1410 tapes had a persistent parity error - that one I was
able to figure out from knowledge of the machine, instruction set, etc.
JRJ
On 8/5/2021 8:14 AM, Paul Koning wrote:
Perhaps the work could be split up: reading the track
waveforms is the one step that requires special hardware (and the skill to handle the tape
with minimal damage). Given a collection of recovered waveforms, the data recovery can
then be done by anyone.
paul
On Aug 5, 2021, at 8:39 AM, Jay Jaeger via cctech
<cctech at classiccmp.org> wrote:
I know Paul well (we were contemporaries at U. WI). He does not do that very often. He
did not indicate any issue with a fire at the building that contains his collection when I
last spoke with him.
He does not actually read "blocks". He reads the tape in an *analog* fashion,
and then processes the results with software. That is how he recovered the IBM 1410
system tapes and diagnostics, for example.
To be honest, I doubt that this content would be such that he would be likely to
volunteer.
JRJ
On 8/4/2021 3:11 PM, Van Snyder wrote:
> Paul Pierce <prp at teleport.com <mailto:prp at teleport.com>> read some
7-track and 9-track tapes for me about twenty years ago. He was in Portland, OR at the
time. His "lab" was on the east side of the Willamette river, so maybe it
didn't get burned down.
> I don't know whether he still has a setup to read tapes. His software would read
blocks forward and backward, including the parity frames, and make corrections.
> Van Snyder
> On Wed, 2021-08-04 at 09:25 -0500, Jay Jaeger via cctech wrote:
>> James, I am located in Madison WI. I would need to fire up my SCSI 9
>> Track drive (software on Linux) and test it as I have not used in a
>> couple of years, but I have done recovery of old tapes from this era
>> before, and have a primitive setup for "baking" tapes before trying to
>> read them.
>>
>> Assuming my HP 9 track is still happy, I can produce AWS format tape
>> images, raw block files and extract individual files (translated into
>> ASCII if that is desirable).
>>
>> I don't remember exactly the time period when tape coatings were such
>> that reading them without "baking" them is very risky - this might be
>> before that era - Al Kossow would probably know - so I'd likely
"bake"
>> it first before trying to read it.
>>
>> Given the name "IEBUPDTX" this tape was certainly intended to be used
on
>> a 360 or 370, as you described below (IBM has a utility IEBUPDTE).
>>
>> So, if you haven't found somebody to read this thing yet, feel free to
>> contact me.
>>
>> JRJ
>>
>> On 8/2/2021 10:11 AM, James Liu via cctech wrote:
>>> Thanks for feedback and offers to assist. I received the tape from
>>> one of the maintainers of Schoonship at CERN, and it was probably made
>>> around 1978 at SLAC.
>>>
>>> For some background, Tini Veltman developed Schoonship in the 1960's
>>> at CERN on the CDC 6600. My understanding is that he more or less
>>> insisted on coding in assembly since he thought FORTRAN or other high
>>> level languages would just get in the way and slow things down. The
>>> code was maintained by Veltman and Strubbe well into the 1970's, but
>>> its future was held back by being so closely tied to CDC hardware.
>>>
>>> In the mid 1970's, Strubbe began a conversion of Schoonschip to IBM
>>> S/360 and S/370. It was sort of a curious technique, as far as I
>>> gathered. The idea was to first translate CDC COMPASS source to an
>>> intermediate PL/I like language. But then, instead of using the IBM
>>> PL/I compiler, a bunch of macros were developed to implement the PL/I
>>> like language in IBM assembly. This conversion was never fully
>>> completed for reasons unknown to me.
>>>
>>> Later on, when Tini joined the University of Michigan (that's where
>>> I'm located), he realized that Schoonschip needed to be updated. But
>>> the update was ... instead of CDC assembly he decided on m68k
>>> assembly. (At this time, in the early 1980's, C probably would have
>>> been the natural language of choice.) Moreover, he insisted on
>>> developing his own toolchain (assembler, linker, etc). This was
>>> before my time at Michigan, but basically he ported Schoonschip to
>>> just about all the m68k machines of that era (Sun, Atari, Amiga, Mac,
>>> NeXT, and others I am not familiar with). We have a pretty good
>>> collection of m68k code
>>> (
>>> http://www-personal.umich.edu/~williams/Vsys/index.html
>>> <http://www-personal.umich.edu/~williams/Vsys/index.html>
>>> ), but nothing
>>> earlier.
>>>
>>> Getting back to the tape, I'm pretty sure it has Strubbe's PL/I like
>>> code as it is an archive of the PL/I conversion. It may also have CDC
>>> source, but that is less obvious until we can see the contents. The
>>> CDC source is historically the most relevant, and I am hoping it
>>> exists on the tape.
>>>
>>> - jim
>>>
7:28 a.m.
On Wed, Aug 4, 2021 at 10:25 AM Jay Jaeger <cube1 at charter.net> wrote:
James, I am located in Madison WI. I would need to fire up my SCSI 9
Track drive (software on Linux) and test it as I have not used in a
couple of years, but I have done recovery of old tapes from this era
before, and have a primitive setup for "baking" tapes before trying to
read them.
Assuming my HP 9 track is still happy, I can produce AWS format tape
images, raw block files and extract individual files (translated into
ASCII if that is desirable).
I don't remember exactly the time period when tape coatings were such
that reading them without "baking" them is very risky - this might be
before that era - Al Kossow would probably know - so I'd likely "bake"
it first before trying to read it.
Thanks, Jay (and others) for offering your assistance. I've asked
Chuck to have a look at the tape, and we'll see how it goes.
Given the name "IEBUPDTX" this tape was
certainly intended to be used on
a 360 or 370, as you described below (IBM has a utility IEBUPDTE).
I can't say I know much about IBM systems, but apparently Strubbe, who
was doing the port and who I got the tape from, was no fan of
IEBUPDTE. I wonder if IEBUPDTX was his attempt at an improvement.
As for CDC Schoonschip, old reports indicate that it consisted of
about 25k lines of COMPASS code along with 1k lines of FORTRAN for
handling I/O. At the time (1960's), Tini may have been right about
making the most of the hardware, especially memory limitations, by
coding in assembly. For example, I think Schoonschip packed a lot of
data into bitfields which FORTRAN may not be so adept at handling.
However I think he hung on to this sort of "high level languages
cripple the computer" mentality for too long. Then again, he was
quite the character.
Stephen Wolfram has some interesting musings on Schoonschip at
https://writings.stephenwolfram.com/2021/01/tini-veltman-1931-2021-from-ass…
So, if you haven't found somebody to read this
thing yet, feel free to
contact me.
JRJ
- jim
--
James T. Liu, Professor of Physics
3409 Randall Laboratory, 450 Church Street, Ann Arbor, MI 48109-1040
Tel: 734 763-4314 Fax: 734 763-2213 Email: jimliu at umich.edu
8:27 a.m.
On 8/5/2021 9:28 AM, James Liu wrote:
Sounds likely.
On Wed, Aug 4, 2021 at 10:25 AM Jay Jaeger <cube1
at charter.net> wrote:
Thanks, Jay (and others) for offering your assistance. I've asked
Chuck to have a look at the tape, and we'll see how it goes.
Great!
Given the name
"IEBUPDTX" this tape was certainly intended to be used on
a 360 or 370, as you described below (IBM has a utility IEBUPDTE).
I can't say I know much about IBM systems, but apparently Strubbe, who
was doing the port and who I got the tape from, was no fan of
IEBUPDTE. I wonder if IEBUPDTX was his attempt at an improvement.
- jim
JRJ
1001
days inactive
1004
days old
36 comments
14 participants
participants (14)
-
bfranchuk＠jetnet.ab.ca -
bill.gunshannon＠hotmail.com -
cclist＠sydex.com -
cisin＠xenosoft.com -
cube1＠charter.net -
dave.g4ugm＠gmail.com -
dkelvey＠hotmail.com -
drb＠msu.edu -
elson＠pico-systems.com -
gavin＠learn.bio -
jimliu＠umich.edu -
paulkoning＠comcast.net -
stefan.skoglund＠agj.net -
van.snyder＠sbcglobal.net