Literature Review
COBOL (common business-oriented language) is a high-level programming language for managing financial transactions in applications around the world and on all platforms.
Grace Hopper is considered the grandmother or mother of this language, although she had nothing to do with the development or design of this language. She is called this because COBOL was based on another language, FLOW-MATIC, which she was involved in creating. This language is also called B-0 or Business Language Version 0.
Reasons for the creation and the first version of COBOL, COBOL-60
It all started on May 28-29, 1959, when a meeting was held at the Pentagon to create a common programming language for business. At that time, the most popular language was FORTRAN, but it did not have the necessary functionality to be useful when writing business or financial applications.
At this meeting, 41 people participated, and they concluded that this language should be easy to learn and be applicable in various fields of activity. Starting from the financial sector and ending with inventory management in warehouses.
Later, the committee met again on June 4, 1959, and established the Committee on Data Systems Languages (CODASYL). Then the committee determined all the advantages and disadvantages of the FLOW-MATIC and COMTRAN languages and later developed COBOL based on them. Grace Hopper herself said:
COBOL (an acronym for Common Business-Oriented Language) is a programming language developed in 1959 by a working group composed of elements of the US industry and some US government agencies to create a programming language suitable for processing commercial data. Grace Murray Hopper played a primary role in the development and design of the language.
COBOL is a procedural programming language, business-oriented and with strong typing. Its syntax is verbose and descriptive, trying to approach natural language. A COBOL program is divided into four divisions: identification, environment, data and procedure.
IDENTIFICATION DIVISION.
PROGRAM-ID. COMPOUND-INTEREST.
ENVIRONMENT DIVISION.
DATA DIVISION.
WORKING-STORAGE SECTION.
01 INITIAL-AMOUNT PIC 9(5)V99 COMP-3.
01 INTEREST-RATE PIC 9(3)V9 COMP-3.
01 YEARS PIC 9(4) COMP-3.
01 FINAL-AMOUNT PIC 9(7)V99 COMP-3.
PROCEDURE DIVISION.
DISPLAY "Enter the initial amount: "
ACCEPT INITIAL-AMOUNT
DISPLAY "Enter the interest rate (as a percentage): "
ACCEPT INTEREST-RATE
DISPLAY "Enter the number of years: "
ACCEPT YEARS
MOVE INITIAL-AMOUNT TO FINAL-AMOUNT
PERFORM VARYING YEARS FROM 1 BY 1
UNTIL YEARS = 0
COMPUTE FINAL-AMOUNT = FINAL-AMOUNT * (1 + INTEREST-RATE / 100)
DISPLAY "The final amount after " YEARS " years is: " FINAL-AMOUNT
STOP RUN.Traditionally, COBOL programs were written on coding forms and then punched on to punch cards. Although nowadays most programs are entered directly into a computer, some COBOL formatting conventions remain that derive from its ancient punch-card history.
On coding forms, the first six character positions are reserved for sequence numbers. The seventh character position is reserved for the continuation character, or for an asterisk that denotes a comment line.
The actual program text starts in column 8. The four positions from 8 to 11 are known as Area A, and positions from 12 to 72 are Area B.
Although many COBOL compilers ignore some of these formatting restrictions, most still retain the distinction between Area A and Area B.
When a COBOL compiler recognizes the two areas, all division names, section names, paragraph names, FD entries and 01 level numbers must start in Area A. All other sentences must start in Area B.
In our example programs we use the compiler directive (available with the NetExpress COBOL compiler) – $ SET SOURCEFORMAT”FREE” – to free us from these formatting restrictions.
Ancient COBOL coding form
For over four decades COBOL has been the dominant programming language in the business computing domain. In that time it it has seen off the challenges of a number of other languages such as PL1, Algol68, Pascal, Modula, Ada, C, C++. All these languages have found a niche but none has yet displaced COBOL. Two recent challengers though, Java and Visual Basic, are proving to be serious contenders.
COBOL’s dominance in underlined by the reports from the Gartner group.
In 1997 they estimated that there were about 300 billion lines of computer code in use in the world. Of that they estimated that about 80% (240 billion lines) were in COBOL and 20% (60 billion lines) were written in all the other computer languages combined [Brown].
In 1999 they reported that over 50% of all new mission-critical applications were still being done in COBOL and their recent estimates indicate that through 2004-2005 15% of all new applications (5 billion lines) will be developed in COBOL while 80% of all deployed applications will include extensions to existing legacy (usually COBOL) programs.
Gartner estimates for 2002 are that there are about two million COBOL programmers world-wide compared to about about one million Java programmers and one million C++ programmers
COBOL is self-documenting
One of the design goals for COBOL was to make it possible for non-programmers such as supervisors, managers and users, to read and understand COBOL code. As a result, COBOL contains such English-like structural elements as verbs, clauses, sentences, sections and divisions. As it happens, this design goal was not realized. Managers and users nowadays do not read COBOL programs. Computer programs are just too complex for most laymen to understand them, however familiar the syntactic elements. But the design goal and its effect on COBOL syntax has had one important side-effect. It has made COBOL the most readable, understandable and self-documenting programming language in use today. It has also made it the most verbose.
It is easy for programmers unused to the business programming paradigm, where programming with a view to ease of maintenance is very important, to dismiss the advantage that COBOL’s readability imparts. Not only does this readability generally assist the maintenance process but the older a program gets the more valuable this readability becomes.
When programs are new, both the in-program comments and the external documentation accurately reflect the program code. But over time, as more and more revisions are applied to the code, it gets out of step with the documentation until the documentation is actually a hindrance to maintenance rather than a help. The self-documenting nature of COBOL means that this problem is not as severe with COBOL programs as it is with other languages
Readers who are familiar with C or C++ or Java might want to consider how difficult it becomes to maintain programs written in these languages. C programs that you have written yourself are difficult enough to understand when you come back to them six months later. Consider how much more difficult it would be to understand a program that had been written fifteen years previously, by someone else, and which had since been amended and added to by so many others that the documentation no longer accurately reflects the program code. This is a nightmare still awaiting maintenance programmers of the future
COBOL is simple
COBOL is a simple language (no pointers, no user defined functions, no user defined types) with a limited scope of function. It encourages a simple straightforward programming style. Curiously enough though, despite its limitations, COBOL has proven itself to be well suited to its targeted problem domain (business computing). Most COBOL programs operate in a domain where the program complexity lies in the business rules that have to be encoded rather than in the sophistication of the data structures or algorithms required. And in cases where sophisticated algorithms are required COBOL usually meets the need with an appropriate verb such as the SORT and the SEARCH.
We noted above that COBOL is a simple language with a limited scope of function. And that is the way it used to be but the introduction of OO-COBOL has changed all that. OO-COBOL retains all the advantages of previous versions but now includes –
User Defined Functions
Object Orientation
National Characters – Unicode
Multiple Currency Symbols
Cultural Adaptability (Locales)
Dynamic Memory Allocation (pointers)
Data Validation Using New VALIDATE Verb
Binary and Floating Point Data Types
User Defined Data Types
COBOL is non-proprietary (portable)
The COBOL standard does not belong to any particular vendor. The vendor independent ANSI COBOL committee legislates formal, non-vendor-specific syntax and semantic language standards. COBOL has been ported to virtually every hardware platform – from every favour of Windows, to every falser of Unix, to AS/400, VSE, OS/2, DOS, VMS, Unisys, DG, VM, and MVS.
COBOL is Maintainable
COBOL has a 30 year proven track record for application maintenance, enhancement and production support at the enterprise level. Early indications from the year 2000 problem are that COBOL applications were actually cheaper to fix than applications written in more recent languages. [ Capers Jones] [Kappleman]
One reason for the maintainability of COBOL programs has been given above – the readability of COBOL code. Another reason is COBOL’s rigid hierarchical structure. In COBOL programs all external references, such as to devices, files, command sequences, collating sequences, the currency symbol and the decimal point symbol, are defined in the Environment Division.
When a COBOL program is moved to a new machine, or has new peripheral devices attached, or is required to work in a different country; COBOL programmers know that the parts of the program that will have to be altered to accommodate these changes will be isolated in the Environment Division. In other programming languages, programmer discipline could have ensured that the references liable to change were restricted to one part of the program but they could just as easily be spread throughout the program. In COBOL programs, programmers have no choice. COBOL’s rigid hierarchical structure ensures that these items are restricted to the Environment Divisio
COBOL (common business-oriented language) is a high-level programming language for managing financial transactions in applications around the world and on all platforms.
Grace Hopper is considered the grandmother or mother of this language, although she had nothing to do with the development or design of this language. She is called this because COBOL was based on another language, FLOW-MATIC, which she was involved in creating. This language is also called B-0 or Business Language Version 0.
Reasons for the creation and the first version of COBOL, COBOL-60
It all started on May 28-29, 1959, when a meeting was held at the Pentagon to create a common programming language for business. At that time, the most popular language was FORTRAN, but it did not have the necessary functionality to be useful when writing business or financial applications.
At this meeting, 41 people participated, and they concluded that this language should be easy to learn and be applicable in various fields of activity. Starting from the financial sector and ending with inventory management in warehouses.
Later, the committee met again on June 4, 1959, and established the Committee on Data Systems Languages (CODASYL). Then the committee determined all the advantages and disadvantages of the FLOW-MATIC and COMTRAN languages and later developed COBOL based on them. Grace Hopper Bherself said:
COBOL (an acronym for Common Business-Oriented Language) is a programming language developed in 1959 by a working group composed of elements of the US industry and some US government agencies to create a programming language suitable for processing commercial data. Grace Murray Hopper played a primary role in the development and design of the language.
COBOL is a procedural programming language, business-oriented and with strong typing. Its syntax is verbose and descriptive, trying to approach natural language. A COBOL program is divided into four divisions: identification, environment, data and procedure.
IDENTIFICATION DIVISION.
PROGRAM-ID. COMPOUND-INTEREST.
ENVIRONMENT DIVISION.
DATA DIVISION.
WORKING-STORAGE SECTION.
01 INITIAL-AMOUNT PIC 9(5)V99 COMP-3.
01 INTEREST-RATE PIC 9(3)V9 COMP-3.
01 YEARS PIC 9(4) COMP-3.
01 FINAL-AMOUNT PIC 9(7)V99 COMP-3.
PROCEDURE DIVISION.
DISPLAY “Enter the initial amount: “
ACCEPT INITIAL-AMOUNT
DISPLAY “Enter the interest rate (as a percentage): “
ACCEPT INTEREST-RATE
DISPLAY “Enter the number of years: “
ACCEPT YEARS
MOVE INITIAL-AMOUNT TO FINAL-AMOUNT
PERFORM VARYING YEARS FROM 1 BY 1
UNTIL YEARS = 0
COMPUTE FINAL-AMOUNT = FINAL-AMOUNT * (1 + INTEREST-RATE / 100)
DISPLAY “The final amount after ” YEARS ” years is: ” FINAL-AMOUNT
STOP RUN.
Traditionally, COBOL programs were written on coding forms and then punched on to punch cards. Although nowadays most programs are entered directly into a computer, some COBOL formatting conventions remain that derive from its ancient punch-card history.
On coding forms, the first six character positions are reserved for sequence numbers. The seventh character position is reserved for the continuation character, or for an asterisk that denotes a comment line.
The actual program text starts in column 8. The four positions from 8 to 11 are known as Area A, and positions from 12 to 72 are Area B.
Although many COBOL compilers ignore some of these formatting restrictions, most still retain the distinction between Area A and Area B.
When a COBOL compiler recognizes the two areas, all division names, section names, paragraph names, FD entries and 01 level numbers must start in Area A. All other sentences must start in Area B.
In our example programs we use the compiler directive (available with the NetExpress COBOL compiler) – $ SET SOURCEFORMAT”FREE” – to free us from these formatting restrictions.
Ancient COBOL coding form
For over four decades COBOL has been the dominant programming language in the business computing domain. In that time it it has seen off the challenges of a number of other languages such as PL1, Algol68, Pascal, Modula, Ada, C, C++. All these languages have found a niche but none has yet displaced COBOL. Two recent challengers though, Java and Visual Basic, are proving to be serious contenders.
COBOL’s dominance in underlined by the reports from the Gartner group.
In 1997 they estimated that there were about 300 billion lines of computer code in use in the world. Of that they estimated that about 80% (240 billion lines) were in COBOL and 20% (60 billion lines) were written in all the other computer languages combined [Brown].
In 1999 they reported that over 50% of all new mission-critical applications were still being done in COBOL and their recent estimates indicate that through 2004-2005 15% of all new applications (5 billion lines) will be developed in COBOL while 80% of all deployed applications will include extensions to existing legacy (usually COBOL) programs.
Gartner estimates for 2002 are that there are about two million COBOL programmers world-wide compared to about about one million Java programmers and one million C++ programmers
COBOL is self-documenting
One of the design goals for COBOL was to make it possible for non-programmers such as supervisors, managers and users, to read and understand COBOL code. As a result, COBOL contains such English-like structural elements as verbs, clauses, sentences, sections and divisions. As it happens, this design goal was not realized. Managers and users nowadays do not read COBOL programs. Computer programs are just too complex for most laymen to understand them, however familiar the syntactic elements. But the design goal and its effect on COBOL syntax has had one important side-effect. It has made COBOL the most readable, understandable and self-documenting programming language in use today. It has also made it the most verbose.
It is easy for programmers unused to the business programming paradigm, where programming with a view to ease of maintenance is very important, to dismiss the advantage that COBOL’s readability imparts. Not only does this readability generally assist the maintenance process but the older a program gets the more valuable this readability becomes.
When programs are new, both the in-program comments and the external documentation accurately reflect the program code. But over time, as more and more revisions are applied to the code, it gets out of step with the documentation until the documentation is actually a hindrance to maintenance rather than a help. The self-documenting nature of COBOL means that this problem is not as severe with COBOL programs as it is with other languages
Readers who are familiar with C or C++ or Java might want to consider how difficult it becomes to maintain programs written in these languages. C programs that you have written yourself are difficult enough to understand when you come back to them six months later. Consider how much more difficult it would be to understand a program that had been written fifteen years previously, by someone else, and which had since been amended and added to by so many others that the documentation no longer accurately reflects the program code. This is a nightmare still awaiting maintenance programmers of the future
COBOL is simple
COBOL is a simple language (no pointers, no user defined functions, no user defined types) with a limited scope of function. It encourages a simple straightforward programming style. Curiously enough though, despite its limitations, COBOL has proven itself to be well suited to its targeted problem domain (business computing). Most COBOL programs operate in a domain where the program complexity lies in the business rules that have to be encoded rather than in the sophistication of the data structures or algorithms required. And in cases where sophisticated algorithms are required COBOL usually meets the need with an appropriate verb such as the SORT and the SEARCH.
We noted above that COBOL is a simple language with a limited scope of function. And that is the way it used to be but the introduction of OO-COBOL has changed all that. OO-COBOL retains all the advantages of previous versions but now includes –
User Defined Functions
Object Orientation
National Characters – Unicode
Multiple Currency Symbols
Cultural Adaptability (Locales)
Dynamic Memory Allocation (pointers)
Data Validation Using New VALIDATE Verb
Binary and Floating Point Data Types
User Defined Data Types
COBOL is non-proprietary (portable)
The COBOL standard does not belong to any particular vendor. The vendor independent ANSI COBOL committee legislates formal, non-vendor-specific syntax and semantic language standards. COBOL has been ported to virtually every hardware platform – from every favour of Windows, to every falser of Unix, to AS/400, VSE, OS/2, DOS, VMS, Unisys, DG, VM, and MVS.
COBOL is Maintainable
COBOL has a 30 year proven track record for application maintenance, enhancement and production support at the enterprise level. Early indications from the year 2000 problem are that COBOL applications were actually cheaper to fix than applications written in more recent languages. [ Capers Jones] [Kappleman]
One reason for the maintainability of COBOL programs has been given above – the readability of COBOL code. Another reason is COBOL’s rigid hierarchical structure. In COBOL programs all external references, such as to devices, files, command sequences, collating sequences, the currency symbol and the decimal point symbol, are defined in the Environment Division.
When a COBOL program is moved to a new machine, or has new peripheral devices attached, or is required to work in a different country; COBOL programmers know that the parts of the program that will have to be altered to accommodate these changes will be isolated in the Environment Division. In other programming languages, programmer discipline could have ensured that the references liable to change were restricted to one part of the program but they could just as easily be spread throughout the program. In COBOL programs, programmers have no choice. COBOL’s rigid hierarchical structure ensures that these items are restricted to the Environment Division
1.2 CONCEPT OF COMPUTER INDEPENDENT DATA DESCRIPTION
To make data as computer-independent as possible, the characteristics or properties of the data are described in relation to a standard data format rather than an equipment-oriented format. This standard data format is oriented to general data processing applications and uses the decimal system to represent numbers (regardless of the radix used by the computer) and all characters of the COBOL character set to describe nonnumeric data items .
1.3 Logical Record Concept In order to separate the logical characteristics of data from the physical characteristics of the data storage media, separate clauses or phrases are used. The following paragraphs discuss the characteristics of files.
1.4 Physical Aspects of a File The physical aspects of a file describe the data as it appears on the input or output media and include such features as: (1) The grouping of logical records within the physical limitations of the file medium. (2) The means by which the file can be identified.
1.5 Conceptual Characteristics of a File The conceptual characteristics of a file are the explicit definition of each logical entity within the file itself. In a COBOL program, the input or output statements refer to one logical record. It is important to distinguish between a physical record and a logical record.
A COBOL logical record is a group of related information, uniquely identifiable, and treated as a unit. A physical record is a physical unit of information whose size and recording mode is convenient to a particular computer for the storage of data on an input or output device. The size of a physical record is hardware dependent and bears no direct relationship to the size of the file of information contained on a device. A logical record may be contained within a s logical records may be contained within a s record may require more than one physical unit source language methods available for descr records and physical units. When a permi established, control of the accessibility of physical unit must be provided by the interacti implementor’s hardware and/or software system, records means to logical records, unless specifically used. ingle physical unit; or several ingle physical unit; or a logical to contain it. There are several the term ‘physical record’ is The concept of a logical record is over into the definition of working intc logical records and defined by a not restricted to file data but is carried storage. Thus, working storage is grouped series of record description entries .
Concept of Levels When a logical record is transferred to or from a physical unit, any translation required by the presence of a CODE-SET clause is accomplished. Padding characters are added or deleted as necessary. None of the clauses used to describe the data in the logical record have any effect on this transfer.
1.6 Record Concepts The record description consists of a set of data description entries which describe the characteristics of a particular record. Each data description entry consists of a level-number followed by a data-name, if required, followed by a series of independent clauses, as require
1.7 Concept of Levels A level concept is inherent in the structure of a logical record. This concept arises from the need to specify subdivision of a record for the purpose of data reference. Once a subdivision has been specified, it may be further subdivided to permit more detailed data referral. The most basic subdivisions of a record, that is, those not further subdivided, are called elementary items; consequently, a record is said to consist of a sequence of elementary items, or the record itself may be an elementary item. In order to refer to a set of elementary items, the elementary items are combined into groups. Each group consists of a named sequence of one or more elementary items. Groups, in turn, may be combined into groups of two or more groups, etc. Thus, an elementary item may belong to more than one group.
1.8 The File section of the Data Division describes the logical characteristics of the files, and the organization of areas used for receiving input or output data. A file comprises one or more blocks on input/output devices. A block may be described by the programmer as comprising one entity Cone logical record>, or comprising a group of smaller entities (logical records). A buffer is the area into which a block is read or from which a block is written. The descriptions of the kinds of logical records that may be contained in a block are specified in the File Section by a level 01 Record Description entry and by the entries subordinate to it. A block may contain one or more logical records, each of which may conform to any of the descriptions specified for the records in the file. The term volume is a term for a unit or reel on which a file is recorded such as a reel of magnetic tape or a disk pack. In this context, volume and the COBOL reserved words UNIT or REEL are identical in meaning.
The choice of record format, which is specified in COBOL via the RECORDING MODE clause, is dependent on the record descriptions. Files for which there is only one record description with an unchanging size
The sizes of the logical records of a file may vary
(1) if there is more than one data record description for the file so that the size of each data record described may differ or
(2) if one or more elements within the file is described with an Option 2 OCCURS clause.
In the latter case, the size of the same logical record may vary from the execution of one READ or WRITE statement of the record to the next. These files may have records of format V or format u.
1.9 GENERAL DESCRIPTION SECTION DATA DIVISION
The Data Division of a COBOL source program describes the information to be processed by the object program. This information falls into the following categories:
1. Data contained in files, entering or leaving the internal storage of the computer.
2. Data developed internally and placed in intermediate or working storage, and constant data defined by the user.
3. Linkage data descriptions for communication between main program and subprograms.
4. Report format specifications and data to be included in the report.
The Data Division begins with the header DATA DIVISION followed by a period. Each of the sections of the Data Division begins with a fixed section-name, and is followed by the word SECTION and a period, as follows: DATA DIVISION. FILE SECTION
File Description entries Record Description entries
Sort Description entries Record Description entries
Saved Area entries Record Description entries
WORKING-STORAGE SECTION. Record Description entries LINKAGE SECTION. Record Description ~1).tries REPORT SECTION. …. t (-ft..,,- 1 <~povt 0r-‘, ‘><,.) Report Description entries Report Group Description entries , Report Element Description entries >
The Record Description entries used in conjunction with a File and/or Sort Description entry describe the individual items contained in a data record of a file.
The Working-Storage Section consists solely of Record Description entries.
These entries describe the areas of storage where intermediate results are stored at object-program execution time, and constants along Ext F Only with their values.
The Linkage Section is a required part of any COBOL subprogram that contains an ENTRY statement with USING option, and serves as a data-linking mechanism between the main program and the subprogram. It consists only of Record Description entries that provide dummy names for linkage to data in the main program.
This is the only Data Division section whose entries do not cause object program data storage areas to be allocated. The Report Section describes the physical aspects of the report format and the conceptual characteristics of the data. It has three types of entries: the Report Description entry, which specifies the information pertaining to the over-all format of the named reporting the Report Group Description entry, which describes the characteristics for a report group and the Report Element Description entry, which defines the characteristics of each group or elementary item included within a report group. CONCEPTS OF DATA DESCRIPTION
FILE SECTION The File Section is used to define data that is contained in files. FILE AND RECORD HANDLING may occupy a block (i.e., a physical record).
In COBOL there are two classes of files;
1. For purposes of processing, the contents of a file are divided into logical records. It is important to note that several logical records A file description file.
2. for which subordinate there is only one 01-level record to the FD entry, called a homogeneous A file for which there is more than one 01-level record description subordinate to the FD entry, called a heterogeneous file. There are also two classes of records that may be contained in a file, fixed-length records and variable-length records.
A record is a variable-length record if it contains in its description an OCCURS clause with a DEPENDING ON option; it is fixed-length if it does not. A homogeneous file may contain either:
1. Fixed-length records, or
2. Variable-length records. A heterogeneous file may contain records with one of three different characteristics:
1. EQUAL Each of the records described is fixed in length and all the lengths are equal.
2. DIFFERING – Each of the records described is fixed in length, but at least two record descriptions have differing lengths.
3. VARIABLE – One or more of the records described is variable in length. Record Types Three record types are available to COBOL users:
1. 2. Fixed-length (Format F): can be used when all logical records in a file are the same length; may be blocked, and may use the first character to control the printer carriage or “punch stacker selection. Variable-length (Format V) : records having a count control field; may use the first character to control the printer carriage or punch stacker selection; may be blocked; may have differing or varying lengths.
3. . Undefined-length (Format U): unblocked of any length. Usually, records processed by COBOL object programs are format V records.
If the WITHOUT COUNT CONTROL portion of the RECORD CONTAINS clause is written, then either Format U or Format F records are assumed by the compiler.
The Working-Storage Section is used to describe areas of storage reserved for intermediate processing of data. This section consists of a series of Record Description entries, each of which describes an item in a work area.
Record description entries in the Linkage Section provide names and descriptions but storage within the program is not reserved, since the data exists elsewhere. Any Record Description clause may be used to describe items in the Linkage Section, with one exception: the VALUE clause may not be specified for other than level 88 items.