[YeGoblynQueenne]

>> They tried to rewrite the core apps but it was impossible to do so and get the performance.

Well, Cobol is a bit like the C of mainframes - you can manipulate memory directly and so on. You can't really do that sort of thing with Java.

[stefs]

a) if it was really running on the old hardware; in that case ruby on a modern machine would have been several magnitudes faster than the original code - at least because of the faster IO

b) if the whole thing was indeed running in an emulator, the emulation overhead would have negated all direct memory access advantages

[wahern]

Emulators on mainframes are much more sophisticated and performant than is typical on x86 and ARM platforms. The hardware and even software is often designed with emulation in mind, not just for backwards compatibility but for forwards compatibility, too.

[andai]

Do you mean to say that they were running a mainframe emulator on a mainframe?

[wahern]

Compilers for some IBM mainframes have for decades (since the 1970s, I think) targeted an intermediate virtual machine instruction set which is then translated on-the-fly to the local architecture by the OS upon execution. So in the case of IBM their machines are truly built with both forward and backward compatibility in mind. The pointers for this instruction set have been 128 bits since the beginning, long before 64-bit hardware even came into being.

Some (or all?) of the latest Unisys mainframes run on Intel Xeons, but with custom chips for translating the machine code of their old architectures.

I don't work in this area. I just like reading about it. Though, unfortunately, it's difficult to find clear specifications and descriptions on how these architectures work.

For example, Unisys' 2200 ClearPath architecture is one of the (if not _the_) last architectures still sold that uses signed-magnitude representation, as well as having an odd-sized integer width of 39 bits. (INT_MAX is 549755813887 and INT_MIN is -549755813887, and the compiler has to "emulate" the modulo arithmetic semantics required of unsigned types in C. ClearPath MCP is also a POSIX system, and has to emulate an 8-bit char type.) I discovered that you could download the specification for their C compiler for free online, which was useful when discussing the relevancy of undefined behavior in C. But AFAIU (and this is where finding concrete details is more difficult) the latest models of the ClearPath line use Xeons with custom chips bolted on to help run the machine code of the older architecture. In any event, the point is that while the old architecture is arguably emulated, it's not a pure software emulation that you might assume, and the resulting performance is better than the previous models of those mainframes, which were still being built at least until a few years ago. In other words, direct memory access isn't ruled out because the I/O systems may have been intentionally designed to work efficiently in a backwards compatible manner.

[dfox]

The 128bit pointer intermediate code is used on what IBM calls "midrange systems" (ie. AS/400), not mainframes. IBM mainframes execute their machine code directly and the ISA is designed such that it allows for efficient virtualization since beginning and is extensible and backwards-compatible. Otherwise the IBM mainframe magic is in IO offload and truly immense memory bandwidth. On the other hand, Unisys systems use architecture that is significantly different from what today's programmer would expect, with completely different memory model originally implemented in hardware (which essentially combines the memory protection model implemented on AS/400 in software with lisp machine-style pointer tagging).

[abakker]

Excellent comment. I'll also point out that system z mainframes are not slow machines, so even with some emulation overhead there is typically enough performance.

[vidarh]

Yes, but good luck translating any sizeable chunk of code to a higher level language without a massive effort figuring out which things are discarded side-effects that can be ignored and which things are relied on later. I just spent a few hours last night massaging a C-translation from 6502 assembler. It's a tiny piece of code - ~3000 lines that'll probably shrink to ~2500 or so as I figure out which results are ignored (the original translation attempted to do a faithful 1-1 translation instruction by instruction, which leads to things like long sequences to handle basic multiplication etc.), but it takes ages, because it is not always obvious when it e.g. depends on the status flags set, and values keep being moved between registers etc. Now try doing that with a big piece of code.

There's a reason why people often resort to emulators.