What's the history of this group? Are we discussing folklore in here?
I think often we are not. (Not a complaint.)
On Wed, 21 Feb 2024 19:55:16 -0300, Julieta Shem wrote:
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...
What's the history of this group? Are we discussing folklore in here?
What's the history of this group? Are we discussing folklore in here?
I think often we are not. (Not a complaint.)
Now if you have any good war stories from the days of big iron
bring them on.
According to Ahem A Rivet's Shot <steveo@eircom.net>:
Now if you have any good war stories from the days of big iron
bring them on.
Back around 1970, this FORTRAN program would crash OS/360:
CALL MAIN
END
Please do not ask me why I know that.
Thread drift is an honoured tradition in this newsfroup.
Back around 1970, this FORTRAN program would crash OS/360:
CALL MAIN
END
Please do not ask me why I know that.
Okay, I wont.
Andreas Kohlbach <ank@spamfence.net> writes:
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? :)
According to D.J. <chucktheouch@gmnol.com>:
Back around 1970, this FORTRAN program would crash OS/360:
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.
Now if you have any good war stories from the days of big iron
bring them on.
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.
In article <20240222081328.9a3efea82299c9896d6d33c2@eircom.net>, steveo@eircom.net (Ahem A Rivet's Shot) wrote:
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.
Now if you have any good war stories from the days of big iron
bring them on.
That reminds me of another story...
Many years ago, or decades, when the beard was not yet grey, I was
On Thu, 22 Feb 2024 08:13:28 +0000, Ahem A Rivet's Shot wrote:
Now if you have any good war stories from the days of big iron
bring them on.
OK, time for another.
With great puzzlement he pronounced the problem cured by swapping
the case!
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?"
Good times. It’s no fun doing that kind of stuff on your own PC.
On Fri, 23 Feb 2024 23:03:54 +0100
D <nospam@example.net> wrote:
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!
In article <20240224112941.e2a43d397d297545c98f60b7@eircom.net>, steveo@eircom.net (Ahem A Rivet's Shot) wrote:
With great puzzlement he pronounced the problem cured by swapping
the case!
Were there, perchance, cable sockets that were part of the case?
With great puzzlement he pronounced the problem cured by swapping the case!
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!
On Fri, 23 Feb 2024 23:03:54 +0100
D <nospam@example.net> wrote:
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!
Ahem A Rivet's Shot <steveo@eircom.net> schrieb:
On Fri, 23 Feb 2024 23:03:54 +0100
D <nospam@example.net> wrote:
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.
According to D.J. <chucktheouch@gmnol.com>:
Back around 1970, this FORTRAN program would crash OS/360:
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.
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.
Thread drift is an honoured tradition in this newsfroup.
Back around 1970, this FORTRAN program would crash OS/360:
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.
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.
On Thu, 22 Feb 2024 22:35:03 -0000 (UTC), John Levine wrote:
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.
According to Lawrence D'Oliveiro <ldo@nz.invalid>:
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.
On Fri, 29 Mar 2024 16:12:33 -0000 (UTC), John Levine wrote:
According to Lawrence D'Oliveiro <ldo@nz.invalid>:
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.
On Fri, 29 Mar 2024 16:12:33 -0000 (UTC), John Levine wrote:
According to Lawrence D'Oliveiro <ldo@nz.invalid>:
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.
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.
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.
According to Lawrence D'Oliveiro <ldo@nz.invalid>:
On Fri, 29 Mar 2024 16:12:33 -0000 (UTC), John Levine wrote:
According to Lawrence D'Oliveiro <ldo@nz.invalid>:
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.
On Fri, 29 Mar 2024 20:50:41 -0000 (UTC)
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
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.
[*] 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).
Lawrence D'Oliveiro <ldo@nz.invalid> writes:
On Fri, 29 Mar 2024 22:40:35 GMT, Scott Lurndal wrote:
[*] 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.
On Sat, 30 Mar 2024 01:26:28 +0000, Scott Lurndal wrote:
Lawrence D'Oliveiro <ldo@nz.invalid> writes:
On Fri, 29 Mar 2024 22:40:35 GMT, Scott Lurndal wrote:
[*] 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.
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'!
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).
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.
On Sat, 30 Mar 2024 15:34 +0000 (GMT Standard Time), John Dallman
wrote:
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.
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.
On 2024-03-30, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
Pretty soon, the only stuff left standing will be Open Source.
...whatever MICROS~1 defines that to be...
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.
_Open source_ does not preclude _commercial_.
In article <uuaafd$1a584$1@dont-email.me>, ldo@nz.invalid (Lawrence D'Oliveiro) wrote:
_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.
On Sun, 31 Mar 2024 00:09 +0000 (GMT Standard Time), John Dallman wrote:
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”.
Pretty soon, the only stuff left standing will be Open Source.
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.
Lawrence D'Oliveiro <ldo@nz.invalid> writes:
On Sun, 31 Mar 2024 00:09 +0000 (GMT Standard Time), John Dallman wrote:
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.
| Sysop: | Tetrazocine |
|---|---|
| Location: | Melbourne, VIC, Australia |
| Users: | 6 |
| Nodes: | 8 (0 / 8) |
| Uptime: | 16:39:19 |
| Calls: | 45 |
| Files: | 21,492 |
| Messages: | 62,947 |