STRUCTURED PROGRAMMING PRACTICES - IBM Mainframe

The following specific structured programming practices are suggested:

  • To improve readability:
  • Limit paragraphs to one listing page.
  • Write paragraph and section names on separate lines.
  • Indent to show program logic.
  • Align the PICTURE clauses.
  • Put the VALUE clause on a separate line, if it is long.
  • Use in-line PERFORM statements if the paragraphs are short.
  • To end the scope of your statements, use explicit scope terminators instead of periods.
  • To be sure you have included all necessary functions, compare your code to the design documents.
  • To achieve top-down programming:
  • Avoid the PERFORM.. THRU structure unless you use the THRU option to an EXIT for a paragraph. (You should enter a program at the beginning of a paragraph and exit at its end.)
  • Avoid skipping around in the code with GO TO statements. The GO TO statement transfers control to one other paragraph, and the GO TO . . . DEPENDING ON statement transfers control to one of several different paragraphs, depending on the value of the control item you define. Errors caused by a GO TO used with DEPENDING ON are difficult to debug, because during execution, it might be difficult to determine the value the control item had at any particular time. The difference between a GO TO branch and a PERFORM is that PERFORM returns control to the statement that follows the PERFORM imperative statement. In contrast, a GO TO branches to another part of the code and stays there.
  • Avoid the ALTER statement. ALTER can be used to change the name of a paragraph to which a GO TO statement transfers control. If you must use this statement (it is not recommended that you do), keep a tally to indicate whether or not the ALTER statement has been executed. Otherwise, errors caused by the statement are difficult to debug.
  • Avoid STOP with literal. STOP with literal suspends execution temporarily and sends a message (the literal) to the system operator. This use is not recommended in an application program.

COBOL Tools for Structured Programming

VS COBOL II offers several language elements that help support a structured approach in your Procedure Division coding:

  • EVALUATE statement - Permits 'CASE' constructions.
  • In-line PERFORM statement - Permits 'DO' constructions.
  • TEST BEFORE and TEST AFTER in the PERFORM statements - Function as 'DO-WHILE' and 'DO-UNTIL' constructions.
  • Scope terminators - Permit nesting of structured programming constructions.

EVALUATE Statement

The case structure is implemented in VS COBOL II by the EVALUATE statement. For example:

EVALUATE Statement

EVALUATE Statement

In the EVALUATE statement, expressions to be tested are called selection subjects. In the example above, CARPOOL-SIZE is the selection-subject. The answer selected is called a selection-object. When evaluated, each pair of selection-subjects and selection-objects must belong to the same class (numeric, character, CONDITION TRUE or FALSE). Use the EVALUATE statement to select from a set of processing actions. Using EVALUATE, you specify a condition to be evaluated and select a processing action based on that evaluation. You can specify up to 255 evaluate subjects and objects in an EVALUATE statement. There is no limit to the number of WHEN clauses that can be specified in an EVALUATE statement, but one page is a practical limit to observe.

The preceding example of the EVALUATE statement shows that when several conditions evaluate to a range of values and each condition leads to the same processing action, you can use the THRU phrase to easily implement this logic. Alternatively, you can also use multiple WHEN statements when several conditions lead to the same processing action. Multiple WHEN statements give you more flexibility for specifying the same processing action for conditions that do not evaluate to values that fall within a range or evaluate to alphanumeric values, as shown in the following example:

evaluate to alphanumeric values

Beginning with the first WHEN phrase, the WHEN phrases are tested in the order they are coded. Therefore, you should order these phrases for optimum performance. The WHEN phrase containing selection-objects that is most likely to be satisfied should be coded first. Code the other WHEN phrases in descending order of probability of satisfaction-except the WHEN OTHER phrase, which must come last. The execution of the EVALUATE statement ends once:

  • The statements associated with the selected WHEN phrase are executed
  • The statements associated with the WHEN OTHER phrase are executed
  • No WHEN conditions are satisfied.

In-Line PERFORM Statement

The traditional out-of-line PERFORM statement requires an implicit branch o a separate paragraph and an implicit return. If the performed paragraph is in the subsequent sequential flow, it will be executed one more time. To avoid this additional execution, the paragraph is placed outside the normal sequential flow. The performed paragraph can be thought of as an internal subroutine.

In structured programming, using an in-line PERFORM statement, the paragraph performs one logical function. For readability, this paragraph should be contained on one listing page (approximately 50 lines or less). The subject of an in-line PERFORM must be an imperative statement. Therefore, statements other than imperative statements within an in-line PERFORM must be coded with their scope terminators. The choice of whether to put a PERFORM statement in-line or out-of-line depends on several factors:

  • Is it performed from several places? Use out-of-line PERFORMS when you perform the same piece of code from several places in your program.
  • Which will be easier to read? If the PERFORM is put in-line, will the logical flow of the program be less clear because the logical portions of the program flow over several pages? One use of the in-line PERFORM that would violate structured programming practices would be to let a paragraph flow over several pages. If, however, the PERFORM paragraph is short, an in-line PERFORM can save the trouble of skipping around in the listing.
  • Which makes sense, given the efficiency trade-off? An in-line PERFORM paragraph does not require branching. But remember, PERFORM coding can improve code optimization, so efficiency concerns should not be overemphasized.

TEST BEFORE or TEST AFTER Loop

The traditional COBOL PERFORM statement allowed just one type of test. The condition to terminate the 'DO LOOP' was always tested before the loop was entered. If the test condition was false, the loop was not executed even once. (In structured programming terminology, this was a 'DO-WHILE' loop.) Because you can now use the TEST BEFORE or TEST AFTER phrase with the PERFORM statement, you can choose to have your test either before the loop entry or after it. With TEST AFTER, the loop is executed the first time-regardless of the condition. TEST BEFORE corresponds to 'DO-WHILE' while TEST AFTER corresponds to 'DO-UNTIL.'

COBOL Tools for Top-Down Coding

The following tools are available to encourage top-down coding:

  • PERFORM statements for program modules - For small program modules that are not shared among programs, you can write the lower-level paragraphs as stubs. During early program development, PERFORM statements can point to these stubs.
  • Nested COPY statements - The COPY statement in VS COBOL II is extended so that you can nest COPY statements to any depth, and you can code them in any program division. You can write and debug the high-level modules of your program first. These high-level modules contain COPY statements that point to unwritten stubs that "stand in" for the lower-level code. Because COPY statements can be nested, you can code COPY statements at every code sequence level in your program. At a later stage in coding, these same COPY statements can point to the completed code sequence.
  • CALL statements - For large and complex programs, use the CALL statement to separate logically distinct portions of your program into called programs. These called subprograms are high-level modules of your application program. The CALL statement executes the subprograms. Each subprogram is a complete program within itself. You develop and code the highest-level control modules first. In these control modules you can code statements that invoke the next lower-level subprograms. These subprograms can be stubs that will later be developed into complete subprograms.

All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd DMCA.com Protection Status

IBM Mainframe Topics