"Phil W Lee" phil(at)lee-family(dot)me(dot)uk wrote in message
...

It wasn't just the names being different at ICL though, they did some
strange stuff all of their own.

I heard that management insisted on the General Origin of Data (the
operating system's initial global pointer) being renamed.

--
Tim Ward - posting as an individual unless otherwise clear
Brett Ward Limited - www.brettward.co.uk
Cambridge Accommodation Notice Board - www.brettward.co.uk/canb
Cambridge City Councillor

On 25/06/2010 20:30, dennis@home wrote:
"Jon Green" wrote in message
...
So now you've got three sets of kit! Primary, local mirror, off-site
hot spare.)

Four, the off-site kit should be a replicate of the main site so you can
use it to provide the same service.

Depends whether your objective is to mirror exactly what was there
before, or simply to serve the files. If the latter, the three sets
will do, and you can go off and buy a new hot mirror once you've the
shelf unit online.

We had fully functioning SystemX exchanges inside containers so we could
park one outside and exchange, connect up the trunks, etc. and away you go.

Yeah, I know a lot of different setups that take that approach, from
temporary mobile phone base stations to entire shippable machine rooms.
Not to mention deployable operating rooms, MRI/CAT units and mobile
morgues for disaster management. It's a handy paradigm.

Jon
--
SPAM BLOCK IN USE! To reply in email, replace 'deadspam'
with 'green-lines'.
Blog: http://bit.ly/45cLHw Pix: http://bit.ly/d8V2NJ
Website: http://www.green-lines.com/

In message , at
17:03:06 on Fri, 25 Jun 2010, Jon Green remarked:
The answer to that is to lay in spare parts at the same time as the
order for the RAID unit. Yes, it increases the initial cost, but at
least you know you have the spares available in five years' time.

The best RAID controllers build that in - they have one or two spare
drives configured in, that don't initially store any data, but can be
swapped in when needed.

I suspect that Mike meant more than just the drives. If you're dealing
with mission-critical data, it's imperative to keep a hot spare RAID
box too, in secure storage away from the building, so that you can
bring up the data set ASAP after a RAID main board failure. There's
absolutely no guarantee that the drive set will work together in a
different model or make -- in fact, it's pretty-much certain they won't.

The RAID controller in one of my servers does exactly that, it imports
the drive characteristics (and hence the total storage characteristic)
from whatever is plugged in. But I agree it may have to be the same
make, but as that's Compaq it's not a huge issue.
--
Roland Perry

In article ,
Clive George wrote:

Hot spares. And they're supplied under a contract where replacements get
delivered to you in a few hours. The maintenance contract pays for their
stockpiling of old drives. And if the small stuff really does disappear,
it copes with putting a larger drive in instead. (wastes the space, but
works).



It's interesting, but I've dealt with all sorts of disk arrays over the
last 15 years or so and it seems that while this becomes true of midrange
kit as you get to the higher end, spare replacement becomes less urgent
again.

DotHill/Sun 3510 arrays - replacement disks sent to site within 4 hours.

HDS AMS/USPs - disks sent next working day (or even slower).

Admittedly, in our large enterprise arrays we do have many roaming spares
(and often RAID 6) so I guess it's just deemed less important. Can't say
it's ever been a problem though. No point sending a disk within hours
when the machine spares out without problem and still has plenty of
resilience.

Controller failures however, they tend to respond to those pretty
quickly ;-)

Darren

On 25/06/2010 21:18, Phil W Lee wrote:
Jon considered Fri, 25 Jun 2010 18:22:54
+0100 the perfect time to write:
That'll work...so long as the backup RAID isn't totalled by the same
fire or power surge that nargled the primary!

When I last did that, the RAIDs were in Tulsa and Ely, so not too much
chance of them both being wiped out by the same disaster.

I assume the data set change over time wasn't all that great then,
otherwise shadowing would have been a running battle!

Jon
--
SPAM BLOCK IN USE! To reply in email, replace 'deadspam'
with 'green-lines'.
Blog: http://bit.ly/45cLHw Pix: http://bit.ly/d8V2NJ
Website: http://www.green-lines.com/

In article ,
dennis@home wrote:

So now you've got three sets of kit! Primary, local mirror, off-site hot
spare.)

Four, the off-site kit should be a replicate of the main site so you can use
it to provide the same service.

Not always...

Our offsite rep is much lower spec to save money. Decision might be that
in a true DR situation with total loss of our primary DC that getting a
few key services up quickly would be important - the rest could wait.

A full same spec replica wasn't deemed cost effective. Not that uncommon.

Darren

On 25/06/2010 22:14, Huge wrote:
On 2010-06-25, Jon wrote:
On 25/06/2010 17:28, Clive George wrote:
On 25/06/2010 17:03, Jon Green wrote:

I suspect that Mike meant more than just the drives. If you're dealing
with mission-critical data, it's imperative to keep a hot spare RAID box
too, in secure storage away from the building, so that you can bring up
the data set ASAP after a RAID main board failure. There's absolutely no
guarantee that the drive set will work together in a different model or
make -- in fact, it's pretty-much certain they won't.

Once you're doing that you may as well have the second RAID (or rather
filer) mirrored from the first, and have a truly hot DR system.

That'll work...so long as the backup RAID isn't totalled by the same
fire or power surge that nargled the primary!

Umm, the backup RAID needs to be in your DR site ...

Depends what you're trying to achieve. If you want to get the RAID
services up and running again ASAP when the main controller cooks off,
then having the backup onsite ready to go hot makes sense.

Probably, as I'd commented to Clive, for best coverage you have primary,
onsite shadow, and offsite shadow, for increasingly severe DR.

Jon
--
SPAM BLOCK IN USE! To reply in email, replace 'deadspam'
with 'green-lines'.
Blog: http://bit.ly/45cLHw Pix: http://bit.ly/d8V2NJ
Website: http://www.green-lines.com/

On 25/06/2010 21:40, Roland Perry wrote:
The RAID controller in one of my servers does exactly that, it imports
the drive characteristics (and hence the total storage characteristic)
from whatever is plugged in. But I agree it may have to be the same
make, but as that's Compaq it's not a huge issue.

I'd say you need a full hardware dupe in hand -- unless you're prepared
to bet your job that some other controller could take in your disk set
and use it without error or corruption! -- and you've tested it up, down
and sideways first, to be sure!

It's the usual conundrum: if you insist on a full dupe setup that may
never be used, you'll be called out for being profligate -- but if you
didn't, and you're now faced with a mission-critical filestore off-line
for hours at least, possibly a day or two, you'll be in deep %^&*, and
the bean-counter who talked you out of it will be uncharacteristically
silent.

Jon
--
SPAM BLOCK IN USE! To reply in email, replace 'deadspam'
with 'green-lines'.
Blog: http://bit.ly/45cLHw Pix: http://bit.ly/d8V2NJ
Website: http://www.green-lines.com/

On 25/06/2010 22:14, Huge wrote:
On 2010-06-25, Jon wrote:
On 25/06/2010 16:04, Huge wrote:
Nor indeed, my precious collection of techno-junk. I expect somone, somewhere
will want it. As I said, the PDP11 and other assorted computing relics
already went to Bletchley Park.

Sadly, my beloved 11/70

Ooh, big iron! Mine was just an 11/23+

Four steaming full-height cabs of it! Converted to single-phase, from
the original three. If I fired them all up at once, domestic ring main
dropped to about 50V (at a guess). Them big disks took a huge
instantaneous current to spin up.

Didn't take long to work out a staged boot procedure...

The annoying thing is that I was getting magtapes of data from NASA at
the time. But NASA wrote them at 6250bpi, and my tape cab only grokked
1600, so I had a pal at Glasgow Uni down-rate them for me.

When (a) I got a PC, and (b) NASA started producing the data on CD-ROM,
things got a _lot_ easier!

Jon
--
SPAM BLOCK IN USE! To reply in email, replace 'deadspam'
with 'green-lines'.
Blog: http://bit.ly/45cLHw Pix: http://bit.ly/d8V2NJ
Website: http://www.green-lines.com/

On 25/06/2010 21:11, Roland Perry wrote:
In message , at
16:47:11 on Fri, 25 Jun 2010, Jon Green remarked:
If you aren't careful, I'll start talking about delay-line memory ;-)

Mercury, I should hope ... the One True DLM!

No, the one I have is acoustic.

Oh, the springy thingy?

Jon
--
SPAM BLOCK IN USE! To reply in email, replace 'deadspam'
with 'green-lines'.
Blog: http://bit.ly/45cLHw Pix: http://bit.ly/d8V2NJ
Website: http://www.green-lines.com/

On 25/06/2010 22:23, Jon Green wrote:
On 25/06/2010 22:14, Huge wrote:
On 2010-06-25, Jon wrote:
On 25/06/2010 17:28, Clive George wrote:
On 25/06/2010 17:03, Jon Green wrote:

I suspect that Mike meant more than just the drives. If you're dealing
with mission-critical data, it's imperative to keep a hot spare
RAID box
too, in secure storage away from the building, so that you can
bring up
the data set ASAP after a RAID main board failure. There's
absolutely no
guarantee that the drive set will work together in a different
model or
make -- in fact, it's pretty-much certain they won't.

Once you're doing that you may as well have the second RAID (or rather
filer) mirrored from the first, and have a truly hot DR system.

That'll work...so long as the backup RAID isn't totalled by the same
fire or power surge that nargled the primary!

Umm, the backup RAID needs to be in your DR site ...

Depends what you're trying to achieve. If you want to get the RAID
services up and running again ASAP when the main controller cooks off,
then having the backup onsite ready to go hot makes sense.

Probably, as I'd commented to Clive, for best coverage you have primary,
onsite shadow, and offsite shadow, for increasingly severe DR.

It's possibly more likely that we'll lose a site than we'll lose a RAID
controller/filer - comms (think JCB), air con, power seem flakier than
our decent hardware :-)

Primary and offsite DR/shadow works well for us. The filers can cope
with loss of quite a lot - redundant raid controller/head, obviously
RAID 6 + hot spare disks, redundant SAN kit. Also the offsite DR is good
enough to be used live. I don't think it's worth spending any more on a
full onsite mirror.

'Course we're not really talking about simple file servers here :-)

On Fri, 25 Jun 2010 22:14:00 +0100, Tim Streater wrote:

Could you define what's meant by "multiprogramming support" in this
context?

Two operating modes - user and executive. Or did I get it wrong and the
4120 had that too? Enter user mode with the EXIT instruction, and
system call back with the EXEN instruction...

Yeah, OK, that's pretty common. I guess I never heard it called that
before. But the I never used any ICL kit.

There's obvioously more, if it is to be useful, but that's a good start.

We had a Honeywell DDP-516 that had a two-mode operation, but it was
useless as (for example) there was no way of telling the previous state
when an interrupt had occurred, so you couldn't restore state. Quite a
lot of other holes too. I rewired the CPU to fix the variouls issues.



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

*lightning protection* - a w_tom conductor

On Sat, 26 Jun 2010 00:14:37 +0100, Tim Streater wrote:

In article ,
Bob Eager wrote:

On Fri, 25 Jun 2010 22:14:00 +0100, Tim Streater wrote:

Could you define what's meant by "multiprogramming support" in
this context?

Two operating modes - user and executive. Or did I get it wrong and
the 4120 had that too? Enter user mode with the EXIT instruction,
and system call back with the EXEN instruction...

Yeah, OK, that's pretty common. I guess I never heard it called that
before. But then I never used any ICL kit.

There's obvioously more, if it is to be useful, but that's a good
start.

We had a Honeywell DDP-516 that had a two-mode operation, but it was
useless as (for example) there was no way of telling the previous state
when an interrupt had occurred, so you couldn't restore state. Quite a
lot of other holes too. I rewired the CPU to fix the variouls issues.

Blimey wot was the point of that then (designing it that way, I mean).

You prolly want to be able to designate memory as no-access, read-only,
read/write, and execute-only, too (as well as mapping it).

I remember going to a presentation on the then-new 68000 in 1979 where
folks were asking about such features (and also what you mentioned), but
the Motorola guy said that they figured it would take too much space on
the chip. Turns out that later, when they looked into it, it didn't add
much extra at all.

It was only a little 16 bit machine, predating the PDP-11. Thousands of
them were node processors on ARPANet.

No idea why they did it like that...but history is littered with half
baked solutions. I would guess cost. The 386 didn't correctly trap
certain instructions, it just made them no-ops...which means hardware
virtualisation wasn't possible. That fed through up to Pentiums quite
recently. Now there's yet another operating mode to select to make it
work as it should have done.

(this rather ignores the fact that partial software virtualisation can
actually be more efficient anyway!)



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

*lightning protection* - a w_tom conductor

In message , at
22:44:26 on Fri, 25 Jun 2010, Jon Green remarked:
No, the one I have is acoustic.

Oh, the springy thingy?

Inside there's a couple of large loops, technically it's a coil, but
that's a confusing way to describe it.
--
Roland Perry

"Tim Streater" wrote in message
...
In article ,
Bob Eager wrote:

On Fri, 25 Jun 2010 22:14:00 +0100, Tim Streater wrote:

Could you define what's meant by "multiprogramming support" in this
context?

Two operating modes - user and executive. Or did I get it wrong and
the
4120 had that too? Enter user mode with the EXIT instruction, and
system call back with the EXEN instruction...

Yeah, OK, that's pretty common. I guess I never heard it called that
before. But then I never used any ICL kit.

There's obvioously more, if it is to be useful, but that's a good start.

We had a Honeywell DDP-516 that had a two-mode operation, but it was
useless as (for example) there was no way of telling the previous state
when an interrupt had occurred, so you couldn't restore state. Quite a
lot of other holes too. I rewired the CPU to fix the variouls issues.

Blimey wot was the point of that then (designing it that way, I mean).

IME you add some "useful" hardware feature and the programmers can't grasp
how to use so it just sits there untested and never gets fixed if its
broken.
I've been there.. I designed part of a redundant processor system where each
CPU could monitor the interrupts and the responses on the other CPUs. So if
an interrupt occurred and the CPU running the lowest priority process didn't
respond another would kick off a fault interrupt. The hardware worked great
but the idea was too hard for the "software" and it got removed during
testing. Intel later infringed the patent I had on interrupting the lowest
priority "CPU" but because we didn't use the idea someone decided the to let
the patent lapse.


You prolly want to be able to designate memory as no-access, read-only,
read/write, and execute-only, too (as well as mapping it).

I remember going to a presentation on the then-new 68000 in 1979 where
folks were asking about such features (and also what you mentioned), but
the Motorola guy said that they figured it would take too much space on
the chip. Turns out that later, when they looked into it, it didn't add
much extra at all.

I expect the machine predates the 68000.
Motorola completely mucked up the MMU they designed. They went through
several versions before they got one that worked properly and put it in the
68030.

In the meantime Intel had produced the 386 which had a working paged MMU in
it and that was what later became the normal way of doing paged memory on
Unix and the likes. Prior to that nearly every Unix machine had different
paging mechanisms.

"dennis@home" wrote in message
...

IME you add some "useful" hardware feature and the programmers can't grasp
how to use so it just sits there untested and never gets fixed if its
broken.

OTOH ... once upon a time a hardware designer designed a "useful" hardware
feature which he thought would aid the programmers but actually made things
vastly more difficult. I persuaded him to change to a much simpler hardware
design that made the software easier, smaller and faster. So some
communication between the two helps sometimes.

--
Tim Ward - posting as an individual unless otherwise clear
Brett Ward Limited - www.brettward.co.uk
Cambridge Accommodation Notice Board - www.brettward.co.uk/canb
Cambridge City Councillor

Bob Eager wrote:
On Fri, 25 Jun 2010 15:25:43 +0000, Huge wrote:

On 2010-06-25, Roland wrote:
In , at 09:56:04 on Fri, 25
Jun 2010, remarked:
In mid 70's I worked on ICL drives, including something they called a
"drum", which was a single-platter mounted vertically.

You sure it was a "platter"? Only, when I worked for ITT in around
1975/6 (on what became the Unimat 4080 telephone switch), the message
switches that we shared our computer room with definitely had drums
that were drum shaped.

Absolutely sure.

It appears that ICLs weird storage topology terminology was unknown to
me. Not surprising. I was a MUMPS programmer roped in to help rewrite
ATV's payroll system in RPG2 (spit) and port it from a 1904S (I think)
to a 2903. That was my only exposure to ICL kit - I left shortly
afterwards to return to my beloved PDP11s and trying to weigh flying
crisps.

I think that's right, though....ICL did keep a lot of old terminology
around. As well as inventing new stuff - like the CPU becoming an OCP
(Order Code Processor)

Ah, but the CPU was the whole box. The OCP was the 'mill'.

"Tim Ward" wrote in message
...
"dennis@home" wrote in message
...

IME you add some "useful" hardware feature and the programmers can't
grasp how to use so it just sits there untested and never gets fixed if
its broken.

OTOH ... once upon a time a hardware designer designed a "useful" hardware
feature which he thought would aid the programmers but actually made
things vastly more difficult. I persuaded him to change to a much simpler
hardware design that made the software easier, smaller and faster. So some
communication between the two helps sometimes.

Oh communication doesn't always help.
There can be complete agreement that its a good idea and it can still get
thrown out when someone decides its going to take 100 man years of effort to
write the code (and I kid you not).

Pseudo code for the item in question..
get fault interrupt
read hardware registers to see what it is thought was wrong
log it
decide action if any.

On Sat, 26 Jun 2010 12:09:45 +0100, Rupert Moss-Eccardt wrote:

I think that's right, though....ICL did keep a lot of old terminology
around. As well as inventing new stuff - like the CPU becoming an OCP
(Order Code Processor)

Ah, but the CPU was the whole box. The OCP was the 'mill'.

Well, on our machine the three boxes were marked 'OCP'!
--
Use the BIG mirror service in the UK:
http://www.mirrorservice.org

*lightning protection* - a w_tom conductor

Andy Burns wrote:

http://www.cgsecurity.org/wiki/PhotoRec

Will pick the bits of recoverable files out of the smouldering
remnants, but it only recognises certain formats.

http://www.cgsecurity.org/wiki/TestDisk

better util from same source - in my limited but grateful experience it's
very capable.

In article , Steve Walker spam-
scribeth thus
Andy Burns wrote:

http://www.cgsecurity.org/wiki/PhotoRec

Will pick the bits of recoverable files out of the smouldering
remnants, but it only recognises certain formats.

http://www.cgsecurity.org/wiki/TestDisk

better util from same source - in my limited but grateful experience it's
very capable.



Did try that but most ever sector segment etc came up with unable to
read..
--
Tony Sayer

Clive George wrote:

It's possibly more likely that we'll lose a site than we'll lose a RAID
controller/filer - comms (think JCB), air con, power seem flakier than
our decent hardware :-)

Primary and offsite DR/shadow works well for us. The filers can cope
with loss of quite a lot - redundant raid controller/head, obviously
RAID 6 + hot spare disks, redundant SAN kit. Also the offsite DR is good
enough to be used live. I don't think it's worth spending any more on a
full onsite mirror.

'Course we're not really talking about simple file servers here :-)

We got lucky last year. The upstairs aircon burst a pipe and dropped
several thousand gallons of cooling water all over our office. It
wrecked a whole lot of screens, one or two PCs (Luckily most of us keep
our PCs under the desks, and the desks acted as umbrellas), and somehow
managed not to leak through the ceiling over the server room. It was
the unique kit in the test lab that really scared us.

We still lost a week's work, despite losing no critical systems. And a
lot of desks!

Andy