IBM System/34
From Wikipedia, the free encyclopedia
 |
This article may require cleanup to meet Wikipedia's quality standards. Please improve this article if you can. (August 2007) |
|
|
The tone or style of this article or section may not be appropriate for Wikipedia. Specific concerns may be found on the talk page. See Wikipedia's guide to writing better articles for suggestions.(December 2007) |
The IBM System/34 was a minicomputer marketed by IBM from 1978 to 1983. It was a multi-user, multi-tasking successor to the single-user System/32. Most notably, it included two very different processors, one based on System/32 and the second based on older System/3. Like the System/32 and the System/3, the System/34 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. Borrowing mainframe features such as programmable job queues and priority levels, the System/34 ran quite nicely on 64K of memory.
IBMers and enthusiasts think of the System/34, System/36, and System/38 as midrange computers.
[edit] Physical Appearance And Requirements
The System/34 5340 System Unit vaguely resembled a huge washer-dryer in appearance, and equally as noisy, due to its numerous internal cooling fans. It had several access doors on both sides, requiring several feet of clearance to open for servicing internal components. Inside, were swing-out assemblies where the circuit boards and memory cards were mounted. Overall, there was a tremendous amount of dead-air space inside. Weighing in at 700 pounds, this was not something you'd lug out to the car and take home for the weekend - though it did use standard household 220V power. 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 US$100,000-plus.
[edit] IBM Abbreviations
IPL - Initial Program Load
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.")
APAR -- Authorized Program Analysis Report
An APAR announced the entry of each new System/34 bug into the IBM process. If it was a genuine problem, the details would be sent for resolution to Rochester (for system problems) or Menlo Park / Rayners Lane (for application problems in MMAS, CMAS or DMAS). Eventually the APAR would be fixed by a corresponding PTF (see below).
PTF - Program Temporary Fix
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/34's last release was Release 9 in 1981) the old PTFs were incorporated into the release update diskettes you received, and the old diskettes became useless. Since 8" diskettes were US$5 apiece retail in the 1980s, most S/34 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.
[edit] SSP - System Support Program
The operating system of the System/34 called is System Support Program or SSP.
[edit] F1, I1, S1-S3, and M1.01 - M2.10
These are proper names given to system equipment.
F1 is the Fixed Disk (the hard drive.) 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.
[edit] EBCDIC
The 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".
[edit] SDA - Screen Design Aid
This application 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.
[edit] SORT - The system sort utility
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 from zero 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-ADDROUT,LABEL-WS.SORT,RETAIN-S
// RUN
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.
[edit] SEU - Source Entry 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.)
[edit] WSU - Work Station Utility
This was an RPG-like language that ran on the S/34. It was focused on data entry type programs. WSU was free, but it wasn't particularly well-received because it was so limited.
[edit] Terminals, Displays, Screens, Workstations and Monitors
Are words used interchangeably to describe the same thing. An operator sat in front of a device that vaguely resembles today's PC, except the monitor was small, expensive (US$2,000), low-resolution (24x80) and the available colors were green and bright green. (A special workstation called a "dual display" employed a system of mirrors and two users sat on either side of it with two keyboards... they were treated to 12x80 displays.)
Some purists refer to a printer as one type of workstation. Watch out for this usage.
[edit] IBM Colors
Before 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.) 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. By 1986, there was another type of "color" monitor - instead of green, the displayed characters were yellow ("amber," in IBM-speak) - just in case you were sick and tired of green.
[edit] Programming IBM Colors
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.
[edit] The Five Lights
On a 5251 type terminal, there were five lights to watch for:
(1) System Available light. If lit, this terminal is connected to the S/34 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 while 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.
[edit] Keyboards
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, a syllabary of the Japanese Language
[edit] CONFIGURING YOUR DEVICES
[edit] Dipswitches
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. Let's say, 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. That's what a dipswitch is.
[edit] Setting the Address
Up to 32 devices could be configured on a System/34, using four lines numbered from 0 to 3. 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.
[edit] 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 alphameric. The system also reserved certain IDs; you can't 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.
[edit] Processors
S/34s had two processors, the Control Storage Processor (CSP), and the Main Storage Processor (MSP). The MSP was the workhorse, based on System/3 architecture; it performed the instructions in the computer programs. The CSP was the governor, a different processor with different semi-RISC instruction set, based on System/32 architecture; 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/34 worked so well.
Actual clock speed of the CPUs inside a System/34 was fixed at 1 MHz for the MSP and 4 MHz for the CSP. In today's PC-based world, think of the S/34 as having the processor equivalent of perhaps two 10 MHz 386s.
[edit] Memory and Disk
The smallest S/34 had 48K of RAM and an 8.6 MB hard drive. (That's 48 kilobytes... less than some modern calculators. And the mammoth 12-inch hard drive spindle could be replaced by the storage capacity of a JumpDrive.)
The largest configured S/34 could support 256K of RAM and 256MB of disk space. This cost over US$200,000 back in the early 1980s. S/34 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... so technically while the system did not recognize more than 256MB, slightly more space than this existed.
[edit] Printers
Typical System/34 offerings would include:
- IBM 5211 - A band printer rated at somewhere around 160 lines per minute (LPM).
- IBM 4214 - An early dot-matrix printer rated at 200 or so characters per second (CPS).
[edit] SSP, The System/34 Operating System
SSP ("System Support Program") was the only operating system of the S/34. It contained support for multiprogramming, multiple processors, 36 devices, job queues, printer queues, security, indexed file support, and fully installed, it was about 5 MB.
[edit] System Security
There are three types of System/34 security: (1) the badge reader that almost nobody ever bought, so it isn't discussed here; (2) password security; and (3) resource security.
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/34 sign on looked like this:
SIGN ON W1
USER ID......... ________
PASSWORD........ ____
MENU (OPTIONAL). ______
LIBRARY......... ________
The PROF ("Profile") 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 PRSRCID ("Profile Resource Security By User ID") procedure was used to establish security ratings for file and library objects. Access levels of O (Owner), G (Change), R (Read), E (Execute) or N (None) could be granted for a user to a particular resource.
The printed disk catalog (VTOC, Volume Table of Contents) displayed all secured objects with the notation 3 as being secured.
[edit] Files And Libraries
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 60 different commands that allowed operators to create, delete, copy, edit/change, and secure files and libraries.
[edit] Disk Space Metrics
Disk space on the System/34 was organized by "blocks." One block = 2560 bytes. A high-end system would ship with about 90,000 blocks of disk space available. System objects could be allocated in blocks or records, but internally it was always blocks.
[edit] Program Sizes
Since the S/34 ran "8-bit" programs, the largest program that could be compiled and run was 64K. Most were not nearly that large. Since memory addresses were stored in 8 bits, a 64K program was often a giant monster RPG screen program with 3,000 lines of code, five or six files, and forty-odd array/table entries.
[edit] Caching
How does a 64K computer program run on a S/34 when only 48K of RAM is available? By using a process called caching. The system uses a cache or workspace on the hard drive to contain portions of the programs currently running. 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. The MSP performed the instructions in the computer program. Insufficient memory makes the system run slower, since the disk speed was only about as good in the 1980s as PC drives are today, and modern "burst mode" rates were unheard of at any price.
To aid the caching mechanism, many midrange programmers were taught to put their initialization functions at the bottom of the program source. While the practise continues to this day in the midrange community, the reasons behind it have long been forgotten.
[edit] SPOOLING
SPOOL is an acronym for Simultaneous Peripheral Operations On Line.
[edit] The Need For Spooling
Computer printers are slow. Very slow. On the S/34, computer programs could write data to the printer much faster than the printer can print... and there can be more than one program writing to a printer at the same time.
[edit] How Spooling Works
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.
[edit] When You Can't Spool
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.)
[edit] Forms Numbers
When the operator prints paychecks, it is vitally important that paycheck information printed on checks 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.
[edit] ALIGNMENT
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.
[edit] JOBS AND JOB QUEUES
What is a job?
In S/34 parlance, a job is any task the computer has been asked to do. A job has a job number, which for a program is the Workstation ID plus the time in HHMMSS format. For a printout, there's a spool job, which is "SP" and a four-digit suffix which is incremented by 1.
So what's a job queue?
Sometimes a needed report should be run in the background so as not to delay the users. If the parameters of the report are defined, it shouldn't occupy the user's time or occupy that valuable area on the CRT. For this reason, the Job Queue was invented. Imagine your program standing in line waiting to use the computer processor. A job queue has a size (the number of jobs that can be in line) and a value for concurrency (how many lines there are, or, more accurately, job queue jobs that can run at the same time.)
JOBQ OCL
The JOBQ OCL statement causes the job queue job to be initialized, but it won't begin immediately if there's a lineup. This allows some greater control of system resources.
EVOKE OCL
The EVOKE OCL statement also causes the job to run in the background, but EVOKE causes the called module to start immediately as a new job, while the procedure that EVOKEd the called module continues to run. There is no delay as there can be when JOBQ is called.
[edit] More Acronyms - MRTs, SRTs, NRTs, NEPs, and NOPs
MRT = Multiple Requestor Terminal program. 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.
SRT = Single Requestor Terminal program. Not a MRT.
NRT = Non-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. By definition, any program that is EVOKEd or JOBQed must be a NRT.
NEP = Never-Ending 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.
NOP = No Operation. 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.
[edit] Language Compilers
The S/34 had five: RPG II, COBOL, BASIC, FORTRAN, and Assembler. RPG was cheaper, created compact code sizes, and became the far-and-away best-seller. Cobol was very popular in the business community. 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. Assembly language is efficient, but it is a little too easy to accidentally create a processor check on the System/34.
One interesting feature of the S/34 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.
Also, the implementation of Basic on the S/34 is very close to that of the System/36, the System/23, the System/38, and the AS/400 (iSeries.) The implementation of RPG II on the System/34 is similar to the RPG II used on the System/36, the System/370 and the System/390, but not like the RPG III and subsequent RPG compilers for the iSeries.
[edit] Other Object Types
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). 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 parameter 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/34 menus allowed the operator to choose numbers between 1 and 24. On the System/34, 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 for this purpose.
[edit] Did I Have To Program?
Not really. You could create a short sequence of file and input specifications and store them as a source member. A component called Data File Utility 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 2007, but in twenty minutes flat you could design a file and a report, and that's not bad. Alternatively, you could define your data files and have the system generate a simple report program for you, using the Create Auto Report command.
[edit] Popular System/34 Applications
MAPICS, the Manufacturing and Planning Integrated Control System, was a popular S/34 application, as were CMAS and DMAS II, all developed at IBM's offices in Menlo Park.
The System/34 Text Editor was a precursor to the IBM Office programs of the future System/36 (DisplayWrite, IDDU, Query, and so forth.)
There was a version of POP (Programmer/Operator Productivity) that ran on a System/34. POP became extremely popular on the System/36 because of its browse and search functions for libraries and files and its easy point-and-shoot interface.
There was a games library called FUNLIB that contained games like Star Trek, Football, Hangman, Coffee, Grand Prix, and a status demo program called STDEMO that graphically displayed currently running programs.
The Britz Word Processing System was a general-purpose text editor that had mailmerge, label, and basic file editing capabilities.
[edit] System/34 Magazines
Not magazine drives, actual magazines that a person would read.
Programmers read about the System/34 in monthly magazines like DataNetwork and News 34/38. Subscription prices were high (around US$8-US$12 per copy) but most Data Processing departments had a subscription. Issues were highly prized amongst programmers for their invaluable programming tips.
[edit] Migrating to the System/36
From 1984 until the mid 1990s, businesses began the process of shutting down their S/34s and moving to twice-as-powerful System/36s. The two machines were not object-code compatible; but source code from a System/34 would basically compile and go on a System/36.
Some System/34 hardware was incompatible with the System/36. An example is the 5252 Dual Display Station, which could not be configured on a S/36.
[edit] Well-known System/34 Programmers And Authors
- Charlie Massoglia
- Donald J. Simons
