Structure of Procedure Trees

Some structures are forced upon the programmer by the logic of the program, while in other situations there is a choice to be made. In particular, you often have to choose whether to insert a new procedure below or to the right of an existing procedure.

A common arrangement is:

where * indicates a repeated procedure. Here PROC4 is not repeated, so it is most natural to insert it to the right of PROC3, not below. You could put it below and insert a suitable condition to enter so that it is executed only once, but the condition would have to be evaluated on every repetition, so you would need a good reason for doing it that way.

The variable first_item is useful if a repeating procedure includes processing which needs to be carried out only on the first pass. If in the diagram above PROC3 does a batch access for some table and PROC2 should be executed only if at least one record is found then, unless you do a preliminary search (and a database access takes longer than evaluating a condition), you have to move PROC2 to within the repeat. The procedure must be re written in the form:

Anything that was done in PROC3 apart from the database access is now deferred until PROC5, and there is a condition to enter PROC2. You could use first_item as the condition, but remember that this variable is reset each time any procedure is entered or repeated. So if there was another procedure to the left of PROC2, you would need to save the value of first_item in your own local variable in the field processing of PROC3, otherwise its value will be lost when you arrive at PROC2.

Another common structure is:

where the same condition to enter governs several procedures. The three lower procedures need not have identical conditions to enter because a further condition to enter can be applied at the lower level. PROC1 frequently has a "dummy" procedure body which does nothing (except hold the entry conditions for subsidiaries).

The root procedure for a menu option often needs a "dummy" procedure body, as in this example:

In other situations there could be more than one possible arrangement and it may not be obvious which is best.

The procedures

and

might be identical in execution, so how do you decide whether to insert PROC3 below or to the right of PROC2? Consider whether PROC2 may be used elsewhere in this or another program; remember that whatever you decide will be effective globally.

Move sideways if you want to do any of the following:

• Sometimes use PROC2 without PROC3
• Execute PROC3 even when PROC2 terminates because the user presses Escape or because no record was found
• Limit the depth of your program on the screen to make it easier to edit without needing to Zoom. Change the output device – you must start a new procedure tree for the new device
• Separate groups of associated procedures to make the program easier to understand. For example, PROC2 might be concerned with database access and updating records, while PROC3 contains procedures for displaying and printing the information
• Secure changes before doing anything else because secure changes is performed AFTER all subsidiaries have been executed

Move downwards if you want to do any of the following:

• Always use PROC3 in conjunction with PROC2
• Omit PROC3 if PROC2 is terminated by an Escape or by no record being found
• Omit PROC3 if PROC2 is terminated by deleting a record, by a checkpoint failure, or by the record not being acceptable (fails a condition on the record)
• Output to a device already selected in the previous procedure