COBOL (/ˈkoʊbɒl/, an acronym for common business-oriented language)
is a compiled English-like computer programming language designed for
business use. It is imperative, procedural and, since 2002,
COBOL is primarily used in business, finance, and
administrative systems for companies and governments.
COBOL is still
widely used in legacy applications deployed on mainframe computers,
such as large-scale batch and transaction processing jobs. But due to
its declining popularity and the retirement of experienced COBOL
programmers, programs are being migrated to new platforms, rewritten
in modern languages or replaced with software packages. Most
COBOL is now purely to maintain existing
COBOL was designed in 1959 by
CODASYL and was partly based on previous
programming language design work by Grace Hopper, commonly referred to
as "the (grand)mother of COBOL". It was created as part of a
US Department of Defense effort to create a portable programming
language for data processing. Intended as a stopgap, the Department of
Defense promptly forced computer manufacturers to provide it,
resulting in its widespread adoption. It was standardized in 1968
and has since been revised four times. Expansions include support for
structured and object-oriented programming. The current standard is
COBOL statements have an English-like syntax, which were designed to
be self-documenting and highly readable. However, it is verbose and
uses over 300 reserved words. In contrast with modern, succinct syntax
like y = x;,
COBOL has a more English-like syntax (in this case, MOVE
x TO y).
COBOL code is split into four divisions (identification,
environment, data and procedure) containing a rigid hierarchy of
sections, paragraphs and sentences. Lacking a large standard library,
the standard specifies 43 statements, 87 functions and just one class.
Academic computer scientists were generally uninterested in business
COBOL was created and were not involved in its
design; it was (effectively) designed from the ground up as a computer
language for business, with an emphasis on inputs and outputs, whose
only data types were numbers and strings of text.
COBOL has been
criticized throughout its life, however, for its verbosity, design
process and poor support for structured programming. These weaknesses
result in monolithic and, though intended to be English-like, largely
incomprehensible programs with high redundancy.
1 History and specification
1.3 COBOL-61 to COBOL-65
COBOL 2002 and object-oriented COBOL
2.2 Code format
2.3 Identification division
2.3.1 Object-oriented programming
2.4 Environment division
2.5 Data division
2.5.1 Aggregated data
2.5.2 Other data levels
2.5.3 Data types
22.214.171.124 PICTURE clause
126.96.36.199 USAGE clause
2.5.4 Report writer
2.6 Procedure division
188.8.131.52 Control flow
184.108.40.206 Data manipulation
2.6.3 Scope termination
2.6.4 Self-modifying code
2.7 Hello, world
3 Criticism and defense
3.1 Lack of structure
3.2 Compatibility issues
3.3 Verbose syntax
3.4 Isolation from the computer science community
3.5 Concerns about the design process
3.6 Influences on other languages
4 See also
7 External links
History and specification
In the late 1950s, computer users and manufacturers were becoming
concerned about the rising cost of programming. A 1959 survey had
found that in any data processing installation, the programming cost
US$800,000 on average and that translating programs to run on new
hardware would cost $600,000. At a time when new programming languages
were proliferating at an ever-increasing rate, the same survey
suggested that if a common business-oriented language were used,
conversion would be far cheaper and faster.
Grace Hopper, the inventor of FLOW-MATIC, a predecessor to COBOL
In April 1959,
Mary K. Hawes called a meeting of representatives from
academia, computer users, and manufacturers at the University of
Pennsylvania to organize a formal meeting on common business
languages. Representatives included Grace Hopper, inventor of the
English-like data processing language FLOW-MATIC,
Jean Sammet and Saul
The group asked the Department of Defense (DoD) to sponsor an effort
to create a common business language. The delegation impressed Charles
A. Phillips, director of the Data System Research Staff at the DoD,
who thought that they "thoroughly understood" the DoD's problems. The
DoD operated 225 computers, had a further 175 on order and had spent
over $200 million on implementing programs to run on them. Portable
programs would save time, reduce costs and ease modernization.
Phillips agreed to sponsor the meeting and tasked the delegation with
drafting the agenda.
On May 28 and 29 of 1959 (exactly one year after the Zürich
meeting), a meeting was held at the Pentagon to discuss the creation
of a common programming language for business. It was attended by 41
people and was chaired by Phillips. The Department of Defense was
concerned about whether it could run the same data processing programs
on different computers. FORTRAN, the only mainstream language at the
time, lacked the features needed to write such programs.
Representatives enthusiastically described a language that could work
in a wide variety of environments, from banking and insurance to
utilities and inventory control. They agreed unanimously that more
people should be able to program and that the new language should not
be restricted by the limitations of contemporary technology. A
majority agreed that the language should make maximal use of English,
be capable of change, be machine-independent and be easy to use, even
at the expense of power.
The meeting resulted in the creation of a steering committee and
short-, intermediate- and long-range committees. The short-range
committee was given to September (three months) to produce
specifications for an interim language, which would then be improved
upon by the other committees. Their official mission, however,
was to identify the strengths and weaknesses of existing programming
languages and did not explicitly direct them to create a new
language. The deadline was met with disbelief by the short-range
committee. One member, Betty Holberton, described the three-month
deadline as "gross optimism" and doubted that the language really
would be a stopgap.
The steering committee met on June 4 and agreed to name the entire
activity as the Committee on Data Systems Languages, or CODASYL, and
to form an executive committee.
The short-range committee was made up of members representing six
computer manufacturers and three government agencies. The six computer
manufacturers were Burroughs Corporation, IBM, Minneapolis-Honeywell
Honeywell Labs), RCA, Sperry Rand, and Sylvania Electric Products.
The three government agencies were the US Air Force, the Navy's David
Taylor Model Basin, and the
National Bureau of Standards
National Bureau of Standards (now the
National Institute of Standards and Technology). The committee was
chaired by Joseph Wegstein of the US National Bureau of Standards.
Work began by investigating data description, statements, existing
applications and user experiences.
The committee mainly examined the FLOW-MATIC,
AIMACO and COMTRAN
programming languages. The
FLOW-MATIC language was
particularly influential because it had been implemented and because
AIMACO was a derivative of it with only minor changes.
FLOW-MATIC's inventor, Grace Hopper, also served as a technical
adviser to the committee. FLOW-MATIC's major contributions to
COBOL were long variable names, English words for commands and the
separation of data descriptions and instructions.
COMTRAN language, invented by Bob Bemer, was regarded as a
competitor to FLOW-MATIC by a short-range committee made up of
colleagues of Grace Hopper. Some of its features were not
COBOL so that it would not look like
dominated the design process, and
Jean Sammet said in 1981 that
there had been a "strong anti-
IBM bias" from some committee members
(herself included). In one case, after Roy Goldfinger, author of
COMTRAN manual and intermediate-range committee member, attended a
subcommittee meeting to support his language and encourage the use of
Grace Hopper sent a memo to the short-range
committee reiterating Sperry Rand's efforts to create a language based
on English. In 1980,
Grace Hopper commented that "
COBOL 60 is 95%
FLOW-MATIC" and that
COMTRAN had had an "extremely small" influence.
Furthermore, she said that she would claim that work was influenced by
COMTRAN only to "keep other people happy [so they]
wouldn't try to knock us out". Features from
COBOL included formulas, the PICTURE clause, an improved
IF statement, which obviated the need for GO TOs, and a more robust
file management system.
The usefulness of the committee's work was subject of great debate.
While some members thought the language had too many compromises and
was the result of design by committee, others felt it was better than
the three languages examined. Some felt the language was too complex;
others, too simple. Controversial features included those some
considered useless or too advanced for data processing users. Such
features included boolean expressions, formulas and table subscripts
(indices). Another point of controversy was whether to make
keywords context-sensitive and the effect that would have on
readability. Although context-sensitive keywords were rejected,
the approach was later used in
PL/I and partially in
2002. Little consideration was given to interactivity, interaction
with operating systems (few existed at that time) and functions
(thought of as purely mathematical and of no use in data
The specifications were presented to the Executive Committee on
September 4. They fell short of expectations: Joseph Wegstein noted
that "it contains rough spots and requires some additions", and Bob
Bemer later described them as a "hodgepodge". The subcommittee was
given until December to improve it.
At a mid-September meeting, the committee discussed the new language's
name. Suggestions included "BUSY" (Business System), "INFOSYL"
(Information System Language) and "COCOSYL" (Common Computer Systems
Language). The name "COBOL" was suggested by Bob Bemer.
In October, the intermediate-range committee received copies of the
FACT language specification created by Roy Nutt. Its features
impressed the committee so much that they passed a resolution to base
COBOL on it. This was a blow to the short-range committee, who had
made good progress on the specification. Despite being technically
superior, FACT had not been created with portability in mind or
through manufacturer and user consensus. It also lacked a demonstrable
implementation, allowing supporters of a FLOW-MATIC-based
overturn the resolution.
RCA representative Howard Bromberg also
blocked FACT, so that RCA's work on a
COBOL implementation would not
go to waste.
'And what name do you want inscribed?'
I said, 'I'll write it for you.' I wrote the name down: COBOL.
'What kind of name is that?'
'Well it's a Polish name. We shortened it and got rid of a lot of
Howard Bromberg on how he bought the
It soon became apparent that the committee was too large for any
further progress to be made quickly. A frustrated Howard Bromberg
bought a $15 tombstone with "COBOL" engraved on it and sent it to
Charles Phillips to demonstrate his displeasure.[b] A
sub-committee was formed to analyze existing languages and was made up
of six individuals:
William Selden and Gertrude Tierney of IBM,
Howard Bromberg and Howard Discount of RCA,
Vernon Reeves and
Jean E. Sammet
Jean E. Sammet of Sylvania Electric Products.
The sub-committee did most of the work creating the specification,
leaving the short-range committee to review and modify their work
before producing the finished specification.
The cover of the
COBOL 60 report
The specifications were approved by the Executive Committee on January
3, 1960, and sent to the government printing office, which printed
COBOL 60. The language's stated objectives were to allow
efficient, portable programs to be easily written, to allow users to
move to new systems with minimal effort and cost, and to be suitable
for inexperienced programmers. The
CODASYL Executive Committee
later created the
COBOL Maintenance Committee to answer questions from
users and vendors and to improve and expand the specifications.
During 1960, the list of manufacturers planning to build COBOL
compilers grew. By September, five more manufacturers had joined
CODASYL (Bendix, Control Data Corporation,
General Electric (GE),
National Cash Register
National Cash Register and Philco), and all represented manufacturers
COBOL compilers. GE and
IBM planned to integrate COBOL
into their own languages, GECOM and COMTRAN, respectively. In
International Computers and Tabulators
International Computers and Tabulators planned to replace
their language, CODEL, with COBOL.
Sperry Rand worked on creating
COBOL compilers. The
COBOL program ran on 17 August on an
RCA 501. On December 6
and 7, the same
COBOL program (albeit with minor changes) ran on an
RCA computer and a Remington-Rand
Univac computer, demonstrating that
compatibility could be achieved.
The relative influences of which languages were used continues to this
day in the recommended advisory printed in all
COBOL is an industry language and is not the property of any company
or group of companies, or of any organization or group of
No warranty, expressed or implied, is made by any contributor or by
COBOL Committee as to the accuracy and functioning of the
programming system and language. Moreover, no responsibility is
assumed by any contributor, or by the committee, in connection
therewith. The authors and copyright holders of the copyrighted
material used herein are as follows:
FLOW-MATIC (trademark of Unisys Corporation), Programming for the
UNIVAC (R) I and II, Data Automation Systems, copyrighted 1958, 1959,
by Unisys Corporation;
IBM Commercial Translator Form No. F28-8013,
copyrighted 1959 by IBM; FACT, DSI 27A5260-2760, copyrighted 1960 by
They have specifically authorized the use of this material, in whole
or in part, in the
COBOL specifications. Such authorization extends to
the reproduction and use of
COBOL specifications in programming
manuals or similar publications.
COBOL-61 to COBOL-65
It is rather unlikely that Cobol will be around by the end of the
Anonymous, June 1960
Many logical flaws were found in
COBOL 60, leading GE's Charles Katz
to warn that it could not be interpreted unambiguously. A reluctant
short-term committee enacted a total cleanup and, by March 1963, it
was reported that COBOL's syntax was as definable as ALGOL's, although
semantic ambiguities remained.
COBOL compilers were primitive and slow. A 1962 US Navy
evaluation found compilation speeds of 3–11 statements per minute.
By mid-1964, they had increased to 11–1000 statements per minute. It
was observed that increasing memory would drastically increase speed
and that compilation costs varied wildly: costs per statement were
between $0.23 and $18.91.
In late 1962,
IBM announced that
COBOL would be their primary
development language and that development of
COMTRAN would cease.
COBOL specification was revised three times in the five years
after its publication. COBOL-60 was replaced in 1961 by COBOL-61. This
was then replaced by the COBOL-61 Extended specifications in 1963,
which introduced the sort and report writer facilities. The added
facilities corrected flaws identified by
Honeywell in late 1959 in a
letter to the short-range committee.
COBOL Edition 1965 brought
further clarifications to the specifications and introduced facilities
for handling mass storage files and tables.
Efforts began to standardize
COBOL to overcome incompatibilities
between versions. In late 1962, both
ISO and the United States of
America Standards Institute (now ANSI) formed groups to create
ANSI produced USA Standard
COBOL X3.23 in August 1968,
which became the cornerstone for later versions. This version was
known as American National Standard (ANS)
COBOL and was adopted by ISO
COBOL had become the most widely used programming language in
Independently of the
ANSI committee, the
CODASYL Programming Language
Committee was working on improving the language. They described new
versions in 1968, 1969, 1970 and 1973, including changes such as new
inter-program communication, debugging and file merging facilities as
well as improved string-handling and library inclusion features.
CODASYL was independent of the
ANSI committee, the CODASYL
Journal of Development was used by
ANSI to identify features that were
popular enough to warrant implementing. The Programming Language
Committee also liaised with ECMA and the Japanese
The Programming Language Committee was not well-known, however. The
vice-president, William Rinehuls, complained that two-thirds of the
COBOL community did not know of the committee's existence. It was also
poor, lacking the funds to make public documents, such as minutes of
meetings and change proposals, freely available.
ANSI published a revised version of (ANS) COBOL, containing
new features such as file organizations, the DELETE statement and
the segmentation module. Deleted features included the NOTE
statement, the EXAMINE statement (which was replaced by INSPECT) and
the implementer-defined random access module (which was superseded by
the new sequential and relative I/O modules). These made up 44
changes, which rendered existing statements incompatible with the new
standard. The report writer was slated to be removed from COBOL,
but was reinstated before the standard was published. ISO
later adopted the updated standard in 1978.
In June 1978, work began on revising COBOL-74. The proposed standard
(commonly called COBOL-80) differed significantly from the previous
one, causing concerns about incompatibility and conversion costs. In
January 1981, Joseph T. Brophy, Senior Vice-President of Travelers
Insurance, threatened to sue the standard committee because it was not
upwards compatible with COBOL-74. Mr. Brophy described previous
conversions of their 40-million-line code base as "non-productive" and
a "complete waste of our programmer resources". Later that year,
Data Processing Management Association
Data Processing Management Association (DPMA) said it was
"strongly opposed" to the new standard, citing "prohibitive"
conversion costs and enhancements that were "forced on the
During the first public review period, the committee received 2,200
responses, of which 1,700 were negative form letters. Other
responses were detailed analyses of the effect COBOL-80 would have on
their systems; conversion costs were predicted to be at least 50 cents
per line of code. Fewer than a dozen of the responses were in favor of
the proposed standard.
In 1983, the DPMA withdrew its opposition to the standard, citing the
responsiveness of the committee to public concerns. In the same year,
National Bureau of Standards
National Bureau of Standards study concluded that the proposed
standard would present few problems. A year later, a COBOL-80
compiler was released to
DEC VAX users, who noted that conversion of
COBOL-74 programs posed few problems. The new EVALUATE statement and
inline PERFORM were particularly well received and improved
productivity, thanks to simplified control flow and debugging.
The second public review drew another 1,000 (mainly negative)
responses, while the last drew just 25, by which time many concerns
had been addressed.
In late 1985,
ANSI published the revised standard. Sixty features were
changed or deprecated and many[quantify] were added, such as:
Scope terminators (END-IF, END-PERFORM, END-READ, etc.)
CONTINUE, a no-operation statement
EVALUATE, a switch statement
INITIALIZE, a statement that can set groups of data to their default
Inline PERFORM loop bodies – previously, loop bodies had to be
specified in a separate procedure
Reference modification, which allows access to substrings
I/O status codes.
The standard was adopted by
ISO the same year. Two amendments
followed in 1989 and 1993, the first introducing intrinsic functions
and the other providing corrections.
ISO adopted the amendments in
1991 and 1994 respectively, before subsequently taking primary
ownership and development of the standard.
COBOL 2002 and object-oriented COBOL
Gartner Group estimated that there were a total of 200
billion lines of
COBOL in existence, which ran 80% of all business
programs.[better source needed]
In the early 1990s, work began on adding object-orientation in the
next full revision of COBOL. Object-oriented features were taken from
C++ and Smalltalk. The initial estimate was to have this
revision completed by 1997, and an
ISO Committee Draft (CD) was
available by 1997. Some vendors (including Micro Focus, Fujitsu, and
IBM) introduced object-oriented syntax based on drafts of the full
revision. The final approved
ISO standard was approved and published
in late 2002.
Micro Focus and RainCode introduced
COBOL compilers targeting the .NET Framework.
There were many other new features, many of which had been in the
COBOL Journal of Development since 1978 and had missed the
opportunity to be included in COBOL-85. These other features
Support for extended character sets such as Unicode
Floating-point and binary data types (until then, binary items were
truncated based on their declaration's base-10 specification)
Portable arithmetic results
Bit and boolean data types
Pointers and syntax for getting and freeing storage
The SCREEN SECTION for text-based user interfaces
The VALIDATE facility
Improved interoperability with other programming languages and
framework environments such as .NET and Java.
Three corrigenda were published for the standard: two in 2006 and one
Between 2003 and 2009, three technical reports were produced
describing object finalization,
XML processing and collection classes
COBOL 2002 suffered from poor support: no compilers completely
supported the standard.
Micro Focus found that it was due to a lack of
user demand for the new features and due to the abolition of the NIST
test suite, which had been used to test compiler conformance. The
standardization process was also found to be slow and
COBOL 2014 includes the following changes:
Portable arithmetic results have been replaced by
IEEE 754 data types
Major features have been made optional, such as the VALIDATE facility,
the report writer and the screen-handling facility.
Dynamic capacity tables (a feature dropped from the draft of COBOL
COBOL programs are used globally in governments and businesses and are
running on diverse operating systems such as z/OS, z/VSE, VME, Unix,
OpenVMS and Windows. In 1997, the
Gartner Group reported that 80% of
the world's business ran on
COBOL with over 200 billion lines of code
and 5 billion lines more being written annually.
Near the end of the 20th century, the year 2000 problem (Y2K) was the
focus of significant
COBOL programming effort, sometimes by the same
programmers who had designed the systems decades before. The
particular level of effort required to correct
COBOL code has been
attributed[by whom?] to the large amount of business-oriented COBOL,
as business applications use dates heavily, and to fixed-length data
fields. After the clean-up effort put into these programs for Y2K, a
2003 survey found that many remained in use. The authors said that
the survey data suggest "a gradual decline in the importance of Cobol
in application development over the [following] 10 years unless ...
integration with other languages and technologies can be adopted".
In 2006 and 2012,
Computerworld surveys found that over 60% of
COBOL (more than
C++ and Visual Basic .NET) and
that for half of those,
COBOL was used for the majority of their
internal software. 36% of managers said they planned to
migrate from COBOL, and 25% said they would like to if it was cheaper.
Instead, some businesses have migrated their systems from expensive
mainframes to cheaper, more modern systems, while maintaining their
COBOL has an English-like syntax, which is used to describe nearly
everything in a program. For example, a condition can be expressed as
x IS GREATER THAN y or more concisely as x GREATER y
or x > y. More complex conditions can be "abbreviated" by
removing repeated conditions and variables. For example, a >
b AND a > c OR a = d can be shortened to a > b AND c OR =
d. As a consequence of this English-like syntax,
COBOL has over 300
keywords.[c] Some of the keywords are simple alternative or
pluralized spellings of the same word, which provides for more
English-like statements and clauses; e.g., the IN and OF keywords can
be used interchangeably, as can IS and ARE, and VALUE and VALUES.
COBOL program is made up of four basic lexical items: words,
literals, picture character-strings (see § PICTURE clause) and
separators. Words include reserved words and user-defined identifiers.
They are up to 31 characters long and may include letters, digits,
hyphens and underscores. Literals include numerals (e.g. 12) and
strings (e.g. 'Hello!'). Separators include the space character
and commas and semi-colons followed by a space.
COBOL program is split into four divisions: the identification
division, the environment division, the data division and the
procedure division. The identification division specifies the name and
type of the source element and is where classes and interfaces are
specified. The environment division specifies any program features
that depend on the system running it, such as files and character
sets. The data division is used to declare variables and parameters.
The procedure division contains the program's statements. Each
division is sub-divided into sections, which are made up of
COBOL's syntax is usually described with a unique metalanguage using
braces, brackets, bars and underlining. The metalanguage was developed
for the original
COBOL specifications. Although
Backus–Naur form did
exist at the time, the committee had not heard of it.
Elements of COBOL's metalanguage
The reserved word is compulsory
Only one option may be selected
Zero or one options may be selected
The preceding element may be repeated
One or more options may be selected. Any option may only be selected
Zero or more options may be selected. Any option may only be selected
As an example, consider the following description of an ADD statement:
displaystyle begin array l underline text ADD , begin
Bmatrix text identifier-1 \ text literal-1 end Bmatrix dots ;
underline text TO ,left text identifier-2 ,left[, underline text
ROUNDED ,right]right dots \quad left[left begin array l text ON
, underline text SIZE , underline text ERROR , text
imperative-statement-1 \ underline text NOT , text ON , underline
text SIZE , underline text ERROR , text imperative-statement-2
\end array rightright]\quad left[, underline text END-ADD
This description permits the following variants:
ADD 1 TO x
ADD 1, a, b TO x ROUNDED, y, z ROUNDED
ADD a, b TO c
ON SIZE ERROR
ADD a TO b
NOT SIZE ERROR
DISPLAY "No error"
ON SIZE ERROR
COBOL can be written in two formats: fixed (the default) or free. In
fixed-format, code must be aligned to fit in certain areas (a
hold-over from using punched cards). Until
COBOL 2002, these were:
Sequence number area
Originally used for card/line numbers, this area is ignored by the
The following characters are allowed here:
* – Comment line
/ – Comment line that will be printed on a new page of a source
- – Continuation line, where words or literals from the previous
line are continued
D – Line enabled in debugging mode, which is otherwise ignored
This contains: DIVISION, SECTION and procedure headers; 01 and 77
level numbers and file/report descriptors
Any other code not allowed in Area A
Program name area
Historically up to column 80 for punched cards, it is used to identify
the program or sequence the card belongs to
COBOL 2002, Areas A and B were merged to form the program-text
area, which now ends at an implementor-defined column.
COBOL 2002 also introduced free-format code. Free-format code can be
placed in any column of the file, as in newer programming languages.
Comments are specified using *>, which can be placed anywhere and
can also be used in fixed-format source code. Continuation lines are
not present, and the >>PAGE directive replaces the /
The identification division identifies the following code entity and
contains the definition of a class or interface.
Classes and interfaces have been in
COBOL since 2002. Classes have
factory objects, containing class methods and variables, and instance
objects, containing instance methods and variables. Inheritance
and interfaces provide polymorphism. Support for generic programming
is provided through parameterized classes, which can be instantiated
to use any class or interface. Objects are stored as references which
may be restricted to a certain type. There are two ways of calling a
method: the INVOKE statement, which acts similarly to CALL, or through
inline method invocation, which is analogous to using functions.
*> These are equivalent.
INVOKE my-class "foo" RETURNING var
MOVE my-class::"foo" TO var *> Inline method invocation
COBOL does not provide a way to hide methods. Class data can be
hidden, however, by declaring it without a PROPERTY clause, which
leaves the user with no way to access it.
Method overloading was
The environment division contains the configuration section and the
input-output section. The configuration section is used to specify
variable features such as currency signs, locales and character sets.
The input-output section contains file-related information.
COBOL supports three file formats, or organizations: sequential,
indexed and relative. In sequential files, records are contiguous and
must be traversed sequentially, similarly to a linked list. Indexed
files have one or more indexes which allow records to be randomly
accessed and which can be sorted on them. Each record must have a
unique key, but other, alternate, record keys need not be unique.
Implementations of indexed files vary between vendors, although common
implementations, such as C‑
ISAM and VSAM, are based on IBM's ISAM.
Relative files, like indexed files, have a unique record key, but they
do not have alternate keys. A relative record's key is its ordinal
position; for example, the 10th record has a key of 10. This means
that creating a record with a key of 5 may require the creation of
(empty) preceding records. Relative files also allow for both
sequential and random access.
A common non-standard extension is the line sequential organization,
used to process text files. Records in a file are terminated by a
newline and may be of varying length.
The data division is split into six sections which declare different
items: the file section, for file records; the working-storage
section, for static variables; the local-storage section, for
automatic variables; the linkage section, for parameters and the
return value; the report section and the screen section, for
text-based user interfaces.
Data items in
COBOL are declared hierarchically through the use of
level-numbers which indicate if a data item is part of another. An
item with a higher level-number is subordinate to an item with a lower
one. Top-level data items, with a level-number of 1, are called
records. Items that have subordinate aggregate data are called group
items; those that do not are called elementary items. Level-numbers
used to describe standard data items are between 1 and 49.
01 some-record. *> Aggregate group record
05 num PIC 9(10). *> Elementary item
05 the-date. *> Aggregate (sub)group
10 the-year PIC 9(4). *> Elementary item
10 the-month PIC 99. *> Elementary item
10 the-day PIC 99. *> Elementary item
In the above example, elementary item num and group item the-date are
subordinate to the record some-record, while elementary items
the-year, the-month, and the-day are part of the group item the-date.
Subordinate items can be disambiguated with the IN (or OF) keyword.
For example, consider the example code above along with the following
05 the-year PIC 9(4).
05 the-month PIC 99.
05 the-day PIC 99.
The names the-year, the-month, and the-day are ambiguous by
themselves, since more than one data item is defined with those names.
To specify a particular data item, for instance one of the items
contained within the sale-date group, the programmer would use
the-year IN sale-date (or the equivalent the-year OF sale-date). (This
syntax is similar to the "dot notation" supported by most contemporary
Other data levels
A level-number of 66 is used to declare a re-grouping of previously
defined items, irrespective of how those items are structured. This
data level, also referred to by the associated RENAMES clause, is
rarely used and, circa 1988, was usually found in old programs.
Its ability to ignore the hierarchical and logical structure data
meant its use was not recommended and many installations forbade its
05 cust-key PIC X(10).
10 cust-first-name PIC X(30).
10 cust-last-name PIC X(30).
05 cust-dob PIC 9(8).
05 cust-balance PIC 9(7)V99.
66 cust-personal-details RENAMES cust-name THRU cust-dob.
66 cust-all-details RENAMES cust-name THRU
A 77 level-number indicates the item is stand-alone, and in such
situations is equivalent to the level-number 01. For example, the
following code declares two 77-level data items, property-name and
sales-region, which are non-group data items that are independent of
(not subordinate to) any other data items:
77 property-name PIC X(80).
77 sales-region PIC 9(5).
An 88 level-number declares a condition name (a so-called 88-level)
which is true when its parent data item contains one of the values
specified in its VALUE clause. For example, the following code
defines two 88-level condition-name items that are true or false
depending on the current character data value of the wage-type data
item. When the data item contains a value of 'H', the condition-name
wage-is-hourly is true, whereas when it contains a value of 'S' or
'Y', the condition-name wage-is-yearly is true. If the data item
contains some other value, both of the condition-names are false.
01 wage-type PIC X.
88 wage-is-hourly VALUE "H".
88 wage-is-yearly VALUE "S", "Y".
COBOL provides the following data types:
May only contain letters or spaces
May contain any characters
PIC 1 USAGE BIT
Data stored in the form of 0s and 1s, as a binary number
Used to reference table elements
Similar to alphanumeric, but using an extended character set, e.g.
May contain only numbers
USAGE OBJECT REFERENCE
May reference either an object or NULL
Type safety is variable in COBOL. Numeric data is converted between
different representations and sizes silently and alphanumeric data can
be placed in any data item that can be stored as a string, including
numeric and group data. In contrast, object references and
pointers may only be assigned from items of the same type and their
values may be restricted to a certain type.
A PICTURE (or PIC) clause is a string of characters, each of which
represents a portion of the data item and what it may contain. Some
picture characters specify the type of the item and how many
characters or digits it occupies in memory. For example, a 9 indicates
a decimal digit, and an S indicates that the item is signed. Other
picture characters (called insertion and editing characters) specify
how an item should be formatted. For example, a series of + characters
define character positions as well as how a leading sign character is
to be positioned within the final character data; the rightmost
non-numeric character will contain the item's sign, while other
character positions corresponding to a + to the left of this position
will contain a space. Repeated characters can be specified more
concisely by specifying a number in parentheses after a picture
character; for example, 9(7) is equivalent to 9999999. Picture
specifications containing only digit (9) and sign (S) characters
define purely numeric data items, while picture specifications
containing alphabetic (A) or alphanumeric (X) characters define
alphanumeric data items. The presence of other formatting characters
define edited numeric or edited alphanumeric data items.
"Hello" (this is legal, but results in undefined behavior)
" -10" (note leading spaces)
"ABC DEF GHI"
The USAGE clause declares the format data is stored in. Depending on
the data type, it can either complement or be used instead of a
PICTURE clause. While it can be used to declare pointers and object
references, it is mostly geared towards specifying numeric types.
These numeric formats are:
Binary, where a minimum size is either specified by the PICTURE clause
or by a USAGE clause such as BINARY-LONG.
USAGE COMPUTATIONAL, where data may be stored in whatever format the
implementation provides; often equivalent to USAGE BINARY
USAGE DISPLAY, the default format, where data is stored as a string
Floating-point, in either an implementation-dependent format or
USAGE NATIONAL, where data is stored as a string using an extended
USAGE PACKED-DECIMAL, where data is stored in the smallest possible
decimal format (typically packed binary-coded decimal)
The report writer is a declarative facility for creating reports. The
programmer need only specify the report layout and the data required
to produce it, freeing them from having to write code to handle things
like page breaks, data formatting, and headings and footings.
Reports are associated with report files, which are files which may
only be written to through report writer statements.
FD report-out REPORT sales-report.
Each report is defined in the report section of the data division. A
report is split into report groups which define the report's headings,
footings and details. Reports work around hierarchical control breaks.
Control breaks occur when a key variable changes it value; for
example, when creating a report detailing customers' orders, a control
break could occur when the program reaches a different customer's
orders. Here is an example report description for a report which gives
a salesperson's sales and which warns of any invalid records:
PAGE LIMITS 60 LINES
FIRST DETAIL 3
01 TYPE PAGE HEADING.
03 COL 1 VALUE "Sales Report".
03 COL 74 VALUE "Page".
03 COL 79 PIC Z9 SOURCE PAGE-COUNTER.
01 sales-on-day TYPE DETAIL, LINE + 1.
03 COL 3 VALUE "Sales on".
03 COL 12 PIC 99/99/9999 SOURCE
03 COL 21 VALUE "were".
03 COL 26 PIC $$$$9.99 SOURCE
01 invalid-sales TYPE DETAIL, LINE + 1.
03 COL 3 VALUE "INVALID RECORD:".
03 COL 19 PIC X(34) SOURCE sales-record.
01 TYPE CONTROL HEADING seller-name, LINE + 2.
03 COL 1 VALUE "Seller:".
03 COL 9 PIC X(30) SOURCE seller-name.
The above report description describes the following layout:
Seller: Howard Bromberg
Sales on 10/12/2008 were $1000.00
Sales on 12/12/2008 were $0.00
Sales on 13/12/2008 were $31.47
INVALID RECORD: Howard Bromberg XXXXYY
Seller: Howard Discount
Sales on 08/05/2014 were $543.98
INVALID RECORD: William Selden 12O52014FOOFOO
Sales on 30/05/2014 were $0.00
Four statements control the report writer: INITIATE, which prepares
the report writer for printing; GENERATE, which prints a report group;
SUPPRESS, which suppresses the printing of a report group; and
TERMINATE, which terminates report processing. For the above sales
report example, the procedure division might look like this:
OPEN INPUT sales, OUTPUT report-out
PERFORM UNTIL 1 <> 1
CLOSE sales, report-out
The sections and paragraphs in the procedure division (collectively
called procedures) can be used as labels and as simple subroutines.
Unlike in other divisions, paragraphs do not need to be in
sections. Execution goes down through the procedures of a program
until it is terminated. To use procedures as subroutines, the
PERFORM verb is used. This transfers control to the specified range of
procedures and returns only upon reaching the end.
A mine is "armed" when the screen is invalid.
Unusual control flow can trigger mines, which cause control in
performed procedures to return at unexpected times to unexpected
locations. Procedures can be reached in three ways: they can be called
with PERFORM, jumped to from a
GO TO or through execution "falling
through" the bottom of an above paragraph. Combinations of these
invoke undefined behavior, creating mines. Specifically, mines occur
when execution of a range of procedures would cause control flow to go
past the last statement of a range of procedures already being
For example, in the code in the adjacent image, a mine is tripped at
the end of update-screen when the screen is invalid. When the screen
is invalid, control jumps to the fix-screen section, which, when done,
performs update-screen. This recursion triggers undefined behavior as
there are now two overlapping ranges of procedures being performed.
The mine is then triggered upon reaching the end of update-screen and
means control could return to one of two locations:
The first PERFORM statement
The PERFORM statement in fix-screen, where it would then
"fall-through" into update-screen and return to the first PERFORM
statement upon reaching the end.
COBOL 2014 has 47 statements (also called verbs), which can be
grouped into the following broad categories: control flow, I/O, data
manipulation and the report writer. The report writer statements are
covered in the report writer section.
COBOL's conditional statements are IF and EVALUATE. EVALUATE is a
switch-like statement with the added capability of evaluating multiple
values and conditions. This can be used to implement decision tables.
For example, the following might be used to control a CNC lathe:
EVALUATE TRUE ALSO desired-speed ALSO current-speed
WHEN lid-closed ALSO min-speed THRU max-speed ALSO LESS THAN
WHEN lid-closed ALSO min-speed THRU max-speed ALSO GREATER THAN
WHEN lid-open ALSO ANY ALSO NOT ZERO
The PERFORM statement is used to define loops which are executed until
a condition is true (not while true, which is more common in other
languages). It is also used to call procedures or ranges of procedures
(see the procedures section for more details). CALL and INVOKE call
subprograms and methods, respectively. The name of the
subprogram/method is contained in a string which may be a literal or a
data item. Parameters can be passed by reference, by content
(where a copy is passed by reference) or by value (but only if a
prototype is available). CANCEL unloads subprograms from memory.
GO TO causes the program to jump to a specified procedure.
The GOBACK statement is a return statement and the STOP statement
stops the program. The EXIT statement has six different formats: it
can be used as a return statement, a break statement, a continue
statement, an end marker or to leave a procedure.
Exceptions are raised by a RAISE statement and caught with a handler,
or declarative, defined in the DECLARATIVES portion of the procedure
division. Declaratives are sections beginning with a USE statement
which specify the errors to handle. Exceptions can be names or
objects. RESUME is used in a declarative to jump to the statement
after the one that raised the exception or to a procedure outside the
DECLARATIVES. Unlike other languages, uncaught exceptions may not
terminate the program and the program can proceed unaffected.
File I/O is handled by the self-describing OPEN, CLOSE, READ, and
WRITE statements along with a further three: REWRITE, which updates a
record; START, which selects subsequent records to access by finding a
record with a certain key; and UNLOCK, which releases a lock on the
last record accessed.
User interaction is done using ACCEPT and DISPLAY.
The following verbs manipulate data:
INITIALIZE, which sets data items to their default values.
MOVE, which assigns values to data items.
SET, which has 15 formats: it can modify indices, assign object
references and alter table capacities, among other functions.
ADD, SUBTRACT, MULTIPLY, DIVIDE, and COMPUTE, which handle arithmetic
(with COMPUTE assigning the result of a formula to a variable).
ALLOCATE and FREE, which handle dynamic memory.
VALIDATE, which validates and distributes data as specified in an
item's description in the data division.
STRING and UNSTRING, which concatenate and split strings,
INSPECT, which tallies or replaces instances of specified substrings
within a string.
SEARCH, which searches a table for the first entry satisfying a
Files and tables are sorted using SORT and the MERGE verb merges and
sorts files. The RELEASE verb provides records to sort and RETURN
retrieves sorted records in order.
Some statements, such as IF and READ, may themselves contain
statements. Such statements may be terminated in two ways: by a period
(implicit termination), which terminates all unterminated statements
contained, or by a scope terminator, which terminates the nearest
matching open statement.
*> Terminator period ("implicit termination")
AT END SET no-more-records TO TRUE.
*> Scope terminators ("explicit termination")
AT END SET no-more-records TO TRUE
Nested statements terminated with a period are a common source of
bugs. For example, examine the following code:
Here, the intent is to display y and z if condition x is true.
However, z will be displayed whatever the value of x because the IF
statement is terminated by an erroneous period after DISPLAY y.
Another bug is a result of the dangling else problem, when two IF
statements can associate with an ELSE.
In the above fragment, the ELSE associates with the IF y
statement instead of the IF x statement, causing a bug.
Prior to the introduction of explicit scope terminators, preventing it
would require ELSE NEXT SENTENCE to be placed after the
The original (1959)
COBOL specification supported the infamous
ALTER X TO PROCEED TO Y statement, for which many
compilers generated self-modifying code. X and Y are procedure labels,
and the single GO TO statement in procedure X executed
after such an ALTER statement means
GO TO Y instead. Many
compilers still support it, but it was deemed obsolete in the
COBOL 1985 standard and deleted in 2002.
A "Hello, world" program in COBOL:
DISPLAY "Hello, world!"
When the – now famous –
"Hello, World!" program
"Hello, World!" program example in The C
Programming Language was first published in 1978 a similar mainframe
COBOL program sample would have been submitted through JCL, very
likely using a punch card reader, and 80 column punch cards. The
listing below, with an empty DATA DIVISION, was tested using GNU/Linux
and the System/370
Hercules emulator running
MVS 3.8J. The JCL,
written in July 2015, is derived from the Hercules tutorials and
samples hosted by Jay Moseley. In keeping with
of that era, HELLO, WORLD is displayed in all capital letters.
//COBUCLG JOB (001),'
COBOL BASE TEST',
//BASETEST EXEC COBUCLG
//COB.SYSIN DD *
00000* VALIDATION OF BASE
01000 IDENTIFICATION DIVISION.
01100 PROGRAM-ID. 'HELLO'.
02000 ENVIRONMENT DIVISION.
02100 CONFIGURATION SECTION.
02110 SOURCE-COMPUTER. GNULINUX.
02120 OBJECT-COMPUTER. HERCULES.
02210 CONSOLE IS CONSL.
03000 DATA DIVISION.
04000 PROCEDURE DIVISION.
04110 DISPLAY 'HELLO, WORLD' UPON CONSL.
04900 STOP RUN.
//LKED.SYSLIB DD DSNAME=SYS1.COBLIB,DISP=SHR
// DD DSNAME=SYS1.LINKLIB,DISP=SHR
//GO.SYSPRINT DD SYSOUT=A
After submitting the JCL, the
MVS console displayed:
19.52.48 JOB 3 $HASP100 COBUCLG ON READER1
19.52.48 JOB 3 IEF677I WARNING MESSAGE(S) FOR JOB COBUCLG
19.52.48 JOB 3 $HASP373 COBUCLG STARTED - INIT 1 - CLASS A -
19.52.48 JOB 3 IEC130I SYSPUNCH DD STATEMENT MISSING
19.52.48 JOB 3 IEC130I SYSLIB DD STATEMENT MISSING
19.52.48 JOB 3 IEC130I SYSPUNCH DD STATEMENT MISSING
19.52.48 JOB 3 IEFACTRT - Stepname Procstep Program
19.52.48 JOB 3 COBUCLG BASETEST COB IKFCBL00 RC=
19.52.48 JOB 3 COBUCLG BASETEST LKED IEWL RC=
19.52.48 JOB 3 +HELLO, WORLD
19.52.48 JOB 3 COBUCLG BASETEST GO PGM=*.DD RC=
19.52.48 JOB 3 $HASP395 COBUCLG ENDED
Line 10 of the console listing above is highlighted for effect, the
highlighting is not part of the actual console output.
The associated compiler listing generated over four pages of technical
detail and job run information, for the single line of output from the
14 lines of COBOL.
Criticism and defense
Lack of structure
In the 1970s, adoption of the structured programming paradigm was
becoming increasingly widespread. Edsger Dijkstra, a preeminent
computer scientist, wrote a letter to the editor of Communications of
the ACM, published 1975 entitled "How do we tell truths that might
hurt?", in which he was critical of
COBOL and several other
contemporary languages; remarking that "the use of
COBOL cripples the
mind". In a published dissent to Dijkstra's remarks, the computer
scientist Howard E. Tompkins claimed that unstructured
COBOL tended to
be "written by programmers that have never had the benefit of
COBOL taught well", arguing that the issue was primarily
one of training.
One cause of spaghetti code was the
GO TO statement. Attempts to
remove GO TOs from
COBOL code, however, resulted in convoluted
programs and reduced code quality. GO TOs were largely replaced
by the PERFORM statement and procedures, which promoted modular
programming and gave easy access to powerful looping facilities.
However, PERFORM could only be used with procedures so loop bodies
were not located where they were used, making programs harder to
COBOL programs were infamous for being monolithic and lacking
COBOL code could only be modularized through
procedures, which were found to be inadequate for large systems. It
was impossible to restrict access to data, meaning a procedure could
access and modify any data item. Furthermore, there was no way to pass
parameters to a procedure, an omission
Jean Sammet regarded as the
committee's biggest mistake. Another complication stemmed from
the ability to PERFORM THRU a specified sequence of procedures. This
meant that control could jump to and return from any procedure,
creating convoluted control flow and permitting a programmer to break
the single-entry single-exit rule.
This situation improved as
COBOL adopted more features. COBOL-74 added
subprograms, giving programmers the ability to control the data each
part of the program could access. COBOL-85 then added nested
subprograms, allowing programmers to hide subprograms. Further
control over data and code came in 2002 when object-oriented
programming, user-defined functions and user-defined data types were
Nevertheless, much important legacy
COBOL software uses unstructured
code, which has become unmaintainable. It can be too risky and costly
to modify even a simple section of code, since it may be used from
unknown places in unknown ways.
COBOL was intended to be a highly portable, "common" language.
However, by 2001, around 300 dialects had been created. One
source of dialects was the standard itself: the 1974 standard was
composed of one mandatory nucleus and eleven functional modules, each
containing two or three levels of support. This permitted 104,976
COBOL-85 was not fully compatible with earlier versions, and its
development was controversial. Joseph T. Brophy, the CIO of Travelers
Insurance, spearheaded an effort to inform
COBOL users of the heavy
reprogramming costs of implementing the new standard. As a
COBOL Committee received more than 2,200 letters from
the public, mostly negative, requiring the committee to make changes.
On the other hand, conversion to COBOL-85 was thought to increase
productivity in future years, thus justifying the conversion
COBOL: /koh′bol/, n.
A weak, verbose, and flabby language used by code grinders to do
boring mindless things on dinosaur mainframes. [...] Its very name is
seldom uttered without ritual expressions of disgust or horror.
COBOL syntax has often been criticized for its verbosity. Proponents
say that this was intended to make the code self-documenting, easing
COBOL was also intended to be easy for
programmers to learn and use, while still being readable to
non-technical staff such as managers. The desire
for readability led to the use of English-like syntax and structural
elements, such as nouns, verbs, clauses, sentences, sections, and
divisions. Yet by 1984, maintainers of
COBOL programs were struggling
to deal with "incomprehensible" code and the main changes in
COBOL-85 were there to help ease maintenance.
Jean Sammet, a short-range committee member, noted that "little
attempt was made to cater to the professional programmer, in fact
people whose main interest is programming tend to be very unhappy with
COBOL" which she attributed to COBOL's verbose syntax.
Isolation from the computer science community
COBOL community has always been isolated from the computer science
community. No academic computer scientists participated in the design
of COBOL: all of those on the committee came from commerce or
government. Computer scientists at the time were more interested in
fields like numerical analysis, physics and system programming than
the commercial file-processing problems which
Jean Sammet attributed COBOL's unpopularity to an
initial "snob reaction" due to its inelegance, the lack of influential
computer scientists participating in the design process and a disdain
for business data processing. The
COBOL specification used a
unique "notation", or metalanguage, to define its syntax rather than
Backus–Naur form because few committee members had heard of
it. This resulted in "severe" criticism.
COBOL suffered from a shortage of material covering it; it took
until 1963 for introductory books to appear (with Richard D. Irwin
publishing a college textbook on
COBOL in 1966). By 1985, there
were twice as many books on
Fortran and four times as many on
COBOL in the Library of Congress. University professors taught
more modern, state-of-the-art languages and techniques instead of
COBOL which was said to have a "trade school" nature. Donald
Nelson, chair of the
COBOL committee, said in 1984 that
"academics ... hate COBOL" and that computer science graduates "had
'hate COBOL' drilled into them". A 2013 poll by
Micro Focus found
that 20% of university academics thought
COBOL was outdated or dead
and that 55% believed their students thought
COBOL was outdated or
dead. The same poll also found that only 25% of academics had COBOL
programming on their curriculum even though 60% thought they should
teach it. In contrast, in 2003,
COBOL featured in 80% of
information systems curricula in the United States, the same
C++ and Java.
There was also significant condescension towards
COBOL in the business
community from users of other languages, for example
assembler, implying that
COBOL could be used only for non-challenging
Concerns about the design process
Doubts have been raised about the competence of the standards
committee. Short-term committee member Howard Bromberg said that there
was "little control" over the development process and that it was
"plagued by discontinuity of personnel and ... a lack of talent."
Jean Sammet and Jerome Garfunkel also noted that changes introduced in
one revision of the standard would be reverted in the next, due as
much to changes in who was in the standard committee as to objective
COBOL standards have repeatedly suffered from delays: COBOL-85 arrived
five years later than hoped,
COBOL 2002 was five years late,
COBOL 2014 was six years late. To combat delays, the
standard committee allowed the creation of optional addenda which
would add features more quickly than by waiting for the next standard
revision. However, some committee members raised concerns about
incompatibilities between implementations and frequent modifications
of the standard.
Influences on other languages
COBOL's data structures influenced subsequent programming languages.
Its record and file structure influenced
PL/I and Pascal, and the
REDEFINES clause was a predecessor to Pascal's variant records.
Explicit file structure definitions preceded the development of
database management systems and aggregated data was a significant
advance over Fortran's arrays. PICTURE data declarations were
incorporated into PL/I, with minor changes.
COBOL's COPY facility, although considered "primitive",
influenced the development of include directives.
The focus on portability and standardization meant programs written in
COBOL could be portable and facilitated the spread of the language to
a wide variety of hardware platforms and operating systems.
Additionally, the well-defined division structure restricts the
definition of external references to the Environment Division, which
simplifies platform changes in particular.
Computer programming portal
Programming language genealogies
Alphabetical list of programming languages
Comparison of programming languages
^ a b c Specifically influenced
COBOL 2002's object-oriented
^ The tombstone is currently at the Computer History Museum.
^ Vendor-specific extensions cause many implementations to have far
more: one implementation recognizes over 1,100 keywords.
^ a b c Saade, Henry; Wallace, Ann (October 1995). "
COBOL '97: A
Status Report". Dr. Dobb's Journal. Retrieved 21 April 2014.
^ a b Arranga, Edmund C.; Coyle, Frank P. (February 1998).
Object-Oriented COBOL. Cambridge University Press. p. 15.
ISBN 978-0132611404. Object-Oriented COBOL's style reflects the
Smalltalk and C++.
^ Arranga, Edmund C.; Coyle, Frank P. (March 1997). "Cobol: Perception
and Reality". Computer. IEEE. 30 (3): 127. doi:10.1109/2.573683.
ISSN 0018-9162. (Subscription required (help)).
^ Imajo, Tetsuji; et al. (September 2000).
COBOL Script: a
business-oriented scripting language. Enterprise Distributed Object
Computing Conference. Makuhari, Japan: IEEE.
doi:10.1109/EDOC.2000.882363. ISBN 0769508650. (Subscription
^ Radin, George (1978). Wexelblat, Richard L., ed. The early history
and characteristics of PL/I. History of Programming Languages.
Academic Press (published 1981). p. 572.
doi:10.1145/800025.1198410. ISBN 0127450408. (Subscription
^ Mitchell, Robert L. (14 March 2012). "Brain drain: Where Cobol
systems go from here". Computerworld. Retrieved 9 February 2015.
^ a b c Mitchell, Robert L. (4 October 2006). "Cobol: Not Dead Yet".
Computerworld. Retrieved 27 April 2014.
^ Porter Adams, Vicki (5 October 1981). "Captain Grace M. Hopper: the
Mother of COBOL". InfoWorld. 3 (20): 33. ISSN 0199-6649.
^ Betts, Mitch (6 Jan 1992). "Grace Hopper, mother of Cobol, dies".
Computerworld. 26 (1): 14. ISSN 0010-4841.
^ Lohr, Steve (2008). Go To: The Story of the Math Majors, Bridge
Players, Engineers, Chess Wizards, Maverick Scientists, and
Iconoclasts--The Programmers Who Created the Software Revolution.
Basic Books. p. 52. ISBN 978-0786730766.
^ Ensmenger, Nathan L. (2009). The Computer Boys Take Over: Computers,
Programmers, and the Politics of Technical Expertise. MIT Press.
p. 100. ISBN 978-0262050937. LCCN 2009052638.
^ "ISO/IEC 1989:2014". ISO. 26 May 2014. Retrieved 7 June 2014.
^ Beyer 2009, p. 282.
^ Gürer, Denise (2002-06-01). "Pioneering Women in Computer Science".
SIGCSE Bull. 34 (2): 175–180. doi:10.1145/543812.543853.
^ Beyer 2009, pp. 281–282.
^ Sammet 1978a, p. 200.
^ Beyer 2009, p. 283.
^ Beyer 2009, p. 284.
^ "Early Meetings of the Conference on Data Systems Languages". IEEE
Annals of the History of Computing. 7 (4): 316. 1985.
doi:10.1109/MAHC.1985.10047. (Subscription required (help)).
^ a b c d e Sammet 2004, p. 104.
^ Beyer 2009, p. 286.
^ a b Conner 1984, p. ID/9.
^ Sammet 1978a, p. 201.
^ a b c d Bemer 1971, p. 132.
^ Beyer 2009, p. 288.
^ Sammet 1978a, p. 203.
CODASYL 1969, § I.2.1.1.
^ Sammet 1978a, p. 204.
CODASYL 1969, § I.1.2.
^ Beyer 2009, p. 290.
^ Sammet, Jean (1978). "The Early History of COBOL". ACM SIGPLAN
Notices. Association for Computing Machinery, Inc. 13 (8): 121–161.
doi:10.1145/960118.808378. Retrieved 14 January 2010. (Subscription
^ Sammet 1978a, p. 217.
^ a b Beyer 2009, p. 292.
^ Bemer 1971, p. 131.
^ Beyer 2009, p. 296.
^ Sammet 1978a, p. 221.
^ Beyer 2009, p. 291.
^ "Oral History of Captain Grace Hopper" (PDF). Computer History
Museum. December 1980. p. 37. Retrieved 28 June 2014.
^ Sammet 1978a, p. 218.
^ Marcotty 1978, p. 268.
^ Sammet 1978a, pp. 205–206.
^ a b Sammet 1978a, Figure 8.
^ Sammet 1978a, pp. 230–231.
^ ISO/IEC JTC 1/SC 22/WG 4 2001, p. 846.
^ Sammet 1978a, p. 220.
^ Sammet 1978a, p. 228.
^ Sammet 1978a, p. 210.
^ Sullivan, Patricia (25 June 2004). "Computer Pioneer Bob Bemer, 84".
The Washington Post. p. B06. Retrieved 28 June 2014.
^ Bemer, Bob. "Thoughts on the Past and Future". Archived from the
original on 16 May 2014. Retrieved 28 June 2014.
^ Beyer 2009, p. 293.
^ Beyer 2009, p. 294.
^ a b "The Story of the
COBOL Tombstone" (PDF). The Computer Museum
Report. The Computer Museum. 13: 8–9. Summer 1985. Archived (PDF)
from the original on 3 April 2014. Retrieved 29 June 2014.
COBOL Tombstone". Computer History Museum. Retrieved 29 June
^ Bemer 1971, p. 130.
^ Beyer 2009, p. 289.
CODASYL 1969, § I.1.1.
^ Brown 1976, p. 47.
^ a b c Bemer 1971, p. 133.
^ a b Beyer 2009, p. 297.
^ Williams, Kathleen Broome (10 November 2012). Grace Hopper: Admiral
of the Cyber Sea. US Naval Institute Press. ISBN 978-1612512655.
^ Compaq Computer Corporation: Compaq
COBOL Reference Manual, Order
Number: AA–Q2G0F–TK October 2000, Page xviii;
Net Cobol Language Reference, Version 15, January 2009; IBM
COBOL for z/OS Language Reference, Version 4
Release 1, SC23-8528-00, December 2007
^ Garfunkel, Jerome (11 November 1984). "In defense of Cobol".
Computerworld. 18 (24): ID/19.
^ a b Bemer 1971, p. 134.
^ Brown 1976, p. 48.
CODASYL 1969, § I.2.2.4.
CODASYL 1969, § I.2.3.
^ a b c d Follet, Robert H.; Sammet, Jean E. (2003). Ralston, Anthony;
Reilly, Edwin D.; Hemmendinger, David, eds. Programming language
standards. Encyclopedia of Computer Science (4th ed.). Wiley.
p. 1467. ISBN 0470864125. (Subscription required
^ a b Beyer 2009, p. 301.
^ a b Brown 1976, p. 49.
^ Brown 1976, p. 52.
^ Taylor, Alan (2 August 1972). "Few Realise Wasted Resources of Local
DP Schools". Computerworld. 6 (31): 11.
^ Triance, J. M. (1974). Programming in COBOL: A Course of Twelve
Television Lectures. Manchester University Press. p. 87.
^ Klein 2010, p. 16.
^ Baird, George N.; Oliver, Paul (May 1977). "1974 Standard
(X3.23–1974)". Programming Language Standards—Who Needs Them?
(PDF) (Technical report). Department of the Navy. pp. 19–21.
Archived (PDF) from the original on 7 January 2014. Retrieved 7
^ Culleton, John R., Jr. (23 July 1975). "'Spotty' Availability A
Problem..." Computerworld. 9 (30): 17. ISSN 0010-4841. CS1
maint: Multiple names: authors list (link)
^ Simmons, Williams B. (18 June 1975). "Does Cobol's Report Writer
Really Miss the Mark?". Computerworld. 9 (25): 20.
^ Shoor, Rita (26 January 1981). "User Threatens Suit Over Ansi
Cobol-80". Computerworld. 15 (4): 1, 8. ISSN 0010-4841.
^ Shoor, Rita (26 October 1981). "DPMA Takes Stand Against Cobol
Draft". Computerworld. 15 (43): 1–2. ISSN 0010-4841.
^ a b c Gallant, John (16 September 1985). "Revised Cobol standard may
be ready in late '85". Computerworld. 19 (37): 1, 8.
^ a b "Expert addresses Cobol 85 standard". Computerworld. 19 (37):
41, 48. 16 September 1985. ISSN 0010-4841.
^ Paul, Lois (15 March 1982). "Responses to Cobol-80 Overwhelmingly
Negative". Computerworld. 16 (11): 1, 5. ISSN 0010-4841.
^ Paul, Lois (25 April 1983). "Study Sees Few Problems Switching to
Cobol-8X". Computerworld. 17 (17): 1, 6.
^ Gillin, Paul (19 November 1984). "DEC users get head start
implementing Cobol-80". Computerworld. 18 (47): 1, 6.
^ Garfunkel 1987, p. 150.
^ Roy, M. K.; Dastidar, D. Ghost (1 June 1989). "Features of
COBOL Programming: Problems and Solutions (2nd ed.).
McGraw-Hill Education. pp. 438–451.
^ Robinson, Brian (9 July 2009). "Cobol remains old standby at
agencies despite showing its age". FCW. Public Sector Media Group.
Retrieved 26 April 2014.
^ a b "
COBOL Standards". Micro Focus. Archived from the original on 31
March 2004. Retrieved 2 September 2014.
COBOL for .Net". netcobol.com. GTSoftware. 2013. Archived from
the original on 8 July 2014. Retrieved 29 January 2014.
^ "A list of Codasyl Cobol features". Computerworld. 10 September
1984. p. ID/28. ISSN 0010-4841. Retrieved 8 June 2014.
^ ISO/IEC JTC 1/SC 22/WG 4 2001, Annex F.
^ Klein 2010, p. 21.
^ a b "JTC1/SC22/WG4 - COBOL". ISO. 30 June 2010. Archived from the
original on 14 February 2014. Retrieved 27 April 2014.
^ Billman, John; Klink, Huib (27 February 2008). "Thoughts on the
COBOL Standardization" (PDF). Archived from the original
(PDF) on 11 July 2009. Retrieved 14 August 2014.
^ ISO/IEC JTC 1/SC 22/WG 4 2014, Annex E.
^ Schricker, Don (2 December 1998). "J4:
COBOL Standardization". Micro
Focus. Archived from the original on 24 February 1999. Retrieved 12
^ Kizior, Ronald J.; Carr, Donald; Halpern, Paul. "Does
COBOL Have a
Future?" (PDF). The Proceedings of the Information Systems Education
Conference 2000. 17 (126). Archived from the original (PDF) on 17
August 2016. Retrieved 30 September 2012.
^ Carr & Kizior 2003, p. 16.
^ Carr & Kizior 2003, p. 10.
^ "Cobol brain drain: Survey results". Computerworld. 14 March 2012.
Retrieved 27 April 2014.
^ ISO/IEC JTC 1/SC 22/WG 4 2014, § 8.9.
^ "Reserved Words Table".
Micro Focus Visual
Reference. Micro Focus. Retrieved 3 March 2014.
^ ISO/IEC JTC 1/SC 22/WG 4 2014, § 220.127.116.11.
^ ISO/IEC JTC 1/SC 22/WG 4 2014, § 8.3.2.
^ a b c d Shneiderman 1985, p. 349.
^ a b ISO/IEC JTC 1/SC 22/WG 4 2001, § F.2.
^ ISO/IEC JTC 1/SC 22/WG 4 2014, § D.18.2.
^ ISO/IEC JTC 1/SC 22/WG 4 2014, § D.18.
^ ISO/IEC JTC 1/SC 22/WG 4 2014, p. 108.
^ ISO/IEC JTC 1/SC 22/WG 4 2014, p. 896.
^ ISO/IEC JTC 1/SC 22/WG 4 2014, § D.2.1.
File Handling. Micro Focus. 1998. Retrieved 27
^ ISO/IEC JTC 1/SC 22/WG 4 2014, § 18.104.22.168.
^ Cutler 2014, Appendix A.
^ Hubbell, Thane (1999).
Sams Teach Yourself
COBOL in 24 hours. SAMS
Publishing. p. 40. ISBN 978-0672314537.
^ McCracken & Golden 1988, § 19.9.
^ Cutler 2014, § 5.8.5.
^ ISO/IEC JTC 1/SC 22/WG 4 2014, § 8.5.2.
^ a b ISO/IEC JTC 1/SC 22/WG 4 2014, § 14.9.24.
^ ISO/IEC JTC 1/SC 22/WG 4 2014, § 14.9.35.
^ ISO/IEC JTC 1/SC 22/WG 4 2014, § 13.18.40.
^ ISO/IEC JTC 1/SC 22/WG 4 2014, § 22.214.171.124.
^ ISO/IEC JTC 1/SC 22/WG 4 2014, p. 855.
^ ISO/IEC JTC 1/SC 22/WG 4 2014, § 14.4.
^ ISO/IEC JTC 1/SC 22/WG 4 2014, § 14.6.3.
^ Field, John; Ramalingam, G. (September 1999). Identifying Procedural
Structure in Cobol Programs (PDF). PASTE '99.
doi:10.1145/381788.316163. ISBN 1581131372.
^ Veerman, Niels; Verhoeven, Ernst-Jan (November 2006). "Cobol
minefield detection" (PDF). Software—Practice and Experience. Wiley.
36 (14). doi:10.1002/spe.v36:14. Archived from the original (PDF) on 6
^ ISO/IEC JTC 1/SC 22/WG4 2014, § 14.9.
^ ISO/IEC JTC 1/SC 22/WG 4 2014, §§ 14.9.4, 14.9.22.
^ ISO/IEC JTC 1/SC 22/WG 4 2014, § D.126.96.36.199.
^ ISO/IEC JTC 1/SC 22/WG 4 2014, § 188.8.131.52.
^ ISO/IEC JTC 1/SC 22/WG 4 2014, §184.108.40.206.
^ ISO/IEC JTC 1/SC 22/WG 4 2014, p. 899.
^ a b McCracken & Golden 1988, § 8.4.
^ Examples of compiler support for ALTER can be seen in the following:
Tiffin, Brian (18 September 2013). "September 2014". GNU Cobol.
Retrieved 5 January 2014.
"The ALTER Statement".
Micro Focus Visual
COBOL 2.2 for Visual Studio
COBOL Language Reference. Micro Focus. Retrieved 5 January
"ALTER Statement (Nucleus)" (PDF). COBOL85 Reference Manual. Fujitsu.
November 1996. p. 555. Archived from the original (PDF) on 6
January 2014. Retrieved 5 January 2014.
"ALTER Statement". Enterprise
COBOL for z/OS Language Reference. IBM.
June 2013. Retrieved 5 January 2014.
^ ISO/IEC JTC 1/SC 22/WG 4 2001, § F.1.
^ Moseley, Jay (17 January 2015). "
COBOL Compiler from MVT". Retrieved
19 July 2015.
^ Dijkstra, Edsger W. (18 June 1975). "How do we tell truths that
might hurt?". University of Texas at Austin. EWD498. Retrieved August
^ Tompkins, H. E. (1983). "In defense of teaching structured
computer science". ACM SIGPLAN Notices. 18 (4): 86.
doi:10.1145/948176.948186. (Subscription required (help)).
^ a b Riehle 1992, p. 125.
^ Shneiderman 1985, pp. 349–350.
^ Coughlan, Michael (16 March 2014). Beginning
COBOL for Programmers.
Apress. p. 4. ISBN 1430262532. Retrieved 13 August
^ Sammet 1978b, p. 258.
^ Riehle 1992, p. 126.
^ Riehle 1992, p. 127.
COBOL and Legacy Code as a Systemic Risk naked capitalism".
2016-07-19. Retrieved 2016-07-23.
^ Lämmel, Ralf; Verhoef, Chris (November–December 2001). "Cracking
the 500-language problem" (PDF).
IEEE Software. 18 (6): 79.
doi:10.1109/52.965809. Archived from the original (PDF) on 19 August
^ Howkins, T. J.; Harandi, M. T. (April 1979). "Towards more portable
COBOL". The Computer Journal. BCS. 22 (4): 290.
^ Garfunkel 1987, p. 11.
^ Garfunkel 1987, p. 15.
^ Raymond, Eric S. (1 October 2004). "COBOL". The Jargon File, version
4.4.8. Archived from the original on 30 August 2014. Retrieved 13
^ Brown 1976, p. 53.
CODASYL 1969, § II.1.1.
^ Shneiderman 1985, p. 350.
^ Sammet 1961, p. 381.
^ a b Conner 1984, p. ID/10.
^ Marcotty 1978, p. 263.
^ Conner 1984, p. ID/14.
^ Sammet 1961, p. 380.
^ Marcotty 1978, p. 266.
^ Sammet 1978b, p. 255.
^ Shneiderman 1985, pp. 348–349.
^ Shneiderman 1985, p. 351.
^ "An interview: Cobol defender". Computerworld. 10 September 1984.
pp. ID/29–ID/32. ISSN 0010-4841. Retrieved 8 June
^ "Academia needs more support to tackle the IT skills gap" (Press
release). Micro Focus. 7 March 2013. Retrieved 4 August 2014.
^ Carr & Kizior 2003, p. 13.
^ Sammet, Jean; Garfunkel, Jerome (October 1985). "Summary of Changes
in COBOL, 1960–1985". Annals of the History of Computing. IEEE. 7
(4): 342. doi:10.1109/MAHC.1985.10033. (Subscription required
^ Cook, Margaret M. (June 1978). Ghosh, Sakti P.; Liu, Leonard Y.,
eds. Data Base Facility for
COBOL 80 (PDF). 1978 National Computer
Conference. Anaheim, California: AFIPS Press. pp. 1107–1112.
doi:10.1109/AFIPS.1978.63. LCCN 55-44701. Retrieved 2 September
2014. The earliest date that a new
COBOL standard could be developed
and approved is the year 1980 [...].
^ "Resolutions from WG4 meeting 24 - June 26-28, 2003 Las Vegas,
Nevada, USA". 11 July 2003. p. 1. Archived from the original
(doc) on 8 March 2016. Retrieved 29 June 2014. a June 2008 revision of
^ Babcock, Charles (14 July 1986). "Cobol standard add-ons flayed".
Computerworld. 20 (28): 1, 12.
^ Marcotty, Michael (1978). Wexelblat, Richard L., ed. Full text of
all questions submitted. History of Programming Languages. Academic
Press (published 1981). p. 274. doi:10.1145/800025.1198371.
ISBN 0127450408. (Subscription required (help)).
^ This can be seen in:
IBM PartnerWorld. IBM. 21 August 2013. Archived from
the original on 12 July 2014. Retrieved 5 February 2014. Micro Focus
COBOL delivers the next generation of
COBOL development and
deployment for Linux x86-64, Linux for System z, AIX, HP/UX, Solaris,
COBOL Compilers family". ibm.com. IBM. Archived from the original on
23 February 2014. Retrieved 5 February 2014.
Tiffin, Brian (4 January 2014). "What platforms are supported by GNU
Cobol?". Archived from the original on 14 December 2013. Retrieved 5
^ Coughlan, Michael (2002). "Introduction to COBOL". Retrieved 3
Bemer, Bob (1971). "A View of the History of COBOL" (PDF). Honeywell
Computer Journal. Honeywell. 5 (3). Retrieved 28 June 2014.
Beyer, Kurt (2009).
Grace Hopper and the Invention of the Information
Age. MIT Press. ISBN 978-0262013109. LCCN 2008044229.
Brown, William R. (1 December 1976). "COBOL". In Belzer, Jack;
Holzman, Albert G.; Kent, Allen. Encyclopedia of Computer Science and
Technology: Volume 5. CRC Press. ISBN 978-0824722555.
Carr, Donald E.; Kizior, Ronald J. (31 December 2003). "Continued
COBOL in Business and Academia: Current Situation and
Comparison to the Year 2000 Study" (PDF). Information Systems
Education Journal. AITP. 1 (52). ISSN 1545-679X. Retrieved 4
CODASYL (July 1969). "
COBOL Journal of Development 1968".
National Bureau of Standards. ISSN 0591-0218.
Conner, Richard L. (14 May 1984). "Cobol, your age is showing".
Computerworld. International Data Group. 18 (20): ID/7–ID/18.
Cutler, Gary (9 April 2014). "GNU
COBOL Programmer's Guide" (PDF) (3rd
ed.). Retrieved 25 February 2014.
Garfunkel, Jerome (1987). The
COBOL 85 Example Book. Wiley.
ISO/IEC JTC 1/SC 22/WG 4 (4 December 2001). "ISO/IEC IS 1989:2001 –
Programming language COBOL". ISO. Archived from the original (ZIP of
PDF) on 24 January 2002. Retrieved 2 September 2014.
ISO/IEC JTC 1/SC 22/WG 4 (31 October 2014). INCITS/ISO/IEC 1989:2014
Programming language COBOL. INCITS.
Klein, William M. (4 October 2010). "The History of COBOL" (PDF).
Archived from the original (PDF) on 7 January 2014. Retrieved 7
Marcotty, Michael (1978). Wexelblat, Richard L., ed. Transcript of
question and answer session. History of Programming Languages.
Academic Press (published 1981). p. 263.
doi:10.1145/800025.1198370. ISBN 0127450408. (Subscription
McCracken, Daniel D.; Golden, Donald G. (1988). A Simplified Guide to
COBOL Programming (2nd ed.). Wiley. ISBN 0471610542.
Riehle, Richard L. (August 1992). "PERFORM considered harmful".
Communications of the ACM. ACM. 35 (8): 125–128.
doi:10.1145/135226.376106. (Subscription required (help)).
Sammet, Jean E. (May 1961). A method of combining
ALGOL and COBOL.
Papers presented at the May 9–11, 1961, western joint
IRE–AIEE–ACM computer conference. ACM. pp. 379–387.
doi:10.1145/1460690.1460734. (Subscription required (help)).
Sammet, Jean E. (1978a). Wexelblat, Richard L., ed. The early history
of COBOL. History of Programming Languages.
Academic Press (published
1981). doi:10.1145/800025.1198367. ISBN 0127450408. (Subscription
Sammet, Jean E. (1978b). Wexelblat, Richard L., ed. Transcript of
presentation. History of Programming Languages. Academic Press
(published 1981). doi:10.1145/800025.1198368. ISBN 0127450408.
(Subscription required (help)).
Sammet, Jean E. (23 July 2004). "COBOL". In Reilly, Edwin D. Concise
Encyclopedia of Computer Science. Wiley. ISBN 978-0470090954.
Shneiderman, B. (October 1985). "The Relationship Between
Computer Science". Annals of the History of Computing. IEEE. 7 (4):
Find more aboutCOBOLat's sister projects
Definitions from Wiktionary
Media from Wikimedia Commons
Textbooks from Wikibooks
Learning resources from Wikiversity
Data from Wikidata
COBOL at Curlie (based on DMOZ)
Visual Basic .NET
Visual Basic .NET (VB.NET)
ISO standards by standard number
ISO standards /
ISO romanizations / IEC standards