IBM vs. Burroughs
by David Barth
written June 1995
This is the story of how a Goliath (IBM) became stronger and more powerful at the expense of several David's (Burroughs and other competitors) in the computer
mainframe industry. International Business Machines was one of the first purveyors of commercial computing equipment. It sold tabulating equipment to the U.S.
Army in the early 1940s to help solve difficult mathematical equations related to development of the atomic bomb, described by Nobel laureate Dr. Richard P.
Feynman in his book, "Surely You're joking, Mr. Feynman!"
By the 1950s IBM dominated computer sales, worldwide. Development was primarily based on hardware requirements as opposed to software criteria. The engineers
designed the hardware and then the software group developed software to run it.
When Burroughs Corporation began development of a new design in the early 1960s, it decided to involve software engineers in the R&D process in an effort to make
their computer easier to use. The result of this unusual approach was the Burroughs B5500, completed in 1965. Unlike earlier Burroughs computers, the B5500
provided multi-programming capability, much the same as IBM's 360 series which followed shortly after. But the similarities between the Burroughs and IBM offerings
ended there.
IBM employed an architecture that used partitioned memory in which there was a foreground and one or more background areas. Programs that ran in foreground
had a higher priority over those that ran in background. Jobs set up to run in foreground included communications programs and those that needed to react quickly to
input. Number-crunching programs, and other batch programs that didn't need to react or complete quickly, were run in background. Obviously, it required an expert
systems programmer (not to be confused with a software programmer) to set up jobs, decide how much memory should be allocated to foreground and background
partitions, etc.
Burroughs took a different approach to memory allocation. Memory was thought of as a contiguous stack. The operating system was loaded first, using as much
memory as it needed at the bottom of the stack. On top of the operating system were piled all other programs, regardless of their priority. The priority of a program
was maintained in an operating system table that could be changed at any time by the operator. Memory allocation was dynamic in that when the operating system
sensed that a program had reached end of job (EOJ), it's memory was made available to the system by pushing down all of the programs running above it into the
space it had used. What this did was continuously maximize the amount of memory available at the top of the stack. If a program couldn't fit in the available
memory at the top of the stack, it would have to wait until enough room became available unless the computer operator interceded to force it in, at the expense
of the lowest priority programs in the stack, which would be temporarily shuttled to disk to make room for the big program.
This operation was called a "crash-out nine" alluding to the activity of "crashing out" lowest priority programs by giving the one awaiting room to run the highest priority,
9. As soon as the operating system saw a program waiting to run with a priority 9, it moved sufficient programs to disk, starting with the one with the lowest priority.
These programs were not aborted. They were suspended until sufficient space became available for them to continue running again. Burroughs called this memory
allocation design a "dynamically-allocated, push-down stack."
Another Burroughs design in memory allocation was the use of 2K blocks of program code that were moved into memory. At the time this was a unique concept that
allowed the computer to run a program that was larger than the available memory by moving a 2K piece of it to memory for execution. When that block was finished
executing, or a jump command required execution in a different part of the program that did not reside in the 2K block, the required 2K block overlayed it and processing
continued. Whether IBM copied this design or came up with it on its own is academic. IBM achieved a marketing coup by calling this methodology "Virtual Memory,"
and the fact that Burroughs was first with it has been forgotten. Had Burroughs called its program execution concept "Magic Memory," "Invisible Memory," "Unlimited
Memory," or some other name and made an extensive marketing effort to tout the achievement, the outcome wouldn't have changed. IBM was just too big to be out
maneuvered, out-marketed, and outsold.
If one thinks about IBM's memory partition design, one soon realizes that there was nearly always wasted memory. Not all memory in the foreground partition would be
utilized, and the same is true for each background partition. But do not jump to the conclusion that IBM was stupid to do this. No, this approach sold memory!
So, during the time that IBM and Burroughs competed, marketing influenced the way the machines were designed. To believe otherwise is to condemn IBM as
being one of the stupidest companies on earth, which, of course, is not true.
The next question was, how are the sizes and use of foreground and background memory managed? That is the job of systems programmers, in addition to a
myriad of other
tasks they accomplished, mandated by the design of the IBM computer. In the old 360 and 370 machines, the computer had to be brought down (all programs shut
down) to change the size of the partitions. However, IBM later upgraded the design of the software to allow dynamic partition sizing that does not require halting
the operating system.
It has been said that IBM provided jobs for more than 100,000 systems programmers! Burroughs did not provide a job for even one systems programmer! With Burroughs
systems, the operations staff controlled the entire computer, everything from running it to entering updates to the operating system. Any Burroughs shop that had
a "systems programmer" really had an operator with a fancy title. The machines were that easy to run.
Another Burroughs innovation that excited everyone who knew anything about computers was the concept of suspending a job when resources, such as a tape drive
or disk space, were insufficient. While IBM programmers suffered for thirty years, struggling with guessing how large a disk file would be next week or
next month, and having to constantly update the primary and secondary extents to allocate sufficient disk space, Burroughs took the position that any program could
have all the disk space it wanted. IBM systems programmers would point out that a runaway program that is in a loop could eat all the available disk space across all
disk packs. That is very possible. However, it is rare, and if it happened, it is of little consequence because of the way Burroughs handled disk resources. If a program
ran out of available disk space, it was suspended (not aborted) by the operating system. The operator was given a console message to that effect and told that he
had several options. He could cancel the program if he believed it was a runaway program. Canceling a program immediately released all of the disk space back to
the system. How easy! How brilliant! How elegant!
However, a common scenario was that the job might be an end-of-month job that had been running for twelve
hours and needed some more space to finish up. The console provided a list of disk files, the largest first, so the operator could decide if it should be deleted to
provide more space for the suspended program to finish up. When the operator deleted a file, the operating system saw the available space and let the suspended
program begin running again. If the available space was, again, used up, this scenario would be repeated until the job was finished or the operator elected to terminate
the job.
Ninety-nine percent of the time, a program that ran out of disk space really needed more and should have never been aborted. IBM automatically aborted any program
that tried to use more disk space than the amount that was allocated in the JCL (Job Control Language). Burroughs gave a file additional disk space in 4K blocks,
and continued to provide blocks of disk space until there was no more. It was an elegant solution to a problem that had caused every application programmer to get
hundreds of phone calls at 2 AM to adjust the primary and secondary extents in the JCL. Many IS managers have lamented the loss of time when a long-running
program aborted because of unknown file space requirements that could not easily be predicted.
IBM answered these criticisms by providing a program that would suggest extents for a file, based on the block size, record length, number of records, estimated
growth over a period of time, etc. This was a plausible solution for most files, but it fell short for files that did not grow in a linear manner. There are rumors that IBM
computers were capable of allocating space in this way at that time, but I believe this is simply untrue. If this were found to be true, applications
programmers would hang every systems programmer in effigy for not turning the option on. Besides, systems programmers, too, suffered from the file space allocation
nightmare thrust upon the computer world by IBM.
Another brilliant aspect of the Burroughs methodology was that the amount of contiguous disk space needed to be only 4KB. For IBM computers, all of the primary
allocation and each of the secondary allocations had to be contiguous. Not only that, only fifteen secondary extents are allowed! For files that require huge amounts
of space, file space allocation is a nightmare unless the disks had recently been defragmented to provide massive blocks of contiguous space.
This does not mean that IBM was stupid in forcing applications programmers to guess how large a file would grow in the future. No, this approach sold disks! Again,
here is an example of the marketing department running the show, and no one can fault IBM's marketing effort. It has paid off handsomely. Unfortunately, it
resulted in an inferior processing philosophy.
From a purely philosophical view, the greatest fault in IBM's way of doing business was that it has refused to change the abort mechanism to a more user-friendly
temporary suspension of a job the way Burroughs did. From a marketing standpoint, IBM did the right thing. IBM never improved a product unless it was under
severe competitive pressure to do so. Although it often upgraded a customer's system to a product "on the shelf," ready for distribution, if it was forced to, the
computer giant refused to do so unless an economic threat was perceived.
The humorous aspect of the IBM story is that, eventually, it faced severe competition from Bill Gates of Microsoft and filed suits to try to control Microsoft's
"monopolistic business practices," which, of course, IBM, itself, used in the past.
Another example of IBM's reluctance to make information systems (IS) development easier was that it continued to cling to the inflexible and unnecessarily
complicated job control language (JCL) for more than thirty years. Burroughs' answer to JCL was an unknown job control language called Work Flow Language
(WFL) which worked and looked a lot like a Cobol program. It could test codes set by programs, and then it could jump anywhere in the WFL job stream.
With JCL, only one code, the condition code, can be tested, and a limited decision was possible. Programmers remember the way IBM's JCL worked by
reciting the lyric, "If True, Fall Through." In WFL, various completion codes could be interrogated and the logic could jump anywhere in the job stream that the
programmer wished.
Many astute programmers have wondered why they had to program a "logical record length" (LRECL) in JCL when they had already specified this parameter in the
program. Burroughs answered this problem by having the compiler make it available in the linked module so that the WFL would have it. WFL always blocked
records based on a two-variable formula: the record length from the program and the type of disk in use. The result of the calculation was the optimal blocking factor
which the operating system automatically used. Later, IBM yielded to pressure and eliminated the need for block size to be specified in the JCL, a
feature available twenty years before in WFL.
When IBM brought out the System 360, jobs to be run on the computer had to specify which tape drive was to be used for each tape file: T1, T2, T3, etc.
The operator had to make certain that he mounted the correct tape on the specified drive or the job would abort. If that wasn't difficult enough, if a tape drive
were inoperative, the operator had to indicate to each job which tape drive would replace the bad one. This problem was subsequently corrected in later versions
of the IBM operating system.
When the B5500 was introduced, it had a novel, but simple approach to handling tape drives. The operator could simply mount the tapes that were going to be
used for any jobs on any tape drives. Old-time IBM operators would consider this to be a horrific travesty of protocol! When the Burroughs operator pressed the
"On-Line" button on a tape drive, the operating system would read the directory block at the beginning of the tape to find out what files resided on that tape. The
list of files would be stored and when a program was executed, if it needed a tape file, the operating system would check the list and provide that tape drive to the
program so it could read the file. If the program needed a scratch tape, the operator simply mounted a scratch tape on any drive and the operating system would
give it to the program that needed it. There were times when an operator had to be careful about running a program that used several tape drives because it might
prevent another, more important program from having access to a tape drive. Operators quickly learned how to manage the drives and were glad to have to flexibility
the operating system provided.
One development tool that Burroughs made available many years before IBM did, was a trace program. Superior to every other "trace" type of tool provided by
IBM, it showed each program statement and the contents of each field in the statement. IBM's offering, when it was finally released, showed only the paragraph
name during the flow of the program. Even the a third party tool, Xpediter, showed the contents of fields on the screen, but because of the limited number of lines
that could be displayed on a screen, fewer than twenty variables could be displayed at any one time. The potential problem with the Burroughs trace was that a
programmer could generate thousands of pages of output since the trace printed each line of the program that was executed. If a program executed a billion
instructions, a billion lines of trace would be generated. Programmers had to be cautious how they set up a trace.
If there was one fault of Burroughs and all of IBM's other competitors, they lacked the marketing savvy and nearly limitless fiscal resources of IBM. It is as if the other
companies had a bunch of brilliant computer nerds developing outstanding products but insufficient budgets and expertise to market them. These products were left
in the dust by the unbelievable marketing power of IBM. This is a lesson that should be taught in every marketing class: "the best product is not guaranteed to
become a success. It must be effectively marketed." A corollary is that "products that may not be quite as sophisticated as other available offerings, if exquisitely
marketed, can be wildly successful."
From the earliest days in the 1940s, IBM wooed America's top industrialists and made itself a household name in computers. As a result, most company executives
who were not educated in the unique products available from Burroughs, always chose IBM. As late as 1989, the Affiliated Banks Service Co.'s board of directors
specified that the CPU (central processing unit) of the computer processing the work of the 29 banks in the holding company, be manufactured by IBM. The
board did allow that non-IBM peripherals could be used. As a result, the CPU was "Blue" (IBM's corporate color), and the peripherals were a mixture of units from
Amdahl, StorageTek, and Hitachi, vendors whose products offered a greater price/performance ratio.
It has been said that no one ever lost his job selecting IBM. On the other side of the coin, more than one IS manager has lost his job when he recommended the
lease of a non-IBM mainframe. A common scenario that led to an IS manager's ouster, involved a manager who recommended the lease or purchase of a Burroughs
computer to his boss. IBM was often able to get an audience through contacts with the boss's boss, a member of the board of directors, or some other company
executive. IBM would offer to set up a meeting between its experts, the IS manager, and his boss. The IBM representatives were well-trained in ways to make a
reluctant IS manager look very bad in front of his superior. So bad, in fact, that the IS manager often lost his job unless he saw the light, backed off, and agreed
that IBM should be selected. Only a fool would dare confront a panel of well-trained IBM experts. The conversation would not center on computers. It would directly
question the credibility of the IS manager with disastrous results for him. This is one way that IBM would continue the expansion of its business and
influence.
That was only one of many strategies used by IBM to achieve victory over competitors in the market place. In a different situation, when a potential client
questioned the viability of an IBM choice based on cost or some other "minor" concern, IBM would use a public relations approach. It would set up a meeting
between key client company representatives, the decision-makers, with an IBM vice president. In addition, IBM would allocate a fancy business jet to the disposal
of the IBM vice president.
As an adjunct to this maneuver, IBM would invite the client company decision makers to meet the plane, driven there in a limousine, go on board the plane to meet the
vice president, then all of them go to an opulent, private, catered reception. IBM was a master in the concept of "wining and dining," taking it to new
heights.
Another option was to fly the company representatives to another city for a dinner and reception. IBM's efforts nearly always resulted in the customer signing up.
IBM's competitors had to be satisfied sitting on the sidelines while IBM wooed the customer. If they did have the desire and expertise to challenge IBM at it's own
marketing game, they fell very short in the required funding to pull it off. The result of superior marketing made IBM a world leader and killed off its competitors,
including Burroughs, that had a superior product.