The
IBM System/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 features was an off-line storage mechanism 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.
IBMers and enthusiasts think of the System/34, System/36, and
System/38 as "midrange" computers.
Overview of the IBM System/36 Are words used interchangeably to describe the same thing. An operator sat in front of a device that vaguely resembled today's PC, except the monitor was small, expensive (US$2,000), low-resolution (24x80) and the available colors were green and bright green, or for the fancier, the seven-color IBM Color Monitors. By the 1990s, third-party companies made terminals for the so-called 5250 marketplace. 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
Some purists refer to a printer as one type of workstation.
Terminals, displays, screens, workstations and monitors Prior to 1984, the 5251 monitor predominated - it was US$2,000 and what IBM called "dual color" (green and bright green). 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 fancy graphics-capable terminal that basically nobody bought.
IBM Colors 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.
Programming IBM Colors 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 five terminal lights The standard US keyboard was heavy, clunky, had 20 more keys than today's 102-key PC keyboard, and weighed up to 25 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.
Keyboards A great computer system wouldn't be complete without great printers. Typical System/36 offerings would include:
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 somewhere around 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 printers were well-built, had impressive duty cycles, and were more expensive than one would think. For example, a 5262 would go for about US$12,000.
Printers Configuring devices Early 1980s-era printers and workstations had a series of binary switches known as "dipswitches" for configuration. The binary OFF settings, zero ("0") and one ("1") were used to switch back and forth internally. 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 setup 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.
Dipswitches 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.
Online Setup Up to 60+ 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. Eight devices could be configured per line; these were numbered 0 through 7.
Three binary switches on every device were used for the terminal's address (the physical designation of a particular terminal on a particular line.) Sometimes, the switches were numbered 1, 2, and 4. In order to set an address, simple addition was used:
Zero is all settings off. One is the 1 setting on. Two is the 2 setting on. Three is the 2 and 1 settings on. Four is the 4 setting on. Five is the 4 and 1 settings on. Six is the 4 and 2 settings on. Seven is all settings on.
Two devices can never have the same address on one line. Once the addresses were set, the system could be configured to use them.
Setting the Address The System/36 had a feature called auto-configure. Just set the addresses on the devices, turn off the S/36, connect the devices to the S/36, and IPL. The system will configure the devices for you, assign workstation IDs, and so forth.
Auto-Configure 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 alphameric. 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.)
Use CNFIGSSP to place your 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 be
IPLed (rebooted.) When IPL finished, the new devices would appear on the status display.
Configuring Using CNFIGSSP System architecture S/36s had two eight-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 "D" model was a later model and was about 60 percent faster than the "A" model.
Processors The 5360, 5362, and 5363 processors had a front panel display with 4 hexadecimal LEDs. If you "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. Is this important to know? It sure is, if time is money - or if the system "hangs" on IPL and therefore a backup is impossible. FF00 has saved the day for a lot of System/36 folks.
The Front Panel 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.
Memory and Disk 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.
Disk Space Metrics The S/36 could compile and run programs up to 64KB in size, although most weren't this large. Due to the memory addressing nature of the S/36 and the 48K of actual RAM available, programs larger than this size were typically split into smaller modules.
Program Sizes 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.
Virtual Memory 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.
SSP, The System/36 Operating System There are four types of System/36 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:
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.
Badge security.
Password security.
Resource security.
Menu security.
System Security 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.
SECEDIT SSP provides for two different data objects called files and libraries. Files contain records, most 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.
Files on the S/36 may be Sequential (S), Direct (D), or Indexed (I). An indexed file may have 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 in length; 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.
Files, Libraries, and Folders 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.
SSP Compared To Windows 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.
Keyboard Tricks SPOOL is an acronym for Simultaneous Peripheral Operations On Line.
Spooling (printing) 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.
The need for spooling 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.
Sometimes the operator requires a dedicated, live printer - for example, when printing receipts for customers in real time, don't use spooling. Use the PRINTER OCL statement to declare the symbolic print job to be unspooled (SPOOL-NO.)
How spooling worked 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.
Forms The expensive check forms must be perfectly aligned or all of the numbers won't fit in the little boxes, which is tragic. 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.
Form alignment The S/36 had four compilers:
RPG II, COBOL, BASIC, and FORTRAN. RPG was cheaper, created compact code sizes, and became the far-and-away best-seller. Cobol's popularity in the larger business community made it popular on the S/36 as well. Fortran just isn't very practical for data processing purposes, and while BASIC was nice, it was implemented as an interactive 40K session. Teaching a BASIC class and watching eight operators try to key in BASIC programs at the same time was an interesting experience.
One interesting 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.
Language support Of course, Cobol, Fortran, and RPG generated object code (type O). Basic was interpreted only; a compilation utility called BASICS created subroutine code (type R). Interestingly, BASIC programs could be saved as sources for compatibility with other computers, but the project's text was nicely preserved in the subroutine (unless the clever 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 above-specified.
DFU programs generated subroutine (R) code. So 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 clever programmer could customize a menu using screen format language, but, caution, calling a customized menu that does not conform to exacting system requirements can 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 clever way for the computer programmer to push up to 10,000 74-byte constants out of program space. That's a big deal when a file is not practical.
Programming 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 you could use to create and edit files and print reports. It was not quite the equal of say, Access 2002, but in twenty minutes flat you could design a file and a report.
Other object types MAPICS, the Manufacturing and Planning Integrated Control System, was a popular S/36 application.
IMAS, a simple accounting package
BPCS, a more advanced accounting system
IBM Office programs (DisplayWrite, IDDU, Query, and so forth) were popular in the late 1980s and were included with the Advanced 36.
The most popular program was POP (Programmer/Operator Productivity Aid.) It cost $1,000. It was, however, widely pirated. It was included 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.
Popular System/36 Applications 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.
System/36 Magazines Hardware models 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 (318kg) 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$100,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.
System/36 Model 5360 IBM introduced the 5362 as a system targeted at the lower end of their market. It was a deskside tower form factor, though 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. One 8" floppy diskette drive was built in.
Addendum: The 5362 did allow use of a channel attached external desktop 9332-200, 400, & 600 DASD, effectively allowing a maximum of 720MB.
System/36 Model 5362 The IBM 5363 improved on the 5362 design. It retained deskside tower style enclosure, but was only 2/3 the size. It featured updated hardware using newer, smaller hard drive platters, a 5 1/4" diskette drive, and a revised distribution of the SSP.
System/36 Model 5363 Was called the "Baby/36" by IBMers, but this name was later attached to a software program produced by California Software Products, Inc. The 5364 was an early (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 a 1980s style PC. The machine had a 5-1/4" diskette drive, which was incompatible with PCs and with other S/36s. The control panel/system console had to be an IBM PC-AT with 256K of memory; no more, no less.
System/36 Model 5364 Was just a stripped-down AS/400. The operating system was OS/400. This machine was offered c.1991 to target customers who had a S/36 and wanted to stay with IBM hardware, but didn't want a massive investment in an AS/400. In this regard, the AS/Entry was a failure because it was too expensive and not enough S/36-like.
The AS/Entry (9401) Was a feature on the AS/400 that was used early on to help migrating S/36 customers. 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. However, there was not very much compatibility and certainly not from an OCL point of view.
System/36 Compatibility Mode In 1994, IBM released the
Advanced/36. Priced as low as $7995, it was the machine that allowed S/36 folks to get faster and more modern hardware while "staying 36." The Advanced 36 allowed SSP, the operating system of the S/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. S/36 cabinets were white (actually "off-white") and the A/36 was black.
The Advanced 36 bought the world of S/36 and SSP about five more years in the marketplace. By the end of the 20th century, the marketplace for the S/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 basically 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 S/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 S/36s are disappearing rapidly from the marketplace.
The Advanced 36 (9236/9436) 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.
The AS/400 Model 150, 170, etc. Businesses and agencies change their computers as often as their managers, and sometimes they change their computers because they changed their managers. The computer industry term for hardware platform change is
migration, and it's usually a headache for most of the people involved. Computer users have to deal with new security protocols, new equipment, and new software applications. Computer technicians and support personnel get a double dose of this since they are supposed to teach, convert, troubleshoot, and/or even design the new system.
Migrating from the S/36 Migration is something we must do in the computer industry, because it allows us to take advantage of new technology, replace obsolete equipment, and reduce maintenance cost. New generation computers are more flexible and offer more choices. Staying current is a goal that best serves the most needs for most people.
Why 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 out-and-out 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: twentieth-century PCs didn't network very well, and they had a tendency to crash and utterly destroy precious data.
Why People Didn't Migrate Was a dream. It was so easy to migrate to the Advanced 36 from the System/36. In fact, it was even easier with a device called a TDL (transition data link) that could be purchased or rented that moved the files and libraries from the old S/36 to the new A/36, via twinax cables.
Migrating to the Advanced 36 Was tough. The AS/400 had troubles like decimal data errors that the S/36 did not, so these types of problems were always popping up. It was obvious that the S/36 owner wanted to put off going "native" on the AS/400 as long as possible, and since there were so many IBM offerings that allowed owners to put it off (36 Environment Compatibility Mode, the AS/Entry, and the best one of all, the Advanced 36) they put it off quite awhile.
The System/36 and the AS/400 were not object-code compatible; source code had to be re-compiled via a RPG II compiler for the S/36 Environment of OS/400. If you did not have source code, you could not re-compile. OCL ran in the S/36 Environment.
However, there were and still are some tools via 3rd parties for converting the existing S/36 application to run "native" on the AS/400, such as "Native Conversion System" (NCS) from Applied Logic Corporation.
Migrating to the AS/400 (iSeries) Was tough. There is a /36 emulator called Open/36 by Open Universal, which was rather expensive (>1000 DM (> US $500) / terminal) and did not perform well. Many companies first tried to emulate the old hardware but ended recoding the RPG applications for the RS/6000.
Other Choices Note that some of these acronyms are common IBM terminology and are also used on the successor
AS/400s, on
IBM mainframes, and on many other IBM mainframe and midrange systems.
Acronyms Starting or restarting the system. This acronym was pronounced eye-pee-ell and was used as a verb ("IPL the system") with past tense ("then we IPLed") and present tense ("while we were IPLing") and so forth - as well as a noun ("after the next IPL.")
IPL - Initial Program Load IBM would distribute bug fixes on diskettes called PTF diskettes. By applying PTFs, you were able to address known and often unknown software problems. When the next release was issued (S/36's last release was 7.1 in 1996; the 5360/62 series received a release called 6.0 or "the VASP (Value Added Software Product)" in 1994.) the old PTFs were incorporated into the release update diskettes you received, and the old diskettes became useless. Since 8" diskettes were US$4 apiece retail in the 1980s, most S/36 programmers had a drawer full of them, usually for their own (not the company's) purposes. Since PTFs were only temporary in the sense that they were superseded by later releases of SSP, using the name "PTF" was considered odd.
PTF - Program Temporary Fix The operating system of the System/36.
SSP - System Support Program These are proper names given to system equipment.
The location of a specific file may be on disk A1, as revealed in the Disk VTOC or as specified in the COPYDATA procedure. However, a file may not be deleted from "A1" using the DELETE SSP procedure - as a disk file, syntax specifies it must be deleted from F1.
A1, A2, A3, and A4 refer to individual Fixed Disks (the hard drives).
F1 collectively refers to all of the Fixed Disks.
I1 is the Diskette Drive.
S1, S2, and S3 are the three single Diskette Slots (if a magazine drive is connected.)
M1.01-M1.10 are diskette slots 1 through 10 on Magazine 1.
M2.01-M2.10 are diskette slots 1 through 10 on Magazine 2.
A1-A4, F1, I1, S1-S3, and M1.01 - M2.10 Extended Binary Coded Decimal Interchange Code is the IBM mainframe counterpart of ASCII, the American Standard Code For Interchange of Information. On the PC side, the 8" diskette disappeared with the TRS-80 Model II Business Computer; the 5-1/4" diskette became the IBM PC standard in 1981 and the 3-1/2" diskette became the standard with the 286-based PC in 1984. But if you really want to make it difficult to convert your computer data to anything PC-based, use EBCDIC.
One glaring difference between
EBCDIC and
ASCII is the fact that ASCII numbers sort to the top and EBCDIC numbers sort to the bottom. Another is signed data. EBCDIC has ten negative digits (D0 to D9) and ten positive digits (F0 to F9). So, literally, -123 becomes F1F2D3 which in text is equal to "12L".
EBCDIC The
SDA utility allows the operator to build screen formats or menus online. Screen formats are very much like what Visual Basic and Access call "forms." Command keys can be enabled/disabled. Input fields, output fields, and constants can be created and conditioned. Conditions (in RPG these are called
indicators) can cause fields to disappear, change colors, and so forth.
SDA - Screen Design Aid SORT is an interesting program. It has one to eight input files, which may be of any valid record length. It has one output file, of any stated length, which may contain 1 to 8 million-plus records.
A sort can contain entire records or just 3-byte addresses which point to records in an associated file. This was called an address-out file or ADDROUT. When using an Addrout, the program read in these 3-byte addresses and then fetched associated records from the master file.
A clever programmer who wanted the benefits of a System/38-style logical file would use an Addrout with a RETAIN-S disposition:
// LOAD MYPROG
// FILE NAME-FILE1,LABEL-MYFILE, DISP-SHR
// FILE NAME-ADDROUT, LABEL-WS.SORT, RETAIN-S
// RUN
Using an E-specification, records read in the ADDROUT file were mapped to related records in the FILE1 file.
After the program finishes, the Addrout file doesn't exist anymore. It has been "scratched," or set to RETAIN-S, meaning the system auto-deletes it.
SORT - The system sort utility This looks like a DOS-era text editor. SEU allows data entry on a line-by-line basis. Special forms are used to assist the operator in keying RPG programs or other types of form-based languages (WSU, Sort, SDA, etc.)
SEU - Source Entry Utility This was an RPG-like language that ran on the S/36. It was focused on data entry type programs. WSU was free, but it wasn't particularly well-received because it was so limited. People who wrote WSU programs for data entry would invariably flag records and use S/34-era procedures like ORGANIZE and EXTRACT to reformat their data. SSP on the S/36 contained a more powerful command called COPYDATA. However, there were still no basic tools to work with data inside the file.
WSU - Work Station Utility This was an acronym describing the process of starting or restarting the System/36. It took quite a while to start a S/36 because every indexed file was examined and the index was rebuilt if needed; every connection to a device was tested; and if there was a user procedure in #LIBRARY called #STRTUP2, the procedure was executed.
IPL - Initial Program Load SSP could actually run one program on up to 7 terminals at once. The operator would start the program on a single terminal, then other terminals could join.
MRT - Multiple Requestor Terminal program Not an MRT.
SRT - Single Requestor Terminal program Started at a terminal, the NRT releases the requesting terminal and continues. This is similar to an MS-DOS TSR (Terminate and Stay Resident) program.
NRT - Non-Requestor Terminal program This is a non-interactive program that does not have a definitive end. It loops and loops, possibly doing cleanup routines or some-such.
NEP - Never-Ending Program In machine language, the No Operation code allows processing to discontinue temporarily and resume after a fixed delay. This is reproduced in programming languages with what is called a Do-Nothing Loop, or by continually measuring the system time and comparing to a calculated value until a greater-equal comparison was met.
Notable System/36 Programmers And Authors News 3X/400's Desktop Guide to the S/36
Multifactorial and polygenic disorders
Hibs career
Promise
Boundaries
