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.
About this task
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
NOSQLCCSIDcompiler option - Specify explicit
FOR BIT DATAdeclarations for those host variables, for example:EXEC SQL DECLARE hostvariable VARIABLE FOR BIT DATA END-EXEC
Usage notes
- If you use the Db2
DCLGENcommand to generate COBOL declarations for a table, you can optionally createFOR BIT DATAdeclarations automatically. To do so, specify theDCLBIT(YES)option of theDCLGENcommand. - Performance consideration: Using the
SQLCCSIDcompiler option could result in some performance overhead in SQL processing, because withSQLCCSIDin effect the default Db2 CCSID association mechanism is overridden with a mechanism that works on a per-host-variable basis.