why ``folklore''?

[Julieta Shem]

What's the history of this group? Are we discussing folklore in here?
I think often we are not. (Not a complaint.)

[Andreas Kohlbach]

Post by Julieta Shem
What's the history of this group? Are we discussing folklore in here?
I think often we are not. (Not a complaint.)

It is folklore. But as so often people tend to deviate from a topic. This
probably happens in all groups.

I remember a even flamewar in alt.test some decades ago...

[Julieta Shem]

Post by Andreas Kohlbach

Post by Julieta Shem
What's the history of this group? Are we discussing folklore in here?
I think often we are not. (Not a complaint.)

It is folklore. But as so often people tend to deviate from a topic. This
probably happens in all groups.
I remember a even flamewar in alt.test some decades ago...

Lol. What happened there? Someone got upset because people were
chatting in a group where we should just do very serious tests? :)

[Andreas Kohlbach]

Post by Julieta Shem

Post by Andreas Kohlbach
I remember a even flamewar in alt.test some decades ago...

Lol. What happened there? Someone got upset because people were
chatting in a group where we should just do very serious tests? :)

Cannot remember the topic. Someone was burning a list of email addresses
of scammers. Someone else (probably a scammer been hit) complaint.

[Charlie Gibbs]

Post by Andreas Kohlbach

Post by Julieta Shem
What's the history of this group? Are we discussing folklore in here?
I think often we are not. (Not a complaint.)

It is folklore. But as so often people tend to deviate from a topic. This
probably happens in all groups.
I remember a even flamewar in alt.test some decades ago...

Thread drift is an honoured tradition in this newsfroup.
And I say this as a proud member of the Non-Sequitur Society:
We might not make sense, but we do like pizza.

[Ahem A Rivet's Shot]

On Thu, 22 Feb 2024 19:46:07 GMT

Post by Charlie Gibbs
Thread drift is an honoured tradition in this newsfroup.

Indeed it was once known as the home of thread drift - or on at
least one occasion drifting threads.

[Lawrence D'Oliveiro]

Post by Charlie Gibbs
Thread drift is an honoured tradition in this newsfroup.

People would scold me for saying “noisegroup” instead of “newsfroup” ...

[Ahem A Rivet's Shot]

On Wed, 21 Feb 2024 19:55:16 -0300

Post by Julieta Shem
What's the history of this group? Are we discussing folklore in here?
I think often we are not. (Not a complaint.)

A long time ago in a ... this group started out as old-timers
swapping war stories from the days of big iron (nothing less than twenty
years old was the original guideline back in the 90s). Most of the regulars
ran out of war stories decades ago and we're losing the older old-timers too
but we keep on nattering about anything and everything. Some while back it
was suggested that a.f.c. really stands for the auld farts of computing.

Now if you have any good war stories from the days of big iron
bring them on.

[D.J.]

On Thu, 22 Feb 2024 16:30:56 -0000 (UTC), John Levine

Post by Ahem A Rivet's Shot
Now if you have any good war stories from the days of big iron
bring them on.

CALL MAIN
END
Please do not ask me why I know that.

Okay, I wont.

[John Levine]

Post by D.J.

CALL MAIN
END
Please do not ask me why I know that.

Okay, I wont.

When a FORTRAN program started up, it made a bunch of system calls to
catch arithmetic exceptions and otherwise set up the environment. It
saved the previous environment so it could resture it after the
program returned. The amount of system space for that save/restore
stuff was small, but how many times was one program likely to do that?

Except that MAIN was the default name for the FORTRAN main program,
so each time it was called, it did the save process, the system
ran out of space, and, oops.

Or, um, so I've heard.

[D.J.]

On Thu, 22 Feb 2024 22:35:03 -0000 (UTC), John Levine

Post by John Levine

Post by D.J.

CALL MAIN
END
Please do not ask me why I know that.

Okay, I wont.

When a FORTRAN program started up, it made a bunch of system calls to
catch arithmetic exceptions and otherwise set up the environment. It
saved the previous environment so it could resture it after the
program returned. The amount of system space for that save/restore
stuff was small, but how many times was one program likely to do that?
Except that MAIN was the default name for the FORTRAN main program,
so each time it was called, it did the save process, the system
ran out of space, and, oops.
Or, um, so I've heard.

I haven't heard that one. Thanks, I think.

[Thomas Koenig]

Post by John Levine

Post by D.J.

CALL MAIN
END
Please do not ask me why I know that.

Okay, I wont.

When a FORTRAN program started up, it made a bunch of system calls to
catch arithmetic exceptions and otherwise set up the environment. It
saved the previous environment so it could resture it after the
program returned. The amount of system space for that save/restore
stuff was small, but how many times was one program likely to do that?
Except that MAIN was the default name for the FORTRAN main program,
so each time it was called, it did the save process, the system
ran out of space, and, oops.

Hmm... on later versions, this would have run up against the REGION
parameter on the JOB card, I assume, so you'd get an ABEND, I assume?

[John Levine]

Post by Thomas Koenig

Post by John Levine

CALL MAIN
END

When a FORTRAN program started up, it made a bunch of system calls to
catch arithmetic exceptions and otherwise set up the environment. It
saved the previous environment so it could resture it after the
program returned. The amount of system space for that save/restore
stuff was small, but how many times was one program likely to do that?
Except that MAIN was the default name for the FORTRAN main program,
so each time it was called, it did the save process, the system
ran out of space, and, oops.

Hmm... on later versions, this would have run up against the REGION
parameter on the JOB card, I assume, so you'd get an ABEND, I assume?

This was on MVT which definitely let you specify your region size.

According to the manual I just read, each call to the SPIE macro
returned the address of the previous PICA, program interruption
control area, in the supervisor. The idea is that a later SPIE will
use that PICA address to put the interrupts back they way they were
before. The PICAs were in the supervisor so call SPIE enough and it
runs out of space. Or so I've heard.

[Lynn Wheeler]

Post by John Levine
This was on MVT which definitely let you specify your region size.
According to the manual I just read, each call to the SPIE macro
returned the address of the previous PICA, program interruption
control area, in the supervisor. The idea is that a later SPIE will
use that PICA address to put the interrupts back they way they were
before. The PICAs were in the supervisor so call SPIE enough and it
runs out of space. Or so I've heard.

region size would otherwise default to something ... it was involved in
the justification to add virtual memory to all 370s (I was asked to
track down the decision a little over a decade and posted the result
here, aka a.f.c. and bit.listserv.mainframe). Basically MVT storage
management was so bad that regions sizes had to be four times larger
than used, as a result typical 1mbyte 370/165 would only run four
regions concurrently, insufficient to keep processor busy and justified.

Initially going to SVS single 16mbyte virtual memory (something like
running MVT in a CP67 16mbyte virtual machine, precursor to VM370) would
allow number of concurrently running regions to be inceased by a factor
of four times with little or no paging.

problem then was region&kernel security/integrity was maintained by 4bit
storage protection keys (zero for kernel, 1-15 for no. concurrent
regions) and as systems got larger/faster, they needed further increase
in concurrently running "regions" ... thus the SVS->MVS with each region
getting its own 16mbyte virtual address space (which resulted in a
number of additional problems).

old archived post:
https://www.garlic.com/~lynn//2011d.html#73

[Lawrence D'Oliveiro]

Except that MAIN was the default name for the FORTRAN main program, so
each time it was called, it did the save process, the system ran out of
space, and, oops.

You’d think the OS would have hardware protection against nonprivileged
user processes being able to do such things. But no.

[John Levine]

Post by Lawrence D'Oliveiro

Except that MAIN was the default name for the FORTRAN main program, so
each time it was called, it did the save process, the system ran out of
space, and, oops.

You’d think the OS would have hardware protection against nonprivileged
user processes being able to do such things. But no.

The save process was a system call and the insufficient space was in the system.

The fix was to make the system call fail if there wasn't enough space.
I didn't stick around long enough to find out when they did that.

[Lawrence D'Oliveiro]

Post by John Levine

Post by Lawrence D'Oliveiro
You’d think the OS would have hardware protection against nonprivileged
user processes being able to do such things. But no.

The save process was a system call and the insufficient space was in the system.

It shouldn’t be possible for ordinary users to bring down the system in
this way.

But that’s the way IBM mainframes worked. Bitsavers has recently added
some issues of “Mainframe Journal” to its magazine collection, and out of
curiosity I read the first one.

There was an item there about VM/CMS (actually CP/CMS, the “CP” being the
precursor of “VM”). This was IBM’s first attempt at a timesharing system.
It did it, not by inventing a multiuser OS, but by giving each user their
own single-user virtual machine (“CMS”). Users could even execute their
own privileged code within their own VM.

That doesn’t sound so bad, until you discover that the overall “control
program” (the “CP” part) would also blindly execute this same privileged
code as well. And so a single nonprivileged user could subvert the entire
system.

[Kerr-Mudd, John]

On Fri, 29 Mar 2024 20:50:41 -0000 (UTC)

Post by Lawrence D'Oliveiro

Post by John Levine

Post by Lawrence D'Oliveiro
You’d think the OS would have hardware protection against nonprivileged
user processes being able to do such things. But no.

The save process was a system call and the insufficient space was in the system.

It shouldn’t be possible for ordinary users to bring down the system in
this way.
But that’s the way IBM mainframes worked. Bitsavers has recently added
some issues of “Mainframe Journal” to its magazine collection, and out of
curiosity I read the first one.
There was an item there about VM/CMS (actually CP/CMS, the “CP” being the
precursor of “VM”). This was IBM’s first attempt at a timesharing system.
It did it, not by inventing a multiuser OS, but by giving each user their
own single-user virtual machine (“CMS”). Users could even execute their
own privileged code within their own VM.
That doesn’t sound so bad, until you discover that the overall “control
program” (the “CP” part) would also blindly execute this same privileged
code as well. And so a single nonprivileged user could subvert the entire
system.

We were all so much more trusting back then.

[John Ames]

On Fri, 29 Mar 2024 21:36:28 +0000

Post by Kerr-Mudd, John
We were all so much more trusting back then.

And, pre-Internet, it was a much better bet that, if some random luser
were to bring the whole system down by some dumb stunt, they'd be
located within a reasonable approximation of swift-kick-in-the-ass
range ;)

[John Levine]

Post by Kerr-Mudd, John

Post by Lawrence D'Oliveiro
That doesn’t sound so bad, until you discover that the overall “control
program” (the “CP” part) would also blindly execute this same privileged
code as well. And so a single nonprivileged user could subvert the entire
system.

We were all so much more trusting back then.

I'm pretty sure he misunderstands how CP worked.

[Lawrence D'Oliveiro]

Post by John Levine
I'm pretty sure he misunderstands how CP worked.

It was a magazine written by IBM professionals, for IBM professionals. If
they didn’t understand “how CP worked”, then I wonder who did ...

[Ahem A Rivet's Shot]

On Fri, 29 Mar 2024 21:36:28 +0000

Post by Kerr-Mudd, John
On Fri, 29 Mar 2024 20:50:41 -0000 (UTC)

Post by Lawrence D'Oliveiro
That doesn’t sound so bad, until you discover that the overall “control
program” (the “CP” part) would also blindly execute this same
privileged code as well. And so a single nonprivileged user could
subvert the entire system.

We were all so much more trusting back then.

Very true. When I got my account on the University 370 along with
the rest we were all told that, unlike the Titan where attempting to hack it
was encouraged, the 370 was trivial to hack and nobody would be impressed if
we tried. Instead we'd just get banned and possibly sent down - so nobody
bothered. Of course a lot of the more popular utilities that circulated
among students exploited oddities of the system creatively - but they were
well tested and didn't tend to bring the system down so they were tolerated.

[John Levine]

Post by Lawrence D'Oliveiro

Post by John Levine

Post by Lawrence D'Oliveiro
You’d think the OS would have hardware protection against nonprivileged
user processes being able to do such things. But no.

The save process was a system call and the insufficient space was in the system.

It shouldn’t be possible for ordinary users to bring down the system in
this way.

No kidding. It was a bug in the OS software.

Post by Lawrence D'Oliveiro
There was an item there about VM/CMS (actually CP/CMS, the “CP” being the
precursor of “VM”). This was IBM’s first attempt at a timesharing system.
It did it, not by inventing a multiuser OS, but by giving each user their
own single-user virtual machine (“CMS”). Users could even execute their
own privileged code within their own VM.

Yes, I used it back in the day to develop and run some economic
simulations. CP actually was a multi-user OS, by the way, with the
communication between users via shared disks and what we called
virtual card chutes, connecting the simulated punch on one virtual
machine to the reader on another.

Post by Lawrence D'Oliveiro
That doesn’t sound so bad, until you discover that the overall “control
program” (the “CP” part) would also blindly execute this same privileged
code as well. And so a single nonprivileged user could subvert the entire
system.

I suppose it had bugs, too, the but point of CP was to translate or
simulate the privileged stuff well enough that the user programs
worked like they were on the bare hardware, not to run it directly.

There were a few things it couldn't quite simulate, like self-modifying
channel programs used by some of the OS telecommunications subsystems
but I think they came up with special case hacks to work around it.
There's probably something in bitsavers about it.

[Bob Eager]

Post by John Levine

Post by Lawrence D'Oliveiro

Post by John Levine

Post by Lawrence D'Oliveiro
You’d think the OS would have hardware protection against
nonprivileged user processes being able to do such things. But no.

The save process was a system call and the insufficient space was in the system.

It shouldn’t be possible for ordinary users to bring down the system in
this way.

No kidding. It was a bug in the OS software.

I had a case where it was a bug in the hardware. And it was hard to fix.

Once the University of Kent had moved to using EMAS (a third party OS), it
was enjoying a rolling MTBF averaging about 2000 hours over a 13 week
period. This was much better than the 20 hours we had been getting from
VME/K. People were very happy.

And then one day it all began to fall apart. The machine just stopped. No
crash, nothing. The engineer's panel indicated that the microcode had
halted. We re-IPLed the system, and an hour or two later it stopped again.
Eventually we called the engineers, and they ran tests. Lots of them. They
pronounced that there was nothing wrong.

Then the 'crashes' stopped, for a couple of weeks. Then they started
again. We couldn't get a handle on what was wrong at all. It was
eventually decided that, the next time it happened, I should use the
engineer's panel, for as long as it took, to investigate the state of the
machine. In the event, I simply dumped out all the target machine
registers, and the microcode PC.

Our engineers obligingly left a microcode training manual lying around,
together with a microfiche listing of the microcode. Oh, and some circuit
diagrams. I retired to a darkened room for much of that day; and the next.
Eventually I emerged with the reason for the crashes. Without going into
too much technical detail, it seemed that the microcode and the hardware
handed off tasks to each other; in particular, a part of the hardware
called the 'scheduler' was responsible for validating the type field in
the descriptor register during the execution of any instruction that used
a descriptor to access an operand. Any invalid type was trapped, and sent
back to the microcode to force an exception (known as a 'contingency').
All other type values were considered valid, and passed back to the
microcode to be used in accessing a jump table, thence invoking the right
bit of microcode for that descriptor type.

So, what was going wrong? It turned out that there was what can only be
described as a hardware design error. The scheduler didn't detect one
particular invalid type code, so it handed it back to the microcode, which
accessed the jump table with it. This of course accessed an entry marked
'can never happen', and the microcode halted. We later discovered that a
physicist's errant FORTRAN program was overwriting a descriptor, and
generating the bad type value. If the machine stopped, he just submitted
the job again until he got fed up and went off for a week or two. Then he
tried again, never noticing the causal connection.

We contacted ICL, but we never seemed to reach anyone who either
understood what the problem was, or had the power or inclination to get it
fixed (which would not have been a quick job, in any case).

So I decided I had better fix this another way. Back to the microcode
listing. I found an empty patch area, and hand assembled a new bit of
microcode which I linked to the right jump table entry. All this did was
generate a 'descriptor error' contingency with a hitherto unused subtype
code. I then wrote a tool to extract the microcode from the system disk,
patch it, and put it back again. We IPLed the system, and tested it (by
this time I had a test program). Success - it correctly triggered the new
contingency and the microcode didn't halt!

The only thing left to do was to modify the various components of the
operating system to do the right thing, culminating in a change to the
FORTRAN run-time system to generate a suitable message. That only took me
a few minutes.

We had no more microcode halts and the users were happy.

[John Dallman]

Post by Bob Eager
We contacted ICL, but we never seemed to reach anyone who either
understood what the problem was, or had the power or inclination to
get it fixed (which would not have been a quick job, in any case).

I've had that problem with a vendor. I gave up, because the problem
wasn't going to affect me, and they really didn't want to know, or indeed,
hear from customers at all, unless we were bringing them money, or
screaming about a bug.

The US Department of Defence has a system for approving commercial
software to be run on their systems. They refuse to run anything they
can't get security patches for, which is reasonable. They are quite
thorough in finding out what they can get patches for, and this causes a
collision with Microsoft practices.

The C/C++ run-time ("CRT") library that programs built with Microsoft
Visual Studio use _isn't_ the same one as the Windows operating system
uses. It's supplied with Visual Studio ("VS", hereafter), and you're
supposed to bundle it with applications. In the modern era this is done
by supplying Microsoft's installer and running it from your own installer.


Versions of VS before VS.2015 each had a different and separate CRT, with
a different filename for each VS version. VS.2015 and all the subsequent
versions have used the same CRT under the same filename. However, if
Microsoft have promised to keep on doing that, I have never heard of it;
they could change it, and might well do so if they overhauled their C++
implementation significantly.

The individual-to-a-VS-version CRTs stop getting patches a bit over ten
years after their VS version was released; the last one will stop soon.
The VS.2015 CRT is still getting patches, and will until at least 2032,
ten years after VS.2022 was released.

However, big and complicated sets of Windows software often have utility
programs or other bits that are built with older VS versions. Some
vendors cling to old VS versions for a long time; in 2008, when VS6 was
leaving support, there were some fairly large software companies that had
_never_ changed their compiler, and were frightened by the idea.

In about 2019, I noticed that a widely used DBMS was still built with a
mixture of VS.2010 and VS.2013. The DoD certainly used it, so they were
going to object to the VS.2010 parts very soon. Could I get the vendor to
listen? Nope! They could understand bug reports, but the software still
worked fine.

John

[Lawrence D'Oliveiro]

Post by John Dallman
In about 2019, I noticed that a widely used DBMS was still built with a
mixture of VS.2010 and VS.2013. The DoD certainly used it, so they were
going to object to the VS.2010 parts very soon.

Hard to see any proprietary software withstanding that kind of scrutiny
for long. Pretty soon, the only stuff left standing will be Open Source.

[John Dallman]

Post by Lawrence D'Oliveiro

Post by John Dallman
In about 2019, I noticed that a widely used DBMS was still built
with a mixture of VS.2010 and VS.2013. The DoD certainly used it, so
they were going to object to the VS.2010 parts very soon.

Hard to see any proprietary software withstanding that kind of
scrutiny for long.

The stuff I work on is built with a single compiler, and we make sure to
stay well ahead of DoD requirements. This isn't hard, it just requires
not taking short-term shortcuts.

Post by Lawrence D'Oliveiro
Pretty soon, the only stuff left standing will be Open Source.

I have my doubts. In the field I work in, there are open source products,
but they aren't very good: the commercial products are all way ahead of
them. Open source works very well in many fields of software, but not all
of them.

John

[Lawrence D'Oliveiro]

Post by John Dallman
In the field I work in, there are open source products,
but they aren't very good: the commercial products are all way ahead of
them.

“Open source” does not preclude “commercial”.

[John Dallman]

_Open source_ does not preclude _commercial_.

In theory, no. However, Sun's attempt to make much of their commercial
closed-source software open source and its contribution to their collapse
tends to strengthen the divide.

John

[Ahem A Rivet's Shot]

On Sun, 31 Mar 2024 11:57 +0100 (BST)

Post by John Dallman

_Open source_ does not preclude _commercial_.

In theory, no. However, Sun's attempt to make much of their commercial
closed-source software open source and its contribution to their collapse
tends to strengthen the divide.

Then there's RHEL et al, also commercial products with open source
cores like MacOS and OneFS.

As for Sun, I think their demise had more to do with the PC
catching up with the Sparc than anything else. We can be thankful that they
made ZFS open source otherwise that splendid filesystem would be lost or
buried in expensive Oracle products.

[Scott Lurndal]

Post by John Dallman
In the field I work in, there are open source products,
but they aren't very good: the commercial products are all way ahead of
them.

“Open source” does not preclude “commercial”.

That's not what you claimed. You said (and I'll quote since you snipped it

Post by John Dallman
Pretty soon, the only stuff left standing will be Open Source.

[Lawrence D'Oliveiro]

Post by Scott Lurndal

Post by Lawrence D'Oliveiro

Post by John Dallman
In the field I work in, there are open source products,
but they aren't very good: the commercial products are all way ahead
of them.
Pretty soon, the only stuff left standing will be Open Source.

“Open source” does not preclude “commercial”.

That's not what you claimed.

I claimed both. One claim does not conflict with the other. In fact, they
reinforce each other.

[Charlie Gibbs]

Post by Lawrence D'Oliveiro

Post by John Dallman
In about 2019, I noticed that a widely used DBMS was still built with a
mixture of VS.2010 and VS.2013. The DoD certainly used it, so they were
going to object to the VS.2010 parts very soon.

Hard to see any proprietary software withstanding that kind of scrutiny
for long. Pretty soon, the only stuff left standing will be Open Source.

...whatever MICROS~1 defines that to be...

[Lawrence D'Oliveiro]

Post by Charlie Gibbs

Post by Lawrence D'Oliveiro
Pretty soon, the only stuff left standing will be Open Source.

...whatever MICROS~1 defines that to be...

They don’t get to control it. In fact, they’re busy playing catch-up,
trying to turn Windows into Linux with WSL.

[Lynn Wheeler]

Post by John Levine
Yes, I used it back in the day to develop and run some economic
simulations. CP actually was a multi-user OS, by the way, with the
communication between users via shared disks and what we called
virtual card chutes, connecting the simulated punch on one virtual
machine to the reader on another.

and RSCS/VNET also forwarded the (virtual unit record) spool files to
users on different machines ... was used for several different "email"
implementations.

GML website seems to have gone 404, but lives on at wayback machine
https://web.archive.org/web/20230402212558/http://www.sgmlsource.com/history/jasis.htm
"Actually, the law office application was the original motivation for
the project, something I was allowed to do part-time because of my
knowledge of the user requirements. My real job was to encourage the
staffs of the various scientific centers to make use of the CP-67-based
Wide Area Network that was centered in Cambridge."

CSC member responsible for CP67 wide-area network (morphs into the
corporate internal network larger than arpanet/internet from just about
beginning until sometime mid/late 80s ... technology also used for the
corporate sponsored univ bitnet/earn, also for a time larger than
internet)
https://en.wikipedia.org/wiki/Edson_Hendricks

"In June 1975, MIT Professor Jerry Saltzer accompanied Hendricks to
DARPA, where Hendricks described his innovations to the principal
scientist, Dr. Vinton Cerf. Later that year in September 15-19 of 75,
Cerf and Hendricks were the only two delegates from the United States,
to attend a workshop on Data Communications at the International
Institute for Applied Systems Analysis, 2361 Laxenburg Austria where
again, Hendricks spoke publicly about his innovative design which paved
the way to the Internet as we know it today."

SJMerc article about Edson (passed aug2020) and "IBM'S MISSED
OPPORTUNITY WITH THE INTERNET" (gone behind paywall but lives free at
wayback machine)
https://web.archive.org/web/20000124004147/http://www1.sjmercury.com/svtech/columns/gillmor/docs/dg092499.htm
Also from wayback machine, some additional (IBM missed INTERENET)
references from Ed's website
https://web.archive.org/web/20000115185349/http://www.edh.net/bungle.htm

corporate sponsored univ bitnet/earn
https://en.wikipedia.org/wiki/BITNET

Note, Pisa Science Center had done "SPM" for CP/67 (inter virtual
machine communication) ... which never ships to customers ... although
the VM/370 RSCS/VNET that shipped to customers included support for
using "SPM". "SPM" was superset combination of the later VM/370 "VMCF",
"IUCV", and "SMSG" (functions).

triva: internally within IBM a VM370/CMS, 3270 client/server "space war"
game was implemented using "SPM" ... and since RCSC/VNET supported
"SPM", clients could be almost anywhere on the internal network. aside:
almost immediately robotic clients appeared, beating all humans (with
their faster response time) ... server then was modified to increase
energy use non-linearly as command intervals dropped below nominal human
response ... somewhat leveling the playing field.

other triva: 1st webserver in the US was on Stanford SLAC VM370 system
https://www.slac.stanford.edu/history/earlyweb/history.shtml
https://www.slac.stanford.edu/history/earlyweb/firstpages.shtml

SLAC also sponsored the monthly VM370 user group meetings ("BAYBUNCH")

[Scott Lurndal]

You’d think the OS would have hardware protection against nonprivileged
user processes being able to do such things. But no.

There was an item there about VM/CMS (actually CP/CMS, the “CP” being the
precursor of “VM”). This was IBM’s first attempt at a timesharing system.
It did it, not by inventing a multiuser OS, but by giving each user their
own single-user virtual machine (“CMS”). Users could even execute their
own privileged code within their own VM.
That doesn’t sound so bad, until you discover that the overall “control
program” (the “CP” part) would also blindly execute this same privileged
code as well. And so a single nonprivileged user could subvert the entire
system.

Lynn will probably chime in at this point, but it is worth remembering
that interactive use (particularly by untrusted users) was not at all
common in production IBM mainframe environments (or Burroughs or Sperry or Honeywell
or GE or ICL or whomever).

Other mainframes (e.g. the B5500) considered security from the
start and ensured[*] that privileged code could only be executed by the
MCP)

[*] One may not like how that was done, but again, these were batch
systems with highly controlled workloads and limited on-line green-screen forms
applications and generally networking only within corporate and proprietary
networks (SNA, BNA, X.25).

[Peter Flass]

Post by Scott Lurndal

Post by Lawrence D'Oliveiro

Post by Lawrence D'Oliveiro
You’d think the OS would have hardware protection against nonprivileged
user processes being able to do such things. But no.

There was an item there about VM/CMS (actually CP/CMS, the “CP” being the
precursor of “VM”). This was IBM’s first attempt at a timesharing system.
It did it, not by inventing a multiuser OS, but by giving each user their
own single-user virtual machine (“CMS”). Users could even execute their
own privileged code within their own VM.
That doesn’t sound so bad, until you discover that the overall “control
program” (the “CP” part) would also blindly execute this same privileged
code as well. And so a single nonprivileged user could subvert the entire
system.

Lynn will probably chime in at this point, but it is worth remembering
that interactive use (particularly by untrusted users) was not at all
common in production IBM mainframe environments (or Burroughs or Sperry or Honeywell
or GE or ICL or whomever).
Other mainframes (e.g. the B5500) considered security from the
start and ensured[*] that privileged code could only be executed by the
MCP)

Sort of. I seem to recall that Algol “stream procedures” bypassed a lot of
checks for memory access.

Post by Scott Lurndal
[*] One may not like how that was done, but again, these were batch
systems with highly controlled workloads and limited on-line green-screen forms
applications and generally networking only within corporate and proprietary
networks (SNA, BNA, X.25).

[Scott Lurndal]

Post by Scott Lurndal

You’d think the OS would have hardware protection against nonprivileged
user processes being able to do such things. But no.

There was an item there about VM/CMS (actually CP/CMS, the “CP” being the
precursor of “VM”). This was IBM’s first attempt at a timesharing system.
It did it, not by inventing a multiuser OS, but by giving each user their
own single-user virtual machine (“CMS”). Users could even execute their
own privileged code within their own VM.
That doesn’t sound so bad, until you discover that the overall “control
program” (the “CP” part) would also blindly execute this same privileged
code as well. And so a single nonprivileged user could subvert the entire
system.

Lynn will probably chime in at this point, but it is worth remembering
that interactive use (particularly by untrusted users) was not at all
common in production IBM mainframe environments (or Burroughs or Sperry or Honeywell
or GE or ICL or whomever).
Other mainframes (e.g. the B5500) considered security from the
start and ensured[*] that privileged code could only be executed by the
MCP)

Sort of. I seem to recall that Algol “stream procedures” bypassed a lot of
checks for memory access.

There was a flavor of Algol (most recently called NEWP, IIRC) which was used
to write the MCP, which allowed many privileged operations. So far as I know,
it was not generally made available to customers.

To be fair, the implementation evolved over several decades and is still
running production in emulation.

[Lawrence D'Oliveiro]

Post by Scott Lurndal
[*] One may not like how that was done, but again, these were batch
systems with highly controlled workloads and limited on-line
green-screen forms applications and generally networking only within
corporate and proprietary networks (SNA, BNA, X.25).

It comes as a bit of a surprise to me to learn that it was the advent of
timesharing, not batch operation, that drove the development of hardware
protection systems.

[Scott Lurndal]

Post by Lawrence D'Oliveiro

Post by Scott Lurndal
[*] One may not like how that was done, but again, these were batch
systems with highly controlled workloads and limited on-line
green-screen forms applications and generally networking only within
corporate and proprietary networks (SNA, BNA, X.25).

It comes as a bit of a surprise to me to learn that it was the advent of
timesharing, not batch operation, that drove the development of hardware
protection systems.

The early batch systems (360, B3500, B6500) all had hardware protection
of some sort (partitions, control/normal state with base and limit
registers, capabilities) respectively. TSS and CANDE were built on
those capabilities.

[Bob Eager]

Post by Scott Lurndal

Post by Lawrence D'Oliveiro

Post by Scott Lurndal
[*] One may not like how that was done, but again, these were batch
systems with highly controlled workloads and limited on-line
green-screen forms applications and generally networking only within
corporate and proprietary networks (SNA, BNA, X.25).

It comes as a bit of a surprise to me to learn that it was the advent of
timesharing, not batch operation, that drove the development of hardware
protection systems.

The early batch systems (360, B3500, B6500) all had hardware protection
of some sort (partitions, control/normal state with base and limit
registers, capabilities) respectively. TSS and CANDE were built on
those capabilities.

The ICT 1900 series was very successful outside the USA, and was based on
the Ferranti-Packard 6000. It was introduced in 1984, and had control/
normal state with base and limit registers. It supported batch and
timesharing.

[Bob Eager]

Post by Bob Eager

Post by Scott Lurndal

Post by Lawrence D'Oliveiro

Post by Scott Lurndal
[*] One may not like how that was done, but again, these were batch
systems with highly controlled workloads and limited on-line
green-screen forms applications and generally networking only within
corporate and proprietary networks (SNA, BNA, X.25).

It comes as a bit of a surprise to me to learn that it was the advent
of timesharing, not batch operation, that drove the development of
hardware protection systems.

The early batch systems (360, B3500, B6500) all had hardware protection
of some sort (partitions, control/normal state with base and limit
registers, capabilities) respectively. TSS and CANDE were built on
those capabilities.

The ICT 1900 series was very successful outside the USA, and was based
on the Ferranti-Packard 6000. It was introduced in 1984, and had
control/ normal state with base and limit registers. It supported batch
and timesharing.

That should read '1964'!

[Ahem A Rivet's Shot]

On 30 Mar 2024 10:51:14 GMT

Post by Bob Eager

Post by Bob Eager
on the Ferranti-Packard 6000. It was introduced in 1984, and had
control/ normal state with base and limit registers. It supported batch
and timesharing.

That should read '1964'!

Orwell an easy mistake.

[Lynn Wheeler]

Post by Lawrence D'Oliveiro
That doesn’t sound so bad, until you discover that the overall
“control program” (the “CP” part) would also blindly execute this same
privileged code as well. And so a single nonprivileged user could
subvert the entire system.

some of the MIT CTSS/7094
https://en.wikipedia.org/wiki/Compatible_Time-Sharing_System
https://multicians.org/thvv/7094.html
people went to the 5th flr for Multics
https://en.wikipedia.org/wiki/Multics

others went to the IBM scientific center on the 4th flr
https://en.wikipedia.org/wiki/Cambridge_Scientific_Center
and did virtual machines, internal network, numerous interactive apps,
monitoring&performance work, invented GML in 1969 (decade later morphs
into ISO standard SGML, and after another decade morphs into HTML at
CERN).

Initially, CP40/CMS was done on a 360/40 with virtual memory hardware
mods ... then morphs into CP67/CMS when 360/67 standard with virtual
memory becomes available. It would simulate a virtual machine's
priviledge instructions ... but isolated within that virtual machine's
domain ... not the real machine's domain.
https://en.wikipedia.org/wiki/CP/CMS
https://en.wikipedia.org/wiki/History_of_CP/CMS
More history/details at Melinda's website
http://www.leeandmelindavarian.com/Melinda#VMHist

Naturally, there was some amount of friendly competitiion between the
two efforts on the 4th & 5th flrs. CTSS "RUNOFF" had been redone for CMS
as "SCRIPT" ... and after GML was invented in 1969, GML tag processing
added to SCRIPT. There was CP67/CMS MIT Urban lab in the bldg across the
quad. The CP67 ASCII support had been for TTY devices with
lines(/transmission) shorter then 255 chars (1byte length
field). Somebody down at Harvard got a new ASCII device (plotter?) and
they needed to patch CP67 to handle up to 1200(?) chars ...a flaw in the
patch crashed the system 27times in one day
https://www.multicians.org/thvv/360-67.html
"Multics was also crashing quite often at that time, but each crash took
an hour to recover because we salvaged the entire file system. This
unfavorable comparison was one reason that the Multics team began
development of the New Storage System.)"

In 60s, there was two commercial online service bureaus spinoffs of the
science center ... specializing in services for the financial industry
and had to demonstrate strong security because competing financial
companies were making use of the services.

there were also various gov. agencies installing CP67/CMS because of its
strong security.

Another commercial online service bureau was TYMSHARE in the 70s
https://en.wikipedia.org/wiki/Tymshare
and in Aug1976 they provided their online computer conferencing
system (precursor to modern social media), "free" to the IBM
user group SHARE
https://en.wikipedia.org/wiki/SHARE_(computing)
as VMSHARE, archives here
http://vm.marist.edu/~vmshare

a 3-letter gov. agency was large customer (and required gov. level
security) and very active in the VM group at SHARE and on vmshare.

The science center had also ported APL\360 to CP67/CMS as CMS\APL,
opening workspaces from "swapped 16kbyes" to demand page large virtual
memory ... and also implemented an API for system services like file I/O
... enabling many real world applications. Then the business planners
in Armonk corporate hdqtrs loaded the most valuable corporate data on
the Cambridge system for doing CMS\APL-based business applications.
Strong security had to also be demonstrated since professors, staff, and
students from Boston area educational institutions were also using the
Cambridge CP67/CMS system.

[Lynn Wheeler]

there was early case where a MIT student "hung" the IBM cambridge system
by writing a channel program that looped, locking up the i/o channel.
system had to be re-ipled and the student contacted to not do that
again, he did it again and his user login was disabled. he then
complained that IBM wasn't allowed to block his user (apparently didn't
realize that it wasn't a MIT system).

the commercial online CP67 services dealt with it early on by adding a
new security class that wouldn't simulate the SIO instruction that
invoked channel programs ... restricting CMS I/O to just "diagnose"
instruction (which already started being used for CMS I/O) ... some
vmshare discussion about sandbox'ing users.

mid-90s there was small conference of cal. univ computer science
graduate school professors ... who complained that graduate students
were getting more "peer points" by demonstrating how to crash systems as
opposed to building systems that were crash proof.

[John Dallman]

Post by Ahem A Rivet's Shot
Now if you have any good war stories from the days of big iron
bring them on.

Not big iron, but I did once get the job of writing software to break the
company's hardware.

It was 1999. We'd just bought a bunch of powerful - for the time -
Windows NT desksides from a second-tier manufacturer who'd suddenly
turned all friendly. I think they were trying to get us to recommend
their hardware for our software, which was never going to happen, but we
were willing to let them try to bribe us.

Tech Support built the machines and they went out onto developers' desks.
They were fine, for the first day. Then one of the hard disks went bad.
We gave that developer their old machine back and called the manufacturer
to replace the disk. The next day, two more disks went bad. At that point,
it was clear we had a bad batch, so we swapped all the old machines back
onto desks, and called the manufacturer to replace all the disks.

They wouldn't. They would happily replace ones that went bad under
warranty, but they would not touch anything that was still working. After
some back-and-forth arguing, I suggested I could provide a "test program."
This just copied a bunch of large files whose contents were very much
like noise (gziped debug-compiled libraries for an obsolete platform)
back and forth a lot, periodically comparing them.

A few days later, I wandered into Tech Support and heard half a 'phone
call:

"Hello, yes, it's us again."

"Yes, another one went overnight. You might want to tell the engineer
to bring a second disk, because there's another one that's making some
very nasty noises."

A few of the drives withstood two weeks of this treatment. We concluded
those weren't from the bad batch, and we had no further trouble with them.


John

[Stefan Ram]

Post by John Dallman
This just copied a bunch of large files whose contents were very much
like noise (gziped debug-compiled libraries for an obsolete platform)
back and forth a lot, periodically comparing them.

I am sometimes moving the contents of old drives to new drives.
One day it occured to me that the program I use for copying
does not actually compare the files after copying. So I wrote a
Python program to verify my copies (actually moves), and so far
I already have found some differences! My Python program will
now copy such files again and again, until they compare equal.
Next step: I'll write a GUI for my Python program and then I'll
use it whenever I want to copy or move a lot!

[Lawrence D'Oliveiro]

Post by Stefan Ram
I am sometimes moving the contents of old drives to new drives.
One day it occured to me that the program I use for copying does not
actually compare the files after copying.

You should be using rsync. Great tool for bulk copies, over networks (via
SSH) or locally. If something interrupts the copy (power outage, network
drops or whatever), just rerun the command, and it will figure out what it
had already copied, and resume from there.

And then, when it is done, you can use the --checksum option to do exactly
what you describe above, and reread everything to make sure it matches.

[D]

Post by John Dallman

Post by Ahem A Rivet's Shot
Now if you have any good war stories from the days of big iron
bring them on.

Not big iron, but I did once get the job of writing software to break the
company's hardware.

That reminds me of another story...

Many years ago, or decades, when the beard was not yet grey, I was
responsible for setting up a lab environment with a few servers,
switches and that's about it.

So after some installing and configuring, I discover that one server
refuses to connect to the network. I check the server configuration,
nothing, I check the switch, nothing, reboot, restart, remove interface,
add interface.

What to do?

Of course the error must be the cable! Said and done.

So I found a box with unopened cables, pulled out the cable, connected,
and...

no connection. Re-check everything, settings, switch, reboot, restart,
nothing. I reinstalled the server, nothing.

So I went to lunch.

After I came back a colleague told me, "oh the server, I fixed it!" and
I asked "what was the problem?" and he responded "the cable, I just
switched the cable!".

So _two_ broken cables after each other, and the second cable came
broken from the manufacturer!!

Best regards,
Daniel

[Ahem A Rivet's Shot]

On Fri, 23 Feb 2024 23:03:54 +0100

Post by D
That reminds me of another story...
Many years ago, or decades, when the beard was not yet grey, I was

One that nobody ever got to the bottom of from a similar point in
time. I was in a small "vertical market" outfit writing CP/M and MPM based
applications - our development system developed tape problems so service
call ...

Engineer comes out, replaces tape drive - problems remain, replaces
controller board and cables - problems remain ...

Eventually every component in the case (a simple 19", 4U steel
box) had been replaced (in fact swapped from an identical machine) without
curing the problems and all the old components assembled in the other case
worked perfectly. Considerable experimentation failed to change this state
of affairs.

With great puzzlement he pronounced the problem cured by swapping
the case!

[John Dallman]

Post by Ahem A Rivet's Shot
With great puzzlement he pronounced the problem cured by swapping
the case!

Were there, perchance, cable sockets that were part of the case?

John

[Ahem A Rivet's Shot]

On Sat, 24 Feb 2024 11:58 +0000 (GMT Standard Time)

Post by John Dallman

Post by Ahem A Rivet's Shot
With great puzzlement he pronounced the problem cured by swapping
the case!

Were there, perchance, cable sockets that were part of the case?

Nope they were in the PSU for mains and the serial port boards for
the rest.

[D]

Post by Ahem A Rivet's Shot
On Fri, 23 Feb 2024 23:03:54 +0100

Post by D
That reminds me of another story...
Many years ago, or decades, when the beard was not yet grey, I was

One that nobody ever got to the bottom of from a similar point in
time. I was in a small "vertical market" outfit writing CP/M and MPM based
applications - our development system developed tape problems so service
call ...
Engineer comes out, replaces tape drive - problems remain, replaces
controller board and cables - problems remain ...
Eventually every component in the case (a simple 19", 4U steel
box) had been replaced (in fact swapped from an identical machine) without
curing the problems and all the old components assembled in the other case
worked perfectly. Considerable experimentation failed to change this state
of affairs.
With great puzzlement he pronounced the problem cured by swapping
the case!

Fascinating! Our dear machines do seem to have a life of their own
sometimes!

[Dennis Boone]

Post by Ahem A Rivet's Shot
With great puzzlement he pronounced the problem cured by swapping
the case!

Reminiscent of MIT's "magic" / "more magic" switch.

De

[Mike Spencer]

Post by Ahem A Rivet's Shot
Engineer comes out, replaces tape drive - problems remain, replaces
controller board and cables - problems remain ...
Eventually every component in the case (a simple 19", 4U steel
box) had been replaced (in fact swapped from an identical machine) without
curing the problems and all the old components assembled in the other case
worked perfectly. Considerable experimentation failed to change this state
of affairs.
With great puzzlement he pronounced the problem cured by swapping
the case!

A resonant clue from Martha Grimes? (q.g.)

https://caseisalteredpinner.co.uk/

:-)

[Thomas Koenig]

Post by Ahem A Rivet's Shot
On Fri, 23 Feb 2024 23:03:54 +0100

Post by D
That reminds me of another story...
Many years ago, or decades, when the beard was not yet grey, I was

One that nobody ever got to the bottom of from a similar point in
time. I was in a small "vertical market" outfit writing CP/M and MPM based
applications - our development system developed tape problems so service
call ...
Engineer comes out, replaces tape drive - problems remain, replaces
controller board and cables - problems remain ...
Eventually every component in the case (a simple 19", 4U steel
box) had been replaced (in fact swapped from an identical machine) without
curing the problems and all the old components assembled in the other case
worked perfectly. Considerable experimentation failed to change this state
of affairs.
With great puzzlement he pronounced the problem cured by swapping
the case!

Maybe it wasn't swapping, but removing and re-attaching grounding
cables, the original case would have worked as well.

[Ahem A Rivet's Shot]

On Mon, 26 Feb 2024 21:29:59 -0000 (UTC)

Post by Thomas Koenig

Post by Ahem A Rivet's Shot
On Fri, 23 Feb 2024 23:03:54 +0100

Post by D
That reminds me of another story...
Many years ago, or decades, when the beard was not yet grey, I was

One that nobody ever got to the bottom of from a similar point
in time. I was in a small "vertical market" outfit writing CP/M and MPM
based applications - our development system developed tape problems so
service call ...
Engineer comes out, replaces tape drive - problems remain,
replaces controller board and cables - problems remain ...
Eventually every component in the case (a simple 19", 4U steel
box) had been replaced (in fact swapped from an identical machine)
without curing the problems and all the old components assembled in the
other case worked perfectly. Considerable experimentation failed to
change this state of affairs.
With great puzzlement he pronounced the problem cured by
swapping the case!

Maybe it wasn't swapping, but removing and re-attaching grounding
cables, the original case would have worked as well.

He tried putting it all back in the original case after swapping
the last component, then experimented. There was no doubt, any set of
components worked in the new case, no combination worked in the original.

[Bob Eager]

Post by Ahem A Rivet's Shot
Now if you have any good war stories from the days of big iron
bring them on.

OK, time for another.

----------------------------------------------------------------------
This follows on from the story in my previous post, and it's about the
loader. This was a joint effort between (I think) two or three of us.

Writing subsystems (see before) was great fun. They could only be done in
assembler, and then they had to be put in a place where they could be
loaded. The only place the system was set up to find them was a particular
area on 'disc 2'. We could copy our programs there, and they could then be
loaded simply by typing their name.

We got up to various antics with subsystems, which eventually resulted in
special restrictions being imposed on where one could copy files. Disc 2
was off limits; it wasn't technically possible to put files there except
from a batch job (too traceable) or the operator's console. So we were
stopped in our tracks.

But not for long. This is where BASIC comes in. The BASIC system had been
written locally (as had the entire online system) but of course it was
rather limited by the available space for each user (a bit less than 1000
(24 bit) words each). The BASIC system lived in a 'common program' memory
area which was separate from that, as indeed did all subsystems.

Because of the space limitations, one could generate a 'BASIC library'.
Bear in mind that BASIC itself compiled to real code. One could write a
load of BASIC, using high line numbers. A special command generated a text
file as output; this file consisted of a stream of octal numbers
representing compiled code. This could be fed to the assembler (it was
syntactically valid for that) and turned into a callable library, which
could be put somewhere that a BASIC user could access it. It was then
possible to call up that library, and use the subroutines in it from one's
own BASIC programs, the library code being loaded into the common program
area, not using up the user's own space. You just had to know the line
numbers for the subroutines in the library, as they weren't visible when
listing your BASIC program.

So, the hack was this. We wrote a few lines of BASIC based at (say) line
10000. Then we generated the source for the library, as usual. At this
point, said source was edited to add rather more assembler - in fact, a
program loader. The 'library' was then assembled and put in a suitable
place on disc.

Using this was simple. One merely ran BASIC, and loaded the hacked
library. Then a command such as:

GOTO 10000

was issued. That entered and ran the loader, which prompted with:

ENTER PROGRAM TO LOAD:

The name of your subsystem (e.g. the one to pre-empt the card reader) was
then typed. Hit the carriage return key, and you'd be in your program.

I don't think we ever got caught with that. The main perpetrators were me
and a guy who ended up being head of software - the job of the guy we were
hiding it all from at the time. And I ended up managing the next
mainframe.

---------------------------------------------------

[Peter Flass]

Post by Bob Eager

Post by Ahem A Rivet's Shot
Now if you have any good war stories from the days of big iron
bring them on.

OK, time for another.
----------------------------------------------------------------------
This follows on from the story in my previous post, and it's about the
loader. This was a joint effort between (I think) two or three of us.
Writing subsystems (see before) was great fun. They could only be done in
assembler, and then they had to be put in a place where they could be
loaded. The only place the system was set up to find them was a particular
area on 'disc 2'. We could copy our programs there, and they could then be
loaded simply by typing their name.
We got up to various antics with subsystems, which eventually resulted in
special restrictions being imposed on where one could copy files. Disc 2
was off limits; it wasn't technically possible to put files there except
from a batch job (too traceable) or the operator's console. So we were
stopped in our tracks.
But not for long. This is where BASIC comes in. The BASIC system had been
written locally (as had the entire online system) but of course it was
rather limited by the available space for each user (a bit less than 1000
(24 bit) words each). The BASIC system lived in a 'common program' memory
area which was separate from that, as indeed did all subsystems.
Because of the space limitations, one could generate a 'BASIC library'.
Bear in mind that BASIC itself compiled to real code. One could write a
load of BASIC, using high line numbers. A special command generated a text
file as output; this file consisted of a stream of octal numbers
representing compiled code. This could be fed to the assembler (it was
syntactically valid for that) and turned into a callable library, which
could be put somewhere that a BASIC user could access it. It was then
possible to call up that library, and use the subroutines in it from one's
own BASIC programs, the library code being loaded into the common program
area, not using up the user's own space. You just had to know the line
numbers for the subroutines in the library, as they weren't visible when
listing your BASIC program.
So, the hack was this. We wrote a few lines of BASIC based at (say) line
10000. Then we generated the source for the library, as usual. At this
point, said source was edited to add rather more assembler - in fact, a
program loader. The 'library' was then assembled and put in a suitable
place on disc.
Using this was simple. One merely ran BASIC, and loaded the hacked
GOTO 10000
The name of your subsystem (e.g. the one to pre-empt the card reader) was
then typed. Hit the carriage return key, and you'd be in your program.
I don't think we ever got caught with that. The main perpetrators were me
and a guy who ended up being head of software - the job of the guy we were
hiding it all from at the time. And I ended up managing the next
mainframe.

Good times. It’s no fun doing that kind of stuff on your own PC.

[Ahem A Rivet's Shot]

On Fri, 23 Feb 2024 18:38:32 -0700

Post by Peter Flass
Good times. It’s no fun doing that kind of stuff on your own PC.

Escaping to the hypervisor from a cloud VM OTOH ... But these days
that sort of thing gets taken rather seriously so best to resist.

[Bob Eager]

Post by Bob Eager

Post by Ahem A Rivet's Shot
Now if you have any good war stories from the days of big iron
bring them on.

OK, time for another.

(trimmed)

There is a bit of a postscript to my previously detailed exploits.

This happened nearly 30 years after the previously mentioned events. I was
hosting a retirement dinner for several staff, all of whom had been around
since I was an undergraduate. One of the guests was the former system
software manager, who had been one of the people who nearly caught us. I
am pretty sure he knew who was responsible, even if he couldn't prove it.
He always had a dry sense of humour.

Of course, we got chatting (he had been my boss when I had a part time
job), and he asked what I was doing now. I replied that I had been
teaching there for many years. He asked what I taught, and I said my
primary interest was operating systems.

His droll reply was "Why am I not surprised?"

[Julieta Shem]

Bob Eager <***@eager.cx> writes:

[...]

Post by Bob Eager
This happened nearly 30 years after the previously mentioned events. I was
hosting a retirement dinner for several staff, all of whom had been around
since I was an undergraduate. One of the guests was the former system
software manager, who had been one of the people who nearly caught us. I
am pretty sure he knew who was responsible, even if he couldn't prove it.
He always had a dry sense of humour.
Of course, we got chatting (he had been my boss when I had a part time
job), and he asked what I was doing now. I replied that I had been
teaching there for many years. He asked what I taught, and I said my
primary interest was operating systems.
His droll reply was "Why am I not surprised?"

Lol! This confirms the conjecture that most perpetrators want to be
caught---telling the story is irresistible.

[Lawrence D'Oliveiro]

I crashed a DEC Alpha (running OSF/1, before it was renamed “Tru64”) not
once, but twice. This was around 1996 or so. I was writing Perl code, and
(memory is hazy, but) I think I was implementing a wrapper for a system
call that had no Perl function equivalent.

The first time it happened, I was running as root. So I decided to try it
as a nonprivileged user the second time ... and crashed the system again.

Seemed the kernel’s validation of pointers into user space was a
little ... deficient.