On Mon, 26 Feb 2024 21:29:59 -0000 (UTC)
Thomas Koenig <tkoenig@netcologne.de> wrote:

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

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.

--
Steve O'Hara-Smith
Odds and Ends at http://www.sohara.org/
For forms of government let fools contest
Whate're is best administered is best - Alexander Pope

John Levine <johnl@taugh.com> schrieb:
> 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.

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?

According to Thomas Koenig <tkoenig@netcologne.de>:
>>>> 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.

--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

John Levine <johnl@taugh.com> writes:
>
> 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

--
virtualization experience starting Jan1968, online at home since Mar1970

On Thu, 22 Feb 2024 19:46:07 GMT, Charlie Gibbs wrote:

> Thread drift is an honoured tradition in this newsfroup.

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

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

> Back around 1970, this FORTRAN program would crash OS/360:

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.

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.

On 23 Feb 2024 19:32:17 GMT, Stefan Ram wrote:

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

According to Lawrence D'Oliveiro <ldo@nz.invalid>:
>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.

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.

--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

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.

On Fri, 29 Mar 2024 20:50:41 -0000 (UTC)
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:

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

--
Bah, and indeed Humbug.

On Fri, 29 Mar 2024 21:36:28 +0000
"Kerr-Mudd, John" <admin@127.0.0.1> wrote:

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

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.

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

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

--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

According to Kerr-Mudd, John <admin@127.0.0.1>:
>> 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.

--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

On Fri, 29 Mar 2024 21:50:11 +0000, John Levine wrote:

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

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.

--
Using UNIX since v6 (1975)...

Use the BIG mirror service in the UK:
http://www.mirrorservice.org

On Fri, 29 Mar 2024 21:36:28 +0000
"Kerr-Mudd, John" <admin@127.0.0.1> wrote:

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

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.

--
Steve O'Hara-Smith
Odds and Ends at http://www.sohara.org/
For forms of government let fools contest
Whate're is best administered is best - Alexander Pope

Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>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.

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

Scott Lurndal <scott@slp53.sl.home> wrote:
> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>> 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.
>
>> 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.

> [*] 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).
>

--
Pete

Peter Flass <peter_flass@yahoo.com> writes:
>Scott Lurndal <scott@slp53.sl.home> wrote:
>> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>>> 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.
>>
>>> 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.

On Fri, 29 Mar 2024 21:50:59 -0000 (UTC), John Levine wrote:

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

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.

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.

--
Using UNIX since v6 (1975)...

Use the BIG mirror service in the UK:
http://www.mirrorservice.org

On Sat, 30 Mar 2024 09:57:52 +0000, Bob Eager wrote:

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

That should read '1964'!

--
Using UNIX since v6 (1975)...

Use the BIG mirror service in the UK:
http://www.mirrorservice.org

On 30 Mar 2024 10:51:14 GMT
Bob Eager <news0009@eager.cx> wrote:

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

--
Steve O'Hara-Smith
Odds and Ends at http://www.sohara.org/
For forms of government let fools contest
Whate're is best administered is best - Alexander Pope