But understanding what is happening to the data moved into a data item is critical in COBOL. For this reason, when discussing data declarations and the assignment of values to data items, I often give a model of the storage.
For instance, Figure 2-7 gives the model of the storage for the data items declared in Example 2-9 and shows what happens to the data when you execute the statement - MOVE "19451225" TO BirthDate.
Figure 2-7. Memory model for the data items declared in Example 2-9
PROCEDURE DIVISION
The PROCEDURE DIVISION is where all the data described in the DATA DIVISION is processed and produced. It is here that you describe your algorithm. The PROCEDURE DIVISION is hierarchical in structure. It consists of sections, paragraphs, sentences, and statements. Only the section is optional; there must be at least one paragraph, one sentence, and one statement in the PROCEDURE DIVISION.
Whereas the paragraph and section names in the other divisions are defined by the language, in the PROCEDURE
DIVISION they are chosen by you. The names chosen should reflect the function of the code contained in the paragraph or section.
In many legacy COBOL programs, paragraph and section names were used chiefly as labels to break up the
program text and to act as the target of GO TO statements and, occasionally, PERFORM statements. In these programs, GO TOs were used to jump back and forward through the program text in a manner that made the program logic very difficult to follow. This programmatic style was derisively labeled spaghetti code.
In this book, I advocate a programming style that eschews the use of GO TOs as much as possible and that uses performs and paragraphs to create single-entry, single-exit, open subroutines. Although the nature of an open subroutine is that control can drop into it, adherence to the single-entry, single-exit philosophy should ensure that this does not happen.
Shortest COBOL Program
COBOL has a very bad reputation for verbosity, but most of the programs on which that reputation was built were written in ANS 68 or ANS 74 COBOL. Those programs are 40 years old. In modern versions of the language, program elements are not required unless explicitly used. For instance, in the ShortestProgram (see Listing 2-1), no entries are required for the ENVIRONMENT and DATA DIVISIONs because they are not used in this program. The IDENTIFICATION
DIVISION is required because it holds the mandatory PROGRAM-ID paragraph. The PROCEDURE DIVISION is also required, there must be at least one paragraph in it (DisplayPrompt), and the paragraph must contain at least one sentence (DISPLAY "I did it".). STOP RUN, a COBOL instruction to halt execution of the program, would normally appear in a program but is not required here because the program will stop when it reaches the end of the program text.
27
Chapter 2 ■ COBOL FOundatiOn
Listing 2-1. Shortest COBOL Program
IDENTIFICATION DIVISION.
PROGRAM-ID. ShortestProgram.
PROCEDURE DIVISION.
DisplayPrompt.
DISPLAY "I did it".
■ Note Some COBOL compilers require that all the divisions be present in a program. Others only require the IDENTIFICATION DIVISION and the PROCEDURE DIVISION.
COBOL Coding Rules
Traditionally, COBOL programs were written on coding sheets (see Figure 2-8), punched on to punch cards, and then loaded into the computer via a card reader. Although nowadays most programs are entered directly via screen and keyboard, some COBOL formatting conventions remain that derive from its ancient punch-card history:
• On the coding sheet, the first six character positions are reserved for sequence numbers.
Sequence numbers used to be a vital insurance against the disaster of dropping your stack of
punch cards.
• The seventh character position is reserved for the continuation character or for an asterisk
that denotes a comment line. The continuation character is rarely used nowadays because any
COBOL statement can be broken into two lines anywhere (other than in a quoted string) there
is a space character.
■ COBOL Detail While other programming languages permit a variety of comment forms (Java for instance supports multiline comments, documentation comments, and end of line comments) COBOL allows only full-line comments.
Comment lines are indicated by placing an asterisk in column 7 (if adhering to the strict formatting conventions - see Figure 2-8) or the the first column if using a version of COBOL that does not adhere to archaic formatting conventions.
One further note; the Open Source COBOL at Compileonline.com requires comments to begin with *> but like Java you can also place these comments at the end of the line.
Figure 2-8. Fragment of a coding sheet showing the different program areas
28
Chapter 2 ■ COBOL FOundatiOn
• The actual program text starts in column 8. The four positions from 8 to 11 are known as Area
A, and the positions from 12 to 72 are called Area B.
• The area from position 73 to 80 is the identification area; it was generally used to identify
the program. This again was disaster insurance. If two stacks of cards were dropped, the
identification allowed the cards belonging to the two programs to be identified.
When a COBOL compiler recognizes the Areas A and B, all division names, section names, paragraph names, file-description (FD) entries, and 01 level numbers must start in Area A. All other sentences must start in Area B.
In some COBOL compilers, it is possible to set a compiler option or include a compiler directive to free you from these archaic formatting conventions. For instance, the Micro Focus Net Express COBOL uses the compiler directive -
$ SET SOURCEFORMAT"FREE". Although modern compilers may free you from formatting restrictions, it is probably still a good idea to position items according to the Area A and Area B rule.
Name Construction
COBOL has a number of different user-devised names, such as data names (variable names), paragraph names,
section names, and mnemonic names. The rules for name construction are given here along with some advice which all programmers should embrace.
All user-defined names in COBOL must adhere to the following rules:
• They must contain at least 1 character and not more than 30 characters.
• They must contain at least one alphabetic character and must not begin or end with a hyphen.
• They must be constructed from the characters A to Z, the numbers 0 to 9, and the hyphen.
Because the hyphen can be mistaken for the minus sign, a word cannot begin or end with a
hyphen.
• Names are not case-sensitive. SalesDate is the same as salesDate or SALESDATE.
• None of the many COBOL reserved words may be used as a user-defined name. The huge
number of reserved words is one of the annoyances of COBOL. One strategy to avoid tripping
over them is to use word doubles such as using IterCount instead of Count.
Here are some examples of user-defined names:
TotalPay
Gross-Pay
PrintReportHeadings
Customer10-Rec
Comments about Naming
Data-item names are used to identify variables. In COBOL, all variable data is defined in the DATA DIVISION rather than throughout the program as is done in many other languages. In the PROCEDURE DIVISION, section names and paragraph names are devised by you and are used to identify blocks of executable code.
The proper selection of data-item, section, and paragraph names is probably the most important thing you can do to make your programs understandable. The names you choose should be descriptive. Data-item names should be descriptive of the data they contain; for instance, it is fairly clear what data the data items TotalPay, GrossPay, and NetPay hold. Section and paragraph names should be descriptive of the function of the code contained in
the paragraph or section; for instance, these seem fairly descriptive: ApplyValidInsertion, GetPostage, and ValidateCheckDigit. Difficulty in assigning a suitably descriptive name to a block of code should be taken as a sign that the program has been incorrectly partitioned and is likely to offend the Module Strength/Cohesion guidelines3-6.
29
Chapter 2 ■ COBOL FOundatiOn
Authors writing about other programming languages often make the same point: programmers should choose
descriptive names. But in many of these languages, where succinctness appears to be a highly lauded characteristic, the ethos of the language seems to contradict this advice. In COBOL, the language is already so verbose that the added burden of descriptive names is not likely to be a problem.
Comments about Program Formatting
In COBOL, hierarchy is vitally important in the declaration of data. Proper indentation is a very useful aid to understanding data hierarchy (more on this later). Misleading or no indentation is often a source of programming errors. Good programmers seem to understand this instinctively: when student programs are graded, those that correctly implement the specification are often found to have excellent formatting, whereas those with programming errors are often poorly formatted. This is ironic, because the programmers who are most in need of the aid of a well-formatted program seem to be those who pay formatting the least attention. Weak programmers never appear to understand how a poorly formatted program conspires against them and makes it much more difficult to produce code that works.
Proper formatting is also important in the PROCEDURE DIVISION. Even though the scope of COBOL verbs is
well-signaled using END delimiters, indentation is still a very useful aid to emphasize scope.
This discussion brings me to an important piece of advice for COBOL programmers. This advice is a restatement of the Golden Rule promulgated by Jesus, Confucius, and others:
Write your programs as you would like them written if you were the one who had to
maintain them.
Comments about Programming Style
As noted earlier, data names and reserved words are not case sensitive. The reserved words PROCEDURE DIVISION
can be written as uppercase, lowercase, or mixed case. My preference, developed during years of reading program printouts, is to put COBOL reserved words in uppercase and user-defined words in mixed case with capitals at the beginning of each word. Sometimes, for clarity, the words may be separated by a hyphen. This is the style I have chosen for this book because I believe it is the best for a printed format.
I want to stress, though, that this stylistic scheme is a personal preference. Programmers in other languages may be more used to a different scheme, and as long as the scheme is consistently used, it should present no problem. It is worth mentioning that when you start to work in a programming shop, a naming scheme may be forced on you. So perhaps it is not a bad thing to get some practice fitting in with someone else’s scheme.
Example Programs
This section provides some example programs to whet your appetite and give you a feel for how a full COBOL
program looks. In particular, they give advance warning about how variables (data items) are declared in COBOL. This differs so much from other languages such as C, Java, and Pascal that it is likely to be a matter of some concern, if not consternation. These programs also introduce some of the more interesting and useful features of COBOL.
30
Chapter 2 ■ COBOL FOundatiOn
The COBOL Greeting Program
Let’s start with the program you last saw in the COBOL coding sheet (see Figure 2-1). In Listing 2-2 it has been modernized a little by introducing lowercase characters. This basic program demonstrates simple data declaration and simple iteration (looping). The variable IterNum is given a starting value of 5, and the PERFORM executes the paragraph DisplayGreeting five times:
Listing 2-2. The COBOL Greeting Program
IDENTIFICATION DIVISION.
PROGRAM-ID. CobolGreeting.
*>Program to display COBOL greetings
DATA DIVISION.
WORKING-STORAGE SECTION.
01 IterNum PIC 9 VALUE 5.
PROCEDURE DIVISION.
BeginProgram.
PERFORM DisplayGreeting IterNum TIMES.
STOP RUN.
DisplayGreeting.
DISPLAY "Greetings from COBOL".
The DoCalc Program
The DoCalc program in Listing 2-3 prompts the user to enter two single-digit numbers. The numbers are added together, and the result is displayed on the computer screen.
Listing 2-3. The DoCalc Example Program
IDENTIFICATION DIVISION.
PROGRAM-ID. DoCalc.
AUTHOR. Michael Coughlan.
DATA DIVISION.
WORKING-STORAGE SECTION.
01 FirstNum PIC 9 VALUE ZEROS.
01 SecondNum PIC 9 VALUE ZEROS.
01 CalcResult PIC 99 VALUE 0.
01 UserPrompt PIC X(38) VALUE
"Please enter two single digit numbers".
PROCEDURE DIVISION.
CalculateResult.
DISPLAY UserPrompt
ACCEPT FirstNum
ACCEPT SecondNum
COMPUTE CalcResult = FirstNum + SecondNum
DISPLAY "Result is = ", CalcResult
STOP RUN.
31
Chapter 2 ■ COBOL FOundatiOn
The program declares three numeric data items (variables): FirstNum for the first number input, SecondNum for the second, and CalcResult to hold the result of the calculation. It also declares a data item to hold the string used to prompt the user to enter two single-digit numbers.
Data declarations in COBOL are very different from the type-based declaration you might be used to in other languages, so some explanation is required. In COBOL, every data-item declaration starts with a level number. Level numbers are used to represent data hierarchy. Because all the items in this example program are independent, elementary data items, they have a level number of 01.
Following the level number is the name of the data item, and this in turn is followed by a storage declaration for the data item. The storage declaration defines the type and size of the storage required. To do this, COBOL uses a kind of “declaration by example” strategy. An example, or picture (hence PIC), is given of the maximum value the data item can hold. The symbols used in the picture declaration indicate the basic type of the item (numeric = 9, alphanumeric
= X, alphabetic = A), and the number of symbols used indicates the size.
Consider the following declarations in DoCalc:
01 FirstNum PIC 9 VALUE ZEROS.
01 SecondNum PIC 9 VALUE ZEROS.
These indicate that FirstNum and SecondNum can each hold a cardinal number with a value between 0 and 9. If these data items were required to hold an integer number, the pictures would have to be defined as PIC S9
(signed numeric).
In this program, the picture clauses (which is what they are called) are followed by VALUE clauses specifying that FirstNum and SecondNum start with an initial value of zero. In COBOL, unless a variable is explicitly given an initial value, its value is undefined.
■ Bug Alert numeric data items must be given an explicit numeric starting value by means of the VALUE clause, using the INITIALIZE verb, or by assignment. if a numeric data item with an undefined value is used in a calculation, the program may crash. Of course, a data item with an undefined value may receive the result of a calculation because in that case any non-numeric data is overwritten with the calculation result.
The CalcResult data item is defined as follows:
01 CalcResult PIC 99 VALUE 0.
This indicates that CalcResult can hold a cardinal number between 0 and 99. It too is initialized to zero, but in this case the value 0 is used rather than the word ZEROS. The word ZEROS is a special COBOL data item called a figurative constant. It has the effect of filling the data i
tem with zeros. I have chosen to initialize this variable with the value 0 to make two points. First, numeric values can be used with the VALUE clause. Second, the figurative constant ZEROS should be used in preference to the numeric value because it is clearer than 0, which in some fonts can easily be mistaken for an O.
The UserPrompt data item is defined as follows:
01 UserPrompt PIC X(24) VALUE
"Please enter two single digit numbers".
This indicates that it can hold an alphanumeric value of up to 24 characters. It has been initialized to a starting string value.
32
Chapter 2 ■ COBOL FOundatiOn
■ COBOL Detail UserPrompt should have been defined as a constant, but COBOL does not allow constants to be created. the nearest you can get to a user-defined constant in COBOL is to assign an initial value to a data item and then not change it. this is a serious deficiency that has finally been addressed in the iSO 2002 version of COBOL by means of the CONSTANT clause.
COBOL pUZZLe
Given the description of BirthDate in example 2-10, what do you think would be displayed by the COBOL code in example 2-11?
Example 2-10. BirthDate Data Description
01 BirthDate.
02 YearOfBirth.
03 CenturyOB PIC 99.
03 YearOB PIC 99.
02 MonthOfBirth PIC 99.
02 DayOfBirth PIC 99.
Example 2-11. Code That Manipulates BirthDate and Its Subordinate Items
MOVE 19750215 TO BirthDate
DISPLAY "Month is = " MonthOfBirth
DISPLAY "Century of birth is = " CenturyOB
DISPLAY "Year of birth is = " YearOfBirth
DISPLAY DayOfBirth "/" MonthOfBirth "/" YearOfBirth
MOVE ZEROS TO YearOfBirth
DISPLAY "Birth date = " BirthDate.
the answer is at the end of the chapter.
The Condition Names Program
The final example program for this chapter previews COBOL condition names and the EVALUATE verb. A condition name is a Boolean item that can only take the value true or false. But it is much more than that. A condition name is associated (via level 88) with a particular data item. Rather than setting the condition name to true or false directly, as you might do in other languages, a condition name automatically takes the value true or false depending on the value of its associated data item.
Michael Coughlan Page 6