|
COBOL
COBOL (/ˈkoʊbɒl, -bɔːl/; an acronym for "common business-oriented language") is a compiled English-like computer programming language designed for business use. It is an imperative, procedural, and, since 2002, object-oriented language. COBOL is primarily used in business, finance, and administrative systems for companies and governments. COBOL is still widely used in applications deployed on mainframe computers, such as large-scale batch and transaction processing jobs. Many large financial institutions were developing new systems in the language as late as 2006,[10] but most programming in COBOL today is purely to maintain existing applications. Programs are being moved to new platforms, rewritten in modern languages, or replaced with other software.[11] COBOL was designed in 1959 by CODASYL and was partly based on the programming language FLOW-MATIC, designed by Grace Hopper. It was created as part of a U.S. Department of Defense effort to create a portable programming language for data processing. It was originally seen as a stopgap, but the Defense Department promptly pressured computer manufacturers to provide it, resulting in its widespread adoption.[12] It was standardized in 1968 and has been revised five times. Expansions include support for structured and object-oriented programming. The current standard is ISO/IEC 1989:2023.[13] COBOL statements have prose syntax such as The 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 applications when 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.[14] COBOL has been criticized for its verbosity, design process, and poor support for structured programming. These weaknesses result in monolithic programs that are hard to comprehend as a whole, despite their local readability. For years, COBOL has been assumed as a programming language for business operations in mainframes,[15] although in recent years, many COBOL operations have been moved to cloud computing.[16] History and specification
BackgroundIn 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 US$600,000. At a time when new programming languages were proliferating, the same survey suggested that if a common business-oriented language were used, conversion would be far cheaper and faster.[17] On 8 April 1959, Mary K. Hawes, a computer scientist at Burroughs Corporation, 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.[18] Representatives included Grace Hopper (inventor of the English-like data processing language FLOW-MATIC), Jean Sammet, and Saul Gorn.[19][20] At the April meeting, 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,[21] who thought that they "thoroughly understood" the DoD's problems. The DoD operated 225 computers, had 175 more 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.[22] Charles Phillips agreed to sponsor the meeting, and tasked the delegation with drafting the agenda.[23] COBOL 60On 28 and 29 May 1959 (exactly one year after the Zürich ALGOL 58 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.[24] 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.[25] 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.[26] The meeting resulted in the creation of a steering committee and short, intermediate, and long-range committees. The short-range committee was given until September (three months) to produce specifications for an interim language, which would then be improved upon by the other committees.[27][28] Their official mission, however, was to identify the strengths and weaknesses of existing programming languages; it did not explicitly direct them to create a new language.[25] The deadline was met with disbelief by the short-range committee.[29] One member, Betty Holberton, described the three-month deadline as "gross optimism" and doubted that the language really would be a stopgap.[30] The steering committee met on 4 June and agreed to name the entire activity the Committee on Data Systems Languages, or CODASYL, and to form an executive committee.[31] The short-range committee members represented six computer manufacturers and three government agencies. The computer manufacturers were Burroughs Corporation, IBM, Minneapolis-Honeywell (Honeywell Labs), RCA, Sperry Rand, and Sylvania Electric Products. The government agencies were the U.S. Air Force, the Navy's David Taylor Model Basin, and the National Bureau of Standards (now the National Institute of Standards and Technology).[32] The committee was chaired by Joseph Wegstein of the U.S. National Bureau of Standards. Work began by investigating data descriptions, statements, existing applications, and user experiences.[33] The committee mainly examined the FLOW-MATIC, AIMACO, and COMTRAN programming languages.[25][34] The FLOW-MATIC language was particularly influential because it had been implemented and because AIMACO was a derivative of it with only minor changes.[35][36] FLOW-MATIC's inventor, Grace Hopper, also served as a technical adviser to the committee.[29] FLOW-MATIC's major contributions to COBOL were long variable names, English words for commands, and the separation of data descriptions and instructions.[37] Hopper is sometimes called "the mother of COBOL" or "the grandmother of COBOL",[38][39][40] although Jean Sammet, a lead designer of COBOL, said Hopper "was not the mother, creator, or developer of Cobol."[41][1] IBM's COMTRAN language, invented by Bob Bemer, was regarded as a competitor to FLOW-MATIC[42][43] by a short-range committee made up of colleagues of Grace Hopper.[44] Some of its features were not incorporated into COBOL so that it would not look like IBM had dominated the design process,[27] and Jean Sammet said in 1981 that there had been a "strong anti-IBM bias" from some committee members (herself included).[45] In one case, after 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.[46] 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.".[47] Features from COMTRAN incorporated into COBOL included formulas,[48] the The usefulness of the committee's work was a 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.[50] Controversial features included those some considered useless or too advanced for data processing users. Such features included Boolean expressions, formulas, and table subscripts (indices).[51][52] Another point of controversy was whether to make keywords context-sensitive and the effect that would have on readability.[51] Although context-sensitive keywords were rejected, the approach was later used in PL/I and partially in COBOL from 2002.[53] 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).[54][55] The specifications were presented to the executive committee on 4 September. 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 committee was given until December to improve it.[29] 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).[56] It is unclear who coined the name "COBOL",[57][58] although Bob Bemer later claimed it had been his suggestion.[59][60][61] 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.[62] 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,[29] allowing supporters of a FLOW-MATIC-based COBOL to overturn the resolution. RCA representative Howard Bromberg also blocked FACT, so that RCA's work on a COBOL implementation would not go to waste.[63] It soon became apparent that the committee was too large to make any further progress 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][65][66] A subcommittee was formed to analyze existing languages and was made up of six individuals:[25][67]
The subcommittee did most of the work creating the specification, leaving the short-range committee to review and modify their work before producing the finished specification.[25] The specifications were approved by the executive committee on 8 January 1960, and sent to the government printing office, which printed them 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.[68] The CODASYL Executive Committee later created the COBOL Maintenance Committee to answer questions from users and vendors and to improve and expand the specifications.[69] 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 language, CODEL, with COBOL.[70] Meanwhile, RCA and Sperry Rand worked on creating COBOL compilers. The first COBOL program ran on 17 August on an RCA 501.[71] On 6 and 7 December, 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.[72] The relative influence of the languages that were used is still indicated in the recommended advisory printed in all COBOL reference manuals:
COBOL-61 to COBOL-65
Anonymous, June 1960[74]
Many logical flaws were found in COBOL 60, leading General Electric's Charles Katz to warn that it could not be interpreted unambiguously. A reluctant short-term committee performed a total cleanup, and, by March 1963, it was reported that COBOL's syntax was as definable as ALGOL's, although semantic ambiguities remained.[70] COBOL is a difficult language to write a compiler for, due to the large syntax and many optional elements within syntactic constructs, as well as the need to generate efficient code for a language with many possible data representations, implicit type conversions, and necessary set-ups for I/O operations.[75] 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.[76] In late 1962, IBM announced that COBOL would be their primary development language and that development of COMTRAN would cease.[76] The 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.[77] The added facilities corrected flaws identified by Honeywell in late 1959 in a letter to the short-range committee.[71] COBOL Edition 1965 brought further clarifications to the specifications and introduced facilities for handling mass storage files and tables.[78] COBOL-68Efforts 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 standards. ANSI produced USA Standard COBOL X3.23 in August 1968, which became the cornerstone for later versions.[79] This version was known as American National Standard (ANS) COBOL and was adopted by ISO in 1972.[80] COBOL-74By 1970, COBOL had become the most widely used programming language in the world.[81] 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.[82] Although 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.[83] The Programming Language Committee also liaised with ECMA and the Japanese COBOL Standard committee.[82] 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 also lacked the funds to make public documents, such as minutes of meetings and change proposals, freely available.[84] In 1974, ANSI published a revised version of (ANS) COBOL, containing new features such as file organizations, the COBOL-85In 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".[90] 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".[91][92] During the first public review period, the committee received 2,200 responses, of which 1,700 were negative form letters.[93] 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.[94] ISO TC97-SC5 installed in 1979 the international COBOL Experts Group, on initiative of Wim Ebbinkhuijsen. The group consisted of COBOL experts from many countries, including the United States. Its goal was to achieve mutual understanding and respect between ANSI and the rest of the world with regard to the need of new COBOL features. After three years, ISO changed the status of the group to a formal Working Group: WG 4 COBOL. The group took primary ownership and development of the COBOL standard, where ANSI made most of the proposals. 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.[92][95] A year later, DEC released a VAX/VMS COBOL-80, and noted that conversion of COBOL-74 programs posed few problems. The new 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.[92] In 1985, the ISO Working Group 4 accepted the then-version of the ANSI proposed standard, made several changes and set it as the new ISO standard COBOL 85. It was published in late 1985. Sixty features were changed or deprecated and 115[97] were added, such as:[98][99]
The new standard was adopted by all national standard bodies, including ANSI.[80] Two amendments followed in 1989 and 1993. The first amendment introduced intrinsic functions and the other provided corrections.[80] COBOL 2002 and object-oriented COBOLIn 1997, Gartner Group estimated that there were a total of 200 billion lines of COBOL in existence, which ran 80% of all business programs.[c][100] 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.[3][4] 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.[101] Fujitsu/GTSoftware,[102] Micro Focus introduced object-oriented COBOL compilers targeting the .NET Framework. 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.[103] These other features included:[104][105]
Three corrigenda were published for the standard: two in 2006 and one in 2009.[106] COBOL 2014Between 2003 and 2009, three technical reports were produced describing object finalization, XML processing and collection classes for COBOL.[106] 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.[107] COBOL 2014 includes the following changes:[108]
COBOL 2023The COBOL 2023 standard added a few new features:
There is as yet no known complete implementation of this standard.[citation needed] LegacyCOBOL programs are used globally in governments and businesses and are running on diverse operating systems such as z/OS, z/VSE, VME, Unix, NonStop OS, 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[c] and 5 billion lines more being written annually.[114] 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 to the large amount of business-oriented COBOL, as business applications use dates heavily, and to fixed-length data fields.[115] Some studies attribute as much as "24% of Y2K software repair costs to Cobol".[116] After the clean-up effort put into these programs for Y2K, a 2003 survey found that many remained in use.[117] 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".[118] In 2006 and 2012, Computerworld surveys (of 352 readers) 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.[10][119] 36% of managers said they planned to migrate from COBOL, and 25% said that they would do so if not for the expense of rewriting legacy code. Alternatively, some businesses have migrated their COBOL programs from mainframes to cheaper, faster hardware.[10] Testimony before the House of Representatives in 2016 indicated that COBOL is still in use by many federal agencies.[120] Reuters reported in 2017 that 43% of banking systems still used COBOL with over 220 billion lines of COBOL code in use.[121] By 2019, the number of COBOL programmers was shrinking fast due to retirements, leading to an impending skills gap in business and government organizations which still use mainframe systems for high-volume transaction processing. Efforts to rewrite systems in newer languages have proven expensive and problematic, as has the outsourcing of code maintenance, thus proposals to train more people in COBOL are advocated.[122] During the COVID-19 pandemic and the ensuing surge of unemployment, several US states reported a shortage of skilled COBOL programmers to support the legacy systems used for unemployment benefit management. Many of these systems had been in the process of conversion to more modern programming languages prior to the pandemic, but the process was put on hold.[123] Similarly, the US Internal Revenue Service rushed to patch its COBOL-based Individual Master File in order to disburse the tens of millions of payments mandated by the Coronavirus Aid, Relief, and Economic Security Act.[124] FeaturesSyntaxCOBOL has an English-like syntax, which is used to describe nearly everything in a program. For example, a condition can be expressed as Each 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. 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. MetalanguageCOBOL's syntax is usually described with a unique metalanguage using braces, brackets, bars and underlining.[129] The metalanguage was developed for the original COBOL specifications.
As an example, consider the following description of an
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
DISPLAY "Error"
END-ADD
ADD a TO b
NOT SIZE ERROR
DISPLAY "No error"
ON SIZE ERROR
DISPLAY "Error"
Code format  The height of COBOL's popularity coincided with the era of keypunch machines and punched cards. The program itself was written onto punched cards, then read in and compiled, and the data fed into the program was sometimes on cards as well.[130] 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:
In COBOL 2002, Areas A and B were merged to form the program-text area, which now ends at an implementor-defined column.[131] 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 Identification divisionThe identification division identifies the following code entity and contains the definition of a class or interface. Object-oriented programmingClasses 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.[132] 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 *> 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 Environment divisionThe 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. FilesCOBOL 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. Other implementations are Record Management Services on OpenVMS and Enscribe on HPE NonStop (Tandem). 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.[136] 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.[137] Data divisionThe 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. Aggregated dataData 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.[138][139] 01 some-record. *> Aggregate group record item
05 num PIC 9(10). *> Elementary item
05 the-date. *> Aggregate (sub)group record item
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 Subordinate items can be disambiguated with the 01 sale-date.
05 the-year PIC 9(4).
05 the-month PIC 99.
05 the-day PIC 99.
The names Other data levelsA 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 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, 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 01 wage-type PIC X.
88 wage-is-hourly VALUE "H".
88 wage-is-yearly VALUE "S", "Y".
Data typesStandard COBOL provides the following data types:[143]
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.[144] 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.[145] PICTURE clauseA
USAGE clause
The
Report writerThe 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.[148] 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: 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 Four statements control the report writer: 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
.
Use of the Report Writer facility tends to vary considerably; some organizations use it extensively and some not at all.[149] In addition, implementations of Report Writer ranged in quality, with those at the lower end sometimes using excessive amounts of memory at runtime.[149] Procedure divisionProceduresThe 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.[150] Execution goes down through the procedures of a program until it is terminated.[151]
To use procedures as subroutines, the A PROCEDURE so-and-so.
PERFORM ALPHA
PERFORM ALPHA THRU GAMMA
STOP RUN.
ALPHA.
DISPLAY 'A'.
BETA.
DISPLAY 'B'.
GAMMA.
DISPLAY 'C'.
The output of this program will be: "A A B C".
The reason is that COBOL, rather than a "return address", operates with what may be called a continuation address. When control flow reaches the end of any procedure, the continuation address is looked up and control is transferred to that address. Before the program runs, the continuation address for every procedure is initialized to the start address of the procedure that comes next in the program text so that, if no The following example (taken from Veerman & Verhoeven 2006) illustrates the problem: LABEL1.
DISPLAY '1'
PERFORM LABEL2 THRU LABEL3
STOP RUN.
LABEL2.
DISPLAY '2'
PERFORM LABEL3 THRU LABEL4.
LABEL3.
DISPLAY '3'.
LABEL4.
DISPLAY '4'.
One might expect that the output of this program would be "1 2 3 4 3": After displaying "2", the second A special consequence of this limitation is that MOVE 1 TO A
PERFORM LABEL
STOP RUN.
LABEL.
DISPLAY A
IF A < 3
ADD 1 TO A
PERFORM LABEL
END-IF
DISPLAY 'END'.
One might expect that the output is "1 2 3 END END END", and in fact that is what some COBOL compilers will produce. But other compilers, like IBM COBOL, will produce code that prints "1 2 3 END END END END ..." and so on, printing "END" over and over in an endless loop. Since there is limited space to store backup continuation addresses, the backups get overwritten in the course of recursive invocations, and all that can be restored is the jump back to StatementsCOBOL 2014 has 47 statements (also called verbs),[154] 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. Control flowCOBOL's conditional statements are EVALUATE TRUE ALSO desired-speed ALSO current-speed
WHEN lid-closed ALSO min-speed THRU max-speed ALSO LESS THAN desired-speed
PERFORM speed-up-machine
WHEN lid-closed ALSO min-speed THRU max-speed ALSO GREATER THAN desired-speed
PERFORM slow-down-machine
WHEN lid-open ALSO ANY ALSO NOT ZERO
PERFORM emergency-stop
WHEN OTHER
CONTINUE
END-EVALUATE
The The Exceptions are raised by a I/OFile I/O is handled by the self-describing User interaction is done using Data manipulationThe following verbs manipulate data:
Files and tables are sorted using Scope terminationSome statements, such as *> 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
Nested statements terminated with a period are a common source of bugs.[159][160] For example, examine the following code: IF x
DISPLAY y.
DISPLAY z.
Here, the intent is to display Another bug is a result of the dangling else problem, when two IF x
IF y
DISPLAY a
ELSE
DISPLAY b.
In the above fragment, the Self-modifying codeThe original (1959) COBOL specification supported the infamous The Hello, worldA "Hello, World!" program in COBOL: IDENTIFICATION DIVISION.
PROGRAM-ID. hello-world.
PROCEDURE DIVISION.
DISPLAY "Hello, world!"
.
When the now famous "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 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.[164] In keeping with COBOL programming of that era, HELLO, WORLD is displayed in all capital letters. //COBUCLG JOB (001),'COBOL BASE TEST', 00010000
// CLASS=A,MSGCLASS=A,MSGLEVEL=(1,1) 00020000
//BASETEST EXEC COBUCLG 00030000
//COB.SYSIN DD * 00040000
00000* VALIDATION OF BASE COBOL INSTALL 00050000
01000 IDENTIFICATION DIVISION. 00060000
01100 PROGRAM-ID. 'HELLO'. 00070000
02000 ENVIRONMENT DIVISION. 00080000
02100 CONFIGURATION SECTION. 00090000
02110 SOURCE-COMPUTER. GNULINUX. 00100000
02120 OBJECT-COMPUTER. HERCULES. 00110000
02200 SPECIAL-NAMES. 00120000
02210 CONSOLE IS CONSL. 00130000
03000 DATA DIVISION. 00140000
04000 PROCEDURE DIVISION. 00150000
04100 00-MAIN. 00160000
04110 DISPLAY 'HELLO, WORLD' UPON CONSL. 00170000
04900 STOP RUN. 00180000
//LKED.SYSLIB DD DSNAME=SYS1.COBLIB,DISP=SHR 00190000
// DD DSNAME=SYS1.LINKLIB,DISP=SHR 00200000
//GO.SYSPRINT DD SYSOUT=A 00210000
// 00220000
After submitting the JCL, the MVS console displayed: 19.52.48 JOB 3 $HASP100 COBUCLG ON READER1 COBOL BASE TEST
19.52.48 JOB 3 IEF677I WARNING MESSAGE(S) FOR JOB COBUCLG ISSUED
19.52.48 JOB 3 $HASP373 COBUCLG STARTED - INIT 1 - CLASS A - SYS BSP1
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 Retcode
19.52.48 JOB 3 COBUCLG BASETEST COB IKFCBL00 RC= 0000
19.52.48 JOB 3 COBUCLG BASETEST LKED IEWL RC= 0000
19.52.48 JOB 3 +HELLO, WORLD
19.52.48 JOB 3 COBUCLG BASETEST GO PGM=*.DD RC= 0000
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. ReceptionLack of structureIn 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 in 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".[165] 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 structured COBOL taught well", arguing that the issue was primarily one of training.[166] One cause of spaghetti code was the COBOL programs were infamous for being monolithic and lacking modularization.[169] COBOL code could be modularized only 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.[170] Another complication stemmed from the ability to 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.[172] Further control over data and code came in 2002 when object-oriented programming, user-defined functions and user-defined data types were included. Nevertheless, much important legacy COBOL software uses unstructured code, which has become practically 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.[173] Compatibility issuesCOBOL was intended to be a highly portable, "common" language. However, by 2001, around 300 dialects had been created.[174] 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 possible variants.[175] 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.[176] 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.[177] Verbose syntaxCOBOL: /koh′bol/, n.
The Jargon File 4.4.8.[178]
COBOL syntax has often been criticized for its verbosity. Proponents say that this was intended to make the code self-documenting, easing program maintenance.[179] COBOL was also intended to be easy for programmers to learn and use,[180] while still being readable to non-technical staff such as managers.[181][182][183][184] 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[183] and the main changes in COBOL-85 were there to help ease maintenance.[93] 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.[185]
Later, 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).[187] Donald Nelson, chair of the CODASYL COBOL committee, said in 1984 that "academics ... hate COBOL" and that computer science graduates "had 'hate COBOL' drilled into them".[188] By the mid-1980s, there was also significant condescension towards COBOL in the business community from users of other languages, for example FORTRAN or assembler, implying that COBOL could be used only for non-challenging problems.[189] In 2003, COBOL featured in 80% of information systems curricula in the United States, the same proportion as C++ and Java.[190] Ten years later, a 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.[191] Concerns about the design processDoubts 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."[81] 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 evidence.[192] COBOL standards have repeatedly suffered from delays: COBOL-85 arrived five years later than hoped,[193] COBOL 2002 was five years late,[3] and COBOL 2014 was six years late.[101][194] 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.[195] Influences on other languagesCOBOL's data structures influenced subsequent programming languages. Its record and file structure influenced PL/I and Pascal, and the
COBOL's 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.[198] Additionally, the well-defined division structure restricts the definition of external references to the Environment Division, which simplifies platform changes in particular.[199] See also
Notes
ReferencesCitations
Sources
External links
COBOL at Wikipedia's sister projects
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
![{\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 \\[1em]\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}}\right|\right]\\[1em]\quad \left[\,{\underline {\text{END-ADD}}}\,\right]\end{array}}}](https://wikimedia.org/api/rest_v1/media/math/render/svg/9bace771d005c9518bae91a76654a24c7763aba9)
