This part focuses on comparing the mainframe machine language with other systems that were popular between the 70s and 90s. These are primarily x86, 68k, VAX and ARM. Systems 390 and, in particular, Z are considered very fragmentary - the main focus is on system 370.
The first 360 systems began shipping to customers in 1965, and the more advanced 370 systems from 1970. IBM maintains software compatibility with these systems to this day! Surprisingly, before 390 systems, shipped, as you might guess since 1990, mainframes worked with 24-bit addresses, that is, they could address no more than 16 megabytes of memory, the same as, for example, 68000, released in 1979, or 65816or 32016, released in 1982. VAX natively supported 32-bit addressing. The popular 68020 or 80386 processors, which appeared in the mid-1980s, also supported 32-bit addresses. In fact, 16 MB of memory for the best systems of the second half of the 80s was already not enough. However, since 1983, IBM has been producing 370-compatible computers that could, as an extension, use 31 address digits, which eliminated the memory problem for better computers. Unusually and uniquely, these extensions and 390 systems used a 31-bit address rather than a full 32-bit one. In 2000, IBM announced the first Z system to use 64-bit addressing and data. Z systems have been using processor chips since 2008. Since 2007, they have been trying to combine the Z architecture in a single chip with the POWER architecture, but so far unsuccessfully. So far, only Intel has managed to combine CISC and RISC in one chip - Pentium Pro in 1995 became the first chip of its kind.
IBM System / 370-145 with a tape drive 2401 and a printer instead of a display, 1971. It may be surprising that there is no display in this very expensive system despite the fact that televisions have been mass-produced for over 20 years.
By the way, some authorities believe that the first serial personal computer was IBM 5100 , in production since 1975, which could execute system 360 instructions through a hardware emulator. Improved versions of it were produced until the mid-1980s. The Wang 2200 was rather the first, though . At prices (roughly $ 10,000), these first personal computers were clearly not for home use.
IBM 5100, APL variant
With the advent of the IBM PC architecture, which, as it turned out, determined the main direction of development for computing technology for decades, IBM tried in 1983 to combine almost all the then best computer technologies in one PC XT / 370 product: its 370 systems, IBM PC XT, Motorola 68000 and Intel 8087. This XT / 370 could be used as an intelligent terminal to work with a mainframe, like a regular IBM XT, or to directly run mainframe software. Interestingly, the XT / 370 added support for using virtual memory, which required two 68000s. In 1984, with the advent of the PC AT, an improved version of the AT / 370 "personal mainframe" was released, which was about twice as fast as the XT in mainframe mode. / 370. The history of such systems did not end there; since the 90s, similar products have been produced, corresponding to 390 systems.As far as I know, this has not been done for Z systems.
IBM uses a rather unusual business model for its mainframes, in which computers are not sold but rented. One of the advantages of such a model is that it guarantees a constant upgrade of the equipment, the outdated equipment is automatically replaced with an updated one of the corresponding class. This model also has disadvantages. For example, a particularly perceptible disadvantage for those who study the history of computer technology is the fact that used computers are almost always disposed of and therefore it is almost impossible to find them in any museum.
Surprised to find a live IBM 4361 system in LCM! But there is reason to believe that this may not be real iron. For some reason, museum visitors have no access to this computer. It is also not clear which model is supposedly presented there, and this despite the fact that other computers in the museum are identified very accurately. Among the 4361 systems, three models 3, 4 and 5 are known, and model 3 appeared later than models 4 and 5. But the system in the museum self-identifies as model 1. It is possible that this is a prototype. However, the museum staff did not answer a direct question about assistance with identification, and this despite the fact that they answer other and often rather difficult questions quite quickly. Some features of the timing of the execution of codes give grounds, although not absolutely solid, to assume that the emulator is most likely connected to the network. In the summer at the museum, in connection with covid,obviously switched to an emulator ... There is still a chance to get to the iron mainframes via the networkHNET , but I haven't succeeded yet.
But whatever it is, everyone can connect and try to work in much the same way as high-paid specialists have worked since the mid-70s. The prices were such that today it is hard to believe. For example, an hour of computer time cost more than $ 20 in the mid-80s, and you still had to pay extra for disk space! True, we are talking about the mainframe operating time, and not the terminal through which the work was going. Therefore, for example, when editing a text from an hour of actual work, it rarely took 5 minutes to pay. The prices for the mainframes themselves were also fantastic. For example, Intel employees recall that in the early 1980s they were given only one mainframe to work with. Its performance was 10 MIPS, and the price was about $ 20 million at that time, which was three times as heavy as today! Interesting,that Intel preferred such computers over the cheaper VAX systems. Now evenA Raspberry Pi is the size of a pill and is priced at a few dollars, and can easily deliver over 1000 MIPS. By the way, you can run an IBM / 370 emulator on a Raspberry Pi or almost any modern computer, which will run significantly faster than any IBM system from the 80s or even 90s. However, the emulator has to be configured and not all useful programs for IBM / 370 are freely available, so free access to a well-tuned system is often the best way to get around the mainframe. Surprisingly, such access programs, terminal emulators 3270, are available even on mobile phones! By the way, I managed to set up my VM / CMS system on the Hercules emulator and deal with file transfer, but it took at least a week.
The Hercules emulator can emulate later IBM / 390 and IBM / Z systems, but due to software license issues, this is much more difficult to do. As an illustration of such problems, I will cite the famous case when IBM insisted on removing the Emulation section from an already published book! In modern electronic versions of this book, this section does not exist; it can only be found in the printed edition or as a separate file on sites dedicated to free software. The fact is that emulation on regular PCs since the early 2000s could be noticeably faster than execution on much more expensive mainframes. IBM therefore had to change its software licenses so that it can only be legally used on hardware purchased from IBM. Of course, we are not talking that emulators are faster than the best mainframes,they only show a noticeably better performance-to-cost ratio.
One way to work with Z or 390 systems is to install Linux on an emulator of those systems. For 390 and Z, at least Ubuntu and Debian distributions are available. It is worth noting here that the rapid development of Linux is largely due to significant support from IBM. In particular, IBM in 2001 invested a billion dollars in Linux development.
Let us now consider the features of the machine language of systems compatible with 360. The basic assembler of such systems is called BAL - Basic Assembly Language. Surprisingly, if the rumors about IBM are to be believed, then assembler is still one of the main working programming languages there.
The assembler of the mainframes in question has a number of archaic features that were no longer present in other well-known architectures that appeared later. For example, it is about the fact that BAL mnemonics determine the type of arguments. Consider x86 assembler instructions as an example
MOV EAX,EBXand MOV EAX,address- both use the MOV mnemonic. For BAL, for such cases, different mnemonics LR and L are used in commands, respectively, LR 0,1andL 0,address... However, similar different mnemonics allow using numbers for naming registers, although usually macros R0, R1, ... instead of numbers 0, 1, ... are the first thing that is defined in macro packages for programming convenience. Another archaism is the use of label jumps in conditional compilation constructs, although in my humble opinion this is sometimes more convenient than block structures. But the most famous archaism is the use of EBCDIC encoding to work with symbolic information. In this coding, strange even for yesterday, the letters of the English alphabet are not encoded in a row, for example, the letter I has a code 201, and the next J is 209! This encoding comes from technologies for working with punched cards that arose in the pre-computer era. System 360 also supports ASCII in hardware, but in its ancient and long-forgotten version,where the character for digit 0 has code 80, not 48 as it is now. As far as I know, ASCII with IBM mainframes was best not even trying to use. ASCII support was removed already in 370 systems, but introduced to a new level in 390 systems. Some BAL mnemonics are striking in their super-shortness and even non-nemonicity, for example, N means AND, O - OR, X - XOR, A - ADD, S - SUBTRACT, M - MULTIPLY, ...
The BAL assembler allows you to work with three basic data types: binary, decimal, and real numbers. 390 systems use another special type for working with real numbers. Some Z systems can also use completely unique data such as decimal real numbers. The instructions for working with each type form a special and rather isolated class of instructions. Generally, with very few exceptions, all 360-compatible systems support decimal and real arithmetic instructions. As you know, for x86 or 68k architectures, support for working with real numbers did not appear immediately and for a long time was an optional option, and working with decimal numbers was not something completely separate from binary arithmetic - it was rather an extension.
For working with real and binary numbers, different sets of registers are used, and for working with decimal numbers, registers are not used at all. System 370 provides 16 general purpose 32-bit registers for binary integers, with the program counter being part of the processor status word. There is no separate stack, it can be organized using any register - this is how the work with the stack was subsequently implemented in ARM. The subroutine call is also done as in ARM, through the link register. All registers are almost always interchangeable, exceptions are very rare. If you compare the binary register system BAL with the competitive VAX architecture, you will notice that the VAX has one register less. This is true for ARM as well.
The structure of the operands in instructions will seem fairly familiar to those who know x86 assembler. For binary numbers, the operands have a register-register or register-memory structure, and for the latter case, both 32-bit and 16-bit signed-expandable values can be loaded from memory. For example, an analogue of the x86 instruction
ADD EAX,EBXwould be AR 0,1, ADD EAX,address- A 0,address, ADD EAX,address[EBX]- A 0,address(1), ADD EAX,address[EBX][EDX]- A 0,address(1,3). However, 360 systems and even their later development do not know how to work with scaling, for example, you ADD EAX,address[8*EBX]cannot write to BAL with one command. On the other hand, x86 does not know how to work with 16-bit signed extensions, for example, the BAL commandAH 0,address, which means taking a 16-bit signed number from memory and adding it to register 0, on x86 will require two instructions to implement.
A rare feature of BAL is that there are separate instructions for addition and subtraction for signed and unsigned numbers, and unsigned operations in BAL are called booleans. This oddity is caused by the absence of flags in the 360 architecture that are familiar to most other architectures. Instead, only two bits are used, which are set differently by different instructions! The only difference between signed and unsigned operations is that they set the two attribute bits mentioned differently. For signed operations on them, you can find out whether the result was zero, whether it was positive or negative, whether an overflow occurred, and for unsigned operations, whether the result was zero and whether a transfer or a loan occurred. Conditional branch instructions allow for all 16 subsets of cases that are possible with 2 bits.Due to this unusual work with operation signs today, conditional branch instructions are difficult to quickly understand. Although BAL extensions usually add quite easy-to-read macros for conditional jumps, where you do not need to parse each of the 4 bits. Here, for fairness, you can see that there are separate commands for signed and unsigned addition and subtraction, for example, in the MIPS architecture, where there are no flags at all!for example, in the MIPS architecture, where there are no flags at all!for example, in MIPS architecture, where there are no flags at all!
Another rare feature is in separate commands for signed and unsigned comparisons. I met similar ones not only at MIPS, but also on MicroBlaze. In the latter, by the way, the transfer is the only supported flag of the operation flags.
In systems compatible with IBM 360, there are no arithmetic operations with the carry flag, so if we need to work with binary numbers, for example, in 128-bit numbers, then we must check the carry sign after performing the first 32-bit operations to organize their addition or subtraction. and make the transition if necessary. This is, of course, very cumbersome compared to x86, ARM, 68k, or even 6502, but on much later MIPS it is even more cumbersome. The normal work with the transfer was done only in the Z system.
There are no cyclic shifts in BAL, but non-cyclic shifts, as in x86, can be either single or double. However, BAL has separate shift instructions for unsigned and signed numbers, only the latter set flag flags. Obviously, the results of left shifts for both cases differ only in flags. Spins added only to 390 systems.
Among the commands for loading registers in BAL, there are most likely unique ones. You can load the module of an integer, negation of this module, or a number with a changed sign - something remotely similar I've only come across in the ARM architecture. It should be noted here that the entire architecture of 360 tends to sign arithmetic, and unsigned arithmetic in this architecture is rather secondary. Initially, BAL did not have unsigned division and multiplication, they were added only to system 390. When the register is loaded, the flags, as well as in x86, do not change, but there is a special boot command that sets the flags - this again reminds ARM, where setting the flags can to govern.
All signed arithmetic operations, including shifts, can throw an overflow exception. Whether an exception is thrown or not is determined by a special mask flag in the status register. Interestingly, binary division and multiplication in BAL do not affect flags at all - here you can remember x86, where division only spoils flags.
Bitwise logical operations in BAL are represented by the usual set of AND, OR, exclusive OR, that is, there is no separate negation operation. Logical operations can have not only register-register or register-memory structure, but also “memory-constant” or “memory-memory” - the latter addressing method is similar to that used for decimal numbers. Addressing of the "memory-constant" type is possible only for working with bytes. Obviously, for logical operations, unlike arithmetic, the use of 16-bit numbers is impossible. For memory-to-memory addressing, you can work with data up to 256 bytes! It turns out that we have three data types for working with logical operations: bytes, 32-bit words, sequences of bytes - and special instructions for each of this type, which is rather somehow non-universal.
Logical operations in BAL are adjacent to operations for transferring bytes. In addition to the usual transfer of up to 256 bytes with one command, there is also a unique instruction for transferring tetrads of bytes. You can send only the upper or lower halves of the bytes, while the other halves retain their value during copying! Such strange operations are needed to support BAL features when working with character and decimal information. There are also forwarding and comparison instructions for 370 systems for up to over 16 million bytes at a time, which can be interrupted. Surprisingly, also slow commands for working with blocks of up to 256 bytes cannot be interrupted, which can create an unpleasant delay in response to an interrupt request. Transfer commands can also be used to fill memory with a specified byte.In addition to transferring from memory to memory, you can also set individual bytes to a given value. Obviously, the instructions for transferring bytes, aside from the new instructions for 390 and Z, are more advanced for x86.
In the register, you can load not only the value at the given address, but also the address itself, as in the LEA commands for x86 or 68k. This feature also allows you to directly load the required constant into the register, although its maximum value cannot be greater than 4095. It also allows you to increment the register by no more than 4095. But the register decrement can only be done by 1. Both an increment and a decrement - these are address commands, so they don't change flags. You can load individual bytes and even groups of bytes from a word in memory into the register, for example, only the first and third bytes - this is possible for all other 32-bit architectures known to me only through a series of 4 commands. Likewise, BAL allows only parts of a register to be dumped into memory.
The BAL series of instructions are very specialized - in other architectures, these are implemented by a series of simpler instructions. For example, the TR instruction allows you to convert a string of characters - one argument specifies the string to be converted, and the other the address of the conversion table. A special variant of this instruction, TRT, can be used to scan a given string and skip empty characters - this is the functionality of the standard C strpos call. The ED and EDMK instructions are completely unique - they have the functionality of the primitive sprintf! However, almost all string operations have a limitation on the maximum string length, no more than 255 bytes, which significantly reduces their power.
In BAL, it is difficult to work with 16-bit unsigned values due to the lack of rotation or SWAP-type commands. With 390 systems, this problem has improved. Some BAL instructions are deprecated, for example, the MVO nibble shift instruction has been supplanted by the more convenient SRP. For block transfers and comparisons, it is better to use the new instructions, although due to the fact that they use a different way of addressing, this may in some rare cases be sub-optimal.
There have already been examples of the four basic BAL addressing modes. There is also a fifth one for three-address commands. Modes such as the VAX, 68k, PDP-11 or even 6809 auto-increment or decrement modes are not available in BAL. There are also no DIMM modes like the VAX, 68020, or PDP-11. And, of course, BAL, unlike VAX or PDP-11 assemblers, is completely non-orthogonal. BAL is closest to x86 and ARM assemblers - the most successful modern architectures. The order of operands in BAL from right to left is the same as in Intel assembler for x86 or in ARM assembler and, accordingly, not like VAX, PDP-11 or 68k. Although the order of bytes in data in BAL is from major to minor (MSB), which differs from x86, ARM or VAX, but corresponds to the accepted for 68k or MIPS.
Operations with decimal numbers are implemented in BAL only through memory-to-memory addressing. Decimal numbers can be specified in memory chunks up to 16 bytes, allowing numbers up to 31 decimal places to be used. This corresponds to the precision of a 107-bit binary number. Thus, only the most modern programming systems using binary integers can handle larger values than 360 systems almost 60 years ago! Of course, it is possible to implement arbitrarily large numbers through binary arithmetic, but for some reason, until recently, there were no popular programming languages that support numbers larger than the ancient system 360. Even now, support for 128-bit integers for x86 is usually only unofficial extensions, such as for GCC.
Decimal numbers on BAL are represented uniquely, they must store the sign - there is no such thing for VAX, x86, 68k, ... Moreover, the sign is stored in the last byte of the number representation! For decimal numbers, BAL has direct support for all basic operations: addition, subtraction, multiplication, and even division - this is also not found in any other architecture I know. In addition, BAL also provides instructions for copying, comparing and shifting decimal numbers. The aforementioned MVO and SRP instructions are designed for just such shifts. Operations can be performed only on packed decimal numbers, but to print them, they must be unpacked, and to represent unpacked digits in BAL, a sign is also required, which in this case does not take up space, since it is placed in the upper tetrad, which requires special work with this notebook before printing.It is strange that the operations for boxing and unboxing can only work on no more than 16 bytes of the decimal number decompressed, which allows only 15-bit numbers to be used with them. This unpleasant problem can be solved by using ED or EDMK for unpacking instructions, but packing a large unpacked number will have to be done through a not very simple sequence of instructions. New instructions have been added to 390 systems to address this issue. Curiously, the packing and unpacking instructions work with any binary data, not just decimal.This unpleasant problem can be solved by using ED or EDMK for unpacking instructions, but packing a large unpacked number will have to be done through a not very simple sequence of instructions. New instructions have been added to 390 systems to address this issue. Curiously, the packing and unpacking instructions work with any binary data, not just decimal.This unpleasant problem can be solved by using ED or EDMK for unpacking instructions, but packing a large unpacked number will have to be done through a not very simple sequence of instructions. New instructions have been added to 390 systems to address this issue. Curiously, the packing and unpacking instructions work with any binary data, not just decimal.
BAL has special unique instructions that allow you to convert a binary number to packed decimal and vice versa in one go. For a decimal number in these instructions, 8 bytes are always allocated, that is, 15 digits and a sign. However, the 32-bit register is only enough to represent a signed number corresponding to a 9-digit decimal number, so not every decimal number in the correct BAL format can be converted to binary in one command. For Z systems, there are extended instructions for such conversions.
Jump instructions in BAL differ in that they, as a rule, are paired - the jump address can be set both explicitly and by the contents of the register - in many other architectures, jumps along the contents of the register are only for unconditional jumps. By the way, there are no unconditional jumps in BAL, they are implemented by setting an always true condition, which is similar to the ARM architecture. Conditional branching in BAL, as noted, has a unique syntax. Consider, for example, the instruction
BT 9,address, which means to make a jump if conditions 0 and 3 are met, but conditions after different commands mean different things. For example, after a signed addition, these conditions mean "the result is 0 or an overflow occurred", and after an unsigned addition - "the result is 0 and there was no carry, or the result is not 0 and there was a carry." Despite the cumbersomeness and some redundancy, it must be admitted that such a system for working with conditions for transitions is probably the most flexible of all known. The nine in the command from the example is used in binary representation 1001, that is, it sets the bit numbers - the system itself is used to encode all combinations of conditions with 4 bits in ARM. In addition to conditional jumps in BAL, there are counter jumps with a decrement, approximately the same as in assemblers Z80, x86, 68k, PDP-11, ... But BAL also has two completely unique instructions for jumps,which, depending on the number of one of the operand registers, can be three-address or four-address! In these unique commands, two registers are added together and the resulting sum is compared with the contents of another register, and the result of this comparison is to determine whether to jump or not. Such unusual instructions are believed to be useful for working with jump tables.
As already noted, the call of subroutines in BAL is implemented without using the stack, by simply storing the return address in a register. However, BAL instructions for such calls, one of which is also called BAL, preserves not only the return address, but also part of the status register, in particular, condition flags, the length of the current instruction, and even a mask for optional exceptions, for example, for integer or decimal overflows - this was already mentioned above. Such an unusual extended storage of information is due to the fact that the instruction counter in the mainframe architecture is the upper part of the machine status word and the instructions for calling subroutines mechanically preserve its upper part. There are no special commands for returning from subroutines, you need to use the usual jump to the address in the register.In 390 systems, in connection with the transition to the 31-bit architecture, new instructions for calling and even returning from subroutines have appeared. New instructions allow flexible use of codes that are executed in different modes in one program.
To quickly call single-command subroutines, BAL has a unique EX instruction that executes the instruction at a given address and moves on to the next instruction. The EX instruction can modify the called instruction, which allows you to use any desired register in the called instruction, or to set parameters for bulk transfer of bytes. A similar instruction, but simpler, is also in the TMS9900 command system.
Initially, BAL did not have relative, relocatable transitions like the Z80 or x86. They were only added to 390 systems.
The commands SPM, TM, TS, STCK and STPT are also somewhat unusual. The first of them allows one command to set all the operation flags and the optional exception mask. The TM command allows you to check a group of bits and identify three cases: all zeros, all ones, a mixture of zeros and ones. This check cannot be done by one command in other architectures. However, TM only works with individual bytes in memory. TS is used when working with multiple processors - there is a similar command for 68k. The STCK instruction reads the value of the external (!) Timer, and the STPT instruction reads the value of the internal timer built into the processor circuit. Strange, but STPT is privileged, but STCK is not.
It is also worth mentioning the instructions CS and CDS, which are intended to support multiprocessing work. They have been implemented for 370 systems, that is, they have been available since the early 70s. In x86, the analogue of CS, the CMPXCHG instruction, was implemented not earlier than 1987, and the analogue of CDS, the CMPXCHG8B instruction, was only implemented in 1994!
From 370 systems, the STIDP system self-identification command is introduced, it is privileged and not very informative. For x86, this command has been made much more powerful. You can also notice here that the IBM 4361 in LCM allows any user to execute STIDP. This is obviously an exception-triggered emulation.
The four addressable BAL modes specify two operands for the instruction, the fifth mode specifies three-address commands. However, ignoring some of the information allows you to have unicast commands, and the use of implicit information allows you to have four-address commands. When used in addressing, register 0 has a special role: it is simply ignored there - this allows you to ignore the base and index when calculating the address. All BAL instructions are strictly 2, 4, or 6 bytes. It looks like a 68000 or PDP-11, but not x86, VAX, or ARM.
Several more addressing modes were added to the 390 system, bringing their number to 18. The number of instructions has also increased quite significantly, among the new instructions there are even ones that support Unicode - there is still no such thing for x86! Among the new instructions for 390 systems, there are other unique ones. Several more addressing modes were added to the Z system, and the total number of commands for modern Z is very large and probably even more than the number of commands for modern x86-64!
In systems 360, 370 and 390, the offsets when accessing data in memory, like in ARM, are 12-bit, that is, no more than 4095, which is not very convenient - in large codes, there may be a shortage of registers for the base. In x86, this offset is 16-bit, which, of course, is much more convenient. But the Z system added support for 20-bit offset addressing, which is of course even better. Although, it is worth noting that in x86-64 or even 68020 the offset can be 32 bit. As noted, pre-390 systems, like ARM, did not have the ability to use large constants when working with registers. The x86 architecture is much more flexible here. Therefore, when using assembler with a 360 or 370 system, it was often necessary to use literals, pseudo-constants, which is somewhat slower.
In terms of performance, systems compatible with IBM / 360 have always had good indicators. My experiments with 4361-1, in particular in the projectcalculations of the number π by the shutter algorithm showed very good timings. The 4361-1 instructions run virtually lag-free like ARM or other modern processors. However, due to a somewhat awkward instruction system inherited from the 60s, in particular, due to the lack of division by a 16-bit divider, the result in terms of the efficiency of the processor electronics was at the level of 80186. This is about 80% worse than the result, shown by the then best VAX computer, Model 785. However, the mainframe in LCM is clearly not the best among the IBM mainframes available then. It is also pertinent to note here that mainframes used channels, specialized processors that made I / O very fast, much faster than most modern computers.
As a student, I happened to work with a domestic clone of IBM / 370, EC-1045, in 1987 through batch mode, and in 1989 through dialogue. For batch mode, it was necessary to prepare punched cards. At that time I already used a home computer and therefore the use of archaic punched cards did not leave the best impression. But the interactive mode was not bad, only it often broke, with a large number of users. Therefore, some students came to work at 4 in the morning! Since then, it has not been possible to deal with mainframes anymore, only recently I decided to deal with this milestone technology for the history of computers through emulation.
Cloning the IBM 360 was very popular. Clones were made in England, Germany, Japan and other companies in the USA. In the USSR, this cloning took on a very dramatic connotation. For the sake of this cloning, almost all domestic developments in the field of IT were folded, some of which were very promising. In particular, the topic of Ural computers was closed , about which the famous computer scientist Charles Simonyi later spoke with warmth . The BESM-10 project was also closed, although the machines of the previous BESM-6 class were comparable to the IBM 360 in terms of speed. Also, for the sake of this cloning, an almost concluded contract with ICL was thwarted, perhaps with this contract the British IT industry would have acquired a new dynamic and would not have declined. Supercomputers onlyElbrus , possibly due to their links to the defense industry, survived the "Clone Invasion", which Dijkstra called the greatest US victory in the Cold War.
As people who worked with mainframes in the USSR recall, domestic clones were distinguished by extremely low reliability and required constant attention from the service personnel. While the original American IBM mainframes were some of the most reliable computers of their time. In Soviet clones, sometimes more than a dozen (typically more than 5) kilograms of precious metals, gold, platinum, palladium and silver were laid, but this did not help to correct the situation with reliability. Due to such a large number of highly liquid values, it is difficult to imagine that a working domestic clone could survive somewhere.
Interestingly, the main developer of the IBM 360 left IBM and founded Amdahl, which for more than two decades has specialized in the production of systems that are compatible with IBM mainframes and at the same time are somewhat superior in speed and reliability at lower prices. As a result, due to the big changes in the mainframe market, Amdahl, like ICL, became part of the Japanese corporation Fujitsu.
In addition to computers of the IBM / 360 architecture, there were other mainframes. In the 60s, American mainframe manufacturers unofficially received the sonorous name of Snow White and the Seven Dwarfs. It is probably easy to guess that Snow White was IBM. Mainframes of original architectures were also produced in other countries. The British architecture ICL 1900 is especially worth mentioning.
As I already wrote, I managed to set up a working configuration for VM / CMS 6. However, it turned out that the XEDIT editor is not freely available, and a simple EDIT is too peculiar and inconvenient, so you have to edit the texts on the host. It was also discovered that a standard program for transferring files from the terminal emulator to the mainframe and vice versa was unavailable, which required the use of virtual punched cards for such a transfer. Another unpleasant surprise came up in connection with debugging. DEBUG command does not support stepping! While such a possibility was even for the DDT debugger for the 8080 processor. It is also surprising, although less critical, that DEBUG does not know how to do disassembly, which was often built into even the simplest monitors of 70s processors.Long line wrapping and end-of-line control characters are not supported at the low level under CMS! Therefore, when printing from assembly language programs, you need to format the lines manually so that they do not disappear beyond the right edge of the screen, and also take care of filling the last line with finishing spaces. Also unusual is the lack of automatic vertical scrolling.
Those who want to work with mainframes for the first time should keep in mind that mainframes are a huge ecosystem, where many familiar concepts can have a different interpretation. For example, the simple concept of a file is not there. One of the key attributes of the file is the record size, there is nothing like this for Linux or Microsoft Windows files. The files themselves differ in the methods of accessing them and there have been written and possibly non-thin books about this. It is also unusual that in CMS the disk name is written at the end of the full file name, and the name, extension and disk are separated by spaces, and the disk name itself is called file mode for some reason. I would also like to sort out the multitasking MVS , as far as I know in the USSR, they never got to it.
In general, it is somewhat unexpected that some well-known operating systems that were used on very expensive computers did not support working with file directories, which equaled them with the very first and primitive operating systems for microcomputers, for example, CP / M or Commodore DOS. It is no coincidence that CMS was sometimes called CP / M for mainframes. Surprisingly, as far as I know, support for catalogs in the CMS was never introduced, although the last release of the system dates back to 2018. For some reason, work with catalogs for expensive computers was often poorly supported before the 80s. For example, there was no such support in DEC RT-11 and even one of the best OS for PDP-11, RSX-11, only supported two-level directories. The most popular IBM OS until the 2000s was MVS (1974) and even here the catalogs were only partially made, as in Apple MFS (1984). Although in Unix (1973), MS-DOS (since 1983) or even 8-bit Apple ProDOS (1983), this was fine from the beginning. The most advanced file handling was offered in VAX / VMS (1977), where in addition to directories there is even built-in support for file versioning.
Interestingly, the scripting language for CMS, MVS and some other IBM operating systems, REXX , has become an abbreviated version of the batch file language for the Commodore Amiga.
Mainframe software is usually two-color. Color terminals were used relatively rarely and therefore there are few color programs. There are also few programs with dynamic graphics; frequent screen refreshes lead to noticeable unpleasant flickering.
Dynamic demo, launched on the emulator IBM 4381 in LCM, terminal 3270-3
In conclusion, I can not help but express my admiration for the IBM technologies. They have always been distinguished by their unique originality and high level. I would especially like to note the very good quality of the documentation, which, even for modern systems, is in the public domain. IBM is demonstrating tremendous dynamism in technology development despite the fact that it is one of the largest companies in the world. In terms of the number of employees, it is almost equal to Microsoft, Google and Intel put together!
The mainframe theme is huge. Of course, I was able to write only a small part of what it can contain. I would be very grateful for clarifications and additional information.
This material is also available in English .