- What COBOL Is and Why You Might Care
- Standards, Implementations, Vendors and Portability
- A Brief History of COBOL
- COBOL in Context
In this chapter, we introduce you to COBOL and give you some context from which to view the rest of the book. COBOL is more than just another programming language. COBOL is an integral component in the public and private infrastructures in nearly every country on the planet. There’s scarcely a person alive today whose life hasn ’t been affected by COBOL programs that perform the day-to-day operations of governments, banks, transportation systems, and manufacturing and distribution systems. Invisible but powerful, COBOL is the brick and mortar of our information systems.
COBOL is an acronym that stands for "Common Business-Oriented Language." The COBOL language has been in widespread use in computer applications (business and otherwise) since the early 1960s. A high-level language with English-like syntax, COBOL has been embraced by every sector of business and government for its readability, maintainability, and portability. COBOL has continuously evolved to take advantage of advances in computer technologies. Unlike any othermany contemporary programming languages, COBOL was designed for use in the business world and is the language of choice of serious business applications developers worldwide. Today, COBOL is the solution for the enterprise. If you’re interested in working with the large information systems at the core of business everywhere, or you’re interested in developing new business applications, you should know COBOL. The good news is that COBOL is very knowable, straightforward, and fun to write. The further good news is that COBOL is rich, challenging, and present in the most complex of systems. You won’t get bored.
If your programming experience has been primarily in one computing environment, you may not be aware of the issues inherent in moving code from one environment to another. You may have never needed to know or care about such things as language standards, specific vendor implementations, and portability. However, if you’re going to master COBOL, you need a basic understanding of these principles. Over time, technological developments that grow into common usage need to be standardized to be used effectively. This is especially true of computer software in general and of programming languages in particular.
The COBOL language definition is the result of decades of work by scores of people who are passionate about creating a standard definition usable by anyone who wants to implement COBOL on a particular platform. The standards committee is comprised of representatives from any organizations that want to participate and touts membership from every COBOL compiler vendor, as well as members from the user community. When a particular organization chooses to implement the COBOL standard, the result is that programs written using that organization’s COBOL will work in the same way using any other organization’s COBOL implementation of the same standard. As long as code elements are restricted to those in the standard, code is portable between environments.
Although the COBOL standard rigidly defines syntax, early versions did not always take into account runtime behaviors, which are often platform specific. Later standards have taken these nuances more into account—for instance, the inclusion of a definition for portable standard arithmetic USAGE PACKED DECIMAL or BINARY. Thus, the standards process undergoes a kind of evolution to keep pace with computing industry changes, in both hardware and software.
In the real world, most COBOL vendors implement the standard and then go beyond it to provide features attractive to their developers. Sometimes these features prove so useful that they find their way into the next standard. You need to remember that if a feature isn’t in the standard, its implementation is not defined, and the feature may or may not work when you try to move your code to a different environment. We spend almost all of Part I of this book documenting the current COBOL standard language definition. In the last chapter of this part of the book, we discuss common nonstandard features you might encounter. In Part III, we discuss COBOL 2000the features under consideration for the next standard. We refer to the evolving new standard that incorporates those features (such as the Object Orientation elements and portable standard arithmetic) as COBOL 2000 because the standards committee hopes (but does not guarantee) that a new standard will be in place by the year 2000.
For Part I of this book we use the amend ’85 standard (except for Chapter 12 which deals with COBOL 2000). We attempt to keep the basics of COBOL and the principles we discuss generic, that is, platform independent. The reality is however, that many, many versions of COBOL exist – for almost every machine and operating system you can imagine. Where we need to get specific to demonstrate our point, we use IBM COBOL on the mainframe, and Fujitsu and MicroFocus COBOL on the PC.
To understand the full impact of COBOL, you need to understand that COBOL was designed by people for other people. It’s not a language defined for a particular machine—it’s a language designed to make it easier for more people to make machines do what they want them to do. The people behind the design constitute a dedicated group of individuals who, for more than 40 years, have labored to create, maintain, and expand this vital language. Crucial to their participation has been the funding, support, and leadership provided by industry leaders.
In 1950s, there was a movement to create programming languages geared specifically to solving problems in business. This movement was in stark contrast to the belief by many programmers and computer authorities that machine language, as the only language a computer could understand, was the best language to program with, no matter the task. Attitudes changed with some of the successes that came out of this effort. A prominent example of a successful programming language for business was FLOW-MATIC, developed and refined by the Sperry-Rand Corporation between 1954 and 1958. FLOW-MATIC was adopted by many large corporations and by the United States Air Force. It was relatively easy to code and debug, largely because its commands were English-like verbs (such as ADD or MOVE) and its data names could be long and meaningful (such as STATE-TAXES and TOTAL-PAY).
In 1959, with the potential for higher-level programming well proven, there began a concerted effort by computer users, along with academics and manufacturers, to define the objectives for commercial business languages. In April of that year, a meeting was held at the University of Pennsylvania to draw up requirements for a universal business language that could be used on all computers. The group asked the Department of Defense (DoD) to help sponsor the research, and DoD agreed.
- Interestingly, the DoD is often given credit for sponsoring COBOL as a way to standardize computing within the military. Although this is not strictly true, the Pentagon did quickly see the benefits of the effort and contributed heavily once invited.
At a May 1959 meeting held in the Pentagon, the group members tentatively decided to call their project Common Business Language (CBL) and to lay out its major requirements—simple English verbs, emphasis on ease of use over power, separate data and procedure segments. Thus, we see in COBOL a syntax that borrows the concept of paragraphs, sentences, and verbs. Perhaps a COBOL program isn't as readable as its inventors envisioned, and it is certainly more verbose than modern-day, minimalist programming languages, but the impetus to keep magic and trickery out of a program is laudable. COBOL’s founders sought to broaden the base of potential programmers, allowing the development of new applications to capitalize on people’s knowledge of business without the burden of understanding the eccentricities of a particular computer. Toward that end, it was decided that the language should be portable across multiple computer systems.
Three committees were formed: one each for short-range, medium-range, and long-range developments of the language. As it turned out, the short-range committee specified the language so convincingly that the others never had to convene. The committee members appointed a governing body from among themselves to oversee the development of the language; this governance body was named CODASYL. By the summer of 1959, the committee had developed a language based largely on the FLOW-MATIC verbs and its three parts—procedure, data description, and environment—which are now three of the four modern COBOL divisions. The committee also borrowed heavily from IBM’s COMMERCIAL TRANSLATOR; in particular, PICTURE clauses and group items (organized into levels labeled by 01, 02, and the like) originated in the IBM language. The committee named the language COBOL, for COmmon Business Oriented Language.
In December 1959, the final draft of the first COBOL specification was completed. Although COBOL has been frequently refined in a formal standardization process since then, many technical decisions made then affect the language today.
As a committee-built and maintained language, the evolution of COBOL has largely been through debate. This has naturally led to some compromises. For example, the question of whether to use symbols or verbs for constructing mathematical formulas led to a decision to support COMPUTE as a more symbolic way to render equations for which the ADD, SUBTRACT, MULTIPLY, and DIVIDE verbs were thought to be more readable.
The payoff for a politically compromised language, as opposed to a proprietary and inherently less portable one, proved to be worthy. COBOL gained popularity quickly. In 1960, the DoD announced that all purchased computers had to include COBOL compilers, and private companies quickly followed suit.
Although the initial requirement for COBOL stated that the standard had to be only good enough to last a couple of years, COBOL remains the most popular language on mainframes, and its use is growing on other platforms as well. One reason COBOL became so popular is that the DoD backed COBOL strongly to avoid contending with multiple languages. The DoD people’s involvement allowed them to insist that COBOL include the most useful elements for business data processing. A second reason for COBOL’s popularity is that it was designed to give identical results on any computer it ran on. This feature, validated through government acceptance testing, gave corporations and governments the confidence to invest heavily in COBOL.
COBOL’s hardware independence has driven a great deal of change in the ongoing specification of the language. This specification strongly emphasizes standard methods of input/output, because those operations form the backbone of business computing. Since the characteristics of input/output devices—and computing technology in general—have changed so rapidly, COBOL has had to expand and change accordingly. COBOL has gone through many changes since it first appeared in 1960, and most of these modifications have been through the forum of a rigorous standardization process.
In 1960, the Computer and Business Equipment Manufacturers Association (CBEMA) formed a committee called the American National Standards Committee on Computers and Information Processing, abbreviated as X3. The X3 committee formed the subcommittee X3.4 for programming languages, which formed the Working Group X3.4.4 "Processor Specification and COBOL Standards." The X3.4.4 (later renamed X3J4) group was responsible for establishing a COBOL standard. The first meeting of this group, in 1963, was attended by representatives of computer manufacturers and users. They established that the goal of the group was to define a national COBOL standard based on the CODASYL publication of COBOL (the original COBOL specification that originated with the committees formed in 1959).
In 1968, the USA Standards Institute (USASI) approved the specification that the COBOL subcommittee developed and published it as X3.23-1968. This document defined COBOL to be composed of a Nucleus and the following eight functional modules:
- Table Handling
- Sequential Access
- Random Access
- Random Processing
- Sort
- Report Writer
- Segmentation
- Library
. Each of these modules was divided into as many as three levels, with each higher level providing more functionality and the lower levels as a strict subset of the higher levels. A minimal implementation of COBOL had to include the low level of the Nucleus, Table Handling, and Sequential Access modules. A full implementation of COBOL would include the highest level of all modules. The American Standards Institute (ASI) became the USA Standards Institute (USASI) in 1966, and then the American National Standards Institute (ANSI) in 1969. This ANSI standard became known as COBOL-68.
The standard was revised in 1974. The eight functional processing modules were expanded to eleven:
- Table Handling
- Sequential I/O
- Relative I/O
- Indexed I/O
- Sort-Merge
- Report Writer
- Segmentation
- Library
- Debug
- Inter-Program Communication
- Communication
Each module contained two or three levels, and in nine modules the lowest level was the null set. Each lower level was a subset of its higher level. The minimum COBOL standard was, as for COBOL-68, the lowest level of the Nucleus, Table Handling, and Sequential I/O modules.
The last version of ANSI COBOL was released in 1985, and it is this version that this book references (we note things that are new or changed in COBOL-85 compared with COBOL-74). The 1985 modules are the same as those in COBOL-74, except that there is no separate Table Handling module; those functions have been incorporated in the Nucleus .
The next proposed standard (COBOL 2000) eliminates modules and the concept of levels of implementation.
The Codasyl COBOL Committee (CCC) continued to exist for a long time in parallel to X3J4. CCC was in charge of all language development, which resulted in in various editions of a document called "Journal of Development" (JOD). X3J4 defined the standard, using the JOD as their primary source. This mode of operation continued until after completion of the ’85 standard. Because of a shortage in membership in both committees, the committees finally merged, and X3J3, recently renamed J4, does both language development and standardization now.
- Even though COBOL was defined and standardized by American groups (and uses English as a basis for its syntax), the international community of business data processors has had a keen interest in the language and in its usability in other environments. The COBOL committee of ANSI, X3J4, kept close liaison with interested international groups, and COBOL-68 complied with the ISO (International Organization for Standardization) recommendations for COBOL. Similarly, the two later ANSI COBOL standards, COBOL-74 and COBOL-85, have been approved and adopted by ISO. An international working group coordinates and controls the development process from the ISO point of view.
In the 1950s, programmer creativity (in the form of "cleverness") was deemed a virtue. The use of GOTO statements, a branching construct that is little more than an assembler "jump" instruction, was very popular in the early days. A GOTO statement usually jumps to another section of program code. These jumps are hard to follow and commonly create spaghetti code, in which you can’t figure out how a branch was made to a particular location in the code or what code will execute next/ However, the programmers left to maintain, modify, and enhance these creative systems found the "spaghetti code" incomprehensible. Although programmers were having fun drawing flowcharts and coding spaghetti bowls of GOTO statements, this methodology began to wear thin. People began to understand that the average life span of a program—that is, how long the program stays in use and must be maintained—is usually seven years or more. In fact, some systems run much longer, staying in production for thirty years or more. Programmers needed to learn to create reliable, maintainable systems. This maintainability became more prized than coming up with beautiful "software creations."
Because of the change in the expectations for software, in the 1960s, there was a flurry of work to try to come up with a coherent software-construction theory. This led to a movement toward modular, or structured programming. At first, the emphasis was more on how coding within a module should look. Later, developers realized that it was as much, if not more, important to concentrate on the overall modular layout of the system.
All programs, as the saying sometimes goes, are not created equal. There are good and bad ways to break down problems into programs. Thus, many people began to look at the characteristics of a good modular structure. With functional decomposition—the breaking down of a program into its smallest functions—was born the clean, pared-down module.
The visionaries behind the structured programming movement showed that there is good design and bad. They came up with two main questions for evaluating module design:
- Are the modules cohesive—do the internals of the modules relate well to each other?
- Are the modules well coupled—do the parameters relate to the module's purpose?
Changes to the COBOL ANSI standard have reflected the movement toward structured programming. The GOTO statement was finally eliminated from practical COBOL programming practice in the ANSI 1985 Standard. That standard introduced scope delimiters, case structures (the EVALUATE verb), and inline PERFORM statements. A 1989 addendum specified intrinsic functions.
Contemporary software development expands beyond the mandate for reliable, maintainable code. Where new development frequently recapitulates the old, the demand for reusable code is considered critical in the development of new systems and the redesign of legacy systems. Object-oriented programming, which we expand on in Part III of the book, is designed to facilitate the development of reusable code and graphical user interfaces (GUIs). The new COBOL standard, targeted for the year 2000, provides constructs for object-oriented programming and other modern programming constructs.
COBOL is a language replete with legend and lore, fame and infamy. With nearly 40 years of COBOL development and hundreds of billions of lines of COBOL code in use around the world, it’s important to understand the realms in which COBOL operates. From a development perspective, COBOL must be considered in the programming environments in which it’s found. Before the advent of the personal computer, every major hardware manufacturer—Digital, Data General, Unisys, and of course, IBM—had some sort of COBOL system.
For many years, the computer industry was led by IBM. IBM successfully sold mainframe computers in well over a hundred countries around the globe. Where IBM went, COBOL went. IBM COBOL applications populate government and business systems everywhere. In the IBM environment, systems grew up around COBOL, intermixed with COBOL, and became inseparable from COBOL.
Today, when you go to an "IBM shop" and look for the COBOL applications, you find them mixed with JCL, CICS, IMS, SQL, and a host of other acronyms. Because it’s impossible to use COBOL in many environments without learning something about these other components as well, we spend time in Part II of the book introducing you to the major pieces.
In the politics of the computer science and software engineering world, COBOL has been widely slandered. Considered unsophisticated by the same people who would have us all typing UNIX and DOS commands, COBOL has been given a bad reputation by people who have never tried to use it. But COBOL is to business applications what the Web is to the Internet. The Internet, before the Web, was a "techie" tool used by a relatively small elite group. With the Web, the Internet became ubiquitous and usable by ordinary people solving everyday business problems. COBOL is the ubiquitous business development language, and leading edge COBOL developers are writing COBOL applications for the Web.
Copyright © 1999 SYBEX Inc., Alameda, CA, USA