COBOL Programming Standards

  1. IDENTIFICATION DIVISION.

The PROGRAM-ID should be an eight character descriptive name of the program.

The AUTHOR must be the name of the student.

The date must include DATE-COMPILED.

There must be remarks divided into specific paragraphs as indicated. The paragraph titles should be displayed in column twelve with the rest of the paragraph indented for clarity.

FUNCTION. Briefly state the function of the program.

INPUT FILES. List the internal name for each file used as input, followed by its disk file name and the sort sequence (if any) of the file.

OUTPUT FILES. List the internal name for each file used for output, followed by its disk file name and the sort sequence (if any) of the file.

PRINTER OUTPUT. Describe briefly each report generated by this program, including information about control breaks.

  1. ENVIRONMENT DIVISION.

INPUT-OUTPUT SECTION. Select files by the order in which they are used.

  1. DATA DIVISION.

Insert a blank line before each 01 level number.

Level numbers.

Use non-contiguous level numbers in increments of five (05, 10, 15).

Indent each higher level number four columns or other standard number of spaces.

Indent NO FEWER than four spaces. .

PICTURE clause.

PICTURE clauses must be vertically aligned in the program.

The PICTURE of a data item should agree with its primary usage. It should be alphanumeric unless used for computation, subscription or editing. You should use Signed Numeric fields in all cases except for subscripts, counters, etc.

VALUE clauses must be vertically aligned in the program.

FILE SECTION.

Files should be defined in the same sequence as they were selected in the ENVIRONMENT DIVISION.

The file names should be descriptive of the function of the file.

Record names should be formulated to include the file description name and the word "RECORD".

Data items under the 01 level should be formulated to include a two character prefix that associates the data name with its record.

WORKING-STORAGE SECTION.

Data names should be descriptive of the function of the item.

Data names should be grouped under the 01 levels in the following order and prefixed as follows:

01 ACCUMULATORS.

Begin all data names with "A".

01 CONSTANTS.

Begin all data names with "C".

01 FLAGS.

Begin all data names with "F".

01 PRINT-LINES.

Begin all data names with "P".

01 WORK-AREAS.

Begin all data names with "W".

01 TABLES.

Begin all data names with "T".

Must be last entry in WORKING-STORAGE.

Data items that cannot logically be grouped in the above categories should be appropriately grouped and inserted in the above list in alphabetical order by the 01 level data name. (With the exception of 01 TABLES which is always the last entry.)

Data names under each 01 level should be formulated to include a two (or more, if necessary) character prefix that associates the data name with its record.

WORKING-STORAGE elementary items should NOT have initial values except for constants, look-up tables, and constant values used for print lines or screens.

There should be no Value clauses in the File Section except for 88-level entries, which we will discuss.

  1. PROCEDURE DIVISION.

General.

Use meaningful paragraph and section names. Begin each with an ascending four digit number indicating the sequence of the paragraph or section within the hierarchy chart. The number should be followed by a dash and the descriptive name, gaps should be left between numbers to facilitate program maintenance. For example:

First paragraph should be a 0000-MAIN.

This paragraph may have a ‘next level’ set of paragraphs (that it invokes (calls)) such as:

1000-INITIALIZE.

2000-COMPUTE-TAX.

3000-PRINT-REPORT.

Each paragraph is to be preceded with a Flower Box: The flower box is to contain:

a description of the function of the paragraph followed by the modules this paragraph calls followed by a listing of the modules that called this paragraph. See separate description of a Sample Program.

Start each verb on a new line. Use indentations of four spaces to the left for each continuation line of statements thatexceed one line.

PERFORMS:

PERFORM each paragraph except the driver. Don't let the program control fall through from one paragraph to the next.

You may alternately use the in-line PERFORM.

The WRITE ... FROM format should be used whenever possible. This is especially appropriate for headers, trailers, and other constant or nearly-constant records. Detailrecords should appear in the FileSection.

Use a separate line for the following:

An ELSE conditional statement

Verbs with multiple conditions:

READ INPUT-FILE

AT END

MOVE "Y" TO S-EOF-INPUT

PERFORM 3200-OUT-OF-INPUT

END-READ.

SCOPE TERMINATORS (ENDS OF PERFORM, READS, Ifs, AND SEVERAL OTHER CONSTRUCTS ARE ABSOLUTELY REQUIRED!!!

Multiple receiving fields for the same move

MOVE FIELD-A TO FIELD-B

FIELD-C.

Multiple LINKAGE areas in a USING statement

CALL "COBSUB2" USING LINK-AREA-1

LINK-AREA-2.

Multiple files OPENed or CLOSEd

OPEN INPUT INPUT-FILE

TRANSACTION-FILE

OUTPUT REPORT-FILE.

You may optionally code a series of sequential MOVE statements aligned on the word TO, as shown below:

MOVE PAGE-NUMBER TO P-HEADER-PAGE.

MOVE HEADING-LINE TO P-REPORT-LINE.

MOVE ZERO TO P-LINE-COUNT.

Literals should only be coded when the value will never need to be modified and when the significance of that value is very obvious. For example:

ADD 1 TO A-PAGE-COUNT. (Acceptable)

MULTIPLY W-BASE-PAY BY 250. (Unacceptable)

Modularity.

A paragraph must be a functionally independent unit of code.

A paragraph may not consist of a single PERFORM statement.

A paragraph has only one entry point and one exit point. .

IF.

Compound IF statements should be avoided. When their use is required, use parentheses for clarity.

Use of mixed mode (negative and positive) is discouraged. Avoid the use of a "NOT" in a compound IF statement.

The format for IF statements is the IF condition statement on one line, the action statement on the second line indented four spaces, the ELSE aligned with the IF on a separate line and the ELSE action statement on a separate line indented four spaces.

IF condition statement

action statement

ELSE

action statement

END-IF

ALL IF Statements must be properly indented and contain scope terminators.

Arithmetic statements.

Keep arithmetic statements as simple as possible.

Statements involving fields with decimals should use the ROUNDED option.

COMPUTE statements should contain parentheses to insure proper ordering of computations.

GOTO. - Notallowed in this course. But in the past:

In structured programming every effort should be made to avoid the use of the GO TO statement. If a GO TO can not be avoided the only valid uses of the GO TO are:

In a downward direction within the same paragraph or section.

To the exit of the same paragraph or section.

Older COBOL programs consisting of the performing of paragraph groups used this technique a great deal, and the use of forward-pointing GOTOs was an acceptable practice.

Output.

Page headings should appear on every page and should be centered.

Page numbers, as of dates, prepared dates, etc. will be discussed in class, as these are normally found on report headers.

The end of each report should be clearly indicated by:

A double space after the last line of the report (before the statistics, if required.)

A row of asterisks with the phrase "END OF REPORT" centered on a line.

******************END OF REPORT********************

Quality control. (may be required from time to time)

Maintain counts of all records from input files and of all record written to output files. Additional quality control information should be collected as needed (total number of errors, etc.) Print all counts at the end of each report or job process.

**********************************************************

STATISTICAL INFORMATION

**********************************************************

PERSONNEL INPUT RECORDS READ 9999

PERSONNEL OUTPUT RECORDS WRITTEN 9999

RECORDS IN ERROR 9999

Prepared by Behrooz Seyed-Abbassi, Jack Leitner, Robert F. Roggio, Diana Stewart, and Ron Zucker.

Additions, corrections, comments please email to (click to send mail)

Significantly updated on 12/30/2005 by R. Roggio.