Programming with the SQLCCSID or NOSQLCCSID option

In general, the SQLCCSID option is recommended for new applications that use the integrated Db2® coprocessor, and as a long-term direction for existing applications. The NOSQLCCSID option is recommended as a mechanism for migrating existing precompiler-based applications to use the integrated Db2 coprocessor.

The SQLCCSID option is recommended for COBOL-Db2 applications that have any of these characteristics:

  • Use COBOL Unicode support
  • Use other COBOL syntax that is indirectly sensitive to CCSID encoding, such as XML support or object-oriented syntax for Java™ interoperability
  • Process character data that is encoded in a CCSID that is different from the default CCSID assumed by Db2

The NOSQLCCSID option is recommended for applications that require the highest compatibility with the behavior of the Db2 precompiler.

For applications that use COBOL alphanumeric data items as host variables interacting with Db2 string data that is defined with the FOR BIT DATA subtype, you must either:

  • Use the NOSQLCCSID compiler option
  • Specify explicit FOR BIT DATA declarations for those host variables, for example:
    
    EXEC SQL DECLARE hostvariable VARIABLE FOR BIT DATA END-EXEC
    

Usage notes

  • If you use the Db2 DCLGEN command to generate COBOL declarations for a table, you can optionally create FOR BIT DATA declarations automatically. To do so, specify the DCLBIT(YES) option of the DCLGEN command.
  • Performance consideration: Using the SQLCCSID compiler option could result in some performance overhead in SQL processing, because with SQLCCSID in effect the default Db2 CCSID association mechanism is overridden with a mechanism that works on a per-host-variable basis.

related concepts  
Db2 coprocessor

Start of change

End of change

related references  
SQLCCSID