4 ms·

The thing is that there was a lot about those old systems that was slow, so you were very, very careful how you programmed. You tended not to use vast library s

The thing is that there was a lot about those old systems that was slow, so you were very, very careful how you programmed. You tended not to use vast library stacks, you went close to the metal and you coded in languages like Assembler, COBOL or FORTRAN. I/O was often run through specialised co-processors (such as IBM's channel processors) and the terminals could sometimes help too. I have friends who have been looking after legacy applications for an airline running on Unisys. The core apps for reservation, Cargo booking and weight/balance were written in FORTRAN. In recent times, the front end was written in Java to give web access. They tried to rewrite the core apps but it was impossible to do so and get the performance.

eru 10y ago
> The thing is that there was a lot about those old systems that was slow, so you were very, very careful how you programmed. That's a common sentiment. I wish I could find the quote by someone who made the transition; it was about how happy they were to be able to compile so much quicker, and how getting immediate feedback made them so much more productive.
- 3n7r0pY 10y ago
  The notion of waiting ages for programs to compile or assemble is mostly related to the older hardware. I compile/assemble COBOL and IBM's assembly language on a z13 daily and it's pretty much instantaneous.
  - eru 10y ago
    > The notion of waiting ages for programs to compile or assemble is mostly related to the older hardware. Oh, I was talking more about older ways to organize the data centre: batch vs timeshare processing. https://en.wikipedia.org/wiki/Time-sharing https://en.wikipedia.org/wiki/Time-sharing
YeGoblynQueenne 10y ago
>> 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 10y ago
  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 10y ago
    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 10y ago
      Do you mean to say that they were running a mainframe emulator on a mainframe?
      - wahern 10y ago
        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.

eru 10y ago

> The thing is that there was a lot about those old systems that was slow, so you were very, very careful how you programmed. That's a common sentiment. I wish I could find the quote by someone who made the transition; it was about how happy they were to be able to compile so much quicker, and how getting immediate feedback made them so much more productive.

3n7r0pY 10y ago
The notion of waiting ages for programs to compile or assemble is mostly related to the older hardware. I compile/assemble COBOL and IBM's assembly language on a z13 daily and it's pretty much instantaneous.
- eru 10y ago
  > The notion of waiting ages for programs to compile or assemble is mostly related to the older hardware. Oh, I was talking more about older ways to organize the data centre: batch vs timeshare processing. https://en.wikipedia.org/wiki/Time-sharing https://en.wikipedia.org/wiki/Time-sharing

YeGoblynQueenne 10y ago

>> 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 10y ago
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 10y ago
  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 10y ago
    Do you mean to say that they were running a mainframe emulator on a mainframe?
    - wahern 10y ago
      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.