||This article's lead section may not adequately summarize key points of its contents. (October 2014)|
|Paradigm||procedural, imperative, object-oriented|
|Designed by||Grace Hopper, William Selden, Gertrude Tierney, Howard Bromberg, Howard Discount, Vernon Reeves, Jean E. Sammet|
|ISO/IEC 1989:2014 / 2014|
COBOL (//, 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, object-oriented. COBOL is primarily used in business, finance, and administrative systems for companies and governments. In 1997, Gartner Group estimated that there were a total of 200 billion lines of COBOL in existence which ran 80% of all business programs.
It was designed in 1959 by the Conference on Data Systems Languages (CODASYL) and was largely 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 temporary 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 ISO/IEC 1989:2014.
COBOL has an English-like syntax which was designed to be self-documenting and highly readable. However, it is verbose and uses over 300 reserved words. In contrast with modern, succinct notation like
x = y;, COBOL uses
MOVE x TO y. COBOL code is split into four divisions (identification, environment, data and procedure) containing a rigid hierarchy sections, paragraphs and sentences. In eschew of a large standard library, the standard specifies 43 statements, 87 functions and just one class.
COBOL has been criticised throughout its life. It has been criticised for its verbosity, design process and poor support for structured programming, which resulted in monolithic and incomprehensible programs. It has also been alienated from computer scientists since its creation.
- 1 History and specification
- 2 Features
- 2.1 Syntax
- 2.2 Code format
- 2.3 Identification division
- 2.4 Environment division
- 2.5 Data division
- 2.6 Procedure Division
- 2.7 Hello, world
- 3 Criticism and defense
- 4 See also
- 5 References
- 6 Sources
- 7 External links
History and specification
Computer users and manufacturers were becoming concerned about the rising cost of programming. A 1959 survey had found that in any data processing installation, programming cost at least $800,000 and that translating programs to run on new hardware would cost $600,000. In a time where 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.
In April 1959, representatives from academia, computer users and manufacturers met 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 Gorn.
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 modernisation.
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 ALGOL 58 meeting), a meeting was held at the Pentagon to discuss creating 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 which 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 maximum 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 three further committees: short-, intermediate- and long-range. 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 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 (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 investigated 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, 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.
IBM's COMTRAN language, invented by Bob Bemer, was a response to the competitive threat potential of FLOW-MATIC and was regarded as its competitor by a short-range committee made up of colleagues of Grace Hopper. Some of its features were not incorporated into COBOL so that it would not look like IBM had dominated the design process  and, in 1981, Jean Sammet said that there had been a "strong anti-IBM bias" from some committee members (herself included). When Roy Goldfinger, author of the COMTRAN manual and intermediate-range committee member, attended a subcommittee meeting to support his language and encourage the use of algebraic expressions, 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 both FLOW-MATIC and COMTRAN only to "keep other people happy [so they] wouldn't try to knock us out". Features from COMTRAN incorporated into COBOL included formulas, the
PICTURE clause, an improved
IF statement which obviated the need for GO TO's 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 COBOL from 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 processing).
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 COBOL to overturn the resolution. RCA representative Howard Bromberg also decided to block FACT so that RCA's work on a COBOL implementation would not go to waste.
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 (the tombstone is currently at the Computer History Museum). 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 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 specifications were approved by the Executive Committee on January 3, 1960, and sent to the government printing office, which printed these as 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 and Philco) and all represented manufacturers had announced COBOL compilers. GE and IBM planned to integrate COBOL into their own languages, GECOM and COMTRAN, respectively. In contrast, International Computers and Tabulators planned to replace their own language, CODEL, with COBOL.
Meanwhile, RCA and Sperry Rand worked on creating COBOL compilers. The first 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.
COBOL-61 to COBOL-65
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.
Early 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-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 fixed 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.
|This section requires expansion with: information about compiler validation by US Navy. (October 2014)|
Efforts began to standardise 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 standards. 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 in 1972.
By 1970, COBOL had become the most widely used programming language in the world.
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. Although CODASYL was independent of the ANSI committee, the CODASYL Journal of Development was used by ANSI to identify features which were popular enough to warrant implementing. The Programming Language Committee also liaised with ECMA and the Japanese COBOL Standard committee.
In 1974, 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, the 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 user".
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, a 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.
- scope terminators (
- nested subprograms
CONTINUE, a no-operation statement
EVALUATE, a switch statement
INITIALIZE, a statement which can set groups of data to their default values
PERFORMloop 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
In the early 1990s it was decided to add object-orientation in the next full revision of COBOL. Object-orientated 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.
There were many other new features, many of which had been in the CODASYL COBOL Journal of Development since 1978 and had missed the opportunity to be included in COBOL-85. These other features included:
- free-form code
- user-defined functions
- locale-based processing
- 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
SCREEN SECTIONfor text-based user interfaces
- improved interoperability with other programming languages and framework environments such as .NET and Java.
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 under-resourced.
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 object-orientation, the
VALIDATEfacility, the report writer and the screen-handling facility.
- Method overloading
- Dynamic capacity tables (a feature dropped from the draft of COBOL 2002)
COBOL programs are used globally in governments and businesses, and are running on diverse operating systems such as z/OS, VME, Unix 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 twentieth 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 fix 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 organizations used 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 programs.
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. However, compiler extensions allow many implementations to have far more: one implementation recognizes over 1,100 keywords. 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
OF keywords can be used interchangeably, as can
The syntactical elements of a COBOL program are "words", "literals", and "punctuation". Word elements include reserved keywords, user-defined identifiers, and labels, and must be separated from other words by spaces, newlines, or punctuation elements. Identifiers (for data items and files, as well as paragraph and section labels) are case-insensitive and may contain dashes for readability, and can be up to 30 characters long. Literal elements include numeric constants and quoted character (string) constants.
A 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 paragraphs.
COBOL can be written in two formats: fixed (the default) or free. In fixed-format, code must be aligned to fit in certain areas. Until COBOL 2002, these were:
|Sequence number area||1–6||Originally used for card/line numbers, this area is ignored by the compiler|
|Indicator area||7||The following characters are allowed here:
|Area A||8–11||This contains:
|Area B||12–72||Any other code not allowed in Area A|
|Program name area||73–||Historically up to column 80 for punched cards, it is used to identify the program or sequence the card belongs to|
In COBOL 2002, Areas A and B were merged and extended to column 255. Also, the program name area was removed.
COBOL 2002 also introduced free-format code. Free-format code can be placed in any column of the file, like in newer languages such as C and Pascal. Comments are specified using
*> which can be placed anywhere and can also can be used in fixed-format source code. Continuation lines are not present and the
>>PAGE directive replaces the
The identification division tells the computer the name of the program and supplies other documentation concerning the program's author, when it was written, when it was compiled, who it is intended for...etc. In fact, only the program name is required by the compiler.
Classes and interfaces were added in COBOL 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 called 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 added in COBOL 2014.
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 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.
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. Data items containing subordinate items which are not subordinate to another item are called records. Items that have no subordinate data items are called elementary items; those that do are called group items.
01 some-record. 05 num PIC 9(10). 05 the-date. 10 the-year PIC 9(4). 10 the-month PIC 99. 10 the-day PIC 99.
In the above example,
the-date are subordinate to the record
the-day are part of the group item
Level-numbers used to describe standard data items are between 01 and 49. Subordinate items can be disambiguated with the
OF) keyword. For example, consider the example code above along with the following example:
01 sale-date. 05 the-year PIC 9(4). 05 the-month PIC 99. 05 the-day PIC 99.
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 its semantic equivalent
the-year OF sale-date). (This syntax is similar to the "dot notation" supported by most C-like and other object-oriented programming languages.)
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.
01 customer-record. 05 cust-key PIC X(10). 05 cust-name. 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 cust-balance.
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,
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 condition, which is simply a list of explicit
VALUE constants. 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
'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'.
Standard COBOL provides the following data types:
|Data type||Sample declaration||Notes|
||May only contain letters or spaces|
||May contain any characters|
||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. UTF-8|
||May contain only numbers|
||May reference either an object or be
PIC) clause is a string of characters, each of which represents a portion of the data item. 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.
||Value in||Value out|
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
PICTUREclause or by a
USAGEclause such as
USAGE COMPUTATIONAL, where data may be stored in whatever format the implementation provides; often equivalent to
USAGE DISPLAY, the default format, where data is stored as a string
- Floating-point, in either an implementation-dependent format or according to IEEE 754.
USAGE NATIONAL, where data is stored as a string using an extended character set
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 from a file of 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:
RD sales-report PAGE LIMITS 60 LINES FIRST DETAIL 3 CONTROLS seller-name. 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 sales-date. 03 COL 21 VALUE "were". 03 COL 26 PIC $$$$9.99 SOURCE sales-amount. 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:
Sales Report Page 1 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 Report Page 12 Sales on 08/05/2014 were $543.98 INVALID RECORD: William Selden 12O52014FOOFOO Sales on 30/05/2014 were $0.00
Using the report writer results in a smaller, simpler procedure division. There are four statements for 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 INITIATE sales-report PERFORM UNTIL 1 <> 1 READ sales AT END EXIT PERFORM END-READ VALIDATE sales-record IF valid-record GENERATE sales-on-day ELSE GENERATE invalid-sales END-IF END-PERFORM TERMINATE sales-report 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 upon reaching the end.
Procedures can be reached in three ways: they can be called with
PERFORM, jumped to from a
GO TO or be reached by execution "falling through" an above paragraph. Combinations of these create "mines", where control in performed procedures returns at unexpected times to unexpected locations. Mines are caused by undefined behaviour in the COBOL standard, specifically when execution of a range of procedures would cause control flow to go past the last statement of a range of procedures already being performed. For example, in the code in the adjacent image, a mine is tripped at the end of
update-screen when the screen is invalid. Control could either return to the first perform statement or to the statement in
fix-error where it will then "fall-through" into
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
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 desired-speed PERFORM slow-down-machine WHEN lid-closed ALSO min-speed THRU max-speed ALSO GREATER THAN desired-speed PERFORM speed-up-machine WHEN lid-open ALSO ANY ALSO NOT ZERO PERFORM emergency-stop WHEN OTHER CONTINUE END-EVALUATE
PERFORM statement is used to define loops which are executed until a condition is true (not while, unlike other languages). It is also used to call procedures or ranges of procedures (see the procedures section for more details).
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.
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, not all exceptions are fatal (for example, attempting to free a null pointer). These non-fatal exceptions do not need to be handled and the program can proceed unaffected.
File I/O is handled by the self-describing
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
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.
COMPUTE, which handle arithmetic (with
COMPUTEassigning the result of a formula to a variable).
FREE, which handle dynamic memory.
VALIDATE, which validates and distributes data as specified in an item's description in the data division.
UNSTRING, which concatenate and split strings, respectively.
INSPECT, which tallies or replaces instances of specified substrings within a string.
SEARCH, which searches a table for the first entry satisfying a condition.
Files and tables are sorted using
MERGE verb merges and sorts files. The
RELEASE verb provides records to sort and the
RETURN verb retrieves sorted records in order.
Some statements, such as
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") IF invalid-record IF no-more-records NEXT SENTENCE ELSE READ record-file AT END SET no-more-records TO TRUE. *> Scope terminators ("explicit termination") IF invalid-record IF no-more-records CONTINUE ELSE READ record-file AT END SET no-more-records TO TRUE END-READ END-IF END-IF
IF x DISPLAY y. DISPLAY z.
Here, the intent is to display
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
Another bug is a result of the dangling else problem, when two
IF statements can associate with an
IF x IF y DISPLAY a ELSE DISPLAY b.
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 inner
The original COBOL specification supported the infamous
ALTER X TO PROCEED TO Y statement, for which many compilers generated self-modifying code.
Y are paragraph labels, and any
GO TO X statements executed after such an
ALTER statement mean
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:
IDENTIFICATION DIVISION. PROGRAM-ID. HELLO-WORLD. PROCEDURE DIVISION. DISPLAY 'Hello, world'. STOP RUN.
Criticism and defense
Lack of structure
In the 1970s, programmers began moving away from unstructured "spaghetti code" to the structured programming paradigm. 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.
In his letter to an editor in 1975 entitled "How do we tell truths that might hurt?" which was critical of several of COBOL's contemporaries, computer scientist and Turing Award recipient Edsger Dijkstra remarked that "The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offense." In his dissenting response to Dijkstra's article and the above "offensive statement," computer scientist Howard E. Tompkins defended structured COBOL: "COBOL programs with convoluted control flow indeed tend to 'cripple the mind'," but this was because "There are too many such business application programs written by programmers that have never had the benefit of structured COBOL taught well..."
COBOL programs were infamous for being monolithic and lacking modularization. COBOL code could only be modularized through procedures, which were found to be inadequate for large systems. It was impossible to hide 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 was the ability to
PERFORM a range 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 included.
COBOL was intended to a be a highly portable, "common" language. However, by 2001, around 300 dialects had been created.
COBOL-85 was not fully compatible with earlier versions, resulting in the "caesarean birth" of COBOL-85.[clarification needed] Joseph T. Brophy, the CIO of Travelers Insurance, spearheaded an effort to inform users of COBOL of the heavy reprogramming costs of implementing the new standard. As a result, the ANSI 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 costs.[page needed]
COBOL syntax has often been criticized for its verbosity. However, proponents note that this was intentional in the language design because it made the code self-documenting, easing program maintenance. COBOL was intended to be easier for programmers to learn and use, but while being readable to non-technical staff such as managers (despite there being no evidence it would be useful). The desire for readability and good program documentation is why COBOL has English-like syntax and structural elements, such as nouns, verbs, clauses, sentences, sections, and divisions. Consequently, COBOL is considered by one source to be "The most readable, understandable and self-documenting programming language in use today. [...] Not only does this readability generally assist the maintenance process but the older a program gets the more valuable this readability becomes." On the other hand, 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 in programming tend to be very unhappy with COBOL" which she attributed to COBOL's verbose syntax.
Alienation from the computer science community
The 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. This was due to the differing interests of computer scientists at the time, who were more interested in fields like numerical analysis, physics and system programming than the commercial file-processing problems which COBOL development tackled. 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 and not the new Backus–Naur form because few committee members had heard of it. This resulted in "severe" criticism.
Later, COBOL suffered from a shortage of material covering it; it took until 1963 for introductory books to appear. By 1985, there were twice as many books on Fortran and four times as many on BASIC than on COBOL in the Library of Congress. As COBOL became a mainstream language, COBOL suffered as 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, the chair of the CODASYL 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 2003, COBOL featured in 80% of information systems curricula, the same proportion as C++ and Java.
Concerns about the design process
There were doubts about the effectiveness of the design process (sometimes from those taking part in it). 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".
COBOL standards have repeatedly suffered from delays: COBOL-85 arrived five years later than hoped, COBOL 2002 was five years late, and 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.
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.
Until COBOL 2002, COBOL was a simple language with a limited scope of function (with no pointers, no user-defined types, and no user-defined functions), encouraging a straightforward coding style. This has made it well-suited to its primary domain of business computing—where the program complexity lies in the business rules that need to be encoded rather than sophisticated algorithms or data structures.
Standardization meant programs written in COBOL are portable and language has since spread on to a wide variety of hardware platforms and operating systems. Additionally, the rigid hierarchical structure restricts the definition of external references to the Environment Division, which simplifies platform changes in particular.
- Programming language genealogies
- Alphabetical list of programming languages
- Comparison of programming languages
- 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.
- Robinson, Brian (9 July 2009). "Cobol remains old standby at agencies despite showing its age". FCW. Public Sector Media Group. Retrieved 26 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.
- 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.
- Sammet 2004, p. 104.
- Beyer 2009, p. 286.
- Conner 1984, p. ID/9.
- Sammet 1978a, p. 201.
- 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.
- Sammet 1978a, p. 217.
- Bemer 1971, p. 131.
- Beyer 2009, p. 292.
- 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 1981, p. 268.
- Sammet 1978a, pp. 205–206.
- 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.
- "The Story of the COBOL Tombstone" (PDF). The Computer Museum Report (The Computer Museum) 13: 8–9. Summer 1985. Archived from the original on 3 April 2014. Retrieved 29 June 2014.
- Bemer 1971, p. 130.
- "COBOL Tombstone". Computer History Museum. Retrieved 29 June 2014.
- Beyer 2009, p. 289.
- CODASYL 1969, § I.1.1.
- Brown 1976, p. 47.
- Bemer 1971, p. 133.
- Beyer 2009, p. 297.
- Williams, Kathleen Broome (10 November 2012). Grace Hopper: Admiral of the Cyber Sea. US Naval Institute Press. ISBN 978-1612512655. OCLC 818867202.
- Garfunkel, Jerome (11 November 1984). "In defense of Cobol". Computerworld 18 (24): ID/19.
- Bemer 1971, p. 134.
- Brown 1976, p. 48.
- CODASYL 1969, § I.2.2.4.
- CODASYL 1969, § I.2.3.
- 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.
- Beyer 2009, p. 301.
- Brown 1976, p. 49.
- Brown 1976, p. 52.
- Triance, J. M. (1974). Programming in COBOL: A Course of Twelve Television Lectures. Manchester University Press. p. 87. ISBN 0719005922.
- Klein 2010, p. 16.
- Baird, George N.; Oliver, Paul (May 1977). "1974 Standard (X3.23–1974)". Programming Language Standards — Who Needs Them? (Technical report). pp. 19–21. Archived from the original on 7 January 2014. Retrieved 7 January 2014.
- Culleton, John R., Jr. (23 July 1975). "'Spotty' Availability A Problem...". Computerworld 9 (30): 17. ISSN 0010-4841.
- Simmons, Williams B. (18 June 1975). "Does Cobol's Report Writer Really Miss the Mark?". Computerworld 9 (25): 20. ISSN 0010-4841.
- 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.
- Gallant, John (16 September 1985). "Revised Cobol standard may be ready in late '85". Computerworld 19 (37): 1, 8. ISSN 0010-4841.
- "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. ISSN 0010-4841.
- Garfunkel 1987, p. 150.
- Roy, M K; Dastidar, D Ghost (1 June 1989). "Features of COBOL-85". COBOL Programming: Problems and Solutions (2nd ed.). McGraw-Hill Education. pp. 438–451. ISBN 978-0074603185.
- Saade, Henry; Wallace, Ann (October 1995). "COBOL '97: A Status Report". Dr. Dobb's Journal. Retrieved 21 April 2014.
- 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 influence of Smalltalk and C++.
- "COBOL Standards". Micro Focus. Archived from the original on 31 March 2004. Retrieved 2 September 2014.
- "NetCOBOL for .Net". netcobol.com. GTSoftware. 2013. Retrieved 29 January 2014.
- "A list of Codasyl Cobol features". Computerworld 18 (37). 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.
- "JTC1/SC22/WG4 - COBOL". ISO. 30 June 2010. Retrieved 27 April 2014.
- Billman, John; Klink, Huib (27 February 2008). "Thoughts on the Future of COBOL Standardization" (PDF). Retrieved 14 August 2014.
- ISO/IEC JTC 1/SC 22/WG 4 2010, Annex E.
- Schricker, Don (2 December 1998). "J4: COBOL Standardization". Micro Focus. Archived from the original on 24 February 1999. Retrieved 12 July 2014.
- Kizior, Ronald J.; Carr, Donald; Halpern, Paul. "Does COBOL Have a Future?". The Proceedings of the Information Systems Education Conference 2000 17 (126). Retrieved 2012-09-30.
- Carr & Kizior 2003, p. 16.
- Carr & Kizior 2003, p. 10.
- Mitchell, Robert L. (4 October 2006). "Cobol: Not Dead Yet". Computerworld. Retrieved 27 April 2014.
- "Cobol brain drain: Survey results". Computerworld. 14 March 2012. Retrieved 27 April 2014.
- ISO/IEC JTC 1/SC 22/WG 4 2010, § 8.9.
- "Reserved Words Table". Micro Focus Visual COBOL 2.2 COBOL Language Reference. Micro Focus. Retrieved 3 March 2014.
- ISO/IEC JTC 1/SC 22/WG 4 2001, § F.2.
- ISO/IEC JTC 1/SC 22/WG 4 2010, § D.2.
- ISO/IEC JTC 1/SC 22/WG 4 2010, § D.18.2.
- ISO/IEC JTC 1/SC 22/WG 4 2010, § D.18.
- ISO/IEC JTC 1/SC 22/WG 4 2010, p. 100.
- ISO/IEC JTC 1/SC 22/WG 4 2010, p. 871.
- ISO/IEC JTC 1/SC 22/WG 4 2010, § D.2.1.
- "File Organizations". File Handling. Micro Focus. 1998. Retrieved 27 June 2014.
- Cutler 2014, Appendix A.
- McCracken & Golden 1988, § 19.9.
- Cutler 2014, § 5.8.5.
- ISO/IEC JTC 1/SC 22/WG 4 2010, § 8.5.2.
- ISO/IEC JTC 1/SC 22/WG 4 2010, § 13.18.39.
- ISO/IEC JTC 1/SC 22/WG 4 2010, § 14.9.24.
- ISO/IEC JTC 1/SC 22/WG 4 2010, § 126.96.36.199.
- Brown 1976, p. 64.
- ISO/IEC JTC 1/SC 22/WG 4 2010, p. 835.
- ISO/IEC JTC 1/SC 22/WG 4 2010, § 14.4.
- ISO/IEC JTC 1/SC 22/WG 4 2010, § 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 on 6 March 2007.
- ISO/IEC JTC 1/SC 22/WG4 2010, § 14.9.
- ISO/IEC JTC 1/SC 22/WG 4, §§ 14.9.4, 14.9.22.
- ISO/IEC JTC 1/SC 22/WG 4 2010, § D.188.8.131.52.
- ISO/IEC JTC 1/SC 22/WG 4 2010, p. 481.
- ISO/IEC JTC 1/SC 22/WG 4 2010, pp. 557–559.
- ISO/IEC JTC 1/SC 22/WG 4 2010, p. 873.
- McCracken & Golden 1988, § 8.4.
- Examples of compiler support for
ALTERcan 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 2013 COBOL Language Reference. Micro Focus. Retrieved 5 January 2014.
- "ALTER Statement (Nucleus)" (PDF). COBOL85 Reference Manual. Fujitsu. November 1996. p. 555. 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.
- Riehle 1992, p. 125.
- Shneiderman 1985, pp. 349–350.
- Dijkstra, Edsger W. (2006). "E. W. Dijkstra Archive: How do we tell truths that might hurt? (EWD498)". University of Texas at Austin. Retrieved August 29, 2007.
- Tompkins, H. E. (1983). "In defense of teaching structured COBOL as computer science". ACM SIGPLAN Notices 18 (4): 86. doi:10.1145/948176.948186.
- Coughlan, Michael (16 March 2014). Beginning COBOL for Programmers. Apress. p. 4. ISBN 1430262532. Retrieved 13 August 2014.
- Sammet 1978b, p. 258.
- Riehle 1992, p. 126.
- Riehle 1992, p. 127.
- Lämmel, Ralf; Verhoef, Chris (November–December 2001). "Cracking the 500-language problem" (PDF). IEEE Software 18 (6): 79. doi:10.1109/52.965809.
- Garfunkel 1987, p. 11.
- Garfunkel 1987.
- Raymond, Eric S. (1 October 2004). "COBOL". The Jargon File, version 4.4.8. Archived from the original on 30 August 2014. Retrieved 13 December 2014.
- Brown 1976, p. 53.
- CODASYL 1969, § II.1.1.
- Shneiderman 1985, p. 350.
- Sammet 1961, p. 381.
- Conner 1984, p. ID/10.
- Marcotty 1981, p. 263.
- Coughlan, Michael (2002). "Introduction to COBOL". Retrieved 3 February 2014.
- Conner 1984, p. ID/14.
- Sammet 1961, p. 380.
- Marcotty 1981, p. 266.
- Sammet 1978b, p. 255.
- CODASYL 1969, § 2.2.5.
- Shneiderman 1985, pp. 348–349.
- Shneiderman 1985, p. 349.
- Shneiderman 1985, p. 351.
- "An interview: Cobol defender". Computerworld 18 (37). 10 September 1984. pp. ID/29–ID/32. ISSN 0010-4841. Retrieved 8 June 2014.
- "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.
- 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. 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" (doc). 11 July 2003. p. 1. Retrieved 29 June 2014.
a June 2008 revision of the COBOL standard
- 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.
- This can be seen in:
- "Visual COBOL". IBM PartnerWorld. IBM. 21 August 2013. Archived from the original on 12 July 2014. Retrieved 5 February 2014.
Micro Focus Visual COBOL delivers the next generation of COBOL development and deployment for Linux x86-64, Linux for System z, AIX, HP/UX, Solaris, and Windows.
- "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 February 2014.
- "Visual COBOL". IBM PartnerWorld. IBM. 21 August 2013. Archived from the original on 12 July 2014. Retrieved 5 February 2014.
- 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 Relevance of 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 August 2014.
- CODASYL (July 1969). CODASYL COBOL Journal of Development 1968. National Bureau of Standards. LCCN 73601243.
- Conner, Richard L. (14 May 1984). "Cobol, your age is showing". Computerworld (International Data Group) 18 (20): ID/7–ID/18. ISSN 0010-4841.
- Cutler, Gary (9 April 2014). "GNU COBOL Programmer's Guide" (3rd ed.). Retrieved 25 February 2014.
- Garfunkel, Jerome (1987). The COBOL 85 Example Book. Wiley. ISBN 0471804614.
- ISO/IEC JTC 1/SC 22/WG 4 (4 December 2001). "ISO/IEC IS 1989:2001 – Programming language COBOL" (ZIP of PDF). ISO. Archived from the original on 23 January 2002. Retrieved 2 September 2014.
- ISO/IEC JTC 1/SC 22/WG 4 (13 July 2010). "ISO/IEC 1989:20xx FCD 1.0 – Programming language COBOL" (PDF). ISO. Retrieved 9 February 2014.
- Klein, William M. (4 October 2010). "The History of COBOL" (PDF). Archived from the original on 7 January 2013. Retrieved 7 January 2014.
- 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.
- McCracken, Daniel D.; Golden, Donald G. (1988). A Simplified Guide to Structured COBOL Programming (2nd ed.). Wiley. ISBN 0471610542. LCCN 87034608.
- Riehle, Richard L. (August 1992). "PERFORM considered harmful". Communications of the ACM (ACM) 35 (8): 125–128.
- 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.
- 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.
- 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.
- Sammet, Jean E. (23 July 2004). "COBOL". In Reilly, Edwin D. Concise Encyclopedia of Computer Science. Wiley. ISBN 978-0470090954. OCLC 249810423.
- Shneiderman, B. (October 1985). "The Relationship Between COBOL and Computer Science". Annals of the History of Computing (IEEE) 7 (4): 348–352. doi:10.1109/MAHC.1985.10041.
- COBOLStandard.info – the official home for COBOL standards
- COBOL Compilerator – online COBOL compiler for small experiments
|Wikibooks has more on the topic of: COBOL|