Particular cases of the DO and CO loops

The specific code that is written in Pacbase can contain DO and CO loops. These loops cannot be inserted like the other condition types (DW and IT for example) with the Rational® Programming Patterns subfunction creation wizard. However, they are migrated and you must know how to maintain them.

The DO loop

This loop can be indicated in a subfunction only. It runs a processing between two bounds according to a positive or negative step. The bounds are required whereas the step is optional. An index represents the subfunction code in the work areas.

This loop cannot be created in Rational Programming Patterns but it is migrated. It is represented by the Fffss subfunction, which contains the generated code of the loop, and by the associated JffssR index in the work areas. In the PDP COBOL editor and the Macro COBOL editor, it is preceded by a comment line with a *.DO annotation. The next lines contain the generated code.
Example: A DO loop is indicated in subfunction 48BD in the following way in Pacbase:
A SF LIN OPE OPERANDS                      LVTY CONDITION
  BD     N   COMPATIBILITY VERIFICATION    15DO 1 ITA00M
  BD 100 M   ZERO T-TA00-00540 (J48BDR)

When the Program that includes this DO subfunction is generated and migrated to Rational Programming Patterns, the following lines are displayed in the COBOL editor:

 *N48BD.    NOTE *COMPATIBILITY VERIFICATION         *.DO
  F48BD.
      MOVE        1                        TO J48BDR
                               GO TO     F48BD-B.
  F48BD-A.
      ADD         1                        TO J48BDR.
  F48BD-B.
      IF          J48BDR                   >  ITA00M 
                               GO TO     F48BD-FN.
      MOVE        ZERO TO T-TA00-00540 (J48BDR). 
  F48BD-900. GO TO F48BD-A. 
  F48BD-FN. EXIT.
In the work areas, the associated index is generated under 01 INDICES on the following line:
Example:
05        J48BDR PICTURE S9(4) VALUE   ZERO.
You can update the generated code of the subfunction in the following ways:
  • Modify the starting bound. This bound is displayed in the first processing line of the subfunction.
    Example:
      MOVE        1                        TO J48BDR
    In this example, 1 is the starting bound.
  • Modify the ending bound. This bound is displayed before the line that branches to the end of the subfunction.
    Example:
      IF          J48BDR                   >  ITA00M 
    In this example, ITA00M is the ending bound.
  • Modify the step, if it was indicated. The step is displayed on the line that starts with ADD or SUBTRACT.
    Example:
      ADD         1                        TO J48BDR.
    In this example, 1 is the step. It is preceded by ADD because it has a positive value.
  • Move the subfunction.
    You can copy and paste it to another location in the code. You must then replace all the references to the old subfunction code with the new subfunction code. You must also create the new JffssR index in the work areas and remove the old index from the following area:
     01   INDICES  COMPUTATIONAL  SYNC.

    You can complete these actions with the find and replace wizard. You find the old subfunction and replace it with the new code.

  • Create another DO loop.

    You can copy and paste an existing DO subfunction. However, to indicate that a processing must be run in a repetitive way, you are advised to insert the Loop insertion snippet. This snippet is available from the Snippets view, in the RPP Snippets category. This snippet inserts a PERFORM COBOL statement.

The CO loop

This loop can be indicated in a subfunction only. It runs instructions that are exclusive of one another and that depend on the possible values of a variable. Only the variable name is indicated in the CO subfunction. The instructions are described on the following lines on IT subfunctions with a lower level. The condition is the value of the variable that corresponds to each instruction.
Note: A subfunction is considered to be of a lower level if its level number is greater.
The CO loop is retrieved in Rational Programming Patterns as a CO micropattern, in Macros only. The following reasons explain this restriction:
  • The CO loop does not generate anything where it is called. It inserts the variable that is indicated in the condition on all the subfunctions with the nearest lower level.
  • The subfunctions that contain the running conditions can be located in various Macros.
Example: In Pacbase, a CO loop is indicated in the subfunction 26BB of a Macro. It is followed by IT subfunctions. In the following example, only the first IT subfunction is indicated. This IT subfunction is run if the $1-COVIL variable has a 75001 value:
A SF LIN OPE OPERANDS                      LVTY CONDITION
  BB     N   TEST ON TOWN CODE             10CO $1-COVIL
- -- --- --- ----------------------------- ---- ---------
  CB     N   75001 CASE                    15IT "75001"
  CB 100 M   "PARIS 01" $1-LIVIL
This CO loop is retrieved in Rational Programming Patterns as *!CO "$1-COVIL", where CO is a micropattern:
 F26BB
 000   *N26BB.    NOTE *TEST ON TOWN CODE            *.
       *LV=10            
 010   *!CO "$1-COVIL"
 F26CB
 000   *N26CB.   NOTE *75001 CASE                    *.
       *IT LV15
                "75001"
 100       MOVE "PARIS 01" TO $1-LIVIL 
When the Program, Screen, or Server that calls the Macro is generated, the CO micropattern is expanded and the following lines are generated in the COBOL code:
 *N26BB.    NOTE *TEST ON TOWN CODE                  *.
 *F26BB. EXIT.                                                lv10
 *N26CB.    NOTE *75001 CASE                         *.IT
  F26CB.    IF    WW00-COVIL =                                lv15
                  "75001"
            NEXT SENTENCE ELSE GO TO     F26CB-FN
      MOVE "PARIS 01" TO WW00-LIVIL.
  F26CB-900. GO TO F26BB-FN.
  F26CB-FN. EXIT. 
The CO micropattern inserts the value to be tested only on the subfunctions that have the nearest lower level in the Macro. It never modifies the specific code of the Program, Screen, or Server.
Example: In the previous example, an F26CE specific subfunction is created and the value of the $1 parameter is modified. After a new generation, the CO loop recognizes the new parameter but the F26CE specific subfunction is not modified.
 *N26BB.    NOTE *TEST ON TOWN CODE                  *.
 *F26BB. EXIT.                                                lv10
 *N26CB.    NOTE *75001 CASE                         *.IT
  F26CB.    IF    WW01-COVIL =                                lv15
                  "75001"
            NEXT SENTENCE ELSE GO TO     F26CB-FN
      MOVE "PARIS 01" TO WW01-LIVIL.
  F26CB-900. GO TO F26BB-FN.
  F26CB-FN. EXIT. 
*N26CE.    NOTE *TEST ON SPECIFIC CODE               *.IT
  F26CE.                                                      lv15
            IF    WW00-COVIL = 
                  "75004"
            NEXT SENTENCE ELSE GO TO     F26CE-FN
       MOVE "PARIS 04" TO WW00-LIVIL
  F26CE-FN. EXIT.

You can transform the dependent subfunctions of a CASE OF execution condition into an EVALUATE COBOL statement if all these subfunctions are specific. The CO loop can be written entirely with specific code (without a micropattern in this case) or can consist in a call to the CO micropattern in a Macro with all the dependent subfunctions written with specific code.

To transform a CO loop into an EVALUATE statement, open the Generated Code Structure view of the Program, Screen, or Server that calls the Macro. Right-click the subfunction that contains the CO and select Function and subfunction actions > CASE OF refactoring to EVALUATE. This choice can be selected only if the Generated language in the Definition tab of the Library of the Program, Screen, or Server is D: COBOL II, 85, LE. The variable is then tested for all the dependent subfunctions of the CO and a branching to the processing of each subfunction is added.

The following modifications are automatic:
  • In the subfunction that contains the CO, the following statements are inserted:
    • EVALUATE <variable>. In this statement, variable represents the variable that is the target of the CASE OF condition.
    • WHEN. Such a statement is inserted for each dependent subfunction. It is inserted as WHEN <value> PERFORM <Fffss> THRU <Fffss-FN>. In this line, Fffss is the code of the dependent subfunction and value is the value that is tested in this subfunction.
    • WHEN OTHER. This statement is inserted for the last dependent subfunction that processes the other cases. If this subfunction does not exist, the statement is not inserted.
    • END-EVALUATE.
    • GO TO <Fffss> -FN, where Fffss is the code of the current subfunction.
  • In the dependent subfunctions of the CO loop, the following elements are deleted:
    • IT after the subfunction title,
    • Condition lines (IF...NEXT SENTENCE ...),
    • Line -900.
Example: This example illustrates a CASE OF that is written with specific code and that includes the same subfunctions as the previous example. After reformatting, the following code is displayed in the COBOL editor:
*N26BB.    NOTE *TEST ON TOWN CODE                    *.    
 F26BB.                                                      lv10
    EVALUATE WW00-COVIL    
         WHEN ‘75001’ 
          PERFORM F26CB THRU F26CB-FN
    END-EVALUATE.          
    GO TO F26BB-FN.
*N26CB.    NOTE *75001 CASE                            *.
 F26CB.                                                      lv15
    MOVE "PARIS 01" TO WW00-LIVIL.                                                          .
 F26CB-FN. EXIT.
*F26BB. EXIT. 
The code is not transformed in the following cases:
  • The dependent subfunctions of the CASE OF come from specific code and Macros.
  • The variable that is the target of the CASE OF cannot be identified.
  • The structure of the CASE OF is not respected. Such is the case, for example, when a condition on several lines in a dependent subfunction makes it impossible to write the EVALUATE statement.
In each of these cases, a message is displayed and states the reason why the code was not transformed.

If a CASE OF micropattern is defined in a Macro and if all its dependent subfunctions are written with specific code, the code is transformed. However, the CO micropattern is irrelevant in the Macro. A warning is displayed upon the generation to inform the user.


Feedback