This technote describes limitations and known problems in the COBOL Application Model (CAM) API in the Code Review for COBOL component in IBM® Rational® Developer for System z® Version 9.0.
Resolving the problem
This technote applies to Rational Developer for System z Version 9.0 and later, except as documented in a later release.
This list does not include limitations and problems that are documented in the product help.
Part A. Limitations
Limitations are listed in the product javadoc. See the javadoc page for the top-level package, com.ibm.etools.cobol.application.model.cobol.
Part B. Known problems
1. When an EXEC statement in the procedure division occurs immediately after a completed sentence, the sentence and the EXEC statement are represented as a single sentence containing two statements. They should be represented as two sentences each containing a single statement.
2. For an ASTNode that is defined or declared outside of the ProcedureDivision, but that is used in a Statement in the ProcedureDivision, the getParent() method returns the parent node of the declaration for all instances. For example, for a MnemonicName declared in the SpecialNames paragraph, but used in an AcceptStmt, the getParent() method returns a SpecialNamesParagraph object rather than the expected AcceptStmt object.
3. When the procedure division contains a section or paragraph ending with a COPY statement, the method ProcedureDivisionContent.getContent() returns incorrect location offsets for that section or paragraph. Note: As a result, the highlighting of code review rule violations within that section or paragraph can be unpredictable.
4. INSPECT TALLYING statements with multiple TALLYING clauses are not modeled correctly:
a) Modeling of an INSPECT TALLYING statement with multiple comparands in the TALLYING clause fails. The method InspectTallyingClause.getComparands() returns a list with a single InspectTallyingLeading object. However, the expectation is that it returns a list of multiple objects, the first an InspectTallyingLeading object and the second an InspectTallyingAll object.
b) Modeling of an INSPECT TALLYING statement with multiple tallying clauses fails. InspectTallyingStmt.getClauses() method returns a list containing a single InspectTallyingClause. The expectation is that this method returns a list containing the multiple InspectTallyingClause objects.
5. Reference modifications on function references of type alphanumeric or national are not represented when the function has no parameters. For example: DISPLAY FUNCTION CURRENT-DATE (1:4).
6. If a file description entry is declared outside of a nested program but is used within the nested program, then a user-written custom rule that checks the file description entry or that checks a statement that refers to the file description entry can generate unpredictable results.
7. Code review cannot analyze a COBOL source code file containing one of the following types of statements:
a) An ENTRY statement containing USING phrases with multiple BY clauses.
b) An altered GO TO statement with no target label.
c) The following arguments of the XML GENERATE statement: XML-DECLARATION, ATTRIBUTES, NAMESPACE, and NAMESPACE-PREFIX.
d) DBCS strings.
8. The methods MergeStmt.getUsing() and MergeStmt.getGivingOrOutputProcedure() use the Java IOFiles class, which does not have location information. As a result, the highlighting of code review rule violations in a COBOL source code file can be unpredictable around lines affected by a user-written custom rule that calls these methods.