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 createFOR BIT DATA
declarations automatically. To do so, specify theDCLBIT(YES)
option of theDCLGEN
command. - Performance consideration: Using the
SQLCCSID
compiler option could result in some performance overhead in SQL processing, because withSQLCCSID
in effect the default Db2 CCSID association mechanism is overridden with a mechanism that works on a per-host-variable basis.
