Rational Programming Patterns provides rules in Software
Analyzer to perform the most common controls on generated COBOL files.
Implementation
Before invoking the analysis
of the COBOL code, open the Software Analyzer Configurations dialog
to define a configuration rules set and specify the following information:
- The scope (analyze the entire workspace, a working set or one
or more selected projects).
- The COBOL rule set. You can change the severity for each rule
(recommendation, warning, or severe).
To start the analysis, right-click a selected file or
project. Select Software Analyzer and the rule
set previously defined. The Software Analyzer Results view
displays the list of the broken rules in a tree-like structure. The
first level represents the category, the second level is the rule,
and the last level lists the instances in error. To see the details
of a violation, right-click the file and select View Result .
The COBOL file opens up in the editor where the violation was detected
and the line in violation is highlighted.
After correcting the
violations and saving, you can start the analysis again to check that
all the rules are respected.
For a complete documentation on
the Software Analyzer, see the Rational Developer for System z online
help, in the COBOL Code Review item of the Developing section.
Design Entities Analysis
Software Analyzer
provides analysis support for the Rational Programming Patterns design
entities.
There are three categories of rules for this analysis:
- The All Entities category contains the
following rules:
- A non blank label is mandatory on design entities
- At least one keyword is mandatory on design entities
- The Generated Entities category contains
the following rule:
- A generated entity must have its name and external name equivalent
- The Segment Entities category includes
the following rules:
- A Segment must use only defined Data Elements
- Avoid calling the same Data Element multiple times in a Segment
Specific COBOL Code Review
Software Analyzer
provides rules that apply only to the specific code inserted by the
user in a generated COBOL program.
The Rational Programming
Patterns rules can be differentiated from the Rational Developer for
System z standard rules because they are all prefixed by RPP
/.
There are four categories of RPP rules. The Pattern
Driven Programming rules are specific and have no equivalent in Rational
Developer for System z.
However, the rules of Naming
Conventions, Performance, and Program Structures are equivalent to
the rules existing in Rational Developer for System z, but they restrict
the control to specific code portions.
- The RPP / Naming Conventions category contains
the rule 'RPP / Use a program name that matches the source file
name'.
- The RPP / Pattern Driven Programming category
includes the following rules:
- RPP / Never override a generated line.
The rule checks
that no line of generated code, including code from a Macro, is overridden.
- RPP / Never override a line coming from a Macro.
The
rule checks that no line coming from a Macro is overridden.
- RPP / User code must be in a user function.
The rule
checks that any block of specific code is inserted into a specific
function. The specific code block starts with the label FXXXX and
ends with the label FXXXX-FN.
If a specific code line is inserted into a function that is generated
or in a function that comes from a Macro, the rule is broken.
- RPP / User functions must have a non-blank comment.
The
rule checks that any function added in specific code is preceded by
a comment line that is not empty. There must be at least one character
between column 8 and column 72.
- The RPP / Performance category includes
the following rules:
- RPP / Avoid INITIALIZE statement. Use elementary MOVE statements
or VALUE clauses.
- RPP / Avoid OCCURS DEPENDING ON phrase.
- RPP / Avoid using subscripts to access a table. Use indexes.
- RPP / EXEC SQL: Avoid SELECT *.
- RPP / EXEC SQL: Use an ORDER BY clause when declaring a cursor.
- RPP / Specify 0 RECORDS for BLOCK CONTAINS clauses in file description
entries.
- RPP / Use an EVALUATE statement rather than nested IF statement.
- RPP / Use an odd number of digits in a COMP-3 or PACKED-DECIMAL
data definition
- RPP / Use binary subscripts.
- The RPP / Program Structures category
includes the following rules:
- RPP / Avoid ACCEPT statements.
- RPP / Avoid ACCEPT statements containing FROM CONSOLE or FROM
SYSIN.
- RPP / Avoid ALTER statements.
- RPP / Avoid CALL statements with a literal program name.
- RPP / Avoid CANCEL statements.
- RPP / Avoid CORRESPONDING phrases.
- RPP / Avoid DISPLAY statements containing UPON CONSOLE.
- RPP / Avoid ENTRY statements.
- RPP / Avoid EXIT PROGRAM statements.
- RPP / Avoid GO TO statements.
- RPP / Avoid GO TO statements, except those that reference an EXIT
paragraph.
- RPP / Avoid IF without ELSE
- RPP / Avoid NEXT SENTENCE phrases.
- RPP / Avoid PERFORM, except PERFORM section.
- RPP / Avoid RESERVE clauses in FILE-CONTROL paragraphs.
- RPP / Avoid STOP RUN and STOP literal statements.
- RPP / Avoid THRU phrases in PERFORM statements.
- RPP / Avoid using level-88 entries in data descriptions.
- RPP / Avoid using more than one EXIT statement per section.
- RPP / Avoid using SECTION in the procedure division.
- RPP / Avoid XML PARSE statements.
- RPP / EXEC CICS: Check EIBRESP after NOHANDLE.
- RPP / EXEC CICS: Use DFHRESP to check the return value.
- RPP / EXEC CICS: Use the RESP option.
- RPP / EXEC SQL: Check the value of SQLCODE after an EXEC SQL statement.
- RPP / Use an EXIT paragraph in each section.
- RPP / Use a WHEN OTHER phrase with an EVALUATE statement.
- RPP / Use CONTINUE rather than NEXT SENTENCE inside a scoped range.
- RPP / Use CURRENT-DATE rather than ACCEPT DATE or ACCEPT TIME.
- RPP / Use level numbers in the sequence 01, 05, 10, 15...
- RPP / Use SEARCH ALL rather than SEARCH to search a table.
- RPP / Use THRU phrases in PERFORM statements.