14. How Expert Designers Go Wrong

Collapse of the aerodynamically misdesigned Tacoma Narrows Bridge
AP Wide World Photos

I beseech you, in the bowels of Christ, think it possible you may be mistaken.

OLIVER CROMWELL [1650]

But when I make a mistake, it is a beaut!

FIORELLO LA GUARDIA

The besetting mistake of expert designers is not designing the thing wrong, but designing the wrong thing.

Mistakes

In any field, the amateur makes lots of little mistakes that a professional would never make. Training, internship, and practice have drilled the professional on good technique.

Professionals, when they goof, do it in a big way—making bridges that collapse during construction, houses with no stairs between stories, computers that radically waste memory bandwidth, programming languages that are too rich to be learned.

Henry Petroski has suggested that after each revolution in materials or technique, designers do in fact

• Tread cautiously at first

• Master the new approach

• Begin to extend it boldly, often forgetting the underlying assumptions

• Overreach in their boldness and self-confidence, pressed perhaps by hubris and competitiveness

He cited a study documenting a consistent 30-year period between major bridge collapses and suggested we were due for another.¹ The I-35W bridge collapse in Minneapolis proved him right.

Probably a major cause of professionals’ gross failures is the appearance of a new generation of designers, trained from the start in the new technique. Not having suffered through the birth pangs, which often consist of controversy that probes assumptions, the new professionals are much less conscious of the assumptions and caveats.

They are also usually quite unconscious of how the new technique fits into the whole armory of possible techniques. The professional, I would suggest, is apt to be familiar with the trees, doesn’t see the woods, and is slow to ask, “Does what I am doing make sense in the large?” To paraphrase Thomas Jefferson, the professional is often so preoccupied with doing the thing right that he fails to stop and ask, “Am I doing the right thing?”

In the development of the System/360 computer family, our superb group of seasoned computer architects rejected automatic memory management, an omission that had to be remedied almost before the paint was dry.

Success is dangerous for the professional designer. Failure stimulates analysis, scrutiny, rethinking. Success stimulates confidence both in design technique and in oneself. Both trusts may be misplaced.

The Worst Computer Language Ever

A vivid example of expert failure is IBM’s Operating System/360 Job Control Language (JCL), now known as MVS Job Control Language for z/OS. It is, I am convinced, the worst computer programming language ever devised by anybody, anywhere. It was developed under my supervision; there is blame enough to go around among all the supervisory levels.

It is instructive first to examine JCL’s deficiencies as a programming language. Then one must inquire how a software team of real experts, having on call, for example, designers of the original Fortran and leading language theoreticians, could go so radically wrong.

Although the mistakes were made 45 years ago, JCL is still in use, in essentially the same form. The mistakes continue to curse us. And the lessons are timeless.

What’s JCL?

OS/360 was originally designed as a batch operating system, although from the first, terminal users could interact in sending jobs into the work queue, setting them up, inquiring about status, and retrieving results. The Job Control Language is a scripting language that specifies the options and priorities to be used for computing a batch job, the input files to be mounted, the disposition of each output file, and a host of other lesser functions concerned with the management of program and data files. A JCL script might specify, for example, compilation of a source program, linking with library programs, execution against particular datasets, and the printing, recording on disk, and archiving on tape of the several outputs.

JCL is really hard to learn and use. A set of JCL commands that successfully controlled a computing process would therefore be copied blindly by other users. Only the boldest would go inside the JCL script to change anything except obvious parameters. Even today, archived programs in Fortran and COBOL are stored away with the attendant JCL, in “dusty-deck” files.

So What’s Wrong with JCL?

The biggest flaw of all was that JCL is indeed a programming language, but it was not perceived as such by its designers.

One Scheduling Language for All Programming Languages

JCL is deeply flawed in its very concept.

OS/360 provided compilers for a rich variety of programming languages, at least six besides Fortran and COBOL. Each user had to know at least two languages: JCL and his programming language of choice. Most did not, hence the borrowed JCL and the dusty decks.

What one wants, instead of a single schedule-time language like JCL, is a schedule-time capability, just like the compile-time capabilities provided for PL/I and for the S/360 Macro Assembler. Then each programmer could work within a single language, specifying some actions for compile time, some for schedule time, and most for run time.

Like S/360 Assembler in Syntax, Rather than a High-Level Language

Having mistakenly decided to have one schedule-time language, the designers chose the wrong one. As early as 1966, one year after the full OS/360 was up and running, assembler-language jobs accounted for only about 1 percent of all jobs. A major paradigm shift had happened, and it wasn’t recognized.

But Not Exactly Like S/360 Assembler Syntax

Enough deviations crept into JCL that knowing S/360 Assembler syntax did not mean knowing JCL syntax.

Card-Column-Dependent

Fortran, for reasons having to do with the 36-bit word of the IBM 704 (1956), allowed statements of 72 characters, plus continuation lines. Characters beyond the 72nd in a line were ignored. (Card columns 73–80 were originally used to serially number program cards, so that if dropped they could be readily reordered!)

JCL followed this punched-card-based format, exactly when the rest of OS/360 was being predicated on terminal access. (Terminals then, and later, didn’t even indicate a numeric character position, so users didn’t know when they had reached position 73.) A major paradigm shift was happening, even being pushed by this very system product, and it wasn’t recognized.

Too Few Verbs

The designers’ proud boast was that JCL has only six verbs: JOB, EXEC, DD, and so on. And so it does. But the number of functions the language has to perform far exceeds six.² With an imposed “elegant” simplicity not up to the actual complexity inherent in the task at hand, the complexity inevitably breaks out in jury-rigged solutions.

Declaration Parameters Do Verbish Things

The verb functions have to be provided somehow. So in JCL a Data Definition (DD) statement is provided with a (too-)rich set of keyword parameters. Many of these are imperative verbs in disguise, such as DISP, which commands what to do with the dataset after a job step ends.

Almost No Branching

Central to most programming languages is the concept of a conditional branch. JCL has no such central concept—branching is an afterthought, restricted in action, achieved through a parameter.

No Iteration

There is no direct primitive in JCL to accomplish iteration; it must be fashioned out of the awkward branching. The designers did not imagine an iterative action in a schedule-time script.

No Clean Subroutine Call

Similarly, the designers did not perceive any need for a subroutine call in a schedule-time script. This is harder to understand, for many JCL programs make extensive use of open subroutines, that is, repeated sequences of commands identical except for a few parameters.

How Did JCL Get That Way?

The professionals who designed JCL brought too much experience to the task. Their familiarity with what they thought to be the problem blocked their thinking about it afresh, in its wider setting. In this case, following an exemplar brought disaster.

The key thinkers on the OS/360 JCL had come to the OS/360 project fresh from the highly successful IBM 1410/7010 Operating System (1963). In terms of function, the 1410/7010 OS was perhaps two orders of magnitude simpler than OS/360. It was strictly a batch operating system designed for classical file-maintenance applications, without teleprocessing. Scheduling functions such as file names and I/O device assignments were specified by a few simple control cards placed before each job’s deck as it was put into the punched-card reader, a technique dating from tape-based operating systems.

The designers of OS/360 JCL saw their task as being a replay of their 1410/7010 experience—designing, as they explained it, “a few control cards for the scheduler.” This was the fatal mistake. Each part of this goal description turned out to be wrong in concept, and stating it wrongly led to wrong thinking throughout the design.

Few types of control cards did indeed characterize the 1410/7010 operating system, and fewness equated to simplicity as a goal for OS/360 JCL. This led to having too few verb types. Not only was fewness of card types wrong; so was the implicit assumption that each job would be controlled by a few cards of each type. In the event, JCL scripts usually contained dozens of statements.

Cards was the second conceptual misleader. The whole JCL programming language was conceptually built around the punched card just as it galloped into obsolescence.

Control cards implied that each was separately interpreted and almost independent in action—and indeed, that was the case in early operating systems. This accounts for the limited branching, iteration, and subroutine facilities of this poor stunted programming language.

Thinking of the cards as separate complete commands explains, I think, why none of us ever recognized that JCL was going to be a programming language—one interpreted and executed at schedule time. Our basic problem was a pedestrian vision.

A consequent problem was that JCL was never really designed—it just grew. Had it been recognized as a system language, it might perhaps have been designed as a language, using the expertise and experience of our language designers.

But, it wasn’t. Initially, as the “layout of a few control cards,” it was a by-task incidental to the main job of designing the job scheduler itself. As the tasks of file system management, teleprocessing network management, and so forth, grew during OS/360 design, every new schedule-time function or specification got loaded onto JCL. Since the language had little flexibility, generality, or comprehensive structure, the new specification ended up as a new keyword parameter, most often in the DD statements. So what should have been adjectives in declarations became imperative verbs with all sorts of action consequences.

Lessons Learned

1. Study failure examples even more carefully than you study successes.

2. Watch yourself after success. Success stimulates confidence in the design technique, in the design itself, and in oneself. All may lead to overconfidence.

3. Think at the top level about the object you are designing and its assumptions about the environment in which it will be used. Is a paradigm shift under way? Will your assumptions still be valid a decade hence? Are you designing the right thing?

Notes and References

1. Petroski [2008], Success through Failure. He cites the original study, Sibly [1977], “Structural accidents and their causes.”

2. A few more verbs have been added during JCL’s evolution. A current JCL standard (November 2008) is given at http://www.isc.ucsb.edu/tsg/jcl.html. The original one is in IBM Corp. [1965], IBM Operating System/360, Job Control Language.