IBM System 3

The IBM System/3 was an IBM midrange computer introduced in 1969, and marketed until 1985. It was produced by IBM Rochester in Minnesota as a low-end business computer aimed at smaller organizations that still used IBM 1400 series computers or unit record equipment. The first member of what IBM refers to as their "midrange" line, it also introduced the RPG II programming language. It is the first ancestor in the product line whose current version is the IBM i series and includes the highly successful AS/400.

History

At its launch in 1969 it was available for $1000/month — less than half cost of an IBM System/360 Model 20; the smallest member of the IBM System/360 family.

Many of the original System/3 model 10 units were shipped diskless, with only the new IBM 5424 Multifunction Card Unit (MFCU) which read, punched, printed on and sorted the new, smaller 96-column punched cards introduced at the same time.

IBM delivered the following models:
* 1969 — IBM 5410, or System/3 Model 10, introduced (shipped in 1970)
* 1970 — IBM 5406, or System/3 Model 6, introduced (disk-oriented system)
* 1973 — IBM 5415, or System/3 Model 15, introduced
* 1974 — IBM 5408, or System/3 Model 8, introduced
* 1975 — IBM 5412, or System/3 Model 12, introduced
* 1976 — IBM 5404, or System/3 Model 4, introduced

The System/3 and successor models System/32, System/34, System/36 and System/38 are generally referred to in IBM terminology as "midrange systems" — in contrast to IBM's mainframes.

Hardware

The IBM System/3 was announced as a computer system that initially consisted of:

* IBM 5410 Model 10 Central Processing Unit
* IBM 5424 Multi Functional Card Unit (MFCU)
* IBM 5203 Line Printer
* IBM 5444 Disk Storage (optional)
* IBM 5471 Printer Keyboard
* IBM 5475 Data Entry Keyboard
* IBM 5496 Data Recorder, a keypunch machine with print and verify functions
* IBM 5486 Card Sorter

Memory

Entry models had as little as 4K (4096) bytes of magnetic-core memory.

Direct access storage

For mass storage, the System/3 used the IBM 5444 single-platter disk, roughly the size of a large pizza; initially each platter held 2.5 MB of data. Standard configuration for storage was one or two fixed disks, each in a separate pull-out drawer, which typically held the operating system and user-developed programs. Additionally, each fixed disc could have a removable cartridge disk attached; these typically contained the data-files associated with various applications, for example Payroll, and users frequently had a number of them. Thus the low-end systems could support a maximum of 10 MB of online storage (two fixed, two removable), although in practice this was very expensive and not common.

The System/3 was also available with the IBM 5445 disk drive (20mb) and later the model 15 allowed "winchester" style 3340 drives. On the smaller models, while you could attach 5445 drives, you had to keep the 5444 for the operating system and other programming libraries, however that limitation was changed with software called elimn8 which allowed 5445 drives to totally replace the 5444's. Other companies such as Memorex manufactured compatible 5445 drives for the System/3.

Multi-Function Card Unit

The most common punched-card device was IBM 5424 Multifunction Card Unit (MFCU) which read, punched, printed on and sorted the new, smaller 96-column punched cards. Instead of the rectangular punches in the classic 80-column IBM card, the new cards had tiny (1 mm), circular holes much like paper tape. Data was stored in six-bit binary-coded decimal code, with three rows of 32 characters each, or in 8-bit EBCDIC, with the two extra holes located in the top rows.
The new cards had room for 128 printed characters in four rows of 32 characters each. They were about 1/3 the size of the older 80 column cards but held 20% more text data. The smaller, and thus lighter card could be processed with faster equipment and with fewer jams.

Available as ''RPQ''s (special order equipment) to handle 80-column cards were the IBM 2560 Multifunction Card Machine (MFCM) which could read, punch, interpret and sort, and the IBM 1442 which could only read and punch.

Magnetic tape

Offline storage was available with the purchase of an external tape drive which read and wrote standard IBM 9-track tape.

The System/3 Mod 10 optionally included the IBM 3410 magnetic tape subsystem.

Operator Console Facility

The System/3 Operator Console Facility (OCF) consisted of either a modified IBM Selectric typewriter interfaced into the computer, or a special purpose IBM 3270 display.
Within the OCF, there was capability to 'cancel' processes and/or tasks that were running, including either partition (P1 or P2). The system could only run two programs simultaneously, except for the model 15 or systems running the Communications Control program, CCP. The CCP was a system control programming feature that allowed to support an online network of terminals.

Printers

A smaller (IBM 5203) printer was attached to the main system. The 5203 was a chain printer with interchangeable cartridges. It could run at 100 or 200 lines per minute, based on model. Later on, IBM offered multiple models of the existing IBM 1403 printer line, which had been originally built for the IBM 1401 computer.

Floppy disk

With the arrival of the IBM 3740 data entry system, the System/3 Model 10 got a feature called LCA (local communication adaptor) which allowed an IBM 3741 station to be "attached" to the system to transmit/receive data. Later models of the System/3 such as the Model 8 were cardless and used the 8" 3740 style floppy disk.

Instruction set

The instruction set was optimised for two key aspects of the product: limited availability of main memory, and the RPG II programming language. The original S/3 (models 10 and then 6, 8 and 12) had 29 instructions, all occupying between 3 and 6 bytes (24 to 48 bits).

The first 4 bits conveyed a lot of information: "1111" meant this was an instruction without operands, known as a command. e.g. Start I/O (the I/O op being defined by previously loaded I/O registers). "11xx" and "xx11" meant a 1-operand instruction, such as a Branch. If xx was 00 the operand was addressed by its full 16-bit address. xx=01 or 10 meant base-displacement addressing was used, using index register 1 or 2 respectively. A base address would previously have been loaded into one of the two index registers and the instruction contained the displacement of up to just 256 bytes (8 bits of addressing).

Other patterns for this first half-byte indicated a 2-operand instruction.
"0000" meant both operands were addressed by their direct 16-bit address.
"0100": operand 1 uses reg 1 as its base; operand 2 uses direct addressing.
"0110": operand 1 uses reg 1 as its base, operand 2 uses reg 2.
And so on.

The remaining 4 bits of the first byte further defined the instruction.
This structure meant that there was the capability to have up to 64 operations in all:
16 commands (though there were never more than five across the whole product range);
16 1-operand instructions starting with 11xx;
16 1-operand instructions starting with xx11;
16 2-operand instructions.

As well as the two index registers already mentioned (referred to as 1 and 2, or binary 01 and 10) there were other registers. "Reg 4" (0100) was the instruction address register (IAR) which pointed at the current instruction. "Reg 8" (1000) was the address recall register (ARR), set by certain instructions. Among these was the conditional branch (mnemonic BC) which used it to point to the byte immediately following the branch operation. For programmers used to IBM mainframe behaviour, this meant that the S/3 branch operation could be likened to a conditional BALR (branch and link register) – very useful when branching to a sub-routine, and returning after it had processed. Finally, "Reg 16" (00010000) was the program status register (PSR), holding such things as the results of a compare instruction. Note that registers were used only for addressing and program status, not for arithmetic.

The arithmetic instructions provided among the 29 instructions were binary add/subtract (provided to help manipulate addresses) and decimal add/subtract. Multiplication and division were not provided for by the standard hardware, and had to be handled by software routines. There was no floating point provision at all. All this continued to be true even with the later and generally more sophisticated Systems/34 and 36.

All the above got more complicated with the System/3 model 15, and the Systems/34 and /36. Though still using 16-bit addressing, all these systems could support well over 64K of main storage (up to 512K and theoretically more), so address translation was used to swap from one 64K address space to another. Address Translation Registers were set to define the actual address space in use at any one time, their contents being concatenated with the 16-bit address used by a program to produce a real address. These "ATRs" were privileged, available only to the operating system.

The original S/3 model 10 (and the later model 12) had an optional crude form of multi-programming called the Dual Program Feature. This provided no more main memory addressing, but gave two sets of registers and instructions which flipped from one "program level" to the other. The standard I/O instructions were also modified to flip when an I/O was started.

So far, only the first byte of the instruction has been explained here. The next ("Q") byte was generally a qualifier, such as specifying the number of bytes to be moved in a move characters op or the condition to test for in a Branch. A couple of instructions used this byte for a 1-byte "immediate" operand. The remaining byte(s) were for the displacement(s) or address(es) for operands, or the details for some commands.

An example: a simple command, Conditional Jump, a special type of conditional branch (forward only, up to 256 bytes) suitable mainly for jumping over short blocks of code: Op code byte= F2 (this is in hexadecimal, Hex F is binary 1111, Hex 2 (0010) defines the op); Q byte= 00000001 specifies that we "jump" if the condition register has the "equal" bit on; Operand= 00011000: if the condition is met we jump forward 24 bytes.

Indicators were binary switches used to control program flow. Over 100 of these were available to the programmer. By using the instruction formats explained above, many of the indicator-oriented operations could be fit into just 3 bytes. For example, a line of RPG might test an indicator for "On": 3 bytes for a "Test Bits On" op; then 3 bytes for a Jump, as previously described, and useful to the RPG compiler. Saving the odd byte here and there was good when you had only 64K to play with—and, on the S/3 itself, that had to include the operating system (which grew to about 20K on the model 10 with the introduction of the "Communication Control Program", CCP).

Operation Control Language

A simple job control language called Operation Control Language (OCL) was superficially similar to the Job Control Language (JCL).

Operator control commands

Operator control commands (OCCs) were used to communicate with the system.

Languages

The System/3 supported RPG II, Fortran IV, COBOL, and '' Assembler''.G360-0002-0

RPG II compiler

The System/3 came standard with a RPG II compiler. In a card-only system, the RPG II compiler was supplied as two phases. The first phase would be booted from one input hopper of the MFCU, and the source would then be read following the compiler. An intermediate form was punched on cards, which were then read by the second phase of the compiler. An executable program deck was then punched. This executable could then be booted ("IPL'ed", for "Initial Program Load") to perform the processing desired. This process could require more than an hour for a significant-sized program.

Problems with System/3

The System/3 had no provision for halting a process once it had started to run. For instance, if a compile failed because of an error on the very first page, the user had to wait for a sometimes voluminous compile listing to print in its entirety. Users learned to reach under the printer and jostle the paper discharge chute, which would cause the machine to halt with a "P3" (printer error) displayed. The user could then dial in the response code FF to abort the run. Another way of stopping it was simply to press the green "Start" button on the console, causing the system to reboot.

Error codes were displayed on a two-digit seven-segment display (one of the first seen, and built with lamps rather than LEDs). The range of error codes included not only decimal and hexadecimal digits (as seven-segment displays are commonly used) but also a limited set of other letters; for example, "P3" was one of several printer error codes. A thick manual that came with the System/3 aided the operator in interpreting the error codes and suggested recovery procedures. The System/3 had no audible warning device, so a program that was not printing, reading cards, or causing other obvious activity could halt and the operator would not know it unless they happened to look at the status display. Models with the Dual Program Feature had two separate status displays.

Most/many users did not buy a console. Instead OCL code was either suppressed entirely or printed on the 5203 printer. The console offered by IBM slowed down program execution tremendously when it printed OCL commands, as it was basically a selectric typewriter.

The concept of keying your punched cards through the console was a marketing ploy. In reality, the System/3 could not be a computer and a keypunch at the same time, so when it was a keypunch, no computing was possible. The original IBM System/3, which was shown in July 1969, had the keypunch console so they could offer a computer for under $2,000/month. In reality it was unworkable and almost invariably users acquired a stand-alone keypunch/verifier.

Later several OEM companies built 96-column keypunches, sorters, and collators. This took the 'heavy lifting' off of the MFCU and freed the System/3 for actual computing functions.

Most experienced System/3 users minimized use of the MFCU as much as possible, since it was a system bottleneck.

Emulation

The later System/32, IBM System/34 and IBM System/36 were all able to run System/3 applications through emulation.

The System/32 used a vertically microcoded processor, with 16-bit microcode words, which emulated the System/3 instruction set, rather slowly, in microcode. The System/34 and System/36 both had two processors: a Control Storage Processor (CSP), as in System/32, which handled most supervisor and input/output operations, and a Main Storage Processor (MSP). This latter was a re-implementation of the System/3 model 15 processor; effectively providing "hardware emulation" of the System/3.

See also

* Distributed Data Management Architecture
* IBM System/370

References

Further reading

*"Everything You Always Wanted to Know About the System/3 But Nobody Told You" by Charlie Massoglia
*"System/3 Disk Sort as a Programming Language" by Charlie Massoglia
*"System/3 Programming RPG II" by Solomon Martin Bernard, 1972,
*"An introduction to computing: IBM System/3" by Jerome T. Murray, 1971,
*"Business System with Punched card data processing and System/3 Model 10", by F. R. Crawford, 1973,

External links

*

Original vintage film from about 1969
Computer History Archives Project



IBM System/3 website

IBM System/3 Models 8, 10, 12, and 15 Components Reference Manual

{{DEFAULTSORT:Ibm System 3
System 03
16-bit computers