Differences between the DB2 precompiler and the DB2 coprocessor

The DB2® precompiler and DB2 coprocessor have architectural differences. You cannot switch from one to the other without considering those differences and adjusting your program accordingly.

Recommendation: Use the coprocessor instead of the precompiler when using Unicode variables in COBOL or PL/I applications.

Depending on whether you use the DB2 precompiler or the DB2 coprocessor, ensure that you account for the following differences:

Differences in handling source CCSIDs:
The DB2 precompiler and DB2 coprocessor convert the SQL statements of your source program to UTF-8 for parsing.

The precompiler or DB2 coprocessor uses the source CCSID(n) value to convert from that CCSID to CCSID 1208 (UTF-8). The CCSID value must be an EBCDIC CCSID. If you want to prepare a source program that is written in a CCSID that cannot be directly converted to or from CCSID 1208, you must create an indirect conversion.
Differences in handling host variable CCSIDs:
- COBOL:
  DB2 precompiler:
  
  The DB2 precompiler sets CCSIDs for alphanumeric host variables only when the program includes an explicit DECLARE :hv VARIABLE statement.
  
  DB2 coprocessor:
  
  The COBOL compiler with National Character Support always sets CCSIDs for alphanumeric variables, including host variables that are used within SQL, to the source CCSID. Alternatively, you can specify that you want the COBOL DB2 coprocessor to handle CCSIDs the same way as the precompiler.
  Recommendation: If you have problems with host variable CCSIDs, use the DB2 precompiler or change your application to include the DECLARE :hv VARIABLE statement to overwrite the CCSID that is specified by the COBOL compiler.
  Example: Assume that DB2 has mapped a FOR BIT DATA column to a host variable in the following way:
```
01  hv1  pic x(5).
01  hv2  pic x(5).
 
EXEC SQL  CREATE TABLE T1 (colwbit  char(5) for bit data,  
                           rowid    char(5))   END-EXEC.

   EXEC SQL                                             
   INSERT INTO T1 VALUES (:hv1, :hv2)    
   END-EXEC.     
```
  DB2 precompiler: In the modified source from the DB2 precompiler, hv1 and hv2 are represented to DB2 through SQLDA in the following way, without CCSIDs:
```
for hv1: NO CCSID

20 SQL-PVAR-NAMEL1  PIC S9(4) COMP-4 VALUE +0.    
20 SQL-PVAR-NAMEC1  PIC X(30) VALUE ' '.         
 
for hv2:  NO CCSID

20 SQL-PVAR-NAMEL2  PIC S9(4) COMP-4 VALUE +0.    
20 SQL-PVAR-NAMEC2  PIC X(30) VALUE ' '
```
  DB2 coprocessor: In the modified source from the DB2 coprocessor with the National Character Support for COBOL, hv1 and hv2 are represented to DB2 in the following way, with CCSIDs: (Assume that the source CCSID is 1140.)
```
for hv1 and hv2, the value for CCSID is set to '1140' ('474'x) in input SQLDA 
of the INSERT statement. 

'7F00000474000000007F'x 
```
  To ensure that no discrepancy exists between the column with FOR BIT DATA and the host variable with CCSID 1140, add the following statement for :hv1 or use the DB2 precompiler:
```
EXEC SQL DECLARE : hv1 VARIABLE FOR BIT DATA END-EXEC.   

 for hv1 declared with for bit data. The value in  SQL---AVAR-NAME-DATA  is 
  set to  'FFFF'x for CCSID instead of '474x'. 

'7F0000FFFF000000007F'x  <<= with DECLARE :hv1 VARIABLE FOR BIT DATA
vs. 
'7F00000474000000007F'x   <<= without 
```
- PL/I
  DB2 coprocessor:
  
  You can specify whether CCSIDs are to be associated with host variables by using the following PL/I SQL preprocessor options:
  CCSID0
  
  Specifies that the PL/I SQL preprocessor is not to set the CCSIDs for all host variables unless they are defined with the SQL DECLARE :hv VARIABLE statement.
  
  NOCCSID0
  
  Specifies that the PL/I SQL preprocessor is to set the CCSIDs for all host variables.