Table of Contents

Search

  1. Preface
  2. Introduction to PowerExchange
  3. DBMOVER Configuration File
  4. Netport Jobs
  5. PowerExchange Message Logs and Destination Overrides
  6. SMF Statistics Logging and Reporting
  7. PowerExchange Security
  8. Secure Sockets Layer Support
  9. PowerExchange Alternative Network Security
  10. PowerExchange Nonrelational SQL
  11. PowerExchange Globalization
  12. Using the PowerExchange ODBC Drivers
  13. PowerExchange Datatypes and Conversion Matrix
  14. DTL__CAPXTIMESTAMP Time Stamps
  15. PowerExchange Glossary

How PowerExchange Determines Internal Code Page Numbers by Data Source

How PowerExchange Determines Internal Code Page Numbers by Data Source

PowerExchange uses internal code page numbers to uniquely identify code pages.
PowerExchange uses the internal code page numbers in many contexts, such as the following situations:
  • Exchanging control, data, and SQL code pages between the PowerExchange Listener and a calling application when processing open requests that are sent across the network.
  • Performing a SQL DTLDESCRIBE operation that processes CHAR and VARCHAR columns when importing metadata.
  • Processing an NRDB data map that defines code pages for fields and the entire map.
You can use the ICUCHECK utility to list the defined code page numbers.
The following table describes how the default internal code page numbers are derived by source or target type:
Source or Target Type
How Code Page Numbers Are Derived
DB2 on i5/OS
PowerExchange determines the internal code page number from the CCSID of the column and code page aliases.
Optionally, columns that have no CCSIDs can be mapped to CHAR columns with code pages using the optional the DB2_BIN_CODEPAGE and DB2_BIN_AS_CHAR configuration statements.
Otherwise, these columns are mapped to BIN columns and can only be processed in hexadecimal format.
DB2 on z/OS bulk data movement
For each source or target DB2 subsystem, PowerExchange determines the internal code page numbers for data columns based on the column CCSIDs and the DB2CODEPAGE statement in the DBMOVER configuration file.
  • For single-byte columns, the internal code page number is based on the CCSID of the column and the first
    sbcs_ccsid
    value in the EBCDIC_CCSID or PLAN_CCSID parameter of the DB2CODEPAGE statement.
  • For graphic double-byte columns, the internal code page number is based on the CCSID of the column and the
    graphic_ccsid
    value in the EBCDIC_CCSID or PLAN_CCSID parameter of the DB2CODEPAGE statement.
  • For mixed-byte columns, the internal code page number is based on the CCSID of the column and the
    mixed_ccsid
    value in the EBCDIC_CCSID or PLAN_CCSID parameter of the DB2CODEPAGE statement.
Nonrelational bulk data movement
PowerExchange determines the internal code page number in the following order:
  1. The code page of the field from which the column was derived. This code page and field are specified in the data map.
  2. The code page of the data map.
  3. The CODEPAGE parameter for the data control code page, on the server where the NRDB access method runs.
Nonrelational CDC
PowerExchange determines the internal code page number in the following order:
  1. The code page of the field from which the column was derived. This code page and field are specified in the data map.
  2. The code page of the data map.
  3. The CODEPAGE parameter for the data control code page, on the server where the NRDB access method runs.
PowerExchange records the code page of a field or data map in the CCT file when you create a capture registration.
Oracle bulk data movement
PowerExchange determines the internal code page number from the character set portion of the NLS_LANG environment variable.
Optionally, you can use the ORACLECODEPAGE parameter in the DBMOVER configuration file.
Oracle CDC
The PowerExchange internal code page for the columns from which changes are captured is always UTF-8.
Microsoft SQL Server
PowerExchange determines the internal code page number from the collation sequence of the database.