How COBClean Reformats COBOL
What We Change:
COBClean reformats your input (source) file and produces an output (cleaned) file.
The cleaned program is functionally and syntactically equivalent to the original program.
The original program is saved as a .BAK file; COBClean will not destroy it. If you don't like what COBClean does, you can always go back to your original mess.
Following is a partial list of the changes we make along the way:
- Precede each DIVISION with a separator comment for easier location. We do the same for each SECTION. The comment is an eye catching solid line of percent symbols:
*%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% |
- Comment out most of your IDENTIFICATION DIVISION, which is what the compiler does with most of it anyway. This frees you from syntax or keyword worries which have been known to fool some compilers.
- We indent your INPUT-OUTPUT SECTION entries.
- In the DATA DIVISION we separate each FD, SD or RD with a standard comment line for ease of location. This comment line looks like:
* -====- |
- We separate each significant 01 level with a similar comment line. By significant we mean one that has a data structure subordinate to it.
- Each subordinate data division level is assigned a level number that increments by 5, e.g., 05, 10, 15, etc.
- Each subordinate level is indented by an amount you specify.
- Data names and PIC clauses are aligned at standard positions.
- You can specify the column number for PIC clause alignment.
- Value clauses that won't fit on the same line as the PICTURE clause are right justified on the following line and continuation lines are handled properly.
- We get rid of 77 level items. We turn them into 01 levels. This is in keeping with future standards which classify 77 levels as an obsolete feature. In byte machines such as the PC they are functionally identical to 01 levels anyway. In mainframes, they are sometimes hard to find in a memory dump, as some compilers placed them in weird nooks and crannies of memory.
- We throw away "noise" such as commas, except in literals and PICTURE clauses.
- In the PROCEDURE DIVISION we start numbering paragraphs with a four digit number which increments by one. This number is prefaced to the descriptive paragraph name, 0001-START-UP for example. All references to this paragraph are changed. You can suppress paragraph re-numbering if desired.
- We number SECTIONS with a number that increments by 100. This means that the first paragraph in the second section will be numbered 0201-xxx.
- If you didn't precede the paragraph with a comment, we will insert a standard comment.
- We will indent your IF clauses by the same increment that we used in the DATA DIVISION. The ELSE will be aligned under the matching IF.
- We indent sentence continuations. One indent for verbs, two indents for continuations of any given verb.
- We align multiple targets (destinations) of COBOL verbs under the first target.
- You can force all targets to be aligned on a specific column if desired.
- We split sentences up so that there is only one verb per line.
- Verbs never follow a paragraph name on the same line. Nothing follows a period on the same line in the PROCEDURE DIVISION.
- We remove consecutive identical comment lines. Other than this bold step we do not mess with your comments, either by content or position.
- We allow you to choose the starting number and increment for "Line Numbers", or allow you to forego them all together.
- We allow you to uniformly translate various portions of the source code to (or from) upper case. We handle either case.
- You can standardize which type of quotation mark you will be using, or use both the single quote and double quote.
- COBClean offers a means of converting from or to the proposed new format of COBOL lines which have no sequence numbers in column 1-6.
- You may also clear or preserve the ID area (columns 73-80) as you wish. (Some programmers code the date of changes and other stuff in this area).
Other Changes:
We will never join a line to a preceding line, even if it would fit, and not violate any of our other rules. We figure that if the programmer split the line, it was for readability, and we should not change it.
Example:
MOVE ZERO TO FIXED-COST
UNIT-PRICE
SHIPPING-COST
SALVAGE-VALUE.
|
Many programmers find the above easier to read than a long list of names strung together on the same line.
We offer a means of handling the upper and lower case code that the ANSI 85 standard allows. You can convert selective portions of your program to lower case, or, if you're a traditionalist, you can force code back to the familiar upper case format.
|
