Dependency Resolver must be able to detect CICS submodules

Various forms of called CICS modules all have in common that the text DFHCOMMAREA appears somewhere in the program source, without any EXEC CICS present. It usually is in the LINKAGE SECTION, the PROCEDURE DIVISION USIING clause and/or in a CALL statement.

So just scanning for that word would help us for this issue.

Two examples:

Example 1:

LINKAGE SECTION.

01 DFHCOMMAREA.

COPY P12034.

COPY P12035.

PROCEDURE DIVISION.

…..

CALL C-OJD00 USING

DFHEIBLK

DFHCOMMAREA

COPYBOOK1

ETC

Example 2:

PROCEDURE DIVISION USING

DFHEIBLK

DFHCOMMAREA

….

There is a second scanning issue, nice to have but less important: CICS EXCI (External CICS Interface) programs that run in MVS batch. Today, the DBB scanner recognizes them as CICS programs but they require a different compiler option (CICS(‘COBOL3’,‘EXCI’)) and a different deployType. The deployType gets them deployed to the Batch run libraries instead of the CICS online PGMLIB.

EXCI is more difficult to detect, because it contains EXEC CICS statements. The way we do that in our RTC scanner: if ‘ LINK’ (mind the space in front) and ‘ RETCODE’ (again a space in front) are found in that order between EXEC CICS and END-EXEC, the program is an EXCI program. LINK and RETCODE may appear on the same line as EXEC CICS or on subsequent lines. E.g.

EXEC CICS

LINK PROGRAM(….)

….

RETCODE(…)

END-EXEC

or

EXEC CICS LINK

PROGRAM(….)

….

RETCODE(…)

END-EXEC