Slashdot Mirror

AFIK, mainframes do not run in lockstep. AFIK, Stratus Technologies is the only vendor you can buy a system the runs in lockstep from. Stratus VOS systems do support COBOL, BTW -- on ia32 hardware. You can probably buy COBOL compilers for modern operating systems from other vendors, too (I've seen evidence that at least 2 vendors are working on it).

As others have pointed out, recompiling the code is going to be a lot easier than figuring out exactly what it does and recoding it in another language. COBOL is going be particularly challenging to port away from: Syntactically, COBOL is nothing to be proud of, but it does give users access to a lot of things that nothing mainstream really does. Like ISAM file systems and decimal arithmetic (which can be implemented using binary and a lot of multiplies and divides by 10). If you are going to translate COBOL into another language, you need to implement a lot of the infrastructure the compiler depends on. That will take years and needs a programming staff that is competent enough to read the standards documents.

maybe you should do a little research, because I did.
http://www.stratus.com/news/2005/20050314a.htm Do you notice something? They installed windows due to defining it as an "open platform". They were deceived. This is the result.

Stratus was chosen as best able to provide an open platform with 99.999 percent uptime reliability – which is mandatory for running an application as important as NADIN 1 – together with the required caliber of maintenance, logistical support, and long service life.

Link to deployment announcement about "modernization" of airspace network.

http://www.stratus.com/news/2005/20050314a.htm

ECC can only correct 1-bit errors. It can't correct 2-bit errors (only detect them) and can't even detect nor correct 3-bit (or more) errors.

No, that's just one kind of memory system. There are a number of designs, and recovery also depends on the kind of error. IIRC, one design is somewhat similar to the CD Red Book spec, in that the bits for a given byte are distributed around - a physical byte is composed of bits all from different memory locations. If part or all of one byte goes bad, the rest of the bits and the parity code are unchanged, and the affected bytes can be reconstructed.

Also like Red Book CDs are multiply redundant memory systems, with -just what it sounds like- multiple copies of each byte, and the memory controller arbitrates differences. CDs effectively contain three copies of the data, striped and parity encoded. That's how scratched CDs can still operate error-free (sometimes.) The space shuttle's computer systems are relatively fault-tolerant - multiple redundant computers all running the same programs and data, with a fourth computer evaluating the output of the other computers, looking for failures.

Where there's a will, there's a way, but the will in the mainstream x86 server industry to build truly fault-tolerant computers is slim. It's a specialty, and that makes it very expensive. Stratus, for example, makes a line of fault-tolerant servers, with some of the fail-over in hardware, so they make their 99.999% uptime claim (about 5 minutes downtime per year.)

"Five nines" is a claim I've heard from most top-dollar *nix hosting companies, but have *never* experienced - it's generally been hours of downtime per year. Not even their network infrastructure gets close to 99.999% uptime! Cadillac prices, but downtime contingency planning is all up to the client, even with "managed hosting." They all suck.

ECC can only correct 1-bit errors. It can't correct 2-bit errors (only detect them) and can't even detect nor correct 3-bit (or more) errors.

No, that's just one kind of memory system. There are a number of designs, and recovery also depends on the kind of error. IIRC, one design is somewhat similar to the CD Red Book spec, in that the bits for a given byte are distributed around - a physical byte is composed of bits all from different memory locations. If part or all of one byte goes bad, the rest of the bits and the parity code are unchanged, and the affected bytes can be reconstructed.

Also like Red Book CDs are multiply redundant memory systems, with -just what it sounds like- multiple copies of each byte, and the memory controller arbitrates differences. CDs effectively contain three copies of the data, striped and parity encoded. That's how scratched CDs can still operate error-free (sometimes.) The space shuttle's computer systems are relatively fault-tolerant - multiple redundant computers all running the same programs and data, with a fourth computer evaluating the output of the other computers, looking for failures.

Where there's a will, there's a way, but the will in the mainstream x86 server industry to build truly fault-tolerant computers is slim. It's a specialty, and that makes it very expensive. Stratus, for example, makes a line of fault-tolerant servers, with some of the fail-over in hardware, so they make their 99.999% uptime claim (about 5 minutes downtime per year.)

"Five nines" is a claim I've heard from most top-dollar *nix hosting companies, but have *never* experienced - it's generally been hours of downtime per year. Not even their network infrastructure gets close to 99.999% uptime! Cadillac prices, but downtime contingency planning is all up to the client, even with "managed hosting." They all suck.

Ok. I found it. THIS IS WHY THE HARDWARE EMULATION IS SO FREAKING HARD:

ftp://ftp.stratus.com/pub/vos/multics/pg/mvm.txt

"The 635 and 645 also had instructions to execute single
instructions or pairs of instructions. These could be used to
ensure atomicity as well; interrupts would happen only after the
instruction, or pair of instructions, had completed. Yet on the
645 these instructions could also take linkage, segmentation, or
page faults...and these faults were restartable! The 635 and 645
repeat (and repeat-double) instructions WERE interruptible, but
only after each instruction or pair of instructions. As a
result, the 645 machine state information was considerably larger
and more complex than the 635 machine state. The ability to
handle interrupts and/or restartable faults during these
particular instructions is arguably the hairiest aspect of of the
(pre-6180-EIS) hardware design, and was the source of many subtle
hardware bugs."

Either instruction of a two instruction pair could be intruped by a page fault, and could be restarted.
1. Very reliable.
2. Some times slow.
3. extremely flexable.
But as the author states...it was the sounce of many subtle hardware bugs.

You could take a linkage fault, stop the program. copy the library from tape into core, and restart the process! ( do THAT LINUX! )

A large and fully redundant fault tolerant server is more flexible. Use virtualization and have many reliable servers of many different operating systems in one unit as opposed to a highly specialized cluster.

For certain tasks, clustering will certainly offer a performance advantage from a scalability standpoint. Yet a fully fault tolerant hardware system like from Stratus offers just a touch more reliability than a fault tolerant software system.

Yuk yuk yuk..

We work with these things all the time. You can yank CPUs while its running and it won't even hiccup. You can open the side of the case and take a whiz in it, and the machine will keep chugging. Cool stuff.

They apparently have permission to modify Windows source to make that stuff work, but linux support would be nice.

Yeah.

Still trucking Multics spin-off Stratus VOS (see that little Multics link at the bottom?) has a lot (all?) of these "scalability" features. Worked nicely on a 6-way server in 1986 anyway, great little system.

No, that stuff exists in the PC world. Linux support for it doesnt.

Stratus' homepage advertises Ultra High Availability Servers. Built around Pentiums and Win2K to be sure, but I fail to see any mention of either Linux or any kind of home-user PC system. Their lowest-end box, the ftServer 3200, is spec'd with 1 or 2 800MHz PIIIs, comes with 2 10/100 and 2 Ultra/160 controllers on the mobo, and has hot-swap everything (PSUs, PCI, fans, disks, CPUs). Sounds like a low-end server offering from Dell or HP uprated with hotswap parts (which is a good idea, reliability needn't be that expensive), but it seems about as similiar to a PC as an BMW M3 GT racer is to a roadgoing edition: the engine is about all they have in common.

There are high-end PCs with the same features. We just got one of these bad boys into the shop to test it as a machine to sell our clients for our critical applications. Pretty much everything is redundant. You can hotswap anything in 'em.

Haven't done anything by way of checking linux compatibility with ours, but the drivers are all standard enough.

Unfortunately, the Ace's Hardware article is depressingly accurate about the state of the mainframe in 2002.

But once upon a time there was a company that beat IBM technology like a drum- Burroughs.

IBM invented hard drives (DASD). Burroughs invented multi-programming environments, virtual memory, the first OS written to a high-level language (ALGOL) and a host of other innovations.

Here is the best overview with plenty o' links, here is official Unisys propaganda if you want to poke around, and here
is a Multics guy giving props.

To give you an idea of how advanced Burroughs was, we were able to run DMSII database dumps to tape while the database was active and did perform successful recoveries off those dumps- in 1985.

The console was magnificent, the built-in system logging was a dream, we fired off batch backups and recoveries from plain-English commands at the console, CANDE is a near perfect development environment (I still laugh at Vi vs. Emacs- morons), and WFL makes JCL look like the silly resource batcher it is.

Unfortunately Burroughs never had a decent sales force, then they merged with Sperry to form Unisys (to enrich Blumenthal, May His Name Be Forever Cursed).

They still make mainframes of a sort, A-series emulators that run on monster PC-cluster machines. These same machines are the cluster boxen for NT and Unix you may have seen around, and they are still big in banking, and make their money in services.

Just remember that IBM mainframes are not the only ones around, but they are dominant.

About 1980 Paul Green and (I think) other multicians started a successful fault-tolerant computer company called Stratus, an effective competitor to Tandem. VOS, the OS, was clearly inspired by Multics and had, or rather has, a consistency and reliability unparalleled in Unix.

Its Multics traits include PL/1 as the systems programming language (actually a subset), transparent networking (attach to any device or file anywhere, rather like Apollo Domain), an ancient Emacs port (or clone?) and other useful features like a transactional file system with indexing.

Lots of these expensive machines were sold to banks and other demanding users in the late 80s, there are plenty still around and indeed they're still available.

The boxes were large and well engineered. Quality seemed to be taken very seriously since any crash was a major event - I only remember one OS crash bug in 6 years of working with them. Machines were connected via dialup to the service centre, and core dumps uploaded for analysis automatically (security settings permitting).

All items of hardware, disks, CPU, memory, networking cards were duplicated - except the real-time clock (!) monitored for failures. Any failed device would be removed from service and could be replaced while the system was running - 'go on, pick a board to unplug' demos were always popular.

Coming back to Unix after platform was a pretty rude shock. What horribly eccentric and buggy shell commands! Why does it keep crashing? In many ways I'd quite like to have one today, certainly something like Java would complement it quite nicely.

I'm sure I'd be more of a Unix fan if I'd not worked with something like VOS. All the components in these fault-tolerant machines were hotpluggable, and all device drivers dynamically loadable and reloadable.

I think my favourite feature was the utterly predictable naming of commands - no umount here.

VOS was designed in the late 70s, based on the legendary Multics.

Anyway, the important thing is not to make excuses for the various problems we've inherited but to organize and develop something better.

You say 'financial support' but your examples of contributions - which from my limited experience are accurate - are not monetary.

Most UGs get intangible support. When I ran a group for Stratus users we never got a cent from the vendor, but they might buy sandwiches for the odd meeting if they were feeling generous.

It's a grey area, but users will quickly desert if it goes all promotional and they can't air their grievances.

As was previously stated, these guarantees are more PR than anything but you brought it up....

Oh, never mind... FlashVOS cancelled their 1988 VOS trademark. Oh.. and Stratus VOS also was cancelled, in 1991.

Oh, never mind... FlashVOS cancelled their 1988 VOS trademark. Oh.. and Stratus VOS also was cancelled, in 1991.

It had certain instructions that would only run in the lowest ring

...and, at least in the older processors only in a segment tagged as a segment whose code should run in "master mode"; even most of the ring 0 code couldn't execute privileged instructions - it could only call small routines in one of those segments (said segments were, presumably, inaccessible outside of ring 0). The entry for "privileged mode" in the Multics site (well, mirror site at Stratus, anyway) glossary says:

The GCOS versions of the Multics processors implemented a traditional one-bit hardware user/supervisor distinction: the CPU privileged mode ("master mode" on the 645) enabled system-control instructions, which were otherwise illegal. In Multics, privileged became a bit (see REWPUG) in the [Segment Descriptor Word], effectively ANDed with ring of execution being ring 0. Very few supervisor segments had this bit. Today, modern processors only have rings.

some of the kernel functionality was actually implemented in the processor's hardware and microcode

Hardware and/or microcode - the GE 645 and 6180 had no microcode; the Multics site glossary entry for the 6180 says:

The 6180 processor was among the last of the great non-microcoded engines. Entirely asynchronous, its hundred-odd boards would send out requests, earmark the results for somebody else, swipe somebody else's signals or data, and backstab each other in all sorts of amusing ways which occasionally failed (the "op not complete" timer would go off and cause a fault). Unlike the PDP-10, there was no hint of an organized synchronization strategy: various "it's ready now", "ok, go", "take a cycle" pulses merely surged through the vast backpanel ANDed with appropriate state and goosed the next guy down. Not without its charms, this seemingly ad-hoc technology facilitated a substantial degree of overlap (see Operations Unit) as well as the "appending" (in the dictionary sense) of the Multics address mechanism to the extant 6000 architecture in an ingenious, modular, and surprising way (see Appending Unit). Modification and debugging of the processor, though, were no fun.

It had certain instructions that would only run in the lowest ring

...and, at least in the older processors only in a segment tagged as a segment whose code should run in "master mode"; even most of the ring 0 code couldn't execute privileged instructions - it could only call small routines in one of those segments (said segments were, presumably, inaccessible outside of ring 0). The entry for "privileged mode" in the Multics site (well, mirror site at Stratus, anyway) glossary says:

The GCOS versions of the Multics processors implemented a traditional one-bit hardware user/supervisor distinction: the CPU privileged mode ("master mode" on the 645) enabled system-control instructions, which were otherwise illegal. In Multics, privileged became a bit (see REWPUG) in the [Segment Descriptor Word], effectively ANDed with ring of execution being ring 0. Very few supervisor segments had this bit. Today, modern processors only have rings.

some of the kernel functionality was actually implemented in the processor's hardware and microcode

Hardware and/or microcode - the GE 645 and 6180 had no microcode; the Multics site glossary entry for the 6180 says:

The 6180 processor was among the last of the great non-microcoded engines. Entirely asynchronous, its hundred-odd boards would send out requests, earmark the results for somebody else, swipe somebody else's signals or data, and backstab each other in all sorts of amusing ways which occasionally failed (the "op not complete" timer would go off and cause a fault). Unlike the PDP-10, there was no hint of an organized synchronization strategy: various "it's ready now", "ok, go", "take a cycle" pulses merely surged through the vast backpanel ANDed with appropriate state and goosed the next guy down. Not without its charms, this seemingly ad-hoc technology facilitated a substantial degree of overlap (see Operations Unit) as well as the "appending" (in the dictionary sense) of the Multics address mechanism to the extant 6000 architecture in an ingenious, modular, and surprising way (see Appending Unit). Modification and debugging of the processor, though, were no fun.

The original site is closed due to bandwidth quota restriction.

See alternate location.

The original UNIX approach of using lock files is particularly awful.

The rings of protection concept really did work. But it takes hardware support, which the PDP-11 didn't have, so UNIX, and its successors, don't work that way. They should. It would be easy to have ring hardware today; in fact, Pentium Pro/II/III machines have some of it, unused.

As for scheduling, Multics had Corbato's algorithm from the beginning, while UNIX had a truly awful scheduler for decades.

No actually it's probably a Stratus box. Stratus These guys make crazy redundant hardware/os stuff. If you have a credit card, get a prescripton from CVS, buy anything on QVC it goes through a stratus box.

• VMS has been around a little while and has quite an assortment of abilities.
• Bridges' OS list

• VMS has been around a little while and has quite an assortment of abilities.
• Bridges' OS list

And the main Multics systems known to still be operational is at my brother's "office," DND: Maritime Command, in Halifax, reportedly planned to be decommissioned next June.

And the main Multics systems known to still be operational is at my brother's "office," DND: Maritime Command, in Halifax, reportedly planned to be decommissioned next June.