| Previous | Table of Contents | Next |
There has always been a group of developers in Rochester who continue to be committed to the System/36. In 1993, at the height of the SLIC development effort, two of the System/36 group leaders, Dick Mustain and Steve Dahl, had an idea. Why not build a new System/36? With the AS/400 moving to RISC, and SLIC being able to incorporate support for other operating systems, it was possible to create a new System/36. These dedicated developers put together a quick prototype and a proposal to put the System/36 operating system on the RISC hardware.
In the preceding few years, various vendors worldwide had started to sell software packages that allowed System/36 customers to move to a RISC-based computer system, either IBM’s RS/6000 or a competitor’s product. The problem with these “look-alike” products was that they provided only part of the System/36 look and feel. System/36 customers still had to make changes to their applications and operational procedures, and still other System/36 software products they were using could not be brought over to the new computer.
IBM had decided that the official migration path for System/36 customers was to the AS/400. Some System/36 customers made this migration, but a much larger group had refused to move anywhere. Estimates had more than 200,000 System/36s still running business applications around the world. Many in IBM believed it was only a matter of time before these customers moved to some IBM platform. Needless to say, the developers’ proposal for a new System/36 was not met with overwhelming enthusiasm.
Fortunately, some managers in Rochester have always been willing to look at new opportunities, and soon a “skunkworks”6 was formed to develop a new System/36. A skunkworks is nothing new to Rochester. We have used this approach many times to develop systems that were not thought to be strategic and were, therefore, not given funding to proceed. Recall that the AS/400 itself came out of such a skunkworks.
6A skunkworks is a small, loosely structured development unit formed to foster innovation, or in some cases, to hide its existence. It is named after Big Barnsmell’s “Skonk Works,” where the bootleg Kickapoo Joy Juice was brewed, in Al Capp’s comic strip “Li’l Abner.”
Soon, a small team of System/36 experts began to assemble. Bob Schmidt, who signed up to manage this team and to keep its existence hidden from the watchful eyes of those who approve funding for such projects, had no problem finding volunteers. Within just a couple months, this small band of dedicated developers had the operating system of the System/36 running on the new RISC processor. New life had been breathed into this product line.
The original System/3 announced in 1969 had a processor implemented directly in hardware. The design was very simple, with only 28 instructions. On top of the System/3 hardware was the operating system, along with all applications and utilities. A major change to this implementation structure occurred with the introduction of the System/32 in 1975.
The idea of moving some of the operating-system functions into microcode had been well established in the early 1970s in Rochester as a result of the System/38 work. These functions were moved to microcode on the System/38 for purposes of technology independence. The System/32 used a microprogrammed processor to emulate the System/3 instruction set. For performance reasons, several functions were moved out of the System/3 operating system and into the microcode of the System/32. Thus, there were similarities between the System/32 and the System/38. They both had some of their operating system implemented in the microcode, although for different reasons.
The System/32 was designed as an entry system, and it performed well at that level. The emulation of the System/3 instruction set was slow, however, because the underlying processor was not a very high-performance engine. The System/32 processor did, however, do a very good job of executing the operating-system functions. It is notable that the processor used for the System/32 was a 16-bit, register-based design that looked remarkably like some of the early RISC hardware.
To expand the performance and capacity range of the System/32 required some changes to the implementation. The System/32 processor was good at running parts of the operating system, so the decision was made to keep it. But because this processor was too slow to emulate the System/3 instructions satisfactorily, a second processor similar to the original System/3 was created to directly execute these instructions with the hardware. The bulk of the operating system was written in the System/3 instruction set and would run on this second processor. Because it fetched its instructions from the main memory, this second processor was called the Main Store Processor (MSP). The System/32 processor fetched its instructions from a separate part of the memory, so it was renamed the Control Store Processor (CSP). In 1977, the first system to use this two-processor structure was announced. This system was called the System/34.
In 1983, the follow-on to the System/34, the System/36, was announced. The System/36 continued to use the two-processor structure pioneered by the System/34. Just like the AS/400, whose operating system is split into parts, OS/400 and SLIC, the System/36’s operating system was split into two parts. The first part, called the System Support Program (SSP), ran on the MSP, while the second part of the operating system ran on the CSP. The larger System/36 models had additional processors to perform I/O operations. These, too, were CSP designs that ran the parts of the operating system for I/O processing. Over the next few years, new models of the System/36 were introduced, all with the two processors.
| Previous | Table of Contents | Next |