10 Nov
2020
10 Nov
'20
11:11 p.m.
I'm currently reviewing a paper about Unix and Linux, and I made the
comment that in the olden days the normal way to build an OS image for
a big computer was from source. Now I've been asked for a reference,
and I can't find one! Can anybody help?
Greg
--
Sent from my desktop computer.
Finger grog(a)lemis.com for PGP public key.
See complete headers for address and phone numbers.
This message is digitally signed. If your Microsoft mail program
reports problems, please read http://lemis.com/broken-MUA
10 Nov
10 Nov
11:38 p.m.
It depends a lot on when.
For pure research V7 / 2BSD / 4BSD that was true. You can give the
install.ms from these releases as a reference. It was a lot more daunting
than today, and often times only bug fixes warranted a recompile. You can
find references in the 2.11BSD patch series to the 'annual recompilation of
the sources' which Steve did and where he'd always find something.
However, after that, everything was binaries. The kernel you got was a
bunch of .o files (even for the V7 ports), though often you had all the
source to the drivers (but not the core of the kernel). I have said files
for Venix, though there it was an extra cost option it seems (I say seems,
since I've not found a price sheet for it from the era, though I have the
disks). DEC's ultrix was binary. Sun's SunOS. All the Unisoft ports to 68k
machines. Sony's NEWS workstations likewise. HP's unix offerings too. Sure,
you could get a source license, sometimes, but they kept those expensive.
IBM and VMS were always binary only (though again, you could buy source if
you had the right amount of $$$ and leverage).
So I'm not sure what old days you were talking about, or which
machines.... The BSD build.sh and/or make world were a bit of an anomaly
imho. Once Linux got distributions the whole notion of building it yourself
faded somewhat.
Warner
On Tue, Nov 10, 2020 at 4:11 PM Greg 'groggy' Lehey <grog(a)lemis.com>
wrote:
I'm currently reviewing a paper about Unix and
Linux, and I made the
comment that in the olden days the normal way to build an OS image for
a big computer was from source. Now I've been asked for a reference,
and I can't find one! Can anybody help?
Greg
--
Sent from my desktop computer.
Finger grog(a)lemis.com for PGP public key.
See complete headers for address and phone numbers.
This message is digitally signed. If your Microsoft mail program
reports problems, please read http://lemis.com/broken-MUA
_______________________________________________
COFF mailing list
COFF(a)minnie.tuhs.org
https://minnie.tuhs.org/cgi-bin/mailman/listinfo/coff
11:45 p.m.
Mumble -- For IBM and DEC in the 60s and early 70s, the manufactures
distributed the (assembler) sources to the OS and we could (and did) build
from source but usually just built parts. By the time of VMS and the
other minis, you tended to link together from modules, although many sites
did have sources (in assembler).
Remember, the target was the manufacturers HW so they were not giving away
much. In the case of IBM, eventually, Amdahl started cloning and they got
a tad more closed, but by that time there were also many mainframe OS
flavors in wild.
That said, I think Burrough's gave away the ESPOL code for their systems,
but I never saw it; so I can not speak definitively there.
Unix was different. Like Burrough's, it was heavily written in a systems
programming language. To my knowledge, the 'concept' or 'porting'
the OS
in it's entirety to a completely new ISA began with UNIX.
On Tue, Nov 10, 2020 at 6:11 PM Greg 'groggy' Lehey <grog(a)lemis.com>
wrote:
I'm currently reviewing a paper about Unix and
Linux, and I made the
comment that in the olden days the normal way to build an OS image for
a big computer was from source. Now I've been asked for a reference,
and I can't find one! Can anybody help?
Greg
--
Sent from my desktop computer.
Finger grog(a)lemis.com for PGP public key.
See complete headers for address and phone numbers.
This message is digitally signed. If your Microsoft mail program
reports problems, please read http://lemis.com/broken-MUA
_______________________________________________
COFF mailing list
COFF(a)minnie.tuhs.org
https://minnie.tuhs.org/cgi-bin/mailman/listinfo/coff
11 Nov
11 Nov
12:06 a.m.
On Tuesday, 10 November 2020 at 18:45:15 -0500, Clem Cole wrote:
On Tue, Nov 10, 2020 at 6:11 PM Greg
'groggy' Lehey <grog(a)lemis.com> wrote:
Right, this is my recollection.
I'm currently reviewing a paper about Unix
and Linux, and I made the
comment that in the olden days the normal way to build an OS image for
a big computer was from source. Now I've been asked for a reference,
and I can't find one! Can anybody help?
Mumble -- For IBM and DEC in the 60s and early 70s, the manufactures
distributed the (assembler) sources to the OS and we could (and did)
build from source but usually just built parts. Remember, the target was the manufacturers HW so they
were not
giving away much.
Again, my assessment.
The real issue is: where can I find a reference? Google brings up so
many false positives that it's not worth the trouble, and Wikipedia's
pages on "System generation" are too vague.
Greg
--
Sent from my desktop computer.
Finger grog(a)lemis.com for PGP public key.
See complete headers for address and phone numbers.
This message is digitally signed. If your Microsoft mail program
reports problems, please read http://lemis.com/broken-MUA
12:10 a.m.
Pretty sure this VM/370 reference has, somewhere in its rather formidable
bulk, what you're looking for. Start around p. 225:
http://bitsavers.informatik.uni-stuttgart.de/pdf/ibm/370/VM_370/Release_6/G…
Now granted VM was never the most popular of the IBM OSes. But it was
delivered (and patched) as assembler sources. You may also enjoy Melinda
Varian's "What Mother Never Told You about VM Service."
http://www.leeandmelindavarian.com/Melinda/tutorial.pdf
On Tue, Nov 10, 2020 at 5:06 PM Greg 'groggy' Lehey <grog(a)lemis.com>
wrote:
On Tuesday, 10 November 2020 at 18:45:15 -0500, Clem
Cole wrote:
Right, this is my recollection.
On Tue, Nov 10, 2020 at 6:11 PM Greg
'groggy' Lehey <grog(a)lemis.com>
wrote:
I'm currently reviewing a paper about Unix
and Linux, and I made the
comment that in the olden days the normal way to build an OS image for
a big computer was from source. Now I've been asked for a reference,
and I can't find one! Can anybody help?
Mumble -- For IBM and DEC in the 60s and early 70s, the manufactures
distributed the (assembler) sources to the OS and we could (and did)
build from source but usually just built parts. Remember, the target was the manufacturers HW so
they were not
giving away much.
Again, my assessment.
The real issue is: where can I find a reference? Google brings up so
many false positives that it's not worth the trouble, and Wikipedia's
pages on "System generation" are too vague.
Greg
--
Sent from my desktop computer.
Finger grog(a)lemis.com for PGP public key.
See complete headers for address and phone numbers.
This message is digitally signed. If your Microsoft mail program
reports problems, please read http://lemis.com/broken-MUA
_______________________________________________
COFF mailing list
COFF(a)minnie.tuhs.org
https://minnie.tuhs.org/cgi-bin/mailman/listinfo/coff
12:12 a.m.
I don't know enough about MVS but it too is public domain until 3.8j or so,
and I would expect that the way you serviced the system was about the same:
patch the assembly code from PTFs (or whatever those are called in
MVS-land), reassemble the modules, relink into a kernel/system
image/whatever the os-appropriate nomenclature is.
Adam
On Tue, Nov 10, 2020 at 5:10 PM Adam Thornton <athornton(a)gmail.com> wrote:
Pretty sure this VM/370 reference has, somewhere in
its rather formidable
bulk, what you're looking for. Start around p. 225:
http://bitsavers.informatik.uni-stuttgart.de/pdf/ibm/370/VM_370/Release_6/G…
Now granted VM was never the most popular of the IBM OSes. But it was
delivered (and patched) as assembler sources. You may also enjoy Melinda
Varian's "What Mother Never Told You about VM Service."
http://www.leeandmelindavarian.com/Melinda/tutorial.pdf
On Tue, Nov 10, 2020 at 5:06 PM Greg 'groggy' Lehey <grog(a)lemis.com>
wrote:
On Tuesday, 10 November 2020 at 18:45:15 -0500,
Clem Cole wrote:
Right, this is my recollection.
On Tue, Nov 10, 2020 at 6:11 PM Greg
'groggy' Lehey <grog(a)lemis.com>
wrote:
I'm currently reviewing a paper about Unix
and Linux, and I made the
comment that in the olden days the normal way to build an OS image for
a big computer was from source. Now I've been asked for a reference,
and I can't find one! Can anybody help?
Mumble -- For IBM and DEC in the 60s and early 70s, the manufactures
distributed the (assembler) sources to the OS and we could (and did)
build from source but usually just built parts. Remember, the target was the manufacturers HW so
they were not
giving away much.
Again, my assessment.
The real issue is: where can I find a reference? Google brings up so
many false positives that it's not worth the trouble, and Wikipedia's
pages on "System generation" are too vague.
Greg
--
Sent from my desktop computer.
Finger grog(a)lemis.com for PGP public key.
See complete headers for address and phone numbers.
This message is digitally signed. If your Microsoft mail program
reports problems, please read http://lemis.com/broken-MUA
_______________________________________________
COFF mailing list
COFF(a)minnie.tuhs.org
https://minnie.tuhs.org/cgi-bin/mailman/listinfo/coff
3:09 a.m.
On Tuesday, 10 November 2020 at 17:12:27 -0700, Adam Thornton wrote:
I don't know enough about MVS but it too is
public domain until 3.8j or so,
and I would expect that the way you serviced the system was about the same:
patch the assembly code from PTFs (or whatever those are called in
MVS-land),
Right! There's a TLA that rings a bell. "Permanent Temporary Fix"?
Or was that a reinterpretation? But yes, it's clearly source-related.
reassemble the modules, relink into a kernel/system
image/whatever
the os-appropriate nomenclature is.
Yup. That reminds me of a poem published in Datamation decades ago:
On either die the printer lie
Fat stacks of paper six feet high
That stun the mind abnd blur the eye,
And lo! Still more comes streaming by,
A fresh SYSABEND dump.
Ye printer clackth merrily
"Compleccioun code is 043"
Alack! What can the matter be
That made SYSABEND dump?
My TCAM hath no MCP?
My data cannot OPENed be?
Consult my neighbourhood SE?
The devil take thy dam and thee,
Thou vile SYSABEND dump!
Assemble modules on the fly
And link for yet another try.
With SUPERZAP a patch apply,
This time THOU SHALT NOT DUMP!
On either side the printer lie
Fat stacks of paper twelve feet high
That blow the mind and blast the eye.
Gadzooks! How shrill yon varlet's cry
As sixteen megabytes go by
In yet another dump.
Greg
--
Sent from my desktop computer.
Finger grog(a)lemis.com for PGP public key.
See complete headers for address and phone numbers.
This message is digitally signed. If your Microsoft mail program
reports problems, please read http://lemis.com/broken-MUA
4:58 a.m.
On Wednesday, 11 November 2020 at 15:54:06 +1100, Dave Horsfall wrote:
On Wed, 11 Nov 2020, Greg 'groggy' Lehey
wrote:
Yes. But I recall correctly. See the Wikipedia page:
Customers sometimes explain the acronym in a tongue-in-cheek manner
as permanent temporary fix or more practically probably this fixes,
because they have the option to make the PTF a permanent part of the
operating system if the patch fixes the problem.
Greg
--
Sent from my desktop computer.
Finger grog(a)lemis.com for PGP public key.
See complete headers for address and phone numbers.
This message is digitally signed. If your Microsoft mail program
reports problems, please read http://lemis.com/broken-MUA
Right! There's a TLA that rings a bell.
"Permanent Temporary Fix"?
Program Temporary Fix. 
13 Nov
13 Nov
2:15 a.m.
On Wed, 11 Nov 2020, Greg 'groggy' Lehey wrote:
Yeah, they did have a habit of being permanent, but I don't recall
them ever being called by any of those names during my servitude.
-- Dave
Program
Temporary Fix.
Yes. But I recall correctly. See the Wikipedia page:
Customers sometimes explain the acronym in a tongue-in-cheek manner as
permanent temporary fix or more practically probably this fixes,
because they have the option to make the PTF a permanent part of the
operating system if the patch fixes the problem.
6:57 a.m.
This has inspired me to re-read Melinda Varian's "What Mother Never Told
You About VM Service" and it's still a magnificent document. I once again
find the control files confusing as hell, but once you get used to how they
work, which once upon a time I was, you had a repeatable (and unwindable!)
service process.
I miss the casualness with which you'd build a new CP nucleus and test it
out on a second-level system. It's so much better than anything in the
Unix world, far more elegant than testing kernel patches in a Linux virtual
machine, largely because of the ease with which you can attach minidisks to
a first, second, or whatever-level system. I guess cgroups and bind mounts
finally get you most of the way there in terms of mounting arbitrary
storage to virtual systems, but it's still a pain in the ass to test
multiple kernels.
Not that I spend much time anymore that far down in the system (any
system!), but...VM got a lot of things right.
Adam
On Thu, Nov 12, 2020 at 7:15 PM Dave Horsfall <dave(a)horsfall.org> wrote:
On Wed, 11 Nov 2020, Greg 'groggy' Lehey
wrote:
Yeah, they did have a habit of being permanent, but I don't recall
them ever being called by any of those names during my servitude.
-- Dave
_______________________________________________
COFF mailing list
COFF(a)minnie.tuhs.org
https://minnie.tuhs.org/cgi-bin/mailman/listinfo/coff
Program
Temporary Fix.
Yes. But I recall correctly. See the Wikipedia page:
Customers sometimes explain the acronym in a tongue-in-cheek manner as
permanent temporary fix or more practically probably this fixes,
because they have the option to make the PTF a permanent part of the
operating system if the patch fixes the problem.
11 Nov
11 Nov
2:07 a.m.
Well bitsavers is probably your best bet. I would look at any ibm doc for
os/360 and TSS/360. Then look at the DEC docs for Tops-10 and the distro
library's. Tops-20 I would have expected but maybe not as by the VMS and
more closed culture had begun at DEC but because it was based on Tenex
(from BBN) might have been available with full sources.
IIRC early versions of RT-11 was distributed as a binary but the sources
were readily available. I know I have seen them. Some of the first
assembler based driver code I ever looked was from RT11 (the TC11 driver)
TSS/8 was in PDP-8 source originally from CMU but DEC made it a product.
That was source which I think I have somewhere from the paper tape swapping
hack.
I never looked for or built OS/8 but I have to believe it was distributed
as source from DEC
As I said I would suggest bit savers.
Clem
On Tue, Nov 10, 2020 at 7:06 PM Greg 'groggy' Lehey <grog(a)lemis.com>
wrote:
On Tuesday, 10 November 2020 at 18:45:15 -0500, Clem
Cole wrote:
Right, this is my recollection.
--
Sent from a handheld expect more typos than usual
On Tue, Nov 10, 2020 at 6:11 PM Greg
'groggy' Lehey <grog(a)lemis.com>
wrote:
I'm currently reviewing a paper about Unix
and Linux, and I made the
comment that in the olden days the normal way to build an OS image for
a big computer was from source. Now I've been asked for a reference,
and I can't find one! Can anybody help?
Mumble -- For IBM and DEC in the 60s and early 70s, the manufactures
distributed the (assembler) sources to the OS and we could (and did)
build from source but usually just built parts. Remember, the target was the manufacturers HW so
they were not
giving away much.
Again, my assessment.
The real issue is: where can I find a reference? Google brings up so
many false positives that it's not worth the trouble, and Wikipedia's
pages on "System generation" are too vague.
Greg
--
Sent from my desktop computer.
Finger grog(a)lemis.com for PGP public key.
See complete headers for address and phone numbers.
This message is digitally signed. If your Microsoft mail program
reports problems, please read http://lemis.com/broken-MUA
12:01 a.m.
On Nov 10, 2020, at 3:11 PM, Greg 'groggy' Lehey <grog(a)lemis.com> wrote:
I'm currently reviewing a paper about Unix and Linux, and I made the
comment that in the olden days the normal way to build an OS image for
a big computer was from source. Now I've been asked for a reference,
and I can't find one! Can anybody help?
Not sure about a "big computer" but what about this paper by Richard
Miller on porting V6 to Interdata 7/32?
http://bitsavers.org/bits/Interdata/32bit/unix/univWollongong_v6/miller.pdf
1:26 a.m.
On Tue, 10 Nov 2020, Bakul Shah wrote:
Not sure about a "big computer" but what
about this paper by Richard
Miller on porting V6 to Interdata 7/32?
http://bitsavers.org/bits/Interdata/32bit/unix/univWollongong_v6/miller.pdf
Either that server is suddenly overloaded, or the Interweb pipes are
suddenly blocked...
-- Dave
1:01 a.m.
On Wed, 11 Nov 2020, Greg 'groggy' Lehey wrote:
I'm currently reviewing a paper about Unix and
Linux, and I made the
comment that in the olden days the normal way to build an OS image for a
big computer was from source. Now I've been asked for a reference, and
I can't find one! Can anybody help?
Depends what you mean by "olden days" and "big computer". As I recall
we
(Uni of NSW) had the source to the 360/50 and the Cyber 72, but not for
the VMS stuff; binaries were patched with IEBUPDTE and later on SUPERZAP
(possibly written locally).
I got an official pat on the back for getting SPITBOL to work after its
time-bombs (yes, plural) expired[*]...
And we had the source to something called Unix Edition 5 & 6 etc, but they
were hardly mainframes :-)
[*]
The first bomb failed with an error message, so I patched that. It then
started crashing rather mysteriously, and I discovered that it was taking
an indirect jump to whatever was in R0 at the time (I think). Rather than
waste time digging them all out, I wrote a program that LOADed the binary,
scanned memory for a word that matched that date, and printed each address
so they could then be inspected by hand. There were something like six of
them... One big SUPERZAP later, and we had a working SPITBOL compiler
again; a bored CompSci student is terrible to behold.
-- Dave
2:03 a.m.
Dave Horsfall <dave(a)horsfall.org> writes:
On Wed, 11 Nov 2020, Greg 'groggy' Lehey
wrote:
Wow... you too... Back in the late 1980s or early 1990s I removed a
time bomb from a language compiler running on a Data General MV/10000
with AOS/VS as the OS while an undergrad. This particular bomb,
apparently, was put in by a disgruntled employee of the company that
provided the compiler, as I received the story. I honestly don't know
many of the details, beyond that. The effort required that I
disassemble the compiler with a assembly debugger and then patch the
machine code to defeat the bomb. I seem to remember that I just patched
out a jump instruction with a nop or two. I have mostly forgotten what
the compiler was for, but it may have been the commercial Simscript
compiler for the DG. We, that is myself and one of the professors, sent
the patch to the company that provided the compiler and I know that they
ended up giving the patch out as another university with the same bomb
problem sent me a thank you note. The only other work around was to set
the clock back on the system, as it literally was a time based bomb.
--
Brad Spencer - brad(a)anduin.eldar.org - KC8VKS - http://anduin.eldar.org
I'm currently reviewing a paper about Unix
and Linux, and I made the
comment that in the olden days the normal way to build an OS image for a
big computer was from source. Now I've been asked for a reference, and
I can't find one! Can anybody help?
Depends what you mean by "olden days" and "big computer". As I
recall we
(Uni of NSW) had the source to the 360/50 and the Cyber 72, but not for
the VMS stuff; binaries were patched with IEBUPDTE and later on SUPERZAP
(possibly written locally).
I got an official pat on the back for getting SPITBOL to work after its
time-bombs (yes, plural) expired[*]...
And we had the source to something called Unix Edition 5 & 6 etc, but they
were hardly mainframes :-)
[*]
The first bomb failed with an error message, so I patched that. It then
started crashing rather mysteriously, and I discovered that it was taking
an indirect jump to whatever was in R0 at the time (I think). Rather than
waste time digging them all out, I wrote a program that LOADed the binary,
scanned memory for a word that matched that date, and printed each address
so they could then be inspected by hand. There were something like six of
them... One big SUPERZAP later, and we had a working SPITBOL compiler
again; a bored CompSci student is terrible to behold.
-- Dave
_______________________________________________
COFF mailing list
COFF(a)minnie.tuhs.org
https://minnie.tuhs.org/cgi-bin/mailman/listinfo/coff
3:11 a.m.
On Wednesday, 11 November 2020 at 12:01:40 +1100, Dave Horsfall wrote:
On Wed, 11 Nov 2020, Greg 'groggy' Lehey
wrote:
Since clarified, of course, but you're in the right track.
I'm currently reviewing a paper about Unix
and Linux, and I made the
comment that in the olden days the normal way to build an OS image for a
big computer was from source. Now I've been asked for a reference, and
I can't find one! Can anybody help?
Depends what you mean by "olden days" and "big computer". As I recall we (Uni of NSW) had the source to the
360/50 and the
Cyber 72, but not for the VMS stuff; binaries were patched with
IEBUPDTE and later on SUPERZAP (possibly written locally).
Was SUPERZAP source or object related? I thought the latter, but I've
never come close to it.
Greg
--
Sent from my desktop computer.
Finger grog(a)lemis.com for PGP public key.
See complete headers for address and phone numbers.
This message is digitally signed. If your Microsoft mail program
reports problems, please read http://lemis.com/broken-MUA
3:22 a.m.
Pretty sure SUPERZAP was for object files. That was for wizardry beyond my
ken. Normal VM service, as I recall, and I am only about 75% sure I'm
right, was in the form of source patches rather like diff files--I don't
know anymore if they were literally editor commands to transform File A
into File B, but that was the net effect--plus reassembly. Patching the
object modules was possible, but you had to be better at it than I ever was
to pull it off.
Adam
On Tue, Nov 10, 2020 at 8:11 PM Greg 'groggy' Lehey <grog(a)lemis.com>
wrote:
On Wednesday, 11 November 2020 at 12:01:40 +1100, Dave
Horsfall wrote:
On Wed, 11 Nov 2020, Greg 'groggy'
Lehey wrote:
Since clarified, of course, but you're in the right track.
I'm currently reviewing a paper about Unix
and Linux, and I made the
comment that in the olden days the normal way to build an OS image for a
big computer was from source. Now I've been asked for a reference, and
I can't find one! Can anybody help?
Depends what you mean by "olden days" and "big computer". As I recall we (Uni of NSW) had the source to the
360/50 and the
Cyber 72, but not for the VMS stuff; binaries were patched with
IEBUPDTE and later on SUPERZAP (possibly written locally).
Was SUPERZAP source or object related? I thought the latter, but I've
never come close to it.
Greg
--
Sent from my desktop computer.
Finger grog(a)lemis.com for PGP public key.
See complete headers for address and phone numbers.
This message is digitally signed. If your Microsoft mail program
reports problems, please read http://lemis.com/broken-MUA
_______________________________________________
COFF mailing list
COFF(a)minnie.tuhs.org
https://minnie.tuhs.org/cgi-bin/mailman/listinfo/coff
5:15 a.m.
On Wed, 11 Nov 2020, Greg 'groggy' Lehey wrote:
Was SUPERZAP source or object related? I thought the
latter, but I've
never come close to it.
Binary, for things for which there was no source (like SPITBOL). To edit
the source, you used a keypunch :-)
Which reminds me; our SPITBOL was just a demo program, until I nobbled it;
the "real" one (no time bomb) cost many $$$ which we couldn't afford.
-- Dave, a bored CompSci student at the time
1254
days inactive
1257
days old
18 comments
7 participants
participants (7)
-
Adam Thornton -
Bakul Shah -
Brad Spencer -
Clem Cole -
Dave Horsfall -
Greg 'groggy' Lehey -
Warner Losh