Identifies the name of the code page that DB2 is currently using. To identify the code page DB2 is using, check the value of the CCSID initialization parameter in DB2.
The Codepage parameter is optional.
WARNING! If you change the DB2 CCSID setting in the DSNTIPF panel, you must also do the following to ensure LTM resumes processing at the end of the DB2 log using the proper CCSID value:
Change the values for the Replication Agent Codepage and RS_ccsid parameters in the LTMCNFG member of the hlq.JCL data set to reflect the new CCSID value.
Reset the truncation point and rs_locater values to zero. See “Basic Replication Agent troubleshooting tips” on page 81 for instructions.
The force option for the Codepage configuration parameter forces Replication Agent to use the code page value provided in the Codepage configuration parameter instead of the CCSID value provided from DB2.
Replication Agent now supports all valid DB2 CCSIDs,
including ASCII and double-byte CCSIDs, in
addition to single-byte character sets.
The utf8 option for the Codepage configuration parameter enables replication from DB2 using a Unicode character set.
Codepage=CP500,force,utf8
CP500
To determine the appropriate value for the Codepage parameter, refer to the table provided in the CODEPAGE member of the hlq.DOCS library.
Here is an excerpt of the CODEPAGE member:
|-------------------------------------------------------| | This table lists the values to use for the Rep Agent | | Codepage= and RS-ccsid= parameters. The 'DB2 CCSID' | | column lists the settings used on the DB2 installation| | panel 'DSNTIPF'. This is usually the same as the | | CCSID for the user database in which the primary table| | was created. The Rep Server/ASE column lists | | character set values. The RS_ccsid value should | | reflect the setting of Replication Server's RS_charset| | configuration parameter. | |-------------------------------------------------------| | | Rep Server/ASE | Rep Agent | Rep Agent | | DB2 CCSID | ---------------| Codepage= | RS_ccsid= | | | character set | | | |-----------|----------------|------------|-------------| | 37 | cp437 | 37 | 437 | |-----------|----------------|------------|-------------| ... ... ... ... |-----------|----------------|------------|-------------| | 500 | cp437 | 500 | 437 | |-----------|----------------|------------|-------------| | 500 | iso_1 | 500 | 819 | |-----------|----------------|------------|-------------| | 500 | cp850 | 500 | 850 | |-----------|----------------|------------|-------------| | 500 | iso15(8859-15) | 500 | 923 | |-----------|----------------|------------|-------------| ... ... ... ... |-----------|----------------|------------|-------------| | 5348 | cp1252 | 5348 | 1252 | |-----------|----------------|------------|-------------|
This table matches DB2 CCSIDs with their appropriate Replication Agent Codepage and RS_ccsid configuration parameter values.
You can verify the CCSID setting for a database by executing the following query:
SELECT * FROM SYSIBM.SYSDATABASE WHERE NAME = 'database_name'
where database_name is the name of the database for which you are verifying the CCSID setting.
You can also verify the CCSID settings for translation tables used by the LTM in character data conversions by executing the following query:
SELECT * FROM SYSIBM.SYSSTRINGS WHERE INCCSID = inccsid AND OUTCCSID = outccsid
Character translation errors can occur when the value of the Codepage parameter value does not match the code page that DB2 is currently using.
See the IBM Character Data Representation Architecture Reference and Registry, document #SC09-2190-00, for the Character Data Representation Architecture conversion tables.
To support replication with a Unicode character set, you must:
Specify the utf8 option in the LTM for MVS Codepage parameter:
Codepage=CP500,,utf8
Specify a Unicode datatype (unichar or univarchar) in the replication definition for the column in the DB2 database
WARNING! If Codepage is specified as CP500,force,utf8, then unprintable EBCDIC characters may not be replicated to char or varchar datatypes. This is not a problem when replicating to the unichar datatype.
Check for the latest EBF to address this issue (QTS #303468).