Comment by tyingq | Hacker News Reader

Comment by tyingq | Hacker News Reader

Parent Full thread

"Mainframe" usually meaning you have legacy code that requires something that only runs in that environment. Like the TPF OS that Visa, Sabre, and many airlines use. Or z/OS things like CICS, Adabas, IDMS, IMS, VSAM, JCL, heavily mainframe flavored COBOL, 360 Assembler, etc.

That is, the only driving requirement left for IBM mainframes is your own software that depends on system software that only exists on IBM mainframes.

Same reason some people still use other old environments like HP MPE, IBM AS/400, and Tandem Nonstop, and so on. They have found, thus far, that the cost of doing that is less than the cost of rewriting it. Or they have been unable to do that for reasons other than cost.

Edit: Separately, there are still some technical advantages. z/OS mainframes have a level of "within the rack" redundancy that you won't find in commodity servers. Or, with TPF, it's difficult to engineer a solution that scales as well and remains reliable...it's a very battle tested distributed K/V store that deals with heavy write contention.

Really hard to replicate Tandem Nonstop's feature set if that was what you actually needed.

Of course part of the reason it faded away (indeed, was gradually fading away even when I worked for Tandem) is that almost nobody does need that sort of reslience.

Loma Prieta Earthquake, day 2.

Bank calls the Tandem support line: "Our computer is down. It crashed! How do we get it back up?"

It wasn't offline. It had fallen over, punching through some of the sections of the raised floor.

360 Assembler was the second (and last) assembly I learned (after 6502¹). Gotta love an architecture that requires you to maintain your own call stack for subroutines. Or that has CPU-level instructions to move integers to and from EBCDIC strings.

--- 1. Well, I guess second-and-a-half. I played a little with Z-80 on my Spectravideo computer, but mostly that was writing a disassembler in MSX basic to reverse-engineer how the system worked after it was abandoned by its manufacturer. The disassembler was never finished because I didn't properly manage the multibyte opcodes.

It's all software and not hardware?

The redundancy part of mainframes is hardware. You can live swap a CPU, for example.

That's an aside though. The reason people keep buying them is software lock in, yes. There's a reason Amazon likes to push their proprietary services...they are the new mainframe.

IBM has amazing support software for mainframes. Their fix tool, for example (SMTP/E) makes individual tapes for each customer to ensure that fixes go on correctly. All the dependencies are resolved for that individual customer by IBM before the tape ships. That's one-on-one service that makes sure your machine doesn't go down from a patch.

In a high availability environment (like banking or airline reservations, as mentioned), mainframes never go off, even during upgrades. When physical machines need replacement, the entire system is run in parallel on a second machine.

These boxes have both incredible I/O hardware (there's never been anything like IBM channel I/O) and the software to keep everything humming. On a typical day when I worked there, we'd have a 1,000 devs using the same box (and that was a small installation) with multiple operating systems, virtualizations, etc. with zero hiccups.

IBM also has amazing software for getting stuff done. Documentation, for example, is universal and available worldwide from any terminal. When you want a printed manual, the system figures out which big, fast printer is near you and offers to print it down the hall. Every IBM employee has access to all the company's resources from every terminal, and it all just works.

Yes, PCs have caught up to emulating many of these features, but they definitely don't have the robustness or ease of use that System/370 (z/OS) did.

Reply on news.ycombinator.com