The IBM System/36 (often abbreviated as S/36) was a minicomputer marketed by IBM from 1983 to 2000. It was a multi-user, multi-tasking successor to the System/34. Like the System/34 and the older System/32, the System/36 was primarily programmed in the RPG II language. One of the machine's more interesting optional features was an off-line storage mechanism (on the 5360 model) that utilized "magazines" – boxes of 8-inch floppies that the machine could load and eject in a nonsequential fashion. The System/36 also had many mainframe features such as programmable job queues and scheduling priority levels.
Overview of the IBM System/36 
The first model of the System/36 was the 5360. It weighed 700 lb (318 kg), cost (US) $100,000 and up, and is believed to have had processor speeds of about 2 MHz and 8 MHz for its two processors, which in 1983 was faster than the "Personal Computers" on the market. The 5362 weighed only 150 pounds (68 kg) and cost (US) $20,000.
In the 1970s, the US Department of Justice brought an antitrust lawsuit against IBM, claiming it was using unlawful practices to knock out competitors. At this time, IBM had been about to consolidate its entire line (System/370, 4300, System/32, System/34, System/38) into one "family" of computers with the same ISAM database technology, programming languages, and hardware architecture. But after the lawsuit was filed, IBM decided it would have two families: the System/38 line, intended for large companies and representing IBM's future direction, and the System/36 line, intended for small companies who had used the company's legacy System/32/34 computers.
The System/36 used virtually the same RPG II, SDA, OCL, and other technologies that the System/34 used, though it was object-code incompatible. Its original displays (at 24×80) were the most popular, and used the same basic screen size still used on modern computers. A 27×132 display was supported c.1987, but never quite caught on. The S/36 was a small business computer; it had an 8-inch diskette drive, between one and four hard drives in sizes of 30 to 716 MB, and memory from 128K up to 7MB. Tape drives were available as backup devices; the 6157 QIC (quarter-inch cartridge) and the reel-to-reel 8809 both had capacities of roughly 60MB. The Advanced/36 9402 tape drive, c.1994, had a capacity of 2.5GB.
The System/36 used a command-line environment, but it was simpler than the System/34 because of 100 or so menus that simplified the command process. Instead of typing "BLDLIBR MYLIB,100,30" to create a user program library, an operator could use menus to find the description "Create a user library" and fill in a form to accomplish the same goal. RPG II was modified from the System/3 days to allow access to the "WORKSTN file" to allow a punched card-based language to interact with a person sitting at a keyboard and monitor. A WORKSTN file was an output file (it wrote to the monitor) and also an input file (because it accepted the user's keyboard input). Thus it was labeled a combined-primary file or a combined-demand file.
Command keys became RPG indicators KA-KY, and different on-screen forms were recognized by different invisible control characters hidden in the forms themselves. Interestingly, since the user had to display a form on the screen in order to type, RPG II provided a way for a program to write output before accepting input. Many successful programmers moved from using the combined-primary WORKSTN file to using a combined-demand file, which had operation codes to read and write the display. There was even a way to code for multiple WORKSTNs; several people could sign on to the same copy of the same program in memory. The largest program size was 64k.
A company called Amalgamated Software of North America (ASNA) produced a third-party compiler for the System/36 in the late 1980s called 400RPG. Another company called BPS created a third-party pre-processor called RPG II-1/2. Both of these products allowed users to write RPG II programs with RPG III opcodes. ASNA also produced an improved file access algorithm called ACCELER8 and a program-canceling utility called TERMIN8. Other third-party companies produced RPG subroutines that greatly enhanced the abilities of RPG. There were at least 230 commercially-available subroutines.
There were a few holdovers from the days of the System/32 (the "Bionic Desk" of 1975): the KEYBOARD, CONSOLE, and DISPLAY files which provided unformatted access to the monitor and keyboard. (CONSOLE came from the System/3 days). Clever System/36 programmers could use a KEYBOARD file to accept commands from the procedure (the "system input file") meaning that a program could be customized at run time without a recompilation.
// LOAD MYPROG // FILE NAME-INPUT // RUN THIS IS CUSTOM DATA SO IS THIS /* (means end of data)
The System/36 was flexible and powerful for its time:
- It allowed 80 monitors (see below for IBM's description of a monitor) and printers to be connected. All users could access the system's hard drive or any printer.
- It provided password security and resource security, allowing control over who was allowed to access any program or file.
- Devices could be as far as a mile from the system unit.
- Users could dial into a System/36 from anywhere in the world and get a 9600 baud connection (which was very fast in the 1980s) and very responsive for connections which used only screen text and no graphics.
- It allowed the creation of databases of very large size. It supported up to about 8 million records, and the largest 5360 with four hard drives in its extended cabinet could hold 1.453 gigabytes.
- The S/36 was regarded as "bulletproof" for its ability to run many months between reboots (IPLs).
In the late 1980s the US Department of Justice ended its case against IBM, and so IBM went forward with a system named the AS/400. The new system was a smaller and less-expensive S/38 with a more powerful database, and so was instantly popular among the 20,000 S/38 customers. But the company had trouble convincing the 300,000 S/34 and S/36 customers to migrate; people who paid $20k for their S/36 didn't want to pay $40k for the AS/400 even though IBM did offer a very easy migration path that could be handled by the customer themselves.
Terminals, displays, screens, workstations and monitors 
At that time, the terms terminal, display, screen, workstation and monitor were used interchangeably to describe the same thing, although today only the first one is considered the appropriate one (other ones evolved to reflect other uses). Although not consistently in any manner, IBM preferred term at that moment was monitor.
An operator basically sat in front of this device that vaguely resembled today's PC, except the monitor was smaller, the device was more expensive (US$2,000), it featured a text-only (24×80) interface and the available colors for the screen were only green and bright green, although a seven-color IBM Color Monitors later became available. Some purists refer to a printer as one type of workstation.
5250 Compatible Terminals 
By the mid-1980s, third-party companies have made compatible devices (based on what would become IBM 5250 standard, today mostly served by terminal emulators). Prices plummeted and new features appeared – for example, Decision Data terminals allowed operators to choose the seven colors from a 64-color palette; there was an optional time display; and setup was accomplished through onscreen menus rather than dipswitches.
IBM Colors 
Prior to 1984, the 5251 monitor predominated – it was US$2,000 and what IBM called "dual color" (green and white). However, by 1984, the IBM 3180 terminal helped usher in the grand new age of IBM Color – seven colors (pink, red, blue, yellow, green, white, and turquoise.) For those who wished to "keep it cheap" but eschew the omnipresent green, there were also amber and white selections as early as 1986. By 1984, the price of the 3180 terminals was under US$2,000, though there was a graphics-capable terminal that sold poorly.
Interestingly, programming colors did not require a new screen programming language, because the implementation was completely at the hardware level. A protocol called the IBM 5250 Data Stream interpreted field attributes such as blinking, non-display, high intensity, reverse image, underline, and column separators and was used in combination to create colors. Normal text was presented as green on a 3180 color terminal, but high intensity became white. Column separators became yellow. Blinking became red. Underlined text was presented as blue. High intensity blinking became pink. High intensity column separators became turquoise.
Unfortunately, extensive use of colors became confusing when using the less expensive dual-color terminals.
The five terminal lights 
On a 5251 type terminal (aka "Concrete Block",) there were five lights to watch for:
(1) System Available light. If lit, this terminal is connected to the S/36 and is receiving information from it.
(2) Message Waiting light. Other users, and the system itself, can send messages to workstations. If lit, there is at least 1 message that has not been seen yet. When a program ends or when the user signs on, the message(s) will be shown.
(3) Insert. The Insert key has been pressed. Characters after the cursor will shift right when text is keyed. Press Insert again to cease Insert Mode.
(4) Caps Lock light. The Caps Lock key has been pressed. All keys pressed will be uppercase. Press Caps Lock again to unlock.
(5) Keyboard Shift light. The Shift key is being pressed. The key pressed simultaneously will be uppercase.
The standard US keyboard was heavy, clunky, featured 122 keys, and weighed approximately 10 pounds. (On the positive side it had a cent-sign key and a HELP key. The PRINT key did what it was supposed to do; it printed the screen.) There was a special terminal and keyboard for Katakana.
Typical System/36 installations would include one of these printers.:
IBM 5219 – A daisywheel impact printer not far removed from the IBM typewriters. It was good for about 40 characters per second (CPS).
IBM 3262/5262 – A band printer rated at 650 lines per minute (LPM).
IBM 4234 – A dot-matrix printer rated at 410/800 LPM.
IBM 5224 – A dot-matrix printer rated at 100/240 LPM.
IBM 5225 – A dot-matrix printer rated at 280/560 LPM.
IBM 3812 LED page printer
IBM printers were well-built, had impressive duty cycles, and were priced in line with their marque. For example, a 5262 would go for about US$12,000.
Configuring devices 
Early 1980s-era printers and workstations had a series of binary switches known as "dipswitches" for configuration. For example, U.S. English and UK English, where the British use the pound sterling ("£") and the Americans use the dollar ("$"). A switch could be set up on printers and monitors where in the zero position the British value would display or print. In the one position the American value would display or print.
Online Setup 
By the mid-1980s the dipswitches were gone and the status quo became online setup. The technical person would hold down a certain key while powering up the device. A "test mode" display would appear, and a menu option would allow the operator to choose the addresses for the devices. Sometimes an emulated terminal would have a PC-style printer port. Sometimes the emulation would allow you to configure as many as seven devices.
Setting the Address 
Up to 40 local devices could be configured on a System/36, using eight lines numbered from 0 to 7. A line was defined as a series of twinaxial cables attached to devices with IN and OUT ports. Three binary switches on every device were used for the terminal's address (the physical designation of a particular terminal on a particular line.) Two devices can not have the same address on the same line. Once the addresses were set, the system could be configured to use them. A workstation expansion gave you ports 8 through 15, and another 40 devices.
The System/36 had a feature called auto-configure. This allowed configuration merely by setting the addresses on the devices, turning off the S/36, connecting the devices to the S/36, and restarting the S/36. The system would configure the devices, including assigning workstation IDs, and so forth.
Configuring Using CNFIGSSP 
The CNFIGSSP procedure was used to configure the system, including the devices. Each device is assigned a two-character ID. The first letter must be alphabetic; the second must be alphanumeric. The system also reserved certain IDs; you could not call your device I1 or F1, for example. I1 is the name of the diskette drive; F1 is what the system calls the hard drive (stands for "fixed disk," since it's not a removable disk pack.)
CNFIGSSP is used to place devices on the line/address map; identify the particular IBM printer or terminal model; assign characteristics such as console, alternate console, subconsole; and to name the printer's subconsole. To apply CNFIGSSP, the system must be dedicated (no other users logged on or programs running.) The system must then be IPLed (rebooted.) When IPL finishes, the newly configured devices will appear on the status display.
System architecture 
S/36s had two sixteen-bit processors, the CSP or Control Storage Processor, and the MSP or Main Storage Processor. The MSP was the workhorse; it performed the instructions in the computer programs. The CSP was the governor; it performed system functions in the background. Special utility programs were able to make direct calls to the CSP to perform certain functions; these are usually system programs like $CNFIG which was used to configure the computer system. These two processors worked in tandem, and it's one reason the S/36 worked so well.
The primary purpose of the CSP was to keep the MSP busy; as such, it ran at slightly more than 4X the speed of the MSP. The first System/36 models (the 5360-A) had a 4 MHz CSP and a 1 MHz MSP. The CSP would load code and data into main storage behind the MSP's program counter. As the MSP was working on one process, the CSP was filling storage for the next process.
The 5360 processors came in four models, labeled 5360-A through 5360-D. The later "D" model was about 60 percent faster than the "A" model.
Front Panel 
The 5360, 5362, and 5363 processors had a front panel display with 4 hexadecimal LEDs. If the operator "dialed up" the combination F-F-0-0 before performing an IPL, many diagnostics were skipped, causing the duration of the IPL to be about a minute instead of about 10 minutes. Of course part of the IPL was typically keysorting the indexed files and if the machine had been shut down without a "keysort" (performed part of the P S (or STOP SYSTEM) then depending on the number of indexed files (and their sizes) it could take upwards of an hour to come back up.
Memory and Disk 
The smallest S/36 had 128K of RAM and a 30 MB hard drive.
The largest configured S/36 could support 7MB of RAM and 1478MB of disk space. This cost over US$200,000 back in the early 1980s. S/36 hard drives contained a feature called "the extra cylinder," so that bad spots on the drive were detected and dynamically mapped out to good spots on the extra cylinder. It is therefore possible for the S/36 to use more space than it can technically address. Disk address sizes limit the size of the active S/36 partition to about 2GB; however, the Advanced/36 Large Package had a 4GB hard drive which could contain up to three (emulated) S/36s, and Advanced/36 computers had more memory than SSP could address (32MB to 96MB) which was used to increase disk caching.
Disk space on the System/36 was organized by "blocks." One block = 2560 bytes. A high-end 5360 system would ship with about 550,000 blocks of disk space available. System objects could be allocated in blocks or records, but internally it was always blocks.
Program Sizes 
The S/36 could compile and run programs up to 64 kB in size, although most were not this large. This became a bottleneck issue only for the largest screen programs. With the Advanced/36, there were features added to the SSP operating system including the ability to call other programs from within. So a program that was say 60 kB could call another program that was 30kB or 40KB. This call/parm had been available with 3rd party packages on the System/36 but not widely used until the feature was put in 7.1 and 7.5 of SSP on the Advanced/36.
Virtual Memory 
IBM developed a form of virtual memory in 1960, which the S/36 used in a similar manner to "swap" space on modern computers. Like the modern equivalent, the system uses a cache or workspace on the hard drive to contain portions of the program(s) currently running, allowing programs larger than the amount of physical RAM (48KB in the case of the S/36) to be run. Loading the whole program into the cache area and then moving it piecemeal in and out of storage was a system function performed by the CSP, while the MSP executed the instructions in the computer program. As with modern computers, paging data between system memory and a hard disk is inherently slower than using an equivalent amount of physical RAM, an effect which was compounded by the lack of "burst" transfer modes and overall slower performance on the hard disks of that era.
SSP, The System/36 Operating System 
SSP ("System Support Program") was the only operating system of the S/36. It contained support for multiprogramming, multiple processors, 80 devices, job queues, printer queues, security, indexed file support, and fully installed, it was about 10MB. On the advanced/36, the number of workstations/printers was increased to 160. And with the "guest/36" which was the SSP operating system operating as a "guest" on OS/400 (V3R6 thru V4R4), you could have up to 216 devices.
System Security 
There are four types of System/36 security:
- Badge security.
- Password security.
- Resource security.
- Menu security.
Badge security is implemented using a stripe reader device attached to the System/36 terminal. In order to log on, the user not only typed the user/password information but also swiped the badge through the reader.
Password security was used to begin a session at a computer terminal. Unless security was inactive, a correct password must be entered to begin.
The System/36 sign on looked like this:
SIGN ON W1 User ID......... ________ Password........ ____ Menu (Optional). ______ Library......... ________ Procedure....... ________
Entering a zero ("0") for menu meant that no menu would be displayed. The S/36 "command display" would appear with no menu options. Entering a zero for library would override the default library and use the system library (#LIBRARY.) Entering a zero for procedure would override the default sign-on procedure and no procedure would run at sign-on. Mandatory menus cannot be overridden or respecified in libraries other than the named library.
The SECEDIT procedure was used to work with User IDs and passwords. The user profile contains a 1-to-8 character alphanumeric User ID, a 4 character alphanumeric password, a code for the user's security rating – M (Master Security Officer), S (Security Officer), O (System Operator), C (Subconsole Operator), or D (Display Station Operator) – and a number of other default settings.
The SECEDIT RESOURCE procedure was used to establish security ratings for file, library, folder, and group objects. Access levels of O (Owner), C (Change), U (Update), R (Read), E (Execute) or N (None) could be granted for a user to a particular resource. A group object was a sort of holding company that owned one or more lower objects. For example, granting access to the group ACCOUNTG made it easier to establish access to all of the accounting files. Group objects could also reference group files; the group UB referenced UB.OLD, UB.NEW, UB.01, or any filename with the embedded period.
SECEDIT USERID was also used to confine a user's operational authority to a specific menu. By entering a Y for Mandatory Menu and specifying a default sign-on menu, the security officer could prevent the user from any program access not found on that sign-on menu. A user so confined could only run menu options, send messages, and sign off the system.
NOTE: The printed disk catalog (VTOC, Volume Table of Contents) originally displayed all secured objects with the notation 3 as being secured. By Release 4 of SSP in 1985 this notation was changed to a 4.
Files, Libraries, and Folders 
SSP provides for two different data objects called files and libraries. Files contain records, almost always with a fixed record length. Libraries contain programs which can reference and access these files. SSP contained more than 80 different commands that allowed operators to create, delete, copy, edit/change, and secure files and libraries. Early in the System/36 development cycle, this was seriously improved to incorporate the folder object, which can have tremendous size, numerous extents, and contain subfolders.
A library or a file must exist in a contiguous organization on one fixed disk (however, a library may contain one "extent" of roughly 50 blocks which must be reorganized, and it cannot be extended if allocated to other users). A file may be organized with an EXTEND value or it may be allocated with FILE OCL to automatically extend. All record adds/updates/deletes wait while the file is being extended. It is good sense policy to create extend values large enough to minimize the frequency of extends. Libraries could have "extents" that were not contigious. At times, when compiling a program, an extent would be created and by doing a "CONDENSE", it was removed if there was enough room in the main allocation for it. Otherwise one did an ALOCLIBR to reallocate the library to a bigger size.
Files on the S/36 may be Sequential (S), Direct (D), or Indexed (I). An indexed file can have multiple alternate indexes (X), and in fact, a sequential file may have alternate indexes placed on it so there is no primary index. An indexed file contains a key, which must be contiguous and may be up to 60 characters long; however, alternate indexes may have three-part keys which are not contiguous with one another. Duplicate keys in indexed or alternate index files may be allowed or disallowed. A file with direct organization is built with all records added and cannot auto-extend. A file with sequential or indexed organization is built with no records added. An alternate index always has as many records as its parent, as opposed to a System/38-style logical file which is built with conditions to filter records from the parent.
SSP Compared To Windows 
When moving between these operating systems, some things to consider include the following:
First, the SSP user interface is command-based rather than graphical user interfaces like Windows; interacting with the computer is about what commands are typed and what keys are pressed, rather than the mouse click.
Keys F1-F12 are also called Cmd ("command") keys. Most standard S/36 keyboards have 24 Cmd keys (on some models, shifted F1-F12 keys are called F13-F24.)
SSP menus associate a number, not an icon, with a desired function or application. The Windows Control Panel is similar to the SSP Main System Menu which is accessible from an application menu by pressing Cmd5.
Windows uses point and click; with SSP, the most important function is Enter/Rec Adv, also known as Enter. Under Windows, the operator moves from field to field with the mouse click or by pressing the Tab key; with SSP, Field Exit and Field Backspace are also important.
Keyboard tricks 
Experienced Windows users know that using the ALT key in combination with up to four digits on the keypad can produce characters that are otherwise unavailable on standard PC keyboards (such as accented vowels, graphic box drawing characters, and so on). Similarly, Shift+Tilde along with two hexadecimal characters will accomplish the same task on the S/36.
Spooling (printing) 
SPOOL is an acronym for Simultaneous Peripheral Operations On Line.
As with some modern machines, computer printers made during the S/36 era were very slow, to the point that it was possible for the S/36 or other computers to write data to the printer faster than it can print. Spooling was used on the S/36 to deal with this issue, with the added benefit that multiple programs could write to the printer concurrently, without waiting for each other to finish.
To allow the system to manage the problem, system components called "writers" and "spool files" were developed. A writer is a small system program that reads the spool file, matches a particular printer with a ready-to-print spool object, and begins sending instructions to the printer. It's a two-way process; the printer sends a signal back to the system when it is ready for more work. In order to avoid mixing up data from two spool files, the first report to finish and close is traditionally printed first.
When the operator prints paychecks, it is vitally important that paycheck information prints on check forms and not on plain paper; likewise, a regular printout should never print on expensive check forms. Therefore, forms numbers were created. A forms number is a one-to-four-character alphameric field that programs and operators use to straighten out this problem. Programmers use the PRINTER OCL statement as follows:
// PRINTER NAME-PAYCHECK, FORMS-BUXX, DEVICE-P1
When the spool writer is ready to process the checks spool entry, this message appears at the subconsole:
SYS-1404 Options (012 )
On printer P1, change to forms number BUXX
By replying 1 to this message AFTER changing the forms, the operator could be sure that no other reports on standard stock would print on the checks.
Form alignment 
Check forms must be perfectly aligned or all of the numbers won't fit in the little boxes, wasting an expensive form. Therefore, an alignment can be performed using the PRINTER OCL statement:
// PRINTER NAME-PAYCHECK, FORMS-BUXX, DEVICE-P1,ALIGN-YES
The subconsole will now get this message when ready to print checks:
SYS-5825 Options (012 )
Align the forms in printer P1
By replying this message AFTER aligning the forms, the operator could be sure that the check information didn't print until the forms were properly aligned.
Language support 
The S/36 had four compilers: RPG II, COBOL, BASIC, and FORTRAN. RPG was cheaper, created compact code sizes, and became by far the best-seller. Cobol's popularity in the larger business community made it popular on the S/36 as well. Fortran is not very practical for data processing purposes, and while BASIC was powerful and easily portable to other IBM computers, it was limited by being implemented as an interactive 40K session.
One feature of the S/36 was that Basic and Fortran were exclusive. One could not run a Fortran program on the system when running Basic, nor vice versa. Fortran was certainly not a popular language, so one would suppose this microcode level problem was only annoying to academia.
Other object types 
Cobol, Fortran, and RPG generated object code (type O). Basic was interpreted only; a compilation utility called BASICS created subroutine code (type R). BASIC programs could be saved as sources for compatibility with other computers, but the project's text was preserved in the subroutine (unless the programmer used the LOCK command to keep it private.)
Procedures, which use OCL to start programs and assign resources to them, are type P.
Source members for all objects are type S, with the exception of Basic as specified above.
DFU programs generated subroutine (R) code, as did WSU programs.
Screen formats generated object code.
Menus generated object code. A menu is simply a very specific screen format with a companion message member suffixed with two pound signs ("##") to contain the action to be taken when the associated number was chosen. System/36 menus allowed the operator to choose numbers between 1 and 24. On the System/36, a programmer could customize a menu using screen format language, but calling a customized menu that did not conform to exacting system requirements could cause a program error.
Message members generated object code that could be called by a program using the MEMBER OCL statement:
// MEMBER USER1-PROGMSG
Passing a four-digit code to an assembler routine returned the associated text. It was also a way for the programmer to push up to 10,000 74-byte constants out of program space.
Programming ability was not essential. A short sequence of file and input specifications could be created and stored as a source member. A component called Data File Utility (DFU) could then be used to generate on-screen displays that could be used to create and edit files and print reports.
Popular System/36 Applications 
- The most popular program was Programmer/Operator Productivity Aid (POP) It cost $1,000. It was, however, widely pirated. It was included with the Advanced 36.
- MAPICS, the Manufacturing and Production Information Control System, was a popular S/36 application.
- IMAS, a simple accounting package
- BPCS, a more advanced accounting system
- IBM Office/36 collection of programs (DisplayWrite/36, IDDU, Query, and so forth) were popular in the late 1980s and were later bundled with the Advanced/36.
- A popular database tool available from a third party was FEU (File Edit Utility.)
- There was a games library called FUNLIB that contained games like Star Trek, Football, Hangman, Coffee, Grand Prix, and a Biorhythm program. An associated PICTURES library let you print ASCII art of Star Trek's Mr. Spock, John Dean, and Christmas calendars.
System/36 magazines 
A number of publications were available covering the System/36, such as DataNetwork (which became Midrange Computing) and News 34/38 (which became News 3X/400, News/400, and iSeries Magazine.) Subscription prices ranged from US$8 to US$12 per copy. Others included Tips 'n' Techniques (TNT), and SCOPE/36, whose publishers distributed a newsletter format and a library of utilities and source code on diskette media. In the latter years of the S/36, registered subscribers could download source code from the Internet.
- News 3X/400's Desktop Guide to the S/36
- Midrange Computing's Power Tools
- Everything You Always Wanted to Know About the System/36 But Nobody Told You by Charlie Massoglia
- Writing and Using System/36 Procedures Effectively by Charlie Massoglia
- Everything You Always Wanted to Know About POP But Nobody Told You by Merikay Lee
- System/3, System/34, and System/36 Disk Sort as a Programming Language by Charlie Massoglia
Hardware models 
System/36 Model 5360 
The System/36 5360 System Unit vaguely resembled a huge washer-dryer in appearance, but unlike its predecessor, it ran on 220 volts AC. At 700 pounds (318 kg) this was still not quite a Pocket PC. Conventional wisdom called for the system to be kept in its own air-conditioned room. Conventional wisdom was, actually, very wise about this, since the system cost around US$140,000.
The five red lights on the System/36 were as follows: (1) Power check. (2) Processor check. (3) Program check. (4) Console check. (5) Temperature check.
If any light other than #4 ever came on, the system needed to be IPLed. Console can be restored if it has been powered off, but the other conditions are unrecoverable.
There were various models of the 5360, including a C and D model that dealt with speed and the ability to support an additional trailer to house additional drives.
System/36 Model 5362 
IBM introduced the 5362 or "Compact 36" in 1984 as a system targeted at the lower end of their market. It had a deskside tower form factor (albeit a bulky one). It was designed to operate in a normal office environment, requiring little special consideration. It differed from the 5360 in by having a more limited card cage, capable of fewer peripherals. It used 14" fixed disks (30 or 60MB) and could support up to two; RAM (main storage) ranged from 128KB to 512 KB. One 8" floppy diskette drive was built in.
The 5362 also allowed the use of a channel attached external desktop 9332-200, 400, & 600 DASD, effectively allowing a maximum of 720MB.
System/36 Model 5364 
The model 5364 was called the "System/36 PC" or "Desktop 36" (and also, informally, the "Baby/36" by some – but this name was later attached to a software program produced by California Software Products, Inc.). The 5364 was a June 1985 attempt by IBM to implement a System/36 on PC-sized hardware. Inside, there were IBM chips, but the cabinet size was reminiscent of an IBM PC-AT of the period. The machine had a 1.2 MB 5.25-inch diskette drive, which was incompatible with PCs and with other S/36s. The control panel/system console (connected via an expansion card) was an IBM PC with at least 256KB RAM.
System/36 Model 5363 
The IBM 5363 was positioned as a replacement for the 5364, and was announced in October 1987. It used a deskside tower style enclosure like that of the 5362, but was only 2/3 the size. It featured updated hardware using newer, smaller hard drive platters, a 5¼" diskette drive, and a revised distribution of the SSP.
The AS/Entry (9401) 
The AS/Entry was just a stripped-down AS/400. The operating system was SSP Release 6. This machine was offered c.1991 to target customers who had a S/36 and wanted to one day migrate to an AS/400, but didn't want a massive investment in an AS/400. In this regard, the AS/Entry was a failure because IBM decided the machine's architecture was not economically feasible and the older model 5363 that the 9401 was based on was a much more reliable system.
System/36 Environment Mode of OS/400 
System/36 environment Mode is a feature on the AS/400 that is used to run OCL and RPG II programs on OS/400. The operating system of the AS/400, OS/400, is contained in a library called QSYS. This was augmented for the S/36 folks with a library called QSSP so that many SSP commands could be in some way supported. To start the S/36E on OS/400 enter the command strs36.
The Advanced/36 (9402-236/9402-436) 
In 1994, IBM released the Advanced/36. Priced as low as $7995, it was the machine that allowed System/36 users to get faster and more modern hardware while "staying 36." The Advanced/36 allowed SSP, the operating system of the System/36, to be contained within AS/400's OS/400 as a "virtual machine" so that it could be upgraded to a full-blown AS/400 for $15k. The A/36 was slightly larger than a common PC cabinet and could easily be mistaken for a 1990s-era tower PC. System/36 cabinets were white (actually "off-white") and the Advanced/36 was black.
The Advanced/36 bought the world of System/36 and SSP about five more years in the marketplace. By the end of the 20th century, the marketplace for the System/36 was almost unrecognizable. IBM printers and displays had completely dominated the marketplace in the 80s, but now the commonplace sighting was a PC or a third-party monitor with an attached PC-type printer that effectively shaved 70 to 90 percent off of IBM list for the same goods. Twinaxial cable had disappeared in favor of cheap adapters and standard telephone wire.
The System/36 market was eventually devoured by AS/400s at the high end and PCs at the low end. Personal computers were not nearly the database equal of SSP, but time and technology had taken their toll on a system that had remained basically unchanged since 1983. By 2000, the Advanced/36 was withdrawn from marketing, and System/36s are disappearing rapidly from the marketplace.
The AS/400 Model 150, 170, etc. 
By 2000, IBM offered certain AS/400 models that could run SSP as a "main" operating system or as a "guest." These were the Model 150 and Model 170 System Units. Actually any AS/400 that ran V3R6 through V4R4 could run the "guest". Up to 3 guest/36 virtual machines could be on one AS/400.
Migrating from the System/36 
||This article is written like a personal reflection or opinion essay rather than an encyclopedic description of the subject. (January 2013)|
||The neutrality of this section is disputed. (January 2013)|
||This section needs additional citations for verification. (January 2013)|
Why People Didn't Migrate 
One reason people continued to use the System/36 when it was no longer the speed champ, the storage champ, or the technology champ of the computer industry is, it was the economy champ. It was cheaper to buy one computer with 20 workstations and the programs that 20 people used than to buy 20 computers with 20 copies of every program they used. Another reason was that early PCs didn't network very well and had a tendency to crash, destroying valuable data.
Migrating to the Advanced/36 
Migration to the Advanced/36 was facilititated by a device called a TDL (transition data link), which could be purchased or rented, that moved the files and libraries from the old System/36 to the new Advanced/36 via twinax cables. Another way to migrate was that if you had the 6157 (or built in) cassette drive on the S/36 (or the 8809 9 track tape drive), you could simply do a "save all" and "restore" it onto the Advanced/36 (if you had comparable cassette drive or reel to reel drive).
Migrating to the AS/400 (iSeries) 
Migrating to the AS/400 could be tough for those owners unwilling or unable to take the time or the expense to clean their data or get new AS/400 versions of their S/36 applications.
Even simple data transcription errors could generate "data exceptions" and crash programs, a blank field filled with spaces and being defined as a numeric field should be filled with zeros, that, or its definition changed to alphanumeric. System/36 files were "flat" files without any definition, all System/36 applications each contained their own (poorly or partially) cloned definitions in order to access and modify the data. Also, because of inadequate data entry verification, with users often being able to use quick and dirty System/36 utilities to modify files, System/36 files could contain decimal data errors and other corrupt data that the System/36 applications ignored or masked. This data proved troublesome on the AS/400 when accessing it with revised or new "native" applications and especially when the data was converted to "native" format in internally self-described files without being "cleaned" before or during conversion.
It was obvious that the System/36 owner wanted to put off going "native" on the AS/400 as long as possible, and they put it off quite a while since there were so many IBM offerings that allowed owners to put it off, including the System/36 Environment "compatibility mode", the AS/Entry, and the Advanced/36.
The System/36 and the AS/400 were not object-code compatible; source code had to be re-compiled via an RPG II compiler for the System/36 Environment of the OS/400. On the other hand, since OCL was interpreted, it ran as is in the System/36 Environment. There were and still are some tools by 3rd parties for converting the existing System/36 application to run "native" on the AS/400, as well as consulting firms that still offer this service.
However with changes made in the S/36EE (S/36 Execution Environment) for data decimal errors, it was quite easy to migrate from a system/36, advanced/36 or guest/36 to this environment and run and begin to take advantage of the features not only of SSP/OCL but of the i5/OS (OS/400) Operating System and CL (Control Language) as you could mix the two and then begin to develop new applications (if desired) in the native i5/OS environment. About the only thing that would cause a user problems from the typical S/36 shop would be if they had used assembler subroutines called in their RPG II programs to do some special tricks. Some of those could be emulated such as reading cursor row/column for example. And some of the limitations that existed in SSP such as a program maximum size of 64KB were gone, the number of files in a program dramatically increased, along with the number of tables/arrays,number of workstations/printers allowed on the machine, number of files on the system, number of records, etc. From within an RPG II program you could call an RPG/400 or RPG-IV program that accessed an internet function such as credit card approval or an XML service.
Migrating to the RS/6000 (pSeries) 
An /36 emulator called Open/36 by Open Universal was available at (>1000 DM, > US $500, / terminal). Many companies first tried to emulate the old hardware but ended recoding the RPG applications for the RS/6000.
Migrating to UNIX (HPUX, Solaris, AIX) and Linux 
Companies like Unibol (now Infinite Software) developed a product named Unibol 36 (now named Infinite 36). This product family incorporated compilers and a deployment environment for RPG II and COBOL applications for the System/36. The current version of Infinite 36 deploys under 64-bit versions of HPUX, AIX and Red Hat Enterprise Linux.
Migrating to Windows 
California Software (now Infinite Software) developed a toolset named BABY/36 that recompiled RPG II source and deployed it under the Microsoft Windows operating system. Infinite Software later released a version of Infinite 36 for Windows. The current version of Infinite 36 operates under Windows Server 2008 r2 (64-bit).
Other Choices 
Many customers left IBM hardware altogether. The UNISYS "A" system could function under an SSP-like operating system.
- IBM Archives: Italy chronology 1970 – 1997
- IBM Archives: IBM System/36
- IBM Archives: Rochester chronology – page 4
- IBM Unveils Multitasking Processor for Use with PC Interface, and Upgrades System-38 Processor. AT&T Agrees to Buy Stock in Chip Maker, CAD Firm; Cuts Long-Distance Prices
- COMPANY NEWS; I.B.M. INTRODUCES SYSTEM/36 MODE – New York Times
- IBM Systems Magazine – An Overview of the System/36 Environment
|Wikimedia Commons has media related to: IBM System/36|