Differences between the Db2 precompiler and the integrated Db2 coprocessor

There are some differences in the way certain aspects of SQL code are handled between the separate precompiler and the integrated coprocessor. View the following items to take into account these differences when you change to using the coprocessor.

Continuation lines

Precompiler: Requires that an EXEC SQL statement start in columns 12 through 72; continuation lines of the statement can start anywhere in columns 8 through 72.

Coprocessor: Requires that all lines of an EXEC SQL statement be coded in columns 12 through 72, including continuation lines.

Action to migrate to coprocessor: Move any continuation of EXEC SQL statements that start in columns 8 through 11 over to start in columns 12 through 72.

FOR BIT DATA host variables

Precompiler: A COBOL alphanumeric data item can be used as a host variable to hold Db2® character data that has subtype FOR BIT DATA. An explicit EXEC SQL DECLARE VARIABLE statement that declares the host variable in question as FOR BIT DATA is not required with the precompiler.

Coprocessor: A COBOL alphanumeric data item can be used as a host variable to hold Db2 character data having subtype FOR BIT DATA only if:

You specify the NOSQLCCSID compiler option, or
An explicit EXEC SQL DECLARE VARIABLE statement for the host variable is specified in the COBOL program. For example:
```
EXEC SQL DECLARE :HV1 VARIABLE FOR BIT DATA END-EXEC
```

If you use the Db2 DCLGEN command to generate COBOL declarations for a table, you can create the EXEC SQL DECLARE statements automatically. To do so, specify the DCLBIT(YES) option of the DCLGEN command.

Action to migrate to coprocessor:

Use DCLGEN to add the explicit EXEC SQL DECLARE VARIABLE FOR BIT DATA statement to the data declarations for any data items that are used as bit data and not just as character data.
Add the explicit EXEC SQL DECLARE VARIABLE FOR BIT DATA statement to the data declarations manually.
Use the NOSQLCCSID compiler option.

Host variables defined in the FILE SECTION

Precompiler: Only gives a warning message for a host variable defined in the File Section, even though the Db2 Application Programming and SQL Guide clearly states that this is not allowed. Here is the message that the Db2 precompiler issues:

DSNH310I W csectname LINE nnnn COL cc language HOST VARIABLE name WAS DECLARED IN FILE SECTION.

Coprocessor: Gives a severe error message for a host variable defined in the File Section. Here is the message that the Db2 coprocessor issues:

IGYPS0231-S SQL HOST VARIABLE name WAS DEFINED IN THE "FILE SECTION".

Multiple definitions of a host variable

Precompiler: Does not require host variable references to be unique.

The first definition that maps to a valid Db2 data type is used.

Coprocessor: Requires that all host variables references be unique.

If a host variable reference is not unique, the coprocessor diagnoses it as a nonunique reference. You must fully qualify the host variable reference to make it unique.

Action to migrate to coprocessor: Fully qualify any host variable references for which there are multiple definitions.

Period at the end of an EXEC SQL INCLUDE statement

Precompiler: A period is not required.

If you do specify a period, the precompiler processes it as part of the statement. If you do not specify a period, the precompiler accepts the statement as if a period were specified.

Coprocessor: A period is required. (The coprocessor treats the EXEC SQL INCLUDE statement like a COPY statement.)

Note: Periods are not required following any other EXEC SQL statements, except for EXEC SQL INCLUDE statements.

Example:

IF A = B THEN
    EXEC SQL INCLUDE somecode END-EXEC.
ELSE
    ...
END-IF

Note that the period does not terminate the IF statement.

Action to migrate to coprocessor: Add a period after every

EXEC SQL INCLUDE somecode END-EXEC

statement.

REPLACE and EXEC SQL statements

Precompiler: COBOL REPLACE statements and the REPLACING phrase of COPY statements act on the expanded source created from EXEC SQL statements.

Coprocessor: COBOL REPLACE statements and the REPLACING phrase of COPY statements act on the original source program including EXEC statements, which can result in different behavior in the following examples:


REPLACE ==ABC ==By ==XYZ ==.
01 G.
02 ABC PIC X(10).
...
EXEC SQL SELECT *INTO :G.ABC FROM TABLE1 END-EXEC

With the precompiler the reference to G.ABC will be displayed as ABC OF G in the expanded source and will be replaced with XYZ OF G. With the coprocessor, replacement will not occur because ABC is not delimited by separators in the original source string G.ABC.

Action to migrate to coprocessor: Change your code to either REPLACE the qualified references (for example G.ABC) as well as the unqualified references:


REPLACE ==ABC ==By ==XYZ ==
==G.ABC ==By ==G.XYZ ==.

Or change code so that qualification is not required, stop using REPLACE for such data items, or any other means to allow the COBOL programs changed by REPLACE to compile cleanly.

Source code that follows END-EXEC

Precompiler: Ignores any code that follows the END-EXEC on the same line.

Coprocessor: Processes the code that follows the END-EXEC on the same line.

Note: This includes a period that follows END-EXEC, so that using the integrated SQL coprocessor with SQL statements that have periods on the same line as the END-EXEC should be changed. The periods should be removed since they were ignored in the precompiler case.

Action to migrate to coprocessor: add the floating comment indicator *> after the END-EXEC phrase.

SQL-INIT-FLAG

Precompiler: If you pass host variables that might be located at different addresses when the program is called more than once, the called program must reset SQL-INIT-FLAG. Resetting this flag indicates to Db2 that storage must be initialized when the next SQL statement runs. To reset the flag, insert the statement MOVE ZERO TO SQL-INIT-FLAG in the PROCEDURE DIVISION of the called program, ahead of any executable SQL statements that use the host variables.

Coprocessor: The called program does not need to reset SQL-INIT-FLAG. An SQL-INIT-FLAG is automatically defined in the program to aid in program portability. However, statements that modify SQL-INIT-FLAG, such as MOVE ZERO TO SQL-INIT-FLAG, have no effect on the SQL processing in the program.

Action to migrate to coprocessor: Optionally remove references to SQL-INIT-FLAG, they are not used and not needed.

SYSLIB and COPY versus EXEC SQL INCLUDE

Precompiler: The precompiler has a separate SYSLIB concatenation from the compiler, so that a specific member name, like 'member1', might refer to two different members using EXEC SQL INCLUDE 'member1' during precompilation and COPY 'member1' during compilation.

Coprocessor: There is only one SYSLIB concatenation for both EXEC SQL INCLUDE statements and COPY statements. In this case, you cannot use a single name to refer to two different members.

Action to migrate to coprocessor: Rename the SQL INCLUDE member or the copybook member, and make corresponding source code changes to the SQL INCLUDE or COPY statements involved.