IBM

InfoSphere Change Data Capture

Version 6.5.0.2

IBM InfoSphere Change Data Capture

Management Console, Version 6.5.0.2
Administration Guide


IBM
InfoSphere Change Data Capture
Version 6.5.0.2

IBM InfoSphere Change Data Capture

Management Console, Version 6.5.0.2
Administration Guide


 Note
Before using this information and the product it supports, read the information in Notices on page 659.

First edition, second revision

This edition applies to version 6, release 5 of IBM InfoSphere Change Data Capture (product number 5724-U70),
version 6, release 5 of IBM InfoSphere Change Data Capture for z/OS (product number 5755-U96), and version 10,
release 1 of InfoSphere Classic Change Data Capture for z/OS (product number 5655-W29), and to all subsequent
releases and modifications until otherwise indicated in new editions.
Copyright IBM Corporation 2008, 2011.
US Government Users Restricted Rights Use, duplication or disclosure restricted by GSA ADP Schedule Contract
with IBM Corp.
Contents
Overview of InfoSphere CDC . . . . . . 1 To change the existing role on a user account . . 27
Understanding the InfoSphere CDC workflow . . . 3 To enable a System Administrator with user
account and datastore administration privileges . 27
What's new . . . . . . . . . . . . . 5 To view the history of a user account . . . . . 28
Managing security on user accounts . . . . . . 28
To disable a user account . . . . . . . . . 28
Before you start Management Console . 7 To require a user to change password at next
Configuring firewall settings for outbound (static) login . . . . . . . . . . . . . . . 28
ports . . . . . . . . . . . . . . . . . 7 To override password expiration policy set in
To configure static ports . . . . . . . . . 9 Management Console . . . . . . . . . . 29
Logging in to Management Console by connecting To unlock a user account . . . . . . . . . 29
to Access Server . . . . . . . . . . . . . 10 To unlock a system administrator user account 29
To log in to Management Consoleby connecting Setting password and account security policies on
to Access Server . . . . . . . . . . . . 10 user accounts . . . . . . . . . . . . . . 30
To change your log in password . . . . . . 11 To set complex passwords on user accounts . . 30
To enforce password history . . . . . . . . 31
Understanding the Management To enforce password expiry . . . . . . . . 31
Console interface . . . . . . . . . . 13 To enforce password locking on failed login
attempts . . . . . . . . . . . . . . 31
Setting preferences . . . . . . . . . 15 To enforce new account expiry . . . . . . . 31
To display previous failed login attempts . . . 31
Setting advanced preferences . . . . . . . . 15
To display the last successful login . . . . . 32
To set timeout values . . . . . . . . . . 16
Creating user list reports . . . . . . . . . . 32
To allocate memory for Management Console . . 16
To create a user list report . . . . . . . . 32
To add a character encoding . . . . . . . . 16
To modify a character encoding . . . . . . 16
To delete a character encoding . . . . . . . 17 Setting up datastores . . . . . . . . 33
To import the CSV template . . . . . . . . 17 Managing datastores . . . . . . . . . . . 33
To export the CSV template . . . . . . . . 18 To add a datastore . . . . . . . . . . . 34
Setting connection preferences . . . . . . . . 18 To edit a datastore . . . . . . . . . . . 34
To specify a default Access Server port number 18 To delete a datastore . . . . . . . . . . 35
To specify firewall settings for outbound (static) To copy a datastore . . . . . . . . . . . 35
ports . . . . . . . . . . . . . . . 19 To view the history of a datastore . . . . . . 35
To connect to databases automatically . . . . 19 To set connection parameters on a datastore . . 35
Setting datastore multiuser preferences . . . . . 19 Managing datastore connections . . . . . . . 36
To automatically enable multiuser configuration To delete a connection . . . . . . . . . . 37
when adding new datastores . . . . . . . 19 To override default connection parameters on a
To prompt users to log comments when datastore . . . . . . . . . . . . . . 37
unlocking subscriptions . . . . . . . . . 20 Assigning users to datastores . . . . . . . . 38
Setting prompt preferences . . . . . . . . . 20 To assign a datastore to users . . . . . . . 38
To set prompt preferences . . . . . . . . 21 To assign users to a datastore . . . . . . . 39
To automatically close progress windows . . . 21 Enabling multiple users to work simultaneously on
To show the Show Subscription Active/Edit the same datastore . . . . . . . . . . . . 40
Panel . . . . . . . . . . . . . . . 21 To enable multiple users to work with an existing
To configure filtering for databases, schemas, and datastore . . . . . . . . . . . . . . 41
tables . . . . . . . . . . . . . . . 21 Creating datastore list reports . . . . . . . . 41
Setting statistics preferences . . . . . . . . . 21 To create a datastore list report . . . . . . . 42
To set the length of time for data retention . . . 21
To set the sample rate for data collection . . . 22 Auditing user accounts, datastores,
security policies, and general events. . 43
Setting up user accounts . . . . . . . 23 Collecting data generated by user activities . . . . 43
Managing user accounts . . . . . . . . . . 23 To enable auditing . . . . . . . . . . . 44
To add a user. . . . . . . . . . . . . 24 To generate an audit trail log . . . . . . . 44
To edit a user. . . . . . . . . . . . . 25 To generate a security log report . . . . . . 44
To delete a user . . . . . . . . . . . . 26 To clear the log . . . . . . . . . . . . 45
To copy a user . . . . . . . . . . . . 26

Copyright IBM Corp. 2008, 2011 iii

Setting up and configuring
subscriptions . . . . . . . . . . . . 47
Subscriptions view (Configuration perspective) . . 48
Setting up subscriptions . . . . . . . . . . 49
To add a subscription . . . . . . . . . . 49
To modify a subscription . . . . . . . . . 50
To delete a subscription . . . . . . . . . 51
Specifying network settings for subscriptions . . . 51
To specify a TCP host for a subscription . . . . 51
To specify a firewall port for a subscription. . . 52
Setting propagation control on subscriptions . . . 52
To set propagation control on a subscription . . 52
Locking subscriptions within a datastore . . . . 52
To view subscription state details . . . . . . 53
To view subscription state details in the
Subscription Active/Edit Panel. . . . . . . 53
To lock a subscription for editing . . . . . . 53
To lock a subscription for editing in the
Subscription Active/Edit Panel. . . . . . . 54
To unlock a subscription . . . . . . . . . 54
To unlock a subscription in the Subscription
Active/Edit Panel . . . . . . . . . . . 54
To unlock a subscription (System Administrator) 54
To unlock a subscription in the Subscription
Active/Edit Panel (System Administrator) . . . 55
To view the history report for a subscription . . 55
Determining error handling for subscriptions . . . 55
To set error handling for a subscription . . . . 55
Making subscriptions persistent . . . . . . . 56
To mark a subscription as persistent . . . . . 57
Searching for tables used in replication . . . . . 57
To search for subscriptions that use a table in
replication . . . . . . . . . . . . . . 57
Setting up subscriptions for datastores outside of
your organization . . . . . . . . . . . . 58
To add a subscription for an external target
datastore . . . . . . . . . . . . . . 58
To modify a subscription for an external target
datastore . . . . . . . . . . . . . . 59
Copying subscriptions . . . . . . . . . . . 59
To copy a subscription. . . . . . . . . . 59
To copy a subscription for an external target
datastore . . . . . . . . . . . . . . 61
Upgrading existing Transformation Server
subscriptions to InfoSphere CDC . . . . . . . 62
To upgrade a subscription . . . . . . . . 63
To transfer a bookmark from the original
subscription to the upgraded subscription . . . 64
To clear the log position on the original
subscription . . . . . . . . . . . . . 64
Reverting to Transformation Server . . . . . . 65
To downgrade a subscription . . . . . . . 65
Using projects to organize your subscriptions . . . 65
To add a project . . . . . . . . . . . . 66
To rename a project. . . . . . . . . . . 66
To delete a project . . . . . . . . . . . 66
Exporting and importing projects . . . . . . . 67
To export projects . . . . . . . . . . . 67
To import projects . . . . . . . . . . . 67
iv InfoSphere Change Data Capture Management Console: Administration Guide
Setting up datastores for replication . . 69
Understanding the Datastores view . . . . . . 69
Connecting to a datastore. . . . . . . . . . 70
To connect to a datastore . . . . . . . . . 70
To disconnect from a datastore . . . . . . . 70
Shutting down a datastore . . . . . . . . . 70
To shut down a datastore. . . . . . . . . 71
Updating access parameters for a subscription. . . 71
To update access parameters for a subscription 71
Setting system parameters on source and target
datastores . . . . . . . . . . . . . . . 71
To add a system parameter . . . . . . . . 72
To modify a system parameter . . . . . . . 72
To delete a system parameter . . . . . . . 72
Creating aliases for a target datastore on a private
network connection. . . . . . . . . . . . 72
To add an alias . . . . . . . . . . . . 73
To modify an alias . . . . . . . . . . . 73
To delete an alias . . . . . . . . . . . 73
Managing tables available for
replication . . . . . . . . . . . . . 75
Updating, removing, and viewing tables for
replication . . . . . . . . . . . . . . . 75
To update the definition of a table . . . . . . 75
To remove a table from Management Console . . 76
To view the properties of a table . . . . . . 76
Updating the definition of a mapped source and
target table in a subscription. . . . . . . . . 76
To update the definition of a source table . . . 77
To update the definition of a target table . . . 77
Mapping tables . . . . . . . . . . . 79
Table Mappings view . . . . . . . . . . . 79
Understanding filtering and mapping tables . . . 82
To manually define a filter . . . . . . . . 82
Mapping using standard replication . . . . . . 83
To map similar source tables to similar target
tables (One-to-One) . . . . . . . . . . . 83
To map tables for InfoSphere Classic CDC for
z/OS . . . . . . . . . . . . . . . 85
To map a custom source table to a custom target
table (standard) . . . . . . . . . . . . 86
To map multi-member source tables on IBM i
(standard) . . . . . . . . . . . . . . 87
To map multi-member source tables to existing
target tables on IBM i (one-to-one). . . . . . 89
To map multi-member source tables to new
tables on IBM i (one-to-one) . . . . . . . . 90
Mapping using LiveAudit . . . . . . . . . 91
To map a single source table using LiveAudit . . 92
To map a multi-member table using LiveAudit
for IBM i . . . . . . . . . . . . . . 93
To map multiple source tables to existing tables
using LiveAudit . . . . . . . . . . . . 94
To map multiple source tables to new tables
using LiveAudit . . . . . . . . . . . . 95
Mapping using InfoSphere DataStage. . . . . . 96
To map a single source table to InfoSphere
DataStage using flat files . . . . . . . . . 97
 To map a single source table to InfoSphere
DataStage using Direct Connect . . . . . . 98
To map multiple source tables to InfoSphere
DataStage using flat files . . . . . . . . . 99
To map multiple source tables to InfoSphere
DataStage using Direct Connect . . . . . . 99
Generating an InfoSphere DataStage definition file
for a subscription . . . . . . . . . . . . 100
To generate an InfoSphere DataStage definition
file . . . . . . . . . . . . . . . . 102
Mapping using Adaptive Apply . . . . . . . 102
To map a source table using Adaptive Apply 102
To map a table for bulk Adaptive Apply . . . 104
To map multi-member source tables using
Adaptive Apply on IBM i . . . . . . . . 105
Mapping to summarize data . . . . . . . . 107
To map a source table to summarize data . . . 107
To map multi-member source tables using
Summarization on IBM i . . . . . . . . 108
Mapping to consolidate data (one-to-one) . . . . 110
To map a source table to consolidate data
(one-to-one) . . . . . . . . . . . . . 110
To map multi-member source tables using
Consolidation One-to-One on IBM i . . . . . 112
Mapping to consolidate data (one-to-many) . . . 113
To map a source table to consolidate data
(one-to-many) . . . . . . . . . . . . 114
To map multi-member source tables using
Consolidation one-to-many on IBM i . . . . 116
Mapping to a datastore outside of your
organization . . . . . . . . . . . . . . 117
To map tables for a subscription on an external
datastore . . . . . . . . . . . . . . 118
Mapping to a JMS Message Destination using
InfoSphere CDC Event Server . . . . . . . . 118
To map multiple source tables to a JMS message
destination . . . . . . . . . . . . . 121
To map a single source table to a JMS message
destination . . . . . . . . . . . . . 122
To stage a source table . . . . . . . . . 124
Remapping a source table . . . . . . . . . 125
To remap a source table . . . . . . . . . 125
To remap a source table (InfoSphere CDC Event
Server) . . . . . . . . . . . . . . 126
Copying selected table mappings . . . . . . . 126
To copy selected table mappings . . . . . . 126
To copy selected table mappings for an external
target datastore . . . . . . . . . . . . 127
Deleting table mappings. . . . . . . . . . 128
To delete a table mapping . . . . . . . . 128
To delete a table mapping (InfoSphere CDC
Event Server) . . . . . . . . . . . . 128
Exporting and importing subscriptions and
selected table mappings . . . . . . . . . . 129
To export a subscription into an XML file . . . 129
To export selected table mappings into an XML
file . . . . . . . . . . . . . . . . 129
To import a subscription from an XML file . . 130
Customizing InfoSphere DataStage
table mappings . . . . . . . . . . 131
Setting properties for a subscription that targets
InfoSphere DataStage. . . . . . . . . . . 131
To specify batch size thresholds for an
InfoSphere DataStage subscription . . . . . 132
To specify large object truncation size for an
InfoSphere DataStage subscription . . . . . 132
To specify the file name format for an
InfoSphere DataStage subscription . . . . . 133
To specify Direct Connect settings for an
InfoSphere DataStage subscription . . . . . 133
Understanding data types supported
by InfoSphere CDC . . . . . . . . . 135
Supported data types. . . . . . . . . . . 135
Supported column mappings . . . . . . . . 140
Mapping columns . . . . . . . . . 149
Mapping source columns to target columns . . . 149
To map a source column to a target column . . 149
Mapping journal control fields to target columns 150
To map a journal control field to a target
column . . . . . . . . . . . . . . 150
Mapping expressions to target columns . . . . 151
To map an expression to a target column . . . 151
To accumulate or deduct numeric data on a
target column . . . . . . . . . . . . 152
Mapping source and target columns automatically 152
To map columns automatically . . . . . . 152
Mapping initial values to target columns . . . . 153
To define an initial value for a target column 153
Adding and mapping derived columns to target
columns . . . . . . . . . . . . . . . 154
To add a derived column . . . . . . . . 155
To map a derived column to a target column 156
To modify a derived column . . . . . . . 156
To delete a derived column. . . . . . . . 157
Setting data translations on column
mappings . . . . . . . . . . . . . 159
Setting data translations . . . . . . . . . . 159
To add a data translation . . . . . . . . 160
To modify a data translation . . . . . . . 160
To delete a data translation . . . . . . . . 161
Importing and exporting data translations . . . . 161
To export a data translation . . . . . . . 161
To import a data translation . . . . . . . 162
Replicating multibyte (MBCS) and
double-byte (DBCS) character data . . 163
Common encoding conversion scenarios . . . . 164
Considerations when replicating MBCS character
data . . . . . . . . . . . . . . . . 165
Upgrading subscriptions to use auto-encoding
mode . . . . . . . . . . . . . . . . 166
To upgrade subscriptions to use auto-encoding
mode . . . . . . . . . . . . . . . 167
Configuring MBCS encoding conversion between
your source and target . . . . . . . . . . 167
To configure MBCS encoding conversion . . . 167
Contents v
Specifying the workload preference . . . . . . 168 Configuring table-level user exits for InfoSphere
To set the workload preference . . . . . . 169 CDC for Oracle (version 6.1 and below) or
Handling Unicode character encoding . . . . . 169 InfoSphere CDC for Sybase (version 6.1 and below) 204
To set handling for Unicode character encoding 170 To configure a C shared library . . . . . . 205
To configure a stored procedure (Oracle and
Setting member identifiers. . . . . . 171 Sybase) . . . . . . . . . . . . . . 206
Setting member identifiers for multi-member To configure a derived column or an expression
source tables . . . . . . . . . . . . . 171 that calls %STPROC (Oracle and Sybase) . . . 207
To add a member identifier. . . . . . . . 171 Configuring table-level user exits for InfoSphere
To modify a member identifier . . . . . . 172 CDC for IBM i (version 6.2 and below) or
To delete a member identifier . . . . . . . 172 InfoSphere CDC for z/OS . . . . . . . . . 207
To configure a standard function . . . . . . 207
Creating a custom data format for IBM InfoSphere
Using journal control fields for
DataStage . . . . . . . . . . . . . . 208
auditing replication activities . . . . 173 To create a custom data format for InfoSphere
About journal control fields . . . . . . . . 173 DataStage . . . . . . . . . . . . . 209
Commit Cycle ID (&CCID) . . . . . . . . 174 Configuring subscription-level user exits . . . . 209
Source RRN (&CNTRRN) . . . . . . . . 174 To configure a user exit for a subscription . . . 209
Entry Type Code (&CODE) . . . . . . . . 175 Understanding user exit configuration for
Entry Type (&ENTTYP) . . . . . . . . . 175 InfoSphere CDC Event Server . . . . . . . . 210
Source Job Name (&JOB) . . . . . . . . 176 Overriding JMS message header properties . . . 210
Source Job Number (&JOBNO) . . . . . . 176 To override JMS message header properties . . 211
Source Job User (&JOBUSER) . . . . . . . 177 Sending the XML message to a different JMS
Journal Name (&JOURNAL) . . . . . . . 178 message destination . . . . . . . . . . . 212
Source Table Library (&LIBRARY) . . . . . 179 To send the XML message to another JMS
Source Table Member Name (&MEMBER) . . . 179 message destination . . . . . . . . . . 212
Source Table Name (&OBJECT) . . . . . . 180 Creating XML output and applying XSLT to an
Source Program Name (&PROGRAM) . . . . 180 XML message . . . . . . . . . . . . . 213
Journal Sequence Number (&SEQNO) . . . . 181 To create an XML message and apply XSLT . . 214
Source Server Name (&SYSTEM) . . . . . . 182 Sending XML messages to multiple JMS message
Record Modification Time (&TIMSTAMP) . . . 182 destinations . . . . . . . . . . . . . . 215
Record Modification User (&USER) . . . . . 183 To send an XML message to a different JMS
About journal codes . . . . . . . . . . . 184 message destination . . . . . . . . . . 215
Table Clear . . . . . . . . . . . . . 184 Querying a Web service to access content . . . . 217
Delete . . . . . . . . . . . . . . . 185 To query a Web service to access content . . . 217
Insert . . . . . . . . . . . . . . . 186 Content based routing . . . . . . . . . . 218
Update Before . . . . . . . . . . . . 186 To route the content of an XML message to
Update After . . . . . . . . . . . . 186 another JMS message destination . . . . . . 219
Translating journal codes into meaningful
information . . . . . . . . . . . . . . 187
Column functions . . . . . . . . . 221
Conventions in using column functions . . . . 221
Controlling table operations . . . . . 189 String functions . . . . . . . . . . . . 222
Controlling the apply of refresh operations . . . 189 Concatenation%CONCAT . . . . . . . 222
To keep all rows on a refresh . . . . . . . 189 Lowercase%LOWER . . . . . . . . . 223
To delete all rows on a refresh. . . . . . . 190 Left trim%LTRIM . . . . . . . . . . 224
To audit rows on a refresh . . . . . . . . 190 Capitalization%PROPER . . . . . . . . 224
Specifying SQL to control refresh operations . . . 191 Character substitution%REPLACE. . . . . 225
To specify additional SQL after a refresh . . . 192 Right trim%RTRIM. . . . . . . . . . 227
To delete selected rows on a refresh . . . . . 192 Substring%SUBSTRING . . . . . . . . 228
Uppercase%UPPER . . . . . . . . . 228
Configuring user exits . . . . . . . 195 Date and time functions . . . . . . . . . . 229
Configuring table-level user exits . . . . . . . 195 Century%CENTURY . . . . . . . . . 230
To configure a stored procedure . . . . . . 196 Current date%CURDATE. . . . . . . . 231
To configure a derived column or an expression Current time%CURTIME . . . . . . . . 232
that calls %STPROC, %USER, or %USERFUNC . 197 Current timestamp%CURTMSTP . . . . . 234
To configure a user exit for a Java class. . . . 198 Conversion functions . . . . . . . . . . . 235
Configuring table-level user exits for InfoSphere Character conversion%TOCHAR . . . . . 235
CDC for Microsoft SQL Server. . . . . . . . 199 Character format conversion
To configure for IDispatch COM DLL . . . . 200 %TOCHARFORMAT . . . . . . . . . . 237
To configure for C or C++ . . . . . . . . 201 Date conversion%TODATE . . . . . . . 238
To configure a stored procedure . . . . . . 202 Date and time conversion%TODATETIME 239

vi InfoSphere Change Data Capture Management Console: Administration Guide

 Number conversion%TONUMBER . . . . 242 Transform extensions . . . . . . . . . . . 278
Time conversion%TOTIME . . . . . . . 243 sxt:add . . . . . . . . . . . . . . 279
Conditional and variable functions . . . . . . 245 sxt:db-lookup . . . . . . . . . . . . 279
Conditional%IF . . . . . . . . . . . 245 sxt:divide. . . . . . . . . . . . . . 279
Variable%VAR . . . . . . . . . . . 246 sxt:filter . . . . . . . . . . . . . . 280
Data functions . . . . . . . . . . . . . 247 sxt:formatDate . . . . . . . . . . . . 280
Before value%BEFORE . . . . . . . . 247 sxt:getSequentialNum . . . . . . . . . 281
Current value%CURR . . . . . . . . . 247 sxt:getSubField . . . . . . . . . . . . 281
Retrieve column%GETCOL (DB2 for i) . . . 249 sxt:getSysDateTime . . . . . . . . . . 281
Retrieve column%GETCOL (Dynamic SQL) 252 sxt:getSysDate . . . . . . . . . . . . 282
Retrieve column%SELECT . . . . . . . 255 sxt:getSysTime . . . . . . . . . . . . 282
User exit functions . . . . . . . . . . . 259 sxt:groupConcat . . . . . . . . . . . 282
Stored procedure%STPROC . . . . . . . 259 sxt:ifExist . . . . . . . . . . . . . . 282
User exit%USER . . . . . . . . . . 260 sxt:ifReturn . . . . . . . . . . . . . 283
User exit%USER (InfoSphere CDC for sxt:isEqual . . . . . . . . . . . . . 283
Microsoft SQL 5.x). . . . . . . . . . . 264 sxt:multiply . . . . . . . . . . . . . 283
User Exit%USERFUNC . . . . . . . . 265 sxt:nodeConcat . . . . . . . . . . . . 283
%GETCOL column function scenarios (DB2 for sxt:padLeft . . . . . . . . . . . . . 284
IBM i) . . . . . . . . . . . . . . . . 267 sxt:padRight . . . . . . . . . . . . . 284
Retrieving a column from another table using sxt:proper . . . . . . . . . . . . . 284
the %GETCOL function (DB2 for i) . . . . . 267 sxt:setDefault . . . . . . . . . . . . 285
Performing an outer join using the %GETCOL sxt:subtract . . . . . . . . . . . . . 285
function (DB2 for i) . . . . . . . . . . 268 sxt:toLowerCase . . . . . . . . . . . 285
Nesting columns to join data using the sxt:toUpperCase . . . . . . . . . . . 286
%GETCOL function (DB2 for i) . . . . . . 268 sxt:trim . . . . . . . . . . . . . . 286
Combining columns using the %GETCOL Using external Java objects in data transformations 286
function (DB2 for i) . . . . . . . . . . 268 Simple string objects (type I) . . . . . . . 286
%GETCOL column function scenarios (Dynamic SQL data types (type II) . . . . . . . . . 287
SQL) . . . . . . . . . . . . . . . . 269 XML objects (type III) . . . . . . . . . 287
Retrieving a column using the %GETCOL XPath expression operators . . . . . . . . . 287
function (Dynamic SQL). . . . . . . . . 269 + Operator . . . . . . . . . . . . . 288
Retrieving a column using the %GETCOL - Operator . . . . . . . . . . . . . 288
function without reading the same row from the * Operator . . . . . . . . . . . . . 288
table . . . . . . . . . . . . . . . 269 div Operator . . . . . . . . . . . . 288
Retrieving a column using nested %GETCOL mod Operator . . . . . . . . . . . . 288
functions (Dynamic SQL) . . . . . . . . 270 = Operator . . . . . . . . . . . . . 288
Filtering rows using the %GETCOL function != Operator . . . . . . . . . . . . . 288
(Dynamic SQL) . . . . . . . . . . . . 271 < Operator . . . . . . . . . . . . . 289
Publishing multiple derived columns using the <= Operator . . . . . . . . . . . . . 289
%GETCOL function (Dynamic SQL) . . . . . . 271 > Operator . . . . . . . . . . . . . 289
XPath functions . . . . . . . . . . . . 272 >= Operator . . . . . . . . . . . . . 289
ceiling . . . . . . . . . . . . . . . 272 or Operator . . . . . . . . . . . . . 289
concat . . . . . . . . . . . . . . . 273 and Operator . . . . . . . . . . . . 289
contains . . . . . . . . . . . . . . 273 () parentheses Operator . . . . . . . . . 289
floor . . . . . . . . . . . . . . . 273 [ ] Operator . . . . . . . . . . . . . 290
false . . . . . . . . . . . . . . . 273 / Operator . . . . . . . . . . . . . 290
formatNumber . . . . . . . . . . . . 274 // Operator . . . . . . . . . . . . . 290
normalizeSpace. . . . . . . . . . . . 274 @ Operator . . . . . . . . . . . . . 290
not . . . . . . . . . . . . . . . . 274
number . . . . . . . . . . . . . . 275 Filtering rows and columns . . . . . 291
position . . . . . . . . . . . . . . 275 Filtering rows . . . . . . . . . . . . . 291
round . . . . . . . . . . . . . . . 275 To filter rows . . . . . . . . . . . . 291
startsWith . . . . . . . . . . . . . 275 Selecting critical columns to filter rows . . . . . 292
string . . . . . . . . . . . . . . . 276 To select critical columns . . . . . . . . 292
stringLength. . . . . . . . . . . . . 276 Filtering columns . . . . . . . . . . . . 292
substring . . . . . . . . . . . . . . 276 To filter columns . . . . . . . . . . . 293
substringAfter . . . . . . . . . . . . 276
substringBefore . . . . . . . . . . . . 277
Setting conflict detection and
sum . . . . . . . . . . . . . . . 277
translate . . . . . . . . . . . . . . 277 resolution . . . . . . . . . . . . . 295
true . . . . . . . . . . . . . . . 278 Resolving conflicts for source or target wins . . . 295

Contents vii
 To resolve conflicts for source row wins . . . 296
To resolve conflicts for target row wins . . . . 297
Resolving conflicts for largest or smallest value
wins . . . . . . . . . . . . . . . . 297
To resolve conflicts for largest value wins . . . 298
To resolve conflicts for smallest value wins . . 299
Resolving conflicts with user exits . . . . . . 299
To resolve conflicts with user exit programs . . 300
Controlling row operations . . . . . 301
Suppressing the apply of row operations . . . . 301
To suppress an insert, update, or delete . . . 301
Preventing the audit of row operations . . . . . 302
To prevent row operations from being audited 302
To audit only the after image . . . . . . . 302
Detecting conflicts on row operations . . . . . 303
To detect conflicts on row operations . . . . 303
Enabling the apply of soft deletes (InfoSphere CDC
for Oracle) . . . . . . . . . . . . . . 304
To enable InfoSphere CDC for Oracle to apply a
soft delete . . . . . . . . . . . . . 304
Customizing JMS message
destination mappings . . . . . . . . 305
Creating an XML message . . . . . . . . . 305
To create an XML message . . . . . . . . 305
Importing and exporting XML files, schemas, and
mapping projects . . . . . . . . . . . . 306
To import an XML, schema, or mapping
definition file . . . . . . . . . . . . 307
To export an XML schema or mapping
definition file . . . . . . . . . . . . 307
Building an XPath expression . . . . . . . . 308
To build an XPath expression . . . . . . . 308
Querying columns from other tables. . . . . . 309
To query columns from other tables . . . . . 309
Setting JMS message header
properties . . . . . . . . . . . . . 313
Defining the JMS message header . . . . . . 313
To add a JMS message header property . . . 313
To add a custom JMS message header property 314
To delete a custom JMS message header
property . . . . . . . . . . . . . . 314
Setting general runtime options . . . . . . . 315
To enable InfoSphere CDC Event Server to trim
text . . . . . . . . . . . . . . . . 315
To disable InfoSphere CDC Event Server from
differentiating between an empty string from a
NULL value . . . . . . . . . . . . . 316
To disable streamed transformation mode . . . 316
Configuring replication . . . . . . . 317
Flagging a source table for refresh . . . . . . 317
To flag a source table for a Standard Refresh 319
To flag a source table for a Differential Refresh 320
Marking a table capture point on a source table 320
To mark a table capture point on a source table
before mirroring . . . . . . . . . . . 321
Parking a table from replication . . . . . . . 321
viii InfoSphere Change Data Capture Management Console: Administration Guide
To park a table from replication . . . . . . 321
Changing the refresh order of tables . . . . . . 321
To change the refresh order of tables . . . . 322
Changing the replication method of a table . . . 322
To change the replication method of a table . . 322
Selecting a new journal table . . . . . . . . 323
To select a new journal table . . . . . . . 324
Setting members for replication . . . . . . . 325
To select a member for replication . . . . . 325
Changing the message destination . . . . . . 325
To change the message destination of a table 325
Starting and ending replication. . . . 327
Starting mirroring . . . . . . . . . . . . 328
To start continuous mirroring . . . . . . . 329
To start scheduled end (net-change) mirroring 329
Starting a refresh on a subscription . . . . . . 330
To start a refresh . . . . . . . . . . . 332
Ending replication . . . . . . . . . . . . 332
To end replication . . . . . . . . . . . 333
Sending XML messages to a JMS message
destination . . . . . . . . . . . . . . 334
To send an XML message to a JMS message
destination or a staging target database. . . . 335
Setting notifications . . . . . . . . 337
Selecting a notification handler . . . . . . . 338
Choosing a notification category and a message
type . . . . . . . . . . . . . . . . 339
Setting notifications for a datastore . . . . . . 340
To set an e-mail (MAPI) notification . . . . . 340
To set an email (SMTP) notification . . . . . 341
To set an e-mail notification (InfoSphere CDC
for Oracle) . . . . . . . . . . . . . 341
To set an e-mail notification . . . . . . . 342
To set a notification for the CHCPRINT spool
file . . . . . . . . . . . . . . . . 342
To set a notification for an operator system log 342
To set a notification for a UNIX system log . . 343
To set a notification using a user exit program 343
To set a notification using a user exit program 343
To set a notification using a user exit program 344
To set a notification for a message queue . . . 344
To filter a notification message . . . . . . 345
Setting notifications for a subscription . . . . . 345
To set notifications for a subscription . . . . 345
To view the datastore default notifications for a
subscription . . . . . . . . . . . . . 346
Copying notifications for a subscription . . . . 346
To copy notification settings . . . . . . . 346
Setting latency thresholds and notifications . . . 346
To set a latency threshold and notification . . . 347
Promoting subscription changes . . . 349
Before you promote a subscription or selected table
mappings . . . . . . . . . . . . . . 349
Promoting subscriptions . . . . . . . . . . 350
To promote a subscription to a new subscription 351
To promote changes to an existing subscription 352
Promoting selected table mappings . . . . . . 353
 To promote selected table mappings to a new convertNotNullableColumns . . . . . . . 388
environment. . . . . . . . . . . . . 354 MirrorError . . . . . . . . . . . . . 388
To promote selected table mappings to an RefreshError. . . . . . . . . . . . . 389
existing subscription . . . . . . . . . . 356 RefreshMode . . . . . . . . . . . . 389
Database translation log system parameters . . . 390
Monitoring subscriptions . . . . . . 359 Cleanup Interval . . . . . . . . . . . 390
Subscriptions view (Monitoring perspective) . . 359 Cleanup Log Events . . . . . . . . . . 390
Understanding subscription states . . . . . . 360 Cleanup Record Count . . . . . . . . . 391
Displaying the replication diagram . . . . . . 361 LogCleanupMethod . . . . . . . . . . 392
Viewing latency for a subscription . . . . . . 362 Report Position Interval . . . . . . . . . 392
To view latency values for a subscription . . . 362 Synchronization Interval. . . . . . . . . 393
Viewing replication activity. . . . . . . . . 363 Commitment control system parameters . . . . 394
To view replication activities for a subscription 364 CommitmentControl . . . . . . . . . . 394
Viewing replication events . . . . . . . . . 364 Commit Group Size . . . . . . . . . . 395
To view events (InfoSphere CDC version 6.5 RefreshBlock . . . . . . . . . . . . 395
and later). . . . . . . . . . . . . . 366 SeparateCommits . . . . . . . . . . . 396
To retrieve events that occurred within a date Event log system parameters . . . . . . . . 396
range (InfoSphere CDC version 6.5 and later) . 366 AllowEventLogClear . . . . . . . . . . 396
To view events (InfoSphere CDC version 6.3 Multibyte character set system parameters. . . . 397
and earlier) . . . . . . . . . . . . . 367 Unicode Handling . . . . . . . . . . . 397
To view event details . . . . . . . . . . 367 Latency system parameters . . . . . . . . . 398
To copy events . . . . . . . . . . . . 368 Deadband Percentage . . . . . . . . . 398
To clear all events for the selected subscription 368 Monitor Sample Interval. . . . . . . . . 400
To clear selected events for the selected Notification system parameters . . . . . . . 400
subscription . . . . . . . . . . . . . 368 convertNotNullableMsg . . . . . . . . . 400
To export events . . . . . . . . . . . 369 DM_STATUS_INTERVAL . . . . . . . . 401
Performance view (Monitoring perspective) . . . 369 Heartbeat Timeout. . . . . . . . . . . 402
Available metrics . . . . . . . . . . . . 370 InvalidNumericMsg . . . . . . . . . . 402
Datastore metrics . . . . . . . . . . . 370 Tracing system parameters . . . . . . . . . 403
Single Scrape metrics . . . . . . . . . . 372 CommTrace . . . . . . . . . . . . . 403
Log reader metrics . . . . . . . . . . 373 ProgramTrace . . . . . . . . . . . . 404
Log parser metrics. . . . . . . . . . . 374 traceActive . . . . . . . . . . . . . 404
Source transformation engine metrics . . . . 376 TraceLevel . . . . . . . . . . . . . 404
Target transformation engine metrics . . . . 377 trcCleanup . . . . . . . . . . . . . 405
Target database metrics . . . . . . . . . 378 trcCOMM . . . . . . . . . . . . . 405
Analyzing subscription performance. . . . . . 380 trcFiles . . . . . . . . . . . . . . 405
To view bottlenecks for a subscription . . . . 381 trcFncCalls . . . . . . . . . . . . . 405
To chart metrics for a subscription . . . . . 381 trcJrlSync . . . . . . . . . . . . . . 406
To chart metrics for tables . . . . . . . . 381 trcReplStatus . . . . . . . . . . . . 406
To view the busiest tables in a subscription . . 382 trcScan . . . . . . . . . . . . . . 406
To stop table-level performance monitoring . . 382 trcSQL. . . . . . . . . . . . . . . 406
trcThread . . . . . . . . . . . . . . 406
Data type system parameters . . . . . . . . 406
System parameters for InfoSphere
TrimVarchar . . . . . . . . . . . . . 407
CDC for Microsoft SQL Server Lock detection system parameters . . . . . . 407
(version 5.3 and earlier) . . . . . . . 383 DeadlockRetrys. . . . . . . . . . . . 407
General product system parameters . . . . . . 383 DM_LOCK_DETECTION . . . . . . . . 407
AuthCode . . . . . . . . . . . . . 384 DM_LOCK_TIMEOUT . . . . . . . . . 408
DBMS . . . . . . . . . . . . . . . 384
dbUser . . . . . . . . . . . . . . 384 System Parameters for InfoSphere
dllname . . . . . . . . . . . . . . 384
CDC for Microsoft SQL Server
DSN . . . . . . . . . . . . . . . 384
NetServiceName . . . . . . . . . . . 385 (version 6.0 and later). . . . . . . . 409
pwdencrypt . . . . . . . . . . . . . 385 General product system parameters . . . . . . 409
Startup Timeout . . . . . . . . . . . 385 mirror_auto_restart_interval_minutes . . . . 409
TSSrcCP . . . . . . . . . . . . . . 386 Notification system parameters . . . . . . . 410
TSTgtCP . . . . . . . . . . . . . . 386 events_max_retain . . . . . . . . . . . 410
TCP_KEEPALIVE_SECS . . . . . . . . . 386 global_shutdown_after_no_heartbeat_response_minutes
410
WindowsAuthentication . . . . . . . . . 387 global_conversion_not_possible_warning . . . 410
Replication system parameters . . . . . . . 387 Maximize throughput system parameters . . . . 411
AutoRestart . . . . . . . . . . . . . 387 global_max_batch_size . . . . . . . . . 411

Contents ix
 mirror_interim_commit_threshold . . . . . 412
refresh_commit_after_max_operations . . . . 412
Encoding system parameters . . . . . . . . 413
global_unicode_as_char . . . . . . . . . 413
Supplemental logging system parameters . . . . 414
mirror_logging_by_empty_triggers . . . . . 414
Disk resource system parameters . . . . . . . 415
mirror_global_disk_quota_mb . . . . . . . 415
mirror_global_disk_quota_gb . . . . . . . 415
Apply process system parameters . . . . . . 416
convert_not_nullable_column . . . . . . . 416
convert_not_nullable_message . . . . . . . 417
global_default_after_database_minimum_timestamp417
global_default_before_database_minimum_timestamp
418
mirror_end_on_error . . . . . . . . . . 418
mirror_expected_errors_list . . . . . . . . 418
refresh_end_on_error . . . . . . . . . . 419
refresh_expected_errors_list . . . . . . . 419
refresh_loader_drop_index . . . . . . . . 419
refresh_with_referential_integrity . . . . . . 420
userexit_max_lob_size_kb . . . . . . . . 420
System parameters for InfoSphere
CDC for Oracle (version 6.2 and
earlier) . . . . . . . . . . . . . . 421
General product system parameters . . . . . . 421
CODE_PAGE . . . . . . . . . . . . 422
DEFAULT_ORACLE_HOME . . . . . . . 422
DEFAULT_ORACLE_SID . . . . . . . . 422
DEFAULT_ORACLE_USER . . . . . . . . 423
DM_COMMS_HOME . . . . . . . . . 423
D_MIRROR_HOME . . . . . . . . . . 423
D_MIRROR_LOG . . . . . . . . . . . 423
DM_DYNAMIC_PARAMETER_CHECK_INT 424
DM_MAX_MONITOR_ENTRIES . . . . . . 424
DM_TS_MAX_POOL_SIZE_MB . . . . . . 425
DM_TS_POOL_BLOCK_SIZE_MB . . . . . 425
<subscription>_MAX_POOL_SIZE_MB . . . . 426
<subscription>_POOL_BLOCK_SIZE_MB . . . 426
LD_LIBRARY_PATH . . . . . . . . . . 427
LIBPATH . . . . . . . . . . . . . . 427
ORACLE_HOME . . . . . . . . . . . 427
ORACLE_SID . . . . . . . . . . . . 428
PASSWORD . . . . . . . . . . . . . 428
PUBLISH_METADATA . . . . . . . . . 428
RLD_SYSTEM_TXQSIZE . . . . . . . . 429
<subscription>_TXQSIZE . . . . . . . . . 429
SHLIB_PATH . . . . . . . . . . . . 430
STARTUP_TIMEOUT. . . . . . . . . . 430
TCP_KEEPALIVE_SECS . . . . . . . . . 430
USER . . . . . . . . . . . . . . . 431
Apply process system parameters . . . . . . 431
convertNotNullableColumns . . . . . . . 432
D_MIRROR_MIRROR_ERROR_LIST. . . . . 432
D_MIRROR_MIRROR_ERROR_STOP . . . . 433
D_MIRROR_REFRESH_ERROR_LIST . . . . 433
D_MIRROR_REFRESH_ERROR_STOP . . . . 434
DM_ADAPTIVE_APPLY_SOFT_DELETES . . . 434
DM_ADAPTIVE_APPLY_<SCHEMA>.<TABLENAME> 435
DM_ADAPTIVE_APPLY_MIMIC_SOURCE_OPERATION 435
x InfoSphere Change Data Capture Management Console: Administration Guide
DM_ARRAY_BIND_MAX . . . . . . . . 436
FILTER_NOCHANGE_UPDATES_FOR_AUDIT 436
NLS_LANG . . . . . . . . . . . . . 437
NLS_NCHAR . . . . . . . . . . . . 437
NOT_NULL_DATE_DEFAULT . . . . . . 437
TRIM_CHAR_TO_VARCHAR . . . . . . . 437
TRIM_VARCHAR_TO_VARCHAR . . . . . 438
TRIM_TO_NULL . . . . . . . . . . . 438
UNICODE_HANDLING. . . . . . . . . 439
Cascading replication system parameters . . . . 440
CASCADE_OMIT_TARGETS . . . . . . . 440
PREVENT_RECURSION. . . . . . . . . 441
Database journal (trigger) system parameters . . . 441
REPORT_POSITION_INTERVAL . . . . . . 441
MONITOR_PURGE_INTERVAL . . . . . . 442
MONITOR_REFRESH_PERIOD . . . . . . 442
Maximize throughput system parameters . . . . 443
COMMIT_GROUP_SIZE. . . . . . . . . 443
COMMIT_LEVEL . . . . . . . . . . . 444
COMMIT_INTERVAL . . . . . . . . . 444
MAINTAIN_TRANSACTION_CONSISTENCY 445
SYNCHRONIZATION_COMMIT_
GROUP_SIZE . . . . . . . . . . . . 445
SYNCHRONIZATION_INTERVAL . . . . . 446
TRANSACTION_GROUP_SIZE . . . . . . 446
TRANSACTION_INTERVAL . . . . . . . 447
TRANSACTION_RECORDS_THRESHOLD . . 447
Tracing system parameters . . . . . . . . . 448
D_MIRROR_SP_TRACE . . . . . . . . . 448
D_MIRROR_TRACE . . . . . . . . . . 448
D_MIRROR_TRACE_FILE_SIZE . . . . . . 449
D_MIRROR_TRACE_ON_ERROR . . . . . 449
DM_PRINT_DIAGNOSTICS . . . . . . . 450
D_MIRROR_ALARM_TRACE . . . . . . . 450
Refresh loader system parameters . . . . . . 451
DIRPATH_BUF_ROWS . . . . . . . . . 451
DIRPATH_BUF_SIZE . . . . . . . . . . 452
DIRPATH_CACHE_DATE_SIZE . . . . . . 453
DIRPATH_LOAD . . . . . . . . . . . 453
DIRPATH_LOGGING . . . . . . . . . 454
DIRPATH_DO_RECOVERY. . . . . . . . 454
User exit system parameters . . . . . . . . 455
D_MIRROR_SP_CONNECTION . . . . . . 455
DM_FROM_CODEPAGE_V4USEREXIT. . . . 455
DM_TO_CODEPAGE_V4USEREXIT . . . . . 456
Table mapping system parameters . . . . . . 456
TS_DELETE_ASSIGNED_OBJECTS_DURING_DESCRIBE 456
Notification system parameters . . . . . . . 457
convertNotNullableMsg . . . . . . . . . 457
DEADBAND_PERCENTAGE . . . . . . . 458
DM_STATUS_INTERVAL . . . . . . . . 459
HEARTBEAT_TIMEOUT . . . . . . . . 460
LOG_EMAIL_USERNAME . . . . . . . . 460
MONITOR_SAMPLE_INTERVAL. . . . . . 461
STATISTICS_INTERVAL . . . . . . . . . 461
Disk resource system parameters . . . . . . . 462
LOG_MAX_SIZE . . . . . . . . . . . 462
System parameters for InfoSphere
CDC for Oracle (version 6.3 and later) . 463
General product system parameters . . . . . . 463
 mirror_auto_restart_interval_minutes . . . . 463 Disk resource system parameters . . . . . . . 485
mirror_set_table_data_capture_timeout . . . . 464 mirror_global_disk_quota_mb . . . . . . . 485
Transaction log location system parameters . . . 464 mirror_global_disk_quota_gb . . . . . . . 486
mirror_archive_log_directory . . . . . . . 464 Apply process system parameters . . . . . . 486
mirror_asm_oracle_path . . . . . . . . . 464 convert_not_nullable_column . . . . . . . 487
mirror_online_log_directory . . . . . . . 465 convert_not_nullable_message . . . . . . . 487
oracle_archive_dir . . . . . . . . . . . 465 global_max_batch_size . . . . . . . . . 488
oracle_archive_destination_id . . . . . . . 465 mirror_end_on_error . . . . . . . . . . 488
oracle_archive_logs_only . . . . . . . . 466 mirror_expected_errors_list . . . . . . . . 488
oracle_log_path_userexit. . . . . . . . . 466 refresh_end_on_error . . . . . . . . . . 489
oracle_log_shipping . . . . . . . . . . 466 refresh_expected_errors_list . . . . . . . 489
oracle_using_log_transport_services . . . . . 467 refresh_in_unicode . . . . . . . . . . 490
Notification system parameters . . . . . . . 468 refresh_with_referential_integrity . . . . . . 490
events_max_retain . . . . . . . . . . . 468 trim_char_to_varchar . . . . . . . . . . 490
global_conversion_not_possible_warning . . . 469 trim_varchar_to_varchar. . . . . . . . . 491
global_shutdown_after_no_heartbeat_response_minutes
469 userexit_max_lob_size_queue_kb . . . . . . 491
Maximize throughput system parameters . . . . 469
mirror_interim_commit_threshold . . . . . 470 System parameters for InfoSphere
mirror_sess_hist_age_threshold . . . . . . 470 CDC for Sybase (version 6.0 and
mirror_src_ora_version . . . . . . . . . 471
refresh_commit_after_max_operations . . . . 471
earlier) . . . . . . . . . . . . . . 493
userexit_max_lob_size_kb . . . . . . . . 471 General product system parameters . . . . . . 493
Encoding system parameters . . . . . . . . 472 CODE_PAGE . . . . . . . . . . . . 494
global_unicode_as_char . . . . . . . . . 472 D_MIRROR_HOME . . . . . . . . . . 494
Disk resource system parameters . . . . . . . 473 D_MIRROR_LOG . . . . . . . . . . . 494
mirror_global_disk_quota_mb . . . . . . . 473 DM_DYNAMIC_PARAMETER_CHECK_INT 494
mirror_global_disk_quota_gb . . . . . . . 474 DM_MAX_MONITOR_ENTRIES . . . . . . 495
staging_store_can_run_independently . . . . 474 DSQUERY . . . . . . . . . . . . . 495
staging_store_disk_quota_gb . . . . . . . 475 LD_LIBRARY_PATH . . . . . . . . . . 496
staging_store_disk_quota_mb . . . . . . . 475 LIBPATH . . . . . . . . . . . . . . 496
Apply process system parameters . . . . . . 475 PUBLISH_METADATA . . . . . . . . . 496
convert_not_nullable_column . . . . . . . 476 SYBASE . . . . . . . . . . . . . . 497
convert_not_nullable_message . . . . . . . 476 SYBASE_OCS . . . . . . . . . . . . 497
global_max_batch_size . . . . . . . . . 477 SHLIB_PATH . . . . . . . . . . . . 497
mirror_end_on_error . . . . . . . . . . 477 STARTUP_TIMEOUT. . . . . . . . . . 497
mirror_expected_errors_list . . . . . . . . 477 USER . . . . . . . . . . . . . . . 498
refresh_end_on_error . . . . . . . . . . 478 Apply process system parameters . . . . . . 498
refresh_expected_errors_list . . . . . . . 478 convertNotNullableColumns . . . . . . . 498
refresh_in_unicode . . . . . . . . . . 479 D_MIRROR_MIRROR_ERROR_STOP . . . . 499
refresh_with_referential_integrity . . . . . . 479 D_MIRROR_REFRESH_ERROR_STOP . . . . 499
trim_char_to_varchar . . . . . . . . . . 479 FILTER_NOCHANGE_UPDATES_FOR_AUDIT 500
trim_varchar_to_varchar. . . . . . . . . 480 NLS_LANG . . . . . . . . . . . . . 500
userexit_max_lob_size_kb . . . . . . . . 480 TRANSACTION_GROUP_SIZE . . . . . . 500
TRANSACTION_INTERVAL . . . . . . . 501
TRANSACTION_RECORDS_THRESHOLD . . 502
System parameters for InfoSphere TRIM_CHAR_TO_VARCHAR . . . . . . . 502
CDC for Oracle - Trigger (version 6.3 TRIM_VARCHAR_TO_VARCHAR . . . . . 502
and later) . . . . . . . . . . . . . 481 TRIM_TO_NULL . . . . . . . . . . . 503
General product system parameters . . . . . . 481 Cascading replication system parameters . . . . 504
mirror_auto_restart_interval_minutes . . . . 481 PREVENT_RECURSION. . . . . . . . . 504
Notification system parameters . . . . . . . 482 Database journal (trigger) system parameters . . . 504
events_max_retain . . . . . . . . . . . 482 REPORT_POSITION_INTERVAL . . . . . . 504
global_conversion_not_possible_warning . . . 482 Maximize throughput system parameters . . . . 505
global_shutdown_after_no_heartbeat_response_minutes
482 COMMIT_GROUP_SIZE. . . . . . . . . 505
Maximize throughput system parameters . . . . 483 COMMIT_INTERVAL . . . . . . . . . 506
mirror_interim_commit_threshold . . . . . 483 SYNCHRONIZATION_COMMIT_
refresh_commit_after_max_operations . . . . 483 GROUP_SIZE . . . . . . . . . . . . 507
Database journal (trigger) system parameters . . . 484 SYNCHRONIZATION_INTERVAL . . . . . 508
mirror_journal_schema . . . . . . . . . 484 Tracing system parameters . . . . . . . . . 508
Encoding system parameters . . . . . . . . 484 D_MIRROR_ALARM_TRACE . . . . . . . 508
global_unicode_as_char . . . . . . . . . 484 D_MIRROR_TRACE . . . . . . . . . . 509

Contents xi
 D_MIRROR_TRACE_FILE_SIZE . . . . . . 509 Startup Timeout . . . . . . . . . . . 535
D_MIRROR_TRACE_ON_ERROR . . . . . 510 TCP_KEEPALIVE_SECS . . . . . . . . . 535
Notification system parameters . . . . . . . 510 Replication system parameters . . . . . . . 536
convertNotNullableMsg . . . . . . . . . 511 Allow Refresh While Active . . . . . . . 536
DEADBAND_PERCENTAGE . . . . . . . 511 End on Error During Mirroring . . . . . . 536
DM_STATUS_INTERVAL . . . . . . . . 513 End on Error During Refresh . . . . . . . 537
HEARTBEAT_TIMEOUT . . . . . . . . 513 Refresh After Restore . . . . . . . . . . 537
LOG_EMAIL_USERNAME . . . . . . . . 514 Cascading replication system parameters . . . . 538
MONITOR_SAMPLE_INTERVAL. . . . . . 514 Enable Cascading Replicates . . . . . . . 538
STATISTICS_INTERVAL . . . . . . . . . 515 Database journal (trigger) system parameters . . . 538
Disk resource system parameters . . . . . . . 515 Default Journal Library . . . . . . . . . 538
LOG_MAX_SIZE . . . . . . . . . . . 515 Default Journal Name . . . . . . . . . 539
Refresh loader system parameters . . . . . . 516 Replicate User Defined Journal Entries . . . . 539
D_HOME_BCP . . . . . . . . . . . . 516 Report Position Interval . . . . . . . . . 540
D_MIRROR_BCP . . . . . . . . . . . 516 Synchronization Interval. . . . . . . . . 540
D_MIRROR_BCP_ROWS . . . . . . . . 517 Remote journal system parameters . . . . . . 541
D_MIRROR_FASTBCP . . . . . . . . . 517 Data Origin TCP/IP Name . . . . . . . . 541
DM_BCP_PACKET_SIZE . . . . . . . . 517 Data Origin Port . . . . . . . . . . . 541
Relational Database Directory Entry . . . . . 542
System parameters for InfoSphere Commitment control system parameters . . . . 542
CDC for Sybase (version 6.3 and later) 519 Commitment Control . . . . . . . . . . 542
Multibyte character set system parameters. . . . 543
General product system parameters . . . . . . 519
Unicode Handling . . . . . . . . . . . 543
mirror_auto_restart_interval_minutes . . . . 519
Latency system parameters . . . . . . . . . 544
Notification system parameters . . . . . . . 520
Deadband Percentage . . . . . . . . . 544
events_max_retain . . . . . . . . . . . 520
Monitor Sample Interval. . . . . . . . . 546
global_conversion_not_possible_warning . . . 520
Notification system parameters . . . . . . . 546
global_shutdown_after_no_heartbeat_response_minutes
521
Heartbeat Timeout. . . . . . . . . . . 546
Maximize throughput system parameters . . . . 521
Messages on Column Not Null Capable . . . 547
global_max_batch_size . . . . . . . . . 521
Messages on Invalid Numerics . . . . . . 547
mirror_interim_commit_threshold . . . . . 522
Progress Status Interval . . . . . . . . . 548
refresh_commit_after_max_operations . . . . 522
Data type system parameters . . . . . . . . 549
Encoding system parameters . . . . . . . . 523
Numeric Column Validation . . . . . . . 549
global_unicode_as_char . . . . . . . . . 523
Date and time column function system parameters 549
Disk resource system parameters . . . . . . . 524
Default Date On Error . . . . . . . . . 549
mirror_global_disk_quota_mb . . . . . . . 524
Row and column filtering system parameters. . . 550
mirror_global_disk_quota_gb . . . . . . . 524
Audit Filtered Transactions . . . . . . . . 550
Apply process system parameters . . . . . . 525
Critical Column Filtering . . . . . . . . 551
global_default_after_database_minimum_timestamp525
Event log system parameters . . . . . . . . 551
global_default_before_database_minimum_timestamp
526
Notify Message Queue . . . . . . . . . 551
convert_not_nullable_column . . . . . . . 526
Notify Message Queue Library . . . . . . 552
convert_not_nullable_message . . . . . . . 527
Notify Message Threshold . . . . . . . . 552
mirror_end_on_error . . . . . . . . . . 527
Lock detection system parameters . . . . . . 553
mirror_expected_errors_list . . . . . . . . 527
Lock Timeout Value . . . . . . . . . . 553
refresh_end_on_error . . . . . . . . . . 528
refresh_expected_errors_list . . . . . . . 528
refresh_loader_drop_index . . . . . . . . 529 System parameters for InfoSphere
refresh_with_referential_integrity . . . . . . 529 CDC for DB2 UDB and Teradata
trim_char_to_varchar . . . . . . . . . . 529 (version 6.0 and earlier) . . . . . . . 555
trim_varchar_to_varchar. . . . . . . . . 530 General product system parameters . . . . . . 555
userexit_max_lob_size_kb . . . . . . . . 530 audit_auth_ code . . . . . . . . . . . 556
Supplemental logging system parameters . . . . 531 auth_ code . . . . . . . . . . . . . 556
auto_configure_supplemental_logging . . . . 531 db_password . . . . . . . . . . . . 556
mirror_logging_by_empty_triggers . . . . . 531 db_user . . . . . . . . . . . . . . 557
debug . . . . . . . . . . . . . . . 557
System parameters for InfoSphere engine_ port. . . . . . . . . . . . . 557
CDC for IBM i (version 6.2 and earlier) 533 log_file_quota . . . . . . . . . . . . 557
General product system parameters . . . . . . 533 log_total_quota . . . . . . . . . . . . 557
Authorization Code . . . . . . . . . . 534 md_db_url . . . . . . . . . . . . . 558
Enable *MAXOPT3 Option . . . . . . . . 534 md_schema . . . . . . . . . . . . . 558
Record Format Check . . . . . . . . . 534 scrape_timeout . . . . . . . . . . . . 558

xii InfoSphere Change Data Capture Management Console: Administration Guide

 startup_timeout . . . . . . . . . . . 558 target_trace_physical_messages . . . . . . 578
target_debug . . . . . . . . . . . . 558 trace_level . . . . . . . . . . . . . 578
target_initial_codepage . . . . . . . . . 559 trace_on . . . . . . . . . . . . . . 578
ts_password . . . . . . . . . . . . . 559 Teradata TPump system parameters . . . . . . 578
ts_product . . . . . . . . . . . . . 559 tpump_arc_data_files . . . . . . . . . . 578
Access Server system parameters . . . . . . . 559 tpump_files_root_folder . . . . . . . . . 579
accessserver_udp_ listenport . . . . . . . 559 tpump_logging . . . . . . . . . . . . 580
agent_assert . . . . . . . . . . . . . 560 tpump_max_file_size . . . . . . . . . . 580
agent_debug. . . . . . . . . . . . . 560 tpump_script_params_file . . . . . . . . 581
agent_jdbcdb2_driver. . . . . . . . . . 560 tpump_script_val_file. . . . . . . . . . 581
agent_jdbcdb2_driver_net . . . . . . . . 560 tpump_ timeout . . . . . . . . . . . 582
agent_jdbcpb_driver . . . . . . . . . . 560
agent_jdbcpb_driver_net. . . . . . . . . 560 System parameters for InfoSphere
agent_max_connections_num . . . . . . . 561 CDC for DB2 LUW (version 6.1 and
agent_message_version . . . . . . . . . 561
agent_msg_resources_file . . . . . . . . 561
later) . . . . . . . . . . . . . . . 583
agent_src_engine_address . . . . . . . . 561 General product system parameters . . . . . . 583
agent_src_engine_port . . . . . . . . . 561 mirror_auto_restart_interval_minutes . . . . 583
agent_src_engine_socket_tmout . . . . . . 561 Notification system parameters . . . . . . . 584
agent_trace_in_message . . . . . . . . . 561 events_max_retain . . . . . . . . . . . 584
agent_trace_out_message . . . . . . . . 562 global_conversion_not_possible_warning . . . 584
agent_udp_ listenport . . . . . . . . . 562 global_shutdown_after_no_heartbeat_response_minutes
584
Cascading replication system parameters . . . . 562 Maximize throughput system parameters . . . . 585
cascade_replication . . . . . . . . . . 562 mirror_interim_commit_threshold . . . . . 585
Commitment control system parameters . . . . 563 refresh_commit_after_max_operations . . . . 586
commit_group_size . . . . . . . . . . 563 Encoding system parameters . . . . . . . . 586
commit_ interval . . . . . . . . . . . 564 global_unicode_as_char . . . . . . . . . 586
refresh_commit_ block_size. . . . . . . . 565 Disk resource system parameters . . . . . . . 587
scraper_trans_ num_limit . . . . . . . . 565 mirror_global_disk_quota_mb . . . . . . . 587
source_default_ commit_level . . . . . . . 565 mirror_global_disk_quota_gb . . . . . . . 588
target_default_commit_level . . . . . . . 566 staging_store_can_run_independently . . . . 588
Database translation log system parameters . . . 566 staging_store_disk_quota_gb . . . . . . . 589
report_position_interval . . . . . . . . . 567 staging_store_disk_quota_mb . . . . . . . 589
Fastload system parameters . . . . . . . . 567 Apply process system parameters . . . . . . 589
refresh_del_fastload_file . . . . . . . . . 567 convert_not_nullable_column . . . . . . . 590
dofastload . . . . . . . . . . . . . 568 convert_not_nullable_message . . . . . . . 590
fastload_backup_path . . . . . . . . . 569 global_max_batch_size . . . . . . . . . 591
fastload_in_whole . . . . . . . . . . . 569 mirror_end_on_error . . . . . . . . . . 591
fastload_path . . . . . . . . . . . . 569 mirror_expected_errors_list . . . . . . . . 592
make_fastload_log_file . . . . . . . . . 570 refresh_end_on_error . . . . . . . . . . 592
max_fastload_ file_size . . . . . . . . . 570 refresh_expected_errors_list . . . . . . . 592
Latency system parameters . . . . . . . . . 571 refresh_loader_drop_index . . . . . . . . 593
monitor_sample_interval . . . . . . . . 571 refresh_with_referential_integrity . . . . . . 593
Lock detection system parameters . . . . . . 571 userexit_max_lob_size_kb . . . . . . . . 593
dm_lock_detection. . . . . . . . . . . 572
dm_lock_timeout . . . . . . . . . . . 572 System parameters for InfoSphere
Multibyte character set system parameters. . . . 573 CDC for Teradata (version 6.2 and
unicode_handling . . . . . . . . . . . 573 later) . . . . . . . . . . . . . . . 595
Notification system parameters . . . . . . . 574 Notification system parameters . . . . . . . 595
dm_status_interval . . . . . . . . . . 574 events_max_retain . . . . . . . . . . . 595
heartbeat_timeout . . . . . . . . . . . 575 global_conversion_not_possible_warning . . . 596
Replication system parameters . . . . . . . 575 global_shutdown_after_no_heartbeat_response_minutes
596
dobatch . . . . . . . . . . . . . . 575 Maximize throughput system parameters . . . . 596
source_default_active_refresh . . . . . . . 576 global_max_batch_size . . . . . . . . . 597
target_mirror_number_of_errors_before_abort 576 mirror_interim_commit_threshold . . . . . 597
target_print_refresh_details . . . . . . . . 576 Disk resource system parameters . . . . . . . 598
target_refresh_number_of_errors_before_abort 577 mirror_global_disk_quota_mb . . . . . . . 598
Tracing system parameters . . . . . . . . . 577 mirror_global_disk_quota_gb . . . . . . . 598
message_handler_trace_level . . . . . . . 577 Apply process system parameters . . . . . . 599
message_trace_level . . . . . . . . . . 577 convert_not_nullable_column . . . . . . . 599
target_trace_logical_messages . . . . . . . 577 convert_not_nullable_message . . . . . . . 600

Contents xiii
 mirror_end_on_error . . . . . . . . .
mirror_expected_errors_list . . . . . . .
mirror_td_apply_method . . . . . . .
refresh_end_on_error . . . . . . . . .
refresh_expected_errors_list . . . . . .
trim_char_to_varchar . . . . . . . . .
trim_varchar_to_varchar. . . . . . . .
userexit_max_lob_size_kb . . . . . . .
Teradata TPump system parameters . . . . .
mirror_tpump_files_root_folder_path . . .
mirror_tpump_max_file_size_mb . . . . .
mirror_tpump_script_val_file_name . . . .
mirror_tpump_timeout_seconds . . . . .
mirror_tpump_update_on_key_column . . .
Fastload system parameters . . . . . . .
refresh_max_fastload_file_size_mb . . . .
System parameters for InfoSphere
CDC Event Server . . . . . . . . . 609
Notification system parameters . . . . . .
events_max_retain . . . . . . . . . .
global_conversion_not_possible_warning . .
Apply process system parameters . . . . .
convert_not_nullable_column . . . . . .
convert_not_nullable_message . . . . . .
mirror_commit_on_transaction_boundary . .
mirror_end_on_error . . . . . . . . .
mirror_expected_errors_list . . . . . . .
mirror_interim_commit_threshold . . . .
refresh_end_on_error . . . . . . . . .
refresh_expected_errors_list . . . . . .
userexit_max_lob_size_kb . . . . . . .
Disk resource system parameters . . . . . .
mirror_global_disk_quota_mb . . . . . .
mirror_global_disk_quota_gb . . . . . .
System parameters for InfoSphere
CDC for IBM InfoSphere DataStage . . 617
Notification system parameters . . . . . . . 617
events_max_retain . . . . . . . . . . . 617
global_conversion_not_possible_warning . . . 618
global_shutdown_after_no_heartbeat_response_minutes
618
Disk resource system parameters . . . . . . . 618
mirror_global_disk_quota_mb . . . . . . . 619
mirror_global_disk_quota_gb . . . . . . . 619
Apply process system parameters . . . . . . 620
convert_not_nullable_column . . . . . . . 620
convert_not_nullable_message . . . . . . . 620
mirror_end_on_error . . . . . . . . . . 621
mirror_expected_errors_list . . . . . . . . 621
mirror_interim_commit_threshold . . . . . 622
refresh_end_on_error . . . . . . . . . . 622
refresh_expected_errors_list . . . . . . . 622
refresh_with_referential_integrity . . . . . . 623
trim_char_to_varchar . . . . . . . . . . 623
trim_varchar_to_varchar. . . . . . . . . 623
InfoSphere DataStage system parameters . . . . 624
userexit_max_lob_size_kb . . . . . . . . 624
xiv InfoSphere Change Data Capture Management Console: Administration Guide
. 600 System parameters for InfoSphere
. 601 CDC for IBM Informix Dynamic Server. 625
. 601 General product system parameters . . . . . . 625
. 602 mirror_auto_restart_interval_minutes . . . . 625
. 602 Notification system parameters . . . . . . . 626
. 602 events_max_retain . . . . . . . . . . . 626
. 603 global_conversion_not_possible_warning . . . 626
. 603 global_shutdown_after_no_heartbeat_response_minutes
626
. 603 Maximize throughput system parameters . . . . 627
. 604 mirror_interim_commit_threshold . . . . . 627
. 604 refresh_commit_after_max_operations . . . . 628
. 605 Encoding system parameters . . . . . . . . 628
. 606 global_unicode_as_char . . . . . . . . . 628
. 606 Disk resource system parameters . . . . . . . 629
. 606 mirror_global_disk_quota_mb . . . . . . . 629
. 606 mirror_global_disk_quota_gb . . . . . . . 629
Apply process system parameters . . . . . . 630
convert_not_nullable_column . . . . . . . 630
convert_not_nullable_message . . . . . . . 631
. 609 global_max_batch_size . . . . . . . . . 631
. 609 mirror_end_on_error . . . . . . . . . . 632
. 609 mirror_expected_errors_list . . . . . . . . 632
. 610 refresh_end_on_error . . . . . . . . . . 632
. 610 refresh_expected_errors_list . . . . . . . 633
. 611 refresh_with_referential_integrity . . . . . . 633
. 611 trim_char_to_varchar . . . . . . . . . . 633
. 612 trim_varchar_to_varchar. . . . . . . . . 634
. 612 userexit_max_lob_size_kb . . . . . . . . 634
. 612
. 613 Commands for Access Server . . . . 635
. 613 Datastore commands . . . . . . . . . . . 635
. 613 dmchangeconnectionpasswordChanging the
. 614 connection parameters to a datastore . . . . 635
. 614 dmcreatedatastoreAdding a datastore . . . 636
. 614 dmdeleteconnectionDeleting a datastore
connection . . . . . . . . . . . . . 637
dmdeletedatastoreDeleting a datastore . . . 638
dmlistuserdatastoresGenerating a report list of
datastores assigned to a user . . . . . . . 639
User account commands. . . . . . . . . . 639
dmchangeuserpasswordChanging the
password on a user account . . . . . . . 640
dmcreateuserAdding a user account . . . . 640
dmdeleteuserDeleting a user . . . . . . 642
dmdisableuserDisabling a user account . . . 643
dmenableuserEnabling a user . . . . . . 643
dmlistusersListing user accounts . . . . . 644
dmresetuserResetting a user account . . . . 646
dmunlockuserUnlocking a user account . . . 646
Other commands . . . . . . . . . . . . 647
dmaccessserverStart Access Server . . . . 647
dmaddconnectionAdding a datastore
connection to a user . . . . . . . . . . 648
dmlistdatastoreusersGenerating a report list of
users assigned to a datastore . . . . . . . 649
dmshowversionShow InfoSphere CDC Access
Server version . . . . . . . . . . . . 649
onlineOpen command environment . . . . 650
Using Support Assistant and Contacting IBM Support. . . . . . . . . . 654
contacting IBM Support . . . . . . . 651
Preparing to collect diagnostic data and tracing Glossary . . . . . . . . . . . . . 655
information . . . . . . . . . . . . . . 651
To enable tracing for Management Console and Notices . . . . . . . . . . . . . . 659
Access Server . . . . . . . . . . . . 652 Trademarks . . . . . . . . . . . . . . 661
To enable tracing for datastores for InfoSphere
CDC version 6.3 and above (optional) . . . . 652
To start the collection of diagnostic data and
tracing information with Support Assistant . . 653

Contents xv
xvi InfoSphere Change Data Capture Management Console: Administration Guide
Overview of InfoSphere CDC
IBM InfoSphere Change Data Capture, or simply InfoSphere CDC, is a
replication solution that captures database changes as they happen and delivers
them to target databases, message queues, or an ETL solution such as InfoSphere
DataStage based on table mappings configured in the InfoSphere CDC
Management Console GUI application.

InfoSphere CDC provides low impact capture and fast delivery of data changes for
key information management initiatives including dynamic data warehousing,
master data management, application consolidations or migrations, operational BI,
and enabling SOA projects. InfoSphere CDC also helps reduce processing
overheads and network traffic by only sending the data that has changed.
Replication can be carried out continuously or periodically. When data is
transferred from a source server, it can be remapped or transformed in the target
environment.

The following diagram illustrates the key components of InfoSphere CDC.

The key components of the InfoSphere CDC architecture are described below:
v Access ServerControls all of the non-command line access to the replication
environment. When you log in to Management Console, you are connecting to
Access Server.
v Admin APIOperates as an optional Java-based programming interface that
you can use to script operational configurations or interactions. After you have
set up replication, Management Console can be closed on the client workstation
without affecting active data replication activities between source and target
servers.
v Apply agentActs as the agent on the target that processes changes as sent by
the source.
v Command line interfaceAllows you to administer datastores and user
accounts, as well as to perform administration scripting, independent of
Management Console.

Copyright IBM Corp. 2008, 2011 1

 v Communication Layer (TCP/IP)Acts as the dedicated network connection
between the Source and the Target.
v DatastoreThe Source and Target datastores represent the data files and
InfoSphere CDC instances required for data replication. Each datastore
represents a database to which you want to connect and acts as a container for
your tables. Tables made available for replication are contained in a datastore.
v InfoSphere CDC Management ConsoleThe interactive application that you
use to configure and monitor replication. It allows you to manage replication on
various servers, specify replication parameters, and initiate refresh and mirroring
operations from a client workstation. Management Console also allows you to
monitor replication operations, latency, event messages, and other statistics
supported by the source or target datastore. The monitor in Management
Console is intended for time-critical working environments that require
continuous analysis of data movement.
v MetadataRepresents the information about the relevant tables, mappings,
subscriptions, notifications, events, and other particulars of a data replication
instance that you set up.
v MirrorPerforms the replication of changes to the target table or accumulation
of source table changes used to replicate changes to the target table at a later
time. If you have implemented bidirectional replication in your environment,
mirroring can occur to and from both the source and target tables.
v RefreshPerforms the initial synchronization of the tables from the source
database to the target. This is read by the Refresh reader.
v Replication EngineServes to send and receive data. The process that sends
replicated data is the Source Capture Engine and the process that receives
replicated data is the Target Engine. An InfoSphere CDC instance can operate as a
source capture engine and a target engine simultaneously.
v Single ScrapeActs as a source-only log reader and a log parser component. It
checks and analyzes the source database logs for all of the subscriptions on the
selected datastore.
v Source transformation engineUsed to process row filtering, critical columns,
column filtering, encoding conversions, and other data to propagate to the target
datastore engine.
v Source database logsMaintained by the source database for its own recovery
purposes. The InfoSphere CDC log reader inspects these in the mirroring
process, but only looks for those tables that are mapped for replication.
v Target transformation engineUsed to process data and value translations,
encoding conversions, user exits, conflict detections, and other data on the target
datastore engine.
There are two types of target-only destinations for replication that are not
databases:
v JMS MessagesActs as a JMS message destination (queue or topic) for
row-level operations that are created as XML documents.
v InfoSphere DataStageProcesses changes delivered from InfoSphere CDC that
can be used by InfoSphere DataStage jobs.

For more information on how to install Management Console and Access Server,
see Access Server and Management Console - Installation Guide. For information on
how to install your source and target replication engines, see the end-user
documentation for your replication engine platform.

See also:

2 InfoSphere Change Data Capture Management Console: Administration Guide

 Understanding the InfoSphere CDC workflow

Understanding the InfoSphere CDC workflow

This list and the following sections detail the workflow for setting up and
configuring replication in InfoSphere CDC:
v Installing Access Server
v Installing Management Console
v Adding and configuring datastores
v Adding and configuring subscriptions
v Mapping and customize tables
If you are using InfoSphere CDC Event Server, creating and customizing XML
messages for table mappings.
If you are using InfoSphere DataStage, generating .dsx definition files and
custom Java classes for InfoSphere DataStage jobs.
v Starting and ending replication

Overview of InfoSphere CDC 3

4 InfoSphere Change Data Capture Management Console: Administration Guide
What's new
A large number of features and enhancements have been added to Management
Console version 6.5. The following table lists the major feature changes:

Item Description For more information, see:

Ending replication Four choices for stopping Starting and ending replication
replication on page 327
Replicating v Auto-encoding mode Replicating multibyte (MBCS)
multibyte and double-byte (DBCS) character
v Translation and Encoding tabs
character set data on page 163
in the Table Mappings view
(MBCS) data
Table mappings Two options: Flat File or Direct Mapping using InfoSphere
for InfoSphere Connect DataStage on page 96
CDC for
InfoSphere
DataStage
Row subsets on Filter a refresh through the use of Flagging a source table for
refresh an SQL WHERE clause to only refresh on page 317
include rows within a specified
range.
Monitoring Changes to the Monitoring Subscriptions view (Monitoring
perspective, including a new view: perspective) on page
Performance. 359Performance view
(Monitoring perspective) on page
369
Upgrading Upgrade Transformation Server Upgrading existing
InfoSphere CDC for Microsoft SQL Server or Transformation Server
Transformation Server for Oracle subscriptions to InfoSphere CDC
to InfoSphere CDC version 6.5 on page 62Reverting to
Transformation Server on page 65

Copyright IBM Corp. 2008, 2011 5

6 InfoSphere Change Data Capture Management Console: Administration Guide
Before you start Management Console
Before you can start and log in to Management Console, make sure that you have
Access Server installed and running.

For more information, see the Management Console and Access Server - Installation
Guide.

Important: As of version 6.3.1 fix pack 1, both Management Console and Access
Server must be at the same level. Management Console can only connect to a
similar version of Access Server.

InfoSphere CDC version 6.5 introduces a number of enhancements and changes.

While InfoSphere CDC version 6.5 is backward-compatible, you must upgrade
your existing InfoSphere CDC agent datastores for their appropriate database
platforms to version 6.5 to access the full range of functionality introduced with
version 6.5.

In this section, you will learn:

Configuring firewall settings for outbound (static) ports
Logging in to Management Console by connecting to Access Server on page
10
Related concepts
Setting up user accounts on page 23
Commands for Access Server on page 635

Configuring firewall settings for outbound (static) ports

If your network uses a firewall or other security mechanism that requires static
ports for communication, then you must specify the ports that other computers can
use to communicate with Access Server services.

Note: In addition to a network firewall, you might have personal firewall software
installed and enabled on client machines. This firewall may cause a problem when
connecting to Management Console from Access ServerTypically, the resolution is
to add Management Console to your list of software exemptions in the personal
firewall software. However, depending on your personal firewall, this may differ.
Consult your personal firewall documentation for any connection conflicts or
problems..

Copyright IBM Corp. 2008, 2011 7

 The following figure highlights the ports you can configure for Management
Console and Access Server components. You can configure static port numbers for
all or some of these ports, depending on your network requirements.

The labels in the figure above correspond to the following groups of ports:
v 1Communication from Management Console to the Access Server service. You
specify this port when you install Access Server and when you log in to
Management Console. The default port is 10101 and you can set this value in
Management Console.
v 2Communication from Access Server back to Management Console for
monitor updates.
v 3Communication from Management Console to the Access Server service, per
datastore (that is, per InfoSphere CDC installation). This requires two ports for
each InfoSphere CDC installation.
v 4Communication from the Access Server service to the datastore, listen
process. This is established for each Management Console connection.
v 5Communication from the Access Server service to the datastore, monitor
process. This is a shared connection between all Management Console
connections on the same datastore. This requires two ports for each datastore.

You must also configure your routers and firewalls to allow communication
through the configured ports. For more information, contact your network
administrator.

Management Console requires:

v One input and output port to the Access Server.
v One input port from the Access Server
v One input and output port per datastore (regardless of whether you connect to
the datastore)

The Access Server requires:

v One input and output port per datastore, per installation of Management
Console
v Two input and output ports, per datastore

Additionally, you can have more than one datastore, or more than one installation
of Management Console; for example:

8 InfoSphere Change Data Capture Management Console: Administration Guide

 v One installation of Management Console and one datastore
v One installation of Management Console and two datastores
v Two installations of Management Console and one datastore
v Two installations of Management Console and two datastores

Example: calculating ports required

To help determine the number of ports required, take a scenario where there are
ten concurrent users and three datastores.

To calculate the number of Access Server ports to open, use this formula: number
of ports to open = 2 * (number of users + (number of users * number of
datastores) + number of datastores) where a datastore refers to an InfoSphere
CDC installation.

Using the above scenario of ten concurrent users and three datastores, the number
of Access Server ports required is 86. Here is the breakdown of the calculation,
following the order in the figure above illustrating the ports you can configure for
Management Console and Access Server components:
v Number of concurrent users that will log into Access Server = 10
v One port per user to connect to and deliver unsolicited message = 10
v Number of possible concurrent connections from Management Console to
connect to datastores); that is, 10 users * 3 datastores = 10 * 3
v Number of possible concurrent connections to datastore, listen process; that is,
10 users * 3 datastores)
v Two ports required to connect to each datastore, monitor process = 2 * 3
Therefore, 10 + 10 + (10 *3) + (10 *3) + (2 *3) = 86

To calculate the number of ports to open Management Console, use this formula:
number of ports to open = 2 + number of datastores

Using the above scenario of ten concurrent users and three datastores, the number
of ports required is 5 for each Management Console. This is the breakdown of the
calculation for each Management Console:
v Connection to Access Server = 1
v Connection for unsolicited updates from Access Server = 1
v One port for each connection to a datastore, listen process = 1 * 3
Therefore, 1 + 1 + (1 *3) = 5

See also:
To configure static ports

To configure static ports

1. Open the dmaccessserver.vmargs file in a text editor. This file is located in the
conf directory in your Access Server installation directory.
2. Replace the entry in this file with the following text:
-jar lib/server.jar local_port:<first_port>
local_port_count:<number_available_ports> <Access_Server_listener_port>
where:

Before you start Management Console 9

 v <first_port> is the first port in the range that you want the Access Server
service to use when sending messages or establishing connections.
v <number_available_ports> is the number of ports you want to reserve for
this use.
To calculate the number of Access Server ports to open, use this formula:
number of ports to open = 2 * (number of users + (number of users *
number of datastores) + number of datastores) where a datastore refers to
an InfoSphere CDC installation.
v <Access_Server_listener_port> is the port number that Access Server listens
on and is set during the Access Server installation. You do not have to
specify a value here if you are using the default port number of 10101.
For example, if the number of available ports for communication is 500 and
you want Access Server to listen for connections on port 10101, then the entry
would be as follows:
-jar lib/server.jar local_port:10102 local_port_count:500 10101

This enables Access Server to listen for connections on port 10101 and restricts
it to using ports in the range of 10102 to 10601.
These changes will take effect after you restart the Access Server service.

Logging in to Management Console by connecting to Access Server

After you start Management Console, you will be prompted to log in to Access
Server. Access Server is the server application that controls access to your
replication environment.

System Administrators with user and datastore account management rights can
create additional user accounts in the Access Manager perspective.

You can have multiple instances of Access Server in your working environment,
but you can only connect to one server at a time.

See also:
To log in to Management Consoleby connecting to Access Server
To change your log in password on page 11

To log in to Management Consoleby connecting to Access

Server
1. Ensure that your InfoSphere CDC system administrator has added you as a
user to an existing datastore in Management Console. Your system
administrator can set your user name and password in the Access Manager
perspective.
2. Navigate to the programs menu and start Management Console.
3. Type your user name in the User Name box.
4. Type your password in the Password box. The password is case-sensitive.
5. In the Server Name list, type or select the host name (system name) or full IP
address of the workstation running Access Server.
6. Type the TCP/IP port number in the Port Number box.
The port number that appears by default is specified in the Edit > Preferences
menu.

10 InfoSphere Change Data Capture Management Console: Administration Guide

 Related tasks
To add a user on page 24

To change your log in password

1. Click File > Access Server > Change Password.
2. Type the current password in the Current Password box.
3. Type and confirm the new password in the New Password and Confirm
Password boxes.
Your password must conform to the password policy defined by the Access
Server system administrator.

Before you start Management Console 11

12 InfoSphere Change Data Capture Management Console: Administration Guide
Understanding the Management Console interface
Management Console is composed of a number of windows or tabs that are
referred to as perspectives and views. After logging in to Management Console you
will see three perspectives: the Configuration perspective, the Monitoring
perspective, and the Access Manager perspective, from which you can access a
number of different views depending on your role and access level:
v The Monitoring perspective contains the Subscriptions view and the
Performance view. These views that allow you to initiate replication and
monitor your replication activity.
v The Configuration perspective contains the Subscriptions view, the Datastores
view, and the Table Mappings view. These views enable you to configure your
replication environment by connecting to your datastores, creating subscriptions,
mapping your tables, and configuring how to transform your data.
v The Access Manager perspective contains the Datastore Management view, the
User Management view, and the Connection Management view. These views
enable you to create and manage datastores, user accounts, and access
connections.

Preferences allow you to control the behavior of Management Console. For

example, you can choose whether you want to connect to datastores automatically
after logging in to Management Console.

The information, features and options displayed in the Management Console

interface is determined by several factors:
v your role as a user
v which datastores you have access to
v the type of the datastore
v the version of the datastore

Only the relevant information will be displayed in the interface and only the
eligible features and options will be available for use.
Related concepts
Managing user accounts on page 23
Monitoring subscriptions on page 359
Setting up datastores on page 33
Setting up and configuring subscriptions on page 47
A subscription is a connection that is required to replicate data between a source
datastore and a target datastore. It contains details of the data that is being
replicated and how the source data is applied to the target. Subscriptions use
datastores as the source or target of replicated data. You can view the datastores
that your subscriptions are using in the Source and Target columns of the
Subscriptions view.

Copyright IBM Corp. 2008, 2011 13

14 InfoSphere Change Data Capture Management Console: Administration Guide
Setting preferences
Preferences allow you to control certain aspects of the behavior of Management
Console.

In this section, you will learn:

Setting advanced preferences
Setting connection preferences on page 18
Setting datastore multiuser preferences on page 19
Setting prompt preferences on page 20
Setting statistics preferences on page 21

Setting advanced preferences

When mapping tables, you can show all databases, schemas, libraries, or tables
that are available for mapping, or you can specify filter criteria to display only
those databases, schemas, libraries, or tables that you require.

You can set the following advanced preferences:

v Access Server TimeoutsSet the timeout value to indicate how long
Management Console waits for a response from the datastore.
v MemoryAllocate memory for Management Console. You can increase the
amount of memory available for Management Console.
v EncodingAdd character sets and encodings to Management Console. For
InfoSphere CDC version 6.3 and earlier, you can add character sets and
encodings to Management Console that are different from the standard character
sets and encodings that are provided by default. These become available for
encoding conversion on the Encoding tab in the Mapping Details view.
You can also import and export character sets and encodings if you need to
share these settings.
Using filtering optimizes system performance and enables you to navigate more
efficiently if you have a large number of nodes (databases, schemas, libraries, or
tables). Depending on your InfoSphere CDC replication platform, and the
Minimum Number value specified for filtering in Edit > Preferences > Prompts >
Filtering, the Filter Databases, Filter Schemas, Filter Libraries, or Filter Tables
dialog box opens when you expand a datastore, database, schema, or library
respectively. The Filter Databases window can appear with the two replication
platforms that can contain multiple databases, Transformation Server version 5.3
for SQL Server and z/OS. For other replication platforms that contain single
database instances, the Filter Schemas and Filter Tables dialog boxes can open
when you expand the respective nodes under a datastore.

See also:
To set timeout values on page 16
To allocate memory for Management Console on page 16
To add a character encoding on page 16
To modify a character encoding on page 16
To delete a character encoding on page 17

Copyright IBM Corp. 2008, 2011 15

 To import the CSV template on page 17
To export the CSV template on page 18

To set timeout values

1. Click Edit > Preferences.
2. Click Advanced.
3. In the Access Server Timeouts area, type the desired value in the following
box:
v Describe Timeout (in minutes)
4. Click Apply.

To allocate memory for Management Console

1. Click Edit > Preferences.
2. Click Advanced.
3. Type the maximum amount of memory you want to allocate for Management
Console in the Maximum Memory (in megabytes) box.
4. Click Apply.

To add a character encoding

Note: This task is only applicable to InfoSphere CDC version 6.3 and earlier.
1. Click Edit > Preferences.
2. Select Advanced and click Encoding.
3. Click Add.
4. Type the supported encoding name in the ISO/IANA Name box.
This is dependent on database platform. Refer to the Java Supported Encodings
Document for a list of supported ISO/IANA encoding names.
5. Type the supported encoding name in the IBM CCSID box.
A Coded Character Set Identifier (CCSID) is a unique 16-bit number identifying
a set of encoding scheme identifiers, character set identifiers, code page
identifiers, and additional coding-related required information.
6. Choose one of the following from the Character Length box.
v Single-byte
v Double-byte
v Multi-byte
Related concepts
Setting advanced preferences on page 15
Related tasks
To modify a character encoding
To delete a character encoding on page 17

To modify a character encoding

Note: This task is only applicable to InfoSphere CDC version 6.3 and earlier.
1. Click Edit > Preferences.
2. Select Advanced and click Encoding.
3. Click Modify.

16 InfoSphere Change Data Capture Management Console: Administration Guide

 4. Select the desired character set from the list in the Column Encodings dialog
box.
5. Type the supported encoding name in the ISO/IANA Name box.
This is dependent on database platform. Refer to the Java Supported Encodings
Document for a list of supported ISO/IANA encoding names.
6. Type the supported encoding name in the IBM CCSID box.
A Coded Character Set Identifier (CCSID) is a unique 16-bit number identifying
a set of encoding scheme identifiers, character set identifiers, code page
identifiers, and additional coding-related required information.
7. Choose one of the following from the Character Length box.
v Single-byte
v Double-byte
v Multi-byte
Related concepts
Setting advanced preferences on page 15
Related tasks
To delete a character encoding
To add a character encoding on page 16

To delete a character encoding

Note: This task is only applicable to InfoSphere CDC version 6.3 and earlier.
1. Click Edit > Preferences.
2. Select Advanced and click Encoding.
3. Select the character set.
4. Click Delete.
Related concepts
Setting advanced preferences on page 15
Related tasks
To add a character encoding on page 16
To modify a character encoding on page 16

To import the CSV template

Note: This task is only applicable to InfoSphere CDC version 6.3 and earlier.
1. Click Edit > Preferences.
2. Select Advanced and click Encoding.
3. Click Import.
4. Type a name for the template in the File Name box.

Setting preferences 17
 Related concepts
Setting advanced preferences on page 15
Related tasks
To export the CSV template

To export the CSV template

Note: This task is only applicable to InfoSphere CDC version 6.3 and earlier.
1. Click Edit > Preferences.
2. Select Advanced and click Encoding.
3. Click Export.
4. Type a name for the template in the File Name box.
Related concepts
Setting advanced preferences on page 15
Related tasks
To import the CSV template on page 17

Setting connection preferences

You can set the Access Server default port, specify the number of ports for Access
Server, and choose whether you want to connect to datastores automatically after
logging in to Management Console.

Access Server Default PortThe Access Server default port is a unique TCP/IP
number that is used to connect to Access Server. You specify this port number
when you install Access Server and when you log in to Management Console.

Enable Firewall SettingsThe starting port number, and number of ports you
require to go through a firewall to Access Server. The following ports are required:
two for connection to Management Console; and two for each datastore associated
with your Management Console user.

Connect to Datastores AutomaticallyWhen enabled, automatically connects to

datastores after logging into Management Console. When disabled, you are
required to manually connect to each datastore after logging in.

See also:
To specify a default Access Server port number
To specify firewall settings for outbound (static) ports on page 19
To connect to databases automatically on page 19

To specify a default Access Server port number

1. Click Edit > Preferences.
2. Click Connection.
3. Type the unique TCP/IP port number in the Default Port text box in the
Access Server area.
4. Click Apply.

18 InfoSphere Change Data Capture Management Console: Administration Guide

 Related concepts
Setting connection preferences on page 18

To specify firewall settings for outbound (static) ports

1. Click Edit > Preferences.
2. Click Connection.
3. Enable the Enable Firewall Settings check box in the Firewall area.
4. Type the starting port in the Starting Port box.
5. Type the number of ports in the Number of Ports box. By default, the value is
2. You need two ports to connect to Management Console, and two for each
datastore associated with your Management Console user. You cannot specify
less than two ports.
6. Click Apply.
Related concepts
Setting connection preferences on page 18

To connect to databases automatically

1. Click Edit > Preferences.
2. Click Connection.
3. Enable the Connect to Datastores Automatically check box in the Datastores
area.
4. Click Apply.
Related concepts
Setting connection preferences on page 18

Setting datastore multiuser preferences

If you have, or you plan to add, a datastore that is accessed by more than one user,
you can enable automatic multiuser configuration when adding datastores, and
you can prompt users to log comments when unlocking subscriptions.

Note that multiuser configuration can be enabled for InfoSphere CDC version 6.3
Fix Pack 3 and later. It is not available for InfoSphere CDC for z/OS or InfoSphere
CDC for IBM i.

See also:
To automatically enable multiuser configuration when adding new datastores
To prompt users to log comments when unlocking subscriptions on page 20

To automatically enable multiuser configuration when adding

new datastores
1. Verify your version of InfoSphere CDC.
Multiuser configuration can be enabled for InfoSphere CDC version 6.3 Fix
Pack 3 and later. It is not available for InfoSphere CDC for z/OS or InfoSphere
CDC for IBM i.
2. Click Edit > Preferences.
3. Click Multiuser.
4. Enable the Automatically enable multiuser configuration when adding
datastores check box.

Setting preferences 19
 5. Click Apply.

To prompt users to log comments when unlocking

subscriptions
1. Click Edit > Preferences.
2. Click Multiuser.
3. Enable the Ask user to log comments when unlocking a subscription check
box.
4. Click Apply.

Setting prompt preferences

You can control when Management Console prompts you for confirmation before
or while performing certain tasks.

In the Confirmation area, you can enable:

v Marking a Table Capture PointEnables Management Console to prompt you
with a confirmation message before setting a capture point for a table. The
message warns you that setting a capture point will update the bookmark for
the table.
v Shutting Down DatastoreEnables Management Console to prompt you with a
confirmation message before shutting down an InfoSphere CDC datastore.
v Changing Connection Parameters PasswordEnables Management Console to
prompt you with a reminder that when you change a connection parameter
password you must update related subscriptions.
v Close Progress Windows AutomaticallyEnables Management Console to close
the progress window for successful actions; it will prompt you to request more
details only if the action is not successful.

In the Hints area, you can enable:

v Show Subscription Active/Edit PanelEnables Management Console to display
subscription information, in the Subscriptions perspective in the Configuration
view. This is most useful when determining if a subscription on a datastore with
multiuser mode enabled is locked, and who locked it, or if it is available for
editing. Depending on the state of the subscription, you will see a Start Editing
button, an End Editing button, or an Unlock button if you are an administrator
enabled to perform user access and datastore administration.

In the Filtering area, you can enable:

v Minimum numberSpecifies the minimum number of objects that will prompt
database, schema, library, or table filtering when selecting nodes in a datastore.
The default value is 1000.

You can click Restore Defaults at any time to use the default preferences.

See also:
To set prompt preferences on page 21
To automatically close progress windows on page 21
To show the Show Subscription Active/Edit Panel on page 21
To configure filtering for databases, schemas, and tables on page 21

20 InfoSphere Change Data Capture Management Console: Administration Guide

 To set prompt preferences
1. Click Edit > Preferences.
2. Click Prompts.
3. Specify the prompt options you want by enabling the appropriate check boxes.
4. Click Apply.

To automatically close progress windows

1. Click Edit > Preferences.
2. Click Prompts.
3. Enable the Close Progress Windows Automatically check box.
4. Click Apply.

To show the Show Subscription Active/Edit Panel

1. Click Edit > Preferences.
2. Click Prompts.
3. Enable the Show Subscription Active/Edit Panel check box.
4. Click Apply.

To configure filtering for databases, schemas, and tables

1. Click Edit > Preferences.
2. Click Prompts.
3. In the Minimum number box in the Filtering section, specify the number of
databases, schemas (or libraries), or tables at which the Map Tables wizard will
prompt you to specify a filter. Note that if you select a large value, loading all
databases, schemas, or tables may take some time. The default value is 1000.
4. Click Apply.

Setting statistics preferences

You can control how Management Console collects statistics for your replication
environment by setting the following preferences:
v Statistics History Retained (minutes)Specifies the length of time that
Management Console retains data for the statistics view.
v Statistics Sample Rate (seconds)Specifies the time interval frequency at which
Management Console collects data for the statistics view. A lower number will
increase the frequency of data collection.

See also:
To set the length of time for data retention
To set the sample rate for data collection on page 22

To set the length of time for data retention

1. Click Edit > Preferences.
2. Click Statistics.
3. Type the number of minutes in the Statistics History Retained (minutes) box.
4. Click Apply.

Setting preferences 21
 To set the sample rate for data collection
1. Click Edit > Preferences.
2. Click Statistics.
3. Type the number of minutes in the Statistics Sample Rate (seconds) box.
4. Click Apply.

22 InfoSphere Change Data Capture Management Console: Administration Guide

Setting up user accounts
Access Manager is an integrated component of Management Console that provides
a central point of administration for System Administrators to manage datastores
and user accounts.

You must be a System Administrator with user and datastore account management
permission to create datastores and users in the Access Manager perspective. You
can then assign these users to datastores and set database connection parameters in
order to provide users with access to an instance of InfoSphere CDC. Users can be
assigned to different roles that are distinguished by different levels of access into
Management Console. The Access Manager perspective also provides security
options that you can set on user accounts.

In this section, you will learn:

Managing user accounts
Managing security on user accounts on page 28
Setting password and account security policies on user accounts on page 30
Creating user list reports on page 32

Managing user accounts

The Access Manager perspective contains the User Management view. This view
enables you to create and manage user accounts and assign them to datastores.

In order to work in the Access Manager perspective, you must have a System
Administrator role and be enabled to manage user accounts and datastores.

Use the Access Manager view to:

v Add, modify, delete, or copy user accountsAdding a user account is necessary
to provide users with the ability to connect to Access Server and log into
Management Console. When adding a user account, you must specify a unique
user name. When setting a password for the user, it must meet any complex
password requirements you may have set in Management Console.
v Assign a datastore to a userAssigning a datastore provides the user access to
an instance of InfoSphere CDC and the ability to connect to the datastore that
you have made available for replication on the server.
v Change the security role of a userChanging the security role on a user
account determines the level of access a user has in Management Console. Users
can work in either a System Administrator account, Administrator account,
Monitor account, or an Operator account.
v Generate a report on selected user accountsGenerating a report on a specific
user account can help you keep track of which datastores the user has access to,
the role of the user, the date of user account creation, and the last time it was
modified. You can also track account status settings such as if the account is
locked, disabled, if the user is required to change their password at next login,
or if the account has a password expiry policy set on it.

Copyright IBM Corp. 2008, 2011 23

 Understanding user roles

There are four user role types available in the Management Console, each with
varying degrees of access and control:
v System AdministratorSpecifies that users assigned to this role can perform all
available operations in Management Console. Only users that require full
operational access to the Monitoring and Configuration perspectives should be
assigned to this role. System Administrators can also modify system parameters
to calibrate their replication environment.
Enable user account and datastore administrationEnables a user assigned
the System Administrator role access to the Access Manager perspective. If
you enable this option for a user, then they can create users and datastores, as
well as define Access Server password settings. This option is available only
to the System Administrator role.
v AdministratorSpecifies that users assigned to this role can access both the
Monitoring and Configuration perspectives in Management Console.
Administrators can create new subscriptions, can add, import and export
projects, but are not able to access the Access Manager perspective, and cannot
add or edit users or datastores. Administrators can start and end replication.
v OperatorSpecifies that users assigned to this role can access both the
Monitoring and Configuration perspectives in Management Console. Operators
can add, import and export projects, but they cannot create new subscriptions.
Users assigned to the Operator role can start, stop, and monitor replication
activities. They can also view the tables selected for refresh and start a refresh on
a subscription. Operators can view notifications sent by subscriptions or
datastores. However, users assigned to this role cannot configure replication and
select or remove tables from a refresh.
v MonitorSpecifies that users assigned to this role only have access to the
Monitoring perspective in Management Console. Users assigned to the Monitor
role can view events, statistics, and table mappings. Monitors can view the
replication state and status of a subscription and can view latency threshold
information. However, users assigned to this role cannot start or stop replication,
configure replication, refresh tables, or view notifications sent by subscriptions
and datastores.

See also:
To add a user
To edit a user on page 25
To delete a user on page 26
To copy a user on page 26
To change the existing role on a user account on page 27
To enable a System Administrator with user account and datastore
administration privileges on page 27
To view the history of a user account on page 28
Related tasks
To assign a datastore to users on page 38

To add a user
1. Ensure that you are a System Administrator and have the privileges to manage
datastores and user accounts.
2. Click Access Manager > User Management.

24 InfoSphere Change Data Capture Management Console: Administration Guide

 3. Click File > Access Server > New User.
4. Type the name of the user in the Name box.
This is the name the user will need to supply when connecting to Access Server
and logging into Management Console.
5. If you want to keep a profile of the user for system administrator purposes,
type their full name and a description in the Full Name and Description boxes.
6. If you want the user to specify a password, type and confirm it in the
Password and Confirm Password boxes.
If you have enabled complex passwords, then you must specify a password
that meets the requirements.
7. If you want to assign the user to a role, choose one of the following:
v System AdministratorSpecifies that users assigned to this role can perform
all available operations in Management Console. Only users that require full
operational access to the Monitoring and Configuration perspectives should
be assigned to this role. System Administrators can also modify system
parameters to calibrate their replication environment.
Enable user account and datastore administrationEnables a user
assigned the System Administrator role access to the Access Manager
perspective. If you enable this option for a user, then they can create users
and datastores, as well as define Access Server password settings. This
option is available only to the System Administrator role.
v AdministratorSpecifies that users assigned to this role can access both the
Monitoring and Configuration perspectives in Management Console.
Administrators can create new subscriptions, can add, import and export
projects, but are not able to access the Access Manager perspective, and
cannot add or edit users or datastores. Administrators can start and end
replication.
v OperatorSpecifies that users assigned to this role can access both the
Monitoring and Configuration perspectives in Management Console.
Operators can add, import and export projects, but they cannot create new
subscriptions. Users assigned to the Operator role can start, stop, and
monitor replication activities. They can also view the tables selected for
refresh and start a refresh on a subscription. Operators can view notifications
sent by subscriptions or datastores. However, users assigned to this role
cannot configure replication and select or remove tables from a refresh.
v MonitorSpecifies that users assigned to this role only have access to the
Monitoring perspective in Management Console. Users assigned to the
Monitor role can view events, statistics, and table mappings. Monitors can
view the replication state and status of a subscription and can view latency
threshold information. However, users assigned to this role cannot start or
stop replication, configure replication, refresh tables, or view notifications
sent by subscriptions and datastores.

To edit a user
1. Ensure that you are a System Administrator and have the privileges to manage
datastores and user accounts.
2. Click Access Manager > User Management.
3. Select an existing user.
4. Click File > Access Server > Properties.
5. If you want to change the full name or description of the user, type this
information in the Full Name and Description boxes.

Setting up user accounts 25

 6. If you want the user to specify a new password, type and confirm it in the
Password and Confirm Password boxes. As the system administrator, if you
have enabled complex passwords, then you must specify a password that meets
the requirements.
7. If you want to change the role assigned to the user, choose one of the
following:
v System AdministratorSpecifies that users assigned to this role can perform
all available operations in Management Console. Only users that require full
operational access to the Monitoring and Configuration perspectives should
be assigned to this role. System Administrators can also modify system
parameters to calibrate their replication environment.
Enable user account and datastore administrationEnables a user
assigned the System Administrator role access to the Access Manager
perspective. If you enable this option for a user, then they can create users
and datastores, as well as define Access Server password settings. This
option is available only to the System Administrator role.
v AdministratorSpecifies that users assigned to this role can access both the
Monitoring and Configuration perspectives in Management Console.
Administrators can create new subscriptions, can add, import and export
projects, but are not able to access the Access Manager perspective, and
cannot add or edit users or datastores. Administrators can start and end
replication.
v OperatorSpecifies that users assigned to this role can access both the
Monitoring and Configuration perspectives in Management Console.
Operators can add, import and export projects, but they cannot create new
subscriptions. Users assigned to the Operator role can start, stop, and
monitor replication activities. They can also view the tables selected for
refresh and start a refresh on a subscription. Operators can view notifications
sent by subscriptions or datastores. However, users assigned to this role
cannot configure replication and select or remove tables from a refresh.
v MonitorSpecifies that users assigned to this role only have access to the
Monitoring perspective in Management Console. Users assigned to the
Monitor role can view events, statistics, and table mappings. Monitors can
view the replication state and status of a subscription and can view latency
threshold information. However, users assigned to this role cannot start or
stop replication, configure replication, refresh tables, or view notifications
sent by subscriptions and datastores.

To delete a user
1. Ensure that you are a System Administrator and have the privileges to manage
datastores and user accounts.
2. Click Access Manager > User Management.
3. Select an existing user or hold the Ctrl key to select multiple users.
4. Click File > Access Server > Delete User.

To copy a user
1. Ensure that you are a System Administrator and have the privileges to manage
datastores and user accounts.
2. Click Access Manager > User Management.
3. Select an existing user.
4. Click File > Access Server > Copy.
5. Type the name of the user in the New name box.
26 InfoSphere Change Data Capture Management Console: Administration Guide
To change the existing role on a user account
1. Ensure that you are a System Administrator and have the privileges to manage
datastores and user accounts.
2. Click Access Manager > User Management.
3. Select a user or hold the Ctrl key to select multiple users.
4. Click File > Access Server > Change Role.
5. Choose from one of the following roles:
v System AdministratorSpecifies that users assigned to this role can perform
all available operations in Management Console. Only users that require full
operational access to the Monitoring and Configuration perspectives should
be assigned to this role. System Administrators can also modify system
parameters to calibrate their replication environment.
Enable user account and datastore administrationEnables a user
assigned the System Administrator role access to the Access Manager
perspective. If you enable this option for a user, then they can create users
and datastores, as well as define Access Server password settings. This
option is available only to the System Administrator role.
v AdministratorSpecifies that users assigned to this role can access both the
Monitoring and Configuration perspectives in Management Console.
Administrators can create new subscriptions, can add, import and export
projects, but are not able to access the Access Manager perspective, and
cannot add or edit users or datastores. Administrators can start and end
replication.
v OperatorSpecifies that users assigned to this role can access both the
Monitoring and Configuration perspectives in Management Console.
Operators can add, import and export projects, but they cannot create new
subscriptions. Users assigned to the Operator role can start, stop, and
monitor replication activities. They can also view the tables selected for
refresh and start a refresh on a subscription. Operators can view notifications
sent by subscriptions or datastores. However, users assigned to this role
cannot configure replication and select or remove tables from a refresh.
v MonitorSpecifies that users assigned to this role only have access to the
Monitoring perspective in Management Console. Users assigned to the
Monitor role can view events, statistics, and table mappings. Monitors can
view the replication state and status of a subscription and can view latency
threshold information. However, users assigned to this role cannot start or
stop replication, configure replication, refresh tables, or view notifications
sent by subscriptions and datastores.

To enable a System Administrator with user account and

datastore administration privileges
1. Ensure that you are a System Administrator and have the privileges to manage
datastores and user accounts.
2. Click Access Manager > User Management.
3. Select an existing user.
4. Click File > Access Server > Properties.
5. Ensure that the user is assigned to the System Administrator role.
6. Enable the Enable user account and datastore administration check box.

Setting up user accounts 27

 To view the history of a user account
1. Ensure that you are a System Administrator and have the privileges to manage
datastores and user accounts.
2. Click Access Manager > User Management.
3. Select an existing user.
4. Click File > Access Server > Properties.
5. Click the History tab.

Managing security on user accounts

Note: To be able to work in the Access Manager perspective, you must be a
System Administrator that has the privilege to manage datastores and user
accounts.

You can set specific security options on an existing user account in the Access
Manager perspective of Management Console.

Use the User Properties dialog box to:

v Disable user accounts
v Require users to change their passwords at next login
v Override any password expiration policy you may have set in Management
Console
v Lock or unlock user accounts

See also:
To disable a user account
To require a user to change password at next login
To override password expiration policy set in Management Console on page
29
To unlock a user account on page 29
To unlock a system administrator user account on page 29

To disable a user account

1. Click Access Manager > User Management.
2. Select an existing user.
3. Click File > Access Server > Properties.
4. Enable the Account is disabled check box.

To require a user to change password at next login

1. Ensure that you are a System Administrator and have the privileges to manage
datastores and user accounts.
2. Click Access Manager > User Management.
3. Select an existing user.
4. Click File > Access Server > Properties.
5. Enable the User must change password at next login check box in the Status
section.

28 InfoSphere Change Data Capture Management Console: Administration Guide

To override password expiration policy set in Management
Console
1. Ensure that you are a System Administrator and have the privileges to manage
datastores and user accounts.
2. Click Access Manager > User Management.
3. Select an existing user.
4. Click File > Access Server > Properties.
5. Enable the Password never expires check box.

To unlock a user account

1. Ensure that you are a System Administrator and have the privileges to manage
datastores and user accounts.
2. Click Access Manager > User Management.
3. Select the user that is locked out of the account.
4. Click File > Access Server > Properties .
5. Disable the Account is locked check box.

To unlock a system administrator user account

1. Ensure that you are a System Administrator and have the privileges to manage
datastores and user accounts.
2. Issue the following command from the command-line of the UNIX or Windows
server where Access Server is installed:
DMUNLOCKUSER username [-accessserver hostname port adminuser adminpassword]
username
Specifies the name of the user you want to unlock.
-accessserver hostname port adminuser adminpassword
These parameters are optional and indicate that you want to run this
command for an installation of Access Server that is physically remote from
the Access Server installation where you are running this command. In
other words, you must install Access Server and run this command on a
system to which you have direct physical access. If you have installed
Access Server on the same machine as Management Console, then these
parameters are not required.
-accessserver
Specify -accessserver. This parameter indicates that you want to
connect to a remote installation of Access Server.
hostname
The fully qualified host name of the remote system where Access
Server is installed.
port
The port number of the remote system where Access Server is installed.
adminuser
A user with SYSADMIN privileges (see role parameter in the
dmcreateuser command) and the ability to manage users and datastores
(see manager parameter in the dmcreateuser command).
adminpassword
The password for the specified SYSADMIN user.

Setting up user accounts 29

Setting password and account security policies on user accounts
You can enhance password and account security on all user accounts in the Access
Manager perspective of Management Console. Use the Access Server Options
dialog box to:
v Set a complex password requirementEnhances password security by enabling
users to specify a complex password when logging into Management Console.
v Enforce password historyEnables System Administrators to enhance security
by ensuring that old passwords are not continually reused. For this policy to be
effective, do not let users change their password immediately after setting a new
one. You can control this by setting the minimum age of the password.
v Enforce a password expiry policyEnables System Administrators to enhance
security by ensuring that new passwords are created and associated with user
accounts.
v Lock accounts after a number of failed login attemptsEnables a three strikes
login policy which is used to prevent computer password attacks. The policy
creates a condition where a user will be locked out of their account after a
number of attempts. By default, this setting is set to 3 login attempts.
v Enforce an account expiry after new account creationEnhances account
security by forcing users to change their passwords when a new account is
created for them.
v Display the number of failed login attemptsEnables users to track the
number of failed login attempts before they get locked out of the account.
v Display the last successful loginEnables users to track their last successful
login.

Note: To be able to work in the Access Manager perspective, you must be a

System Administrator that has the privilege to manage datastores and user
accounts.

See also:
To set complex passwords on user accounts
To enforce password history on page 31
To enforce password expiry on page 31
To enforce password locking on failed login attempts on page 31
To enforce new account expiry on page 31
To display previous failed login attempts on page 31
To display the last successful login on page 32

To set complex passwords on user accounts

1. Ensure that you are a System Administrator and have the privileges to manage
datastores and user accounts.
2. Click File > Access Server > Access Server Options.
3. Click Passwords.
4. Enable the Require complex password check box.
5. Type the minimum password length in the Minimum password length box.
The number must be between 0 and 30.
6. Type the minimum number of alphabetic characters in the Minimum
alphabetic characters box. The number must be between 0 and 30.

30 InfoSphere Change Data Capture Management Console: Administration Guide

 7. Type the minimum number of non-alphabetic characters in the Minimum
non-alphabetic characters box. The number must be between 0 and 30.

To enforce password history

1. Ensure that you are a System Administrator and have the privileges to manage
datastores and user accounts.
2. Click File > Access Server > Access Server Options.
3. Click Passwords.
4. Enable the Enforce Password history check box.
5. Type the number of passwords remembered in the Passwords remembered
box.
The number must be between 1 and 12. The default number is 5.

To enforce password expiry

1. Ensure that you are a System Administrator and have the privileges to manage
datastores and user accounts.
2. Click File > Access Server > Access Server Options.
3. Click Passwords.
4. Enable the Enforce password expiry check box.
5. Type the maximum number of days before a password expires in the
Maximum password (age) box.
The number must be between 1 and 999. The default number is 3.

To enforce password locking on failed login attempts

1. Ensure that you are a System Administrator and have the privileges to manage
datastores and user accounts.
2. Click File > Access Server > Access Server Options.
3. Click Accounts.
4. Enable the Lock accounts on failed login attempts check box.
5. Type the maximum number of attempts before an accounts is locked in the
Consecutive failures before lock box.
The number must be between 1 and 100. The default number is 3.

To enforce new account expiry

1. Ensure that you are a System Administrator and have the privileges to manage
datastores and user accounts.
2. Click File > Access Server > Access Server Options.
3. Click Accounts.
4. Enable the Enforce new account expiry check box.
5. Type the maximum number of days before a new account expires in the
Maximum new account age (days) box.
The number must be between 1 and 999. The default number is 15.

To display previous failed login attempts

1. Ensure that you are a System Administrator and have the privileges to manage
datastores and user accounts.
2. Click File > Access Server > Access Server Options.
3. Click Accounts.
Setting up user accounts 31
 4. Enable the Display previous failed login attempts check box.

To display the last successful login

1. Ensure that you are a System Administrator and have the privileges to manage
datastores and user accounts.
2. Click File > Access Server > Access Server Options.
3. Click Accounts.
4. Enable the Display last successful login check box.

Creating user list reports

You can generate a user list report in the Access Manager perspective of
Management Console.

Note: To be able to work in the Access Manager perspective, you must be a

System Administrator that has the privilege to manage datastores and user
accounts.

See also:
To create a user list report

To create a user list report

1. Ensure that you are a System Administrator and have the privileges to manage
datastores and user accounts.
2. Click Access Manager > User Management.
3. Select an existing user or hold Ctrl to select multiple users.
4. Click File > Access Server > Reports > User Report.
5. Enable one or more of the following:
v Full NameIncludes the full name you specified when you created the user.
v RoleIncludes the role you had assigned to the user.
v DescriptionIncludes the description you specified when you created the
user.
v Account StatusIncludes information about the account such as password
expiry or if the account has been disabled or locked.
v Date CreatedIncludes the date you had created the user account.
v Date Last ModifiedIncludes the date the user was last modified.
v Datastores AccessIncludes the datastores you have assigned to the user.

32 InfoSphere Change Data Capture Management Console: Administration Guide

Setting up datastores
Access Manager is an integrated component of Management Console that provides
a central point of administration for System Administrators to manage datastores
and user accounts.

You must be a System Administrator with user and datastore account management
permission to create datastores and users in the Access Manager perspective. You
can then assign these users to datastores and set database connection parameters in
order to provide users with access to an instance of InfoSphere CDC. Users can be
assigned to different roles that are distinguished by different levels of access into
Management Console. The Access Manager perspective also provides security
options that you can set on user accounts.

In this section, you will learn:

Managing datastores
Managing datastore connections on page 36
Assigning users to datastores on page 38
Enabling multiple users to work simultaneously on the same datastore on
page 40
Creating datastore list reports on page 41

Managing datastores
A datastore represents the InfoSphere CDC instance.

The Datastore Management view in the Access Manager perspective in

Management Console can only be accessed by a user with the role of System
Administrator that has been also been enabled to perform user account and
datastore management.

Use the Datastore Management view to:

v Add, modify, copy, and delete datastoresAdding a datastore in Management
Console means that you are providing users access to an instance of InfoSphere
CDC for the purposes of configuration, monitoring, and operational control.
When adding a new datastore, you can optionally specify information about the
database and provide database connection parameters so that users can connect
to the datastore. Only users you have assigned to a datastore can connect to the
datastore.
v Assign users to a datastoreAssigning users to a datastore gives them access to
an installation of InfoSphere CDC and the ability to connect to the database that
you have made available for replication on the server.
v Enable multiple users to work with the same datastoreEnabling more than
one user to work with subscriptions in the same datastore means allowing users
to lock subscriptions they want to edit. This makes the subscriptions temporarily
unavailable to others, so there are no edit conflicts. A System Administrator
enabled to perform user account and datastore administration can also unlock a
subscription on behalf of a user (for example, a user locks a subscription, but
then goes on vacation; the System Administrator enabled to perform user
account and datastore administration can override the lock and make the
subscription available to other users now).

Copyright IBM Corp. 2008, 2011 33

 v Propagate connection parametersPropagating new connection parameters to
all users of the datastore eases system administration in that you only have to
specify connection parameters once.
v Generate reports on the activities related to a set of datastoresGenerating a
report on a specific datastore can help you keep track of which users you have
assigned datastore access to and what databases users can access, the date of
creation, and the last time it was modified.

See also:
To add a datastore
To edit a datastore
To delete a datastore on page 35
To copy a datastore on page 35
To view the history of a datastore on page 35
To set connection parameters on a datastore on page 35
Related concepts
Setting up datastores for replication on page 69
Related tasks
To assign users to a datastore on page 39

To add a datastore
1. Ensure that you are a System Administrator and have the privileges to manage
datastores and user accounts.
2. Click Access Manager > Datastore Management.
3. Click File > Access Server > New Datastore.
4. Type the name of the datastore in the Name box.
5. Type a description in the Description box.
6. Type the host name or the full IP address of the server where you have
installed InfoSphere CDC in the Host Name box.
7. Type the port number of the server in the Port box.
8. Ping the server. If successful, this returns the datastore properties including the
type of server where you have installed InfoSphere CDC and the version
number of the product. Datastores that use the Java VM and are platform
independent will return a platform type of Java VM and a database type of JDBC
for all types of servers.
9. If you want to enable multiple users to configure subscriptions in the same
datastore, enable the Require subscriptions to be locked before editing box in
the Multiuser Configuration area.
Related concepts
Setting up datastores for replication on page 69
Enabling multiple users to work simultaneously on the same datastore on page
40
Setting prompt preferences on page 20

To edit a datastore
1. Ensure that you are a System Administrator and have the privileges to
manage datastores and user accounts.
2. Click Access Manager > Datastore Management.
3. Select an existing datastore.
34 InfoSphere Change Data Capture Management Console: Administration Guide
 4. Click File > Access Server > Properties.
5. If you want to change the Name of the datastore, type it in the Name box.
6. If you want to change the description, type it in the Description box.
7. If the name of the server or IP address where InfoSphere CDC is installed has
changed, type it in the Host Name box.
8. If the port number of the server has changed, type it in the Port box.
9. If you upgrade an instance of InfoSphere CDC 6.3 to the Fix Pack 3 level, and
want to allow multiple users to work with the same datastore, you must ping
the server by clicking the Ping button.
10. If you want to enable multiple users to configure subscriptions in the same
datastore, enable the Require subscriptions to be locked before editing box
in the Multiuser Configuration area.
Related concepts
Setting up datastores for replication on page 69

To delete a datastore
1. Ensure that you are a System Administrator and have the privileges to manage
datastores and user accounts.
2. Click Access Manager > Datastore Management.
3. Select an existing datastore or hold Ctrl and select multiple datastores.
4. Click File > Access Server > Delete Datastore .
Related concepts
Setting up datastores for replication on page 69

To copy a datastore
1. Ensure that you are a System Administrator and have the privileges to manage
datastores and user accounts.
2. Click Access Manager > Datastore Management.
3. Select an existing datastore.
4. Click File > Access Server > Copy Datastore.
5. Type the name of the new datastore in the New Name box.
Related concepts
Setting up datastores for replication on page 69

To view the history of a datastore

1. Click Access Manager > Datastore Management.
2. Select a datastore.
3. Click File > Access Server > Properties.
4. Click History.
Related concepts
Setting up datastores for replication on page 69

To set connection parameters on a datastore

1. Ensure that you are a System Administrator and have the privileges to manage
datastores and user accounts.
2. Click Access Manager > Datastore Management.
3. Select an existing datastore.

Setting up datastores 35
 4. Click File > Access Server > Properties.
5. Click Connection Parameters.
6. Set the following options:
v In the Connection Parameters section:
Database/URLSpecifies the name of the database or the Universal
Resource Locator (URL) of the database server you want to connect to.
This option is automatically disabled for z/OS or IBM i datastores, and for
datastores at version 6.3.0 and later.
DatabaseSpecifies the name of the database server you want to connect
to. This option is only enabled for datastores for which it is required.
DB LoginSpecifies the database user name to connect to the database. If
you want users to connect to the database for replication with InfoSphere
DataStage, then you must specify the user you created when installing
InfoSphere CDC.
DB PasswordSpecifies the password to connect to the database.
Confirm PasswordSpecifies a repeat entry of the password for accuracy.
v In the Propagate Changes section:
Propagate changes to all usersEnable this check box if you want all
users assigned to this datastore to receive the connection parameters that
you specify on this dialog box.
Related concepts
Setting up datastores for replication on page 69

Managing datastore connections

A datastore represents the InfoSphere CDC instance.

The Connection Management view in the Access Manager perspective in

Management Console can only be accessed by a user with the role of System
Administrator that has been also been enabled to perform user account and
datastore management.

The contents displayed in the Connection Management view depend on the entry
you select from either the Datastore Management view or the User Management
view. Selecting an entry from the Datastore Management view displays the
selected datastore and any users assigned to it. Selecting an entry from the User
Management view displays the selected users and any assigned datastores.

Use the Connection Management view to:

v Assign a user to a datastoreAssigning a user to a datastore creates a
relationship between the datastore and that user. When assigning a user, you can
specify the correct connection parameters for the user to connect to the
datastore; if you don't, the user will be prompted to enter these parameters
when connecting to the datastore. You can assign the same user to more than
one datastore.
v Assign a datastore to a userAssigning a datastore to a user creates a
relationship between the user and that datastore. When assigning a user, you
can specify the correct connection parameters for the user to connect to the
datastore; if you don't, the user will be prompted to enter these parameters
when connecting to the datastore. You can assign the same datastore to more
than one user.

36 InfoSphere Change Data Capture Management Console: Administration Guide

 v Set connection parametersSetting connection parameters on a datastore
provides users with the ability to connect to the datastore. If you have already
specified connection parameters for a datastore when you added it to
Management Console, then these parameters will display when you assign a
user to a datastore. You can choose to apply the same connection parameters, or
you can choose to override them and specify another set of connection
parameters.
v Modify and delete connection parametersDeleting an existing connection is
necessary when a user no longer requires access to a specific datastore. You can
also modify connection parameters. Ensure that users are aware of the new
parameters so that they can connect.

See also:
To delete a connection
To override default connection parameters on a datastore
Related tasks
To assign users to a datastore on page 39

To delete a connection
1. Ensure that you are a System Administrator and have the privileges to manage
datastores and user accounts.
2. Click Access Manager.
3. Delete an existing connection using one of the following methods:
v Click Datastores Management and select an existing datastore that has a
user assigned to it. Click Connection Management and right-click on the
user assigned to the datastore. Click Delete Connection.
v Click User Management and select an existing user that has a datastore
assigned to it. Click Connection Management and right-click on the
datastore assigned to the user. Click Delete Connection.

To override default connection parameters on a datastore

1. Ensure that you are a System Administrator and have the privileges to manage
datastores and user accounts.
2. Click Access Manager > Datastore Management.
3. Select the datastore.
4. Select the user assigned to this datastore in the Connection Management view.
5. Click File > Access Server > Connection Parameters.
6. Set the following options:
v In the Connection Parameters section:
Database/URLSpecifies the name of the database or the Universal
Resource Locator (URL) of the database server you want to connect to.
This option is automatically disabled for z/OS or IBM i datastores, and for
datastores at version 6.3.0 and later.
DatabaseSpecifies the name of the database server you want to connect
to. This option is only enabled for datastores for which it is required.
DB LoginSpecifies the database user name to connect to the database. If
you want users to connect to the database for replication with InfoSphere
DataStage, then you must specify the user you created when installing
InfoSphere CDC.
DB PasswordSpecifies the password to connect to the database.

Setting up datastores 37
 Confirm PasswordSpecifies a repeat entry of the password for accuracy.
v In the Propagate Changes section:
Propagate changes to all usersEnable this check box if you want all
users assigned to this datastore to receive the connection parameters that
you specify on this dialog box.
7. If you want to set specific options on how these connection parameters are
displayed to the user when connecting to the datastore in the Connect to
datastore dialog box, then enable one or more of the following options:
v Always show connection dialogAllows the user to specify the password
each time they want to connect to the datastore.
v Show parameter values (except password)Displays the connection
parameters to the user (except password) each time the user tries to connect
to the datastore. Enable this to allow you to enable Write-protect parameters
(except password).
v Write-protect parameters (except password)Displays the connection
parameters to the user (except password) in read-only format each time the
user tries to connect to the datastore. Enable Show parameter values (except
password) to allow you to enable this.
v Allow connection parameters savingAllows the user to save the
connection parameters when connecting to a datastore.

Assigning users to datastores

In the Access Manager perspective of Management Console using either the
Datastore Management view, the User Management view, or the Connection
Management view, you can either assign a datastore to a user, or you can assign a
user to a datastore.

Both methods create the required relationship between a datastore and a user.
Users require this relationship to connect to a datastore.

A datastore represents the InfoSphere CDC instance.

See also:
To assign a datastore to users
To assign users to a datastore on page 39

To assign a datastore to users

1. Ensure that you are a System Administrator and have the privileges to manage
datastores and user accounts.
2. Ensure that you have added a user.
3. Click Access Manager > User Management.
4. Click File > Access Server > Assign > Datastore.
5. Select a datastore.
6. Review the connection parameters. You can click OK to accept the default
connection parameters on the datastore or you can choose to override the
default parameters for the selected user.
7. If you choose to override the defaults, specify the following:
v In the Connection Parameters section:

38 InfoSphere Change Data Capture Management Console: Administration Guide

 Database/URLSpecifies the name of the database or the Universal
Resource Locator (URL) of the database server you want to connect to.
This option is automatically disabled for z/OS or IBM i datastores, and for
datastores at version 6.3.0 and later.
DatabaseSpecifies the name of the database server you want to connect
to. This option is only enabled for datastores for which it is required.
DB LoginSpecifies the database user name to connect to the database. If
you want users to connect to the database for replication with InfoSphere
DataStage, then you must specify the user you created when installing
InfoSphere CDC.
DB PasswordSpecifies the password to connect to the database.
Confirm PasswordSpecifies a repeat entry of the password for accuracy.
v In the Propagate Changes section:
Propagate changes to all usersEnable this check box if you want all
users assigned to this datastore to receive the connection parameters that
you specify on this dialog box.
8. If you want to set specific options on how these connection parameters are
displayed to the user when connecting to the datastore in the Connect to
datastore dialog box, then enable one or more of the following options:
v Always show connection dialogAllows the user to specify the password
each time they want to connect to the datastore.
v Show parameter values (except password)Displays the connection
parameters to the user (except password) each time the user tries to connect
to the datastore. Enable this to allow you to enable Write-protect parameters
(except password).
v Write-protect parameters (except password)Displays the connection
parameters to the user (except password) in read-only format each time the
user tries to connect to the datastore. Enable Show parameter values (except
password) to allow you to enable this.
v Allow connection parameters savingAllows the user to save the
connection parameters when connecting to a datastore.

To assign users to a datastore

1. Ensure that you are a System Administrator and have the privileges to manage
datastores and user accounts.
2. Ensure that you have added a datastore.
3. Click Access Manager > Datastore Management.
4. Select an existing datastore.
5. Right-click and select Assign User.
6. Select a user or hold Ctrl to select multiple users.
7. Review the connection parameters. You can click OK to accept the default
connection parameters on the datastore or you can choose to override the
default parameters for the selected users.
8. If you choose to override the defaults, specify the following:
v In the Connection Parameters section:
Database/URLSpecifies the name of the database or the Universal
Resource Locator (URL) of the database server you want to connect to.
This option is automatically disabled for z/OS or IBM i datastores, and for
datastores at version 6.3.0 and later.

Setting up datastores 39
 DatabaseSpecifies the name of the database server you want to connect
to. This option is only enabled for datastores for which it is required.
DB LoginSpecifies the database user name to connect to the database. If
you want users to connect to the database for replication with InfoSphere
DataStage, then you must specify the user you created when installing
InfoSphere CDC.
DB PasswordSpecifies the password to connect to the database.
Confirm PasswordSpecifies a repeat entry of the password for accuracy.
v In the Propagate Changes section:
Propagate changes to all usersEnable this check box if you want all
users assigned to this datastore to receive the connection parameters that
you specify on this dialog box.
9. If you want to set specific options on how these connection parameters are
displayed to the user when connecting to the datastore in the Connect to
datastore dialog box, then enable one or more of the following options:
v Always show connection dialogAllows the user to specify the password
each time they want to connect to the datastore.
v Show parameter values (except password)Displays the connection
parameters to the user (except password) each time the user tries to connect
to the datastore. Enable this to allow you to enable Write-protect parameters
(except password).
v Write-protect parameters (except password)Displays the connection
parameters to the user (except password) in read-only format each time the
user tries to connect to the datastore. Enable Show parameter values (except
password) to allow you to enable this.
v Allow connection parameters savingAllows the user to save the
connection parameters when connecting to a datastore.

Enabling multiple users to work simultaneously on the same datastore

Note: Multiuser configuration can be enabled for InfoSphere CDC version 6.3 Fix
Pack 3 and later. It is not available for InfoSphere CDC for z/OS or InfoSphere
CDC for IBM i.

You can configure datastores to allow multiple users to work on them

simultaneously. Enabling this option requires users to explicitly lock a subscription
within a datastore so that others do not use it and cause conflicts. A System
Administrator enabled to perform user account and datastore administration can
set this option either during or after datastore creation, and can also unlock
subscriptions.

Management Console displays the status of subscriptions in one of two ways:

v Using status icons in the list of subscriptions in the Subscriptions perspective in
the Configuration view. Depending on the state of the subscription, you will see
a small lock icon to indicate that the subscription is locked, or a small box and
arrow icon to indicate that the subscription is available for editing. This
perspective does not provide details on who has locked a subscription.
v Using the Subscription Active/Edit Panel, a window under the list of
subscriptions in the Subscriptions perspective in the Configuration view that
displays subscription status details. This panel is enabled by default. To turn it
off, go to Edit > Preferences. If the subscription is available for editing and
multiuser configuration is enabled, you will see a Start Editing button. If you

40 InfoSphere Change Data Capture Management Console: Administration Guide

 are editing the subscription, you will see a pencil and End Editing button. If
another user is editing the subscription, you will see a lock icon and details on
the user who has locked the subscription. If you are an administrator enabled to
perform user access and datastore administration, you will see the Unlock
button when a subscription is locked by another user. If multiuser configuration
is not enabled, a subscription is always available for editing unless the
subscription is currently replicating.

If you disable the multiuser configuration option after it is enabled, Management

Console users working with the subscriptions in this datastore will not be aware of
this change until they log into Management Console again.

If you are using multiple Access Server instances on the same datastore, then you
must enable or disable the datastore multiuser configuration option for each
instance.
To enable multiple users to work with an existing datastore

To enable multiple users to work with an existing datastore

1. Ensure that you are a System Administrator and have the privileges to manage
datastores and user accounts.
2. Verify your version of InfoSphere CDC.
Multiuser configuration can be enabled for InfoSphere CDC version 6.3 Fix
Pack 3 and later. It is not available for InfoSphere CDC for z/OS or InfoSphere
CDC for IBM i.
3. Click Access Manager > Datastore Management.
4. Right-click on a datastore and select Properties.
5. Ping the server by clicking the Ping button in the Identification area.
6. Enable the Require subscriptions to be locked before editing check box in the
Multiuser Configuration area.
7. Click OK.
8. If you are using multiple Access Server instances on the same datastore, then
you must enable the datastore multiuser configuration option for each instance.
Related concepts
Enabling the apply of soft deletes (InfoSphere CDC for Oracle) on page 304
Related tasks
To add a datastore on page 34
To modify a system parameter on page 72

Creating datastore list reports

You can generate a datastore list report in the Access Manager perspective of
Management Console.

Note: To be able to work in the Access Manager perspective, you must be a

System Administrator that has the privilege to manage datastores and user
accounts.

See also:
To create a datastore list report on page 42

Setting up datastores 41
 To create a datastore list report
1. Ensure that you are a System Administrator and have the privileges to manage
datastores and user accounts.
2. Click Access Manager > Datastore Management.
3. Select an existing datastore or hold Ctrl to select multiple datastores.
4. Click File > Access Server > Reports > Datastore Report.
5. Enable one or more of the following:
v DescriptionIncludes a description you specified when you added the
datastore.
v Datastore PlatformIncludes the type of database platform on which this
datastore resides.
v Date CreatedIncludes the date you had created the datastore.
v Date Last ModifiedIncludes the date the datastore was last modified.
v User AccessIncludes the users you have assigned to this datastore.
6. Click OK and Save.

42 InfoSphere Change Data Capture Management Console: Administration Guide

Auditing user accounts, datastores, security policies, and
general events
You can audit user accounts, datastores, security policies, and general events in the
Access Manager perspective of Management Console. Collecting data generated by
user activities is very important for analyzing the security of information, verifying
system integrity, and detecting signs of suspicious behavior. By generating reports
that contain this type of information, you can systematically examine user activities
and identify any attempts to breach the security of your replication configuration.
When audit logging is enabled, Access Server keeps track of significant activities
and records them into an audit log file. You can archive audit log files and
generate audit trail reports for a specified period of time from the current audit
log, or from an archived log file. Two types of reports can be generated from an
audit log: audit trail and security log. You can save audit trail reports as HTML
files, and display or print them through a web browser.

Note: To be able to work in the Access Manager perspective, you must be a

System Administrator that has the privilege to manage datastores and user
accounts.

In this section, you will learn:

Collecting data generated by user activities

Collecting data generated by user activities

Use the Audit tab in the Access Server Options dialog box to:
v Enable audit loggingEnabling audit logging lets you audit the activity of user
accounts, datastores, security policies set on user accounts, and other general
events.
Use the Audit Trail Report dialog box to generate an audit trail report. You can
generate audit trail reports after enabling audit logging. The following activities are
recorded in the report:
v Added, modified, or deleted user accounts
v Added, modified, deleted, or renamed datastores
v New or lost user and datastore assignments
v Enabled, disabled, or modified ability to generate an audit log
v Modified security settings on user accounts
Use the Security Log dialog box to generate a security log report. You can generate
security log reports after enabling audit logging. The following activities are
recorded the report:
v Modified user passwords
v Disabled or enabled user accounts
v Locked or unlocked user accounts
v Successful or failed log in attempts by a user
v Which users are logged or logged out of Management Console
v Which datastores users are connected to or disconnected from
v Started or stopped Access Server
v Generated report lists

Copyright IBM Corp. 2008, 2011 43

 Each of the activities contained in either an audit trail or security log report has the
following categories and items of information:
v EventSpecifies the description of the activity being audited.
v TimestampThe date and time of activity.
v IdentificationDepending on the activities being audited, the report will
specify the name on the user account, datastore name, and the process
responsible for generating the activity.
v CommentProvides more information if applicable.

Note: To be able to work in the Access Manager perspective, you must be a

System Administrator that has the privilege to manage datastores and user
accounts.

See also:
To enable auditing
To generate an audit trail log
To generate a security log report
To clear the log on page 45

To enable auditing
1. Ensure that you are a System Administrator and have the privileges to manage
datastores and user accounts.
2. Click File > Access Server > Access Server Options.
3. Click the Audit tab.
4. Enable the Enable audit log check box.
5. Enable one or more of the following:
v Audit account managementEnable if you want to audit user account
management activities such as the creation, modification, and deletion of
users.
v Audit datastore managementEnable if you want to audit datastore
management activities such as the creation, modification, and deletion of
datastores.
v Audit security policy managementEnable if you want to audit security
policy settings related to passwords and user accounts.
v Audit general eventsEnable if you want to audit general events generated
by Access Server.

To generate an audit trail log

1. Ensure that you are a System Administrator and have the privileges to manage
datastores and user accounts.
2. Ensure that you have enabled audit logging.
3. Click File > Access Server > Audit log > Audit Trail.
4. Select the start date of the events you want to audit in the From box.
5. Select the end date of the events you want to audit in the To box.

To generate a security log report

1. Ensure that you are a System Administrator and have the privileges to manage
datastores and user accounts.
2. Ensure that you have enabled audit logging.

44 InfoSphere Change Data Capture Management Console: Administration Guide

 3. Click File > Access Server > Audit log > Security Log.
4. Select the start date of the events you want to audit in the From box.
5. Select the end date of the events you want to audit in the To box.

To clear the log

1. Ensure that you are a System Administrator and have the privileges to manage
datastores and user accounts.
2. Ensure that you have enabled audit logging and generated a report.
This ensures that there is nothing important in the report that you want to save
first before clearing the log.
3. Click File > Access Server > Audit log > Clear Log .
4. Click Yes.

Auditing user accounts, datastores, security policies, and general events 45

46 InfoSphere Change Data Capture Management Console: Administration Guide
Setting up and configuring subscriptions
A subscription is a connection that is required to replicate data between a source
datastore and a target datastore. It contains details of the data that is being
replicated and how the source data is applied to the target. Subscriptions use
datastores as the source or target of replicated data. You can view the datastores
that your subscriptions are using in the Source and Target columns of the
Subscriptions view.

Before you can start replicating data, you need to add a subscription. When adding
a new subscription, you can organize your subscription into a project and select
the datastores you want to use as the source and target of data during replication
activities. How you decide to set up the datastores in your subscriptions depends
on your replication requirements.

Setting up subscriptions for datastores outside of your

organization

You can also add subscriptions that send data to a target datastore that is external
to your organization. In order to set up a subscription that sends data to an
external target datastore, the receiving organization must have installed InfoSphere
CDC Management Console and you must have the necessary authentication and
database details to connect to their target datastore.

External source or target datastores are not available in your Access Manager,
either because they reside outside of your organization or department, or your
system administrator has not given you the permission to access it.

If you have received authorization from the company or organization to which you
are replicating data, then you can modify the properties of an external target
datastore, including the port number, owner, and password. System and database
information about external target datastores is provided by the organization or
department that owns that datastore.

You can also copy subscriptions that send data to an external target. This is a
timesaving mechanism.

If your organization is at the receiving end of replication activities coordinated

with another organization that is outside of your database security policy, then you
should see Unknown source datastores in your subscription list. This is because
you are receiving replicated data from a source datastore that is outside of your
security policy (and, therefore, to which you do not have access to) and the name
of the source datastore is not known to you.

Setting properties for a subscription that targets IBM InfoSphere

DataStage

If you create a subscription that uses InfoSphere CDC for InfoSphere DataStage as
a target datastore, you can modify the following subscription properties:
v Batch size thresholdsInfoSphere DataStage uses jobs to process batches of
data. When balancing the need to get data applied to the target quickly against
the need to minimize resource utilization, you can set the batch size threshold
property to run jobs less frequently and process larger amounts of data.
Copyright IBM Corp. 2008, 2011 47
 v Large object truncation size for character and binary dataThe truncation
point affects the fixed record length used by an InfoSphere DataStage job that
processes the changed data. You should set this property to as small a size as
possible while still retaining enough of the data from the large columns to meet
your business needs.

See also:
Subscriptions view (Configuration perspective)
Setting up subscriptions on page 49
Specifying network settings for subscriptions on page 51
Setting propagation control on subscriptions on page 52
Locking subscriptions within a datastore on page 52
Determining error handling for subscriptions on page 55
Making subscriptions persistent on page 56
Searching for tables used in replication on page 57
Setting up subscriptions for datastores outside of your organization on page
58
Copying subscriptions on page 59
Upgrading existing Transformation Server subscriptions to InfoSphere CDC
on page 62
Reverting to Transformation Server on page 65
Using projects to organize your subscriptions on page 65
Exporting and importing projects on page 67

Subscriptions view (Configuration perspective)

A subscription is a connection that is required to replicate data between a source
datastore and a target datastore. It contains details of the data that is being
replicated and how the source data is applied to the target. Subscriptions use
datastores as the source or target of replicated data.

In this view, you can do the following:

v Add and configure subscriptions
v Create, export, and import projects for your subscriptions
v Promote subscriptions

48 InfoSphere Change Data Capture Management Console: Administration Guide

 Related concepts
Logging in to Management Console by connecting to Access Server on page 10
Setting up and configuring subscriptions on page 47
A subscription is a connection that is required to replicate data between a source
datastore and a target datastore. It contains details of the data that is being
replicated and how the source data is applied to the target. Subscriptions use
datastores as the source or target of replicated data. You can view the datastores
that your subscriptions are using in the Source and Target columns of the
Subscriptions view.
Promoting subscription changes on page 349

Setting up subscriptions
Before you can start replicating data, you need to add a subscription. When adding
a new subscription, you can organize your subscription into a project and select
the datastores you want to use as the source and target of data during replication
activities. How you decide to set up the datastores in your subscriptions depends
on your replication requirements.

When creating your subscriptions, be aware that all subscriptions that come from
the same source datastore must have a unique name and all subscriptions that go
to the same target datastore must have a unique Source ID. The source ID is
automatically generated based on truncating the subscription name to 8 characters.
If you attempt to create a subscription with a duplicate Source ID, an error will
result and the subscription will not be created. If this occurs, you must open the
Advanced Settings dialog and give the subscription a unique Source ID.

See also:
To add a subscription
To modify a subscription on page 50
To delete a subscription on page 51

To add a subscription
1. Click Configuration > Subscriptions.
2. Right-click on a project and select New Subscription.
3. Type the name of the new subscription in the Name box.
All subscriptions that come from the same source datastore must have a
unique name and all subscriptions that go to the same target datastore must
have a unique Source ID. The source ID is automatically generated based on
truncating the subscription name to 8 characters. If you attempt to create a
subscription with a duplicate Source ID, an error will result and the
subscription will not be created. If this occurs, click Advanced Settings and
give the subscription a unique Source ID.
4. Type the description of the new subscription in the Description box.
5. If you want to include the new subscription in a project, select a project from
the Project list or click New Project to create a new project.
If you do not select a project, Management Console places the new
subscription into the Default Project.
6. Select the source datastore from the Source list.
7. Select the target datastore from the Target list.
8. If you selected <External> from the Target datastore list, click Details to
supply the required connection information.
Setting up and configuring subscriptions 49
 9. If you want to specify advanced settings for the subscription, click Advanced
Settings. Modify the following properties and click OK, then click Next.
v Source IDSpecify the source ID for the new subscription.
v Firewall PortSpecify a port number for the new subscription.
v TCP HostSpecify the TCP host that your source datastore will use to
recognize the target datastore when the computer where InfoSphere CDC is
installed has multiple network cards. This is useful if you want to specify a
host that is different from the host that you specified in the Access Manager
perspective. The default option is Auto-select, which will automatically
select the network card that can communicate with the target datastore. The
host that you specified in theAccess Manager perspective also appears by
default as well as any alias that you configured in the Datastore Properties
dialog box.
v Propagation ControlClick Add and select the source ID for any
subscription for which you want to prevent data from being replicated to
the target.
v Do not replicate data received from any subscriptionsEnable if you want
to prevent replication from all subscriptions.
v Select the datastore to handle the transferable workSpecify where
transferable work will be performed, in order to minimize impact on the
source or target datastore.
v Mark subscription as persistentEnable if you want to specify that the
subscription is persistent. A subscription can only be restarted automatically
if it is enabled for persistency.
10. Click OK.
Related concepts
Setting up subscriptions on page 49
Setting up subscriptions for datastores outside of your organization on page 58
Creating aliases for a target datastore on a private network connection on page
72
Using projects to organize your subscriptions on page 65
Related tasks
To add a subscription for an external target datastore on page 58

To modify a subscription
1. Click Configuration > Subscriptions.
2. Right-click on a subscription and select Properties.
3. You can modify the following:
v DescriptionType the description of the subscription.
v ProjectSelect a project or click New Project to create a new project.
4. If you specified an External target datastore when mapping your tables, you
can click Details and modify the appropriate settings.

50 InfoSphere Change Data Capture Management Console: Administration Guide

 Related concepts
Setting up subscriptions on page 49
Setting up subscriptions for datastores outside of your organization on page 58
Creating aliases for a target datastore on a private network connection on page
72
Related tasks
To modify a subscription for an external target datastore on page 59

To delete a subscription
1. Click Configuration > Subscriptions.
2. Ensure that replication for the subscription has ended.
3. Ensure that the subscription is connected to the target datastore.
4. If you are using InfoSphere CDC Version 5.2 and have a subscription with an
external target datastore, ensure that have removed the table mappings for the
subscription.
5. Right-click on a subscription and select Delete subscription.
Related tasks
To end replication on page 333
To delete a table mapping on page 128
To connect to a datastore on page 70

Specifying network settings for subscriptions

You can set some network communication settings for your subscription.

You can specify the TCP host that your source datastore will use to recognize the
target datastore when the computer where InfoSphere CDC is installed has
multiple network cards. This is useful if you want to specify a host that is different
from the host that you specified in InfoSphere CDC Access Manager.

You may also specify a firewall port for a subscription, which is useful if the
source and target datastores have a limited number of ports for communication
through a firewall.

See also:
To specify a TCP host for a subscription
To specify a firewall port for a subscription on page 52

To specify a TCP host for a subscription

1. Click Configuration > Subscriptions.
2. Right-click on a subscription and select Properties.
3. Click Advanced Settings.
4. Select the TCP host name for the subscription in the TCP Host drop down list.
Your source datastore will use this name to recognize the source database when
the computer where InfoSphere CDC is installed has multiple network cards.
This is useful if you want to specify a host that you specified in the Access
Manager perspective.
The default option is Auto-select which will automatically select the network
card that can communicate with the datastore. The host that you specified in

Setting up and configuring subscriptions 51

 the Access Manager perspective also appears by default as well as any aliases
that you configured in the Datastore Properties dialog box.
Related concepts
Specifying network settings for subscriptions on page 51
Creating aliases for a target datastore on a private network connection on page
72

To specify a firewall port for a subscription

1. Click Configuration > Subscriptions.
2. Right-click on a subscription and select Properties.
3. Click Advanced Settings.
4. Type the appropriate port number in the Firewall Port box if your source
datastore is behind a firewall.
Related concepts
Specifying network settings for subscriptions on page 51

Setting propagation control on subscriptions

You can use propagation control to prevent the replication of data from a
particular source. This is useful if you are using a bidirectional replication
configuration and prevents subscriptions from unnecessarily repeating operations
like inserting data.

See also:
To set propagation control on a subscription

To set propagation control on a subscription

1. Click Configuration > Subscriptions.
2. Right-click on a subscription and select Properties.
3. Click Advanced Settings.
4. Click Add in the Propagation Control area to select the source ID of the
subscription from which you want to prevent data from being replicated to the
target.
Table-level recursion prevention overrides this setting for a subscription. For
more information on how to set recursion prevention, see To change the
replication method of a table on page 322.
5. Select the Do not replicate data received from any subscriptions box if you
want to prevent data from being replicated to the target for all subscriptions.
Related concepts
Setting propagation control on subscriptions
Related tasks
To change the replication method of a table on page 322

Locking subscriptions within a datastore

Note: Multiuser configuration can be enabled for InfoSphere CDC version 6.3 Fix
Pack 3 and later. It is not available for InfoSphere CDC for z/OS or InfoSphere
CDC for IBM i.

52 InfoSphere Change Data Capture Management Console: Administration Guide

 Users can lock subscriptions within a datastore so that it is read-only to other
users. If you are a System Administrator enabled to perform user account and
datastore administration, you can also override this setting and unlock the
subscription so that it becomes available to other users.

See also:
To view subscription state details
To view subscription state details in the Subscription Active/Edit Panel
To lock a subscription for editing
To lock a subscription for editing in the Subscription Active/Edit Panel on
page 54
To unlock a subscription on page 54
To unlock a subscription in the Subscription Active/Edit Panel on page 54
To unlock a subscription (System Administrator) on page 54
To unlock a subscription in the Subscription Active/Edit Panel (System
Administrator) on page 55
To view the history report for a subscription on page 55

To view subscription state details

1. Ensure that you have the role of Operator, Administrator, or System
Administrator.
2. Click Configuration > Subscriptions.
3. Browse through the list of subscriptions.
Management Console displays an icon that indicates locked or available for
editing beside each subscription in the list.

To view subscription state details in the Subscription

Active/Edit Panel
1. Ensure that you have the role of Operator, Administrator, or System
Administrator.
2. Click Configuration > Subscriptions.
3. Ensure that the Subscription Active/Edit Panel appears under the list of
subscriptions.
4. Click the desired subscription in the list of subscriptions to view its details in
the Subscription Active/Edit Panel.

To lock a subscription for editing

1. Ensure that you have the role of Operator, Administrator, or System
Administrator.
2. Click Configuration > Subscriptions.
Management Console displays an icon that indicates locked or available for
editing beside each subscription in the list.
3. Right-click the subscription you want to edit from the list of subscriptions.
4. Click Start Editing to lock the subscription, which makes the subscription
read-only to other users and allows you to start editing it.

Setting up and configuring subscriptions 53

 To lock a subscription for editing in the Subscription
Active/Edit Panel
1. Ensure that you have the role of Operator, Administrator, or System
Administrator.
2. Click Configuration > Subscriptions.
3. Ensure that the Subscription Active/Edit Panel appears under the list of
subscriptions.
4. Click the desired subscription in the list of subscriptions to view its details in
the Subscription Active/Edit Panel.
5. Click the Start Editing button to lock the subscription, which makes the
subscription read-only to other users and allows you to start editing it.

To unlock a subscription
1. Ensure that you have the role of Operator, Administrator, or System
Administrator.
2. Click Configuration > Subscriptions.
Management Console displays an icon that indicates locked or available for
editing beside each subscription in the list.
3. Right-click the subscription you want to unlock from the list of subscriptions.
4. Click End Editing to unlock the subscription and allow other users to edit it.
5. Add a comment to log your changes for the subscription in the dialog that
displays.

To unlock a subscription in the Subscription Active/Edit Panel

1. Ensure that you have the role of Operator, Administrator, or System
Administrator.
2. Click Configuration > Subscriptions.
3. Ensure that the Subscription Active/Edit Panel appears under the list of
subscriptions.
4. Click the desired subscription in the list of subscriptions to view its details in
the Subscription Active/Edit Panel.
5. Click the End Editing button to unlock the subscription and allow other users
to edit it.
6. Add a comment to log your changes for the subscription in the dialog that
displays.

To unlock a subscription (System Administrator)

1. Ensure that you are a System Administrator and have the privileges to manage
datastores and user accounts.
2. Verify that the user who has locked the subscription has completed and saved
all work.
Management Console will notify the user, who currently has the subscription
locked, that their changes will be aborted and Management Console will be
terminated. This can result in lost in configuration if changes are currently
being saved.
3. Click Configuration > Subscriptions.
Management Console displays an icon beside each subscription that indicates
locked or available for editing beside each subscription in the list..
4. Right-click the subscription you want to unlock from the list of subscriptions.
54 InfoSphere Change Data Capture Management Console: Administration Guide
 5. Click End Editing to unlock the subscription, which aborts any unsaved
changes and makes the subscription available to other users.
6. Add a comment to log your changes for the subscription in the dialog that
displays.
7. Click OK.

To unlock a subscription in the Subscription Active/Edit Panel

(System Administrator)
1. Ensure that you are a System Administrator and have the privileges to manage
datastores and user accounts.
2. Verify that the user who has locked the subscription has completed and saved
all work.
Management Console will notify the user, who currently has the subscription
locked, that their changes will be aborted and Management Console will be
terminated. This can result in lost in configuration if changes are currently
being saved.
3. Click Configuration > Subscriptions.
4. Ensure that the Subscription Active/Edit Panel appears under the list of
subscriptions.
5. Click the desired subscription in the list of subscriptions to view its details in
the Subscription Active/Edit Panel.
6. Click the End Editing button to unlock the subscription, abort any unsaved
changes, and make the subscription available to other users.
7. Add a comment to log your changes for the subscription in the dialog that
displays.

To view the history report for a subscription

1. Click Configuration > Subscriptions.
2. Right-click the subscription you want to view from the list of subscriptions.
3. Select Show Edit History to see all the activities to and comments logged
against to the subscription.

Determining error handling for subscriptions

When an error occurs in an InfoSphere CDC for z/OS subscription, the global
error parameter for the datastore determines whether replication stops or continues
with error. You can use the subscription error handling options to override this, if
desired.

See also:
To set error handling for a subscription

To set error handling for a subscription

1. Ensure that you are connected to an InfoSphere CDC for z/OS datastore.
2. Click Configuration > Subscriptions.
3. Right-click on a subscription and select Properties.
4. Click Advanced Settings.
5. Select an option from the When mirroring list box to determine the action to be
performed when an error occurs while mirroring.

Setting up and configuring subscriptions 55

 v Use global End on Error settingApplies the ENDONERROR value for the
address space, as set in the CONFIG statement. This is the default value. For
more information on the CONFIG statement see the Modifying general product
configuration control statements section in your InfoSphere Change Data Capture
for z/OS documentation
v End on ErrorEnds mirroring after an error is detected on the target
database.
v Continue on ErrorMirroring continues after an error is detected on the
target database.
6. Select an option from the When refreshing list box to determine the action to
be performed when an error occurs during a refresh.
v Use global End on Error settingApplies the ENDONERROR value for the
address space, as set in the CONFIG statement. This is the default value. For
more information on the CONFIG statement see the Modifying general product
configuration control statements section in your InfoSphere Change Data Capture
for z/OS documentation
v End on ErrorEnds the refresh operation after an error is detected.
v Continue on ErrorContinues the refresh operation after the error is
detected.

Making subscriptions persistent

InfoSphere CDC may initiate a normal shutdown and end mirroring under the
following circumstances:
v Interruptions in network communications
v DB2 LUW deadlock or timeout errors for subscriptions that target DB2 LUW

To automatically restart continuous mirroring of subscriptions after a normal

shutdown of InfoSphere CDC due to the preceding scenarios, you can mark the
subscriptions as persistent.

When persistency is enabled and network communications terminate, InfoSphere

CDC attempts to automatically restart continuous mirroring for persistent
subscriptions at regular intervals. Attempts continue until an automatic restart is
successful or until the persistent subscription or the InfoSphere CDC for z/OS
address space is terminated.

In the event of a deadlock or timeout error with subscriptions that target DB2
LUW, an event message will indicate that the error is recoverable and if you mark
the subscription as persistent it will restart automatically. When restarted, the
subscription will apply the data that has been rolled back as a result of the error
and continue.

Subscriptions will not restart automatically if you intentionally end replication for
an active subscription by name. For InfoSphere CDC for z/OS subscriptions only,
automatic restart will still apply if you have ended replication for a group of
subscriptions by specifying the wild card character ('*') with the ENDTSMIR
command.

Persistency is only relevant to subscriptions that are used for continuous mirroring.
If a persistent InfoSphere CDC for z/OS subscription is used for Refresh or
Scheduled End (Net Change) mirroring and network communications are
interrupted, this subscription is restarted according to how the same subscription
was terminated the last time it was used for continuous mirroring. For all other

56 InfoSphere Change Data Capture Management Console: Administration Guide

 InfoSphere CDC replication engines, if a persistent subscription is used for Refresh
or Scheduled End (Net Change) mirroring and network communications are
interrupted, it will not be restarted automatically.

You can set how often InfoSphere CDC for z/OS attempts to automatically restart
continuous mirroring for all persistent subscriptions by modifying the
AUTORESTARTINTERVAL configuration control statement keyword. For more
information, see your InfoSphere CDC for z/OS documentation. For all other
InfoSphere CDC replication engines, you can set how often InfoSphere CDC
attempts to automatically restart continuous mirroring for all persistent
subscriptions through the mirror_auto_restart_interval_minutes system
parameter.

See also:
To mark a subscription as persistent

To mark a subscription as persistent

1. Click Configuration > Subscriptions.
2. Right-click on a subscription and select Properties.
3. Click Advanced Settings.
4. Select the Mark subscription as persistent check box.
The new persistency setting will not take effect until the subscription starts
mirroring.

Searching for tables used in replication

In order to make tables available for replication, you must create a subscription
and associate a source and target datastore. These datastores contain the tables you
want to use in replication. You may have more than one subscription using the
same table in replication. When you want to make the table unavailable from
replication, it becomes important to search for the table and identify which
subscriptions are using it replication activities.

See also:
To search for subscriptions that use a table in replication

To search for subscriptions that use a table in replication

1. Click Configuration > Datastores.
2. Select a datastore.
3. Right-click the datastore and select Replication Tables.
4. Expand the Available Tables tree to display the tables.
5. Select a table and click Properties to open the Table Properties dialog box.
6. Click the Subscriptions tab.
7. Click Search on the Subscriptions tab. If you do not want a case-sensitive
search, clear the Match case box.
8. In the search results, you can identify the subscription from the following:
v SubscriptionThe name of the subscription that uses the selected table.
v Used AsIdentifies whether the table is used as source or target.
v Replication MethodThe replication method for the selected table.

Setting up and configuring subscriptions 57

 v Table StatusIdentifies if the selected table has been refreshed, mirrored, or
parked.

Setting up subscriptions for datastores outside of your organization

You can add subscriptions that send data to a target datastore that is external to
your organization. In order to set up a subscription that sends data to an external
target datastore, the receiving organization must have installed InfoSphere CDC
Management Console and you need to find out the necessary authentication and
database details to connect to their target datastore.

External target datastores are not available in your Access Manager because they
reside outside of your organization or department, or your System Administrator
has not given you the permission to access it.

If you have received authorization from the company or organization to which you
are replicating data, then you can modify the properties of an external target
datastore, including the port number, owner, and password. System and database
information about external target datastores is provided by the organization or
department that owns that datastore.

You can also copy subscriptions that send data to an external target. This is a
time-saving mechanism.

If your organization is at the receiving end of replication activities co-ordinated

with another organization that is outside of your database security policy, then you
should see Unknown source datastores in your subscription list. This is because
you are receiving replicated data from a source datastore that is outside of your
security policy (and, therefore, to which you do not have access to) and the name
of the source datastore is not known to you.

See also:
To add a subscription for an external target datastore
To modify a subscription for an external target datastore on page 59

To add a subscription for an external target datastore

1. Ensure that you have the required information to connect to the external
target datastore.
2. Click Configuration > Subscriptions.
3. Right-click on a subscription and select New Subscription.
4. Type the name of the new subscription in the Name box.
All subscriptions that come from the same source datastore must have a
unique name and all subscriptions that go to the same target datastore must
have a unique Source ID. The source ID is automatically generated based on
truncating the subscription name to 8 characters. If you attempt to create a
subscription with a duplicate Source ID, an error will result and the
subscription will not be created. If this occurs, click Advanced Settings and
give the subscription a unique Source ID.
5. Type the description of the new subscription in the Description box.
6. If you want to include the new subscription in a project, select a project from
the Project list or click New Project to create a new project.
If you do not select a project, Management Console places the new
subscription into the Default Project.

58 InfoSphere Change Data Capture Management Console: Administration Guide

 7. Select <External> from the Target list and click Details.
8. Select the operating system from the Platform list.
9. Type the host name or IP address of the external target in the Host Name box.
10. Type the port number for the external target in the Target Port box.
11. Select the type of database for your external target that holds the InfoSphere
CDC metadata from the Database Type list.
The metadata tables are created when you install InfoSphere CDC. For more
information, see the appropriate InfoSphere CDC End-User Documentation.
12. Type the name of the metadata database in the Database Name box.
13. Type the name of the database user that owns the external target metadata in
the Owner box.
14. Type the password for the database user in the Password box.
15. Click OK.
16. If the subscription is sending data to an external target, you can specify a
source ID that makes the subscription identifiable for the receiving
organization. Click Advanced Settings and enter the source ID in the Source
ID box.
Related concepts
Setting up subscriptions for datastores outside of your organization on page 58
Related tasks
To modify a subscription for an external target datastore

To modify a subscription for an external target datastore

1. Ensure that you have the required information to connect to the external target
datastore.
2. Click Configuration > Subscriptions.
3. Right-click on a subscription with an external target datastore and select
Properties.
4. Click Details and make the necessary changes.
Related concepts
Setting up subscriptions for datastores outside of your organization on page 58
Related tasks
To add a subscription for an external target datastore on page 58

Copying subscriptions
Copying a subscription is a time-saving mechanism. If you have a subscription that
contains table mappings that you do not want to recreate, then you can copy the
subscription under a new name. You can also recreate an existing subscription with
the same table mappings if you want to setup a replication scenario within in
another environment.

See also:
To copy a subscription
To copy a subscription for an external target datastore on page 61

To copy a subscription
1. Click Configuration > Subscriptions.
2. Right-click on a subscription and select Copy Subscription.

Setting up and configuring subscriptions 59

 3. Type a name for the subscription in the Name box.
All subscriptions that come from the same source datastore must have a
unique name and all subscriptions that go to the same target datastore must
have a unique Source ID. The source ID is automatically generated based on
truncating the subscription name to 8 characters. If you attempt to create a
subscription with a duplicate Source ID, an error will result and the
subscription will not be created. If this occurs, click Advanced Settings and
give the subscription a unique Source ID.
4. Type a description for the subscription in the Description box.
5. If you want to include the new subscription in a project, select a project from
the Project list or click New Project to create a new project.
If you do not select a project, Management Console places the new
subscription into the Default Project.
6. Click Next.
7. Select the source datastore for the new subscription from the New Source
Datastore list.
8. Select the databases and owners for the new source datastore under New
Name.
9. If you want to specify advanced settings for the subscription, click Advanced
Settings. Modify the following properties and click OK, then click Next.
v Source IDSpecify the source ID for the new subscription.
v Firewall PortSpecify a port number for the new subscription.
v TCP HostSpecify the TCP host that your source datastore will use to
recognize the target datastore when the computer where InfoSphere CDC is
installed has multiple network cards. This is useful if you want to specify a
host that is different from the host that you specified in the Access Manager
perspective. The default option is Auto-select, which will automatically
select the network card that can communicate with the target datastore. The
host that you specified in theAccess Manager perspective also appears by
default as well as any alias that you configured in the Datastore Properties
dialog box.
v Propagation ControlClick Add and select the source ID for any
subscription for which you want to prevent data from being replicated to
the target.
v Do not replicate data received from any subscriptionsEnable if you want
to prevent replication from all subscriptions.
v Select the datastore to handle the transferable workSpecify where
transferable work will be performed, in order to minimize impact on the
source or target datastore.
v Mark subscription as persistentEnable if you want to specify that the
subscription is persistent. A subscription can only be restarted automatically
if it is enabled for persistency.
10. Click Next.
11. Select the target datastore for the new subscription from the New Target
Datastore list.
12. Select the databases and owners for the new target datastore under New
Name.
13. If you want to specify advanced settings for the subscription, click Advanced
Settings. Modify the following properties and click OK, then click Next.
v Source IDSpecify the source ID for the new subscription.
v Firewall PortSpecify a port number for the new subscription.

60 InfoSphere Change Data Capture Management Console: Administration Guide

 v TCP HostSpecify the TCP host that your source datastore will use to
recognize the target datastore when the computer where InfoSphere CDC is
installed has multiple network cards. This is useful if you want to specify a
host that is different from the host that you specified in the Access Manager
perspective. The default option is Auto-select, which will automatically
select the network card that can communicate with the target datastore. The
host that you specified in theAccess Manager perspective also appears by
default as well as any alias that you configured in the Datastore Properties
dialog box.
v Propagation ControlClick Add and select the source ID for any
subscription for which you want to prevent data from being replicated to
the target.
v Do not replicate data received from any subscriptionsEnable if you want
to prevent replication from all subscriptions.
v Select the datastore to handle the transferable workSpecify where
transferable work will be performed, in order to minimize impact on the
source or target datastore.
v Mark subscription as persistentEnable if you want to specify that the
subscription is persistent. A subscription can only be restarted automatically
if it is enabled for persistency.
14. Click Next.
15. If the existing subscription contains user exits, then specify their location for
the new subscription under New Location and click Next.
16. If you built a derived column, an expression, or a row-filtering expression that
uses the %SELECT column function, then confirm the list of displayed
expressions and click Next.
After copying the subscription, you may have to change these expressions
manually.
17. Review the list of changes and click Finish.
Related concepts
Copying subscriptions on page 59
Related reference
Retrieve column%SELECT on page 255

To copy a subscription for an external target datastore

1. Click Configuration > Subscriptions.
2. Right-click on a subscription and select Copy Subscription.
3. Type the name of the new subscription in the Name box.
4. Type the description of the new subscription in the Description box.
5. If you want to include the new subscription in a project, select a project from
the Project list or click New Project to create a new project.
If you do not select a project, Management Console places the new
subscription into the Default Project.
6. Click Next.
7. Select the new source datastore for the subscription from the New Source
Datastore list.
8. Select the databases and owners for your new source datastore under New
Name.
9. Click Next.
10. If you want to specify advanced settings, click Advanced Settings.

Setting up and configuring subscriptions 61

 11. If you want to change the properties of the external target datastore, then
make the necessary changes and click Next.
12. Review the list of changes and click Finish.
Related concepts
Copying subscriptions on page 59

Upgrading existing Transformation Server subscriptions to InfoSphere

CDC
Supported upgrade paths

v Transformation Server for Microsoft SQL Server version 5.3.4 to InfoSphere CDC for
Microsoft SQL Server version 6.2
v Transformation Server for Oracle version 6.0 (Service Pack 3 OR Service Pack 3 TFE 28
or later) to InfoSphere CDC for Oracle version 6.5
Supported upgrade combinations
When you upgrade a source or target product from Transformation Server to either
InfoSphere CDC for Microsoft SQL Server version 6.2 or InfoSphere CDC for Oracle
version 6.5, then the corresponding source or target product can be of any other platform,
provided it meets the minimum version requirements:
v InfoSphere CDC version 6.3 (any platform) or later
v IBM i version 6.1 TFE 1 or later
v Transformation Server for z/OS version 5.4 or later
Also, when upgrading combinations between Transformation Server for Microsoft SQL
Server and Transformation Server for Oracle, whether either of these products is used as a
source or a target of replication, you must always upgrade Transformation Server for
Microsoft SQL Server to InfoSphere CDC for Microsoft SQL Server version 6.2 before
upgrading to InfoSphere CDC for Oracle version 6.5.

If you have existing subscriptions for Transformation Server, then you can upgrade
these subscriptions to InfoSphere CDC by completing the following tasks:
v Upgrade subscriptions by selecting new names, new source IDs, and source and
target datastores.

Note: Transformation Server for Microsoft SQL Server version 5.3.4 supports
multiple databases. InfoSphere CDC for Microsoft SQL Server version 6.2
supports a single database. If you are upgrading a subscription that uses
multiple databases, such as database1.user.source_table ->
database2.user.target_table, ... databaseY.user.target_table you must
install InfoSphere CDC for Microsoft SQL Server version 6.2 on database1,
database2, ...databaseY to upgrade the subscription.
v After upgrading, you must transfer the bookmark from your original
subscription to the new upgraded subscription. Or, you can perform a refresh on
the upgraded subscription, however you would lose your current position in the
log. If you find you need to resort back to your original subscription after the
upgrade, then you can transfer the bookmark to the original subscription.
v After transferring the bookmark to the new subscription, you can choose to clear
the log position for the original subscription. This task is optional and will
prevent you from resuming replication with the original subscription. This
means that you cannot resort back to Transformation Server for replication
activities. Therefore, only clear the log position on the original subscription
when certain you no longer need to replicate with that subscription. If the

62 InfoSphere Change Data Capture Management Console: Administration Guide

 upgraded subscription is not running as expected and you want to resume
mirroring with the original subscription, you must refresh the tables in the
original subscription so that log position is reset to start from a new capture
point.

Considerations:
v Propagation control settings will not be included in the migration.
v InfoSphere CDC for Oracle uses the single scrape mechanism, which enables it
to only begin replication from one bookmark position. Once you begin
replication on a subscription, you cannot set a bookmark position that
InfoSphere CDC for Oracle has already passed. For this reason, it is important to
note that if you have multiple subscriptions that need to be upgraded, you must
upgrade all subscriptions and transfer each of the bookmarks before starting
replication on any of these subscriptions.

See also:
To upgrade a subscription
To transfer a bookmark from the original subscription to the upgraded
subscription on page 64
To clear the log position on the original subscription on page 64

To upgrade a subscription
1. Ensure that you have installed the correct product version you want to
upgrade to. For example, if you are upgrading to InfoSphere CDC for Oracle
version 6.5, then you need to install this product in addition to having an
existing installation of Transformation Server for Oracle version 6.0 (Service
Pack 3 TFE 28 and above).
2. Ensure that you perform the upgrade during a period of time when there is
low transaction activity taking place in your database.
3. Ensure that you have created a new datastore for the InfoSphere CDC product
you want to upgrade to.
4. Ensure that the new datastore is associated to the same database that contains
the tables being replicated by your existing installation of Transformation
Server.
5. Log in to Management Console.
6. Connect to the datastore that is associated with your existing installation of
Transformation Server.
7. Connect to the new datastore that is associated with your new installation of
InfoSphere CDC.
8. Click Configuration > Subscriptions.
9. Select the subscription you want to upgrade to InfoSphere CDC. This
subscription contains the same datastore that is associated with your existing
installation of Transformation Server. You can select and upgrade more than
one subscription at a time.
10. Click Subscription > Upgrade > Upgrade Subscription.
11. Click Continue if you want to upgrade the subscription without assistance
from Product Support.
12. Type a new name for the subscription in the New Name box.
13. Type a new source ID for the subscription in the New Source ID box.
14. Select a new source datastore for the subscription in the Source Datastore box.
15. Select a new target datastore for the subscription in the Target Datastore box.

Setting up and configuring subscriptions 63

 16. Click OK.
17. View the report.
After upgrading your subscription, Management Console displays an upgrade
report that outlines any issues encountered during the upgrade process to
InfoSphere CDC.
Related tasks
To log in to Management Consoleby connecting to Access Server on page 10
To connect to a datastore on page 70

To transfer a bookmark from the original subscription to the

upgraded subscription
1. Ensure that you have already upgraded your subscriptions from
Transformation Server to InfoSphere CDC.
2. Click Configuration > Subscriptions.
3. Click Subscription > Upgrade > Transfer Bookmark. Management Console
displays all subscriptions for which you can transfer the bookmark.
4. Enable the Transfer to New Subscription check box for subscriptions for which
you want to transfer the bookmark.
5. To view the upgrade report for the subscription, click View Upgrade Report... .
6. Enable the After transferring bookmark... check box if you want to start
mirroring after transferring the bookmark. If you are upgrading subscriptions
for InfoSphere CDC for Oracle, then ensure you have upgraded and transferred
the bookmarks of all subscriptions before enabling this check box.
7. Click Transfer Bookmark to transfer the bookmark to the specified
subscriptions. You can resume mirroring with these subscriptions.
After transferring the bookmark, Management Console displays a report that
outlines any issues encountered during the bookmark transfer process.
Related tasks
To upgrade a subscription on page 63
To clear the log position on the original subscription

To clear the log position on the original subscription

1. Ensure that you have already upgraded your subscriptions from
Transformation Server to InfoSphere CDC.
2. Click Configuration > Subscriptions.
3. Click Subscriptions > Upgrade > Clear Log Position.
Management Console displays all subscriptions for which you can clear the log
position.
4. Enable the Clear Log check box for subscriptions for which you want to clear
the log position.
5. Click Clear Log Position to set the replication method for the specified
subscriptions to Refresh.

64 InfoSphere Change Data Capture Management Console: Administration Guide

 Related tasks
To upgrade a subscription on page 63
To transfer a bookmark from the original subscription to the upgraded
subscription on page 64

Reverting to Transformation Server

Supported downgrade paths

v InfoSphere CDC for Microsoft SQL Server version 6.2 to Transformation Server for
Microsoft SQL Server version 5.3.4
v InfoSphere CDC for Oracle version 6.5 to Transformation Server for Oracle version 6.0
Service Pack 3 TFE 28 or later

You can revert from InfoSphere CDC to Transformation Server when you want to
resume replication activities with the original subscription.

If this is the case, then you must ensure that the original subscription has an
existing log position and it has not been cleared. Otherwise, you cannot resume
replication activities with that subscription unless you perform a refresh on it. In
order to continue replication activities from the current log position, you must
transfer the bookmark from the upgraded subscription to the original subscription.

See also:
To downgrade a subscription

To downgrade a subscription
1. Ensure you have not cleared the log position on the original subscription.
2. Click Configuration > Subscriptions.
3. Click Subscription > Upgrade > Transfer Bookmark. Management Console
displays all subscriptions for which you can transfer the bookmark.
4. Enable the Transfer to Original Subscription check box for subscriptions for
which you want to transfer the bookmark.
5. To view the upgrade report for the subscription, click View Upgrade Report... .
6. Enable the After transferring bookmark... check box if you want to start
mirroring after transferring the bookmark. If you are upgrading subscriptions
for InfoSphere CDC for Oracle, then ensure you have transferred the
bookmarks of all subscriptions before enabling this check box.
7. Click Transfer Bookmark to transfer the bookmark to the specified
subscriptions. You can resume mirroring with these subscriptions.
After transferring the bookmark, Management Console displays a report that
outlines any issues encountered during the bookmark transfer process. This
report is displayed whether or not errors are encountered during the transfer
bookmark process.

Using projects to organize your subscriptions

Projects let you group your subscriptions into categories to reflect your
organizational or operational needs.

Organizational Approach for ProjectsThe organizational approach is useful if

you want to group your subscriptions according to their current state of

Setting up and configuring subscriptions 65

 development. In many working environments, organizations prefer to test an
InfoSphere CDC replication configuration before promoting the configuration to a
production environment.

If you have subscriptions that are still in development, others that are being tested,
and some that have been promoted to production, you may want to group your
subscriptions in projects according to their current development state. For example,
you can use Test, Development, and Production for project names. As you finish
development or testing of a subscription, you can then move the subscription to
the appropriate project.

Operational Approach for ProjectsThe operational approach is useful if you are

creating subscriptions that relate to particular departments or operations within
your organization. For example, you may have subscriptions that relate to human
resources, finance, or sales. In this case, you may want to organize your
subscriptions into projects that reflect these particular operations or departments.

See also:
To add a project
To rename a project
To delete a project

To add a project
1. Click Configuration > Subscriptions.
2. Right-click in the Subscriptions view and select Project > Add New Project.
3. Enter a unique name for your project.
Related concepts
Using projects to organize your subscriptions on page 65
Related tasks
To rename a project
To delete a project

To rename a project
1. Click Configuration > Subscriptions.
2. Right-click on a project and select Project > Rename Project.
3. Enter a new name for your project.
Related concepts
Using projects to organize your subscriptions on page 65
Related tasks
To add a project
To delete a project

To delete a project
1. Click Configuration > Subscriptions.
2. Right-click on a project and select Project > Delete Project.
Management Console will delete the project and move all subscriptions to your
Default project.

66 InfoSphere Change Data Capture Management Console: Administration Guide

 Related concepts
Using projects to organize your subscriptions on page 65
Related tasks
To rename a project on page 66
To add a project on page 66

Exporting and importing projects

Every user of Management Console will have a different approach to organizing
their projects and subscriptions. To share your project organization with other
users, you can export your projects to a CSV template on your local computer.
Other users can then import the CSV template into Management Console.

See also:
To export projects
To import projects

To export projects
1. Click Configuration > Subscriptions.
2. Right-click on a project and select Project > Export Projects.
3. Type a name for the template in the File Name box.
4. Click Save.
Related concepts
Exporting and importing projects
Related tasks
To import projects

To import projects
1. Click Configuration > Subscriptions.
2. Right-click on a project and select Project > Import Projects.
Existing projects will be deleted during project import.
3. Select the CSV template that you want to import into Management Console and
click Open.
You will have to restart Management Console or reconnect to Access Server to
see the changes.
Related concepts
Exporting and importing projects
Related tasks
To export projects

Setting up and configuring subscriptions 67

68 InfoSphere Change Data Capture Management Console: Administration Guide
Setting up datastores for replication
Datastores are logical entities that represent the data files and processes required to
accomplish data replication. Each datastore represents the database or target
destination to which you want to connect. Tables made available for replication are
contained in a datastore. Depending on the database platform on which you have
installed InfoSphere CDC, you can connect to datastores on several different
platforms, including DB2 for i, DB2 for z/OS, DB2 for LUW, IBM InfoSphere
DataStage, IBM solidDB, and IBM Informix Dynamic Server, Microsoft SQL
Server, Oracle, Sybase, Teradata, and InfoSphere CDC for Event Server.

In this section, you will learn:

Understanding the Datastores view
Connecting to a datastore on page 70
Shutting down a datastore on page 70
Updating access parameters for a subscription on page 71
Setting system parameters on source and target datastores on page 71
Creating aliases for a target datastore on a private network connection on
page 72

Understanding the Datastores view

The Datastores view is located in the Configuration perspective in Management
Console. The functionality options and what the Datastores view looks like to a
user depends on that user's role. A user must have a role of System Administrator,
Administrator, or Operator in order to see this view.

Note that users with the Monitor role can connect to datastores to which they have
access using the Connect to datastore button located above the Subscriptions view
of the Monitoring perspective, even though they cannot see the Datastores view.

Depending on the role that your user ID has, you can do the following in this
view:

Functions Roles
Connect to datastores v System Administrator
v Administrator
v Operator
v Monitor
Configure notifications on source or target datastores v System Administrator
v Administrator
v Operator
Configure properties on datastores v System Administrator
v Administrator (can configure
properties except for system
parameters)
View, create or modify replication tables v System Administrator
v Administrator

Copyright IBM Corp. 2008, 2011 69

 Related concepts
Logging in to Management Console by connecting to Access Server on page 10
Setting up datastores for replication on page 69

Connecting to a datastore
Before you can connect to a datastore, you must have user access to a datastore. If
you do not see a datastore listed, request your System Administrator to set access
parameters for you in the Access Manager perspective in Management Console.

By default, Management Console connects to all datastores that you have access to
when you log in to Management Console by connecting to Access Server. You can
turn off this behavior in Edit > Preferences. If the Connect to Datastores
Automatically preference is disabled, you must manually connect to each
datastore.

To see whether or not you are connected to a datastore, use the Datastores view.

To see a summary of your datastore connection status, refer to the bottom right
section of Management Console. This section shows the number of connections
established. If Management Console cannot establish a connection with a particular
datastore, then this datastore is listed with the following icon: . Click the icon to
view general information about the datastore and possible reasons as to why a
connection could not be established.

See also:
To connect to a datastore
To disconnect from a datastore

To connect to a datastore
1. Ensure that you have user access to the datastore.
2. Click File > Connect to Datastores.
3. Select the datastore.
4. Click Connect.
Related concepts
Assigning users to datastores on page 38

To disconnect from a datastore

1. Ensure that you have user access to the datastore
2. Click Configuration > Datastores.
3. Select the datastore.
4. Click File > Datastore > Disconnect.
Related concepts
Assigning users to datastores on page 38

Shutting down a datastore

Note: This information does not apply to InfoSphere CDC for z/OS datastores.

70 InfoSphere Change Data Capture Management Console: Administration Guide

 When you want to end all replication processes for an InfoSphere CDC replication
engine to perform database or operating system maintenance activities, you must
shut down the associated datastore in Management Console. This ends replication
on all active subscriptions.

You can also use the command-line tools that are available with your InfoSphere
CDC replication engine to end all replication processes.

See also:
To shut down a datastore

To shut down a datastore

1. Click Configuration > Datastores.
2. Right-click on a datastore and select Shut down datastore.

Updating access parameters for a subscription

When configuring a datastore in Access Manager, you must specify the access
parameters that InfoSphere CDC uses to connect to the database. Access
parameters include information such as a user ID, password, host name, and port.
If at some point you decide to change access parameters for a datastore, then you
need to update each subscription that uses this datastore as a target in
Management Console.

See also:
To update access parameters for a subscription

To update access parameters for a subscription

1. Click Configuration > Datastores.
2. Right-click on a datastore and select Properties.
3. Click General.
4. Click Update Related Subscriptions.
5. If there are any active subscriptions, click End Replication on each active
subscription.
6. Click Update.
7. Restart Management Console.

Setting system parameters on source and target datastores

You can add, modify, or delete system parameters for datastores. System
parameters let you customize the behavior of InfoSphere CDC in your replication
environment. You can specify system parameters in Management Console or
modify system parameters on the replication servers by performing
server-dependent operations. When you change the value of a system parameter
for a particular source or target datastore, all users that have access to that
datastore will see the change as well.

The default values for most system parameters should be adequate. However,
depending on your requirements, you can modify the a system parameter to
specify a behavior for InfoSphere CDC that is different than the default.

See also:

Setting up datastores for replication 71

 To add a system parameter
To modify a system parameter
To delete a system parameter

To add a system parameter

1. Click Configuration > Datastores.
2. Right-click on a datastore and select Properties.
3. Click Add on the System Parameters tab.
4. Type the name of the parameter in the Parameter Name box.
5. Type the value in the Value box.
6. Click OK.
Related concepts
Setting system parameters on source and target datastores on page 71

To modify a system parameter

1. Click Configuration > Datastores.
2. Right-click on a datastore and select Properties.
3. Select a system parameter on the System Parameters tab.
4. Click Modify.
5. Type a value in the Value box.
6. Click OK.
Related concepts
Setting system parameters on source and target datastores on page 71

To delete a system parameter

1. Click Configuration > Datastores.
2. Right-click on a datastore and select Properties.
3. Select a system parameter on the System Parameters tab.
4. Click Delete.
Related concepts
Setting system parameters on source and target datastores on page 71

Creating aliases for a target datastore on a private network connection

The Access Manager perspective uses the host name or the IP address you
specified to connect to your target datastore. If you want to create a subscription
that replicates data to a target datastore on a private network connection, then you
need to identify the name your source datastore uses to recognize that target
datastore. Depending on your environment, this could be a host name, IP address,
Data Source Name (DSN), etc. You can identify this name by creating an alias in
Management Console. For more information on how to set up connection
parameters to connect to a datastore, see To set connection parameters on a
datastore on page 35.

See also:
To add an alias on page 73
To modify an alias on page 73
To delete an alias on page 73

72 InfoSphere Change Data Capture Management Console: Administration Guide

To add an alias
1. Click Configuration > Datastores.
2. Right-click on a datastore and select Properties.
3. Click Add on the Alias tab.
4. Type a name in the Alias box.
Related concepts
Creating aliases for a target datastore on a private network connection on page
72

To modify an alias
1. Click Configuration > Datastores.
2. Right-click on a datastore and select Properties.
3. Select an alias on the Alias tab.
4. Click Modify.
5. Type a name in the Alias box.
Related concepts
Creating aliases for a target datastore on a private network connection on page
72

To delete an alias
1. Click Configuration > Datastores.
2. Right-click on a datastore and select Properties.
3. Select an alias on the Alias tab.
4. Click Delete.
Related concepts
Creating aliases for a target datastore on a private network connection on page
72

Setting up datastores for replication 73

74 InfoSphere Change Data Capture Management Console: Administration Guide
Managing tables available for replication
You can view the tables that are available for replication, update the definition of
the table if you have changed the structure of the table in your database, and
remove any tables from replication in Management Console.

In this section, you will learn:

Updating, removing, and viewing tables for replication
Updating the definition of a mapped source and target table in a subscription
on page 76

Updating, removing, and viewing tables for replication

When you map tables, the tables are added to the set of tables available for
replication.

If you have changed the definition of either a source or target table in your
RDBMS (relational database management system), you will need to update its
definition in Management Console.

If you have deleted tables from your RDBMS (relational database management
system), then you also need to remove the table from replication.

Use the Replication Tables dialog box to update the definition of a table that has
changed in your database, to view the properties of tables, and to remove tables no
longer in use by subscriptions for replication.

You can make tables available for replication by selecting tables for a table
mapping in the Map Tables wizard.

See also:
To update the definition of a table
To remove a table from Management Console on page 76
To view the properties of a table on page 76

To update the definition of a table

1. Click Configuration > Datastores.
2. Select a datastore.
3. Right-click and select Replication Tables.
4. Expand the database user or schema until you display its tables.
Tables are only available if you have created a table mapping in the Map
Tables wizard.
5. Select the table that has changed in your relational database management
system and click Update. The status of the table mapping will change to
Parked.

Copyright IBM Corp. 2008, 2011 75

 Related concepts
Updating, removing, and viewing tables for replication on page 75

To remove a table from Management Console

1. Ensure that there are no subscriptions using the tables in replication. Delete any
table mappings, if necessary.
2. Click Configuration > Datastores.
3. Select a datastore.
4. Right-click and select Replication Tables.
5. Expand the database user or schema until you display its tables.
Tables are only available if you have created a table mapping in the Map
Tables wizard.
6. Select the table and click Remove.
Related concepts
Searching for tables used in replication on page 57
Updating, removing, and viewing tables for replication on page 75
Related tasks
To delete a table mapping on page 128

To view the properties of a table

1. Click Configuration > Datastores.
2. Select a datastore.
3. Right-click and select Replication Tables.
4. Expand the database user or schema until you display its tables.
Tables are only available if you have created a table mapping in the Map
Tables wizard.
5. Select the table and click Properties.
Related concepts
Updating, removing, and viewing tables for replication on page 75

Updating the definition of a mapped source and target table in a

subscription
Once you change the structure of a mapped source or target table in your
database, you must update the definition of the table in Management Console so
that subscriptions are aware of the new structure.
v Updating the definition of a source tableIf you change the definition of a
source table (add a new column, set column constraints, or new foreign key
dependencies) in your database, then you have to update the definition of the
table in Management Console. Management Console requires you to update the
source table so that the new structure is available for configuration when editing
your table mapping details. For example, if you have added a new column on
the source table, then you may want to map this new column to a target
column.
v Updating the definition of a target tableIf you change the definition of a
target table (add a new column, set column constraints, or new foreign key
dependencies) in your database, then you need to update the definition of the
target table in Management Console. Management Console requires you to
update the target table so that the new structure is available for configuration

76 InfoSphere Change Data Capture Management Console: Administration Guide

 when editing your table mapping details. For example, if you have added a new
column on the target table, then you may want to map a source column to the
target column.

See also:
To update the definition of a source table
To update the definition of a target table

To update the definition of a source table

1. Click Configuration > Subscriptions.
2. Select the subscription that contains the mapped source and target tables.
3. Select and right-click on the table mapping in the Table Mappings area.
4. Select Update Table Definition > Source Table.
5. Select each active subscription and click End Replication.
6. Select Update metadata definition of table, if you want the source catalog
updated with the current definition of the source table selected.
7. Select Describe, if you want the source database to send its definition of the
table to the target. By default, this option is selected.
8. Select Reassign, if you want to reassign the current target table with the
definition in the source table. By default, this option is selected.
9. Click Update. The status of the table mapping is changed to Parked.
10. Verify your mapping details.
If you have added a new column and you want InfoSphere CDC to replicate
data from this column, then you need to map that column to the target.
11. If you want to restart mirroring on the subscription, you need to synchronize
your source and target tables so that InfoSphere CDC can set a log position.
Related concepts
Flagging a source table for refresh on page 317
Updating the definition of a mapped source and target table in a subscription on
page 76
Mapping source columns to target columns on page 149

To update the definition of a target table

1. Click Configuration > Subscriptions.
2. Select the subscription.
3. Select and right-click on the table mapping in the Table Mappings area.
4. Select Update Table Definition > Target Table.
5. Click End Replication on each active subscription.
6. Click Update.
7. Verify your table mapping details.
If you have added a new column to your target table and you want InfoSphere
CDC to replicate data to the column, then you need to map a source column to
the new target column.
Related concepts
Mapping source columns to target columns on page 149
Updating the definition of a mapped source and target table in a subscription on
page 76

Managing tables available for replication 77

78 InfoSphere Change Data Capture Management Console: Administration Guide
Mapping tables
After defining a subscription in Management Console, use the Map Tables wizard
to map source and target tables. Subscriptions can contain as many table mappings
as necessary. The number of table mappings you create depends on how many
source tables you want InfoSphere CDC to replicate to the target system.

In this section, you will learn:

Table Mappings view
Understanding filtering and mapping tables on page 82
Mapping using standard replication on page 83
Mapping using LiveAudit on page 91
Mapping using InfoSphere DataStage on page 96
Generating an InfoSphere DataStage definition file for a subscription on page
100
Mapping using Adaptive Apply on page 102
Mapping to summarize data on page 107
Mapping to consolidate data (one-to-one) on page 110
Mapping to consolidate data (one-to-many) on page 113
Mapping to a datastore outside of your organization on page 117
Mapping to a JMS Message Destination using InfoSphere CDC Event Server
on page 118
InfoSphere CDC Event Server receives replicated row-level operations (inserts,
updates, deletes) from your source database and transforms these rows into
XML.
Remapping a source table on page 125
Copying selected table mappings on page 126
Deleting table mappings on page 128
Exporting and importing subscriptions and selected table mappings on page
129

Table Mappings view

After defining a subscription in InfoSphere CDC Management Console, you can
use the Map Tables wizard to map source and target tables. Subscriptions can
contain as many table mappings as necessary, and the number of table mappings
you create depends on how many source tables you want InfoSphere CDC to
replicate to the target system. The table mappings that you create with the wizard
are displayed in this view, and when you select a subscription with table
mappings, the table mappings are loaded into the view.

Use the Table Mappings view to see a list of mapped source and target tables
within a subscription. You can also view the mapping type, replication method,
and status of each table mapping.

In this view, you can do the following:

v View a list of mapped source and target tables within a subscription
v View the mapping type, replication method, and status of each table mapping

Copyright IBM Corp. 2008, 2011 79

 v Change the replication method of a table mapping
v Flag a source table for refresh before mirroring
v Set a log position on a source table
v Park a table mapping from replication
v Change the refresh order on a table mapping
v Customize the kind of information you want to map to target columns in a
subscription.
v Include or exclude rows or columns for replication.
v Add, modify, and delete a data translation.
v Specify how InfoSphere CDC converts character sets on source and target
columns during replication.
v Set how a target table responds to changes made on the source table.
v Control the truncation of the target table in response to a table-level clear or
refresh operation so that all or some of the rows are preserved.
v Set member identifiers for multi-member source tables.
v Configure conflict detection and resolution.
v Configure user exits.

A number of tabs containing mapping information details are available in the

Table Mappings view when you select a table mapping in this view. The specific
tabs that are loaded for display will differ depending on which databases and
which version of corresponding InfoSphere CDC agents on the source and target
systems for the selected table mapping. The following list contains descriptions for
each of these tabs:
v Column MappingsUse the Column Mappings tab to perform the following
tasks:
map source columns to target columns
create a derived column on the source table
build custom expressions and map to target columns
map accumulation and deduction expressions for summarization mapping
types
map journal control fields
map source and target columns automatically
v FilteringUse the Filtering tab to perform the following tasks:
define a row-filtering expression to include or exclude rows from replication
filter columns
enable critical column selection
v TranslationUse the Translation tab in InfoSphere CDC version 6.3, and earlier,
to perform the following tasks:
set translations
set translation conversions
set multibyte character encoding conversions (this is a new feature and only
available in specific platforms and versions of InfoSphere CDC)
v EncodingUse the Encoding tab in InfoSphere CDC version 6.5, and later, to
perform the following tasks:
set encodings
set encoding conversions

80 InfoSphere Change Data Capture Management Console: Administration Guide

 set multibyte character encoding conversions (this is a new feature and only
available in specific platforms and versions of InfoSphere CDC)
v ConflictsUse the Conflicts tab when you want InfoSphere CDC to detect
conflicts on target columns and resolve them:
source row wins
target row wins
largest value wins
smallest value wins
user exits
v OperationsUse the Operation tab to specify the row-level or table-level
operations you want InfoSphere CDC to apply on a target table when there is a
corresponding row-level or table-level operation on the source table. If you do
not want InfoSphere CDC to detect conflicts on target columns, then you can
select None.
v User ExitsUse the User Exit tab when you want InfoSphere CDC to detect
conflicts on target columns and resolve them. You can perform the following
tasks:
identify the name and type of user exit you want InfoSphere CDC to call
specify at which event or action you want InfoSphere CDC to call the user
exit (either before or after a row-level or table-level operation)
v Flat FileAppears if you have an InfoSphere DataStage subscription that was
created using the flat file method. It includes the following information:
LocationSpecifies the location of the directory for output of the flat files.
Record FormatSpecifies the format of the records to be generated.
Custom Data FormatSpecifies the name of the Java class used, if any, to
format the data.
v Direct ConnectAppears if you have an InfoSphere DataStage subscription that
was created using the direct connect method. It includes the following
information:
Record FormatSpecifies the format of the records to be generated.
Custom Data FormatSpecifies the name of the Java class used, if any, to
format the data.

Mapping tables 81
 Related concepts
Setting up and configuring subscriptions on page 47
A subscription is a connection that is required to replicate data between a source
datastore and a target datastore. It contains details of the data that is being
replicated and how the source data is applied to the target. Subscriptions use
datastores as the source or target of replicated data. You can view the datastores
that your subscriptions are using in the Source and Target columns of the
Subscriptions view.
Mapping tables on page 79
Mapping columns on page 149
Filtering rows and columns on page 291
Setting data translations on column mappings on page 159
Replicating multibyte (MBCS) and double-byte (DBCS) character data on page
163
Controlling row operations on page 301
Controlling table operations on page 189
Setting member identifiers on page 171
Setting conflict detection and resolution on page 295
Configuring table-level user exits on page 195

Understanding filtering and mapping tables

Using filtering optimizes system performance and enables you to navigate more
efficiently if you have a large number of nodes (databases, schemas, libraries, or
tables) to navigate.

Depending on your InfoSphere CDC replication platform, and the Minimum

Number threshold value specified for filtering in Edit > Preferences > Prompts >
Filtering, the Filter Databases, Filter Schemas, Filter Libraries, or Filter Tables
dialog box opens when you expand a datastore, database, or schema respectively
when mapping tables.

The Filter Databases window can appear with the two replication platforms that
can contain multiple databases, Transformation Server version 5.3 for Microsoft
SQL Server, and z/OS.

For other replication platforms that contain single database instances, the Filter
Schemas window (for Oracle) or Filter Libraries window (for IBM i) can open, and
Filter Tables dialog boxes can open when you expand the respective nodes under a
datastore.

See also:
To manually define a filter
Related concepts
Setting advanced preferences on page 15

To manually define a filter

1. Select the node (datastore, database, or schema) and click Specify Filter.
Depending on your InfoSphere CDC replication platform, and the Minimum
Number value specified for filtering in Edit > Preferences > Advanced >
Filtering, the Filter Databases, Filter Schemas, or Filter Tables dialog box opens
when you expand a datastore, database, or schema respectively.

82 InfoSphere Change Data Capture Management Console: Administration Guide

 2. Select a method of filtering:
v Select Show all schemas or Show all tables to
v Select Show filtered schemas or Show filtered tables, then you can
Click Import to load a previously exported set of filtering criteria, or
Manually enter the filtering variables you want to use in the provided
field and click Export to save the criteria in a .txt file
3. Click OK.

Mapping using standard replication

If you want your target table to keep an updated image of the data contained in
the source table, then map your source and target tables using standard replication.
Your source and target tables can be of different types and you can transform the
data that you replicate between the source and the target. Under standard
replication, InfoSphere CDC applies the same operation that occurred on the
source table to the target table. A row insert operation on the source table
determines a row insert operation on the target table, and so on. You can map
tables one at a time using standard replication.

Management Console provides two mechanisms for mapping using standard

replication.
v One-to-oneMap tables using one-to-one replication when you want to map
multiple source tables to multiple target tables at a time and these tables share
the same table structure and similar table names. The Map Tables wizard
automatically maps tables based on an example mapping you set up.
v StandardMap tables using standard replication when you want to map only
one source table to one target table at a time. These are tables that do not share
the same table structure or similar table names.

See also:
To map similar source tables to similar target tables (One-to-One)
To map tables for InfoSphere Classic CDC for z/OS on page 85
To map a custom source table to a custom target table (standard) on page 86
To map multi-member source tables on IBM i (standard) on page 87
To map multi-member source tables to existing target tables on IBM i
(one-to-one) on page 89
To map multi-member source tables to new tables on IBM i (one-to-one) on
page 90

To map similar source tables to similar target tables

(One-to-One)
1. Click Configuration > Subscriptions.
2. Select a subscription, right-click and select Map Tables.
3. Select One-to-One mapping and click Next.
4. Expand the database, schema, or table from the Source Tables list to view
tables from your database that are available for mapping. Right-click the
database user or schema and click Refresh if you do not see your table listed.
You may be prompted to filter databases, schemas, or tables if Automatically
prompt for filter when expanding nodes is enabled in your preferences. For

Mapping tables 83
 more information see, Setting advanced preferences on page 15. To
manually define a filter, select a datastore, database, or schema and click
Specify Filter.
5. Enable one or more tables to map from the Source Tables list. If you do not
see your table listed, right-click the database user or schema and select
Refresh.
6. If you want to hide columns so that the target is not aware of them, select a
source table and click Filter Columns. Clear the check box for the column you
want to hide and click OK.
7. Click Next.
8. Select Map to existing target tables and click Next.
If you want to map to a new target table, click Create new target tables.
9. Expand the database, schema, or table from the Target Tables list to view
tables from your database that are available for mapping. Right-click the
database user or schema and click Refresh if you do not see your table listed.
The wizard uses the relationship between this target table and the selected
source table to map the remaining source and target tables. You can click
Change Example Table if you want the Map Tables wizard to base the
mapping on a different source table. This option is only available if you have
selected more than one source table.
10. Enable a table to map from the Target Table list. If you do not see your table
listed, right-click the database user or schema and select Refresh.
11. Click Next.
12. Verify the mappings in the Complete Mappings dialog, and click Next.

Note: The Map Tables wizard may leave some source tables unmapped if it
did not find a target table that shared the same table structure or similar
column names. You must map these manually.
13. If you are replicating source database changes using InfoSphere CDC for
Oracle Trigger-based edition and you want to use a journal table to mirror
database operations from the source table to the target table, then choose one
of the following and click Next:
v Use Default JournalEnable when you want InfoSphere CDC for Oracle to
use the default journal table provided with InfoSphere CDC for Oracle: <TS
SCHEMA>.DMCJRN. InfoSphere CDC uses this journal table to detect and
replicate database changes from the source to the target.
v Use Selected JournalEnable when you want InfoSphere CDC for Oracle
to use another journal table other than the default journal table provided
with InfoSphere CDC for Oracle. When you select the database owner and
provide a name for the journal table, InfoSphere CDC Event Server creates
this new journal table and uses it to detect and replicate database changes
from the source to the target.
OwnerLists the database owner of the journal table.
NameLists the name of the journal table.
14. Review the mapping summary and click Finish.

84 InfoSphere Change Data Capture Management Console: Administration Guide

 Related tasks
To map a custom source table to a custom target table (standard) on page 86
To map multi-member source tables on IBM i (standard) on page 87
To map multi-member source tables to existing target tables on IBM i
(one-to-one) on page 89
To map multi-member source tables to new tables on IBM i (one-to-one) on page
90

To map tables for InfoSphere Classic CDC for z/OS

1. Click Configuration > Subscriptions.
2. Select a subscription, right-click and select Map Tables.
3. Select One-to-One mapping and click Next.
4. Expand the Source Tables list to view the IMS tables from your InfoSphere
Classic CDC for z/OS datastore that are available for mapping.
You may be prompted to filter databases, schemas, or tables if Automatically
prompt for filter when expanding nodes is enabled in your preferences. For
more information see, Setting advanced preferences on page 15. To
manually define a filter, select a datastore, database, or schema and click
Specify Filter.
5. Enable one or more tables to map from the Source Tables list. If you do not
see your table listed, right-click the database user or schema and select
Refresh.
6. If you want to hide columns so that the target is not aware of them, select a
source table and click Filter Columns. Clear the check box for the column you
want to hide and click OK.
7. Click Next.
8. Select Map to existing target tables and click Next.
If you want to map to a new target table, click Create new target tables.
9. Expand the database, schema, or table from the Target Tables list to view
tables from your database that are available for mapping. Right-click the
database user or schema and click Refresh if you do not see your table listed.
The wizard uses the relationship between this target table and the selected
source table to map the remaining source and target tables. You can click
Change Example Table if you want the Map Tables wizard to base the
mapping on a different source table. This option is only available if you have
selected more than one source table.
10. Enable a table to map from the Target Table list. If you do not see your table
listed, right-click the database user or schema and select Refresh.
11. Click Next.
12. Verify the mappings in the Complete Mappings dialog, and click Next.

Note: The Map Tables wizard may leave some source tables unmapped if it
did not find a target table that shared the same table structure or similar
column names. You must map these manually.
13. Review the mapping summary and click Finish.

Mapping tables 85
 To map a custom source table to a custom target table
(standard)
1. Click Configuration > Subscriptions.
2. Select a subscription, right-click and select Map Tables.
3. Select One table mapping of any type.
4. Select Standard from the Mapping type list and click Next.
5. Expand the database, schema, or table from the Source Tables list to view
tables from your database that are available for mapping. Right-click the
database user or schema and click Refresh if you do not see your table listed.
You may be prompted to filter databases, schemas, or tables if Automatically
prompt for filter when expanding nodes is enabled in your preferences. For
more information see, Setting advanced preferences on page 15. To
manually define a filter, select a datastore, database, or schema and click
Specify Filter.
6. Enable the table to map from the Source Table list. If you do not see your
table listed, right-click the database user or schema and select Refresh.
7. If you want to hide columns so that the target is not aware of them, select a
source table and click Filter Columns. Clear the check box for the column you
want to hide and click OK.
8. Click Next.
9. Expand the database, schema, or table from the Target Tables list to view
tables from your database that are available for mapping. Right-click the
database user or schema and click Refresh if you do not see your table listed.
If you want to map to a new target table, click Create Table.
10. Choose one of the following and click Next:
v Use an IndexSelect the index name from the Index box. Use if your target
table has an index that uniquely identifies a row.
v Use all searchable columnsSearches all target columns to identify which
columns are suitable to uniquely identify rows. The results of the search are
used to build a WHERE clause which uniquely identifies the row on the
target column to apply data.
v Specify the keySelect the target columns from the Key Columns list. Use
if one or more target columns uniquely identifies a row.
11. Choose a replication method from the following and click Next:
v Mirror (Change Data Capture)Immediately replicates changes made to
the source table to the target table or accumulate source table changes and
replicate at a later time. If your configuration requires you to prevent
recursive updates when mirroring, enable the Prevent Recursion check box.
This check box is only available in versions of InfoSphere CDC that support
both source and target databases.
v Refresh (Snapshot)Replicates a snapshot of the source table to the target
table.
12. If you are replicating source database changes using InfoSphere CDC for
Oracle Trigger-based edition and want to use a journal table to mirror
database operations from the source to the target table, then enable one of the
following:
v Use Default JournalEnable when you want InfoSphere CDC for Oracle to
use the default journal table provided with InfoSphere CDC for Oracle: <TS
SCHEMA>.DMCJRN. InfoSphere CDC uses this journal table to detect and
replicate database changes from the source to the target.

86 InfoSphere Change Data Capture Management Console: Administration Guide

 v Use Selected JournalEnable when you want InfoSphere CDC for Oracle
to use another journal table other than the default journal table provided
with InfoSphere CDC for Oracle. When you select the database owner and
provide a name for the journal table, InfoSphere CDC for Oracle creates this
new journal table and uses it to detect and replicate database changes from
the source to the target.
OwnerLists the database owner of the journal table.
NameLists the name of the journal table.
13. If you have configured bidirectional replication, then enable the Prevent
Recursion check box. This prevents InfoSphere CDC from replicating changes
back to the source database when you have configured a subscription for
bidirectional replication. This is only available in versions of InfoSphere CDC
that support both source and target databases. Contact IBM Technical Support
to implement bidirectional replication in your environment.
14. Click Next.
15. Review the mapping summary.
16. Choose one of the following options and click Finish:
v Define column mappingsContinues with the column mapping.
v Create a new table mappingAllows you to start a new table mapping.
v Return to current viewReturns you to the current view.
Related concepts
Mapping using standard replication on page 83
Setting member identifiers for multi-member source tables on page 171

To map multi-member source tables on IBM i (standard)

1. Ensure that InfoSphere CDC for IBM i is installed on both source and target.
2. Click Configuration > Subscriptions.
3. Select a subscription, right-click and select Map Tables.
4. Select One table mapping of any type.
5. Select Standard from the Mapping type list and click Next.
6. Expand the database, schema, or table from the Source Tables list to view
tables from your database that are available for mapping. Right-click the
database user or schema and click Refresh if you do not see your table listed.
You may be prompted to filter databases, schemas, or tables if Automatically
prompt for filter when expanding nodes is enabled in your preferences. For
more information see, Setting advanced preferences on page 15. To
manually define a filter, select a datastore, database, or schema and click
Specify Filter.
7. Enable the table to map from the Source Table list. If you do not see your
table listed, right-click the database user or schema and select Refresh.
8. If you want to hide columns so that the target is not aware of them, select a
source table and click Filter Columns. Clear the check box for the column you
want to hide and click OK.
9. Click Next.
10. Expand the database, schema, or table from the Target Tables list to view
tables from your database that are available for mapping. Right-click the
database user or schema and click Refresh if you do not see your table listed.
11. Select a table from the Target Table list. If you do not see your table listed,
select the database user or schema and click Refresh. Choose one of the
following options and click Next:

Mapping tables 87
 v Source and Target Files are Single MemberMerges all members from the
source table to a single-member target table.
v Use Source member Structure on TargetMaintains the same
multi-member structure on the target table as the one on the source table.
Each source member is mapped to the corresponding target member.
v Merge Source Members into One Target MemberMerges all members
from the source table to a single member in a multi-member.
12. Choose one of the following and click Next:
v Use an IndexSelect the index name from the Index box. Use if your target
table has an index that uniquely identifies a row.
v Use all searchable columnsSearches all target columns to identify which
columns are suitable to uniquely identify rows. The results of the search are
used to build a WHERE clause which uniquely identifies the row on the
target column to apply data.
v Specify the keySelect the target columns from the Key Columns list. Use
if one or more target columns uniquely identifies a row.
13. Choose a replication method from the following and click Next:
v Mirror (Change Data Capture)Immediately replicates changes made to
the source table to the target table or accumulate source table changes and
replicate at a later time. If your configuration requires you to prevent
recursive updates when mirroring, enable the Prevent Recursion check box.
This check box is only available in versions of InfoSphere CDC that support
both source and target databases.
v Refresh (Snapshot)Replicates a snapshot of the source table to the target
table.
v Use Relative Record NumberEnables InfoSphere CDC to replicate
updates to the target using a relative record number. When this option is
checked, InfoSphere CDC sends the Relative Record Number to the target
and expects the Relative Record Number to be the identifying column on
the target side. This means that the target tables cannot be updated by more
than one source table (a target table cannot be a warehouse for multiple
source tables). If you do not check this box, then InfoSphere CDC for IBM i
uses a unique key to replicate to the target.

Notes:
When this option is checked, if the source table is reorganized,
InfoSphere CDC will automatically start a refresh for that table.
If no Relative Record Number is available on the target table (for
example, if the table resides on a non-IBM i system), you can still make
use of this option by mapping the Relative Record Number on the source
table to a column in the target table to. For more information, see
Source RRN (&CNTRRN) on page 174.
This option is only available when you have installed InfoSphere CDC
for IBM i on the source database.
14. Review the mapping summary.
15. Choose one of the following options and click Finish:
v Define column mappingsContinues with the column mapping.
v Create a new table mappingAllows you to start a new table mapping.
v Return to current viewReturns you to the current view.

88 InfoSphere Change Data Capture Management Console: Administration Guide

 Related concepts
Mapping using standard replication on page 83
Setting member identifiers for multi-member source tables on page 171

To map multi-member source tables to existing target tables

on IBM i (one-to-one)
1. Click Configuration > Subscriptions.
2. Select a subscription, right-click and select Map Tables.
3. Select One-to-one Mappings and click Next.
4. Expand the database, schema, or table from the Source Tables list to view
tables from your database that are available for mapping. Right-click the
database user or schema and click Refresh if you do not see your table listed.
You may be prompted to filter databases, schemas, or tables if Automatically
prompt for filter when expanding nodes is enabled in your preferences. For
more information see, Setting advanced preferences on page 15. To
manually define a filter, select a datastore, database, or schema and click
Specify Filter.
5. If you want to hide columns so that the target is not aware of them, select a
source table and click Filter Columns. Clear the check box for the column you
want to hide and click OK.
6. Enable one or more tables to map from the Source Tables list. If you do not
see your table listed, right-click the database user or schema and select
Refresh.
7. If you want to hide columns so that the target is not aware of them, select a
source table and click Filter Columns. Clear the check box for the column you
want to hide and click OK.
8. Click Next.
9. Select Map to existing target tables and click Next.
10. Expand the database, schema, or table from the Target Tables list to view
tables from your database that are available for mapping. Right-click the
database user or schema and click Refresh if you do not see your table listed.
The wizard uses the relationship between this target table and the selected
source table to map the remaining source and target tables. You can click
Change Example Table if you want the Map Tables wizard to base the
mapping on a different source table. This option is only available if you have
selected more than one source table.
11. Select the target table from the Target Table list and click Next.
If any of the mappings are incorrect, you can click the assigned target table
and pick another target table from the displayed list. If you have not chosen
similar tables, you can select target tables individually by clicking on the
target list beside the source table you want to map.
12. Choose a replication method from the following and click Next:
v Mirror (Change Data Capture)Immediately replicates changes made to
the source table to the target table or accumulate source table changes and
replicate at a later time. If your configuration requires you to prevent
recursive updates when mirroring, enable the Prevent Recursion check box.
This check box is only available in versions of InfoSphere CDC that support
both source and target databases.
v Refresh (Snapshot)Replicates a snapshot of the source table to the target
table.

Mapping tables 89
 v Use Relative Record NumberEnables InfoSphere CDC to replicate
updates to the target using a relative record number. When this option is
checked, InfoSphere CDC sends the Relative Record Number to the target
and expects the Relative Record Number to be the identifying column on
the target side. This means that the target tables cannot be updated by more
than one source table (a target table cannot be a warehouse for multiple
source tables). If you do not check this box, then InfoSphere CDC for IBM i
uses a unique key to replicate to the target.

Notes:
When this option is checked, if the source table is reorganized,
InfoSphere CDC will automatically start a refresh for that table.
If no Relative Record Number is available on the target table (for
example, if the table resides on a non-IBM i system), you can still make
use of this option by mapping the Relative Record Number on the source
table to a column in the target table to. For more information, see
Source RRN (&CNTRRN) on page 174.
This option is only available when you have installed InfoSphere CDC
for IBM i on the source database.
13. Click Next.
14. Review the mapping summary and click Finish.
Related concepts
Mapping using standard replication on page 83
Setting member identifiers for multi-member source tables on page 171

To map multi-member source tables to new tables on IBM i

(one-to-one)
1. Click Configuration > Subscriptions.
2. Select a subscription, right-click and select Map Tables.
3. Select One-to-one Mappings and click Next.
4. Expand the database, schema, or table from the Source Tables list to view
tables from your database that are available for mapping. Right-click the
database user or schema and click Refresh if you do not see your table listed.
You may be prompted to filter databases, schemas, or tables if Automatically
prompt for filter when expanding nodes is enabled in your preferences. For
more information see, Setting advanced preferences on page 15. To
manually define a filter, select a datastore, database, or schema and click
Specify Filter.
5. Enable one or more tables to map from the Source Tables list. If you do not
see your table listed, right-click the database user or schema and select
Refresh.
6. If you want to hide columns so that the target is not aware of them, select a
source table and click Filter Columns. Clear the check box for the column you
want to hide and click OK.
7. Click Next.
8. Select Create New Target Tables and click Next.
9. Click in the Target Library column, select a target owner, and click Next.
10. Choose from the following options and click Next:
v Identical to the source table namesNames the new target tables the same
name as the source tables.

90 InfoSphere Change Data Capture Management Console: Administration Guide

 v Source table names with prefixes and/or suffixesAdds the suffix, the
prefix, or both, to the source table name. Enable the Use prefix/suffix for
index name check box to use the prefix and suffix as the index name.
11. Choose a replication method from the following and click Next:
v Mirror (Change Data Capture)Immediately replicates changes made to
the source table to the target table or accumulate source table changes and
replicate at a later time. If your configuration requires you to prevent
recursive updates when mirroring, enable the Prevent Recursion check box.
This check box is only available in versions of InfoSphere CDC that support
both source and target databases.
v Refresh (Snapshot)Replicates a snapshot of the source table to the target
table.
v Use Relative Record NumberEnables InfoSphere CDC to replicate
updates to the target using a relative record number. When this option is
checked, InfoSphere CDC sends the Relative Record Number to the target
and expects the Relative Record Number to be the identifying column on
the target side. This means that the target tables cannot be updated by more
than one source table (a target table cannot be a warehouse for multiple
source tables). If you do not check this box, then InfoSphere CDC for IBM i
uses a unique key to replicate to the target.

Notes:
When this option is checked, if the source table is reorganized,
InfoSphere CDC will automatically start a refresh for that table.
If no Relative Record Number is available on the target table (for
example, if the table resides on a non-IBM i system), you can still make
use of this option by mapping the Relative Record Number on the source
table to a column in the target table to. For more information, see
Source RRN (&CNTRRN) on page 174.
This option is only available when you have installed InfoSphere CDC
for IBM i on the source database.
12. Review the mapping summary and click Finish.
Related concepts
Mapping using standard replication on page 83
Setting member identifiers for multi-member source tables on page 171

Mapping using LiveAudit

If you want your target table to keep an audit trail of operations applied to the
source table, then use the Map Tables wizard to map your source and target tables
using LiveAudit. When you replicate data using LiveAudit, your target tables
contain rows that track insert, update, delete, and clear (truncate) operations
applied to the mapped source table. LiveAudit is most useful if your environment
must satisfy data auditing and change-tracking requirements. With LiveAudit, you
can audit changes to sensitive information, and you can monitor and report on risk
in a timely manner. The following table summarizes how row-level operations are
replicated to the target datastore when you map your tables for LiveAudit.

Source operations Target Operations

INSERT INSERTs the new row that was added.

Mapping tables 91
 Source operations Target Operations
UPDATE (Key not changed) Either:
v INSERT the row that contains the after
image.
v INSERT row containing before image
values, and INSERT another row
containing after image values.
UPDATE (Key changed) Either:
v INSERT the row that contains the after
image.
v INSERT row containing before image
values, and INSERT another row
containing after image values.
DELETE INSERTs the row that was deleted.

See also:
To map a single source table using LiveAudit
To map a multi-member table using LiveAudit for IBM i on page 93
To map multiple source tables to existing tables using LiveAudit on page 94
To map multiple source tables to new tables using LiveAudit on page 95

To map a single source table using LiveAudit

1. Click Configuration > Subscriptions.
2. Select a subscription, right-click and select Map Tables.
3. Select One table mapping of any type and choose LiveAudit Mappings from
the Mapping Type list box.
4. Click Next.
5. Review the following audit columns. You can choose to add, modify, or delete
audit columns to the target table. Click Next:
v AudTimeStores the &TIMSTAMP journal control field which indicates
date and time changes are made to the source.
v AudTypeStores the &ENTTYP journal control field which indicates the
type of change made to the source.
v AudUserStores the &USER journal control field which indicates the ID of
the user who made the change to the source.
6. Expand the database, schema, or table from the Source Tables list to view
tables from your database that are available for mapping. Right-click the
database user or schema and click Refresh if you do not see your table listed.
You may be prompted to filter databases, schemas, or tables if Automatically
prompt for filter when expanding nodes is enabled in your preferences. For
more information see, Setting advanced preferences on page 15. To
manually define a filter, select a datastore, database, or schema and click
Specify Filter.
7. Enable one or more tables to map from the Source Tables list. If you do not
see your table listed, right-click the database user or schema and select
Refresh.
8. If you want to hide columns so that the target is not aware of them, select a
source table and click Filter Columns. Clear the check box for the column you
want to hide and click OK.

92 InfoSphere Change Data Capture Management Console: Administration Guide

 9. Click Next.
10. Expand the database, schema, or table from the Target Tables list to view
tables from your database that are available for mapping. Right-click the
database user or schema and click Refresh if you do not see your table listed.
11. Enable a table to map from the Target Table list. If you do not see your table
listed, right-click the database user or schema and select Refresh.
12. Click Next.
13. Review the mapping summary.
14. Choose one of the following options and click Finish:
v Define column mappingsContinues with the column mapping.
v Create a new table mappingAllows you to start a new table mapping.
v Return to current viewReturns you to the current view.
Related concepts
Mapping using LiveAudit on page 91

To map a multi-member table using LiveAudit for IBM i

1. Ensure that InfoSphere CDC for IBM i is installed on both source and target.
2. Click Configuration > Subscriptions.
3. Select a subscription, right-click and select Map Tables.
4. Select One table mapping of any type.
5. Choose LiveAudit Mappings from the Mapping Type list box and click Next.
6. Review the following audit columns. You can choose to add, modify, or delete
audit columns to the target table. Click Next:
v AudTimeStores the &TIMSTAMP journal control field which indicates
date and time changes are made to the source.
v AudTypeStores the &ENTTYP journal control field which indicates the
type of change made to the source.
v AudUserStores the &USER journal control field which indicates the ID of
the user who made the change to the source.
7. Expand the database, schema, or table from the Source Tables list to view
tables from your database that are available for mapping. Right-click the
database user or schema and click Refresh if you do not see your table listed.
You may be prompted to filter databases, schemas, or tables if Automatically
prompt for filter when expanding nodes is enabled in your preferences. For
more information see, Setting advanced preferences on page 15. To
manually define a filter, select a datastore, database, or schema and click
Specify Filter.
8. Enable the table to map from the Source Table list. If you do not see your
table listed, right-click the database user or schema and select Refresh.
9. If you want to hide columns so that the target is not aware of them, select a
source table and click Filter Columns. Clear the check box for the column you
want to hide and click OK.
10. Click Next.
11. Expand the database, schema, or table from the Target Tables list to view
tables from your database that are available for mapping. Right-click the
database user or schema and click Refresh if you do not see your table listed.
12. Select a target table to map from the Target Table list and choose one of the
following options.

Mapping tables 93
 v Source and Target Files are Single MemberMerges all members from the
source table to a single-member target table.
v Use Source member Structure on TargetMaintains the same
multi-member structure on the target table as the one on the source table.
Each source member is mapped to the corresponding target member.
v Merge Source Members into One Target MemberMerges all members
from the source table to a single member in a multi-member target table.
13. Review the mapping settings.
14. Choose one of the following options and click Finish:
v Define column mappingsContinues with the column mapping.
v Create a new table mappingAllows you to start a new table mapping.
v Return to current viewReturns you to the current view.
Related concepts
Mapping using standard replication on page 83
Setting member identifiers for multi-member source tables on page 171

To map multiple source tables to existing tables using

LiveAudit
1. Click Configuration > Subscriptions.
2. Select a subscription, right-click and select Map Tables.
3. Select LiveAudit Mappings and click Next.
4. Review the following audit columns. You can choose to add, modify, or delete
audit columns to the target table. Click Next:
v AudTimeStores the &TIMSTAMP journal control field which indicates
date and time changes are made to the source.
v AudTypeStores the &ENTTYP journal control field which indicates the
type of change made to the source.
v AudUserStores the &USER journal control field which indicates the ID of
the user who made the change to the source.
5. Expand the database, schema, or table from the Source Tables list to view
tables from your database that are available for mapping. Right-click the
database user or schema and click Refresh if you do not see your table listed.
You may be prompted to filter databases, schemas, or tables if Automatically
prompt for filter when expanding nodes is enabled in your preferences. For
more information see, Setting advanced preferences on page 15. To
manually define a filter, select a datastore, database, or schema and click
Specify Filter.
6. Enable one or more tables to map from the Source Tables list. If you do not
see your table listed, right-click the database user or schema and select
Refresh.
7. If you want to hide columns so that the target is not aware of them, select a
source table and click Filter Columns. Clear the check box for the column you
want to hide and click OK.
8. Click Next.
9. Select Map to existing target tables and click Next.
10. Expand the database, schema, or table from the Target Tables list to view
tables from your database that are available for mapping. Right-click the
database user or schema and click Refresh if you do not see your table listed.

94 InfoSphere Change Data Capture Management Console: Administration Guide

 11. Verify that the correct target table is mapped to the source tables and click
Next.
If any of the mappings are incorrect, you can click the assigned target table
and pick another target table from the displayed list. If you have not chosen
similar tables, you can select target tables individually by clicking on the
target list beside the source table you want to map.
12. Review the mapping summary and click Finish.
InfoSphere CDC inserts a row into the target table for every row-level
operation (insert, update, or delete) applied to a row in the source table. The
target table can become extremely large. Ensure that you allow sufficient disk
space and perform regular maintenance for target tables that audit data.
Related concepts
Mapping using LiveAudit on page 91

To map multiple source tables to new tables using LiveAudit

1. Click Configuration > Subscriptions.
2. Select a subscription, right-click and select Map Tables.
3. Select LiveAudit Mappings and click Next.
4. Review the following audit columns. You can choose to add, modify, or delete
audit columns to the target table. Click Next:
v AudTimeStores the &TIMSTAMP journal control field which indicates
date and time changes are made to the source.
v AudTypeStores the &ENTTYP journal control field which indicates the
type of change made to the source.
v AudUserStores the &USER journal control field which indicates the ID of
the user who made the change to the source.
5. Expand the database, schema, or table from the Source Tables list to view
tables from your database that are available for mapping. Right-click the
database user or schema and click Refresh if you do not see your table listed.
You may be prompted to filter databases, schemas, or tables if Automatically
prompt for filter when expanding nodes is enabled in your preferences. For
more information see, Setting advanced preferences on page 15. To
manually define a filter, select a datastore, database, or schema and click
Specify Filter.
6. Enable one or more tables to map from the Source Tables list. If you do not
see your table listed, right-click the database user or schema and select
Refresh.
7. If you want to hide columns so that the target is not aware of them, select a
source table and click Filter Columns. Clear the check box for the column you
want to hide and click OK.
8. Click Next.
9. Select Create new target tables and click Next.
10. Click Click to select a target owner under Target Library or Target Schema
(if you're using a DB2 agent) and select a target owner.
Note that if you are mapping to a datastore that uses a DB2 database, you
must type the Tablespace in the Select Schema for New Target Tables dialog
box.
11. Choose from the following options and click Next:
v Identical to the source table namesNames the new target tables the same
name as the source tables.

Mapping tables 95
 v Source table names with prefixes and/or suffixesAdds the suffix, the
prefix, or both, to the source table name. Enable the Use prefix/suffix for
index name check box to use the prefix and suffix as the index name.
12. Review the mapping summary and click Finish.
Related concepts
Mapping using LiveAudit on page 91

Mapping using InfoSphere DataStage

After adding a subscription that uses InfoSphere CDC for InfoSphere DataStage as
a target datastore, you must map one or more source tables to the target system,
IBM InfoSphere DataStage. You can create as many table mappings as you feel
necessary, and this may depend on the number of tables that you want to replicate
to the target system.

There are two methods of mapping tables in InfoSphere CDC for consumption by
InfoSphere DataStage. The two options differ from one another.

In the Flat File method, InfoSphere CDC produces one or more files containing
information about one or more records and database operations, with each record
occupying its own line followed by a delimiter if you use the Single Record
option, or with each record occupying two lines if you choose the Multiple
Records option when mapping your tables. Those files are saved to be retrieved by
InfoSphere DataStage and used by the Sequential File Reader stage of the InfoSphere
DataStage job. For update operations, the flat file will have both the before and
after image in one line.

In the Direct Connect method, the data is not written to a file, but is sent instead
over a TCP/IP connection directly to InfoSphere DataStage to be processed by a
specific InfoSphere DataStage job that you have identified by specifying the
matching Project Name, Job Name, and Connection Key in the InfoSphere
DataStage Properties dialog box in Management Console. The InfoSphere
DataStage Connector processes the data, then transforms and translates it into a
format recognized by the InfoSphere DataStage job.

With the Direct Connect connection method, you can enable the autostart feature to
run in active mode, which allows you to start a InfoSphere DataStage job from
InfoSphere CDC and begin to stream data to InfoSphere DataStage. Running with
autostart enabled requires both InfoSphere CDC and InfoSphere DataStage to be
installed on the same server. If autostart is not enabled, you will be running in
passive mode, and you must run jobs from InfoSphere DataStage before the Direct
Connect data stream can begin. Note that to use the full functionality of the Direct
Connect option, you must have Management Console version 6.5, Access Server
version 6.5 installed as well as having InfoSphere CDC version 6.5 installed on the
same server as InfoSphere DataStage, a component of IBM Information Server
version 8.5.

Understanding the workflow

Depending on the connection method you choose, files are either saved for
retrieval by InfoSphere DataStage (Flat File), or data is streamed to InfoSphere
DataStage (Direct Connect), by InfoSphere CDC when either when data limits are
reached (determined the Batch Size Threshold settings you've indicated in the
InfoSphere DataStage Properties dialog box in Management Console after
mapping your tables) or when a refresh or mirroring operation ends.

96 InfoSphere Change Data Capture Management Console: Administration Guide

 For the Flat File connection method, the process begins once a refresh or mirroring
operation begins, and InfoSphere CDC starts writing change information to
temporary data files for only those tables in the subscription for which there are
changes. Once the Batch Size Threshold limits are met, InfoSphere CDC hardens
the temporary data files at the subscription level with timestamps in the filenames.
No data files are produced for tables that have no changes. Once the refresh or
mirroring operation is ended, <TABLE_NAME>.STOPPED files, which server as status
flags, are produced for each table in the subscription, then the bookmark is
updated. These files are ready for consumption by the InfoSphere DataStage job.

Attention: If you kill a refresh or mirroring operation using the dmterminate

command, the temporary data files cannot be hardened at the subscription level,
no <TABLE_NAME>.STOPPED status flag files are generated for the tables in the
subscription, and the bookmark is not updated. You must restart the refresh or
mirroring process. Be aware that restarting uses the last-saved bookmark and starts
a new set of temporary data files to be hardened as thresholds are met. To ensure
that the temporary data files are hardened, and the <TABLE_NAME>.STOPPED status
flag files are created, use a Normal or Scheduled End shutdown in Management
Console, or you can issue a dmshutdown command with the appropriate flags for
the severity level. If you use the Abort or Immediate shutdown options,
InfoSphere CDC may opt not harden the temporary data files as a way of
facilitating these more rapid shutdown requests.

For the Direct Connect connection method, the process is similar. The size and time
limits set in the InfoSphere DataStage Properties dialog box determine when data
is sent, and the matching Project Name, Job Name, and Connection Key
information set in the InfoSphere DataStage Properties dialog box permit
InfoSphere CDC to send the data to InfoSphere DataStage directly, without saving
any of the data as flat files.

Additionally, with the Direct Connect connection method, you can enable the
autostart feature to run in active mode, which allows InfoSphere DataStage to start
a job when appropriate and begin to stream data to InfoSphere DataStage. Running
with autostart enabled requires both InfoSphere CDC and InfoSphere DataStage to
be installed on the same server. If autostart is not enabled, you must run jobs from
InfoSphere DataStage before the Direct Connect data stream can begin. For
instructions on enabling autostart, see the Management Console documentation.
To map a single source table to InfoSphere DataStage using flat files
To map a single source table to InfoSphere DataStage using Direct Connect
on page 98
To map multiple source tables to InfoSphere DataStage using flat files on
page 99
To map multiple source tables to InfoSphere DataStage using Direct Connect
on page 99

To map a single source table to InfoSphere DataStage using

flat files
1. Click Configuration > Subscriptions.
2. Select a subscription, right-click and select Map Tables.
3. Select One table mapping and select InfoSphere DataStage from the Select
Mapping Type box.
4. Click Next.
5. Select Flat File and click Next.

Mapping tables 97
 6. Expand the database, schema, or table from the Source Tables list to view
tables from your database that are available for mapping. Right-click the
database user or schema and click Refresh if you do not see your table listed.
You may be prompted to filter databases, schemas, or tables if Automatically
prompt for filter when expanding nodes is enabled in your preferences. For
more information see, Setting advanced preferences on page 15. To
manually define a filter, select a datastore, database, or schema and click
Specify Filter.
7. Enable the table to map from the Source Table list. If you do not see your
table listed, right-click the database user or schema and select Refresh.
8. If you want to hide columns so that the target is not aware of them, select a
source table and click Filter Columns. Clear the check box for the column you
want to hide and click OK.
9. Click Next.
10. Type the output directory for the flat files that are generated by InfoSphere
CDC and used by InfoSphere DataStage in the Directory box.
11. Select one of the following options for the record format of the flat files and
click Next:
v Single RecordAn update operation is sent as a single row.
v Multiple RecordAn update operation is sent as two rows.
12. Review the mapping settings.
13. Click Finish.

To map a single source table to InfoSphere DataStage using

Direct Connect
1. Click Configuration > Subscriptions.
2. Select a subscription, right-click and select Map Tables.
3. Select One table mapping and select InfoSphere DataStage from the
Mapping Type box.
4. Click Next.
5. Select Direct Connect and click Next.
6. Expand the database, schema, or table from the Source Tables list to view
tables from your database that are available for mapping. Right-click the
database user or schema and click Refresh if you do not see your table listed.
You may be prompted to filter databases, schemas, or tables if Automatically
prompt for filter when expanding nodes is enabled in your preferences. For
more information see, Setting advanced preferences on page 15. To
manually define a filter, select a datastore, database, or schema and click
Specify Filter.
7. Enable one or more tables to map from the Source Tables list. If you do not
see your table listed, right-click the database user or schema and select
Refresh.
8. If you want to hide columns so that the target is not aware of them, select a
source table and click Filter Columns. Clear the check box for the column you
want to hide and click OK.
9. Click Next.
10. Enable one of the following options for the output records used by InfoSphere
DataStage and click Next:
v Single RecordAn update operation is sent as a single row.
v Multiple RecordAn update operation is sent as two rows.
98 InfoSphere Change Data Capture Management Console: Administration Guide
 11. Review the mapping settings.
12. Click Finish.

To map multiple source tables to InfoSphere DataStage using

flat files
1. Click Configuration > Subscriptions.
2. Select a subscription, right-click and select Map Tables.
3. Under Automatic, select InfoSphere DataStage.
4. Click Next.
5. Select Flat File and click Next.
6. Expand the database, schema, or table from the Source Tables list to view
tables from your database that are available for mapping. Right-click the
database user or schema and click Refresh if you do not see your table listed.
You may be prompted to filter databases, schemas, or tables if Automatically
prompt for filter when expanding nodes is enabled in your preferences. For
more information see, Setting advanced preferences on page 15. To
manually define a filter, select a datastore, database, or schema and click
Specify Filter.
7. Enable one or more tables to map from the Source Tables list. If you do not
see your table listed, right-click the database user or schema and select
Refresh.
8. If you want to hide columns so that the target is not aware of them, select a
source table and click Filter Columns. Clear the check box for the column you
want to hide and click OK.
9. Click Next.
10. Type the output directory for the flat files that are generated by InfoSphere
CDC and used by InfoSphere DataStage in the Directory box.
11. Enable one of the following options for the flat file output records and click
Next:
v Single RecordAn update operation is sent as a single row.
v Multiple RecordAn update operation is sent as two rows.
12. Review the mapping settings.
13. Click Finish.

To map multiple source tables to InfoSphere DataStage using

Direct Connect
1. Click Configuration > Subscriptions.
2. Select a subscription, right-click and select Map Tables.
3. Select One table mapping and select InfoSphere DataStage from the
Mapping Type box.
4. Click Next.
5. Select Direct Connect and click Next.
6. Expand the database, schema, or table from the Source Tables list to view
tables from your database that are available for mapping. Right-click the
database user or schema and click Refresh if you do not see your table listed.
You may be prompted to filter databases, schemas, or tables if Automatically
prompt for filter when expanding nodes is enabled in your preferences. For

Mapping tables 99
 more information see, Setting advanced preferences on page 15. To
manually define a filter, select a datastore, database, or schema and click
Specify Filter.
7. Enable one or more tables to map from the Source Tables list. If you do not
see your table listed, right-click the database user or schema and select
Refresh.
8. If you want to hide columns so that the target is not aware of them, select a
source table and click Filter Columns. Clear the check box for the column you
want to hide and click OK.
9. Click Next.
10. Type the host name of your InfoSphere DataStage installation in the Host box.
11. Specify the starting port if you have selected more than one source table in the
Port box.
12. Enable one of the following options for the output records used by InfoSphere
DataStage and click Next:
v Single RecordAn update operation is sent as a single row.
v Multiple RecordAn update operation is sent as two rows.
13. Review the mapping settings.
14. Click Finish.

Generating an InfoSphere DataStage definition file for a subscription

InfoSphere DataStage uses job definitions to describe the sequence of steps, or stages,
required to transform data based on system and business requirements. InfoSphere
DataStage jobs are designed and edited in InfoSphere DataStage Designer.

When using InfoSphere CDC for InfoSphere DataStage, you have the option of
generating a job definition in InfoSphere CDC without the need to create it in
InfoSphere DataStage Designer, or you can create a custom data format if you are
using an existing format you created in InfoSphere DataStage Designer. Before you
generate a definition file, you must map your tables.

Using Management Console to generate a definition file

When using InfoSphere CDC for InfoSphere DataStage, you can generate a job
definition containing default data formatting in Management Console without the
need to create it in InfoSphere DataStage Designer. After mapping your tables to
InfoSphere DataStage, you can generate a job definition file (*.dsx) that describes
the default data format of the flat file generated by InfoSphere CDC among other
things. You import this file into InfoSphere DataStage Designer to create a template
set of jobs into which you can add business logic and customize as necessary.

Generating an InfoSphere DataStage definition .dsx file is most useful to users who
do not already have existing or custom InfoSphere DataStage jobs set up. If you
have existing jobs in InfoSphere DataStage, or you have made changes to the data
format that will be sent by InfoSphere CDC to InfoSphere DataStage, you should
consider creating a custom data format for InfoSphere DataStage.

As part of the configuration process in Management Console, you can generate a

definition file (*.dsx) that is imported into InfoSphere DataStage. To generate a
InfoSphere DataStage definition file, you must complete the configuration steps in
Management Console.

100 InfoSphere Change Data Capture Management Console: Administration Guide

The .dsx definition file you generate in Management Console and import into
InfoSphere DataStage contains the information that is used to recreate columns in
InfoSphere DataStage based on the data types of the source columns as determined
by your table mapping choices. The .dsx file also contains information on which of
the two connection methods that you select when you map your tables. The
connection type options are:
v Flat Fileuses a file system to deposit source changes for InfoSphere DataStage
to retrieve.
v Direct Connectuses TCP/IP as the transport protocol to stream data from
InfoSphere CDC to InfoSphere DataStage. Note that to use the full functionality
of the Direct Connect option, including the autostart option, you must have
Management Console version 6.5, Access Server version 6.5 installed as well as
having InfoSphere CDC version 6.5 installed on the same server as InfoSphere
DataStage, a component of IBM Information Server version 8.5.

For the Flat File connection method, the package consists of a job sequence, a
parallel job, and two utility routines that are used by the job sequence. The job
sequence has three parameters. The values for these parameters are specified by
Management Console when it generates the InfoSphere DataStage .dsx definition
file:
v SPFolderPaththe full path name for the folder to be searched.
v SPFileNamePatternthe file name pattern used to identify the source flat files.
v SPEndFileNamePatternthe file name that InfoSphere CDC creates when
subscriptions stop mirroring. The name of this file signals InfoSphere DataStage
to stop. If you do not want InfoSphere DataStage to stop, you can change the
name of the file with this parameter.

For the Direct Connect connection method, the data is not written to a file, but is
sent instead over a TCP/IP connection directly to InfoSphere DataStage to be
processed by a specific InfoSphere DataStage job that you have identified by
specifying the matching Project Name, Job Name, and Connection Key in the
InfoSphere DataStage Properties dialog box in Management Console after
mapping your tables. The InfoSphere DataStage Connector processes the data, then
transforms and translates it into a format recognized by the InfoSphere DataStage
job.

Creating a custom data format for InfoSphere DataStage

You can customize the data that is being generated by InfoSphere CDC and sent to
InfoSphere DataStage by specifying a Java class. This is ideal for users who have
existing InfoSphere DataStage jobs that expect a particular data format. If you use
a custom data format that changes the default format of the flat file sent from
InfoSphere CDC to InfoSphere DataStage, the .dsx file described in Using
Management Console to generate a definition file on page 100 won't be useful
because it contains only default data formatting. If you have created and imported
a .dsx file into InfoSphere DataStage, you must ensure that it is still relevant in
InfoSphere DataStage Designer.

For more information on these requirements, refer to the InfoSphere DataStage

product technical documentation.

See also:
To generate an InfoSphere DataStage definition file on page 102

Mapping tables 101

 Related concepts
Setting properties for a subscription that targets InfoSphere DataStage on page
131

To generate an InfoSphere DataStage definition file

1. Ensure that you have completed your table mapping for the subscription.
2. Click Configuration > Subscriptions.
3. Right-click on a subscription and select InfoSphere DataStage > Generate
InfoSphere DataStage Job Definition .
4. Select the location for your DSX file (*.dsx) and click Save.
5. Import the DSX file into InfoSphere DataStage Designer.
For more information on importing and working with the DSX file in
InfoSphere DataStage Designer, see your IBM InfoSphere DataStage
documentation.

Mapping using Adaptive Apply

If you know that your source and target tables are not synchronized, but you want
to replicate data from the source to the target without error, then map your source
table to your target table using the Adaptive Apply mapping type. For example, if
there is an insert on the source table, but that row already exists in your target
table, InfoSphere CDC switches the insert to an update operation. Also, if there is
an update on your source table, and this row does not exist on your target table,
then InfoSphere CDC switches the update into an insert.

Adaptive Apply ensures that replicated rows in the source and target tables are the
same. You can also use Adaptive Apply to restore the contents of a target table
from recorded journal or log entries. To do this, you set the journal or log position
to a specific entry or point in time, and then use Adaptive Apply to populate an
empty target table with the latest data.

See also:
To map a source table using Adaptive Apply
To map a table for bulk Adaptive Apply on page 104
To map multi-member source tables using Adaptive Apply on IBM i on page
105

To map a source table using Adaptive Apply

1. Click Configuration > Subscriptions.
2. Select a subscription, right-click and select Map Tables.
3. Select One table mapping of any type.
4. Select Adaptive Apply from the Mapping type list and click Next.
5. Expand the database, schema, or table from the Source Tables list to view
tables from your database that are available for mapping. Right-click the
database user or schema and click Refresh if you do not see your table listed.
You may be prompted to filter databases, schemas, or tables if Automatically
prompt for filter when expanding nodes is enabled in your preferences. For
more information see, Setting advanced preferences on page 15. To
manually define a filter, select a datastore, database, or schema and click
Specify Filter.

102 InfoSphere Change Data Capture Management Console: Administration Guide

 6. Enable the table to map from the Source Table list. If you do not see your
table listed, right-click the database user or schema and select Refresh.
7. If you want to hide columns so that the target is not aware of them, select a
source table and click Filter Columns. Clear the check box for the column you
want to hide and click OK.
8. Click Next.
9. Expand the database, schema, or table from the Target Tables list to view
tables from your database that are available for mapping. Right-click the
database user or schema and click Refresh if you do not see your table listed.
10. Enable a table to map from the Target Table list and click Next. If you do not
see your table listed, right-click the database user or schema and select
Refresh. Click Next.
If you want to create a new table to map to, click Create Table.
11. Choose one of the following and click Next:
v Use an IndexSelect the index name from the Index box. Use if your target
table has an index that uniquely identifies a row.
v Use all searchable columnsSearches all target columns to identify which
columns are suitable to uniquely identify rows. The results of the search are
used to build a WHERE clause which uniquely identifies the row on the
target column to apply data.
v Specify the keySelect the target columns from the Key Columns list. Use
if one or more target columns uniquely identifies a row.
12. Choose a replication method from the following and click Next:
v Mirror (Change Data Capture)Immediately replicates changes made to
the source table to the target table or accumulate source table changes and
replicate at a later time. If your configuration requires you to prevent
recursive updates when mirroring, enable the Prevent Recursion check box.
This check box is only available in versions of InfoSphere CDC that support
both source and target databases.
v Refresh (Snapshot)Replicates a snapshot of the source table to the target
table.
13. If you are replicating source database changes using InfoSphere CDC for
Oracle Trigger-based edition and want to use a journal table to mirror
database operations from the source to the target table, then enable one of the
following:
v Use Default JournalEnable when you want InfoSphere CDC for Oracle to
use the default journal table provided with InfoSphere CDC for Oracle: <TS
SCHEMA>.DMCJRN. InfoSphere CDC uses this journal table to detect and
replicate database changes from the source to the target.
v Use Selected JournalEnable when you want InfoSphere CDC for Oracle
to use another journal table other than the default journal table provided
with InfoSphere CDC for Oracle. When you select the database owner and
provide a name for the journal table, InfoSphere CDC for Oracle creates this
new journal table and uses it to detect and replicate database changes from
the source to the target.
OwnerLists the database owner of the journal table.
NameLists the name of the journal table.
14. If you have configured bidirectional replication, then enable the Prevent
Recursion check box. This prevents InfoSphere CDC from replicating changes
back to the source database when you have configured a subscription for
bidirectional replication. This is only available in versions of InfoSphere CDC

Mapping tables 103

 that support both source and target databases. Contact IBM Technical Support
to implement bidirectional replication in your environment.
15. Click Next.
16. Review the mapping summary.
17. Choose one of the following options and click Finish:
v Define column mappingsContinues with the column mapping.
v Create a new table mappingAllows you to start a new table mapping.
v Return to current viewReturns you to the current view.
Related concepts
Mapping using Adaptive Apply on page 102

To map a table for bulk Adaptive Apply

1. Click Configuration > Subscriptions.
2. Select a subscription, right-click and select Map Tables.
3. Select One-to-One mapping.
4. Select Adaptive Apply from the Mapping Type drop down list and click
Next.
5. Expand the database, schema, or table from the Source Tables list to view
tables from your database that are available for mapping. Right-click the
database user or schema and click Refresh if you do not see your table listed.
You may be prompted to filter databases, schemas, or tables if Automatically
prompt for filter when expanding nodes is enabled in your preferences. For
more information see, Setting advanced preferences on page 15. To
manually define a filter, select a datastore, database, or schema and click
Specify Filter.
6. Enable one or more tables to map from the Source Tables list. If you do not
see your table listed, right-click the database user or schema and select
Refresh.
7. If you want to hide columns so that the target is not aware of them, select a
source table and click Filter Columns. Clear the check box for the column you
want to hide and click OK.
8. Click Next.
9. Select Map to existing target tables and click Next.
If you want to map to a new target table, click Create new target tables.
10. Expand the database, schema, or table from the Target Tables list to view
tables from your database that are available for mapping. Right-click the
database user or schema and click Refresh if you do not see your table listed.
The wizard uses the relationship between this target table and the selected
source table to map the remaining source and target tables. You can click
Change Example Table if you want the Map Tables wizard to base the
mapping on a different source table. This option is only available if you have
selected more than one source table.
11. Enable a table to map from the Target Table list. If you do not see your table
listed, right-click the database user or schema and select Refresh.
12. Click Next.
13. Choose a replication method from the following and click Next:
v Mirror (Change Data Capture)Immediately replicates changes made to
the source table to the target table or accumulate source table changes and
replicate at a later time. If your configuration requires you to prevent

104 InfoSphere Change Data Capture Management Console: Administration Guide

 recursive updates when mirroring, enable the Prevent Recursion check box.
This check box is only available in versions of InfoSphere CDC that support
both source and target databases.
v Refresh (Snapshot)Replicates a snapshot of the source table to the target
table.
v Use Relative Record NumberEnables InfoSphere CDC to replicate
updates to the target using a relative record number. When this option is
checked, InfoSphere CDC sends the Relative Record Number to the target
and expects the Relative Record Number to be the identifying column on
the target side. This means that the target tables cannot be updated by more
than one source table (a target table cannot be a warehouse for multiple
source tables). If you do not check this box, then InfoSphere CDC for IBM i
uses a unique key to replicate to the target.

Notes:
When this option is checked, if the source table is reorganized,
InfoSphere CDC will automatically start a refresh for that table.
If no Relative Record Number is available on the target table (for
example, if the table resides on a non-IBM i system), you can still make
use of this option by mapping the Relative Record Number on the source
table to a column in the target table to. For more information, see
Source RRN (&CNTRRN) on page 174.
This option is only available when you have installed InfoSphere CDC
for IBM i on the source database.
14. Verify the mappings in the Complete Mappings dialog, and click Next.

Note: The Map Tables wizard may leave some source tables unmapped if it
did not find a target table that shared the same table structure or similar
column names. You must map these manually.

To map multi-member source tables using Adaptive Apply on

IBM i
1. Click Configuration > Subscriptions.
2. Select a subscription, right-click and select Map Tables.
3. Select One table mapping of any type.
4. Select Adaptive Apply from the Mapping type list and click Next.
5. Expand the database, schema, or table from the Source Tables list to view
tables from your database that are available for mapping. Right-click the
database user or schema and click Refresh if you do not see your table listed.
You may be prompted to filter databases, schemas, or tables if Automatically
prompt for filter when expanding nodes is enabled in your preferences. For
more information see, Setting advanced preferences on page 15. To
manually define a filter, select a datastore, database, or schema and click
Specify Filter.
6. Enable the table to map from the Source Table list. If you do not see your
table listed, right-click the database user or schema and select Refresh.
7. If you want to hide columns so that the target is not aware of them, select a
source table and click Filter Columns. Clear the check box for the column you
want to hide and click OK.
8. Click Next.

Mapping tables 105

 9. Expand the database, schema, or table from the Target Tables list to view
tables from your database that are available for mapping. Right-click the
database user or schema and click Refresh if you do not see your table listed.
10. Enable a table to map from the Target Table list and click Next. If you do not
see your table listed, right-click the database user or schema and select
Refresh. Click Next.
If you want to create a new table to map to, click Create Table.
11. Choose one of the following and click Next:
v Use an IndexSelect the index name from the Index box. Use if your target
table has an index that uniquely identifies a row.
v Use all searchable columnsSearches all target columns to identify which
columns are suitable to uniquely identify rows. The results of the search are
used to build a WHERE clause which uniquely identifies the row on the
target column to apply data.
v Specify the keySelect the target columns from the Key Columns list. Use
if one or more target columns uniquely identifies a row.
12. Choose a replication method from the following and click Next:
v Mirror (Change Data Capture)Immediately replicates changes made to
the source table to the target table or accumulate source table changes and
replicate at a later time. If your configuration requires you to prevent
recursive updates when mirroring, enable the Prevent Recursion check box.
This check box is only available in versions of InfoSphere CDC that support
both source and target databases.
v Refresh (Snapshot)Replicates a snapshot of the source table to the target
table.
v Use Relative Record NumberEnables InfoSphere CDC to replicate
updates to the target using a relative record number. When this option is
checked, InfoSphere CDC sends the Relative Record Number to the target
and expects the Relative Record Number to be the identifying column on
the target side. This means that the target tables cannot be updated by more
than one source table (a target table cannot be a warehouse for multiple
source tables). If you do not check this box, then InfoSphere CDC for IBM i
uses a unique key to replicate to the target.

Notes:
When this option is checked, if the source table is reorganized,
InfoSphere CDC will automatically start a refresh for that table.
If no Relative Record Number is available on the target table (for
example, if the table resides on a non-IBM i system), you can still make
use of this option by mapping the Relative Record Number on the source
table to a column in the target table to. For more information, see
Source RRN (&CNTRRN) on page 174.
This option is only available when you have installed InfoSphere CDC
for IBM i on the source database.
13. Review the mapping settings.
14. Choose one of the following options and click Finish:
v Define column mappingsContinues with the column mapping.
v Create a new table mappingAllows you to start a new table mapping.
v Return to current viewReturns you to the current view.

106 InfoSphere Change Data Capture Management Console: Administration Guide

 Related concepts
Mapping using Adaptive Apply on page 102

Mapping to summarize data

If you want to accumulate or deduct numerical values on the target, then map
your source and target tables using the Summarization mapping type. There are
two types of summarization: Accumulation and Deduction. Accumulation ensures
that numeric changes applied to the target column are directly proportional to
changes applied to the corresponding source columns. Deduction ensures that
numeric changes applied to the target columns are inversely proportional to
changes applied to mapped source columns.

See also:
To map a source table to summarize data
To map multi-member source tables using Summarization on IBM i on page
108

To map a source table to summarize data

1. Click Configuration > Subscriptions.
2. Select a subscription, right-click and select Map Tables.
3. Select One table mapping of any type.
4. Select Summarization from the Mapping type list.
5. Expand the database, schema, or table from the Source Tables list to view
tables from your database that are available for mapping. Right-click the
database user or schema and click Refresh if you do not see your table listed.
You may be prompted to filter databases, schemas, or tables if Automatically
prompt for filter when expanding nodes is enabled in your preferences. For
more information see, Setting advanced preferences on page 15. To
manually define a filter, select a datastore, database, or schema and click
Specify Filter.
6. Enable the table to map from the Source Table list. If you do not see your
table listed, right-click the database user or schema and select Refresh.
7. If you want to hide columns so that the target is not aware of them, select a
source table and click Filter Columns. Clear the check box for the column you
want to hide and click OK.
8. Click Next.
9. Expand the database, schema, or table from the Target Tables list to view
tables from your database that are available for mapping. Right-click the
database user or schema and click Refresh if you do not see your table listed.
10. Enable a table to map from the Target Table list and click Next. If you do not
see your table listed, right-click the database user or schema and select
Refresh. Click Next.
If you want to create a new table to map to, click Create Table.
11. Select the target columns from the Key Columns list and click Next.
12. Choose one of the following from the Summarization Type list:
v AccumulationNumeric changes applied to target columns are directly
proportional to changes applied to source columns.
v DeductionNumeric changes applied to target columns are inversely
proportional to changes applied to source columns.
13. Select the source column from the Summarized Column list and click Next.
Mapping tables 107
 14. Choose a replication method from the following and click Next:
v Mirror (Change Data Capture)Immediately replicates changes made to
the source table to the target table or accumulate source table changes and
replicate at a later time. If your configuration requires you to prevent
recursive updates when mirroring, enable the Prevent Recursion check box.
This check box is only available in versions of InfoSphere CDC that support
both source and target databases.
v Refresh (Snapshot)Replicates a snapshot of the source table to the target
table.
15. If you are replicating source database changes using InfoSphere CDC for
Oracle Trigger-based edition and want to use a journal table to mirror
database operations from the source to the target table, then enable one of the
following:
v Use Default JournalEnable when you want InfoSphere CDC for Oracle to
use the default journal table provided with InfoSphere CDC for Oracle: <TS
SCHEMA>.DMCJRN. InfoSphere CDC uses this journal table to detect and
replicate database changes from the source to the target.
v Use Selected JournalEnable when you want InfoSphere CDC for Oracle
to use another journal table other than the default journal table provided
with InfoSphere CDC for Oracle. When you select the database owner and
provide a name for the journal table, InfoSphere CDC for Oracle creates this
new journal table and uses it to detect and replicate database changes from
the source to the target.
OwnerLists the database owner of the journal table.
NameLists the name of the journal table.
16. If you have configured bidirectional replication, then enable the Prevent
Recursion check box. This prevents InfoSphere CDC from replicating changes
back to the source database when you have configured a subscription for
bidirectional replication. This is only available in versions of InfoSphere CDC
that support both source and target databases. Contact IBM Technical Support
to implement bidirectional replication in your environment.
17. Click Next.
18. Review the mapping settings.
19. Choose one of the following options and click Finish:
v Define column mappingsContinues with the column mapping.
v Create a new table mappingAllows you to start a new table mapping.
v Return to current viewReturns you to the current view.
Related concepts
Mapping to summarize data on page 107

To map multi-member source tables using Summarization on

IBM i
1. Click Configuration > Subscriptions.
2. Select a subscription, right-click and select Map Tables.
3. Enable One table mapping of any type.
4. Select Summarization from the Mapping type list.
5. Expand the database, schema, or table from the Source Tables list to view
tables from your database that are available for mapping. Right-click the
database user or schema and click Refresh if you do not see your table listed.

108 InfoSphere Change Data Capture Management Console: Administration Guide

 You may be prompted to filter databases, schemas, or tables if Automatically
prompt for filter when expanding nodes is enabled in your preferences. For
more information see, Setting advanced preferences on page 15. To
manually define a filter, select a datastore, database, or schema and click
Specify Filter.
6. Enable the table to map from the Source Table list. If you do not see your
table listed, right-click the database user or schema and select Refresh.
7. If you want to hide columns so that the target is not aware of them, select a
source table and click Filter Columns. Clear the check box for the column you
want to hide and click OK.
8. Click Next.
9. Expand the database, schema, or table from the Target Tables list to view
tables from your database that are available for mapping. Right-click the
database user or schema and click Refresh if you do not see your table listed.
10. Enable a table to map from the Target Table list and click Next. If you do not
see your table listed, right-click the database user or schema and select
Refresh. Click Next.
If you want to create a new table to map to, click Create Table.
11. Select the target columns from the Key Columns list and click Next.
InfoSphere CDC for IBM i requires that the selected key columns match an
existing index.
12. Choose one of the following from the Summarization Type list:
v AccumulationNumeric changes applied to target columns are directly
proportional to changes applied to source columns.
v DeductionNumeric changes applied to target columns are inversely
proportional to changes applied to source columns.
13. Select the source column from the Summarized Column list and click Next.
14. Choose a replication method from the following and click Next:
v Mirror (Change Data Capture)Immediately replicates changes made to
the source table to the target table or accumulate source table changes and
replicate at a later time. If your configuration requires you to prevent
recursive updates when mirroring, enable the Prevent Recursion check box.
This check box is only available in versions of InfoSphere CDC that support
both source and target databases.
v Refresh (Snapshot)Replicates a snapshot of the source table to the target
table.
v Use Relative Record NumberEnables InfoSphere CDC to replicate
updates to the target using a relative record number. When this option is
checked, InfoSphere CDC sends the Relative Record Number to the target
and expects the Relative Record Number to be the identifying column on
the target side. This means that the target tables cannot be updated by more
than one source table (a target table cannot be a warehouse for multiple
source tables). If you do not check this box, then InfoSphere CDC for IBM i
uses a unique key to replicate to the target.

Notes:
When this option is checked, if the source table is reorganized,
InfoSphere CDC will automatically start a refresh for that table.
If no Relative Record Number is available on the target table (for
example, if the table resides on a non-IBM i system), you can still make
use of this option by mapping the Relative Record Number on the source

Mapping tables 109

 table to a column in the target table to. For more information, see
Source RRN (&CNTRRN) on page 174.
This option is only available when you have installed InfoSphere CDC
for IBM i on the source database.
15. Review the mapping settings.
16. Choose one of the following options and click Finish:
v Define column mappingsContinues with the column mapping.
v Create a new table mappingAllows you to start a new table mapping.
v Return to current viewReturns you to the current view.
Related concepts
Mapping to summarize data on page 107

Mapping to consolidate data (one-to-one)

If your business environment contains information that is scattered across different
source tables, you may want to consolidate it to facilitate report generation, data
management, or data security. To merge different information about a common
entity into a single row, such as a person, a customer, or a product part, map your
source table to your target table using the Consolidation one-to-one mapping type.

See also:
To map a source table to consolidate data (one-to-one)
To map multi-member source tables using Consolidation One-to-One on IBM
i on page 112
Related concepts
Mapping using standard replication on page 83
Adding and mapping derived columns to target columns on page 154
Related tasks
To map a source table to consolidate data (one-to-many) on page 114
To map multi-member source tables using Consolidation one-to-many on IBM i
on page 116
Related reference
Retrieve column%GETCOL (Dynamic SQL) on page 252

To map a source table to consolidate data (one-to-one)

1. Click Configuration > Subscriptions.
2. Select a subscription, right-click and select Map Tables.
3. Enable One table mapping of any type.
4. Select Consolidation One-to-one from the Mapping type list.
5. Expand the database, schema, or table from the Source Tables list to view
tables from your database that are available for mapping. Right-click the
database user or schema and click Refresh if you do not see your table listed.
You may be prompted to filter databases, schemas, or tables if Automatically
prompt for filter when expanding nodes is enabled in your preferences. For
more information see, Setting advanced preferences on page 15. To
manually define a filter, select a datastore, database, or schema and click
Specify Filter.
6. Enable the table to map from the Source Table list. If you do not see your
table listed, right-click the database user or schema and select Refresh.

110 InfoSphere Change Data Capture Management Console: Administration Guide

 7. If you want to hide columns so that the target is not aware of them, select a
source table and click Filter Columns. Clear the check box for the column you
want to hide and click OK.
8. Click Next.
9. Expand the database, schema, or table from the Target Tables list to view
tables from your database that are available for mapping. Right-click the
database user or schema and click Refresh if you do not see your table listed.
10. Enable a table to map from the Target Table list and click Next. If you do not
see your table listed, right-click the database user or schema and select
Refresh. Click Next.
If you want to create a new table to map to, click Create Table.
11. Check the key for the target columns and click Next.
12. Choose a replication method from the following and click Next:
v Mirror (Change Data Capture)Immediately replicates changes made to
the source table to the target table or accumulate source table changes and
replicate at a later time. If your configuration requires you to prevent
recursive updates when mirroring, enable the Prevent Recursion check box.
This check box is only available in versions of InfoSphere CDC that support
both source and target databases.
v Refresh (Snapshot)Replicates a snapshot of the source table to the target
table.
13. If you are replicating source database changes using InfoSphere CDC for
Oracle Trigger-based edition and want to use a journal table to mirror
database operations from the source to the target table, then enable one of the
following:
v Use Default JournalEnable when you want InfoSphere CDC for Oracle to
use the default journal table provided with InfoSphere CDC for Oracle: <TS
SCHEMA>.DMCJRN. InfoSphere CDC uses this journal table to detect and
replicate database changes from the source to the target.
v Use Selected JournalEnable when you want InfoSphere CDC for Oracle
to use another journal table other than the default journal table provided
with InfoSphere CDC for Oracle. When you select the database owner and
provide a name for the journal table, InfoSphere CDC for Oracle creates this
new journal table and uses it to detect and replicate database changes from
the source to the target.
OwnerLists the database owner of the journal table.
NameLists the name of the journal table.
14. If you have configured bidirectional replication, then enable the Prevent
Recursion check box. This prevents InfoSphere CDC from replicating changes
back to the source database when you have configured a subscription for
bidirectional replication. This is only available in versions of InfoSphere CDC
that support both source and target databases. Contact IBM Technical Support
to implement bidirectional replication in your environment.
15. Click Next.
16. Review the mapping settings.
17. Choose one of the following options and click Finish:
v Define column mappingsContinues with the column mapping.
v Create a new table mappingAllows you to start a new table mapping.
v Return to current viewReturns you to the current view.

Mapping tables 111

 Related concepts
Mapping to consolidate data (one-to-one) on page 110

To map multi-member source tables using Consolidation

One-to-One on IBM i
1. Click Configuration > Subscriptions.
2. Select a subscription, right-click and select Map Tables.
3. Select One table mapping of any type.
4. Select Consolidation One-to-one from the Mapping type list.
5. Expand the database, schema, or table from the Source Tables list to view
tables from your database that are available for mapping. Right-click the
database user or schema and click Refresh if you do not see your table listed.
You may be prompted to filter databases, schemas, or tables if Automatically
prompt for filter when expanding nodes is enabled in your preferences. For
more information see, Setting advanced preferences on page 15. To
manually define a filter, select a datastore, database, or schema and click
Specify Filter.
6. Enable the table to map from the Source Table list. If you do not see your
table listed, right-click the database user or schema and select Refresh.
7. If you want to hide columns so that the target is not aware of them, select a
source table and click Filter Columns. Clear the check box for the column you
want to hide and click OK.
8. Click Next.
9. Expand the database, schema, or table from the Target Tables list to view
tables from your database that are available for mapping. Right-click the
database user or schema and click Refresh if you do not see your table listed.
10. Enable a table to map from the Target Table list and click Next. If you do not
see your table listed, right-click the database user or schema and select
Refresh. Click Next.
If you want to create a new table to map to, click Create Table.
11. Check the key for the target columns and click Next.
12. Choose a replication method from the following and click Next:
v Mirror (Change Data Capture)Immediately replicates changes made to
the source table to the target table or accumulate source table changes and
replicate at a later time. If your configuration requires you to prevent
recursive updates when mirroring, enable the Prevent Recursion check box.
This check box is only available in versions of InfoSphere CDC that support
both source and target databases.
v Refresh (Snapshot)Replicates a snapshot of the source table to the target
table.
v Use Relative Record NumberEnables InfoSphere CDC to replicate
updates to the target using a relative record number. When this option is
checked, InfoSphere CDC sends the Relative Record Number to the target
and expects the Relative Record Number to be the identifying column on
the target side. This means that the target tables cannot be updated by more
than one source table (a target table cannot be a warehouse for multiple
source tables). If you do not check this box, then InfoSphere CDC for IBM i
uses a unique key to replicate to the target.

Notes:

112 InfoSphere Change Data Capture Management Console: Administration Guide

 When this option is checked, if the source table is reorganized,
InfoSphere CDC will automatically start a refresh for that table.
If no Relative Record Number is available on the target table (for
example, if the table resides on a non-IBM i system), you can still make
use of this option by mapping the Relative Record Number on the source
table to a column in the target table to. For more information, see
Source RRN (&CNTRRN) on page 174.
This option is only available when you have installed InfoSphere CDC
for IBM i on the source database.
13. Review the mapping settings.
14. Choose one of the following options and click Finish:
v Define column mappingsContinues with the column mapping.
v Create a new table mappingAllows you to start a new table mapping.
v Return to current viewReturns you to the current view.
Related concepts
Mapping to consolidate data (one-to-one) on page 110

Mapping to consolidate data (one-to-many)

If you are using a lookup table to make updates to a target table, then you can
map your lookup table using one-to-many row consolidation. When you map a
lookup table using one-to-many consolidation, InfoSphere CDC only applies
updates to the rows in the target table.
v If you insert a row into your lookup table, InfoSphere CDC:
Does not apply an operation to the target table (leaves the target table
unchanged); or
Updates the row that has the same consolidation key value.
v If you delete a row from your lookup table, InfoSphere CDC does not apply an
operation to target table.
v If you update a row in your lookup table, InfoSphere CDC updates all rows
that have the same consolidation key value.

The following example illustrates how InfoSphere CDC can update regional tax
code information in a target table that was mapped to a source table using One to
Many Consolidation. When there are updates made to the lookup table
TAXCODES, InfoSphere CDC updates these columns in the target table.

Before you map your lookup table for one-to-many

consolidation, make sure you have completed the following
tasks:
v Created a lookup table
For InfoSphere CDC to accomplish one-to-many row consolidation, you need to
create a lookup table that contains the columns you want InfoSphere CDC to

Mapping tables 113

 update in your target table. For example, if you want InfoSphere CDC to update
tax codes for a specific state, then make sure these columns exist in your lookup
table and that you set a primary key. For example, the primary key in the
TAXCODES table would be STATE. You can then map your lookup table to the
target table using one-to-many consolidation.
v Mapped your source table to the target table using Standard mapping type
InfoSphere CDC requires that at least one source table is mapped to the target
table using a mapping type other than one-to-many consolidation, such as
Standard. When you map a source table using one-to-many mapping, InfoSphere
CDC only updates the target table and does not insert or delete rows in the
target table. Therefore, another mapping type such as Standard ensures that
InfoSphere CDC populates the target table with source data. You need to
identify the primary key on the source table. For example, to populate the target
table STOREDATA with data from the source table STORELOC, you would map
the source columns STORE, CITY, STATE, and TAX to the target columns
STORE_CON, CITY_CON, STATE_CON, and TAX_CON. You can map these
columns using Standard mapping type.
v Created a derived column on the source table using %GETCOL to retrieve
data from your lookup table
After mapping your source table to the target table using Standard mapping
type, InfoSphere CDC requires you create a derived column on the source table
to retrieve data from the lookup table when replicating data from the source to
the target table. For example, if you want your source table to retrieve tax codes
and state information from the TAXCODES table, your %GETCOL expression
would be: %GETCOL(TAX, TAXCODES, <default value>, STATE, STATE). The
default value of the tax you want InfoSphere CDC to retrieve is up to you. In
this example, a typical default value would be 0.

See also:
To map a source table to consolidate data (one-to-many)
To map multi-member source tables using Consolidation one-to-many on IBM
i on page 116

To map a source table to consolidate data (one-to-many)

1. Click Configuration > Subscriptions.
2. Select a subscription, right-click and select Map Tables.
3. Enable One table mapping of any type.
4. Select Consolidation One-to-one from the Mapping type list.
5. Expand the database, schema, or table from the Source Tables list to view
tables from your database that are available for mapping. Right-click the
database user or schema and click Refresh if you do not see your table listed.
You may be prompted to filter databases, schemas, or tables if Automatically
prompt for filter when expanding nodes is enabled in your preferences. For
more information see, Setting advanced preferences on page 15. To
manually define a filter, select a datastore, database, or schema and click
Specify Filter.
6. Enable the table to map from the Source Table list. If you do not see your
table listed, right-click the database user or schema and select Refresh.
7. If you want to hide columns so that the target is not aware of them, select a
source table and click Filter Columns. Clear the check box for the column you
want to hide and click OK.
8. Click Next.

114 InfoSphere Change Data Capture Management Console: Administration Guide

 9. Expand the database, schema, or table from the Target Tables list to view
tables from your database that are available for mapping. Right-click the
database user or schema and click Refresh if you do not see your table listed.
10. Enable a table to map from the Target Table list and click Next. If you do not
see your table listed, right-click the database user or schema and select
Refresh. Click Next.
If you want to create a new table to map to, click Create Table.
11. Check the consolidation key for the target columns and click Next. InfoSphere
CDC uses the consolidation key to determine the rows that will be updated in
the target table in response to an update in the look-up table. The
consolidation key must identify the same column you identified as the
primary key in the lookup table.
12. Choose a replication method from the following and click Next:
v Mirror (Change Data Capture)Immediately replicates changes made to
the source table to the target table or accumulate source table changes and
replicate at a later time. If your configuration requires you to prevent
recursive updates when mirroring, enable the Prevent Recursion check box.
This check box is only available in versions of InfoSphere CDC that support
both source and target databases.
v Refresh (Snapshot)Replicates a snapshot of the source table to the target
table.
13. If you are replicating source database changes using InfoSphere CDC for
Oracle Trigger-based edition and want to use a journal table to mirror
database operations from the source to the target table, then enable one of the
following:
v Use Default JournalEnable when you want InfoSphere CDC for Oracle to
use the default journal table provided with InfoSphere CDC for Oracle: <TS
SCHEMA>.DMCJRN. InfoSphere CDC uses this journal table to detect and
replicate database changes from the source to the target.
v Use Selected JournalEnable when you want InfoSphere CDC for Oracle
to use another journal table other than the default journal table provided
with InfoSphere CDC for Oracle. When you select the database owner and
provide a name for the journal table, InfoSphere CDC for Oracle creates this
new journal table and uses it to detect and replicate database changes from
the source to the target.
OwnerLists the database owner of the journal table.
NameLists the name of the journal table.
14. If you have configured bidirectional replication, then enable the Prevent
Recursion check box. This prevents InfoSphere CDC from replicating changes
back to the source database when you have configured a subscription for
bidirectional replication. This is only available in versions of InfoSphere CDC
that support both source and target databases. Contact IBM Technical Support
to implement bidirectional replication in your environment.
15. Click Next.
16. Review the mapping settings.
17. Choose one of the following options and click Finish:
v Define column mappingsContinues with the column mapping.
v Create a new table mappingAllows you to start a new table mapping.
v Return to current viewReturns you to the current view.
18. After you map your lookup table for one-to-many consolidation, set the
following on the table mapping:

Mapping tables 115

 a. Select the table mapping you just created in the Table Mappings view and
right-click Open Mapping Details.
b. Verify your column mappings to the target table on the Column
Mappings tab. Make sure that the appropriate columns from the lookup
table are mapped to the target table.
c. Select Update all if exists from the On Insert list on the Operations tab.
This ensures that InfoSphere CDC updates all rows where the
consolidation key is the same when there is an insert on the lookup table.
d. Click Apply.

To map multi-member source tables using Consolidation

one-to-many on IBM i
1. Click Configuration > Subscriptions.
2. Select a subscription, right-click and select Map Tables.
3. Select One table mapping of any type.
4. Select Consolidation One-to-one from the Mapping type list.
5. Expand the database, schema, or table from the Source Tables list to view
tables from your database that are available for mapping. Right-click the
database user or schema and click Refresh if you do not see your table listed.
You may be prompted to filter databases, schemas, or tables if Automatically
prompt for filter when expanding nodes is enabled in your preferences. For
more information see, Setting advanced preferences on page 15. To
manually define a filter, select a datastore, database, or schema and click
Specify Filter.
6. Enable the table to map from the Source Table list. If you do not see your
table listed, right-click the database user or schema and select Refresh.
7. If you want to hide columns so that the target is not aware of them, select a
source table and click Filter Columns. Clear the check box for the column you
want to hide and click OK.
8. Click Next.
9. Expand the database, schema, or table from the Target Tables list to view
tables from your database that are available for mapping. Right-click the
database user or schema and click Refresh if you do not see your table listed.
10. Select a table from the Target Table list. If you do not see your table listed,
select the database user or schema and click Refresh. Choose one of the
following options and click Next:
v Source and Target Files are Single MemberMerges all members from the
source table to a single-member target table.
v Use Source member Structure on TargetMaintains the same
multi-member structure on the target table as the one on the source table.
Each source member is mapped to the corresponding target member.
v Merge Source Members into One Target MemberMerges all members
from the source table to a single member in a multi-member.
11. If you want to create a new table to map to, click Create Table.
12. Check the key for the target columns and click Next.
13. Choose a replication method from the following and click Next:
v Mirror (Change Data Capture)Immediately replicates changes made to
the source table to the target table or accumulate source table changes and
replicate at a later time. If your configuration requires you to prevent

116 InfoSphere Change Data Capture Management Console: Administration Guide

 recursive updates when mirroring, enable the Prevent Recursion check box.
This check box is only available in versions of InfoSphere CDC that support
both source and target databases.
v Refresh (Snapshot)Replicates a snapshot of the source table to the target
table.
v Use Relative Record NumberEnables InfoSphere CDC to replicate
updates to the target using a relative record number. When this option is
checked, InfoSphere CDC sends the Relative Record Number to the target
and expects the Relative Record Number to be the identifying column on
the target side. This means that the target tables cannot be updated by more
than one source table (a target table cannot be a warehouse for multiple
source tables). If you do not check this box, then InfoSphere CDC for IBM i
uses a unique key to replicate to the target.

Notes:
When this option is checked, if the source table is reorganized,
InfoSphere CDC will automatically start a refresh for that table.
If no Relative Record Number is available on the target table (for
example, if the table resides on a non-IBM i system), you can still make
use of this option by mapping the Relative Record Number on the source
table to a column in the target table to. For more information, see
Source RRN (&CNTRRN) on page 174.
This option is only available when you have installed InfoSphere CDC
for IBM i on the source database.
14. Review the mapping settings.
15. Choose one of the following options and click Finish:
v Define column mappingsContinues with the column mapping.
v Create a new table mappingAllows you to start a new table mapping.
v Return to current viewReturns you to the current view.
16. After you map your lookup table for one-to-many consolidation, set the
following on the table mapping:
a. Select the table mapping you just created in the Table Mappings view and
right-click Open Mapping Details.
b. Verify your column mappings to the target table on the Column
Mappings tab. Make sure that the appropriate columns from the lookup
table are mapped to the target table.
c. Select Update all if exists from the On Insert list on the Operations tab.
This ensures that InfoSphere CDC updates all rows where the
consolidation key is the same when there is an insert on the lookup table.
d. Click Apply.

Mapping to a datastore outside of your organization

If you are mapping tables for a subscription with an external target datastore, the
organization that owns the external target datastore must first add tables to the
subscription before you can map the tables. After adding tables to the subscription,
you can map tables using one of the available mapping types.

See also:
To map tables for a subscription on an external datastore on page 118

Mapping tables 117

 To map tables for a subscription on an external datastore
1. Click Configuration > Subscriptions.
2. Select a subscription, right-click and select Map Tables.
3. Expand the database, schema, or table from the Source Tables list to view
tables from your database that are available for mapping. Right-click the
database user or schema and click Refresh if you do not see your table listed.
You may be prompted to filter databases, schemas, or tables if Automatically
prompt for filter when expanding nodes is enabled in your preferences. For
more information see, Setting advanced preferences on page 15. To manually
define a filter, select a datastore, database, or schema and click Specify Filter.
4. Enable one or more tables to map from the Source Tables list. If you do not see
your table listed, right-click the database user or schema and select Refresh.
5. If you want to hide columns so that the target is not aware of them, select a
source table and click Filter Columns. Clear the check box for the column you
want to hide and click OK.
6. Click Next.
7. Review the mapping settings.
8. Click Finish.
Related concepts
Mapping to a datastore outside of your organization on page 117

Mapping to a JMS Message Destination using InfoSphere CDC Event

Server
InfoSphere CDC Event Server receives replicated row-level operations (inserts,
updates, deletes) from your source database and transforms these rows into XML.

Using InfoSphere CDC Management Console, you can map source columns to
XML elements and attributes. When you start mirroring and if there is a row-level
operation on your source table, InfoSphere CDC Event Server receives and applies
the row-level operation to the XML document which is sent to a JMS message
destination (queue or topic). Before you can use InfoSphere CDC Event Server to
transform table data in XML, you must install and setup a InfoSphere CDC source
product that can scrape row-level operations (inserts, updates, and deletes) from
your source database.

InfoSphere CDC Event Server is a target-only product. This means that InfoSphere
CDC Event Server can only receive row-level and table-level operations already
replicated from another supported InfoSphere CDC product that you have
installed. You must install another InfoSphere CDC product and connect to this
datastore so that you can select the source tables you want to make available for
replication. You can then continue to add a subscription that uses InfoSphere CDC
Event Server as the target datastore.

There are two methods for mapping to a JMS Message Destination:

v Message Destination MappingsAllows you to map a source table to a JMS
message destination. In this method, InfoSphere CDC Event Server receives the
row-level operation (insert, update, or delete) and transforms it into a row that
is inserted into an XML message. The Message Destination Mappings mapping
type option is available in the Map Tables wizard. When you map a source
table to a message destination, InfoSphere CDC Event Server receives the

118 InfoSphere Change Data Capture Management Console: Administration Guide

 row-level operation and transforms this row into XML. This XML message is
sent to a JMS application supported by InfoSphere CDC Event Server.
v One table mapping of any type:
StandardYou can stage your source table in an embedded target staging
database using the Standard mapping type provided with InfoSphere CDC
Event Server. In this method, the standard mapping type creates an exact
copy of your source table in the staging database and to a JMS message
destination. InfoSphere CDC Event Server receives the row-level operation
from the staging database and transforms it into XML. When you select the
One table mapping of any type option in the Map Tables wizard and choose
Standard, the wizard lets you map your source table to a target table
available in an embedded staging database provided with InfoSphere CDC
Event Server. InfoSphere CDC Event Server provides an embedded staging
database as a temporary repository for your source table before it is
transformed to XML. You may want to map your source table to a target
staging table in order to customize the source table outside of your
production database in some way before InfoSphere CDC Event Server
converts the replicated rows into XML. Also, by mapping the source table to a
staging database, you can reduce performance overhead on your production
database. InfoSphere CDC Event Server depends on the staging database
(instead of your production database) to receive and transform replicated
rows into XML.
Adaptive ApplyAdaptive Apply ensures that replicated rows in the source
and target tables are the same. You can also use Adaptive Apply to restore the
contents of a target table from recorded journal or log entries. To do this, you
set the journal or log position to a specific entry or point in time, and then
use Adaptive Apply to populate an empty target table with the latest data.

Setting mapping details on a subscription that targets a JMS

Message destination

Management Console lets you create an XML message for subscriptions that target
JMS message destinations. In addition to the existing mapping details that you can
configure with other InfoSphere CDC products you install, Management Console
provides additional configuration details available only with subscriptions created
with InfoSphere CDC Event Server:
v XML Message tabUse this tab to create your XML message, import and export
mapping projects, import and export XML schemas, build XPath expressions,
and query columns from other tables if required.
v XML Settings tabUse this tab to set JMS message header properties and set
general runtime options.

As with other InfoSphere CDC products, the Filtering tab, the Translation tab, and
the User Exits tab are available for configuration with InfoSphere CDC Event
Server. The Column mappings tab and the Operations tab are only available if you
have mapped your source table to a target staging table.
v Column Mapping tabUse this tab to map source columns to columns in a
target staging table. InfoSphere CDC Event Server provides an embedded
staging database as a temporary repository for your source table before it is
converted into XML. This tab is only available if you have you have mapped
your source table to a target staging table using the Standard mapping type in
the Map Tables wizard. You may want to map your source table to a target
staging table when:

Mapping tables 119

 You want to customize the source table outside of your production database.
Before mapping your source table to a JMS message destination, you can map
your source table to a target staging table in order to send a copy of the
source table to the staging database. Using the Column Mappings tab, you
can decide on the source columns you want to map (or unmap) from columns
in the target staging table. This lets you control which columns you want to
include or exclude for replication and therefore the kind of data you want to
include or exclude for InfoSphere CDC Event Server to XML.
You want to reduce performance overhead on your production database.
Because you have mapped your source table to a target staging table, when
you start replication, a copy of your source table is sent to the staging
database. In this scenario, InfoSphere CDC Event Server receives replicated
rows from the staging database (instead of your production database) and
transforms these rows into XML. This setup reduces performance overhead
on your production environment.
v Filtering tabUse this tab to include or exclude rows or columns for
replication.
v Translation tabDepending on how you have mapped your source table, you
can use this tab to add a data translation between your source and target staging
columns and set encoding conversions or both. You can only set a data
translation on a subscription for source columns that are mapped to target
staging columns. If you have only mapped your source table to a JMS message
destination, then you can only set encoding conversions for any multibyte
character sets in your source table. When you add a data translation and start
replication, the supported InfoSphere CDC source product translates values from
the source column into the new value you specified for the mapped target
column. InfoSphere CDC Event Server then inserts the translated value into an
XML document.
v Encoding tabUse this tab to view and set encoding options. For InfoSphere
CDC version 6.3 and earlier, Management Console provides standard character
sets and encodings. To add additional character sets and encodings, use the CSV
(comma separated variable) template that is found in the Advanced preferences
of Edit > Preferences. This step is not necessary for InfoSphere CDC version 6.5,
which retrieves the supported encodings directly from your datastores.
v Operation tabUse this tab to control how InfoSphere CDC Event Server
applies row-level operations (insert, update, and deletes) and table-level
operations (truncate/clear) to the target staging table. This tab is only available
if you have you have mapped your source table to a target staging table using
the Standard mapping type in the Map Tables wizard.
v User Exits tabUse this tab configure a user exit for InfoSphere CDC Event
Server. User exits define a set of actions that you want InfoSphere CDC Event
Server to run either before or after applying a row-level operation. Depending
on how you have mapped your source table, InfoSphere CDC Event Server can
run the user exit before or after applying a row-level operation to the target
staging table, run the user exit before or after applying a row-level operation to
the JMS message destination, or both. Row-level operations include an insert,
update, or a delete.

See also:
To map multiple source tables to a JMS message destination on page 121
To map a single source table to a JMS message destination on page 122
To stage a source table on page 124

120 InfoSphere Change Data Capture Management Console: Administration Guide

To map multiple source tables to a JMS message destination
1. Click Configuration > Datastores.
Ensure that you are connected to an Event Server datastore.
2. Click Configuration > Subscriptions.
Ensure that you have created a subscription that uses the Event Server
datastore as the target.
3. Select a subscription, right-click and select Map Tables.
Ensure that you have ended replication on the subscription.
4. Select Message Destination Mappings.
5. Click Next.
6. Expand the database, schema, or table from the Source Tables list to view
tables from your database that are available for mapping. Right-click the
database user or schema and click Refresh if you do not see your table listed.
You may be prompted to filter databases, schemas, or tables if Automatically
prompt for filter when expanding nodes is enabled in your preferences. For
more information see, Setting advanced preferences on page 15. To
manually define a filter, select a datastore, database, or schema and click
Specify Filter.
7. Enable one or more tables to map from the Source Tables list. If you do not
see your table listed, right-click the database user or schema and select
Refresh.
8. If you want to hide columns so that the target is not aware of them, select a
source table and click Filter Columns. Clear the check box for the column you
want to hide and click OK.
9. Click Next.
10. Enable one of the following options:
v Use the source table structure for the XML message:
Include before-image valuesEnable this check box when you want the
XML message to include the before image of a row-level operation. The
before-image represents the data in the source column before an insert,
update, or delete operation on the row.
Include after-image valuesEnable this check box when you want the
XML message to include the after image of a row-level operation. The
after-image represents the data in the source column after an insert,
update, or delete operation on the row.
Include journal control valuesEnable this check box when you want
the XML message to include journal control fields. These provide
information about the source table, the source database, or the row-level
operations taking place in the database log or journal of the source
database. For example, the _ENNTYPE journal control field indicates the
type of row-level operation (insert, update, or delete) that took place on
the source table.
v Value FormatChoose how you want to format source column data in the
XML message. You can choose from one of the following:
Use attributes for data valuesFormats data values of the before image,
the after image, or journal control fields in your XML message as XML
attributes.
Use elements for data valuesFormats data values of the before image,
the after image, or journal control fields in your XML message as XML
elements.

Mapping tables 121

 v Do not specify the message format at this timeEnable this option when
you want to manually decide whether you want to include the before or
after image values for source columns, or journal control fields in your
XML document.
11. Click Next.
12. Select and expand the JMS connection you had configured in the InfoSphere
CDC Event Server Configuration Tool and select an existing destination or
click Add Destination to add a queue or a topic.
13. Type the name of queue or topic in the Name box.
14. Type a brief description about the queue or topic in the Description box.
15. Type the JNDI name of the JMS queue or topic to which you want to send the
XML message in the Request Destination box.
16. Enable one of the following options:
v Use persistent deliveryEnable to ensure the message is not lost in transit
due to a JMS provider failure.
v Use transacted sessionsEnables InfoSphere CDC Event Server to open a
transacted session and commit every message to the JMS queue or topic.
17. Click Test and OK.
18. Click Next and Finish.
Related concepts
Mapping to a JMS Message Destination using InfoSphere CDC Event Server on
page 118
InfoSphere CDC Event Server receives replicated row-level operations (inserts,
updates, deletes) from your source database and transforms these rows into XML.
Related tasks
To map a single source table to a JMS message destination
To stage a source table on page 124

To map a single source table to a JMS message destination

1. Click Configuration > Datastores.
Ensure that you are connected to an Event Server datastore.
2. Click Configuration > Subscriptions.
Ensure that you have created a subscription that uses the Event Server
datastore as the target.
3. Select a subscription, right-click and select Map Tables.
Ensure that you have ended replication on the subscription.
4. Select Message Destination Mappings.
5. Click Next.
6. Expand the database, schema, or table from the Source Tables list to view
tables from your database that are available for mapping. Right-click the
database user or schema and click Refresh if you do not see your table listed.
You may be prompted to filter databases, schemas, or tables if Automatically
prompt for filter when expanding nodes is enabled in your preferences. For
more information see, Setting advanced preferences on page 15. To
manually define a filter, select a datastore, database, or schema and click
Specify Filter.
7. Enable one or more tables to map from the Source Tables list. If you do not
see your table listed, right-click the database user or schema and select
Refresh.

122 InfoSphere Change Data Capture Management Console: Administration Guide

 8. If you want to hide columns so that the target is not aware of them, select a
source table and click Filter Columns. Clear the check box for the column you
want to hide and click OK.
9. Click Next.
10. Enable one of the following options:
v Use the source table structure for the XML message:
Include before-image valuesEnable this check box when you want the
XML message to include the before image of a row-level operation. The
before-image represents the data in the source column before an insert,
update, or delete operation on the row.
Include after-image valuesEnable this check box when you want the
XML message to include the after image of a row-level operation. The
after-image represents the data in the source column after an insert,
update, or delete operation on the row.
Include journal control valuesEnable this check box when you want
the XML message to include journal control fields. These provide
information about the source table, the source database, or the row-level
operations taking place in the database log or journal of the source
database. For example, the _ENNTYPE journal control field indicates the
type of row-level operation (insert, update, or delete) that took place on
the source table.
v Value FormatChoose how you want to format source column data in the
XML message. You can choose from one of the following:
Use attributes for data valuesFormats data values of the before image,
the after image, or journal control fields in your XML message as XML
attributes.
Use elements for data valuesFormats data values of the before image,
the after image, or journal control fields in your XML message as XML
elements.
v Do not specify the message format at this timeEnable this option when
you want to manually decide whether you want to include the before or
after image values for source columns, or journal control fields in your
XML document.
11. If you have decided to format the XML message based on an imported
schema, mapping project, or XML file, then browse for the file and enable one
or both of the following options:
v Import repeated elements with the same parentBy default, InfoSphere
CDC Event Server imports only one repeated element in a group node with
the same parent. Enable this option to import all repeated elements.
v Import attribute valuesBy default, InfoSphere CDC Event Server imports
only the structure of your XML. Enable this option to import the attribute
values. This may be necessary if attribute values represent the structure of
your XML document.
12. Click Next.
13. Select and expand the JMS connection you had configured in the InfoSphere
CDC Event Server Configuration Tool and select an existing destination or
click Add Destination to add a queue or a topic.
14. Type the name of queue or topic in the Name box.
15. Type a brief description about the queue or topic in the Description box.
16. Type the JNDI name of the JMS queue or topic to which you want to send the
XML message in the Request Destination box.

Mapping tables 123

 17. Enable one of the following options:
v Use persistent deliveryEnable to ensure the message is not lost in transit
due to a JMS provider failure.
v Use transacted sessionsEnables InfoSphere CDC Event Server to open a
transacted session and commit every message to the JMS queue or topic.
18. Click Test and OK.
19. Click Next and Finish.
Related concepts
Mapping to a JMS Message Destination using InfoSphere CDC Event Server on
page 118
InfoSphere CDC Event Server receives replicated row-level operations (inserts,
updates, deletes) from your source database and transforms these rows into XML.
Related tasks
To map multiple source tables to a JMS message destination on page 121
To stage a source table

To stage a source table

1. Click Configuration > Datastores.
Ensure that you are connected to an Event Server datastore.
2. Click Configuration > Subscriptions.
Ensure that you have created a subscription that uses the Event Server
datastore as the target.
3. Select a subscription, right-click and select Map Tables.
Ensure that you have ended replication on the subscription.
4. Select One table mapping of any type.
5. Select either Standard or Adaptive Apply as the mapping type, depending on
your requirements.
6. Click Next.
7. Expand the database, schema, or table from the Source Tables list to view
tables from your database that are available for mapping. Right-click the
database user or schema and click Refresh if you do not see your table listed.
You may be prompted to filter databases, schemas, or tables if Automatically
prompt for filter when expanding nodes is enabled in your preferences. For
more information see, Setting advanced preferences on page 15. To
manually define a filter, select a datastore, database, or schema and click
Specify Filter.
8. Enable the table to map from the Source Table list. If you do not see your
table listed, right-click the database user or schema and select Refresh.
9. If you want to hide columns so that the target is not aware of them, select a
source table and click Filter Columns. Clear the check box for the column you
want to hide and click OK.
10. Click Next.
11. Expand the database, schema, or table from the Target Tables list to view
tables from your database that are available for mapping. Right-click the
database user or schema and click Refresh if you do not see your table listed.
12. Choose one of the following and click Next:
v Use an IndexSelect the index name from the Index box. Use if your target
table has an index that uniquely identifies a row.

124 InfoSphere Change Data Capture Management Console: Administration Guide

 v Use all searchable columnsSearches all target columns to identify which
columns are suitable to uniquely identify rows. The results of the search are
used to build a WHERE clause which uniquely identifies the row on the
target column to apply data.
v Specify the keySelect the target columns from the Key Columns list. Use
if one or more target columns uniquely identifies a row.
13. Choose a replication method from the following and click Next:
v Mirror (Change Data Capture)Immediately replicates changes made to
the source table to the target table or accumulate source table changes and
replicate at a later time. If your configuration requires you to prevent
recursive updates when mirroring, enable the Prevent Recursion check box.
This check box is only available in versions of InfoSphere CDC that support
both source and target databases.
v Refresh (Snapshot)Replicates a snapshot of the source table to the target
table.
14. Review the mapping summary.
15. Choose one of the following options and click Finish:
v Define column mappingsContinues with the column mapping.
v Create a new table mappingAllows you to start a new table mapping.
v Return to current viewReturns you to the current view.
Related concepts
Mapping to a JMS Message Destination using InfoSphere CDC Event Server on
page 118
InfoSphere CDC Event Server receives replicated row-level operations (inserts,
updates, deletes) from your source database and transforms these rows into XML.

Remapping a source table

You can remap an existing source table so that it is mapped to the correct target
table. If you want to remap a source table on a subscription that uses InfoSphere
CDC Event Server as the target datastore, then you can do the following:
v Remap a source table already mapped to a JMS message destination to a
staging target table.
v Remap a source table already mapped to a staging target table to a JMS
message destination.

See also:
To remap a source table
To remap a source table (InfoSphere CDC Event Server) on page 126

To remap a source table

1. Ensure that the subscription has at least one table mapping. You set this when
mapping tables in the Map Tables wizard.
2. Ensure that you have ended any active replication on the subscription.
3. Click Configuration > Subscriptions.
4. Select the subscription that contains the mapped source and target tables.
5. Select the mapped source and target tables in the Table Mappings view.
6. Right-click and click Remap Source Table .

Mapping tables 125

 Related concepts
Remapping a source table on page 125

To remap a source table (InfoSphere CDC Event Server)

1. Click Configuration > Datastores.
Ensure that you are connected to an Event Server datastore.
2. Click Configuration > Subscriptions.
Ensure that you have created a subscription that uses the Event Server
datastore as the target.
3. Select the subscription that contains the mapped source and target tables.
Ensure that you have ended replication on the subscription.
4. Select the table mapping in the Table Mappings view.
5. Right-click Remap Source Table.
This option is only available if you have already mapped your source table to a
message destination or to a staging target table.
6. Select one of the following options:
v Message Destination MappingsSelect this option if you want to map this
source table to a message destination.
v One mapping of any typeSelect this option if you want to map this source
table to a staging target table. Select Standard as the mapping type.
7. Click Next and map the source table to a message destination or to a staging
target table.
Related concepts
Remapping a source table on page 125
Related tasks
To map multiple source tables to a JMS message destination on page 121
To stage a source table on page 124

Copying selected table mappings

Copying selected table mappings is similar to copying a subscription except that it
only copies the mappings that you select to a new or existing subscription.
Copying a subscription copies all table mappings to a new or existing subscription.
This is useful if you only want to copy a subset of the mappings in a subscription.

See also:
To copy selected table mappings
To copy selected table mappings for an external target datastore on page 127
Related concepts
Copying subscriptions on page 59

To copy selected table mappings

1. Click Configuration > Subscriptions.
2. Select the subscription with the table mappings you want to copy.
3. In the Table Mapping view, right-click one or more table mappings and select
Copy Table Mappings.
4. Type a name for the subscription in the Name box.

126 InfoSphere Change Data Capture Management Console: Administration Guide

 All subscriptions that come from the same source datastore must have a
unique name and all subscriptions that go to the same target datastore must
have a unique Source ID. The source ID is automatically generated based on
truncating the subscription name to 8 characters. If you attempt to create a
subscription with a duplicate Source ID, an error will result and the
subscription will not be created. If this occurs, click Advanced Settings and
give the subscription a unique Source ID.
5. Type a description for the subscription in the Description box.
6. If you want to include the new subscription in a project, select a project from
the Project list or click New Project to create a new project.
If you do not select a project, Management Console places the new
subscription into the Default Project.
7. Click Next.
8. Select the source datastore for the new subscription from the New Source
Datastore list.
9. Select the databases and owners for your new source datastore under New
Name.
10. If you want to specify advanced settings, click Advanced Settings.
11. Click Next.
12. Select the target datastore for the new subscription from the New Target
Datastore list.
13. Select the databases and owners for the new target datastore under New
Name and click Next.
14. If the existing subscription contains user exits, then specify their location for
the new subscription under New Location and click Next.
15. If you built a derived column, an expression, or a row-filtering expression that
uses the %SELECT column function, then confirm the list of displayed
expressions and click Next.
After copying the subscription, you may have to change these expressions
manually.
16. Review the list of changes and click Finish.
Related concepts
Copying subscriptions on page 59
Related reference
Retrieve column%SELECT on page 255

To copy selected table mappings for an external target

datastore
1. Click Configuration > Subscriptions.
2. Select the subscription with the table mappings you want to copy to an
external target datastore.
3. Right-click one or more table mappings in the Table Mapping view and select
Copy Table Mappings.
4. Type a name for the subscription in the Name box.
All subscriptions that come from the same source datastore must have a
unique name and all subscriptions that go to the same target datastore must
have a unique Source ID. The source ID is automatically generated based on
truncating the subscription name to 8 characters. If you attempt to create a
subscription with a duplicate Source ID, an error will result and the

Mapping tables 127

 subscription will not be created. If this occurs, click Advanced Settings and
give the subscription a unique Source ID.
5. Type a description for the subscription in the Description box.
6. If you want to include the new subscription in a project, select a project from
the Project list or click New Project to create a new project.
If you do not select a project, Management Console places the new
subscription into the Default Project.
7. Click Next.
8. Select the new source datastore for the subscription from the New Source
Datastore list.
9. Select the databases and owners for your new source datastore under New
Name.
10. If you want to specify advanced settings, click Advanced Settings.
11. Click Next.
12. If you want to change the properties of the external target datastore, then
make the necessary changes and click Next.
13. Review the list of changes and click Finish.
Related concepts
Copying subscriptions on page 59
Setting up subscriptions for datastores outside of your organization on page 58
Related reference
Retrieve column%SELECT on page 255

Deleting table mappings

You can delete table mappings that belong to a particular subscription. Before
deleting a table mapping, you need to end replication on the subscription that
contains the table mapping you want to delete. If the subscription uses InfoSphere
CDC Event Server as the target datastore and you have mapped your source table
to both a JMS message destination and a staging target table, then you are
provided with the option to delete either mapping.

See also:
To delete a table mapping
To delete a table mapping (InfoSphere CDC Event Server)

To delete a table mapping

1. Ensure that you have ended replication on the subscription.
2. Click Configuration > Subscriptions.
3. Select the subscription that contains the mapped source and target tables.
4. Select the table mapping in the Table Mappings view.
5. Right-click and click Delete Table Mappings.
Related concepts
Ending replication on page 332

To delete a table mapping (InfoSphere CDC Event Server)

1. Click Configuration > Subscriptions.
2. Select a subscription that contains the table mapping to a message destination,
to a staging target table, or both.

128 InfoSphere Change Data Capture Management Console: Administration Guide

 Ensure that you have ended replication on the subscription.
3. Select the table mapping in the Table Mappings view.
4. Right-click and click Delete Table Mappings.
5. If you have mapped your source table to both a message destination and a
target staging table, you will be presented with the following options:
v Delete message destination mappingEnable this check box if you want to
unmap your source table from a JMS message destination.
v Delete staging target mappingEnable this check box if you want to unmap
your source table from a staging target table.
6. If you have mapped your source table to either one of a message destination or
a staging target table, then click Yes to the confirmation message.
Related concepts
Ending replication on page 332

Exporting and importing subscriptions and selected table mappings

Using InfoSphere CDC's export and import capabilities, you can prepare XML files
that include details you have set on your subscription, and you can save these files
on your local computer or elsewhere. You can also export selected table mappings
in a subscription.

See also:
To export a subscription into an XML file
To export selected table mappings into an XML file
To import a subscription from an XML file on page 130

To export a subscription into an XML file

1. Click Configuration > Subscriptions.
2. Right-click on a subscription and select Export Subscription.
3. Type the name for the XML file and click Save.
Related concepts
Exporting and importing subscriptions and selected table mappings
Related tasks
To promote a subscription to a new subscription on page 351
To promote changes to an existing subscription on page 352
To export selected table mappings into an XML file

To export selected table mappings into an XML file

1. Click Configuration > Subscriptions.
2. Select the subscription with the table mappings you want to export.
3. Right-click one or more table mappings in the Table Mapping view and select
Export Table Mappings.
4. Type the name for the XML file and click Save.
5. Import the XML file that you have created into a subscription

Mapping tables 129

 Related tasks
To import a subscription from an XML file
To export a subscription into an XML file on page 129

To import a subscription from an XML file

1. Click Configuration > Subscriptions.
2. Right-click on a project and select Import Subscription.
3. Select an XML file and click Open.
4. Depending on how you want to import the settings of your subscription, select
one of the following options:
v Import to a new subscriptionCopies the settings in the XML file into a
new subscription.
v Import to an existing subscriptionCopies the settings in the XML file into
an existing subscription.
Related concepts
Exporting and importing subscriptions and selected table mappings on page 129
Related tasks
To promote a subscription to a new subscription on page 351
To promote changes to an existing subscription on page 352

130 InfoSphere Change Data Capture Management Console: Administration Guide

Customizing InfoSphere DataStage table mappings
If you are using InfoSphere DataStage, after you have mapped your tables to
InfoSphere DataStage, you can customize your table mappings by creating derived
columns, by filtering rows and columns, and by specifying how InfoSphere CDC
converts character sets on source columns during replication:
v Derived ColumnsUsed to create an expression that is evaluated by InfoSphere
CDC on a source column. The results of the expression are sent to the target
system, InfoSphere DataStage.
v Multibyte and Unicode Character Set ConversionsUsed to specify how
InfoSphere CDC converts character sets on source columns during replication.
v Filtering Rows and ColumnsUsed to include or exclude rows or columns for
replication.
When customizing your InfoSphere DataStage table mappings in Management
Console, you will have access to a subset of functionality that is normally available
for database targets. Functionality that is not available for InfoSphere DataStage
table mappings is not displayed or disabled.
Setting properties for a subscription that targets InfoSphere DataStage
Related concepts
Replicating multibyte (MBCS) and double-byte (DBCS) character data on page
163
Filtering rows and columns on page 291
Related tasks
To add a derived column on page 155

Setting properties for a subscription that targets InfoSphere DataStage

After you have mapped tables for a subscription that uses InfoSphere CDC for
InfoSphere DataStage as a target datastore, you can modify the following
subscription properties:
v GeneralAppears for both the Flat File and the Direct Connect connection
methods for table mappings.
Batch size thresholdsBalances the need to get data applied to the target
quickly against the need to minimize resource utilization. You can set the
batch size threshold property to run InfoSphere DataStage jobs less frequently
and process larger amounts of data.
Large object truncation size for character and binary dataAffects the fixed
record length used by an InfoSphere DataStage job that processes the changed
data. You should set this property to as small a size as possible while still
retaining enough of the data from the large columns to meet your business
needs.
v File Name FormatAppears only for subscriptions using the Flat File
connection method for table mappings.
Include the record count in the file nameEnable this check box to include
the record count in the file name of the Flat File output for the InfoSphere
DataStage job.
v Direct ConnectAppears only for subscriptions using the Direct Connect
connection method for table mappings.

Copyright IBM Corp. 2008, 2011 131

 Project NameUsed by InfoSphere DataStage to uniquely identify the
information sent by InfoSphere CDC for processing.
Job NameUsed by InfoSphere DataStage to uniquely identify the
information sent by InfoSphere CDC for processing.
Connection KeyUsed by InfoSphere DataStage to authenticate the
connection and communicate with InfoSphere CDC to process the uniquely
identified job.
Auto-start InfoSphere DataStage JobEnable this after setting the three
preceeding settings to start the InfoSphere DataStage job from InfoSphere
CDC.

See also:
To specify batch size thresholds for an InfoSphere DataStage subscription
To specify large object truncation size for an InfoSphere DataStage
subscription
To specify the file name format for an InfoSphere DataStage subscription on
page 133
To specify Direct Connect settings for an InfoSphere DataStage subscription
on page 133
Related concepts
InfoSphere DataStage system parameters on page 624
Related tasks
To specify Direct Connect settings for an InfoSphere DataStage subscription on
page 133

To specify batch size thresholds for an InfoSphere DataStage

subscription
1. Click Configuration > Subscriptions.
2. Right-click on a subscription and select InfoSphere DataStage > InfoSphere
DataStage Properties.
3. Type the number of rows that can be changed before subscription data is sent
to InfoSphere DataStage in the Number of rows box.
The default value is 100000.
4. Type the amount of time that will elapse before subscription data is sent to
InfoSphere DataStage in the Time (seconds) box. The default value is 600.
The values that you specify are used by InfoSphere CDC to determine when a
flat file is complete and is made available to InfoSphere DataStage for
processing.
5. Click OK.

To specify large object truncation size for an InfoSphere

DataStage subscription
1. Click Configuration > Subscriptions.
2. Right-click on a subscription and select InfoSphere DataStage > InfoSphere
DataStage Properties.
3. Type the truncation point for large character data in the Character data (#
characters) box.
The default value is 8000.
4. Type the truncation point for large binary data in the Binary data (# bytes) box.

132 InfoSphere Change Data Capture Management Console: Administration Guide

 The default value is 8000.
5. Click OK.

To specify the file name format for an InfoSphere DataStage

subscription
1. Click Configuration > Subscriptions.
2. Right-click on a subscription and select InfoSphere DataStage > InfoSphere
DataStage Properties.
3. Enable the Include record count in file name check box.
4. Click OK.

To specify Direct Connect settings for an InfoSphere

DataStage subscription
1. Click Configuration > Subscriptions.
2. Select the desired subscription and ensure that it is mapped using the Direct
Connect connection method.
3. Right-click on the subscription and select InfoSphere DataStage > InfoSphere
DataStage Properties.
4. Type in the entries for the following:
v Project Name:
v Job Name:
v Connection Key:
5. If you want to use the auto-start options, enable the Auto-start InfoSphere
DataStage Job check box.

Customizing InfoSphere DataStage table mappings 133

134 InfoSphere Change Data Capture Management Console: Administration Guide
Understanding data types supported by InfoSphere CDC
When you map source and target columns for replication in Management Console,
you should know which data types are compatible. For more information on how
to map tables for replication, see the "Mapping tables" section in your Management
Console documentation.

In this section, you will learn:

Supported data types
Supported column mappings on page 140

Supported data types

Each InfoSphere CDC replication engine supports a variety of data types, as
indicated by the table below.

The following considerations and restrictions exist for the replication of data types:
v InfoSphere CDC casts data into and out of the database with LOB,
CLOB, XML, and SQL_VARIANT data types. Due to this limitation imposed by
the database, mirroring and refresh performance may be reduced when
replicating these data types.
v In addition to the listed data types, InfoSphere CDC supports Alias
Data Types (ADT) in all versions of Microsoft SQL Server.
v User-defined data types that are not aliases of standard database data types
cannot be replicated by InfoSphere CDC. Tables where unsupported data types
are present will not be included in the catalog and are not available for
mapping.
v InfoSphere CDC does not provide support for columns of type
BFILE or CFILE.
v If you are replicating the TIMEZONE data type and the source and
target have a different TIMEZONE value, the data replicated will be adjusted
and use the source TIMEZONE value.
v InfoSphere CDC provides support for the ROWID and XML data types and this
includes the use of SQL*Loader to load the data into the source table.
v The LOAD utility is not supported with LOB and XML columns.
v Support for CHAR and VARCHAR data types includes BIT, MIXED
and SBCS
v InfoSphere CDC can replicate IMAGE, TEXT, NTEXT,
VARBINARY(MAX), NVARACHAR(MAX), and VARCHAR(MAX) data types of
unlimited length.
v Binary data in derived expressions is not supported
v You cannot map a binary type target table column to a constant or
journal control field
v Binary data columns are not supported for value translations.

Copyright IBM Corp. 2008, 2011 135

 InfoSphere CDC can replicate data in Large Object (LOB) columns available in
your database. These columns contain character or image data that are larger than
scalar data types. For instance, some tables contain columns for long textual
comments or bitmap images.

InfoSphere CDC can replicate LOB data types of all lengths supported by the
source and target DBMS.

When replicating LOB data, consider the following:

v InfoSphere CDC version 6.3 and earlier does not support the replication of LOB
data types encoded in multibyte character sets (MBCS). Replication of
single-byte character set (SBCS) encoded LOB data types is supported.
v InfoSphere CDC for z/OS version 6.2 and earlier running on a
source or target does not support the replication of large object (LOB) data.
v InfoSphere CDC replicates LOB data types by querying the source database
directly for every row change which may affect product performance in some
situations. To avoid this scenario, remove LOB columns from table mappings in
Management Console.
v InfoSphere CDC can replicate BLOB, CLOB, LONG, LONG RAW,
and NCLOB data types of unlimited length.
v InfoSphere CDC can replicate BLOB and CLOB data types of
unlimited length.
v InfoSphere CDC can replicate IMAGE, TEXT, NTEXT,
VARBINARY(MAX), NVARCHAR(MAX), and VARCHAR(MAX) data types of
unlimited length.
v There is no limit as to the total length of all LOB columns in a table when
replicating LOB columns.
v LOB columns are read from the database at the time of replication. Therefore,
only the current image of a LOB column field in a source table will be sent at
the time of replication.
v You cannot map LOB columns in a source table to key columns in a target table.
v You cannot define LOB columns as key columns in a target table.
v You cannot reference LOB columns in row-filtering expressions.
v LOB data types are truncated before sending them to an expression defined for a
derived column.
v LOB data types are truncated before sending them to target row-level user exits.
v InfoSphere CDC provides support for traditional LOBs (known as
BASICFILE LOBs in Oracle 11.1 and higher). It also supports LOBs stored as
SECUREFILE with the following options: DEDUPLICATE/KEEP_DUPLICATES,
COMPRESS/NOCOMPRESS or ENCRYPT/DECRYPT.
v LOB, CLOB AND DBCLOB columns are not supported for value
translations.
v LOB, BINARY AND VARBINARY type source derived columns are
not supported
v You cannot pass LOB columns to user exits

InfoSphere CDC can replicate data in XML columns available in your database.
When replicating XML data, consider the following:
v InfoSphere CDC for z/OS version 6.2 and earlier running on a
source or target does not support the replication of XML data.

136 InfoSphere Change Data Capture Management Console: Administration Guide

 v XML data types are not supported in non-nullable columns on target tables.
v XML data types are supported in nullable columns on target tables
v You cannot map XML columns in a source table to key columns in a target table.
v You cannot define XML columns as key columns in a target table.
v You cannot reference XML columns in derived or row-filtering expressions.
v XML columns are not supported for Conflict Detection and Resolution
operations
v XML columns are not supported for value translations
v XML columns are not supported for code page translation
v XML columns are not supported for code page overrides, but they
will be translated, if required.
v XML type source derived columns are not supported
v You cannot pass XML columns to user exits
Table 1. Supported data types
Data type Supported by replication engine
DB2 Informix Microsoft
DB2 for DB2 Dynamic SQL Oracle Oracle
LUW z/OS for i Server Server Redo Trigger Sybase Teradata
BIGINT U U U U U U
BIGSERIAL U
Binary U U U
BINARY_DOUBLE U
BINARY_FLOAT U
BIT U U
BLOB U U U U U U U
BOOLEAN U
BYTE U
BYTEINT U
CHAR U U U U U U U U
CHARACTER U U
CHARACTER FOR BIT U U
DATA
CHARACTER U
VARYING
CLOB U U U U U U
DATE U U U U U U U U
DATE DMY U
DATE EUR U
DATE ISO U
DATE JUL U
DATE MDY U
DATE USA U
DATE YMD U
DATETIME U

Understanding data types supported by InfoSphere CDC 137

Table 1. Supported data types (continued)
Data type Supported by replication engine
DB2 Informix Microsoft
DB2 for DB2 Dynamic SQL Oracle Oracle
LUW z/OS for i Server Server Redo Trigger Sybase Teradata
DATETIME HOUR TO U
SECOND
DATETIME YEAR TO U
FRACTION(5)
DATETIME2 U
DATETIMEOFFSET U
DBCLOB U U U
DBCS EITHR U
DBCS GRAPHIC U
DBCS ONLY U
DBCS OPEN U
DECIMAL U U U U U U
DOUBLE U U U U
FLOAT U U U U U U U U U
GRAPHIC U U U U
HEX (fixed length only) U
IMAGE U U U
INT8 U
INTEGER U U U U U U U U U
INTERVAL U
INTERVAL DAY TO U U
SECOND
INTERVAL DAY TO U U
MONTH
LOBs U U U
LONG RAW U U
LONG VARCHAR U U U U U
LONG VARCHAR FOR U U
BIT DATA
LONG VARGRAPHIC U U
LVARCHAR U
MONEY U U U
NCHAR U U U U U
NCLOB U U
NTEXT U
NUMERIC U U U U U U U
NVARCHAR U U U
NVARCHAR2 U U
NVARCHAR(MAX) U

138 InfoSphere Change Data Capture Management Console: Administration Guide

Table 1. Supported data types (continued)
Data type Supported by replication engine
DB2 Informix Microsoft
DB2 for DB2 Dynamic SQL Oracle Oracle
LUW z/OS for i Server Server Redo Trigger Sybase Teradata
PACKED DECIMAL U
RAW U U
REAL U U U U U U U
ROWID U U
ROWVERSION U
SERIAL U
SERIAL8 U
SMALLDATETIME U U
SMALLFLOAT U
SMALLINT U U U U U U U
SMALLMONEY U U
SQL_VARIANT U
TEXT U U
TIME U U U U U
TIMEZONE U U
TIME EUR U
TIME HMS U
TIME ISO U
TIME JIS U
TIME USA U
TIMESTAMP U U U U U U U
TIMESTAMP WITH U U
TIME ZONE
TIMESTAMP WITH U U
LOCAL TIME ZONE
TINYINT U U
UNICHAR U
UNIQUEIDENTIFIER U
UNITEXT U
UNIVARCHAR U
VARBINARY U U U
VARBINARY(MAX) U
VARBYTE U
VARCHAR U U U U U U
VARCHAR FOR BIT U U
DATA
VARCHAR(MAX) U
VARCHAR2 U U

Understanding data types supported by InfoSphere CDC 139

Table 1. Supported data types (continued)
Data type Supported by replication engine
DB2 Informix Microsoft
DB2 for DB2 Dynamic SQL Oracle Oracle
LUW z/OS for i Server Server Redo Trigger Sybase Teradata
VARGRAPHIC U U U
XML U U U U
XMLTYPE U U
ZONED NUMERIC U

Supported column mappings

This section indicates the table mappings that you can create in InfoSphere CDC
Management Console with supported data types.

DB2 LUW

Source data types Supported table mappings

BIGINT Any numeric, binary, or BLOB data type
BLOB Any binary or BLOB data type
CHAR Any character, variable character, CLOB,
binary, or BLOB data type
CHARACTER FOR BIT DATA Any binary or BLOB data type
CLOB Any character, variable character, CLOB,
binary, or BLOB data type
DATE Any date data type
DBCLOB Any character, variable character, CLOB,
DBCLOB, or BLOB data type
DECIMAL Any numeric data type
DOUBLE PRECISION Any numeric, binary, or BLOB data type
FLOAT Any numeric, binary, or BLOB data type
GRAPHIC Any character, variable character, CLOB,
binary, or BLOB data type
INTEGER Any numeric, binary, or BLOB data type
LONG VARCHAR Any character, variable character, CLOB,
binary, or BLOB data type
LONG VARCHAR FOR BIT DATA Any binary or BLOB data type
LONG VARGRAPHIC Any character, variable character, CLOB,
binary, or BLOB data type
NUMERIC Any numeric, binary, or BLOB data type
REAL Any numeric, binary, or BLOB data type
SMALLINT Any numeric, binary, or BLOB data type
TIME Any time data type
TIMESTAMP Any date, time, or timestamp data type
VARCHAR Any character, variable character, CLOB,
binary, or BLOB data type

140 InfoSphere Change Data Capture Management Console: Administration Guide

Source data types Supported table mappings
VARCHAR FOR BIT DATA Any binary or BLOB data type
VARGRAPHIC Any character, variable character, CLOB,
binary, or BLOB data type
XML XML, CLOB, or any character type

DB2 for z/OS

For the purposes of supported table mappings, the following text offers a
definition of binary and text fields:
v A text field is any CHAR, VARCHAR, GRAPHIC, VARGRAPHIC, BINARY,
VARBINARY, BLOB, CLOB or DBCLOB column which has a CCSID (code page)
or an XML column. By default, columns will have a CCSID or not, based on
their definition in DB2. This CCSID, or lack of it, can be overridden using the
Encoding tab in the Mapping Details view. Any text field can be mapped to
any other text field.
v A binary field is any CHAR, VARCHAR, GRAPHIC, VARGRAPHIC, BINARY,
VARBINARY, BLOB, CLOB or DBCLOB column which does not have a CCSID
(code page). By default, columns will have a CCSID or not, based on their
definition in DB2. This CCSID, or lack of it, can be overridden using the
Encoding tab in the Mapping Details view. Any binary field can be mapped to
any other binary field.

Supported table Supported table Supported table

mappings when a mappings when a mappings when a
code page is code page is not code page is not
Source data types assigned assigned applicable
BIGINT N/A N/A Any numeric data
type
BINARY Any text field Any binary field N/A
BLOB Any text field Any binary field N/A
CHAR (for BIT) Any text field Any binary field N/A
CHAR (for MIXED) Any text field Any binary field N/A
CHAR (for SBCS) Any text field Any binary field N/A
CLOB Any text field Any binary field N/A
DATE N/A N/A Any date data type
DBCLOB Any text field Any binary field
DECIMAL N/A N/A Any numeric data
type
FLOAT N/A N/A Any numeric data
type
GRAPHIC Any text field Any binary field
INTEGER N/A N/A Any numeric data
type

Understanding data types supported by InfoSphere CDC 141

 Supported table Supported table Supported table
mappings when a mappings when a mappings when a
code page is code page is not code page is not
Source data types assigned assigned applicable
ROWID N/A N/A For DB2 for z/OS to
DB2 to z/OS
mappings, a source
ROWID column can
only be mapped to a
target ROWID
column. Column
mappings to any
other target database
permit mappings to
binary data types.
SMALLINT N/A N/A Any numeric data
type
TIME N/A N/A Any time data type
TIMESTAMP N/A N/A Any date, time, or
timestamp data type
VARBINARY Any text field Any binary field N/A
VARCHAR (for BIT) Any text field Any binary field N/A
VARCHAR (for Any text field Any binary field N/A
MIXED)
VARCHAR (for Any text field Any binary field N/A
SBCS)
VARGRAPHIC Any text field Any binary field N/A
XML N/A N/A Any text field where
the source field
contains a valid XML
document

Informix Dynamic Server

Source data types Supported table mappings

BIGINT Any numeric data type
BIGSERIAL Any numeric data type
BLOB Any BLOB data type.
BOOLEAN Any Boolean data type
CHAR Any character or variable character data
type
CHARACTER Any character or variable character data
type
CHARACTER VARYING Any character or variable character data
type
CLOB Any character, variable character, CLOB,
binary, or BLOB data type
DATE Any date data type
DATETIME HOUR TO SECOND Any date data type
DATETIME YEAR TO FRACTION(5) Any date data type

142 InfoSphere Change Data Capture Management Console: Administration Guide

Source data types Supported table mappings
DECIMAL Any numeric data type
FLOAT Any numeric data type
INT8 Any numeric data type
INTEGER Any numeric data type
LVARCHAR Any character or variable character data
type
MONEY Any numeric data type
NCHAR Any character or variable character data
type
NUMERIC Any numeric data type
NVARCHAR Any character or variable character data
type
SERIAL Any numeric data type
SERIAL(8) Any numeric data type
SMALLFLOAT Any numeric data type
SMALLINT Any numeric data type
VARCHAR Any character or variable character data
type

Microsoft SQL Server

Source data types Supported table mappings

BIGINT Any numeric data type
BINARY Any binary or BLOB data type
BIT Any numeric data type
CHAR Any character, variable character, CLOB,
binary, or BLOB data type
DATETIME Any datetime, date, or time data type
DATE Any datetime, date, or time data type
DATETIME2 Any datetime, date, or time data type
DATETIMEOFFSET Any datetime, date, or time data type
DECIMAL Any numeric data type
FLOAT Any numeric data type
IMAGE Any BLOB data type.
INTEGER Any numeric data type
MONEY Any numeric data type
NCHAR Any character, variable character, CLOB,
binary, or BLOB data type
NTEXT Any character, variable character, CLOB,
binary, or BLOB data type
NVARCHAR Any character, variable character, CLOB,
binary, or BLOB data type
NVARCHAR(MAX) Any character, variable character, CLOB,
binary, or BLOB data type

Understanding data types supported by InfoSphere CDC 143

 Source data types Supported table mappings
NUMERIC Any numeric data type
REAL Any numeric data type
ROWVERSION Any binary or BLOB data type
SMALLDATETIME Any datetime, date, or time data type
SMALLINT Any numeric data type
SMALLMONEY Any numeric data type
SQL_VARIANT sql_variant
TEXT Any character, variable character, CLOB,
binary, or BLOB data type
TIME Any datetime, date, or time data type
TINYINT Any numeric data type
UNIQUEIDENTIFIER Any binary or BLOB data type
VARBINARY Any binary or BLOB data type
VARBINARY(MAX) Any binary or BLOB data type
VARCHAR(MAX) Any character, variable character, CLOB,
binary, or BLOB data type
XML XML, CLOB, or any character type

Oracle

Source data types Supported table mappings

BLOB Any character, variable character, LOB,
interval DTS, interval YTM, LONG RAW,
LONG VARCHAR, NCHAR, NVARCHAR,
RAW, or XML type data type
CHAR Any character, variable character, LOB,
interval DTS, interval YTM, LONG RAW,
LONG VARCHAR, NCHAR, NVARCHAR,
RAW, or XML type data type
CLOB Any character, variable character, LOB,
interval DTS, interval YTM, LONG RAW,
LONG VARCHAR, NCHAR, NVARCHAR,
RAW, or XML type data type
DATE Any date or timestamp data type
FLOAT Any numeric data type
INTEGER Any numeric data type
INTERVAL DAY TO SECOND Any character, variable character, LOB,
interval DTS, interval YTM, LONG RAW,
LONG VARCHAR, NCHAR, NVARCHAR,
RAW, or XML type data type

144 InfoSphere Change Data Capture Management Console: Administration Guide

Source data types Supported table mappings
INTERVAL DAY TO MONTH Any character, variable character, LOB,
interval DTS, interval YTM, LONG RAW,
LONG VARCHAR, NCHAR, NVARCHAR,
RAW, or XML type data type

Any character, variable character, LOB,

interval DTS, interval YTM, LONG RAW,
LONG VARCHAR, NCHAR, NVARCHAR,
RAW, or XML type data type
LONG RAW Any character, variable character, LOB,
interval DTS, interval YTM, LONG RAW,
LONG VARCHAR, NCHAR, NVARCHAR,
RAW, or XML type data type
LONG VARCHAR Any character, variable character, LOB,
interval DTS, interval YTM, LONG RAW,
LONG VARCHAR, NCHAR, NVARCHAR,
RAW, or XML type data type
NCHAR Any character, variable character, LOB,
interval DTS, interval YTM, LONG RAW,
LONG VARCHAR, NCHAR, NVARCHAR,
RAW, or XML type data type
NCLOB Any character, variable character, LOB,
interval DTS, interval YTM, LONG RAW,
LONG VARCHAR, NCHAR, NVARCHAR,
RAW, or XML type data type
NUMERIC Any numeric data type
NVARCHAR2 Any character, variable character, LOB,
interval DTS, interval YTM, LONG RAW,
LONG VARCHAR, NCHAR, NVARCHAR,
RAW, or XML type data type
RAW Any character, variable character, LOB,
interval DTS, interval YTM, LONG RAW,
LONG VARCHAR, NCHAR, NVARCHAR,
RAW, or XML type data type
REAL Any numeric data type
TIMESTAMP Any date or timestamp data type
TIMESTAMP WITH TIME ZONE Any date or timestamp data type
TIMESTAMP WITH LOCAL TIME ZONE Any date or timestamp data type
TIMEZONE Any date or timestamp data type
VARCHAR2 Any character, variable character, LOB,
interval DTS, interval YTM, LONG RAW,
LONG VARCHAR, NCHAR, NVARCHAR,
RAW, or XML type data type
XMLTYPE Any character, variable character, LOB,
interval DTS, interval YTM, LONG RAW,
LONG VARCHAR, NCHAR, NVARCHAR,
RAW, or XML type data type

Oracle Trigger

Understanding data types supported by InfoSphere CDC 145

 Source data types Supported table mappings
BLOB Any character, variable character, LOB,
interval DTS, interval YTM, LONG RAW,
LONG VARCHAR, NCHAR, NVARCHAR,
RAW, or XML type data type
CHAR Any character, variable character, LOB,
interval DTS, interval YTM, LONG RAW,
LONG VARCHAR, NCHAR, NVARCHAR,
RAW, or XML type data type
CLOB Any character, variable character, LOB,
interval DTS, interval YTM, LONG RAW,
LONG VARCHAR, NCHAR, NVARCHAR,
RAW, or XML type data type
DATE Any date or timestamp data type
FLOAT Any numeric data type
INTEGER Any numeric data type
INTERVAL DAY TO SECOND Any character, variable character, LOB,
interval DTS, interval YTM, LONG RAW,
LONG VARCHAR, NCHAR, NVARCHAR,
RAW, or XML type data type
INTERVAL DAY TO MONTH Any character, variable character, LOB,
interval DTS, interval YTM, LONG RAW,
LONG VARCHAR, NCHAR, NVARCHAR,
RAW, or XML type data type

Any character, variable character, LOB,

interval DTS, interval YTM, LONG RAW,
LONG VARCHAR, NCHAR, NVARCHAR,
RAW, or XML type data type
LONG RAW Any character, variable character, LOB,
interval DTS, interval YTM, LONG RAW,
LONG VARCHAR, NCHAR, NVARCHAR,
RAW, or XML type data type
LONG VARCHAR Any character, variable character, LOB,
interval DTS, interval YTM, LONG RAW,
LONG VARCHAR, NCHAR, NVARCHAR,
RAW, or XML type data type
NCHAR Any character, variable character, LOB,
interval DTS, interval YTM, LONG RAW,
LONG VARCHAR, NCHAR, NVARCHAR,
RAW, or XML type data type
NCLOB Any character, variable character, LOB,
interval DTS, interval YTM, LONG RAW,
LONG VARCHAR, NCHAR, NVARCHAR,
RAW, or XML type data type
NUMERIC Any numeric data type
NVARCHAR2 Any character, variable character, LOB,
interval DTS, interval YTM, LONG RAW,
LONG VARCHAR, NCHAR, NVARCHAR,
RAW, or XML type data type
RAW Any character, variable character, LOB,
interval DTS, interval YTM, LONG RAW,
LONG VARCHAR, NCHAR, NVARCHAR,
RAW, or XML type data type

146 InfoSphere Change Data Capture Management Console: Administration Guide

Source data types Supported table mappings
REAL Any numeric data type
TIMESTAMP Any date or timestamp data type
TIMESTAMP WITH TIME ZONE Any date or timestamp data type
TIMESTAMP WITH LOCAL TIME ZONE Any date or timestamp data type
TIMEZONE Any date or timestamp data type
VARCHAR2 Any character, variable character, LOB,
interval DTS, interval YTM, LONG RAW,
LONG VARCHAR, NCHAR, NVARCHAR,
RAW, or XML type data type
XMLTYPE Any character, variable character, LOB,
interval DTS, interval YTM, LONG RAW,
LONG VARCHAR, NCHAR, NVARCHAR,
RAW, or XML type data type

Sybase

Source data types Supported table mappings

BIGINT Any numeric data type
BINARY Any binary or LOB data type
BIT Any numeric data type
CHAR Any character, variable character, or binary
data type
DATE Any date or datetime data type
DATETIME Any date or datetime data type
DECIMAL Any numeric data type
FLOAT Any numeric data type
IMAGE Any binary or LOB data type
INTEGER Any numeric data type
MONEY Any numeric data type
NCHAR Any character, variable character, or binary
data type
NTEXT Any character, variable character, or binary
data type
NVARCHAR Any character, variable character, or binary
data type
NUMERIC Any numeric data type
REAL Any numeric data type
SMALLDATETIME Any date or datetime data type
SMALLINT Any numeric data type
SMALLMONEY Any numeric data type
TEXT Any character, variable character, or binary
data type
TIME Any time data type
TIMESTAMP Any character, variable character, or binary
data type

Understanding data types supported by InfoSphere CDC 147

 Source data types Supported table mappings
TINYINT Any numeric data type
UNICHAR Any character, variable character, or binary
data type
UNITEXT Any character, variable character, or binary
data type
UNIVARCHAR Any character, variable character, or binary
data type
VARBINARY Any binary or LOB data type
VARCHAR Any character, variable character, or binary
data type

Teradata

Source data types Supported table mappings

BYTE Any character, variable character, GRAPHIC,
or VARGRAPHIC data type
BYTEINT Any numeric data type
CHAR Any character, variable character, GRAPHIC,
or VARGRAPHIC data type
DATE Any date or timestamp data type
DECIMAL Any numeric data type
DOUBLE PRECISION Any numeric data type
FLOAT Any numeric data type
GRAPHIC Any character, variable character, GRAPHIC,
or VARGRAPHIC data type
INT (or INTEGER) Any numeric data type
INTERVAL Any numeric data type
LONG VARCHAR Any character, variable character, GRAPHIC,
or VARGRAPHIC data type
NUMERIC Any numeric data type
REAL Any numeric data type
SMALLINT Any numeric data type
TIME Any time or timestamp data type
TIMESTAMP Any date, time, or timestamp data type
VARBYTE Any character, variable character, GRAPHIC,
or VARGRAPHIC data type
VARCHAR Any character, variable character, GRAPHIC,
or VARGRAPHIC data type
VARGRAPHIC Any character, variable character, GRAPHIC,
or VARGRAPHIC data type

148 InfoSphere Change Data Capture Management Console: Administration Guide

Mapping columns
After mapping your tables using the Map Tables wizard, you can use the Column
Mappings tab in the Table Mappings view to customize what items you want to
map to target columns in a subscription. If you have mapped your tables using
any mapping type, then most or all of your target columns are already mapped to
source columns that have identical names and attributes. However, using the
Columns Mappings tab, you can customize the kind of information you want to
map to a target column and populate it with.

Database defaults, if defined in the target database, will be used

automatically during the mapping process if there is no compatible (that is to say,
identically named) source column for the target column.

In this section, you will learn:

Mapping source columns to target columns
Mapping journal control fields to target columns on page 150
Mapping expressions to target columns on page 151
Mapping source and target columns automatically on page 152
Mapping initial values to target columns on page 153
Adding and mapping derived columns to target columns on page 154

Mapping source columns to target columns

Manually map any remaining target columns left by the Map Table wizard so that
they are populated with data during replication activities. For example, the Map
Tables wizard may have left certain target columns unmapped if the column
names between the source and target tables did not match, or if the data types
between columns are not compatible.

See also:
To map a source column to a target column

To map a source column to a target column

1. Click Configuration > Subscriptions.
2. Select the subscription.
3. Click the Table Mappings view and select the table mapping from the Source
Table column.
4. Right-click and select Open Mapping Details.
You may see target columns that are not mapped to any source columns. These
target columns are mapped with an initial default value such as BLANK,
CURRENT DATE, NULL, and so on.
5. Click the Column Mappings tab.
6. Expand the Source Columns list and select a source column.
7. Ensure that the data types are compatible by enabling the Show Column Data
Types check box.
You can map source columns to target columns only if the data types between
both are compatible.

Copyright IBM Corp. 2008, 2011 149

 8. Drag and drop the source column to the Source area to map it to a target
column.
9. Click Save.

A check mark ( ) displays next to any source column that is mapped to a

target column. When you start replication on the subscription, InfoSphere CDC
populates the target column with data from the source column.
Related concepts
Mapping source columns to target columns on page 149
Starting and ending replication on page 327

Mapping journal control fields to target columns

Journal control fields let you populate a target column with system information
about the inserts, updates, or deletes taking place on your source tables. If you
decide to map a journal control field to a target column, then each time there is a
change in your source table, InfoSphere CDC translates the journal control field
into system information and populates this information into the mapped target
column during replication. For example, you may want to audit the name of the
user that inserts a row in a source table. To capture this information in a target
column, map the &USER journal control field to the appropriate target column.

Journal control fields are especially useful when you want to audit the changes
that are taking place in your source environment. These are available to you when
you select LiveAudit as your mapping type.

See also:
To map a journal control field to a target column
Related concepts
About journal control fields on page 173
Mapping using LiveAudit on page 91

To map a journal control field to a target column

1. Click Configuration > Subscriptions.
2. Select the subscription.
3. Click the Table Mappings view and select the table mapping from the Source
Table column.
4. Right-click and select Open Mapping Details.
5. Click the Column Mappings tab.
6. Expand the Journal Control Fields list and select a journal control field that is
compatible with the data type of the target column.
7. Drag and drop the journal control field to Source area to map it to a target
column.
8. Click Save.
When you start replication on the subscription, InfoSphere CDC populates the
target column with system information.

150 InfoSphere Change Data Capture Management Console: Administration Guide

 Related concepts
Mapping journal control fields to target columns on page 150

Mapping expressions to target columns

Mapping expressions to a target columnExpressions are stored and evaluated
on target columns. For example, you can create an expression that:
v Converts integer data on the source column to character data using the column
function %TOCHAR. An expression such as %TOCHAR(OrderID, 6) would convert
integer data to a string of six characters in the source column OrderID so that it
is compatible with the target column that you want to populate.
v Calls a stored procedure that you have configured in a user exit program. You
can specify an expression that contains a valid call to the %STPROC column
manipulation function. If you are calling a stored procedure that is not owned
by the InfoSphere CDC user, you must provide the name in the form
<schema>.<stored procedure name>.

Mapping accumulation and deduction expressions to a target columnIf you

have mapped your tables using Summarization in the Map Tables wizard, then
you can map accumulation or deduction expressions to a target column. When you
map tables for summarization, the target table is largely a repository of numerical
data increments or decrements in response to source row-level operations
transferred by refresh or mirroring activity. For example, if you have a target
column such as REVENUE and you want the value in this column to increment
each time a product gets sold in the SALESAMOUNT source column, then you can
map SALESAMOUNT to REVENUE. Drag and drop the source column from the
list beside the target column to which you want to map.

See also:
To map an expression to a target column
To accumulate or deduct numeric data on a target column on page 152
Related concepts
Mapping to summarize data on page 107
Related tasks
To configure a derived column or an expression that calls %STPROC (Oracle and
Sybase) on page 207

To map an expression to a target column

1. Click Configuration > Subscriptions.
2. Select the subscription.
3. Click the Table Mappings view and select the table mapping from the Source
Table column.
4. Right-click and select Open Mapping Details.
5. Click the Column Mappings tab.
6. Expand the Expressions list and drag and drop New Expression to the target
column you want to map.
7. Build an expression.
8. Click OK.
You should see the expression mapped to the target column on the Column
Mappings tab.
9. Click Save.

Mapping columns 151

 When you start replication, InfoSphere CDC evaluates the expression on the
target column.
Related concepts
Mapping expressions to target columns on page 151

To accumulate or deduct numeric data on a target column

1. Click Configuration > Subscriptions.
2. Select the subscription.
3. Click the Table Mappings view and select the table mapped for Summarization
4. Right-click and select Open Mapping Details.
5. Click the Column Mappings tab.
6. Depending on which source columns you want to summarize data, map your
source columns to target columns.
7. Expand the Summarization list and drag and drop either Accumulation or
Deduction expressions on the source and target column mapping.
You can also build an expression that summarizes data.
8. Select the source column and click OK.
Depending on how you want to summarize data, the source column in the list
updates with a plus or minus sign.
9. Click Save.
When you start replication on the subscription, InfoSphere CDC accumulates or
deducts the summarized data in response to row-level operations occurring on
the source table.
Related concepts
Mapping expressions to target columns on page 151

Mapping source and target columns automatically

Use the Map Columns Automatically dialog box to customize how you want to
map source and target columns. For example, you may have wanted to map a
particular target column to a source column, but because the column names did
not match, the Map Tables wizard did not map them as you wanted. The Map
Tables wizard cannot map a source column such as LOC to the target column
LOCATION. Instead, you can map columns using a different mapping mode based
on criteria such as ordinal position.

See also:
To map columns automatically

To map columns automatically

1. Click Configuration > Subscriptions.
2. Select the subscription.
3. Click the Table Mappings view and select the table mapping from the Source
Table column.
4. Right-click and select Open Mapping Details.
5. Click the Column Mappings tab.
6. Click Auto Map.
7. Select one of the following mapping modes:

152 InfoSphere Change Data Capture Management Console: Administration Guide

 v Original mappingMaps columns based on changes made on the Column
Mapping tab before you opened the Map Columns Automatically dialog box.
v Ordinal positionMaps columns based on the order of columns in the
source and target tables. The first column in the target table is mapped to the
first column in the source table, the second column in the target table is
mapped to the second column in the source table, and so on. If the number
of columns in the target table is greater than the number of the columns in
the source table, then initial values are used for trailing columns in the target
table. If the number of columns in the source table is greater than the
number of columns in the target table, then trailing columns in the source
table remain unmapped. You can only map by ordinal position provided the
data types are compatible.
v Name to nameMaps columns based on matching column names. For
example, if a column in the source table is called EMPNAME, then this
column is automatically mapped to the column in the target table called
EMPNAME.
v Name to descriptionMaps columns based on matching target column
names in source column descriptions. This is useful when you are working
on an IBM i database platform and you need to map the source table names
to target columns.
8. Click OK.
9. Click Save.
You should see your target columns mapped in the mode you selected on the
Column Mappings tab.
When you start replication on the subscription, InfoSphere CDC populates the
target columns using the mapping mode you set.
Related concepts
Mapping source and target columns automatically on page 152

Mapping initial values to target columns

Use the Column Mappings tab to map initial values to unmapped target columns.
After you have mapped your tables using the Map Tables wizard, there may be
target columns that remain unmapped. Target columns can remain unmapped if
the source and target column names do not match, or if there is a greater number
of target columns than source columns. For these target columns, you can define
an initial value such as a constant to populate the target column, or use the default
value of the target column as specified in your RDBMS.

See also:
To define an initial value for a target column

To define an initial value for a target column

1. Click Configuration > Subscriptions.
2. Select the subscription.
3. Click the Table Mappings view and select the table mapping from the Source
Table column.
4. Right-click and select Open Mapping Details.
5. Click the Column Mappings tab.
You will see any unmapped target columns.

Mapping columns 153

 6. Place your cursor beside the target column that you want to populate with an
initial value, and click the Initial Value column.
7. Click to open the Set Initial Value dialog box.
8. Select one of the following options:
v ConstantPopulates the target column with a constant. The constant is
limited to 25 characters. If you select this option, you need to type a
constant in the Constant box.
v NullPopulates the target column with a null value. The data type of the
target column must be nullable.
v BlankPopulates the target column with a blank character. The data type
of the target column must be character or a binary data type.
v ZeroPopulates the target column with a value of zero. The data type of
the target column must be numeric.
v Database DefaultPopulates the target column with the default specified
in your RDBMS. Whenever a row gets inserted into the target table, the
value that populates this column is determined from the column defaults
defined in your RDBMS.
v Current DatePopulates the target column with the current date. The data
type of the target column must be datetime. If your subscription uses
InfoSphere CDC for z/OS as a target datastore, and you have mapped your
tables using the LiveAudit mapping type, then both the before image and
the after image of an update operation are populated with the same current
date.
v Read OnlyIndicates that the column is Read Only and cannot be
populated with an initial value.
9. Click OK.
10. Click Save.
Related concepts
Mapping initial values to target columns on page 153

Adding and mapping derived columns to target columns

Derived columns let you move the processing of an expression from the target
instance to the source instance.

For example, you may have already defined an expression that concatenates the
values of two source columns, FIRSTNAME and LASTNAME, and mapped this
expression to a target column named called FULLNAME. When you start
replication, InfoSphere CDC evaluates the expression on the target instance and
stores the results in the FULLNAME target column.

However, it may become necessary in your environment to move the processing of

this expression to the source instance. Using this same example, you can build a
derived column on the source table named FULLNAME and define an expression
that concatenates the values of the two source columns FIRSTNAME and
LASTNAME. You can then map the derived column named FULLNAME to the
target column named FULLNAME. When you start replication, InfoSphere CDC
evaluates the expression on the source instance and sends the results to the target
column.

You can also create a derived column to:

154 InfoSphere Change Data Capture Management Console: Administration Guide

 v Extract characters from string data by using functions such as %SUBSTRING,
and then store the result in a derived column. For example, you can extract a
person's initial from a column named FIRSTNAME, by using the expression
SUBSTRING(FIRSTNAME,1,1).
v Call a stored procedure that you have configured in a user exit program. You
can specify an expression that contains a valid call to the %STPROC column
manipulation function. If you are calling a stored procedure that is not owned
by the InfoSphere CDC user, you must provide the name in the form
<schema>.<stored procedure name>.
v Retrieve information from a lookup table using %GETCOL. You can create a
derived column on the source table using %GETCOL so that you can retrieve
data from a lookup table. You can then map the source table using one-to-many
consolidation.

In each of these scenarios, you can then map the derived column to the
appropriate target column. InfoSphere CDC will evaluate the expression on the
source table and send the results to the target column.

Since the derived expression is evaluated each time a change is replicated to the
target table, the complexity of the expression can affect overall performance.

See also:
To add a derived column
To map a derived column to a target column on page 156
To modify a derived column on page 156
To delete a derived column on page 157

To add a derived column

1. Click Configuration > Subscriptions.
2. Select the subscription.
3. Click the Table Mappings view and select the table mapping from the Source
Table column.
4. Right-click and select Open Mapping Details.
5. Click the Column Mappings tab.
6. Expand the Source Columns list and double-click New Derived Column.
7. If you already have a source column in your RDBMS on which you want to
base the properties of your derived column, click Copy Column and select the
column from the list of tables.
The properties of this column (the data type, length, and any precision) are
used as the properties of your derived column.
8. Type a name for the derived column in the Name box.
This name must be unique.
9. Type a brief description of the derived column in the Description box.
10. Select a data type of the result from the Data Type list.
11. Type the maximum length for the returned value in the Length box.
12. Select an evaluation frequency:
v After Image OnlySelect this option when you want InfoSphere CDC to
evaluate the expression in the derived column for the after image of the
source table.

Mapping columns 155

 v Before and After ImagesSelect this option when you want InfoSphere
CDC to evaluate the expression in the derived column for both the before
and after images of the source table.
13. If you selected the After Image Only value, evaluate it for performance
reasons.
Derived columns and the expressions you build for them are evaluated on
source tables.
14. If you selected the Before and After Images (*BTH) value, an evaluation is
only necessary when you are performing conflict detection and resolution,
which requires the before image to recognize conflicts, or when you are
auditing so that you can audit the full before image. You also need to select
this evaluation frequency if the target column to which you mapped the
derived column is a primary key column. This maintains database integrity.
Derived columns and the expressions you build for them are evaluated on
source tables.
15. Click Editor to build the expression for the derived column.
16. Click Verify to verify the syntax of the expression.
17. Click OK to return to the Define Derived Column dialog box.
18. Click OK.
19. Click Save.

To map a derived column to a target column

1. Click Configuration > Subscriptions.
2. Select the subscription.
3. Click the Table Mappings view and select the table mapping from the Source
Table column.
4. Right-click and select Open Mapping Details.
5. Click the Column Mappings tab.
6. Expand the Source Columns list, and drag and drop the derived column and
map it to the appropriate target column.
7. Click Save.
When you start replication on the subscription, InfoSphere CDC populates the
target column with the results stored in the derived column.
Related concepts
Adding and mapping derived columns to target columns on page 154
Related tasks
To add a derived column on page 155
To modify a derived column
To delete a derived column on page 157

To modify a derived column

1. Click Configuration > Subscriptions.
2. Select the subscription.
3. Click the Table Mappings view and select the table mapping from the Source
Table column.
4. Right-click and select Open Mapping Details.
5. Click the Column Mappings tab.

156 InfoSphere Change Data Capture Management Console: Administration Guide

 6. Expand the Source Columns list, select and right-click on an existing derived
column and click Modify Derived Column.
7. Make the necessary changes and click OK.
8. Click Verify to ensure the expression is valid.
9. Click Save.
When you start replication on the subscription, InfoSphere CDC populates the
target column with the results stored in the derived column.
Related concepts
Adding and mapping derived columns to target columns on page 154
Related tasks
To add a derived column on page 155
To delete a derived column

To delete a derived column

1. Click Configuration > Subscriptions.
2. Select the subscription.
3. Click the Table Mappings view and select the table mapping from the Source
Table column.
4. Right-click and select Open Mapping Details.
5. Click the Column Mappings tab.
6. Expand the Source Columns list, select and right-click on an existing derived
column and click Delete Derived Column.
7. Click Save.
Related concepts
Adding and mapping derived columns to target columns on page 154
Related tasks
To end replication on page 333
To add a derived column on page 155
To modify a derived column on page 156

Mapping columns 157

158 InfoSphere Change Data Capture Management Console: Administration Guide
Setting data translations on column mappings
Use the Translation tab to add, modify, and delete a data translation. When you
add a data translation and start replication, InfoSphere CDC converts data from
the source columns into the new data you set for a mapped target column. You can
also import and export data translations.

In this section, you will learn:

Setting data translations
Importing and exporting data translations on page 161

Setting data translations

Management Console lets you translate specific data in your source columns to
new data to mapped target columns. For example, you may have a source column
called CITY containing entries like NY, TO, and LON: codes that you want
translated to a target column in their full names (New York, Toronto, and London).
By specifying data translations, you can convert specific data values during data
replication.

You can define data translations for different data types and should only be used
when there is a limited number of translations, such as translating product codes
to their descriptions.

If you need to convert numerical or date information (where the number of

possible data types are limitless), it is best to use an appropriate column function
or write a user exit program to convert this kind of information.

Before adding a data translation, consider the following:

v You can add a data translation for columns that contain integer data. However,
InfoSphere CDC does not support translations that convert to or from fractional
data. For example, InfoSphere CDC supports translations to and from 1 and 100,
but does not support translations to and from 1.01 and 100.01.
v You cannot add a data translation for date, time and timestamp data types. Only
character and integer numeric data types are supported.
v If you use fractional data to represent whole numbers (for example, 1.0 and
100.0), then InfoSphere CDC translates these whole numbers if you have defined
corresponding integer translations (for 1 and 100 respectively).
v You can add a data translation only if the target column is already mapped to a
source column.
v You cannot add data-to-data translations for target columns with large object
(LOB) data types.
v If you have created a subscription that targets an InfoSphere CDC Event Server
datastore, then you can only add a data translation for source columns that are
mapped to target staging columns. You cannot set a data translation for source
columns that are mapped to XML elements and attributes.

See also:
To add a data translation on page 160
To modify a data translation on page 160

Copyright IBM Corp. 2008, 2011 159

 To delete a data translation on page 161
Related tasks
To add a data translation
To modify a data translation
To delete a data translation on page 161
To import a data translation on page 162
To export a data translation on page 161

To add a data translation

1. Click Configuration > Subscriptions.
2. Select the subscription.
3. Click the Table Mappings view and select the table mapping from the Source
Table column.
4. Right-click and select Open Mapping Details.
5. Click the Translation tab.
6. Select a mapped source and target column.
7. Click Add.
8. Type the data you want to translate in the From Value box.
9. If you want to translate a NULL data type, then check the Translate from
NULL box.
10. Type the value to which you want to translate, in the To Value box.
11. If you want to translate to a NULL value, check the Translate to NULL box.
12. If you want to add another translation, click Add to add the current
translation and prepare the dialog for the creation of another translation. If
you do not want to add another data translation, click OK.
13. Click Save.
Related concepts
Mapping tables on page 79
Starting and ending replication on page 327

To modify a data translation

1. Click Configuration > Subscriptions.
2. Select the subscription.
3. Click the Table Mappings view and select the table mapping from the Source
Table column.
4. Right-click and select Open Mapping Details.
5. Click the Translation tab.
6. Select a translation from the Data Translations list and click Modify.
7. Make the necessary changes and click OK.
8. Click Save.

160 InfoSphere Change Data Capture Management Console: Administration Guide

 Related concepts
Mapping tables on page 79
Starting and ending replication on page 327

To delete a data translation

1. Click Configuration > Subscriptions.
2. Select the subscription.
3. Click the Table Mappings view and select the table mapping from the Source
Table column.
4. Right-click and select Open Mapping Details.
5. Click the Translation tab.
6. Select an existing data translation and click Delete.
7. Click Save.
Related concepts
Mapping tables on page 79
Starting and ending replication on page 327

Importing and exporting data translations

You can import and export data translations for mapped source and target
columns. It may be necessary to export a data translation when you know of
multiple column mappings that require the same translation. Instead of manually
specifying the translation for each column mapping, you can import the data
translation and apply it for each column mapping.

When you import a data translation into Management Console, any existing
translations are replaced with the imported translations.

See also:
To export a data translation
To import a data translation on page 162

To export a data translation

1. Click Configuration > Subscriptions.
2. Select the subscription.
3. Click the Table Mappings view and select the table mapping from the Source
Table column.
4. Right-click and select Open Mapping Details.
5. Click the Translation tab.
6. Select a mapped source and target column.
7. Ensure that you have added a data translation for this mapping.
8. Click Export.
9. Save the data translation as a CSV file and click OK.

Setting data translations on column mappings 161

 Related concepts
Importing and exporting data translations on page 161
Related tasks
To import a data translation

To import a data translation

1. Click Configuration > Subscriptions.
2. Select the subscription.
3. Click the Table Mappings view and select the table mapping from the Source
Table column.
4. Right-click and select Open Mapping Details.
5. Click the Translation tab.
6. Select a mapped source and target column.
7. Ensure that you have exported a data translation for this mapping.
8. Click Import.
9. Locate the CSV file and click OK.
Related concepts
Importing and exporting data translations on page 161
Related tasks
To export a data translation on page 161

162 InfoSphere Change Data Capture Management Console: Administration Guide

Replicating multibyte (MBCS) and double-byte (DBCS)
character data
InfoSphere CDC replicates character data between a wide variety of encodings and
will automatically convert the data from the column encoding detected on the
source to the column encoding detected on the target. For example, you can
replicate multibyte character data such as Japanese, Chinese, or Korean. Character
data in these languages cannot be represented in a single-byte. The most common
MBCS implementation is double-byte character sets (DBCS).

By default, InfoSphere CDC assumes that the data stored in a character capable
column is in the encoding associated with that column type. For instance, if your
database is set to use Shift-JIS, then data stored in CHAR and VARCHAR columns
is assumed to be in Shift-JIS by default. However, InfoSphere CDC is only
concerned with the encoding of the data, not the encoding of the column storage
type. This flexibility allows the product to deal with situations where the encoding
of the data does not match the encoding specified for the column in the database.
The ability to override the detected encoding is determined by InfoSphere CDC.
Overriding the detected column encoding allows you to specify the actual
encoding of the data as known by you.

This functionality has been extended to not only standard character-capable

column types such as CHAR and VARCHAR, but also to traditionally Unicode
capable columns such as NCHAR and NVARCHAR, many traditionally binary
column types, as well as many large object (LOB) column types, whether or not
these are traditionally considered to be character-based. InfoSphere CDC treats all
of them as being character data capable. To provide the greatest level of flexibility
and where permitted by the limitations of the database, InfoSphere CDC
undertakes to remove the distinction between the data themselves and the data
type as known by the database that is used to contain the data.

There may be situations where you want to replicate the data exactly as is with no
change to encoding. In these situations, you can designate the column as being
binary and the data will be replicated as is. All binary designated column data
must also be mapped to binary column data.

Encoding conversion can increase the workload for your source or target servers.
InfoSphere CDC provides the ability to specify (with a subscription-level
preference) where that workload will be incurred on either the source or the
target.

InfoSphere CDC also provides an upgrade process for subscriptions that use older
implementations (InfoSphere CDC version 6.3 and earlier) of MBCS support.
Management Console allows you to quickly convert subscriptions to the
auto-encoding mode for MBCS data that is available in InfoSphere CDC version
6.5.

In this section, you will learn:

Common encoding conversion scenarios on page 164
Considerations when replicating MBCS character data on page 165
Upgrading subscriptions to use auto-encoding mode on page 166

Copyright IBM Corp. 2008, 2011 163

 Configuring MBCS encoding conversion between your source and target on
page 167
Specifying the workload preference on page 168
Handling Unicode character encoding on page 169

Common encoding conversion scenarios

Use the following scenarios as guidelines when you want to convert character set
encodings between your source and target.

Scenario 1: Converting encoding between a DB2 z/OS source

and a DB2 LUW target

In this scenario, you have a DB2 z/OS source database with data in Simplified
Chinese and a default database character set encoding of CCSID 935. Your target
database is a DB2 for Windows system with data in Simplified Chinese and a
default character set encoding of GB18030 (CCSID 1392).

InfoSphere CDC will automatically detect the default database encoding of the
source and target columns in your table mappings. If the detected encodings are
appropriate for your business needs, no further configuration is required.

Note: Because of the encoding differences between these platforms, it is important

to note that not all characters will convert with equivalent characters.

Scenario 2: Converting from a national language character set to

Unicode

In this scenario, you have a configuration in which data needs to be converted

from a national language character set to Unicode. For example, the character set
encoding on the source is Traditional Chinese, while the character set encoding on
the target (to which you want to convert) is Unicode. No configuration is required
in Management Console.

Scenario 3: Overriding the database default encoding of a

column as detected by InfoSphere CDC

The default encoding of a column in a database can be different from the data
itself. InfoSphere CDC allows you to deal with these situations by allowing you to
override the detected encoding of a column.

For example, you have a source database with a default encoding of Windows-1252
and you want to replicate CHAR data to your target. You also have Shift-JIS
character data in CHAR columns in your source database. InfoSphere CDC will
likely detect that all CHAR columns in your source database are Windows-1252
because this is the encoding of the column in your database or the default database
encoding. InfoSphere CDC will determine if you can select an encoding that is
more appropriate for your data. If InfoSphere CDC allows it, you can override the
Windows-1252 encoding and select Shift-JIS encoding for those columns that
contain Shift-JIS data.

164 InfoSphere Change Data Capture Management Console: Administration Guide

 Scenario 4: Replicating mixed character data encodings on the
source to multiple encodings on the target

In this scenario, your source data is a mix of different character encodings but is
primarily IBM-943. Business requirements dictate that you must have the following
character encodings on your target: IBM-943 and IBM-943c.

InfoSphere CDC allows you to override the detected encodings in your target
columns and set them to either IBM-943 or IBM-943c.

Scenario 5: Replicating character data with no change to

encoding

You can replicate data as is with no change to the encoding by designating the
source and target columns in a table mapping as a binary with the Override
encoding as binary option in Management Console.

In this scenario, your DB2 for z/OS source has data structures in a character field.
The data structure contains EBCDIC characters, dates, and packed numbers. You
want to use a user exit to split the data and send it to 10-20 fields on your target.
You can use the Java getBytes function in your user exit to read the data and
perform the data conversion. Since the getBytes function is only allowed on a
binary field or a character field that is overridden in Management Console as a
binary, you can use Override encoding as binary option for the source and target
columns in the table mapping. This will allow getBytes to retrieve data from the
source image as bytes.

The Override encoding as binary option is useful in scenarios where the character
column does not contain characters only, but other data types with complex
structures.

Scenario 6: Overriding a binary field with an appropriate

encoding for your data

In this scenario, you have source column with various encodings in a binary field.
You use row filtering when replicating tables to the target so that you only have
one type of encoding on the target. In the source columns that are detected as
Binary by Management Console, you can override the detected encoding type of
Binary and select the encoding that is appropriate for the actual data in each
source column. In this scenario, you can have the same source table mapped to the
same target table, but the encodings on the source binary columns are different
from the single encoding that is found on your target.
Related concepts
Configuring MBCS encoding conversion between your source and target on page
167
Handling Unicode character encoding on page 169

Considerations when replicating MBCS character data

When mapping source columns to target columns that contain MBCS character
data, consider the following:
v Most databases enforce NCHAR and NVARCHAR as Unicode and the encoding
is not changeable.
v All binary data types such as BLOB will not have a default encoding, although
InfoSphere CDC allows you to specify an encoding.

Replicating multibyte (MBCS) and double-byte (DBCS) character data 165

 v Ensure that the target column you want to send data to is large enough to store
the replicated character data.
v Your data will not be replicated if you override the encoding for
graphic, vargraphic, and dbclob columns.
v For InfoSphere CDC products that support XML replication, InfoSphere CDC
can only replicate XML compliant data to XML column types. Please see the
XML specification for the compliance criteria.
v InfoSphere CDC will respect the mappings and apply the data according to the
character set that is configured for the data. InfoSphere CDC does not validate
that the character set can be inserted correctly into the column.
v Target tables must use the correct length values. Databases use character length
semantics, byte length semantics, or both.
v InfoSphere CDC version 6.5 performs encoding conversion on the target by
default, with an option to specify the source. This is a change in behavior from
previous releases of InfoSphere CDC that always performs encoding conversion
on the source with no option to specify the target. Encoding conversion is a CPU
intensive activity and you should take this into consideration when deciding
where encoding conversion will take place.
v Before using MBCS functionality in InfoSphere CDC, you must ensure that your
operating system, database, and all tools used to enter data (such as a terminal)
are properly configured for your MBCS environment by a system administrator.
Otherwise, unexpected behavior may result.
v Java class user exits in InfoSphere CDC support MBCS character data. All
character data is converted to Java String objects.
v InfoSphere CDC for Teradata does not support MBCS character data on the AIX
operating system.
Related concepts
Replicating multibyte (MBCS) and double-byte (DBCS) character data on page
163

Upgrading subscriptions to use auto-encoding mode

If you are planning to upgrade your datastore to InfoSphere CDC version 6.5 and
you want to use the auto-encoding functionality that is available for MBCS
character data, you are required to manually upgrade subscriptions that you
created with InfoSphere CDC version 6.3 and earlier.

To use auto-encoding mode for subscriptions created with InfoSphere CDC version
6.3 and earlier:
1. Upgrade your target datastore to InfoSphere CDC version 6.5.
2. Upgrade your source datastore to InfoSphere CDC version 6.5.
3. Upgrade subscriptions that were created with InfoSphere CDC version 6.3 by
following the procedure outlined in this section.

For more information on upgrade procedures, see the InfoSphere CDC

documentation for your database platform.

Note: All subscriptions created with a new installation of InfoSphere CDC version
6.5 will automatically use auto-encoding mode.

See also:
To upgrade subscriptions to use auto-encoding mode on page 167

166 InfoSphere Change Data Capture Management Console: Administration Guide

 To upgrade subscriptions to use auto-encoding mode
1. Click Configuration > Subscriptions.
2. Right-click the subscription (InfoSphere CDC version 6.3 and earlier) that you
want to upgrade and select Convert to Auto-Encoding Mode.
3. Management Console prompts you to confirm that you want to convert all
table mappings in the subscription to auto-encoding mode. Click Yes.
4. Management Console displays a progress bar and disconnects from Access
Server when the upgrade is complete.
5. Log in to Access Server to use auto-encoding mode for the upgraded
subscription.
Related concepts
Upgrading subscriptions to use auto-encoding mode on page 166

Configuring MBCS encoding conversion between your source and

target
Use the Encoding tab in the Mapping Details view to configure encoding
conversion between your source and target for MBCS data. InfoSphere CDC
converts the character sets during replication.

InfoSphere CDC automatically detects the default database encoding for source
and target columns in a table mapping. If your database supports it, you can
choose to override the default encoding for a column if this suits your business
needs. If the detected default encodings are appropriate for your business needs,
no further changes are necessary.

For InfoSphere CDC version 6.3 and earlier, Management Console provides
standard character sets and encodings. To add additional character sets and
encodings, use the CSV (comma separated variable) template that is found in the
Advanced preferences of Edit > Preferences. This step is not necessary for
InfoSphere CDC version 6.5, which retrieves the supported encodings directly from
your datastores.

See also:
To configure MBCS encoding conversion

To configure MBCS encoding conversion

1. Click Configuration > Subscriptions.
2. Right-click the table mapping and select Open Mapping Details.
3. Click the Encoding tab.
4. Depending on your version of InfoSphere CDC, choose from the following
options:
For InfoSphere CDC version 6.5:
a. If you want to change the encoding for a source column that supports
character encoding, click Edit in the Source Encoding area to open the
Source Encoding dialog box.
b. From the list of supported encoding overrides, select the appropriate
encoding for your data.
For example, if your data is stored in Chinese characters, then you can
select from either Traditional or Simplified encodings.

Replicating multibyte (MBCS) and double-byte (DBCS) character data 167

 c. To replicate the data with no changes to the encoding, select Override
encoding as binary. You must also designate the target column as binary if
the source column is binary.
d. Click OK.
e. If you want to change the encoding for a target column that supports
character encoding, click Edit in the Target Encoding area to open the
Target Encoding dialog box.
f. From the list of supported encoding overrides, select the appropriate
encoding for your data. This is the encoding that your source data will be
converted to.
g. If you designated a source column as binary, you must also select Override
encoding as binary for the target column.
h. Click OK.
For InfoSphere CDC version 6.3 and earlier:
a. If you want to change the encoding for a source or target column that
supports character encoding, select the source column and click Edit to
open the Column Encoding dialog box.
b. In the Source drop down list, select the appropriate encoding for your
source column.
For example, if your data is stored in Chinese characters, then you can
select from either Traditional or Simplified encodings.
c. In the Target drop-down list, select the appropriate encoding for your target
column. This is the encoding that your source data will be converted to.
d. Click OK.
5. Click Save.
Related concepts
Configuring MBCS encoding conversion between your source and target on page
167

Specifying the workload preference

InfoSphere CDC provides the ability to specify whether your source or target
should try to minimize CPU load in order to improve performance.

Encoding conversion is one process that respects this preference. There are a
number of factors that influence where the encoding conversion will take place
and because of these, this preference is not a guarantee. Factors influencing where
the encoding conversion takes place include the encoding conversion capabilities of
the source and target, and the number of table mappings of a single source column
to target columns.

InfoSphere CDC version 6.5 performs encoding conversion on the target by

default, with an option to specify the source. This is a change in behavior from
previous releases of InfoSphere CDC that always performs encoding conversion on
the source with no option to specify the target. Subscriptions that are upgraded
from InfoSphere CDC version 6.3 will perform encoding conversion on the source
by default, although you now have the option of specifying the target. Encoding
conversion is a CPU intensive activity and you should take this into consideration
when deciding where encoding conversion will take place.

See also:
To set the workload preference on page 169

168 InfoSphere Change Data Capture Management Console: Administration Guide

 To set the workload preference
1. Click Configuration > Subscriptions.
2. Right-click the subscription that contains table mappings with encoding
conversion work and select Properties.
3. Click Advanced Settings.
4. Select one of the following options from the Select the datastore to handle
transferable work drop-down box:
v TargetInfoSphere CDC will attempt to perform the encoding conversion
workload on the server where your target datastore is installed. This is the
default setting.
v SourceInfoSphere CDC will attempt to perform the encoding conversion
workload on the server where your source datastore is installed. This is the
default setting for subscriptions that have been upgraded from InfoSphere
CDC version 6.3 and earlier.

Note: If your target datastore is InfoSphere CDC for IBM InfoSphere DataStage,
encoding conversion workload will always take place on the server where your
target datastore is installed.
5. Click OK and click OK again.
6. A progress bar is displayed while Management Console updates the
subscription properties.
Related concepts
Specifying the workload preference on page 168

Handling Unicode character encoding

Note: The tasks in this section are only applicable to InfoSphere CDC version 6.3
and earlier.

Use the Encoding tab in the Mapping Details view of Management Console to set
how InfoSphere CDC handles Unicode data from the source column. If your source
column contains character data stored in multibyte, double-byte, or Unicode
character set, then you can indicate how InfoSphere CDC handles data from this
source column when replicating to a target column.

Management Console provides standard character sets and encodings. If you want
to add more character sets and encodings, then you are required to add it to the
CSV template that is found in the Advanced preferences in Edit > Preferences.

Before you can configure how InfoSphere CDC handles Unicode data, you need to
set one of the following system parameters (depending on the version and
platform of InfoSphere CDC) to define the system default method of handling data
in Unicode columns:
v For InfoSphere CDC for Oracle (version 6.3), see global_unicode_as_char on
page 472.
v For InfoSphere CDC for Oracle - Trigger (version 6.3), see
global_unicode_as_char on page 484.
v For InfoSphere CDC for Oracle (version 6.2 and earlier), see
UNICODE_HANDLING on page 439.
v For InfoSphere CDC for Microsoft SQL Server (version 5.3 and earlier), see
Unicode Handling on page 397.

Replicating multibyte (MBCS) and double-byte (DBCS) character data 169

 v For InfoSphere CDC for Microsoft SQL Server (version 6.0 to version 6.3), see
global_unicode_as_char on page 413.
v For InfoSphere CDC for Sybase (version 6.3), see global_unicode_as_char on
page 523.
v For InfoSphere CDC for IBM Informix Dynamic Server (version 6.3), see
global_unicode_as_char on page 628.
v For InfoSphere CDC for DB2 LUW (version 6.1 to version 6.3), see
global_unicode_as_char on page 586.
v For InfoSphere CDC for DB2 LUW (version 6.0 and earlier), see
unicode_handling on page 573.
v For InfoSphere CDC for IBM i (version 6.2 and earlier), see Unicode Handling
on page 543.

See also:
To set handling for Unicode character encoding

To set handling for Unicode character encoding

Note: This task is only applicable to InfoSphere CDC version 6.3 and earlier.
1. Click Configuration > Subscriptions.
2. Select the subscription.
3. Click the Table Mappings view and select the table mapping from the Source
Table column.
4. Right-click and select Open Mapping Details.
5. Click the Encoding tab.
6. Right-click the source column that supports character handling from the Source
Columns list and select Edit Encoding. This opens the Column Encoding
dialog box.
7. If you have set the applicable system parameter (depending on your version of
InfoSphere CDC) to use the system default method to handle the character set,
select System Default.
8. If you want to use an encoding for the character set, select from one of the
following:
v CHARSelect this value if you have set the applicable system parameter to
CHAR or true. InfoSphere CDC treats all data in Unicode columns as
single-byte characters. Use this encoding when Unicode columns contain
single-byte character data.
v NOCHANGESelect this value if you have set the applicable system
parameter to NO CHANGE or false. InfoSphere CDC treats all data in Unicode
columns as a continuous bit stream. Use this encoding when Unicode
columns contain non-single-byte character data. NOCHANGE ensures that
InfoSphere CDC handles non-single-byte character data in the same way as
previous InfoSphere CDC releases.
9. Click Save.
Related concepts
Handling Unicode character encoding on page 169

170 InfoSphere Change Data Capture Management Console: Administration Guide

Setting member identifiers
IBM i environments supports a table concept known as multi-member files, in
which one table can possess several different members. Each member is part of the
same table and shares the same schema, but the members are uniquely named and
have unique data. If you have installed InfoSphere CDC for IBM i on your source
system and want to replicate a multi-member source table to a single-member
target table, then you need to identify each member in the source table. InfoSphere
CDC requires an identifier so that it does not truncate rows when it applies a
refresh to a single-member target table. If you do not specify an identifier for your
multi-member source table, then each time InfoSphere CDC applies a refresh to the
single-member target, the member data on the target is overwritten by data from
another member.

In this section, you will learn:

Setting member identifiers for multi-member source tables

Setting member identifiers for multi-member source tables

You can add, modify, or delete member identifiers when you have installed
InfoSphere CDC for IBM i on your source system and you are replicating a
multi-member source table to a single-member target table on any platform.

Before adding a member identifier, you need to create a column on the target table
that can maintain the identifiers for the members in your source table. After
creating the target column, map the journal control field &MEMBER to this
column.

See also:
To add a member identifier
To modify a member identifier on page 172
To delete a member identifier on page 172

To add a member identifier

1. Ensure that you have mapped an InfoSphere CDC for IBM i multi-member
source table to a single-member target table on any platform
2. Click Configuration > Subscriptions.
3. Select the subscription.
4. Click the Table Mappings view and select the table mapping from the Source
Table column.
5. Right-click and select Open Mapping Details.
6. Click the Operation tab.
7. Click Member Identifiers.
8. Click Add.
9. Type the name of the member for which you want to add an identifier in the
Member Name box.
10. Expand the Target Columns tree and double-click to select the target column
you want to include in the member identifier WHERE clause.
11. Click Verify to make sure the expression is valid and click OK.

Copyright IBM Corp. 2008, 2011 171

 You can continue adding identifiers for each member in your source table.
12. Click OK.
13. Click Save.
Related concepts
Setting member identifiers for multi-member source tables on page 171

To modify a member identifier

1. Click Configuration > Subscriptions.
2. Select the subscription.
3. Click the Table Mappings view and select the table mapping from the Source
Table column.
4. Right-click and select Open Mapping Details.
5. Click the Operation tab.
6. Click Member Identifiers.
7. Click Modify.
8. Make the necessary changes and clickOK.
You can continue making changes to other member identifiers or click OK to
save your changes.
9. Click Save.
Related concepts
Setting member identifiers for multi-member source tables on page 171

To delete a member identifier

1. Click Configuration > Subscriptions.
2. Select the subscription.
3. Click the Table Mappings view and select the table mapping from the Source
Table column.
4. Right-click and select Open Mapping Details.
5. Click the Operation tab.
6. Click Member Identifiers.
7. Select the member identifier that you want to delete and click Delete.
8. Click OK.
9. Click Save.
Related concepts
Setting member identifiers for multi-member source tables on page 171

172 InfoSphere Change Data Capture Management Console: Administration Guide

Using journal control fields for auditing replication activities
In this section, you will learn:
About journal control fields
About journal codes on page 184
Translating journal codes into meaningful information on page 187

About journal control fields

Journal control fields provide information about the log entry on the source
system. When a change is made on the source system, the database records the
change in a log entry that contains the changed data plus extra information about
what type of change was made, who made the change, and when the change was
made. When a relevant log entry triggers a replication event to the target system,
InfoSphere CDC replicates the changed data along with the extra log entry
information to the target system. InfoSphere CDC makes the extra log entry
information available through journal control fields.

InfoSphere CDC provides many journal control fields that contain log entries from
your source systems. You can map journal control fields to columns on the target
system. InfoSphere CDC replicates the log information from the source system and
applies this information to the mapped columns on your target system. For
example, you may want to maintain when the last replicated change was applied
to each row in a table on the source system. To capture this information for each
row in a table on the target system, you can add a column to the table and map
that column to the appropriate journal control field. You can also include journal
control fields in row selection and derived expressions.

Before using a journal control field, you should consider the following:
v If you have installed InfoSphere CDC Version 5.2 or higher, some journal control
fields contain non-character data. Depending on the source and target database
vendors, InfoSphere CDC converts these values to character data before they are
passed to a user exit program. For more information, see the appropriate User
Exits section for your platform.
v Depending on the type of platform you have installed InfoSphere CDC and the
replication method (mirror or refresh), some journal control fields may or may
not be supported.
v If you have installed InfoSphere CDC for z/OS and you want to build an
expression with &MEMBER, then you need to enclose this journal control field
in single quotes.
v InfoSphere CDC does not support the mapping of journal control fields to LOB
columns in a target table.

See also:
Commit Cycle ID (&CCID) on page 174
Source RRN (&CNTRRN) on page 174
Entry Type Code (&CODE) on page 175
Entry Type (&ENTTYP) on page 175
Source Job Name (&JOB) on page 176

Copyright IBM Corp. 2008, 2011 173

 Source Job Number (&JOBNO) on page 176
Source Job User (&JOBUSER) on page 177
Journal Name (&JOURNAL) on page 178
Source Table Library (&LIBRARY) on page 179
Source Table Member Name (&MEMBER) on page 179
Source Table Name (&OBJECT) on page 180
Source Program Name (&PROGRAM) on page 180
Journal Sequence Number (&SEQNO) on page 181
Source Server Name (&SYSTEM) on page 182
Record Modification Time (&TIMSTAMP) on page 182
Record Modification User (&USER) on page 183

Commit Cycle ID (&CCID)

An identifier for the transaction with the insert, delete or update operation.

Data TypeInteger (InfoSphere CDC 5.x and later)

InfoSphere CDC SupportSupport for this journal control field is available only
when InfoSphere CDC mirrors data, and is not available when refreshing data. If
you decide to use this journal control field when refreshing data, InfoSphere CDC
sets this journal control field to a default value of 0.

Source RRN (&CNTRRN)

The relative record number of the source table that recorded the journal entry.

Data TypeInteger (InfoSphere CDC 5.x)

InfoSphere CDC SupportDepending on the InfoSphere CDC product that you

install, journal control fields may or may not be supported when mirroring or
refreshing data. Unsupported journal control fields contain default values that vary
between the InfoSphere CDC products.
v InfoSphere CDC for IBM iSupport for this journal control field is available
when InfoSphere CDC mirrors or refreshes data.
v InfoSphere CDC for Oracle Trigger version 6.0 and earlierSupport for this
journal control field is available when InfoSphere CDC mirrors or refreshes data.
v InfoSphere CDC for Microsoft SQL ServerSupport for this journal control
field is available only when InfoSphere CDC refreshes data, and is not available
when mirroring data. If you decide to use this journal control field when
mirroring data, InfoSphere CDC sets this journal control field to a default value
of 0.
v InfoSphere CDC for DB2 UDB Support for this journal control field is
available only when InfoSphere CDC refreshes data, and is not available when
mirroring data. If you decide to use this journal control field when mirroring
data, InfoSphere CDC sets this journal control field to a default value of 0.
v InfoSphere CDC for z/OSSupport for this journal control field is not
available.

174 InfoSphere Change Data Capture Management Console: Administration Guide

Entry Type Code (&CODE)
The code that identifies the type of journal entry. "U" for refresh and "R" for mirror.

Data TypeCharacter

InfoSphere CDC SupportDepending on the InfoSphere CDC product that you

install, journal control fields may or may not be supported when mirroring or
refreshing data. Unsupported journal control fields contain default values that vary
between the InfoSphere CDC products.
v InfoSphere CDC for IBM iSupport for this journal control field is available
only when mirroring data, and is not available when refreshing data. If you
decide to use this journal control field when refreshing data, InfoSphere CDC
sets this journal control field to a default value of U.
v InfoSphere CDC for Oracle Trigger version 6.0 and earlierSupport for this
journal control field is available only when InfoSphere CDC refreshes data, and
is not available when mirroring data. When refreshing data, InfoSphere CDC
sets this journal control field to a default value of R. If you decide to use this
journal control field when mirroring data, InfoSphere CDC sets this journal
control field to NULL.
v InfoSphere CDC for Microsoft SQL ServerSupport for this journal control
field is available when InfoSphere CDC mirrors or refreshes data.
v InfoSphere CDC for DB2 LUWSupport for this journal control field is
available when InfoSphere CDC mirrors or refreshes data.
v InfoSphere CDC for z/OSSupport for this journal control field is available
when InfoSphere CDC mirrors or refreshes data.

Entry Type (&ENTTYP)

Indicates the type of update.

For each journal entry code there are one or more possible journal entry types that
provide more detailed information about the entry. For more information, see
Using journal control fields for auditing replication activities on page 173.

You can use journal entry types for auditing events that occur between your source
and target tables. For example, you can use a journal entry type to label each audit
record with the event that occurred on your source table that caused the audit
record to be written to the target table. This is represented by a distinct two-letter
code.

Data TypeCharacter

InfoSphere CDC SupportDepending on the InfoSphere CDC product that you

install, journal control fields may or may not be supported when mirroring or
refreshing data. Unsupported journal control fields contain default values that vary
between the InfoSphere CDC products.
v InfoSphere CDC for IBM iSupport for this journal control field is available
only when InfoSphere CDC mirrors data, and is not available when refreshing
data. If you decide to use this journal control field when refreshing data,
InfoSphere CDC sets this journal control field to a default value of RR.
v InfoSphere CDC for Oracle Trigger version 6.0 and earlierSupport for this
journal control field is available when InfoSphere CDC mirrors or refreshes data.

Using journal control fields for auditing replication activities 175

 v InfoSphere CDC for Microsoft SQL ServerSupport for this journal control
field is available when InfoSphere CDC mirrors or refreshes data.
v InfoSphere CDC for DB2 UDBSupport for this journal control field is
available when InfoSphere CDC mirrors or refreshes data.
v InfoSphere CDC for z/OSSupport for this journal control field is available
when InfoSphere CDC mirrors or refreshes data.

Source Job Name (&JOB)

The name of the job that made the update on the source system.

Data TypeCharacter

InfoSphere CDC SupportDepending on the InfoSphere CDC product that you

install, journal control fields may or may not be supported when mirroring or
refreshing data. Unsupported journal control fields contain default values that vary
between the InfoSphere CDC products.
v InfoSphere CDC for IBM iSupport for this journal control field is available
only when InfoSphere CDC mirrors data, and is not available when refreshing
data. If you decide to use this journal control field when refreshing data,
InfoSphere CDC sets this journal control field to UNKNOWN.
v InfoSphere CDC for Oracle Trigger version 6.0 and earlierSupport for this
journal control field is available only when InfoSphere CDC mirrors data, and is
not available when refreshing data. When mirroring data, this journal control
field contains the program that performed the operation on the source table. If
you decide to use this journal control field when refreshing data, InfoSphere
CDC sets this journal control field to NULL.
v InfoSphere CDC for Microsoft SQL Server (version 5.3)Support for this
journal control field is not available. If you decide to use this journal control
field when mirroring data, this journal control field contains data that is not
consistent with the defined contents of the journal control field. If you decide to
use this journal control field when refreshing data, InfoSphere CDC leaves this
journal control field empty.
v InfoSphere CDC for Microsoft SQL Server (version 6.0)Support for this
journal control field is not available. If you decide to use this journal control
field when mirroring data, InfoSphere CDC leaves it empty. If you decide to use
this journal control field when refreshing data, InfoSphere CDC sets this journal
control field to TS.
v InfoSphere CDC for DB2 UDBSupport for this journal control field is not
available. If you decide to use this journal control field when mirroring data,
InfoSphere CDC leaves it empty. If you decide to use this journal control field
when refreshing data, InfoSphere CDC sets this journal control field to TS.
v InfoSphere CDC for z/OSSupport for this journal control field is available
only when InfoSphere CDC mirrors data, and is not available when refreshing
data. When mirroring data, this journal control field contains the Logical Unit of
Work's Correlation ID. The Correlation ID is an internal DB2 identifier. It is
usually the name of the job that created the Logical Unit of Work.

Source Job Number (&JOBNO)

The operating system user ID of the update process.

Data TypeCharacter

176 InfoSphere Change Data Capture Management Console: Administration Guide

 InfoSphere CDC SupportDepending on the InfoSphere CDC product that you
install, journal control fields may or may not be supported when mirroring or
refreshing data. Unsupported journal control fields contain default values that vary
between the InfoSphere CDC products.
v InfoSphere CDC for IBM iSupport for this journal control field is available
only when InfoSphere CDC mirrors data, and is not available when refreshing
data. If you decide to use this journal control field when refreshing data,
InfoSphere CDC sets this journal control field to a default value of 0.
v InfoSphere CDC for Oracle Trigger version 6.0 and earlierSupport for this
journal control field is available only when InfoSphere CDC mirrors data, and is
not available when refreshing data. When mirroring data, this journal control
field contains the process ID (UNIX) and the process name (Windows) that
performed the operation on the source table. If you decide to use this journal
control field when refreshing data, InfoSphere CDC sets this journal control field
to NULL.
v InfoSphere CDC for Microsoft SQL Server (version 5.3)Support for this
journal control is not available. If you decide to use this journal control field
when mirroring data, InfoSphere CDC sets this journal control field to a default
value of 0. If you decide to use this journal control field when refreshing data,
InfoSphere CDC leaves this journal control field empty.
v InfoSphere CDC for Microsoft SQL Server (version 6.0)Support for this
journal control field is not available. If you decide to use this journal control
field when mirroring data, InfoSphere CDC leaves this journal control field
empty. If you decide to use this journal control field when refreshing data,
InfoSphere CDC sets this journal control field to 000000.
v InfoSphere CDC for DB2 UDBSupport for this journal control field is not
available. If you decide to use this journal control field when mirroring data,
InfoSphere CDC leaves this journal control field empty. If you decide to use this
journal control field when refreshing data, InfoSphere CDC sets this journal
control field to 000000.
v InfoSphere CDC for z/OSSupport for this journal control field is not
available. When mirroring data, InfoSphere CDC sets this journal control field to
000000. If you decide to use this journal control when refreshing data, the
journal control field contains an empty string.

Source Job User (&JOBUSER)

The operating system user at the time of the update.

Data TypeCharacter

InfoSphere CDC SupportDepending on the InfoSphere CDC product that you

install, journal control fields may or may not be supported when mirroring or
refreshing data. Unsupported journal control fields contain default values that vary
between the InfoSphere CDC products.
v InfoSphere CDC for IBM iSupport for this journal control field is available
only when InfoSphere CDC mirrors data, and is not available when refreshing
data. If you decide to use this journal control field when refreshing data,
InfoSphere CDC sets this journal control field to UNKNOWN.
v InfoSphere CDC for Oracle Trigger version 6.0 and earlierSupport for this
journal control field is available only when InfoSphere CDC mirrors data, and is
not available when refreshing data. When mirroring data, this journal control
field contains the name of the user that performed the operation on the source

Using journal control fields for auditing replication activities 177

 table. If you decide to use this journal control field when refreshing data,
InfoSphere CDC sets this journal control field to NULL.
v InfoSphere CDC for Microsoft SQL Server (version 5.3)Support for this
journal control field is not available. If you decide to use this journal control
field when mirroring or refreshing data, InfoSphere CDC leaves this journal
control field empty.
v InfoSphere CDC for Microsoft SQL Server (version 6.0 and later)Support for
this journal control field is not available. If you decide to use this journal control
field when mirroring data, InfoSphere CDC sets this journal control field to the
database user name. The name is set to the database user that owns the
InfoSphere CDC metadata tables. If you decide to use this journal control field
when refreshing data, InfoSphere CDC sets this journal control field to TS.
v InfoSphere CDC for DB2 UDBSupport for this journal control field is not
available.
v InfoSphere CDC for z/OSSupport for this journal control field is available
when InfoSphere CDC mirrors or refreshes data. When mirroring data, this
journal control field contains the Authorization ID that the job used to connect
to DB2. This is usually the User ID of the job. When refreshing data, this journal
control field contains the User ID of the InfoSphere CDC address space.

Journal Name (&JOURNAL)

The name of the journal.

Depending on the version of InfoSphere CDC you install, the high byte of this
journal control field identifies the name of the journal, and the low byte of this
field identifies the library where it resides. For example, JRN1 LIB1.

Data TypeCharacter

InfoSphere CDC SupportDepending on the InfoSphere CDC product that you

install, journal control fields may or may not be supported when mirroring or
refreshing data. Unsupported journal control fields contain default values that vary
between the InfoSphere CDC products.

If both the name and library are included in this journal control field, then
&JRNLIB journal control field is not supported by InfoSphere CDC.
v InfoSphere CDC for IBM iSupport for this journal control field is available
only when InfoSphere CDC mirrors data, and is not available when refreshing
data. When mirroring data, it contains the journal name and journal library. If
you decide to use this journal control field when refreshing data, InfoSphere
CDC sets this journal control field to UNKNOWN.
v InfoSphere CDC for Oracle Trigger version 6.0 and earlierSupport for this
journal control field is available only when InfoSphere CDC mirrors data, and is
not available when refreshing data. When mirroring data, this journal control
field contains the journal name in the format <schema>.<journal>. If you decide
to use this journal control field when refreshing data, InfoSphere CDC sets this
journal control field to NULL.
v InfoSphere CDC for Microsoft SQL ServerSupport for this journal control
field is available only when InfoSphere CDC mirrors data, and is not available
when refreshing data. If you decide to use this journal control field when
refreshing data, InfoSphere CDC leaves this journal control field empty.
v InfoSphere CDC for DB2 UDBSupport for this journal control field is
available only when InfoSphere CDC mirrors data, and is not available when

178 InfoSphere Change Data Capture Management Console: Administration Guide

 refreshing data. If you decide to use this journal control field when refreshing
data, InfoSphere CDC leaves this journal control field empty.
v InfoSphere CDC for z/OSSupport for this journal control field is only
available when InfoSphere CDC mirrors data, and is not available when
refreshing data. When mirroring data, this journal control field contains the
name of the DB2 subsystem or data sharing group to which InfoSphere CDC is
connected.

Source Table Library (&LIBRARY)

The name of the source table schema or its alias.

Data TypeCharacter

InfoSphere CDC SupportDepending on the InfoSphere CDC product that you

install, journal control fields may or may not be supported when mirroring or
refreshing data. Unsupported journal control fields contain default values that vary
between the InfoSphere CDC products.
v InfoSphere CDC for IBM iSupport for this journal control field is available
when InfoSphere CDC mirrors or refreshes data.
v InfoSphere CDC for Oracle Trigger version 6.0 and earlierSupport for this
journal control field is available only when InfoSphere CDC mirrors data, and is
not available when refreshing data. When mirroring data, this journal control
field contains the journal name in the format <schema>.<journal>. If you decide
to use this journal control field when refreshing data, InfoSphere CDC sets this
journal control field to a default value of N.
v InfoSphere CDC for Microsoft SQL ServerSupport for this journal control
field is available when InfoSphere CDC mirrors or refreshes data.
v InfoSphere CDC for DB2 UDBSupport for this journal control field is
available when InfoSphere CDC mirrors or refreshes data.
v InfoSphere CDC for z/OSSupport for this journal control field is only
available when InfoSphere CDC mirrors data, and is not available when
refreshing data. When mirroring data, the journal control field contains the
database name in which the table was created and owner ID of the table in the
format <dbname.owner>.

Source Table Member Name (&MEMBER)

The name of the source table or its alias.

Data TypeCharacter

InfoSphere CDC SupportDepending on the InfoSphere CDC product that you

install, journal control fields may or may not be supported when mirroring or
refreshing data. Unsupported journal control fields contain default values that vary
between the InfoSphere CDC products.
v InfoSphere CDC for IBM iSupport for this journal control field is available
when InfoSphere CDC mirrors or refreshes data.
v InfoSphere CDC for Oracle Trigger version 6.0 and earlierSupport for this
journal control field is available when InfoSphere CDC mirrors or refreshes data.
When mirroring or refreshing data, this journal control field contains the name
of the source table.

Using journal control fields for auditing replication activities 179

 v InfoSphere CDC for Microsoft SQL Server (version 5.3)Support for this
journal control field is available when InfoSphere CDC mirrors or refreshes data.
When mirroring or refreshing data, this journal control field contains the name
of the source table.
v InfoSphere CDC for Microsoft SQL Server (version 6.0)Support for this
journal control field is not available. If you decide to use this journal control
field when mirroring or refreshing data, InfoSphere CDC leaves this journal
control field empty.
v InfoSphere CDC for DB2 UDBSupport for this journal control field is not
available. If you decide to use this journal control field when mirroring or
refreshing data, InfoSphere CDC leaves this journal control field empty.
v InfoSphere CDC for z/OSSupport for this journal control field is not
available.

Source Table Name (&OBJECT)

The name of the source table or its alias.

Data TypeCharacter

InfoSphere CDC SupportDepending on the InfoSphere CDC product that you

install, journal control fields may or may not be supported when mirroring or
refreshing data. Unsupported journal control fields contain default values that vary
between the InfoSphere CDC products.
v InfoSphere CDC for IBM iSupport for this journal control field is available
when InfoSphere CDC mirrors or refreshes data.
v InfoSphere CDC for Oracle Trigger version 6.0 and earlierSupport for this
journal control field is available only when InfoSphere CDC mirrors data. When
mirroring or refreshing data, this journal control field contains the name of the
source table.
v InfoSphere CDC for Microsoft SQL ServerSupport for this journal control
field is available when InfoSphere CDC mirrors or refreshes data
v InfoSphere CDC for DB2 LUWSupport for this journal control field is
available when InfoSphere CDC mirrors or refreshes data. When mirroring or
refreshing data, this journal control field contains the name of the source table.
v InfoSphere CDC for z/OSSupport for this journal control field is available
when InfoSphere CDC mirrors or refreshes data. When mirroring or refreshing
data, this journal control field contains the name of the source table.

Source Program Name (&PROGRAM)

The name of the program on the source system that made the update.

Data TypeCharacter

InfoSphere CDC SupportDepending on the InfoSphere CDC product that you

install, journal control fields may or may not be supported when mirroring or
refreshing data. Unsupported journal control fields contain default values that vary
between the InfoSphere CDC products.
v InfoSphere CDC for IBM iSupport for this journal control field is available
only when InfoSphere CDC mirrors data, and is not available when refreshing
data. If you decide to use this journal control field when refreshing data,
InfoSphere CDC sets this journal control field to UNKNOWN.

180 InfoSphere Change Data Capture Management Console: Administration Guide

 v InfoSphere CDC for Oracle Trigger version 6.0 and earlierSupport for this
journal control field is available only when InfoSphere CDC mirrors data, and is
not available when refreshing data. When mirroring data, this journal control
field contains the program that performed the operation on the source table. If
you decide to use this journal control field when refreshing data, InfoSphere
CDC sets this journal control field to NULL
v InfoSphere CDC for Microsoft SQL Server (version 5.3)Support for this
journal control field is not available. If you decide to use this journal control
field when mirroring or refreshing data, InfoSphere CDC leaves this journal
control field empty.
v InfoSphere CDC for Microsoft SQL Server (version 6.0)Support for this
journal control field is not available. If you decide to use this journal control
field when mirroring data, InfoSphere CDC sets this journal control field to
UNKNOWN. If you decide to use this journal control field when refreshing
data, InfoSphere CDC leaves this journal control field empty.
v InfoSphere CDC for DB2 UDBSupport for this journal control field is not
available. If you decide to use this journal control field when mirroring or
refreshing data, InfoSphere CDC leaves this journal control field empty.
v InfoSphere CDC for z/OSSupport for this journal control field is available
when InfoSphere CDC mirrors or refreshes data. When mirroring or refreshing
data, this journal control field contains the DB2 plan name to which the user is
connected. A plan describes the SQL that accesses the tables, paths, indices used
and so on.

Journal Sequence Number (&SEQNO)

The sequence number of this update in the journal.

Data TypeInteger (InfoSphere CDC 5.x)

InfoSphere CDC SupportDepending on the InfoSphere CDC product that you

install, journal control fields may or may not be supported when mirroring or
refreshing data. Unsupported journal control fields contain default values that vary
between the InfoSphere CDC products.
v InfoSphere CDC for IBM iSupport for this journal control field is available
only when InfoSphere CDC mirrors data, and is not available when refreshing
data. If you decide to use this journal control field when refreshing data,
InfoSphere CDC sets this journal control field to relative record number on the
target.
v InfoSphere CDC for Oracle Trigger version 6.0 and earlierSupport for this
journal control field is available only when InfoSphere CDC mirrors data, and is
not available when refreshing data. When mirroring data, this journal control
field contains the sequence number. If you decide to use this journal control field
when refreshing data, InfoSphere CDC sets this journal control field to NULL.
v InfoSphere CDC for Microsoft SQL ServerSupport for this journal control
field is not available. If you decide to use this journal control field when
mirroring or refreshing data, InfoSphere CDC sets this journal control field to a
default value of 0.
v InfoSphere CDC for DB2 UDBSupport for this journal control field is not
available. If you decide to use this journal control field when mirroring or
refreshing data, InfoSphere CDC sets this journal control field to a default value
of 0.

Using journal control fields for auditing replication activities 181

 v InfoSphere CDC for z/OSSupport for this journal control field is only
available when InfoSphere CDC mirrors data, and is not available when
refreshing data. When mirroring data, this journal control field contains the RBA
or LRSN integer. DB2 uses RBAs and LRSNs to keep track of log positions. If
you decide to use this journal control field when refreshing data, InfoSphere
CDC sets this journal control field to a default value of 0.

Source Server Name (&SYSTEM)

The host name of the source system.

Data TypeCharacter

InfoSphere CDC SupportDepending on the InfoSphere CDC product that you

install, journal control fields may or may not be supported when mirroring or
refreshing data. Unsupported journal control fields contain default values that vary
between the InfoSphere CDC products.
v InfoSphere CDC for IBM iSupport for this journal control field is available
when InfoSphere CDC mirrors or refreshes data.
v InfoSphere CDC for Oracle Trigger version 6.0 and earlierSupport for this
journal control field is available when InfoSphere CDC mirrors or refreshes data.
When mirroring or refreshing data, this journal control field contains the name
of the source system.
v InfoSphere CDC for Microsoft SQL Server (version 5.x)Support for this
journal control field is not available. If you decide to use this journal control
field when mirroring or refreshing data, InfoSphere CDC leaves this journal
control field empty.
v InfoSphere CDC for Microsoft SQL Server (version 6.x)Support for this
journal control field is not available. If you decide to use this journal control
field when mirroring or refreshing data, InfoSphere CDC leaves this journal
control field empty.
v InfoSphere CDC for DB2 UDBSupport for this journal control field is
available when InfoSphere CDC mirrors or refreshes data
v InfoSphere CDC for z/OSSupport for this journal control field is available
when InfoSphere CDC mirrors or refreshes data. When mirroring or refreshing
data, this journal control field contains the system name on which InfoSphere
CDC is running. The system name is extracted from the root control block (CVT)
of the z/OS operating system.

Record Modification Time (&TIMSTAMP)

The date and time of when the update or refresh was made on the source. In
environments that support microsecond precision, the date and time format of this
journal control field is YYYY-MM-DD-HH:MM:SS.UUUUUU. Otherwise, InfoSphere CDC
sets the microsecond component UUUUUU to zeroes or does not include it at all.

Data TypeTimestamp (InfoSphere CDC 5.x)

InfoSphere CDC SupportDepending on the InfoSphere CDC product that you

install, journal control fields may or may not be supported when mirroring or
refreshing data. Unsupported journal control fields contain default values that vary
between the InfoSphere CDC products.
v InfoSphere CDC for IBM iSupport for this journal control field is available
when InfoSphere CDC mirrors or refreshes data. When mirroring data, this
182 InfoSphere Change Data Capture Management Console: Administration Guide
 journal control field contains the date and time when you write the data to the
source table. When refreshing data, this journal control field contains the current
date and time.
v InfoSphere CDC for Oracle Trigger version 6.0 and earlierSupport for this
journal control field is available when InfoSphere CDC mirrors or refreshes data.
InfoSphere CDC for Oracle supports the following date and time format for this
journal control field: YYYY-MM-DD-HH:MM:SS. When mirroring data, this journal
control field contains the date and time when you write the data to the source
table. When refreshing data, this journal control field contains the current date
and time.
v InfoSphere CDC for Microsoft SQL Server (version 5.3)Support for this
journal control field is available when InfoSphere CDC mirrors or refreshes data.
When mirroring data, this journal control field contains the date and time when
you write the data to the source table. When refreshing data, this journal control
field contains the date and time of when InfoSphere CDC replicated the row in
the source table.
v InfoSphere CDC for Microsoft SQL Server (version 6.0)Support for this
journal control field is available when InfoSphere CDC mirrors or refreshes data.
When mirroring data, this journal control field contains the date and time when
you write the data to the source table. When refreshing data, this journal control
field contains the date and time of when InfoSphere CDC refreshed the first row.
v InfoSphere CDC for DB2 UDBSupport for this journal control field is
available when InfoSphere CDC mirrors or refreshes data. When mirroring data,
this journal control field contains the date and time when you write the data to
the source table. When refreshing data, this journal control field contains the
date and time of when InfoSphere CDC refreshed the first row.
v InfoSphere CDC for z/OSSupport for this journal control field is available
when InfoSphere CDC mirrors or refreshes data. When mirroring data, this
journal control field contains the date and time when you write the data to the
source table. When refreshing data, this journal control field contains the date
and time when the SQL FETCH was issued. Note that the time value format
(local or UTC) is determined by the REPLTIMESTAMP configuration parameter.

Record Modification User (&USER)

The user ID that made the update on the source.

Data TypeCharacter

InfoSphere CDC SupportDepending on the InfoSphere CDC product that you

install, journal control fields may or may not be supported when mirroring or
refreshing data. Unsupported journal control fields contain default values that vary
between the InfoSphere CDC products.
v InfoSphere CDC for IBM iSupport for this journal control field is available
only when InfoSphere CDC mirrors data, and is not available when refreshing
data. If you decide to use this journal control field when refreshing data,
InfoSphere CDC sets this journal control field to UNKNOWN.
v InfoSphere CDC for Oracle Trigger version 6.0 and earlierSupport for this
journal control field is available only when InfoSphere CDC mirrors data, and is
not available when refreshing data. When mirroring data, this journal control
field contains the name of the database user that performed the operation on the
source table. If you decide to use this journal control field when refreshing data,
InfoSphere CDC sets this journal control field to NULL.

Using journal control fields for auditing replication activities 183

 v InfoSphere CDC for Microsoft SQL Server (version 5.3)Support for this
journal control field is only available when InfoSphere CDC mirrors data, and is
not available when refreshing data. When mirroring data, this journal control
field contains the name of the user or if the user that made the change is the
system administrator, it contains the name of the dbo.
v InfoSphere CDC for Microsoft SQL Server (version 6.0)Support for this
journal control field is available only when InfoSphere CDC mirrors data, and is
not available when refreshing data. If you decide to use this journal control field
when refreshing data, InfoSphere CDC sets this journal control field to NOT
SET.
v InfoSphere CDC for DB2 UDBSupport for this journal control field is
available only when InfoSphere CDC mirrors data, and is not available when
refreshing data. When mirroring data, this journal control field contains the
Authorization ID that the job used to connect to DB2.
v InfoSphere CDC for z/OSSupport for this journal control field is available
only when InfoSphere CDC mirrors data, and is not available when refreshing
data. When mirroring data, this journal control field contains the Authorization
ID that the job used to connect to DB2. This is usually the User ID of the job.

About journal codes

The &ENTTYP journal control field generates journal codes that provide you with
the information you need to identify the exact table operations on the source
system that generated the audit record in the table on the target system. By
mapping the &ENTTYP journal control field to the added audit column in the
table on the target system, you can determine the events that generated each audit
record. In the target database, the &ENTTYPjournal control field contains the
two-character journal code that identifies the specific event that happened at the
source table level and which generated the audit record on the target system.

InfoSphere CDC generates multiple journal codes. Journal codes represent events
that take place in your source database. You can customize the journal codes by
building an expression with the %IF column function. For more information, see
Translating journal codes into meaningful information on page 187.

You can customize the journal codes generated by InfoSphere CDC.

See also:
Table Clear
Delete on page 185
Insert on page 186
Update Before on page 186
Update After on page 186

Table Clear
The Table Clear events clear data in a table on the source system. Depending on
the type of Table Clear event that has taken place on the source system, InfoSphere
CDC supports an IBM i journal code.

IBM i journal codes

v CRIndicates that a file, table, or member has been cleared on the source
system.

184 InfoSphere Change Data Capture Management Console: Administration Guide

 v MDIndicates that a file, table, or member has been deleted on the source
system. This uses journal control fields for auditing replication activities.
v RSIndicates that prior to a refresh, a file, table, or member has been cleared on
the source system. In this case, the refresh is a result of an implied table restore.
v AYJournal Change Apply Start, which indicates the starting point for a set of
journal entries applied to a file, table, or member on the source system.
InfoSphere CDC appends this entry to the audit table on the target system.
v AZJournal Change Apply End, which indicates the ending point for a set of
journal entries applied to a file, table, or member on the source system.
InfoSphere CDC appends this entry to the audit table on the target system.
v RCJournal Change Remove Start, which indicates the starting point for a set
of journal entries and reverses previous applies that were made to a file, table,
or member on the source system. InfoSphere CDC appends this entry to the
audit table on the target system.
v RZJournal Change Remove End, which indicates the ending point for a set of
journal entries and reverses previous applies that were made to a file, table, or
member on the source system. InfoSphere CDC appends this entry to the audit
table on the target system. RZ is a journal code generated by InfoSphere CDC. It
is not an IBM i journal code.
v JMIndicates that journaling on the file or table has been started on the source
system.
v EJIndicates that journaling on the file or table ended on the source system.
v RGIndicates that a file, table, or member has been reorganized on the source
system.
v MNBefore Rename, which indicates when the file or member has been
renamed on the source system. InfoSphere CDC appends this entry to the audit
table on the target system.
v NZAfter Rename, which indicates that a new name has been given to a file or
member on the source system. InfoSphere CDC appends this entry to the audit
table on the target system.
v MMBefore Publication File Move, which indicates when the file has been
moved on the source system. InfoSphere CDC appends this entry to the audit
table on the target system.
v MZAfter Publication File Move, which indicates a new location for a file that
has been moved on the source system. InfoSphere CDC appends this entry to
the audit table on the target system. MZ is a journal code generated by
InfoSphere CDC. It is not an IBM i journal code.
v MRIndicates that a file on the source system has been restored.
v CHIndicates that a file on the source system has been changed. When a
non-schema change is applied to the audit table on the source system,
InfoSphere CDC appends this entry to the audit table on the target system.

Delete
The Delete events delete records in a table on the source system. Depending on the
type of Delete event that has taken place on the source system, InfoSphere CDC
supports an IBM i journal code.

IBM i journal codes

v DLIndicates that a record from a table on the source system has been deleted.
v DRIndicates that a record from a table on the source system has been deleted
because of a rollback operation of an inserted record.

Using journal control fields for auditing replication activities 185

 Insert
The Insert events insert rows in a table on the source system. Depending on the
type of Insert event that has taken place on the source system, InfoSphere CDC
supports an IBM i journal code.

IBM i journal codes

v PTIndicates that a record in a table on the source system has been inserted.
v PXIndicates that a record in a table on the source system has been inserted by
re-establishing a deleted record.
v URIndicates that a record in a table on the source system has been inserted
through a rollback of a deleted record.
v RRIndicates that a record in a table on the source system has been refreshed.

Update Before
The Update Before events provide you with the before image of records updated in
a table on the source system. Depending on the type of Update Before event that
has taken place on the source system, InfoSphere CDC generates a journal code.

IBM i journal codes

v UBIndicates the before image of a record updated in a table on the source
system.
v FDIndicates the before image of a record updated in a table on the source
system that satisfies a row selection expression. InfoSphere CDC appends this
entry to the audit table on the target system as a Filtered Record Delete. FD is a
journal code generated by InfoSphere CDC. It is not an IBM i journal code.
v FBIndicates the before image of a record updated in a table on the source
system that does not satisfy a row selection expression. InfoSphere CDC
appends this entry to the audit table on the target system as a Filtered Record
Insert. This record is only placed in the audit table when the corresponding after
image satisfies the row selection expression (FI) and you want to include both
images in the audit table. Otherwise, InfoSphere CDC only includes a single
record (FI) in the audit table. You can audit both images using an InfoSphere
CDC system parameter. For more information, see the appropriate InfoSphere
CDC User Manual for your platform. FB is a journal code generated by
InfoSphere CDC. It is not an IBM i journal code.
v BRIndicates the before image of a record updated for rollback in a table on the
source system.

Update After
The Update After events provide you with the after image of records updated in a
table on the source system. Depending on the type of Update After event that has
taken place on the source system, InfoSphere CDC generates a journal code.

IBM i journal codes

v UPIndicates the after image of a record updated in a table on the source
system.
v FIIndicates the after image of a record updated in a table on the source system
that satisfies a row selection expression. InfoSphere CDC appends this entry to
the audit table on the target system as a Filtered Record Insert. FD is a journal
code generated by InfoSphere CDC. It is not an IBM i journal code.
v FPIndicates the after image of a record updated in a table on the source
system that does not satisfy a row selection expression. InfoSphere CDC

186 InfoSphere Change Data Capture Management Console: Administration Guide

 appends this entry to the audit table on the target system as a Filtered Record
Delete. This record is only placed in the audit table when the corresponding
before image satisfies the row selection expression (FD) and you want to include
both images in the audit table. Otherwise, InfoSphere CDC only includes a
single record (FD) in the audit table. You can audit both images using an
InfoSphere CDC system parameter. For more information, see the appropriate
InfoSphere CDC documentation for your platform. FP is a journal code
generated by InfoSphere CDC. It is not an IBM i journal code.
v URIndicates the after image of a record updated for rollback in a table on the
source system.

Translating journal codes into meaningful information

When you map your tables using LiveAudit, you can map your audit columns to
the &ENTTYP journal control field to let you know what kind of change has been
made on your source table. Because there are many changes that can take place, if
you map a journal control field to a target column, InfoSphere CDC generates a
distinct two-letter journal code on your audit table to help you identify the event
that occurred on the source. For example, if there has been a row inserted in your
source table, then in response to this update, InfoSphere CDC inserts a row into
the target table with the journal code 'PT'.

The journal codes your system generates depend on the database platform that
you are using. You may want to customize journal codes so that they are more
meaningful in your organization. For example, instead of having the journal code
"PT" to indicate that there has been a new row inserted in your source table, you
may want to use a one-letter code such as "I" to identify the insert.

The %IF column function evaluates conditional expressions and returns different
values if the expression is true or false. The example below illustrates how you can
use the %IF column function to convert journal codes into custom letters
%IF(&ENTTYP=PT OR &ENTTYP="RR","I", %IF(&ENTTYP= "UB", "B", %IF(&ENTTYP= "UP",
"A", %IF(&ENTTYP="DL","D","R"))))

This expression does the following:

v If a row has been inserted or refreshed on the source table, then InfoSphere CDC
generates "I" on the audit table.
v If the before image on the source table has been updated, then InfoSphere CDC
generates "B" on the audit table.
v If the after image has been updated on the source table then InfoSphere CDC
generates "A" in the audit table.
v If a row on the source table has been deleted, then InfoSphere CDC generates
"D" on the audit table, otherwise it generates "R" on the audit table.

Using journal control fields for auditing replication activities 187

188 InfoSphere Change Data Capture Management Console: Administration Guide
Controlling table operations
By default, InfoSphere CDC truncates the target table in response to a table-level
clear or refresh operation. You can control this so that InfoSphere CDC preserves
all or some of the rows.

In this section, you will learn:

Controlling the apply of refresh operations
Specifying SQL to control refresh operations on page 191

Controlling the apply of refresh operations

Use the Operations tab to control how InfoSphere CDC applies table-level clear or
refresh operations to a target table. You can do this if you have mapped your
tables using one of Standard, Adaptive Apply, Summarization, or Consolidation.

Also, if you have mapped your tables using LiveAudit, then you can specify that
InfoSphere CDC provide an audit trail each time there is an table-level clear or
refresh operation applied to the target table.

See also:
To keep all rows on a refresh
To delete all rows on a refresh on page 190
To audit rows on a refresh on page 190

To keep all rows on a refresh

1. Click Configuration > Subscriptions.
2. Select the subscription.
Ensure that the subscription contains a table mapping that was mapped using
Standard, Adaptive Apply, Summarization or Consolidation.
3. Select the table mapping in the Table Mappings view.
4. Right-click and select Open Mapping Details.
5. Click the Operation tab.
6. From the On Clear/Truncate list, select Do Not Delete.
7. Click Save.
When you start a refresh on a table mapping, InfoSphere CDC does not delete
the rows in the target table.

Copyright IBM Corp. 2008, 2011 189

 Related concepts
Mapping using standard replication on page 83
Mapping using LiveAudit on page 91
Mapping using Adaptive Apply on page 102
Mapping to summarize data on page 107
Starting a refresh on a subscription on page 330
Controlling the apply of refresh operations on page 189

To delete all rows on a refresh

1. Click Configuration > Subscriptions.
2. Select the subscription.
Ensure that your subscription contains a table mapping that was mapped using
Standard, Adaptive Apply or Summarization.
3. Select the table mapping in the Table Mappings view.
4. Right-click and select Open Mapping Details.
5. Click the Operation tab.
6. Select Delete All from the On Clear/Truncate list.
7. Click Save.
Related concepts
Mapping using standard replication on page 83
Mapping using Adaptive Apply on page 102
Mapping to summarize data on page 107
Starting a refresh on a subscription on page 330

To audit rows on a refresh

1. Click Configuration > Subscriptions.
2. Select the subscription.
Ensure that your subscription contains a table mapping that was mapped using
LiveAudit.
3. Select the table mapping in the Table Mappings view.
4. Right-click and select Open Mapping Details.
5. Click the Operation tab.
6. Select Audit from the On Clear/Truncate list.
7. Click Save.
When you start a refresh on the table mapping, InfoSphere CDC audits the
table-level clear or refresh operations applied to the target table.

190 InfoSphere Change Data Capture Management Console: Administration Guide

 Related concepts
Mapping using standard replication on page 83
Mapping using LiveAudit on page 91
Mapping using Adaptive Apply on page 102
Mapping to summarize data on page 107
Starting a refresh on a subscription on page 330

Specifying SQL to control refresh operations

By default, InfoSphere CDC deletes all rows in the target table in response to a
table-level clear or refresh operation. Use the Operation tab to specify a SQL
WHERE clause that restricts the rows you want InfoSphere CDC to delete in
response to a table clear or refresh operation. InfoSphere CDC only deletes or
truncates the rows for which the condition is true. For example, you may want to
use the WHERE clause to delete rows from the supplier table. The SQL statement
SupplierName= 'IBM' would delete all rows from the supplier table where the
SupplierName is IBM.

You can also specify additional SQL statements that execute after InfoSphere CDC
applies a table refresh or truncate/clear operation to the target table.

For all InfoSphere CDC products (except for InfoSphere CDC for z/OS and
InfoSphere CDC for DB2 LUW), you need to run the DMSQL command to enable
the Additional SQL feature in Management Console. For more information, see
the commands section of the appropriate InfoSphere CDC End-User Documentation
for your InfoSphere CDC product.

If you have installed InfoSphere CDC for z/OS, then you need to set the keyword
ALLOWSQL to YES to enable theAdditional SQL feature in Management Console.
You can add this keyword to the TSDDBMxx Configuration Control data set
member. For more information about this keyword, see Section 4.3 Modifying
DBMS LOAD Configuration Control Statements in the InfoSphere CDC for z/OS
End-User Documentation.

If you have installed InfoSphere CDC for DB2 LUW, then you need to create a
metadata table to enable the Additional SQL feature in Management Console. For
more information, see InfoSphere CDC for DB2 LUW End-User Documentation.

Before issuing SQL statements in Management Console, consider the following:

v If you are referencing a database, table, or column name that contains spaces,
then you must enclose the name in square brackets. For example, to reference
the table name "EMP NY", you must enter it as [EMP NY].
v If your delete WHERE clause references a character column, the specified value
must be enclosed in single quotes. For example, MGR = 'Anna Kim'.
v You cannot reference LOB columns in delete WHERE clauses.
v Specify only SQL INSERT, UPDATE, and DELETE statements.
v SQL statements must be 4,000 bytes or less in length. If you specify SQL
statements that do not fit on one line, do not press the Enter key to break the
statements over more than one line. The text will feed automatically to the next
line.
v No support for logical branching and iteration.
v The database running on the target server must recognize the syntax of the SQL
statements.

Controlling table operations 191

 v Separate multiple SQL statements by semi-colons (;). If a character string in a
SQL statement contains a semi-colon, specify two semi-colons consecutively (;;)
in the string.
v Management Console does not verify SQL statements for syntactical correctness.
The target DBMS verifies statements during replication.

See also:
To specify additional SQL after a refresh
To delete selected rows on a refresh

To specify additional SQL after a refresh

1. Click Configuration > Subscriptions.
2. Select the subscription.
3. Select the table mapping in the Table Mappings view.
4. Right-click and select Open Mapping Details.
5. Click the Operation tab.
6. Select Delete Selected Rows from the On Clear/Truncate list.
7. Click Additional SQL.
8. If you want InfoSphere CDC to execute SQL after a truncate operation, then
type SQL statement in the SQL Immediately After Truncate box.
9. If you want InfoSphere CDC to execute SQL after a refresh operation, then
type SQL in the SQL Immediately After Refresh box.
10. Click OK.
11. Click Save.

Note: If InfoSphere CDC encounters an error during execution of a SQL statement,

it ignores all remaining statements. Also, depending on the system parameters you
have set, InfoSphere CDC either continues or ends data replication in response to
the error.
Related concepts
Specifying SQL to control refresh operations on page 191
Related tasks
To delete selected rows on a refresh

To delete selected rows on a refresh

1. Click Configuration > Subscriptions.
2. Select the subscription.
3. Select the table mapping in the Table Mappings view.
4. Right-click and select Open Mapping Details.
5. Click the Operation tab.
6. Select Delete Selected Rows from the On Clear/Truncate list.
7. Click Editor to specify a SQL WHERE clause for the selected rows.
8. Expand the Target Columns list and select the target columns on which you
want to restrict deletions.
9. Click Verify to make sure the SQL WHERE clause is valid and click OK.
10. Click Save.

192 InfoSphere Change Data Capture Management Console: Administration Guide

Related concepts
Specifying SQL to control refresh operations on page 191
Starting a refresh on a subscription on page 330

Controlling table operations 193

194 InfoSphere Change Data Capture Management Console: Administration Guide
Configuring user exits
A user exit lets you define a subroutine that InfoSphere CDC can invoke when a
predefined event occurs. Two types of user exits are available:
v Table-level user exits run a set of actions before or after a database event occurs
on a specified table.
v Subscription-level user exits run a set of actions before or after a commit event
occurs on a specified subscription.

Subscription-level user exits can work in tandem with table-level user exits, to
keep track of which table-level user exits were invoked during a transaction. The
subscription-level user exit could then use that information to apply actions based
on the tables in the transaction.

In this section, you will learn:

Configuring table-level user exits
Configuring table-level user exits for InfoSphere CDC for Microsoft SQL
Server on page 199
Configuring table-level user exits for InfoSphere CDC for Oracle (version 6.1
and below) or InfoSphere CDC for Sybase (version 6.1 and below) on page 204
Configuring table-level user exits for InfoSphere CDC for IBM i (version 6.2
and below) or InfoSphere CDC for z/OS on page 207
Creating a custom data format for IBM InfoSphere DataStage on page 208
Configuring subscription-level user exits on page 209
Understanding user exit configuration for InfoSphere CDC Event Server on
page 210
Overriding JMS message header properties on page 210
Sending the XML message to a different JMS message destination on page
212
Creating XML output and applying XSLT to an XML message on page 213
Sending XML messages to multiple JMS message destinations on page 215
Querying a Web service to access content on page 217
Content based routing on page 218

Configuring table-level user exits

A table-level user exit lets you define a set of actions that InfoSphere CDC can run
before or after a database event occurs on a specified table. When using InfoSphere
CDC, a database event is defined as either a row-level operation or as a table-level
operation. Row-level operations include an insert, update, or a delete. Table-level
operations include a refresh or a truncate operation. For example, you can
configure a row-level user exit program that sends an alert after InfoSphere CDC
replicates a delete operation on a particular target table.

User exits can be grouped as either a Before User Exit or an After User Exit:
v Before User Exitruns before InfoSphere CDC replicates any row-level or
table-level operations to the target table.

Copyright IBM Corp. 2008, 2011 195

 v After User Exitruns after InfoSphere CDC replicates any row-level or
table-level operations to the target table.

The following list identifies common scenarios for developing a user exit program
before or after row or table-level operations:
v Customize when InfoSphere CDC replicates a row-level operation to the target
table. For example, you can develop logic for insert, update, or delete operations
so that these occur based on some specified criteria, such as the original invoice
date. InfoSphere CDC can run the user exit and apply the row-level operation
(insert, update, or delete) to the appropriate target table based on the original
invoice date, such as, January 2004, February 2004, November 2006, and so on.
v Disable the default row-level or table-level operations, and replace them by
invoking a user exit program that performs custom operations. For example, in
response to a table-level truncate operation, you can develop a user exit that lets
you do a soft delete rather than a hard delete on the target table.

See also:
To configure a stored procedure
To configure a derived column or an expression that calls %STPROC, %USER,
or %USERFUNC on page 197
To configure a user exit for a Java class on page 198

To configure a stored procedure

1. Verify your version of InfoSphere CDC.
This information is applicable to the following versions of InfoSphere CDC:
v InfoSphere CDC for Microsoft SQL Server (version 6.0 and higher)
v InfoSphere CDC for DB2 UDB (version 6.1 and higher)
v InfoSphere CDC for Oracle (version 6.3)
v InfoSphere CDC for Oracle - Trigger (version 6.3)
v InfoSphere CDC for Sybase (version 6.3)
2. Click Configuration > Subscriptions.
3. Select the subscription.
4. Select the table mapping in the Table Mappings view.
5. Right-click and select Open Mapping Details.
6. Click the User Exits tab.
7. Select Stored Procedure from the User Exit Type list.
Use the Stored Procedure - Deprecated option to maintain user exits that
were created using InfoSphere CDC for Microsoft SQL Server (version 5.3).
Use the Stored Procedure option for all new user exits.
8. Type the name of the schema that contains the stored procedure in the
Schema box.
9. Type the name of the user exit programs you want InfoSphere CDC to call
beside one or more of the following operations:

Option Description
Before Insert InfoSphere CDC runs the user exit before
replicating an insert operation.
After Insert InfoSphere CDC runs the user exit after
replicating an insert operation.

196 InfoSphere Change Data Capture Management Console: Administration Guide

 Option Description
Before Update InfoSphere CDC runs the user exit before
replicating an update operation.
After Update InfoSphere CDC runs the user exit after
replicating an update operation.
Before Delete InfoSphere CDC runs the user exit before
replicating a delete operation.
After Delete InfoSphere CDC runs the user exit after
replicating a delete operation.
Before Refresh InfoSphere CDC runs the user exit before
replicating a refresh operation.
After Refresh InfoSphere CDC runs the user exit after
replicating a refresh operation.
Before Truncate InfoSphere CDC runs the user exit before
replicating a truncate operation.
After Truncate InfoSphere CDC runs the exist after
replicating a truncate operation.

10. Click Save.

Related concepts
Configuring table-level user exits for InfoSphere CDC for Microsoft SQL Server
on page 199
Related tasks
To configure a stored procedure on page 202

To configure a derived column or an expression that calls

%STPROC, %USER, or %USERFUNC
1. Click the Column Mappings tab, and do one of the following:
v If you want InfoSphere CDC to evaluate an expression on the source table,
then add a derived column.
v If you want InfoSphere CDC to evaluate an expression on the target table,
then build an expression.
Make sure the expression you define contains a valid call to the %STPROC,
%USER or %USERFUNC column function. If you are calling a stored procedure
that is not owned by the InfoSphere CDC user, you must provide the name in
the form <schema>.<stored procedure name>.
2. Map the derived column or the expression to the target column.

Configuring user exits 197

 Related concepts
Configuring table-level user exits for InfoSphere CDC for Microsoft SQL Server
on page 199
Related tasks
To configure a stored procedure on page 202
To configure a stored procedure on page 196
To add a derived column on page 155
To map a derived column to a target column on page 156
To map an expression to a target column on page 151

To configure a user exit for a Java class

Note: For Java class user exits, method names are pre-defined. This means that
you can only enable and disable user exit programs. You need to configure a user
exit in java that implements the UserExitIF interface class. For more information
about this class, see the InfoSphere CDC End-User Documentation for each platform.
1. Click Configuration > Subscriptions.
2. Select the subscription.
3. Click the Table Mappings view and select the table mapping from the Source
Table column.
4. Right-click and select Open Mapping Details.
5. Click the User Exits tab.
6. Select Java Class from the User Exit Type list.
7. Type the name of the Java class user exit that implements the UserExitIF
interface in the Class Name box.
For example, you may have imported the UserExitIF interface, and the user
exit program class that implements this interface in your function has the
following definition: public class UE1 implements UserExitIF
In the Class Name box, you need to type:

Option Description
UE1 If it is a stand-alone class
<Java package>.UE1 If the class is included in a Java package (for
example, com.ibm.interface.UE1)

The files you generate from compiling the user exit program must be located
in a library or folder that is referenced by the CLASSPATH environment
variable.
8. Type the parameters that you want to make available to the user exit program
in the Parameter box.
You can access the parameters in the user exit program class by invoking the
getParameter( ) method during the initialization process. There are no
conventions for specifying the parameters. The values you type in this box are
free-form. The string of parameter values cannot exceed 255 characters in
length.
9. Type the name of the user exit programs you want InfoSphere CDC to call
beside one or more of the following operations:

198 InfoSphere Change Data Capture Management Console: Administration Guide

 Option Description
Before Insert InfoSphere CDC runs the user exit before
replicating an insert operation.
After Insert InfoSphere CDC runs the user exit after
replicating an insert operation.
Before Update InfoSphere CDC runs the user exit before
replicating an update operation.
After Update InfoSphere CDC runs the user exit after
replicating an update operation.
Before Delete InfoSphere CDC runs the user exit before
replicating a delete operation.
After Delete InfoSphere CDC runs the user exit after
replicating a delete operation.
Before Refresh InfoSphere CDC runs the user exit before
replicating a refresh operation.
After Refresh InfoSphere CDC runs the user exit after
replicating a refresh operation.
Before Truncate InfoSphere CDC runs the user exit before
replicating a truncate operation.
After Truncate InfoSphere CDC runs the exist after
replicating a truncate operation.

10. Click Save.

Related concepts
Configuring table-level user exits for InfoSphere CDC for Microsoft SQL Server

Configuring table-level user exits for InfoSphere CDC for Microsoft

SQL Server
You can configure the following types of table-level user exits with InfoSphere
CDC for Microsoft SQL Server:

IDispatch COM DLL (InfoSphere CDC for Microsoft SQL Server)You can
invoke at runtime a function you defined using IDispatch. When configuring an
IDispatch COM DLL user exit,Management Console lets you enable or disable user
exits developed for IDispatch. Before you can use Management Console to
configure a user exit, you need to do the following in Microsoft SQL Server:
v Create the user-defined function.
v Create the user exit.
v Extract or build the DLL file and place it in a location. For example, C:\Program
Files\Microsoft SQL Server\MSSQL\Bin (or wherever appropriate).
v If you are using Visual Basic, you must reference the library dts_usrext.tlb
after starting Visual Basic. InfoSphere CDC provides a predefined interface
(IDTS_UserExit) so that InfoSphere CDC can interact with the server object you
define. The interface contains four predefined user exit program stubs that you
should not modify. As a result, you can only select (not name) the functions that
you want to call at the various processing points. For more information, see
your user exits documentation for InfoSphere CDC for Microsoft SQL Server.

C or C++ (InfoSphere CDC for Microsoft SQL Server)You can specify a DLL
library that contains the compiled user exit program.

Configuring user exits 199

 Stored Procedure (Transformation Server for Microsoft SQL Server (version 5.3)-
deprecated)You can configure a user exit as a stored procedure for
Transformation Server for Microsoft SQL Server Version 5.3. Depending on how
you have configured the stored procedure, you need to identify temporary or
permanent tables so that Transformation Server can populate these tables with the
images of the row-level operations applied to the target table. Your stored
procedure user exit can then retrieve the image of the row from these tables and
use them as required.

Java ClassFor Java class user exits, method names are pre-defined. This means
that you can only enable and disable user exit programs. You need to configure a
user exit in java that implements the UserExitIF interface class. For more
information about this class, see the InfoSphere CDC End-User Documentation for
each of these platforms.

See also:
To configure for IDispatch COM DLL
To configure for C or C++ on page 201
To configure a stored procedure on page 202
Related concepts
Configuring table-level user exits for InfoSphere CDC for Microsoft SQL Server
on page 199

To configure for IDispatch COM DLL

Note: This function is deprecated and is available only for backward compatibility
to Transformation Server for Microsoft SQL Server version 5.3. It is applicable to
InfoSphere CDC for Microsoft SQL Server (version 6.2 and higher)
1. Click Configuration > Subscriptions.
2. Select the subscription.
3. Select the table mapping in the Table Mappings view.
4. Right-click and select Open Mapping Details.
5. Click the User Exits tab.
6. Select IDispatch COM DLL from the User Exit Type list box.
7. Type the name of the class module and project that contains the user exit
program that you want run in the DLL Name box.
8. If you want InfoSphere CDC to retrieve the current constant value from the
target and pass it to a user exit program that runs before or after InfoSphere
CDC replicates an update operation to the target table, then enable Update
All Columns.
9. Type the name of the user exit programs you want InfoSphere CDC to call
beside one or more of the following operations:

Option Description
Before Insert InfoSphere CDC runs the user exit before
replicating an insert operation.
After Insert InfoSphere CDC runs the user exit after
replicating an insert operation.
Before Update InfoSphere CDC runs the user exit before
replicating an update operation.

200 InfoSphere Change Data Capture Management Console: Administration Guide

 Option Description
After Update InfoSphere CDC runs the user exit after
replicating an update operation.
Before Delete InfoSphere CDC runs the user exit before
replicating a delete operation.
After Delete InfoSphere CDC runs the user exit after
replicating a delete operation.
Before Refresh InfoSphere CDC runs the user exit before
replicating a refresh operation.
After Refresh InfoSphere CDC runs the user exit after
replicating a refresh operation.
Before Truncate InfoSphere CDC runs the user exit before
replicating a truncate operation.
After Truncate InfoSphere CDC runs the exist after
replicating a truncate operation.

10. Click Save.

In some environments, the target table may contain one or more columns that
store user-defined constants. Other applications usually maintain these
constant values, and they are not affected by InfoSphere CDC. If you do not
enable Update All Columns, then InfoSphere CDC passes the default column
value (for example, zero, blank, or NULL) to the user exit program. Due to
performance reasons, it is important that you clear this box if you do not need
to pass the user-defined constant values.
Related concepts
Configuring table-level user exits for InfoSphere CDC for Microsoft SQL Server
on page 199

To configure for C or C++

Note: This function is deprecated and is available only for backward compatibility
to Transformation Server for Microsoft SQL Server version 5.3. It is applicable to
InfoSphere CDC for Microsoft SQL Server (version 6.2 and higher)
1. Click Configuration > Subscriptions.
2. Select the subscription.
3. Click the Table Mappings view and select the table mapping from the Source
Table column.
4. Right-click and select Open Mapping Details.
5. Click the User Exits tab.
6. Select C/C++ DLL from the User Exit Type list.
7. Type the full path name of a DLL library that contains the compiled user exit
program in the DLL Name box.
8. If you want InfoSphere CDC to retrieve the current constant value from the
target and pass it to a user exit program that runs before or after InfoSphere
CDC replicates an update operation to the target table, then enable Update
All Column.
9. Type the name of the user exit programs you want to call in the Function
Name list.
10. Type the name of the user exit programs you want InfoSphere CDC to call
beside one or more of the following operations:

Configuring user exits 201

 Option Description
Before Insert InfoSphere CDC runs the user exit before
replicating an insert operation.
After Insert InfoSphere CDC runs the user exit after
replicating an insert operation.
Before Update InfoSphere CDC runs the user exit before
replicating an update operation.
After Update InfoSphere CDC runs the user exit after
replicating an update operation.
Before Delete InfoSphere CDC runs the user exit before
replicating a delete operation.
After Delete InfoSphere CDC runs the user exit after
replicating a delete operation.
Before Refresh InfoSphere CDC runs the user exit before
replicating a refresh operation.
After Refresh InfoSphere CDC runs the user exit after
replicating a refresh operation.
Before Truncate InfoSphere CDC runs the user exit before
replicating a truncate operation.
After Truncate InfoSphere CDC runs the exist after
replicating a truncate operation.

11. Click Save.

In some environments, the target table may contain one or more columns that
store user-defined constants. Other applications usually maintain these
constant values, and they are not affected by InfoSphere CDC. If you do not
enable Update All Columns, then InfoSphere CDC passes the default column
value (for example, zero, blank, or NULL) to the user exit program. Due to
performance reasons, it is important that you clear this box if you do not need
to pass the user-defined constant values.
Related concepts
Configuring table-level user exits for InfoSphere CDC for Microsoft SQL Server
on page 199

To configure a stored procedure

Note: This function is deprecated and is available only for backward compatibility
to Transformation Server for Microsoft SQL Server version 5.3. It is applicable to
InfoSphere CDC for Microsoft SQL Server (version 6.2 and higher)
1. Click Configuration > Subscriptions.
2. Select the subscription.
3. Click the Table Mappings view and select the table mapping from the Source
Table column.
4. Right-click and select Open Mapping Details.
5. Click the User Exits tab.
6. Select Stored Procedure from the User Exit Type list.
7. Type the database owner of the stored procedure, in the Database Owner box.
8. If you have a stored procedure that runs after InfoSphere CDC replicates an
update operation to the target table, then provide the name of the temporary
or permanent table in the Update Table Image box.

202 InfoSphere Change Data Capture Management Console: Administration Guide

 During replication, InfoSphere CDC populates this table with the after image
of the update operation that was applied to the target. Your stored procedure
user exit then retrieves the after image of the row from this table.
9. If you have a stored procedure that requires access to a specific row, then
provide the name of the temporary or permanent table in the Key Table
Image box.
Depending on the kind of row-level operation applied to the target table,
InfoSphere CDC populates this table with either the after or before images of
the key column data. Your stored procedure user exit then retrieves the after
or before image of the key column data from this table.
10. If you have a stored procedure that requires access to journal information for
each updated row, then provide the name of the temporary or permanent
table in the Journal Table Image box.
InfoSphere CDC populates this table with the journal header information.
Journal header information includes journal control fields and journal codes
that indicate what kind of update was made on the row. For more information
about journal control fields, see Using journal control fields for auditing
replication activities on page 173.
11. If you have configured a stored procedure that runs before a row-level
operation is replicated to the target table, then provide the name of the
temporary or permanent table in the Before Table Image box.
During replication, InfoSphere CDC populates this table with the before
image of the rows in the source table. Your stored procedure user exit then
retrieves the before image of the row from this table.

Notes:
v InfoSphere CDC supports fully qualified image table names to a maximum
of 100 characters in length, but database naming restrictions still apply. Note
that InfoSphere CDC does not verify whether an image table name
conforms to a database naming convention. If you are referencing a
database or table that contains spaces, then you must enclose the name in
square brackets. For example, to reference the table name "EMP NY", you
must enter it as [EMP NY].
v The image tables and the target tables should reside in different databases
to prevent any possibility of locking the database.
12. If you want to create permanent tables using Management Console, then click
Create Tables.
13. If you want to retrieve the current constant value (also known as the before or
after image of the source row) and pass it to a user exit program that runs
before or after a row-level operation is replicated to the target table, then
check the Update All Columns box.
14. Type the name of the user exit programs you want InfoSphere CDC to call
beside one or more of the following operations:

Option Description
Before Insert InfoSphere CDC runs the user exit before
replicating an insert operation.
After Insert InfoSphere CDC runs the user exit after
replicating an insert operation.
Before Update InfoSphere CDC runs the user exit before
replicating an update operation.

Configuring user exits 203

 Option Description
After Update InfoSphere CDC runs the user exit after
replicating an update operation.
Before Delete InfoSphere CDC runs the user exit before
replicating a delete operation.
After Delete InfoSphere CDC runs the user exit after
replicating a delete operation.
Before Refresh InfoSphere CDC runs the user exit before
replicating a refresh operation.
After Refresh InfoSphere CDC runs the user exit after
replicating a refresh operation.
Before Truncate InfoSphere CDC runs the user exit before
replicating a truncate operation.
After Truncate InfoSphere CDC runs the exist after
replicating a truncate operation.

15. Click Save.

In some environments, the target table may contain one or more columns that
store user-defined constants. Other applications usually maintain these
constant values, and they are not affected by InfoSphere CDC. If you do not
enable Update All Columns, then InfoSphere CDC passes the default column
value (for example, zero, blank, or NULL) to the user exit program. Due to
performance reasons, it is important that you clear this box if you do not need
to pass the user-defined constant values.
Related concepts
Configuring table-level user exits for InfoSphere CDC for Microsoft SQL Server
on page 199
Related tasks
To configure a stored procedure on page 196

Configuring table-level user exits for InfoSphere CDC for Oracle

(version 6.1 and below) or InfoSphere CDC for Sybase (version 6.1 and
below)
C Shared LibraryYou can configure a C user exit program for InfoSphere CDC.
You can configure the InfoSphere CDC to run the user exit program before or after
an insert, update, delete, or truncate operation.

Stored ProcedureYou can configure a stored procedure user exit for InfoSphere
CDC. You need to identify the schema that contains the stored procedure and
identify the InfoSphere CDC operations on which you want to run the user exit.
InfoSphere CDC can call your stored procedure from either the source or target
when you use the %STPROC column function in an expression. If you want
InfoSphere CDC to evaluate and call your stored procedure on the source, then
you need to add a derived column. If you want InfoSphere CDC to evaluate and
call your stored procedure on the target, then you need to build an expression.

See also:
To configure a C shared library on page 205
To configure a stored procedure (Oracle and Sybase) on page 206

204 InfoSphere Change Data Capture Management Console: Administration Guide

 To configure a derived column or an expression that calls %STPROC (Oracle
and Sybase) on page 207

To configure a C shared library

1. Click Configuration > Subscriptions.
2. Ensure that you are connected to an InfoSphere CDC for Oracle or an
InfoSphere CDC for Sybase datastore.
3. Select the subscription.
4. Select the table mapping in the Table Mappings view.
5. Right-click and select Open Mapping Details.
6. Click the User Exits tab.
7. Select C Shared Library from the User Exit Type list.
8. Type the full path name of the file containing the shared library in the File
(path) box.
9. If you want InfoSphere CDC to retrieve the current constant value from the
target and pass it to a user exit program that runs before or after InfoSphere
CDC replicates an update operation to the target table, then check the
Retrieve Current Values box.
10. Type the name of the user exit programs you want InfoSphere CDC to call
beside one or more of the following operations:

Option Description
Before Insert InfoSphere CDC runs the user exit before
replicating an insert operation.
After Insert InfoSphere CDC runs the user exit after
replicating an insert operation.
Before Update InfoSphere CDC runs the user exit before
replicating an update operation.
After Update InfoSphere CDC runs the user exit after
replicating an update operation.
Before Delete InfoSphere CDC runs the user exit before
replicating a delete operation.
After Delete InfoSphere CDC runs the user exit after
replicating a delete operation.
Before Refresh InfoSphere CDC runs the user exit before
replicating a refresh operation.
After Refresh InfoSphere CDC runs the user exit after
replicating a refresh operation.
Before Truncate InfoSphere CDC runs the user exit before
replicating a truncate operation.
After Truncate InfoSphere CDC runs the exist after
replicating a truncate operation.

11. Specify the parameters that you want InfoSphere CDC to pass to the user exit
program.
12. Click Save.
In some environments, the target table may contain one or more columns that
store user-defined constants. Other applications usually maintain these
constant values, and they are not affected by InfoSphere CDC. If you do not
enable Retrieve Current Value, then InfoSphere CDC passes the default

Configuring user exits 205

 column value (for example, zero, blank, or NULL) to the user exit program.
Due to performance reasons, it is important that you clear this box if you do
not need to pass the user-defined constant values.
Related concepts
Configuring table-level user exits for InfoSphere CDC for Oracle (version 6.1 and
below) or InfoSphere CDC for Sybase (version 6.1 and below) on page 204

To configure a stored procedure (Oracle and Sybase)

1. Ensure that you are connected to an InfoSphere CDC for Oracle or an
InfoSphere CDC for Sybase datastore.
2. Click Configuration > Subscriptions.
3. Select the subscription.
4. Click the Table Mappings view and select the table mapping from the Source
Table column.
5. Right-click and select Open Mapping Details.
6. Click the User Exits tab.
7. Select Stored Procedure from the User Exit Type list.
8. Type the name of the schema that contains the stored procedure in the
Schema box.
9. If you want InfoSphere CDC to retrieve the current constant value from the
target and pass it to a user exit program that runs before or after InfoSphere
CDC replicates an update operation to the target table, then check the
Retrieve Current Values box.
10. Type the name of the user exit programs you want InfoSphere CDC to call
beside one or more of the following operations:

Option Description
Before Insert InfoSphere CDC runs the user exit before
replicating an insert operation.
After Insert InfoSphere CDC runs the user exit after
replicating an insert operation.
Before Update InfoSphere CDC runs the user exit before
replicating an update operation.
After Update InfoSphere CDC runs the user exit after
replicating an update operation.
Before Delete InfoSphere CDC runs the user exit before
replicating a delete operation.
After Delete InfoSphere CDC runs the user exit after
replicating a delete operation.
Before Refresh InfoSphere CDC runs the user exit before
replicating a refresh operation.
After Refresh InfoSphere CDC runs the user exit after
replicating a refresh operation.
Before Truncate InfoSphere CDC runs the user exit before
replicating a truncate operation.
After Truncate InfoSphere CDC runs the exist after
replicating a truncate operation.

11. Click Save.

206 InfoSphere Change Data Capture Management Console: Administration Guide

 In some environments, the target table may contain one or more columns that
store user-defined constants. Other applications usually maintain these
constant values, and they are not affected by InfoSphere CDC. If you do not
enable Retrieve Current Value, then InfoSphere CDC passes the default
column value (for example, zero, blank, or NULL) to the user exit program.
Due to performance reasons, it is important that you clear this box if you do
not need to pass the user-defined constant values.
Related concepts
Configuring table-level user exits for InfoSphere CDC for Oracle (version 6.1 and
below) or InfoSphere CDC for Sybase (version 6.1 and below) on page 204

To configure a derived column or an expression that calls

%STPROC (Oracle and Sybase)
1. Ensure that you are connected to an InfoSphere CDC for Oracle or an
InfoSphere CDC for Sybase datastore.
2. Click the User Exits tab, and configure a stored procedure.
3. Click the Column Mappings tab, and do one of the following:
v If you want InfoSphere CDC to evaluate an expression on the source table,
then add a derived column.
v If you want InfoSphere CDC to evaluate an expression on the target table,
then build an expression.
Make sure the expression you define contains a valid call to the %STPROC
column function. If you are calling a stored procedure that is not owned by the
InfoSphere CDC user, you must provide the name in the form <schema>.<stored
procedure name>.
4. Map the derived column or the expression to the target column.
Related tasks
To configure a stored procedure (Oracle and Sybase) on page 206
To add a derived column on page 155
To map a derived column to a target column on page 156
To map an expression to a target column on page 151

Configuring table-level user exits for InfoSphere CDC for IBM i

(version 6.2 and below) or InfoSphere CDC for z/OS
You can write standard function user exits in RPG, COBOL, and C/C++.

See also:
To configure a standard function

To configure a standard function

1. Ensure that you are connected to an InfoSphere CDC for IBM i or an
InfoSphere CDC for z/OS datastore.
2. Click Configuration > Subscriptions.
3. Select the subscription.
4. Click the Table Mappings view and select the table mapping from the Source
Table column.
5. Right-click and select Open Mapping Details.
6. Click the User Exits tab.

Configuring user exits 207

 7. Select Standard Function from the User Exit Type list.
8. Type the name of the user exit programs you want InfoSphere CDC to call
beside one or more of the following operations:

Option Description
Before Insert InfoSphere CDC runs the user exit before
replicating an insert operation.
After Insert InfoSphere CDC runs the user exit after
replicating an insert operation.
Before Update InfoSphere CDC runs the user exit before
replicating an update operation.
After Update InfoSphere CDC runs the user exit after
replicating an update operation.
Before Delete InfoSphere CDC runs the user exit before
replicating a delete operation.
After Delete InfoSphere CDC runs the user exit after
replicating a delete operation.
Before Refresh InfoSphere CDC runs the user exit before
replicating a refresh operation.
After Refresh InfoSphere CDC runs the user exit after
replicating a refresh operation.
Before Truncate InfoSphere CDC runs the user exit before
replicating a truncate operation.
After Truncate InfoSphere CDC runs the exist after
replicating a truncate operation.

9. Click Save.
Related concepts
Configuring table-level user exits for InfoSphere CDC for IBM i (version 6.2 and
below) or InfoSphere CDC for z/OS on page 207

Creating a custom data format for IBM InfoSphere DataStage

You can customize the data that is being generated by InfoSphere CDC and sent to
InfoSphere DataStage by specifying a Java class. This is ideal for users who have
existing InfoSphere DataStage jobs that expect a particular data format. If you use
a custom data format that changes the default format of the flat file sent from
InfoSphere CDC to InfoSphere DataStage, the .dsx file described in Using
Management Console to generate a definition file on page 100 won't be useful
because it contains only default data formatting. If you have created and imported
a .dsx file into InfoSphere DataStage, you must ensure that it is still relevant in
InfoSphere DataStage Designer.

For example, you may have an existing InfoSphere DataStage file-based job that
will not read the default data format generated by Management Console. In this
case, it may be easier for you to specify a Java class to customize the data format
rather than modifying your existing InfoSphere DataStage job.

A Java class that creates a custom data format must implement the
DataStageDataFormatIF interface.

For more information on the DataStageDataFormatIF interface, see the Javadocs

that are installed with your InfoSphere CDC for InfoSphere DataStage installation.

208 InfoSphere Change Data Capture Management Console: Administration Guide

 For more information on these requirements, refer to the InfoSphere DataStage
product technical documentation.

See also:
To create a custom data format for InfoSphere DataStage

To create a custom data format for InfoSphere DataStage

1. Click Configuration > Subscriptions.
2. Select the subscription.
3. Click the Table Mappings view and select the table mapping from the Source
Table column.
4. Right-click and select Open Mapping Details.
5. Click the Flat File or Direct Connect tab depending on your mapping type.
6. Type the name of the Java class that implements the DataStageDataFormatIF
interface in the Class Name box.
For example, you may have imported the DataStageDataFormatIF interface,
and the class that implements this interface in your function has the following
definition:
public class CustomFormat1 implements DataStageDataFormatIF
In the Class Name box in the Custom Data Format area, you must type:
v CustomFormat1Identifies a stand-alone class.
v <Java package>.CustomFormat1Identifies that class is included in a Java
package (for example, com.ibm.interface.CustomFormat1 ).
The files you generate from compiling the class must be located in a library or
folder that is referenced by the CLASSPATH environment variable.
7. Click Save.

Configuring subscription-level user exits

A subscription-level user exit lets you define a set of actions that InfoSphere CDC
can run before or after a commit event occurs on a specified subscription.

Subscription-level user exits can work alone or in tandem with table-level user
exits, to keep track of which table-level user exits were called during a transaction.
The subscription-level user exit could then use that information to apply actions
based on the tables in the transaction.

See also:
To configure a user exit for a subscription

To configure a user exit for a subscription

1. Click Configuration > Subscriptions.
2. Select the subscription.
3. Right-click and select User Exits.
4. Select Java Class from the User Exit Type list.
5. Type the name of the Java class user exit that implements the
SubscriptionUserExitIF interface in the Class Name box.
For example, you may have imported the SubscriptionUserExitIF interface, and
the user exit program class that implements this interface in your function has
the following definition:

Configuring user exits 209

 public class UE1 implements SubscriptionUserExitIF

In the Class Name box, you must type:

v UE1Indicates a stand-alone class.
v <Java package>.UE1Indicates that the class is included in a Java package
(for example, com.datamirror.interface.UE1).
The files you generate from compiling the user exit program must be located in
a library or folder that is referenced by the CLASSPATH environment variable.
6. Type the parameters that you want to make available to the user exit program
in the Parameter box.
You can access the parameters in the user exit program class by invoking the
getParameter( ) method during the initialization process. There are no
conventions for specifying the parameters. The values you type in this box are
free-form. The string of parameter values cannot exceed 255 characters in
length.

Understanding user exit configuration for InfoSphere CDC Event

Server
You can configure a user exit to define a set of actions that InfoSphere CDC Event
Server can run either before or after applying a row-level operation to a staged
target table or to a JMS message destination. Row-level operations include an
insert, update, or a delete. You can develop the user exit using Java.

You can run user exits either before or after the following conditions:
v Row level operations are applied to a table in a staging database
v Row level operations are applied to a JMS message destination
v Row level operations are applied to a table in a staging database and a JMS
message destination

In this section, you will learn:

Overriding JMS message header properties

You can override the default JMS message header properties you had set for a
source table to XML mapping in the XML Settings tab. Depending on the JMS
message property you want to override, InfoSphere CDC Event Server lets you
specify parameters for the following methods in the EventServerIF interface:
v setJmsCorrelationID()
v setJmsCustomProperty()
v setJmsDeliveryMode()
v setJmsPriority()
v setJmsReplyTo()
v setJmsTimeToLive()
v setJmsType()

For an example of a user exit that overrides the JMS properties of an existing
source table to XML mapping, see SampleUserExit1.java located in the samples
folder or directory of your InfoSphere CDC Event Server installation.

See also:

210 InfoSphere Change Data Capture Management Console: Administration Guide

 To override JMS message header properties

To override JMS message header properties

1. Click Configuration > Datastores.
Ensure that you are connected to an Event Server datastore.
2. Click Configuration > Subscriptions.
Ensure that you have created a subscription that uses the Event Server
datastore as the target.
3. Ensure that you have created at least one source table to XML message
destination mapping within this subscription.
4. Select the table mapping and right-click Open Mapping Details.
5. Click the User Exits tab.
6. Choose Java Class from the User Exit Type box.
7. In the Class Name box, type the Java class name of the user exit that
implements the UserExitIF interface if you have developed the user exit in Java.
8. Type the parameters that you want to make available to the user exit program
in the Parameter box.
You can access the parameters in the Java class by invoking the getParameter()
method during the initialization process. There are no conventions for
specifying the parameters. The values you type in this box are free-form. The
string of parameter values cannot exceed 255 characters in length.
9. Enable the Before or After check box for one or more of the following
operations:

Option Description
Insert InfoSphere CDC Event Server runs the user
exit before or after applying an insert
operation to a table you have staged, before
or after applying an insert operation to a
JMS message destination, or both.
Update InfoSphere CDC Event Server runs the user
exit before or after applying an update
operation to a table you have staged, before
or after applying an update operation to a
JMS message destination, or both.
Delete InfoSphere CDC Event Server runs the user
exit before or after applying a delete
operation to a table you have staged, before
or after applying a delete operation to a JMS
message destination, or both.
Refresh InfoSphere CDC Event Server runs the user
exit before or after applying a refresh
operation to a table you have staged, before
or after applying a refresh operation to a
JMS message destination, or both.
Truncate InfoSphere CDC Event Server runs the user
exit before or after applying a truncate
operation to a table you have staged, before
or after applying a truncate operation to a
JMS message destination, or both.

Configuring user exits 211

 Related concepts
Sending XML messages to multiple JMS message destinations on page 215
Defining the JMS message header on page 313
Overriding JMS message header properties on page 210
Understanding user exit configuration for InfoSphere CDC Event Server on page
210

Sending the XML message to a different JMS message destination

You can develop a user exit that lets you send an XML message to a different JMS
message destination than the one you added using the InfoSphere CDC
Configuration tool. Using the setDestination() method in a user exit with the
EventServerIF interface, you can send an XML message to a different JMS message
destination.

For an example of a user exit that sends an XML message to a different JMS
message destination, see SampleUserExit2.java located in the samples folder or
directory of your InfoSphere CDC Event Server installation.

See also:
To send the XML message to another JMS message destination

To send the XML message to another JMS message

destination
1. Click Configuration > Datastores.
Ensure that you are connected to an Event Server datastore.
2. Click Configuration > Subscriptions.
Ensure that you have created a subscription that uses the Event Server
datastore as the target.
3. Ensure that you have created at least one source table to XML message
destination mapping within this subscription.
4. Select the table mapping and right-click Open Mapping Details.
5. Click the User Exits tab.
6. Choose Java Class from the User Exit Type box.
7. In the Class Name box, type the Java class name of the user exit that
implements the UserExitIF interface if you have developed the user exit in
Java.
8. Type the parameters that you want to make available to the user exit program
in the Parameter box.
You can access the parameters in the Java class by invoking the getParameter()
method during the initialization process. There are no conventions for
specifying the parameters. The values you type in this box are free-form. The
string of parameter values cannot exceed 255 characters in length.
9. Enable the Before or After check box for one or more of the following
operations:

212 InfoSphere Change Data Capture Management Console: Administration Guide

 Option Description
Insert InfoSphere CDC Event Server runs the user
exit before or after applying an insert
operation to a table you have staged, before
or after applying an insert operation to a
JMS message destination, or both.
Update InfoSphere CDC Event Server runs the user
exit before or after applying an update
operation to a table you have staged, before
or after applying an update operation to a
JMS message destination, or both.
Delete InfoSphere CDC Event Server runs the user
exit before or after applying a delete
operation to a table you have staged, before
or after applying a delete operation to a JMS
message destination, or both.
Refresh InfoSphere CDC Event Server runs the user
exit before or after applying a refresh
operation to a table you have staged, before
or after applying a refresh operation to a
JMS message destination, or both.
Truncate InfoSphere CDC Event Server runs the user
exit before or after applying a truncate
operation to a table you have staged, before
or after applying a truncate operation to a
JMS message destination, or both.

10. Click Save.

You can start mirroring on the subscription that contains the source table
assigned to a JMS message destination. The user exit program will set the new
destination before InfoSphere CDC Event Server applies the operation to a
JMS message destination.
Related concepts
Sending XML messages to a JMS message destination on page 334
Sending the XML message to a different JMS message destination on page 212

Creating XML output and applying XSLT to an XML message

You can develop a user exit which lets you create an XML message and then
format the XML message using XSL Transformations (XSLT). InfoSphere CDC
Event Server lets you specify parameters for the following methods in the
EventServerIF interface:
v createXmlOutput()
v apply Xslt()

For example, the following user exit applies XSLT on an existing XML message:
}
/**
* Apply XSLT transform to the output message
* @throws UserExitException
*/
private void applyXslt(EventServerIF eventServer, ReplicationEventIF p_Event)
throws UserExitException
{
//Get TS/ES XML Engine to create the xml file

Configuring user exits 213

 String xml = eventServer.createXmlOutput(p_Event);
// Apply XSLT transform to the xml message
String xsltOutput = eventServer.applyXslt("xslt/dbxml.xsl", xml);
//Set the xml message that TS/ES is going to send
eventServer.setOutputTextMessage(xsltOutput);
}
public boolean processReplicationEvent(ReplicationEventIF p_Event) throws
UserExitException
{
boolean retValue = true;
int eventType = p_Event.getEventType();
if (eventType == ReplicationEventTypes.BEFORE_INSERT_EVENT)
{
EventServerIF eventServer = p_Event.getEventServer();
// Apply XSLT transform
applyXslt(eventServer, p_Event);
}
return retValue;
}

See also:
To create an XML message and apply XSLT

To create an XML message and apply XSLT

1. Click Configuration > Datastores.
Ensure that you are connected to an Event Server datastore.
2. Click Configuration > Subscriptions.
Ensure that you have created a subscription that uses the Event Server
datastore as the target.
3. Ensure that you have created at least one source table to XML message
destination mapping within this subscription.
4. Select the table mapping and right-click Open Mapping Details.
5. Click the User Exits tab.
6. Choose Java Class from the User Exit Type box.
7. In the Class Name box, type the Java class name of the user exit that
implements the UserExitIF interface if you have developed the user exit in
Java.
8. Type the parameters that you want to make available to the user exit program
in the Parameter box.
You can access the parameters in the Java class by invoking the getParameter()
method during the initialization process. There are no conventions for
specifying the parameters. The values you type in this box are free-form. The
string of parameter values cannot exceed 255 characters in length.
9. Enable the Before or After check box for one or more of the following
operations:

Option Description
Insert InfoSphere CDC Event Server runs the user
exit before or after applying an insert
operation to a table you have staged, before
or after applying an insert operation to a
JMS message destination, or both.

214 InfoSphere Change Data Capture Management Console: Administration Guide

 Option Description
Update InfoSphere CDC Event Server runs the user
exit before or after applying an update
operation to a table you have staged, before
or after applying an update operation to a
JMS message destination, or both.
Delete InfoSphere CDC Event Server runs the user
exit before or after applying a delete
operation to a table you have staged, before
or after applying a delete operation to a JMS
message destination, or both.
Refresh InfoSphere CDC Event Server runs the user
exit before or after applying a refresh
operation to a table you have staged, before
or after applying a refresh operation to a
JMS message destination, or both.
Truncate InfoSphere CDC Event Server runs the user
exit before or after applying a truncate
operation to a table you have staged, before
or after applying a truncate operation to a
JMS message destination, or both.

10. Click Save.

You can start mirroring on the subscription that contains the source table
assigned to a JMS message destination. The user exit program will set the new
destination before InfoSphere CDC Event Server applies the operation to a
JMS message destination.
Related concepts
Sending XML messages to a JMS message destination on page 334
Creating XML output and applying XSLT to an XML message on page 213

Sending XML messages to multiple JMS message destinations

You can send an XML message to a different JMS queue or topic than the one you
configured in InfoSphere CDC Event Server using standard Java methods. This lets
you override the JMS message destination you selected when configuring
InfoSphere CDC. For an example of a user exit that sends to a different JMS
message destination, see SampleUserExit2.java located in the samples folder or
directory of your InfoSphere CDC Event Server installation.

You need to create the JMS destination you want to send the XML message to
using Java JMS methods. For more information, see http://java.sun.com/
products/jms/javadoc-102a/index.html.

See also:
To send an XML message to a different JMS message destination

To send an XML message to a different JMS message

destination
1. Click Configuration > Datastores.
Ensure that you are connected to an Event Server datastore.
2. Click Configuration > Subscriptions.

Configuring user exits 215

 Ensure that you have created a subscription that uses the Event Server
datastore as the target.
3. Ensure that you have created at least one source table to XML message
destination mapping within this subscription.
4. Select the table mapping and right-click Open Mapping Details.
5. Click the User Exits tab.
6. Choose Java Class from the User Exit Type box.
7. In the Class Name box, type the Java class name of the user exit that
implements the UserExitIF interface if you have developed the user exit in
Java.
8. Type the parameters that you want to make available to the user exit program
in the Parameter box.
You can access the parameters in the Java class by invoking the getParameter()
method during the initialization process. There are no conventions for
specifying the parameters. The values you type in this box are free-form. The
string of parameter values cannot exceed 255 characters in length.
9. Enable the Before or After check box for one or more of the following
operations:

Option Description
Insert InfoSphere CDC Event Server runs the user
exit before or after applying an insert
operation to a table you have staged, before
or after applying an insert operation to a
JMS message destination, or both.
Update InfoSphere CDC Event Server runs the user
exit before or after applying an update
operation to a table you have staged, before
or after applying an update operation to a
JMS message destination, or both.
Delete InfoSphere CDC Event Server runs the user
exit before or after applying a delete
operation to a table you have staged, before
or after applying a delete operation to a JMS
message destination, or both.
Refresh InfoSphere CDC Event Server runs the user
exit before or after applying a refresh
operation to a table you have staged, before
or after applying a refresh operation to a
JMS message destination, or both.
Truncate InfoSphere CDC Event Server runs the user
exit before or after applying a truncate
operation to a table you have staged, before
or after applying a truncate operation to a
JMS message destination, or both.

10. Click Save.

You can start mirroring on the subscription that contains the source table
assigned to a JMS message destination. The user exit program will set the new
destination before InfoSphere CDC Event Server applies the operation to a
JMS message destination.

216 InfoSphere Change Data Capture Management Console: Administration Guide

 Related concepts
Sending XML messages to a JMS message destination on page 334
Sending XML messages to multiple JMS message destinations on page 215

Querying a Web service to access content

You can query a Web service using standard Java methods.

By developing a user exit, you can call a web service with InfoSphere CDC Event
Server. For example, you may be using a web service application to keep track of
new customers that have just registered online. You can access content from the
Web service application to include it in an XML message you configured with
InfoSphere CDC Event Server.

For an example of a user exit that queries a Web service, see SampleUserExit3.java
located in the samples folder or directory of your InfoSphere CDC Event Server
installation.

See also:
To query a Web service to access content

To query a Web service to access content

1. Click Configuration > Datastores.
Ensure that you are connected to an Event Server datastore.
2. Click Configuration > Subscriptions.
Ensure that you have created a subscription that uses the Event Server
datastore as the target.
3. Ensure that you have created at least one source table to XML message
destination mapping within this subscription.
4. Select the table mapping and right-click Open Mapping Details.
5. Click the User Exits tab.
6. Choose Java Class from the User Exit Type box.
7. In the Class Name box, type the Java class name of the user exit that
implements the UserExitIF interface if you have developed the user exit in
Java.
8. In the Class Name box, type:

Option Description
UE1 If it is a stand-alone class
<Java package>.UE1 If the class is included in a Java package (for
example, com.datamirror.interface.UE1). The
files you generate from compiling the user
exit program must be located in a library or
folder that is referenced by the CLASSPATH
environment variable.

9. Type the parameters that you want to make available to the user exit program
in the Parameter box.
You can access the parameters in the Java class by invoking the getParameter()
method during the initialization process. There are no conventions for
specifying the parameters. The values you type in this box are free-form. The
string of parameter values cannot exceed 255 characters in length.

Configuring user exits 217

 10. Enable the Before or After check box for one or more of the following
operations:

Option Description
Insert InfoSphere CDC Event Server runs the user
exit before or after applying an insert
operation to a table you have staged, before
or after applying an insert operation to a
JMS message destination, or both.
Update InfoSphere CDC Event Server runs the user
exit before or after applying an update
operation to a table you have staged, before
or after applying an update operation to a
JMS message destination, or both.
Delete InfoSphere CDC Event Server runs the user
exit before or after applying a delete
operation to a table you have staged, before
or after applying a delete operation to a JMS
message destination, or both.
Refresh InfoSphere CDC Event Server runs the user
exit before or after applying a refresh
operation to a table you have staged, before
or after applying a refresh operation to a
JMS message destination, or both.
Truncate InfoSphere CDC Event Server runs the user
exit before or after applying a truncate
operation to a table you have staged, before
or after applying a truncate operation to a
JMS message destination, or both.

11. Click Save.

You can start mirroring on the subscription that contains the source table
assigned to a JMS message destination. The user exit program will set the new
destination before InfoSphere CDC Event Server applies the operation to a
JMS message destination.
Related concepts
Sending XML messages to a JMS message destination on page 334
Querying a Web service to access content on page 217

Content based routing

You can develop a user exit that lets you send an XML message to a specific JMS
message destination based on the content of the message.

For example, you may want to create a simple XML message whenever a new
employee is created. You can detect new employees by monitoring inserts into the
dbo.Employee table and create an source table to XML mapping using all columns
from this table. You can then send the XML message to a JMS queue called "HR1"
and also send this XML message to another queue called "IT1" each time a new
employee is added to the IT department.

See also:
To route the content of an XML message to another JMS message destination
on page 219

218 InfoSphere Change Data Capture Management Console: Administration Guide

To route the content of an XML message to another JMS
message destination
1. Click Configuration > Datastores.
Ensure that you are connected to an Event Server datastore.
2. Click Configuration > Subscriptions.
Ensure that you have created a subscription that uses the Event Server
datastore as the target.
3. Ensure that you have created at least one source table to XML message
destination mapping within this subscription.
4. Select the table mapping and right-click Open Mapping Details.
5. Click the User Exits tab.
6. Choose Java Class from the User Exit Type box.
7. In the Class Name box, type the Java class name of the user exit that
implements the UserExitIF interface if you have developed the user exit in
Java.
8. Type the parameters that you want to make available to the user exit program
in the Parameter box.
You can access the parameters in the Java class by invoking the getParameter()
method during the initialization process. There are no conventions for
specifying the parameters. The values you type in this box are free-form. The
string of parameter values cannot exceed 255 characters in length.
9. Enable the Before or After check box for one or more of the following
operations:

Option Description
Insert InfoSphere CDC Event Server runs the user
exit before or after applying an insert
operation to a table you have staged, before
or after applying an insert operation to a
JMS message destination, or both.
Update InfoSphere CDC Event Server runs the user
exit before or after applying an update
operation to a table you have staged, before
or after applying an update operation to a
JMS message destination, or both.
Delete InfoSphere CDC Event Server runs the user
exit before or after applying a delete
operation to a table you have staged, before
or after applying a delete operation to a JMS
message destination, or both.
Refresh InfoSphere CDC Event Server runs the user
exit before or after applying a refresh
operation to a table you have staged, before
or after applying a refresh operation to a
JMS message destination, or both.
Truncate InfoSphere CDC Event Server runs the user
exit before or after applying a truncate
operation to a table you have staged, before
or after applying a truncate operation to a
JMS message destination, or both.

10. Click Save.

Configuring user exits 219

 You can start mirroring on the subscription that contains the source table
assigned to a JMS message destination. The user exit program will set the new
destination before InfoSphere CDC Event Server applies the operation to a
JMS message destination.
Related concepts
Sending XML messages to multiple JMS message destinations on page 215
Content based routing on page 218

220 InfoSphere Change Data Capture Management Console: Administration Guide

Column functions
InfoSphere CDC provides a number of column functions that you can use in
expressions when mapping target columns. This topic describes each of the column
functions, their syntax and parameters, and also provides examples that illustrate
how to use them.

In this section, you will learn:

Conventions in using column functions
String functions on page 222
Date and time functions on page 229
Conversion functions on page 235
Conditional and variable functions on page 245
Data functions on page 247
User exit functions on page 259
%GETCOL column function scenarios (DB2 for IBM i) on page 267
%GETCOL column function scenarios (Dynamic SQL) on page 269
Publishing multiple derived columns using the %GETCOL function (Dynamic
SQL) on page 271
XPath functions on page 272
Transform extensions on page 278
Using external Java objects in data transformations on page 286
XPath expression operators on page 287

Conventions in using column functions

Before using column functions in expressions, you should consider the following:
v Depending on the InfoSphere CDC you have installed, some column functions
may not be supported.
v Names of column functions are case insensitive.
v For some column functions, you cannot specify a Large OBject (LOB) column as
a function parameter. For more information about LOB data type support, see
the InfoSphere CDC documentation for your database platform.
v You can specify character literals in their internal numeric representation, as
parameters for column functions. To do this, use the double-angled bracket
notation (<< >>). This notation lets you work with character literals that contain
both printable and non-printable characters.
v Specifying character values as decimal integers:
The values you specify within brackets are decimal integers that represent
either American Standard Code for Information Interchange (ASCII) or
Extended Binary Coded Decimal Interchange Code (EBCDIC) characters. For
ASCII characters, these values must be in the range of 0 to 127. For EBCDIC,
these values must be in the range of 0 to 255. For example, <<32>> represents
a blank character in ASCII. Do not prefix these values with zeroes.
If you have installed InfoSphere CDC for z/OS or InfoSphere CDC for IBM i
as a target system, and the column function manipulates a value from a target

Copyright IBM Corp. 2008, 2011 221

 column, then specify integers in EBCDIC format. For all other InfoSphere
CDC products installed on the target system, you can specify integers in
ASCII format.
v InfoSphere CDC for z/OS does not support the double-angled bracket notation.
v You can specify multiple characters in the same character literal. For example, if
you are using the ASCII character set, the notation
<<65>><<78>><<78>><<65>> and <<65>>NN<<65>> represent the string
"ANNA".
v If you do not follow the double-angled bracket notation, such as <45>>, then
InfoSphere CDC does not generate an error. Instead, InfoSphere CDC treats it as
a sequence of characters (<, 4, 5, >, and >), and returns the result based on this
sequence.
v To specify NULL as a parameter in a column function, enter NULL without any
delimiter.

String functions
Use these functions when you want InfoSphere CDC to manipulate strings. During
replication, you can have InfoSphere CDC concatenate multiple strings, remove
blank characters from a string, change the case of the characters in a string, replace
characters of a string with other characters, or extract a substring from a string.

Note: Some examples in this section use the double-angled bracket notation (<<
>>) and are based on the American Standard Code for Information Interchange
(ASCII) character set. Under a different character set, these examples do not
produce the same results as described.

See also:
Concatenation%CONCAT
Lowercase%LOWER on page 223
Left trim%LTRIM on page 224
Capitalization%PROPER on page 224
Character substitution%REPLACE on page 225
Right trim%RTRIM on page 227
Substring%SUBSTRING on page 228
Uppercase%UPPER on page 228

Concatenation%CONCAT
Use this function when you want InfoSphere CDC to concatenate multiple
character fields and literals to form a single string. There is no limit to the number
of input fields or the resulting length.

Syntax
%CONCAT(<parm1>, <parm2>, ...<parm20>)

Parameters

parm1 to parm20Specify character columns, literals, or column functions that

return character strings.

222 InfoSphere Change Data Capture Management Console: Administration Guide

 Note: Concatenating a NULL has no effect. If all input fields are NULL, then
NULL is returned.

Result data type

Character-based.

Examples

%CONCAT(FNAME, " ", LNAME)

Concatenates the values from the FNAME and LNAME columns with a blank
character inserted between them. For example, if FNAME = "Ray" and LNAME =
"Kennedy", this function returns "Ray Kennedy".

WITH P %CONCAT("InfoSphere", " ", "CDC", "Management", "Console")

Returns the string "InfoSphere CDC Management Console".

%CONCAT("Anna", "<<32>>", "Kim<<0>>")

Returns the NULL-terminated ASCII string "Anna Kim". For information about the
double-angled bracket notation, see String functions on page 222.

Lowercase%LOWER
Use this function when you want InfoSphere CDC to convert all uppercase
characters in a string to lowercase during replication.

Syntax
%LOWER(<parm>)

Parameters
parmSpecifies a character column, literal, or column function that returns a
character string.

Result data type

Character-based. Returns NULL if parm is NULL.

Examples

%LOWER(DEPARTMENT)

Returns the strings in the DEPARTMENT column in lowercase. For example,

"accounting", "marketing", and so on.

%LOWER("BrUcE JoNeS")

Returns the string "bruce jones".

%LOWER(%SUBSTRING("BrUcE JoNeS",3,2))

Returns the string "uc".

Column functions 223

 %LOWER("<<65>><<78>><<78>><<65>><<32>><<75>><<73>><<77>>")

Returns the ASCII string "anna kim".

Related concepts
String functions on page 222
Related reference
Uppercase%UPPER on page 228
Substring%SUBSTRING on page 228

Left trim%LTRIM
Use this function when you want InfoSphere CDC to trim all leading blank
characters from a character string during replication. Blank characters that are
embedded in a string are not trimmed.

Syntax
%LTRIM(<parm>)

Parameters

parmSpecifies a character column, literal, or column function that returns a

character string.

Result data type

Character-based. Returns NULL if parm is NULL.

Examples

%LTRIM(" George Smith")

Returns the string "George Smith" with no leading blank characters.

%LTRIM("Andrea Moss ")

Returns the string "Andrea Moss ". The %LTRIM function does not trim trailing
and embedded blank characters.

%LTRIM("<<32>><<32>><<32>>Anna Kim")

Returns the ASCII string "Anna Kim" with no leading blank characters.
Related concepts
String functions on page 222
Related reference
Right trim%RTRIM on page 227

Capitalization%PROPER
Use this function when you want InfoSphere CDC to convert the first letter of each
word to uppercase, and the remaining letters to lowercase during replication. A
word is a consecutive sequence of non-blank characters encapsulated by blank
characters and string boundaries.

224 InfoSphere Change Data Capture Management Console: Administration Guide

 Syntax
%PROPER(<parm>)

Parameters

parmSpecifies a character column, literal, or column manipulation function that

returns a character string.

Result data type

Character-based. Returns NULL if parm is NULL.

Examples

%PROPER(NAME)

Returns the value in the NAME column with the first letter of each word
capitalized. For example, "Steve Malone".

%PROPER("TiNa MaNcInI")

Returns the string "Tina Mancini".

%PROPER(%SUBSTRING("tInA mAnCiNi",3,6))

Returns the string "Na Man".

%PROPER("mary-lou fernandez")

Returns the string "Mary-lou Fernandez". Note that "lou" is not converted to "Lou".

%PROPER("<<97><<110>><<110>><<97>><<32>><<107>><<105>><<109>>")

Returns the ASCII string "Anna Kim".

Related concepts
String functions on page 222
Related reference
Substring%SUBSTRING on page 228

Character substitution%REPLACE
Use this function when you want InfoSphere CDC to replace leading, trailing, or
all occurrences of a specified character with another character during replication. It
provides a character-by-character replacement. You can use this function to replace
leading blank characters with zeros.

Syntax
%REPLACE(<parm>, "<type>", "<str1>", "<str2>")

Parameters
v parmSpecifies a character column, literal, or column function that returns a
character string. If parm is NULL, this function returns NULL.
v typeSpecifies the substitution type. You must enclose values of this parameter
in double quotes.

Column functions 225

 *ALLReplaces all occurrences of the specified character.
*TRAILReplaces all trailing occurrences of the specified character.
*LEADReplaces all leading occurrences of the specified character.
v str1Specifies the set of characters to be replaced.
v str2Specifies the set of characters to replace those specified in str1 . If the
number of characters in str1 is greater than that in str2 , the extraneous
characters in str1 are deleted in the result. If the number of characters in str1 is
less than that in strthe extraneous characters in str2 are ignored. If you specify
str2 as two consecutive double quotes ("") , you can remove instances of a
character from str1.

Result data type

Character. Returns NULL if parm is NULL.

Examples

%REPLACE(CUSTNO, "*LEAD", " ", "0")

Replaces all leading blank characters in the CUSTNO column with zeros.

%REPLACE(CUSTNO, "*LEAD", "ABC", "123")

Replaces all leading occurrences of "A" with "1", "B" with "2", and "C" with "3" in
the CUSTNO column. Evaluation begins with the first character and continues
until a character other than "A", "B" or "C" is found. For example, if a column
value is "AC7777", this example returns "137777". If a column value is "ADC7777",
this example returns "1DC7777".

%REPLACE(PHONENO, "*ALL", " ", "")

Removes all blank characters in the PHONENO column. This example illustrates
how the %REPLACE function can be used to remove a character from a string
instead of replacing it with another character.

%REPLACE(PHONENO, "*LEAD", " ", "")

Removes all leading blank characters in the PHONENO column. This example is
similar to the previous example, except that only leading blank characters are
removed. To remove leading blank characters, you can also use the %LTRIM
function. To remove trailing blank characters, use the %RTRIM function.

%REPLACE(PARTNO, "*TRAIL", "ACY", "acy")

Replaces all trailing occurrences of "A" with "a", "C" with "c", and "Y" with "y" in
the PARTNO column. Evaluation begins with the last character and continues until
a character other than "A", "C" or "Y" is found. For example, if a column value is
"2361ACY", this example returns "2361acy". If a column value is "2361ADY", this
example returns "2361ADy".

%REPLACE("259899", "*ALL", "29", "4")

Returns "458". Replaces all occurrences of "2" with "4", and removes all occurrences
of "9".

226 InfoSphere Change Data Capture Management Console: Administration Guide

 %REPLACE("259899", "*ALL", "2", "45")

Returns "459899". Replaces all occurrences of "2" with "4". Does not remove
occurrences of "5".

%REPLACE(PRODDESC, "*ALL", "<<0>><<13>>", "<<32>><<32>>")

On platform that use the ASCII character set, this functions replaces all occurrences
of NUL and carriage return in the PRODDESC column with blank characters.
Related concepts
String functions on page 222
Related reference
Left trim%LTRIM on page 224
Right trim%RTRIM

Right trim%RTRIM
Use this function when you want InfoSphere CDC to trim all trailing blank
characters from a character string during replication. Blank characters that are
embedded in a string are not trimmed.

Syntax
%RTRIM(<parm>)

Parameters
v parmSpecifies a character column, literal, or column function that returns a
character string.

Result data type

Character-based. Returns NULL if parm is NULL.

Examples

%RTRIM("Steve Malone ")

Returns the string "Steve Malone" with no trailing blank characters.

%RTRIM(" Andrea Moss")

Returns the string " Andrea Moss". The %RTRIM function does not trim leading
and embedded blank characters.

%RTRIM("Anna Kim<<32>><<32>><<32>>")

Returns the ASCII string "Anna Kim" with no trailing blank characters.

Column functions 227

 Related concepts
String functions on page 222
Related reference
Left trim%LTRIM on page 224

Substring%SUBSTRING
Use this function when you want InfoSphere CDC to create a character string that
is a subset of an existing string that begins at a specified starting position and
continues for a specified length.

Syntax
%SUBSTRING(<parm>, <position>, <length>)

Parameters
v parmSpecifies a character column, literal, or column function that returns a
character string.
v positionSpecifies the starting position. This value must be greater than or equal
to 1.
v lengthSpecifies the length of the substring. This value must be greater than or
equal to 1.

Result data type

Character-based. Returns NULL if parm is NULL.

If position is greater than the length of parm , then the function returns a string of
blank characters, with a length of length. If position is less than the length of parm,
but position + length is greater then the length of parm , then the function returns a
string of length length that has the portion of parm that starts at position and ends
at the end of parm, right-padded with blank characters.

Examples

%SUBSTRING(DIVISION,3,2)

Returns two characters from the DIVISION column beginning from the third
position.

%SUBSTRING("Tony Jackson",0,2)

Generates a runtime error because the starting position cannot be less than 1.

%SUBSTRING("Anna<<32>>Kim<<0>>", 1, 8)

Returns the ASCII string "Anna Kim" with no NULL-termination.

Related concepts
String functions on page 222

Uppercase%UPPER
Use this function when you want InfoSphere CDC to convert all lowercase
characters in a string to uppercase during replication.

228 InfoSphere Change Data Capture Management Console: Administration Guide

 Syntax
%UPPER(<parm>)

Parameters

parmSpecifies a character column, literal, or column function that returns a

character string.

Result data type

Character-based. Returns NULL if parm is NULL.

Examples

%UPPER(DEPARTMENT)

Returns the strings in the DEPARTMENT column in uppercase. For example,

"ACCOUNTING", "MARKETING", and so on.

%UPPER("AnDrEa MoSs")

Returns the string "ANDREA MOSS".

%UPPER("[emp ny]")

Returns the string "[EMP NY]".

%UPPER(%SUBSTRING("AnDrEa MoSs",3,2))

Returns the string "DR".

%UPPER("<<97>><<110>><<110>><<97>><<32>><<75>><<73>><<77>>")

Returns the ASCII string "ANNA KIM".

Related concepts
String functions on page 222
Related reference
Lowercase%LOWER on page 223
Substring%SUBSTRING on page 228

Date and time functions

Use these functions when you want InfoSphere CDC to manipulate date and time
values during replication. You can add a two-digit century specification to a date,
or retrieve the current date and time.

See also:
Century%CENTURY on page 230
Current date%CURDATE on page 231
Current time%CURTIME on page 232
Current timestamp%CURTMSTP on page 234

Column functions 229

 Century%CENTURY
Use this function when you want InfoSphere CDC to add a two-digit century
specification to a date that identifies the year without the century during
replication. This function accepts a character date value specified in one of six
different formats.

Syntax
%CENTURY(<parm>, "<type>", [centuryline])

Parameters
v parmSpecifies a character column, literal or column function that returns a date
value accepted by the function.
v typeSpecifies the format of the input date. You must enclose values of this
parameter in double quotes.
*YMDThe input format is yymmdd.
*MDYThe input format is mmddyy.
*DMYThe input format is ddmmyy.
*YMThe input format is yymm.
*MYThe input format is mmyy.
*JULThe input format is yyjjj, where jjj represent the sequence number of a
day in the calendar year. jjj must be between 1, which represents January 1st,
and 366, which represents December 31st in a leap year. For jjj values less
than 100, you must specify the leading zero or zeros. For example, the Julian
date for February 4th is 035, which represents the 35th day of the year.
v centurylineSpecifies the year in the century used to determine which century is
added to the date. All years that precede the century line year will be designated
as being in the 21st century. All years including and following the century line
year will be designated as being in the 20th century. If centuryline is greater than
99, all years are designated as being in the 21st century.
For example, if centuryline is set to 30 and the two-digit year specified by parm
is 19, this function returns 2019. If centuryline is set to 20 and the two-digit year
specified by parm is 33, this function returns 1933.
This parameter is optional. If you omit this parameter, InfoSphere CDC assumes
a default value of 40.

Result data type

Character if parm is character. Otherwise, it returns a numeric value. If parm or type

is NULL, this function returns NULL.

Examples
Input century line
Input Date (parm) Input Format (type) (centuryline) Result
101001 "*YMD" 20101001 (October 1,
2010)
211197 "*DMY" 0 21111997 (November
21, 1997)
032080 "*MDY" 60 03201980 (March 20,
1980)
0493 "*MY" 80 041993 (April 1993)

230 InfoSphere Change Data Capture Management Console: Administration Guide

 Input century line
Input Date (parm) Input Format (type) (centuryline) Result
2001 "*YM" 202001 (January 2002)
99365 "*JUL" 92 1999365 (December
31, 1999)
NULL "*YM" NULL

Related concepts
Date and time functions on page 229

Current date%CURDATE
Use this function when you want InfoSphere CDC to return the current date
during data replication (refresh or mirroring) activities on the source or target. For
example, you may want to track when InfoSphere CDC inserts a record or when it
performs updates on source and target columns. This function uses the system
clock you have set on the source or target.

Note: InfoSphere CDC for IBM i does not support this function.

Mapping a target column to an expression that uses the %CURDATE function is

not the same as defining the current date as the initial value for the target column.
When you map a target column to an expression, InfoSphere CDC populates the
target column with the current date when a record is inserted or updated in the
target table. However, when you define the initial value as the current date,
InfoSphere CDC populates the target column with the current date only when it
inserts a record into the target table.

Syntax
%CURDATE("<timezone>")

Parameters

timezoneSpecifies the time zone of the result. You must enclose values of this
parameter in double or single quotes.
v *LOCReturns the date local to the source or target.
v *UTCReturns the date in Coordinated Universal Time (UTC).
v *GMTReturns the date in Greenwich Mean Time (GMT). This is the same as
*UTC.

Result data type

Character in the format CCYY-MM-DD.

Examples

%CURDATE("*LOC")

If the local time is March 11, 2004, this function returns 2004-03-11.

%CURDATE("*UTC")

Column functions 231

 For a server located in the Japan Standard Time (JST) zone, on August 28, 2007, at
1:21 AM, this function returns 2007- 08-27. JST is 9 hours ahead of UTC (UTC+9).

%CURDATE("*GMT")

For a server located in the Japan Standard Time (JST) zone, on August 28, 2007, at
1:21 AM, this function returns 2007- 08-27. JST is 9 hours ahead of UTC (UTC+9).
This example is equivalent to %CURDATE ("*UTC").

%SUBSTRING(%TOCHAR(%CURDATE("*LOC"), 10), 6, 5)

Returns the month and day of the %CURDATE function invocation local to the
source or target. You can use this example if you require the month and day only.
For example, if the local date is January 29, 2007, the expression returns "01-29".
The %TOCHAR function extracts the month, separator character, and day.
Related concepts
Date and time functions on page 229
Mapping initial values to target columns on page 153
Related reference
Character conversion%TOCHAR on page 235
Substring%SUBSTRING on page 228
Current time%CURTIME
Current timestamp%CURTMSTP on page 234

Current time%CURTIME
Use this function when you want InfoSphere CDC to return the time when it
inserts or updates a row on source and target columns. This function uses the
system clock on the source or target.

Note: InfoSphere CDC for IBM i does not support this function.

Syntax
%CURTIME("<timezone>")

Parameters

timezoneSpecifies the time zone of the result. You must enclose values of this
parameter in double or single quotes.
v *LOCReturns the time local to the source or target.
v *UTCReturns the time in Coordinated Universal Time (UTC).
v *GMTReturns the time in Greenwich Mean Time (GMT). This is the same as
*UTC.

Result data type

Character, in the format HH.MM.SS.

Examples

%CURTIME("*LOC")

If the local time is 11:25:22 PM (local), this function returns 23.25.22.

232 InfoSphere Change Data Capture Management Console: Administration Guide

%CURTIME("*UTC")

For a server located in the Hawaiian Standard Time (HST) zone, at 9:14:33 PM, this
function returns 07.14.33. HST is 10 hours behind UTC (UTC-10).

%CURTIME("*GMT")

For a server located in the Hawaiian Standard Time (HST) zone, at 9:14:33 PM, this
function returns 07.14.33. HST is 10 hours behind UTC (UTC-10). This example is
equivalent to %CURTIME ("*UTC").

%TOCHAR(%IF(%VAR(EST, %TONUMBER(%REPLACE(%TOCHAR(%CURTIME("*LOC"), 8),

"*ALL", ".", "")) + 30000) < 240000, %VAR(EST), %VAR(EST) 240000), 6)

Returns the time of the %CURTIME function invocation three time zones ahead
relative to the local time zone on the source or target. This example illustrates that
an expression can be defined to convert local time to the equivalent time in any
other time zone (not necessarily UTC). It returns a character result after performing
time calculations.

For example, if this expression is evaluated on a server located in the Pacific

Standard Time (PST) zone at 3:22:48 PM, the expression returns "182248". The
result represents the same time in the Eastern Standard Time (EST) zone, which is
3 hours ahead of PST (PST+3). In the event that the returned Pacific time is in the
interval from 9:00:00 PM to 12:00:00 AM, the %IF function ensures that the
expression returns the equivalent Eastern time on the following day.

To modify the above expression to select a different time zone ahead or behind the
local time zone, change + 30000 to a different sign and value. For example,
changing +30000 to +20000 returns the equivalent time in the Central Standard
Time (CST) zone.

%IF(%VAR(DIFF, %TONUMBER(%TOCHAR(%CURTIME("*LOC"), 2))

%TONUMBER(%TOCHAR(%CURTIME("*UTC"), 2))) > 12, %VAR(DIFF) 24,
%IF(%VAR(DIFF) < 12, %VAR(DIFF) + 24, &VAR(DIFF)))

Returns the time difference between UTC and the time zone of the source or target
where the %CURTIME functions are invoked.

For example, if this expression is evaluated on a server located in the Central

Europe Time (CET) zone at 6:43:07 PM, the expression returns 1. If the server is
located in the Mountain Standard Time (MST) zone and the functions are invoked
at 1:22:13 AM, the expression returns -7.

Note: This example compares equivalent times after obtaining two separate time
samples, which may not always produce the correct results. The expression will
not produce the correct result if %CURTIME ("*LOC") is invoked at 7:59:59 AM, local
time, and %CURTIME ("*UTC") is invoked one second later at 8:00:00 AM, local time.

Column functions 233

 Related concepts
Date and time functions on page 229
Mapping initial values to target columns on page 153
Related reference
Current date%CURDATE on page 231
Current timestamp%CURTMSTP
Character conversion%TOCHAR on page 235
Substring%SUBSTRING on page 228

Current timestamp%CURTMSTP
Use this function to when you want InfoSphere CDC to track the date and time
when it inserts or updates a row in source and target columns. This function uses
the system clock on the source or target.

Note: InfoSphere CDC for IBM i does not support this function.

Syntax
%CURTMSTP("<timezone>")

Parameters

timezoneSpecifies the time zone of the result. You must enclose values of this
parameter in double or single quotes.
v *LOCReturns the time local to the source or target.
v *UTCReturns the time in Coordinated Universal Time (UTC).
v *GMTReturns the time in Greenwich Mean Time (GMT). This is the same as
*UTC.

Result data type

Character, in the format CCYY-MM-DD-HH.MM.SS.UUUUUU, where UUUUUU

represents the number of microseconds. For example, 2008-12-09-03.11.34.849217.
For environments that do not support microsecond precision, zeroes will be used
to right-pad the result to a six-digit length. In the examples for this function, the
results do not show microseconds.

Examples

%CURTMSTP("*LOC")

If the local time is 2:05:54 AM on June 18, 2005, this function returns
2005-06-18-02.05.54.

%CURTMSTP("*UTC")

For a server located in the Japan Standard Time (JST) zone, at 4:31:01 AM on
September 22, 2011, this function returns 2011-09-21-19.31.01. JST is 9 hours ahead
of UTC (UTC+9).

%CURTMSTP("*GMT")

234 InfoSphere Change Data Capture Management Console: Administration Guide

 For a server located in the Japan Standard Time (JST) zone, at 4:31:01 AM on
September 22, 2011, this function returns 2011-09-21-19.31.01. JST is 9 hours ahead
of UTC (UTC+9). This example is equivalent to %CURTMSTP("*UTC").

%TOCHAR(%CURTMSTP("*UTC"), 16)

Returns the date and time (hours and minutes only) of the %CURTMSTP function
invocation in UTC. You can use this example if you do not require the number of
seconds and microseconds.

For example, if the %CURTMSTP function is invoked on a server located in the

Western Standard Time (WST) zone on April 24, 2013 at 4:05:22 AM, the expression
returns "2013-04-23-20.05". WST is 8 hours ahead of UTC (UTC+8). The %TOCHAR
function converts the date to character data and returns the first 16 characters of
the timestamp returned by the %CURTMSTP function.
Related concepts
Date and time functions on page 229
Related reference
Character conversion%TOCHAR
Current date%CURDATE on page 231
Current time%CURTIME on page 232

Conversion functions
Use these functions when you want InfoSphere CDC to convert values from one
data type to another during replication. You can convert from any value to a
character string or a numeric value, or from a numeric or character value to a
datetime-type value.

See also:
Character conversion%TOCHAR
Character format conversion%TOCHARFORMAT on page 237
Date conversion%TODATE on page 238
Date and time conversion%TODATETIME on page 239
Number conversion%TONUMBER on page 242
Time conversion%TOTIME on page 243

Character conversion%TOCHAR
Use this function to convert any value to a character string.

Syntax
%TOCHAR(<parm>, <length>, [decimal])

Parameters
v parmSpecifies a column name, literal, or a column function. If you specify a
date, time, or timestamp for this parameter, the output format is "yyyy-MM-dd
HH:mm:ss". If you specify a DATE, the output format is "yyyy-MM-dd". If you
specify a TIME, the output format is "HH:mm:ss"

Column functions 235

 v lengthSpecifies the number of characters to be returned. A decimal place
counts as a returned value. For example, if you specify that you want to return
three characters, this function returns the three leftmost or high order digits of
parm.

Note: Specify a negative value for this parameter if you would like %TOCHAR
to treat the incoming value as unsigned. This feature is only available with
InfoSphere CDC for z/OS.
v decimalAn integer value that specifies the number of decimal places in the
returned value. The following table provides several examples with integers that
have a defined number of decimal places and an example of how InfoSphere
CDC converts real floating decimals.

Input value Length Decimal Result

1.2345 6 2 001.23
1234.5 7 2 1234.50
1.02 7 2 0001.02
1.02 (Real floating 7 2 1.02000
decimal)

Result data type

If length specifies a value greater than the length of parm, the result is left-padded
or right-padded with blank characters.

Examples
Input value Input length Decimal places
(parm) (length) (decimal) Result
12345 3 Not specified. "123"
123.45 5 Not specified. "123.4"
0.123 3 Not specified. "0.1"
1234 6 Not specified. "001234"

The integer value is

left-padded with zeros to
return a string of six
characters.
1.02 7 Not specified. "1.020000"

The decimal part is

right-padded with zeros to
return a string of seven
characters.
45699 9 2 "000456.99"

The integer value is

left-padded with zeros and
two decimal places to return
a string of nine characters.

236 InfoSphere Change Data Capture Management Console: Administration Guide

 Input value Input length Decimal places
(parm) (length) (decimal) Result
&SEQNO -20 Not specified. "13878964169332555778". By
specifying a negative length,
%TOCHAR treats the
&SEQNO journal control field
as unsigned.
Note: The ability to specify
negative lengths is only
supported by InfoSphere
CDC for z/OS.

Related reference
Character format conversion%TOCHARFORMAT
Number conversion%TONUMBER on page 242

Character format conversion%TOCHARFORMAT

Note: This function is not available for InfoSphere CDC for z/OS

Use this function to convert any date or number to a string. This function returns
date formats found in java.text.SimpleDateFormat or number formats found in
java.text.DecimalFormat. If your input value is a String, this function returns a
String.

Syntax
%TOCHARFORMAT(<parm>, "<format>")

Parameters
v parmSpecifies the input value which can be a String, Date, or Number.
v formatSpecifies the format of the returned value. Note the following when
specifying values for this parameter:
If parm = NumberSpecify formats that are valid for
java.text.DecimalFormat.
If parm = DateSpecify formats that are valid for
java.text.SimpleDateFormat.
If parm = StringThe function will ignore this parameter and return a String.

Result data type

String. This function returns NULL if parm or format are NULL.

Examples
Format for return value
Input value (parm) (format) Result
1234 "0.###E0" Returns a string in the following
format:
v 1.234E3
date "yyyy.MM.dd G 'at' Returns a string in the following
HH:mm:ss z" format:
v 2001.07.04 AD at 12:08:56 PDT

Column functions 237

 Related reference
Character conversion%TOCHAR on page 235
Number conversion%TONUMBER on page 242

Date conversion%TODATE
Use this function when you want InfoSphere CDC to convert a numeric or
character data type value to a datetime-data type during replication. You can
convert dates from packed-numeric, zoned-numeric, or from character formats
without century, to datetime or character-type values with century.

Syntax
%TODATE(<date>, "<type>")

Parameters
v dateSpecifies the input date. If date is the name of a column containing a
character string, the length of that string must match the length for the format
specified by type as indicated below. InfoSphere CDC generates an error if the
length is any other value.
Note the following about the values returned by this function:
If you specify NULL for date, this function returns NULL.
If you specify "0" for date, this function returns "1901-01-01".
If you specify a DATE for date, this function returns a DATE

Note: If you specify "-" and "/" characters, these characters are removed before
the value is evaluated by InfoSphere CDC.

type value Length of date

*YMD (yymmdd) 6 digits
*MDY (mmddyy) 6 digits
*DMY (ddmmyy) 6 digits
*YYMD (ccyymmdd) 8 digits
*CYMD (cyymmdd) 7 digits
*JUL (yyjjj) 6 digits
*CJUL (cyyjjj) 6 digits
*YJUL (ccyyjjj) 7 digits

v typeSpecifies the format of the input date. You must enclose values of this
parameter in double quotes.
*YMDSpecifies the input format is yymmdd.
*MDYSpecifies the input format is mmddyy.
*DMYSpecifies the input format is ddmmyy.
*YYMDSpecifies the input format is ccyymmdd, where cc represents the
century.
*CYMDSpecifies the input format is cyymmdd, where c represents the
century. A value of 0 for c represents the 20th century. Any other value
represents the 21st century.
*JULSpecifies the input format is yyjjj, where jjj represent the sequence
number of a day in the calendar year. jjj must be between 1, which represents
January 1st, and 366, which represents December 31st in a leap year. For jjj

238 InfoSphere Change Data Capture Management Console: Administration Guide

 values less than 100, you must specify the leading zero or zeros. For example,
the Julian date for February 4th is 035, which represents the 35th day of the
year.
When you set type to *JUL, if you specify a value for yy between 40 and 99,
the %TODATE function returns the corresponding year in the 20th century.
For example, 1940. If you specify a value for yy between 0 and 39, the
%TODATE function returns the corresponding year in the 21st century. For
example, 2039.
*CJULSpecifies the input format is cyyjjj, where c represents the century. A
value of 0 for c represents the 20th century. Any other value represents the
21st century.
*YJULSpecifies the input format is ccyyjjj, where cc represents the century.

Result data type

Date in standard ISO (International Organization for Standardization) format, that

is CCYY-MM-DD.

Examples
Input date (date) Input format (type) Result
760704 *YMD 1976-07-04 (July 4, 1976)
100195 *MDY 1995-10-01 (October 10, 1995)
000000 *MDY 1901-01-01 (January 1, 1901)
010768 *DMY 1968-07-01 (July 1, 1968)
19560205 *YYMD 1956-02-05 (February 5, 1956)
1100216 *CYMD 2010-02-16 (February 16,
2010)
95004 *JUL 1995-01-04 (January 4, 1995)
102032 *CJUL 2002-02-01 (February 2, 2002)
1991359 *YJUL 1991-12-25 (December 25,
1991)

Related reference
Date and time conversion%TODATETIME

Date and time conversion%TODATETIME

Use this function when you want InfoSphere CDC to convert a numeric or
character data type to a datetime data type during replication. You can convert
dates from packed-numeric, zoned-numeric, or from character formats without
century, to datetime or character-type values with century. You can also convert
time data types from packed-numeric, zoned-numeric, or character formats into
datetime or character-type values with century.

Note: InfoSphere CDC for IBM i does not support this function.

Syntax
%TODATETIME (<date>, "<type>", <time>)

Column functions 239

 Parameters
v dateSpecifies the input date. If date is the name of a column containing a
character string, the length of that string must match the length for the format
specified by type as indicated below. InfoSphere CDC generates an error if the
length is any other value.
Note the following about the values returned by this function:
If you specify NULL for date, this function returns NULL.
If InfoSphere CDC encounters an error when parsingdate, this function returns
"1901-01-01".
If you specify "DATE" for date, this function returns a timestamp.

Note: If you specify "-" and "/" characters, these characters are removed before
the value is evaluated by InfoSphere CDC.

type value Length of date

*YMD (yymmdd) 6 digits
*MDY (mmddyy) 6 digits
*DMY (ddmmyy) 6 digits
*YYMD (ccyymmdd) 8 digits
*CYMD (cyymmdd) 7 digits
*JUL (yyjjj) 6 digits
*CJUL (cyyjjj) 6 digits
*YJUL (ccyyjjj) 7 digits

v typeSpecifies the format of the input date. You must enclose values of this
parameter in double quotes.
*YMDSpecifies the input format is yymmdd.
*MDYSpecifies the input format is mmddyy.
*DMYSpecifies the input format is ddmmyy.
*YYMDSpecifies the input format is ccyymmdd, where cc represents the
century.
*CYMDSpecifies the input format is cyymmdd, where c represents the
century. A value of 0 for c represents the 20th century. Any other value
represents the 21st century.
*JULSpecifies the input format is yyjjj, where jjj represent the sequence
number of a day in the calendar year. jjj must be between 1, which represents
January 1st, and 366, which represents December 31st in a leap year. For jjj
values less than 100, you must specify the leading zero or zeros. For example,
the Julian date for February 4th is 035, which represents the 35th day of the
year.
When you set type to *JUL, if you specify a value for yy between 40 and 99,
the %TODATETIME function returns the corresponding year in the 20th
century. For example, 1940. If you specify a value for yy between 0 and 39,
the %TODATETIME function returns the corresponding year in the 21st
century. For example, 2039.
*CJULSpecifies the input format is cyyjjj, where c represents the century. A
value of 0 for c represents the 20th century. Any other value represents the
21st century.
*YJULSpecifies the input format is ccyyjjj, where cc represents the century.

240 InfoSphere Change Data Capture Management Console: Administration Guide

v timeSpecifies the input time. The table below indicates the length and format
for this parameter, depending on the data type of the input time.

Data type Length Format

Numeric 5 digits HMMSS. For example, 71500
represents 7:15 AM.
6 digits HHMMSS. For example,
223000 represents 10:30 PM.
Character 8 digits HH:MM:SS. You must
enclose values of this
parameter in double quotes.
For example, "10:30:00"
represents 10:30 AM.

Result data type

Date, in standard ISO (International Organization for Standardization) format. If

the input date contains an invalid value for the year, month, or day, the
%TODATETIME function returns the default value 1901-01-01 for the date.

Examples

The table below provides examples for this function. These examples show the
colon (:) as the separator in the returned ISO time values. Depending on your
environment, a different character may separate the year, the month, and the day
in the output date. Also, a different character may separate the hours, the minutes,
and the seconds in the output time.

Input date (date) Input format (type) Input time (time) Result
891102 *YMD 112500 1989-11-02 11:25:00
(November 2, 1989 at
11:25 AM)
030496 *MDY "13:42:00" 1996-03-04 13:42:00
(March 4, 1996 at 1:42
PM)
000000 *MDY "10:55:00" 1901-01-01 10:55:00
(January 1, 1901 at
10:55 AM)
210570 *DMY "09:05:00" 1970-05-21 09:05:00
(May 21, 1970 at 9:05
AM)
20100902 *YYMD 023000 2010-09-02 02:30:00
(February 9, 2010 at
2:30 AM)
1060723 *CYMD 193300 2006-07-23 19:33:00
(July 23, 2006 at 7:33
PM)
91060 *JUL 220100 1991-03-01 22:01:00
(March 1, 1991 at
10:01 PM)
097106 *CJUL 043500 1997-04-16 04:35:00
(April 16, 1997 at 4:35
AM)

Column functions 241

 Input date (date) Input format (type) Input time (time) Result
2002092 *YJUL "17:15:00" 2002-04-02 17:15:00
(April 2, 2002 at 5:15
PM)

Related reference
Date conversion%TODATE on page 238
Time conversion%TOTIME on page 243

Number conversion%TONUMBER
Use this function when you want InfoSphere CDC to convert a character field or
literal to a numeric value during replication. If your input value is a number, this
function returns a number.

Syntax
%TONUMBER(<parm>)

Parameters
v parmSpecifies a character column, literal or column function that returns a
character string. It must be in the following format:
[<whitepsace>] [<sign>] [<digits>] [.<digits>] [{e | E} [<sign>] <digits>]
In the specification above, the white space can consist of one or more blank or
tab characters. The signs must be plus (+) or minus (-), and you can specify only
decimal digits. At least one digit must appear after the decimal point. The
decimal digits may be followed by an exponent that consists of the letter E (in
upper or lower case) and an optionally signed decimal integer.
Note the following when using the %TONUMBER function:
If parm does not follow the format above, the %TONUMBER function returns
zero.
If you convert a correctly formed character field or literal that contains an
exponent, the %TONUMBER function returns a signed decimal of arbitrary
precision with a 32-bit scale.
Floating point values and integer values expressed in character form are
converted to a signed decimal of arbitrary precision with a 32-bit scale.
Precision may be lost when you convert numerical values expressed in
character form that exceed a certain number of digits.
If parm is a number, this function returns a number.

Result data type

Numeric.

Examples
Input value (parm) Result
"12.45" Returns a floating point value of 12.45. If
this function is mapped to an integer
column, then it truncates the decimal part is
truncated and returns 12.
"3" Returns an integer value of 3.

242 InfoSphere Change Data Capture Management Console: Administration Guide

 Input value (parm) Result
"-12.4" Returns a floating point value of -12.4.
"-0920824" Returns an integer of -920824. Leading zeros
are removed.
NULL If the column from which this function is
called is nullable, this function returns
NULL. Otherwise, it returns an integer value
of 0.
"ABC" Returns an integer value of 0, because the
%TONUMBER function cannot convert
character strings that do not conform to the
data format described for parm.
"" Returns an integer value of 0. The input
value is valid as a character string, but it
cannot be converted to a numeric value.
"12345678901234567.89" Returns a non-zero result, but precision may
be lost.
"- 10" Returns an integer value of 0.
"911HELLO" Returns an integer value of 0.
"+2.2e+2" Returns a floating point value of 220.
" 4.5E3" Returns a floating point value of 4500.
"$1000" Returns an integer value of 0.
"-.1e0" Returns a floating point value of -0.1.
"44 90" Returns an integer value of 0.
" 66.67" Returns a floating point value of 66.67

Time conversion%TOTIME
Use this function when you want InfoSphere CDC to convert a character, numeric,
or time data type to a time data type during replication. You can convert from
different formats based on the type of the input value.

Use this function to when you want InfoSphere CDC to track the date and time
when it inserts or updates a row in source and target columns. This function uses
the system clock on the source or target.

Note: InfoSphere CDC for IBM i does not support this function.

Syntax
%TOTIME(<time>)

Parameters

timeSpecifies a column or literal that can have one of the following types:
v Time, in the format HMMSS or HHMMSS. For example, 71500 represents 7:15
AM and 223000 represents 10:30 PM.
v Numeric. This value must be positive, and if it contains a fractional part, the
fraction must be zero.
v Character, in one of the following formats:
[whitespace] digit digit digit digit digit digit [whitespace]

Column functions 243

 This format lets you specify a time value that contains six consecutive digits.
Any number of blank characters can precede or follow the six digits. For
example, %TOTIME ( 012537 ) returns 01:25:37.
[whitespace] digit [digit] separator digit [digit] [separator digit [digit]]
[whitespace]

This format lets you specify a time value that contains valid separator characters
(colon, comma, period or one or more spaces) between hours, minutes, and
seconds. Any number of blank characters can precede the first digit or follow the
last digit.
You cannot specify more than one separator character in the time value. For
example, %TOTIME (12:05.20) is not valid. You can omit the number of seconds,
in which case the %TOTIME function assumes zero seconds. For example,
%TOTIME ("12:05") returns 12:05:00. You can omit leading zeros in the number of
hours, minutes, and seconds. For example, %TOTIME ("12 5 20") returns 12:05:20.
[whitespace] digit [digit] separator digit [digit] [whitespace] {A | a | P | p}
[{M | m}] [whitespace]

This format lets you specify a time value that indicates AM or PM. You can
specify AM and PM in a number of different ways, such as A, AM, Am, a, aM,
am, P, or PM. Any number of blank characters can precede the first digit or
follow the AM/PM specification.
You cannot specify more than one separator character in the time value. For
example, %TOTIME ("04: 20 PM") is not valid. You cannot specify seconds in this
format. If you do so, the %TOTIME function assumes zero seconds. You can
omit leading zeros in the number of hours and minutes. For example, %TOTIME
("3 5 P") returns 15:05:00.

Note the following with respect to return values for this function:
v If your input value is NULL, this function returns NULL.
v If your input value is a Time this function returns a Time.
v If InfoSphere CDC encounters an error when parsing the input value, this
function returns 00:00:00".

Result data type

This function returns a Time.

Examples

The following examples show the colon (:) as the separator character in the
returned ISO (International Organization for Standardization) time values.
Depending on your environment, a different character may separate the hours,
minutes, and seconds in the output time.

Input value (parm) Result

" 012537 " 01:25:37
"22:4:12" 22:04:12
"4:05P" 16:05:00
"2 5 Am" 02:05:00
204521 20:45:21
91035.0000 09:10:35

244 InfoSphere Change Data Capture Management Console: Administration Guide

 Input value (parm) Result
250521 00:00:00
"10: 10:35" 00:00:00

Conditional and variable functions

Use the %IF column function when you want InfoSphere CDC to evaluate an
expression and return different results. Use the %VAR function when you want
InfoSphere CDC to declare a new variable, assign a value to it, or retrieve the
value of an existing variable.

See also:
Conditional%IF
Variable%VAR on page 246

Conditional%IF
Use this function when you want InfoSphere CDC to evaluate a conditional
expression and return different results during replication.

Syntax
%IF(<conditional>, <expression_if_true>, <expression_if_false>)

Parameters
v conditionalSpecifies a conditional expression that evaluates to true or false. The
conditional expression must compare identical data types.
v expression_if_trueSpecifies an expression that is evaluated if the condition is
true.
v expression_if_falseSpecifies an expression that is evaluated if the condition is
false.

The values returned by expression_if_true and expression_if_false must both be of the

same data type.

Result data type

The type of data returned by the true (expression_if_true) and false

(expression_if_false) expressions.

Examples

%IF(ID=1, "ID is 1", "ID is not 1")

If the value in the ID column is equal to 1, this function returns the string "ID is 1".
Otherwise, it returns the string "ID is not 1".

%IF(DATSTR="010101", %TODATE(19010101, "*YYMD"), %IF(DATSTR="999999",

NULL, %TODATE(DATSTR, "*YMD")))

If a value in the DATSTR column is "010101", this function returns 1901-01-01. If a

value in DATSTR is "999999", it returns NULL. In all other cases, it returns
equivalent dates to values in DATSTR. For example, for a value of "710723" in the

Column functions 245

 DATSTR column, this example returns 71-07-23.
Related reference
Date conversion%TODATE on page 238
Variable%VAR

Variable%VAR
Use this function when you want InfoSphere CDC to evaluate a conditional
expression and return different results during replication.

Syntax
%VAR(<variable_name>, [expression])

Parameters
v variable_nameSpecifies the name of the defined or retrieved variable.
v expressionSpecifies a literal or a complex expression. This parameter is
optional. If you specify it, the function creates a new variable, assigns the given
value to it, and returns the value of the variable. If the variable already exists,
the function assigns the new value to it.
If you omit this parameter, the function retrieves the value of the variable,
provided that the variable is defined (using the %VAR function) in a preceding
column or previously in the current expression.
You can pass a variable in the same row, from column to column, in ascending
column sequence. However, you cannot pass a variable between rows.

Result data type

The type of data assigned to the variable (variable_name).

Examples

%VAR(SBTTL, PRICE*QTY)

If the value in the PRICE column is 10 and the value in the QTY column is 5, then
this function assigns the value 50 to the SBTTL variable, and returns the value 50.
%VAR(SBTTL) If SBTTL is defined either in an expression for a preceding column
or earlier in the current expression, this function returns the current value of the
SBTTL variable.

%IF(%VAR(QTY, QTYORD + QTYBACKORD) <100, %VAR(QTY) * PRICE, %VAR(QTY) *

PRICE * (1- DISCOUNT))

Sets the QTY variable to QTYORD plus QTYBACKORD. If QTY is less than 100,
then the result of the expression is QTY * PRICE. Otherwise, the result of the
expression is QTY * PRICE * (1 - DISCOUNT).

246 InfoSphere Change Data Capture Management Console: Administration Guide

 Related reference
Conditional%IF on page 245

Data functions
Use these functions when you want InfoSphere CDC to retrieve column values
during replication. When you use these functions, InfoSphere CDC can return the
value of a source column before applying an update, the value of a target column
before applying an update, and the value of a column for a specific row in a table.

See also:
Before value%BEFORE
Current value%CURR
Retrieve column%GETCOL (DB2 for i) on page 249
Retrieve column%GETCOL (Dynamic SQL) on page 252
Retrieve column%SELECT on page 255

Before value%BEFORE
Use this function when you want InfoSphere CDC to retrieve the value of a source
column before applying an update.

Syntax
%BEFORE(<parm>)

Parameters

parmSpecifies the name of a source column. You cannot specify a journal control
field, an expression, or a column function as the input parameter.

Result data type

The data type of the source column (parm). When a row is inserted into the target
table, including all rows that are inserted during a refresh, this function returns
NULL. Otherwise, this function returns the appropriate default value for the data
type of the target column.

Examples

%BEFORE(CRLIMIT)

Returns the previous value in the CRLIMIT column, before it was updated on the
source by the change being replicated.
Related reference
Current value%CURR

Current value%CURR
Use this function when you want InfoSphere CDC to retrieve the value of a target
column before applying an update on a source column.

By default %CURR will only access the target database to retrieve the current
value when the source operation is an UPDATE. In general it provides no value if

Column functions 247

 done for an INSERT or DELETE. If you are using %CURR for Adaptive Apply or
with conflict resolution enabled, then you may want InfoSphere CDC to access the
target database for all source operations. This behavior can be enabled by adding
the enable_percent_curr_for_all_db_operations system parameter and then setting
it to true.

Note: InfoSphere CDC for z/OS does not support this function.

Syntax
%CURR(<parm>)

Parameters

parmSpecifies the name of a source column. You cannot specify a journal control
field, an expression, or a column function as the input parameter.

Result data type

The data type of the target column (parm). When a row is inserted into the target
table, including all rows that are inserted during a refresh, this function returns the
appropriate default value for the data type of the target column.

The %CURR function returns the value of the target column as single-byte
characters, even if the source column contains multibyte data.

Note: This function does not support the retrieval of large object columns such as
BLOB, CLOB, and XML from the target database.

Examples

%CURR(BALANCE)

Returns the current value of the target column BALANCE. In an expression, the
current balance would be placed in the derived column before the update to
BALANCE is applied to the target table.

%CURR(BALANCE) - %BEFORE(BALANCE)

Calculates the difference between the values in the source and target columns
before an update is made. If the result is not equal to zero, the column values were
not the same before the update was applied on the source and on the target. You
can use this example only for numeric fields.

(SRCCNT - %BEFORE(SRCCNT)) + %CURR(TGTTOT)

You can use this example to maintain the total of two or more numeric column
values that are contained in the same table on different datastores.

In each source table, the SRCCNT column is mapped to the corresponding target
column with the same name. The expression in this example is assigned to the
derived column TGTTOL on the target. When a value in a SRCCNT column is
updated, the difference between the new value and the previous value is
calculated using the %BEFORE function. This difference is added to the current
sum stored in the derived column TGTTOL. The result of the expression is
assigned to the derived column.

248 InfoSphere Change Data Capture Management Console: Administration Guide

 %CURR(%TONUMBER(EMPNO))

InfoSphere CDC generates an error when verifying the expression, because

%CURR does not accept another column function (in this example, %TONUMBER)
as its parameter.
Related reference
Before value%BEFORE on page 247

Retrieve column%GETCOL (DB2 for i)

Use this function when you want InfoSphere CDC to retrieve the value of a
column for a specific row in a table. You can also use this function, with a subset
of parameters, so that InfoSphere CDC returns additional columns when it has
previously invoked a %GETCOL function.

You can use the %GETCOL function in expressions to perform the following
operations:
v Obtain columns from one or more keyed secondary tables and join them with an
existing primary table before sending data to the target. The primary table refers
to the source table being replicated. The secondary tables refer to tables
referenced in the %GETCOL function.
v Specify how keys of the secondary tables are populated, to allow InfoSphere
CDCto perform the necessary secondary reads.
v Use columns from secondary tables that were retrieved previously to populate
keys for subsequent reads (the population of key column values is not restricted
to primary columns only).
v Specify the order that table reads are performed.
v Condition the table reads that are performed.
v Read tables external to InfoSphere CDC to perform dynamic translations on the
target.

Note: This topic contains information about the %GETCOL function supported by
InfoSphere CDC for IBM i.

Long syntax formatreads from database

%GETCOL(<column_name>, <table_name>, [default_value], [record_format],
[<key_count>, <key_value1>, <key_value2>, ..., <key_valuen>])

This function reads a table and returns the value of the column specified, based on
the key column values that are identified. If more than one row satisfy the key
requirements specified, then this function returns the first row only. If the read is
unsuccessful, then this function returns the default value specified and sends a
message to the appropriate message queue.

The specified column in the table must exist when specifying the expression.

Short syntax formatreads from existing &GETCOL result

%GETCOL(<column_name>, <table_name>)
%GETCOL(<column_name>, <table_name>, [default_value])
%GETCOL(<column_name>, <table_name>, [default_value]), [record_format])

This function returns the value of the specified column from a row retrieved by a
previous %GETCOL function invocation. The short syntax lets you retrieve more than
one column from a table (that was read previously using the %GETCOL function),

Column functions 249

 without reading the table again. The previous %GETCOL function invocation must be
for the same journal entry during continuous mirroring or the same row during
refresh.

The <table_name> and record_format parameters specified in the short format of the
%GETCOL function invocation must match the <table_name> and record_format
parameters specified in the long format of the %GETCOL function invocation.

Parameters
v column_nameSpecifies the name of a column. You cannot specify an expression
for this parameter.
v table_nameSpecifies the name of a table. This table must be keyed. You cannot
specify an expression for this parameter. You can specify the table name using
one of the following formats:
The library, file, and member names are specified. For example,
"LIBRARY/FILE(MEMBER)".
The library and file are specified. InfoSphere CDC assumes a default value of
*FIRST for the member name. For example, "LIBRARY/FILE".
The file is specified. InfoSphere CDC assumes a default value of *LIBL for the
library name and a default value of *FIRST for the member name. For
example, "FILE".
The file and member names are specified. InfoSphere CDC assumes a default
value of *LIBL for the library name. For example, "FILE(MEMBER)".
v default_valueSpecifies a default value to return if the read fails. This value must
be a literal or constant, depending on the data type of the specified column. For
character, date, time, and timestamp data types, you must enclose values of this
parameter in double quotes. For example, "NO SALESREP" or "1995-05-10". If
you specify NULL as the default value, then the column must be nullable. You
cannot specify an expression for this parameter.
If you omit this parameter, then you must enter a comma instead of the
parameter value to indicate its position in the parameter list.
If you omit this parameter, then this function returns a default value according
to the data type of the column specified.

Field type Default value

Character Blank character
Decimal (packed) Zero
Numeric (zoned) Zero
Real (4byte floating point) Zero
Float (8byte floating point) Zero
Date 0001-01-01 (Date Zero). This applies to all
date formats except *JUL (Julian).
1940-01-01 (Date Zero). This applies to the
*JUL (Julian) date format.
Time 00:00:00 (Time Zero)
Integer (4 bytes) Zero
Small integer (2 bytes) Zero
Timestamp 0001-01-01 00:00:00 (Timestamp Zero)

250 InfoSphere Change Data Capture Management Console: Administration Guide

v record_formatSpecifies the record format for the record to read. You cannot
specify an expression for this parameter. Specify this parameter if more than one
record format exist. If you omit this parameter, then you must enter a comma
instead of the parameter value to indicate its position in the parameter list. If
you omit this parameter, then InfoSphere CDC reads the first record format.
v key_countIndicates the number of key values specified as parameters. It should
be the number of key columns of the record format selected. It must be an
integer greater than 0. You cannot specify an expression for this parameter. If
you omit this parameter, then InfoSphere CDC assumes a default value of 1.
v key_value1, key_value2, ...key_valuenSpecifies the key values to use when
performing the read. These key values must match the key columns of the table
to read. Character data passed as key parameters is padded with blank
characters, or truncated if the length does not match the length of the key
column.
The key value can be either a primary table column (direct column mapping) or
an expression. Some examples include:
An expression performed on a primary table column that matches the
definition of the key column in the table to read.
A column from a previous read using the %GETCOL function.
An expression performed on a column that was previously read using the
%GETCOL function.
You must specify these parameters if the key_count parameter is specified.

Result data type

The data type of the column retrieved (column_name). The %GETCOL function returns
the value of the column as single-byte characters, even if the source column
contains multibyte data.

Examples

The following examples are of scenarios where the %GETCOL function is used:

%GETCOL (CUSTNAME, "PRODLIB/CUSTMAST")

Retrieves the CUSTNAME column from a previous read of the CUSTMAST table
in library PRODLIB, member *FIRST, and record format *FIRST. If the read is
unsuccessful (for example, not found) and assuming that the data type for the
CUSTNAME column is CHARACTER, then this function returns blanks characters.

%GETCOL (CUSTNAME, "PRODLIB/CUSTMAST", "NO CUSTMAST")

Retrieves the CUSTNAME column from a previous read of the CUSTMAST table
in library PRODLIB, member *FIRST, and record format *FIRST. If the read is
unsuccessful (for example, not found), then this function returns "NO
CUSTMAST".

%GETCOL (CUSTNAME, "PRODLIB/CUSTMAST",, "FMT2")

Retrieves the CUSTNAME column from a previous read of the CUSTMAST table
in library PRODLIB, member *FIRST, and record format "FMT2". The previous read
must have "FMT2" specified for the record format.

Column functions 251

 If the read is unsuccessful (for example, not found) and assuming that the data
type for the CUSTNAME column is CHARACTER, then this function returns blank
characters.
Related concepts
%GETCOL column function scenarios (DB2 for IBM i) on page 267
%GETCOL column function scenarios (Dynamic SQL) on page 269
Related reference
Retrieve column%GETCOL (Dynamic SQL)
Retrieve column%SELECT on page 255

Retrieve column%GETCOL (Dynamic SQL)

Note: This topic contains information about the %GETCOL function supported by
any InfoSphere CDC product except for InfoSphere CDC for IBM i.

Use this function to perform a secondary table column lookup based on the
specified secondary columns. The %GETCOL function retrieves data from secondary
table columns. To use this function before replication, you must add a derived
column to the primary table and enter an expression for that column that uses the
%GETCOL function. You can also use this function when entering an expression for a
target column.

To use this function, the secondary tables must have WHERE clause columns. The
WHERE clause columns must be specified by name and you must provide a value
expression for every WHERE clause column. Any column in the replicating table can
be referenced by value expressions, and the captured column value is substituted
in the expression.

If the secondary columns have different data types, then you must convert them to
appropriate data types using conversion column functions such as %TOCHAR.

If you are using InfoSphere CDC for z/OS, then see %GETCOL and %SELECT
Function Calls and Processing Efficiency in your InfoSphere CDC for z/OS
documentation for information about performance considerations when using the
%GETCOL or %SELECT column functions.

This function gives you the option of specifying the encoding to be used for a
column in a secondary table. You should only specify a value for ENCODING if
you want to override or change the default encoding of the column as set in your
database and detected by InfoSphere CDC. When retrieving data from a secondary
table, InfoSphere CDC will use the following criteria (in the order specified) to
determine the encoding for a column:
1. The ENCODING specification for a column in a secondary table that is
explicitly identified in %GETCOL.
2. The ENCODING specification for a column in your subscription if the
secondary table is specified in the subscription. This encoding value is specified
on the Encoding tab in the Mapping Details view of Management Console
3. The default encoding of the column in your database.

Long syntax formatreads from database

%GETCOL(<secondary_column_name>, <table_name>, [default_value],
<secondary_column_name1>, <key_value1>, [<secondary_column_name2>
, <key_value2>, [...], <secondary_column_namen>,
<key_valuen>])

252 InfoSphere Change Data Capture Management Console: Administration Guide

This function reads a table and returns the value of the column specified, based on
the secondary column names and values that are identified. If you specify a table
or column name that contains spaces, then you must enclose that name in square
brackets. For example, enter [EMP NY] to reference a table named "EMP NY".

Long syntax format with optional ENCODING specification

%GETCOL(<secondary_column_name> [ENCODING <encoding>], <table_name>,
[default_value], <secondary_column_name1> [ENCODING <encoding1>],
<key_value1>, [<secondary_column_name2> [ENCODING <encoding2>], <key_value2>,
[...], <secondary_column_namen> [ENCODING <encodingn>], <key_valuen>])

Short syntax formatreads from existing &GETCOL result

%GETCOL(<secondary_column_name>, <table_name>, <default_value>)

This function returns the value of a the specified column from a row retrieved by a
previous %GETCOL function invocation. The short syntax lets you retrieve more than
one column from a table (that was read previously using the %GETCOL function),
without reading the table again. You must use the long syntax format of this
function to specify an encoding.

The <table_name> parameter specified in the short format of the %GETCOL function
invocation must match the <table_name> parameter specified in the long format of
the %GETCOL function invocation. If the read is unsuccessful or a previous %GETCOL
function invocation was not performed, then InfoSphere CDC generates an error
message and sets the values of the derived column in which the %GETCOL function
is used to default values, based on the data type of the derived column.

Parameters
v secondary_column_nameSpecifies the name of a column in a secondary table.
You cannot specify an expression for this parameter. If the specified column does
not exist in the secondary table, then InfoSphere CDC generates an error
message when verifying the expression that contains the %GETCOL function. If you
want to override or change the default encoding for a column as set by your
database and detected by InfoSphere CDC, you have the option of using
ENCODING <encoding> to specify the ISO/IANA name for the encoding of the
column. ENCODING <encoding> is not supported for InfoSphere CDC for z/OS.
This option is only supported when using the long syntax format.
If you are using InfoSphere CDC for IBM Informix Dynamic Server, the values
you specify here must be in lower case.
v table_nameSpecifies the name of a table. Note the following when specifying
this parameter:
If you installed InfoSphere CDC for Oracle, you can specify the table name in
the format '<OWNER_NAME>.<TABLE_NAME>', where the owner and table
are in uppercase. If you omit the owner name, then InfoSphere CDC assumes
that the owner is the user that installed InfoSphere CDC. If ownership of the
table cannot be determined, then InfoSphere CDC assumes the default value
of PUBLIC for the owner name. If you installed InfoSphere CDC for Microsoft
SQL Server or InfoSphere CDC for Sybase, you must specify the table name
in the format "<database_name>.<owner_name>.<table_name>".
If you installed InfoSphere CDC for z/OS, you must specify the table name in
the format "<owner_name>.<table_name>" or <owner_name>.<table_name>.
If you installed InfoSphere CDC for DB2 LUW, you must specify the table
name in the format "[owner_name].<table_name>" or
'[owner_name].<table_name>'.

Column functions 253

 v default_valueSpecifies a default value to return when no row can be found in
the secondary table using the key value that matches the value of the referring
(foreign) secondary column in the primary table row. If the corresponding row
cannot be found in the secondary table, then the default value populates the
derived column for the row sent to the target. If you specify NULL as the
default value, then the column must be nullable. For certain InfoSphere CDC
products, this is a required parameter. InfoSphere CDC generates an error if a
default value is required, but is not specified in a %GETCOL function invocation. If
you omit this parameter, then you must enter two consecutive commas (for the
long syntax) or a comma (for the short syntax) prior to the right parenthesis to
indicate its position in the parameter list. In this case, the %GETCOL function
returns a default value according to the data type of the column specified.
v secondary_column_name1, secondary_column_name2,
...secondary_column_namenIdentifies the secondary column name in the
secondary table used to retrieve the secondary column specified by
secondary_column_name.
The DB2 UDB for z/OS API requires that the column specified in
secondary_column_name is not nullable. InfoSphere CDC for z/OS generates an
error message if it encounters a NULL key value when processing the %GETCOL
function. To ensure that the %GETCOL function is invoked only for records with
non-NULL key values, use the %IF function.
If you are using InfoSphere CDC for IBM Informix Dynamic Server, the values
you specify here must be in lower case.
v key_value1, key_value2, ...key_valuenSpecifies an associated key value for each
secondary column name. The key value can be any expression. If you specify a
primary column name, then InfoSphere CDC uses the after image value of that
column as the key_value for the secondary column in the secondary table to
locate the corresponding row in the secondary table. You can specify multiple
secondary column names and key value pairs.
If you are using InfoSphere CDC for IBM Informix Dynamic Server, the values
you specify here must be in lower case.

Note: For InfoSphere CDC for z/OS, you can specify up to nine
secondary_column_name/key_value pairs.

Result data type

The data type of the column retrieved (secondary_column_name). The %GETCOL

function always returns data that matches the data type of the column. For
character (String) data, it returns a UTF-8 string.

Examples

For examples and scenarios for the %GETCOL function, see the related topics below.

254 InfoSphere Change Data Capture Management Console: Administration Guide

 Related concepts
%GETCOL column function scenarios (Dynamic SQL) on page 269
%GETCOL column function scenarios (DB2 for IBM i) on page 267
Configuring MBCS encoding conversion between your source and target on page
167
Related reference
Character conversion%TOCHAR on page 235
Retrieve column%GETCOL (DB2 for i) on page 249
Conditional%IF on page 245

Retrieve column%SELECT
Use this function to specify a valid SQL SELECT statement that retrieves one or
more column values from a secondary table so that they can be logically joined to
a primary table record.

For information about performance considerations when using the %GETCOL or

%SELECT column functions, see the "%GETCOL and %SELECT Function Calls and
Processing Efficiency" section in your InfoSphere CDC for z/OS documentation.
You can specify only one SQL SELECT statement in each %SELECT function.

To use this function, the z/OS user identifier that is used to start the InfoSphere
CDC address space must have sufficient DB2 for z/OS privileges to perform SQL
SELECT statements.

Note: This function is only supported by InfoSphere CDC for z/OS.

CAUTION:
The use of SQL SELECT statements may constitute a security concern in your
environment. Certain clauses and functions may have side effects that result in
the changing of DB2 table data, the generation of data outside of the control of
DB2 or both. Therefore, you should exercise caution when using the %SELECT
function to issue SQL SELECT statements.

Syntax
%SELECT(<sql_select_stmt>, <parm>, <parm2>, ..., <parm>, [default_value],
[default_value2], ...,[default_value])

Parameters
v sql_select_stmtSpecifies a character string containing a valid SQL SELECT
statement. The statement must be valid according to DB2 for z/OS usage rules.
For usage rules, see your DB2 for z/OS documentation. You must use parameter
placeholders to refer to values that are not available until the expression is being
executed. To identify parameter placeholders in the SQL SELECT WHERE
clause, use question marks (?).
In the SQL WHERE clause, you can use any operators that are supported by
DB2 for z/OS, such as IN. For information about other operators that you can
use, see your DB2 for z/OS documentation.
v parm1, parm2, ..., parmnSpecify literals, column functions, expressions,
expression variables, or primary table columns. In the WHERE clause, the value
specified for parm1 replaces the first question mark, the value specified for

Column functions 255

 parm2 replaces the second question mark in the WHERE clause, and so on. You
cannot specify NULL for any parameter placeholder. default_value1,
default_value2, ...,
v default_valuemSpecify default values that the function returns for each column
when the record specified by the WHERE clause does not exist in the secondary
table. If you do not specify a default value for a column and the secondary table
record does not exist, then this function returns an appropriate value, based on
the data type of the column. For example, zero for numeric-based columns,
zero-length strings for character-based columns, and so on. To specify a default
value for a column that is not listed first in the SQL SELECT statement, you
must specify default values for all preceding columns.
Note the following when specifying parameters for this function:
The number of parameters cannot exceed 21.
You must specify a minimum of two parameters. If you only want to specify
the SQL SELECT statement parameter, then you must also specify another
parameter for the function. See examples below for situations where you
must specify an unused parameter.

Result data type

The data type of the first secondary table column listed in the SQL SELECT
statement.

The result of the %SELECT function is a value from the first column specified in
the SQL SELECT statement. If two or more column values are retrieved by the SQL
SELECT statement, then these values are assigned to variables. By default, the
variable names are the same as the corresponding column names. If these variable
names cannot be defined, then the names are set to COLn, where n is the numeric
position, starting at 1, of the corresponding column in the SQL SELECT statement.

Using the %VAR function in expressions, you can retrieve the values assigned to
variables and map them to subsequent columns in the primary table. Using a
single %SELECT function to retrieve all secondary table column values and then
using the %VAR function to map to subsequent columns is more efficient than
invoking the %SELECT function multiple times to retrieve each column value
individually.

Note: If you have defined variables that have the same names as those created by
InfoSphere CDC automatically, then the previously defined variables will be
overwritten. Therefore, make sure existing variable names that you have defined
do not conflict with variable names created by InfoSphere CDC.

Examples

The following examples use the relationship between primary and secondary
tables:

256 InfoSphere Change Data Capture Management Console: Administration Guide

%SELECT("SELECT COUNTRY FROM DB1.GSMITH.COUNTRY WHERE BRANCH = ?",
EMPBRANCH)

Assuming the primary and secondary tables shown above, you map the %SELECT
function to the EMPCOUNTRY column in the EMPLOYEE table.

For an employee in the EMPLOYEE primary table, this example returns their
country from the COUNTRY secondary table record. If COUNTRY does not
contain a record that satisfies the condition in the WHERE clause, then this
function returns the default value for the data type of the COUNTRY column. For
example, blank characters if the data type is character.

%SELECT("SELECT Q1, Q2, Q3, Q4 FROM DB1.GSMITH.SALES WHERE EMP = ? AND ? =

4", EMPID, EMPBRANCH, 0, 0, 0, 0)

Assuming the primary and secondary tables shown above, you map the %SELECT
function to the EMPQ1 column in the EMPLOYEE table.

For an employee in the EMPLOYEE primary table, who works at Branch 4, this
example returns their first quarter sales figure from the SALES secondary table
record.

Since this example returns more than one column value, InfoSphere CDC defines
three variables, named Q2, Q3, and Q4, to maintain the second, third, and fourth
quarter sales figures, respectively. You can retrieve these values using the %VAR
function and map them to the EMPQ2, EMPQ3, and EMPQ4 columns in
EMPLOYEE.

If SALES does not contain a record that satisfies the condition in the WHERE
clause, then the function returns 0. In addition, InfoSphere CDC sets the three
variables Q2, Q3, and Q4 to 0.

%SELECT("SELECT INCOME, CODE, LASTADJDATE, NEXTADJDATE FROM

DB1.GSMITH.SALARY WHERE EMP = ? AND BRANCH = ?", EMPID, EMPBRANCH, 0, "Z",
1970-01-01)

Assuming the primary and secondary tables shown in the previous image, you
map the %SELECT function to the EMPINCOME column in the EMPLOYEE table.

For an employee in the EMPLOYEE primary table, this example returns their
income from the SALARY secondary table record.

Since this example returns more than one column value, InfoSphere CDC defines
three variables, named CODE, LASTADJDATE, and NEXTADJDATE, to maintain

Column functions 257

 the other items of salary information. You can retrieve these values using the
%VAR function and map them to columns that you must add to the primary table.

If SALARY does not contain a record that satisfies the condition in the WHERE
clause, then:
v The %SELECT function returns 0.
v The CODE variable is set to "Z".
v The LASTADJDATE variable is set to 1970-01-01.
v The NEXTADJDATE variable is set to 1901-01-01 (the z/OS default date value).

%SELECT("SELECT INCOME, LASTADJDATE, CODE, NEXTADJDATE FROM

DB1.GSMITH.SALARY WHERE EMP = ? AND BRANCH = ?", EMPID, EMPBRANCH, 0,
1970-01-01)

In this example, you must specify a default value for LASTADJDATE only.Since
this column is listed third in the SQL SELECT statement, you must also specify
default values for the INCOME and CODE columns. To eliminate the need to
specify a default value for CODE, reference LASTADJDATE before CODE in the
SQL SELECT statement.

%SELECT("SELECT USED FROM DB1.GSMITH.VACATION WHERE EMP = ? AND EMPCOUNTRY

IN (USA, UK, JAPAN, FRANCE)", EMPID, 0)

Assuming the primary and secondary tables shown in the previous image, you
map the %SELECT function to the EMPVACUSED column in the EMPLOYEE
table.

For an employee in the EMPLOYEE primary table located in United States, United
Kingdom, Japan, or France, this example returns the amount of vacation used from
the VACATION secondary table record. If VACATION does not contain a record
that satisfies the condition in the WHERE clause, then the %SELECT function
returns 0.

%SELECT("SELECT NEXT VALUE FOR SEQ1 FROM SYSIBM.SYSDUMMY1", 1)

This example returns the next value for sequence SEQ1. In this case, the data type
of the result is the same as the data type of the sequence object. This example uses
the %SELECT function to retrieve the next value for a sequence in DB2 for z/OS
V8 or higher. SYSDUMMY1 is an existing DB2 dummy system table referenced in
the SQL SELECT statement to satisfy syntax requirements.

You must enter any integer value for the second parameter, in order to call the
function. For example, 1.

For information about sequences and the types of values that you can generate
from sequences, see your DB2 for z/OS documentation.

%SELECT("SELECT PREVIOUS VALUE FOR SEQ2 FROM SYSIBM.SYSDUMMY1", 24)

This example returns the previous value for sequence SEQ2. In this case, the data
type of the result is the same as the data type of the sequence object.

258 InfoSphere Change Data Capture Management Console: Administration Guide

 This example uses the %SELECT function to retrieve the previous value for a
sequence in DB2 for z/OS V8 or higher. SYSDUMMY1 is an existing DB2 dummy
system table referenced in the SQL SELECT statement to satisfy syntax
requirements.

You must enter any integer value for the second parameter, in order to call the
function. For example, 24.

For information about sequences and the types of values that you can generate
from sequences, see your DB2 for z/OS documentation.

User exit functions

Use these functions to call user exit programs from expressions. Depending on the
InfoSphere CDC platform you have installed, you can call a stored procedure or
another type of user exit program using a column function.

See also:
Stored procedure%STPROC
User exit%USER on page 260
User exit%USER (InfoSphere CDC for Microsoft SQL 5.x) on page 264
User Exit%USERFUNC on page 265

Stored procedure%STPROC
Use this function to call a stored procedure. You can call a stored procedure from a
derived column on the source or create an expression on the target.

Note: InfoSphere CDC for z/OS and InfoSphere CDC for DB2 UDB do not
support this function. On the z/OS platform, use the %USER function to call a
user exit program that issues SQL statements.

Syntax
%STPROC(stored_procedure_name, <parm1>, <parm2>, ..., <parm20>)

Parameters
v stored_procedure_nameSpecifies the name of the stored procedure in the default
database. You must enclose values of this parameter in single quotes. If you
installed InfoSphere CDC for Microsoft SQL Server, you must specify the name
of the stored procedure in the format
<databae_name>.<owner_name>.<stored_procedure_name>. The database and owner
name are not required if the stored procedure is defined in the default database.
v parm1, parm2, ..., parm20Specify columns or literals that are passed as
parameters to the stored procedure (maximum 20). The type and order of the
parameters specified in the %STPROC function invocation must match the type
and order of the parameters defined in the stored procedure.
If you installed InfoSphere CDC for Sybase, the first parameter defined in the
stored procedure specifies the value returned by the function. Do not specify this
parameter in the list of parameters for the %STPROC function (parm1, parm2, ...,
parm20).
You can omit any number of trailing parameters. InfoSphere CDC assumes the
default value if a parameter is not specified. For example, for a stored procedure

Column functions 259

 with five parameters, if you specify values for the first two parameters only,
InfoSphere CDC assigns default values to the last three parameters.

Result data type

The data type of the result returned by the stored procedure.

Examples

The following example returns the customer name that corresponds to a specified
customer identification number.

Perform the following steps:

1. Define a stored procedure, as presented below, in the default database:
v If you installed InfoSphere CDC for Microsoft SQL Server or InfoSphere CDC
for Sybase:
create procedure CUSTNAME @CUSTNAME varchar(30) OUT, @CUSTID int as
select @CUSTNAME=name from customer where custno=@CUSTID
v If you installed InfoSphere CDC for Oracle:
create or replace function custname (custid integer)
return varchar2 as
nameFound varchar2(30);
begin
select name1 into nameFound from customer where custno = custid;
return nameFound;
end custname;
2. Use the following column function:
%STPROC('CUSTNAME, CUSTOMER_ID)
This call returns the customer name that corresponds to the customer
identification number CUSTOMER_ID.
Related tasks
To add a derived column on page 155
To map an expression to a target column on page 151
Related reference
User exit%USER

User exit%USER
Use this function to call a user exit program from an expression. This function
provides flexibility when complex logic that cannot be expressed using the
provided column functions is required. You can use this function to call a user exit
program with input parameters.

For more information about user exit programs, see the appropriate InfoSphere
CDC user exits guide.

Note: InfoSphere CDC for Microsoft SQL Server does not support this function. If
you are using an InfoSphere CDC product other than InfoSphere CDC for z/OS,
you cannot use this function to call a stored procedure.

Syntax
%USER(<program_name>, <parm1>, <parm22>, ..., <parmn>

260 InfoSphere Change Data Capture Management Console: Administration Guide

Parameters
v program_nameSpecifies the name of the user exit program. You must enclose
values of this parameter in single quotes. You can write the user exit program in
any high-level language. You must place an executable object for the user exit
program in the InfoSphere CDC installation directory prior to starting refresh or
mirroring.
v parm1, parm2, ..., parmnSpecify columns or literals that are passed as
parameters to the user exit program (maximum 20).
In the user exit program that you write, you must declare a data structure that
defines specific fields for the result and each input parameter (parm1, parm2, ...,
parmn).

Field Length and data type Description

DATATYPE Two-byte binary Specifies the data type of the
result or input parameter:
v 1Character
v 2Date
v 3Float
v 4Integer
v 5Packed numeric
v 6Time
v 7Zoned numeric
LENGTH Two-byte integer Specifies the length of the
result or input parameter in
bytes.
DIGITS Two-byte binary Specifies the number of
digits in the result or input
parameter.
DECPLC Two-byte binary Specifies the number of
decimal places in the result
or input parameter.
NULLIND Two-byte binary Specifies whether or not the
result or input parameter is
NULL:
v 0Result or input
parameter is not NULL.
v 1Result or input
parameter is NULL.

Column functions 261

 Field Length and data type Description
DTMFMT Four-byte character Specifies the date format in
the result or input parameter:
v *USAUnited States date
format.
v *ISOISO (International
Organization for
Standardization) date
format.
v *EUREuropean date
format.
v *JISJapanese Industrial
Standard.
v *YMDThe date format is
yymmdd.
v *MDYThe date format is
mmddyy.
v *DMYThe date format is
ddmmyy.
<VALUE> Specifies one of the
following:
v For each input parameter,
the field that contains the
input parameter value
passed to the user exit
program.
v For the user exit program
result, the field that
contains the result
returned by the user exit
program.

The name of this field in the

user exit program is
user-defined. For example,
see the COBOL user exit
program below.

Result data type

The data type of the result returned by the user exit program.

Examples

%USER('USERSEL1, BRANCH)

This function calls the COBOL program USERSEL1, passing the BRANCH column
as a parameter. USERSEL1 checks whether or not BRANCH is set to '11'. If it is,
then the user exit program returns a one-byte character value of Y. Otherwise, it
returns a character value of N.

Note: The following user exit program is provided for illustration purposes only
and should be tested for all production environments.

262 InfoSphere Change Data Capture Management Console: Administration Guide

IDENTIFICATION DIVISION.
PROGRAM-ID. USERSEL1.
AUTHOR. IBM CORP.
INSTALLATION. DATAMIRROR CORP.
DATE-COMPILED.
*******************************************************************
* Program : USERSEL1.
* ----------------
* Version: 1.0
* ----------------
* Description: SAMPLE COBOL USER ENTRY POINT PROGRAM
* ----------------
*
******************************************************************
ENVIRONMENT DIVISION.
CONFIGURATION SECTION.
SOURCE-COMPUTER. IBM-AS400.
OBJECT-COMPUTER. IBM-AS400.
******************************************************************
* D A T A D I V I S I O N
******************************************************************
DATA DIVISION.
******************************************************************
* W O R K I N G S T O R A G E S E C T I O N
******************************************************************
WORKING-STORAGE SECTION.
*
01 DATATYPES COMP-4.
03 TYP-CHAR PIC S9(4) VALUE 1.
03 TYP-DATE PIC S9(4) VALUE 2.
03 TYP-FLOAT PIC S9(4) VALUE 3.
03 TYP-INTEGER PIC S9(4) VALUE 4.
03 TYP-PACKED PIC S9(4) VALUE 5.
03 TYP-TIME PIC S9(4) VALUE 6.
03 TYP-ZONED PIC S9(4) VALUE 7.
******************************************************************
* L I N K A G E S E C T I O N
******************************************************************
LINKAGE SECTION.
01 RETURN-VALUE.
03 RV-DATATYPE PIC S9(4) COMP-4.
03 RV-LENGTH PIC S9(4) COMP-4.
03 RV-DIGITS PIC S9(4) COMP-4.
03 RV-DECPLC PIC S9(4) COMP-4.
03 RV-NULLIND PIC S9(4) COMP-4.
03 RV-DTMFMT PIC X(4).
03 RV-SELECT PIC X(1).
01 PARM-1.
03 P1-DATATYPE PIC S9(4) COMP-4.
03 P1-LENGTH PIC S9(4) COMP-4.
03 P1-DIGITS PIC S9(4) COMP-4.
03 P1-DECPLC PIC S9(4) COMP-4.
03 P1-NULLIND PIC S9(4) COMP-4.
03 P1-DTMFMT PIC X(4).
03 P1-BRANCH PIC X(2).
******************************************************************
* P R O C E D U R E D I V I S I O N
******************************************************************
PROCEDURE DIVISION USING RETURN-VALUE
PARM-1.
ML-0010.
*
* This example program checks parm 1 for a value of '11 and if found,
* returns 'Y, else returns 'N.
*
* Define the Returned Value as a 1-byte character field.
*

Column functions 263

 MOVE TYP-CHAR TO RV-DATATYPE.
MOVE 1 TO RV-LENGTH.
MOVE ZERO TO RV-DIGITS.
MOVE ZERO TO RV-DECPLC.
MOVE ZERO TO RV-NULLIND.
MOVE SPACES TO RV-DTMFMT.
*
* Test for a value of '11 in the first parameter.
*
IF P1-BRANCH IS EQUAL TO '11
MOVE 'Y TO RV-SELECT
ELSE
MOVE 'N TO RV-SELECT.
EXIT PROGRAM.
Related reference
Stored procedure%STPROC on page 259
User exit%USER (InfoSphere CDC for Microsoft SQL 5.x)
User Exit%USERFUNC on page 265

User exit%USER (InfoSphere CDC for Microsoft SQL 5.x)

If you have installed InfoSphere CDC for Microsoft SQL Server, use this function to
call a stored procedure on the source. This function allows you to specify Microsoft
stored procedures as input parameters.

To call stored procedures in expressions defined on the target, use the %STPROC
function.

For information about creating Microsoft SQL Server stored procedures, see
InfoSphere CDC for Microsoft SQL Server User Exits Guide.

Note: This function is only supported by InfoSphere CDC for Microsoft SQL
Server on the source.

Syntax
%USER(<database_name>.<owner_name>.<stored_procedure_name>, <parm1>,
<parm2>, ..., <parm20>

Parameters
v database_nameSpecifies the name of the database where the stored procedure
resides.
v owner_nameSpecifies the owner of the stored procedure. For example, dbo.
v stored_procedure_nameSpecifies the name of the stored procedure.
v parm1, parm2, ..., parm20Specify columns or literals that are passed as
parameters to the stored procedure (maximum 20). The type and order of the
parameters specified in the %USER call must match the type and order of the
parameters defined in the stored procedure.
The first parameter defined in the stored procedure must be the OUTPUT
parameter followed by the input parameters. Do not specify this parameter in
the %USER parameter list (parm1, parm2, ..., parm20).
The number of parameters specified in the stored procedure must match the
number of parameters specified in Management Console.
You can omit any number of trailing parameters. InfoSphere CDC assumes the
default value if a parameter is not specified. For example, for a stored procedure

264 InfoSphere Change Data Capture Management Console: Administration Guide

 with five parameters, if you specify values for the first two parameters only,
InfoSphere CDC assigns default values to the last three parameters.

Result data type

The data type of the result returned by the stored procedure.

Examples

%USER("ibm.dbo.sp_date_diff",COL_DATE) %USER("ibm.dbo.sp_date_diff","12-
jan-2000")

The first call example specifies a source column name as input parameter
(COL_DATE), while the second call example specifies a value as input parameter
("12-jan-2000"). These examples assume that a stored procedure, similar to the
following, is defined in the database. The example stored procedure calculates the
difference in days between the current date and a date specified as parameter:
CREATE PROCEDURE dbo.sp_date_diff @out_int int output, @in_date datetime AS
select @out_int = DATEDIFF(day, @in_date, getdate()) GO
%USER("ibm.dbo.sp_join",col_item_number)
%USER("ibm.dbo.sp_join",12)

The first call example specifies a source column name as input parameter
(col_item_number), while the second call example specifies a value as input
parameter (12). These examples assume that a stored procedure, similar to the
following, is defined in the database. The example stored procedure performs a
join to a description table to get the description of an item given its item number:
CREATE PROCEDURE dbo.sp_join
@out_item_description varchar(10) output
@in_item_number int
AS
SELECT @out_item_description = inventory_db.dbo.description.item_desc
FROM inventory_db.dbo.item_list INNER JOIN
inventory_db.dbo.description ON inventory_db.dbo.item_list.item_number =
inventory_db.dbo.description.item_number
WHERE (inventory_db.dbo.description.item_number = @in_item_number)
GO
Related reference
Stored procedure%STPROC on page 259
User exit%USER on page 260
User Exit%USERFUNC

User Exit%USERFUNC
Use this function to call a Java class user exit program or a stored procedure from
an expression. This function provides flexibility when complex logic that cannot be
expressed using the provided column functions is required. You can use this
function to call a user exit program with input parameters. This function also
supports MBCS data. For more information about user exit programs, see your
InfoSphere CDC user exits documentation.

Syntax
%USERFUNC(function_type, program_name, [<parm1>, <parm2>, ..., <parmn>]

Column functions 265

 Parameters
v function_typeIndicate the type of user exit. Specify JAVA to call a Java class
user exit program or STOREDPROC to call a stored procedure user exit
program. You must enclose these values in double quotes to indicate they are
strings, not column names.
The Java class should be placed in your lib directory. If your Java class has a
package name then you must create the appropriate directories under the lib
directory.
The stored procedure must exist in your database and you must specify the
database owner or schema.
v program_nameThe name of your Java class or stored procedure. Stored
procedures must exist in your database you must specify the database owner or
schema as well as the name of the stored procedure.
v parm1, parm2, ..., parmnSpecify columns or literals that are passed as
parameters to the Java class user exit or stored procedure user exit.

Result data type

The data type of the result returned by the stored procedure.

Examples

%USERFUNC("JAVA", "USERSEL1", BRANCH)

This function calls the Java user exit program of USERSEL1 and passes the
BRANCH column as a parameter. USERSEL1 checks whether or not BRANCH is
set to '11'. If it is, then the user exit program returns a one-byte character value of
Y. Otherwise, it returns a character value of N.

%USERFUNC("STOREDPROC","dbo.sp_date_diff",COL_DATE)
%USERFUNC("STOREDPROC","dbo.sp_date_diff","12-jan-2000")

The first call example specifies a source column name as input parameter
(COL_DATE), while the second call example specifies a value as input parameter
("12-jan-2000"). These examples assume that a stored procedure, similar to the
following, is defined in the database. The example stored procedure calculates the
difference in days between the current date and a date specified as parameter. The
stored procedure must exist in your database and you must specify the stored
procedure name and database owner or schema:
CREATE PROCEDURE dbo.sp_date_diff
@out_int int output,
@in_date datetime
AS
select @out_int = DATEDIFF(day, @in_date, getdate())
GO

%USERFUNC("STOREDPROC","dbo.sp_join",col_item_number)
%USERFUNC("STOREDPROC","dbo.sp_join",12)

The first call example specifies a source column name as input parameter
(col_item_number), while the second call example specifies a value as input
parameter (12). These examples assume that a stored procedure, similar to the
following, is defined in the database. The example stored procedure performs a
join to a description table to get the description of an item given its item number.

266 InfoSphere Change Data Capture Management Console: Administration Guide

 The stored procedure must exist in your database and you must specify the stored
procedure name and database owner or schema.
CREATE PROCEDURE dbo.sp_join
@out_item_description varchar(10) output
@in_item_number int
AS
SELECT @out_item_description = inventory_db.dbo.description.item_desc
FROM inventory_db.dbo.item_list INNER JOIN
inventory_db.dbo.description ON
inventory_db.dbo.item_list.item_number =
inventory_db.dbo.description.item_number
WHERE (inventory_db.dbo.description.item_number = @in_item_number)
GO
Related concepts
Replicating multibyte (MBCS) and double-byte (DBCS) character data on page
163
Related reference
Stored procedure%STPROC on page 259
User exit%USER on page 260
User exit%USER (InfoSphere CDC for Microsoft SQL 5.x) on page 264

%GETCOL column function scenarios (DB2 for IBM i)

The %GETCOL column function scenarios in this section are specific to InfoSphere
CDC for IBM i. If you are using a different InfoSphere CDC product, %GETCOL
column function scenarios (Dynamic SQL) on page 269.

See also:
Retrieving a column from another table using the %GETCOL function (DB2 for
i)
Performing an outer join using the %GETCOL function (DB2 for i) on page
268
Nesting columns to join data using the %GETCOL function (DB2 for i) on
page 268
Combining columns using the %GETCOL function (DB2 for i) on page 268

Retrieving a column from another table using the %GETCOL

function (DB2 for i)
This example uses the relationship between a primary (EMPLOYEE) and secondary
(BRANCH, STATE, and COUNTRY) tables.

In this example, you will retrieve the column NAME from the STATE table using
the STATE column from the EMPLOYEE table. To use this example, perform the
following steps:
1. Add a derived column, STNAME, based on the NAME column, to the STATE
table.
2. Enter the following expression for the STNAME derived column:

Column functions 267

 %GETCOL(NAME, "PRODLIB/STATE", , , 1, STATE)

Performing an outer join using the %GETCOL function (DB2

for i)
This example uses the relationship between primary and secondary tables. In this
example, you will retrieve the column NAME from the COUNTRY table using the
COUNTRY column from the STATE table. The COUNTRY column, used to read
the COUNTRY table, is not from the primary table.

To use this example, perform the following steps:

1. Add a derived column, CTNAME, based on the NAME column, to the
COUNTRY table.
2. Enter the following expression for the CTNAME column:
%GETCOL(NAME, "PRODLIB/COUNTRY", , , 1, %GETCOL(COUNTRY,
"PRODLIB/STATE"))
The second %GETCOL function retrieves the COUNTRY column from the
STATE table. This column was retrieved in a previous %GETCOL invocation. In
the first %GETCOL function, the default_value and record_format parameters
are not specified, as they are specified in the long version of the %GETCOL
function that performed the read.

Nesting columns to join data using the %GETCOL function

(DB2 for i)
This example uses the relationship between primary and secondary tables. In this
example, you will consolidate data from secondary tables without replicating the
secondary tables.

To use this example, perform the following steps:

1. Add a derived column, CTNAME, based on the NAME column, to the
COUNTRY table.
2. Enter the following expression for the CTNAME column:
%GETCOL(NAME, "PRODLIB/COUNTRY", , , 1, %GETCOL(COUNTRY,
"PRODLIB/STATE", , , 1, STATE))
This function retrieves the NAME column from the COUNTRY table using the
STATE column from the EMPLOYEE table and the COUNTRY column from the
STATE table.

Combining columns using the %GETCOL function (DB2 for i)

This example uses the relationship between primary and secondary tables. In this
example, you will combine the STATE and COUNTRY columns from the STATE
table using the %CONCAT function. To use this example, perform the following
steps:
1. Add a derived column, REGION, based on the STATE and COUNTRY columns
in the STATE table.
2. Enter the following expression for the REGION column:
%CONCAT(%GETCOL(STATE, "PRODLIB/STATE", "FAILED", , 1, STATE), "-",
%GETCOL(COUNTRY, "PRODLIB/STATE", "FAILED"))
The second %GETCOL function retrieves the COUNTRY column from the
STATE table. This column was retrieved in a previous %GETCOL function
invocation.

268 InfoSphere Change Data Capture Management Console: Administration Guide

 Related reference
Concatenation%CONCAT on page 222

%GETCOL column function scenarios (Dynamic SQL)

The %GETCOL column function scenarios in this section apply to any InfoSphere
CDC product except InfoSphere CDC for IBM i. For InfoSphere CDC for z/OS, you
can also refer to Retrieve column%SELECT on page 255.

See also:
Retrieving a column using the %GETCOL function (Dynamic SQL)
Retrieving a column using the %GETCOL function without reading the same
row from the table
Retrieving a column using nested %GETCOL functions (Dynamic SQL) on
page 270
Filtering rows using the %GETCOL function (Dynamic SQL) on page 271

Retrieving a column using the %GETCOL function (Dynamic

SQL)
This example refers to the primary (EMPLOYEE) and secondary (BRANCH,
STATE, and COUNTRY) table relationship. The table names referenced in the
examples follow the format for InfoSphere CDC for Microsoft SQL Server and
InfoSphere CDC for Sybase. If you installed another InfoSphere CDC product, see
the <table_name> parameter in this function for more information about specifying
table names which depends on your database.

To use the example, you must add a derived column to the MASTER.DBO.EMPLOYEE
primary table and enter the specified %GETCOL function in that column.

%GETCOL(NAMEB, "MASTER.DBO.BRANCH", "<NO NAME>", BRANCHB, BRANCH)

This example retrieves the NAMEB column from the MASTER.DBO.BRANCH secondary
table, using the value in the BRANCH column in the primary table and the key
column BRANCHB in the secondary table.

If a record in the primary table has a branch number that does not exist in the
MASTER.DBO.BRANCH table, then this function returns "" for that record in the
retrieved column.

Retrieving a column using the %GETCOL function without

reading the same row from the table
This example refers to the primary and secondary tables. The table names
referenced in the examples follow the format for InfoSphere CDC for Microsoft
SQL Server and InfoSphere CDC for Sybase. If you installed another InfoSphere
CDC product, see the <table_name> parameter in this function for more information
about specifying table names which depends on your database.

Column functions 269

 To use the example, you must add a derived column to the MASTER.DBO.EMPLOYEE
primary table and enter the specified %GETCOL function in that column.

%GETCOL(NAMES, "MASTER.DBO.STATE", , STATES, STATE)

This function call retrieves the NAMES column from the MASTER.DBO.STATE
secondary table, using the key column STATE in the primary table and the key
column STATES in the secondary table. If a record in the primary table has a state
that does not exist in MASTER.DBO.STATE, then this function returns the default
value for the data type of the NAMES column. For example, blank characters if the
data type is character.

%GETCOL(COUNTRYS, "MASTER.DBO.STATE", "")

Used after the previous %GETCOL function, this function call retrieves the
COUNTRYS column from the MASTER.DBO.STATE secondary table, without reading
again the same row from the table. If a record in the primary table has a state that
does not exist in MASTER.DBO.STATE, then this function returns the default value for
the data type of the COUNTRYS column. For example, blank characters if the data
type is character.

Retrieving a column using nested %GETCOL functions

(Dynamic SQL)
This example refers to the primary and secondary table relationship. The table
names referenced in the examples follow the format for InfoSphere CDC for
Microsoft SQL Server and InfoSphere CDC for Sybase. If you installed another
InfoSphere CDC product, see the <table_name> parameter for information about
specifying table names for this function, depending on your database.

To use the example, you must add a derived column to the MASTER.DBO.EMPLOYEE
primary table and enter the specified %GETCOL function in that column.

%GETCOL(NAMES, "MASTER.DBO.STATE", , STATES, STATE)

This function call retrieves the NAMES column from the MASTER.DBO.STATE
secondary table, using the key column STATE in the primary table and the key
column STATES in the secondary table. If a record in the primary table has a state
that does not exist in MASTER.DBO.STATE, then this function returns the default
value for the data type of the NAMES column. For example, blank characters if the
data type is character.

%GETCOL(NAMEC, "MASTER.DBO.COUNTRY", , COUNTRYC, %GETCOL(COUNTRYS,

"MASTER.DBO.STATE", ""))

Used after the previous %GETCOL function, the second %GETCOL function in this
example is called first to retrieve the COUNTRYS column from the
MASTER.DBO.STATE table. Then, the first %GETCOL function is called to retrieve the
NAMEC column from the MASTER.DBO.COUNTRY table using the key column
COUNTRYS in MASTER.DBO.STATE and the key column COUNTRYC in
MASTER.DBO.COUNTRY.

In this example you do not retrieve the NAMEC column in the

MASTER.DBO.COUNTRY table directly, using the COUNTRYC key column, because the
primary table does not contain a key column to retrieve NAMEC. Instead, you

270 InfoSphere Change Data Capture Management Console: Administration Guide

 retrieve the NAMEC column indirectly using the COUNTRYS key column in
MASTER.DBO.STATE and the COUNTRYC key column in MASTER.DBO.COUNTRY.

Filtering rows using the %GETCOL function (Dynamic SQL)

This example refers to the primary and secondary table relationship. The table
names referenced in the examples follow the format for InfoSphere CDC for
Microsoft SQL Server and InfoSphere CDC for Sybase. If you installed another
InfoSphere CDC product, see the <table_name> parameter in this function for more
information about specifying table names which depends on your database.

To use the example, you must add a derived column to the MASTER.DBO.EMPLOYEE
primary table and enter the specified %GETCOL function in that column.

%GETCOL(COUNTRYS, "MASTER.DBO.STATE", , STATES, STATE) = 'USA'

This example uses the %GETCOL function in a row-filtering expression. The

function retrieves values of the COUNTRYS column from the MASTER.DBO.STATE table
and compares them with 'USA'. Depending on your row filtering settings on the
Filtering tab, rows in the MASTER.DBO.EMPLOYEE primary table, with a COUNTRYS
value set to USA, are either selected or omitted for replication.

Publishing multiple derived columns using the %GETCOL function

(Dynamic SQL)
This example refers to the primary and secondary table relationship. The table
names referenced in the examples follow the format for InfoSphere CDC for
Microsoft SQL Server and InfoSphere CDC for Sybase. If you installed another
InfoSphere CDC product, see the <table_name>parameter for information about
specifying table names for this function, depending on your database.

This example combines the CUSTID and CUSTADDR tables into a single CUSTOMER table
with all five columns. By calling the %GETCOL function twice, you retrieve values
of two columns from the same row in the secondary table. The first call reads the
entire row into memory and the second call retrieves data from the same row in
memory, without reading the same table twice.

To use this example, perform the following steps:

1. Add a derived column, ADDR1, to the CUSTID source table and enter the
following expression for the column:
%GETCOL(ADDRESS1, "MASTER.DBO.CUSTADDR", "Not Found", CUSTNO, CUSTNO)
2. Add a derived column, ADDR2, to the CUSTID source table and enter the
following expression for the column:
%GETCOL(ADDRESS2, "MASTER.DBO.CUSTADDR", "Not Found")

Column functions 271

 The expression for ADDR1 queries the CUSTADDR table and returns the value in the
ADDRESS1 column where the two CUSTNO values match. The expression for
ADDR2 uses the results returned by the previous %GETCOL function invocation
without reading the CUSTADDR table. Instead, it uses matching rows from the
ADDR2 definition to know when to return the value from the ADDRESS2 column.
If either %GETCOL function cannot find a matching row, then it returns a value of
"Not Found".

Related concepts
Filtering rows and columns on page 291

XPath functions
The XPath functions implemented by InfoSphere CDC Event Server follow specific
syntax. For details regarding the XPath functions, see W3C's Web site at
http://www.w3.org. In the current release the following XPath functions are
implemented:

See also:
ceiling
concat on page 273
contains on page 273
floor on page 273
false on page 273
formatNumber on page 274
normalizeSpace on page 274
not on page 274
number on page 275
position on page 275
round on page 275
startsWith on page 275
string on page 276
stringLength on page 276
substring on page 276
substringAfter on page 276
substringBefore on page 277
sum on page 277
translate on page 277
true on page 278

ceiling
Returns the smallest integer greater than or equal to the numeric value of the
argument.

Syntaxceiling(value)

272 InfoSphere Change Data Capture Management Console: Administration Guide

 Input Parameters(value) represents an input value that can be converted to a
number.

Example<sxt:element name="Price" value="ceiling(12.5)"/>. This function

returns a value of 13.

concat
Concatenates two or more values into one string.

Syntaxconcat(value1, value2, [, value3, ...])

Input Parametersvalue1, value2, [, value3, ...] represent input values: expressions,

literals, or functions.

Return ValueString

Example<sxt:element name="Full_Name" value="concat(First_Name, ` `,

Last_Name)"/>

contains
Determines whether a string is contained within another string. The function
returns true if value 1 contains value 2, otherwise, false.

Syntaxcontains(value1, value2)

Input Parametersvalue1, value2 represent input values: expressions, literals, or

functions.

Return ValueBoolean

Example<sxt:element name="isQualified" value="contains(/employee/

skill,"Java")"/>

floor
Returns the largest integer that is less than or equal to the numeric value of the
argument.

Syntaxfloor(value)

Input Parametersvalue represents an input value that can be converted to a

number.

Return ValueNumber

Example<sxt:element name="Price" value="floor(12.5)"/>. This function

returns a value of 12.

false
Returns false.

Syntaxfalse( )

Column functions 273

 Input ParametersNone

Return ValuebBoolean

Example<sxt:element name="OnSale" value="false()"/>

formatNumber
Formats a numeric value according to a specified pattern. The default pattern
implemented follows Java JDK Version 1.1 specification. For more information on
number formats, see the Java API documentation.

Syntaxformat-number(value, format-pattern)

Input Parameters
v value represents an input value that can be converted to a number.
v format-pattern represents a string value that contains the formatting rules.

Return ValueString

Example<sxt:element name="Price" value="format-number(12.5,

$#.00)"/>. The preceding declaration formats "12.5" to "$12.50" and assigns it as
the contents of the Price element.

normalizeSpace
Trims the leading and trailing white spaces (blank spaces, tabs and new line
characters), and converts multiple white spaces to a single blank space.

Syntaxnormalize-space(value)

Input Parametersvalue represents an input string value.

Return ValueString

Example<sxt:element name="Test" value="normalize-space (` Hello world!

)"/>

not
Returns true if the argument is false, returns false if the argument is true.

Syntaxnot(value)

Input Parametersvalue represents an input boolean value or expression.

Return ValueBoolean

Example<sxt:element name="Admit" value="not(/Customers/Customer/

age<18)"/>

274 InfoSphere Change Data Capture Management Console: Administration Guide

number
This function converts a value to a decimal number.

Syntaxnumber(value)

Input Parametersvalue represents an input string of numeric values.

Return ValueNumber

Example<sxt:element name="Cost" value="number(15.6)"/>

position
Returns a number equal to the context position from the expression evaluation
context.

Syntaxposition( )

Input ParametersNone

Return ValueNumber

Example<sxt:element name="ColumnNum" value="/root/a[position()=3]"/>

round
Returns the closest integer to the numeric value of the argument.

Syntaxround(value)

Input Parametersvalue represents an input number, which must be surrounded

by single quotes.

Return ValueNumber

Example<sxt:element name="Cost" value="round(15.6)"/>. For this example,

the return value is 16.

startsWith
Returns true if one string begins with another.

Syntaxstarts-with(value1, value 2)

Input Parameters
v value1 represents an input value: an expression, a literal, or a function.
v value2 represents the substring to be searched.

Return ValueBoolean

Example<sxt:element name="isLocal" value="starts-with(Phone, "416")"/>

Column functions 275

 string
Converts a number or node to a string.

Syntaxstring(value)

Input Parametersvalue represents an input number.

Return ValueString

Example<sxt:element name="Cost" value="string(15.6)"/>

stringLength
This function returns the length of a string.

Syntaxstring-length(value)

Input Parametersvalue represents an input value: an expression, a literal, or a

function.

Return ValueNumber

Example<sxt:element name="TestLength" value="string-length(Phone)"/>

substring
This function extracts a substring from a string starting at, and ending with, a
specified position.

Syntaxsubstring(value, beginIndex, [length])

Input Parameters
v value represents an input value: an expression, a literal, or a function.
v beginIndex represents the beginning position, zero-based.
v length represents the end position, zero based. If omitted, the substring runs to
the end of the input string.

Return ValueString

Example<sxt:element name="Area_Code" value="substring(Phone, 0, 3)"/>

substringAfter
Extracts a substring from a string. The substring to be extracted appears after the
first occurrence of a specified substring.

Syntaxsubstring-after(value, searchSubstring)

Input Parameters
v value represents an input value: an expression, literal, or a function.
v searchSubstring represents the substring to be searched.

276 InfoSphere Change Data Capture Management Console: Administration Guide

 Return ValueString

Example<sxt:element name="LocalNumber" value="substring-after (Phone, `

`)"/>

substringBefore
Syntaxsubstring-before(value, searchSubstring)

DescriptionExtracts a substring from a string. The substring to be extracted

appears before the first occurrence of a specified substring.

Input Parameters
v value represents an input value: an expression, a literal, or a function.
v searchSubstring represents the substring to be searched.

Return ValueString

Example<sxt:element name="AreaCode" value="substring-before(Phone, `

`)"/>

sum
Syntaxsum(node_set)

DescriptionReturns the total value of a set of numeric values in a node-set.

Input Parametersnode_set is an X-Path expression that represents a node-set.

Return ValueNumber

Example<sxt:element name="TotalPrice" value="sum(//UnitPrice)"/>

translate
Syntaxtranslate(value, from, to)

DescriptionSubstitutes characters in a supplied string with specified replacement

characters.

Input Parameters
v value represents an input value: an expression, a literal, or a function.
v from represents the characters to be replaced.
v to represents the characters to be used as the replacement for the from
characters. If omitted, the from characters are removed.

Return ValueString

Example<sxt:element name="Phone" value="substring(Phone, ` `, `-`)"/>

Column functions 277

 true
Syntaxtrue( )

DescriptionReturns true.

Input ParametersNone

Return ValueBoolean

Example<sxt:element name="OnSale" value="true()"/>

Nesting is supported in the current version.

Transform extensions
To meet specific transform requirements, these extensions have been developed to
supplement XPath and XSLT recommendations provided by W3C. The first
extension is an XPath expression for self-reference. A leading # symbol means
self-reference from the target point of view. For example, /root/level1/@attr1
points to an attribute in the source DOM, while #/root/level1/@attr1 points to an
attribute in the target that is the XML document to be generated. InfoSphere CDC
Event Server functions are marked with the sxt: prefix, which must be used with
the function name.

See also:
sxt:add on page 279
sxt:db-lookup on page 279
sxt:divide on page 279
sxt:filter on page 280
sxt:formatDate on page 280
sxt:getSequentialNum on page 281
sxt:getSubField on page 281
sxt:getSysDateTime on page 281
sxt:getSysDate on page 282
sxt:getSysTime on page 282
sxt:groupConcat on page 282
sxt:ifExist on page 282
sxt:ifReturn on page 283
sxt:isEqual on page 283
sxt:multiply on page 283
sxt:nodeConcat on page 283
sxt:padLeft on page 284
sxt:padRight on page 284
sxt:proper on page 284
sxt:setDefault on page 285
sxt:subtract on page 285
sxt:toLowerCase on page 285
sxt:toUpperCase on page 286
sxt:trim on page 286
278 InfoSphere Change Data Capture Management Console: Administration Guide
sxt:add
Syntaxsxt:add (value1, value2, [value3,...])

DescriptionThis function adds two or more values provided.

Input Parametersvalue1, value2, [value3, ...] represent two or more values that can
be converted to numbers.

Return ValueNumber

Example<sxt:element name="Total_Quantity" value="sxt:add(QOH, QOO)"/>

sxt:db-lookup
Syntaxsxt:db-lookup (JDBCDriver, URL,UserName, Password, SQLStatement
|StoredProcedure[,param1,param2,...])

DescriptionThis function gets a single value from the specified database by

performing a query. Do not use this function on tables that are being transformed.
Use sxtdb:lookup for tables under current transformation

Input Parameters
v JDBCDriverRepresents the name of a valid JDBC driver class.
v URLRepresents a unique URL to the database.
v UserNameRepresents a valid user name to access the database.
v PasswordRepresents a valid password associated with the user name.
v SQLStatementRepresents the SQL statement to be applied to the database. Only
standard SQL types are supported.
v StoredProcedure[,param1,param2,...] Represents the stored procedure. The
syntax is: (outputParameter Datatype) call ProcedureName ([inputParameter
Datatype, ...])
outputParameterThe stored procedure can have only one output parameter,
and the output parameter must be the last parameter. The supported data
types are: CHAR, VARCHAR, LONGVARCHAR, INTEGER, DOUBLE, DATE,
TIME, TIMESTAMP
inputParameterRepresents the value of the input parameter (optional).

stringThis function will return the first column in the first row of the result set
sxt:db-lookup("sun.jdbc.odbc.JdbcOdbcDriver","jdbc:odbc:pubs", "sa","sa","SELECT
country_name FROM countries WHERE country_id=?", @countryID)

sxt:divide
Syntaxsxt:divide (value1, value2)

DescriptionThis function divides two values provided.

Input Parametersvalue1, value2 represent two values that can be converted to

numbers. value2 cannot be zero.

Return ValueNumber

Column functions 279

 Example<sxt:element name="Overtime_Rate" value="sxt:divide(overtime,
standard)"/>

sxt:filter
Syntaxsxt:filter (node-set, condition)

DescriptionThis function filters the node-set using a conditional expression in

the context of each of the node-sets. This is equivalent to the XPath "[ ]" filtering
mechanism.

Input Parameters
v node-set represents the node-set to be selectively returned if a node meets the
condition.
v condition represents a filter condition that can be evaluated (true or false).

Return ValueNode-set

Example<sxt:attribute name="keys"
value="sxt:groupConcat(sxt:filter(data_key, sxt:is-equal(data_type,2)),
)"/>

sxt:formatDate
Syntaxsxt:formatDate (value, original-format-pattern, to-format-pattern)

DescriptionThis function formats the date string using the specified pattern. The
patterns must follow the rules in Java. For more information on date formats, see
the Java API documentation.

Input Parameters
v value represents an input value that can be converted to a date.
v original-format-pattern represents a string value that contains the original
formatting rules.
v to-format-pattern represents a string value that contains the formatting rules for
the converted date. The patterns must follow the rules in Java.
yyyy-MM-dd (for example, 2001-01-25)
MMM dd, yyyy (for example, Jan 25, 2004)
MMMM d, yyyy (for example, January 25, 2004)
M/dd/yyyy (for example 1/25/2004)
yyyy-MM-dd HH:mm:ss (for example, 2004-01-25 13:25:30)
yyyy-MM-dd hh:mm:ss a (for example, 2004-01-25 01:25:30 PM).

Return ValueString

Example<sxt:element name="Birthday" value="sxt:formatDate(@dob,

yyyy-MMdd, MMM dd, yyyy)"/>

280 InfoSphere Change Data Capture Management Console: Administration Guide

sxt:getSequentialNum
Syntaxsxt:getSequentialNum (seed, increment)

Description This function generates sequential numbers in a session.

Input Parameters
v seed represents the start value of a counter.
v increment represents the increment for each number.

Return ValueNumber

Example<sxt:element name="ID" value="sxt:getSequentialNum(1,1)"/>. In this

example, when the function is called for the first time, the return value is 1; the
second time, the return value is 2, the third time, 3, and so on. The counter does
not persist between sessions or processes.

sxt:getSubField
Syntaxsxt:getSubField (value, delimiter, subFieldIndex)

DescriptionThis function extracts a sub-field value from a string that contains a

list of delimited values.

Input Parameters
v value represents an input value: an expression, a literal, or a function.
v delimiter represents a delimiter used to separate the sub-field values. For
example: comma, tab, |, and so on.
v subFieldIndex represents the ordinal position of the sub-field. For example, the
first sub-field is 1, and so on.

Return ValueString

Example<sxt:element name="Area_Code" value="sxt:getSubField(Phone, `-`,

1)"/>

sxt:getSysDateTime
SyntaxgetSysDateTime ( )

DescriptionThis function returns the system date and system time at runtime.

Input ParametersNone

Return ValueString

Example<sxt:element name="UpdateTimestamp"
value="sxt:getSysDateTime()"/>

Column functions 281

 sxt:getSysDate
SyntaxgetSysDate ( )

DescriptionThis function returns the system date at runtime.

Input ParametersNone

Return ValueString

Example<sxt:element name="UpdateDate" value="sxt:getSysDate()"/>

sxt:getSysTime
Syntaxsxt:getSysTime ( )

DescriptionThis function returns the system time at runtime.

Input ParametersNone

Return ValueString

Example<sxt:element name="UpdateTime" value="sxt:getSysTime()"/>

sxt:groupConcat
Syntaxsxt:groupConcat (nodeToConcat, delimiter)

DescriptionThis function converts one level node in a node-set to a string and

then concatenates them together into a string

Input Parameters
v nodeToConcat represents the node to be concatenated. It must be a node-set.
v delimiter represents the delimiter to be used for separating each sub-value.

Return ValueString

Example<sxt:element name="AuthorPhones" value="sxt:groupConcat(/authors/

phone, ,)"/>

sxt:ifExist
Syntaxsxt:if-exist (nodeOrExpr1, node OrExpr2)

DescriptionThis function verifies whether or not the first value is empty. If it is

empty, it returns the second value. Otherwise, it returns the first value.

Input Parameters
v nodeOrExpr1 represents the first node or expression.
v nodeOrExpr2 represents the second node or expression.

Return ValueString

282 InfoSphere Change Data Capture Management Console: Administration Guide

 Example<sxt:element name="Phone" value="sxt:if-exist(@WorkPhone,
@HomePhone)"/>

sxt:ifReturn
Syntaxsxt:if-return (testCondition, valueForTrue, valueForFalse)

DescriptionThis function evaluates a condition and, depending on the

evaluation result, returns a specified value.

Input Parameters
v testCondition represents an expression that can be evaluated to true or false.
v valueForTrue represents the value to be returned when the condition is true.
v valueForFalse represents the value to be returned when the condition is false.

Return ValueString

Example<sxt:element name="Language" value="sxt:if-return(sxt:is-

equal(@lang,`fr), `French, `English)"/>

sxt:isEqual
Syntaxsxt:is-equal (nodeOrExpr, valueToTestAgainst)

DescriptionThis function tests if a node or expression has a specific value.

Input Parameters
v nodeOrExpr represents a node/expression whose value is compared with the
specified value.
v valueToTestAgainst represents a specific value for testing the node or the
expression.

Return ValueBoolean

Example<sxt:element name="no_name" value="sxt:is-equal(@name, ")"/>

sxt:multiply
Syntaxsxt:multiply (value1, value2, [value3, ...])

DescriptionThis function multiplies two or more values provided.

Input Parametersvalue1, value2, [value3, ...] represent two or more values that can
be converted to numbers.

Return ValueNumber

Example<sxt:element name="Cost" value="sxt:multiply(Quantity, Price)"/>

sxt:nodeConcat
Syntaxsxt:nodeConcat (flag, nodeToConcat, delimiter)

Column functions 283

 DescriptionThis function converts each node in a node-set to a string and then
concatenates them together into a string.

Input Parameters
v flag represents an expression that can be evaluated to true or false.
v nodeToConcat represents the node to be concatenated. It must be a node-set.
v delimiter represents the delimiter to be used for separating each sub-value.

Return ValueString

Example<sxt:element name="AuthorPhones" value="sxt:nodeConcat(,/

authors/phone, ,)"/>

sxt:padLeft
Syntaxsxt:pad-left (string_to_pad, value, string_to_fill)

DescriptionThis function adds a number of characters to the left of a string. If

the length of the string to return is less than the value specified, the return string is
truncated.

Input Parameters
v string_to_pad specifies the string to be modified by adding characters to the left.
v value specifies the length of the string to be returned.
v string_to_fill specifies the string that contains the characters to fill.

Return ValueString

Example<sxt:element name="Leading_Zeros_Number" value="sxt:pad-

left(number,8, 0)"/>

sxt:padRight
Syntaxsxt:pad-right (string_to_pad, value, string_to_fill)

DescriptionThis function adds a number of characters to the right of a string. If

the length of the string to return is less than the value specified, the return string is
truncated.

Input Parameters
v string_to_pad specifies the string to be modified by adding characters to the
right.
v value specifies the length of the string to be returned.
v string_to_fill specifies the string that contains the characters to fill.

Return ValueString

Example<sxt:element name="Trailing_Space" value="sxt:pad-right(fname,

10, )"/>

sxt:proper
Syntaxsxt:proper (string)

284 InfoSphere Change Data Capture Management Console: Administration Guide

 DescriptionThis function performs a capitalization of all the words provided as
input. The first letter of a word is converted to uppercase, while the other ones to
lowercase.

Input Parametersstring Specifies a string that contains a number of words.

Return ValueString

Example<sxt:element name="FullName" value="sxt:proper(full_name)"/>

sxt:setDefault
Syntaxsxt:setDefault (nodeOrExpr, defaultValue)

DescriptionThis function returns a default value if a specified node/expression

is evaluated to an empty string.

Input Parameters
v nodeOrExpr represents a node/expression to be tested.
v defaultValue represents the value to be returned when the node/expression
contains an empty string.

Return ValueString

Example<sxt:element name="Language"
value="sxt:setDefault(@lang,English)"/>

sxt:subtract
Syntaxsxt:subtract (value1, value2, [value3, ...])

DescriptionThis function subtracts one or more values from the first value
specified.

Input Parametersvalue1, value2, [value3, ...] represent two or more values that can
be converted to numbers.

Return ValueNumber

Example<sxt:element name="Stored_Quantity" value="sxt:subtract(100, 20,

30)"/>. In this example, the return value is 50.

sxt:toLowerCase
Syntaxsxt:toLowerCase (value)

DescriptionThis function converts a string to lower case.

Input Parametersvalue represents the value to convert to lower case.

Return ValueString

Example<sxt:element name="FirstName" value="sxt:toLowerCase(first_name)

"/>

Column functions 285

 sxt:toUpperCase
Syntaxsxt:toUpperCase (value)

DescriptionThis function converts a string to upper case.

Input Parametersvalue represents the value to convert to upper case.

Return ValueString

Example<sxt:element name="LastName" value="sxt:toUpperCase(last_name)"/>

sxt:trim
Syntaxsxt:trim (value)

DescriptionThis function strips off the leading and trailing blank spaces of a
string.

Input Parametersvalue represents the string value to be trimmed.

Return ValueString

Example<sxt:element name="FirstName" value="sxt:trim(first_name)"/>

Using external Java objects in data transformations

You can extend your data transformations using external Java objects. Some of the
things you can do include but are not limited to the following:
v Implement your own custom data validation
v Translate values using look-up tables
v Perform complex calculations

It is very easy to use your Java classes in your mapping project. The methods must
be public but need not be static. Make sure that any external Java classes you want
to use can be found in the CLASSPATH environment variable. InfoSphere CDC
Event Server will use Java Reflection API to call your programs.

InfoSphere CDC Event Server provides three types of calling conventions that can
manipulate the following objects:

See also:
Simple string objects (type I)
SQL data types (type II) on page 287
XML objects (type III) on page 287

Simple string objects (type I)

For this type of implementation, all the data passed to your Java program are of
String type. Your program must also return a string.

Syntaxjavas:[package.]className.methodName ([param1, ...]) -> String

286 InfoSphere Change Data Capture Management Console: Administration Guide

 where:
v javasRepresents the identifier for the external Java call simple method.
v classNameRepresents the Java class name, which may also reference the
package name.
v methodNameRepresents the method that performs the processing. Parameters
are optional, and they can be XPath expressions, functions, or literal strings.

Example<sxt:element name="MyTag"
value="javas:com.ibm.MyClass.someMethod(@cust_id)"/>

SQL data types (type II)

For this type of implementation, all the data passed to your Java program are of
Object type. Your program must also return an object. The data types are common
SQL data types for databases. They are those defined by the java.sql package. The
syntax is the same as for the type I, except that the identifier is java: instead of
javas:, as follows:
java:[package.]ClassName.methodName([param1, ...]) -> Object

XML objects (type III)

This type of implementation supports extended XML objects, including XPath
node-set and DOM objects (for example, Element and Node). InfoSphere CDC
Event Server provides a set of XObjects (for example, XString, XNumber, XBoolean,
and Xdate).

The syntax is the following:

javax:[package.]ClassName.methodName([param1, ...]) -> XObject

In the current release, only type I (simple string objects) is fully implemented,
while type II (SQL data types) and type III (XML objects) will be implemented in a
future release.

XPath expression operators

An XPath expression returns either a node-set, a string, a Boolean, or a number.

See also:
+ Operator on page 288
- Operator on page 288
* Operator on page 288
div Operator on page 288
mod Operator on page 288
= Operator on page 288
!= Operator on page 288
< Operator on page 289
<= Operator on page 289
> Operator on page 289
>= Operator on page 289
or Operator on page 289
and Operator on page 289

Column functions 287

 () parentheses Operator on page 289
[ ] Operator on page 290
/ Operator on page 290
// Operator on page 290
@ Operator on page 290

+ Operator
DescriptionAdds two numbers. You can also use it to add two expressions that
return a numeric result.

- Operator
DescriptionYields the difference between two numbers or indicates the negative
value of a numeric expression.

* Operator
DescriptionMultiplies two numbers.

div Operator
DescriptionDivides two numbers and returns a floating decimal.

mod Operator
DescriptionDivides two numbers and returns only the remainder.

= Operator
DescriptionEqual. If the expression is equal to the specified value, the operator
returns true. If the expression is not equal to the specified value, the operator
returns false.

Exampleprice=7.80

ReturnsTrue if price is 7.80; false if price is 7.90

!= Operator
DescriptionNot equal to. If the expression is not equal to the specified value, the
operator returns true. If the expression is equal to the specified value, the operator
returns false.

Exampleprice!=7.80

ReturnsTrue if price is 7.90; false if price is 7.80

288 InfoSphere Change Data Capture Management Console: Administration Guide

< Operator
DescriptionCompares two numeric expressions and determines whether
expression1 is less than expression2; if so, the operator returns true. If expression1 is
greater than or equal to expression2, the operator returns false.

Exampleprice<7.80

ReturnsTrue if price is 7.00; false if price is 7.80

<= Operator
DescriptionCompares two specified numeric expressions and determines
whether expression1 is less than or equal to the expression2; if it is, the operator
returns true. If the expression1 is greater than expression2, the operator returns false.

Exampleprice<=7.80

ReturnsTrue if price is 7.00; false if price is 7.90

> Operator
DescriptionCompares two numeric expressions and determines whether
expression1 is greater than expression2; if it is, the operator returns true. If expression1
is less than or equal to expression2, the operator returns false.

Exampleprice>7.80

ReturnsTrue if price is 7.90; false if price is 7.80

>= Operator
DescriptionCompares two numeric expressions and determines whether
expression1 is greater than or equal to expression2 (true) or expression1 is less than
expression2 (false).

or Operator
DescriptionLogical or.

and Operator
DescriptionLogical and.

() parentheses Operator
DescriptionControls the order in which the operators execute in the expression.
Parentheses override the normal precedence order and cause the expressions
within the parentheses to be evaluated first. When parentheses are nested, the
contents of the innermost parentheses are evaluated before the contents of the
outer ones.

Column functions 289

 [ ] Operator
DescriptionA filter is evaluated as a Boolean on every node that is within the
current context. If the Boolean evaluates to true, the node is included in the
returned set; otherwise, it is excluded. Filters are enclosed in brackets.

/ Operator
DescriptionSelects from the root node.

// Operator
DescriptionSelects nodes in the document that match the selection no matter
where they are.

@ Operator
DescriptionIdentifies an attribute of a node.

290 InfoSphere Change Data Capture Management Console: Administration Guide

Filtering rows and columns
Use the Filtering tab to include or exclude rows or columns for replication.

In this section, you will learn:

Filtering rows
Selecting critical columns to filter rows on page 292
Filtering columns on page 292

Filtering rows
In order to include or exclude particular rows for replication, you need to build a
row-filtering expression. All row-filtering expressions that you define must return a
boolean result. For example, you may have a source column such as SALARY that
maintains the salary for each employee in your organization. You may only want
to replicate those rows to the target table for those employees that have a salary
greater than $48,000. In this scenario, you would need to define a row-filtering
expression (SALARY > 48000).

You can use column manipulation functions, basic numeric operators, and SQL
SELECT WHERE clauses in your row-filtering expressions.

The following are examples of valid row-filtering expressions:

v (SALES < 10000) OR (SALES > 90000)
v ((AIRPORT = 'JFK') OR (AIRPORT = 'LAX'))
v %IF(COUNTRY = 'US', PRODUCTPRICE, PRODUCTPRICE *1.2) > 50
v PRODUCTPRICE * (1 + TAX) > 20000

See also:
To filter rows

To filter rows
1. Click Configuration > Subscriptions.
2. Select the subscription.
3. Click the Table Mappings view and select the table mapping from the Source
Table column.
4. Right-click and select Open Mapping Details.
5. Click the Filtering tab.
6. Click Editor and build a row-filtering expression.
The expression must return a boolean result.
7. Click Verify to check the syntax of the expression and click OK to return to the
Filtering tab.
8. Choose one of the following options in the Row-filtering area:
v Select rows that match the expressionSelect this option if you want
InfoSphere CDC to replicate the source rows that satisfy your row-filtering
expression.

Copyright IBM Corp. 2008, 2011 291

 v Omit rows that match the expressionSelect this option if you want
InfoSphere CDC to replicate all rows except those that satisfy your
row-filtering expression.
9. Click Save.
Related concepts
Filtering rows on page 291

Selecting critical columns to filter rows

When you start replication on the subscription, InfoSphere CDC replicates the row
based on the criteria you specified in your row-filtering expression.

By default, InfoSphere CDC replicates inserts, updates, and deletes to the target
table during replication. However, you can control the updates that InfoSphere
CDC replicates using the select critical column feature. When you select a column
as critical, InfoSphere CDC only replicates update operations when any critical
column has changed value.

For example, you may have a source table that maintains customer account
information. Instead of receiving every update made to the source table, you may
only want the target table to receive the row when the customer account balance is
updated. In this scenario, you would select the column
(Customer_Account_Balance) as a critical column. InfoSphere CDC will only
replicate this row when there are updates made to the Customer_Account_Balance
column.

See also:
To select critical columns

To select critical columns

1. Click Configuration > Subscriptions.
2. Select the subscription.
3. Click the Table Mappings view and select the table mapping from the Source
Table column.
4. Right-click and select Open Mapping Details.
5. Click the Filtering tab.
6. Enable the Critical check box next to each column you want to set as critical.
7. Click Save.
8. If you are using InfoSphere CDC for IBM i on the source, then you need to
enable the Critical Column Filtering system parameter to *YES.
Related reference
Critical Column Filtering on page 551

Filtering columns
By default, InfoSphere CDC replicates all mapped source columns to the target
table. If there is a source column you want to exclude for replication, then you can
clear it on the Filtering tab. Excluding source columns for replication may become
necessary if the column contains confidential information that you do not want the
target to receive.

See also:

292 InfoSphere Change Data Capture Management Console: Administration Guide

 To filter columns

To filter columns
1. Click Configuration > Subscriptions.
2. Select the subscription.
3. Click the Table Mappings view and select the table mapping from the Source
Table column.
4. Right-click and select Open Mapping Details.
5. Ensure that the source column has been unmapped from any target columns on
the Column Mappings tab.
6. Click the Filtering tab.
Source columns that you can clear for replication are selected with a green
check mark in the Replicate column.
If a source column has been mapped to a target column, the check mark will be
grey instead of green and cannot be unchecked. You will have to unmap the
source column on the Column Mappings tab before you will be able to filter it
from replication.
7. Clear the green check mark for any columns that you do not want InfoSphere
CDC to replicate data from a source columns
8. Click Save.
Related concepts
Filtering columns on page 292

Filtering rows and columns 293

294 InfoSphere Change Data Capture Management Console: Administration Guide
Setting conflict detection and resolution
Conflict detection and resolution lets you detect, log, and act on inconsistent data
on the target. This ensures your replication environment handles data conflicts
automatically and in accordance with your business rules. Set conflict detection so
that InfoSphere CDC can detect and resolve conflicts as they occur. As conflicts are
detected and resolved, InfoSphere CDC logs them in a conflict resolution audit
table.

During replication, InfoSphere CDC detects conflicts when you:

v Insert a row and the row's key already exists in the target table. This violates
the unique key constraint.
v Update a row and the row's key does not exist in the target table.
v Update a row and the contents of the rows in the source table and target table,
before the update, do not match.
v Delete a row and the row's key does not exist in the target table.
v Delete a row and the contents of the rows in the source table and target table,
before the delete, do not match.

InfoSphere CDC does not detect conflicts in target columns that are:
v Populated with expressions using the %BEFORE, %CURR, %GETCOL,
%STPROC, and %USER column functions.
v Populated with journal control fields.
v Not populated by a value.

Notes:
v InfoSphere CDC does not detect conflicts in columns that have Large Object
(LOB) data types.
v Conflict detection and resolution is only available when you map your tables
using Standard replication. Conflict detection and resolution is supported for
InfoSphere CDC Version 5.3 and higher.

For more information on the requirements to configure a user exit program for
conflict detection and resolution, see the "User Exits" section in the InfoSphere
CDC documentation for your platform.

In this section, you will learn:

Resolving conflicts for source or target wins
Resolving conflicts for largest or smallest value wins on page 297
Resolving conflicts with user exits on page 299

Resolving conflicts for source or target wins

Resolving conflicts for source wins

Use the Conflicts tab to set conflict detection and resolution so that the source
wins. When InfoSphere CDC resolves conflicts so that the source column wins, it
applies the row from the source table to the target table. This ensures the target
table row matches the data in your source table upon replication. For example, a

Copyright IBM Corp. 2008, 2011 295

 remote location ships 100 books and updates their INVENTORY table to the latest
quantity of the books. When InfoSphere CDC attempts to replicate the update to
the target table, it detects a conflict because there is no row to update. In this
scenario, InfoSphere CDC resolves the conflict by inserting the row from the source
to the target.

Resolving conflicts for target wins

Use the Conflicts tab to set conflict detection and resolution so that the target
wins. When InfoSphere CDC resolves conflicts for target wins, it does not apply
any source changes to the target table. This preserves the row in the target table as
InfoSphere CDC does not apply data from the source in the event of a conflict.

For example, a remote location ships 25 pens and reduces the quantity of their
pens to 175. Before starting replication with InfoSphere CDC, a clerk accidently
changes the quantity of the pens to 300 on the target table. If InfoSphere CDC is
configured to resolve conflicts for target wins, then no change is made to the target
table and it is the same both before and after replication.

Note: Conflict detection and resolution is only available when you map your
tables using Standard replication. Conflict detection and resolution is supported
for InfoSphere CDC version 5.3 and higher. Conflict detection and resolution is not
available for InfoSphere CDC for Teradata, InfoSphere CDC for InfoSphere
DataStage or InfoSphere CDC Event Server.

See also:
To resolve conflicts for source row wins
To resolve conflicts for target row wins on page 297
Related concepts
Resolving conflicts for source or target wins on page 295
Mapping using standard replication on page 83

To resolve conflicts for source row wins

1. Ensure that InfoSphere CDC is version 5.3 or higher
2. Click Configuration > Subscriptions.

296 InfoSphere Change Data Capture Management Console: Administration Guide

 3. Select the subscription.
4. Click the Table Mappings view and select the table mapping from the Source
Table column.
This should be mapped for Standard replication.
5. Right-click and select Open Mapping Details.
6. Click the Conflicts tab.
The Target Column displays all of the columns in the target table.
7. Select the columns on which you want to detect conflicts.
8. Select Source Wins from the Conflict Resolution Method list.
9. Click Save.
When you start replication on the subscription, if InfoSphere CDC detects a
conflict in the target column, the source data is replicated to the target.
Related concepts
Resolving conflicts for source or target wins on page 295
Mapping using standard replication on page 83

To resolve conflicts for target row wins

1. Ensure that InfoSphere CDC is version 5.3 or higher
2. Click Configuration > Subscriptions.
3. Select the subscription.
4. Click the Table Mappings view and select the table mapping from the Source
Table column.
This should be mapped for Standard replication.
5. Right-click and select Open Mapping Details.
6. Click the Conflicts tab.
The Target Column displays all of the columns in the target table.
7. Select the columns on which you want to detect conflicts.
8. Select Target Wins from the Conflict Resolution Method list.
9. Click Save.
When you start replication on the subscription, if InfoSphere CDC detects a
conflict in the target column, the source data is replicated to the target.
Related concepts
Resolving conflicts for source or target wins on page 295
Mapping using standard replication on page 83

Resolving conflicts for largest or smallest value wins

Use the Conflicts tab to set conflict detection and resolution so that the largest
value wins or the smallest value wins.

Resolving conflicts for largest value wins

When InfoSphere CDC resolves conflicts for largest value wins, it applies the
change to the target if the source row has a larger value than the corresponding
row on the target table. For example, if the comparison column contains revision
times, then the target row matches the row that was most recently updated (largest
time value).

Setting conflict detection and resolution 297

 When resolving conflicts for largest value wins, InfoSphere CDC treats NULL
values as the smallest possible value. If the row does not exist on the target table,
then InfoSphere CDC uses NULL as the comparison value. If InfoSphere CDC
detects the conflict while deleting a row, then it uses the before image of the source
table and compares it to the target value. If both the source and target values are
the same, then InfoSphere CDC resolves the conflict using the Target Wins method
(no change is applied to the target).

Resolving conflicts for smallest value wins

When InfoSphere CDC resolves conflicts for smallest value wins, it only applies
the change to the target if the value in the source row is smaller than the
corresponding row on the target table. For example, if the comparison column
contains quantities, then InfoSphere CDC matches the target row with the row that
has the smaller quantity.

When resolving conflicts for smallest value wins, InfoSphere CDC treats NULL
values as the smallest possible value. If the row does not exist on the target table,
then InfoSphere CDC uses NULL as the comparison value. If InfoSphere CDC
detects the conflict while deleting a row, then it uses the before image of the source
table and compares it to the target value. If both the source and target values are
the same, then InfoSphere CDC resolves the conflict using the Target Wins method
(no change is applied to the target).

If both the source and target values are the same, then InfoSphere CDC resolves it
using the Target Wins method (no change is applied to the target).

Note: Conflict detection and resolution is only available when you map your
tables using Standard replication. Conflict detection and resolution is supported
for InfoSphere CDC version 5.3 and higher. Conflict detection and resolution is not
available for InfoSphere CDC for Teradata, InfoSphere CDC for InfoSphere
DataStage or InfoSphere CDC Event Server.

See also:
To resolve conflicts for largest value wins
To resolve conflicts for smallest value wins on page 299
Related concepts
Mapping using standard replication on page 83

To resolve conflicts for largest value wins

1. Ensure that InfoSphere CDC is version 5.3 or higher
2. Click Configuration > Subscriptions.
3. Select the subscription.
4. Select the table mapping in the Table Mappings view.
This should be mapped for Standard replication.
298 InfoSphere Change Data Capture Management Console: Administration Guide
 5. Right-click and select Open Mapping Details.
6. Click the Conflicts tab.
The Target Column displays all of the columns in the target table.
7. Select the target columns on which you want to detect conflicts in the Detect
Conflicts area.
8. Select Largest Value Wins from the Conflict Resolution Method list.
9. Select the column on the target table that you want to compare to the row on
the source table from the Value Comparison Column .
10. Click Save.
When you start replication on the subscription, if InfoSphere CDC detects a
conflict in the target column, the source data is replicated to the target.
Related concepts
Resolving conflicts for source or target wins on page 295
Mapping using standard replication on page 83

To resolve conflicts for smallest value wins

1. Ensure that InfoSphere CDC is version 5.3 or higher
2. Click Configuration > Subscriptions.
3. Select the subscription.
4. Select the table mapping in the Table Mappings view.
This should be mapped for Standard replication.
5. Right-click and select Open Mapping Details.
6. Click the Conflicts tab.
The Target Column displays all of the columns in the target table.
7. Select the columns on which you want to detect conflicts.
8. Select Smallest Value Wins from the Conflict Resolution Method list.
9. Select the column on the target table that you want to compare to the row on
the source table from the Value Comparison Column.
10. Click Save.
When you start replication on the subscription, if InfoSphere CDC detects a
conflict in the target column, the source data is replicated to the target.
Related concepts
Resolving conflicts for source or target wins on page 295
Mapping using standard replication on page 83

Resolving conflicts with user exits

Use the Conflicts tab to resolve conflicts with user exit programs.

Resolving conflicts with user exit programs

When InfoSphere CDC resolves conflicts with a user exit program, it applies the
image returned by the user exit program to the target table. Configuring a user exit
program lets you specify the row you want InfoSphere CDC to use to resolve the
conflict on the target table. When your user exit program returns a row, InfoSphere
CDC applies that row to the target table to resolve the conflict.

For example, a remote location receives a new shipment of erasers with a quantity
of 400 and updates their INVENTORY table by inserting a new row. When

Setting conflict detection and resolution 299

 InfoSphere CDC attempts to replicate the new insert, it detects a conflict because
the row already exists in the target table. Since the database administrator has
configured a user exit program that:
v Receives data from the Eraser row from both the source and target table.
v Concatenates values of both tables.

InfoSphere CDC resolves the conflict according to the specifications in the user exit
program.

Note: Conflict detection and resolution is only available when you map your
tables using Standard replication. Conflict detection and resolution is supported
for InfoSphere CDC version 5.3 and higher. Conflict detection and resolution is not
available for InfoSphere CDC for Teradata, InfoSphere CDC for InfoSphere
DataStage or InfoSphere CDC Event Server.

See also:
To resolve conflicts with user exit programs
Related concepts
Mapping using standard replication on page 83

To resolve conflicts with user exit programs

1. Ensure that InfoSphere CDC is version 5.3 or higher
2. Click Configuration > Subscriptions.
3. Select the subscription.
4. Select the table mapping in the Table Mappings view.
This should be mapped for Standard replication.
5. Right-click and select Open Mapping Details.
6. Click the Conflicts tab.
The Target Column displays all of the columns in the target table.
7. Select the columns on which you want to detect conflicts.
8. Select User Exit from the Conflict Resolution Method list.
9. Type the full path and file name of the user exit program you want to call
when InfoSphere CDC detects a conflict in the User Exit (with path) box.
10. Click Save.
When you start replication on the subscription, if InfoSphere CDC detects a
conflict in the target column, the source data is replicated to the target.
Related concepts
Resolving conflicts for source or target wins on page 295
Mapping using standard replication on page 83

300 InfoSphere Change Data Capture Management Console: Administration Guide

Controlling row operations
Management Console lets you set how a target table responds to changes made on
the source table.

In this section, you will learn:

Suppressing the apply of row operations
Preventing the audit of row operations on page 302
Detecting conflicts on row operations on page 303
Enabling the apply of soft deletes (InfoSphere CDC for Oracle) on page 304

Suppressing the apply of row operations

Use the Operations tab to suppress an insert, update, or a delete from replicating
to the target table. You may decide to suppress row-level operations from
replicating to a target table if you have a target-side application on which you do
not want any updates or deletes to occur. For example, if your target-side
application is a data warehouse, you may only want inserts to occur on your data
warehouse tables or other third party applications.

You can suppress operations if you mapped tables using either Standard or
Adaptive Apply replication.

See also:
To suppress an insert, update, or delete
Related concepts
Mapping using standard replication on page 83
Mapping using Adaptive Apply on page 102

To suppress an insert, update, or delete

1. Click Configuration > Subscriptions.
2. Select the subscription.
Ensure that the subscription contains a table mapping that was mapped using
Standard or Adaptive Apply.
3. Select the table mapping in the Table Mappings view.
4. Right-click and select Open Mapping Details.
5. Click the Operation tab.
6. Choose one or more of the following:
v Do not insertPrevents InfoSphere CDC from applying an insert to a
mapped target table.
v Do not updatePrevents InfoSphere CDC from applying an update to a
mapped target table.
vDo not deletePrevents InfoSphere CDC from applying a delete to a
mapped target table.
7. Click Save.
Depending on your selections, when you start replication, InfoSphere CDC
does not apply the row operation.

Copyright IBM Corp. 2008, 2011 301

 Related concepts
Suppressing the apply of row operations on page 301

Preventing the audit of row operations

Use the Operations tab to prevent InfoSphere CDC from the auditing of row
operations. If you have mapped your tables using LiveAudit, then InfoSphere CDC
audits row level operations taking place on the source. You can also restrict
auditing so that your target table only audits the after image when there is a
change to a row in the source table. This is especially useful if you want to reduce
the size of your audit trails for recovery purposes.

See also:
To prevent row operations from being audited
To audit only the after image
Related concepts
Mapping using LiveAudit on page 91

To prevent row operations from being audited

1. Click Configuration > Subscriptions.
2. Select the subscription.
Ensure that the subscription contains a table mapping that was mapped using
LiveAudit.
3. Select the table mapping in the Table Mappings view.
4. Right-click and select Open Mapping Details.
5. Click the Operation tab.
6. Choose one or more of the following:
v Do not insertPrevents InfoSphere CDC from auditing an insert to a
mapped target table.
v Do not updatePrevents InfoSphere CDC from auditing an update to a
mapped target table.
v Do not deletePrevents InfoSphere CDC from auditing a delete to a
mapped target table.
7. Click Save.
Related concepts
Preventing the audit of row operations

To audit only the after image

1. Click Configuration > Subscriptions.
Ensure that the subscription contains a table mapping that was mapped using
LiveAudit.
2. Select the subscription.
3. Select the table mapping in the Table Mappings view.
4. Right-click and select Open Mapping Details.
5. Click the Operation tab.
6. Select Audit After Image from the On Update list.
7. Click Save.

302 InfoSphere Change Data Capture Management Console: Administration Guide

 Related concepts
Preventing the audit of row operations on page 302

Detecting conflicts on row operations

Use the Operations tab to set conflict detection between row operations on the
source and target. If you have mapped your tables using Adaptive Apply , then
InfoSphere CDC forces the target table into consistency with row-level operations
taking place on the source table. However, when InfoSphere CDC applies an insert,
update, or delete and it is not the same as the row level operation applied to a
target table, then this creates a conflict. For example, you may have inserted a row
in the source table, but the resulting row-level operation on the target table is an
update because that row already exists in the target table. To ensure that the target
table is always consistent with the source table, you can set detection on row-level
conflicts. When there is a conflict against an insert, update or a delete operation,
InfoSphere CDC generates a message.

You can view these messages in the Events area of the Subscriptions view of the
Monitoring perspective.

See also:
To detect conflicts on row operations
Related concepts
Resolving conflicts for source or target wins on page 295
Mapping using Adaptive Apply on page 102

To detect conflicts on row operations

1. Click Configuration > Subscriptions.
2. Select the subscription.
Ensure that the subscription contains a table mapping that was mapped using
Adaptive Apply.
3. Select the table mapping in the Table Mappings view.
4. Right-click and select Open Mapping Details.
5. Click the Operation tab.
6. Choose one or more of the following:
v On InsertGenerates a message when there is an insert on the source, but
the responding row-level operation on the target is an update. Select Update
Row if Exists, Else Insert and check the Log changed database action box.
v On UpdateGenerates a message when there is an update on the source,
but the responding row-level operation on the target is an insert. Select
Update Row if Exists, Else Insert and check the Log changed database
action box.
v On DeleteGenerates a messages when there is a delete on the source, but
there is no responding row-level operation to apply to the target. Select
Delete Row if Exists and check the Log changed database action box.
7. Click Save.

Controlling row operations 303

 Related concepts
Resolving conflicts for source or target wins on page 295
Detecting conflicts on row operations on page 303

Enabling the apply of soft deletes (InfoSphere CDC for Oracle)

You can introduce a flag that audits the current state of an existing target table
which indicates that a row has been deleted (this is called a soft delete) instead of
actually deleting the row (a hard delete). If you have mapped your target tables
using Adaptive Apply, then you can enable InfoSphere CDC for Oracle to apply a
soft delete on the target table. This means that when there is a delete on the source
table, InfoSphere CDC either:
v updates a row on the target table if the row exists, or
v inserts a row on the target table if it does not exist.

When InfoSphere CDC applies the soft delete, the target table will contain:
v the before image of the row that was deleted and
v the journal entry type Delete.

Depending on whether you want InfoSphere CDC for Oracle to apply the soft
delete to all mapped target tables or to apply the soft delete on a specific target
table in the subscription, you must enable one of the following system parameters:
v DM_ADAPTIVE_APPLY_SOFT_DELETESInfoSphere CDC for Oracle applies a soft
delete on all target tables mapped using Adaptive Apply in a subscription.
v DM_ADAPTIVE_APPLY_<SCHEMA>.<TABLENAME>InfoSphere CDC for
Oracle applies a soft delete on a specific target table mapped using Adaptive
Apply in a subscription.

See also:
To enable InfoSphere CDC for Oracle to apply a soft delete

To enable InfoSphere CDC for Oracle to apply a soft delete

1. Ensure that you have set either the DM_ADAPTIVE_APPLY_SOFT_DELETES system
parameter or the DM_ADAPTIVE_APPLY_<SCHEMA>.<TABLENAME> system
parameter to ON.
2. Click Configuration > Subscriptions.
3. Select the subscription.
Ensure that the subscription contains a table mapping that is configured for
Adaptive Apply replication.
4. Select the table mapping in the Table Mappings view.
5. Right-click and select Open Mapping Details.
6. Click the Operation tab.
7. Choose Delete Row, If Exists from the On Delete list.
8. Click Save.
Related reference
DM_ADAPTIVE_APPLY_SOFT_DELETES on page 434
DM_ADAPTIVE_APPLY_<SCHEMA>.<TABLENAME> on page 435

304 InfoSphere Change Data Capture Management Console: Administration Guide

Customizing JMS message destination mappings
After mapping your tables using the Map Tables wizard, you can use the XML
Message tab to customize which columns you want to map to XML elements and
attributes. You can build your XML message and XPath expressions, import and
export mapping projects, import/export XML schemas, and query columns from
other tables if required.

This tab is only available for subscriptions targeting a JMS message destination.

In this section, you will learn:

Creating an XML message
Importing and exporting XML files, schemas, and mapping projects on page
306
Building an XPath expression on page 308
Querying columns from other tables on page 309

Creating an XML message

You can create an XML message by mapping source columns to XML elements and
attributes.

See also:
To create an XML message

To create an XML message

1. Click Configuration > Datastores.
Ensure that you are connected to an Event Server datastore.
2. Click Configuration > Subscriptions.
Ensure that you have created a subscription that uses the Event Server
datastore as the target.
3. Select the subscription that contains the table mapping to a message
destination.
Ensure that you have ended any active replication on the subscription.
4. Click the Table Mappings view and select the table mapping from the Source
Table column.
5. Right-click Open Mapping Details.
6. Click the XML Message tab.
7. Expand the Source tree and build the structure of the XML message in one of
the following ways:
v If you want the XML message to have the same structure as your source
table, then you can drag and drop the entire source table to the root (/)
node of the XML Document Structure area. This method retains mappings
between source columns and XML elements and attributes.
v If you have an existing XML structure, then you can import the structure
into the XML Document Structure area.
v You can manually build the XML structure using the options provided in
the XML Document Structure area:

Copyright IBM Corp. 2008, 2011 305

 Add an XML element
Add an XML attribute
Rename an element or attribute
Move an XML element or attribute up and down the result tree
Change the node type to either XML element or attribute
8. Verify the following options from the Output area for each XML element or
attribute you have mapped to a source column:
v AlwaysIndicates that if the value of an XML element or attribute is
empty, then InfoSphere CDC Event Server includes the XML element or
attribute in the XML message and sets the value to an empty string. This
occurs when you have mapped an XML element or attribute to a source
column that is blank, or when you have mapped the XML element or
attribute to a source column that contains a derived expression that results
to an empty string.
v Optional when empty or NULLIndicates that if the value of an XML
element or attribute is mapped to a source column that is empty or NULL,
then the XML element or attribute is not included in the XML message.
v Optional when NULLIndicates that if the value of an XML element or
attribute is mapped to a source column that is NULL, then the XML
element or attribute is not included in the XML message. However, if the
XML element or attribute is mapped to a source column that contains an
empty string, then InfoSphere CDC Event Server includes the XML element
or attribute in the XML message.
9. Verify the XPath expression for each mapping in the Value area.
When you map a source column to an XML element or attribute, you are
mapping the value of the source column to an XML element or attribute. This
value is represented as an XPath expression in the Value area. If necessary,
you can edit the expression using the Expression editor.
10. Click Save.
Related concepts
Importing and exporting XML files, schemas, and mapping projects
Related tasks
To build an XPath expression on page 308
To end replication on page 333

Importing and exporting XML files, schemas, and mapping projects

You can import XML files into Management Console. You can also import and
export XSD files and XTRANS files created in Management Console.
v Importing XML filesYou may have already created an XML file using an
editor outside of Management Console. You can import this XML file and
continue mapping source columns to elements and attributes in Management
Console. When importing XML files, you can choose to import repeated
elements, as well as choosing to import attribute values into Management
Console.
v Importing and exporting XSD filesYou may want to import the schema of an
XML message into Management Console when it is necessary to generate an
XML document using a specific structure. When importing the schema, the
structure of the XML document is displayed the XML Document Structure area
in Management Console. You can then continue to map source columns to XML
elements or attributes to create values and build XPath expressions if required.

306 InfoSphere Change Data Capture Management Console: Administration Guide

 The XPath expression identifies the XML element or attribute that contains the
value of a source column. You can also export the schema. This may be
necessary when another department or organization requires the schema.
v Importing and exporting XTRANS filesYou can export the mapping
definition of your XML document with values to your local computer. You can
later reuse the mapping definition for other XML documents by importing it
back into Management Console. It is important to note that any preexisting
mappings between source columns to XML elements and attributes in
Management Console are replaced with the imported mapping definition.

See also:
To import an XML, schema, or mapping definition file
To export an XML schema or mapping definition file

To import an XML, schema, or mapping definition file

1. Click Configuration > Datastores.
Ensure that you are connected to an Event Server datastore.
2. Click Configuration > Subscriptions.
Ensure that you have created a subscription that uses the Event Server
datastore as the target.
3. Select the subscription that contains the table mapping to a message
destination.
4. Click the Table Mappings view and select the table mapping from the Source
Table column.
5. Right-click Open Mapping Details.
6. Click the XML Message tab.
7. Click and from the Files of Type list, select one of the following:
v Schema fileImports the structure of the XML document.
v Mapping definitionImports an XML document with mapped source
column to XML element and attribute values. The values in the mapping
definition replace any preexisting mappings of your XML document in
Management Console.
v XML fileImports an XML document. If you are importing an XML file,
then the XML Import Options dialog box opens and you can enable one or
both of the following options:
Import repeated elements with the same parentBy default,
Management Console imports only one repeated element in a group node
with the same parent. Enable this option to import all repeated elements.
Import attribute valuesBy default, Management Console imports only
the structure of your XML. Enable this option to import the attribute
values. This may be necessary if attribute values represent the structure of
your XML document.
8. Click Save.
Related concepts
Importing and exporting XML files, schemas, and mapping projects on page 306

To export an XML schema or mapping definition file

1. Click Configuration > Datastores.
Ensure that you are connected to an Event Server datastore.

Customizing JMS message destination mappings 307

 2. Click Configuration > Subscriptions.
Ensure that you have created a subscription that uses the Event Server
datastore as the target.
3. Select the subscription that contains the table mapping to a message
destination.
4. Click the Table Mappings view and select the table mapping from the Source
Table column.
5. Right-click Open Mapping Details.
6. Click the XML Message tab.
Ensure that you have created the structure of an XML message that you can
export.
7. Click and from the Save as Type list, select one of the following:
v Schema file (XSD)Exports only the structure of the XML document. This
includes the name of the element, attribute, and the tree structure. Any
pre-existing mapping definitions are not exported.
v Mapping definition (XTRANS)Exports the structure of the XML
document and the mapping definition you created in Management Console.
8. Click Save.
Related concepts
Importing and exporting XML files, schemas, and mapping projects on page 306

Building an XPath expression

When you launch the Expression Builder, you can build an XPath expression to
reference a source column (the before or after image), a journal control field, a
function, a literal value in single quotes, or a combination of these.

For more information about XPath expressions, see http://www.w3.org/TR/xpath.

See also:
To build an XPath expression

To build an XPath expression

1. Click Configuration > Datastores.
Ensure that you are connected to an Event Server datastore.
2. Click Configuration > Subscriptions.
Ensure that you have created a subscription that uses the Event Server
datastore as the target.
3. Select the subscription that contains the table mapping to a message
destination.
4. Click the Table Mappings view and select the table mapping from the Source
Table column.
5. Right-click Open Mapping Details.
6. Click the XML Message tab.
Ensure that you have an existing XML structure you can build an expression
for in the XML Document Structure area.
7. Select an XML element or attribute for which you want to build an XPath
expression and double-click the Value area to open the Expression Builder.

308 InfoSphere Change Data Capture Management Console: Administration Guide

 8. You can build an expression using a combination of one or more of the
following items:
v FunctionsSpecifies functions and a location path for your XPath
expression.
v OperatorsUses operators to build your expression.
For more information about a specific function or operator, press F1.
v DatabaseRepresents the source database and lists all the nodes (such as
source columns and journal control fields) in your source table. Select the
node you want to search for, double-click it to add to the Expression box.
You can repeat this process for all the nodes you want to add to the
expression.
v Target XML DocumentRepresents the XML document that you want to
send to the JMS queue or topic.
v Saved expressionsLists any saved expressions you have built. Your
XPath expression can reference these.
9. Click Verify to verify the expression.
10. Click OK.
Related concepts
Building an XPath expression on page 308

Querying columns from other tables

The XML message you want to send may depend on columns from other tables.
You can query these columns from other databases for which you have configured
a JDBC connection or from tables in the InfoSphere CDC Event Server staging
database.

See also:
To query columns from other tables

To query columns from other tables

1. Click Configuration > Datastores.
Ensure that you are connected to an Event Server datastore.
2. Click Configuration > Subscriptions.
3. Select the subscription that contains the table mapping to a message
destination.
The selected subscription must use an InfoSphere CDC Event Server datastore
as the target.
4. Select the table mapping to work with on the Table Mappings view.
5. Right-click Open Mapping Details.
6. Click the XML Message tab.
7. Expand the Other Tables tree.
8. Double-click on Add Tables.
9. Choose one of the following options:
v Add table as top level nodeSelect this option when you want the other
table to reside at the node level.
v Add table as a child of another tableSelect this option when you want
the table to reside as the child of another table. You must add a parent table
before you can add a child table.

Customizing JMS message destination mappings 309

 10. Click Next.
11. Select the table you want to add. This can be from a database you have
configured a JDBC connection for or from the InfoSphere CDC Event Server
staging database.
12. Choose one of the following:
v Click Next to continue with the wizardDirects the wizard to create the
SQL statement for you based on the columns in the other table. You can
modify the SQL statement in the SQL Expression editor.
v Click Finish to add the table and open the SQL editorAllows you to
create your own SQL statement in the SQL Expression editor.
13. If you chose the Click Finish to add the table and open the SQL editor
option, click Finish. The SQL Expression Editor opens and you are required
to build a valid SQL expression. When you have completed building the SQL
statement, you must map this expression to an XML element or attribute in
your XML document. When you start replication, InfoSphere CDC Event
Server will retrieve data values from the table based on your query.
Otherwise, click Next to continue build your SQL statement with the help of
the wizard.
14. Review the columns in your select statement on the SELECT Clause.
15. If you want to add more columns, click Add.
Specify a name for the column and the column or expression you want
InfoSphere CDC Event Server to retrieve. You can modify the name to an alias
name. With SQL, aliases can be used for column names and table names. If
you specify an alias for the column name, the SELECT statement will retrieve
the column and return the result with the alias name you specified.
Select the column from the Column/Expression list box and click OK
16. Click Next.
17. On the WHERE Clause page, you can choose to add filters to restrict which
rows are returned by the query. The where clause is optional. Omitting the
WHERE clause from your SQL statement specifies that all rows are returned
by the query. If you want to create a WHERE clause, click Add to enable the
fields required to build your WHERE clause statement.
Your WHERE clause can return one of the following values:
v Static valuesTo build your WHERE clause so that it returns a static value,
select Value from the Type list and specify the value in the Value box.
v The before image or the after image of a rowTo build your WHERE
clause so that it returns the before image or the after image of the column,
select Trigger from the Type list and then select either the before image or
the after image of the column from the Value list.
Also, if you want InfoSphere CDC Event Server to detect any missing
before images or after images, then enable the If before/after image does
not exist, use other image check box. For example, if you map the before
image of a column to an XML element or attribute and the operation on the
source database was an insert, then because there is no before image of that
column, InfoSphere CDC Event Server inserts the after image of the column
instead when you enable this check box. Also, if you map the after image of
a column to XML element or attribute and the operation on the source
database was a delete, then because there is no after image of a delete
operation, InfoSphere CDC Event Server inserts the before image of that
column instead.
v The column of a parent tableTo build your WHERE clause so that it
returns the column of the parent table, select Parent Table Column from the

310 InfoSphere Change Data Capture Management Console: Administration Guide

 Type list and then select the column name from the Value list. This option
is only available if the table is added a child of a parent table.
18. Click Next.
19. On the GROUP BY clause page, group the results by one or more columns.
The GROUP BY clause is optional. When specified, it can be used in a
SELECT statement to collect data across multiple rows.
20. Click Next.
21. On the ORDERED BY clause page, sort the records in your result set. The
ORDER BY clause is optional. You can order the result set in either ascending
or descending order.
22. Click Finish.
Related concepts
Querying columns from other tables on page 309

Customizing JMS message destination mappings 311

312 InfoSphere Change Data Capture Management Console: Administration Guide
Setting JMS message header properties
Only available for subscriptions targeting a JMS message destination, you can use
the XML Settings tab to set JMS message header properties for the XML message.
These properties are saved on the source table to XML mapping and are valid each
time you send the XML message to a queue or topic. You can edit these values
using the expression editor at any time.

In addition to the JMS header properties provided with InfoSphere CDC Event
Server, you may also need to associate extra information in the header of an XML
message. InfoSphere CDC Event Server lets you specify custom JMS header
properties in an XML message. You can use this information in a JMS selector to
filter messages.

In this section, you will learn:

Defining the JMS message header
Setting general runtime options on page 315

Defining the JMS message header

You can add and delete JMS message header properties. You can also add or delete
custom properties that you create.

See also:
To add a JMS message header property
To add a custom JMS message header property on page 314
To delete a custom JMS message header property on page 314

To add a JMS message header property

1. Click Configuration > Datastores.
Ensure that you are connected to an Event Server datastore.
2. Click Configuration > Subscriptions.
Ensure that you have created a subscription that uses the Event Server
datastore as the target.
3. Select the subscription that contains the table mapping to a message
destination.
4. Click the Table Mappings view and select the table mapping from the Source
Table column.
5. Right-click Open Mapping Details.
6. Click the XML Settings tab.
7. Select one of the following in the Standard Settings area:
v JMS Correlation IDProvides a way to correlate related messages. This is
normally used for a request or response scenario. This can either be a
vendor-specific ID, an application-specific string, or a provider-native byte
value.
v JMS PriorityIndicates the priority at which the JMS server will handle
the message. By default, InfoSphere CDC Event Server assigns a priority of

Copyright IBM Corp. 2008, 2011 313

 4. JMS uses a priority scale from 0 to 9, where 0 indicates the lowest
priority and 9 indicates the highest priority.
v JMS Reply ToContains a destination supplied by a client when a
message is sent. If you want to receive a response from the JMS queue or
topic when either of these destinations receive a message, then specify the
destination.
v JMS Time to LiveSpecifies the number of milliseconds that you want the
XML message to remain in the queue or topic. This value is used by your
JMS provider to delete XML messages automatically once the amount of
time specified in the box expires. The default value is 0, which indicates
that the XML message will never be deleted automatically from the queue
or topic.
v JMS TypeSpecifies the type of message you are sending. This could be
the name of the queue or topic. Your JMS provider can use a message
repository that contains the definition of messages sent by third party
applications. You should enter a symbolic value that can be configured to
the values defined in the current providers' message repository.
8. Click to open the expression editor and set a value for the JMS property.
9. Specify a value (enclose the value in quotation marks) or an expression for the
JMS property and click Verify .
10. Click OK.
11. Click Save.
Related concepts
Setting JMS message header properties on page 313

To add a custom JMS message header property

1. Click Configuration > Datastores.
Ensure that you are connected to an Event Server datastore.
2. Click Configuration > Subscriptions.
Ensure that you have created a subscription that uses the Event Server
datastore as the target.
3. Select the subscription that contains the table mapping to a message
destination.
4. Click the Table Mappings view and select the table mapping from the Source
Table column.
5. Right-click Open Mapping Details.
6. Click the XML Settings tab.
7. Click Add.
8. Type the name of the JMS property and click OK.
9. Click to set a value in the Expression editor.
10. Click OK.
11. Click Save.
Related concepts
Setting JMS message header properties on page 313

To delete a custom JMS message header property

1. Click Configuration > Datastores.
Ensure that you are connected to an Event Server datastore.

314 InfoSphere Change Data Capture Management Console: Administration Guide

 2. Click Configuration > Subscriptions.
Ensure that you have created a subscription that uses the Event Server
datastore as the target.
3. Select the subscription that contains the table mapping to a message
destination.
4. Click the Table Mappings view and select the table mapping from the Source
Table column.
5. Right-click Open Mapping Details.
6. Click the XML Settings tab.
7. Select the JMS property you want to delete in the Custom Settings area.
8. Click Delete.
9. Click Save.
Related concepts
Setting JMS message header properties on page 313

Setting general runtime options

You can set the following runtime options:
v Trim textBy default, InfoSphere CDC Event Server does not trim trailing
spaces from values in the message body and message header. You can enable
this option so that InfoSphere CDC Event Server trims the trailing spaces.
v Nullable XPath expressionBy default, InfoSphere CDC Event Server
differentiates between empty strings and a null value. Most XML parsers return
an empty string if a referenced node does not exist in the source table. This
results in no distinction between an empty string and a null value. However,
InfoSphere CDC Event Server can differentiate a real empty string (the node
does exist, but contains an empty value) from a null value (the referenced node
does not exist at all). Disable this option if you do not want InfoSphere CDC
Event Server to distinguish between empty strings and a null value.
v Allowed streamed transformation modeBy default, InfoSphere CDC Event
Server uses IBM's Streamed XML Transformation (XST). Disable this check box if
you want InfoSphere CDC Event Server to use the Document Object Model
(DOM) instead. The XST technology will dynamically switch parsing mode
between (Simple API for XML) SAX and DOM depending on your
transformation requirements. This may affect the performance but may be
necessary in some cases.

See also:
To enable InfoSphere CDC Event Server to trim text
To disable InfoSphere CDC Event Server from differentiating between an
empty string from a NULL value on page 316
To disable streamed transformation mode on page 316

To enable InfoSphere CDC Event Server to trim text

1. Click Configuration > Datastores.
Ensure that you are connected to an Event Server datastore.
2. Click Configuration > Subscriptions.
Ensure that you have created a subscription that uses the Event Server
datastore as the target.

Setting JMS message header properties 315

 3. Select the subscription that contains the table mapping to a message
destination.
4. Click the Table Mappings view and select the table mapping from the Source
Table column.
5. Right-click Open Mapping Details.
6. Click the XML Settings tab.
7. Enable the Trim Text check box to trim the trailing spaces from all values in the
message body and message header.
8. Click Save.
Related concepts
Setting general runtime options on page 315

To disable InfoSphere CDC Event Server from differentiating

between an empty string from a NULL value
1. Click Configuration > Datastores.
Ensure that you are connected to an Event Server datastore.
2. Click Configuration > Subscriptions.
Ensure that you have created a subscription that uses the Event Server
datastore as the target.
3. Select the subscription that contains the table mapping to a message
destination.
4. Click the Table Mappings view and select the table mapping from the Source
Table column.
5. Right-click Open Mapping Details.
6. Click the XML Settings tab.
7. Disable the Nullable XPath expression check box.
8. Click Save.
Related concepts
Setting general runtime options on page 315

To disable streamed transformation mode

1. Click Configuration > Datastores.
Ensure that you are connected to an Event Server datastore.
2. Click Configuration > Subscriptions.
Ensure that you have created a subscription that uses the Event Server
datastore as the target.
3. Select the subscription that contains the table mapping to a message
destination.
4. Click the Table Mappings view and select the table mapping from the Source
Table column.
5. Right-click Open Mapping Details.
6. Click the XML Settings tab.
7. Disable the Enable streamed transformation mode check box.
8. Click Save.
Related concepts
Setting general runtime options on page 315

316 InfoSphere Change Data Capture Management Console: Administration Guide

Configuring replication
After creating subscriptions and mapping your tables between your source and
target, you can configure replication in the Configuration perspective of
Management Console. Configuration involves tasks such as flagging tables for
refresh, marking a table capture point on a source table, changing the replication
method, and parking a table from replication. Configuring replication is often
necessary before proceeding to operational tasks such as starting replication or
starting a refresh.

The Configuration perspective requires Administrator or Operator role privileges

for read and write access. The Monitor role cannot view the Configuration
perspective.

In this section, you will learn:

Flagging a source table for refresh
Marking a table capture point on a source table on page 320
Parking a table from replication on page 321
Changing the refresh order of tables on page 321
Changing the replication method of a table on page 322
Selecting a new journal table on page 323
Setting members for replication on page 325
Changing the message destination on page 325

Flagging a source table for refresh

The InfoSphere CDC refresh operation is designed to synchronize source and target
tables. Tables can become out of synchronization for various reasons, including the
following issues:
v Parked tablesParking a table from replication for some time to make changes
(such as updating the definition of a source table) and the changes that are
taking place on the source are no longer being replicated. This may cause the
target table to become inconsistent with the source table.
v Configuration changesA refresh may be necessary when a set of subscriptions
are promoted from a test environment to a production environment. The
promotion operation may add new transformations or other table mapping
changes which require the source and target tables to be refreshed in order to
prepare for mirroring.
v Maintenance operationsLarge bulk SQL operations performed during
maintenance windows on the source table which affect a majority of the rows
may be faster to resynchronize using refresh. Refresh may be faster than
mirroring to replicate millions of changes due to the ability to bulk load rows
into the target database.

When you have a subscription that contains a target table that is not synchronized
with the source table, you can flag the source table for a refresh. Tables that are
flagged for refresh and have a replication method of Mirror will be refreshed
before mirroring begins.

Copyright IBM Corp. 2008, 2011 317

 InfoSphere CDC will refresh all of the flagged tables within a single subscription as
one sequential operation which will run to completion. Each table is refreshed
individually one at a time until all flagged tables have finished refreshing. Refresh
is an operation which applies to a single subscription, so while one subscription is
refreshing other subscriptions are not affected; they may continue mirroring data
for different tables or refreshing tables as required. To perform a parallel refresh,
multiple subscriptions can be used.

InfoSphere CDC offers two types of refresh operations: Standard Refresh and
Differential Refresh.

A Standard Refresh results in a complete copy of the data in a source table being
sent to the target table. This operation truncates or deletes the contents of the
target table and then inserts the new contents as sent by the source system.

A Differential Refresh updates the target table by applying only the differences
between it and the source table. Instead of the target table being cleared at the start
of the refresh and repopulated with data, as with the Standard Refresh, the
Differential Refresh compares each row in the target table with each row in the
source table to identify missing, changed or additional rows. The primary
advantage of the Differential Refresh is that the target table stays online during the
refresh operation.

There are three possible methods for the Differential Refresh:

v Refresh OnlyPerforms a Differential Refresh by changing any target rows that
differ from the source rows.
v Refresh and Log DifferencesPerforms a Differential Refresh, and also creates
a log table in the target replication engine metadata to track all changes during
the refresh. The log table is identical to the target table, with the addition of a
column to indicate the actions taken during the refresh, such as inserting a row,
deleting a row, or updating a row. For an update, both the source and target row
images are logged. This log table is created in the same database and tablespace
as the TS_CONFAUD table (or DMMD_DMCONFAUD table for InfoSphere
CDC for z/OS), with the same owner as the metadata. The name of the log table
is created by combining the subscription name, the target table name, and the
refresh start date and time.
v Only Log DifferencesCreates and populates a log table in the target
replication engine metadata to identify all differences between the source and
target tables. The target table is not updated. This allows you to evaluate what
the differences are between the target and the source. If you then decide to
refresh the table, you can go back to the subscription and select Refresh Only to
update the target table or update the target table manually based on the contents
of the log table.

Performing a Differential Refresh has some requirements and restrictions:

v Differential refresh is only available for tables that use Standard replication
v The collation sequence of the source and target tables must be identical
v Derived columns on the source table are not supported
v Any target columns which are mapped to derived expressions, constants or
journal control fields will be ignored
v The key columns of the target table must be mapped directly to columns on the
source table.

318 InfoSphere Change Data Capture Management Console: Administration Guide

 Both a Standard Refresh and Differential Refresh can be further refined through the
use of a WHERE clause to only include rows within a specified range. This is
useful for tables where only the most recent data requires a refresh.

This feature requires one of the following conditions be met:

v The table capture point has been set, either explicitly or through the table having
been mirrored
v The scraping point for the subscription has been set (using the SETLOGPOS
command or dmsetbookmark command where applicable)

The order in which data is retrieved from the database during a refresh depends
on the type of refresh performed. During a Standard Refresh, no ORDER BY sort is
used; the database determines the order in which the data is returned. During a
Differential Refresh, InfoSphere CDC queries the database using an ORDER BY
sort on the table keys chosen in the table mapping to sort the source and target
tables and determine their differences.

When a refresh is performed with multiple tables, the order in which each
individual table is refreshed is based on the group order, as set in Refresh Order
option. If no Refresh Order is set, then tables are refreshed in alphabetical order.

After a refresh has successfully completed, the subscription can be restarted for
mirroring. InfoSphere CDC will then process the backlog of changes. For tables
which weren't refreshed InfoSphere CDC will continue processing changes from
the position where mirroring ended. For tables which were refreshed, InfoSphere
CDC will process all the changes that committed after refresh began for that table.

See also:
To flag a source table for a Standard Refresh
To flag a source table for a Differential Refresh on page 320
Related concepts
Changing the refresh order of tables on page 321
Starting a refresh on a subscription on page 330

To flag a source table for a Standard Refresh

1. Ensure that the subscription has at least one table mapping with replication
method set to Mirror. You set this when mapping tables in the Map Tables
wizard.
2. Ensure that you have ended any active replication on the subscription.
3. Click Configuration > Subscriptions.
4. Select the subscription that contains the mapped source and target tables.
5. Select the mapped source and target tables in the Table Mappings view.
6. Right-click and click Flag for Refresh ....
7. Select Standard Refresh.
8. Enable the Refresh only a subset of rows check box to define the subset of
rows within the table that will be refreshed. Enter an SQL WHERE clause in
either the Source WHERE clause or Target WHERE clause list box. The Use
SQL WHERE clause check box option is not available if you have selected
multiple table mappings or if you have installed InfoSphere CDC version 6.3
Fix Pack 3 and earlier.
9. Click OK.

Configuring replication 319

 Related concepts
Starting and ending replication on page 327
Mapping tables on page 79
Flagging a source table for refresh on page 317
Controlling the apply of refresh operations on page 189
Ending replication on page 332

To flag a source table for a Differential Refresh

1. Ensure that the subscription has at least one table mapping with replication
method set to Mirror. You set this when mapping tables in the Map Tables
wizard.
2. Ensure that you have ended any active replication on the subscription.
3. Click Configuration > Subscriptions.
4. Select the subscription that contains the mapped source and target tables.
5. Select the mapped source and target tables in the Table Mappings view.
6. Right-click and click Flag for Refresh ....
7. Select Differential Refresh.
8. Select the level of Differential Refresh:
v Refresh OnlyPerforms a Differential Refresh by changing any target rows
that differ from the source rows.
v Refresh and Log DifferencesPerforms a Differential Refresh, and also
creates a log table to track all changes during the refresh.
v Only Log DifferencesCreates and populates a log table to identify all
differences between the source and target tables.
9. Enable the Refresh only a subset of rows check box to define the subset of
rows within the table that will be refreshed. Enter an SQL WHERE clause in
either the Source WHERE clause or Target WHERE clause list box. The Use
SQL WHERE clause check box option is not available if you have selected
multiple table mappings or if you have installed InfoSphere CDC version 6.3
Fix Pack 3 and earlier.
10. Click OK.

Marking a table capture point on a source table

Attention: Only use this procedure when you want to override an existing
position in the stream of changed data. This is possible when you have already
synchronized (refreshed) your source and target tables using an application other
than InfoSphere CDC Management Console (for example, using the import or
export capabilities of your database platform) and you know the point in time
your source and target are synchronized with each other.

InfoSphere CDC mirrors changes to the target table from the current position in
the stream of changed data. This position is set by InfoSphere CDC when you
select Mirror (Change Data Capture) after mapping your tables in the Map Tables
wizard. If you want to override the position set by InfoSphere CDC, then you can
manually mark a table capture point in Management Console. When you decide to
start mirroring on the subscription, InfoSphere CDC identifies the position you
have set as the point in time from which to capture and replicate database changes
to the target.

See also:

320 InfoSphere Change Data Capture Management Console: Administration Guide

 To mark a table capture point on a source table before mirroring

To mark a table capture point on a source table before

mirroring
1. Ensure that your database platform is in idle mode to avoid losing
synchronization between your source and target tables.
2. Ensure that you have ended any active replication on the subscription that
contains the source table.
3. Click Configuration > Subscriptions.
4. Select the subscription that contains the mapped source and target tables.
5. Select the mapped source tables in the Table Mappings view.
You can mark a table capture point on more than one mapped source table at a
time.
6. Right-click and select Mark Table Capture Point For Mirroring.
Related concepts
Marking a table capture point on a source table on page 320
Ending replication on page 332

Parking a table from replication

If your subscription contains more than one table mapping, then you can park one
or more before starting mirroring or a refresh on your subscription. When you
park a table mapping from replication, InfoSphere CDC does not replicate changes
to the target.

See also:
To park a table from replication

To park a table from replication

1. Ensure that you have ended any active replication on the subscription.
2. Click Configuration > Subscriptions.
3. Select the subscription that contains the mapped source and target tables.
4. Select the mapped source and target tables in the Table Mappings view.
You can park more than one table-mapping at a time.
5. Right-click and click Park (Do Not Replicate).
Related concepts
Parking a table from replication
Ending replication on page 332

Changing the refresh order of tables

If you have set referential integrity constraints on your tables, then you can set a
refresh order to preserve these constraints during a refresh. For example, you may
want InfoSphere CDC to refresh your DEPARTMENT tables before refreshing your
EMPLOYEE tables, based on the fact that each employee belongs to a specific
department. You can change the order in which InfoSphere CDC refreshes your
table mappings by moving tables into groups. Each table you decide to move into
a group is assigned a sequence number that InfoSphere CDC uses to refresh each
table mapping in numerical order. For example, if you want InfoSphere CDC to
refresh your DEPARTMENT table before refreshing the EMPLOYEE table, then you

Configuring replication 321

 can add a group for each of these table mappings and move the DEPARTMENT
table in group 1 and the EMPLOYEE table in group 2.

Any remaining table mappings that you did not add to a group are refreshed in
alphabetical order by InfoSphere CDC last.

See also:
To change the refresh order of tables

To change the refresh order of tables

1. Ensure that you have ended any active replication on the subscription.
2. When setting up tables that have referential integrity constraints, ensure that
the target tables are empty before starting replication.
3. Click Configuration > Subscriptions.
4. Select the subscription that contains the mapped source and target tables.
5. Select the table mapping you want InfoSphere CDC to refresh first in the Table
Mappings view.
6. Right-click and click Refresh Order....
7. Click Add New Group to add the first group (Group 1).
Repeat this step for as many groups you want to add.
8. Select one or more source tables to be moved into the group and click Move
To....
9. Select the group to which you want to move the selected tables and click OK.
Related concepts
Changing the refresh order of tables on page 321
Selecting a new journal table on page 323
Ending replication on page 332

Changing the replication method of a table

Your subscription can contain table mappings that have a combination of
replication methods: Mirror or Refresh. You can change the replication method of
one or more of your table mappings within a subscription. Before you can change
the replication method, if you are mirroring the source table to the target, then you
need to end replication on the subscription.

See also:
To change the replication method of a table
Related concepts
Starting mirroring on page 328
Ending replication on page 332

To change the replication method of a table

1. Ensure that you have ended any active replication on the subscription.
2. Click Configuration > Subscriptions.
3. Select the subscription that contains the mapped source and target tables.
4. Select the table mapping in the Table Mappings view.
5. Right-click and click Change Replication Method.
6. Select one of the following options:

322 InfoSphere Change Data Capture Management Console: Administration Guide

 v Mirror (Change Data Capture)Immediately replicates changes made to the
source table to the target table or accumulate source table changes and
replicate at a later time. If your configuration requires you to prevent
recursive updates when mirroring, enable the Prevent Recursion check box.
v Refresh (Snapshot)Replicates a snapshot of the source table to the target
table.

Note: If you are replicating your source table using InfoSphere CDC for
Oracle Trigger-based edition and decide to change the replication method
from Mirror to Refresh, then InfoSphere CDC disassociates the journal table
from the source table. This was the journal table you had selected in the Map
Tables wizard. After InfoSphere CDC completes the refresh operation on the
subscription, if you want InfoSphere CDC to continue mirroring changes
from this source table using the same journal table, then you must change
the replication method back to Mirror and select the same journal table you
were using before.
v Prevent RecursionPrevents InfoSphere CDC from replicating changes back
to the source database when you have configured a subscription for
bidirectional replication. This is only available in versions of InfoSphere CDC
that support both source and target databases. Contact IBM Technical
Support to implement bidirectional replication in your environment.
v Use Relative Record NumberEnables InfoSphere CDC to replicate updates
to the target using a relative record number. When this option is checked,
InfoSphere CDC sends the Relative Record Number to the target and expects
the Relative Record Number to be the identifying column on the target side.
This means that the target tables cannot be updated by more than one source
table (a target table cannot be a warehouse for multiple source tables). If you
do not check this box, then InfoSphere CDC for IBM i uses a unique key to
replicate to the target.

Notes:
When this option is checked, if the source table is reorganized, InfoSphere
CDC Event Server will automatically start a refresh for that table.
If no Relative Record Number is available on the target table (for example,
if the table resides on a non-IBM i system), you can still make use of this
option by mapping the Relative Record Number on the source table to a
column in the target table to. For more information, see Source RRN
(&CNTRRN) on page 174.
This option is only available when using an InfoSphere CDC for IBM i
source.
Related tasks
To set propagation control on a subscription on page 52

Selecting a new journal table

InfoSphere CDC for Oracle Trigger based edition uses journal tables to detect and
replicate database changes to the target table. If you have mapped your source and
target tables and have enabled Mirror (Change Data Capture) in the Map Tables
wizard, then you have already selected a journal table. InfoSphere CDC creates this
table and uses it to track the database operations that occur on your source system.
Each time there is a new row-level operation on your source table, a trigger
executes in response to the database operation and InfoSphere CDC reads the
journal table to identify the database operation that occurred. InfoSphere CDC then
scrapes the database operation from the journal table and replicates it to the target.

Configuring replication 323

 If you want to change the journal table you had selected in the Map Tables
wizard, then you must change the replication method to Refresh so that InfoSphere
CDC can disassociate the journal from the source table. You can then change the
replication method back to Mirror and select a new journal table that you want
InfoSphere CDC to use.

See also:
To select a new journal table

To select a new journal table

1. Ensure that you have ended replication on the subscription.
2. Click Configuration > Subscriptions.
3. Select the subscription that contains the mapped source and target tables.
4. Select a table mapping.
5. Right-click and select Change Replication Method.
6. Select Refresh.
This disassociates the journal table from the source table. If you are using this
same source table in other subscriptions, then you must set the replication
method to Refresh for these subscriptions as well. InfoSphere CDC
disassociates the journal table from the source table in each subscription.
7. Click OK.
The table mapping should have a replication method and status of
Refresh/Refresh.
8. Select the same table mapping and click Change Replication Method.
9. Select Mirror.
This lets you select a new journal table.
10. Select one of the following options and click OK.
v Use Default JournalEnable when you want InfoSphere CDC for Oracle to
use the default journal table provided with InfoSphere CDC for Oracle: <TS
SCHEMA>.DMCJRN. InfoSphere CDC uses this journal table to detect and
replicate database changes from the source to the target.
v Use Selected JournalEnable when you want InfoSphere CDC for Oracle
to use another journal table other than the default journal table provided
with InfoSphere CDC for Oracle. When you select the database owner and
provide a name for the journal table, InfoSphere CDC for Oracle creates this
new journal table and uses it to detect and replicate database changes from
the source to the target.
OwnerLists the database owner of the journal table.
NameLists the name of the journal table.

324 InfoSphere Change Data Capture Management Console: Administration Guide

 Related concepts
Ending replication on page 332
Selecting a new journal table on page 323
Mapping tables on page 79

Setting members for replication

IBM i environments supports a table concept known as multi-member files, in
which one table can possess several different members. Each member is part of the
same table and shares the same schema, but the members are uniquely named and
have unique data. If you have installed InfoSphere CDC for IBM i and have
multi-member source tables, then you can select the members you want InfoSphere
CDC to replicate.

See also:
To select a member for replication

To select a member for replication

1. Ensure that you have ended replication on the subscription.
2. Click Configuration > Subscriptions.
3. Select the subscription that contains the mapped source and target tables.
4. Select a table mapping.
5. Right-click, click Set Member Replication.
6. You can choose from one of the following:
v All current and future membersEnables InfoSphere CDC to replicate all
members, including members you may add a future point in time.
v Selected members onlyEnables InfoSphere CDC to only replicate the
members you selected.
Related concepts
Setting members for replication

Changing the message destination

This option is only available for subscriptions that use InfoSphere CDC Event
Server as the target datastore. You can change the JMS message destination of a
table mapping.

See also:
To change the message destination of a table

To change the message destination of a table

1. Click Configuration > Datastores.
Ensure that you are connected to an Event Server datastore.
2. Click Configuration > Subscriptions.
Ensure that you have created a subscription that uses the Event Server
datastore as the target.
3. Select a subscription that contains the table mapping to a message destination.
4. Select the table mapping in the Table Mappings view.
5. Right-click and select Message Destination.

Configuring replication 325

 6. Select the new message destination and click OK.
Related concepts
Changing the message destination on page 325

326 InfoSphere Change Data Capture Management Console: Administration Guide

Starting and ending replication
With InfoSphere CDC you can mirror data from source tables (using Change Data
Capture replication) that are mapped to target tables in Management Console.
InfoSphere CDC provides two types of mirroring: Continuous and Scheduled End
(Net Change).

As its name implies, Continuous mirroring replicates changes to the target on a

continuous basis. Use this type of mirroring when business requirements dictate
that you need replication to be running continuously and you do not have a
clearly defined reason to end replication at the present time.

Scheduled End (Net Change) mirroring replicates changes (to the target) up to a
user-specified point in the source database log and then ends replication. Use this
type of mirroring when business requirements dictate that you only replicate your
data periodically and you have a clearly defined end point for the state of your
target database when replication ends. Scheduled End (Net Change) mirroring
allows you to end replication at the following points in your source database log:
v Current time or Now
v User-specified date and time
v User-specified log position

These user specified end points ensure that your target database is in a known
state when replication ends.

Ending replication allows you to prepare for transitional activities in your business
environment and allows you to move to the next step in your business processes.
If you are replicating data continuously with Continuous mirroring and business
reasons arise that require an end to replication, InfoSphere CDC provides multiple
options that suit most business needs. If your business requirements dictate that
replication must end at a particular point in your source database log because the
target database must be in a known state when replication ends, you can choose
from the following options:
v Current time or Now
v User-specified date and time
v User-specified log position

If business requirements do not require a specific end point but do require a time
frame for ending replication, InfoSphere CDC provides escalating options (Normal,
Immediate, and Abort) that end replication more rapidly at the expense of a
slower start when resuming replication. For example, a routine end to replication
with no particular urgency may require the Normal option, whereas a sudden
business need to end replication rapidly may require the Abort option.

You can also refresh all tables or a subset of tables in your subscription depending
on your business requirements. A refresh sends a complete copy of data in a source
table to the target table and overwrites any existing rows in the target table. Unlike
mirroring, a refresh operation with InfoSphere CDC does not require additional
database logging which reduces the workload of your source database.

Copyright IBM Corp. 2008, 2011 327

 Operational tasks such as starting and ending replication and starting a refresh are
normally performed in the Monitoring perspective in Management Console and
require Monitor role privileges. Configuration tasks for replication such as flagging
tables for refresh, setting or changing the replication method, marking the table
capture point, and parking tables are performed in the Configuration perspective
of Management Console and require Administrator role privileges for read and
write access and Operator role privileges for read-only access.

In this section, you will learn:

Starting mirroring
Starting a refresh on a subscription on page 330
Ending replication on page 332
Sending XML messages to a JMS message destination on page 334

Starting mirroring
InfoSphere CDC provides two types of mirroring for source tables that are mapped
to target tables: Continuous and Scheduled End (Net Change). The type of
mirroring you select depends on your business needs.

Continuous mirroring replicates changes to the target on a continuous basis. Use

this type of mirroring when business requirements dictate that you need
replication to be running continuously and you do not have a clearly defined
reason to end replication at the present time.

Continuous mirroring is appropriate when your business processes require the

source and target to be synchronized at all times. Continuous mirroring is also
useful if your environment experiences frequent changes to large volumes of data.
Instead of capturing these changes using a batch transfer, you can replicate
changes to the target on a continuous basis.

Scheduled End (Net Change) mirroring replicates changes (to the target) up to a
user-specified point in the source database log and then ends replication. Use this
type of mirroring when business requirements dictate that you only replicate your
data periodically and you have a clearly defined end point for the state of your
target database when replication ends. Scheduled End (Net Change) mirroring
allows you to end replication at the following points in your source database log:
v Current time or Now
v User-specified date and time
v User-specified log position

These user specified end points ensure that your target database is in a known
state when replication ends.

For example, if you start Scheduled End (Net Change) mirroring and specify a
time of 12 PM, InfoSphere CDC will continue mirroring all changes that have been
committed to the target until 12 PM in the source database log. At this point,
mirroring will end. You can also reschedule the Scheduled End (Net Change)
mirroring to a new time or log position if business reasons warrant.

See also:
To start continuous mirroring on page 329
To start scheduled end (net-change) mirroring on page 329

328 InfoSphere Change Data Capture Management Console: Administration Guide

To start continuous mirroring
1. Ensure that the subscription has at least one table mapping with replication
method set to Mirror. You can set the replication method in the Configuration
perspective and also when you map tables in the Map Tables wizard.
2. Click Monitoring > Subscriptions.
3. If the subscription is available for editing, right-click one or more subscriptions
and select Start Mirroring.
The Refresh Details button is displayed if you have one or more tables flagged
for refresh and allows you to view the refresh configuration of these tables.
Continuous mirroring will not start until the refresh of these tables is complete.
4. Select Continuous and click OK to start mirroring.
Mirroring will continue until you end replication.
Related concepts
Starting mirroring on page 328
Related tasks
To start scheduled end (net-change) mirroring
To flag a source table for a Standard Refresh on page 319

To start scheduled end (net-change) mirroring

1. Ensure that the subscription has at least one table mapping with replication
method set to Mirror. You can set the replication method in the Configuration
perspective and also when you map tables in the Map Tables wizard.
2. Click Monitoring > Subscriptions.
3. If the subscription is available for editing, right-click one or more subscriptions
and select Start Mirroring.
The Refresh Details button is displayed if you have one or more tables flagged
for refresh and allows you to view the refresh configuration of these tables.
Scheduled End (Net Change) mirroring will not start until the refresh of these
tables is complete.
4. Depending on your version of InfoSphere CDC, choose one of the following
options.
InfoSphere CDC version 6.5:
v Scheduled EndInfoSphere CDC mirrors all committed database changes in
the source database and then ends replication normally at the indicated
point.
NowInfoSphere CDC mirrors all committed database changes in the
source database and then ends replication normally at the current source
system time in the database log. The source system time when replication
will end is set when you click OK.
Specific Date/TimeInfoSphere CDC mirrors all committed database
changes in the source database and then ends replication normally at the
specified date and time in your source system database log. The current
Coordinated Universal Time (UTC) offset (in minutes) of your InfoSphere
CDC source system is displayed as a hint.
Specific Log PositionInfoSphere CDC mirrors all committed database
changes in the source database and then ends replication normally at the
specified log position in your source database log. The format of a valid
log position for this subscription is displayed as a hint.
InfoSphere CDC version 6.3 and earlier:

Starting and ending replication 329

 v Scheduled End (Net Change)InfoSphere CDC will continue mirroring up
until the current source system time in the database log and then end
replication. The source system time when replication will end is set when
you click OK.
5. Click OK to start Scheduled End (Net Change) mirroring.
After starting Scheduled End (Net Change) mirroring, you also have the
option of rescheduling the end of replication to a more suitable time or log
position if business reasons warrant.
Related concepts
Starting mirroring on page 328
Related tasks
To start continuous mirroring on page 329
To flag a source table for a Standard Refresh on page 319

Starting a refresh on a subscription

The InfoSphere CDC refresh operation is designed to synchronize source and target
tables. Tables can become out of synchronization for various reasons, including the
following issues:
v Parked tablesParking a table from replication for some time to make changes
(such as updating the definition of a source table) and the changes that are
taking place on the source are no longer being replicated. This may cause the
target table to become inconsistent with the source table.
v Configuration changesA refresh may be necessary when a set of subscriptions
are promoted from a test environment to a production environment. The
promotion operation may add new transformations or other table mapping
changes which require the source and target tables to be refreshed in order to
prepare for mirroring.
v Maintenance operationsLarge bulk SQL operations performed during
maintenance windows on the source table which affect a majority of the rows
may be faster to resynchronize using refresh. Refresh may be faster than
mirroring to replicate millions of changes due to the ability to bulk load rows
into the target database.

When you have a subscription that contains a target table that is not synchronized
with the source table, you can flag the source table for a refresh. Tables that are
flagged for refresh and have a replication method of Mirror will be refreshed
before mirroring begins.

InfoSphere CDC will refresh all of the flagged tables within a single subscription as
one sequential operation which will run to completion. Each table is refreshed
individually one at a time until all flagged tables have finished refreshing. Refresh
is an operation which applies to a single subscription, so while one subscription is
refreshing other subscriptions are not affected; they may continue mirroring data
for different tables or refreshing tables as required. To perform a parallel refresh,
multiple subscriptions can be used.

InfoSphere CDC offers two types of refresh operations: Standard Refresh and
Differential Refresh.

A Standard Refresh results in a complete copy of the data in a source table being
sent to the target table. This operation truncates or deletes the contents of the
target table and then inserts the new contents as sent by the source system.

330 InfoSphere Change Data Capture Management Console: Administration Guide

A Differential Refresh updates the target table by applying only the differences
between it and the source table. Instead of the target table being cleared at the start
of the refresh and repopulated with data, as with the Standard Refresh, the
Differential Refresh compares each row in the target table with each row in the
source table to identify missing, changed or additional rows. The primary
advantage of the Differential Refresh is that the target table stays online during the
refresh operation.

There are three possible methods for the Differential Refresh:

v Refresh OnlyPerforms a Differential Refresh by changing any target rows that
differ from the source rows.
v Refresh and Log DifferencesPerforms a Differential Refresh, and also creates
a log table in the target replication engine metadata to track all changes during
the refresh. The log table is identical to the target table, with the addition of a
column to indicate the actions taken during the refresh, such as inserting a row,
deleting a row, or updating a row. For an update, both the source and target row
images are logged. This log table is created in the same database and tablespace
as the TS_CONFAUD table (or DMMD_DMCONFAUD table for InfoSphere
CDC for z/OS), with the same owner as the metadata. The name of the log table
is created by combining the subscription name, the target table name, and the
refresh start date and time.
v Only Log DifferencesCreates and populates a log table in the target
replication engine metadata to identify all differences between the source and
target tables. The target table is not updated. This allows you to evaluate what
the differences are between the target and the source. If you then decide to
refresh the table, you can go back to the subscription and select Refresh Only to
update the target table or update the target table manually based on the contents
of the log table.

Performing a Differential Refresh has some requirements and restrictions:

v Differential refresh is only available for tables that use Standard replication
v The collation sequence of the source and target tables must be identical
v Derived columns on the source table are not supported
v Any target columns which are mapped to derived expressions, constants or
journal control fields will be ignored
v The key columns of the target table must be mapped directly to columns on the
source table.

Both a Standard Refresh and Differential Refresh can be further refined through the
use of a WHERE clause to only include rows within a specified range. This is
useful for tables where only the most recent data requires a refresh.

This feature requires one of the following conditions be met:

v The table capture point has been set, either explicitly or through the table having
been mirrored
v The scraping point for the subscription has been set (using the SETLOGPOS
command or dmsetbookmark command where applicable)

The order in which data is retrieved from the database during a refresh depends
on the type of refresh performed. During a Standard Refresh, no ORDER BY sort is
used; the database determines the order in which the data is returned. During a

Starting and ending replication 331

 Differential Refresh, InfoSphere CDC queries the database using an ORDER BY
sort on the table keys chosen in the table mapping to sort the source and target
tables and determine their differences.

When a refresh is performed with multiple tables, the order in which each
individual table is refreshed is based on the group order, as set in Refresh Order
option. If no Refresh Order is set, then tables are refreshed in alphabetical order.

After a refresh has successfully completed, the subscription can be restarted for
mirroring. InfoSphere CDC will then process the backlog of changes. For tables
which weren't refreshed InfoSphere CDC will continue processing changes from
the position where mirroring ended. For tables which were refreshed, InfoSphere
CDC will process all the changes that committed after refresh began for that table.

See also:
To start a refresh
Related concepts
Promoting subscription changes on page 349
Flagging a source table for refresh on page 317
Changing the refresh order of tables on page 321

To start a refresh
1. Stop mirroring on any active subscriptions that will have tables refreshed.
2. Ensure that the tables to be refreshed have been flagged for refresh.
3. Click Monitoring > Subscriptions.
4. If the subscription is available for editing, right-click one or more subscriptions
and select Start Refresh.
The Start Refresh dialog shows all tables in the selected subscriptions that have
been flagged for refresh
5. If you want to view the refresh details for a specific table, select it and click
Refresh Options.
If multiple table mappings were selected, any enabled row constraints will not
be displayed on the Refresh Options dialog.
6. Click OK.
Related concepts
Controlling the apply of refresh operations on page 189

Ending replication
Ending replication allows you to prepare for transitional activities in your business
environment and allows you to move to the next step in your business processes.
Here are some examples of transitional activities in your business environment that
may require an end to replication:
v Initiating a database backup.
v Performing a regularly scheduled reboot of your source database server.
v Quiescing your database in preparation for an upgrade.
v Weekly batch processing has just completed.
v Preparing for off-line maintenance activities.

If you are replicating data continuously with Continuous mirroring and business
reasons arise that require an end to replication, InfoSphere CDC provides multiple
332 InfoSphere Change Data Capture Management Console: Administration Guide
 options that suit most business needs. If your business requirements dictate that
replication must end at a particular point in your source database log because the
target database must be in a known state when replication ends, you can choose
from the following options:
v Current time or Now
v User-specified date and time
v User-specified log position

An example of a scenario that might require these options is that you are
populating a reporting instance and you need stable (non-changing) data in your
reporting instance during the day. At the end of the day when you shut down
your application, you can choose one of the Scheduled End (Net Change) options
to update the reporting instance with data from the current day as well.

If business requirements do not require a specific end point but do require a time
frame for ending replication, InfoSphere CDC provides escalating options (Normal,
Immediate, and Abort) that end replication more rapidly at the expense of a
slower start when resuming replication. For example, a routine end to replication
with no particular urgency may require the Normal option, whereas a sudden
business need to end replication rapidly may require the Abort option. A routine
reboot of a SAN might be appropriate for the Normal option, whereas a sudden
and unexpected hardware or application failure may require the Abort option.

If you initiate an end to replication and business reasons warrant a change in the
desired time frame, you can reschedule the end of replication by specifying a new
date and time, a new position in the database log, or choose another option for
ending replication.

Ending replication is also necessary if you want to update and make changes to
your subscription by:
v Adding a table mapping to the subscription.
v Deleting a table mapping from the subscription.
v Temporarily removing a table mapping from the subscription (parking a table).
v Modifying mapping details such as source and target column mappings, derived
columns, data translations, row and column selections, user exits, and so on.
v Updating the properties of a subscription when the structure of your source
and/or target tables change.

See also:
To end replication

To end replication
1. Click Monitoring > Subscriptions.
2. If the subscriptions are available for editing, right-click one or more
subscriptions and select End Replication.
3. Depending on your version of InfoSphere CDC, choose from the following
options.
InfoSphere CDC version 6.5:
v NormalInfoSphere CDC completes in progress work and then ends
replication. If a refresh is in progress, Normal will complete the refresh for
the current table before replication ends.

Starting and ending replication 333

 Normal is the most appropriate option for most business requirements and is
the preferred method for ending replication in most situations.
v ImmediateInfoSphere CDC stops all in progress work and then ends
replication. Starting replication after using this option can be slower than
using the Normal. If a refresh is in progress, the refresh for the current table
will be interrupted and then replication will end.
Attention: Use this option if business reasons require replication to end
faster than Normal at the expense of a slower start when you resume
replication on the subscription.
v AbortInfoSphere CDC stops all in progress work and then ends replication
rapidly. Starting replication after using this option can be much slower than
the Normal. A refresh in progress will be interrupted and the target will stop
processing any data that has not been committed before replication ends.
Attention: Use this option if your business reasons require a rapid end to
replication and you are willing to tolerate a much slower start when you
resume replication on the subscription.
A sudden business requirement for an unplanned shutdown of your source
system may require this option for ending replication.
v Scheduled EndThis option will process all committed database changes in
the source database and then end replication at the indicated point with the
Normal option. This option is not available if all the tables in a subscription
are currently refreshing.
NowEnd replication at the current source system time in your source
database log. The source system time when replication will end is set
when you click OK.
Specific Date/TimeEnd replication with the Normal option at the
specified date and time. InfoSphere CDC displays the UTC offset (in
minutes) of the source database.
Specific Log PositionEnd replication with the Normal option at the
specified log position. InfoSphere CDC displays the format of the log
position for the source datastore.
InfoSphere CDC version 6.3 and earlier:
v ControlledInfoSphere CDC completes all in-progress operations and
applies pending changes to the target table.
v ImmediateInfoSphere CDC interrupts any in-progress operations and does
not apply pending changes to the target table.
4. Click OK.
If business reasons warrant a change in the desired time frame for replication
to end (faster or slower), you can reschedule the end of replication by
specifying a new date and time, a new position in the database log, or choose
another option for ending replication.

Note: As latency between the source and target increases, the amount of time
required to end replication will also increase.

Sending XML messages to a JMS message destination

For InfoSphere CDC Event Server to send the XML message to a JMS message
destination, you must start mirroring on the subscription that contains the table
mapping.

334 InfoSphere Change Data Capture Management Console: Administration Guide

 When you start mirroring on the subscription, InfoSphere CDC Event Server sends
a complete copy of all the rows in your source table to the JMS message
destination, to the staging target table, or both. The subscription stays active and
waits for additional events to occur on the source table.

See also:
To send an XML message to a JMS message destination or a staging target
database

To send an XML message to a JMS message destination or a

staging target database
1. Click Configuration > Datastores.
Ensure that you are connected to an Event Server datastore.
2. Click Configuration > Subscriptions.
Ensure that you have created a subscription that uses the Event Server
datastore as the target.
3. Select the subscription that contains the table mapping to a message
destination, a staging target table, or both.
4. Click the Table Mappings view and select the table mapping.
Ensure that you have set the replication method for this table mapping to
Mirror (Change Data Capture).
5. Click Monitoring > Subscriptions.
6. Select the subscription that contains the table mapping, right-click Start
Mirroring.
If this is the first time you are starting replication, InfoSphere CDC Event
Server sends a copy of all the rows to your message destination, staging target
table, or both. After this is complete, it switches to Mirror Continuous.
Related concepts
Sending XML messages to multiple JMS message destinations on page 215
Related tasks
To create an XML message on page 305

Starting and ending replication 335

336 InfoSphere Change Data Capture Management Console: Administration Guide
Setting notifications
You can use notifications when you want to be alerted of any problems in your
replication environment. Notifications are most useful when performing diagnostic
analysis of replication activities in the Management Console and you want to
detect events that are happening in your source datastores, target datastores and
subscriptions.

Setting notifications for datastores and subscriptions

You can set notifications so that they are sent from either a source or target
datastore, or set notifications so that they are sent from a subscription. When you
set a notification on the datastore, the InfoSphere CDC loads these as default
notification settings across all subscriptions that use that datastore. This means that
each subscription that uses the datastore for replication inherits the notification
settings by default. Setting notifications at the datastore level is useful when you
want to set the same notifications for all your datastores regardless of which
subscriptions use them. However, if you have a subscription that uses the same
datastore in some special way, then you can set the notification at the subscription
level.

Set notifications from the datastore before setting notifications from each
subscription. This is to help you during diagnose and track the location of your
notifications.

Filtering notifications

You can filter notifications. When an event occurs in your replication environment,
InfoSphere CDC generates messages in the Events area of the Subscriptions view
of the Monitoring perspective. Each message is identified with an event ID. Using
the event ID, you can specify the messages for which you want to be notified or
those which should be suppressed. For example, if you want to be notified when
mirroring fails on a subscription, you can specify the event ID for that message in
the Filter Messages dialog box.

Copying notifications

You can copy notification settings to notification categories in the same datastore or
subscription. Email notification settings include information such as the name of
the person to which you send a notification or the subject line of an e-mail. You
can copy this information to other notification categories in the same datastore.

For example, you may have already set an e-mail notification that gets sent to
john_smith@ibm.com when the datastore DM0001@50000 on the source-side detects
a fatal communications error on the network. You may have set other notifications
that get sent in different events, but want all those notifications sent to the same
account. Instead of having to manually specify that john_smith@ibm.com receive
all notifications detected from DM0001@50000 in each notification, you can copy
this setting to other notification categories. Before you setup an e-mail notification
for MAPI, you should read the considerations outlined for these protocols in your
InfoSphere CDC for Microsoft SQL Server documentation.

Copyright IBM Corp. 2008, 2011 337

 Setting latency thresholds and notifications

You can also set latency notifications that alert you when InfoSphere CDC has
passed your warning or problem thresholds. You must specify a threshold before
you can set up a notification.

In this section, you will learn:

Selecting a notification handler
Choosing a notification category and a message type on page 339
Setting notifications for a datastore on page 340
Setting notifications for a subscription on page 345
Copying notifications for a subscription on page 346
Setting latency thresholds and notifications on page 346

Selecting a notification handler

Before setting up a notification, you need to decide on the kind of notification
handler you want to use to receive notifications. Notification handlers specify how
you want a certain notification to be handled. You can set a notification so that it is
handled through e-mail, message queues, or user exits. For example, you may
want to send messages to an e-mail address, relay a message to a message queue,
or you may prefer to set up a user exit that triggers certain operations upon
specific InfoSphere CDC events.

Depending on the InfoSphere CDC product you have installed, you can select
certain notification handlers in the Notifications dialog box:
v Message QueueYou can indicate that you want to relay a message to a
specified message queue when a certain type of message is generated. You have
the option of relaying that message to up to ten different message queues. To
specify a message queue, you need to specify both the name of the message
queue and the library where it resides.
v User Exit/User HandlerYou can indicate that you want to launch a user exit
program when a certain type of message is generated. Note that you are
responsible for creating the user exit program and ensuring that it works
properly. For more information about creating user exit programs for alerts and
alarms, see the appropriate InfoSphere CDC End-User Documentation.
v EmailYou can indicate that you want to send the generated message to an
e-mail address. Depending on the type of datastore, SMTP (Simple Mail Transfer
Protocol) and MAPI (Messaging Application Program Interface) can be used for
sending e-mail messages. Unless explicitly stated, each setting described below
applies to both SMTP and MAPI.
v SNMP (Simple Network Management Protocol)You can indicate that you
want to send a trap containing the generated message to an SNMP management
system.
v Event LogYou can indicate that you want to send the generated message to
the Windows application log.
v TSDPRINTYou can indicate that you want to send the generated message to
the TSDPRINT spool file provided with InfoSphere CDC for z/OS.

338 InfoSphere Change Data Capture Management Console: Administration Guide

 SYSLOG
v DB2 UDB for z/OSYou can indicate that you want to send the generated
message to the operator system log maintained on zSeries servers. For more
information about the operator system log, see the InfoSphere CDC for z/OS
End-User Documentation.
v Oracle (on UNIX servers only)You can indicate that you want to send a
generated message to the UNIX syslogd program that logs messages from
external applications like InfoSphere CDC
Related concepts
Setting notifications for a datastore on page 340
Setting notifications for a subscription on page 345

Choosing a notification category and a message type

When setting up a notification, you must select a notification category and a
notification message type.

Notification categories

Notification categories represent the events that InfoSphere CDC detects in your
source and target datastores.
v Scrape/Refresh Events (Source)Categorizes notifications that are generated for
events that occur when InfoSphere CDC scrapes or refreshes data from your
source datastore.
v Apply Events (Target)InfoSphere CDC generates notifications related to events
that occur during the target apply process. For example, InfoSphere CDC can
generate a message when there is failure to apply on the target table.
v Communications EventsCategorizes notifications that are generated for
communication events that can occur between source and the target datastores.
For example, InfoSphere CDC can generate a message when there is a failure to
create TCP/IP socket.
v Environment EventsCategorizes notifications that are generated when
requirements for a basic replication environment are not met. For example,
InfoSphere CDC can generate a message when it cannot connect to a database,
or when permissions have not been set.
v Journal/Log Maintenance EventsCategorizes notifications that are generated
when InfoSphere CDC reads the journal or during log maintenance.

Notification message type

v Fatal MessagesEnables you to setup a notification for fatal messages. For
example, InfoSphere CDC can generate a fatal message in the Events area of the
Subscriptions view of the Monitoring perspective when it cannot open or find a
metadata table, or when it encounters a communication error between
datastores.
v Error MessagesEnables you to setup a notification for error messages.
InfoSphere CDC sends a notification when it encounters an error. For example,
InfoSphere CDC can generate an error message in the Events area of the
Subscriptions view of the Monitoring perspective when it inserts a row and
creates a duplicate key, or when it encounters a runtime verification error on a
derived expression.
v Informational MessagesEnables you to setup a notification for informational
messages. InfoSphere CDC sends a notification when it encounters an event that
you need to know about. For example, InfoSphere CDC can generate

Setting notifications 339

 informational messages in the Events area of the Subscriptions view of the
Monitoring perspective when it is ready to mirror tables, or when it encounters
instances that require code page conversions.
v Status MessagesEnables you to setup a notification for status messages.
InfoSphere CDC sends a notification when it encounters a specific event during
replication. For example, InfoSphere CDC can generate status messages in the
Events area of the Subscriptions view of the Monitoring perspective when it is
going to refresh a table, when it cannot journal changes on a table, or when it
has parked a table for replication.
v Operational MessagesEnables you to setup a notification for operational
messages. InfoSphere CDC sends a notification when it has completed an
operation during replication. For example, InfoSphere CDC can generate
operational messages in the Events area of the Subscriptions view of the
Monitoring perspective after applying an operation to the target table, or when
it has completed a refresh on a table.
Related concepts
Setting notifications for a datastore
Setting notifications for a subscription on page 345

Setting notifications for a datastore

Use the Source tab or the Target tab in the Notifications dialog box to set up a
notification. InfoSphere CDC can generate messages for events that occur on either
your source or target datastore.

See also:
To set an e-mail (MAPI) notification
To set an email (SMTP) notification on page 341
To set an e-mail notification (InfoSphere CDC for Oracle) on page 341
To set an e-mail notification on page 342
To set a notification for the CHCPRINT spool file on page 342
To set a notification for an operator system log on page 342
To set a notification for a UNIX system log on page 343
To set a notification using a user exit program on page 343
To set a notification using a user exit program on page 343
To set a notification using a user exit program on page 344
To set a notification for a message queue on page 344
To filter a notification message on page 345

To set an e-mail (MAPI) notification

Note: This task is only applicable if you are connected to an InfoSphere CDC for
Microsoft SQL Server version 5.3 datastore.
1. Verify your version of InfoSphere CDC.
2. Click Configuration > Datastores.
3. Right-click on a datastore and select Notifications.
4. Depending on whether you want InfoSphere CDC to detect events on the
source datastore or on the target datastore, click the Source tab or the Target
tab.
5. Select a category from Notification Categories.

340 InfoSphere Change Data Capture Management Console: Administration Guide

 6. Select Email (MAPI).
7. Type the e-mail address in the Alert Account box. Use a semicolon to separate
multiple e-mail addresses or specify a distribution list from your e-mail
application.
8. Type the subject in theSubject box.
9. Type the name of the mail profile you created to identify the mailbox of the
specific domain user in theProfile box. The subject and profile name cannot
exceed 254 characters.
Related concepts
Setting notifications on page 337
Selecting a notification handler on page 338

To set an email (SMTP) notification

Note: This task is only applicable if you are connected to an InfoSphere CDC for
Microsoft SQL Server version 5.3 datastore.
1. Verify your version of InfoSphere CDC.
2. Click Configuration > Datastores.
3. Right-click on a datastore and select Notifications.
4. Depending on whether you want InfoSphere CDC to detect events on the
source datastore or on the target datastore, click the Source tab or the Target
tab.
5. Select a category from Notification Categories.
6. Select Email (SMTP).
7. Type the email address that will receive the e-mail in the Alert Account box.
Use a semicolon to separate multiple e-mail addresses or specify a distribution
list from your email application.
8. Type the host name of your outgoing mail server in the SMTP Mail Host box.
9. Type the e-mail address that will send the generated messaged in the Sender
Account box.
Related concepts
Setting notifications on page 337
Selecting a notification handler on page 338

To set an e-mail notification (InfoSphere CDC for Oracle)

Note: This task is only applicable if you are connected to an InfoSphere CDC for
Oracle datastore.
1. Click Configuration > Datastores.
2. Right-click on a datastore and select Notifications.
3. Depending on whether you want InfoSphere CDC to detect events on the
source datastore or on the target datastore, click the Source tab or the Target
tab.
4. Select a category from Notification Categories.
5. Select the Email box.
6. Type the e-mail address in the Address box. Use a semicolon to separate
multiple e-mail addresses or specify a distribution list from your e-mail
application.
7. Type the subject in the Subject box. The subject cannot exceed 254 characters.

Setting notifications 341

 Related concepts
Setting notifications on page 337
Selecting a notification handler on page 338

To set an e-mail notification

Note: This task is only applicable if you are connected to an InfoSphere CDC for
DB2 LUW datastore, InfoSphere CDC for Microsoft SQL Server version 6.0
datastore, or an InfoSphere CDC for Teradata datastore.
1. Click Configuration > Datastores.
2. Right-click on a datastore and select Notifications.
3. Depending on whether you want InfoSphere CDC to detect events on the
source datastore or on the target datastore, click the Source tab or the Target
tab.
4. Select a category from Notification Categories.
5. Select the INTERNET MAIL box.
6. Type the host name of your outgoing mail server in the SMTP Mail Host box.
7. Type the e-mail address that you want to notify in the Alert Account box. Use
a semicolon to separate multiple e-mail addresses or specify a distribution list
from your e-mail application.
8. Type your e-mail address in the Sender Mail Address box.
9. Type your e-mail password in the Sender Mail Password box.
Related concepts
Setting notifications on page 337
Selecting a notification handler on page 338

To set a notification for the CHCPRINT spool file

1. Click Configuration > Datastores.
2. Ensure that you are connected to an InfoSphere CDC for z/OS datastore.
3. Right-click on a datastore and select Notifications.
4. Depending on whether you want InfoSphere CDC to detect events on the
source datastore or on the target datastore, click the Source tab or the Target
tab.
5. Select a category from Notification Categories.
6. Select the CHCPRINT box.
Related concepts
Setting notifications on page 337
Selecting a notification handler on page 338

To set a notification for an operator system log

1. Click Configuration > Datastores.
2. Ensure that you are connected to an InfoSphere CDC for z/OS datastore.
3. Right-click on a datastore and select Notifications.
4. Depending on whether you want InfoSphere CDC to detect events on the
source datastore or on the target datastore, click the Source tab or the Target
tab.
5. Select a category from Notification Categories.
6. Select the SYSLOG box.

342 InfoSphere Change Data Capture Management Console: Administration Guide

 Related concepts
Setting notifications on page 337
Selecting a notification handler on page 338

To set a notification for a UNIX system log

1. Contact your UNIX system administrator to find out how many log channels
are configured in your environment.
This program supports up to eight log channels and identifies different
locations where you can place messages. You can configure log channels using
a predefined configuration file (/etc/syslog.conf).
2. Click Configuration > Datastores.
3. Ensure that you are connected to an InfoSphere CDC for Oracle datastore.
4. Right-click on a datastore and select Notifications.
5. Depending on whether you want InfoSphere CDC to detect events on the
source datastore or on the target datastore, click the Source tab or the Target
tab.
6. Select a category from Notification Categories.
7. Select the Syslog box.
8. Type the number of the log channel in the Facilities box.
Routes messages to the location specified in the configuration file
(/etc/syslog.conf). The number must be between 0 and 7 and it corresponds
to the number specified in the configuration file.
9. Type a string in the ID box.
Appends to all messages routed through the log channel. You can attach an
identifier for each message.
Related concepts
Setting notifications on page 337
Selecting a notification handler on page 338

To set a notification using a user exit program

1. Click Configuration > Datastores.
2. Ensure that you are connected to an InfoSphere CDC for z/OS datastore.
3. Right-click on a datastore and select Notifications.
4. Depending on whether you want InfoSphere CDC to detect events on the
source datastore or on the target datastore, click the Source tab or the Target
tab.
5. Select a category from Notification Categories.
6. Select the USER HANDLER box.
7. Type the name of the module in the box.
Related concepts
Setting notifications on page 337
Selecting a notification handler on page 338

To set a notification using a user exit program

1. Click Configuration > Datastores.
2. Ensure that you are connected to an InfoSphere CDC for IBM i datastore.
3. Right-click on a datastore and select Notifications.

Setting notifications 343

 4. Depending on whether you want InfoSphere CDC to detect events on the
source datastore or on the target datastore, click the Source tab or the Target
tab.
5. Select a category from Notification Categories.
6. Select the USER HANDLER box.
7. Type the name of the user exit program in the Program box.
8. Type the name of the library in the Library box.
Related concepts
Setting notifications on page 337
Selecting a notification handler on page 338

To set a notification using a user exit program

1. Click Configuration > Datastores.
2. Ensure that you are connected to an InfoSphere CDC for DB2 LUW datastore,
an InfoSphere CDC for Microsoft SQL Server version 6.0 datastore, an
InfoSphere CDC for PointBase datastore, or an InfoSphere CDC for Teradata
datastore.
3. Right-click on a datastore and select Notifications.
4. Depending on whether you want InfoSphere CDC to detect events on the
source datastore or on the target datastore, click the Source tab or the Target
tab.
5. Select a category from Notification Categories.
6. Select the USER HANDLER box.
7. Type the fully qualified Java class name of the user exit program in the Java
Class Name box.
Related concepts
Setting notifications on page 337
Selecting a notification handler on page 338

To set a notification for a message queue

1. Click Configuration > Datastores.
2. Ensure that you are connected to an InfoSphere CDC for IBM i datastore.
3. Right-click on a datastore and select Notifications.
4. Depending on whether you want InfoSphere CDC to detect events on the
source datastore or on the target datastore, click the Source tab or the Target
tab.
5. Select a category from Notification Categories.
6. Select the Message Queue box.
7. Type the name of the message queue in the Queue box.
You can relay the same message up to 10 message queues.
8. Type the name of the library in the Library box.

344 InfoSphere Change Data Capture Management Console: Administration Guide

 Related concepts
Setting notifications on page 337
Selecting a notification handler on page 338

To filter a notification message

1. Click Configuration > Datastores.
2. Right-click on a datastore and select Notifications.
3. Click Filter Messages.
4. Type the event ID in the box.
If messages are sent from InfoSphere CDC for IBM i, use the full IBM i message
ID when specifying this event ID.
5. Select one of the following:
v Do not send these messagesDoes not send the specified messages.
v Send these messages onlySends the specified messages.
Related concepts
Setting notifications on page 337
Selecting a notification handler on page 338

Setting notifications for a subscription

If you want to send a notification only when a datastore is used by a subscription,
then you can set notifications at the subscription level.

Before setting a notification for a subscription, you should do the following:

v View any default notifications that were set at the datastore level for the
subscription.
v Decide what kind of events you want to be notified about in your replication
environment. When setting notifications you must first identify the category of
the message you want to set, and then decide on a severity level.

See also:
To set notifications for a subscription
To view the datastore default notifications for a subscription on page 346

To set notifications for a subscription

1. Click Configuration > Subscriptions.
2. Right-click on a datastore and select Notifications.
3. Click the Source tab or the Target tab.
4. Select a category from Notification Categories.
5. Clear any default notifications settings to enable the Notification Settings area.
6. Specify how you want to send this notification in the Notification Settings
area.
Depending on the InfoSphere CDC product you have installed, you can send
this notification through e-mail message queues, or a user exit program.

Setting notifications 345

 Related concepts
Setting notifications for a subscription on page 345

To view the datastore default notifications for a subscription

1. Click Configuration > Subscriptions.
2. Right-click on a datastore and select Notifications.
3. Depending on whether you want InfoSphere CDC to detect events on the
source datastore or on the target datastore, click the Source tab or the Target
tab.
4. Click Datastore Defaults.
The Notifications dialog box opens and displays the default notifications that
were set for the datastore.
Related concepts
Setting notifications for a subscription on page 345

Copying notifications for a subscription

You can copy notification settings from one category to another in the same
subscription. For example, e-mail notification settings include information such as
the name of the person to which you send a notification, or you can copy the
subject line of an email between different notification categories on a subscription.

See also:
To copy notification settings

To copy notification settings

1. Click Configuration > Datastores.
2. Right-click on a datastore and select Notifications.
3. Click Source or Target.
4. Select the notification setting.
5. Click Copy Settings.
6. Clear the boxes for the notifications that you do not want to copy. If you want
to copy all notification settings, click OK.
Related concepts
Setting notifications on page 337
Selecting a notification handler on page 338

Setting latency thresholds and notifications

You can set a notification that specifies the latency (in minutes) of a subscription.
This notification specifies how long it takes InfoSphere CDC to apply data to the
target datastore. You must set latency thresholds before you can set a notification.

When you set a notification, InfoSphere CDC sends you a notification after the
following events:
v NormalLatency for the journal or log is below the warning threshold. This
means that latency is acceptable and within your normal range. Latency is
normal according to the latency thresholds you have set for the subscription.

346 InfoSphere Change Data Capture Management Console: Administration Guide

 v WarningLatency for the journal or log is above the warning threshold but
below the problem threshold. Latency is starting to become a problem according
to the latency thresholds you have set for the subscription.
v ProblemLatency for the journal or log is above the problem threshold. Latency
is now a problem according to the latency thresholds you have set for the
subscription.

See also:
To set a latency threshold and notification

To set a latency threshold and notification

1. Click Configuration > Subscriptions.
2. Right-click on a subscription and select Latency Thresholds.
3. Enable the Notify when latency crosses these thresholds check box.
4. Specify a warning threshold (in minutes).
5. Specify a problem threshold (in minutes). The problem threshold must be
greater than the warning threshold.
6. Click Set Notification.
7. As a best practice, ensure that Target > Apply > Informational is enabled. You
must configure at least one notification setting in the Informational category so
that you can receive notification messages and this must be set on the Target
tab. These changes will take effect the next time you start replication on this
subscription.
8. Specify how you want to send this notification in the Notification Settings
area.
Depending on the InfoSphere CDC product you have installed, you can send
this notification through e-mail message queues, or a user exit program.
Related concepts
Setting latency thresholds and notifications on page 346

Setting notifications 347

348 InfoSphere Change Data Capture Management Console: Administration Guide
Promoting subscription changes
Promotion is the process in Management Console by which you can develop,
modify, and move configuration details in subscriptions from your development
environment to your test environment then to your production environment. If
your organization has implemented a succession of development stages, then you
may want to test your subscriptions before making them available in your
production environment. The Promote Subscription wizard promotes the
configuration details you set for your table mapping in the Mapping Details area
of Management Console to the new environment. When you are finished
promoting your changes, the subscription is relocated into the new environment
and uses new source and target datastores. The Promote Table Mappings wizard
allows you to promote selected table mappings in a subscription rather than all
table mappings.

In this section, you will learn:

Before you promote a subscription or selected table mappings
Promoting subscriptions on page 350
Promoting selected table mappings on page 353

Before you promote a subscription or selected table mappings

You should consider the following points before promoting a subscription or
selected table mappings:
v End replicationEnsure that you have ended replication on the subscription.
v Ensure that tables are present on the schema being promotedFor
Management Console to successfully promote subscriptions, check that the
database tables for the schemas selected for promotion are valid. Otherwise,
promotion will fail.
v Organize subscriptions into projectsOrganize the subscription that you want
to promote into a project. The purpose of promoting subscriptions is to relocate
your subscription from one environment to another. Placing subscriptions into
projects are a useful organizational tool to distinguish between an existing and
newly promoted subscription.
v Review mapping details for the subscriptionEnsure that you have reviewed
mapping details you set for the subscription. These mapping details are
promoted to the new environment. Management Console promotes the
properties of your subscription, including the source database information,
source table selections, table mappings, the replication method, source and target
column mappings, any notifications you set for the subscription, data
translations, and any expressions into the new environment.
v Identify database name and ownerIdentify the database name and owner of
the new source database. If you have built an expression on the source such as
%GETCOL, then this kind of expression will reference the names of columns
from other tables. Before you promote these expressions to the new
environment, you should know the name and owner of the new source database
that contain the table referenced in the expression.
For example, you may have built a derived column on the source that references
values from another table located in another database:
%GETCOL(JobTitle, "Northwind.dbo.CustomerData", "Sales Manager")

Copyright IBM Corp. 2008, 2011 349

 When promoting expressions to a new environment, the table called
CustomerData might exist in another database other than Northwind. If so, then
you need to specify the name of the new source database that contains this table
in the Promote Subscription wizard.
v Identify the full path name or program name of user exits called by an
expressionIf you have an expression that calls a stored procedure on the
source using the %USER column function, you need to make sure that stored
procedure exists in the new source database and specify the location of the
stored procedure (for example, the DLL path) in the Promote Subscription
wizard.
Also, if you have an expression that calls a stored procedure on the target using
the %STPROC function, you need to make sure that stored procedure exists in
the new target database. You should also know the location (full path) for the
stored procedure.
v Refreshing only a subset of rowsIf SQL Where clauses have been specified to
define a subset of rows within a refresh configuration for a table mapping, they
will not be promoted to the new table mapping.
Related concepts
Promoting subscription changes on page 349
Related tasks
To end replication on page 333

Promoting subscriptions
Use the Promote Subscription wizard to promote your subscription to a new
environment. For example, you can promote your subscription from a
development environment and into a production environment when you are ready
to use that subscription in replication activities.

Using the Promote Subscription wizard, you can:

v Promote to a new subscriptionIn this scenario, you are promoting a
subscription to a new environment. For example, you may have projects that are
exclusive for development or testing purposes. You can promote subscriptions
into one of these environments.
v Promote changes to an existing subscriptionIn this scenario, you have made
changes to a subscription that has already been promoted to another
environment. For example, the subscription may already exist in a project that
you have reserved for testing subscriptions, but you may have made some
minor changes on the subscription. To make sure the subscription in the test
environment includes the changes that you made, you need to promote your
changes to the testing environment.

Note: When promoting changes to an existing subscription, InfoSphere CDC

maintains synchronization between your source and target tables and you do not
need to set the log position in the new environment. However, if you are
making changes that causes you to lose synchronization between your source
and target tables (such as updating the definition of a source table), then
InfoSphere CDC does not maintain the log position and you will have to
resynchronize your source and target tables in the original and in the new
environment. For more information on how to synchronize source and target
tables in a table mapping, see Flagging a source table for refresh on page 317.

See also:

350 InfoSphere Change Data Capture Management Console: Administration Guide

 To promote a subscription to a new subscription
To promote changes to an existing subscription on page 352

To promote a subscription to a new subscription

1. Click Configuration > Subscriptions.
2. Right-click on a subscription and select Promote Subscription.
3. Select Promote to a new subscription.
4. Type the name of the new subscription in the Name box.
All subscriptions that come from the same source datastore must have a
unique name and all subscriptions that go to the same target datastore must
have a unique Source ID. The source ID is automatically generated based on
truncating the subscription name to 8 characters. If you attempt to create a
subscription with a duplicate Source ID, an error will result and the
subscription will not be created. If this occurs, click Advanced Settings and
give the subscription a unique Source ID.
5. Type the description of the new subscription in the Description box.
6. If you want to include the new subscription in a project, select a project from
the Project list or click New Project to create a new project.
If you do not select a project, Management Console places the new
subscription into the Default Project.
7. Click Next.
8. Select the name of the new source datastore from the New Source Datastore
list.
9. Select the name of the database and owner from the New Name list.
If you have built a derived column on the source that references another table
in another database using the %GETCOL column function, specify the name of
the database and owner that contains the table that is referenced in the
%GETCOL function. Also, make sure that the table referenced in the derived
column exists in the new source database.
10. If you want to specify advanced settings for the subscription, click Advanced
Settings. Modify the following properties and click OK, then click Next.
v Source IDSpecify the source ID for the new subscription.
v Firewall PortSpecify a port number for the new subscription.
v TCP HostSpecify the TCP host that your source datastore will use to
recognize the target datastore when the computer where InfoSphere CDC is
installed has multiple network cards. This is useful if you want to specify a
host that is different from the host that you specified in the Access Manager
perspective. The default option is Auto-select, which will automatically
select the network card that can communicate with the target datastore. The
host that you specified in theAccess Manager perspective also appears by
default as well as any alias that you configured in the Datastore Properties
dialog box.
v Propagation ControlClick Add and select the source ID for any
subscription for which you want to prevent data from being replicated to
the target.
v Do not replicate data received from any subscriptionsEnable if you want
to prevent replication from all subscriptions.
v Select the datastore to handle the transferable workSpecify where
transferable work will be performed, in order to minimize impact on the
source or target datastore.

Promoting subscription changes 351

 v Mark subscription as persistentEnable if you want to specify that the
subscription is persistent. A subscription can only be restarted automatically
if it is enabled for persistency.
11. Select the name of the new target datastore from the New Target Datastore
list.
12. If you have added an alias for the target datastore that the source system can
recognize, then click Advanced Settings and choose a valid alias and click
OK.
13. Select the name of the database and owner from the New Name list and click
Next.
14. If you have configured expressions with column functions that call user exit
programs, such as %USER or %STPROC, then specify the full path that contains
the stored procedure, or the name of the user exit program referenced in the
expression, then click Next.
Make sure that the stored procedure or user exit program already exists in the
new source database.
15. If you have built a derived column, an expression, or a row-filtering
expression that uses the %SELECT column function, then confirm the list of
displayed expressions and click Next.
After the promotion, make sure that the table or column referenced in the
%SELECT expression exists in the new database.
16. Click View XML to confirm the location and attributes of the promoted
subscription.
17. Review the list of changes and click Finish.
Related concepts
Before you promote a subscription or selected table mappings on page 349
Promoting subscriptions on page 350

To promote changes to an existing subscription

1. Click Configuration > Subscriptions.
2. Right-click on a subscription and select Promote Subscription.
3. Select Promote changes to an existing subscription.
4. Select the subscription to which you want to promote changes from the
Promote To list.
5. In the Table Mappings area you can select one of the following two options
and click Next:
v Replace all table mappings in the existing subscriptionIndicates the
table mappings in the subscription you are promoting will replace all
existing table mappings in the existing subscription you are promoting to.
For example, you plan on promoting table mappings from subscription
Develop to subscription Test. Subscription Develop contains four table
mappings: A, B, C, and D. A and B are selected for promotion to subscription
Test. Subscription Test contains three table mappings: A, B, and Z. By
selecting this option, table mappings A and B in subscription Develop will
replace all of the existing table mappings in subscription Test. After
promotion is complete, subscription Test will only contain table mappings A
and B. Table mapping Z will no longer exist in subscription Test.
v Only replace table mappings from the promoted subscriptionIndicates
the table mappings in the subscription you are promoting will only replace

352 InfoSphere Change Data Capture Management Console: Administration Guide

 table mappings with identical names in the existing subscription you are
promoting to. All other table mappings will remain in the subscription you
are promoting to.
For example, you plan on promoting table mappings from subscription
Develop to subscription Test. Subscription Develop contains four table
mappings: A, B, C, and D. A and B are selected for promotion to subscription
Test. Subscription Test contains three table mappings: A, B, and Z. By
selecting this option, table mappings A and B in subscription Develop will
only replace table mappings A and B in subscription Test. After promotion
is complete, subscription Test will still contain three table mappings: A, B
and Z.
6. Confirm the source datastore and the name of the database and owner from
which you want to promote the changes, then click Next.
If you have built a derived column on the source that references another table
in another database using the %GETCOL column function, specify the name of
the database and owner that contains the table that is referenced in the
%GETCOL function. Also, make sure that the table referenced in the derived
column exists in the new source database.
7. Confirm the target datastore and the name of the database and owner to
which you want to promote the changes.
8. If you have configured expressions with column functions that call user exit
programs, such as %USER or %STPROC, specify the full path that contains the
stored procedure, or the name of the user exit program referenced in the
expression, then click Next.
Make sure that the stored procedure or user exit program already exists in the
new source database.
9. If you have built a derived column, an expression, or a row-filtering
expression that uses the %SELECT column function, confirm the list of
displayed expressions and click Next.
After promotion, make sure that the table or column referenced in the %SELECT
expression exists in the new database.
10. Click View XML to confirm the location and attributes of the promoted
subscription.
11. Review the list of changes and click Finish.
Related concepts
Before you promote a subscription or selected table mappings on page 349
Promoting subscriptions on page 350

Promoting selected table mappings

Use the Promote Table Mappings wizard to promote your selected table mappings
to a subscription in a new environment. For example, you can promote your
subscription from a development environment and into a production environment
when you are ready to use that subscription in replication activities.

Using the Promote Table Mappings wizard, you can:

v Promote a Subscription to a New EnvironmentIn this scenario, you are
promoting selected table mappings to a subscription in a new environment. For
example, you may have projects that are exclusive for development or testing
purposes. You can promote subscriptions into one of these environments.
v Promote Changes to an Existing SubscriptionIn this scenario, you have
made changes to table mappings in a subscription that has already been

Promoting subscription changes 353

 promoted to another environment. For example, the subscription may already
exist in a project that you have reserved for testing subscriptions, but you may
have made some minor changes to the table mappings for the subscription. To
make sure the subscription in the test environment includes the changes that
you made, you need to promote your changes to the testing environment.

Note: When promoting changes to an existing subscription, InfoSphere CDC

maintains synchronization between your source and target tables and you do not
need to set the log position in the new environment. However, if you are
making changes that causes you to lose synchronization between your source
and target tables (such as updating the definition of a source table), then
InfoSphere CDC does not maintain the log position and you will have to
resynchronize your source and target tables in the original and in the new
environment. For more information on how to synchronize source and target
tables in a table mapping, see Flagging a source table for refresh on page 317.

Be aware that if SQL Where clauses have been specified to define a subset of rows
within a refresh configuration for a table mapping, they will not be promoted to
the new table mapping.

See also:
To promote selected table mappings to a new environment
To promote selected table mappings to an existing subscription on page 356
Related concepts
Before you promote a subscription or selected table mappings on page 349

To promote selected table mappings to a new environment

1. Click Configuration > Subscriptions.
2. Select the subscription with the table mappings you want to promote.
3. In the Table Mapping view, right-click one or more table mappings and select
Promote Table Mappings.
4. Select Promote to a new subscription.
5. Type the name of the new subscription in the Name box.
All subscriptions that come from the same source datastore must have a
unique name and all subscriptions that go to the same target datastore must
have a unique Source ID. The source ID is automatically generated based on
truncating the subscription name to 8 characters. If you attempt to create a
subscription with a duplicate Source ID, an error will result and the
subscription will not be created. If this occurs, click Advanced Settings and
give the subscription a unique Source ID.
6. Type the description of the new subscription in the Description box.
7. If you want to include the new subscription in a project, select a project from
the Project list or click New Project to create a new project.
If you do not select a project, Management Console places the new
subscription into the Default Project.
8. Click Next.
9. Select the name of the new source datastore from the New Source Datastore
list.
10. Select the name of the database and owner from the New Name list.
If you have built a derived column on the source that references another table
in another database using the %GETCOL column function, specify the name of

354 InfoSphere Change Data Capture Management Console: Administration Guide

 the database and owner that contains the table that is referenced in the
%GETCOL function. Also, make sure that the table referenced in the derived
column exists in the new source database.
11. If you want to specify advanced settings for the subscription, click Advanced
Settings. Modify the following properties and click OK, then click Next.
v Source IDSpecify the source ID for the new subscription.
v Firewall PortSpecify a port number for the new subscription.
v TCP HostSpecify the TCP host that your source datastore will use to
recognize the target datastore when the computer where InfoSphere CDC is
installed has multiple network cards. This is useful if you want to specify a
host that is different from the host that you specified in the Access Manager
perspective. The default option is Auto-select, which will automatically
select the network card that can communicate with the target datastore. The
host that you specified in theAccess Manager perspective also appears by
default as well as any alias that you configured in the Datastore Properties
dialog box.
v Propagation ControlClick Add and select the source ID for any
subscription for which you want to prevent data from being replicated to
the target.
v Do not replicate data received from any subscriptionsEnable if you want
to prevent replication from all subscriptions.
v Select the datastore to handle the transferable workSpecify where
transferable work will be performed, in order to minimize impact on the
source or target datastore.
v Mark subscription as persistentEnable if you want to specify that the
subscription is persistent. A subscription can only be restarted automatically
if it is enabled for persistency.
12. Select the name of the new target datastore from the New Target Datastore
list.
13. If you have added an alias for the target datastore that the source system can
recognize, then click Advanced Settings and choose a valid alias and click
OK.
14. Select the name of the database and owner from the New Name list and click
Next.
15. If you have configured expressions with column functions that call user exit
programs, such as %USER or %STPROC, then specify the full path that contains
the stored procedure, or the name of the user exit program referenced in the
expression, then click Next.
Make sure that the stored procedure or user exit program already exists in the
new source database.
16. If you have built a derived column, an expression, or a row-filtering
expression that uses the %SELECT column function, then confirm the list of
displayed expressions and click Next.
After the promotion, make sure that the table or column referenced in the
%SELECT expression exists in the new database.
17. Click View XML to confirm the location and attributes of the promoted
subscription.
18. Review the list of changes and click Finish.

Promoting subscription changes 355

 Related concepts
Before you promote a subscription or selected table mappings on page 349

To promote selected table mappings to an existing

subscription
1. Click Configuration > Subscriptions.
2. Select the subscription with the table mappings you want to promote.
3. In the Table Mapping view, right-click one or more table mappings and select
Promote Table Mappings.
4. Select Promote changes to an existing subscription.
5. Select the subscription to which you want to promote changes from the
Promote To list.
6. In the Table Mappings area you can select one of the following two options
and click Next:
v Replace all table mappings in the existing subscriptionIndicates that the
selected table mappings that you are promoting will replace all existing
table mappings in the existing subscription you are promoting to.
For example, you plan on promoting table mappings from subscription
Develop to subscription Test. Subscription Develop contains four table
mappings: A, B, C, and D. A and B are selected for promotion to subscription
Test. Subscription Test contains three table mappings: A, B, and Z. By
selecting this option, table mappings A and B in subscription Develop will
replace all of the existing table mappings in subscription Test. After
promotion is complete, subscription Test will only contain table mappings A
and B. Table mapping Z will no longer exist in subscription Test.
v Only replace the selected table mappingsIndicates that only the selected
table mappings in the subscription being promoted will replace table
mappings (with identical names) in the existing subscription you are
promoting to. All other table mappings will remain in the subscription you
are promoting to.
For example, you plan on promoting table mappings from subscription
Develop to subscription Test. Subscription Develop contains four table
mappings: A, B, C, and D. A and B are selected for promotion to subscription
Test. Subscription Test contains three table mappings: A, B, and Z. By
selecting this option, table mappings A and B in subscription Develop will
only replace table mappings A and B in subscription Test. After promotion
is complete, subscription Test will still contain three table mappings: A, B
and Z.
7. Confirm the source datastore and the name of the database and owner from
which you want to promote the changes, then click Next.
If you have built a derived column on the source that references another table
in another database using the %GETCOL column function, specify the name of
the database and owner that contains the table that is referenced in the
%GETCOL function. Also, make sure that the table referenced in the derived
column exists in the new source database.
8. Confirm the target datastore and the name of the database and owner to
which you want to promote the changes.
9. If you have configured expressions with column functions that call user exit
programs, such as %USER or %STPROC, specify the full path that contains the
stored procedure, or the name of the user exit program referenced in the
expression, then click Next.

356 InfoSphere Change Data Capture Management Console: Administration Guide

 Make sure that the stored procedure or user exit program already exists in the
new source database.
10. If you have built a derived column, an expression, or a row-filtering
expression that uses the %SELECT column function, confirm the list of
displayed expressions and click Next.
After promotion, make sure that the table or column referenced in the %SELECT
expression exists in the new database.
11. Click View XML to confirm the location and attributes of the promoted
subscription.
12. Review the list of changes and click Finish.
Related concepts
Before you promote a subscription or selected table mappings on page 349

Promoting subscription changes 357

358 InfoSphere Change Data Capture Management Console: Administration Guide
Monitoring subscriptions
After configuring your replication environment and starting replication for your
subscriptions, you can monitor and analyze replication activities for each
subscription in the Monitoring perspective.

The Monitoring perspective lets you diagnose potential problems by allowing you
to perform the following actions:
v Examine the amount of latency for a subscription. You can set latency thresholds
and notifications for your subscriptions to help you determine when latency is
becoming a problem.
v View replication activity for a subscription
v Check system messages and events that relate to a subscription or a datastore in
the Event Log or Current Replication Events area. You can view messages for
each subscription and datastore in your replication configuration.
v Analyze replication performance

In this section, you will learn:

Subscriptions view (Monitoring perspective)
Understanding subscription states on page 360
Displaying the replication diagram on page 361
Viewing latency for a subscription on page 362
Viewing replication activity on page 363
Viewing replication events on page 364
Performance view (Monitoring perspective) on page 369
Available metrics on page 370
Analyzing subscription performance on page 380
Related concepts
Setting notifications on page 337
Disk resource system parameters on page 462

Subscriptions view (Monitoring perspective)

The Subscription view of the Monitoring perspective allows you to monitor and
analyze replication activities for each subscription so that you can diagnose
potential problems. In addition, this view contains operational features for
subscriptions that allow you to connect to datastores, start replication and end
replication.

In this view, you can perform the following actions:

v Connect to a datastore
v View the subscription summary
v View the replication diagram
v Monitor the state of your subscription
v Start or end replication on a subscription
v Refresh a subscription
v View a summary of latency, replication activity and events

Copyright IBM Corp. 2008, 2011 359

 The area at the top left of the view has two modes: subscription summary and
replication diagram.

The subscription summary mode displays a summary of replication states and

latency on the left, and a list of subscriptions on the right.

The Replication area of the summary breaks down replication into five states and
shows a count of how many subscriptions fall within each state:
v MirroringIncludes subscriptions that have a state of Mirroring Continuous
and Mirroring Scheduled End
v RefreshIncludes subscriptions that have a state of Refreshing
v FailedIncludes subscriptions that have a state of Failed.
v InactiveIncludes subscriptions that have a state of Inactive or Unknown
v OtherIncludes all other kinds of states, such as Starting, Ending, Locked.

The Replication area can also be used as a filter; clicking a state changes the list to
include only subscriptions in that state. The Clear Filter link returns the list to its
default display.

The Latency area of the summary breaks down latency levels into three states:
Problem, Warning and Normal. A count is shown indicating how many
subscriptions fall within each state. You need to have set latency threshold values
for your subscriptions in order for values to be displayed in this area, otherwise
the subscriptions will fall into the normal category.

The replication diagram mode displays a schematic diagram to visually

represent the datastores and the mapping relationships between them in your
replication configuration.

The bottom section of the window displays a summary of latency, replication

activity and events.
Related concepts
Starting mirroring on page 328
Starting a refresh on a subscription on page 330
Ending replication on page 332
Displaying the replication diagram on page 361
Setting latency thresholds and notifications on page 346
Viewing replication activity on page 363
Viewing latency for a subscription on page 362
Viewing replication events on page 364
Monitoring subscriptions on page 359
Starting and ending replication on page 327
Connecting to a datastore on page 70

Understanding subscription states

Subscriptions configured in Management Console can be in one of the following
states:
v EndingIndicates that InfoSphere CDC is close to completing replication
activity on the subscription and is in the process of shutting down.

360 InfoSphere Change Data Capture Management Console: Administration Guide

 v FailedIndicates that the subscription stopped replication after encountering an
error.
v InactiveIndicates that InfoSphere CDC is not replicating data on the
subscription.
v LockedIndicates that the subscription has been locked by a user. A locked
subscription is read-only to all other users.
v Mirror ContinuousIndicates that InfoSphere CDC is mirroring data between
the source and target. This occurs when you have started continuous mirroring
on the subscription.
v Mirror Net ChangeIndicates that InfoSphere CDC is mirroring changes that
were made to the source since replication last ended. InfoSphere CDC ends
replication after the changes are mirrored to the target.
v Refresh Before MirroringIndicates that InfoSphere CDC will refresh the data
before mirroring will begin.
v RefreshingIndicates that InfoSphere CDC is refreshing data from the source to
the target. After completing the refresh, InfoSphere CDC starts mirroring the
subscription or returns to a state of Inactive, depending on the replication
method that you have selected for the subscription.
v StartingIndicates that InfoSphere CDC is starting replication for the
subscription.
v UnknownIndicates that InfoSphere CDC cannot determine the state of the
subscription. This may be a result of a lack of communication between the
monitoring process and the datastores, or your subscription is using an external
source datastore.
v Waiting for DataStage to be startedIndicates that Management Console is
waiting for the InfoSphere DataStage job to begin before replication can start.

An icon is displayed beside the subscription name to visually indicate its state.
Related concepts
Viewing replication events on page 364
Locking subscriptions within a datastore on page 52

Displaying the replication diagram

The replication diagram in the Subscriptions view of the Monitoring perspective
uses a schematic diagram to visually represent the datastores and the mapping
relationships between them in your replication configuration.

Datastores are represented by graphic elements with connecting lines running

between those that share table mappings. Each connecting line that run between
datastore graphics has an arrowhead pointing to the target datastore.

A circular indicator at the midpoint of the connector indicates subscription state:

green for active, yellow for inactive or red for failed. Since a connector can
represent multiple subscriptions, the state that is displayed is that of the
subscription with the lowest state. For example, if 5 subscriptions are represented
by a connector, four of which are active and one is inactive, the circular indicator
will be yellow.

Choosing either one of these datastores or connections loads a list of associated

subscriptions and the projects they're organized in.

Monitoring subscriptions 361

Viewing latency for a subscription
InfoSphere CDC measures latency as the amount of time that passes between when
data changes on a source table and when it changes on the target table. For
example, if an application inserts a row into the source table at 10:00 and
InfoSphere CDC applies that row to the target table at 10:15, then the latency for
the subscription is 15 minutes. It is up to you to decide how much latency you are
willing to tolerate in your environment.

The Latency area of the Subscriptions view of the Monitoring perspective

displays a graphical summary of latency for the current subscription.

In order to view latency information, you need to ensure that Collect Statistics is
enabled for the subscription. Once enabled, an icon will be displayed in a
column on the right side of the subscription list.

You can drill down in this view to see a more detailed explanation of latency by
double-clicking on the area title.. A summary of latency values and a graph will be
displayed:
v CurrentIndicates the amount of time the subscription is latent in replicating
data to the target.
v HighIndicates the highest amount of time a subscription has experienced
latency since you started to collect statistics.
v LowIndicates the least amount of time a subscription has experienced latency
since you started to collect statistics.
v AverageIndicates the average amount of time a subscription has experienced
latency since you started to collect statistics.

You can export the latency information to a comma-delimited file by clicking

Export Statistics, located above the graph.

Latency considerations
v To receive accurate latency statistics for a subscription, ensure that your system
time (for each machine where you have installed InfoSphere CDC) is
synchronized and that the time zone matches the time zone of your region.
InfoSphere CDC calculates latency based on your system time and the offset
from Coordinated Universal Time (UTC).
v Depending on the platform on which you have InfoSphere CDC, you can set the
DEADBAND PERCENTAGE system parameter to greater than zero on your target
datastore if you want InfoSphere CDC to apply padding around your latency
threshold.

See also:
To view latency values for a subscription

To view latency values for a subscription

1. Click Monitoring > Subscriptions.
2. Select a subscription.
3. Ensure that Collect Statistics has been enabled for the subscription.
4. Double-click on Latency.

362 InfoSphere Change Data Capture Management Console: Administration Guide

Viewing replication activity
The Activity area of the Subscriptions view of the Monitoring perspective
displays a graphical summary of either mirroring or refresh activity. You can drill
down in this view to see a more detailed explanation of activity by double-clicking
on the area title.

In order to view replication activity, you need to ensure that the Collect Statistics
button is enabled for the subscription. Once enabled, an icon will be
displayed in a column on the right side of the subscription list.

Activity - Refresh

If your subscription is refreshing, a pie chart depicting the progress of the refresh
will be displayed, along with the following information:
v Tables completedDisplays a percentage value for the number of tables in the
subscription that have finished refreshing.
v Refresh startedDisplays the date and time that the refresh began.
v Refresh completedDisplays the date and time that the refresh ended.
v Table nameSpecifies the name of the target table currently being refreshed. This
information will only be displayed while the refresh is in progress.
v Rows readSpecifies the number of rows in the source table that have been
read. This information will only be displayed while the refresh is in progress.

Double-clicking Activity - Refresh will drill down into a more detailed view of the
replication activity.

The pie chart is displayed again, along with a list of the tables to be refreshed. For
each table, the following information is displayed:
v Source TableSpecifies the source table.
v Target TableSpecifies the target table being refreshed.
v DurationDisplays the amount of time the refresh has lasted.
v Records ReadDisplays the number of records that have been read on the
source table.
v Records AppliedDisplays the number of records in the table that have been
applied to the target table.
v StatusDisplays the current status of the table. The status will be Refreshing...
will the refresh of a table is still in progress or Completed when the refresh of
the table has completed.

Activity - Mirroring

If you subscription is mirroring, a graph showing the recent progress of replication

will be displayed, along with the total volume of bytes per second. Double-clicking
Activity - Mirroring will drill down into a more detailed view of the replication
activity. You can choose to view activities by either action or volume.

If you select Operations, a list of basic replication activities (inserts, updates, and
deletes) for the source and target datastores is displayed on the left.

If you select Bytes, a list of processed volume activities (measured in bytes) for the
source and target datastores is displayed on the left.

Monitoring subscriptions 363

 Each action is summarized for current activity, the highest level of activity and
cumulative activity for the replication session.

For the Operations tab, the Cumulative column displays a count of the activities
that occurred after statistics collection was enabled during the current replication
session (the current session being when mirroring or refresh was started, until
replication is ended). The next time that replication is started, the event count will
return to zero and begin again. The frequency at which Management Console
collects data for the cumulative count is based upon the value set in the Statistics
Sample rate (seconds) box on the Preferences dialog. The count will begin after
the first instance of the specified interval.

Up to five of these activities can be selected to plot the graph on the right. Each
activity will be assigned a different color on the graph.

You can export the statistics information to a comma-delimited file by clicking

Export Statistics, located above the graph.

See also:
To view replication activities for a subscription
Related concepts
Setting statistics preferences on page 21

To view replication activities for a subscription

1. Click Monitoring > Subscriptions.
2. Select a subscription.
3. Ensure that Collect Statistics has been enabled for the subscription.
4. Double-click on Activity, Activity - Mirroring or Activity - Refresh.

Viewing replication events

The Events area of the Subscriptions view of the Monitoring perspective lets you
view events and messages generated by InfoSphere CDC during replication
activities. It allows you to monitor activity and identify problems with the
replication activity of your subscriptions. The top level view provides a summary
regarding the number of events, broken down by type. You can drill down in this
view to see a list of events by double-clicking on the area title.

Events allow you to perform the following actions:

v View events generated by specific subscriptions or datastores
v Filter events based on severity
v Copy events. You can then paste the event into another application. For
example, you may want to copy an event into an e-mail for technical support
reasons.
v Export events to a comma-delimited file
v Clear event messages that you no longer need to investigate
v Search for specific events
v From the Events column, view the number of errors associated with your
subscriptions when you first load your subscription. The value from this column
acts as an indicator for you to address the errors as required. Once you have
addressed all the events, you can reset the Events column to repopulate with
new statistics.

364 InfoSphere Change Data Capture Management Console: Administration Guide

If the subscription you have selected belongs to a datastore of InfoSphere CDC
version 6.3 or earlier, the Events area will be titled Event Log Summary. In this
mode, the Events area will display the events that occurred during the life of the
subscription.

If the subscription you have selected belongs to a datastore of InfoSphere CDC

version 6.5, the Events area will be titled Current Replication Events. In this
mode, the Events area will display the events that occurred during the current
replication session; that is to say, from when mirroring or refresh was started, until
replication is ended. The next time that replication is started, the event count will
return to zero and begin again.

There are several categories of events, which are listed by increasing severity:
v InformationThese events provide feedback about InfoSphere CDC operations.
These events do not indicate that an error has occurred.
v DiagnosticThese events contain information that helps you diagnose or solve
a problem that may occur as a result of a certain action or operation. This
category of events is generated only by InfoSphere CDC for IBM i, InfoSphere
CDC for Oracle version 6.0 and earlier, InfoSphere CDC for Microsoft SQL
version 5.3.4 and earlier replication engines.
v NoticeThese events describe situations that InfoSphere CDC has detected,
which alerts you about a potential error. This category of events is generated
only by InfoSphere CDC for IBM i, InfoSphere CDC for Oracle version 6.0 and
earlier, InfoSphere CDC for Microsoft SQL version 5.3.4 and earlier replication
engines.
v WarningThese events describe situations that InfoSphere CDC has detected,
which alerts you about a potential error.
v ErrorThese events describe an error that InfoSphere CDC has detected, or
explain conditions that led to InfoSphere CDC shutting down.
v EscapeThese events describe an error that InfoSphere CDC has detected, or
explain conditions that led to InfoSphere CDC shutting down. This category of
events is generated only by InfoSphere CDC for IBM i, InfoSphere CDC for
Oracle version 6.0 and earlier, InfoSphere CDC for Microsoft SQL version 5.3.4
and earlier replication engines.

There are multiple ways to filter the display of events:

v CategoryClicking either Subscription, Single Scrape or Datastore will filter
the display to include only those events that apply to the selected category. The
Single Scrape option will only be available when it is an applicable filter.
v Source or TargetFilter the display to include only the events generated by the
source or target datastores.
v ErrorsFilter the display to show only errors by clicking the Errors link.
v WarningsFilter the display to show only warnings by clicking the Warnings
link.
v AllCancels the Errors and Warnings filters. The returns to the default value,
which is to display all events that apply to the Category, Source or Target filters
if applied.

See also:
To view events (InfoSphere CDC version 6.5 and later) on page 366
To retrieve events that occurred within a date range (InfoSphere CDC version
6.5 and later) on page 366

Monitoring subscriptions 365

 To view events (InfoSphere CDC version 6.3 and earlier) on page 367
To view event details on page 367
To copy events on page 368
To clear all events for the selected subscription on page 368
To clear selected events for the selected subscription on page 368
To export events on page 369

To view events (InfoSphere CDC version 6.5 and later)

1. Click Monitoring > Subscriptions.
2. Select a subscription.
Ensure that the subscription belongs to a datastore which is InfoSphere CDC
version 6.5.
3. Double-click Current Replication Events in the bottom section of the window.
The display changes to show a list of events.
4. Click Retrieve Events and choose the quantity of events to retrieve:
v Get More EventsRetrieves any events that have occurred subsequent to
your last retrieval. This option will be unavailable if a Custom query has
been used previously or if it's your first time retrieving events for this
subscription in this Management Console session.
v Last 24 HoursRetrieves events from the last 24 hours.
v Last 7 DaysRetrieves events from the last seven calendar days.
v Last 30 DaysRetrieves events from the last thirty calendar days.
v All EventsRetrieves all events. If the quantity of events is large, there may
be a delay while they are loaded.
v CustomAllows you to retrieve events based on a date range that you
determine or by specific categories of events.
5. If you want to filter the display by event source category, click one of the
following items:
v SubscriptionFilters the display to include only events that apply to the
subscription.
v Single ScrapeFilters the display to include only events that apply to Single
Scrape. This option will be unavailable if Single Scrape is not supported by
the replication engine.
v DatastoreFilters the display to include only events that apply to the
datastore.
v SourceFilters the display to include only events generated by the source
datastore.
v TargetFilters the display to include only events generated by target
datastore.
6. If you want to filter the display by type of event, click Errors or Warnings at
the bottom of the events list.

To retrieve events that occurred within a date range

(InfoSphere CDC version 6.5 and later)
1. Click Monitoring > Subscriptions.
2. Select a subscription.
Ensure that the subscription belongs to a datastore which is InfoSphere CDC
version 6.5.

366 InfoSphere Change Data Capture Management Console: Administration Guide

 3. Double-click Current Replication Events in the bottom section of the window.
The display changes to show a list of events.
4. Click Retrieve Events and select Custom.
The Retrieve Events dialog box opens.
5. Select the Retrieve events based on date range: option.
6. Select the starting date and time value for the range in the From: controls.
7. Select the ending date and time value for the range in the To: controls.
8. Select Source Events to retrieve events from the source datastore and choose
one of the following items from the list box:
v AllIncludes all source events that occurred during the specified date range.
v DatastoreIncludes all source events applicable to the datastore that
occurred during the specified date range.
v SubscriptionIncludes all source events applicable to the subscription that
occurred during the specified date range.
v Single ScrapeIncludes all source events applicable to the Single Scrape
component that occurred during the specified date range.
9. Select Target Events to retrieve events from the target datastore and choose one
of the following items from the list box:
v AllIncludes all target events that occurred during the specified date range.
v DatastoreIncludes all target events applicable to the datastore that
occurred during the specified date range.
v SubscriptionIncludes all target events applicable to the subscription that
occurred during the specified date range.
v Single ScrapeIncludes all target events applicable to the Single Scrape
component that occurred during the specified date range.

To view events (InfoSphere CDC version 6.3 and earlier)

1. Click Monitoring > Subscriptions.
2. Select a subscription.
Ensure that the subscription belongs to a datastore which is InfoSphere CDC
version 6.3 and earlier.
3. Double-click Event Log Summary in the bottom section of the window.
The display changes to show a list of events.
4. Click Retrieve Events.
5. If you want to filter the display of events by type, click Errors or Warnings at
the bottom of the events list.
Related concepts
Viewing replication events on page 364

To view event details

1. Click Monitoring > Subscriptions.
2. Select a subscription.
3. Double-click on Current Replication Events or Event Log Summary, as
applicable.
The display changes to show a list of events.
4. Select an event.
5. Right-click and select Event Details.

Monitoring subscriptions 367

 The Event Details dialog opens.
6. If you want to view details for sequential events, click Next or Previous
Related concepts
Viewing replication events on page 364

To copy events
1. Click Monitoring > Subscriptions.
2. Select a subscription.
3. Double-click on Current Replication Events or Event Log Summary, as
applicable.
4. Select an event or hold Ctrl and select multiple events.
5. Right-click and select Copy Selected Events.
6. Paste the events in the desired application.
Related concepts
Viewing replication events on page 364

To clear all events for the selected subscription

1. Click Monitoring > Subscriptions.
2. Select a subscription.
3. Double-click on Current Replication Events or Event Log Summary, as
applicable.
4. Right-click in the list of events and select Clear Events > Clear All Events.
Related concepts
Viewing replication events on page 364

To clear selected events for the selected subscription

1. Click Monitoring > Subscriptions.
2. Select a subscription.
3. Double-click on Current Replication Events or Event Log Summary, as
applicable.
4. Right-click in the list of events and select Clear Events > Custom.
The Clear Events dialog opens.
5. Select one of the following options to determine the time period for events to
be cleared:
v Clear all events beforeIncludes the events that occurred before the date
and time you set.
v Clear eventsIncludes all events listed.
6. If you want to clear events from the source datastore, select the Source Events
check box and select one of the following items from the list box:
v AllClears all events generated by the source datastore.
v DatastoreClears all events generated by the source datastore applying to
the source datastore.
v SubscriptionClears all events generated by the source datastore applying
to subscriptions.
v Single ScrapeClears all events generated by the source datastore applying
to Single Scrape.

368 InfoSphere Change Data Capture Management Console: Administration Guide

 7. If you want to clear events from the target datastore, select the Target Events
check box and select one of the following items from the list box:
v AllClears all events generated by the target datastore.
v DatastoreClears all events generated by the target datastore applying to
the target datastore.
v SubscriptionClears all events generated by the target datastore applying to
subscriptions.
v Single ScrapeClears all events generated by the target datastore applying
to Single Scrape.

To export events
1. Click Monitoring > Subscriptions.
2. Select a subscription.
3. Double-click on Current Replication Events or Event Log Summary, as
applicable.
4. Right-click in the list of events and select Export Events.
5. If you want to export events from the source datastore, select the Source
Events check box and select one of the following items from the list box:
v AllClears all events generated by the source datastore.
v DatastoreClears all events generated by the source datastore applying to
the source datastore.
v SubscriptionClears all events generated by the source datastore applying
to subscriptions.
v Single ScrapeClears all events generated by the source datastore applying
to Single Scrape.
6. If you want to export events from the target datastore, select the Target Events
check box and select one of the following items from the list box:
v AllClears all events generated by the target datastore.
v DatastoreClears all events generated by the target datastore applying to
the target datastore.
v SubscriptionClears all events generated by the target datastore applying to
subscriptions.
v Single ScrapeClears all events generated by the target datastore applying
to Single Scrape.
7. You are prompted to save the list of events in a formatted text file to your local
computer.
Related concepts
Viewing replication events on page 364

Performance view (Monitoring perspective)

Note: The Performance view of the Monitoring perspective is only available for
InfoSphere CDC version 6.5 subscriptions.

The Performance view allows you to diagnose the performance of a subscription

or tables within a subscription by selecting metrics by which to gauge
performance.

Note: Be aware that the collection of table-level statistics may stress resources and
affect performance.

Monitoring subscriptions 369

 The Performance view consists of four areas. The selected subscription (and any
selected tables) is displayed in the top left area of the view. Below it is a list of
available metrics. This list will vary depending on the subscription selected. Once
metrics have been selected (a maximum of ten are allowed), the graphical display
on the right is populated, with a statistics count area at the bottom.

The graphical display area contains three zones:

v BottlenecksDisplays a bar chart featuring the five components of the pipeline:
Log Reader, Source Engine, Communication, Target Engine, Target Database. The
results of the bar chart will help you isolate which components are causing
bottlenecks.
v LatencyDisplays a graphical summary of latency for the selected subscription.
v StatisticsDisplays a graph of the performance of the selected metrics.

Available metrics
The following is a list of the metrics available for analyzing subscription
performance.

See also:
Datastore metrics
Single Scrape metrics on page 372
Log reader metrics on page 373
Log parser metrics on page 374
Source transformation engine metrics on page 376
Target transformation engine metrics on page 377
Target database metrics on page 378

Datastore metrics
These metrics allows you to analyze replication activities specific to the source
datastore.

See also:
Time check missed count - seconds
Free memory - bytes on page 371
Maximum memory - bytes on page 371
Total memory - bytes on page 371
Garbage collections - count on page 371
Garbage collection CPU time - milliseconds on page 372
Global memory manager - bytes used for replication on page 372

Time check missed count - seconds

UnitsCumulative seconds

DescriptionTracks how often and by how much InfoSphere CDC missed its
periodic time check. InfoSphere CDC will record the number of seconds missed,
cumulatively.

BenefitUse this statistic to discover either CPU starvation or excessive garbage

collection, meaning that InfoSphere CDC is using a lot of small blocks of memory.

370 InfoSphere Change Data Capture Management Console: Administration Guide

Free memory - bytes
UnitsBytes

DescriptionTracks the amount of free memory as a subset of the maximum

memory that is available.

BenefitUse this statistic in conjunction with the Total memory and Maximum
memory statistics to better understand memory utilization. A low value for this
statistic would indicate a memory starvation issue and could be addressed by
allocating more memory to the engine.
Related reference
Total memory - bytes
Maximum memory - bytes

Maximum memory - bytes

UnitsBytes

DescriptionTracks the user configured memory for the InfoSphere CDC Java
Virtual Machine (JVM).

BenefitUse this statistic in conjunction with the Free memory and Total memory
statistics to better understand memory utilization.
Related reference
Free memory - bytes
Total memory - bytes

Total memory - bytes

UnitsBytes

DescriptionTracks the total amount of memory currently allocated by the

InfoSphere CDC Java Virtual Machine (JVM).

BenefitUse this statistic in conjunction with the Free memory and Maximum
memory statistics to better understand memory utilization. This value should be
less than or equal to Maximum memory.
Related reference
Free memory - bytes
Maximum memory - bytes

Garbage collections - count

UnitsCumulative count

DescriptionTracks the cumulative count since the start of collection.

BenefitUse this statistic to understand garbage collection activity. A large

number indicates that time spent freeing memory is having an impact on
performance.

Monitoring subscriptions 371

 Garbage collection CPU time - milliseconds
UnitsMilliseconds

DescriptionTracks the time since the start of collection.

BenefitCould indicate too much memory was being allocated by having very
large garbage collection blocks occurring

Global memory manager - bytes used for replication

UnitsBytes

DescriptionTracks the amount of physical memory used.

BenefitUse this statistic to determine if the InfoSphere CDC memory

configuration is correct or if adjustments are required.

Single Scrape metrics

These metrics allows you to analyze replication activities specific to the Single
Scrape component on the source replication engine.

See also:
Disk size - bytes
Disk writes - bytes
Disk reads - bytes

Disk size - bytes

UnitsBytes

DescriptionTracks the current staging store size on disk.

BenefitUse this statistic to understand staging store sizing. A large size on disk
could indicate large latency for one or more subscriptions or a stopped
subscription.

Disk writes - bytes

UnitsBytes

DescriptionTracks the physical bytes written to disk

BenefitUse this statistic to understand disk I/O activity. A large number

indicates performance impact from disk I/O activity; increasing the memory
allocated to Single Scrape may be required.

Disk reads - bytes

UnitsCumulative bytes

DescriptionTracks the physical bytes read from disk.

BenefitUse this statistic to understand disk I/O activity. A large number

indicates performance impact from disk I/O activity; increasing the memory
allocated to Single Scrape may be required.

372 InfoSphere Change Data Capture Management Console: Administration Guide

Log reader metrics
These metrics allows you to analyze replication activities specific to the log reader
for the source replication engine.

See also:
Physical bytes read - bytes
Log position timestamp
Committed transactions - count
CPU time - seconds

Physical bytes read - bytes

UnitsBytes

DescriptionTracks the physical bytes read by the log reader. This includes any
extra I/O that is done by replication engines to read logs. For API-based log
readers, this value will be 0.

BenefitUse this statistic to understand log reader activity. A large number would
indicate a lot of log data being processed. If this number is high and the amount of
data replicated is low, it means that InfoSphere CDC is filtering out most
information from the log. If the number is low, there is not a lot going on in the
database.

Log position timestamp

UnitsCumulative seconds

DescriptionTracks the replication speed relative to the database.

BenefitUse this statistic to understand the progress InfoSphere CDC is making

relative to the database speed, as measured by the log positions being read. This
value may not be accurate if timestamps are not regularly encountered in the log
file.

Committed transactions - count

UnitsCumulative count

DescriptionTracks the total number of committed transactions.

BenefitUse this statistic to understand transaction processing. The number of

transactions processed is a workload indicator.

CPU time - seconds

UnitsCumulative seconds

DescriptionTotal CPU used by all threads.

BenefitUse this statistic to understand CPU usage. A high value could indicate a
lot of out-of-scope data.

Monitoring subscriptions 373

 Log parser metrics
These metrics allows you to analyze replication activities specific to the log parser
on the source replication engine.

See also:
Disk size - bytes
Disk writes - bytes
Disk reads - bytes
In scope transactions - count
New tables - count on page 375
CPU time - seconds on page 375
Transaction histogram (0 to 1/2 X) - bytes on page 375
Transaction histogram (1/2X to X) - bytes on page 375
Transaction histogram (X to 2X) - bytes on page 375
Transaction histogram (2X to 4X) - bytes on page 376
Transaction histogram (4X to 8X) - bytes on page 376
Transaction histogram (8X and larger) - bytes on page 376

Disk size - bytes

UnitsBytes

DescriptionTracks the current staging store size on disk.

BenefitUse this statistic to understand staging store sizing. A large size on disk
could indicate large transactions being processed or many concurrent open
transactions.

Disk writes - bytes

UnitsBytes

DescriptionTracks the physical bytes written to disk

BenefitUse this statistic to understand disk I/O activity. A large number

indicates performance impact from disk I/O activity; increasing the memory
allocated to Single Scrape may be required.

Disk reads - bytes

UnitsCumulative bytes

DescriptionTracks the physical bytes read from disk.

BenefitUse this statistic to understand disk I/O activity. A large number

indicates performance impact from disk I/O activity; increasing the memory
allocated for the global memory manager may be required.

In scope transactions - count

UnitsCumulative count

DescriptionTracks the number of in scope transactions.

374 InfoSphere Change Data Capture Management Console: Administration Guide

BenefitUse this statistic to understand how many transactions are in scope
relative to all the transactions in the log. This value is a workload indicator and
should be used in conjunction with the Total Transactions statistic.

New tables - count

UnitsCumulative count since the start of the subscription

DescriptionProvides a count of new tables seen by the log parser.

BenefitUse this statistic to understand log parser activity. Each time a new table
is encountered by InfoSphere CDC, the source database must be queried for the
table's structure. Seeing a high value for this statistic could indicate a loss of
performance due to source database queries to retrieve table information,
explaining why latency would increase for a period of time.

CPU time - seconds

UnitsSeconds

DescriptionTracks CPU seconds since replication started.

BenefitUse this statistic to understand CPU usage. If this value is high the CPU
could be the constraint for parsing of the log. Splitting the subscription might
resolve this issue.

Transaction histogram (0 to 1/2 X) - bytes

UnitsCumulative count

DescriptionTracks the cumulative count of transactions of a given size. X is the

size of the transaction that always gets stored in memory.

BenefitUse this statistic to understand memory usage. This statistic is a

workload indicator and could indicate that memory settings need to be turned.

Transaction histogram (1/2X to X) - bytes

UnitsCumulative counts of transactions of a given size.

DescriptionTracks the cumulative count of transactions of a given size. X is the

size of the transaction that always gets stored in memory.

BenefitUse this statistic to understand memory usage. This statistic is a

workload indicator and could indicate that memory settings need to be turned.

Transaction histogram (X to 2X) - bytes

UnitsCumulative counts of transactions of a given size.

DescriptionTracks the cumulative count of transactions of a given size. X is the

size of the transaction that always gets stored in memory.

BenefitUse this statistic to understand memory usage. This statistic is a

workload indicator and could indicate that memory settings need to be turned.

Monitoring subscriptions 375

 Transaction histogram (2X to 4X) - bytes
UnitsCumulative counts of transactions of a given size.

DescriptionTracks the cumulative count of transactions of a given size. X is the

size of the transaction that always gets stored in memory.

BenefitUse this statistic to understand memory usage. This statistic is a

workload indicator and could indicate that memory settings need to be turned.

Transaction histogram (4X to 8X) - bytes

UnitsCumulative counts of transactions of a given size.

DescriptionTracks the cumulative count of transactions of a given size. X is the

size of the transaction that always gets stored in memory.

BenefitUse this statistic to understand memory usage. This statistic is a

workload indicator and could indicate that memory settings need to be turned.

Transaction histogram (8X and larger) - bytes

UnitsCumulative counts of transactions of a given size.

DescriptionTracks the cumulative count of transactions of a given size. X is the

size of the transaction that always gets stored in memory.

BenefitUse this statistic to understand memory usage. This statistic is a

workload indicator and could indicate that memory settings need to be turned.

Source transformation engine metrics

These metrics allows you to analyze replication activities specific to the source
transformation engine.

See also:
Rows evaluating Derived Expressions - count
Rows calling source db - count
Rows calling User Exits - count on page 377
CPU Used - seconds on page 377
MBCS conversions - bytes on page 377

Rows evaluating Derived Expressions - count

UnitsCumulative row count

DescriptionTracks the number of rows with at least one derived expression.

BenefitUse this statistic to understand activity on the source replication due to a

derived expression. A large number would indicate potential performance issues
due to the execution of a derived expression.

Rows calling source db - count

UnitsCumulative row count

376 InfoSphere Change Data Capture Management Console: Administration Guide

 DescriptionTracks the number of rows with at least one call out to the source
database.

BenefitUse this statistic to understand row activity. A large number would

indicate potential performance issues due to calls out to the source database.

Rows calling User Exits - count

UnitsCumulative row count

DescriptionTracks the number of rows with calls out to user functionality

BenefitUse this statistic to understand activity on the source replication due to

user exits. A large number would indicate potential performance issues due to calls
out to user functionality.

CPU Used - seconds

UnitsCumulative CPU seconds

DescriptionTracks the CPU time used by the source transformation engine.

BenefitUse this statistic to understand CPU usage. A value equal to the time
period would indicate a CPU bottleneck.

MBCS conversions - bytes

UnitsCumulative bytes

DescriptionTracks the count of input bytes converted by character conversion.

BenefitUse this statistic to understand activity on the source replication engine

due to MBCS conversions. A large number could cause performance issues due to
MBCS processing.

Target transformation engine metrics

These metrics allows you to analyze replication activities specific to the target
transformation engine.

See also:
CPU time - seconds
Rows evaluating Expressions - count on page 378
Rows calling target DB - count on page 378
Rows calling User Exits - count on page 378
MBCS conversions - bytes on page 378

CPU time - seconds

UnitsCumulative CPU seconds

DescriptionTracks the CPU time for Image Builders

BenefitUse this statistic to understand CPU usage. A large number would

indicate a potential CPU bottleneck on the target.

Monitoring subscriptions 377

 Rows evaluating Expressions - count
UnitsCumulative row count

DescriptionTracks the number of rows with at least one expression.

BenefitUse this statistic to understand activity due to a derived expression. A

large number would indicate potential performance issues due to expression
execution.

Rows calling target DB - count

UnitsCumulative row count

DescriptionTracks the number of rows with at least one call out to the target
database.

BenefitUse this statistic to understand row activity. A large number would

indicate potential performance issues due to calls out to the target database.

Rows calling User Exits - count

UnitsCumulative row count

DescriptionTracks the number rows with calls out to user functionality

BenefitUse this statistic to understand activity due to user exits. A large number
would indicate potential performance issues due to calls out to user functionality.

MBCS conversions - bytes

UnitsCumulative bytes

DescriptionTracks the count of input bytes converted by character conversion

BenefitUse this statistic to understand activity on the target replication engine

due to MBCS conversions. A large number could cause performance issues due to
MBCS processing.

Target database metrics

These metrics allows you to analyze replication activities specific to the target
database.

See also:
CPU used - seconds on page 379
CDR conflicts - count on page 379
Adaptive apply changes - count on page 379
Apply commits - counts on page 379
Average array size - count on page 379
SQL errors ignored - count on page 379
Slow DB operations - count on page 380

378 InfoSphere Change Data Capture Management Console: Administration Guide

CPU used - seconds
UnitsCumulative CPU seconds

DescriptionTracks the CPU time used by the target database.

BenefitUse this statistic to understand CPU usage. A value equal to the time
period would indicate a CPU bottleneck.

CDR conflicts - count

UnitsCumulative count

DescriptionTracks the number of conflicts detected in conflict detection and

resolution.

BenefitUse this statistic to understand conflict detection activity. A large number

of conflicts would impact performance due to the resolution of the conflict logic.

Adaptive apply changes - count

UnitsCumulative count

DescriptionTracks the number of adaptive changes during adaptive apply.

BenefitUse this statistic to understand adaptive change activity. A large number

of conflicts would impact performance due to the resolution of the conflict logic.

Apply commits - counts

UnitsCumulative count

DescriptionTracks the number of apply commits

BenefitUse this statistic to understand apply activity on the target database. A

large number of commits would indicate that transaction grouping has been
misconfigured.

Average array size - count

UnitsDiscrete value

DescriptionTracks the average size of arrays in the last period

BenefitUse this statistic to understand InfoSphere CDC optimizer activity. A

small number could indicate that the optimizer is not able to array operations to
improve performance.

SQL errors ignored - count

UnitsCumulative count

DescriptionTracks the number of SQL data errors that have been ignored.

Monitoring subscriptions 379

 BenefitUse this statistic to understand data error activity. This value indicates
the number of data errors that would stopped the target replication engine but
didn't due to either the mirror_end_on_error and refresh_end_on_error system
parameters being set to false.

Slow DB operations - count

UnitsCumulative count

DescriptionTracks the count of slow database operations.

BenefitUse this statistic to understand activity on the target database. A high

value for this statistic could indicate a performance problem with the target
database.

Analyzing subscription performance

Note: The ability to analyze subscription performance is only available for
InfoSphere CDC subscriptions at version 6.5 or later.

The Performance view of the Monitoring perspective allows you to view,

investigate and diagnose the performance of subscriptions or tables within them to
determine the causes of unexpected or unacceptable levels of latency.

Many factors can contribute to latency. Environmental variables, such as CPU

speed, memory allocation and network bandwidth, can affect replication
performance. InfoSphere CDC configuration settings may also be a cause.

The following list provides examples of common situations in which you may
experience latency:
v Insufficient network bandwidth for the volume of transactions that you are
processing is increasing the amount of time between changes on the source table
and the same change on the target table. To resolve this problem, contact your
network administrator.
v A large refresh is occurring.
v Resource intensive batch jobs or background tasks on either the source or target
can result in increased latency for subscriptions until these processes are
complete.
v InfoSphere CDC is replicating tables with Large Objects (LOB), increasing
latency due to large table row sizes.
v A database lock contention, in which a reporting system on the target database
may unexpectedly lock data in the database, may force InfoSphere CDC to wait
for the locks to be released.

To determine what is causing the latency to occur, use the Bottlenecks area of the
Performance view to identify where bottlenecks are occurring. This view displays
a bar chart featuring the five components of the pipeline:
v Log ReaderDisplays bottleneck levels for the log reader on the source
replication engine.
v Source EngineDisplays bottleneck levels for the log parser on the source
replication engine.
v CommunicationsDisplays bottleneck levels for communications for the source
replication engine.

380 InfoSphere Change Data Capture Management Console: Administration Guide

 v Target EngineDisplays bottleneck levels for the target replication engine.
v Target DatabaseDisplays bottleneck levels for the target database.

The results of the bar chart will help you isolate where bottlenecks are occurring.
Once you have identified the problem area, you can perform a more in-depth
analysis by charting metrics specific to that area.

You can analyze table-level performance, if you suspect that individual tables
within a subscription are causing latency issues. InfoSphere CDC provides a list of
the source tables in the subscription that are the most active. Before proceeding
with table-level analysis, you should be aware that the collection of table-level
statistics might require additional resources and can affect system performance.

Additionally, you can export the information collected in the Monitoring

perspective to a comma-delimited file for further analysis by clicking Export
Statistics, located above the graphical display.

See also:
To view bottlenecks for a subscription
To chart metrics for a subscription
To chart metrics for tables
To view the busiest tables in a subscription on page 382
To stop table-level performance monitoring on page 382

To view bottlenecks for a subscription

1. Click Monitoring > Subscriptions.
2. Select a subscription.
3. Right-click and select Show in Performance View.
The Performance view opens.
4. Click Collect Data.

To chart metrics for a subscription

1. Click Monitoring > Subscriptions.
2. Select a subscription.
3. Right-click and select Show in Performance View.
The Performance view opens.
4. Select the desired metrics.
You can select a maximum of ten metrics from any of the categories.
5. Click Collect Data.

To chart metrics for tables

1. Click Monitoring > Subscriptions.
2. Select a subscription.
3. Right-click and select Show in Performance View.
The Performance view opens.
4. Right-click on the subscription and select Select Tables....
The Select Tables dialog opens.
5. Select the tables to be monitored for performance.

Monitoring subscriptions 381

 6. Click OK.
7. Select the desired metrics.
You can select a maximum of ten metrics from any of the categories.
8. Click Collect Data.

To view the busiest tables in a subscription

1. Click Monitoring > Subscriptions.
2. Select a subscription.
3. Right-click and select Show in Performance View.
The Performance view opens.
4. Right-click on the subscription and select Busy Tables....

To stop table-level performance monitoring

1. Click Monitoring > Subscriptions.
2. Select a subscription.
3. Right-click and select Show in Performance View.
The Performance view opens.
4. Right-click on the subscription and select Select Tables....
The Select Tables dialog opens.
5. Deselect all items.

382 InfoSphere Change Data Capture Management Console: Administration Guide

System parameters for InfoSphere CDC for Microsoft SQL
Server (version 5.3 and earlier)
System parameters let you control the behavior of InfoSphere CDC. If your
replication environment requires a particular configuration, then you can use
system parameters to modify the behavior of default operations in InfoSphere
CDC. The default system parameter settings are appropriate for most installations.
Maintain these default settings until you become familiar with the configuration of
InfoSphere CDC.

InfoSphere CDC provides system parameters that control the behavior of your
source and target datastores.

Notes:
v If you make changes to a system parameter during active replication, you must
stop and restart replication for the changes to take effect.
v When upgrading to a later version of InfoSphere CDC, any preexisting settings
for system parameters are maintained.

In this section, you will learn:

General product system parameters
Replication system parameters on page 387
Database translation log system parameters on page 390
Commitment control system parameters on page 394
Event log system parameters on page 396
Multibyte character set system parameters on page 397
Latency system parameters on page 398
Notification system parameters on page 400
Tracing system parameters on page 403
Data type system parameters on page 406
Lock detection system parameters on page 407

General product system parameters

General product system parameters let you control basic features of InfoSphere
CDC and information you may have specified during installation.

See also:
AuthCode on page 384
DBMS on page 384
dbUser on page 384
dllname on page 384
DSN on page 384
NetServiceName on page 385
pwdencrypt on page 385
Startup Timeout on page 385
TSSrcCP on page 386

Copyright IBM Corp. 2008, 2011 383

 TSTgtCP on page 386
TCP_KEEPALIVE_SECS on page 386
WindowsAuthentication on page 387

AuthCode
VersionInfoSphere CDC for Microsoft SQL Server version 5.3 and earlier

Use this system parameter to adjust the authorization code issued by IBM.

You may need to modify your authorization code when:

v Moving from a temporary license to a permanent license
v Machine classes have changed
v Upgrading to a new version of InfoSphere CDC

Applies ToSource and Target

Note: You can also modify the authorization using the Authorization Code Setup
utility
Related concepts
System parameters for InfoSphere CDC for Microsoft SQL Server (version 5.3 and
earlier) on page 383
Setting system parameters on source and target datastores on page 71

DBMS
VersionInfoSphere CDC for Microsoft SQL Server version 5.3 and earlier

For information about setting this system parameter, see your IBM representative.

Applies ToTarget

dbUser
VersionInfoSphere CDC for Microsoft SQL Server version 5.3 and earlier

For information about setting this system parameter, see your IBM representative.

Applies ToSource and Target

dllname
VersionInfoSphere CDC for Microsoft SQL Server version 5.3 and earlier

For information about setting this system parameter, see your IBM representative.

Applies ToTarget

DSN
VersionInfoSphere CDC for Microsoft SQL Server version 5.3 and earlier

384 InfoSphere Change Data Capture Management Console: Administration Guide

 Use this system parameter to identify ODBC data source name used by InfoSphere
CDC to define the metadata database on either the source or target system.

Applies ToSource and Target

Note: This parameter was specified during InfoSphere CDC installation.

Related concepts
System parameters for InfoSphere CDC for Microsoft SQL Server (version 5.3 and
earlier) on page 383
Setting system parameters on source and target datastores on page 71

NetServiceName
VersionInfoSphere CDC for Microsoft SQL Server version 5.3 and earlier

For information about setting this system parameter, see your IBM representative.

Applies ToTarget

pwdencrypt
VersionInfoSphere CDC for Microsoft SQL Server version 5.3 and earlier

Use this system parameter to encrypt or decrypt user identifiers and passwords
stored in InfoSphere CDC metadata tables.

Applies ToSource

The pwdencrypt system parameters is set to either 0 or 1:

v 0Do not encrypt user identifiers and passwords in metadata tables.
v 1Encrypt user identifiers and passwords in metadata tables.

Default Setting1

Guidelines

Encryption or decryption does not affect existing user identifiers and passwords in
InfoSphere CDC metadata tables. Any changes you make to this system parameter
apply only to user identifiers and passwords added after setting the system
parameter.
Related concepts
System parameters for InfoSphere CDC for Microsoft SQL Server (version 5.3 and
earlier) on page 383
Setting system parameters on source and target datastores on page 71
Related reference
Deadband Percentage on page 398

Startup Timeout
VersionInfoSphere CDC for Microsoft SQL Server version 5.3 and earlier

For information about setting this system parameter, see your IBM representative.

System parameters for InfoSphere CDC for Microsoft SQL Server (version 5.3 and earlier) 385
 Applies ToSource and Target

TSSrcCP
VersionInfoSphere CDC for Microsoft SQL Server version 5.3 and earlier

Use this system parameter to identify the code page InfoSphere CDC uses for each
instance of a target database.

Applies ToTarget

Default SettingThe system code page when InfoSphere CDC was installed.
Related concepts
System parameters for InfoSphere CDC for Microsoft SQL Server (version 5.3 and
earlier) on page 383
Setting system parameters on source and target datastores on page 71

TSTgtCP
VersionInfoSphere CDC for Microsoft SQL Server version 5.3 and earlier

Use this system parameter to identify the source system code page of InfoSphere
CDC.

Applies ToSource

Default SettingThe system code page when InfoSphere CDC was installed.
Related concepts
System parameters for InfoSphere CDC for Microsoft SQL Server (version 5.3 and
earlier) on page 383
Setting system parameters on source and target datastores on page 71

TCP_KEEPALIVE_SECS
VersionInfoSphere CDC for Microsoft SQL Server version 5.3 and earlier

Use this system parameter to determine the time (in seconds) InfoSphere CDC
waits before sending a keep alive notification over the network. During idle
periods, InfoSphere CDC sends a keep alive notification to keep the connection
open.

Applies ToSource and Target

Default Setting300 seconds (5 min)

Minimum Setting0

Guidelines
v To prevent the firewall from closing during active data replication, set this
parameter to a value lower than the configured firewall timeout.
v To set TCP_KEEPALIVE_SECS:
1. Create a registry key called HKEY_LOCAL_MACHINE\SOFTWARE\DataMirror\
InfoSphere CDC\Comms

386 InfoSphere Change Data Capture Management Console: Administration Guide

 2. Create a string value called TCP_KEEPALIVE_SECS under the registry key
created above.
3. Set TCP_KEEPALIVE_SECS to the value that you want.

Note: It is important you set this system parameter when you have a firewall
connection that has been configured to timeout. This prevents the firewall from
closing the connection.
Related concepts
System parameters for InfoSphere CDC for Microsoft SQL Server (version 5.3 and
earlier) on page 383
Setting system parameters on source and target datastores on page 71

WindowsAuthentication
VersionInfoSphere CDC for Microsoft SQL Server version 5.3 and earlier

For information about setting this parameter, see your IBM representative.

Applies ToSource and Target

Replication system parameters

Replication system parameters let you control how InfoSphere CDC behaves after
detecting errors during replication. You can also control how often InfoSphere CDC
communicates the status of replication activities, and how InfoSphere CDC should
apply a refresh operation.

See also:
AutoRestart
convertNotNullableColumns on page 388
MirrorError on page 388
RefreshError on page 389
RefreshMode on page 389

AutoRestart
VersionInfoSphere CDC for Microsoft SQL Server version 5.3 and earlier

Use this system parameter to enable or disable InfoSphere CDC to automatically

restart replication after detecting a failover in a clustered environment.

Applies ToSource

The AutoRestart system parameters is set to either 0 or 1:

v 0Disables automatic restart of replication operations.
v 1Enables automatic restart of replication operations.

Default Setting0

System parameters for InfoSphere CDC for Microsoft SQL Server (version 5.3 and earlier) 387
 Related concepts
System parameters for InfoSphere CDC for Microsoft SQL Server (version 5.3 and
earlier) on page 383
Setting system parameters on source and target datastores on page 71
Related reference
convertNotNullableColumns

convertNotNullableColumns
VersionInfoSphere CDC for Microsoft SQL Server version 5.3 and earlier

Use this system parameter to indicate whether or not NULL values will be
converted to default values when replicating data that contains NULL values to
non-nullable target columns.

Applies ToTarget

Set this parameter to one of the following:

v OFFAn error message will be generated in Event Log. Replication will
continue or not based on whether the MirrorError or RefreshError system
parameters are set to END or ON.
v ONInfoSphere CDC will automatically insert an appropriate default value in
the target column. No error message is generated in Event Log and replication
continues.
Depending on the convertNotNullableMsg system parameter setting, a warning
message may be generated in Event Log.
The default value depends on the data type of the subscription column. For
example, zero for numeric data types, blank character for character data types,
1901-01-01 for date data types, and so on.

Default SettingOFF
Related concepts
System parameters for InfoSphere CDC for Microsoft SQL Server (version 5.3 and
earlier) on page 383
Setting system parameters on source and target datastores on page 71
System parameters for InfoSphere CDC for Sybase (version 6.0 and earlier) on
page 493
Related reference
MirrorError
RefreshError on page 389
convertNotNullableMsg on page 400
D_MIRROR_MIRROR_ERROR_STOP on page 499
D_MIRROR_REFRESH_ERROR_STOP on page 499

MirrorError
VersionInfoSphere CDC for Microsoft SQL Server version 5.3 and earlier

Use this system parameter to start or stop InfoSphere CDC from continuing
mirroring when it encounters one or more errors.

388 InfoSphere Change Data Capture Management Console: Administration Guide

 Applies ToTarget

The MirrorError system parameter can be set to either END or GO:

v ENDStops mirroring after InfoSphere CDC encounters an error.
v GOContinues mirroring after InfoSphere CDC encounters an error.

Default SettingEND
Related concepts
System parameters for InfoSphere CDC for Microsoft SQL Server (version 5.3 and
earlier) on page 383
Setting system parameters on source and target datastores on page 71

RefreshError
VersionInfoSphere CDC for Microsoft SQL Server version 5.3 and earlier

Use this system parameter to start or stop InfoSphere CDC from continuing
mirroring when it encounters one or more errors.

Applies ToTarget

The RefreshError system parameter can be set to either END or GO:

v ENDInfoSphere CDC ends a refresh operation after it encounters one or more
errors.
v GOInfoSphere CDC continues a refresh operation after it encountering one or
more errors.

Default SettingEND
Related concepts
System parameters for InfoSphere CDC for Microsoft SQL Server (version 5.3 and
earlier) on page 383
Setting system parameters on source and target datastores on page 71

RefreshMode
VersionInfoSphere CDC for Microsoft SQL Server version 5.3 and earlier

Use this system parameter to set how InfoSphere CDC applies rows to the target
during a refresh operation. InfoSphere CDC can use BCP (bulk copy refresh) in
which a block of rows are sent as a single unit during a refresh operation. This
method is faster than the standard method of refreshing tables used by InfoSphere
CDC.

Applies ToTarget

The RefreshMode system parameter can be set to either BCP or SQL:

v BCPPerform a bulk copy refresh.
v SQLPerform a standard refresh.

Default SettingBCP

System parameters for InfoSphere CDC for Microsoft SQL Server (version 5.3 and earlier) 389
 Note: Use the RefreshBlock system parameter to set the number of records in a
block.
Related concepts
System parameters for InfoSphere CDC for Microsoft SQL Server (version 5.3 and
earlier) on page 383
Setting system parameters on source and target datastores on page 71
Related reference
RefreshBlock on page 395

Database translation log system parameters

Database transaction log system parameters let you control how InfoSphere CDC
cleans the logs of the distribution database. You can also control often InfoSphere
CDC reports its log position to the target and performs log synchronization
between the source and the target.

See also:
Cleanup Interval
Cleanup Log Events
Cleanup Record Count on page 391
LogCleanupMethod on page 392
Report Position Interval on page 392
Synchronization Interval on page 393

Cleanup Interval
VersionInfoSphere CDC for Microsoft SQL Server version 5.3 and earlier

Use this system parameter to set the time (in seconds) for InfoSphere CDC to clean
up the distribution database on the source system.

Applies ToSource

Default Setting120 seconds

Minimum Settings1 second

Related concepts
System parameters for InfoSphere CDC for Microsoft SQL Server (version 5.3 and
earlier) on page 383
Setting system parameters on source and target datastores on page 71

Cleanup Log Events

VersionInfoSphere CDC for Microsoft SQL Server version 5.3 and earlier

Use this system parameter to enable or disable InfoSphere CDC from generating a
notification during a cleanup cycle. InfoSphere CDC can generate regular
notifications to indicate how many processed log entries it deleted from the
distribution database during a cleanup cycle. If the cleanup cycle completes in a
short period of time, then InfoSphere CDC only generates notifications that mark
the start and end of each cleanup cycle.

390 InfoSphere Change Data Capture Management Console: Administration Guide

 Applies ToSource

The Cleanup Log Events system parameter is set to either YES or NO:
v YESGenerates notifications indicating the duration of the cleanup cycle and
how many processed log entries have been deleted from the distribution
database.
v NODoes not generate notifications indicating the duration of the cleanup cycle
and how many processed log entries have been deleted from the distribution
database.

Default SettingNO

Notes:
v InfoSphere CDC places notifications in the Event Log.
v If you modify the value after setting the system parameter, InfoSphere CDC uses
the modified value after completing the next cleanup cycle.
v The time between consecutive cleanup cycles is determined by the Cleanup
Interval system parameter.
Related concepts
System parameters for InfoSphere CDC for Microsoft SQL Server (version 5.3 and
earlier) on page 383
Viewing replication events on page 364
Setting system parameters on source and target datastores on page 71

Cleanup Record Count

VersionInfoSphere CDC for Microsoft SQL Server version 5.3 and earlier

Use this system parameter to increase or decrease the number of log entries
InfoSphere CDC can delete from the distribution database during a cleanup cycle.
Depending on the number of log entries you set for deletion and the amount of
data being mirrored in your environment, multiple operations may be required to
delete all processed log entries during a cleanup cycle.

Applies ToSource

Default Setting8000 log entries

Minimum Settings100 log entries

Maximum Settings100000 log entries

Guidelines
v You may want to reduce the number of operations applied to the distribution
database and set this parameter to a higher number so that InfoSphere CDC can
delete a greater number of log entries. Although this improves the performance
of the cleanup cycle, a higher number of log entries can increase the amount of
time it takes for InfoSphere CDC to complete the cleanup cycle. This can also
conflict with other processes that use the distribution database (for example, the
Microsoft log reader process and the InfoSphere CDC log scraper process). To
avoid conflicts with other processes that access the distribution database, set this
parameter to a smaller number of log entries that InfoSphere CDC can delete
during a clean up cycle.

System parameters for InfoSphere CDC for Microsoft SQL Server (version 5.3 and earlier) 391
 v To ensure a short cleanup cycle, set this parameter to the approximate number
of log entries that InfoSphere CDC can delete in your environment in 1 second.

Notes:
v If you set a value outside the acceptable range, then InfoSphere CDC uses the
defaults.
v If you modify the value after setting the system parameter, InfoSphere CDC uses
the modified value after completing the next cleanup cycle.
v The time between consecutive cleanup cycles is determined by the Cleanup
Interval system parameter.
Related concepts
System parameters for InfoSphere CDC for Microsoft SQL Server (version 5.3 and
earlier) on page 383
Setting system parameters on source and target datastores on page 71
Related reference
Cleanup Log Events on page 390

LogCleanupMethod
VersionInfoSphere CDC for Microsoft SQL Server version 5.3 and earlier

Use this system parameter to enable or disable InfoSphere CDC from using IBM
stored procedures to clean up transactions in the distribution database.

Applies ToSource

The LogCleanupMethod system parameter is set to either 0 or 1:

v 0Use Microsoft stored procedures.
v 1Use IBM stored procedures.

Default Setting0
Related concepts
System parameters for InfoSphere CDC for Microsoft SQL Server (version 5.3 and
earlier) on page 383
Setting system parameters on source and target datastores on page 71

Report Position Interval

VersionInfoSphere CDC for Microsoft SQL Server version 5.3 and earlier

Use this system parameter to set how often (in milliseconds) InfoSphere CDC
informs the target system about its log position. When the source system is in idle
mode and there are no log entries for the subscription, the source system informs
the target system of its current log position. The target system uses this
information to advance its bookmarks.

Applies ToSource

Default Setting5000 milliseconds (5 seconds)

Minimum Settings1000 milliseconds (1 second)

392 InfoSphere Change Data Capture Management Console: Administration Guide

 Maximum Settings300000 milliseconds (5 minutes)

Guidelines
v If the number of milliseconds is set low, then the target system can provide
accurate progress notifications that indicate how far replication has progressed.
v If the number of milliseconds is set high, it may affect the accuracy of the
information displayed in progress and bookmark notifications.

Notes:
v If you set a value outside the acceptable range, then InfoSphere CDC uses the
defaults.
v This system parameter can also prevent InfoSphere CDC from rereading log
entries that do not apply to the table currently being replicated.
Related concepts
System parameters for InfoSphere CDC for Microsoft SQL Server (version 5.3 and
earlier) on page 383
Setting system parameters on source and target datastores on page 71
System parameters for InfoSphere CDC for IBM i (version 6.2 and earlier) on
page 533

Synchronization Interval
VersionInfoSphere CDC for Microsoft SQL Server version 5.3 and earlier

Use this system parameter to set how often (in seconds) InfoSphere CDC performs
log synchronization between the source and the target. Synchronization is achieved
when the source reports to the target the position of the last committed change.

Applies ToSource

Default Setting60 seconds

Minimum Settings1 second

Maximum Settings3000 seconds (50 minutes)

Guidelines

If you are replicating large volumes of data, set this system parameter to a lower
number of seconds to remove obsolete logs more frequently.

Note: If a value outside the acceptable range is specified, the default setting is
used.

System parameters for InfoSphere CDC for Microsoft SQL Server (version 5.3 and earlier) 393
 Related concepts
System parameters for InfoSphere CDC for Microsoft SQL Server (version 5.3 and
earlier) on page 383
Setting system parameters on source and target datastores on page 71
System parameters for InfoSphere CDC for IBM i (version 6.2 and earlier) on
page 533

Commitment control system parameters

Commitment control system parameters let you control how InfoSphere CDC
issues commits to the target system.

See also:
CommitmentControl
Commit Group Size on page 395
RefreshBlock on page 395
SeparateCommits on page 396

CommitmentControl
VersionInfoSphere CDC for Microsoft SQL Server version 5.3 and earlier

Use this system parameter to enable or disable InfoSphere CDC from using
commitment control. Enabling commitment control maintains transaction
consistency during replication and ensures that all transactions are applied to the
target system. If there is a communications or server failure and you have enabled
this system parameter, then InfoSphere CDC rolls back the partially applied
transaction to the last commit.

Applies ToSource

The CommitmentControl system parameter is set to either 0 or 2:

v 0Disables commitment control for transaction processing. InfoSphere CDC
does not maintain transaction consistency during replication.
v 2Enables InfoSphere CDC to use commitment control against the target system
after applying all rows. This setting provides true transaction consistency by
ensuring that entire transactions are committed to the target database even in
the event of a communications or server failure

Default Setting0

Note: You can set the maximum number of rows that InfoSphere CDC can contain
a committed transaction using the RefreshBlock system parameter.

394 InfoSphere Change Data Capture Management Console: Administration Guide

 Related concepts
System parameters for InfoSphere CDC for Microsoft SQL Server (version 5.3 and
earlier) on page 383
Setting system parameters on source and target datastores on page 71
Related reference
RefreshBlock

Commit Group Size

VersionInfoSphere CDC for Microsoft SQL Server version 5.3 and earlier

Specifies the number of rows applied to the database before a commit is issued.

Applies ToTarget

This system parameter allows the subscriber to issue the commits on an interval
basis rather than on each entry thus reducing the number of commits and leading
to an improvement in overall apply performance.

Note: This parameter only affects the commit size if the CommitmentControl
parameter is set to 0.

Specify the number of entries you want InfoSphere CDC to apply before issuing a
commit. For example, if you set this parameter to 10, a commit is issued every ten
entries.

Default Setting0 rows. InfoSphere CDC does not use commit groups to perform
synchronization.

RefreshBlock
VersionInfoSphere CDC for Microsoft SQL Server version 5.3 and earlier

Use this system parameter to set the number of rows InfoSphere CDC can contain
in a refresh block or a commit group. Depending on how you are refreshing data
to the target, InfoSphere CDC can contain rows for bulk copy refresh or a commit
group operations.

Applies ToTarget

Default Setting10000 records

Guidelines
v If the table you are replicating is relatively large, IBM recommends increasing
the number of records (refresh block or commit group) to improve performance.
v If you are encounter errors during replication, reduce the number of records.
Although performance is affected, lowering the number of records may
eliminate these errors during replication.

System parameters for InfoSphere CDC for Microsoft SQL Server (version 5.3 and earlier) 395
 Related concepts
System parameters for InfoSphere CDC for Microsoft SQL Server (version 5.3 and
earlier) on page 383
Setting system parameters on source and target datastores on page 71
Related reference
CommitmentControl on page 394
SeparateCommits

SeparateCommits
VersionInfoSphere CDC for Microsoft SQL Server version 5.3 and earlier

Use this system parameter to control how InfoSphere CDC commits bookmarks.
InfoSphere CDC can commit bookmarks together or separate from the user data.
For more information about bookmarks and how to retrieve bookmark values on
the target, see Transformation Server for Microsoft SQL Server Commands Reference.

Applies ToTarget

The SeparateCommits system parameter can set to On or Off:

v OnInfoSphere CDC commits the bookmark separate from user data.
v OffInfoSphere CDC commits the bookmark together with the user data.

Default SettingOff

Guidelines

IBM recommends that you set this parameter to On only for performance reasons.
If you set this parameter to On and InfoSphere CDC encounters an error during
the apply process and ends the apply process abnormally, then this may result in
the bookmark not being synchronized with the target system.
Related concepts
System parameters for InfoSphere CDC for Microsoft SQL Server (version 5.3 and
earlier) on page 383
Setting system parameters on source and target datastores on page 71

Event log system parameters

Event log system parameters let you control how InfoSphere CDC interacts with
notify message queues.

See also:
AllowEventLogClear

AllowEventLogClear
VersionInfoSphere CDC for Microsoft SQL Server version 5.3 and earlier

For information about setting this system parameter, see your IBM representative.

Applies ToSource

396 InfoSphere Change Data Capture Management Console: Administration Guide

Multibyte character set system parameters
Multibyte character set system parameters let you control how InfoSphere CDC
treats character sets during replication.

See also:
Unicode Handling

Unicode Handling
VersionInfoSphere CDC for Microsoft SQL Server version 5.3 and earlier

Use this system parameter to indicate the default method of treating data in
defined Unicode columns. For each InfoSphere CDC installation on a server, this
system parameter defines the system default method of treating data in Unicode
columns. If a Unicode column is set to System Default on the Encoding tab of the
Mapping Details view in Management Console, InfoSphere CDC uses the method
for processing Unicode columns that you select in this system parameter.

Applies ToSource

Data types

Use this system parameter:

v nchar
v nvarchar

This system parameter is set to either CHAR or NOCHANGE:

v CHARInfoSphere CDC treats all data in Unicode columns as single-byte
characters. Use this setting when Unicode columns contain single-byte character
data.
v NOCHANGEInfoSphere CDC treats all data in Unicode columns as a
continuous bit stream. Use this setting when Unicode columns contain
non-single-byte character data. NOCHANGE ensures InfoSphere CDC will
handle non-single-byte character data in the same way as previous InfoSphere
CDC releases.

Default SettingNOCHANGE

Note: NOCHANGE does not ensure that replicated non-single-byte character data
in Unicode columns are represented properly on the target. For replicated
non-single-byte character data, you many need to apply user exit programs or
other customization to properly represent the data in Unicode columns.

For more information about user exit programs, see your InfoSphere CDC for
Microsoft SQL Server documentation

System parameters for InfoSphere CDC for Microsoft SQL Server (version 5.3 and earlier) 397
 Related concepts
System parameters for InfoSphere CDC for Microsoft SQL Server (version 5.3 and
earlier) on page 383
Setting system parameters on source and target datastores on page 71
Related tasks
To set handling for Unicode character encoding on page 170

Latency system parameters

Latency system parameters let you control how often InfoSphere CDC generates a
latency notification and updates latency statistics in the Event Log.

See also:
Deadband Percentage
Monitor Sample Interval on page 400

Deadband Percentage
VersionInfoSphere CDC for Microsoft SQL Server version 5.3 and earlier

Applies ToTarget

Identifies the size of the range around each latency threshold setting. Based on
latency thresholds defined, a latency message is generated when latency has risen
above or fallen below a threshold. Latency is calculated at regular intervals, where
the interval is the current setting for the MONITOR_SAMPLE_INTERVAL system
parameter. You can set notifications in response to a generated latency message.

This system parameter, which is expressed as a percentage, allows you to pad a

threshold equally on both sides to create a range around the threshold. By
adjusting this system parameter, the size of the range around the threshold can be
increased or decreased, and the threshold itself can be made thicker or thinner. A
latency message is generated only when latency has risen above the upper limit of
the range or fallen below the lower limit of the range. By changing the value
assigned to this system parameter, you can control the number of latency messages
placed in Event Log.

For example, assume that a latency threshold is 5 minutes and this system
parameter is set to 10. A 10% range is applied around the 5 minute threshold. The
following calculations are performed to determine the lower and upper limits (in
minutes) of the range around the threshold:
v Padding = 10% of 5 minutes = 0.5 minutes (rounded up to 1 minute)
v Padding is rounded up or down to the nearest whole minute:
Upper limit of range = 5 minutes + 1 minute (padding) = 6 minutes
Lower limit of range = 5 minutes - 1 minute (padding) = 4 minutes

As a result, a latency message will be generated only when latency rises above 6
minutes or falls below 4 minutes. Given sample latency over a ten minute period
where latency is calculated every minute, three latency messages are generated.
This graph illustrates latency message generation with the DEADBAND_PERCENTAGE
value set to 10%:

398 InfoSphere Change Data Capture Management Console: Administration Guide

If this DEADBAND_PERCENTAGE is set to 3 (the default setting) for the same example,
no padding is applied to the latency threshold. Therefore, a latency message is
generated each time latency crosses over the latency threshold of 5 minutes. Based
on the same sample latency in the previous graph where latency is calculated
every minute, five latency messages are generated when this system parameter is
set to 3. This graph illustrates latency message generation with the
DEADBAND_PERCENTAGE value set to 3%:

If the number of latency messages generated over the ten minute period for the
10% (3 latency messages) and 3% (5 latency messages) settings are averages, an
additional 288 latency messages would be generated each day if this system
parameter is not changed from its default setting to 10%.

Since there are two latency thresholds that you can set (a warning threshold and a
problem threshold), two separate ranges are defined when padding is at least one
minute. In this case, each range is attached to its threshold, and the two ranges can
overlap with no change in behavior.

If a value outside the acceptable range is specified, the default setting is used.

Default Setting3%

Minimum Setting3%

Maximum Setting10%

Note: If you set a value outside the acceptable range, then InfoSphere CDC uses
the defaults.

System parameters for InfoSphere CDC for Microsoft SQL Server (version 5.3 and earlier) 399
 Related concepts
System parameters for InfoSphere CDC for Microsoft SQL Server (version 5.3 and
earlier) on page 383
Setting latency thresholds and notifications on page 346
Setting system parameters on source and target datastores on page 71
Related reference
pwdencrypt on page 385

Monitor Sample Interval

VersionInfoSphere CDC for Microsoft SQL Server version 5.3 and earlier

Use this system parameter to set how often (in seconds) InfoSphere CDC updates
replication latency metrics. InfoSphere CDC samples the target system to determine
if latency has risen above or fallen below the specified threshold settings.

Applies ToSource and Target

Default Setting5 seconds

Minimum Setting0 seconds. Replication latency metrics are not updated.

Maximum Setting3600 seconds (one hour)

Notes:
v InfoSphere CDC generates latency notifications when latency rises above or falls
below the thresholds and places these in the Event Log.
v If you set a value outside the acceptable range, then InfoSphere CDC uses the
defaults.
Related concepts
Setting latency thresholds and notifications on page 346
System parameters for InfoSphere CDC for Microsoft SQL Server (version 5.3 and
earlier) on page 383
Setting system parameters on source and target datastores on page 71
System parameters for InfoSphere CDC for IBM i (version 6.2 and earlier) on
page 533

Notification system parameters

Notification system parameters let you control if you should generate InfoSphere
CDC messages in the Event Log for specific events.

See also:
convertNotNullableMsg
DM_STATUS_INTERVAL on page 401
Heartbeat Timeout on page 402
InvalidNumericMsg on page 402

convertNotNullableMsg
VersionInfoSphere CDC for Microsoft SQL Server version 5.3 and earlier

400 InfoSphere Change Data Capture Management Console: Administration Guide

 Use this system parameter to indicate whether or not a warning message will be
generated in Event Log each time data that contains NULL values is converted to
default values for non-nullable target columns.

Applies ToTarget

This system parameter applies only when convertNotNullableColumns=ON.

Otherwise, this parameter has no effect.

Set this parameter to one of the following:

v OFFNo warning message is generated in Event Log.
v ONA warning message is generated in Event Log each time a NULL value is
converted to a default value.

Default SettingOFF
Related concepts
System parameters for InfoSphere CDC for Microsoft SQL Server (version 5.3 and
earlier) on page 383
Setting system parameters on source and target datastores on page 71
System parameters for InfoSphere CDC for Sybase (version 6.0 and earlier) on
page 493
Related reference
convertNotNullableColumns on page 388
DM_STATUS_INTERVAL
Heartbeat Timeout on page 402
InvalidNumericMsg on page 402

DM_STATUS_INTERVAL
VersionInfoSphere CDC for Microsoft SQL Server version 5.3 and earlier

Use this system parameter to set how often (in seconds) InfoSphere CDC issues
progress notifications about the status of replication activities.

On the source, progress notifications identify:

v The bookmark sent by the source
v The corresponding log name
v The subscription name to which the bookmark was sent

On the target, progress notifications identify:

v The bookmark received by the target
v The corresponding log name
v The source ID from which the bookmark was received

Applies ToSource and Target

Default Setting0 seconds. No progress notifications will be issued.

Minimum Setting0 seconds. No progress notifications will be issued.

Maximum Setting7200 seconds

System parameters for InfoSphere CDC for Microsoft SQL Server (version 5.3 and earlier) 401
 Notes:
v InfoSphere CDC places progress notifications in the Event Log.
v If a value outside the acceptable range is specified, the default setting is used.
Related concepts
System parameters for InfoSphere CDC for Microsoft SQL Server (version 5.3 and
earlier) on page 383
Setting system parameters on source and target datastores on page 71

Heartbeat Timeout
VersionInfoSphere CDC for Microsoft SQL Server version 5.3 and earlier

Use this system parameter to increase or decrease the communication timeout

interval (in minutes) before InfoSphere CDC detects a communication problem and
attempts to stop active replication processes.

InfoSphere CDC sends internal heartbeat notifications between the source and
target systems to verify communications and the status of replication processes for
each active subscription. If the source or target do not receive a reply to a
notification within the specified timeout interval, then InfoSphere CDC determines
that a problem has occurred and attempts to stop all its source and target
processes for each active subscription.

Applies ToSource

Default Setting15 minutes

Minimum Setting3 minutes

Maximum Setting999 minutes

Notes:
v InfoSphere CDC places notifications (message identifiers 3165 and 11010) in the
Event Log when a heartbeat timeout occurs.
v If you set a value outside the acceptable range, then InfoSphere CDC uses the
defaults.
Related concepts
System parameters for InfoSphere CDC for Microsoft SQL Server (version 5.3 and
earlier) on page 383
Viewing replication events on page 364
Setting system parameters on source and target datastores on page 71

InvalidNumericMsg
VersionInfoSphere CDC for Microsoft SQL Server version 5.3 and earlier

Use this system parameter to enable or disable InfoSphere CDC from generating a
notification each time it detects an invalid numeric field.

Applies ToTarget

The InvalidNumericMsg system parameter can be set to YES, NO, or NB.

402 InfoSphere Change Data Capture Management Console: Administration Guide

 v YESGenerate a notification for each invalid numeric field detected by
InfoSphere CDC.
v NODo not generate a notification for each invalid numeric field detected by
InfoSphere CDC.
v NBGenerate a notification for certain types of invalid numeric fields detected
by InfoSphere CDC. notifications are generated for each invalid numeric fields
except those that are not initialized.

Default SettingYES
Related concepts
System parameters for InfoSphere CDC for Microsoft SQL Server (version 5.3 and
earlier) on page 383
Setting system parameters on source and target datastores on page 71

Tracing system parameters

Tracing system parameters let you perform diagnostic activities with InfoSphere
CDC.

See also:
CommTrace
ProgramTrace on page 404
traceActive on page 404
TraceLevel on page 404
trcCleanup on page 405
trcCOMM on page 405
trcFiles on page 405
trcFncCalls on page 405
trcJrlSync on page 406
trcReplStatus on page 406
trcScan on page 406
trcSQL on page 406
trcThread on page 406

CommTrace
VersionInfoSphere CDC for Microsoft SQL Server version 5.3 and earlier

Use this system parameter to turn tracing of the communications module on or off.

Applies ToTarget

The CommTrace system parameter can be set to either ON or OFF:

v ONActivates a communications module trace.
v OFFDo not activate a communications module trace.

Default SettingOFF

Notes:
v The trace should only be produced if requested by IBM technical support.

System parameters for InfoSphere CDC for Microsoft SQL Server (version 5.3 and earlier) 403
 v Activating a trace adversely affects performance.
Related concepts
System parameters for InfoSphere CDC for Microsoft SQL Server (version 5.3 and
earlier) on page 383
Setting system parameters on source and target datastores on page 71

ProgramTrace
VersionInfoSphere CDC for Microsoft SQL Server version 5.3 and earlier

Use this system parameter to activate or deactivate InfoSphere CDC from tracing
the update module.

Applies ToTarget

The ProgramTrace system parameter can be set to either ON or OFF:

v ONActivate an update module trace.
v OFFDo not activate an update module trace.

Default SettingOFF

Notes:
v The trace is encrypted and should only be produced if requested by IBM
technical support.
v Activating a trace adversely affects performance.
Related concepts
System parameters for InfoSphere CDC for Microsoft SQL Server (version 5.3 and
earlier) on page 383
Setting system parameters on source and target datastores on page 71

traceActive
VersionInfoSphere CDC for Microsoft SQL Server version 5.3 and earlier

For information about setting this system parameter, see your IBM representative.

Applies ToSource

TraceLevel
VersionInfoSphere CDC for Microsoft SQL Server version 5.3 and earlier

Use this system parameter to set the level of detail produced by a program trace.

Applies ToTarget

The TraceLevel system parameter can be set to either 1, 2, or 3:

v 1Produces a trace with the highest level of detail.
v 2Produces a trace with a medium level of detail.
v 3Produces a trace with the lowest level of detail.

Default Setting3

404 InfoSphere Change Data Capture Management Console: Administration Guide

 Note: Contact IBM technical support for the suggested level of detail.
Related concepts
System parameters for InfoSphere CDC for Microsoft SQL Server (version 5.3 and
earlier) on page 383
Setting system parameters on source and target datastores on page 71

trcCleanup
VersionInfoSphere CDC for Microsoft SQL Server version 5.3 and earlier

For information about setting this system parameter, see your IBM representative.

Applies ToSource

trcCOMM
VersionInfoSphere CDC for Microsoft SQL Server version 5.3 and earlier

For information about setting this system parameter, see your IBM representative.

Applies ToSource

trcFiles
VersionInfoSphere CDC for Microsoft SQL Server version 5.3 and earlier

Use this system parameter to identify the location of the file that contains
information produced by an update or communications module trace.

Applies ToSource and Target

Default SettingInfoSphere CDC installation folder.

Guidelines

You must specify the full path of the folder where you want to place the trace file.

Note: You can enable tracing using the ProgramTrace and CommTrace system
parameters.
Related concepts
System parameters for InfoSphere CDC for Microsoft SQL Server (version 5.3 and
earlier) on page 383
Setting system parameters on source and target datastores on page 71
Related reference
CommTrace on page 403
ProgramTrace on page 404

trcFncCalls
VersionInfoSphere CDC for Microsoft SQL Server version 5.3 and earlier

For information about setting this system parameter, see your IBM representative.

System parameters for InfoSphere CDC for Microsoft SQL Server (version 5.3 and earlier) 405
 Applies ToSource

trcJrlSync
VersionInfoSphere CDC for Microsoft SQL Server version 5.3 and earlier

For information about setting this system parameter, see your IBM representative.

Applies ToSource

trcReplStatus
VersionInfoSphere CDC for Microsoft SQL Server version 5.3 and earlier

For information about setting this system parameter, see your IBM representative.

Applies ToSource

trcScan
VersionInfoSphere CDC for Microsoft SQL Server version 5.3 and earlier

For information about setting this system parameter, see your IBM representative.

Applies ToSource

trcSQL
VersionInfoSphere CDC for Microsoft SQL Server version 5.3 and earlier

For information about setting this system parameter, see your IBM representative.

Applies ToSource

trcThread
VersionInfoSphere CDC for Microsoft SQL Server version 5.3 and earlier

For information about setting this system parameter, see your IBM representative.

Applies ToSource

Data type system parameters

Data type system parameters let you control how InfoSphere CDC handles certain
data types.

See also:
TrimVarchar on page 407

406 InfoSphere Change Data Capture Management Console: Administration Guide

 TrimVarchar
VersionInfoSphere CDC for Microsoft SQL Server version 5.3 and earlier

For information about setting this system parameter, see your IBM representative.

Applies ToTarget

Lock detection system parameters

Lock detection system parameters let you control how InfoSphere CDC applies
data when it detects a locked table or row.

See also:
DeadlockRetrys
DM_LOCK_DETECTION
DM_LOCK_TIMEOUT on page 408

DeadlockRetrys
VersionInfoSphere CDC for Microsoft SQL Server version 5.3 and earlier

Use this system parameter to identify the number of attempts InfoSphere CDC
applies a table or row-level operation (clear table, insert, update, or delete) to the
target table after detecting a deadlock. If the operation cannot be applied after the
specified number of attempts has been made, InfoSphere CDC cancels the
operation and generates an error notification in Event Log.

Applies ToTarget

Default Setting3 attempts

Related concepts
Viewing replication events on page 364
System parameters for InfoSphere CDC for Microsoft SQL Server (version 5.3 and
earlier) on page 383
Setting system parameters on source and target datastores on page 71

DM_LOCK_DETECTION
VersionInfoSphere CDC for Microsoft SQL Server version 5.3 and earlier

Use this system parameter to turn lock detection on or off. If InfoSphere CDC
attempts to modify a table or row that has been locked by another process, then
turning lock detection ON enables InfoSphere CDC to wait for a specific amount of
time before attempting to apply the data again.

Applies ToSource and Target

The DM_LOCK_DETECTION system can be set to either ON or OFF:

v ONEnables table and row lock detection.
v OFFDisables table and row lock detection. InfoSphere CDC waits until the
locked row becomes available.

System parameters for InfoSphere CDC for Microsoft SQL Server (version 5.3 and earlier) 407
 Default SettingON

Note: You can specify the time to wait using the DM_LOCK_TIMEOUT system
parameter.
Related concepts
System parameters for InfoSphere CDC for Microsoft SQL Server (version 5.3 and
earlier) on page 383
Setting system parameters on source and target datastores on page 71
Related reference
DM_LOCK_TIMEOUT

DM_LOCK_TIMEOUT
VersionInfoSphere CDC for Microsoft SQL Server version 5.3 and earlier

Use this system parameter to set the amount of time (in seconds) that InfoSphere
CDC waits before attempting to modify a locked user or metadata table. When
InfoSphere CDC attempts to modify a locked table, it places a notification in the
Event Log. These notifications identify the specific table and row that InfoSphere
CDC could not modify.

Applies ToTarget

Default Setting30 seconds

Minimum Setting1 second

Maximum Setting60 seconds

Notes:
v If you set a value outside the acceptable range, then InfoSphere CDC uses the
defaults.
v Table locking notification is supported for tables containing user data and
replication metadata tables.
Related concepts
System parameters for InfoSphere CDC for Microsoft SQL Server (version 5.3 and
earlier) on page 383
Setting system parameters on source and target datastores on page 71

408 InfoSphere Change Data Capture Management Console: Administration Guide

System Parameters for InfoSphere CDC for Microsoft SQL
Server (version 6.0 and later)
System parameters let you control the behavior of InfoSphere CDC. If your
replication environment requires a particular configuration, then you can use
system parameters to modify the behavior of default operations in InfoSphere
CDC. The default system parameter settings are appropriate for most installations.
Maintain these default settings until you become familiar with the configuration of
InfoSphere CDC.

InfoSphere CDC provides system parameters that control the behavior of your
source and target datastores.

Notes:
v If you make changes to a system parameter during active replication, you must
stop and restart InfoSphere CDC for the changes to take effect.
v When upgrading to a later version of InfoSphere CDC, any preexisting settings
for system parameters are maintained.

In this section, you will learn:

General product system parameters
Notification system parameters on page 410
Maximize throughput system parameters on page 411
Encoding system parameters on page 413
Supplemental logging system parameters on page 414
Disk resource system parameters on page 415
Apply process system parameters on page 416

General product system parameters

General product system parameters let you control basic features of InfoSphere
CDC and information you may have specified during installation.

See also:
mirror_auto_restart_interval_minutes

mirror_auto_restart_interval_minutes
VersionInfoSphere CDC for Sybase version 6.3 Fix Pack 3 TFE 9 and later.

Use this parameter to indicate how long (in minutes) InfoSphere CDC will attempt
to automatically restart continuous mirroring for persistent subscriptions.

Applies ToSource

Default0

Minimum0

Maximum60
Copyright IBM Corp. 2008, 2011 409
Notification system parameters
Notification system parameters let you control if you should generate InfoSphere
CDC messages in the Event Log for specific events.

See also:
events_max_retain
global_shutdown_after_no_heartbeat_response_minutes
global_conversion_not_possible_warning

events_max_retain
VersionInfoSphere CDC for Microsoft SQL Server version 6.0 and later

Use this system parameter to control the maximum number of events that
InfoSphere CDC will store in the event log. If InfoSphere CDC generates more
events than the specified maximum, then the earliest events will be deleted.

Default Setting10000

Minimum -1

Maximum2147483647

global_shutdown_after_no_heartbeat_response_minutes
VersionInfoSphere CDC for Microsoft SQL Server version 6.0 and later

Use this system parameter to specify the duration, in minutes, of communication

inactivity before active InfoSphere CDC processes for a subscription are stopped. If
a value outside the acceptable range is specified, the default setting is used.

Applies ToSource

Default Setting15 minutes

Minimum Setting3 minutes

Maximum Setting999 minutes

Related concepts
System Parameters for InfoSphere CDC for Microsoft SQL Server (version 6.0 and
later) on page 409
Setting system parameters on source and target datastores on page 71

global_conversion_not_possible_warning
VersionInfoSphere CDC for Microsoft SQL Server version 6.0 and later

Use this system parameter to control whether or not InfoSphere CDC generates a
warning in the Management Console Event Log in the following situations:
v Data conversion is not possible for a specific data value.
v Converted data types are encountered that are out of range.

410 InfoSphere Change Data Capture Management Console: Administration Guide

 Set this parameter to one of the following:
v trueGenerates a warning in the Event Log if data conversion is not possible
for a specific data value or converted data types are encountered that are out of
range.
v falseDoes not generate a warning in the Event Log if data conversion is not
possible for a specific data value or converted data types are encountered that
are out of range.

Applies ToTarget

Default Settingfalse
Related concepts
System Parameters for InfoSphere CDC for Microsoft SQL Server (version 6.0 and
later) on page 409
Setting system parameters on source and target datastores on page 71
Related reference
global_default_after_database_minimum_timestamp on page 417
global_default_before_database_minimum_timestamp on page 418

Maximize throughput system parameters

InfoSphere CDC system parameters allow you to significantly reduce the workload
of the target database during mirroring. The InfoSphere CDC apply process groups
transactions on the target to reduce the workload. Every commit on the target
database will correspond with a commit on the target. However, it may not
perform every commit that was done on the source. For example, if the source
does three small transactions containing one operation each, the target may commit
all three operations as part of a single transaction. You can use this grouping of
system parameters to significantly reduce the resources required by the target
database. The default settings are appropriate for most databases, but if your target
system has limited resources and an increase in latency is acceptable, you can
adjust the settings appropriately.

See also:
global_max_batch_size
mirror_interim_commit_threshold on page 412
refresh_commit_after_max_operations on page 412

global_max_batch_size
VersionInfoSphere CDC for Microsoft SQL Server version 6.0 and later

Use this system parameter to specify the maximum number of rows that
InfoSphere CDC can place in an array and apply to the target database during
refresh or mirroring. InfoSphere CDC collects rows and places them in an array (in
memory) while receiving table-level operations from the source system. InfoSphere
CDC applies the rows from the array when there is a change to a different table,
when there is a new table-level operation, or when the maximum number of rows
in an array has been reached. You can use this parameter during mirroring only if
mirror_end_on_error is true and mirror_expected_errors_list is empty. Use only
during a refresh if refresh_end_on_error is true and refresh_expected_errors_list is
empty. Before InfoSphere CDC places rows into an array, it allocates memory for
the maximum number of rows you specify and multiplies this integer by the

System Parameters for InfoSphere CDC for Microsoft SQL Server (version 6.0 and later) 411
 maximum length of a row. If the maximum number of rows is too large, then
InfoSphere CDC cannot allocate enough memory and will shut down. Management
Console references this area to present replication latency information.

Applies ToTarget

Default Setting25 rows

Maximum Setting2147483647 rows

Minimum Setting1 row

mirror_interim_commit_threshold
VersionInfoSphere CDC for Microsoft SQL Server version 6.3 Fix Pack 3 and
later.

By default, InfoSphere CDC guarantees transactional delivery of change data to the

target. This ensures that if any data from a source transaction is committed to the
target, then all other in scope operations from that source transaction are
committed as well.

In cases where large transactions are done on the source system, it can be more
efficient to break a large transaction into smaller transactions when applying data
to the target. You can configure this behavior using this system parameter.

The default value of 0 for this system parameter indicates that the product
guarantees transactional delivery of change data to the target. A value greater than
0 indicates that you want InfoSphere CDC to break up large transactions into
smaller transactions. For example, a value of 2000 indicates that InfoSphere CDC
will split up large source transactions so that each transaction committed to the
target database contains no more than 2000 operations.

Applies ToTarget

Default Setting0

Minimum Setting0

refresh_commit_after_max_operations
VersionInfoSphere CDC for Microsoft SQL Server version 6.0 and later

This system parameter identifies the number of rows comprising each transaction
during refresh. To reduce the workload on the target database during refresh,
InfoSphere CDC periodically commits the changes to the target database rather
than performing the refresh as a single large transaction.

Applies ToTarget

Default Setting1000

Maximum Setting2147483647

Minimum Setting1

412 InfoSphere Change Data Capture Management Console: Administration Guide

 Related concepts
System Parameters for InfoSphere CDC for Microsoft SQL Server (version 6.0 and
later) on page 409
Setting system parameters on source and target datastores on page 71

Encoding system parameters

For some system parameters, you can set the default method for treating data in
defined Unicode columns, and you can set the default character encoding for your
database.

See also:
global_unicode_as_char

global_unicode_as_char
VersionInfoSphere CDC for Microsoft SQL Server version 6.0 and later

This system parameter indicates the default method of treating data in defined
Unicode columns. For each InfoSphere CDC installation on a server, this system
parameter defines the system default method of treating data in Unicode columns.
If a Unicode column is set to System Default on the Encoding tab of the Mapping
Details view in Management Console, InfoSphere CDC uses the method for
processing Unicode columns that you select in this system parameter.

Set this parameter to one of the following:

v trueInfoSphere CDC treats all data in Unicode columns as single-byte
characters. Use this setting when Unicode columns contain single-byte character
data.
v falseInfoSphere CDC treats all data in Unicode columns as a continuous bit
stream. Use this setting when Unicode columns contain non-single-byte
character data. Setting this system parameter to false ensures that InfoSphere
CDC handles non-single-byte character data in the same way as previous
InfoSphere CDC releases.

Note: Setting this parameter to false does not ensure that replicated
non-single-byte character data in Unicode columns are represented properly on
the target. For replicated non-single-byte character data, you may have to apply
user exit programs or other customizations to properly represent data in
Unicode columns. For more information about user exit programs, see the
InfoSphere CDC End-User Documentation for your platform.

Applies ToSource

Default Settingfalse

Note: The following SQL Server data types are considered to be Unicode columns
and are therefore affected by the value assigned to this system parameter:
v nchar
v nvarchar

System Parameters for InfoSphere CDC for Microsoft SQL Server (version 6.0 and later) 413
 Related concepts
System Parameters for InfoSphere CDC for Microsoft SQL Server (version 6.0 and
later) on page 409
Setting system parameters on source and target datastores on page 71
Common encoding conversion scenarios on page 164

Supplemental logging system parameters

Some system parameter control the database logging mechanism used by
InfoSphere CDC.

See also:
mirror_logging_by_empty_triggers
auto_configure_supplemental_logging on page 531
mirror_logging_by_empty_triggers on page 531

mirror_logging_by_empty_triggers
VersionInfoSphere CDC for Microsoft SQL Server version 6.0 and later

This system parameter allows you to choose empty triggers as your supplemental
logging method for Microsoft SQL Server 2000.

Set this parameter to one of the following:

v trueEmpty triggers are used as your supplemental logging method for
Microsoft SQL Server 2000.
v falseThe Distribution Database is used as your supplemental logging method.
This method of supplemental logging is available for Microsoft SQL Server 2000
and Microsoft SQL Server 2005.

If you choose false and are using Microsoft SQL Server 2000, you must add your
database to replication/publication with the following steps:
1. Set up Microsoft Replication and verify that the Distribution database exists.
2. Add the database to Microsoft Replication using the following query:
EXEC sp_replicationdboption @dbname = 'your_db_name', @optname =
'publish', @value = 'true'

Where your_db_name is your database name.

Note that you can use the following query to check if your database is enabled for
Microsoft Replication:

exec sp_helpreplicationdboption

Applies ToSource

Default Settingtrue

414 InfoSphere Change Data Capture Management Console: Administration Guide

 Related concepts
System Parameters for InfoSphere CDC for Microsoft SQL Server (version 6.0 and
later) on page 409
Setting system parameters on source and target datastores on page 71

Disk resource system parameters

Some system parameters control memory usage in InfoSphere CDC. For improved
performance, if you are able to allocate more than the default value of 512 MB for
the InfoSphere CDC Java Virtual Machine, then you can adjust the disk resource
system parameters to use the increased memory.

See also:
mirror_global_disk_quota_mb
mirror_global_disk_quota_gb

mirror_global_disk_quota_mb
VersionInfoSphere CDC for Microsoft SQL Server version 6.3

Use this system parameter to globally set a disk quota (in MB) for all capture
components including temporary files, transaction queues, and LOBs which are
staged on the target before being applied. InfoSphere CDC will manage disk space
utilization across all components as required.

Most databases have a mechanism that allows you to roll back or undo changes to
your database by storing uncommitted changes. Similarly, InfoSphere CDC uses
the disk quota controlled by this system parameter to store in scope change data
that has not been committed in your database. Once the database transaction is
committed, the disk space used by the transaction is released. Note that InfoSphere
CDC stores the data in memory to improve performance and will only persist the
data to disk if memory is unavailable.

The default setting of this system parameter is such that the product will only stop
replicating after this disk quota exhausts all available disk space on your system. If
you would prefer the product to stop replicating after it uses a specific amount of
disk space, you can set the value with this system parameter.

Applies ToSource and Target

Default Setting9223372036854775807

Maximum9223372036854775807

Minimum100

mirror_global_disk_quota_gb
VersionInfoSphere CDC for Microsoft SQL Server version 6.5

Use this system parameter to globally set a disk quota (in GB) for all capture
components including temporary files, transaction queues, and LOBs which are
staged on the target before being applied. InfoSphere CDC will manage disk space
utilization across all components as required.

System Parameters for InfoSphere CDC for Microsoft SQL Server (version 6.0 and later) 415
 Most databases have a mechanism that allows you to roll back or undo changes to
your database by storing uncommitted changes. Similarly, InfoSphere CDC uses
the disk quota controlled by this system parameter to store in scope change data
that has not been committed in your database. Once the database transaction is
committed, the disk space used by the transaction is released. Note that InfoSphere
CDC stores the data in memory to improve performance and will only persist the
data to disk if memory is unavailable.

The default setting of this system parameter is such that the product will only stop
replicating after this disk quota exhausts all available disk space on your system. If
you would prefer the product to stop replicating after it uses a specific amount of
disk space, you can set the value with this system parameter.

Applies ToSource and Target

Default Setting9223372036854775807

Maximum9223372036854775807

Minimum1

Apply process system parameters

Some system parameters adjust the way InfoSphere CDC applies rows, column
data, and error handling.

See also:
convert_not_nullable_column
convert_not_nullable_message on page 417
global_default_after_database_minimum_timestamp on page 417
global_default_before_database_minimum_timestamp on page 418
mirror_end_on_error on page 418
mirror_expected_errors_list on page 418
refresh_end_on_error on page 419
refresh_expected_errors_list on page 419
refresh_loader_drop_index on page 419
refresh_with_referential_integrity on page 420
userexit_max_lob_size_kb on page 420

convert_not_nullable_column
VersionInfoSphere CDC for Microsoft SQL Server version 6.0 and later

Use this system parameter to control how InfoSphere CDC behaves when it applies
a null value to a non-nullable column. When set to true (default value), the null
value will be replaced with a default value (based on the data type of the column)
and InfoSphere CDC will generate a warning in the event log. When set to false,
InfoSphere CDC applies the null value directly to the non-nullable column which
will result in an error and cause a shutdown of InfoSphere CDC on the target
database.

416 InfoSphere Change Data Capture Management Console: Administration Guide

 Note: If you decided to set this system parameter to false and have specified this
as an error for InfoSphere CDC to ignore using the mirror_expected_errors_list
system parameter, then InfoSphere CDC will ignore the error and not shutdown.

Set this parameter to one of the following:

v trueNull value will be replaced with default value for non-nullable column,
and a warning event will be logged.
v falseNull data will be applied as-is to non-nullable column and database will
usually return an error code.

Applies ToSource and Target

Default SettingTrue

convert_not_nullable_message
VersionInfoSphere CDC for Microsoft SQL Server version 6.0 and later

Use this system parameter to determine if a message will be generated in the

Event Log when InfoSphere CDC converts a null value to a default value when
applied to a non-nullable column. When set to true (default value), InfoSphere
CDC will log the event the first time it encounters a null to non-nullable mapping
(on a per column per table basis). When set to false, InfoSphere CDC will not
generate a message when a null value is converted to a default value.

Note: This system parameter applies only when the convert_not_nullable_column

parameter has been set to true.

Set this parameter to one of the following:

v trueGenerates a warning message in the Event Log the first time a null value
is converted to a default value on a per column per table basis.
v falseNo warning message is generated in the Event Log.

Applies ToTarget

Default SettingTrue

global_default_after_database_minimum_timestamp
VersionInfoSphere CDC for Microsoft SQL Server version 6.0 and later

In environments where the timestamp range in your source database differs from
the target database, this system parameter allows you to control the default values
that InfoSphere CDC sets on the target for out-of-range date-time values.

Use this system parameter to control the value substituted by InfoSphere CDC in
the target database when a value is being set on a target date-time column that is
greater than the maximum accepted value for the target database.

Note: To determine if a value is out-of-range, InfoSphere CDC converts the value

to a timestamp data type and then validates the timestamp to determine if it is
within range.

Default Setting1901-01-01 00:00:00.000

System Parameters for InfoSphere CDC for Microsoft SQL Server (version 6.0 and later) 417
 Related reference
global_conversion_not_possible_warning on page 410

global_default_before_database_minimum_timestamp
VersionInfoSphere CDC for Microsoft SQL Server version 6.0 and later

In environments where the timestamp range in your source database differs from
the target database, this system parameter allows you to control the default values
that InfoSphere CDC sets on the target for out-of-range date-time values.

Use this system parameter to control the value substituted by InfoSphere CDC in
the target database when a value is being set on a target date-time column that is
less than the minimum accepted value for the target database.

Note: To determine if a value is out-of-range, InfoSphere CDC converts the value

to a timestamp data type and then validates the timestamp to determine if it is
within range.

Default Setting1901-01-01 00:00:00.000

Related reference
global_conversion_not_possible_warning on page 410

mirror_end_on_error
VersionInfoSphere CDC for Microsoft SQL Server version 6.0 and later

Use this system parameter to indicate if you want to end mirroring after an apply
error occurs on the target database.

Set this parameter to one of the following:

v trueEnd mirroring after an apply error on the target database.
v falseDo not end mirroring after an apply error on the target database.

Applies ToTarget

Default SettingTrue
Related concepts
System Parameters for InfoSphere CDC for Microsoft SQL Server (version 6.0 and
later) on page 409
Setting system parameters on source and target datastores on page 71

mirror_expected_errors_list
VersionInfoSphere CDC for Microsoft SQL Server version 6.0 and later

Use this system parameter when you want InfoSphere CDC to ignore one or more
database errors when applying data changes to the target during mirroring. The
error specified must correspond to the integer error code (database-vendor specific)
returned by the SQLException class in JDBC (Java Database Connectivity). Specify
multiple errors with a comma separated list of integer error codes.

418 InfoSphere Change Data Capture Management Console: Administration Guide

 Note: Latency may increase when using this system parameter since InfoSphere
CDC will not use JDBC array apply in order to track the errors specified.

Applies ToTarget

refresh_end_on_error
VersionInfoSphere CDC for Microsoft SQL Server version 6.0 and later

Use this system parameter to indicate if you want to end a refresh after an apply
error occurs.

Set this parameter to one of the following:

v trueEnd a refresh after an apply error occurs.
v falseDo not end a refresh after an apply error occurs.

Applies ToTarget

Default SettingTrue
Related concepts
System Parameters for InfoSphere CDC for Microsoft SQL Server (version 6.0 and
later) on page 409
Setting system parameters on source and target datastores on page 71

refresh_expected_errors_list
VersionInfoSphere CDC for Microsoft SQL Server version 6.0 and later

Use this system parameter when you want InfoSphere CDC to ignore one or more
database errors when refreshing data to the target. The error specified must
correspond to the integer error code (database-vendor specific) returned by the
SQLException class in JDBC (Java Database Connectivity). Specify multiple errors
with a comma separated list of integer error codes.

Note: Latency may increase when using this system parameter since InfoSphere
CDC will not use JDBC array apply in order to track the errors specified.

Applies ToTarget

refresh_loader_drop_index
VersionInfoSphere CDC for Microsoft SQL Server version 6.0 and later

This system parameter indicates whether or not InfoSphere CDC will drop all
indexes on the tables being refreshed and then rebuild the indexes after the refresh.
In most environments, this will improve refresh performance.

If the refresh fails for any reason, InfoSphere CDC will write SQL statements to a
file which will allow you to manually rebuild the indexes for all tables in your
database. The location of the file is specified in the Management Console event log.

Applies ToTarget

Default Settingtrue

System Parameters for InfoSphere CDC for Microsoft SQL Server (version 6.0 and later) 419
 refresh_with_referential_integrity
VersionInfoSphere CDC for Microsoft SQL Server version 6.0 and later

Use this system parameter to indicate whether or not you want the data removed
from all the target tables being refreshed before repopulating any of them. This is
most useful when there are referential integrity constraints on the tables being
refreshed.

Set this parameter to one of the following:

v trueIndicates that InfoSphere CDC will first remove all data in reverse of the
specified refresh order. When specifying the refresh order, in general parent
tables should appear before the referenced child tables. The product will then
remove data from the child tables before the parent tables.
v falseIndicates that InfoSphere CDC will not first remove all data from your
tables and will refresh the tables in the specified order.

Applies ToSource

Default Settingfalse

userexit_max_lob_size_kb
VersionInfoSphere CDC for Microsoft SQL Server version 6.0 and later

Use this system parameter to set the maximum size of LOB data (in kb) that
InfoSphere CDC can pass to a user exit.

Applies ToTarget

Default Setting128 kb

Maximum9223372036854775807 kb

Minimum1 kb

420 InfoSphere Change Data Capture Management Console: Administration Guide

System parameters for InfoSphere CDC for Oracle (version
6.2 and earlier)
System parameters let you control the behavior of InfoSphere CDC. If your
replication environment requires a particular configuration, then you can use
system parameters to modify the behavior of default operations in InfoSphere
CDC. The default system parameter settings are appropriate for most installations.
Maintain these default settings until you become familiar with the configuration of
InfoSphere CDC.

InfoSphere CDC provides system parameters that control the behavior of your
source and target datastores.

Note: If you make changes to a system parameter during active replication, you
must stop and restart replication for the changes to take effect.

In this section, you will learn:

General product system parameters
Apply process system parameters on page 431
Cascading replication system parameters on page 440
Database journal (trigger) system parameters on page 441
Maximize throughput system parameters on page 443
Tracing system parameters on page 448
Refresh loader system parameters on page 451
User exit system parameters on page 455
Table mapping system parameters on page 456
Notification system parameters on page 457
Disk resource system parameters on page 462

General product system parameters

General product system parameters let you control basic features of InfoSphere
CDC and information you may have specified during installation.

See also:
CODE_PAGE on page 422
DEFAULT_ORACLE_HOME on page 422
DEFAULT_ORACLE_SID on page 422
DEFAULT_ORACLE_USER on page 423
DM_COMMS_HOME on page 423
D_MIRROR_HOME on page 423
D_MIRROR_LOG on page 423
DM_DYNAMIC_PARAMETER_CHECK_INT on page 424
DM_MAX_MONITOR_ENTRIES on page 424
DM_TS_MAX_POOL_SIZE_MB on page 425
DM_TS_POOL_BLOCK_SIZE_MB on page 425
<subscription>_MAX_POOL_SIZE_MB on page 426

Copyright IBM Corp. 2008, 2011 421

 <subscription>_POOL_BLOCK_SIZE_MB on page 426
LD_LIBRARY_PATH on page 427
LIBPATH on page 427
ORACLE_HOME on page 427
ORACLE_SID on page 428
PASSWORD on page 428
PUBLISH_METADATA on page 428
RLD_SYSTEM_TXQSIZE on page 429
<subscription>_TXQSIZE on page 429
SHLIB_PATH on page 430
STARTUP_TIMEOUT on page 430
TCP_KEEPALIVE_SECS on page 430
USER on page 431

CODE_PAGE
VersionInfoSphere CDC for Oracle version 6.2 and earlier

Use this system parameter to specify the code page associated with NLS_LANG.
This value is set during installation and should not be modified except under the
guidance of a IBM technical support.

Applies ToSource and Target

Default SettingThe system code page when InfoSphere CDC was installed.
Related concepts
System parameters for InfoSphere CDC for Oracle (version 6.2 and earlier) on
page 421
Related reference
NLS_LANG on page 437

DEFAULT_ORACLE_HOME
VersionInfoSphere CDC for Oracle version 6.2 and earlier

Use this parameter to specify the installation directory for the Oracle database
instance that is started by default. Modify this parameter only if you installed
InfoSphere CDC in multiple database instances.

Applies ToSource
Related concepts
System parameters for InfoSphere CDC for Oracle (version 6.2 and earlier) on
page 421

DEFAULT_ORACLE_SID
VersionInfoSphere CDC for Oracle version 6.2 and earlier

422 InfoSphere Change Data Capture Management Console: Administration Guide

 Use this system parameter to specify the Oracle SID for the Oracle database
instance that is started by default. Modify this parameter only if you installed
InfoSphere CDC in multiple database instances.

Applies ToSource

Default SettingThe Oracle SID specified when InfoSphere CDC was installed.
Related concepts
System parameters for InfoSphere CDC for Oracle (version 6.2 and earlier) on
page 421

DEFAULT_ORACLE_USER
VersionInfoSphere CDC for Oracle version 6.2 and earlier

Use this system parameter to specify the name of the user for the Oracle database
instance that is started by default. Modify this parameter only if you installed
InfoSphere CDC in multiple database instances.

Applies ToSource

Default SettingThe Oracle user specified when InfoSphere CDC was installed.
Related concepts
System parameters for InfoSphere CDC for Oracle (version 6.2 and earlier) on
page 421

DM_COMMS_HOME
VersionInfoSphere CDC for Oracle version 6.2 and earlier

For information about setting this system parameter, see your IBM representative.

D_MIRROR_HOME
VersionInfoSphere CDC for Oracle version 6.2 and earlier

Use this system parameter to specify the directory (full path) where InfoSphere
CDC is installed on the server.

Applies ToSource and Target

Default SettingThe installation directory specified when InfoSphere CDC was

installed.
Related concepts
System parameters for InfoSphere CDC for Oracle (version 6.2 and earlier) on
page 421

D_MIRROR_LOG
VersionInfoSphere CDC for Oracle version 6.2 and earlier

Use this system parameter to specify the directory (full path) where InfoSphere
CDC log files are located.

System parameters for InfoSphere CDC for Oracle (version 6.2 and earlier) 423
 Applies ToSource and Target

Default SettingThe log subdirectory in the installation directory specified when

installing InfoSphere CDC.
Related concepts
System parameters for InfoSphere CDC for Oracle (version 6.2 and earlier) on
page 421

DM_DYNAMIC_PARAMETER_CHECK_INT
VersionInfoSphere CDC for Oracle version 6.2 and earlier

Use this system parameter to specify how often, in seconds, InfoSphere CDC
checks for changes to the values of dynamic system parameters during active
replication to a subscription. For example, to check once a day, set this parameter
to 216,000.

The following system parameters are dynamic:

v D_MIRROR_TRACE on page 509
v D_MIRROR_TRACE_ON_ERROR on page 510 (on the target only)
v DM_PRINT_DIAGNOSTICS on page 450
v STATISTICS_INTERVAL on page 515
v SYNCHRONIZATION_COMMIT_ GROUP_SIZE on page 507
v SYNCHRONIZATION_INTERVAL on page 508

Applies ToSource and Target

Default Setting300 seconds (5 minutes)

Minimum Setting0. InfoSphere CDC does not check for changes to dynamic
system parameters.

Maximum Setting2,147,483,648 (maximum integer)

Related concepts
System parameters for InfoSphere CDC for Oracle (version 6.2 and earlier) on
page 421

DM_MAX_MONITOR_ENTRIES
VersionInfoSphere CDC for Oracle version 6.2 and earlier

Use this system parameter to increase or decrease the number of subscriptions that
InfoSphere CDC can support in the Monitor in Management Console. InfoSphere
CDC allocates an entry for each source and target datastore within a subscription.
For example, if you have a datastore that is being used as a source datastore
within 20 subscriptions and as a target datastore within 10 subscriptions, then you
must set this system parameter to at least 30. InfoSphere CDC will allocate 30
entries for this datastore.

Applies ToSource

Default Setting20 entries. By default, InfoSphere CDC can handle 20

subscriptions.

424 InfoSphere Change Data Capture Management Console: Administration Guide

 Minimum Setting1 entry

Maximum Setting1000 entries

DM_TS_MAX_POOL_SIZE_MB
VersionInfoSphere CDC for Oracle version 6.2 and earlier

Use this system parameter when you need to resize the staging store component of
InfoSphere CDC. You can specify a value in megabytes (MB). After specifying the
size of the staging store, you should specify the number of blocks you want
InfoSphere CDC to create using the DM_TS_POOL_BLOCK_SIZE_MB system parameter.

Applies ToSource

This setting must be large enough to store data for the largest predicted transaction
that occurs in the Oracle database. If the size of the active staging store is not large
enough to accommodate all data, InfoSphere CDC issues an error message
(Message ID 307) in the event log and shuts down. The staging store size should
be at least 150% of the largest predicted transaction.

Note: After changing the value of this parameter, you must set the journal position
to the last applied position by running the setjrnpos command.

Default Setting25% of the default setting for the RLD_SYSTEM_TXQSIZE system

parameter which is 128 MB.

For more information about the setjrnpos command, see the "setjrnposSet
journal position in the commands" section of the InfoSphere CDC for Oracle End-User
Documentation.

To set the journal position, see "Running the Bookmark Viewer Command and
Setting the Journal Position on the Source" in the "Installing InfoSphere CDC"
section of the InfoSphere CDC for Oracle End-User Documentation.
Related reference
DM_TS_POOL_BLOCK_SIZE_MB
RLD_SYSTEM_TXQSIZE on page 429

DM_TS_POOL_BLOCK_SIZE_MB
VersionInfoSphere CDC for Oracle version 6.2 and earlier

Use this system parameter when you are in the process of resizing the staging
store component of InfoSphere CDC and need to specify a block size you want
InfoSphere CDC to create for the staging store. You must have already specified
the size of the staging store (in MB) using the DM_TS_MAX_POOL_SIZE_MB system
parameter.

The value you specify for DM_TS_POOL_BLOCK_SIZE_MB indicates the block size you
want InfoSphere CDC to create for the staging store. The size you had specified
with the DM_TS_MAX_POOL_SIZE_MB system parameter is adjusted based on the block
size you specify.

Applies ToSource

System parameters for InfoSphere CDC for Oracle (version 6.2 and earlier) 425
 Default SettingNone. If you do not specify a block size for this system
parameter, then InfoSphere CDC will create a maximum of 4 blocks (no larger than
20 MB each) of space for the staging store. For example, you may have specified
100 MB for the staging store using the DM_TS_MAX_POOL_SIZE_MB system parameter.
In this scenario, InfoSphere CDC will create a maximum 5 blocks of 20 MB each.
Related reference
DM_TS_MAX_POOL_SIZE_MB on page 425

<subscription>_MAX_POOL_SIZE_MB
VersionInfoSphere CDC for Oracle version 6.2 and earlier

Use this system parameter when you want to resize the staging store for a specific
subscription. You can specify a value in megabytes (MB). After specifying the size
of the staging store, you should specify the block size you want InfoSphere CDC to
create using the <subscription>_POOL_BLOCK_SIZE_MB system parameter.

Applies ToSource

Default Setting--25% of the default setting for the RLD_SYSTEM_TXQSIZE system

parameter which is 128 MB.

This setting must be large enough to store data for the largest predicted transaction
that occurs in the Oracle database. If the size of the active staging store is not large
enough to accommodate all data, InfoSphere CDC issues an error message
(Message ID 307) in the event log and shuts down. The staging store size should
be at least 150% of the largest predicted transaction.

Note: After changing the value of this parameter, you must set the journal position
to the last applied position by running the setjrnpos command.

For more information about the setjrnpos command, see the "setjrnposSet
journal position in the commands" section of the InfoSphere CDC for Oracle End-User
Documentation.

To set the journal position, see "Running the Bookmark Viewer Command and
Setting the Journal Position on the Source" in the "Installing InfoSphere CDC"
section of the InfoSphere CDC for Oracle End-User Documentation.
Related reference
RLD_SYSTEM_TXQSIZE on page 429
<subscription>_POOL_BLOCK_SIZE_MB

<subscription>_POOL_BLOCK_SIZE_MB
VersionInfoSphere CDC for Oracle version 6.2 and earlier

Use this system parameter when you are in the process of resizing the staging
store component for a specific subscription and need to specify a block size you
want InfoSphere CDC to create for the staging store. You must have already
specified the size of the staging store (in MB) using the
<subscription>_TS_POOL_BLOCK_SIZE_MB system parameter.

The value you specify for <subscription>_TS_POOL_BLOCK_SIZE_MB indicates the

block size you want InfoSphere CDC to create for the staging store. The size you

426 InfoSphere Change Data Capture Management Console: Administration Guide

 had specified with the <subscription>_TS_POOL_BLOCK_SIZE_MB system parameter is
adjusted based on the block size you specify.

Applies ToSource

Default SettingNone. If you do not specify a block size for this system
parameter, then InfoSphere CDC will create a maximum of 4 blocks (no larger than
20 MB each) of space for the staging store. For example, you may have specified
100 MB for the staging store using the <subscription>_TS_POOL_BLOCK_SIZE_MB
system parameter. In this scenario, InfoSphere CDC will create a maximum 5
blocks of 20 MB each.
Related reference
<subscription>_MAX_POOL_SIZE_MB on page 426

LD_LIBRARY_PATH
VersionInfoSphere CDC for Oracle version 6.2 and earlier

Use this system parameter to specify the path to the InfoSphere CDC libraries and
the database libraries for Solaris and Linux operating systems. This value is set
during installation and should not be modified.

Applies ToSource and Target

Default SettingThe path to the InfoSphere CDC libraries and the Oracle libraries
when InfoSphere CDC was installed
Related concepts
System parameters for InfoSphere CDC for Oracle (version 6.2 and earlier) on
page 421

LIBPATH
VersionInfoSphere CDC for Oracle version 6.2 and earlier

Use this system parameter to specify the path to the InfoSphere CDC libraries and
the database libraries (for AIX operating systems). This value is set during
installation and should not be modified.

Applies ToSource and Target

Default SettingThe path to the InfoSphere CDC libraries and the database
libraries when InfoSphere CDC was installed.
Related concepts
System parameters for InfoSphere CDC for Oracle (version 6.2 and earlier) on
page 421

ORACLE_HOME
VersionInfoSphere CDC for Oracle version 6.2 and earlier

Use this system parameter to specify the Oracle home directory.

Applies ToSource

System parameters for InfoSphere CDC for Oracle (version 6.2 and earlier) 427
 Default SettingThe Oracle home directory specified when InfoSphere CDC was
installed.
Related concepts
System parameters for InfoSphere CDC for Oracle (version 6.2 and earlier) on
page 421

ORACLE_SID
VersionInfoSphere CDC for Oracle version 6.2 and earlier

Use this system parameter to specify the Oracle SID.

Applies ToSource

Default SettingThe Oracle SID specified when InfoSphere CDC was installed.
Related concepts
System parameters for InfoSphere CDC for Oracle (version 6.2 and earlier) on
page 421

PASSWORD
VersionInfoSphere CDC for Oracle version 6.2 and earlier

Use this system parameter to identify the encrypted database password, which can
be set using the dmsetpass command. For information about dmsetpass, see
dmsetpassSet Password in the Commands section of the InfoSphere CDC for
Oracle documentation for version 6.2 and below.

Applies ToSource

This parameter was set during installation and should not be modified.
Related concepts
System parameters for InfoSphere CDC for Oracle (version 6.2 and earlier) on
page 421

PUBLISH_METADATA
VersionInfoSphere CDC for Oracle version 6.2 and earlier

Use this system parameter to enable or disable the display of InfoSphere CDC
metadata tables in Management Console.

Applies ToSource

Set this parameter to one of the following:

v OFFInfoSphere CDC metadata tables are not displayed in Management
Console.
v ONInfoSphere CDC metadata tables are displayed in the Add/Remove Tables
dialog box, making them available to be selected for replication.

Default SettingOFF

428 InfoSphere Change Data Capture Management Console: Administration Guide

 Related concepts
System parameters for InfoSphere CDC for Oracle (version 6.2 and earlier) on
page 421

RLD_SYSTEM_TXQSIZE
VersionInfoSphere CDC for Oracle version 6.2 and earlier

Use this system parameter to specify the size, in megabytes (MB), for the active
transaction queue store maintained by InfoSphere CDC. The active transaction
queue store contains data for concurrent transactions that have been extracted from
the Oracle redo log.

Applies ToSource

This setting must be large enough to store data for all concurrent transactions that
occur in the Oracle database. If the size of the active transaction queue store is not
large enough to accommodate all data, InfoSphere CDC issues an error message
and shuts down.

Default Setting128 MB

Minimum Setting5 MB
Related concepts
System parameters for InfoSphere CDC for Oracle (version 6.2 and earlier) on
page 421

<subscription>_TXQSIZE
VersionInfoSphere CDC for Oracle version 6.2 and earlier

Use this system parameter to specify the size, in megabytes (MB), you want to
allocate per subscription for the active transaction queue store. This area represents
the amount of space required to store data for a single transaction, extracted from
the Oracle redo log.

This system parameter is useful when you want to allocate a specific amount of
queue storage for a specific subscription you have added in InfoSphere CDC
Management Console. If you want all other subscriptions to use the same storage
size, then use the RLD_SYSTEM_TXQSIZE to allocate queue storage size.

Applies ToSource

Default SettingThere is no default value for this system parameter. If you decide
not to specify a value in megabytes for this system parameter, then InfoSphere
CDC will use the value you specified for the RLD_SYSTEM_TXQSIZE system
parameter.

Notes:
v The subscription name precedes the name of the system parameter (TXQSIZE).
For example, sub1TXQSIZE.
v The name of the system parameter is not case-sensitive. If you have added two
subscriptions in Management Console named SUB1 and sub1, then both
subscriptions will use the same value specified for the system parameter.

System parameters for InfoSphere CDC for Oracle (version 6.2 and earlier) 429
 v This system parameter applies only to the Redo Log edition of InfoSphere CDC
for Oracle.
Related concepts
System parameters for InfoSphere CDC for Oracle (version 6.2 and earlier) on
page 421
Related reference
RLD_SYSTEM_TXQSIZE on page 429

SHLIB_PATH
VersionInfoSphere CDC for Oracle version 6.2 and earlier

Use this system parameter to specify the path to the InfoSphere CDC libraries and
the database libraries for HP-UX operating systems. This value is set during
installation and should not be modified.

Applies ToSource and Target

Default SettingThe path to the InfoSphere CDC libraries and the database
libraries when InfoSphere CDC was installed.
Related concepts
System parameters for InfoSphere CDC for Oracle (version 6.2 and earlier) on
page 421

STARTUP_TIMEOUT
VersionInfoSphere CDC for Oracle version 6.2 and earlier

Use this system parameter to specify the maximum waiting period, in seconds, for
process handling to complete during InfoSphere CDC startup. It indicates how
long the InfoSphere CDC communication module waits for the database
initialization program to start before timing out.

Applies ToSource and Target. Target only for InfoSphere CDC for Teradata.

Default Setting120

Minimum Setting60

Maximum Setting3600
Related concepts
System parameters for InfoSphere CDC for Oracle (version 6.2 and earlier) on
page 421

TCP_KEEPALIVE_SECS
VersionInfoSphere CDC for Oracle version 6.2 and earlier

Use this parameter to specify the time interval, during idle periods, to wait before
sending a keep alive message over the network. If a connection is idle for the
specified time interval, InfoSphere CDC sends a keep alive message to keep the
connection open.

430 InfoSphere Change Data Capture Management Console: Administration Guide

 Applies ToSource and Target

Setting this system parameter is needed in environments that have firewalls with
timeout connection values, to prevent them from closing the connection. Set this
parameter to a value lower than the firewall timeout, so that the firewall does not
close the connection during data replication.

To set this system parameter, do the following:

1. Create a file named dmcommparms.cfg in the <InfoSphere CDC install dir>/lib
directory.
2. Insert the following line in the file:
TCP_KEEPALIVE_SECS = <value>;
where value is the setting for this system parameter. For example, to set to 1
minute, enter:
TCP_KEEPALIVE_SECS = 60;

Default Setting300 seconds (5 min)

Minimum Setting0
Related concepts
System parameters for InfoSphere CDC for Oracle (version 6.2 and earlier) on
page 421

USER
VersionInfoSphere CDC for Oracle version 6.2 and earlier

Use this system parameter to specify the Oracle user name that was specified
during installation. You can also set this user using the dmsetpass command. For
information about dmsetpass, see the dmsetpassSet Password in the Commands
section of the InfoSphere CDC for Oracle documentation for version 6.2 and earlier.

Applies ToSource

Default SettingThe InfoSphere CDC user specified when InfoSphere CDC was
installed.
Related concepts
System parameters for InfoSphere CDC for Oracle (version 6.2 and earlier) on
page 421

Apply process system parameters

Some system parameters adjust the way InfoSphere CDC applies rows, column
data, and error handling.

See also:
convertNotNullableColumns on page 432
D_MIRROR_MIRROR_ERROR_LIST on page 432
D_MIRROR_MIRROR_ERROR_STOP on page 433
D_MIRROR_REFRESH_ERROR_LIST on page 433
D_MIRROR_REFRESH_ERROR_STOP on page 434
DM_ADAPTIVE_APPLY_SOFT_DELETES on page 434

System parameters for InfoSphere CDC for Oracle (version 6.2 and earlier) 431
 DM_ADAPTIVE_APPLY_<SCHEMA>.<TABLENAME> on page 435
DM_ADAPTIVE_APPLY_MIMIC_SOURCE_OPERATION on page 435
DM_ARRAY_BIND_MAX on page 436
FILTER_NOCHANGE_UPDATES_FOR_AUDIT on page 436
NLS_LANG on page 437
NLS_NCHAR on page 437
NOT_NULL_DATE_DEFAULT on page 437
TRIM_CHAR_TO_VARCHAR on page 437
TRIM_VARCHAR_TO_VARCHAR on page 438
TRIM_TO_NULL on page 438
UNICODE_HANDLING on page 439

convertNotNullableColumns
VersionInfoSphere CDC for Oracle version 6.2 and earlier

Use this system parameter to indicate whether or not NULL values will be
converted to default values when replicating data that contains NULL values to
non-nullable target columns.

Applies ToTarget

Set this parameter to one of the following:

v OFFAn error message will be generated in Event Log. Replication will
continue or not based on whether the MirrorError or RefreshError system
parameters are set to END or ON.
v ONInfoSphere CDC will automatically insert an appropriate default value in
the target column. No error message is generated in Event Log and replication
continues.
Depending on the convertNotNullableMsg system parameter setting, a warning
message may be generated in Event Log.
The default value depends on the data type of the subscription column. For
example, zero for numeric data types, blank character for character data types,
1901-01-01 for date data types, and so on.

Default SettingOFF
Related concepts
System parameters for InfoSphere CDC for Oracle (version 6.2 and earlier) on
page 421
Related reference
D_MIRROR_MIRROR_ERROR_STOP on page 433
D_MIRROR_REFRESH_ERROR_STOP on page 434
convertNotNullableMsg on page 457

D_MIRROR_MIRROR_ERROR_LIST
VersionInfoSphere CDC for Oracle version 6.2 and earlier

Use this system parameter to allow certain errors to be ignored during mirroring.

432 InfoSphere Change Data Capture Management Console: Administration Guide

 Applies ToTarget

If the D_MIRROR_MIRROR_ERROR_STOP on page 499 system parameter is set

to ON, use this parameter to allow certain errors to be ignored during mirroring.
The value assigned to this parameter is a comma-delimited list of Oracle or Sybase
database error numbers.

For example, to ignore primary key violations, but to stop mirroring on any other
update errors, set D_MIRROR_MIRROR_ERROR_LIST=1. This value corresponds to the
Oracle error "ORA-00001: unique constraint violated (<schema>.<constraint>)".
Related concepts
System parameters for InfoSphere CDC for Oracle (version 6.2 and earlier) on
page 421
Related reference
D_MIRROR_MIRROR_ERROR_STOP

D_MIRROR_MIRROR_ERROR_STOP
VersionInfoSphere CDC for Oracle version 6.2 and earlier

Use this parameter to indicate whether or not mirroring continues after an error
has occurred during a row insert, delete, or update operation.

Applies ToTarget

Set this parameter to one of the following:

v ONMirroring stops after an error has occurred.
v OFFMirroring continues after an error has occurred.

Default SettingON
Related concepts
System parameters for InfoSphere CDC for Oracle (version 6.2 and earlier) on
page 421
Related reference
D_MIRROR_MIRROR_ERROR_LIST on page 432

D_MIRROR_REFRESH_ERROR_LIST
VersionInfoSphere CDC for Oracle version 6.2 and earlier

Use this system parameter to allow certain errors to be ignored during data
refresh.

Applies ToTarget

If the D_MIRROR_REFRESH_ERROR_STOP on page 499 system parameter is set

to ON, use this parameter to allow certain errors to be ignored during data refresh.
The value assigned to this parameter is a comma-delimited list of Oracle or Sybase
database error numbers.

For example, to ignore primary key violations, but to stop refresh on any other
update errors, set D_MIRROR_REFRESH_ERROR_LIST=1. This value corresponds to the
Oracle error "ORA-00001: unique constraint violated (<schema>.<constraint>)".

System parameters for InfoSphere CDC for Oracle (version 6.2 and earlier) 433
 Related concepts
System parameters for InfoSphere CDC for Oracle (version 6.2 and earlier) on
page 421
Related reference
D_MIRROR_MIRROR_ERROR_STOP on page 433

D_MIRROR_REFRESH_ERROR_STOP
VersionInfoSphere CDC for Oracle version 6.2 and earlier

Use this system parameter to indicate whether or not InfoSphere CDC should
continue to perform a refresh after encountering an error during a row insert
operation.

Applies ToTarget

Set this parameter to one of the following:

v ONData refresh stops after an error has occurred.
v OFFData refresh continues after an error has occurred.

Default SettingON
Related concepts
System parameters for InfoSphere CDC for Oracle (version 6.2 and earlier) on
page 421
Related reference
D_MIRROR_REFRESH_ERROR_LIST on page 433

DM_ADAPTIVE_APPLY_SOFT_DELETES
VersionInfoSphere CDC for Oracle version 6.2 and earlier

Use this system parameter to enable InfoSphere CDC to apply a soft delete on all
target tables mapped using Adaptive Apply in a subscription.

Applies ToTarget

Set this parameter to one of the following:

v ONWhen there is a delete on the source table, InfoSphere CDC either:
updates the rows on all target tables if the rows exist, or
inserts the rows on all target tables if the rows do not exist.
v OFFWhen there is a delete on the source table, InfoSphere CDC either:
deletes the rows on all target tables if the rows exist, or
does nothing and issues an informational message in the Event log if the
rows do not exist.

434 InfoSphere Change Data Capture Management Console: Administration Guide

 Related concepts
System parameters for InfoSphere CDC for Oracle (version 6.2 and earlier) on
page 421
Enabling the apply of soft deletes (InfoSphere CDC for Oracle) on page 304

DM_ADAPTIVE_APPLY_<SCHEMA>.<TABLENAME>
VersionInfoSphere CDC for Oracle version 6.2 and earlier

Use this system parameter to enable InfoSphere CDC to apply a soft delete on a
specific target table mapped using Adaptive Apply in a subscription.

Applies ToTarget

Set this parameter to one of the following:

v ONWhen there is a delete on the source table, InfoSphere CDC either:
updates the row on the target table if the row exists, or
inserts the row on the target table if it does not exist.
v OFFWhen there is a delete on the source table, InfoSphere CDC either:
deletes the row on the target table if the row exists, or
does nothing and issues an informational message in the Event log if the row
does not exist.
Related concepts
System parameters for InfoSphere CDC for Oracle (version 6.2 and earlier) on
page 421
Enabling the apply of soft deletes (InfoSphere CDC for Oracle) on page 304

DM_ADAPTIVE_APPLY_MIMIC_SOURCE_OPERATION
VersionInfoSphere CDC for Oracle version 6.2 and earlier

Use this system parameter to modify the how InfoSphere CDC applies data to the
target when you have mapped your source and target tables using Adaptive
Apply. If you enable this system parameter, InfoSphere CDC avoids performing a
SELECT query on the target table and you may benefit with performance
improvement.

For information about setting this system parameter, see your IBM representative.

Applies ToTarget

Set this parameter to one of the following:

v ONInfoSphere CDC avoids performing a SELECT query on the target table.
v OFFInfoSphere CDC performs a SELECT query on the target table.

Default SettingOFF

System parameters for InfoSphere CDC for Oracle (version 6.2 and earlier) 435
 Related concepts
System parameters for InfoSphere CDC for Oracle (version 6.2 and earlier) on
page 421

DM_ARRAY_BIND_MAX
VersionInfoSphere CDC for Oracle version 6.2 and earlier

Use this system parameter to specify the maximum number of rows that
InfoSphere CDC can place in an array and apply to the target database. InfoSphere
CDC collects rows and places them in an array (in memory) while receiving
table-level operations from the source system. InfoSphere CDC applies the rows
from the array when there is a change to a different table, when there is a new
table-level operation, or when the maximum number of rows in an array has been
reached.

Applies ToTarget

Default Setting25

Minimum Setting1

Maximum SettingMaximum number of rows (integer)

Guidelines

Before InfoSphere CDC places rows into an array, it allocates memory for the
maximum number of rows you specify and multiplies this integer by the
maximum length of a row. If the maximum number of rows is too large, then
InfoSphere CDC cannot allocate enough memory and will shut down.
Related concepts
System parameters for InfoSphere CDC for Oracle (version 6.2 and earlier) on
page 421

FILTER_NOCHANGE_UPDATES_FOR_AUDIT
VersionInfoSphere CDC for Oracle version 6.2 and earlier

Use this system parameter to indicate whether or not updates that have identical
before and after column images (that is, the row has been updated to the same
value), are replicated to the target table for any tables configured for LiveAudit
replication.

Applies ToSource

Set this parameter to one of the following:

v OFFIf a row in a source table is updated to the same value, InfoSphere CDC
replicates the value to the target table.
v ONIf a row in a source table is updated to the same value, InfoSphere CDC
does not replicate the value to the target table.

This parameter only affects tables that are configured for LiveAudit replication. For
non-audit tables, only updates that change the column data are replicated to the
target tables.

436 InfoSphere Change Data Capture Management Console: Administration Guide

 Default SettingOFF
Related concepts
System parameters for InfoSphere CDC for Oracle (version 6.2 and earlier) on
page 421

NLS_LANG
VersionInfoSphere CDC for Oracle version 6.2 and earlier

Use this system parameter to specify the database character set preceded with a
period. For more information about setting this system parameter, see your IBM
representative.

Applies ToSource and Target

Default SettingThe database character set, preceded with a period,

corresponding to the language selected when the database was installed.
Related concepts
System parameters for InfoSphere CDC for Oracle (version 6.2 and earlier) on
page 421

NLS_NCHAR
VersionInfoSphere CDC for Oracle version 6.2 and earlier

Use this system parameter to set the database national character set.

For information about setting this system parameter, see your IBM representative.

NOT_NULL_DATE_DEFAULT
VersionInfoSphere CDC for Oracle version 6.2 and earlier

Applies ToTarget

Specifies the default value that InfoSphere CDC assigns to a NULL date being
replicated to a non-nullable date column on the target database. If this parameter is
not specified, InfoSphere CDC uses the Default Setting.

Default Setting1901-01-01
Related concepts
System parameters for InfoSphere CDC for Oracle (version 6.2 and earlier) on
page 421
Related reference
TRIM_TO_NULL on page 438

TRIM_CHAR_TO_VARCHAR
VersionInfoSphere CDC for Oracle version 6.2 and earlier

Use this system parameter to specify whether or not trailing blank characters are
trimmed from source columns of CHAR data type when replicating data to target
columns of VARCHAR data type.

System parameters for InfoSphere CDC for Oracle (version 6.2 and earlier) 437
 Applies ToTarget

Set this parameter to one of the following:

v OFFTrailing blanks are not trimmed.
v ONTrailing blanks are trimmed. If TRIM_TO_NULL =OFF, InfoSphere CDC inserts
a single blank character in the target column. If TRIM_TO_NULL =ON and the target
column is nullable, InfoSphere CDC inserts NULL in the column.

Default SettingOFF
Related concepts
System parameters for InfoSphere CDC for Oracle (version 6.2 and earlier) on
page 421
Related reference
TRIM_TO_NULL

TRIM_VARCHAR_TO_VARCHAR
VersionInfoSphere CDC for Oracle version 6.2 and earlier

Use this system parameter to specify whether or not trailing blank characters are
trimmed from source columns of VARCHAR data type when replicating data to
target columns of VARCHAR data type.

Applies ToTarget

Set this parameter to one of the following:

v OFFTrailing blanks are not trimmed.
v ONTrailing blanks are trimmed. If TRIM_TO_NULL =OFF, InfoSphere CDC inserts
a single blank character in the target column. If TRIM_TO_NULL =ON and the target
column is nullable, InfoSphere CDC inserts NULL in the column.

Default SettingOFF
Related concepts
System parameters for InfoSphere CDC for Oracle (version 6.2 and earlier) on
page 421
Related reference
TRIM_TO_NULL

TRIM_TO_NULL
VersionInfoSphere CDC for Oracle version 6.2 and earlier

Use this system parameter to specify how source columns that contain blank
characters only are handled during data replication.

Applies ToTarget

Set this parameter to one of the following:

v OFFFor data mapped to VARCHAR columns, trailing blanks are trimmed or
not to a single blank depending on the TRIM_CHAR_TO_VARCHAR and
TRIM_VARCHAR_TO_VARCHAR system parameters. For data mapped to CHAR
columns, setting this parameter to OFF has no effect.

438 InfoSphere Change Data Capture Management Console: Administration Guide

 v ONFor data mapped to CHAR columns, if the target column is nullable,
InfoSphere CDC inserts NULL in the column. For CHAR data mapped to
VARCHAR columns, if TRIM_CHAR_TO_VARCHAR =ON and the target column is
nullable, InfoSphere CDC inserts NULL in the column. For VARCHAR data
mapped to VARCHAR columns, if TRIM_VARCHAR_TO_VARCHAR =ON and the target
column is nullable, InfoSphere CDC inserts NULL in the column.

If the target column is non-nullable, source columns that contain blank characters
only are handled according to the convertNotNullableColumns system parameter.

The table below explains how the TRIM_ system parameters affect the data
replicated to the target for source columns that contain blank characters only.

TRIM_ parameter settings Target data

TRIM_CHAR_ TO_ TRIM_ VARCHAR_ TRIM_ TO_ CHAR to VARCHAR Any data
VARCHAR TO_ VARCHAR NULL VARCHAR to type to
VARCHAR CHAR
ON ON ON NULL NULL NULL
ON OFF ON NULL Source data NULL
OFF ON ON Source data NULL NULL
OFF OFF ON Source data Source data NULL
ON ON OFF Single blank Single blank Blanks
ON OFF OFF Single blank Source data Blanks
OFF ON OFF Source data Single blank Blanks
OFF OFF OFF Source data Source data Blanks

Default SettingOFF
Related concepts
System parameters for InfoSphere CDC for Oracle (version 6.2 and earlier) on
page 421
Related reference
TRIM_VARCHAR_TO_VARCHAR on page 438
TRIM_CHAR_TO_VARCHAR on page 437

UNICODE_HANDLING
VersionInfoSphere CDC for Oracle version 6.2 and earlier

Use this system parameter to indicate the default method of treating data in
defined Unicode columns. For each InfoSphere CDC installation on a server, this
system parameter defines the system default method of treating data in Unicode
columns. If a Unicode column is set to System Default on the Encoding tab of the
Mapping Details view in Management Console, InfoSphere CDC uses the method
for processing Unicode columns that you select in this system parameter.

Applies ToSource

The following Oracle data types are considered to be Unicode columns, and are
therefore affected by the value assigned to this system parameter:
v NCHAR

System parameters for InfoSphere CDC for Oracle (version 6.2 and earlier) 439
 v NVARCHAR2
v NCLOB

This system parameter is set to either CHAR or NOCHANGE:

v CHARInfoSphere CDC treats all data in Unicode columns as single-byte
characters. Use this setting when Unicode columns contain single-byte character
data.
v NOCHANGEInfoSphere CDC treats all data in Unicode columns as a
continuous bit stream. Use this setting when Unicode columns contain
non-single-byte character data. NOCHANGE ensures InfoSphere CDC will
handle non-single-byte character data in the same way as previous InfoSphere
CDC releases.

Note: If replicating data to a non-Oracle target, NOCHANGE does not ensure that
replicated non-single-byte character data in Unicode columns are represented
properly on the target. For replicated non single-byte character data, you may need
to apply user exit programs or other customizations to properly represent data in
Unicode columns. For more information about user exit programs, see your
InfoSphere CDC for Oracle documentation.

Default SettingNOCHANGE

Note: NOCHANGE does not ensure that replicated non-single-byte character data
in Unicode columns are represented properly on the target. For replicated
non-single-byte character data, you many need to apply user exit programs or
other customization to properly represent the data in Unicode columns.
Related concepts
System parameters for InfoSphere CDC for Oracle (version 6.2 and earlier) on
page 421
Replicating multibyte (MBCS) and double-byte (DBCS) character data on page
163

Cascading replication system parameters

Cascading replication system parameters control InfoSphere CDC cascading
replication.

See also:
CASCADE_OMIT_TARGETS
PREVENT_RECURSION on page 441

CASCADE_OMIT_TARGETS
VersionInfoSphere CDC for Oracle version 6.2 and earlier

Use this system parameter to indicate whether or not cascading replication will be
disabled for specific subscriptions.

Applies ToSource

The value assigned to this parameter is a comma-separated list of subscription

names. Changes applied by InfoSphere CDC are not replicated to these
subscriptions, even if you set the system parameter PREVENT_RECURSION to
OFF. The list of subscriptions cannot exceed 1023 bytes in length.
440 InfoSphere Change Data Capture Management Console: Administration Guide
 Related concepts
System parameters for InfoSphere CDC for Oracle (version 6.2 and earlier) on
page 421
Related reference
PREVENT_RECURSION

PREVENT_RECURSION
VersionInfoSphere CDC for Oracle version 6.2 and earlier

Use this parameter to indicate whether or not to prevent cascading replication for
bidirectional configurations.

Applies ToSource

Set this parameter to one of the following:

v ONChanges applied by InfoSphere CDC are not be replicated back to the
source database from where it came from.
v OFFChanges made by InfoSphere CDC are replicated, except when filtered out
by the CASCADE_OMIT_TARGETS system parameter.

Default SettingON
Related concepts
System parameters for InfoSphere CDC for Oracle (version 6.2 and earlier) on
page 421
Related reference
CASCADE_OMIT_TARGETS on page 440

Database journal (trigger) system parameters

Database journal or trigger system parameters let you manage the InfoSphere CDC
journal table.

See also:
REPORT_POSITION_INTERVAL
MONITOR_PURGE_INTERVAL on page 442
MONITOR_REFRESH_PERIOD on page 442

REPORT_POSITION_INTERVAL
VersionInfoSphere CDC for Oracle version 6.2 and earlier

Use this system parameter to specify how often (in seconds) the source informs the
target about its position in the current journal during times of no activity. During
times of no activity, when there are no journal entries to be processed pertaining to
the current subscription, the source informs the target of its current position so that
the target can advance its bookmarks accordingly. By specifying a low setting for
this parameter, the target can reflect more accurately how far replication has
progressed.

Applies ToSource

System parameters for InfoSphere CDC for Oracle (version 6.2 and earlier) 441
 After a shutdown and restart, you can use this system parameter to prevent
InfoSphere CDC from rereading entries that do not apply to the current replication
configuration.

The value of this parameter affects the information that is displayed in progress
and bookmark messages. A high value for this parameter may result in
information that is not up-to-date being displayed.

Default Setting5

Minimum Setting1

Maximum Setting300
Related concepts
System parameters for InfoSphere CDC for Oracle (version 6.2 and earlier) on
page 421

MONITOR_PURGE_INTERVAL
VersionInfoSphere CDC for Oracle version 6.2 and earlier

Use this system parameter to specify the time interval between journal purges.
When this time interval has elapsed, InfoSphere CDC removes from its journals all
records that have been committed on all targets to which they are replicated.

Applies ToSource

Specify this parameter in the format #h#m#s, where # is the number of hours,
minutes, and seconds, respectively. For example, 1h30m represents 1 hour and 30
minutes. If a time specification value is 0, you can omit it.

Default Setting1h

Minimum Setting1m
Related concepts
System parameters for InfoSphere CDC for Oracle (version 6.2 and earlier) on
page 421

MONITOR_REFRESH_PERIOD
VersionInfoSphere CDC for Oracle version 6.2 and earlier

Use this parameter to specify the time interval between journal polls. InfoSphere
CDC performs journal polls to check for new changes on the source.

Applies ToSource

Note: If you replicate large volumes of data, set this parameter to its minimum
value so that InfoSphere CDC checks for changes more frequently.

Specify this parameter in the format #h#m#s, where # is the number of hours,
minutes, and seconds, respectively. For example, 1h30m represents 1 hour and 30
minutes. If a time specification value is 0, you can omit it.

442 InfoSphere Change Data Capture Management Console: Administration Guide

 Default Setting5s

Minimum Setting1s
Related concepts
System parameters for InfoSphere CDC for Oracle (version 6.2 and earlier) on
page 421

Maximize throughput system parameters

InfoSphere CDC system parameters allow you to significantly reduce the workload
of the target database during mirroring. The InfoSphere CDC apply process groups
transactions on the target to reduce the workload. Every commit on the target
database will correspond with a commit on the target. However, it may not
perform every commit that was done on the source. For example, if the source
does three small transactions containing one operation each, the target may commit
all three operations as part of a single transaction. You can use this grouping of
system parameters to significantly reduce the resources required by the target
database. The default settings are appropriate for most databases, but if your target
system has limited resources and an increase in latency is acceptable, you can
adjust the settings appropriately.

See also:
COMMIT_GROUP_SIZE
COMMIT_LEVEL on page 444
COMMIT_INTERVAL on page 444
MAINTAIN_TRANSACTION_CONSISTENCY on page 445
SYNCHRONIZATION_COMMIT_ GROUP_SIZE on page 445
SYNCHRONIZATION_INTERVAL on page 446
TRANSACTION_GROUP_SIZE on page 446
TRANSACTION_INTERVAL on page 447
TRANSACTION_RECORDS_THRESHOLD on page 447

COMMIT_GROUP_SIZE
VersionInfoSphere CDC for Oracle version 6.2 and earlier

Use this system parameter to specify the minimum number of rows InfoSphere
CDC should apply to the database before a commit is issued. InfoSphere CDC
issues a commit on the target when the transaction that contains the rows
completes.

Use the COMMIT_GROUP_SIZE and COMMIT_INTERVAL system parameters together.

InfoSphere CDC issues a commit when either when the number of rows specified
by COMMIT_GROUP_SIZE has been applied to the target, or when the time interval
specified by COMMIT_INTERVAL has elapsed. Setting only one of these system
parameters without the other can result in uncommitted data on the target.

Applies ToTarget

Default Setting5000

Minimum Setting0. InfoSphere CDC does not use commit groups to apply data
to the target.

System parameters for InfoSphere CDC for Oracle (version 6.2 and earlier) 443
 Guidelines

Set this parameter to 0 if D_MIRROR_MIRROR_ERROR_STOP=OFF. If a rollback occurs,

InfoSphere CDC rolls back all outstanding rows in the commit group. Since
InfoSphere CDC is set to continue on error, you may lose data.

Note: Use this parameter only if InfoSphere CDC is not running under
commitment control (COMMIT_LEVEL =0).

COMMIT_LEVEL
VersionInfoSphere CDC for Oracle version 6.2 and earlier

Use this system parameter to indicate the level of commitment control for
InfoSphere CDC to process transactions.

Applies ToTarget

Set this parameter to one of the following:

v 0Disables commitment control for transaction processing. No attempt to
maintain transaction consistency is performed in the event that replication is
interrupted.
v 2When replication is interrupted, updates in a transaction that is partially
applied on the source and target databases will be rolled back to the last
transaction that was successfully committed. This level of commitment control
provides true transaction consistency, and ensures that a transaction will not be
partially applied on the target database. Replication resumes after the last
transaction that was successfully committed.
Related concepts
System parameters for InfoSphere CDC for Oracle (version 6.2 and earlier) on
page 421

COMMIT_INTERVAL
VersionInfoSphere CDC for Oracle version 6.2 and earlier

Use this system parameter to specify the time interval between commits, in
seconds, to limit the number of commits InfoSphere CDC issues on the target
database. Use the COMMIT_GROUP_SIZE and COMMIT_INTERVAL system parameters
together. InfoSphere CDC issues a commit when either when the number of rows
specified by COMMIT_GROUP_SIZE has been applied to the target, or when the time
interval specified by COMMIT_INTERVAL has elapsed. Setting only one of these system
parameters without the other can result in uncommitted data on the target.

When the COMMIT_INTERVAL time expires, InfoSphere CDC issues a commit on the
target database for transactions that completed within that time interval.

Applies ToTarget

Default Setting60

Minimum Setting0. InfoSphere CDC issues a commit on a target database for

each completed transaction.

444 InfoSphere Change Data Capture Management Console: Administration Guide

 Guidelines

Set this parameter to 0 if D_MIRROR_MIRROR_ERROR_STOP=OFF. If a rollback occurs,

InfoSphere CDC rolls back all outstanding rows in the commit group. Since
InfoSphere CDC is set to continue on error, you may lose data.

Note: Use this parameter only if InfoSphere CDC is not running under
commitment control (COMMIT_LEVEL =0).
Related concepts
System parameters for InfoSphere CDC for Oracle (version 6.2 and earlier) on
page 421
Related reference
COMMIT_LEVEL on page 444
COMMIT_GROUP_SIZE on page 505
D_MIRROR_MIRROR_ERROR_STOP on page 433

MAINTAIN_TRANSACTION_CONSISTENCY
VersionInfoSphere CDC for Oracle version 6.2 and earlier

Use this system parameter to Indicate whether or not to maintain commitment

control.

Applies ToSource

Set this parameter to one of the following:

v OFFCommitment control is disabled. In this case, the COMMIT_LEVEL
system parameter is treated as 0.
v ONCommitment control is enabled. In this case, the COMMIT_LEVEL system
parameter must be 0 or 2.

Note: To enable commitment control, you must set

MAINTAIN_TRANSACTION_CONSISTENCY=ON and COMMIT_LEVEL=2
before configuring any tables for mirroring.

Default SettingOFF
Related concepts
System parameters for InfoSphere CDC for Oracle (version 6.2 and earlier) on
page 421
Related reference
COMMIT_LEVEL on page 444

SYNCHRONIZATION_COMMIT_ GROUP_SIZE
VersionInfoSphere CDC for Oracle version 6.2 and earlier

Use this system parameter to specify the number of transactions applied to the
database before InfoSphere CDC performs synchronization between the source and
target.

Applies ToSource and Target

System parameters for InfoSphere CDC for Oracle (version 6.2 and earlier) 445
 The SYNCRONIZATION_COMMIT_GROUP_SIZE and SYNCHRONIZATION_INTERVAL system
parameters are intended to be used together. Synchronization occurs either when
the number of transactions (specified by SYNCRONIZATION_COMMIT_GROUP_SIZE) have
been applied or when the time interval (specified by SYNCHRONIZATION_INTERVAL)
has elapsed, whichever comes first.

Default Setting128

Minimum Setting0. InfoSphere CDC does not use commit groups to perform
synchronization.

Maximum Setting2,147,483,648 (maximum integer)

DynamicYes
Related concepts
System parameters for InfoSphere CDC for Oracle (version 6.2 and earlier) on
page 421
Related reference
SYNCHRONIZATION_INTERVAL

SYNCHRONIZATION_INTERVAL
VersionInfoSphere CDC for Oracle version 6.2 and earlier

Use this system parameter to specify the interval, in seconds, at which

synchronization is performed between the source and target. Synchronization is
achieved when the target reports to the source the position of the last committed
change.

Applies ToSource

The SYNCRONIZATION_INTERVAL and SYNCHRONIZATION_COMMIT_ GROUP_SIZE system

parameters are intended to be used together. Synchronization occurs either when
the number of transactions (specified by SYNCHRONIZATION_COMMIT_ GROUP_SIZE )
have been applied or when the time interval (specified by
SYNCRONIZATION_INTERVAL) has elapsed, whichever comes first.

Default Setting1

Minimum Setting1

Maximum Setting300

DynamicYes
Related concepts
System parameters for InfoSphere CDC for Oracle (version 6.2 and earlier) on
page 421
Related reference
SYNCHRONIZATION_COMMIT_ GROUP_SIZE on page 445

TRANSACTION_GROUP_SIZE
VersionInfoSphere CDC for Oracle version 6.2 and earlier

446 InfoSphere Change Data Capture Management Console: Administration Guide

 Use this system parameter to specify the number of complete transactions applied
to the database before InfoSphere CDC issues a commit. Use the
TRANSACTION_GROUP_SIZE, TRANSACTION_INTERVAL, and
TRANSACTION_RECORDS_THRESHOLDS system parameters together. InfoSphere CDC
issues a commit after applying the number of transactions specified by the
TRANSACTION_GROUP_SIZE, or when the time interval specified by
TRANSACTION_INTERVAL has elapsed. Setting only one of these system parameters
without the other can result in uncommitted transactions on the target.

Applies ToTarget

Default Setting500

Minimum Setting0

Guidelines

To increase the throughput, set to a number of transactions that would be received

when busy during the TRANSACTION_INTERVAL.

Note: Use this parameter only if InfoSphere CDC is running under commitment
control. The COMMIT_LEVEL system parameter should be set to2 on the target
database, and the MAINTAIN_TRANSACTION_CONSISTENCY system parameter should be
set to ON on the source database.

TRANSACTION_INTERVAL
VersionInfoSphere CDC for Oracle version 6.2 and earlier

Use this system parameter to specify the time interval, in seconds, that can elapse
between transactions before InfoSphere CDC issues a commit. If there are no
transactions received by the target system, then InfoSphere CDC issues a commit
immediately. Use this system parameter with the TRANSACTION_GROUP_SIZE system
parameter. InfoSphere CDC issues a commit after applying the number of
transactions specified by the TRANSACTION_GROUP_SIZE system parameter, or when
the time interval specified by TRANSACTION_INTERVAL system parameter has elapsed.
Setting only one of these system parameters without the other can result in
uncommitted transactions on the target.

Applies ToTarget

Default Setting1

Minimum Setting0

Guidelines

InfoSphere CDC issues a commit only when a commit is received by the target
system and you have reached the transaction group size, or exceeded the time
interval, or exceeded the records threshold.

TRANSACTION_RECORDS_THRESHOLD
VersionInfoSphere CDC for Oracle version 6.2 and earlier

System parameters for InfoSphere CDC for Oracle (version 6.2 and earlier) 447
 Use this system parameter to specify the maximum number of operations within a
transaction or group of transactions before InfoSphere CDC issues a commit

Applies ToTarget

Default Setting3000

Minimum Setting0

Tracing system parameters

Tracing system parameters let you perform diagnostic activities with InfoSphere
CDC.

See also:
D_MIRROR_SP_TRACE
D_MIRROR_TRACE
D_MIRROR_TRACE_FILE_SIZE on page 449
D_MIRROR_TRACE_ON_ERROR on page 449
DM_PRINT_DIAGNOSTICS on page 450
D_MIRROR_ALARM_TRACE on page 450

D_MIRROR_SP_TRACE
VersionInfoSphere CDC for Oracle version 6.2 and earlier

Use this system parameter to enable tracing for your stored procedure user exit.

Applies ToTarget

Set this parameter to one of the following:

v OFFTracing is disabled.
v ONTracing is enabled and InfoSphere CDC creates the appropriate trace files
in the log directory. These trace files are not encrypted. It is a plain ASCII text
file and can be read directly for troubleshooting purposes.

Default SettingOFF

DynamicNo

D_MIRROR_TRACE
VersionInfoSphere CDC for Oracle version 6.2 and earlier

Use this system parameter to indicate whether or not tracing is enabled.

Applies ToSource and Target

Set this parameter to one of the following:

v OFFTracing is disabled. This setting has no effect when
D_MIRROR_TRACE_ON_ERROR=ON.

448 InfoSphere Change Data Capture Management Console: Administration Guide

 v ONTracing is enabled and InfoSphere CDC creates the appropriate trace files
in the log directory. These trace files are encrypted, and are meant to be sent to
IBM technical support for troubleshooting purposes.

When enabling this setting, also set the size of the trace file to an appropriate
value using the D_MIRROR_TRACE_FILE_SIZE system parameter. To avoid disk space
problems, set the size of the trace file to a value that is not too high.

Default SettingOFF

DynamicYes
Related concepts
System parameters for InfoSphere CDC for Oracle (version 6.2 and earlier) on
page 421
Related reference
D_MIRROR_TRACE_FILE_SIZE
D_MIRROR_LOG on page 423
DIRPATH_LOGGING on page 454
D_MIRROR_ALARM_TRACE on page 450

D_MIRROR_TRACE_FILE_SIZE
VersionInfoSphere CDC for Oracle version 6.2 and earlier

Use this system parameter to specify the maximum size of a trace file in bytes.
InfoSphere CDC creates two trace files. When the first trace file reaches its
maximum size, InfoSphere CDC creates a second file. When the second trace file
reaches its maximum size, InfoSphere CDC starts overwriting the first file.

Applies ToSource and Target

Default Setting10,000,000 bytes

Minimum Setting1,000,000 bytes

Related concepts
System parameters for InfoSphere CDC for Oracle (version 6.2 and earlier) on
page 421

D_MIRROR_TRACE_ON_ERROR
VersionInfoSphere CDC for Oracle version 6.2 and earlier

Use this system parameter to specify whether or not InfoSphere CDC enables
tracing automatically when an error occurs.

Applies ToSource and Target

Set this parameter to one of the following:

v OFFInfoSphere CDC does not enable tracing when an error occurs.
v ONInfoSphere CDC enables tracing when an error occurs. InfoSphere CDC
creates the appropriate trace files in the InfoSphere CDC log directory. These
trace files are encrypted, and are meant to be sent to IBM technical support for
troubleshooting purposes.
System parameters for InfoSphere CDC for Oracle (version 6.2 and earlier) 449
 When enabling this setting, also set the size of the trace file to an appropriate
value using the D_MIRROR_TRACE_FILE_SIZE system parameter. To avoid disk space
problems, set the size of the trace file to a value that is not too high.

Default SettingOFF

DynamicYes (on the target only)

Related concepts
System parameters for InfoSphere CDC for Oracle (version 6.2 and earlier) on
page 421
Related reference
D_MIRROR_TRACE_FILE_SIZE on page 449

DM_PRINT_DIAGNOSTICS
VersionInfoSphere CDC for Oracle version 6.2 and earlier

Use this system parameter to Indicate whether or not to generate diagnostic

messages in the InfoSphere CDC log files.

Applies ToSource

Set this parameter to one of the following:

v OFFDiagnostic messages will not be generated.
v ONDiagnostic messages will be generated.

Note: If you enable tracing, it may cause large trace files to be created, which
can consume a large amount of disk space and affect performance. To avoid
running into disk space shortage problems, use this parameter only if advised
by IBM technical support.

Default SettingOFF
Related concepts
System parameters for InfoSphere CDC for Oracle (version 6.2 and earlier) on
page 421

D_MIRROR_ALARM_TRACE
VersionInfoSphere CDC for Oracle version 6.2 and earlier

Use this system parameter to Indicate whether or not tracing for notification is
enabled.

Applies ToSource and Target

Set this parameter to one of the following:

v OFFTracing for notification is disabled.
v ONTracing for notification is enabled.

Tracing for notification is enabled when D_MIRROR_TRACE system parameter is also

set to ON. The notification tracing will be located in the same trace file used for

450 InfoSphere Change Data Capture Management Console: Administration Guide

 regular tracing located in the directory specified by the D_MIRROR_LOG system
parameter. The trace files are encrypted and are meant to be sent to IBM for
troubleshooting purposes.

Default SettingOFF
Related concepts
System parameters for InfoSphere CDC for Oracle (version 6.2 and earlier) on
page 421
Related reference
D_MIRROR_TRACE on page 448

Refresh loader system parameters

Some system parameters affect how InfoSphere CDC applies refresh operations.

See also:
DIRPATH_BUF_ROWS
DIRPATH_BUF_SIZE on page 452
DIRPATH_CACHE_DATE_SIZE on page 453
DIRPATH_LOAD on page 453
DIRPATH_LOGGING on page 454
DIRPATH_DO_RECOVERY on page 454

DIRPATH_BUF_ROWS
VersionInfoSphere CDC for Oracle version 6.2 and earlier

Use this system parameter to specify the number of rows allocated in the internal
buffer used for direct path loading. By setting this parameter to a value greater
than 0, you can improve direct path loading performance.

Applies ToTarget

The table below explains how the DIRPATH_BUF_ROWS and DIRPATH_BUF_SIZE system
parameters affect the size of the internal buffer that InfoSphere CDC uses for direct
path loading.

DIRPATH_BUF_ SIZE DIRPATH_BUF_ ROWS Internal buffer size

0 0 Determined dynamically,
based on the size of the table
being loaded.
0 Greater than 0 As specified by
DIRPATH_BUF_ROWS.
InfoSphere CDC allocates an
internal buffer that is large
enough to store the number
of rows specified by
DIRPATH_BUF_ROWS.
Greater than 0 0 As specified by
DIRPATH_BUF_SIZE.
Greater than 0 Greater than 0 As specified by
DIRPATH_BUF_SIZE.

System parameters for InfoSphere CDC for Oracle (version 6.2 and earlier) 451
 Default Setting0

Minimum Setting0

Maximum Setting231
Related concepts
System parameters for InfoSphere CDC for Oracle (version 6.2 and earlier) on
page 421
Related reference
DIRPATH_BUF_SIZE

DIRPATH_BUF_SIZE
VersionInfoSphere CDC for Oracle version 6.2 and earlier

Use this system parameter to specify the size, in bytes, for the internal buffer used
for direct path loading. By setting this parameter to a value greater than 0, you can
improve direct path loading performance.

Applies ToTarget

The table below explains how the DIRPATH_BUF_SIZE and DIRPATH_BUF_ROWS system
parameters affect the size of the internal buffer that InfoSphere CDC uses for direct
path loading.

DIRPATH_BUF_ SIZE DIRPATH_BUF_ ROWS Internal buffer size

0 0 Determined dynamically,
based on the size of the table
being loaded.
0 Greater than 0 As specified by
DIRPATH_BUF_ROWS.
InfoSphere CDC allocates an
internal buffer that is large
enough to store the number
of rows specified by
DIRPATH_BUF_ROWS.
Greater than 0 0 As specified by
DIRPATH_BUF_SIZE.
Greater than 0 Greater than 0 As specified by
DIRPATH_BUF_SIZE.

Default Setting0

Minimum Setting0

Maximum Setting231

452 InfoSphere Change Data Capture Management Console: Administration Guide

 Related concepts
System parameters for InfoSphere CDC for Oracle (version 6.2 and earlier) on
page 421
Related reference
DIRPATH_BUF_ROWS on page 451

DIRPATH_CACHE_DATE_SIZE
VersionInfoSphere CDC for Oracle version 6.2 and earlier

Use this system parameter to specify the number of DATE (date and timestamp)
values to be cached per table being refreshed, during direct path loading. If the
table being refreshed contains DATE data type columns, you can improve direct
path loading performance by setting this parameter to a value higher than the
default setting. If the table being refreshed does not contain any DATE data type
columns, this parameter has no effect.

Applies ToTarget

Default Setting0. DATE values are not cached.

Minimum Setting0

Maximum Setting2^32
Related concepts
System parameters for InfoSphere CDC for Oracle (version 6.2 and earlier) on
page 421

DIRPATH_LOAD
VersionInfoSphere CDC for Oracle version 6.2 and earlier

Use this system parameter to enable or disable direct path loading.

Applies ToTarget

Set this parameter to one of the following:

v ONDirect path loading is enabled.
InfoSphere CDC uses Oracle Call Interface (OCI) functions to perform data
refresh. By using OCI functions, InfoSphere CDC can load multiple rows by
loading a direct path stream that contains data for multiple rows.

Note: If you want to enable direct path loading, then you need perform a
refresh on each subscription to send data to the target datastore.
v OFFDirect path loading is disabled.

Note: This setting is required in cascading replication configurations, to make

sure that data changes are correctly replicated to the target tables.

Default SettingON

System parameters for InfoSphere CDC for Oracle (version 6.2 and earlier) 453
 Related concepts
System parameters for InfoSphere CDC for Oracle (version 6.2 and earlier) on
page 421

DIRPATH_LOGGING
VersionInfoSphere CDC for Oracle version 6.2 and earlier

Applies ToTarget

Indicates whether or not full image redo logging is performed. This system
parameter corresponds to the Oracle NOLOGGING keyword.

Set this parameter to one of the following:

v OFFFull image redo logging is not performed. Oracle generates a minimum
number of redo log entries, thus providing improved performance. However, in
case of instance failure, records that were inserted are marked as logically
corrupted and cannot be recovered.
v ONFull image redo logging is performed. Oracle inserts data with full image
redo logging, which ensures that the necessary information is available in case of
instance failure.

For more information about image redo logging, see your Oracle documentation.

Default SettingOFF
Related concepts
System parameters for InfoSphere CDC for Oracle (version 6.2 and earlier) on
page 421

DIRPATH_DO_RECOVERY
VersionInfoSphere CDC for Oracle version 6.2 and earlier

Use this system parameter to modify how InfoSphere CDC handles rows that have
conflicting unique index values. In Direct Path Load, InfoSphere CDC places an
index in direct load state when it detects one or more conflicts after performing a
refresh of all rows.

Applies ToTarget
v OFFNo rows are removed and the index remains in direct load state and
ROWID of duplicate rows are stored in the exception table as indicated in the
event log.
v ONAll rows with conflicting unique index values will be removed and the
index will be enabled.

Default SettingOFF

454 InfoSphere Change Data Capture Management Console: Administration Guide

 Related concepts
System parameters for InfoSphere CDC for Oracle (version 6.2 and earlier) on
page 421

User exit system parameters

Some system parameters control user exits.

See also:
D_MIRROR_SP_CONNECTION
DM_FROM_CODEPAGE_V4USEREXIT
DM_TO_CODEPAGE_V4USEREXIT on page 456

D_MIRROR_SP_CONNECTION
VersionInfoSphere CDC for Oracle version 6.2 and earlier

Use this system parameter to indicate whether or not a second connection to the
Oracle database is established for a stored procedure user exit program to run.

Applies ToTarget

Set this parameter to one of the following:

v OFFA second connection to the database is not established. The stored
procedure user exit program and InfoSphere CDC will use the same, shared
connection to the Oracle database. This setting ensures that changes to tables
made by InfoSphere CDC are visible to the stored procedure user exit program.
v ONA second connection to the database is established.

The stored procedure user exit program will use this separate, second connection,
to the Oracle database.

Attention: If any stored procedure user exit program is issuing a commit or

rollback, you must set this parameter to ON, otherwise data may be lost, or errors
may be generated when applying data to the target database.

Setting this parameter to ON does not affect stored procedure user exit programs
for conflict resolution, or stored procedure user exit programs invoked within an
expression, using the %STPROC column function. They will always use the same
connection to the database as InfoSphere CDC.

Default SettingOFF
Related concepts
System parameters for InfoSphere CDC for Oracle (version 6.2 and earlier) on
page 421

DM_FROM_CODEPAGE_V4USEREXIT
VersionInfoSphere CDC for Oracle version 6.2 and earlier

Applies ToTarget

System parameters for InfoSphere CDC for Oracle (version 6.2 and earlier) 455
 Set this parameter only if using before or after images in C user exit programs
defined in InfoSphere CDC Version 4.x.

In InfoSphere CDC Version 4.x, the before and after images in C user exit
programs were received in the code page of the source. In Version 5.1 and greater,
they are received in the code page of the target. To use the user exit program as
defined in Version 4.x, data must be translated back from the code page of the
target to the code page of the source.

Therefore, specify for this parameter the code page to translate from (the code page
of the target).

If this parameter is not set, no translation will be performed from the code page of
the source to the code page of the target.
Related concepts
System parameters for InfoSphere CDC for Oracle (version 6.2 and earlier) on
page 421

DM_TO_CODEPAGE_V4USEREXIT
VersionInfoSphere CDC for Oracle version 6.2 and earlier

Applies ToTarget

Set this parameter only if using before or after images in C user exit programs
defined in InfoSphere CDC Version 4.x.

In InfoSphere CDC Version 4.x, the before and after images in C user exit
programs were received in the code page of the source. In Version 5.1 and higher,
they are received in the code page of the target. To use the user exit program as
defined in Version 4.x, data must be translated back from the code page of the
target to the code page of the source.

Therefore, specify for this parameter the code page to translate to (the code page of
the source).

If this parameter is not set, no translation will be performed from the code page of
the target to the code page of the source.
Related concepts
System parameters for InfoSphere CDC for Oracle (version 6.2 and earlier) on
page 421

Table mapping system parameters

Some system parameters control table mappings.

See also:
TS_DELETE_ASSIGNED_OBJECTS_DURING_DESCRIBE

TS_DELETE_ASSIGNED_OBJECTS_DURING_DESCRIBE
VersionInfoSphere CDC for Oracle version 6.2 and earlier

456 InfoSphere Change Data Capture Management Console: Administration Guide

 Use this system parameter (when describing source tables to subscriptions) to
specify whether or not to remove references to target tables when the mapped
source table no longer exists.

Applies ToTarget

Set this parameter to one of the following:

v OFFInfoSphere CDC does not remove references to target tables when the
assigned source table no longer exists.
v ONInfoSphere CDC removes references to target tables when the assigned
source table no longer exists.

Default SettingOFF
Related concepts
System parameters for InfoSphere CDC for Oracle (version 6.2 and earlier) on
page 421

Notification system parameters

Notification system parameters let you control if you should generate InfoSphere
CDC messages in the Event Log for specific events.

See also:
convertNotNullableMsg
DEADBAND_PERCENTAGE on page 458
DM_STATUS_INTERVAL on page 459
HEARTBEAT_TIMEOUT on page 460
LOG_EMAIL_USERNAME on page 460
MONITOR_SAMPLE_INTERVAL on page 461
STATISTICS_INTERVAL on page 461

convertNotNullableMsg
VersionInfoSphere CDC for Oracle version 6.2 and earlier

Use this system parameter to indicate whether or not NULL values will be
converted to default values when replicating data that contains NULL values to
non-nullable target columns.

Applies ToTarget

Set this parameter to one of the following:

v OFFAn error message will be generated in Event Log. Replication will
continue or not based on whether the MirrorError or RefreshError system
parameters are set to END or ON.
v ONInfoSphere CDC will automatically insert an appropriate default value in
the target column. No error message is generated in Event Log and replication
continues.
Depending on the convertNotNullableMsg system parameter setting, a warning
message may be generated in Event Log.

System parameters for InfoSphere CDC for Oracle (version 6.2 and earlier) 457
 The default value depends on the data type of the subscription column. For
example, zero for numeric data types, blank character for character data types,
1901-01-01 for date data types, and so on.

Default SettingOFF
Related concepts
System parameters for InfoSphere CDC for Oracle (version 6.2 and earlier) on
page 421

DEADBAND_PERCENTAGE
VersionInfoSphere CDC for Oracle version 6.2 and earlier

Applies ToTarget

Identifies the size of the range around each latency threshold setting. Based on
latency thresholds defined, a latency message is generated when latency has risen
above or fallen below a threshold. Latency is calculated at regular intervals, where
the interval is the current setting for the MONITOR_SAMPLE_INTERVAL system
parameter. You can set notifications in response to a generated latency message.

This system parameter, which is expressed as a percentage, allows you to pad a

threshold equally on both sides to create a range around the threshold. By
adjusting this system parameter, the size of the range around the threshold can be
increased or decreased, and the threshold itself can be made thicker or thinner. A
latency message is generated only when latency has risen above the upper limit of
the range or fallen below the lower limit of the range. By changing the value
assigned to this system parameter, you can control the number of latency messages
placed in Event Log.

For example, assume that a latency threshold is 5 minutes and this system
parameter is set to 10. A 10% range is applied around the 5 minute threshold. The
following calculations are performed to determine the lower and upper limits (in
minutes) of the range around the threshold:
v Padding = 10% of 5 minutes = 0.5 minutes (rounded up to 1 minute)
v Padding is rounded up or down to the nearest whole minute:
Upper limit of range = 5 minutes + 1 minute (padding) = 6 minutes
Lower limit of range = 5 minutes - 1 minute (padding) = 4 minutes

As a result, a latency message will be generated only when latency rises above 6
minutes or falls below 4 minutes. Given sample latency over a ten minute period
where latency is calculated every minute, three latency messages are generated.
This graph illustrates latency message generation with the DEADBAND_PERCENTAGE
value set to 10%:

458 InfoSphere Change Data Capture Management Console: Administration Guide

 If this DEADBAND_PERCENTAGE is set to 3 (the default setting) for the same example,
no padding is applied to the latency threshold. Therefore, a latency message is
generated each time latency crosses over the latency threshold of 5 minutes. Based
on the same sample latency in the previous graph where latency is calculated
every minute, five latency messages are generated when this system parameter is
set to 3. This graph illustrates latency message generation with the
DEADBAND_PERCENTAGE value set to 3%:

If the number of latency messages generated over the ten minute period for the
10% (3 latency messages) and 3% (5 latency messages) settings are averages, an
additional 288 latency messages would be generated each day if this system
parameter is not changed from its default setting to 10%.

Since there are two latency thresholds that you can set (a warning threshold and a
problem threshold), two separate ranges are defined when padding is at least one
minute. In this case, each range is attached to its threshold, and the two ranges can
overlap with no change in behavior.

If a value outside the acceptable range is specified, the default setting is used.

Default Setting3%

Minimum Setting3%

Maximum Setting10%

Note: If you set a value outside the acceptable range, then InfoSphere CDC uses
the defaults.
Related concepts
System parameters for InfoSphere CDC for Oracle (version 6.2 and earlier) on
page 421
Disk resource system parameters on page 462
Setting latency thresholds and notifications on page 346

DM_STATUS_INTERVAL
VersionInfoSphere CDC for Oracle version 6.2 and earlier

Use this system parameter to specify how often progress messages should be
issued in seconds. These messages are displayed in Event Log to indicate how
replication is advancing and to provide detailed information about InfoSphere
CDC replication activities.

Applies ToSource and Target

System parameters for InfoSphere CDC for Oracle (version 6.2 and earlier) 459
 Note: Low values of this parameter may result in many messages displayed in
Event Log. In this situation, clear Event Log on a regular basis.

Default Setting0 seconds. No progress notifications will be issued.

Minimum Setting0 seconds. No progress notifications will be issued.

Maximum Setting7200 seconds

Related concepts
System parameters for InfoSphere CDC for Oracle (version 6.2 and earlier) on
page 421

HEARTBEAT_TIMEOUT
VersionInfoSphere CDC for Oracle version 6.2 and earlier

Use this parameter to specify the number of minutes of communication inactivity

to wait before active InfoSphere CDC processes for a subscription are stopped.
Heartbeat is a feature that manages InfoSphere CDC processes when a problem
with communications or a process has been detected through the absence of
communications over a specified period of time.

For each active subscription, internal heartbeat messages are sent regularly
between the source and the target to determine communications and process
status. If a reply to a message is not received by the source or target within the
specified timeout interval, then InfoSphere CDC determines that a problem has
occurred, and attempts to stop all its source and target processes for the
subscription. In addition, messages (message identifiers 2612 and 3165) are placed
in Event Log when heartbeat timeouts occur.

Applies ToSource

Default Setting15 minutes

Minimum Setting3 minutes

Maximum Setting999 minutes

Related concepts
System parameters for InfoSphere CDC for Oracle (version 6.2 and earlier) on
page 421
Viewing replication events on page 364

LOG_EMAIL_USERNAME
VersionInfoSphere CDC for Oracle version 6.2 and earlier

Use this system parameter to specify the user name that receives e-mail messages
in response to invoking the dmreadlog command or the warning message that is
generated when Event Log exceeds the threshold value set by the LOG_MAX_SIZE
system parameter.

Applies ToSource and Target

460 InfoSphere Change Data Capture Management Console: Administration Guide

 In UNIX environments, the value assigned to this parameter is a comma-separated
list of user names. The value of this parameter cannot exceed 30 bytes in length.

To suppress all e-mail messages, set this parameter to NOMAIL.

Default SettingThe InfoSphere CDC account (UNIX user) specified when

InfoSphere CDC was installed
Related concepts
System parameters for InfoSphere CDC for Oracle (version 6.2 and earlier) on
page 421
Related reference
STATISTICS_INTERVAL

MONITOR_SAMPLE_INTERVAL
VersionInfoSphere CDC for Oracle version 6.2 and earlier

Use this system parameter to identify the period of time, in seconds, between
consecutive updates to a storage area that is used to maintain replication latency
metrics. Management Console references this area to present replication latency
information.

Applies ToSource and Target

On the target, this setting also represents how often the storage area is sampled to
determine if latency has risen above or fallen below specified threshold settings.
InfoSphere CDC generates latency messages when latency rises above or falls
below the thresholds. In response to a generated message, you can set latency
notifications.

If a value smaller than the minimum setting is specified, the minimum setting is
used. If a value larger than the maximum setting is specified, the maximum setting
is used.

Default Setting5 seconds

Minimum Setting0 seconds. Replication latency metrics are not updated.

Maximum Setting3600 seconds

Related concepts
System parameters for InfoSphere CDC for Oracle (version 6.2 and earlier) on
page 421
Setting latency thresholds and notifications on page 346

STATISTICS_INTERVAL
VersionInfoSphere CDC for Oracle version 6.2 and earlier

Use this system parameter to specify how often, in seconds, InfoSphere CDC issues
messages that contain statistics information. These messages are displayed in Event
Log.

Applies ToSource and Target

System parameters for InfoSphere CDC for Oracle (version 6.2 and earlier) 461
 Note: Use this parameter only if advised by IBM technical support.

Default Setting0. InfoSphere CDC does not provide statistics information.

Minimum Setting0. InfoSphere CDC does not provide statistics information.

Maximum Setting2,147,483,647 (maximum integer)

DynamicYes
Related concepts
System parameters for InfoSphere CDC for Oracle (version 6.2 and earlier) on
page 421

Disk resource system parameters

Some system parameters control memory usage in InfoSphere CDC. For improved
performance, if you are able to allocate more than the default value of 512 MB for
the InfoSphere CDC Java Virtual Machine, then you can adjust the disk resource
system parameters to use the increased memory.

See also:
LOG_MAX_SIZE

LOG_MAX_SIZE
VersionInfoSphere CDC for Oracle version 6.2 and earlier

Use this system parameter to specify the threshold size of Event Log in KB. A
warning message is generated in Event Log when its size exceeds specified
threshold. The messages in Event Log are deleted automatically when the size of
Event Log is ten times the value specified by this parameter.

Applies ToSource and Target

If you do not want to specify a threshold size, set this parameter to NOMAX.

Default Setting5000
Related concepts
System parameters for InfoSphere CDC for Oracle (version 6.2 and earlier) on
page 421

462 InfoSphere Change Data Capture Management Console: Administration Guide

System parameters for InfoSphere CDC for Oracle (version
6.3 and later)
System parameters let you control the behavior of InfoSphere CDC. If your
replication environment requires a particular configuration, then you can use
system parameters to modify the behavior of default operations in InfoSphere
CDC. The default system parameter settings are appropriate for most installations.
Maintain these default settings until you become familiar with the configuration of
InfoSphere CDC.

InfoSphere CDC provides system parameters that control the behavior of your
source and target datastores.

Note: If you make changes to a system parameter during active replication, you
must stop and restart replication for the changes to take effect.

In this section, you will learn:

General product system parameters
Transaction log location system parameters on page 464
Notification system parameters on page 468
Maximize throughput system parameters on page 469
Encoding system parameters on page 472
Disk resource system parameters on page 473
Apply process system parameters on page 475

General product system parameters

General product system parameters let you control basic features of InfoSphere
CDC and information you may have specified during installation.

See also:
mirror_auto_restart_interval_minutes
mirror_set_table_data_capture_timeout on page 464

mirror_auto_restart_interval_minutes
VersionInfoSphere CDC for Oracle version 6.3 Fix Pack 3 TFE 9 and later.

Use this parameter to indicate how long (in minutes) InfoSphere CDC will attempt
to automatically restart continuous mirroring for persistent subscriptions.

Applies ToSource

Default0

Minimum0

Maximum60

Copyright IBM Corp. 2008, 2011 463

 mirror_set_table_data_capture_timeout
VersionInfoSphere CDC for Oracle version 6.3 and later

Use this system parameter to indicate how long (in seconds) InfoSphere CDC waits
before declaring a failure when preparing a table for mirroring.

Applies ToSource

Default30 seconds

Minimum0 minutes

Maximum90 seconds

Transaction log location system parameters

Use these system parameters to indicate the location of your database transaction
logs.

See also:
mirror_archive_log_directory
mirror_asm_oracle_path
mirror_online_log_directory on page 465
oracle_archive_dir on page 465
oracle_archive_destination_id on page 465
oracle_archive_logs_only on page 466
oracle_log_path_userexit on page 466
oracle_log_shipping on page 466
oracle_using_log_transport_services on page 467

mirror_archive_log_directory
VersionInfoSphere CDC for Oracle version 6.3 and later

Use this system parameter to override the directory for archiving log files for
mirroring. Specify a directory that should be used instead of the one Oracle has
specified.

Applies ToSource

Default SettingNo directory; instead, InfoSphere CDC will use the directory
specified by Oracle.

mirror_asm_oracle_path
VersionInfoSphere CDC for Oracle version 6.3 and later

Use this system parameter if the Oracle database uses ASM to manage its datafile
or redo logs on a Linux system. Replace the ORCL label that references the
common directory of the ASM-managed devices with the actual directory path.

464 InfoSphere Change Data Capture Management Console: Administration Guide

mirror_online_log_directory
VersionInfoSphere CDC for Oracle version 6.3 and later

Use this system parameter to override the directory for reading online log files.
Specify a directory that should be used instead of the one Oracle has specified.

Applies ToSource

Default SettingNo directory; instead, InfoSphere CDC will use the directory
specified by Oracle.

oracle_archive_dir
VersionInfoSphere CDC for Oracle version 6.3 and later

Use this system parameter to specify the fully qualified path to the Oracle archive
log when you are shipping your archive logs to another system. InfoSphere CDC
only uses this value if you do not specify a Java class user exit in the
oracle_log_path_userexit system parameter.

For example, you can specify the following value:

/archivelog/mycdcsystem/

Note: For RAC environments where the thread ID is not included in the archive
log file name, InfoSphere CDC will read the archive logs from subdirectories that
are named using the thread number. For example, /archivelog/mycdcsystem/1 for
thread 1 and /archivelog/mycdcsystem/2 for thread 2.

Applies ToSource
Related reference
oracle_log_path_userexit on page 466

oracle_archive_destination_id
VersionInfoSphere CDC for Oracle version 6.3 and later

Note: You must indicate that you are using Oracle Data Guard log transport
services with the oracle_using_log_transport_services system parameter before
you can specify a value here.

Use this system parameter to indicate the destination ID of the archive destination
on the secondary system where you have configured the archived redo log
repository. Set this system parameter to a numeric value between 1 and 10.

For more information on using Oracle Data Guard and log transport services, see
your Oracle documentation.

Default Setting1

Applies ToSource

System parameters for InfoSphere CDC for Oracle (version 6.3 and later) 465
 Related reference
oracle_using_log_transport_services on page 467
oracle_log_shipping
oracle_archive_dir on page 465

oracle_archive_logs_only
VersionInfoSphere CDC for Oracle version 6.3 and later

Use this system parameter to indicate that InfoSphere CDC will only use Oracle
archive logs, not online redo logs.

Set this parameter to one of the following:

v trueInfoSphere CDC will only use Oracle archive logs.
v falseInfoSphere CDC will use Oracle online redo logs and Oracle archive
logs.

Default Settingfalse

Applies ToSource
Related reference
oracle_log_shipping

oracle_log_path_userexit
VersionInfoSphere CDC for Oracle version 6.3 and later

Use this system parameter to specify a Java class user exit that returns the fully
qualified path to the Oracle archive log.

You must implement the ArchiveLogPathUserExit user exit class as a Java class
user exit and define the method that returns the fully qualified path to the system
where you shipped the archive logs. The name of the archive log must be included
in the path. You can customize the logic in the user exit to suit your business
requirements.

A sample user exit class, SampleArchiveLogPathUserExit, is installed with

InfoSphere CDC.

For more information on sample user exits and implementing a Java class user
exit, see your InfoSphere CDC for Oracle documentation.

Applies ToSource
Related tasks
To configure a user exit for a Java class on page 198
Related reference
oracle_archive_dir on page 465

oracle_log_shipping
VersionInfoSphere CDC for Oracle version 6.3 and later

466 InfoSphere Change Data Capture Management Console: Administration Guide

 Use this system parameter to indicate whether or not InfoSphere CDC replication
processes will use copies of complete Oracle archive logs that are shipped to a
secondary system that is accessible to InfoSphere CDC.

If you decide to ship your logs, InfoSphere CDC latency is affected by the Oracle
log switch frequency and the amount of time required to physically ship the logs
to the remote destination. Latency may increase if the log switch interval and the
log shipping time increase.

You can ship your archive logs in one of two ways:

v Use Oracle Data Guard log transport services to ship your logs to an archived
redo log repository on a secondary system that is accessible to InfoSphere CDC.
In addition to this parameter, use the following system parameters to configure
the product to run with this type of log shipping:
oracle_using_log_transport_services
oracle_archive_destination_id
oracle_archive_dir
oracle_archive_logs_only
v Use scripts or some other method to ship your archive logs to a secondary
system that is accessible to InfoSphere CDC. In addition to this parameter, use
the following system parameters to configure the product to run with this type
of log shipping:
oracle_archive_dir
oracle_log_path_userexit
oracle_archive_logs_only

Note: For both types of log shipping, the parameters used and the values specified
may vary depending on your business requirements.

Set this parameter to one of the following:

v trueInfoSphere CDC replication processes will use copies of Oracle archive
logs that are shipped to a secondary system.
v falseInfoSphere CDC replication processes will not use copies of Oracle
archive logs that are shipped to a secondary system.

Default Settingfalse

Applies ToSource
Related reference
oracle_archive_dir on page 465
oracle_log_path_userexit on page 466
oracle_archive_logs_only on page 466
oracle_using_log_transport_services
oracle_archive_destination_id on page 465

oracle_using_log_transport_services
VersionInfoSphere CDC for Oracle version 6.3 and later

Note: You must enable log shipping with the oracle_log_shipping system
parameter before you can specify a value here.

System parameters for InfoSphere CDC for Oracle (version 6.3 and later) 467
 Use this system parameter to indicate whether or not InfoSphere CDC will read
logs from an archived redo log repository on a secondary system populated with
Oracle Data Guard log transport services.

When using log transport services to ship your logs:

v The first archiving destination, the one with the lowest destination ID, must use
the same file names as the log shipping destination.
v The log shipping destination must use the ARCH archiver.

For more information on how to configure Data Guard, see your Oracle
documentation.

Set this parameter to one of the following:

v trueInfoSphere CDC will rely on Oracle Data Guard log transport services to
ship archive logs to an archived redo log repository on a secondary system.
v falseInfoSphere CDC will rely on a log shipping process managed by the user
to ship archive logs to the secondary system.

Default Settingfalse

Applies ToSource
Related reference
oracle_archive_destination_id on page 465
oracle_log_shipping on page 466
oracle_archive_dir on page 465

Notification system parameters

Notification system parameters let you control if you should generate InfoSphere
CDC messages in the Event Log for specific events.

See also:
events_max_retain
global_conversion_not_possible_warning on page 469
global_shutdown_after_no_heartbeat_response_minutes on page 469

events_max_retain
VersionInfoSphere CDC for Oracle version 6.3 and later

Use this system parameter to control the maximum number of events that
InfoSphere CDC will store in the event log. If InfoSphere CDC generates more
events than the specified maximum, then the earliest events will be deleted.

Default Setting10000

Minimum -1

Maximum2147483647

468 InfoSphere Change Data Capture Management Console: Administration Guide

 Related concepts
System parameters for InfoSphere CDC for Oracle (version 6.3 and later) on page
463

global_conversion_not_possible_warning
VersionInfoSphere CDC for Oracle version 6.3 and later

Use this system parameter to control whether or not InfoSphere CDC generates a
warning in the Management Console Event Log in the following situations:
v Data conversion is not possible for a specific data value.
v Converted data types are encountered that are out of range.

Set this parameter to one of the following:

v trueGenerates a warning in the Event Log if data conversion is not possible
for a specific data value or converted data types are encountered that are out of
range.
v falseDoes not generate a warning in the Event Log if data conversion is not
possible for a specific data value or converted data types are encountered that
are out of range.

Applies ToTarget

Default Settingfalse
Related concepts
System parameters for InfoSphere CDC for Oracle (version 6.3 and later) on page
463

global_shutdown_after_no_heartbeat_response_minutes
VersionInfoSphere CDC for Oracle version 6.3 and later

Use this system parameter to specify the duration, in minutes, of communication

inactivity before active InfoSphere CDC processes for a subscription are stopped. If
a value outside the acceptable range is specified, the default setting is used.

Applies ToSource

Default Setting15 minutes

Minimum Setting3 minutes

Maximum Setting999 minutes

Related concepts
System parameters for InfoSphere CDC for Oracle (version 6.3 and later) on page
463

Maximize throughput system parameters

InfoSphere CDC system parameters allow you to significantly reduce the workload
of the target database during mirroring. The InfoSphere CDC apply process groups
transactions on the target to reduce the workload. Every commit on the target
database will correspond with a commit on the target. However, it may not

System parameters for InfoSphere CDC for Oracle (version 6.3 and later) 469
 perform every commit that was done on the source. For example, if the source
does three small transactions containing one operation each, the target may commit
all three operations as part of a single transaction. You can use this grouping of
system parameters to significantly reduce the resources required by the target
database. The default settings are appropriate for most databases, but if your target
system has limited resources and an increase in latency is acceptable, you can
adjust the settings appropriately.

See also:
mirror_interim_commit_threshold
mirror_sess_hist_age_threshold
mirror_src_ora_version on page 471
refresh_commit_after_max_operations on page 471
userexit_max_lob_size_kb on page 471

mirror_interim_commit_threshold
VersionInfoSphere CDC for Oracle version 6.3 Fix Pack 3 and later.

By default, InfoSphere CDC guarantees transactional delivery of change data to the

target. This ensures that if any data from a source transaction is committed to the
target, then all other in scope operations from that source transaction are
committed as well.

In cases where large transactions are done on the source system, it can be more
efficient to break a large transaction into smaller transactions when applying data
to the target. You can configure this behavior using this system parameter.

The default value of 0 for this system parameter indicates that the product
guarantees transactional delivery of change data to the target. A value greater than
0 indicates that you want InfoSphere CDC to break up large transactions into
smaller transactions. For example, a value of 2000 indicates that InfoSphere CDC
will split up large source transactions so that each transaction committed to the
target database contains no more than 2000 operations.

Applies ToTarget

Default Setting0

Minimum Setting0

mirror_sess_hist_age_threshold
VersionInfoSphere CDC for Oracle version 6.3 and later

Use this system parameter to identify the number of days of session history to
maintain. If the value is set to a positive number, the session history will be
purged accordingly. A negative number results in the retention of all log
information.

Default Setting3

Minimum -1 minutes

470 InfoSphere Change Data Capture Management Console: Administration Guide

 Maximum9223372036854775807 minutes
Related concepts
System parameters for InfoSphere CDC for Oracle (version 6.3 and later) on page
463

mirror_src_ora_version
VersionInfoSphere CDC for Oracle version 6.3 and later

This system parameter identifies the database version of the primary database. If
the primary database is version 10g or higher, then you must set this parameter on
both the primary and backup systems. Set this parameter to the full database
version number. For example, 10.2.0.1.0.
Related concepts
System parameters for InfoSphere CDC for Oracle (version 6.3 and later) on page
463

refresh_commit_after_max_operations
VersionInfoSphere CDC for Oracle version 6.3 and later

This system parameter identifies the number of rows comprising each transaction
during refresh. To reduce the workload on the target database during refresh,
InfoSphere CDC periodically commits the changes to the target database rather
than performing the refresh as a single large transaction.

Applies ToTarget

Default Setting1000

Maximum Setting2147483647

Minimum Setting1
Related concepts
System parameters for InfoSphere CDC for Oracle (version 6.3 and later) on page
463

userexit_max_lob_size_kb
VersionInfoSphere CDC for Oracle version 6.3 and later

Use this system parameter to set the maximum size of LOB data (in kb) that
InfoSphere CDC can pass to a user exit.

Applies ToTarget

Default Setting128 kb

Maximum9223372036854775807 kb

Minimum1 kb

System parameters for InfoSphere CDC for Oracle (version 6.3 and later) 471
 Related concepts
System parameters for InfoSphere CDC for Oracle (version 6.3 and later) on page
463

Encoding system parameters

For some system parameters, you can set the default method for treating data in
defined Unicode columns, and you can set the default character encoding for your
database.

See also:
global_unicode_as_char

global_unicode_as_char
VersionInfoSphere CDC for Oracle version 6.3 and later

This system parameter indicates the default method of treating data in defined
Unicode columns. For each InfoSphere CDC installation on a server, this system
parameter defines the system default method of treating data in Unicode columns.
If a Unicode column is set to System Default on the Encoding tab of the Mapping
Details view in Management Console, InfoSphere CDC uses the method for
processing Unicode columns that you select in this system parameter.

Set this parameter to one of the following:

v trueInfoSphere CDC treats all data in Unicode columns as single-byte
characters. Use this setting when Unicode columns contain single-byte character
data.
v falseInfoSphere CDC treats all data in Unicode columns as a continuous bit
stream. Use this setting when Unicode columns contain non-single-byte
character data. Setting this system parameter to false ensures that InfoSphere
CDC handles non-single-byte character data in the same way as previous
InfoSphere CDC releases.

Note: Setting this parameter to false does not ensure that replicated
non-single-byte character data in Unicode columns are represented properly on
the target. For replicated non-single-byte character data, you may have to apply
user exit programs or other customizations to properly represent data in
Unicode columns. For more information about user exit programs, see the
InfoSphere CDC End-User Documentation for your platform.

Applies ToSource

Default Settingfalse

For information about how data in each Unicode source column is treated and
setting multibyte and Unicode character set conversions, see Replicating multibyte
(MBCS) and double-byte (DBCS) character data on page 163.

472 InfoSphere Change Data Capture Management Console: Administration Guide

 Related concepts
System parameters for InfoSphere CDC for Oracle (version 6.3 and later) on page
463

Disk resource system parameters

Some system parameters control memory usage in InfoSphere CDC. For improved
performance, if you are able to allocate more than the default value of 512 MB for
the InfoSphere CDC Java Virtual Machine, then you can adjust the disk resource
system parameters to use the increased memory.

See also:
mirror_global_disk_quota_mb
mirror_global_disk_quota_gb on page 474
staging_store_can_run_independently on page 474
staging_store_disk_quota_gb on page 475
staging_store_disk_quota_mb on page 475

mirror_global_disk_quota_mb
VersionInfoSphere CDC for Oracle version 6.3

Use this system parameter to globally set a disk quota (in MB) for all capture
components including temporary files, transaction queues, and LOBs which are
staged on the target before being applied. InfoSphere CDC will manage disk space
utilization across all components as required.

Most databases have a mechanism that allows you to roll back or undo changes to
your database by storing uncommitted changes. Similarly, InfoSphere CDC uses
the disk quota controlled by this system parameter to store in scope change data
that has not been committed in your database. Once the database transaction is
committed, the disk space used by the transaction is released. Note that InfoSphere
CDC stores the data in memory to improve performance and will only persist the
data to disk if memory is unavailable.

The default setting of this system parameter is such that the product will only stop
replicating after this disk quota exhausts all available disk space on your system. If
you would prefer the product to stop replicating after it uses a specific amount of
disk space, you can set the value with this system parameter.

Applies ToSource and Target

Default Setting9223372036854775807

Maximum9223372036854775807

Minimum100

System parameters for InfoSphere CDC for Oracle (version 6.3 and later) 473
 Related concepts
System parameters for InfoSphere CDC for Oracle (version 6.3 and later) on page
463

mirror_global_disk_quota_gb
VersionInfoSphere CDC for Oracle version 6.5

Use this system parameter to globally set a disk quota (in GB) for all capture
components including temporary files, transaction queues, and LOBs which are
staged on the target before being applied. InfoSphere CDC will manage disk space
utilization across all components as required.

Most databases have a mechanism that allows you to roll back or undo changes to
your database by storing uncommitted changes. Similarly, InfoSphere CDC uses
the disk quota controlled by this system parameter to store in scope change data
that has not been committed in your database. Once the database transaction is
committed, the disk space used by the transaction is released. Note that InfoSphere
CDC stores the data in memory to improve performance and will only persist the
data to disk if memory is unavailable.

The default setting of this system parameter is such that the product will only stop
replicating after this disk quota exhausts all available disk space on your system. If
you would prefer the product to stop replicating after it uses a specific amount of
disk space, you can set the value with this system parameter.

Applies ToSource and Target

Default Setting9223372036854775807

Maximum9223372036854775807

Minimum1

staging_store_can_run_independently
VersionInfoSphere CDC for Oracle version 6.3 and later

Use this system parameter to determine if subscriptions will exclusively use the
InfoSphere CDC staging store to accumulate change data or if they will be allowed
to use independent log readers and log parsers to receive data directly from the
database logs.

Set this parameter to one of the following values:

v trueSpecifies that subscriptions can use either the staging store to accumulate
change data or use independent log readers and log parsers to receive data
directly from the database logs.
v falseSpecifies that subscriptions will use the InfoSphere CDC staging store to
accumulate change data.

Changes to this system parameter value will only take effect after the replication
engine is restarted.

If you change the value from true to false, you will need to clear the staging store
before beginning replication.
474 InfoSphere Change Data Capture Management Console: Administration Guide
 Applies ToSource

Default Settingtrue

staging_store_disk_quota_gb
VersionInfoSphere CDC for Oracle version 6.5

Use this system parameter to specify the maximum amount of disk space that will
be utilized by the InfoSphere CDC staging store on your source system.

If you have enabled the Continuous Capture feature and you are accumulating
change data in your staging store when subscriptions are stopped, you should take
into consideration the additional disk utilization that this feature requires.

Applies ToSource

Default Setting100 GB

Maximum Setting2147483647 GB

Minimum Setting1 GB

staging_store_disk_quota_mb
VersionInfoSphere CDC for Oracle version 6.3

Use this system parameter to specify the maximum amount of disk space that will
be utilized by the InfoSphere CDC staging store on your source system.

If you have enabled the Continuous Capture feature and you are accumulating
change data in your staging store when subscriptions are stopped, you should take
into consideration the additional disk utilization that this feature requires.

Applies ToSource

Default Setting2147483647 MB

Maximum Setting2147483647 MB

Minimum Setting100 MB

Apply process system parameters

Some system parameters adjust the way InfoSphere CDC applies rows, column
data, and error handling.

See also:
convert_not_nullable_column on page 476
convert_not_nullable_message on page 476
global_max_batch_size on page 477
mirror_end_on_error on page 477
mirror_expected_errors_list on page 477
refresh_end_on_error on page 478

System parameters for InfoSphere CDC for Oracle (version 6.3 and later) 475
 refresh_expected_errors_list on page 478
refresh_in_unicode on page 479
refresh_with_referential_integrity on page 479
trim_char_to_varchar on page 479
trim_varchar_to_varchar on page 480
userexit_max_lob_size_kb on page 480

convert_not_nullable_column
VersionInfoSphere CDC for Oracle version 6.3 and later

Use this system parameter to control how InfoSphere CDC behaves when it applies
a null value to a non-nullable column. When set to true (default value), the null
value will be replaced with a default value (based on the data type of the column)
and InfoSphere CDC will generate a warning in the event log. When set to false,
InfoSphere CDC applies the null value directly to the non-nullable column which
will result in an error and cause a shutdown of InfoSphere CDC on the target
database.

Note: If you decided to set this system parameter to false and have specified this
as an error for InfoSphere CDC to ignore using the mirror_expected_errors_list
system parameter, then InfoSphere CDC will ignore the error and not shutdown.

Set this parameter to one of the following:

v trueNull value will be replaced with default value for non-nullable column,
and a warning event will be logged.
v falseNull data will be applied as-is to non-nullable column and database will
usually return an error code.

Applies ToSource and Target

Default SettingTrue
Related concepts
System parameters for InfoSphere CDC for Oracle (version 6.3 and later) on page
463

convert_not_nullable_message
VersionInfoSphere CDC for Oracle version 6.3 and later

Use this system parameter to determine if a message will be generated in the

Event Log when InfoSphere CDC converts a null value to a default value when
applied to a non-nullable column. When set to true (default value), InfoSphere
CDC will log the event the first time it encounters a null to non-nullable mapping
(on a per column per table basis). When set to false, InfoSphere CDC will not
generate a message when a null value is converted to a default value.

Note: This system parameter applies only when the convert_not_nullable_column

parameter has been set to true.

Set this parameter to one of the following:

v trueGenerates a warning message in the Event Log the first time a null value
is converted to a default value on a per column per table basis.

476 InfoSphere Change Data Capture Management Console: Administration Guide

 v falseNo warning message is generated in the Event Log.

Applies ToTarget

Default SettingTrue

global_max_batch_size
VersionInfoSphere CDC for Oracle version 6.3 and later

Use this system parameter to specify the maximum number of rows that
InfoSphere CDC can place in an array and apply to the target database during
refresh or mirroring. InfoSphere CDC collects rows and places them in an array (in
memory) while receiving table-level operations from the source system. InfoSphere
CDC applies the rows from the array when there is a change to a different table,
when there is a new table-level operation, or when the maximum number of rows
in an array has been reached. You can use this parameter during mirroring only if
mirror_end_on_error is true and mirror_expected_errors_list is empty. Use only
during a refresh if refresh_end_on_error is true and refresh_expected_errors_list is
empty. Before InfoSphere CDC places rows into an array, it allocates memory for
the maximum number of rows you specify and multiplies this integer by the
maximum length of a row. If the maximum number of rows is too large, then
InfoSphere CDC cannot allocate enough memory and will shut down. Management
Console references this area to present replication latency information.

Applies ToTarget

Default Setting25 rows

Maximum Setting2147483647 rows

Minimum Setting1 row

mirror_end_on_error
VersionInfoSphere CDC for Oracle version 6.3 and later

Use this system parameter to indicate if you want to end mirroring after an apply
error occurs on the target database.

Set this parameter to one of the following:

v trueEnd mirroring after an apply error on the target database.
v falseDo not end mirroring after an apply error on the target database.

Applies ToTarget

Default SettingTrue
Related concepts
System parameters for InfoSphere CDC for Oracle (version 6.3 and later) on page
463

mirror_expected_errors_list
VersionInfoSphere CDC for Oracle version 6.3 and later

System parameters for InfoSphere CDC for Oracle (version 6.3 and later) 477
 Use this system parameter when you want InfoSphere CDC to ignore one or more
database errors when applying data changes to the target during mirroring. The
error specified must correspond to the integer error code (database-vendor specific)
returned by the SQLException class in JDBC (Java Database Connectivity). Specify
multiple errors with a comma separated list of integer error codes.

For example, if you want InfoSphere CDC to continue mirroring when it

encounters primary key violations in your Oracle target database, set this
parameter to mirror_expected_errors_list=1. The integer error code of 1
corresponds to the Oracle error: ORA-00001: unique constraint violated
(<schema>.<constraint>). If you also want to ignore ORA-01407: cannot update
(string) to NULL, set this parameter to mirror_expected_errors_list=1,1407.

Note: Latency may increase when using this system parameter since InfoSphere
CDC will not use JDBC array apply in order to track the errors specified.

Applies ToTarget
Related concepts
System parameters for InfoSphere CDC for Oracle (version 6.3 and later) on page
463

refresh_end_on_error
VersionInfoSphere CDC for Oracle version 6.3 and later

Use this system parameter to indicate if you want to end a refresh after an apply
error occurs.

Set this parameter to one of the following:

v trueEnd a refresh after an apply error occurs.
v falseDo not end a refresh after an apply error occurs.

Applies ToTarget

Default SettingTrue
Related concepts
System parameters for InfoSphere CDC for Oracle (version 6.3 and later) on page
463

refresh_expected_errors_list
VersionInfoSphere CDC for Oracle version 6.3 and later

Use this system parameter when you want InfoSphere CDC to ignore one or more
database errors when refreshing data to the target. The error specified must
correspond to the integer error code (database-vendor specific) returned by the
SQLException class in JDBC (Java Database Connectivity). Specify multiple errors
with a comma separated list of integer error codes.

For example, if you want InfoSphere CDC to continue refresh when it encounters
primary key violations in your Oracle target database, set this parameter to
mirror_expected_errors_list=1. The integer error code of 1 corresponds to the
Oracle error: ORA-00001: unique constraint violated (<schema>.<constraint>). If

478 InfoSphere Change Data Capture Management Console: Administration Guide

 you also want to ignore ORA-01407: cannot update (string) to NULL, set this
parameter to mirror_expected_errors_list=1,1407.

Note: Latency may increase when using this system parameter since InfoSphere
CDC will not use JDBC array apply in order to track the errors specified.

Applies ToTarget

refresh_in_unicode
VersionInfoSphere CDC for Oracle version 6.3 and later

Use this system parameter when you want InfoSphere CDC to refresh a target
table that contains multibyte object names.

Set this parameter to one of the following:

v trueInfoSphere CDC will refresh the target table that contains multibyte object
names.
v falseInfoSphere CDC will not refresh a target table that contains multibyte
object names.

Applies ToTarget

Default Settingfalse
Related concepts
System parameters for InfoSphere CDC for Oracle (version 6.3 and later) on page
463

refresh_with_referential_integrity
VersionInfoSphere CDC for Oracle version 6.3 and later

Use this system parameter to indicate whether or not you want the data removed
from all the target tables being refreshed before repopulating any of them. This is
most useful when there are referential integrity constraints on the tables being
refreshed.

Set this parameter to one of the following:

v trueIndicates that InfoSphere CDC will first remove all data in reverse of the
specified refresh order. When specifying the refresh order, in general parent
tables should appear before the referenced child tables. The product will then
remove data from the child tables before the parent tables.
v falseIndicates that InfoSphere CDC will not first remove all data from your
tables and will refresh the tables in the specified order.

Applies ToSource

Default Settingfalse

trim_char_to_varchar
VersionInfoSphere CDC for Oracle version 6.3 and later

System parameters for InfoSphere CDC for Oracle (version 6.3 and later) 479
 Use this system parameter to specify whether or not InfoSphere CDC should strip
or leave trailing blanks on string data of the column in the target table.

Set this parameter to one of the following:

v trueInfoSphere CDC strips the data of trailing blanks.
v falseInfoSphere CDC does not strip the string data of trailing blanks.

Applies ToTarget

Default Settingfalse
Related concepts
System parameters for InfoSphere CDC for Oracle (version 6.3 and later) on page
463

trim_varchar_to_varchar
VersionInfoSphere CDC for Oracle version 6.3 and later

Use this system parameter to specify whether or not InfoSphere CDC should strip
or leave trailing blanks on string data of the column in the target table.

Set this parameter to one of the following:

v trueInfoSphere CDC strips the data of trailing blanks.
v falseInfoSphere CDC does not strip the string data of trailing blanks.

Applies ToTarget

Default Settingfalse
Related concepts
System parameters for InfoSphere CDC for Oracle (version 6.3 and later) on page
463

userexit_max_lob_size_kb
VersionInfoSphere CDC for Oracle version 6.3 and later

Use this system parameter to set the maximum size of LOB data (in kb) that
InfoSphere CDC can pass to a user exit.

Applies ToTarget

Default Setting128 kb

Maximum9223372036854775807 kb

Minimum1 kb
Related concepts
System parameters for InfoSphere CDC Event Server on page 609
Setting system parameters on source and target datastores on page 71

480 InfoSphere Change Data Capture Management Console: Administration Guide

System parameters for InfoSphere CDC for Oracle - Trigger
(version 6.3 and later)
System parameters let you control the behavior of InfoSphere CDC. If your
replication environment requires a particular configuration, then you can use
system parameters to modify the behavior of default operations in InfoSphere
CDC. The default system parameter settings are appropriate for most installations.
Maintain these default settings until you become familiar with the configuration of
InfoSphere CDC.

InfoSphere CDC provides system parameters that control the behavior of your
source and target datastores.

Note: If you make changes to a system parameter during active replication, you
must stop and restart replication for the changes to take effect.

In this section, you will learn:

General product system parameters
Notification system parameters on page 482
Maximize throughput system parameters on page 483
Database journal (trigger) system parameters on page 484
Encoding system parameters on page 484
Disk resource system parameters on page 485
Apply process system parameters on page 486

General product system parameters

General product system parameters let you control basic features of InfoSphere
CDC and information you may have specified during installation.

See also:
mirror_auto_restart_interval_minutes

mirror_auto_restart_interval_minutes
VersionInfoSphere CDC for Oracle - Trigger version 6.3 Fix Pack 3 TFE 9 and
later.

Use this parameter to indicate how long (in minutes) InfoSphere CDC will attempt
to automatically restart continuous mirroring for persistent subscriptions.

Applies ToSource

Default0

Minimum0

Maximum60

Copyright IBM Corp. 2008, 2011 481

Notification system parameters
Notification system parameters let you control if you should generate InfoSphere
CDC messages in the Event Log for specific events.

See also:
events_max_retain
global_conversion_not_possible_warning
global_shutdown_after_no_heartbeat_response_minutes

events_max_retain
VersionInfoSphere CDC for Oracle - Trigger version 6.3 and later

Use this system parameter to control the maximum number of events that
InfoSphere CDC will store in the event log. If InfoSphere CDC generates more
events than the specified maximum, then the earliest events will be deleted.

Default Setting10000

Minimum -1

Maximum2147483647

global_conversion_not_possible_warning
VersionInfoSphere CDC for Oracle - Trigger version 6.3 and later

Use this system parameter to control whether or not InfoSphere CDC generates a
warning in the Management Console Event Log in the following situations:
v Data conversion is not possible for a specific data value.
v Converted data types are encountered that are out of range.

Set this parameter to one of the following:

v trueGenerates a warning in the Event Log if data conversion is not possible
for a specific data value or converted data types are encountered that are out of
range.
v falseDoes not generate a warning in the Event Log if data conversion is not
possible for a specific data value or converted data types are encountered that
are out of range.

Applies ToTarget

Default Settingfalse

global_shutdown_after_no_heartbeat_response_minutes
VersionInfoSphere CDC for Oracle - Trigger version 6.3 and later

Use this system parameter to specify the duration, in minutes, of communication

inactivity before active InfoSphere CDC processes for a subscription are stopped. If
a value outside the acceptable range is specified, the default setting is used.

482 InfoSphere Change Data Capture Management Console: Administration Guide

 Applies ToSource

Default Setting15 minutes

Minimum Setting3 minutes

Maximum Setting999 minutes

Maximize throughput system parameters

InfoSphere CDC system parameters allow you to significantly reduce the workload
of the target database during mirroring. The InfoSphere CDC apply process groups
transactions on the target to reduce the workload. Every commit on the target
database will correspond with a commit on the target. However, it may not
perform every commit that was done on the source. For example, if the source
does three small transactions containing one operation each, the target may commit
all three operations as part of a single transaction. You can use this grouping of
system parameters to significantly reduce the resources required by the target
database. The default settings are appropriate for most databases, but if your target
system has limited resources and an increase in latency is acceptable, you can
adjust the settings appropriately.

See also:
mirror_interim_commit_threshold
refresh_commit_after_max_operations

mirror_interim_commit_threshold
VersionInfoSphere CDC for Oracle - Trigger version 6.3 Fix Pack 3 and later.

By default, InfoSphere CDC guarantees transactional delivery of change data to the

target. This ensures that if any data from a source transaction is committed to the
target, then all other in scope operations from that source transaction are
committed as well.

In cases where large transactions are done on the source system, it can be more
efficient to break a large transaction into smaller transactions when applying data
to the target. You can configure this behavior using this system parameter.

The default value of 0 for this system parameter indicates that the product
guarantees transactional delivery of change data to the target. A value greater than
0 indicates that you want InfoSphere CDC to break up large transactions into
smaller transactions. For example, a value of 2000 indicates that InfoSphere CDC
will split up large source transactions so that each transaction committed to the
target database contains no more than 2000 operations.

Applies ToTarget

Default Setting0

Minimum Setting0

refresh_commit_after_max_operations
VersionInfoSphere CDC for Oracle - Trigger version 6.3 and later

System parameters for InfoSphere CDC for Oracle - Trigger (version 6.3 and later) 483
 This system parameter identifies the number of rows comprising each transaction
during refresh. To reduce the workload on the target database during refresh,
InfoSphere CDC periodically commits the changes to the target database rather
than performing the refresh as a single large transaction.

Applies ToTarget

Default Setting1000

Maximum Setting2147483647

Minimum Setting1

Database journal (trigger) system parameters

Database journal or trigger system parameters let you manage the InfoSphere CDC
journal table.

See also:
mirror_journal_schema

mirror_journal_schema
VersionInfoSphere CDC for Oracle - Trigger version 6.3 and later

Use this system parameter to enable multiple instances of InfoSphere CDC to share
the same trigger and journal table. To enable this system parameter, you must
specify the name of the journal that you want shared with another instance of
InfoSphere CDC. For example, if you have created an instance INSTANCE1 that
specifies the journal SCHEMA1, and created another instance INSTANCE2 that
specifies the journal SCHEMA2, then you would set the system parameter
mirror_journal_schema on INSTANCE2 so that it points to the journal SCHEMA1.
This enables both instances to share the same trigger and journal table. You can
only set a value for this system parameter before mapping your tables and setting
the subscription for mirroring. The value of this system parameter must refer to
the name of an existing journal table.

Applies ToSource

Default SettingNot applicable

Encoding system parameters

For some system parameters, you can set the default method for treating data in
defined Unicode columns, and you can set the default character encoding for your
database.

See also:
global_unicode_as_char

global_unicode_as_char
VersionInfoSphere CDC for Oracle - Trigger version 6.3 and later

484 InfoSphere Change Data Capture Management Console: Administration Guide

 This system parameter indicates the default method of treating data in defined
Unicode columns. For each InfoSphere CDC installation on a server, this system
parameter defines the system default method of treating data in Unicode columns.
If a Unicode column is set to System Default on the Encoding tab of the Mapping
Details view in Management Console, InfoSphere CDC uses the method for
processing Unicode columns that you select in this system parameter.

Set this parameter to one of the following:

v trueInfoSphere CDC treats all data in Unicode columns as single-byte
characters. Use this setting when Unicode columns contain single-byte character
data.
v falseInfoSphere CDC treats all data in Unicode columns as a continuous bit
stream. Use this setting when Unicode columns contain non-single-byte
character data. Setting this system parameter to false ensures that InfoSphere
CDC handles non-single-byte character data in the same way as previous
InfoSphere CDC releases.

Note: Setting this parameter to false does not ensure that replicated
non-single-byte character data in Unicode columns are represented properly on
the target. For replicated non-single-byte character data, you may have to apply
user exit programs or other customizations to properly represent data in
Unicode columns. For more information about user exit programs, see the
InfoSphere CDC End-User Documentation for your platform.

Applies ToSource

Default Settingfalse

For information about how data in each Unicode source column is treated and
setting multibyte and Unicode character set conversions, see Replicating multibyte
(MBCS) and double-byte (DBCS) character data on page 163.

Disk resource system parameters

Some system parameters control memory usage in InfoSphere CDC. For improved
performance, if you are able to allocate more than the default value of 512 MB for
the InfoSphere CDC Java Virtual Machine, then you can adjust the disk resource
system parameters to use the increased memory.

See also:
mirror_global_disk_quota_mb
mirror_global_disk_quota_gb on page 486

mirror_global_disk_quota_mb
VersionInfoSphere CDC for Oracle - Trigger version 6.3

Use this system parameter to globally set a disk quota (in MB) for all capture
components including temporary files, transaction queues, and LOBs which are
staged on the target before being applied. InfoSphere CDC will manage disk space
utilization across all components as required.

Most databases have a mechanism that allows you to roll back or undo changes to
your database by storing uncommitted changes. Similarly, InfoSphere CDC uses
the disk quota controlled by this system parameter to store in scope change data
System parameters for InfoSphere CDC for Oracle - Trigger (version 6.3 and later) 485
 that has not been committed in your database. Once the database transaction is
committed, the disk space used by the transaction is released. Note that InfoSphere
CDC stores the data in memory to improve performance and will only persist the
data to disk if memory is unavailable.

The default setting of this system parameter is such that the product will only stop
replicating after this disk quota exhausts all available disk space on your system. If
you would prefer the product to stop replicating after it uses a specific amount of
disk space, you can set the value with this system parameter.

Applies ToSource and Target

Default Setting9223372036854775807

Maximum9223372036854775807

Minimum100

mirror_global_disk_quota_gb
VersionInfoSphere CDC for Oracle - Trigger version 6.5

Use this system parameter to globally set a disk quota (in GB) for all capture
components including temporary files, transaction queues, and LOBs which are
staged on the target before being applied. InfoSphere CDC will manage disk space
utilization across all components as required.

Most databases have a mechanism that allows you to roll back or undo changes to
your database by storing uncommitted changes. Similarly, InfoSphere CDC uses
the disk quota controlled by this system parameter to store in scope change data
that has not been committed in your database. Once the database transaction is
committed, the disk space used by the transaction is released. Note that InfoSphere
CDC stores the data in memory to improve performance and will only persist the
data to disk if memory is unavailable.

The default setting of this system parameter is such that the product will only stop
replicating after this disk quota exhausts all available disk space on your system. If
you would prefer the product to stop replicating after it uses a specific amount of
disk space, you can set the value with this system parameter.

Applies ToSource and Target

Default Setting9223372036854775807

Maximum9223372036854775807

Minimum1

Apply process system parameters

Some system parameters adjust the way InfoSphere CDC applies rows, column
data, and error handling.

See also:
convert_not_nullable_column on page 487

486 InfoSphere Change Data Capture Management Console: Administration Guide

 convert_not_nullable_message
global_max_batch_size on page 488
mirror_end_on_error on page 488
mirror_expected_errors_list on page 488
refresh_end_on_error on page 489
refresh_expected_errors_list on page 489
refresh_in_unicode on page 490
refresh_with_referential_integrity on page 490
trim_char_to_varchar on page 490
trim_varchar_to_varchar on page 491
userexit_max_lob_size_queue_kb on page 491

convert_not_nullable_column
VersionInfoSphere CDC for Oracle - Trigger version 6.3 and later

Use this system parameter to control how InfoSphere CDC behaves when it applies
a null value to a non-nullable column. When set to true (default value), the null
value will be replaced with a default value (based on the data type of the column)
and InfoSphere CDC will generate a warning in the event log. When set to false,
InfoSphere CDC applies the null value directly to the non-nullable column which
will result in an error and cause a shutdown of InfoSphere CDC on the target
database.

Note: If you decided to set this system parameter to false and have specified this
as an error for InfoSphere CDC to ignore using the mirror_expected_errors_list
system parameter, then InfoSphere CDC will ignore the error and not shutdown.

Set this parameter to one of the following:

v trueNull value will be replaced with default value for non-nullable column,
and a warning event will be logged.
v falseNull data will be applied as-is to non-nullable column and database will
usually return an error code.

Applies ToSource and Target

Default SettingTrue

convert_not_nullable_message
VersionInfoSphere CDC for Oracle - Trigger version 6.3 and later

Use this system parameter to determine if a message will be generated in the

Event Log when InfoSphere CDC converts a null value to a default value when
applied to a non-nullable column. When set to true (default value), InfoSphere
CDC will log the event the first time it encounters a null to non-nullable mapping
(on a per column per table basis). When set to false, InfoSphere CDC will not
generate a message when a null value is converted to a default value.

Note: This system parameter applies only when the convert_not_nullable_column

parameter has been set to true.

System parameters for InfoSphere CDC for Oracle - Trigger (version 6.3 and later) 487
 Set this parameter to one of the following:
v trueGenerates a warning message in the Event Log the first time a null value
is converted to a default value on a per column per table basis.
v falseNo warning message is generated in the Event Log.

Applies ToTarget

Default SettingTrue

global_max_batch_size
VersionInfoSphere CDC for Oracle - Trigger version 6.3 and later

Use this system parameter to specify the maximum number of rows that
InfoSphere CDC can place in an array and apply to the target database during
refresh or mirroring. InfoSphere CDC collects rows and places them in an array (in
memory) while receiving table-level operations from the source system. InfoSphere
CDC applies the rows from the array when there is a change to a different table,
when there is a new table-level operation, or when the maximum number of rows
in an array has been reached. You can use this parameter during mirroring only if
mirror_end_on_error is true and mirror_expected_errors_list is empty. Use only
during a refresh if refresh_end_on_error is true and refresh_expected_errors_list is
empty. Before InfoSphere CDC places rows into an array, it allocates memory for
the maximum number of rows you specify and multiplies this integer by the
maximum length of a row. If the maximum number of rows is too large, then
InfoSphere CDC cannot allocate enough memory and will shut down. Management
Console references this area to present replication latency information.

Applies ToTarget

Default Setting25 rows

Maximum Setting2147483647 rows

Minimum Setting1 row

mirror_end_on_error
VersionInfoSphere CDC for Oracle - Trigger version 6.3 and later

Use this system parameter to indicate if you want to end mirroring after an apply
error occurs on the target database.

Set this parameter to one of the following:

v trueEnd mirroring after an apply error on the target database.
v falseDo not end mirroring after an apply error on the target database.

Applies ToTarget

Default SettingTrue

mirror_expected_errors_list
VersionInfoSphere CDC for Oracle - Trigger version 6.3 and later

488 InfoSphere Change Data Capture Management Console: Administration Guide

 Use this system parameter when you want InfoSphere CDC to ignore one or more
database errors when applying data changes to the target during mirroring. The
error specified must correspond to the integer error code (database-vendor specific)
returned by the SQLException class in JDBC (Java Database Connectivity). Specify
multiple errors with a comma separated list of integer error codes.

For example, if you want InfoSphere CDC to continue mirroring when it

encounters primary key violations in your Oracle target database, set this
parameter to mirror_expected_errors_list=1. The integer error code of 1
corresponds to the Oracle error: ORA-00001: unique constraint violated
(<schema>.<constraint>). If you also want to ignore ORA-01407: cannot update
(string) to NULL, set this parameter to mirror_expected_errors_list=1,1407.

Note: Latency may increase when using this system parameter since InfoSphere
CDC will not use JDBC array apply in order to track the errors specified.

Applies ToTarget

refresh_end_on_error
VersionInfoSphere CDC for Oracle - Trigger version 6.3 and later

Use this system parameter to indicate if you want to end a refresh after an apply
error occurs.

Set this parameter to one of the following:

v trueEnd a refresh after an apply error occurs.
v falseDo not end a refresh after an apply error occurs.

Applies ToTarget

Default SettingTrue

refresh_expected_errors_list
VersionInfoSphere CDC for Oracle - Trigger version 6.3 and later

Use this system parameter when you want InfoSphere CDC to ignore one or more
database errors when refreshing data to the target. The error specified must
correspond to the integer error code (database-vendor specific) returned by the
SQLException class in JDBC (Java Database Connectivity). Specify multiple errors
with a comma separated list of integer error codes.

For example, if you want InfoSphere CDC to continue refresh when it encounters
primary key violations in your Oracle target database, set this parameter to
mirror_expected_errors_list=1. The integer error code of 1 corresponds to the
Oracle error: ORA-00001: unique constraint violated (<schema>.<constraint>). If
you also want to ignore ORA-01407: cannot update (string) to NULL, set this
parameter to mirror_expected_errors_list=1,1407.

Note: Latency may increase when using this system parameter since InfoSphere
CDC will not use JDBC array apply in order to track the errors specified.

Applies ToTarget

System parameters for InfoSphere CDC for Oracle - Trigger (version 6.3 and later) 489
 refresh_in_unicode
VersionInfoSphere CDC for Oracle - Trigger version 6.3 and later

Use this system parameter when you want InfoSphere CDC to refresh a target
table that contains multibyte object names.

Set this parameter to one of the following:

v trueInfoSphere CDC will refresh the target table that contains multibyte object
names.
v falseInfoSphere CDC will not refresh a target table that contains multibyte
object names.

Applies ToTarget

Default Settingfalse

refresh_with_referential_integrity
VersionInfoSphere CDC for Oracle - Trigger version 6.3 and later

Use this system parameter to indicate whether or not you want the data removed
from all the target tables being refreshed before repopulating any of them. This is
most useful when there are referential integrity constraints on the tables being
refreshed.

Set this parameter to one of the following:

v trueIndicates that InfoSphere CDC will first remove all data in reverse of the
specified refresh order. When specifying the refresh order, in general parent
tables should appear before the referenced child tables. The product will then
remove data from the child tables before the parent tables.
v falseIndicates that InfoSphere CDC will not first remove all data from your
tables and will refresh the tables in the specified order.

Applies ToSource

Default Settingfalse

trim_char_to_varchar
VersionInfoSphere CDC for Oracle - Trigger version 6.3 and later

Use this system parameter to specify whether or not InfoSphere CDC should strip
or leave trailing blanks on string data of the column in the target table.

Set this parameter to one of the following:

v trueInfoSphere CDC strips the data of trailing blanks.
v falseInfoSphere CDC does not strip the string data of trailing blanks.

Applies ToTarget

Default Settingfalse

490 InfoSphere Change Data Capture Management Console: Administration Guide

trim_varchar_to_varchar
VersionInfoSphere CDC for Oracle - Trigger version 6.3 and later

Use this system parameter to specify whether or not InfoSphere CDC should strip
or leave trailing blanks on string data of the column in the target table.

Set this parameter to one of the following:

v trueInfoSphere CDC strips the data of trailing blanks.
v falseInfoSphere CDC does not strip the string data of trailing blanks.

Applies ToTarget

Default Settingfalse

userexit_max_lob_size_queue_kb
VersionInfoSphere CDC for Oracle - Trigger version 6.3 and later

Use this system parameter to set the maximum size of LOB data (in kb) that
InfoSphere CDC can pass to a user exit.

Applies ToTarget

Default Setting128 kb

Maximum9223372036854775807 kb

Minimum1 kb

System parameters for InfoSphere CDC for Oracle - Trigger (version 6.3 and later) 491
492 InfoSphere Change Data Capture Management Console: Administration Guide
System parameters for InfoSphere CDC for Sybase (version
6.0 and earlier)
System parameters let you control the behavior of InfoSphere CDC. If your
replication environment requires a particular configuration, then you can use
system parameters to modify the behavior of default operations in InfoSphere
CDC. The default system parameter settings are appropriate for most installations.

InfoSphere CDC provides system parameters that control the behavior of your
source and target datastores.

Note: If you make changes to a system parameter during active replication, you
must stop and restart replication for the changes to take effect.

In this section, you will learn:

General product system parameters
Apply process system parameters on page 498
Cascading replication system parameters on page 504
Database journal (trigger) system parameters on page 504
Maximize throughput system parameters on page 505
Tracing system parameters on page 508
Notification system parameters on page 510
Disk resource system parameters on page 515
Refresh loader system parameters on page 516

General product system parameters

General product system parameters let you control basic features of InfoSphere
CDC and information you may have specified during installation.

See also:
CODE_PAGE on page 494
D_MIRROR_HOME on page 494
D_MIRROR_LOG on page 494
DM_DYNAMIC_PARAMETER_CHECK_INT on page 494
DM_MAX_MONITOR_ENTRIES on page 495
DSQUERY on page 495
LD_LIBRARY_PATH on page 496
LIBPATH on page 496
PUBLISH_METADATA on page 496
SYBASE on page 497
SYBASE_OCS on page 497
SHLIB_PATH on page 497
STARTUP_TIMEOUT on page 497
USER on page 498

Copyright IBM Corp. 2008, 2011 493

 CODE_PAGE
VersionInfoSphere CDC for Sybase version 6.0 and earlier

Use this system parameter to specify the code page associated with NLS_LANG.
This value is set during installation and should not be modified except under the
guidance of a IBM technical support.

Applies ToSource and Target

Default SettingThe system code page when InfoSphere CDC was installed.
Related concepts
System parameters for InfoSphere CDC for Sybase (version 6.0 and earlier) on
page 493
Related reference
NLS_LANG on page 500

D_MIRROR_HOME
VersionInfoSphere CDC for Sybase version 6.0 and earlier

Use this system parameter to specify the directory (full path) where InfoSphere
CDC is installed on the server.

Applies ToSource and Target

Default SettingThe installation directory specified when InfoSphere CDC was

installed.
Related concepts
System parameters for InfoSphere CDC for Sybase (version 6.0 and earlier) on
page 493

D_MIRROR_LOG
VersionInfoSphere CDC for Sybase version 6.0 and earlier

Use this system parameter to specify the directory (full path) where InfoSphere
CDC log files are located.

Applies ToSource and Target

Default SettingThe log subdirectory in the installation directory specified when

installing InfoSphere CDC.
Related concepts
System parameters for InfoSphere CDC for Sybase (version 6.0 and earlier) on
page 493

DM_DYNAMIC_PARAMETER_CHECK_INT
VersionInfoSphere CDC for Sybase version 6.0 and earlier

494 InfoSphere Change Data Capture Management Console: Administration Guide

 Use this system parameter to specify how often, in seconds, InfoSphere CDC
checks for changes to the values of dynamic system parameters during active
replication to a subscription. For example, to check once a day, set this parameter
to 216,000.

The following system parameters are dynamic:

v D_MIRROR_TRACE on page 509
v D_MIRROR_TRACE_ON_ERROR on page 510 (on the target only)
v DM_PRINT_DIAGNOSTICS on page 450
v STATISTICS_INTERVAL on page 515
v SYNCHRONIZATION_COMMIT_ GROUP_SIZE on page 507
v SYNCHRONIZATION_INTERVAL on page 508

Applies ToSource and Target

Default Setting300 seconds (5 minutes)

Minimum Setting0. InfoSphere CDC does not check for changes to dynamic
system parameters.

Maximum Setting2,147,483,648 (maximum integer)

Related concepts
System parameters for InfoSphere CDC for Sybase (version 6.0 and earlier) on
page 493

DM_MAX_MONITOR_ENTRIES
VersionInfoSphere CDC for Sybase version 6.0 and earlier

Use this system parameter to increase or decrease the number of subscriptions that
InfoSphere CDC can support in the Monitor in Management Console. InfoSphere
CDC allocates an entry for each source and target datastore within a subscription.
For example, if you have a datastore that is being used as a source datastore
within 20 subscriptions and as a target datastore within 10 subscriptions, then you
must set this system parameter to at least 30. InfoSphere CDC will allocate 30
entries for this datastore.

Applies ToSource

Default Setting20 entries. By default, InfoSphere CDC can handle 20

subscriptions.

Minimum Setting1 entry

Maximum Setting1000 entries

DSQUERY
VersionInfoSphere CDC for Sybase version 6.0 and earlier

Use this system parameter to specify the name of the Sybase server.

Applies ToSource and Target

System parameters for InfoSphere CDC for Sybase (version 6.0 and earlier) 495
 LD_LIBRARY_PATH
VersionInfoSphere CDC for Sybase version 6.0 and earlier

Use this system parameter to specify the path to the InfoSphere CDC libraries and
the database libraries for Solaris and Linux operating systems. This value is set
during installation and should not be modified.

Applies ToSource and Target

Default SettingThe path to the InfoSphere CDC libraries and the Sybase libraries
when InfoSphere CDC was installed
Related concepts
System parameters for InfoSphere CDC for Sybase (version 6.0 and earlier) on
page 493

LIBPATH
VersionInfoSphere CDC for Sybase version 6.0 and earlier

Use this system parameter to specify the path to the InfoSphere CDC libraries and
the database libraries (for AIX operating systems). This value is set during
installation and should not be modified.

Applies ToSource and Target

Default SettingThe path to the InfoSphere CDC libraries and the database
libraries when InfoSphere CDC was installed.
Related concepts
System parameters for InfoSphere CDC for Sybase (version 6.0 and earlier) on
page 493

PUBLISH_METADATA
VersionInfoSphere CDC for Sybase version 6.0 and earlier

Use this system parameter to enable or disable the display of InfoSphere CDC
metadata tables in Management Console.

Applies ToSource

Set this parameter to one of the following:

v OFFInfoSphere CDC metadata tables are not displayed in Management
Console.
v ONInfoSphere CDC metadata tables are displayed in the Add/Remove Tables
dialog box, making them available to be selected for replication.

Default SettingOFF

496 InfoSphere Change Data Capture Management Console: Administration Guide

 Related concepts
System parameters for InfoSphere CDC for Sybase (version 6.0 and earlier) on
page 493

SYBASE
VersionInfoSphere CDC for Sybase version 6.0 and earlier

Use this system parameter to specify the Sybase home directory. This value is set
during the installation and should not be modified.

Applies ToSource and Target

Related concepts
System parameters for InfoSphere CDC for Sybase (version 6.0 and earlier) on
page 493

SYBASE_OCS
VersionInfoSphere CDC for Sybase version 6.0 and earlier

Use this system parameter to specify the Sybase Open Client directory. This value
is set during the installation and should not be modified.

Applies ToSource and Target

Related concepts
System parameters for InfoSphere CDC for Sybase (version 6.0 and earlier) on
page 493

SHLIB_PATH
VersionInfoSphere CDC for Sybase version 6.0 and earlier

Use this system parameter to specify the path to the InfoSphere CDC libraries and
the database libraries for HP-UX operating systems. This value is set during
installation and should not be modified.

Applies ToSource and Target

Default SettingThe path to the InfoSphere CDC libraries and the database
libraries when InfoSphere CDC was installed.
Related concepts
System parameters for InfoSphere CDC for Sybase (version 6.0 and earlier) on
page 493

STARTUP_TIMEOUT
VersionInfoSphere CDC for Sybase version 6.0 and earlier

Use this system parameter to specify the maximum waiting period, in seconds, for
process handling to complete during InfoSphere CDC startup. It indicates how
long the InfoSphere CDC communication module waits for the database
initialization program to start before timing out.

System parameters for InfoSphere CDC for Sybase (version 6.0 and earlier) 497
 Applies ToSource and Target. Target only for InfoSphere CDC for Teradata.

Default Setting120

Minimum Setting60

Maximum Setting3600
Related concepts
System parameters for InfoSphere CDC for Sybase (version 6.0 and earlier) on
page 493

USER
VersionInfoSphere CDC for Sybase version 6.0 and earlier

Use this system parameter to specify the database user name that was specified
during installation. You can also set this user using the dmsetpass command.

Applies ToSource

Default SettingThe InfoSphere CDC user specified when InfoSphere CDC was
installed.
Related concepts
System parameters for InfoSphere CDC for Sybase (version 6.0 and earlier) on
page 493

Apply process system parameters

Some system parameters adjust the way InfoSphere CDC applies rows, column
data, and error handling.

See also:
convertNotNullableColumns
D_MIRROR_MIRROR_ERROR_STOP on page 499
D_MIRROR_REFRESH_ERROR_STOP on page 499
FILTER_NOCHANGE_UPDATES_FOR_AUDIT on page 500
NLS_LANG on page 500
TRANSACTION_GROUP_SIZE on page 500
TRANSACTION_INTERVAL on page 501
TRANSACTION_RECORDS_THRESHOLD on page 502
TRIM_CHAR_TO_VARCHAR on page 502
TRIM_VARCHAR_TO_VARCHAR on page 502
TRIM_TO_NULL on page 503

convertNotNullableColumns
VersionInfoSphere CDC for Sybase version 6.0 and earlier

Use this system parameter to indicate whether or not NULL values will be
converted to default values when replicating data that contains NULL values to
non-nullable target columns.

498 InfoSphere Change Data Capture Management Console: Administration Guide

 Applies ToTarget

Set this parameter to one of the following:

v OFFAn error message will be generated in Event Log. Replication will
continue or not based on whether the MirrorError or RefreshError system
parameters are set to END or ON.
v ONInfoSphere CDC will automatically insert an appropriate default value in
the target column. No error message is generated in Event Log and replication
continues.
Depending on the convertNotNullableMsg system parameter setting, a warning
message may be generated in Event Log.
The default value depends on the data type of the subscription column. For
example, zero for numeric data types, blank character for character data types,
1901-01-01 for date data types, and so on.

Default SettingOFF

D_MIRROR_MIRROR_ERROR_STOP
VersionInfoSphere CDC for Sybase version 6.0 and earlier

Use this parameter to indicate whether or not mirroring continues after an error
has occurred during a row insert, delete, or update operation.

Applies ToTarget

Set this parameter to one of the following:

v ONMirroring stops after an error has occurred.
v OFFMirroring continues after an error has occurred.

Default SettingON
Related concepts
System parameters for InfoSphere CDC for Sybase (version 6.0 and earlier) on
page 493
Related reference
D_MIRROR_REFRESH_ERROR_STOP

D_MIRROR_REFRESH_ERROR_STOP
VersionInfoSphere CDC for Sybase version 6.0 and earlier

Use this system parameter to indicate whether or not InfoSphere CDC should
continue to perform a refresh after encountering an error during a row insert
operation.

Applies ToTarget

Set this parameter to one of the following:

v ONData refresh stops after an error has occurred.
v OFFData refresh continues after an error has occurred.

Default SettingON

System parameters for InfoSphere CDC for Sybase (version 6.0 and earlier) 499
 Related concepts
System parameters for InfoSphere CDC for Sybase (version 6.0 and earlier) on
page 493
Related reference
D_MIRROR_MIRROR_ERROR_STOP on page 499

FILTER_NOCHANGE_UPDATES_FOR_AUDIT
VersionInfoSphere CDC for Sybase version 6.0 and earlier

Use this system parameter to indicate whether or not updates that have identical
before and after column images (that is, the row has been updated to the same
value), are replicated to the target table for any tables configured for LiveAudit
replication.

Applies ToSource

Set this parameter to one of the following:

v OFFIf a row in a source table is updated to the same value, InfoSphere CDC
replicates the value to the target table.
v ONIf a row in a source table is updated to the same value, InfoSphere CDC
does not replicate the value to the target table.

This parameter only affects tables that are configured for LiveAudit replication. For
non-audit tables, only updates that change the column data are replicated to the
target tables.

Default SettingOFF
Related concepts
System parameters for InfoSphere CDC for Sybase (version 6.0 and earlier) on
page 493

NLS_LANG
VersionInfoSphere CDC for Sybase version 6.0 and earlier

Use this system parameter to specify the database character set preceded with a
period. For more information about setting this system parameter, see your IBM
representative.

Applies ToSource and Target

Default SettingThe database character set, preceded with a period,

corresponding to the language selected when the database was installed.
Related concepts
System parameters for InfoSphere CDC for Sybase (version 6.0 and earlier) on
page 493

TRANSACTION_GROUP_SIZE
VersionInfoSphere CDC for Sybase version 6.0 and earlier

500 InfoSphere Change Data Capture Management Console: Administration Guide

 Use this system parameter to specify the number of complete transactions applied
to the database before InfoSphere CDC issues a commit. Use the
TRANSACTION_GROUP_SIZE, TRANSACTION_INTERVAL, and
TRANSACTION_RECORDS_THRESHOLDS system parameters together. InfoSphere CDC
issues a commit after applying the number of transactions specified by the
TRANSACTION_GROUP_SIZE, or when the time interval specified by
TRANSACTION_INTERVAL has elapsed. Setting only one of these system parameters
without the other can result in uncommitted transactions on the target.

Applies ToTarget

Default Setting500

Minimum Setting0

Guidelines

To increase the throughput, set to a number of transactions that would be received

when busy during the TRANSACTION_INTERVAL.

Note: Use this parameter only if InfoSphere CDC is running under commitment
control. The COMMIT_LEVEL system parameter should be set to2 on the target
database, and the MAINTAIN_TRANSACTION_CONSISTENCY system parameter should be
set to ON on the source database.
Related concepts
System parameters for InfoSphere CDC for Sybase (version 6.0 and earlier) on
page 493

TRANSACTION_INTERVAL
VersionInfoSphere CDC for Sybase version 6.0 and earlier

Use this system parameter to specify the time interval, in seconds, that can elapse
between transactions before InfoSphere CDC issues a commit. If there are no
transactions received by the target system, then InfoSphere CDC issues a commit
immediately. Use this system parameter with the TRANSACTION_GROUP_SIZE system
parameter. InfoSphere CDC issues a commit after applying the number of
transactions specified by the TRANSACTION_GROUP_SIZE system parameter, or when
the time interval specified by TRANSACTION_INTERVAL system parameter has elapsed.
Setting only one of these system parameters without the other can result in
uncommitted transactions on the target.

Applies ToTarget

Default Setting1

Minimum Setting0

Guidelines

InfoSphere CDC issues a commit only when a commit is received by the target
system and you have reached the transaction group size, or exceeded the time
interval, or exceeded the records threshold.

System parameters for InfoSphere CDC for Sybase (version 6.0 and earlier) 501
 Related concepts
System parameters for InfoSphere CDC for Sybase (version 6.0 and earlier) on
page 493

TRANSACTION_RECORDS_THRESHOLD
VersionInfoSphere CDC for Sybase version 6.0 and earlier

Use this system parameter to specify the maximum number of operations within a
transaction or group of transactions before InfoSphere CDC issues a commit

Applies ToTarget

Default Setting3000

Minimum Setting0
Related concepts
System parameters for InfoSphere CDC for Sybase (version 6.0 and earlier) on
page 493

TRIM_CHAR_TO_VARCHAR
VersionInfoSphere CDC for Sybase version 6.0 and earlier

Use this system parameter to specify whether or not trailing blank characters are
trimmed from source columns of CHAR data type when replicating data to target
columns of VARCHAR data type.

Applies ToTarget

Set this parameter to one of the following:

v OFFTrailing blanks are not trimmed.
v ONTrailing blanks are trimmed. If TRIM_TO_NULL =OFF, InfoSphere CDC inserts
a single blank character in the target column. If TRIM_TO_NULL =ON and the target
column is nullable, InfoSphere CDC inserts NULL in the column.

Default SettingOFF
Related concepts
System parameters for InfoSphere CDC for Sybase (version 6.0 and earlier) on
page 493
Related reference
TRIM_TO_NULL on page 503

TRIM_VARCHAR_TO_VARCHAR
VersionInfoSphere CDC for Sybase version 6.0 and earlier

Use this system parameter to specify whether or not trailing blank characters are
trimmed from source columns of VARCHAR data type when replicating data to
target columns of VARCHAR data type.

Applies ToTarget

502 InfoSphere Change Data Capture Management Console: Administration Guide

 Set this parameter to one of the following:
v OFFTrailing blanks are not trimmed.
v ONTrailing blanks are trimmed. If TRIM_TO_NULL =OFF, InfoSphere CDC inserts
a single blank character in the target column. If TRIM_TO_NULL =ON and the target
column is nullable, InfoSphere CDC inserts NULL in the column.

Default SettingOFF
Related concepts
System parameters for InfoSphere CDC for Sybase (version 6.0 and earlier) on
page 493
Related reference
TRIM_TO_NULL

TRIM_TO_NULL
VersionInfoSphere CDC for Sybase version 6.0 and earlier

Use this system parameter to specify how source columns that contain blank
characters only are handled during data replication.

Applies ToTarget

Set this parameter to one of the following:

v OFFFor data mapped to VARCHAR columns, trailing blanks are trimmed or
not to a single blank depending on the TRIM_CHAR_TO_VARCHAR and
TRIM_VARCHAR_TO_VARCHAR system parameters. For data mapped to CHAR
columns, setting this parameter to OFF has no effect.
v ONFor data mapped to CHAR columns, if the target column is nullable,
InfoSphere CDC inserts NULL in the column. For CHAR data mapped to
VARCHAR columns, if TRIM_CHAR_TO_VARCHAR =ON and the target column is
nullable, InfoSphere CDC inserts NULL in the column. For VARCHAR data
mapped to VARCHAR columns, if TRIM_VARCHAR_TO_VARCHAR =ON and the target
column is nullable, InfoSphere CDC inserts NULL in the column.

If the target column is non-nullable, source columns that contain blank characters
only are handled according to the convertNotNullableColumns system parameter.

The table below explains how the TRIM_ system parameters affect the data
replicated to the target for source columns that contain blank characters only.

TRIM_ parameter settings Target data

TRIM_CHAR_ TO_ TRIM_ VARCHAR_ TRIM_ TO_ CHAR to VARCHAR Any data
VARCHAR TO_ VARCHAR NULL VARCHAR to type to
VARCHAR CHAR
ON ON ON NULL NULL NULL
ON OFF ON NULL Source data NULL
OFF ON ON Source data NULL NULL
OFF OFF ON Source data Source data NULL
ON ON OFF Single blank Single blank Blanks
ON OFF OFF Single blank Source data Blanks
OFF ON OFF Source data Single blank Blanks

System parameters for InfoSphere CDC for Sybase (version 6.0 and earlier) 503
 TRIM_ parameter settings Target data
OFF OFF OFF Source data Source data Blanks

Default SettingOFF
Related concepts
System parameters for InfoSphere CDC for Sybase (version 6.0 and earlier) on
page 493
Related reference
TRIM_CHAR_TO_VARCHAR on page 502
TRIM_VARCHAR_TO_VARCHAR on page 502

Cascading replication system parameters

Cascading replication system parameters control InfoSphere CDC cascading
replication.

See also:
PREVENT_RECURSION

PREVENT_RECURSION
VersionInfoSphere CDC for Sybase version 6.0 and earlier

Use this parameter to indicate whether or not to prevent cascading replication for
bidirectional configurations.

Applies ToSource

Set this parameter to one of the following:

v ONChanges applied by InfoSphere CDC are not be replicated back to the
source database from where it came from.
v OFFChanges made by InfoSphere CDC are replicated, except when filtered out
by the CASCADE_OMIT_TARGETS system parameter.

Default SettingON
Related concepts
System parameters for InfoSphere CDC for Sybase (version 6.0 and earlier) on
page 493

Database journal (trigger) system parameters

Database journal or trigger system parameters let you manage the InfoSphere CDC
journal table.

See also:
REPORT_POSITION_INTERVAL

REPORT_POSITION_INTERVAL
VersionInfoSphere CDC for Sybase version 6.0 and earlier

504 InfoSphere Change Data Capture Management Console: Administration Guide

 Use this system parameter to specify how often (in seconds) the source informs the
target about its position in the current journal during times of no activity. During
times of no activity, when there are no journal entries to be processed pertaining to
the current subscription, the source informs the target of its current position so that
the target can advance its bookmarks accordingly. By specifying a low setting for
this parameter, the target can reflect more accurately how far replication has
progressed.

Applies ToSource

After a shutdown and restart, you can use this system parameter to prevent
InfoSphere CDC from rereading entries that do not apply to the current replication
configuration.

The value of this parameter affects the information that is displayed in progress
and bookmark messages. A high value for this parameter may result in
information that is not up-to-date being displayed.

Default Setting5

Minimum Setting1

Maximum Setting300
Related concepts
System parameters for InfoSphere CDC for Sybase (version 6.0 and earlier) on
page 493

Maximize throughput system parameters

InfoSphere CDC system parameters allow you to significantly reduce the workload
of the target database during mirroring. The InfoSphere CDC apply process groups
transactions on the target to reduce the workload. Every commit on the target
database will correspond with a commit on the target. However, it may not
perform every commit that was done on the source. For example, if the source
does three small transactions containing one operation each, the target may commit
all three operations as part of a single transaction. You can use this grouping of
system parameters to significantly reduce the resources required by the target
database. The default settings are appropriate for most databases, but if your target
system has limited resources and an increase in latency is acceptable, you can
adjust the settings appropriately.

See also:
COMMIT_GROUP_SIZE
COMMIT_INTERVAL on page 506
SYNCHRONIZATION_COMMIT_ GROUP_SIZE on page 507
SYNCHRONIZATION_INTERVAL on page 508

COMMIT_GROUP_SIZE
VersionInfoSphere CDC for Sybase version 6.0 and earlier

System parameters for InfoSphere CDC for Sybase (version 6.0 and earlier) 505
 Use this system parameter to specify the minimum number of rows InfoSphere
CDC should apply to the database before a commit is issued. InfoSphere CDC
issues a commit on the target when the transaction that contains the rows
completes.

Use the COMMIT_GROUP_SIZE and COMMIT_INTERVAL system parameters together.

InfoSphere CDC issues a commit when either when the number of rows specified
by COMMIT_GROUP_SIZE has been applied to the target, or when the time interval
specified by COMMIT_INTERVAL has elapsed. Setting only one of these system
parameters without the other can result in uncommitted data on the target.

Applies ToTarget

Default Setting5000

Minimum Setting0. InfoSphere CDC does not use commit groups to apply data
to the target.

Guidelines

Set this parameter to 0 if D_MIRROR_MIRROR_ERROR_STOP=OFF. If a rollback occurs,

InfoSphere CDC rolls back all outstanding rows in the commit group. Since
InfoSphere CDC is set to continue on error, you may lose data.

Note: Use this parameter only if InfoSphere CDC is not running under
commitment control (COMMIT_LEVEL =0).
Related concepts
System parameters for InfoSphere CDC for Oracle (version 6.2 and earlier) on
page 421
System parameters for InfoSphere CDC for Sybase (version 6.0 and earlier) on
page 493
Related reference
COMMIT_INTERVAL on page 444
COMMIT_LEVEL on page 444
D_MIRROR_MIRROR_ERROR_STOP on page 433
COMMIT_INTERVAL
D_MIRROR_MIRROR_ERROR_STOP on page 499

COMMIT_INTERVAL
VersionInfoSphere CDC for Sybase version 6.0 and earlier

Use this system parameter to specify the time interval between commits, in
seconds, to limit the number of commits InfoSphere CDC issues on the target
database. Use the COMMIT_GROUP_SIZE and COMMIT_INTERVAL system parameters
together. InfoSphere CDC issues a commit when either when the number of rows
specified by COMMIT_GROUP_SIZE has been applied to the target, or when the time
interval specified by COMMIT_INTERVAL has elapsed. Setting only one of these system
parameters without the other can result in uncommitted data on the target.

When the COMMIT_INTERVAL time expires, InfoSphere CDC issues a commit on the
target database for transactions that completed within that time interval.

506 InfoSphere Change Data Capture Management Console: Administration Guide

 Applies ToTarget

Default Setting60

Minimum Setting0. InfoSphere CDC issues a commit on a target database for

each completed transaction.

Guidelines

Set this parameter to 0 if D_MIRROR_MIRROR_ERROR_STOP=OFF. If a rollback occurs,

InfoSphere CDC rolls back all outstanding rows in the commit group. Since
InfoSphere CDC is set to continue on error, you may lose data.

Note: Use this parameter only if InfoSphere CDC is not running under
commitment control (COMMIT_LEVEL =0).
Related concepts
System parameters for InfoSphere CDC for Sybase (version 6.0 and earlier) on
page 493
Related reference
COMMIT_GROUP_SIZE on page 505
D_MIRROR_MIRROR_ERROR_STOP on page 499

SYNCHRONIZATION_COMMIT_ GROUP_SIZE
VersionInfoSphere CDC for Sybase version 6.0 and earlier

Use this system parameter to specify the number of transactions applied to the
database before InfoSphere CDC performs synchronization between the source and
target.

Applies ToSource and Target

The SYNCRONIZATION_COMMIT_GROUP_SIZE and SYNCHRONIZATION_INTERVAL system

parameters are intended to be used together. Synchronization occurs either when
the number of transactions (specified by SYNCRONIZATION_COMMIT_GROUP_SIZE) have
been applied or when the time interval (specified by SYNCHRONIZATION_INTERVAL)
has elapsed, whichever comes first.

Default Setting128

Minimum Setting0. InfoSphere CDC does not use commit groups to perform
synchronization.

Maximum Setting2,147,483,648 (maximum integer)

DynamicYes

System parameters for InfoSphere CDC for Sybase (version 6.0 and earlier) 507
 Related concepts
System parameters for InfoSphere CDC for Sybase (version 6.0 and earlier) on
page 493
Related reference
SYNCHRONIZATION_INTERVAL

SYNCHRONIZATION_INTERVAL
VersionInfoSphere CDC for Sybase version 6.0 and earlier

Use this system parameter to specify the interval, in seconds, at which

synchronization is performed between the source and target. Synchronization is
achieved when the target reports to the source the position of the last committed
change.

Applies ToSource

The SYNCRONIZATION_INTERVAL and SYNCHRONIZATION_COMMIT_ GROUP_SIZE system

parameters are intended to be used together. Synchronization occurs either when
the number of transactions (specified by SYNCHRONIZATION_COMMIT_ GROUP_SIZE )
have been applied or when the time interval (specified by
SYNCRONIZATION_INTERVAL) has elapsed, whichever comes first.

Default Setting1

Minimum Setting1

Maximum Setting300

DynamicYes
Related concepts
System parameters for InfoSphere CDC for Sybase (version 6.0 and earlier) on
page 493
Related reference
SYNCHRONIZATION_COMMIT_ GROUP_SIZE on page 507

Tracing system parameters

Tracing system parameters let you perform diagnostic activities with InfoSphere
CDC.

See also:
D_MIRROR_ALARM_TRACE
D_MIRROR_TRACE on page 509
D_MIRROR_TRACE_FILE_SIZE on page 509
D_MIRROR_TRACE_ON_ERROR on page 510

D_MIRROR_ALARM_TRACE
VersionInfoSphere CDC for Sybase version 6.0 and earlier

508 InfoSphere Change Data Capture Management Console: Administration Guide

 Use this system parameter to Indicate whether or not tracing for notification is
enabled.

Applies ToSource and Target

Set this parameter to one of the following:

v OFFTracing for notification is disabled.
v ONTracing for notification is enabled.

Tracing for notification is enabled when D_MIRROR_TRACE system parameter is also

set to ON. The notification tracing will be located in the same trace file used for
regular tracing located in the directory specified by the D_MIRROR_LOG system
parameter. The trace files are encrypted and are meant to be sent to IBM for
troubleshooting purposes.

Default SettingOFF

D_MIRROR_TRACE
VersionInfoSphere CDC for Sybase version 6.0 and earlier

Use this system parameter to indicate whether or not tracing is enabled.

Applies ToSource and Target

Set this parameter to one of the following:

v OFFTracing is disabled. This setting has no effect when
D_MIRROR_TRACE_ON_ERROR=ON.
v ONTracing is enabled and InfoSphere CDC creates the appropriate trace files
in the log directory. These trace files are encrypted, and are meant to be sent to
IBM technical support for troubleshooting purposes.

When enabling this setting, also set the size of the trace file to an appropriate
value using the D_MIRROR_TRACE_FILE_SIZE system parameter. To avoid disk space
problems, set the size of the trace file to a value that is not too high.

Default SettingOFF

DynamicYes
Related concepts
System parameters for InfoSphere CDC for Sybase (version 6.0 and earlier) on
page 493
Related reference
D_MIRROR_TRACE_FILE_SIZE

D_MIRROR_TRACE_FILE_SIZE
VersionInfoSphere CDC for Sybase version 6.0 and earlier

Use this system parameter to specify the maximum size of a trace file in bytes.
InfoSphere CDC creates two trace files. When the first trace file reaches its
maximum size, InfoSphere CDC creates a second file. When the second trace file
reaches its maximum size, InfoSphere CDC starts overwriting the first file.

System parameters for InfoSphere CDC for Sybase (version 6.0 and earlier) 509
 Applies ToSource and Target

Default Setting10,000,000 bytes

Minimum Setting1,000,000 bytes

Related concepts
System parameters for InfoSphere CDC for Sybase (version 6.0 and earlier) on
page 493

D_MIRROR_TRACE_ON_ERROR
VersionInfoSphere CDC for Sybase version 6.0 and earlier

Use this system parameter to specify whether or not InfoSphere CDC enables
tracing automatically when an error occurs.

Applies ToSource and Target

Set this parameter to one of the following:

v OFFInfoSphere CDC does not enable tracing when an error occurs.
v ONInfoSphere CDC enables tracing when an error occurs. InfoSphere CDC
creates the appropriate trace files in the InfoSphere CDC log directory. These
trace files are encrypted, and are meant to be sent to IBM technical support for
troubleshooting purposes.

When enabling this setting, also set the size of the trace file to an appropriate
value using the D_MIRROR_TRACE_FILE_SIZE system parameter. To avoid disk space
problems, set the size of the trace file to a value that is not too high.

Default SettingOFF

DynamicYes (on the target only)

Related concepts
System parameters for InfoSphere CDC for Sybase (version 6.0 and earlier) on
page 493
Related reference
D_MIRROR_TRACE_FILE_SIZE on page 509

Notification system parameters

Notification system parameters let you control if you should generate InfoSphere
CDC messages in the Event Log for specific events.

See also:
convertNotNullableMsg on page 511
DEADBAND_PERCENTAGE on page 511
DM_STATUS_INTERVAL on page 513
HEARTBEAT_TIMEOUT on page 513
LOG_EMAIL_USERNAME on page 514
MONITOR_SAMPLE_INTERVAL on page 514
STATISTICS_INTERVAL on page 515

510 InfoSphere Change Data Capture Management Console: Administration Guide

convertNotNullableMsg
VersionInfoSphere CDC for Sybase version 6.0 and earlier

Use this system parameter to indicate whether or not a warning message will be
generated in Event Log each time data that contains NULL values is converted to
default values for non-nullable target columns.

Applies ToTarget

This system parameter applies only when convertNotNullableColumns=ON.

Otherwise, this parameter has no effect.

Set this parameter to one of the following:

v OFFNo warning message is generated in Event Log.
v ONA warning message is generated in Event Log each time a NULL value is
converted to a default value.

Default SettingOFF

DEADBAND_PERCENTAGE
VersionInfoSphere CDC for Sybase version 6.0 and earlier

Applies ToTarget

Identifies the size of the range around each latency threshold setting. Based on
latency thresholds defined, a latency message is generated when latency has risen
above or fallen below a threshold. Latency is calculated at regular intervals, where
the interval is the current setting for the MONITOR_SAMPLE_INTERVAL system
parameter. You can set notifications in response to a generated latency message.

This system parameter, which is expressed as a percentage, allows you to pad a

threshold equally on both sides to create a range around the threshold. By
adjusting this system parameter, the size of the range around the threshold can be
increased or decreased, and the threshold itself can be made thicker or thinner. A
latency message is generated only when latency has risen above the upper limit of
the range or fallen below the lower limit of the range. By changing the value
assigned to this system parameter, you can control the number of latency messages
placed in Event Log.

For example, assume that a latency threshold is 5 minutes and this system
parameter is set to 10. A 10% range is applied around the 5 minute threshold. The
following calculations are performed to determine the lower and upper limits (in
minutes) of the range around the threshold:
v Padding = 10% of 5 minutes = 0.5 minutes (rounded up to 1 minute)
v Padding is rounded up or down to the nearest whole minute:
Upper limit of range = 5 minutes + 1 minute (padding) = 6 minutes
Lower limit of range = 5 minutes - 1 minute (padding) = 4 minutes

As a result, a latency message will be generated only when latency rises above 6
minutes or falls below 4 minutes. Given sample latency over a ten minute period
where latency is calculated every minute, three latency messages are generated.
This graph illustrates latency message generation with the DEADBAND_PERCENTAGE

System parameters for InfoSphere CDC for Sybase (version 6.0 and earlier) 511
 value set to 10%:

If this DEADBAND_PERCENTAGE is set to 3 (the default setting) for the same example,
no padding is applied to the latency threshold. Therefore, a latency message is
generated each time latency crosses over the latency threshold of 5 minutes. Based
on the same sample latency in the previous graph where latency is calculated
every minute, five latency messages are generated when this system parameter is
set to 3. This graph illustrates latency message generation with the
DEADBAND_PERCENTAGE value set to 3%:

If the number of latency messages generated over the ten minute period for the
10% (3 latency messages) and 3% (5 latency messages) settings are averages, an
additional 288 latency messages would be generated each day if this system
parameter is not changed from its default setting to 10%.

Since there are two latency thresholds that you can set (a warning threshold and a
problem threshold), two separate ranges are defined when padding is at least one
minute. In this case, each range is attached to its threshold, and the two ranges can
overlap with no change in behavior.

If a value outside the acceptable range is specified, the default setting is used.

Default Setting3%

Minimum Setting3%

Maximum Setting10%

Note: If you set a value outside the acceptable range, then InfoSphere CDC uses
the defaults.

512 InfoSphere Change Data Capture Management Console: Administration Guide

 Related concepts
System parameters for InfoSphere CDC for Sybase (version 6.0 and earlier) on
page 493
Setting latency thresholds and notifications on page 346
Disk resource system parameters on page 515

DM_STATUS_INTERVAL
VersionInfoSphere CDC for Sybase version 6.0 and earlier

Use this system parameter to specify how often progress messages should be
issued in seconds. These messages are displayed in Event Log to indicate how
replication is advancing and to provide detailed information about InfoSphere
CDC replication activities.

Applies ToSource and Target

Note: Low values of this parameter may result in many messages displayed in
Event Log. In this situation, clear Event Log on a regular basis.

Default Setting0 seconds. No progress notifications will be issued.

Minimum Setting0 seconds. No progress notifications will be issued.

Maximum Setting7200 seconds

Related concepts
System parameters for InfoSphere CDC for Sybase (version 6.0 and earlier) on
page 493

HEARTBEAT_TIMEOUT
VersionInfoSphere CDC for Sybase version 6.0 and earlier

Use this parameter to specify the number of minutes of communication inactivity

to wait before active InfoSphere CDC processes for a subscription are stopped.
Heartbeat is a feature that manages InfoSphere CDC processes when a problem
with communications or a process has been detected through the absence of
communications over a specified period of time.

For each active subscription, internal heartbeat messages are sent regularly
between the source and the target to determine communications and process
status. If a reply to a message is not received by the source or target within the
specified timeout interval, then InfoSphere CDC determines that a problem has
occurred, and attempts to stop all its source and target processes for the
subscription. In addition, messages (message identifiers 2612 and 3165) are placed
in Event Log when heartbeat timeouts occur.

Applies ToSource

Default Setting15 minutes

Minimum Setting3 minutes

Maximum Setting999 minutes

System parameters for InfoSphere CDC for Sybase (version 6.0 and earlier) 513
 Related concepts
System parameters for InfoSphere CDC for Sybase (version 6.0 and earlier) on
page 493

LOG_EMAIL_USERNAME
VersionInfoSphere CDC for Sybase version 6.0 and earlier

Use this system parameter to specify the user name that receives e-mail messages
in response to invoking the dmreadlog command or the warning message that is
generated when Event Log exceeds the threshold value set by the LOG_MAX_SIZE
system parameter.

Applies ToSource and Target

In UNIX environments, the value assigned to this parameter is a comma-separated

list of user names. The value of this parameter cannot exceed 30 bytes in length.

To suppress all e-mail messages, set this parameter to NOMAIL.

Default SettingThe InfoSphere CDC account (UNIX user) specified when

InfoSphere CDC was installed
Related concepts
System parameters for InfoSphere CDC for Sybase (version 6.0 and earlier) on
page 493
Related reference
STATISTICS_INTERVAL on page 515

MONITOR_SAMPLE_INTERVAL
VersionInfoSphere CDC for Sybase version 6.0 and earlier

Use this system parameter to identify the period of time, in seconds, between
consecutive updates to a storage area that is used to maintain replication latency
metrics. Management Console references this area to present replication latency
information.

Applies ToSource and Target

On the target, this setting also represents how often the storage area is sampled to
determine if latency has risen above or fallen below specified threshold settings.
InfoSphere CDC generates latency messages when latency rises above or falls
below the thresholds. In response to a generated message, you can set latency
notifications.

If a value smaller than the minimum setting is specified, the minimum setting is
used. If a value larger than the maximum setting is specified, the maximum setting
is used.

Default Setting5 seconds

Minimum Setting0 seconds. Replication latency metrics are not updated.

Maximum Setting3600 seconds

514 InfoSphere Change Data Capture Management Console: Administration Guide

 Related concepts
System parameters for InfoSphere CDC for Sybase (version 6.0 and earlier) on
page 493
Setting latency thresholds and notifications on page 346

STATISTICS_INTERVAL
VersionInfoSphere CDC for Sybase version 6.0 and earlier

Use this system parameter to specify how often, in seconds, InfoSphere CDC issues
messages that contain statistics information. These messages are displayed in Event
Log.

Applies ToSource and Target

Note: Use this parameter only if advised by IBM technical support.

Default Setting0. InfoSphere CDC does not provide statistics information.

Minimum Setting0. InfoSphere CDC does not provide statistics information.

Maximum Setting2,147,483,647 (maximum integer)

DynamicYes
Related concepts
System parameters for InfoSphere CDC for Sybase (version 6.0 and earlier) on
page 493

Disk resource system parameters

Some system parameters control memory usage in InfoSphere CDC. For improved
performance, if you are able to allocate more than the default value of 512 MB for
the InfoSphere CDC Java Virtual Machine, then you can adjust the disk resource
system parameters to use the increased memory.

See also:
LOG_MAX_SIZE

LOG_MAX_SIZE
VersionInfoSphere CDC for Sybase version 6.0 and earlier

Use this system parameter to specify the threshold size of Event Log in KB. A
warning message is generated in Event Log when its size exceeds specified
threshold. The messages in Event Log are deleted automatically when the size of
Event Log is ten times the value specified by this parameter.

Applies ToSource and Target

If you do not want to specify a threshold size, set this parameter to NOMAX.

Default Setting5000

System parameters for InfoSphere CDC for Sybase (version 6.0 and earlier) 515
 Related concepts
System parameters for InfoSphere CDC for Sybase (version 6.0 and earlier) on
page 493

Refresh loader system parameters

Some system parameters affect how InfoSphere CDC applies refresh operations.

See also:
D_HOME_BCP
D_MIRROR_BCP
D_MIRROR_BCP_ROWS on page 517
D_MIRROR_FASTBCP on page 517
DM_BCP_PACKET_SIZE on page 517

D_HOME_BCP
VersionInfoSphere CDC for Sybase version 6.0 and earlier

Use this system parameter to specify the directory where InfoSphere CDC will
place a BCP log file. The log file contains the statements that were used to recreate
the indexes after the BCP operation was completed.

Applies ToSource and Target

Default SettingThe directory specified by the D_MIRROR_LOG system parameter.

D_MIRROR_BCP
VersionInfoSphere CDC for Sybase version 6.0 and earlier

Use this system parameter to indicate if BCP refresh operations are enabled. Under
BCP, a block of data is accumulated and applied to target tables in a single
operation. InfoSphere CDC accumulates records on the Sybase server, and then
performs a bulk copy when the block contains a specific number of records.

Applies ToTarget

Set this parameter to one of the following:

v ONInfoSphere CDC uses the Sybase Bulk Copy (BCP) library to perform data
refresh. The bulk copy is generally faster. However, all updates performed under
BCP cannot be reversed.
v OFFInfoSphere CDC uses SQL inserts to perform data refresh. This setting lets
InfoSphere CDC roll back the previous copy operation.

Default SettingON

Note: To enable InfoSphere CDC to refresh target tables using BCP, make sure
that this parameter is set to ON, and that D_MIRROR_FASTBCP is set to OFF. If
D_MIRROR_FASTBCP is set to ON as well, then fast BCP refresh is enabled.

516 InfoSphere Change Data Capture Management Console: Administration Guide

D_MIRROR_BCP_ROWS
VersionInfoSphere CDC for Sybase version 6.0 and earlier

Use this system parameter to specify the number of rows that the server will buffer
before InfoSphere CDC commits to the database in a single operation. You need to
consider the amount of storage available to buffer rows. For example, to copy
blocks of 500 rows to target tables, you would set D_MIRROR_BCP_ROWS to a value of
500.

Applies ToTarget

Default Setting50000 rows. If the system parameter D_MIRROR_BCP is set to OFF

or if D_MIRROR_BCP_ROWS is set to a negative number, then the server will buffer
50000 rows before InfoSphere CDC commits these blocks to target tables.

Note: If you specify a value of zero, then the server will buffer all the rows in the
table before committing data to the database.

D_MIRROR_FASTBCP
VersionInfoSphere CDC for Sybase version 6.0 and earlier

Use this system parameter to enable or disable fast BCP refresh operations. Fast
BCP applies records in blocks, but provides better performance than BCP.

Applies ToTarget

Set this parameter to one of the following:

v ONEnables InfoSphere CDC to apply records to target tables using fast BCP.
When you enable this parameter, InfoSphere CDC removes all indexes from the
target table, loads the data into the table, and then rebuilds the indexes. If
InfoSphere CDC cannot rebuild the indexes because of an error (for example, a
duplicate value encountered in a unique index) then InfoSphere CDC generates
an error in the Event Log and the command to rebuild the index is saved in a
file in the log directory. You must also set the D_MIRROR_BCP system parameter to
ON to enable fast BCP.
v OFFDisables InfoSphere CDC from using fast BCP.

Default SettingOFF

DM_BCP_PACKET_SIZE
VersionInfoSphere CDC for Sybase version 6.0 and earlier

Use this system parameter to specify the length (bytes) of the network packets you
want InfoSphere CDC to send to the Sybase server when a BCP refresh is enabled.
The value of this parameter impacts the speed at which the load of data will occur.
You should specify network packet sizes larger than the default to improve the
performance of BCP refresh operations.

Applies ToTarget

Default Setting512 bytes

System parameters for InfoSphere CDC for Sybase (version 6.0 and earlier) 517
 Minimum Setting512 bytes

Maximum Setting65535 bytes

Note: The number of bytes cannot be greater than the maximum network packet
size value you have specified for the Sybase database. While Sybase
documentation states that this is a negotiated value, the connection will fail if the
size specified for this system parameter is larger than the Sybase database setting.
Therefore, the maximum value for the Sybase database should be set to a value
that allows large packet sizes.

For more information about the Sybase configuration variables related to network
communication, see your Sybase documentation.

518 InfoSphere Change Data Capture Management Console: Administration Guide

System parameters for InfoSphere CDC for Sybase (version
6.3 and later)
System parameters let you control the behavior of InfoSphere CDC. If your
replication environment requires a particular configuration, then you can use
system parameters to modify the behavior of default operations in InfoSphere
CDC. The default system parameter settings are appropriate for most installations.

InfoSphere CDC provides system parameters that control the behavior of your
source and target datastores.

Note: If you make changes to a system parameter during active replication, you
must stop and restart replication for the changes to take effect.

In this section, you will learn:

General product system parameters
Notification system parameters on page 520
Maximize throughput system parameters on page 521
Encoding system parameters on page 523
Disk resource system parameters on page 524
Apply process system parameters on page 525
Supplemental logging system parameters on page 414

General product system parameters

General product system parameters let you control basic features of InfoSphere
CDC and information you may have specified during installation.

See also:
mirror_auto_restart_interval_minutes

mirror_auto_restart_interval_minutes
VersionInfoSphere CDC for Sybase version 6.3 Fix Pack 3 TFE 9 and later.

Use this parameter to indicate how long (in minutes) InfoSphere CDC will attempt
to automatically restart continuous mirroring for persistent subscriptions.

Applies ToSource

Default0

Minimum0

Maximum60

Copyright IBM Corp. 2008, 2011 519

Notification system parameters
Notification system parameters let you control if you should generate InfoSphere
CDC messages in the Event Log for specific events.

See also:
events_max_retain
global_conversion_not_possible_warning
global_shutdown_after_no_heartbeat_response_minutes on page 521

events_max_retain
VersionInfoSphere CDC for Sybase version 6.3 and later

Use this system parameter to control the maximum number of events that
InfoSphere CDC will store in the event log. If InfoSphere CDC generates more
events than the specified maximum, then the earliest events will be deleted.

Default Setting10000

Minimum -1

Maximum2147483647
Related concepts
System parameters for InfoSphere CDC for Sybase (version 6.3 and later) on
page 519

global_conversion_not_possible_warning
VersionInfoSphere CDC for Sybase version 6.3 and later

Use this system parameter to control whether or not InfoSphere CDC generates a
warning in the Management Console Event Log in the following situations:
v Data conversion is not possible for a specific data value.
v Converted data types are encountered that are out of range.

Set this parameter to one of the following:

v trueGenerates a warning in the Event Log if data conversion is not possible
for a specific data value or converted data types are encountered that are out of
range.
v falseDoes not generate a warning in the Event Log if data conversion is not
possible for a specific data value or converted data types are encountered that
are out of range.

Applies ToTarget

Default Settingfalse

520 InfoSphere Change Data Capture Management Console: Administration Guide

 Related concepts
System parameters for InfoSphere CDC for Sybase (version 6.3 and later) on
page 519
Related reference
global_default_after_database_minimum_timestamp on page 525
global_default_before_database_minimum_timestamp on page 526

global_shutdown_after_no_heartbeat_response_minutes
VersionInfoSphere CDC for Sybase version 6.3 and later

Use this system parameter to specify the duration, in minutes, of communication

inactivity before active InfoSphere CDC processes for a subscription are stopped. If
a value outside the acceptable range is specified, the default setting is used.

Applies ToSource

Default Setting15 minutes

Minimum Setting3 minutes

Maximum Setting999 minutes

Related concepts
System parameters for InfoSphere CDC for Sybase (version 6.3 and later) on
page 519

Maximize throughput system parameters

InfoSphere CDC system parameters allow you to significantly reduce the workload
of the target database during mirroring. The InfoSphere CDC apply process groups
transactions on the target to reduce the workload. Every commit on the target
database will correspond with a commit on the target. However, it may not
perform every commit that was done on the source. For example, if the source
does three small transactions containing one operation each, the target may commit
all three operations as part of a single transaction. You can use this grouping of
system parameters to significantly reduce the resources required by the target
database. The default settings are appropriate for most databases, but if your target
system has limited resources and an increase in latency is acceptable, you can
adjust the settings appropriately.

See also:
global_max_batch_size
mirror_interim_commit_threshold on page 522
refresh_commit_after_max_operations on page 522

global_max_batch_size
VersionInfoSphere CDC for Sybase version 6.3 and later

Use this system parameter to specify the maximum number of rows that
InfoSphere CDC can place in an array and apply to the target database during
refresh or mirroring. InfoSphere CDC collects rows and places them in an array (in
memory) while receiving table-level operations from the source system. InfoSphere

System parameters for InfoSphere CDC for Sybase (version 6.3 and later) 521
 CDC applies the rows from the array when there is a change to a different table,
when there is a new table-level operation, or when the maximum number of rows
in an array has been reached. You can use this parameter during mirroring only if
mirror_end_on_error is true and mirror_expected_errors_list is empty. Use only
during a refresh if refresh_end_on_error is true and refresh_expected_errors_list is
empty. Before InfoSphere CDC places rows into an array, it allocates memory for
the maximum number of rows you specify and multiplies this integer by the
maximum length of a row. If the maximum number of rows is too large, then
InfoSphere CDC cannot allocate enough memory and will shut down. Management
Console references this area to present replication latency information.

Applies ToTarget

Default Setting25 rows

Maximum Setting2147483647 rows

Minimum Setting1 row

mirror_interim_commit_threshold
VersionInfoSphere CDC for Sybase version 6.3 Fix Pack 3 and later.

By default, InfoSphere CDC guarantees transactional delivery of change data to the

target. This ensures that if any data from a source transaction is committed to the
target, then all other in scope operations from that source transaction are
committed as well.

In cases where large transactions are done on the source system, it can be more
efficient to break a large transaction into smaller transactions when applying data
to the target. You can configure this behavior using this system parameter.

The default value of 0 for this system parameter indicates that the product
guarantees transactional delivery of change data to the target. A value greater than
0 indicates that you want InfoSphere CDC to break up large transactions into
smaller transactions. For example, a value of 2000 indicates that InfoSphere CDC
will split up large source transactions so that each transaction committed to the
target database contains no more than 2000 operations.

Applies ToTarget

Default Setting0

Minimum Setting0

refresh_commit_after_max_operations
VersionInfoSphere CDC for Sybase version 6.3 and later

This system parameter identifies the number of rows comprising each transaction
during refresh. To reduce the workload on the target database during refresh,
InfoSphere CDC periodically commits the changes to the target database rather
than performing the refresh as a single large transaction.

Applies ToTarget

522 InfoSphere Change Data Capture Management Console: Administration Guide

 Default Setting1000

Maximum Setting2147483647

Minimum Setting1
Related concepts
System parameters for InfoSphere CDC for Sybase (version 6.3 and later) on
page 519

Encoding system parameters

For some system parameters, you can set the default method for treating data in
defined Unicode columns, and you can set the default character encoding for your
database.

See also:
global_unicode_as_char

global_unicode_as_char
VersionInfoSphere CDC for Sybase version 6.3 and later

This system parameter indicates the default method of treating data in defined
Unicode columns. For each InfoSphere CDC installation on a server, this system
parameter defines the system default method of treating data in Unicode columns.
If a Unicode column is set to System Default on the Encoding tab of the Mapping
Details view in Management Console, InfoSphere CDC uses the method for
processing Unicode columns that you select in this system parameter.

Set this parameter to one of the following:

v trueInfoSphere CDC treats all data in Unicode columns as single-byte
characters. Use this setting when Unicode columns contain single-byte character
data.
v falseInfoSphere CDC treats all data in Unicode columns as a continuous bit
stream. Use this setting when Unicode columns contain non-single-byte
character data. Setting this system parameter to false ensures that InfoSphere
CDC handles non-single-byte character data in the same way as previous
InfoSphere CDC releases.

Note: Setting this parameter to false does not ensure that replicated
non-single-byte character data in Unicode columns are represented properly on
the target. For replicated non-single-byte character data, you may have to apply
user exit programs or other customizations to properly represent data in
Unicode columns. For more information about user exit programs, see the
InfoSphere CDC End-User Documentation for your platform.

Applies ToSource

Default Settingfalse

System parameters for InfoSphere CDC for Sybase (version 6.3 and later) 523
 Related concepts
System parameters for InfoSphere CDC for Sybase (version 6.3 and later) on
page 519

Disk resource system parameters

Some system parameters control memory usage in InfoSphere CDC. For improved
performance, if you are able to allocate more than the default value of 512 MB for
the InfoSphere CDC Java Virtual Machine, then you can adjust the disk resource
system parameters to use the increased memory.

See also:
mirror_global_disk_quota_mb
mirror_global_disk_quota_gb

mirror_global_disk_quota_mb
VersionInfoSphere CDC for Sybase version 6.3

Use this system parameter to globally set a disk quota (in MB) for all capture
components including temporary files, transaction queues, and LOBs which are
staged on the target before being applied. InfoSphere CDC will manage disk space
utilization across all components as required.

Most databases have a mechanism that allows you to roll back or undo changes to
your database by storing uncommitted changes. Similarly, InfoSphere CDC uses
the disk quota controlled by this system parameter to store in scope change data
that has not been committed in your database. Once the database transaction is
committed, the disk space used by the transaction is released. Note that InfoSphere
CDC stores the data in memory to improve performance and will only persist the
data to disk if memory is unavailable.

The default setting of this system parameter is such that the product will only stop
replicating after this disk quota exhausts all available disk space on your system. If
you would prefer the product to stop replicating after it uses a specific amount of
disk space, you can set the value with this system parameter.

Applies ToSource and Target

Default Setting9223372036854775807

Maximum9223372036854775807

Minimum100
Related concepts
System parameters for InfoSphere CDC for Sybase (version 6.3 and later) on
page 519

mirror_global_disk_quota_gb
VersionInfoSphere CDC for Sybase version 6.5

Use this system parameter to globally set a disk quota (in GB) for all capture
components including temporary files, transaction queues, and LOBs which are

524 InfoSphere Change Data Capture Management Console: Administration Guide

 staged on the target before being applied. InfoSphere CDC will manage disk space
utilization across all components as required.

Most databases have a mechanism that allows you to roll back or undo changes to
your database by storing uncommitted changes. Similarly, InfoSphere CDC uses
the disk quota controlled by this system parameter to store in scope change data
that has not been committed in your database. Once the database transaction is
committed, the disk space used by the transaction is released. Note that InfoSphere
CDC stores the data in memory to improve performance and will only persist the
data to disk if memory is unavailable.

The default setting of this system parameter is such that the product will only stop
replicating after this disk quota exhausts all available disk space on your system. If
you would prefer the product to stop replicating after it uses a specific amount of
disk space, you can set the value with this system parameter.

Applies ToSource and Target

Default Setting9223372036854775807

Maximum9223372036854775807

Minimum1

Apply process system parameters

Some system parameters adjust the way InfoSphere CDC applies rows, column
data, and error handling.

See also:
global_default_after_database_minimum_timestamp
global_default_before_database_minimum_timestamp on page 526
convert_not_nullable_column on page 526
convert_not_nullable_message on page 527
mirror_end_on_error on page 527
mirror_expected_errors_list on page 527
refresh_end_on_error on page 528
refresh_expected_errors_list on page 528
refresh_loader_drop_index on page 529
refresh_with_referential_integrity on page 529
trim_char_to_varchar on page 529
trim_varchar_to_varchar on page 530
userexit_max_lob_size_kb on page 530

global_default_after_database_minimum_timestamp
VersionInfoSphere CDC for Sybase version 6.3 and later

In environments where the timestamp range in your source database differs from
the target database, this system parameter allows you to control the default values
that InfoSphere CDC sets on the target for out-of-range date-time values.

System parameters for InfoSphere CDC for Sybase (version 6.3 and later) 525
 Use this system parameter to control the value substituted by InfoSphere CDC in
the target database when a value is being set on a target date-time column that is
greater than the maximum accepted value for the target database.

Note: To determine if a value is out-of-range, InfoSphere CDC converts the value

to a timestamp data type and then validates the timestamp to determine if it is
within range.

Default Setting1901-01-01 00:00:00.000

Related reference
global_conversion_not_possible_warning on page 520

global_default_before_database_minimum_timestamp
VersionInfoSphere CDC for Sybase version 6.3 and later

In environments where the timestamp range in your source database differs from
the target database, this system parameter allows you to control the default values
that InfoSphere CDC sets on the target for out-of-range date-time values.

Use this system parameter to control the value substituted by InfoSphere CDC in
the target database when a value is being set on a target date-time column that is
less than the minimum accepted value for the target database.

Note: To determine if a value is out-of-range, InfoSphere CDC converts the value

to a timestamp data type and then validates the timestamp to determine if it is
within range.

Default Setting1901-01-01 00:00:00.000

Related reference
global_conversion_not_possible_warning on page 520

convert_not_nullable_column
VersionInfoSphere CDC for Sybase version 6.3 and later

Use this system parameter to control how InfoSphere CDC behaves when it applies
a null value to a non-nullable column. When set to true (default value), the null
value will be replaced with a default value (based on the data type of the column)
and InfoSphere CDC will generate a warning in the event log. When set to false,
InfoSphere CDC applies the null value directly to the non-nullable column which
will result in an error and cause a shutdown of InfoSphere CDC on the target
database.

Note: If you decided to set this system parameter to false and have specified this
as an error for InfoSphere CDC to ignore using the mirror_expected_errors_list
system parameter, then InfoSphere CDC will ignore the error and not shutdown.

Set this parameter to one of the following:

v trueNull value will be replaced with default value for non-nullable column,
and a warning event will be logged.
v falseNull data will be applied as-is to non-nullable column and database will
usually return an error code.

526 InfoSphere Change Data Capture Management Console: Administration Guide

 Applies ToSource and Target

Default SettingTrue
Related concepts
System parameters for InfoSphere CDC for Sybase (version 6.3 and later) on
page 519

convert_not_nullable_message
VersionInfoSphere CDC for Sybase version 6.3 and later

Use this system parameter to determine if a message will be generated in the

Event Log when InfoSphere CDC converts a null value to a default value when
applied to a non-nullable column. When set to true (default value), InfoSphere
CDC will log the event the first time it encounters a null to non-nullable mapping
(on a per column per table basis). When set to false, InfoSphere CDC will not
generate a message when a null value is converted to a default value.

Note: This system parameter applies only when the convert_not_nullable_column

parameter has been set to true.

Set this parameter to one of the following:

v trueGenerates a warning message in the Event Log the first time a null value
is converted to a default value on a per column per table basis.
v falseNo warning message is generated in the Event Log.

Applies ToTarget

Default SettingTrue

mirror_end_on_error
VersionInfoSphere CDC for Sybase version 6.3 and later

Use this system parameter to indicate if you want to end mirroring after an apply
error occurs on the target database.

Set this parameter to one of the following:

v trueEnd mirroring after an apply error on the target database.
v falseDo not end mirroring after an apply error on the target database.

Applies ToTarget

Default SettingTrue
Related concepts
System parameters for InfoSphere CDC for Sybase (version 6.3 and later) on
page 519

mirror_expected_errors_list
VersionInfoSphere CDC for Sybase version 6.3 and later

System parameters for InfoSphere CDC for Sybase (version 6.3 and later) 527
 Use this system parameter when you want InfoSphere CDC to ignore one or more
database errors when applying data changes to the target during mirroring. The
error specified must correspond to the integer error code (database-vendor specific)
returned by the SQLException class in JDBC (Java Database Connectivity). Specify
multiple errors with a comma separated list of integer error codes.

For example, if you want InfoSphere CDC to continue mirroring when it

encounters a duplicate key violation in your Sybase target database, set this
parameter to mirror_expected_errors_list=2601. The integer error code of 2601
corresponds to the Sybase error: The SQL error code is 2601. The SQL state
is: 23000. The error message is: [CDC][Sybase JDBC Driver][Sybase]Attempt
to insert duplicate key row in object TBL with unique index
TBL_13600048452.. If you also want to ignore an error code of 3459, set this
parameter to mirror_expected_errors_list=2601,3459.

Note: Latency may increase when using this system parameter since InfoSphere
CDC will not use JDBC array apply in order to track the errors specified.

Applies ToTarget
Related concepts
System parameters for InfoSphere CDC for Sybase (version 6.3 and later) on
page 519

refresh_end_on_error
VersionInfoSphere CDC for Sybase version 6.3 and later

Use this system parameter to indicate if you want to end a refresh after an apply
error occurs.

Set this parameter to one of the following:

v trueEnd a refresh after an apply error occurs.
v falseDo not end a refresh after an apply error occurs.

Applies ToTarget

Default SettingTrue
Related concepts
System parameters for InfoSphere CDC for Sybase (version 6.3 and later) on
page 519

refresh_expected_errors_list
VersionInfoSphere CDC for Sybase version 6.3 and later

Use this system parameter when you want InfoSphere CDC to ignore one or more
database errors when refreshing data to the target. The error specified must
correspond to the integer error code (database-vendor specific) returned by the
SQLException class in JDBC (Java Database Connectivity). Specify multiple errors
with a comma separated list of integer error codes.

For example, if you want InfoSphere CDC to continue refresh when it encounters a
duplicate key violation in your Sybase target database, set this parameter to
mirror_expected_errors_list=2601. The integer error code of 2601 corresponds to

528 InfoSphere Change Data Capture Management Console: Administration Guide

 the Sybase error: The SQL error code is 2601. The SQL state is: 23000. The
error message is: [CDC][Sybase JDBC Driver][Sybase]Attempt to insert
duplicate key row in object TBL with unique index TBL_13600048452.. If
you also want to ignore an error code of 3459, set this parameter to
mirror_expected_errors_list=2601,3459.

Note: Latency may increase when using this system parameter since InfoSphere
CDC will not use JDBC array apply in order to track the errors specified.

Applies ToTarget
Related concepts
System parameters for InfoSphere CDC for Sybase (version 6.3 and later) on
page 519

refresh_loader_drop_index
VersionInfoSphere CDC for Sybase version 6.3 and later

This system parameter indicates whether or not InfoSphere CDC will drop all
indexes on the tables being refreshed and then rebuild the indexes after the refresh.
In most environments, this will improve refresh performance.

If the refresh fails for any reason, InfoSphere CDC will write SQL statements to a
file which will allow you to manually rebuild the indexes for all tables in your
database. The location of the file is specified in the Management Console event log.

Applies ToTarget

Default Settingtrue

refresh_with_referential_integrity
VersionInfoSphere CDC for Sybase version 6.3 and later

Use this system parameter to indicate whether or not you want the data removed
from all the target tables being refreshed before repopulating any of them. This is
most useful when there are referential integrity constraints on the tables being
refreshed.

Set this parameter to one of the following:

v trueIndicates that InfoSphere CDC will first remove all data in reverse of the
specified refresh order. When specifying the refresh order, in general parent
tables should appear before the referenced child tables. The product will then
remove data from the child tables before the parent tables.
v falseIndicates that InfoSphere CDC will not first remove all data from your
tables and will refresh the tables in the specified order.

Applies ToSource

Default Settingfalse

trim_char_to_varchar
VersionInfoSphere CDC for Sybase version 6.3 and later

System parameters for InfoSphere CDC for Sybase (version 6.3 and later) 529
 Use this system parameter to specify whether or not InfoSphere CDC should strip
or leave trailing blanks on string data of the column in the target table.

Set this parameter to one of the following:

v trueInfoSphere CDC strips the data of trailing blanks.
v falseInfoSphere CDC does not strip the string data of trailing blanks.

Applies ToTarget

Default Settingfalse
Related concepts
System parameters for InfoSphere CDC for Sybase (version 6.3 and later) on
page 519

trim_varchar_to_varchar
VersionInfoSphere CDC for Sybase version 6.3 and later

Use this system parameter to specify whether or not InfoSphere CDC should strip
or leave trailing blanks on string data of the column in the target table.

Set this parameter to one of the following:

v trueInfoSphere CDC strips the data of trailing blanks.
v falseInfoSphere CDC does not strip the string data of trailing blanks.

Applies ToTarget

Default Settingfalse
Related concepts
System parameters for InfoSphere CDC for Sybase (version 6.3 and later) on
page 519

userexit_max_lob_size_kb
VersionInfoSphere CDC for Sybase version 6.3 and later

Use this system parameter to set the maximum size of LOB data (in kb) that
InfoSphere CDC can pass to a user exit.

Applies ToTarget

Default Setting128 kb

Maximum9223372036854775807 kb

Minimum1 kb

530 InfoSphere Change Data Capture Management Console: Administration Guide

 Related concepts
System parameters for InfoSphere CDC for Sybase (version 6.3 and later) on
page 519

Supplemental logging system parameters

Some system parameter control the database logging mechanism used by
InfoSphere CDC.

See also:
mirror_logging_by_empty_triggers on page 414
auto_configure_supplemental_logging
mirror_logging_by_empty_triggers

auto_configure_supplemental_logging
VersionInfoSphere CDC for Sybase version 6.3 and later

Use this system parameter to specify how supplemental logging is performed. Set
this parameter to one of the following:
v trueInfoSphere CDC uses the value of the mirror_logging_by_empty_triggers
system parameter to enable logging.
v falseIndicates that you must either create an empty trigger or set the table's
replication flag (using sp_setreptable 'table-name', true).

Default Settingtrue

mirror_logging_by_empty_triggers
VersionInfoSphere CDC for Sybase version 6.3 and later

Use this system parameter to choose empty triggers as your supplemental logging
method for Sybase. InfoSphere CDC only uses this system parameter if
auto_configure_supplemental_logging is set to true.

Set this parameter to one of the following:

v true Indicates that an empty trigger will be created (if one does not exist) to
enable supplemental logging.
v falseIndicates that the table's replication flag will be set.

Note: If the table's replication flag is set and Sybase Replication Server is not
replicating the table, a warning will be written to the ASE error log each time an
insert is performed. In this case you must create an empty subscription (see
http://infocenter.sybase.com/help/index.jsp?topic=/
com.sybase.infocenter.dc35817.1510/html/rsunix_config/CHDCGDAG.htm)

Applies ToSource

Default Settingtrue

System parameters for InfoSphere CDC for Sybase (version 6.3 and later) 531
532 InfoSphere Change Data Capture Management Console: Administration Guide
System parameters for InfoSphere CDC for IBM i (version 6.2
and earlier)
System parameters let you control the behavior of InfoSphere CDC. If your
replication environment requires a particular configuration, then you can use
system parameters to modify the behavior of default operations in InfoSphere
CDC. The default system parameter settings are appropriate for most installations.
Maintain these default settings until you become familiar with InfoSphere CDC
replication configuration.

InfoSphere CDC provides system parameters that control the behavior of your
source and target datastores.

Notes:
v If you make changes to a system parameter during active replication, you must
stop and restart replication to for the changes to take effect.
v When upgrading to a later version of InfoSphere CDC, any preexisting settings
for system parameters are maintained.

In this section, you will learn:

General product system parameters
Replication system parameters on page 536
Cascading replication system parameters on page 538
Database journal (trigger) system parameters on page 538
Remote journal system parameters on page 541
Commitment control system parameters on page 542
Multibyte character set system parameters on page 543
Latency system parameters on page 544
Notification system parameters on page 546
Data type system parameters on page 549
Date and time column function system parameters on page 549
Row and column filtering system parameters on page 550
Event log system parameters on page 551
Lock detection system parameters on page 553

General product system parameters

General product system parameters let you control basic features of InfoSphere
CDC and information you may have specified during installation.

See also:
Authorization Code on page 534
Enable *MAXOPT3 Option on page 534
Record Format Check on page 534
Startup Timeout on page 535
TCP_KEEPALIVE_SECS on page 535

Copyright IBM Corp. 2008, 2011 533

 Authorization Code
VersionInfoSphere CDC for IBM i version 6.2 and earlier

Use this system parameter to adjust the authorization code issued by IBM.

You may need to modify your authorization code when:

v Moving from a temporary license to a permanent license
v Machine classes have changed
v Upgrading to a new version of InfoSphere CDC

Applies ToSource and Target

Note: You can also modify the authorization using the Authorization Code Setup
utility
Related concepts
System parameters for InfoSphere CDC for IBM i (version 6.2 and earlier) on
page 533

Enable *MAXOPT3 Option

VersionInfoSphere CDC for IBM i version 6.2 and earlier

For information about setting this system parameter, see your IBM representative.

Applies ToSource
Related concepts
System parameters for InfoSphere CDC for IBM i (version 6.2 and earlier) on
page 533

Record Format Check

VersionInfoSphere CDC for IBM i version 6.2 and earlier

Use this system parameter to enable or disable InfoSphere CDC from checking
record formats of the physical and logical files.

Applies ToTarget

The Record Format Check system parameter can be set to either *YES or *NO:
v *YESEnables InfoSphere CDC to check the record formats of the physical and
logical files. Only a physical file that has the same record format as the logical
file can be selected as a destination of mirrored data using a unique key.
v *NODisables InfoSphere CDC from checking the record formats of the
physical and logical files. You can select a physical file to be the destination of
mirrored data using a unique key that does not have the same record format as
the logical file.

Default Setting*YES

534 InfoSphere Change Data Capture Management Console: Administration Guide

 Related concepts
System parameters for InfoSphere CDC for IBM i (version 6.2 and earlier) on
page 533

Startup Timeout
VersionInfoSphere CDC for IBM i version 6.2 and earlier

For information about setting this system parameter, see your IBM representative.

Applies ToSource and Target

Related concepts
System parameters for InfoSphere CDC for IBM i (version 6.2 and earlier) on
page 533

TCP_KEEPALIVE_SECS
VersionInfoSphere CDC for IBM i version 6.2 and earlier

Use this system parameter to determine the time (in seconds) InfoSphere CDC
waits before sending a keep alive notification over the network. During idle
periods, InfoSphere CDC sends a keep alive notification to keep the connection
open.

Applies ToSource and Target

Default Setting300 seconds (5 min)

Minimum Setting0

Guidelines

It is important you set this system parameter when you have a firewall connection
that has been configured to timeout. This prevents the firewall from closing the
connection.

To set this system parameter, do the following:

1. Create a data area named DMCOMMS by issuing the following command:
CRTDTAARA DTAARA(<InfoSphere CDC product library>/DMCOMMS) TYPE(*CHAR)
LEN(2000)
2. Set the timeout value by issuing the following command:
CHGDTAARA DTAARA(<InfoSphere CDC product library>/DMCOMMS (521 10))
VALUE('<value>')
where value is a 10-digit number that represents the setting for this system
parameter. For example, to set to 1 minute, issue:
CHGDTAARA DTAARA(DMIRROR/DMCOMMS (521 10)) VALUE(0000000060)

To prevent the firewall from closing during active data replication, set this
parameter to a value lower than the configured firewall timeout.

System parameters for InfoSphere CDC for IBM i (version 6.2 and earlier) 535
 Related concepts
System parameters for InfoSphere CDC for IBM i (version 6.2 and earlier) on
page 533

Replication system parameters

Replication system parameters let you control how InfoSphere CDC behaves after
detecting errors during replication. You can also control how often InfoSphere CDC
communicates the status of replication activities, and how InfoSphere CDC should
apply a refresh operation.

See also:
Allow Refresh While Active
End on Error During Mirroring
End on Error During Refresh on page 537
Refresh After Restore on page 537

Allow Refresh While Active

VersionInfoSphere CDC for IBM i version 6.2 and earlier

Use this system parameter to enable or disable InfoSphere CDC from refreshing a
target table while changes are being made to the source table. After InfoSphere
CDC completes the refresh, it sends any remaining changes that were made on the
source table during the refresh to the target table.

Applies ToSource

The Allow Refresh While Active system parameter can be set to either *YES or
*NO:
v *YESEnables InfoSphere CDC to refresh the target table while there are active
changes being made on the source table.
v *NODisables InfoSphere CDC from performing a refresh when there are active
changes being made on the source table.

Default Setting*YES
Related concepts
System parameters for InfoSphere CDC for IBM i (version 6.2 and earlier) on
page 533

End on Error During Mirroring

VersionInfoSphere CDC for IBM i version 6.2 and earlier

Use this system parameter to end or continue mirroring when InfoSphere CDC
encounters one or more errors.

Applies ToTarget

The End on Error During Mirroring system parameter can be set to either *YES or
*NO:
v *YESInfoSphere CDC ends mirroring immediately after it detects an error.

536 InfoSphere Change Data Capture Management Console: Administration Guide

 v *NOInfoSphere CDC reports the error and continues mirroring after it detects
the error. This is the recommended setting for this parameter.

Default Setting*NO
Related concepts
System parameters for InfoSphere CDC for IBM i (version 6.2 and earlier) on
page 533

End on Error During Refresh

VersionInfoSphere CDC for IBM i version 6.2 and earlier

Use this system parameter to end or continue a refresh operation after InfoSphere
CDC encounters one or more errors.

Applies ToTarget

The End on Error During Refresh system parameter can be set to either *YES or
*NO:
v *YESInfoSphere CDC ends a refresh operation immediately after it detects an
error. This is the recommended setting for this parameter.
v *NOInfoSphere CDC reports the error and continues with the refresh
operation after it detects the error.

Default Setting*YES
Related concepts
System parameters for InfoSphere CDC for IBM i (version 6.2 and earlier) on
page 533

Refresh After Restore

VersionInfoSphere CDC for IBM i version 6.2 and earlier

Use this system parameter to set when InfoSphere CDC refreshes tables that have
been restored.

Applies ToSource

The Refresh After Restore system parameter can be set to either *IMMED or
*DELAY:
v *IMMEDInfoSphere CDC starts a Refresh of the restored tables immediately.
v *DELAYInfoSphere CDC delays the start of a Refresh of the restored tables
until the next time a refresh operation is started. InfoSphere CDC also delays the
start of a Refresh Before Mirror.

Default Setting*IMMED

System parameters for InfoSphere CDC for IBM i (version 6.2 and earlier) 537
 Related concepts
System parameters for InfoSphere CDC for IBM i (version 6.2 and earlier) on
page 533

Cascading replication system parameters

Cascading replication system parameters control InfoSphere CDC cascading
replication.

See also:
Enable Cascading Replicates

Enable Cascading Replicates

VersionInfoSphere CDC for IBM i version 6.2 and earlier

Use this system parameter to enable or disable cascading replication.

Applies ToSource

The Enable Cascading Replicates system parameter can be set to either *YES or
*NO:
v *YESEnables InfoSphere CDC to send replicated data from one target system
to another target system.
v *NODisables InfoSphere CDC from sending replicated data from one target
system to another target system.

Default Setting*YES

Guidelines

Set this system parameter to *NO if there are one or more tables being maintained
at the same time on two servers.
Related concepts
System parameters for InfoSphere CDC for IBM i (version 6.2 and earlier) on
page 533

Database journal (trigger) system parameters

Database journal or trigger system parameters let you manage the InfoSphere CDC
journal table.

See also:
Default Journal Library
Default Journal Name on page 539
Replicate User Defined Journal Entries on page 539
Report Position Interval on page 540
Synchronization Interval on page 540

Default Journal Library

VersionInfoSphere CDC for IBM i version 6.2 and earlier

538 InfoSphere Change Data Capture Management Console: Administration Guide

 Use this system parameter to identify the library where the default InfoSphere
CDC journal resides. For more information about journals, see InfoSphere CDC for
IBM i Commands Reference.

Applies ToSource

The Default Journal Library system parameter can be set to either the name of
the library, *LIBL , or *CURLIB:
v The name of a library.
v *LIBLSpecifies the set of libraries in your library list. The libraries are
searched in order for the first occurrence of the specified default journal.
v *CURLIBSpecifies the current library.

Default Setting*CURLIB

.
Related concepts
System parameters for InfoSphere CDC for IBM i (version 6.2 and earlier) on
page 533

Default Journal Name

VersionInfoSphere CDC for IBM i version 6.2 and earlier

Use this system parameter to identify the name of the InfoSphere CDC default
journal. By default, tables mirrored by InfoSphere CDC use this journal. For more
information about journals, see InfoSphere CDC for IBM i Commands Reference.

Applies ToSource

Default SettingDMCJRN
Related concepts
System parameters for InfoSphere CDC for IBM i (version 6.2 and earlier) on
page 533

Replicate User Defined Journal Entries

VersionInfoSphere CDC for IBM i version 6.2 and earlier

Use this system parameter to enable or disable InfoSphere CDC processing

user-defined journal entries for replication. For information about processing
user-defined journal entries for replication, see InfoSphere CDC for IBM i Commands
Reference.

Applies ToSource

The Replicate User Define Journal Entries system parameter can be set to either
*NO or *YES:
v *NODisables InfoSphere CDC from processing user-defined journal entries for
replication.
v *YESEnables InfoSphere CDC to process user-defined journal entries for
replication.

System parameters for InfoSphere CDC for IBM i (version 6.2 and earlier) 539
 Default Setting*NO

Guidelines

Setting this system parameter to *YES can impact overall performance.

Report Position Interval

VersionInfoSphere CDC for IBM i version 6.2 and earlier

Use this system parameter to set how often (in milliseconds) InfoSphere CDC
informs the target system about its log position. When the source system is in idle
mode and there are no log entries for the subscription, the source system informs
the target system of its current log position. The target system uses this
information to advance its bookmarks.

Applies ToSource

Default Setting5000 milliseconds (5 seconds)

Minimum Settings1000 milliseconds (1 second)

Maximum Settings300000 milliseconds (5 minutes)

Guidelines
v If the number of milliseconds is set low, then the target system can provide
accurate progress notifications that indicate how far replication has progressed.
v If the number of milliseconds is set high, it may affect the accuracy of the
information displayed in progress and bookmark notifications.

Notes:
v If you set a value outside the acceptable range, then InfoSphere CDC uses the
defaults.
v This system parameter can also prevent InfoSphere CDC from rereading log
entries that do not apply to the table currently being replicated.

Synchronization Interval
VersionInfoSphere CDC for IBM i version 6.2 and earlier

Use this system parameter to set how often (in seconds) InfoSphere CDC performs
log synchronization between the source and the target. Synchronization is achieved
when the source reports to the target the position of the last committed change.

Applies ToSource

Default Setting60 seconds

Minimum Settings1 second

Maximum Settings3000 seconds (50 minutes)

Guidelines

540 InfoSphere Change Data Capture Management Console: Administration Guide

 If you are replicating large volumes of data, set this system parameter to a lower
number of seconds to remove obsolete logs more frequently.

Note: If a value outside the acceptable range is specified, the default setting is
used.

Remote journal system parameters

Remote journal system parameters let you control if InfoSphere CDC uses remote
or local journaling when running source replication activities.

See also:
Data Origin TCP/IP Name
Data Origin Port
Relational Database Directory Entry on page 542

Data Origin TCP/IP Name

VersionInfoSphere CDC for IBM i version 6.2 and earlier

Use this system parameter to enable InfoSphere CDC Management Console and
InfoSphere CDC (installed on the InfoSphere CDC/400 Source System) to use the
IP address or host name of the InfoSphere CDC/400 Data Origin Server (where
your source files reside).

Applies ToInfoSphere CDC/400 Data Origin Server

v IP AddressEnables InfoSphere CDC Management Console to use the IP
address or host name of the InfoSphere CDC/400 Data Origin Server. This lets
InfoSphere CDC (installed on the InfoSphere CDC/400 Source System) to
retrieve source files from the InfoSphere CDC/400 Data Origin Server. The value
can be either the host name or the IP address of the InfoSphere CDC/400 Data
Origin Server.
v *LOCAL InfoSphere CDC Management Console uses the IP address or host
name of the InfoSphere CDC/400 Source System. Setting this system parameter
to *LOCAL disables InfoSphere CDC from performing replication activities with
a remote journal.

Default Setting*LOCAL
Related concepts
System parameters for InfoSphere CDC for IBM i (version 6.2 and earlier) on
page 533

Data Origin Port

VersionInfoSphere CDC for IBM i version 6.2 and earlier

Use this system parameter to enable InfoSphere CDC Management Console and
InfoSphere CDC (installed on the InfoSphere CDC/400 Source System) to use the
port number of the InfoSphere CDC/400 Data Origin Server. The value that you
specify for this system parameter must match the TCP listener port number of the
InfoSphere CDC/400 Data Origin Server.

Applies ToInfoSphere CDC/400 Data Origin Server

System parameters for InfoSphere CDC for IBM i (version 6.2 and earlier) 541
 Default Setting0

GuidelinesYou must enable the Data Origin TCP/IP Name system parameter to
either the IP address or the host name of the InfoSphere CDC/400 Data Origin
Server for this system parameter to take affect.

Relational Database Directory Entry

VersionInfoSphere CDC for IBM i version 6.2 and earlier

Use this system parameter to specify the relational database directory entry added
to the InfoSphere CDC/400 Source System which references the relational database
directory entry on the InfoSphere CDC/400 Data Origin Server.

Applies ToInfoSphere CDC/400 Data Origin Server

Default Setting*NONE

GuidelinesYou must enable the Data Origin TCP/IP Name system parameter to
either the IP address or the host name of the InfoSphere CDC/400 Data Origin
Server for this system parameter to take affect.

Commitment control system parameters

Commitment control system parameters let you control how InfoSphere CDC
issues commits to the target system.

See also:
Commitment Control

Commitment Control
VersionInfoSphere CDC for IBM i version 6.2 and earlier

Use this system parameter to enable or disable InfoSphere CDC from using
commitment control. Enabling commitment control maintains transaction
consistency during replication and ensures that all transactions are applied to the
target system. If there is a communications or server failure, and you have enabled
this system parameter, then InfoSphere CDC rolls back the partially applied
transaction to the last commit. For more information about commitment control,
see "Considerations for Commitment Control (*LEVEL1)" in InfoSphere CDC for IBM
i Commands Reference.

Applies ToTarget

The Commitment Control system parameter can be set to *NONE or *LEVEL1:

v *NONEDisables commitment control for transaction processing. InfoSphere
CDC does not maintain transaction consistency during replication and in the
event of a communications or server failure. To ensure consistency across
different platforms and previous releases of InfoSphere CDC, disabling
commitment control is the default setting for this parameter.
v *LEVEL1Enables InfoSphere CDC to use commitment control against the
target system after applying all rows. This setting provides true transaction

542 InfoSphere Change Data Capture Management Console: Administration Guide

 consistency by ensuring that entire transactions are committed to the target
database even in the event of a communications or server failure.

Default Setting*NONE

Guidelines

If you select *LEVEL1, you must disable the system parameter Refresh While
Active on the source.
Related concepts
System parameters for InfoSphere CDC for IBM i (version 6.2 and earlier) on
page 533
Related reference
Allow Refresh While Active on page 536

Multibyte character set system parameters

Multibyte character set system parameters let you control how InfoSphere CDC
treats character sets during replication.

See also:
Unicode Handling

Unicode Handling
VersionInfoSphere CDC for IBM i version 6.2 and earlier

Use this system parameter to indicate the default method of treating data in
defined Unicode columns. For each InfoSphere CDC installation on a server, this
system parameter defines the system default method of treating data in Unicode
columns. If a Unicode column is set to System Default on the Encoding tab of the
Mapping Details view in Management Console, InfoSphere CDC uses the method
for processing Unicode columns that you select in this system parameter.

Applies ToSource

The following IBM DB2 for i data types are considered to be Unicode columns and
are affected by the value assigned to this system parameter:
v GRAPHIC or VARGRAPHIC with code page 1208 (UTF-8)
v CHARACTER or VARCHAR with code page 1208 (UTF-8)

This system parameter is set to either CHAR or NOCHANGE:

v CHARInfoSphere CDC treats all data in Unicode columns as single-byte
characters. Use this setting when Unicode columns contain single-byte character
data.
v NOCHANGEInfoSphere CDC treats all data in Unicode columns as a
continuous bit stream. Use this setting when Unicode columns contain
non-single-byte character data. NOCHANGE ensures InfoSphere CDC will
handle non-single-byte character data in the same way as previous InfoSphere
CDC releases.

Default SettingNOCHANGE

System parameters for InfoSphere CDC for IBM i (version 6.2 and earlier) 543
 Note: NOCHANGE does not ensure that replicated non-single-byte character data
in Unicode columns are represented properly on the target. For replicated
non-single-byte character data, you many need to apply user exit programs or
other customization to properly represent the data in Unicode columns.

For more information about user exit programs, see your InfoSphere CDC for IBM
i documentation.
Related concepts
System parameters for InfoSphere CDC for IBM i (version 6.2 and earlier) on
page 533
Related tasks
To set handling for Unicode character encoding on page 170

Latency system parameters

Latency system parameters let you control how often InfoSphere CDC generates a
latency notification and updates latency statistics in the Event Log.

See also:
Deadband Percentage
Monitor Sample Interval on page 546

Deadband Percentage
VersionInfoSphere CDC for IBM i version 6.2 and earlier

Applies ToTarget

Identifies the size of the range around each latency threshold setting. Based on
latency thresholds defined, a latency message is generated when latency has risen
above or fallen below a threshold. Latency is calculated at regular intervals, where
the interval is the current setting for the MONITOR_SAMPLE_INTERVAL system
parameter. You can set notifications in response to a generated latency message.

This system parameter, which is expressed as a percentage, allows you to pad a

threshold equally on both sides to create a range around the threshold. By
adjusting this system parameter, the size of the range around the threshold can be
increased or decreased, and the threshold itself can be made thicker or thinner. A
latency message is generated only when latency has risen above the upper limit of
the range or fallen below the lower limit of the range. By changing the value
assigned to this system parameter, you can control the number of latency messages
placed in Event Log.

For example, assume that a latency threshold is 5 minutes and this system
parameter is set to 10. A 10% range is applied around the 5 minute threshold. The
following calculations are performed to determine the lower and upper limits (in
minutes) of the range around the threshold:
v Padding = 10% of 5 minutes = 0.5 minutes (rounded up to 1 minute)
v Padding is rounded up or down to the nearest whole minute:
Upper limit of range = 5 minutes + 1 minute (padding) = 6 minutes
Lower limit of range = 5 minutes - 1 minute (padding) = 4 minutes

544 InfoSphere Change Data Capture Management Console: Administration Guide

As a result, a latency message will be generated only when latency rises above 6
minutes or falls below 4 minutes. Given sample latency over a ten minute period
where latency is calculated every minute, three latency messages are generated.
This graph illustrates latency message generation with the DEADBAND_PERCENTAGE
value set to 10%:

If this DEADBAND_PERCENTAGE is set to 3 (the default setting) for the same example,
no padding is applied to the latency threshold. Therefore, a latency message is
generated each time latency crosses over the latency threshold of 5 minutes. Based
on the same sample latency in the previous graph where latency is calculated
every minute, five latency messages are generated when this system parameter is
set to 3. This graph illustrates latency message generation with the
DEADBAND_PERCENTAGE value set to 3%:

If the number of latency messages generated over the ten minute period for the
10% (3 latency messages) and 3% (5 latency messages) settings are averages, an
additional 288 latency messages would be generated each day if this system
parameter is not changed from its default setting to 10%.

Since there are two latency thresholds that you can set (a warning threshold and a
problem threshold), two separate ranges are defined when padding is at least one
minute. In this case, each range is attached to its threshold, and the two ranges can
overlap with no change in behavior.

If a value outside the acceptable range is specified, the default setting is used.

Default Setting3%

Minimum Setting3%

Maximum Setting10%

Note: If you set a value outside the acceptable range, then InfoSphere CDC uses
the defaults.

System parameters for InfoSphere CDC for IBM i (version 6.2 and earlier) 545
 Related concepts
System parameters for InfoSphere CDC for IBM i (version 6.2 and earlier) on
page 533

Monitor Sample Interval

VersionInfoSphere CDC for IBM i version 6.2 and earlier

Use this system parameter to set how often (in seconds) InfoSphere CDC updates
replication latency metrics. InfoSphere CDC samples the target system to determine
if latency has risen above or fallen below the specified threshold settings.

Applies ToSource and Target

Default Setting5 seconds

Minimum Setting0 seconds. Replication latency metrics are not updated.

Maximum Setting3600 seconds (one hour)

Notes:
v InfoSphere CDC generates latency notifications when latency rises above or falls
below the thresholds and places these in the Event Log.
v If you set a value outside the acceptable range, then InfoSphere CDC uses the
defaults.

Notification system parameters

Notification system parameters let you control if you should generate InfoSphere
CDC messages in the Event Log for specific events.

See also:
Heartbeat Timeout
Messages on Column Not Null Capable on page 547
Messages on Invalid Numerics on page 547
Progress Status Interval on page 548

Heartbeat Timeout
VersionInfoSphere CDC for IBM i version 6.2 and earlier

Use this system parameter to increase or decrease the communication timeout

interval (in minutes) before InfoSphere CDC detects a communication problem and
attempts to stop active replication processes.

InfoSphere CDC sends internal heartbeat notifications between the source and
target systems to verify communications and the status of replication processes for
each active subscription. If the source or target do not receive a reply to a
notification within the specified timeout interval, then InfoSphere CDC determines
that a problem has occurred and attempts to stop all its source and target
processes for each active subscription.

546 InfoSphere Change Data Capture Management Console: Administration Guide

 InfoSphere CDC places notifications (message identifiers DMU3165 and DMU0647)
in the Event Log when a heartbeat timeout occurs.

Applies ToSource

Default Setting15 minutes

Minimum Setting3 minutes

Maximum Setting999 minutes

Note: If you set a value outside the acceptable range, then InfoSphere CDC uses
the defaults.
Related concepts
System parameters for InfoSphere CDC for IBM i (version 6.2 and earlier) on
page 533

Messages on Column Not Null Capable

VersionInfoSphere CDC for IBM i version 6.2 and earlier

Use this system parameter to enable or disable InfoSphere CDC from generating a
message each time it attempts to replicate NULL to a target column that is
non-nullable.

Applies ToTarget

The Messages on Column Not Null Capable system parameter can be set to either
*YES or *NO:
v *YESEnables InfoSphere CDC to generate a message each time it attempts to
replicate NULL to a target column that is non- nullable.
v *NODisables InfoSphere CDC from generating a message each time it
attempts to replicate NULL to a target column that is non-nullable. For all
instances, you are notified by a message.

Default Setting*YES
Related concepts
System parameters for InfoSphere CDC for IBM i (version 6.2 and earlier) on
page 533

Messages on Invalid Numerics

VersionInfoSphere CDC for IBM i version 6.2 and earlier

Use this system parameter to enable or disable InfoSphere CDC from generating a
message each time it detects an invalid numeric field.

Applies ToTarget

The Messages on Invalid Numerics system parameter can be set to either *YES,
*NO, or *NB:
v *YESInfoSphere CDC generates a message for each invalid numeric field
detected.

System parameters for InfoSphere CDC for IBM i (version 6.2 and earlier) 547
 v *NOInfoSphere CDC does not generate a message for each invalid numeric
field detected. If you are sure that numeric data does not have to be validated,
set this parameter to *NO to maintain existing performance levels.
v *NBInfoSphere CDC does not generate a message when blank or uninitialized
numeric fields are detected. Messages for other types of invalid numeric data are
still generated.

Default Setting*YES
Related concepts
System parameters for InfoSphere CDC for IBM i (version 6.2 and earlier) on
page 533
Related reference
Numeric Column Validation on page 549

Progress Status Interval

VersionInfoSphere CDC for IBM i version 6.2 and earlier

Use this system parameter to set how often (in seconds) InfoSphere CDC issues
progress notifications. InfoSphere CDC generates notifications on the source and
target and these provide information about replication activities.

On the source, progress notifications identify:

v The bookmark sent by the source
v The corresponding log name
v The subscription name to which the bookmark was sent

On the target, progress notifications identify:

v The bookmark received by the target
v The corresponding log name
v The source ID from which the bookmark was received

Applies ToSource and Target

Default Setting0 seconds. No progress messages are issued.

Minimum Setting0 seconds

Maximum Setting7200 seconds

Notes:
v InfoSphere CDC places progress notifications in the Event Log.
v If you set a value outside the acceptable range, then InfoSphere CDC uses the
defaults.

548 InfoSphere Change Data Capture Management Console: Administration Guide

 Related concepts
System parameters for InfoSphere CDC for IBM i (version 6.2 and earlier) on
page 533

Data type system parameters

Data type system parameters let you control how InfoSphere CDC handles certain
data types.

See also:
Numeric Column Validation

Numeric Column Validation

VersionInfoSphere CDC for IBM i version 6.2 and earlier

Use this system parameter to enable or disable InfoSphere CDC from checking
decimal and numeric columns for valid formats before applying numeric data to
the target table.

Applies ToTarget

The Numeric Column Validation system parameter can be set to either *YES or
*NO:
v *YESEnables InfoSphere CDC to validate invalid packed/zoned data before
applying it to the target table. If invalid packed/zoned data is found, then
InfoSphere CDC generates a message is generated set the field to 0
automatically.
v *NODisables InfoSphere CDC from validating packed/zoned data before
applying it to the target table. If you are sure that numeric data does not have to
be validated, set this parameter to *NO to maintain existing performance levels.

Default Setting*YES
Related concepts
System parameters for InfoSphere CDC for IBM i (version 6.2 and earlier) on
page 533

Date and time column function system parameters

Date and time column function system parameters let you control how InfoSphere
CDC handles date and time in tables.

See also:
Default Date On Error

Default Date On Error

VersionInfoSphere CDC for IBM i version 6.2 and earlier

Use this system parameter to set which date InfoSphere CDC returns when an
invalid date is passed to the %TODATE column function.

Applies ToTarget

System parameters for InfoSphere CDC for IBM i (version 6.2 and earlier) 549
 The Default Date On Error system parameter can be set to *NEW or *OLD:
v *NEWReturns the date 1901-01-01.
v *OLDReturns the date 0001-01-01.

Default Setting*NEW
Related concepts
System parameters for InfoSphere CDC for IBM i (version 6.2 and earlier) on
page 533
Related reference
Date conversion%TODATE on page 238

Row and column filtering system parameters

Row and column filtering system parameters let you control what kind of data
InfoSphere CDC applies to the target system.

See also:
Audit Filtered Transactions
Critical Column Filtering on page 551

Audit Filtered Transactions

VersionInfoSphere CDC for IBM i version 6.2 and earlier

Use this system parameter to set which images you want to audit after InfoSphere
CDC applies a row update that satisfies a row-filtering expression. By default,
InfoSphere CDC audits both the before and after images after applying a row
update that satisfies a row-filtering expression.

Applies ToSource

The Audit Filtered Transactions system parameter can be set to either *YES or
*NO:
v *YESAudits both the before and after images when a row update results in
only one of these images satisfying a defined row-filtering expression.
v *NOAudits only the after image that satisfies or does not satisfy a defined
row-filtering expression.

Default Setting*YES

Guidelines
v You can use this system parameter to override a row-filtering expression when
it is necessary to audit both before and after images in the target table, but only
one of these images satisfies the row-filtering expression. In this scenario, you
can use two journal codes (FP and FB) to identify the images in the target audit
table that do not satisfy the row-filtering expression.

You may want to enable this system parameter to *YES when:

v Using LiveAudit to audit changes made on the source table.
v Recording both the before and after images in the target audit table when a row
update operation is applied to the assigned publication table.
v Using row-filtering expressions to filter rows placed in the target audit table.

550 InfoSphere Change Data Capture Management Console: Administration Guide

 Notes:
v Previous releases of InfoSphere CDC do no support this system parameter.
v The listed default setting (*YES) applies only to new InfoSphere CDC
installations on an IBM i server. The default setting for InfoSphere CDC
upgrades is *NO. This setting maintains existing InfoSphere CDC behavior prior
to support for this system parameter.
Related concepts
System parameters for InfoSphere CDC for IBM i (version 6.2 and earlier) on
page 533
About journal control fields on page 173

Critical Column Filtering

VersionInfoSphere CDC for IBM i version 6.2 and earlier

Use this system parameter to enable critical column selection.

Applies ToSource

The Critical Column Filtering system parameter can be set to either *YES or
*NO:
v *YESEnables critical column selection.
v *NODisables critical column selection.

Default Setting*NO
Related concepts
System parameters for InfoSphere CDC for IBM i (version 6.2 and earlier) on
page 533

Event log system parameters

Event log system parameters let you control how InfoSphere CDC interacts with
notify message queues.

See also:
Notify Message Queue
Notify Message Queue Library on page 552
Notify Message Threshold on page 552

Notify Message Queue

VersionInfoSphere CDC for IBM i version 6.2 and earlier

Use this system parameter to identify the name of the message queue that
InfoSphere CDC uses to send notifications when the number of errors exceeds the
notify message threshold system parameter.

Applies ToSource and Target

Default SettingQSYSOPR

System parameters for InfoSphere CDC for IBM i (version 6.2 and earlier) 551
 Note: You can set the notify message threshold using the Notify Message
Threshold system parameter.
Related concepts
System parameters for InfoSphere CDC for IBM i (version 6.2 and earlier) on
page 533
Related reference
Notify Message Threshold

Notify Message Queue Library

VersionInfoSphere CDC for IBM i version 6.2 and earlier

Use this system parameter to identify the name of the library where the notify
message queue resides.

Applies ToSource and Target

You can set the Notify Message Queue Library system parameter to one of the
following:
v The name of a library
v *LIBLSpecifies the set of libraries in your library list. The libraries are
searched in order for the first occurrence of the specified message queue.
v *CURLIBSpecifies the current library.

Default Setting*LIBL
Related concepts
System parameters for InfoSphere CDC for IBM i (version 6.2 and earlier) on
page 533
Related reference
Notify Message Queue on page 551

Notify Message Threshold

VersionInfoSphere CDC for IBM i version 6.2 and earlier

Use this system parameter to identify the number of errors that InfoSphere CDC
generates before it sends a notification to the notify message queue.

Applies ToSource and Target

Default Setting1 error

552 InfoSphere Change Data Capture Management Console: Administration Guide

 Related concepts
System parameters for InfoSphere CDC for IBM i (version 6.2 and earlier) on
page 533
Related reference
Notify Message Queue on page 551

Lock detection system parameters

Lock detection system parameters let you control how InfoSphere CDC applies
data when it detects a locked table or row.

See also:
Lock Timeout Value

Lock Timeout Value

VersionInfoSphere CDC for IBM i version 6.2 and earlier

Use this system parameter to set the amount of time (in seconds) that InfoSphere
CDC waits before attempting to modify a locked user or metadata table. When
InfoSphere CDC attempts to modify a locked table, it places a notification in the
Event Log. These notifications identify the specific table and row that InfoSphere
CDC could not modify.

Applies ToSource and Target

Default Setting30 seconds

Minimum Setting2 seconds

Maximum Setting60 seconds

Notes:
v If a table or row is locked, InfoSphere CDC waits for a specified timeout period
to expire before attempting to apply data again.
v If you set a value outside the acceptable range, then InfoSphere CDC uses the
defaults.
Related concepts
System parameters for InfoSphere CDC for IBM i (version 6.2 and earlier) on
page 533

System parameters for InfoSphere CDC for IBM i (version 6.2 and earlier) 553
554 InfoSphere Change Data Capture Management Console: Administration Guide
System parameters for InfoSphere CDC for DB2 UDB and
Teradata (version 6.0 and earlier)
System parameters let you control the behavior of InfoSphere CDC. If your
replication environment requires a particular configuration, then you can use
system parameters to modify the behavior of default operations in InfoSphere
CDC. The default system parameter settings are appropriate for most installations.
Maintain these default settings until you become familiar with the configuration of
InfoSphere CDC.

InfoSphere CDC provides system parameters that control the behavior of your
source and target datastores.

Note: If you make changes to a system parameter during active replication, you
must stop and restart replication for the changes to take effect.

When upgrading to a later version of InfoSphere CDC, any preexisting settings for
system parameters are maintained.

In this section, you will learn:

General product system parameters
Access Server system parameters on page 559
Cascading replication system parameters on page 562
Commitment control system parameters on page 563
Database translation log system parameters on page 566
Fastload system parameters on page 567
Latency system parameters on page 571
Lock detection system parameters on page 571
Multibyte character set system parameters on page 573
Notification system parameters on page 574
Replication system parameters on page 575
Tracing system parameters on page 577
Teradata TPump system parameters on page 578

General product system parameters

General product system parameters let you control basic features of InfoSphere
CDC and information you may have specified during installation.

See also:
audit_auth_ code on page 556
auth_ code on page 556
db_password on page 556
db_user on page 557
debug on page 557
engine_ port on page 557
log_file_quota on page 557

Copyright IBM Corp. 2008, 2011 555

 log_total_quota on page 557
md_db_url on page 558
md_schema on page 558
scrape_timeout on page 558
startup_timeout on page 558
target_debug on page 558
target_initial_codepage on page 559
ts_password on page 559
ts_product on page 559

audit_auth_ code
VersionInfoSphere CDC for DB2 UDB and InfoSphere CDC for Teradata version
6.0 and earlier

This system parameter identifies the authorization code used to enable the
LiveAudit feature in InfoSphere CDC. When assigning the authorization code to
this system parameter, authorization codes are case-sensitive; therefore, the code
assigned to this parameter must be identical to the one obtained from IBM.

Applies ToSource and Target for InfoSphere CDC for DB2 UDB

Does Not Apply ToInfoSphere CDC for Teradata

Related concepts
System parameters for InfoSphere CDC for DB2 UDB and Teradata (version 6.0
and earlier) on page 555
Setting system parameters on source and target datastores on page 71

auth_ code
VersionInfoSphere CDC for DB2 UDB and InfoSphere CDC for Teradata version
6.0 and earlier

This system parameter identifies the authorization code that is required to replicate
and receive data with InfoSphere CDC. When assigning the authorization code to
this system parameter, authorization codes are case-sensitive; therefore, the code
assigned to this parameter must be identical to the one obtained from IBM.

Applies ToSource and Target for InfoSphere CDC for DB2 UDB

Does Not Apply ToInfoSphere CDC for Teradata

Related concepts
System parameters for InfoSphere CDC for DB2 UDB and Teradata (version 6.0
and earlier) on page 555
Setting system parameters on source and target datastores on page 71

db_password
VersionInfoSphere CDC for DB2 UDB and InfoSphere CDC for Teradata version
6.0 and earlier

556 InfoSphere Change Data Capture Management Console: Administration Guide

 For information about setting this system parameter, see your IBM representative.

db_user
VersionInfoSphere CDC for DB2 UDB and InfoSphere CDC for Teradata version
6.0 and earlier

For information about setting this system parameter, see your IBM representative.

debug
VersionInfoSphere CDC for DB2 UDB and InfoSphere CDC for Teradata version
6.0 and earlier

For information about setting this system parameter, see your IBM representative.

engine_ port
VersionInfoSphere CDC for DB2 UDB and InfoSphere CDC for Teradata version
6.0 and earlier

This system parameter identifies the port number on the server that is being used
for communications with client workstations running Management Console and
other replication servers. This port number was specified during InfoSphere CDC
installation. It can be changed by modifying this system parameter or using the
Change Listener Port utility. For more information about this utility, see the
appropriate InfoSphere CDC installation and user manual.

The port number that you specify must be unused, and the same port number
cannot be used for any other application installed on the same server.

Applies ToSource and Target for InfoSphere CDC for DB2 UDB, Target only for
InfoSphere CDC for Teradata

Default Setting11111
Related concepts
System parameters for InfoSphere CDC for DB2 UDB and Teradata (version 6.0
and earlier) on page 555
Setting system parameters on source and target datastores on page 71

log_file_quota
VersionInfoSphere CDC for DB2 UDB and InfoSphere CDC for Teradata version
6.0 and earlier

For information about setting this system parameter, see your IBM representative.

log_total_quota
VersionInfoSphere CDC for DB2 UDB and InfoSphere CDC for Teradata version
6.0 and earlier

For information about setting this system parameter, see your IBM representative.

System parameters for InfoSphere CDC for DB2 UDB and Teradata (version 6.0 and earlier) 557
 md_db_url
VersionInfoSphere CDC for DB2 UDB and InfoSphere CDC for Teradata version
6.0 and earlier

For information about setting this system parameter, see your IBM representative.

md_schema
VersionInfoSphere CDC for DB2 UDB and InfoSphere CDC for Teradata version
6.0 and earlier

For information about setting this system parameter, see your IBM representative.

scrape_timeout
VersionInfoSphere CDC for DB2 UDB and InfoSphere CDC for Teradata version
6.0 and earlier

For information about setting this system parameter, see your IBM representative.

startup_timeout
VersionInfoSphere CDC for DB2 UDB and InfoSphere CDC for Teradata version
6.0 and earlier

This system parameter specifies the maximum waiting period, in seconds, for
process handling to complete during InfoSphere CDC startup. This system
parameter indicates how long the communication module waits for the database
initialization program to start before timing out.

Applies ToSource and Target for InfoSphere CDC for DB2 UDB, Target only for
InfoSphere CDC for Teradata

Default Setting120 seconds

Minimum Setting60 seconds

Maximum Setting3,600 seconds

Related concepts
System parameters for InfoSphere CDC for DB2 UDB and Teradata (version 6.0
and earlier) on page 555
Setting system parameters on source and target datastores on page 71

target_debug
VersionInfoSphere CDC for DB2 UDB and InfoSphere CDC for Teradata version
6.0 and earlier

For information about setting this system parameter, see your IBM representative.

558 InfoSphere Change Data Capture Management Console: Administration Guide

 target_initial_codepage
VersionInfoSphere CDC for DB2 UDB and InfoSphere CDC for Teradata version
6.0 and earlier

For information about setting this system parameter, see your IBM representative.

ts_password
VersionInfoSphere CDC for DB2 UDB and InfoSphere CDC for Teradata version
6.0 and earlier

For information about setting this system parameter, see your IBM representative.

ts_product
VersionInfoSphere CDC for DB2 UDB and InfoSphere CDC for Teradata version
6.0 and earlier

For information about setting this system parameter, see your IBM representative.

Access Server system parameters

Access Server system parameters are for managing Access Server.

See also:
accessserver_udp_ listenport
agent_assert on page 560
agent_debug on page 560
agent_jdbcdb2_driver on page 560
agent_jdbcdb2_driver_net on page 560
agent_jdbcpb_driver on page 560
agent_jdbcpb_driver_net on page 560
agent_max_connections_num on page 561
agent_message_version on page 561
agent_msg_resources_file on page 561
agent_src_engine_address on page 561
agent_src_engine_port on page 561
agent_src_engine_socket_tmout on page 561
agent_trace_in_message on page 561
agent_trace_out_message on page 562
agent_udp_ listenport on page 562

accessserver_udp_ listenport
VersionInfoSphere CDC for DB2 UDB and InfoSphere CDC for Teradata version
6.0 and earlier

This system parameter identifies the UDP listener port number used by Access
Server to receive auto-discovery broadcast InfoSphere CDC from different
datastores in your configuration. The port number that you specify must not
System parameters for InfoSphere CDC for DB2 UDB and Teradata (version 6.0 and earlier) 559
 already be in use on the client workstation, and must be the same port number
specified in Management Console when logging on. If the port number is changed
on a client workstation running Management Console, this system parameter must
be set to the updated port number.

Applies ToSource and Target for InfoSphere CDC for DB2 UDB, Target only for
InfoSphere CDC for Teradata

Default Setting10101
Related concepts
System parameters for InfoSphere CDC for DB2 UDB and Teradata (version 6.0
and earlier) on page 555
Setting system parameters on source and target datastores on page 71

agent_assert
VersionInfoSphere CDC for DB2 UDB and InfoSphere CDC for Teradata version
6.0 and earlier

For information about setting this system parameter, see your IBM representative.

agent_debug
VersionInfoSphere CDC for DB2 UDB and InfoSphere CDC for Teradata version
6.0 and earlier

For information about setting this system parameter, see your IBM representative.

agent_jdbcdb2_driver
VersionInfoSphere CDC for DB2 UDB and InfoSphere CDC for Teradata version
6.0 and earlier

For information about setting this system parameter, see your IBM representative.

agent_jdbcdb2_driver_net
VersionInfoSphere CDC for DB2 UDB and InfoSphere CDC for Teradata version
6.0 and earlier

For information about setting this system parameter, see your IBM representative.

agent_jdbcpb_driver
VersionInfoSphere CDC for DB2 UDB and InfoSphere CDC for Teradata version
6.0 and earlier

For information about setting this system parameter, see your IBM representative.

agent_jdbcpb_driver_net
VersionInfoSphere CDC for DB2 UDB and InfoSphere CDC for Teradata version
6.0 and earlier

560 InfoSphere Change Data Capture Management Console: Administration Guide

 For information about setting this system parameter, see your IBM representative.

agent_max_connections_num
VersionInfoSphere CDC for DB2 UDB and InfoSphere CDC for Teradata version
6.0 and earlier

For information about setting this system parameter, see your IBM representative.

agent_message_version
VersionInfoSphere CDC for DB2 UDB and InfoSphere CDC for Teradata version
6.0 and earlier

For information about setting this system parameter, see your IBM representative.

agent_msg_resources_file
VersionInfoSphere CDC for DB2 UDB and InfoSphere CDC for Teradata version
6.0 and earlier

For information about setting this system parameter, see your IBM representative.

agent_src_engine_address
VersionInfoSphere CDC for DB2 UDB and InfoSphere CDC for Teradata version
6.0 and earlier

For information about setting this system parameter, see your IBM representative.

agent_src_engine_port
VersionInfoSphere CDC for DB2 UDB and InfoSphere CDC for Teradata version
6.0 and earlier

For information about setting this system parameter, see your IBM representative.

agent_src_engine_socket_tmout
VersionInfoSphere CDC for DB2 UDB and InfoSphere CDC for Teradata version
6.0 and earlier

For information about setting this system parameter, see your IBM representative.

agent_trace_in_message
VersionInfoSphere CDC for DB2 UDB and InfoSphere CDC for Teradata version
6.0 and earlier

For information about setting this system parameter, see your IBM representative.

System parameters for InfoSphere CDC for DB2 UDB and Teradata (version 6.0 and earlier) 561
 agent_trace_out_message
VersionInfoSphere CDC for DB2 UDB and InfoSphere CDC for Teradata version
6.0 and earlier

For information about setting this system parameter, see your IBM representative.

agent_udp_ listenport
VersionInfoSphere CDC for DB2 UDB and InfoSphere CDC for Teradata version
6.0 and earlier

This system parameter identifies the port number on the replication server used by
the UDP listener for auto-discovery broadcasts sent from Access Server. The port
number that you specify must be unique.

Applies ToSource and Target for InfoSphere CDC for DB2 UDB, Target only for
InfoSphere CDC for Teradata

Default Setting2222
Related concepts
System parameters for InfoSphere CDC for DB2 UDB and Teradata (version 6.0
and earlier) on page 555
Setting system parameters on source and target datastores on page 71

Cascading replication system parameters

Cascading replication system parameters control InfoSphere CDC cascading
replication.

See also:
cascade_replication

cascade_replication
VersionInfoSphere CDC for DB2 UDB and InfoSphere CDC for Teradata version
6.0 and earlier

This system parameter indicates whether or not replicated data received from the
source can be replicated (or cascaded) to other servers. This system parameter is
set on the server that receives replicated data and can cascade the data to one or
more other servers. It is applicable when implementing cascading replication.

Applies ToSource for InfoSphere CDC for DB2 UDB

Does Not Apply ToInfoSphere CDC for Teradata

Set this parameter to one of the following:

v NPrevent replicated data received from the source from being cascaded to
other servers.
v YAllow replicated data received from the source to be cascaded to other
servers.

562 InfoSphere Change Data Capture Management Console: Administration Guide

 Default SettingY
Related concepts
System parameters for InfoSphere CDC for DB2 UDB and Teradata (version 6.0
and earlier) on page 555
Setting system parameters on source and target datastores on page 71

Commitment control system parameters

Commitment control system parameters let you control how InfoSphere CDC
issues commits to the target system.

See also:
commit_group_size
commit_ interval on page 564
refresh_commit_ block_size on page 565
scraper_trans_ num_limit on page 565
source_default_ commit_level on page 565
target_default_commit_level on page 566

commit_group_size
VersionInfoSphere CDC for DB2 UDB and InfoSphere CDC for Teradata version
6.0 and earlier

This system parameter specifies the number of rows that must be applied to the
target database before a commit is issued.

Normally, commits issued to the target database are in response to commits issued
by applications running on the source. This system parameter should only be used
when you want manage commits by controlling how often they are issued to the
target database. This approach can be used to reduce the overhead of frequent
commits to the database. However, managing commits in this manner may result
in inconsistent data in the source and target databases over time. To manage
commits to the target database by setting the commit group size, you must disable
commitment control on the target, by setting the target_default_commit_level on
page 566 system parameter.

To properly calibrate database commits in your environment, you must work with
this system parameter and the dobatch on page 575 system parameter. If the
commit interval frequently expires before a commit group with the specified
number of applied rows has been formed, a smaller number of rows are
committed. In this case, you can decrease the commit group size or increase the
commit interval. However, when a commit group contains an insufficient number
of applied rows for it to be committed, you must set the commit interval to ensure
data is committed within a reasonable period of time.

If this system parameter is set to 0, then:

v Commits are issued at regular intervals when a non-zero commit interval is
specified.
v A commit is issued for each applied row when a zero commit interval is
specified. When commit_group_size and dobatch on page 575 are both set to
zero, InfoSphere CDC internally sets this system parameter to 1 row (default
setting) to ensure commits are issued.

System parameters for InfoSphere CDC for DB2 UDB and Teradata (version 6.0 and earlier) 563
 Applies ToTarget, InfoSphere CDC for DB2 UDB only

Default Setting1 row. A commit is issued for each applied row.

Minimum Setting0
Related concepts
System parameters for InfoSphere CDC for DB2 UDB and Teradata (version 6.0
and earlier) on page 555
Setting system parameters on source and target datastores on page 71

commit_ interval
VersionInfoSphere CDC for DB2 UDB and InfoSphere CDC for Teradata version
6.0 and earlier

This system parameter specifies the amount of time, in seconds, between

consecutive commits issued to the target database. Normally, commits issued to the
target database are in response to commits issued by applications running on the
source. This system parameter should only be used when you want to manage
commits by controlling how often they are issued to the target database. This
approach can be used to reduce the overhead of frequent commits to the database.
However, managing commits in this manner may result in inconsistent data in the
source and target databases over time. To manage commits to the target database
by setting the interval between consecutive commits, you must disable
commitment control on the target, by setting the target_default_commit_level on
page 566 system parameter.

To properly calibrate database commits in your environment, you must work with
this system parameter and the commit_group_size on page 563 system
parameter. For commit groups that have an insufficient number of applied rows
for a commit to be issued, use this system parameter to prevent applied rows in
the commit group from being uncommitted for a long period of time. In particular,
you can use it to force commits during periods of transaction inactivity. However,
if you set the commit interval so that it frequently expires before a commit group
with the specified number of applied rows has been formed, a smaller number of
rows are committed. In this case, you can increase the commit interval or decrease
the commit group size.

If this system parameter is set to 0, then:

v A commit is issued every 5 seconds (default setting) when the size of the
commit group is more than one row. In this case, InfoSphere CDC internally sets
this system parameter to 5 seconds (default setting) to ensure that a commit
group which cannot be committed due to an insufficient number of applied
rows is committed in 5 seconds.
v A commit is issued for each applied row when a zero commit group size is
specified. When commit_group_size and dobatch on page 575 are both set to
zero, InfoSphere CDC internally sets commit_group_size to 1 row (default
setting) to ensure commits are issued.

Applies ToTarget, InfoSphere CDC for DB2 UDB only

Default Setting5 seconds

Minimum Setting0

564 InfoSphere Change Data Capture Management Console: Administration Guide

 Related concepts
System parameters for InfoSphere CDC for DB2 UDB and Teradata (version 6.0
and earlier) on page 555
Setting system parameters on source and target datastores on page 71

refresh_commit_ block_size
VersionInfoSphere CDC for DB2 UDB and InfoSphere CDC for Teradata version
6.0 and earlier

This system parameter identifies the number of records to be inserted into a target
table during a refresh operation before a commit is issued to make those records
persistent. If the tables that you are replicating are relatively large, it is
recommended that you increase the block size to improve performance.

Applies ToTarget

Default Setting1,000 records

Related concepts
System parameters for InfoSphere CDC for DB2 UDB and Teradata (version 6.0
and earlier) on page 555
Setting system parameters on source and target datastores on page 71

scraper_trans_ num_limit
VersionInfoSphere CDC for DB2 UDB and InfoSphere CDC for Teradata version
6.0 and earlier

This system parameter identifies the number of row level entries that are staged in
memory before they are sent to the target. This parameter should be set to the
largest commitment cycle size on your server. Commitment cycle size is the
number of transactions in one commitment cycle. For example, the size of the
following commitment cycle is six:
insert into <table> <values>
insert into <table> <values>
insert into <table> <values>
insert into <table> <values>
insert into <table> <values>
commit

Applies ToSource, InfoSphere CDC for DB2 UDB only

Default Setting1,000,000 row level entries

Related concepts
System parameters for InfoSphere CDC for DB2 UDB and Teradata (version 6.0
and earlier) on page 555
Setting system parameters on source and target datastores on page 71

source_default_ commit_level
VersionInfoSphere CDC for DB2 UDB and InfoSphere CDC for Teradata version
6.0 and earlier

System parameters for InfoSphere CDC for DB2 UDB and Teradata (version 6.0 and earlier) 565
 This system parameter indicates the commitment control level for transactions
mirrored from the source.

Applies ToSource, InfoSphere CDC for DB2 UDB

Does Not Apply ToInfoSphere CDC for Teradata

Set this parameter to one of the following:

v 0Disables commitment control for transaction processing. No attempt to
maintain transaction consistency is performed during mirroring.
v 2Only records in a committed transaction are mirrored to the target. This
setting provides true transaction consistency by ensuring that only committed
transactions are sent to the target.

Default Setting0

target_default_commit_level
VersionInfoSphere CDC for DB2 UDB and InfoSphere CDC for Teradata version
6.0 and earlier

This system parameter indicates the commitment control level for transactions
applied on the target.

Applies ToTarget, InfoSphere CDC for DB2 UDB

Does Not Apply ToInfoSphere CDC for Teradata

Set this parameter to one of the following:

v 2A commit to the target database is performed when all records in a
transaction have been received and applied. This setting provides true
transaction consistency by ensuring that entire transactions are committed to the
target database. If a communications or server failure occurs, a partially applied
transaction in the target database is rolled back to the last transaction that was
committed.
v 0Disables commitment control for transaction processing. No attempt to
maintain transaction consistency is performed during mirroring.

Default Setting2
Related concepts
System parameters for InfoSphere CDC for DB2 UDB and Teradata (version 6.0
and earlier) on page 555
Setting system parameters on source and target datastores on page 71

Database translation log system parameters

Database transaction log system parameters let you control how InfoSphere CDC
cleans the logs of the distribution database. You can also control often InfoSphere
CDC reports its log position to the target and performs log synchronization
between the source and the target.

See also:
report_position_interval on page 567

566 InfoSphere Change Data Capture Management Console: Administration Guide

 report_position_interval
VersionInfoSphere CDC for DB2 UDB and InfoSphere CDC for Teradata version
6.0 and earlier

This system parameter specifies how often, in seconds, the source informs the
target about its position in the current log during inactive periods. During inactive
periods, when there are no log entries pertaining to the current subscription, the
source informs the target of its current position so that the target can advance its
bookmarks accordingly. By specifying a low setting for this parameter, the target
can reflect more accurately how far replication has progressed. This system
parameter can also prevent the reprocessing of entries that do not apply to the
table currently being replicated.

The value of this parameter affects the information that is displayed in

Management Console. A high setting for this parameter may result in presented
information that is not up-to-date.

Applies ToSource, InfoSphere CDC for DB2 UDB

Does Not Apply ToInfoSphere CDC for Teradata

Default Setting5 seconds

Minimum Setting1 second

Maximum Setting300 seconds

Related concepts
System parameters for InfoSphere CDC for DB2 UDB and Teradata (version 6.0
and earlier) on page 555
Setting system parameters on source and target datastores on page 71

Fastload system parameters

Fastload system parameters allow you to configure the Teradata Fastload utility.
InfoSphere CDC for Teradata uses the Fastload utility to load replicated data into
Teradata databases.

See also:
refresh_del_fastload_file
dofastload on page 568
fastload_backup_path on page 569
fastload_in_whole on page 569
fastload_path on page 569
make_fastload_log_file on page 570
max_fastload_ file_size on page 570

refresh_del_fastload_file
VersionInfoSphere CDC for DB2 UDB and InfoSphere CDC for Teradata version
6.0 and earlier

System parameters for InfoSphere CDC for DB2 UDB and Teradata (version 6.0 and earlier) 567
 This system parameter indicates whether or not Teradata FastLoad files are deleted
after using the utility to refresh data in a Teradata database under standard
replication. You can keep these files for future reference or delete them to increase
available disk space.

To refresh data in a Teradata database using the Teradata FastLoad utility, set
dofastload =Y. For more information about the Teradata FastLoad utility, see your
Teradata documentation.

Applies ToTarget, InfoSphere CDC for Teradata only

Set this parameter to one of the following:

v NKeep the Teradata FastLoad files after data has been refreshed in a Teradata
database.
v YDelete the Teradata FastLoad files after data has been refreshed in a Teradata
database.

Default SettingY
Related concepts
System parameters for InfoSphere CDC for DB2 UDB and Teradata (version 6.0
and earlier) on page 555
Setting system parameters on source and target datastores on page 71

dofastload
VersionInfoSphere CDC for DB2 UDB and InfoSphere CDC for Teradata version
6.0 and earlier

This system parameter enables or disables a Fast Bulk Copy (BCP) refresh.
Generally, a BCP refresh provides a better level of performance than a batch refresh
(see dobatch on page 575) or the standard row-by-row refresh.

Applies ToTarget, InfoSphere CDC for DB2 UDB and InfoSphere CDC for
Teradata

Set this parameter to one of the following:

v NDo not perform a BCP refresh.
v YPerform a BCP refresh. In addition, you must:
1. Set the fastload_path on page 569 system parameter to the path of the
temporary file.
2. Set the fastload_backup_path on page 569 system parameter to the path of
the stored backup image.
3. Ensure there are no large object (LOB) data types within your user data. BCP
refresh cannot work with tables containing LOB data types. If a LOB column
is found, a standard (row-by-row) refresh is performed.
To determine if there is an error in the loading process for BCP refresh, examine
the message appended to the loadmsg file in your InfoSphere CDC installation
directory.

Default SettingN

568 InfoSphere Change Data Capture Management Console: Administration Guide

 Related concepts
System parameters for InfoSphere CDC for DB2 UDB and Teradata (version 6.0
and earlier) on page 555
Setting system parameters on source and target datastores on page 71

fastload_backup_path
VersionInfoSphere CDC for DB2 UDB and InfoSphere CDC for Teradata version
6.0 and earlier

This system parameter identifies the path to a stored backup image of the loaded
data for a BCP refresh. The database user that owns the InfoSphere CDC metadata
tables must have read and write permissions to the files whose locations are
identified by the fastload_pathand fastload_backup_path system parameters.

Applies ToTarget, InfoSphere CDC for DB2 UDB only

Related concepts
System parameters for InfoSphere CDC for DB2 UDB and Teradata (version 6.0
and earlier) on page 555
Setting system parameters on source and target datastores on page 71

fastload_in_whole
VersionInfoSphere CDC for DB2 UDB and InfoSphere CDC for Teradata version
6.0 and earlier

This system parameter indicates how data is transferred to the Teradata FastLoad
utility in order to refresh data in a Teradata database. Data can be refreshed in a
single bulk operation or incrementally. The size of each data file passed to the
Teradata FastLoad utility is determined by the max_fastload_ file_size on page
570 system parameter. For more information about the utility, see your Teradata
documentation.

Applies ToTarget, InfoSphere CDC for Teradata only

Set this parameter to one of the following:

v NSubmit a data file to the Teradata FastLoad utility immediately after the file
has been filled with replicated data.
v YSubmit all data to the Teradata FastLoad utility after it has been received
from the publication server.

Default SettingN
Related concepts
System parameters for InfoSphere CDC for DB2 UDB and Teradata (version 6.0
and earlier) on page 555
Setting system parameters on source and target datastores on page 71

fastload_path
VersionInfoSphere CDC for DB2 UDB and InfoSphere CDC for Teradata version
6.0 and earlier

System parameters for InfoSphere CDC for DB2 UDB and Teradata (version 6.0 and earlier) 569
 This system parameter identifies the path to the temporary file used for a Fast
Bulk Copy (BCP) refresh. During a BCP refresh, a copy image of the loaded data is
saved in this temporary file.

The database user that owns the InfoSphere CDC metadata tables must have read
and write permissions to the files whose locations are identified by the
fastload_path on page 569 and fastload_backup_path on page 569 system
parameters.

Applies ToSource and Target for InfoSphere CDC for DB2 UDB, Target only for
InfoSphere CDC for Teradata
Related concepts
System parameters for InfoSphere CDC for DB2 UDB and Teradata (version 6.0
and earlier) on page 555
Setting system parameters on source and target datastores on page 71

make_fastload_log_file
VersionInfoSphere CDC for DB2 UDB and InfoSphere CDC for Teradata version
6.0 and earlier

This system parameter indicates whether or not Teradata FastLoad log files are
created. Log files contain messages generated during refresh operations performed
by the Teradata FastLoad utility. You can create log files and examine their contents
to determine whether or not refresh operations were successful.

Log files are named DM_<username>_<tablename>.log , where <username> is the

database user name that owns the subscription table being refreshed and
<tablename> is the name of the subscription table. These files are placed in the
directory identified by the fastload_path on page 569 system parameter. The
database user name and InfoSphere CDC installation directory were specified
during the installation process.

Applies ToTarget, InfoSphere CDC for Teradata only

Set this parameter to one of the following:

v NDo not create Teradata FastLoad log files to track data refresh operations.
v YCreate the Teradata FastLoad log files to track data refresh operations.

For more information about the Teradata FastLoad utility, see your Teradata
documentation.

Default SettingN
Related concepts
System parameters for InfoSphere CDC for DB2 UDB and Teradata (version 6.0
and earlier) on page 555
Setting system parameters on source and target datastores on page 71

max_fastload_ file_size
VersionInfoSphere CDC for DB2 UDB and InfoSphere CDC for Teradata version
6.0 and earlier

570 InfoSphere Change Data Capture Management Console: Administration Guide

 This system parameter identifies the size, in bytes, that the data file must reach
before the Teradata FastLoad utility refreshes data in a Teradata database. If the
amount of refreshed data is larger than the specified size, InfoSphere CDC closes
the data file after it has been filled and passes it to the Teradata FastLoad utility so
that data is refreshed in the Teradata database. Additional data files are used to
ensure the remaining data is refreshed.

Applies ToTarget, InfoSphere CDC for Teradata only

Default Setting2,000,000,000 bytes

Related concepts
System parameters for InfoSphere CDC for DB2 UDB and Teradata (version 6.0
and earlier) on page 555
Setting system parameters on source and target datastores on page 71

Latency system parameters

Latency system parameters let you control how often InfoSphere CDC generates a
latency notification and updates latency statistics in the Event Log.

See also:
monitor_sample_interval

monitor_sample_interval
VersionInfoSphere CDC for DB2 UDB and InfoSphere CDC for Teradata version
6.0 and earlier

This system parameter identifies the period of time, in seconds, between

consecutive updates to a storage area that is used to maintain replication latency
metrics. Management Console references this area to present replication latency
information.

Applies ToSource and Target for InfoSphere CDC for DB2 UDB, Target only for
InfoSphere CDC for Teradata

Default Setting5 seconds

Minimum Setting0 seconds. Replication latency metrics are not updated.

Maximum Setting3,600 seconds (1 hour)

Related concepts
System parameters for InfoSphere CDC for DB2 UDB and Teradata (version 6.0
and earlier) on page 555
Setting system parameters on source and target datastores on page 71

Lock detection system parameters

Lock detection system parameters let you control how InfoSphere CDC applies
data when it detects a locked table or row.

See also:
dm_lock_detection on page 572

System parameters for InfoSphere CDC for DB2 UDB and Teradata (version 6.0 and earlier) 571
 dm_lock_timeout

dm_lock_detection
VersionInfoSphere CDC for DB2 UDB and InfoSphere CDC for Teradata version
6.0 and earlier

This system parameter indicates whether or not table and row locking detection is
enabled. If a table or row has been locked by another process while InfoSphere
CDC attempts to modify that table or row, InfoSphere CDC waits for a specific
amount of time, specified by dm_lock_timeout, before attempting to apply data
again. InfoSphere CDC generates messages, which can be displayed in Event Log,
when an attempt is made to modify a locked target table or row. These messages
identify the specific table or row that could not be modified.

Applies ToSource and Target for InfoSphere CDC for DB2 UDB, Target only for
InfoSphere CDC for Teradata

Set this parameter to one of the following:

v YEnables table and row locking detection.
v NDisables table and row locking detection. InfoSphere CDC waits until the
locked table or row becomes available.

Default SettingY
Related concepts
System parameters for InfoSphere CDC for DB2 UDB and Teradata (version 6.0
and earlier) on page 555
Setting system parameters on source and target datastores on page 71

dm_lock_timeout
VersionInfoSphere CDC for DB2 UDB and InfoSphere CDC for Teradata version
6.0 and earlier

Applies ToSource and Target for InfoSphere CDC for DB2 UDB, Target only for
InfoSphere CDC for Teradata

Specifies the amount of time, in seconds, InfoSphere CDC waits for a locked table
or row to become available. This system parameter is applicable only when table
and row locking detection is enabled, using the dm_lock_detection system
parameter.

Default Setting30 seconds

Minimum Setting1 second

Maximum Setting60 seconds

572 InfoSphere Change Data Capture Management Console: Administration Guide

 Related concepts
System parameters for InfoSphere CDC for DB2 UDB and Teradata (version 6.0
and earlier) on page 555
Setting system parameters on source and target datastores on page 71

Multibyte character set system parameters

Multibyte character set system parameters let you control how InfoSphere CDC
treats character sets during replication.

See also:
unicode_handling

unicode_handling
VersionInfoSphere CDC for DB2 UDB and InfoSphere CDC for Teradata version
6.0 and earlier

This system parameter indicates the default method of treating data in defined
Unicode columns. For information about how data in each Unicode source column
is treated, see Replicating multibyte (MBCS) and double-byte (DBCS) character
data on page 163. For each InfoSphere CDC installation on a server, this system
parameter defines the system default method of treating data in Unicode columns.
If a Unicode column is set to System Default on the Encoding tab of the Mapping
Details view in Management Console, InfoSphere CDC uses the method for
processing Unicode columns that you select in this system parameter.

Applies ToSource for InfoSphere CDC for DB2 UDB

The following DB2 UDB data types are considered to be Unicode columns, and are
therefore affected by the value assigned to this system parameter:
v GRAPHIC
v VARGRAPHIC
v LONG VARGRAPHIC with code page 1200 (UCS-2 big endian)

This system parameter is set to either CHAR or NOCHANGE:

v CHARInfoSphere CDC treats all data in Unicode columns as single-byte
characters. Use this setting when Unicode columns contain single-byte character
data.
v NOCHANGEInfoSphere CDC treats all data in Unicode columns as a
continuous bit stream. Use this setting when Unicode columns contain
non-single-byte character data. NOCHANGE ensures InfoSphere CDC will
handle non-single-byte character data in the same way as previous InfoSphere
CDC releases.

Notes:
v NOCHANGE does not ensure that replicated non-single-byte character data in
Unicode columns are represented properly on the target. For replicated
non-single-byte character data, you may have to apply user exit programs or
other customization to properly represent data in Unicode columns. For more
information about user exit programs, see your InfoSphere CDC for DB2 UDB
documentation.

System parameters for InfoSphere CDC for DB2 UDB and Teradata (version 6.0 and earlier) 573
 v If you are using IBM DB2 UDB Version 7 database, a BCP refresh locks the
replication data tablespace during loading. For this reason, metadata is not
updated during a BCP refresh if the metadata tables are located in the same
tablespace as the replicated data. For more information on how to avoid this
situation, see the appropriate InfoSphere CDC commands reference or user
manual.

Default SettingNOCHANGE

Note: NOCHANGE does not ensure that replicated non-single-byte character data
in Unicode columns are represented properly on the target. For replicated
non-single-byte character data, you many need to apply user exit programs or
other customization to properly represent the data in Unicode columns.
Related concepts
System parameters for InfoSphere CDC for DB2 UDB and Teradata (version 6.0
and earlier) on page 555
Setting system parameters on source and target datastores on page 71

Notification system parameters

Notification system parameters let you control if you should generate InfoSphere
CDC messages in the Event Log for specific events.

See also:
dm_status_interval
heartbeat_timeout on page 575

dm_status_interval
VersionInfoSphere CDC for DB2 UDB and InfoSphere CDC for Teradata version
6.0 and earlier

This system parameter specifies how often, in seconds, progress messages are
issued. Progress messages are displayed in Event Log to provide detailed and
regular information about InfoSphere CDC replication activities.

On the source, these messages identify the current bookmark that was sent by the
source, its corresponding log name, and the subscription name to which the
bookmark was sent. On the target, progress messages identify the current
bookmark that was received by the target, its corresponding log name, and the
source ID from which the bookmark was received.

Applies ToSource and Target for InfoSphere CDC for DB2 UDB, Target only for
InfoSphere CDC for Teradata

Default Setting0 seconds. No progress messages are issued.

Minimum Setting0 seconds

Maximum Setting7200 seconds

574 InfoSphere Change Data Capture Management Console: Administration Guide

 Related concepts
System parameters for InfoSphere CDC for DB2 UDB and Teradata (version 6.0
and earlier) on page 555
Setting system parameters on source and target datastores on page 71

heartbeat_timeout
VersionInfoSphere CDC for DB2 UDB and InfoSphere CDC for Teradata version
6.0 and earlier

This system parameter specifies the duration, in minutes, of communication

inactivity before active InfoSphere CDC processes for a subscription are stopped. If
a value outside the acceptable range is specified, the default setting is used.

Applies ToSource, InfoSphere CDC for DB2 UDB

Does Not Apply ToInfoSphere CDC for Teradata

Default Setting15 minutes

Minimum Setting3 minutes

Maximum Setting999 minutes

Related concepts
System parameters for InfoSphere CDC for DB2 UDB and Teradata (version 6.0
and earlier) on page 555
Setting system parameters on source and target datastores on page 71

Replication system parameters

Replication system parameters let you control how InfoSphere CDC behaves after
detecting errors during replication. You can also control how often InfoSphere CDC
communicates the status of replication activities, and how InfoSphere CDC should
apply a refresh operation.

See also:
dobatch
source_default_active_refresh on page 576
target_mirror_number_of_errors_before_abort on page 576
target_print_refresh_details on page 576
target_refresh_number_of_errors_before_abort on page 577

dobatch
VersionInfoSphere CDC for DB2 UDB and InfoSphere CDC for Teradata version
6.0 and earlier

This system parameter enables or disables a batch refresh. Generally, a batch

refresh provides a better level of performance than the standard row-by-row
refresh.

Applies ToTarget, InfoSphere CDC for DB2 UDB

System parameters for InfoSphere CDC for DB2 UDB and Teradata (version 6.0 and earlier) 575
 Does Not Apply ToInfoSphere CDC for Teradata

Set this parameter to one of the following:

v YPerform a batch refresh. In addition, you must ensure that there are no large
objects (LOB) data types within your user data. A batch refresh cannot work
with tables containing LOB data types. If a LOB column is found, a standard
(row-by-row) refresh is performed.
v NDo not perform a batch refresh.

Default SettingY
Related concepts
System parameters for InfoSphere CDC for DB2 UDB and Teradata (version 6.0
and earlier) on page 555
Setting system parameters on source and target datastores on page 71

source_default_active_refresh
VersionInfoSphere CDC for DB2 UDB and InfoSphere CDC for Teradata version
6.0 and earlier

For information about setting this system parameter, see your IBM representative.

target_mirror_number_of_errors_before_abort
VersionInfoSphere CDC for DB2 UDB and InfoSphere CDC for Teradata version
6.0 and earlier

This system parameter indicates how many errors to accept on the target before
stopping mirroring. To perform mirroring through any number of errors, set this
parameter to -1.

Applies ToTarget

Attention: If you set this parameter to values greater than 0, data inconsistencies
between the source and target tables may occur.

Default Setting0
Related concepts
System parameters for InfoSphere CDC for DB2 UDB and Teradata (version 6.0
and earlier) on page 555
Setting system parameters on source and target datastores on page 71

target_print_refresh_details
VersionInfoSphere CDC for DB2 UDB and InfoSphere CDC for Teradata version
6.0 and earlier

For information about setting this system parameter, see your IBM representative.

576 InfoSphere Change Data Capture Management Console: Administration Guide

 Related concepts
System parameters for InfoSphere CDC for DB2 UDB and Teradata (version 6.0
and earlier) on page 555
Setting system parameters on source and target datastores on page 71

target_refresh_number_of_errors_before_abort
VersionInfoSphere CDC for DB2 UDB and InfoSphere CDC for Teradata version
6.0 and earlier

This system parameter indicates how many errors to accept on the target before
stopping a refresh. To perform refresh through any number of errors, set this
parameter to -1.

Applies ToTarget

Attention: Do not set this parameter to 0. This setting stops the refresh after the
first record has been successfully refreshed.

Default Setting1

Tracing system parameters

Tracing system parameters let you perform diagnostic activities with InfoSphere
CDC.

See also:
message_handler_trace_level
message_trace_level
target_trace_logical_messages
target_trace_physical_messages on page 578
trace_level on page 578
trace_on on page 578

message_handler_trace_level
VersionInfoSphere CDC for DB2 UDB and InfoSphere CDC for Teradata version
6.0 and earlier

For information about setting this system parameter, see your IBM representative.

message_trace_level
VersionInfoSphere CDC for DB2 UDB and InfoSphere CDC for Teradata version
6.0 and earlier

For information about setting this system parameter, see your IBM representative.

target_trace_logical_messages
VersionInfoSphere CDC for DB2 UDB and InfoSphere CDC for Teradata version
6.0 and earlier

System parameters for InfoSphere CDC for DB2 UDB and Teradata (version 6.0 and earlier) 577
 For information about setting this system parameter, see your IBM representative.

target_trace_physical_messages
VersionInfoSphere CDC for DB2 UDB and InfoSphere CDC for Teradata version
6.0 and earlier

For information about setting this system parameter, see your IBM representative.

trace_level
VersionInfoSphere CDC for DB2 UDB and InfoSphere CDC for Teradata version
6.0 and earlier

For information about setting this system parameter, see your IBM representative.

trace_on
VersionInfoSphere CDC for DB2 UDB and InfoSphere CDC for Teradata version
6.0 and earlier

For information about setting this system parameter, see your IBM representative.

Teradata TPump system parameters

Teradata TPump system parameters allow you to configure the Teradata TPump
utility. InfoSphere CDC for Teradata uses the TPump utility to load replicated data
into Teradata databases.

See also:
tpump_arc_data_files
tpump_files_root_folder on page 579
tpump_logging on page 580
tpump_max_file_size on page 580
tpump_script_params_file on page 581
tpump_script_val_file on page 581
tpump_ timeout on page 582

tpump_arc_data_files
VersionInfoSphere CDC for DB2 UDB and InfoSphere CDC for Teradata version
6.0 and earlier

This system parameter enables or disables the archiving of data (.dat) and script
(.script) files that are used by the Teradata TPump utility. InfoSphere CDC
generates the data and script files that are used by the Teradata TPump utility to
load data into Teradata databases. Data files contain the replicated data that is
loaded into Teradata, and script files specify what is contained in the data files and
how data is loaded. These files are named DM_<timestamp>.dat and
DM_<timestamp>.script, where <timestamp> is the number of milliseconds from
midnight on January 1, 1970 to the time when the file was created.

Applies ToTarget, InfoSphere CDC for Teradata only

578 InfoSphere Change Data Capture Management Console: Administration Guide

 Set this parameter to one of the following:
v NDisables the archiving of Teradata TPump data and script files. Teradata
TPump data and script files are deleted immediately after data has been loaded
into a Teradata database.
v YEnables the archiving of Teradata TPump data and script files.

For more information about the Teradata TPump utility in InfoSphere CDC, see
your InfoSphere CDC for Teradata documentation.

Default SettingN
Related concepts
System parameters for InfoSphere CDC for DB2 UDB and Teradata (version 6.0
and earlier) on page 555
Setting system parameters on source and target datastores on page 71

tpump_files_root_folder
VersionInfoSphere CDC for DB2 UDB and InfoSphere CDC for Teradata version
6.0 and earlier

This system parameter identifies the main directory that is created to accommodate
all Teradata TPump files. This setting specifies where all Teradata TPump files are
located. Subdirectories under the main directory are labeled with the name of the
source ID that is used to receive replicated data. This means that for each source
ID, Teradata TPump files are maintained in a separate directory.

Applies ToTarget, InfoSphere CDC for Teradata only

The three subdirectories that are defined are as follows:

v <tpump_files_root_folder>\<source_id>\TPump
Contains all data (.dat) and script (.script) files that are generated by
InfoSphere CDC and used by the Teradata TPump utility to load data into
Teradata databases. Data files contain the replicated data that is loaded into
Teradata, and script files specify what is contained in the data files and how
data is loaded. These files are named DM_<timestamp>.dat and
DM_<timestamp>.script , where <timestamp> is the number of milliseconds from
midnight on January 1, 1970 to the time when the file was created.
v <tpump_files_root_folder>\<pubid>\TPump\archive
Contains all archived data (.dat) and script (.script) files.
v <tpump_files_root_folder>\<pubid>\TPump\log
Contains all Teradata TPump log files. For more information about log files, see
tpump_logging on page 580. These files are named DM_<timestamp>.log ,
where <timestamp> is the number of milliseconds from midnight on January 1,
1970 to the time when the file was created.

where <tpump_files_root_folder> is the value assigned to this system parameter, and

<source_id> is the source ID defined in Management Console that is used to receive
replicated data.

For example, if <tpump_files_root_folder> is d:\test, and <source_id> is

NEWYORK, then the following three Teradata TPump subdirectories are created
for the NEWYORK source ID: d:\test\NEWYORK\TPump, d:\test\NEWYORK\TPump\
archive, and d:\test\NEWYORK\TPump\log.

System parameters for InfoSphere CDC for DB2 UDB and Teradata (version 6.0 and earlier) 579
 For more information about the Teradata TPump utility in InfoSphere CDC, see
your InfoSphere CDC for Teradata documentation.

Default SettingInfoSphere CDC installation directory

Related concepts
System parameters for InfoSphere CDC for DB2 UDB and Teradata (version 6.0
and earlier) on page 555
Setting system parameters on source and target datastores on page 71

tpump_logging
VersionInfoSphere CDC for DB2 UDB and InfoSphere CDC for Teradata version
6.0 and earlier

This system parameter indicates whether or not Teradata TPump log files are
created. The tpump_files_root_folder on page 579system parameter specifies the
location of these files. Log files are named DM_<timestamp>.log, where <timestamp>
is the number of milliseconds from midnight on January 1, 1970 to the time when
the file was created.

Applies ToTarget, InfoSphere CDC for Teradata only

Set this parameter to one of the following:

v YCreate Teradata TPump log files to track data loading operations.
v NDo not create Teradata TPump log files to track data loading operations.

For more information about the Teradata TPump utility in InfoSphere CDC, see
your InfoSphere CDC for Teradata documentation.

Default SettingY
Related concepts
System parameters for InfoSphere CDC for DB2 UDB and Teradata (version 6.0
and earlier) on page 555
Setting system parameters on source and target datastores on page 71

tpump_max_file_size
VersionInfoSphere CDC for DB2 UDB and InfoSphere CDC for Teradata version
6.0 and earlier

This system parameter identifies the size, in bytes, that the data file (.dat) must
reach before the Teradata TPump utility loads data into a Teradata database. Data
files contain the replicated data that is loaded into Teradata. To optimize
performance, you should set this system parameter so that the amount of time it
takes for the Teradata TPump utility to load data into a Teradata database is
approximately equivalent to the time it takes for the data file to reach the specified
size. As a result, the next load operation can start shortly after the current load
operation has been completed. Therefore, if the amount of time to load data is
longer than the amount of time to fill the data file in preparation for the next load,
decrease the number of bytes assigned to this system parameter.

In addition to setting this system parameter, you must also set with the tpump_
timeout on page 582 system parameter to specify when the Teradata TPump

580 InfoSphere Change Data Capture Management Console: Administration Guide

 utility loads data into a Teradata database. If the timeout period frequently expires
before the data file reaches its specified size, you can increase the timeout period
or decrease the data file size to allow loads to also be determined by data file size.
However, when a data file contains an insufficient amount of data for a load to be
performed, the timeout period must be set to ensure data is loaded within a
reasonable period of time.

For information about where the data file is located, see tpump_files_root_folder
on page 579. For more information about the Teradata TPump utility in InfoSphere
CDC, see yourInfoSphere CDC for Teradata documentation.

Applies ToTarget, InfoSphere CDC for Teradata only

Default Setting100,000 bytes

Related concepts
System parameters for InfoSphere CDC for DB2 UDB and Teradata (version 6.0
and earlier) on page 555
Setting system parameters on source and target datastores on page 71

tpump_script_params_file
VersionInfoSphere CDC for DB2 UDB and InfoSphere CDC for Teradata version
6.0 and earlier

For information about setting this system parameter, see your IBM representative.

tpump_script_val_file
VersionInfoSphere CDC for DB2 UDB and InfoSphere CDC for Teradata version
6.0 and earlier

Identifies the name of the XML file that InfoSphere CDC uses to generate script
(.script) files during replication. Teradata TPump script files specify what is
contained in the data files and how data in these files is loaded into Teradata
databases. The file identified by this system parameter contains a set of Teradata
TPump command parameter settings. You can modify the settings in this file so
that the script files generated by InfoSphere CDC during replication are
customized for your working environment. For more information about
customizing the generated script files using the XML file identified by this system
parameter, see your InfoSphere CDC for Teradata documentation.

IBM recommends that you do not change the default setting for this system
parameter. Instead, modify the tpumpscripttsdefaults.xml file so that it contains
the command parameter settings that you want. If you want to specify a different
XML, this file must exist in the InfoSphere CDC installation directory and contain
the correct XML markup to generate valid script files.

Generally, the default values in the tpumpscripttsdefaults.xml file are suitable for
most working environments. If you want to modify the settings in this file, you
must be familiar with XML and Teradata TPump. For more information about
Teradata TPump commands and command parameters, see your Teradata
documentation.

Applies ToTarget, InfoSphere CDC for Teradata only

System parameters for InfoSphere CDC for DB2 UDB and Teradata (version 6.0 and earlier) 581
 Default Settingtpumpscripttsdefaults.xml
Related concepts
System parameters for InfoSphere CDC for DB2 UDB and Teradata (version 6.0
and earlier) on page 555
Setting system parameters on source and target datastores on page 71

tpump_ timeout
VersionInfoSphere CDC for DB2 UDB and InfoSphere CDC for Teradata version
6.0 and earlier

This system parameter indicates the amount of time, in seconds, between

consecutive Teradata TPump data loads into a Teradata database. You can use this
system parameter to force data to be loaded when the data file (see
tpump_max_file_size on page 580) contains insufficient data for a load to be
performed. It can be used to prevent data in a data file from not being loaded for a
long period of time. In particular, you can use this system parameter to force loads
during periods of slow transaction activity. However, if you set the timeout period
so that it frequently expires before a data file can reach the specified size, a smaller
amount of data is loaded. In this case, you can increase the timeout period or
decrease the data file size to allow loads to also be determined by data file size.

For more information about the Teradata TPump utility in InfoSphere CDC, see
your InfoSphere CDC for Teradata documentation.

Applies ToTarget, InfoSphere CDC for Teradata only

Minimum Setting0 seconds. Disables the timeout so that a load is only

performed when the data file reaches the size specified by the
tpump_max_file_size system parameter.

Default Setting5 seconds

Related concepts
System parameters for InfoSphere CDC for DB2 UDB and Teradata (version 6.0
and earlier) on page 555
Setting system parameters on source and target datastores on page 71

582 InfoSphere Change Data Capture Management Console: Administration Guide

System parameters for InfoSphere CDC for DB2 LUW (version
6.1 and later)
System parameters let you control the behavior of InfoSphere CDC. If your
replication environment requires a particular configuration, then you can use
system parameters to modify the behavior of default operations in InfoSphere
CDC. The default system parameter settings are appropriate for most installations.
Maintain these default settings until you become familiar with the configuration of
InfoSphere CDC.

InfoSphere CDC provides system parameters that control the behavior of your
source and target datastores.

Notes:
v If you make changes to a system parameter during active replication, you must
stop and restart InfoSphere CDC for the changes to take effect.
v When upgrading to a higher version of InfoSphere CDC, any preexisting settings
for system parameters are maintained.

In this section, you will learn:

General product system parameters
Notification system parameters on page 584
Maximize throughput system parameters on page 585
Encoding system parameters on page 586
Disk resource system parameters on page 587
Apply process system parameters on page 589

General product system parameters

General product system parameters let you control basic features of InfoSphere
CDC and information you may have specified during installation.

See also:
mirror_auto_restart_interval_minutes

mirror_auto_restart_interval_minutes
VersionInfoSphere CDC for IBM DB2 UDB version 6.3 Fix Pack 3 TFE 9 and
later.

Use this parameter to indicate how long (in minutes) InfoSphere CDC will attempt
to automatically restart continuous mirroring for persistent subscriptions.

Applies ToSource

Default0

Minimum0

Maximum60

Copyright IBM Corp. 2008, 2011 583

Notification system parameters
Notification system parameters let you control if you should generate InfoSphere
CDC messages in the Event Log for specific events.

See also:
events_max_retain
global_conversion_not_possible_warning
global_shutdown_after_no_heartbeat_response_minutes

events_max_retain
VersionInfoSphere CDC for DB2 LUW version 6.1 and later

Use this system parameter to control the maximum number of events that
InfoSphere CDC will store in the event log. If InfoSphere CDC generates more
events than the specified maximum, then the earliest events will be deleted.

Default Setting10000

Minimum -1

Maximum2147483647

global_conversion_not_possible_warning
VersionInfoSphere CDC for DB2 LUW version 6.1 and later

Use this system parameter to control whether or not InfoSphere CDC generates a
warning in the Management Console Event Log in the following situations:
v Data conversion is not possible for a specific data value.
v Converted data types are encountered that are out of range.

Set this parameter to one of the following:

v trueGenerates a warning in the Event Log if data conversion is not possible
for a specific data value or converted data types are encountered that are out of
range.
v falseDoes not generate a warning in the Event Log if data conversion is not
possible for a specific data value or converted data types are encountered that
are out of range.

Applies ToTarget

Default Settingfalse
Related concepts
System parameters for InfoSphere CDC for DB2 LUW (version 6.1 and later) on
page 583
Setting system parameters on source and target datastores on page 71

global_shutdown_after_no_heartbeat_response_minutes
VersionInfoSphere CDC for DB2 LUW version 6.1 and later

584 InfoSphere Change Data Capture Management Console: Administration Guide

 Use this system parameter to specify the duration, in minutes, of communication
inactivity before active InfoSphere CDC processes for a subscription are stopped. If
a value outside the acceptable range is specified, the default setting is used.

Applies ToSource

Default Setting15 minutes

Minimum Setting3 minutes

Maximum Setting999 minutes

Related concepts
System parameters for InfoSphere CDC for DB2 LUW (version 6.1 and later) on
page 583
Setting system parameters on source and target datastores on page 71

Maximize throughput system parameters

InfoSphere CDC system parameters allow you to significantly reduce the workload
of the target database during mirroring. The InfoSphere CDC apply process groups
transactions on the target to reduce the workload. Every commit on the target
database will correspond with a commit on the target. However, it may not
perform every commit that was done on the source. For example, if the source
does three small transactions containing one operation each, the target may commit
all three operations as part of a single transaction. You can use this grouping of
system parameters to significantly reduce the resources required by the target
database. The default settings are appropriate for most databases, but if your target
system has limited resources and an increase in latency is acceptable, you can
adjust the settings appropriately.

See also:
mirror_interim_commit_threshold
refresh_commit_after_max_operations on page 586

mirror_interim_commit_threshold
VersionInfoSphere CDC for IBM DB2 UDB version 6.3 Fix Pack 3 and later.

By default, InfoSphere CDC guarantees transactional delivery of change data to the

target. This ensures that if any data from a source transaction is committed to the
target, then all other in scope operations from that source transaction are
committed as well.

In cases where large transactions are done on the source system, it can be more
efficient to break a large transaction into smaller transactions when applying data
to the target. You can configure this behavior using this system parameter.

The default value of 0 for this system parameter indicates that the product
guarantees transactional delivery of change data to the target. A value greater than
0 indicates that you want InfoSphere CDC to break up large transactions into
smaller transactions. For example, a value of 2000 indicates that InfoSphere CDC
will split up large source transactions so that each transaction committed to the
target database contains no more than 2000 operations.

System parameters for InfoSphere CDC for DB2 LUW (version 6.1 and later) 585
 Applies ToTarget

Default Setting0

Minimum Setting0

refresh_commit_after_max_operations
VersionInfoSphere CDC for DB2 LUW version 6.1 and later

This system parameter identifies the number of rows comprising each transaction
during refresh. To reduce the workload on the target database during refresh,
InfoSphere CDC periodically commits the changes to the target database rather
than performing the refresh as a single large transaction.

Applies ToTarget

Default Setting1000

Maximum Setting2147483647

Minimum Setting1
Related concepts
System parameters for InfoSphere CDC for DB2 LUW (version 6.1 and later) on
page 583
Setting system parameters on source and target datastores on page 71

Encoding system parameters

For some system parameters, you can set the default method for treating data in
defined Unicode columns, and you can set the default character encoding for your
database.

See also:
global_unicode_as_char

global_unicode_as_char
VersionInfoSphere CDC for DB2 LUW version 6.1 and later

This system parameter indicates the default method of treating data in defined
Unicode columns. For each InfoSphere CDC installation on a server, this system
parameter defines the system default method of treating data in Unicode columns.
If a Unicode column is set to System Default on the Encoding tab of the Mapping
Details view in Management Console, InfoSphere CDC uses the method for
processing Unicode columns that you select in this system parameter.

Set this parameter to one of the following:

v trueInfoSphere CDC treats all data in Unicode columns as single-byte
characters. Use this setting when Unicode columns contain single-byte character
data.
v falseInfoSphere CDC treats all data in Unicode columns as a continuous bit
stream. Use this setting when Unicode columns contain non-single-byte

586 InfoSphere Change Data Capture Management Console: Administration Guide

 character data. Setting this system parameter to false ensures that InfoSphere
CDC handles non-single-byte character data in the same way as previous
InfoSphere CDC releases.

Note: Setting this parameter to false does not ensure that replicated
non-single-byte character data in Unicode columns are represented properly on
the target. For replicated non-single-byte character data, you may have to apply
user exit programs or other customizations to properly represent data in
Unicode columns. For more information about user exit programs, see the
InfoSphere CDC End-User Documentation for your platform.

Applies ToSource

Default Settingfalse
Related concepts
System parameters for InfoSphere CDC for DB2 LUW (version 6.1 and later) on
page 583
Setting system parameters on source and target datastores on page 71

Disk resource system parameters

Some system parameters control memory usage in InfoSphere CDC. For improved
performance, if you are able to allocate more than the default value of 512 MB for
the InfoSphere CDC Java Virtual Machine, then you can adjust the disk resource
system parameters to use the increased memory.

See also:
mirror_global_disk_quota_mb
mirror_global_disk_quota_gb on page 588
staging_store_can_run_independently on page 588
staging_store_disk_quota_gb on page 589
staging_store_disk_quota_mb on page 589

mirror_global_disk_quota_mb
VersionInfoSphere CDC for DB2 LUW version 6.3

Use this system parameter to globally set a disk quota (in MB) for all capture
components including temporary files, transaction queues, and LOBs which are
staged on the target before being applied. InfoSphere CDC will manage disk space
utilization across all components as required.

Most databases have a mechanism that allows you to roll back or undo changes to
your database by storing uncommitted changes. Similarly, InfoSphere CDC uses
the disk quota controlled by this system parameter to store in scope change data
that has not been committed in your database. Once the database transaction is
committed, the disk space used by the transaction is released. Note that InfoSphere
CDC stores the data in memory to improve performance and will only persist the
data to disk if memory is unavailable.

The default setting of this system parameter is such that the product will only stop
replicating after this disk quota exhausts all available disk space on your system. If
you would prefer the product to stop replicating after it uses a specific amount of
disk space, you can set the value with this system parameter.
System parameters for InfoSphere CDC for DB2 LUW (version 6.1 and later) 587
 Applies ToSource and Target

Default Setting9223372036854775807

Maximum9223372036854775807

Minimum100

mirror_global_disk_quota_gb
VersionInfoSphere CDC for DB2 LUW version 6.5

Use this system parameter to globally set a disk quota (in GB) for all capture
components including temporary files, transaction queues, and LOBs which are
staged on the target before being applied. InfoSphere CDC will manage disk space
utilization across all components as required.

Most databases have a mechanism that allows you to roll back or undo changes to
your database by storing uncommitted changes. Similarly, InfoSphere CDC uses
the disk quota controlled by this system parameter to store in scope change data
that has not been committed in your database. Once the database transaction is
committed, the disk space used by the transaction is released. Note that InfoSphere
CDC stores the data in memory to improve performance and will only persist the
data to disk if memory is unavailable.

The default setting of this system parameter is such that the product will only stop
replicating after this disk quota exhausts all available disk space on your system. If
you would prefer the product to stop replicating after it uses a specific amount of
disk space, you can set the value with this system parameter.

Applies ToSource and Target

Default Setting9223372036854775807

Maximum9223372036854775807

Minimum1

staging_store_can_run_independently
VersionInfoSphere CDC for DB2 LUW version 6.3 and later

Use this system parameter to determine if subscriptions will exclusively use the
InfoSphere CDC staging store to accumulate change data or if they will be allowed
to use independent log readers and log parsers to receive data directly from the
database logs.

Set this parameter to one of the following values:

v trueSpecifies that subscriptions can use either the staging store to accumulate
change data or use independent log readers and log parsers to receive data
directly from the database logs.
v falseSpecifies that subscriptions will use the InfoSphere CDC staging store to
accumulate change data.

588 InfoSphere Change Data Capture Management Console: Administration Guide

 Changes to this system parameter value will only take effect after the replication
engine is restarted.

If you change the value from true to false, you will need to clear the staging store
before beginning replication.

Applies ToSource

Default Settingtrue

staging_store_disk_quota_gb
VersionInfoSphere CDC for DB2 LUW version 6.5

Use this system parameter to specify the maximum amount of disk space that will
be utilized by the InfoSphere CDC staging store on your source system.

If you have enabled the Continuous Capture feature and you are accumulating
change data in your staging store when subscriptions are stopped, you should take
into consideration the additional disk utilization that this feature requires.

Applies ToSource

Default Setting100 GB

Maximum Setting2147483647 GB

Minimum Setting1 GB

staging_store_disk_quota_mb
VersionInfoSphere CDC for DB2 LUW version 6.1 to version 6.3

Use this system parameter to specify the maximum amount of disk space that will
be utilized by the InfoSphere CDC staging store on your source system.

If you have enabled the Continuous Capture feature and you are accumulating
change data in your staging store when subscriptions are stopped, you should take
into consideration the additional disk utilization that this feature requires.

Applies ToSource

Default Setting2147483647 MB

Maximum Setting2147483647 MB

Minimum Setting100 MB

Apply process system parameters

Some system parameters adjust the way InfoSphere CDC applies rows, column
data, and error handling.

See also:
convert_not_nullable_column on page 590

System parameters for InfoSphere CDC for DB2 LUW (version 6.1 and later) 589
 convert_not_nullable_message
global_max_batch_size on page 591
mirror_end_on_error on page 591
mirror_expected_errors_list on page 592
refresh_end_on_error on page 592
refresh_expected_errors_list on page 592
refresh_loader_drop_index on page 593
refresh_with_referential_integrity on page 593
userexit_max_lob_size_kb on page 593

convert_not_nullable_column
VersionInfoSphere CDC for DB2 LUW version 6.1 and later

Use this system parameter to control how InfoSphere CDC behaves when it applies
a null value to a non-nullable column. When set to true (default value), the null
value will be replaced with a default value (based on the data type of the column)
and InfoSphere CDC will generate a warning in the event log. When set to false,
InfoSphere CDC applies the null value directly to the non-nullable column which
will result in an error and cause a shutdown of InfoSphere CDC on the target
database.

Note: If you decided to set this system parameter to false and have specified this
as an error for InfoSphere CDC to ignore using the mirror_expected_errors_list
system parameter, then InfoSphere CDC will ignore the error and not shutdown.

Set this parameter to one of the following:

v trueNull value will be replaced with default value for non-nullable column,
and a warning event will be logged.
v falseNull data will be applied as-is to non-nullable column and database will
usually return an error code.

Applies ToSource and Target

Default SettingTrue

convert_not_nullable_message
VersionInfoSphere CDC for DB2 LUW version 6.1 and later

Use this system parameter to determine if a message will be generated in the

Event Log when InfoSphere CDC converts a null value to a default value when
applied to a non-nullable column. When set to true (default value), InfoSphere
CDC will log the event the first time it encounters a null to non-nullable mapping
(on a per column per table basis). When set to false, InfoSphere CDC will not
generate a message when a null value is converted to a default value.

Note: This system parameter applies only when the convert_not_nullable_column

parameter has been set to true.

Set this parameter to one of the following:

v trueGenerates a warning message in the Event Log the first time a null value
is converted to a default value on a per column per table basis.
590 InfoSphere Change Data Capture Management Console: Administration Guide
 v falseNo warning message is generated in the Event Log.

Applies ToTarget

Default SettingTrue

global_max_batch_size
VersionInfoSphere CDC for DB2 LUW version 6.1 and later

Use this system parameter to specify the maximum number of rows that
InfoSphere CDC can place in an array and apply to the target database during
refresh or mirroring. InfoSphere CDC collects rows and places them in an array (in
memory) while receiving table-level operations from the source system. InfoSphere
CDC applies the rows from the array when there is a change to a different table,
when there is a new table-level operation, or when the maximum number of rows
in an array has been reached. You can use this parameter during mirroring only if
mirror_end_on_error is true and mirror_expected_errors_list is empty. Use only
during a refresh if refresh_end_on_error is true and refresh_expected_errors_list is
empty. Before InfoSphere CDC places rows into an array, it allocates memory for
the maximum number of rows you specify and multiplies this integer by the
maximum length of a row. If the maximum number of rows is too large, then
InfoSphere CDC cannot allocate enough memory and will shut down. Management
Console references this area to present replication latency information.

Applies ToTarget

Default Setting25 rows

Maximum Setting2147483647 rows

Minimum Setting1 row

mirror_end_on_error
VersionInfoSphere CDC for DB2 LUW version 6.1 and later

Use this system parameter to indicate if you want to end mirroring after an apply
error occurs on the target database.

Set this parameter to one of the following:

v trueEnd mirroring after an apply error on the target database.
v falseDo not end mirroring after an apply error on the target database.

Applies ToTarget

Default SettingTrue

System parameters for InfoSphere CDC for DB2 LUW (version 6.1 and later) 591
 Related concepts
System parameters for InfoSphere CDC for DB2 LUW (version 6.1 and later) on
page 583
Setting system parameters on source and target datastores on page 71

mirror_expected_errors_list
VersionInfoSphere CDC for DB2 LUW version 6.1 and later

Use this system parameter when you want InfoSphere CDC to ignore one or more
database errors when applying data changes to the target during mirroring. The
error specified must correspond to the integer error code (database-vendor specific)
returned by the SQLException class in JDBC (Java Database Connectivity). Specify
multiple errors with a comma separated list of integer error codes.

For example, if you want InfoSphere CDC to continue mirroring when it

encounters error codes 4250 and 4452 in your DB2 LUW target database, set this
parameter to mirror_expected_errors_list=4250,4452.

Note: Latency may increase when using this system parameter since InfoSphere
CDC will not use JDBC array apply in order to track the errors specified.

Applies ToTarget

refresh_end_on_error
VersionInfoSphere CDC for DB2 LUW version 6.1 and later

Use this system parameter to indicate if you want to end a refresh after an apply
error occurs.

Set this parameter to one of the following:

v trueEnd a refresh after an apply error occurs.
v falseDo not end a refresh after an apply error occurs.

Applies ToTarget

Default SettingTrue
Related concepts
System parameters for InfoSphere CDC for DB2 LUW (version 6.1 and later) on
page 583
Setting system parameters on source and target datastores on page 71

refresh_expected_errors_list
VersionInfoSphere CDC for DB2 LUW version 6.1 and later

Use this system parameter when you want InfoSphere CDC to ignore one or more
database errors when refreshing data to the target. The error specified must
correspond to the integer error code (database-vendor specific) returned by the
SQLException class in JDBC (Java Database Connectivity). Specify multiple errors
with a comma separated list of integer error codes.

592 InfoSphere Change Data Capture Management Console: Administration Guide

 For example, if you want InfoSphere CDC to continue refresh when it encounters
error codes 4250 and 4452 in your DB2 LUW target database, set this parameter to
mirror_expected_errors_list=4250,4452.

Note: Latency may increase when using this system parameter since InfoSphere
CDC will not use JDBC array apply in order to track the errors specified.

Applies ToTarget

refresh_loader_drop_index
VersionInfoSphere CDC for DB2 LUW version 6.1 and later

This system parameter indicates whether or not InfoSphere CDC will drop all
indexes on the tables being refreshed and then rebuild the indexes after the refresh.
In some environments, this may improve refresh performance.

If the refresh fails for any reason, InfoSphere CDC for DB2 LUW provides two
commands (dmviewrepairsql and dmrunrepairsql) that allow you to recover and
rebuild (or optionally clear) the index. You can also manually recreate all table
indexes.

Applies ToTarget

Default Settingfalse

refresh_with_referential_integrity
VersionInfoSphere CDC for DB2 LUW version 6.1 and later

Use this system parameter to indicate whether or not you want the data removed
from all the target tables being refreshed before repopulating any of them. This is
most useful when there are referential integrity constraints on the tables being
refreshed.

Set this parameter to one of the following:

v trueIndicates that InfoSphere CDC will first remove all data in reverse of the
specified refresh order. When specifying the refresh order, in general parent
tables should appear before the referenced child tables. The product will then
remove data from the child tables before the parent tables.
v falseIndicates that InfoSphere CDC will not first remove all data from your
tables and will refresh the tables in the specified order.

Applies ToSource

Default Settingfalse

userexit_max_lob_size_kb
VersionInfoSphere CDC for DB2 LUW version 6.1 and later

Use this system parameter to set the maximum size of LOB data (in kb) that
InfoSphere CDC can pass to a user exit.

System parameters for InfoSphere CDC for DB2 LUW (version 6.1 and later) 593
 Applies ToTarget

Default Setting128 kb

Maximum9223372036854775807 kb

Minimum1 kb

594 InfoSphere Change Data Capture Management Console: Administration Guide

System parameters for InfoSphere CDC for Teradata (version
6.2 and later)
System parameters let you control the behavior of InfoSphere CDC. If your
replication environment requires a particular configuration, then you can use
system parameters to modify the behavior of default operations in InfoSphere
CDC. The default system parameter settings are appropriate for most installations.
Maintain these default settings until you become familiar with the configuration of
InfoSphere CDC.

InfoSphere CDC provides system parameters that control the behavior of your
source and target datastores.

Notes:
v If you make changes to a system parameter during active replication, you must
stop and restart InfoSphere CDC for the changes to take effect.
v When upgrading to a higher version of InfoSphere CDC, any pre-existing
settings for system parameters are maintained.

In this section, you will learn:

Notification system parameters
Maximize throughput system parameters on page 596
Disk resource system parameters on page 598
Apply process system parameters on page 599
Teradata TPump system parameters on page 603
Fastload system parameters on page 606

Notification system parameters

Notification system parameters let you control if you should generate InfoSphere
CDC messages in the Event Log for specific events.

See also:
events_max_retain
global_conversion_not_possible_warning on page 596
global_shutdown_after_no_heartbeat_response_minutes on page 596

events_max_retain
VersionInfoSphere CDC for Teradata version 6.2 and later

Use this system parameter to control the maximum number of events that
InfoSphere CDC will store in the event log. If InfoSphere CDC generates more
events than the specified maximum, then the earliest events will be deleted.

Default Setting10000

Minimum -1

Copyright IBM Corp. 2008, 2011 595

 Maximum2147483647

global_conversion_not_possible_warning
VersionInfoSphere CDC for Teradata version 6.2 and later

Use this system parameter to control whether or not InfoSphere CDC generates a
warning in the Management Console Event Log in the following situations:
v Data conversion is not possible for a specific data value.
v Converted data types are encountered that are out of range.

Set this parameter to one of the following:

v trueGenerates a warning in the Event Log if data conversion is not possible
for a specific data value or converted data types are encountered that are out of
range.
v falseDoes not generate a warning in the Event Log if data conversion is not
possible for a specific data value or converted data types are encountered that
are out of range.

Applies ToTarget

Default Settingfalse

global_shutdown_after_no_heartbeat_response_minutes
VersionInfoSphere CDC for Teradata version 6.2 and later

Use this system parameter to specify the duration, in minutes, of communication

inactivity before active InfoSphere CDC processes for a subscription are stopped. If
a value outside the acceptable range is specified, the default setting is used.

Applies ToSource

Default Setting15 minutes

Minimum Setting3 minutes

Maximum Setting999 minutes

Maximize throughput system parameters

InfoSphere CDC system parameters allow you to significantly reduce the workload
of the target database during mirroring. The InfoSphere CDC apply process groups
transactions on the target to reduce the workload. Every commit on the target
database will correspond with a commit on the target. However, it may not
perform every commit that was done on the source. For example, if the source
does three small transactions containing one operation each, the target may commit
all three operations as part of a single transaction. You can use this grouping of
system parameters to significantly reduce the resources required by the target
database. The default settings are appropriate for most databases, but if your target
system has limited resources and an increase in latency is acceptable, you can
adjust the settings appropriately.

See also:

596 InfoSphere Change Data Capture Management Console: Administration Guide

 global_max_batch_size
mirror_interim_commit_threshold

global_max_batch_size
VersionInfoSphere CDC for Teradata version 6.2 and later

Use this system parameter to specify the maximum number of rows that
InfoSphere CDC can place in an array and apply to the target database during
mirroring. InfoSphere CDC collects rows and places them in an array (in memory)
while receiving table-level operations from the source system. InfoSphere CDC
applies the rows from the array when there is a change to a different table, when
there is a new table-level operation, or when the maximum number of rows in an
array has been reached. You can use this parameter during mirroring only if
mirror_end_on_error is true and mirror_expected_errors_list is empty. Before
InfoSphere CDC places rows into an array, it allocates memory for the maximum
number of rows you specify and multiplies this integer by the maximum length of
a row. If the maximum number of rows is too large, then InfoSphere CDC cannot
allocate enough memory and will shut down. Management Console references this
area to present replication latency information.

Applies ToTarget

Default Setting25 rows

Maximum Setting2147483647 rows

Minimum Setting1 row

Note: This parameter can only be used if mirror_td_apply_method has been set to
JDBC.
Related reference
mirror_td_apply_method on page 601

mirror_interim_commit_threshold
VersionInfoSphere CDC for Teradata version 6.3 Fix Pack 3 and later.

By default, InfoSphere CDC guarantees transactional delivery of change data to the

target. This ensures that if any data from a source transaction is committed to the
target, then all other in scope operations from that source transaction are
committed as well.

In cases where large transactions are done on the source system, it can be more
efficient to break a large transaction into smaller transactions when applying data
to the target. You can configure this behavior using this system parameter.

The default value of 0 for this system parameter indicates that the product
guarantees transactional delivery of change data to the target. A value greater than
0 indicates that you want InfoSphere CDC to break up large transactions into
smaller transactions. For example, a value of 2000 indicates that InfoSphere CDC
will split up large source transactions so that each transaction committed to the
target database contains no more than 2000 operations.

Applies ToTarget
System parameters for InfoSphere CDC for Teradata (version 6.2 and later) 597
 Default Setting0

Minimum Setting0

Disk resource system parameters

Some system parameters control memory usage in InfoSphere CDC. For improved
performance, if you are able to allocate more than the default value of 512 MB for
the InfoSphere CDC Java Virtual Machine, then you can adjust the disk resource
system parameters to use the increased memory.

See also:
mirror_global_disk_quota_mb
mirror_global_disk_quota_gb

mirror_global_disk_quota_mb
VersionInfoSphere CDC for Teradata version 6.3

Use this system parameter to globally set a disk quota (in MB) for all capture
components including temporary files, transaction queues, and LOBs which are
staged on the target before being applied. InfoSphere CDC will manage disk space
utilization across all components as required.

Most databases have a mechanism that allows you to roll back or undo changes to
your database by storing uncommitted changes. Similarly, InfoSphere CDC uses
the disk quota controlled by this system parameter to store in scope change data
that has not been committed in your database. Once the database transaction is
committed, the disk space used by the transaction is released. Note that InfoSphere
CDC stores the data in memory to improve performance and will only persist the
data to disk if memory is unavailable.

The default setting of this system parameter is such that the product will only stop
replicating after this disk quota exhausts all available disk space on your system. If
you would prefer the product to stop replicating after it uses a specific amount of
disk space, you can set the value with this system parameter.

Applies ToSource and Target

Default Setting9223372036854775807

Maximum9223372036854775807

Minimum100

mirror_global_disk_quota_gb
VersionInfoSphere CDC for Teradata version 6.5

Use this system parameter to globally set a disk quota (in GB) for all capture
components including temporary files, transaction queues, and LOBs which are
staged on the target before being applied. InfoSphere CDC will manage disk space
utilization across all components as required.

598 InfoSphere Change Data Capture Management Console: Administration Guide

 Most databases have a mechanism that allows you to roll back or undo changes to
your database by storing uncommitted changes. Similarly, InfoSphere CDC uses
the disk quota controlled by this system parameter to store in scope change data
that has not been committed in your database. Once the database transaction is
committed, the disk space used by the transaction is released. Note that InfoSphere
CDC stores the data in memory to improve performance and will only persist the
data to disk if memory is unavailable.

The default setting of this system parameter is such that the product will only stop
replicating after this disk quota exhausts all available disk space on your system. If
you would prefer the product to stop replicating after it uses a specific amount of
disk space, you can set the value with this system parameter.

Applies ToSource and Target

Default Setting9223372036854775807

Maximum9223372036854775807

Minimum1

Apply process system parameters

Some system parameters adjust the way InfoSphere CDC applies rows, column
data, and error handling.

See also:
convert_not_nullable_column
convert_not_nullable_message on page 600
mirror_end_on_error on page 600
mirror_expected_errors_list on page 601
mirror_td_apply_method on page 601
refresh_end_on_error on page 602
refresh_expected_errors_list on page 602
trim_char_to_varchar on page 602
trim_varchar_to_varchar on page 603
userexit_max_lob_size_kb on page 603

convert_not_nullable_column
VersionInfoSphere CDC for Teradata version 6.2 and later

Use this system parameter to control how InfoSphere CDC behaves when it applies
a null value to a non-nullable column. When set to true (default value), the null
value will be replaced with a default value (based on the data type of the column)
and InfoSphere CDC will generate a warning in the event log. When set to false,
InfoSphere CDC applies the null value directly to the non-nullable column which
will result in an error and cause a shutdown of InfoSphere CDC on the target
database.

Note: If you decided to set this system parameter to false and have specified this
as an error for InfoSphere CDC to ignore using the mirror_expected_errors_list
system parameter, then InfoSphere CDC will ignore the error and not shutdown.

System parameters for InfoSphere CDC for Teradata (version 6.2 and later) 599
 Set this parameter to one of the following:
v trueNull value will be replaced with default value for non-nullable column,
and a warning event will be logged.
v falseNull data will be applied as-is to non-nullable column and database will
usually return an error code.

Applies ToSource and Target

Default SettingTrue

convert_not_nullable_message
VersionInfoSphere CDC for Teradata version 6.2 and later

Use this system parameter to determine if a message will be generated in the

Event Log when InfoSphere CDC converts a null value to a default value when
applied to a non-nullable column. When set to true (default value), InfoSphere
CDC will log the event the first time it encounters a null to non-nullable mapping
(on a per column per table basis). When set to false, InfoSphere CDC will not
generate a message when a null value is converted to a default value.

Note: This system parameter applies only when the convert_not_nullable_column

parameter has been set to true.

Set this parameter to one of the following:

v trueGenerates a warning message in the Event Log the first time a null value
is converted to a default value on a per column per table basis.
v falseNo warning message is generated in the Event Log.

Applies ToTarget

Default SettingTrue

mirror_end_on_error
VersionInfoSphere CDC for Teradata version 6.2 and later

Use this system parameter to indicate if you want to end mirroring after an apply
error occurs on the target database.

Set this parameter to one of the following:

v trueEnd mirroring after an apply error on the target database.
v falseDo not end mirroring after an apply error on the target database.

Applies ToTarget

Default SettingTrue

Note: This parameter can only be used if mirror_td_apply_method has been set to
JDBC.

600 InfoSphere Change Data Capture Management Console: Administration Guide

 Related reference
mirror_td_apply_method

mirror_expected_errors_list
VersionInfoSphere CDC for Teradata version 6.2 and later

Use this system parameter when you want InfoSphere CDC to ignore one or more
database errors when applying data changes to the target during mirroring. The
error specified must correspond to the integer error code (database-vendor specific)
returned by the SQLException class in JDBC (Java Database Connectivity). Specify
multiple errors with a comma separated list of integer error codes.

For example, if you want InfoSphere CDC to continue mirroring when it

encounters error codes 5407 and 3706 in your Teradata target database, set this
parameter to mirror_expected_errors_list=5407,3706.

Note: Latency may increase when using this system parameter since InfoSphere
CDC will not use JDBC array apply in order to track the errors specified.

Applies ToTarget

Note: You can only use this parameter if mirror_td_apply_method has been set to
JDBC.
Related reference
mirror_td_apply_method
refresh_expected_errors_list on page 602

mirror_td_apply_method
VersionInfoSphere CDC for Teradata version 6.2 and later

The default configuration InfoSphere CDC for Teradata uses batches of TPump
scripts to replicate the mirroring changes to the target Teradata database. In order
to realize the full potential of TPump, relatively large time windows must be set
for batches, which could result in higher latency. InfoSphere CDC for Teradata can
be configured to use JDBC instead of TPump. Use this system parameter to choose
the JDBC method for mirroring.

The value for this parameter will be applied to all existing and subsequent
subscriptions in the instance. Existing subscriptions will need to be restarted for
this change to take effect.

Notes:
v To avoid confusion, use only one type of mirroring method for all subscriptions
in a given InfoSphere CDC instance.
v Teradata JDBC driver version 13.00.00.04 or later is required for JDBC support.

Set this parameter to one of the following:

v JDBCEnables mirroring using the JDBC apply method. Use
global_max_batch_size to tune or adjust the performance of the JDBC apply
method.
v TPUMPEnables mirroring using the TPUMP apply method.

System parameters for InfoSphere CDC for Teradata (version 6.2 and later) 601
 Default SettingTPUMP
Related reference
global_max_batch_size on page 597
mirror_expected_errors_list on page 601
refresh_expected_errors_list
mirror_end_on_error on page 600

refresh_end_on_error
VersionInfoSphere CDC for Teradata version 6.2 and later

Use this system parameter to indicate if you want to end a refresh after an apply
error occurs.

Set this parameter to one of the following:

v trueEnd a refresh after an apply error occurs.
v falseDo not end a refresh after an apply error occurs.

Applies ToTarget

Default SettingTrue

refresh_expected_errors_list
VersionInfoSphere CDC for Teradata version 6.2 and later

Use this system parameter when you want InfoSphere CDC to ignore one or more
database errors when refreshing data to the target. The error specified must
correspond to the integer error code (database-vendor specific) returned by the
SQLException class in JDBC (Java Database Connectivity). Specify multiple errors
with a comma separated list of integer error codes.

For example, if you want InfoSphere CDC to continue refresh when it encounters
error codes 5407 and 3706 in your Teradata target database, set this parameter to
mirror_expected_errors_list=5407,3706.

Note: Latency may increase when using this system parameter since InfoSphere
CDC will not use JDBC array apply in order to track the errors specified.

Applies ToTarget

Note: You can only use this parameter if mirror_td_apply_method has been set to
JDBC.
Related reference
mirror_td_apply_method on page 601
mirror_expected_errors_list on page 601

trim_char_to_varchar
VersionInfoSphere CDC for Teradata version 6.2 and later

602 InfoSphere Change Data Capture Management Console: Administration Guide

 Use this system parameter to specify whether or not InfoSphere CDC should strip
or leave trailing blanks on string data of the column in the target table.

Set this parameter to one of the following:

v trueInfoSphere CDC strips the data of trailing blanks.
v falseInfoSphere CDC does not strip the string data of trailing blanks.

Applies ToTarget

Default Settingfalse

trim_varchar_to_varchar
VersionInfoSphere CDC for Teradata version 6.2 and later

Use this system parameter to specify whether or not InfoSphere CDC should strip
or leave trailing blanks on string data of the column in the target table.

Set this parameter to one of the following:

v trueInfoSphere CDC strips the data of trailing blanks.
v falseInfoSphere CDC does not strip the string data of trailing blanks.

Applies ToTarget

Default Settingfalse

userexit_max_lob_size_kb
VersionInfoSphere CDC for Teradata version 6.2 and later

Use this system parameter to set the maximum size of LOB data (in kb) that
InfoSphere CDC can pass to a user exit.

Applies ToTarget

Default Setting128 kb

Maximum9223372036854775807 kb

Minimum1 kb

Teradata TPump system parameters

Teradata TPump system parameters allow you to configure the Teradata TPump
utility. InfoSphere CDC for Teradata uses the TPump utility to load replicated data
into Teradata databases.

See also:
mirror_tpump_files_root_folder_path on page 604
mirror_tpump_max_file_size_mb on page 604
mirror_tpump_script_val_file_name on page 605
mirror_tpump_timeout_seconds on page 606
mirror_tpump_update_on_key_column on page 606

System parameters for InfoSphere CDC for Teradata (version 6.2 and later) 603
 mirror_tpump_files_root_folder_path
VersionInfoSphere CDC for Teradata version 6.2 and later

Identifies the main directory that is created to accommodate all Teradata TPump
files.

This setting specifies where all Teradata TPump files are located. Subdirectories
under the main directory are labeled with the name of the publisher identifier that
is used to receive replicated data. This means that for each publisher identifier,
Teradata TPump files are maintained in a separate directory.

The three subdirectories that are defined are as follows:

v <tpump_files_root_folder>\<pubid>\TPump
Contains all data (.dat) and script (.script) files that are generated by
InfoSphere CDC and used by the Teradata TPump utility to load data into
Teradata databases.
Data files contain the replicated data that is loaded into Teradata, and script files
specify what is contained in the data files and how data is loaded. These files
are named DM_<timestamp>.dat and DM_<timestamp>.script, where <timestamp>
is the number of milliseconds from midnight on January 1, 1970 to the time
when the file was created.
v <tpump_files_root_folder>\<pubid>\TPump\archive
Contains all archived data (.dat) and script (.script) files.
v <tpump_files_root_folder>\<pubid>\TPump\log
Contains all Teradata TPump log files. For more information about log files, see
tpump_logging below.
Log files are named DM_<timestamp>.log, where <timestamp> is the number of
milliseconds from midnight on January 1, 1970 to the time when the file was
created.
where:
<tpump_files_root_folder> is the value assigned to this system parameter.
<pubid> is the publisher identifier defined in Management Console that is
used to receive replicated data.
For example, if:
<tpump_files_root_folder> is d:\test, and
<pubid> is NEWYORK
then the following three Teradata TPump subdirectories are created for the
NEWYORK publisher identifier:
d:\test\NEWYORK\TPump
d:\test\NEWYORK\TPump\archive
d:\test\NEWYORK\TPump\log

Default SettingThe InfoSphere CDC installation directory.

Applies ToTarget

mirror_tpump_max_file_size_mb
VersionInfoSphere CDC for Teradata version 6.2 and later

604 InfoSphere Change Data Capture Management Console: Administration Guide

 Identifies the size, in megabytes, that the data file (.dat) must reach before the
Teradata TPump utility loads data into a Teradata database.

Data files contain the replicated data that is loaded into Teradata. To optimize
performance, you should set this system parameter so that the amount of time it
takes for the Teradata TPump utility to load data into a Teradata database is
approximately equivalent to the time it takes for the data file to reach the specified
size. As a result, the next load operation can start shortly after the current load
operation has been completed. Therefore, if the amount of time to load data is
longer than the amount of time to fill the data file in preparation for the next load,
decrease the number of bytes assigned to this system parameter.

In addition to working with this system parameter, you must also work with the
tpump_ timeout on page 582 system parameter to specify when the Teradata
TPump utility loads data into a Teradata database. If the timeout period frequently
expires before the data file reaches its specified size, you can increase the timeout
period or decrease the data file size to allow loads to also be determined by data
file size. However, when a data file contains an insufficient amount of data for a
load to be performed, the timeout period must be set to ensure data is loaded
within a reasonable period of time.

Default Setting50 Mb

mirror_tpump_script_val_file_name
VersionInfoSphere CDC for Teradata version 6.2 and later

Identifies the name of the XML file that InfoSphere CDC uses to generate script
(.script) files during replication.

Teradata TPump script files specify what is contained in the data files and how
data in these files is loaded into Teradata databases. The file identified by this
system parameter contains a set of Teradata TPump command parameter settings.
You can modify the settings in this file so that the script files generated by
InfoSphere CDC during replication are customized for your working environment.
For more information about customizing the generated script files using the XML
file identified by this system parameter, see your InfoSphere CDC for Teradata
documentation.

IBM recommends that you do not change the default setting for this system
parameter. Instead, modify the tpumpscripttsdefaults.xml file so that it contains
the desired command parameter settings. If you want to specify a different XML,
this file must exist in the InfoSphere CDC installation directory and contain the
correct XML markup to generate valid script files.

Generally, the default values in the tpumpscripttsdefaults.xml file are suitable for
most working environments. If you want to modify the settings in
tpumpscripttsdefaults.xml, you must be familiar with XML and Teradata TPump.
For more information about Teradata TPump commands and command
parameters, see your Teradata documentation.

Default Settingconf/tpumpscripttsdefaults.xml. This file is located in the conf

directory in your InfoSphere CDC installation directory.

System parameters for InfoSphere CDC for Teradata (version 6.2 and later) 605
 mirror_tpump_timeout_seconds
VersionInfoSphere CDC for Teradata version 6.2 and later

Indicates the amount of time, in seconds, between consecutive Teradata TPump

data loads into a Teradata database.

You can use this system parameter to force data to be loaded when the data file
(see tpump_max_file_size on page 580) contains insufficient data for a load to be
performed. It can be used to prevent data in a data file from not being loaded for a
long period of time. In particular, you can use this system parameter to force loads
during periods of slow transaction activity. However, if you set the timeout period
so that it frequently expires before a data file can reach the specified size, a smaller
amount of data is loaded. In this case, you can increase the timeout period or
decrease the data file size to allow loads to also be determined by data file size.

Minimum Setting0 seconds (disables the timeout so that a load is only

performed when the data file reaches the size specified by the
tpump_max_file_size system parameter)

Default Setting5 seconds

mirror_tpump_update_on_key_column
VersionInfoSphere CDC for Teradata version 6.2 and later

Use this system parameter to improve performance in the TPump apply process by
not including key columns in the update statements in the TPump scripts.

This parameter should only be used when you are sure that no key changes will
occur in the source data stream.

Set this parameter to one of the following:

v trueIncludes key columns in the update statements in TPump scripts.
v falseExcludes key columns from the update statements in TPump scripts.

Default Settingtrue

Fastload system parameters

Fastload system parameters allow you to configure the Teradata Fastload utility.
InfoSphere CDC for Teradata uses the Fastload utility to load replicated data into
Teradata databases.

See also:
refresh_max_fastload_file_size_mb

refresh_max_fastload_file_size_mb
VersionInfoSphere CDC for Teradata version 6.2 and later

Identifies the size, in megabytes, that the data file must reach before the Teradata
FastLoad utility refreshes data in a Teradata database.

606 InfoSphere Change Data Capture Management Console: Administration Guide

If the amount of refreshed data is larger than the specified size, InfoSphere CDC
closes the data file after it has been filled and passes it to the Teradata FastLoad
utility so that data is refreshed in the Teradata database. Additional data files are
used to ensure the remaining data is refreshed.

Default Setting100 mb

Maximum9223372036854775807 (or 263 - 1) mb

Minimum1 mb

System parameters for InfoSphere CDC for Teradata (version 6.2 and later) 607
608 InfoSphere Change Data Capture Management Console: Administration Guide
System parameters for InfoSphere CDC Event Server
System parameters let you control the behavior of InfoSphere CDC Event Server. If
your replication environment requires a particular configuration, then you can use
system parameters to modify the behavior of default operations in InfoSphere CDC
Event Server. The default system parameter settings are appropriate for most
installations. Maintain these default settings until you become familiar with the
configuration of InfoSphere CDC Event Server.

InfoSphere CDC Event Server provides system parameters that control the
behavior of your target datastores.

If you make changes to a system parameter during active replication, you must
stop and restart InfoSphere CDC Event Server for the changes to take effect.

When upgrading to a higher version of InfoSphere CDC Event Server, any

pre-existing settings for system parameters are maintained.

In this section, you will learn:

Notification system parameters
Apply process system parameters on page 610
Disk resource system parameters on page 614

Notification system parameters

Notification system parameters let you control if you should generate InfoSphere
CDC messages in the Event Log for specific events.

See also:
events_max_retain
global_conversion_not_possible_warning

events_max_retain
VersionInfoSphere CDC Event Server version 6.3 and later

Use this system parameter to control the maximum number of events that
InfoSphere CDC will store in the event log. If InfoSphere CDC generates more
events than the specified maximum, then the earliest events will be deleted.

Default Setting10000

Minimum -1

Maximum2147483647

global_conversion_not_possible_warning
VersionInfoSphere CDC Event Server version 6.3 and later

Copyright IBM Corp. 2008, 2011 609

 Use this system parameter to control whether or not InfoSphere CDC generates a
warning in the Management Console Event Log in the following situations:
v Data conversion is not possible for a specific data value.
v Converted data types are encountered that are out of range.

Set this parameter to one of the following:

v trueGenerates a warning in the Event Log if data conversion is not possible
for a specific data value or converted data types are encountered that are out of
range.
v falseDoes not generate a warning in the Event Log if data conversion is not
possible for a specific data value or converted data types are encountered that
are out of range.

Applies ToTarget

Default Settingfalse
Related concepts
System parameters for InfoSphere CDC Event Server on page 609

Apply process system parameters

Some system parameters adjust the way InfoSphere CDC applies rows, column
data, and error handling.

See also:
convert_not_nullable_column
convert_not_nullable_message on page 611
mirror_commit_on_transaction_boundary on page 611
mirror_end_on_error on page 612
mirror_expected_errors_list on page 612
mirror_interim_commit_threshold on page 612
refresh_end_on_error on page 613
refresh_expected_errors_list on page 613
userexit_max_lob_size_kb on page 613

convert_not_nullable_column
VersionInfoSphere CDC Event Server version 6.3 and later

Use this system parameter to control how InfoSphere CDC behaves when it applies
a null value to a non-nullable column. When set to true (default value), the null
value will be replaced with a default value (based on the data type of the column)
and InfoSphere CDC will generate a warning in the event log. When set to false,
InfoSphere CDC applies the null value directly to the non-nullable column which
will result in an error and cause a shutdown of InfoSphere CDC on the target
database.

Note: If you decided to set this system parameter to false and have specified this
as an error for InfoSphere CDC to ignore using the mirror_expected_errors_list
system parameter, then InfoSphere CDC will ignore the error and not shutdown.

Set this parameter to one of the following:

610 InfoSphere Change Data Capture Management Console: Administration Guide

 v trueNull value will be replaced with default value for non-nullable column,
and a warning event will be logged.
v falseNull data will be applied as-is to non-nullable column and database will
usually return an error code.

Applies ToSource and Target

Default SettingTrue

convert_not_nullable_message
VersionInfoSphere CDC Event Server version 6.3 and later

Use this system parameter to determine if a message will be generated in the

Event Log when InfoSphere CDC converts a null value to a default value when
applied to a non-nullable column. When set to true (default value), InfoSphere
CDC will log the event the first time it encounters a null to non-nullable mapping
(on a per column per table basis). When set to false, InfoSphere CDC will not
generate a message when a null value is converted to a default value.

Note: This system parameter applies only when the convert_not_nullable_column

parameter has been set to true.

Set this parameter to one of the following:

v trueGenerates a warning message in the Event Log the first time a null value
is converted to a default value on a per column per table basis.
v falseNo warning message is generated in the Event Log.

Applies ToTarget

Default SettingTrue

mirror_commit_on_transaction_boundary
VersionInfoSphere CDC Event Server version 6.3 and later

This system parameter indicates whether or not the commits that InfoSphere CDC
does on the target will always correspond with a commit that occurred on the
source database. If you choose to ignore the commitment control of the source
database, InfoSphere CDC allows you to see the partial results of large
transactions.

Set this parameter to one of the following:

v trueDoes not ignore the commitment control of the source database. Only
records in a committed transaction are mirrored to the target. This setting
provides true transaction consistency by ensuring that only committed
transactions are sent to the target.
v falseIgnores the commitment control of the source database. This value
disables commitment control for transaction processing. No attempt to maintain
transaction consistency is performed during mirroring.

Applies ToTarget

Default SettingFalse

System parameters for InfoSphere CDC Event Server 611

 mirror_end_on_error
VersionInfoSphere CDC Event Server version 6.3 and later

Use this system parameter to indicate if you want to end mirroring after an apply
error occurs on the target database.

Set this parameter to one of the following:

v trueEnd mirroring after an apply error on the target database.
v falseDo not end mirroring after an apply error on the target database.

Applies ToTarget

Default SettingTrue

mirror_expected_errors_list
VersionInfoSphere CDC Event Server version 6.3 and later

Use this system parameter when you want InfoSphere CDC to ignore one or more
database errors when applying data changes to the target during mirroring. The
error specified must correspond to the integer error code (database-vendor specific)
returned by the SQLException class in JDBC (Java Database Connectivity). Specify
multiple errors with a comma separated list of integer error codes.

Note: Latency may increase when using this system parameter since InfoSphere
CDC will not use JDBC array apply in order to track the errors specified.

Applies ToTarget

mirror_interim_commit_threshold
VersionInfoSphere CDC for Event Server version 6.3 Fix Pack 3 and later.

By default, InfoSphere CDC guarantees transactional delivery of change data to the

target. This ensures that if any data from a source transaction is committed to the
target, then all other in scope operations from that source transaction are
committed as well.

In cases where large transactions are done on the source system, it can be more
efficient to break a large transaction into smaller transactions when applying data
to the target. You can configure this behavior using this system parameter.

The default value of 0 for this system parameter indicates that the product
guarantees transactional delivery of change data to the target. A value greater than
0 indicates that you want InfoSphere CDC to break up large transactions into
smaller transactions. For example, a value of 2000 indicates that InfoSphere CDC
will split up large source transactions so that each transaction committed to the
target database contains no more than 2000 operations.

Applies ToTarget

Default Setting0

612 InfoSphere Change Data Capture Management Console: Administration Guide

 Minimum Setting0

refresh_end_on_error
VersionInfoSphere CDC Event Server version 6.3 and later

Use this system parameter to indicate if you want to end a refresh after an apply
error occurs.

Set this parameter to one of the following:

v trueEnd a refresh after an apply error occurs.
v falseDo not end a refresh after an apply error occurs.

Applies ToTarget

Default SettingTrue
Related concepts
System parameters for InfoSphere CDC Event Server on page 609
Setting system parameters on source and target datastores on page 71

refresh_expected_errors_list
VersionInfoSphere CDC Event Server version 6.3 and later

Use this system parameter when you want InfoSphere CDC to ignore one or more
database errors when refreshing data to the target. The error specified must
correspond to the integer error code (database-vendor specific) returned by the
SQLException class in JDBC (Java Database Connectivity). Specify multiple errors
with a comma separated list of integer error codes.

Note: Latency may increase when using this system parameter since InfoSphere
CDC will not use JDBC array apply in order to track the errors specified.

Applies ToTarget

userexit_max_lob_size_kb
VersionInfoSphere CDC Event Server version 6.3 and later

Use this system parameter to set the maximum size of LOB data (in kb) that
InfoSphere CDC can pass to a user exit.

Applies ToTarget

Default Setting128 kb

Maximum9223372036854775807 kb

Minimum1 kb

System parameters for InfoSphere CDC Event Server 613

Disk resource system parameters
Some system parameters control memory usage in InfoSphere CDC. For improved
performance, if you are able to allocate more than the default value of 512 MB for
the InfoSphere CDC Java Virtual Machine, then you can adjust the disk resource
system parameters to use the increased memory.

See also:
mirror_global_disk_quota_mb
mirror_global_disk_quota_gb

mirror_global_disk_quota_mb
VersionInfoSphere CDC Event Server version 6.3

Use this system parameter to globally set a disk quota (in MB) for all capture
components including temporary files, transaction queues, and LOBs which are
staged on the target before being applied. InfoSphere CDC will manage disk space
utilization across all components as required.

Most databases have a mechanism that allows you to roll back or undo changes to
your database by storing uncommitted changes. Similarly, InfoSphere CDC uses
the disk quota controlled by this system parameter to store in scope change data
that has not been committed in your database. Once the database transaction is
committed, the disk space used by the transaction is released. Note that InfoSphere
CDC stores the data in memory to improve performance and will only persist the
data to disk if memory is unavailable.

The default setting of this system parameter is such that the product will only stop
replicating after this disk quota exhausts all available disk space on your system. If
you would prefer the product to stop replicating after it uses a specific amount of
disk space, you can set the value with this system parameter.

Applies ToSource and Target

Default Setting9223372036854775807

Maximum9223372036854775807

Minimum100

mirror_global_disk_quota_gb
VersionInfoSphere CDC Event Server version 6.5

Use this system parameter to globally set a disk quota (in GB) for all capture
components including temporary files, transaction queues, and LOBs which are
staged on the target before being applied. InfoSphere CDC will manage disk space
utilization across all components as required.

Most databases have a mechanism that allows you to roll back or undo changes to
your database by storing uncommitted changes. Similarly, InfoSphere CDC uses
the disk quota controlled by this system parameter to store in scope change data
that has not been committed in your database. Once the database transaction is

614 InfoSphere Change Data Capture Management Console: Administration Guide

committed, the disk space used by the transaction is released. Note that InfoSphere
CDC stores the data in memory to improve performance and will only persist the
data to disk if memory is unavailable.

The default setting of this system parameter is such that the product will only stop
replicating after this disk quota exhausts all available disk space on your system. If
you would prefer the product to stop replicating after it uses a specific amount of
disk space, you can set the value with this system parameter.

Applies ToSource and Target

Default Setting9223372036854775807

Maximum9223372036854775807

Minimum1

System parameters for InfoSphere CDC Event Server 615

616 InfoSphere Change Data Capture Management Console: Administration Guide
System parameters for InfoSphere CDC for IBM InfoSphere
DataStage
System parameters let you control the behavior of InfoSphere CDC. If your
replication environment requires a particular configuration, then you can use
system parameters to modify the behavior of default operations in InfoSphere
CDC. The default system parameter settings are appropriate for most installations.
Maintain these default settings until you become familiar with the configuration of
InfoSphere CDC.

InfoSphere CDC provides system parameters that control the behavior of your
source and target datastores.

Notes:
1. If you make changes to a system parameter during active replication, you must
stop and restart InfoSphere CDC for the changes to take effect.
2. When upgrading to a later version of InfoSphere CDC, any preexisting settings
for system parameters are maintained.

In this section, you will learn:

Notification system parameters
Disk resource system parameters on page 618
Apply process system parameters on page 620
InfoSphere DataStage system parameters on page 624

Notification system parameters

Notification system parameters let you control if you should generate InfoSphere
CDC messages in the Event Log for specific events.

See also:
events_max_retain
global_conversion_not_possible_warning on page 618
global_shutdown_after_no_heartbeat_response_minutes on page 618

events_max_retain
VersionInfoSphere CDC for IBM InfoSphere DataStage version 6.3 and later.

Use this system parameter to control the maximum number of events that
InfoSphere CDC will store in the event log. If InfoSphere CDC generates more
events than the specified maximum, then the earliest events will be deleted.

Default Setting10000

Minimum -1

Maximum2147483647

Copyright IBM Corp. 2008, 2011 617

 global_conversion_not_possible_warning
VersionInfoSphere CDC for IBM InfoSphere DataStage version 6.3 and later.

Use this system parameter to control whether or not InfoSphere CDC generates a
warning in the Management Console Event Log in the following situations:
v Data conversion is not possible for a specific data value.
v Converted data types are encountered that are out of range.

Set this parameter to one of the following:

v trueGenerates a warning in the Event Log if data conversion is not possible
for a specific data value or converted data types are encountered that are out of
range.
v falseDoes not generate a warning in the Event Log if data conversion is not
possible for a specific data value or converted data types are encountered that
are out of range.

Applies ToTarget

Default Settingfalse
Related concepts
System parameters for InfoSphere CDC for IBM InfoSphere DataStage on page
617

global_shutdown_after_no_heartbeat_response_minutes
VersionInfoSphere CDC for IBM InfoSphere DataStage version 6.3 and later.

Use this system parameter to specify the duration, in minutes, of communication

inactivity before active InfoSphere CDC processes for a subscription are stopped. If
a value outside the acceptable range is specified, the default setting is used.

Applies ToSource

Default Setting15 minutes

Minimum Setting3 minutes

Maximum Setting999 minutes

Related concepts
System parameters for InfoSphere CDC for IBM InfoSphere DataStage on page
617

Disk resource system parameters

Some system parameters control memory usage in InfoSphere CDC. For improved
performance, if you are able to allocate more than the default value of 512 MB for
the InfoSphere CDC Java Virtual Machine, then you can adjust the disk resource
system parameters to use the increased memory.

See also:
mirror_global_disk_quota_mb on page 619
mirror_global_disk_quota_gb on page 619

618 InfoSphere Change Data Capture Management Console: Administration Guide

mirror_global_disk_quota_mb
VersionInfoSphere CDC for IBM InfoSphere DataStage version 6.3

Use this system parameter to globally set a disk quota (in MB) for all capture
components including temporary files, transaction queues, and LOBs which are
staged on the target before being applied. InfoSphere CDC will manage disk space
utilization across all components as required.

Most databases have a mechanism that allows you to roll back or undo changes to
your database by storing uncommitted changes. Similarly, InfoSphere CDC uses
the disk quota controlled by this system parameter to store in scope change data
that has not been committed in your database. Once the database transaction is
committed, the disk space used by the transaction is released. Note that InfoSphere
CDC stores the data in memory to improve performance and will only persist the
data to disk if memory is unavailable.

The default setting of this system parameter is such that the product will only stop
replicating after this disk quota exhausts all available disk space on your system. If
you would prefer the product to stop replicating after it uses a specific amount of
disk space, you can set the value with this system parameter.

Applies ToSource and Target

Default Setting9223372036854775807

Maximum9223372036854775807

Minimum100

mirror_global_disk_quota_gb
VersionInfoSphere CDC for IBM InfoSphere DataStage version 6.5

Use this system parameter to globally set a disk quota (in GB) for all capture
components including temporary files, transaction queues, and LOBs which are
staged on the target before being applied. InfoSphere CDC will manage disk space
utilization across all components as required.

Most databases have a mechanism that allows you to roll back or undo changes to
your database by storing uncommitted changes. Similarly, InfoSphere CDC uses
the disk quota controlled by this system parameter to store in scope change data
that has not been committed in your database. Once the database transaction is
committed, the disk space used by the transaction is released. Note that InfoSphere
CDC stores the data in memory to improve performance and will only persist the
data to disk if memory is unavailable.

The default setting of this system parameter is such that the product will only stop
replicating after this disk quota exhausts all available disk space on your system. If
you would prefer the product to stop replicating after it uses a specific amount of
disk space, you can set the value with this system parameter.

Applies ToSource and Target

Default Setting9223372036854775807

System parameters for InfoSphere CDC for IBM InfoSphere DataStage 619
 Maximum9223372036854775807

Minimum1

Apply process system parameters

Some system parameters adjust the way InfoSphere CDC applies rows, column
data, and error handling.

See also:
convert_not_nullable_column
convert_not_nullable_message
mirror_end_on_error on page 621
mirror_expected_errors_list on page 621
mirror_interim_commit_threshold on page 622
refresh_end_on_error on page 622
refresh_expected_errors_list on page 622
refresh_with_referential_integrity on page 623
trim_char_to_varchar on page 623
trim_varchar_to_varchar on page 623

convert_not_nullable_column
VersionInfoSphere CDC for IBM InfoSphere DataStage version 6.3 and later.

Use this system parameter to control how InfoSphere CDC behaves when it applies
a null value to a non-nullable column. When set to true (default value), the null
value will be replaced with a default value (based on the data type of the column)
and InfoSphere CDC will generate a warning in the event log. When set to false,
InfoSphere CDC applies the null value directly to the non-nullable column which
will result in an error and cause a shutdown of InfoSphere CDC on the target
database.

Note: If you decided to set this system parameter to false and have specified this
as an error for InfoSphere CDC to ignore using the mirror_expected_errors_list
system parameter, then InfoSphere CDC will ignore the error and not shutdown.

Set this parameter to one of the following:

v trueNull value will be replaced with default value for non-nullable column,
and a warning event will be logged.
v falseNull data will be applied as-is to non-nullable column and database will
usually return an error code.

Applies ToSource and Target

Default SettingTrue

convert_not_nullable_message
VersionInfoSphere CDC for IBM InfoSphere DataStage version 6.3 and later.

620 InfoSphere Change Data Capture Management Console: Administration Guide

 Use this system parameter to determine if a message will be generated in the
Event Log when InfoSphere CDC converts a null value to a default value when
applied to a non-nullable column. When set to true (default value), InfoSphere
CDC will log the event the first time it encounters a null to non-nullable mapping
(on a per column per table basis). When set to false, InfoSphere CDC will not
generate a message when a null value is converted to a default value.

Note: This system parameter applies only when the convert_not_nullable_column

parameter has been set to true.

Set this parameter to one of the following:

v trueGenerates a warning message in the Event Log the first time a null value
is converted to a default value on a per column per table basis.
v falseNo warning message is generated in the Event Log.

Applies ToTarget

Default SettingTrue

mirror_end_on_error
VersionInfoSphere CDC for IBM InfoSphere DataStage version 6.3 and later.

Use this system parameter to indicate if you want to end mirroring after an apply
error occurs on the target database.

Set this parameter to one of the following:

v trueEnd mirroring after an apply error on the target database.
v falseDo not end mirroring after an apply error on the target database.

Applies ToTarget

Default SettingTrue
Related concepts
System parameters for InfoSphere CDC for IBM InfoSphere DataStage on page
617

mirror_expected_errors_list
VersionInfoSphere CDC for IBM InfoSphere DataStage version 6.3 and later.

Use this system parameter when you want InfoSphere CDC to ignore one or more
database errors when applying data changes to the target during mirroring. The
error specified must correspond to the integer error code (database-vendor specific)
returned by the SQLException class in JDBC (Java Database Connectivity). Specify
multiple errors with a comma separated list of integer error codes.

Note: Latency may increase when using this system parameter since InfoSphere
CDC will not use JDBC array apply in order to track the errors specified.

Applies ToTarget

System parameters for InfoSphere CDC for IBM InfoSphere DataStage 621
 mirror_interim_commit_threshold
VersionInfoSphere CDC for IBM InfoSphere DataStage version 6.3 Fix Pack 3
and later.

By default, InfoSphere CDC guarantees transactional delivery of change data to the

target. This ensures that if any data from a source transaction is committed to the
target, then all other in scope operations from that source transaction are
committed as well.

In cases where large transactions are done on the source system, it can be more
efficient to break a large transaction into smaller transactions when applying data
to the target. You can configure this behavior using this system parameter.

The default value of 0 for this system parameter indicates that the product
guarantees transactional delivery of change data to the target. A value greater than
0 indicates that you want InfoSphere CDC to break up large transactions into
smaller transactions. For example, a value of 2000 indicates that InfoSphere CDC
will split up large source transactions so that each transaction committed to the
target database contains no more than 2000 operations.

Applies ToTarget

Default Setting0

Minimum Setting0

refresh_end_on_error
VersionInfoSphere CDC for IBM InfoSphere DataStage version 6.3 and later.

Use this system parameter to indicate if you want to end a refresh after an apply
error occurs.

Set this parameter to one of the following:

v trueEnd a refresh after an apply error occurs.
v falseDo not end a refresh after an apply error occurs.

Applies ToTarget

Default SettingTrue
Related concepts
System parameters for InfoSphere CDC for IBM InfoSphere DataStage on page
617

refresh_expected_errors_list
VersionInfoSphere CDC for IBM InfoSphere DataStage version 6.3 and later.

Use this system parameter when you want InfoSphere CDC to ignore one or more
database errors when refreshing data to the target. The error specified must
correspond to the integer error code (database-vendor specific) returned by the
SQLException class in JDBC (Java Database Connectivity). Specify multiple errors
with a comma separated list of integer error codes.

622 InfoSphere Change Data Capture Management Console: Administration Guide

 Note: Latency may increase when using this system parameter since InfoSphere
CDC will not use JDBC array apply in order to track the errors specified.

Applies ToTarget

refresh_with_referential_integrity
VersionInfoSphere CDC for IBM InfoSphere DataStage version 6.3 and later.

Use this system parameter to indicate whether or not you want the data removed
from all the target tables being refreshed before repopulating any of them. This is
most useful when there are referential integrity constraints on the tables being
refreshed.

Set this parameter to one of the following:

v trueIndicates that InfoSphere CDC will first remove all data in reverse of the
specified refresh order. When specifying the refresh order, in general parent
tables should appear before the referenced child tables. The product will then
remove data from the child tables before the parent tables.
v falseIndicates that InfoSphere CDC will not first remove all data from your
tables and will refresh the tables in the specified order.

Applies ToSource

Default Settingfalse

trim_char_to_varchar
VersionInfoSphere CDC for IBM InfoSphere DataStage version 6.3 and later.

Use this system parameter to specify whether or not InfoSphere CDC should strip
or leave trailing blanks on string data of the column in the target table.

Set this parameter to one of the following:

v trueInfoSphere CDC strips the data of trailing blanks.
v falseInfoSphere CDC does not strip the string data of trailing blanks.

Applies ToTarget

Default Settingfalse

trim_varchar_to_varchar
VersionInfoSphere CDC for IBM InfoSphere DataStage version 6.3 and later.

Use this system parameter to specify whether or not InfoSphere CDC should strip
or leave trailing blanks on string data of the column in the target table.

Set this parameter to one of the following:

v trueInfoSphere CDC strips the data of trailing blanks.
v falseInfoSphere CDC does not strip the string data of trailing blanks.

Applies ToTarget

System parameters for InfoSphere CDC for IBM InfoSphere DataStage 623
 Default Settingfalse

InfoSphere DataStage system parameters

InfoSphere DataStage system parameters when your LOB data is truncated.

See also:
userexit_max_lob_size_kb

userexit_max_lob_size_kb
VersionInfoSphere CDC for IBM InfoSphere DataStage version 6.3 and later.

This system parameter determines when InfoSphere CDC truncates LOB data and
is related to the InfoSphere DataStage subscription-level properties that you can set
for each subscription in Management Console. InfoSphere CDC first truncates your
LOB data based on this system parameter and then truncates your data again
using the subscription-level properties. For more information on how to set the
subscription-level properties, see Setting properties for a subscription that targets
InfoSphere DataStage on page 131.

This system parameter should be set at least as large as the largest

subscription-level property while taking into account the units and the type of
character data (single-byte or multibyte). For example, if the largest
subscription-level property is set to 8,000 characters and you are using a Japanese
system with the possibility of 2 bytes per character (up to 16,000 bytes), you
should set this system parameter to at least 16 kB.

Default Setting128 kB

Applies ToTarget

624 InfoSphere Change Data Capture Management Console: Administration Guide

System parameters for InfoSphere CDC for IBM Informix
Dynamic Server
System parameters let you control the behavior of InfoSphere CDC. If your
replication environment requires a particular configuration, then you can use
system parameters to modify the behavior of default operations in InfoSphere
CDC. The default system parameter settings are appropriate for most installations.
Maintain these default settings until you become familiar with the configuration of
InfoSphere CDC.

InfoSphere CDC provides system parameters that control the behavior of your
source and target datastores.

Notes:
1. If you make changes to a system parameter during active replication, you must
stop and restart InfoSphere CDC for the changes to take effect.
2. When upgrading to a later version of InfoSphere CDC, any preexisting settings
for system parameters are maintained.

In this section, you will learn:

General product system parameters
Notification system parameters on page 626
Maximize throughput system parameters on page 627
Encoding system parameters on page 628
Disk resource system parameters on page 629
Apply process system parameters on page 630

General product system parameters

General product system parameters let you control basic features of InfoSphere
CDC and information you may have specified during installation.

See also:
mirror_auto_restart_interval_minutes

mirror_auto_restart_interval_minutes
VersionInfoSphere CDC for IBM Informix Dynamic Server version 6.3 Fix Pack 3
TFE 9 and later.

Use this parameter to indicate how long (in minutes) InfoSphere CDC will attempt
to automatically restart continuous mirroring for persistent subscriptions.

Applies ToSource

Default0

Minimum0

Maximum60

Copyright IBM Corp. 2008, 2011 625

Notification system parameters
Notification system parameters let you control if you should generate InfoSphere
CDC messages in the Event Log for specific events.

See also:
events_max_retain
global_conversion_not_possible_warning
global_shutdown_after_no_heartbeat_response_minutes

events_max_retain
VersionInfoSphere CDC for IBM Informix Dynamic Server version 6.3 and later

Use this system parameter to control the maximum number of events that
InfoSphere CDC will store in the event log. If InfoSphere CDC generates more
events than the specified maximum, then the earliest events will be deleted.

Default Setting10000

Minimum -1

Maximum2147483647

global_conversion_not_possible_warning
VersionInfoSphere CDC for IBM Informix Dynamic Server version 6.3 and later

Use this system parameter to control whether or not InfoSphere CDC generates a
warning in the Management Console Event Log in the following situations:
v Data conversion is not possible for a specific data value.
v Converted data types are encountered that are out of range.

Set this parameter to one of the following:

v trueGenerates a warning in the Event Log if data conversion is not possible
for a specific data value or converted data types are encountered that are out of
range.
v falseDoes not generate a warning in the Event Log if data conversion is not
possible for a specific data value or converted data types are encountered that
are out of range.

Applies ToTarget

Default Settingfalse

global_shutdown_after_no_heartbeat_response_minutes
VersionInfoSphere CDC for IBM Informix Dynamic Server version 6.3 and later

Use this system parameter to specify the duration, in minutes, of communication

inactivity before active InfoSphere CDC processes for a subscription are stopped. If
a value outside the acceptable range is specified, the default setting is used.

626 InfoSphere Change Data Capture Management Console: Administration Guide

 Applies ToSource

Default Setting15 minutes

Minimum Setting3 minutes

Maximum Setting999 minutes

Maximize throughput system parameters

InfoSphere CDC system parameters allow you to significantly reduce the workload
of the target database during mirroring. The InfoSphere CDC apply process groups
transactions on the target to reduce the workload. Every commit on the target
database will correspond with a commit on the target. However, it may not
perform every commit that was done on the source. For example, if the source
does three small transactions containing one operation each, the target may commit
all three operations as part of a single transaction. You can use this grouping of
system parameters to significantly reduce the resources required by the target
database. The default settings are appropriate for most databases, but if your target
system has limited resources and an increase in latency is acceptable, you can
adjust the settings appropriately.

See also:
mirror_interim_commit_threshold
refresh_commit_after_max_operations on page 628

mirror_interim_commit_threshold
VersionInfoSphere CDC for IBM Informix Dynamic Server version 6.3 Fix Pack 3
and later.

By default, InfoSphere CDC guarantees transactional delivery of change data to the

target. This ensures that if any data from a source transaction is committed to the
target, then all other in scope operations from that source transaction are
committed as well.

In cases where large transactions are done on the source system, it can be more
efficient to break a large transaction into smaller transactions when applying data
to the target. You can configure this behavior using this system parameter.

The default value of 0 for this system parameter indicates that the product
guarantees transactional delivery of change data to the target. A value greater than
0 indicates that you want InfoSphere CDC to break up large transactions into
smaller transactions. For example, a value of 2000 indicates that InfoSphere CDC
will split up large source transactions so that each transaction committed to the
target database contains no more than 2000 operations.

Applies ToTarget

Default Setting0

Minimum Setting0

System parameters for InfoSphere CDC for IBM Informix Dynamic Server 627
 refresh_commit_after_max_operations
VersionInfoSphere CDC for IBM Informix Dynamic Server version 6.3 and later

This system parameter identifies the number of rows comprising each transaction
during refresh. To reduce the workload on the target database during refresh,
InfoSphere CDC periodically commits the changes to the target database rather
than performing the refresh as a single large transaction.

Applies ToTarget

Default Setting1000

Maximum Setting2147483647

Minimum Setting1

Encoding system parameters

For some system parameters, you can set the default method for treating data in
defined Unicode columns, and you can set the default character encoding for your
database.

See also:
global_unicode_as_char

global_unicode_as_char
VersionInfoSphere CDC for IBM Informix Dynamic Server version 6.3 and later

This system parameter indicates the default method of treating data in defined
Unicode columns. For each InfoSphere CDC installation on a server, this system
parameter defines the system default method of treating data in Unicode columns.
If a Unicode column is set to System Default on the Encoding tab of the Mapping
Details view in Management Console, InfoSphere CDC uses the method for
processing Unicode columns that you select in this system parameter.

Set this parameter to one of the following:

v trueInfoSphere CDC treats all data in Unicode columns as single-byte
characters. Use this setting when Unicode columns contain single-byte character
data.
v falseInfoSphere CDC treats all data in Unicode columns as a continuous bit
stream. Use this setting when Unicode columns contain non-single-byte
character data. Setting this system parameter to false ensures that InfoSphere
CDC handles non-single-byte character data in the same way as previous
InfoSphere CDC releases.

Note: Setting this parameter to false does not ensure that replicated
non-single-byte character data in Unicode columns are represented properly on
the target. For replicated non-single-byte character data, you may have to apply
user exit programs or other customizations to properly represent data in
Unicode columns. For more information about user exit programs, see the
InfoSphere CDC End-User Documentation for your platform.

628 InfoSphere Change Data Capture Management Console: Administration Guide

 Applies ToSource

Default Settingfalse

For information about how data in each Unicode source column is treated and
setting multibyte and Unicode character set conversions, see Replicating multibyte
(MBCS) and double-byte (DBCS) character data on page 163.

Disk resource system parameters

Some system parameters control memory usage in InfoSphere CDC. For improved
performance, if you are able to allocate more than the default value of 512 MB for
the InfoSphere CDC Java Virtual Machine, then you can adjust the disk resource
system parameters to use the increased memory.

See also:
mirror_global_disk_quota_mb
mirror_global_disk_quota_gb

mirror_global_disk_quota_mb
VersionInfoSphere CDC for IBM Informix Dynamic Server version 6.3

Use this system parameter to globally set a disk quota (in MB) for all capture
components including temporary files, transaction queues, and LOBs which are
staged on the target before being applied. InfoSphere CDC will manage disk space
utilization across all components as required.

Most databases have a mechanism that allows you to roll back or undo changes to
your database by storing uncommitted changes. Similarly, InfoSphere CDC uses
the disk quota controlled by this system parameter to store in scope change data
that has not been committed in your database. Once the database transaction is
committed, the disk space used by the transaction is released. Note that InfoSphere
CDC stores the data in memory to improve performance and will only persist the
data to disk if memory is unavailable.

The default setting of this system parameter is such that the product will only stop
replicating after this disk quota exhausts all available disk space on your system. If
you would prefer the product to stop replicating after it uses a specific amount of
disk space, you can set the value with this system parameter.

Applies ToSource and Target

Default Setting9223372036854775807

Maximum9223372036854775807

Minimum100

mirror_global_disk_quota_gb
VersionInfoSphere CDC for IBM Informix Dynamic Server version 6.5

Use this system parameter to globally set a disk quota (in GB) for all capture
components including temporary files, transaction queues, and LOBs which are

System parameters for InfoSphere CDC for IBM Informix Dynamic Server 629
 staged on the target before being applied. InfoSphere CDC will manage disk space
utilization across all components as required.

Most databases have a mechanism that allows you to roll back or undo changes to
your database by storing uncommitted changes. Similarly, InfoSphere CDC uses
the disk quota controlled by this system parameter to store in scope change data
that has not been committed in your database. Once the database transaction is
committed, the disk space used by the transaction is released. Note that InfoSphere
CDC stores the data in memory to improve performance and will only persist the
data to disk if memory is unavailable.

The default setting of this system parameter is such that the product will only stop
replicating after this disk quota exhausts all available disk space on your system. If
you would prefer the product to stop replicating after it uses a specific amount of
disk space, you can set the value with this system parameter.

Applies ToSource and Target

Default Setting9223372036854775807

Maximum9223372036854775807

Minimum1

Apply process system parameters

Some system parameters adjust the way InfoSphere CDC applies rows, column
data, and error handling.

See also:
convert_not_nullable_column
convert_not_nullable_message on page 631
global_max_batch_size on page 631
mirror_end_on_error on page 632
mirror_expected_errors_list on page 632
refresh_end_on_error on page 632
refresh_expected_errors_list on page 633
refresh_with_referential_integrity on page 633
trim_char_to_varchar on page 633
trim_varchar_to_varchar on page 634
userexit_max_lob_size_kb on page 634

convert_not_nullable_column
VersionInfoSphere CDC for IBM Informix Dynamic Server version 6.3 and later

Use this system parameter to control how InfoSphere CDC behaves when it applies
a null value to a non-nullable column. When set to true (default value), the null
value will be replaced with a default value (based on the data type of the column)
and InfoSphere CDC will generate a warning in the event log. When set to false,
InfoSphere CDC applies the null value directly to the non-nullable column which
will result in an error and cause a shutdown of InfoSphere CDC on the target
database.

630 InfoSphere Change Data Capture Management Console: Administration Guide

 Note: If you decided to set this system parameter to false and have specified this
as an error for InfoSphere CDC to ignore using the mirror_expected_errors_list
system parameter, then InfoSphere CDC will ignore the error and not shutdown.

Set this parameter to one of the following:

v trueNull value will be replaced with default value for non-nullable column,
and a warning event will be logged.
v falseNull data will be applied as-is to non-nullable column and database will
usually return an error code.

Applies ToSource and Target

Default SettingTrue

convert_not_nullable_message
VersionInfoSphere CDC for IBM Informix Dynamic Server version 6.3 and later

Use this system parameter to determine if a message will be generated in the

Event Log when InfoSphere CDC converts a null value to a default value when
applied to a non-nullable column. When set to true (default value), InfoSphere
CDC will log the event the first time it encounters a null to non-nullable mapping
(on a per column per table basis). When set to false, InfoSphere CDC will not
generate a message when a null value is converted to a default value.

Note: This system parameter applies only when the convert_not_nullable_column

parameter has been set to true.

Set this parameter to one of the following:

v trueGenerates a warning message in the Event Log the first time a null value
is converted to a default value on a per column per table basis.
v falseNo warning message is generated in the Event Log.

Applies ToTarget

Default SettingTrue

global_max_batch_size
VersionInfoSphere CDC for IBM Informix Dynamic Server version 6.3 and later

Use this system parameter to specify the maximum number of rows that
InfoSphere CDC can place in an array and apply to the target database during
refresh or mirroring. InfoSphere CDC collects rows and places them in an array (in
memory) while receiving table-level operations from the source system. InfoSphere
CDC applies the rows from the array when there is a change to a different table,
when there is a new table-level operation, or when the maximum number of rows
in an array has been reached. You can use this parameter during mirroring only if
mirror_end_on_error is true and mirror_expected_errors_list is empty. Use only
during a refresh if refresh_end_on_error is true and refresh_expected_errors_list is
empty. Before InfoSphere CDC places rows into an array, it allocates memory for
the maximum number of rows you specify and multiplies this integer by the
maximum length of a row. If the maximum number of rows is too large, then

System parameters for InfoSphere CDC for IBM Informix Dynamic Server 631
 InfoSphere CDC cannot allocate enough memory and will shut down. Management
Console references this area to present replication latency information.

Applies ToTarget

Default Setting25 rows

Maximum Setting2147483647 rows

Minimum Setting1 row

mirror_end_on_error
VersionInfoSphere CDC for IBM Informix Dynamic Server version 6.3 and later

Use this system parameter to indicate if you want to end mirroring after an apply
error occurs on the target database.

Set this parameter to one of the following:

v trueEnd mirroring after an apply error on the target database.
v falseDo not end mirroring after an apply error on the target database.

Applies ToTarget

Default SettingTrue

mirror_expected_errors_list
VersionInfoSphere CDC for IBM Informix Dynamic Server version 6.3 and later

Use this system parameter when you want InfoSphere CDC to ignore one or more
database errors when applying data changes to the target during mirroring. The
error specified must correspond to the integer error code (database-vendor specific)
returned by the SQLException class in JDBC (Java Database Connectivity). Specify
multiple errors with a comma separated list of integer error codes.

Note: Latency may increase when using this system parameter since InfoSphere
CDC will not use JDBC array apply in order to track the errors specified.

Applies ToTarget

refresh_end_on_error
VersionInfoSphere CDC for IBM Informix Dynamic Server version 6.3 and later

Use this system parameter to indicate if you want to end a refresh after an apply
error occurs.

Set this parameter to one of the following:

v trueEnd a refresh after an apply error occurs.
v falseDo not end a refresh after an apply error occurs.

Applies ToTarget

632 InfoSphere Change Data Capture Management Console: Administration Guide

 Default SettingTrue

refresh_expected_errors_list
VersionInfoSphere CDC for IBM Informix Dynamic Server version 6.3 and later

Use this system parameter when you want InfoSphere CDC to ignore one or more
database errors when refreshing data to the target. The error specified must
correspond to the integer error code (database-vendor specific) returned by the
SQLException class in JDBC (Java Database Connectivity). Specify multiple errors
with a comma separated list of integer error codes.

Note: Latency may increase when using this system parameter since InfoSphere
CDC will not use JDBC array apply in order to track the errors specified.

Applies ToTarget

refresh_with_referential_integrity
VersionInfoSphere CDC for IBM Informix Dynamic Server version 6.3 and later

Use this system parameter to indicate whether or not you want the data removed
from all the target tables being refreshed before repopulating any of them. This is
most useful when there are referential integrity constraints on the tables being
refreshed.

Set this parameter to one of the following:

v trueIndicates that InfoSphere CDC will first remove all data in reverse of the
specified refresh order. When specifying the refresh order, in general parent
tables should appear before the referenced child tables. The product will then
remove data from the child tables before the parent tables.
v falseIndicates that InfoSphere CDC will not first remove all data from your
tables and will refresh the tables in the specified order.

Applies ToSource

Default Settingfalse

trim_char_to_varchar
VersionInfoSphere CDC for IBM Informix Dynamic Server version 6.3 and later

Use this system parameter to specify whether or not InfoSphere CDC should strip
or leave trailing blanks on string data of the column in the target table.

Set this parameter to one of the following:

v trueInfoSphere CDC strips the data of trailing blanks.
v falseInfoSphere CDC does not strip the string data of trailing blanks.

Applies ToTarget

Default Settingfalse

System parameters for InfoSphere CDC for IBM Informix Dynamic Server 633
 trim_varchar_to_varchar
VersionInfoSphere CDC for IBM Informix Dynamic Server version 6.3 and later

Use this system parameter to specify whether or not InfoSphere CDC should strip
or leave trailing blanks on string data of the column in the target table.

Set this parameter to one of the following:

v trueInfoSphere CDC strips the data of trailing blanks.
v falseInfoSphere CDC does not strip the string data of trailing blanks.

Applies ToTarget

Default Settingfalse

userexit_max_lob_size_kb
VersionInfoSphere CDC for IBM Informix Dynamic Server version 6.3 and later

Use this system parameter to set the maximum size of LOB data (in kb) that
InfoSphere CDC can pass to a user exit.

Applies ToTarget

Default Setting128 kb

Maximum9223372036854775807 kb

Minimum1 kb

634 InfoSphere Change Data Capture Management Console: Administration Guide

Commands for Access Server
Access Server provides a set of commands that let you manage datastores and user
accounts from a Windows, UNIX, or Linux command prompt.

Note the following about the commands:

v You can run the commands from the bin directory in your Access Server
installation directory.
v Use the -? flag to display help information. For example, dmcreateuser -?

In this section, you will learn:

Datastore commands
User account commands on page 639
Other commands on page 647

Datastore commands
This section contains commands that help you create and manage your datastores.

See also:
dmchangeconnectionpasswordChanging the connection parameters to a
datastore
dmcreatedatastoreAdding a datastore on page 636
dmdeleteconnectionDeleting a datastore connection on page 637
dmdeletedatastoreDeleting a datastore on page 638
dmlistuserdatastoresGenerating a report list of datastores assigned to a user
on page 639

dmchangeconnectionpasswordChanging the connection

parameters to a datastore
Use this command to change connection parameters to a datastore for a user
account. When changing a connection for a user, you must identify the name and
password of the database you want users to use for replication. This database
resides on the same server as your InfoSphere CDC installation. When the user
establishes a connection to the datastore, they are in fact connecting to this
database.

Syntax
DMCHANGECONNECTIONPASSWORD userName datastoreName database databaseOwner
databasePassword [-accessserver hostname port adminuser adminpassword]

Parameters
userName
Specifies the name of the user for which you want to create a connection.
datastoreName
Specifies the name of the datastore you want the user to connect to.

Copyright IBM Corp. 2008, 2011 635

 database
Specifies the name of the database that you want users to replicate to or from.
Not all datastore connections are to a database. Use "" if not required.
databaseOwner
Specifies the user name of the database. Not all datastore connections are to a
database. Use "" if not required.
databasePassword
Specifies the password to log into the database. Not all datastore connections
are to a database. Use "" if not required.
-accessserver hostname port adminuser adminpassword
These parameters are optional and indicate that you want to run this
command for an installation of Access Server that is physically remote from
the Access Server installation where you are running this command. In other
words, you must install Access Server and run this command on a system to
which you have direct physical access. If you have installed Access Server on
the same machine as Management Console, then these parameters are not
required.
-accessserver
Specify -accessserver. This parameter indicates that you want to connect
to a remote installation of Access Server.
hostname
The fully qualified host name of the remote system where Access Server is
installed.
port
The port number of the remote system where Access Server is installed.
adminuser
A user with SYSADMIN privileges (see role parameter in the
dmcreateuser command) and the ability to manage users and datastores
(see manager parameter in the dmcreateuser command).
adminpassword
The password for the specified SYSADMIN user.

dmcreatedatastoreAdding a datastore
Use this command to add a new datastore. Adding a datastore in Management
Console means that you are in the process of making an installation of InfoSphere
CDC and the database you want users to replicate to or from available for
connection by other users. When adding a datastore, you must specify information
about where your installation of InfoSphere CDC resides.

Syntax
DMCREATEDATASTORE datastoreName description hostname port
[-accessserver hostname port adminuser adminpassword]

Parameters
datastoreName
Specifies the name of the datastore you want to add.
description
Specifies a brief description about this datastore.

636 InfoSphere Change Data Capture Management Console: Administration Guide

 hostname
Specifies the hostname of the server where you have installed InfoSphere CDC.
port
Specifies the port numbe r of the server where you have installed InfoSphere
CDC.
-accessserver hostname port adminuser adminpassword
These parameters are optional and indicate that you want to run this
command for an installation of Access Server that is physically remote from
the Access Server installation where you are running this command. In other
words, you must install Access Server and run this command on a system to
which you have direct physical access. If you have installed Access Server on
the same machine as Management Console, then these parameters are not
required.
-accessserver
Specify -accessserver. This parameter indicates that you want to connect
to a remote installation of Access Server.
hostname
The fully qualified host name of the remote system where Access Server is
installed.
port
The port number of the remote system where Access Server is installed.
adminuser
A user with SYSADMIN privileges (see role parameter in the
dmcreateuser command) and the ability to manage users and datastores
(see manager parameter in the dmcreateuser command).
adminpassword
The password for the specified SYSADMIN user.

dmdeleteconnectionDeleting a datastore connection

Use this command to delete an existing connection between a datastore and a user.

Syntax
DMDELETECONNECTION userName datastoreName
[-accessserver hostname port adminuser adminpassword]

Parameters
username
Specifies the unique name of the user you want to delete the connection for.
datastoreName
Specifies the name of the datastore you want to delete the connection for.
-accessserver hostname port adminuser adminpassword
These parameters are optional and indicate that you want to run this
command for an installation of Access Server that is physically remote from
the Access Server installation where you are running this command. In other
words, you must install Access Server and run this command on a system to
which you have direct physical access. If you have installed Access Server on
the same machine as Management Console, then these parameters are not
required.

Commands for Access Server 637

 -accessserver
Specify -accessserver. This parameter indicates that you want to connect
to a remote installation of Access Server.
hostname
The fully qualified host name of the remote system where Access Server is
installed.
port
The port number of the remote system where Access Server is installed.
adminuser
A user with SYSADMIN privileges (see role parameter in the
dmcreateuser command) and the ability to manage users and datastores
(see manager parameter in the dmcreateuser command).
adminpassword
The password for the specified SYSADMIN user.

dmdeletedatastoreDeleting a datastore
Use this command to delete a datastore.

Syntax
DMDELETEDATASTORE datastoreName
[-accessserver hostname port adminuser adminpassword]

Parameters
datastoreName
Specifies the name of the datastore you want to delete.
-accessserver hostname port adminuser adminpassword
These parameters are optional and indicate that you want to run this
command for an installation of Access Server that is physically remote from
the Access Server installation where you are running this command. In other
words, you must install Access Server and run this command on a system to
which you have direct physical access. If you have installed Access Server on
the same machine as Management Console, then these parameters are not
required.
-accessserver
Specify -accessserver. This parameter indicates that you want to connect
to a remote installation of Access Server.
hostname
The fully qualified host name of the remote system where Access Server is
installed.
port
The port number of the remote system where Access Server is installed.
adminuser
A user with SYSADMIN privileges (see role parameter in the
dmcreateuser command) and the ability to manage users and datastores
(see manager parameter in the dmcreateuser command).
adminpassword
The password for the specified SYSADMIN user.

638 InfoSphere Change Data Capture Management Console: Administration Guide

 dmlistuserdatastoresGenerating a report list of datastores
assigned to a user
Use this command to generate a list of datastores assigned to a specific user.

Syntax
DMLISTUSERDATASTORES username [-accessserver hostname port adminuser adminpassword]

Parameters
username
Specifies the name of the user you want to generate a list for. This list specifies
the datastores assigned to this user.
-accessserver hostname port adminuser adminpassword
These parameters are optional and indicate that you want to run this
command for an installation of Access Server that is physically remote from
the Access Server installation where you are running this command. In other
words, you must install Access Server and run this command on a system to
which you have direct physical access. If you have installed Access Server on
the same machine as Management Console, then these parameters are not
required.
-accessserver
Specify -accessserver. This parameter indicates that you want to connect
to a remote installation of Access Server.
hostname
The fully qualified host name of the remote system where Access Server is
installed.
port
The port number of the remote system where Access Server is installed.
adminuser
A user with SYSADMIN privileges (see role parameter in the
dmcreateuser command) and the ability to manage users and datastores
(see manager parameter in the dmcreateuser command).
adminpassword
The password for the specified SYSADMIN user.

User account commands

This section contains commands that help you create and manage your user
accounts.

See also:
dmchangeuserpasswordChanging the password on a user account on page
640
dmcreateuserAdding a user account on page 640
dmdeleteuserDeleting a user on page 642
dmdisableuserDisabling a user account on page 643
dmenableuserEnabling a user on page 643
dmlistusersListing user accounts on page 644
dmresetuserResetting a user account on page 646

Commands for Access Server 639

 dmunlockuserUnlocking a user account on page 646

dmchangeuserpasswordChanging the password on a user

account
Use this command to change the password on a user account that you had created.
This user will require the password in order to log into Management Console. To
change passwords, you must be a System Administrator and have the privilege to
manage datastores and user accounts.

Syntax
DMCHANGEUSERPASSWORD username password
[-accessserver hostname port adminuser adminpassword]

Parameters
userName
Specifies the name of the user that you are changing the password for.
password
Specifies the password you want the user to supply when logging into
Management Console. If you have enabled complex passwords, then you must
specify a password that meets the requirements.
-accessserver hostname port adminuser adminpassword
These parameters are optional and indicate that you want to run this
command for an installation of Access Server that is physically remote from
the Access Server installation where you are running this command. In other
words, you must install Access Server and run this command on a system to
which you have direct physical access. If you have installed Access Server on
the same machine as Management Console, then these parameters are not
required.
-accessserver
Specify -accessserver. This parameter indicates that you want to connect
to a remote installation of Access Server.
hostname
The fully qualified host name of the remote system where Access Server is
installed.
port
The port number of the remote system where Access Server is installed.
adminuser
A user with SYSADMIN privileges (see role parameter in the
dmcreateuser command) and the ability to manage users and datastores
(see manager parameter in the dmcreateuser command).
adminpassword
The password for the specified SYSADMIN user.

dmcreateuserAdding a user account

Use this command to add a new user. Adding a user account is necessary to
provide users with the ability to log in to Management Console.

640 InfoSphere Change Data Capture Management Console: Administration Guide

Syntax
DMCREATEUSER username fullname description password role manager changePassword
passwordNeverExpires [-accessserver hostname port adminuser adminpassword]

Parameters
username
Specifies the unique name for the user you want to create an account for.
fullname
Specifies the full name of the user.
description
Specifies a description about the user.
password
Specifies the password you want the user to supply when logging into
Management Console. If you have enabled complex passwords, then you must
specify a password that meets the requirements.
role
Specifies the role you want to assign to the user. Enable one of the following
values:
v SYSADMINSpecifies that a user assigned to this role is working in a
System Administrator account and can perform all available operations in
Management Console. Only users that require full operational access to the
Monitoring and Configuration perspectives should be assigned to this role.
System Administrators can also modify system parameters to calibrate their
replication environment.
v ADMINSpecifies that a user assigned to this role is working in an
Administrator account and can perform all available operations in
Management Console, but cannot modify system parameters. Users assigned
to this role can access both the Monitoring and Configuration perspectives.
v OPERATORSpecifies a that user assigned to this role is working in an
Operator account and has access to both the Monitoring and Configuration
perspectives. Operators can add, import and export projects, but they cannot
create new subscriptions. Users assigned to the Operator role can start, stop,
and monitor replication activities. They can also view the tables selected for
refresh and start a refresh on a subscription. Operators can view notifications
sent by subscriptions or datastores. However, users assigned to this role
cannot configure replication and select or remove tables from a refresh.
v MONITORSpecifies that a user assigned to this role is working in a
Monitoring account and only has access to the Monitoring perspective in
Management Console. Users assigned to the Monitor role can view the event
log, view statistics, and view table mappings. Monitors can view the
replication state and status of a subscription and can view latency threshold
information. However, users assigned to this role cannot start or stop
replication, configure replication, refresh tables, or view notifications sent by
subscriptions and datastores.
manager
Specifies that a user assigned the role of SYSADMIN also has privileges to
manage datastores and user accounts in the Access Manager perspective of
Management Console. If you want to enable this privilege for a System
Administrator, then specify a value of TRUE. Otherwise, specify a value
FALSE.

Commands for Access Server 641

 Note: You must enable this privilege with a value of TRUE if you are creating
a user account for the UNIX or Linux platforms that will allow you to log in to
Management Console for the first time after the installation.
changePassword
Specifies you want the user to change their password when logging into
Management Console for the first time. If you want the user to change the
password, specify a value of TRUE. Otherwise, if you want the user to login
using the same password you have assigned to them, then specify a value of
FALSE.
passwordNeverExpires
Specifies that you want to override any existing password expiry policies set in
Management Console so that the password never expires. If you want to
override an existing password expiry policy, specify a value of TRUE.
Otherwise, if you want the password to expire, then specify a value of FALSE.
-accessserver hostname port adminuser adminpassword
These parameters are optional and indicate that you want to run this
command for an installation of Access Server that is physically remote from
the Access Server installation where you are running this command. In other
words, you must install Access Server and run this command on a system to
which you have direct physical access. If you have installed Access Server on
the same machine as Management Console, then these parameters are not
required.
-accessserver
Specify -accessserver. This parameter indicates that you want to connect
to a remote installation of Access Server.
hostname
The fully qualified host name of the remote system where Access Server is
installed.
adminuser
A user with SYSADMIN privileges (see the role parameter above) and the
ability to manage users and datastores (see the manager parameter above).
adminpassword
The password for the specified SYSADMIN user.

dmdeleteuserDeleting a user
Use this command to delete a user.

Syntax
DMDELETEUSER username [-accessserver hostname port adminuser adminpassword]

Parameters
username
Specifies the name of the user you want to delete.
accessserver hostname port adminuser adminpassword
These parameters are optional. Specifies that you want to connect to a remote
installation of Access Server. If you have installed Access Server on the same
machine as Management Console, then these parameters are not required.

642 InfoSphere Change Data Capture Management Console: Administration Guide

dmdisableuserDisabling a user account
Use this command to disable a user account. This prevents the user from logging
into Management Console.

Syntax
DMDISABLEUSER username [-accessserver hostname port adminuser adminpassword]

Parameters
username
Specifies the name of the user you want to disable.
-accessserver hostname port adminuser adminpassword
These parameters are optional and indicate that you want to run this
command for an installation of Access Server that is physically remote from
the Access Server installation where you are running this command. In other
words, you must install Access Server and run this command on a system to
which you have direct physical access. If you have installed Access Server on
the same machine as Management Console, then these parameters are not
required.
-accessserver
Specify -accessserver. This parameter indicates that you want to connect
to a remote installation of Access Server.
hostname
The fully qualified host name of the remote system where Access Server is
installed.
port
The port number of the remote system where Access Server is installed.
adminuser
A user with SYSADMIN privileges (see role parameter in the
dmcreateuser command) and the ability to manage users and datastores
(see manager parameter in the dmcreateuser command).
adminpassword
The password for the specified SYSADMIN user.

dmenableuserEnabling a user
Use this command to enable a user account. This lets the user log into
Management Console.

Syntax
DMENABLEUSER username [-accessserver hostname port adminuser adminpassword]

Parameters
username
Specifies the name of the user you want to enable.
-accessserver hostname port adminuser adminpassword
These parameters are optional and indicate that you want to run this
command for an installation of Access Server that is physically remote from
the Access Server installation where you are running this command. In other

Commands for Access Server 643

 words, you must install Access Server and run this command on a system to
which you have direct physical access. If you have installed Access Server on
the same machine as Management Console, then these parameters are not
required.
-accessserver
Specify -accessserver. This parameter indicates that you want to connect
to a remote installation of Access Server.
hostname
The fully qualified host name of the remote system where Access Server is
installed.
port
The port number of the remote system where Access Server is installed.
adminuser
A user with SYSADMIN privileges (see role parameter in the
dmcreateuser command) and the ability to manage users and datastores
(see manager parameter in the dmcreateuser command).
adminpassword
The password for the specified SYSADMIN user.

dmlistusersListing user accounts

Use this command to generate a list of users and properties on the account.

Syntax
DMLISTUSERS [-accessserver hostname port adminuser adminpassword]

Parameters
-accessserver hostname port adminuser adminpassword
These parameters are optional and indicate that you want to run this
command for an installation of Access Server that is physically remote from
the Access Server installation where you are running this command. In other
words, you must install Access Server and run this command on a system to
which you have direct physical access. If you have installed Access Server on
the same machine as Management Console, then these parameters are not
required.
-accessserver
Specify -accessserver. This parameter indicates that you want to connect
to a remote installation of Access Server.
hostname
The fully qualified host name of the remote system where Access Server is
installed.
port
The port number of the remote system where Access Server is installed.
adminuser
A user with SYSADMIN privileges (see role parameter in the
dmcreateuser command) and the ability to manage users and datastores
(see manager parameter in the dmcreateuser command).
adminpassword
The password for the specified SYSADMIN user.

644 InfoSphere Change Data Capture Management Console: Administration Guide

Output
User
Specifies the name of the user.
Role
Specifies the role assigned to the user.
v SYSADMINSpecifies that a user assigned to this role is working in a
System Administrator account and can perform all available operations in
Management Console. Only users that require full operational access to the
Monitoring and Configuration perspectives should be assigned to this role.
System Administrators can also modify system parameters to calibrate their
replication environment.
v ADMINSpecifies that a user assigned to this role is working in an
Administrator account and can perform all available operations in
Management Console, but cannot modify system parameters. Users assigned
to this role can access both the Monitoring and Configuration perspectives.
v OPERATORSpecifies a that user assigned to this role is working in an
Operator account and has access to both the Monitoring and Configuration
perspectives. Operators can add, import and export projects, but they cannot
create new subscriptions. Users assigned to the Operator role can start, stop,
and monitor replication activities. They can also view the tables selected for
refresh and start a refresh on a subscription. Operators can view notifications
sent by subscriptions or datastores. However, users assigned to this role
cannot configure replication and select or remove tables from a refresh.
v MONITORSpecifies that a user assigned to this role is working in a
Monitoring account and only has access to the Monitoring perspective in
Management Console. Users assigned to the Monitor role can view the event
log, view statistics, and view table mappings. Monitors can view the
replication state and status of a subscription and can view latency threshold
information. However, users assigned to this role cannot start or stop
replication, configure replication, refresh tables, or view notifications sent by
subscriptions and datastores.
Manager
Specifies if the user assigned to the role of System Administrator has also been
assigned privileges to manage datastores and user accounts. TRUE indicates
that the System Administrator has been given these privileges. FALSE indicates
that the System Administrator has not been given these privileges.
Disabled
Specifies if the account has been disabled. TRUE indicates that the account is
disabled. FALSE indicates the account is enabled.
Locked
Specifies if the account has been locked. This is automatically set to TRUE if
the number of failed login attempts exceeds the locking policy you may have
set.
PwdChange
Specifies if the user is required to change their password the next time the user
logs into Management Console. TRUE indicates the user is required to change
the password. FALSE indicates the user can use the same password assigned to
them.
Expires
Specifies if the user account overrides any existing password expiry policy set

Commands for Access Server 645

 in Management Console. TRUE indicates the password supplied will not expire
and overrides any expiry policy. FALSE indicates the password does expire
based on an expiry policy.

dmresetuserResetting a user account

Use this command to reset a user account. When you reset a user account, the
following properties are returned to their defaults:
v the password is set to an empty string
v the account is enabled
v the account is unlocked
v the user must change their password at next login
v the password is set to follow the password expiry policy

Syntax
DMRESETUSER username [-accessserver hostname port adminuser adminpassword]

Parameters
username
Specifies the name of the user account that needs to be reset.
-accessserver hostname port adminuser adminpassword
These parameters are optional and indicate that you want to run this
command for an installation of Access Server that is physically remote from
the Access Server installation where you are running this command. In other
words, you must install Access Server and run this command on a system to
which you have direct physical access. If you have installed Access Server on
the same machine as Management Console, then these parameters are not
required.
-accessserver
Specify -accessserver. This parameter indicates that you want to connect
to a remote installation of Access Server.
hostname
The fully qualified host name of the remote system where Access Server is
installed.
port
The port number of the remote system where Access Server is installed.
adminuser
A user with SYSADMIN privileges (see role parameter in the
dmcreateuser command) and the ability to manage users and datastores
(see manager parameter in the dmcreateuser command).
adminpassword
The password for the specified SYSADMIN user.

dmunlockuserUnlocking a user account

Use this command to unlock a user account. A user account is automatically locked
after the number of failed login attempts exceeds the locking policy you may have
set in the Access Server Options dialog box in Management Console.

Syntax
646 InfoSphere Change Data Capture Management Console: Administration Guide
 DMUNLOCKUSER username [-accessserver hostname port adminuser adminpassword]

Parameters
username
Specifies the name of the user you want to unlock.
-accessserver hostname port adminuser adminpassword
These parameters are optional and indicate that you want to run this
command for an installation of Access Server that is physically remote from
the Access Server installation where you are running this command. In other
words, you must install Access Server and run this command on a system to
which you have direct physical access. If you have installed Access Server on
the same machine as Management Console, then these parameters are not
required.
-accessserver
Specify -accessserver. This parameter indicates that you want to connect
to a remote installation of Access Server.
hostname
The fully qualified host name of the remote system where Access Server is
installed.
port
The port number of the remote system where Access Server is installed.
adminuser
A user with SYSADMIN privileges (see role parameter in the
dmcreateuser command) and the ability to manage users and datastores
(see manager parameter in the dmcreateuser command).
adminpassword
The password for the specified SYSADMIN user.

Other commands
This section contains miscellaneous commands for Access Server.

See also:
dmaccessserverStart Access Server
dmaddconnectionAdding a datastore connection to a user on page 648
dmlistdatastoreusersGenerating a report list of users assigned to a datastore
on page 649
dmshowversionShow InfoSphere CDC Access Server version on page 649
onlineOpen command environment on page 650

dmaccessserverStart Access Server

Use this command to start Access Server services for Windows and to start Access
Server processes for UNIX and Linux.

Syntax
DMACCESSSERVER

Commands for Access Server 647

 Parameters

None.

dmaddconnectionAdding a datastore connection to a user

Use this command to set connection parameters to a datastore for a user. When
adding a connection for a user, you must identify the name and password of the
database you want users to use for replication. This database resides on the same
server as your InfoSphere CDC installation. When the user establishes a connection
to the datastore, they are in fact connecting to this database.

Syntax
DMADDCONNECTION userName datastoreName database databaseOwner
databasePassword alwaysPrompt showParams writeProtected saveParams
[-accessserver hostname port adminuser adminpassword]

Parameters
userName
Specifies the name of the user for which you want to create a connection.
datastoreName
Specifies the name of the datastore you want the user to connect to.
database
Specifies the name of the database that you want users to replicate to or from.
Not all datastore connections are to a database. Use "" if not required.
databaseOwner
Specifies the user name of the database. Not all datastore connections are to a
database. Use "" if not required.
databasePassword
Specifies the password to log into the database. Not all datastore connections
are to a database. Use "" if not required.
alwaysPrompt
Specifies that you want the user to always be prompted for a connection each
time the user tries to connect to the datastore. If you want the user to be
prompted for a connection, then specify a value of TRUE. Otherwise, specify a
value of FALSE.
showParams
Specifies that you want all the connection parameters displayed to the user
(except for the password) each time the user tries to connect to the datastore. If
you want the parameters displayed, then specify a value of TRUE. Otherwise,
specify a value of FALSE.
writeProtected
Specifies that you want all the connection parameters displayed to the user in
read-only format each time the user tries to connect to the datastore. If you
want the parameters displayed in read-only format, specify a value of TRUE.
Otherwise, specify a value of FALSE.
saveParams
Specifies that you want the user to be able to save connection parameters
when connecting to the datastore. If you want to enable parameter saving, then
specify a value of TRUE. Otherwise, specify a value of FALSE.
-accessserver hostname port adminuser adminpassword

648 InfoSphere Change Data Capture Management Console: Administration Guide

 These parameters are optional and indicate that you want to run this
command for an installation of Access Server that is physically remote from
the Access Server installation where you are running this command. In other
words, you must install Access Server and run this command on a system to
which you have direct physical access. If you have installed Access Server on
the same machine as Management Console, then these parameters are not
required.
-accessserver
Specify -accessserver. This parameter indicates that you want to connect
to a remote installation of Access Server.
hostname
The fully qualified host name of the remote system where Access Server is
installed.
port
The port number of the remote system where Access Server is installed.
adminuser
A user with SYSADMIN privileges (see role parameter in the
dmcreateuser command) and the ability to manage users and datastores
(see manager parameter in the dmcreateuser command).
adminpassword
The password for the specified SYSADMIN user.

dmlistdatastoreusersGenerating a report list of users

assigned to a datastore
Use this command to generate a list of users assigned to a specific datastore.

Syntax
DMLISTDATASTOREUSERS adminUser adminPassword datastoreName

Parameters
adminUser
Specifies the name of the System Administrator.
adminPassword
Specifies the password of the System Administrator.
datastoreName
Specifies the name of the datastore you want to generate a list for. This list
specifies the names of the users assigned to this datastore.

dmshowversionShow InfoSphere CDC Access Server

version
Use this command to display the InfoSphere CDC Access Server version and build
number. Run this command before you contact your IBM representative.

Syntax
DMSHOWVERSION

Commands for Access Server 649

 Parameters

None.

onlineOpen command environment

This command opens a command environment where you can submit
Management Console commands. For more information on the commands that are
available, see Management Console - API and Commands Reference.

Syntax
ONLINE

Parameters

None.

650 InfoSphere Change Data Capture Management Console: Administration Guide

Using Support Assistant and contacting IBM Support
Management Console Support Assistant, or simply Support Assistant, allows you
to collect diagnostic data such as configuration, log, and runtime information for
Management Console, Access Server, and optionally for specific datastores in your
environment. If tracing is enabled, it can also collect trace information for
Management Console, Access Server, and your datastores.

By default with the Standard collection method, Support Assistant collects

diagnostic data and tracing information for Management Console and Access
Server. If you specify a Detailed collection method for datastores, Support
Assistant collects diagnostic and trace data for the time period you specify.

You must enable tracing before running Support Assistant so that Management
Console saves tracing information while you reproduce your support issue.Support
Assistant will collect the trace information for Management Console and Access
Server, and if you enable Detailed collection for the specified datastores, it will
collect the trace information for the time period that you specify.

Support Assistant collects diagnostic data and trace information and places this
data in a compressed file with a .zip extension. It is your responsibility to send
this file to IBM Support which is used to diagnose and troubleshoot your support
issue.
Preparing to collect diagnostic data and tracing information
Contacting IBM Support on page 654

Preparing to collect diagnostic data and tracing information

Before using Support Assistant to collect diagnostic data and tracing information,
review and complete the tasks in the following workflow to ensure the collected
data is adequate for efficient problem diagnosis and resolution:
1. Enable tracing for Management Console and Access Server. See the related
topic below for more information on how to do this.
2. Enable tracing for your datastores if this is requested by IBM Support. Tracing
for your datastores may result in significant performance degradation and is
often recommended only after consultation with IBM Support. See the related
topic below for more information on how to do this.
3. Reproduce the problem you encountered in Management Console or with your
InfoSphere CDC datastore.
4. Start collecting diagnostic data and tracing information with Support Assistant.
Support Assistant collects this information in a compressed file that you will
send to IBM Support. See the related topic below for more information on how
to do this.

Important: In order to minimize impact on your InfoSphere CDC datastore

performance, you should disable full trace for your datastores after reproducing
your support issue.

See also:
To enable tracing for Management Console and Access Server on page 652

Copyright IBM Corp. 2008, 2011 651

 To enable tracing for datastores for InfoSphere CDC version 6.3 and above
(optional)
To start the collection of diagnostic data and tracing information with Support
Assistant on page 653

To enable tracing for Management Console and Access Server

Once tracing is enabled for Management Console and Access Server, log files are
generated which can be collected by Support Assistant.
1. Click Help > Service Information > Trace Options
2. Select the Enable the collection of tracing information check box to activate
tracing.
3. In the Trace Methods area, select one of the following options:
v Capture Access Server messagesSelect this option to diagnose
configuration and monitoring problems between Management Console,
Access Server and datastores. This is the default setting.
v Capture Management Console messages Select this option to diagnose
problems between a single Management Console, Access Server, and
datastores.
v Capture Access Server logging information Select this option to diagnose
Access Serverspecific problems. Only select this option when instructed
byIBM Support.
4. Click OK.
Related concepts
Using Support Assistant and contacting IBM Support on page 651
Related tasks
To enable tracing for datastores for InfoSphere CDC version 6.3 and above
(optional)

To enable tracing for datastores for InfoSphere CDC version

6.3 and above (optional)
Contact IBM Support for information on enabling tracing for other versions of
InfoSphere CDC.

The instructions below do not apply to InfoSphere CDC for z/OS. For InfoSphere
CDC for z/OS, tracing should only be enabled once IBM Support has reviewed the
SPOOLed output and can provide advice on the trace points to enable if it is
necessary to further the investigation.

Note: Tracing for your datastores should only be used when directed by IBM
Support since it may significantly degrade InfoSphere CDC replication engine
performance. For performance reasons, tracing for your datastores should be
turned off immediately after you reproduce your problem in Management Console.
1. Add the global_trace_until system parameter to each datastore (InfoSphere CDC
version 6.3 and above) that encountered a support issue. This system parameter
will enable tracing until the specified date and time.
2. Type a date and time or only a date value in the Value box. Ensure you enclose
the date and time values with quotes. For example, "1/14/08" or "1/14/08 1:34
PM". When you type a specific date and time, full tracing is enabled until that
specified period. If you choose to only specify a date, then tracing is turned on

652 InfoSphere Change Data Capture Management Console: Administration Guide

 by default until 12 AM. For example, if you specify "1/14/08" then tracing is
turned on until January 14, 2008 at 12 AM. If you specify both date and time
"1/14/08 1:34 PM", then tracing is turned on until January 14, 2008 at 1:34 PM.
You can also delete the system parameter to turn off tracing.
3. Click OK.
Due to the performance impact of tracing on your datastores, you should
ensure that tracing is turned off after reproducing your support issue in
Management Console.
Related concepts
Using Support Assistant and contacting IBM Support on page 651
Related tasks
To enable tracing for Management Console and Access Server on page 652
To add a system parameter on page 72
To delete a system parameter on page 72

To start the collection of diagnostic data and tracing

information with Support Assistant
Important: Before you start the collection of diagnostic data and tracing
information with Support Assistant you must follow the workflow and complete
the tasks outlined in Preparing to collect diagnostic data and tracing information
on page 651.
1. Click Help > Service Information > Support Assistant
2. In the Collection area, select the Enable collection check box for each
datastore for which you want to collect diagnostic data and tracing
information. Support Assistant automatically collects diagnostic data and
tracing information for Management Console and Access Server.
3. Click Options to open the Datastore Collection dialog box.
4. In the Collection Method area, choose one of the following options:
v StandardIndicates that Support Assistant will collect standard diagnostic
data for the specified datastores. Tracing information for your datastores is
not collected with this option.
v DetailedIndicates that Support Assistant will collect detailed diagnostic
data for the specified datastores. This method of data collection may take
substantially longer than the Standard collection method. If IBM Support
recommends that you should collect tracing information for the specified
datastores, you must enable tracing on your datastores before you
reproduce the problem and before you use Support Assistant to collect the
tracing data. See the appropriate related topic below for more information
on how to enable tracing for your datastore.
5. For the Detailed collection method in the Time Period area, select the time
period when you want Support Assistant to collect diagnostic data and tracing
information for the specified datastores. Support Assistant automatically
collects all diagnostic data and tracing information for Management Console
and Access Server.
6. Click OK.
7. In the Output area, click Browse to select the directory where you want
Support Assistant to place the generated .zip file after collection is complete.
8. To remove additional diagnostic files from the directory you selected in the
previous step after collection is complete and only leave the .zip file, select
the Clean-up diagnostic files after collection check box.

Using Support Assistant and contacting IBM Support 653

 9. Click Collect Now to start the collection process.
10. After collection is complete, Support Assistant displays the path to the .zip
file on your system. Click Locate File... to open the directory that contains the
compressed file.
If you selected a Detailed collection method for one or more datastores in
Step 4 on page 653, Support Assistant will also display the path to one or
more additional .zip files on the systems where each datastore is installed.
Make note of the location of these files before you close this dialog box. It is
your responsibility to retrieve the .zip files and send them to IBM Support.

Note: .zip files with a *.inprocess extension are still collecting data from
your datastore and are not ready to be sent to IBM Support. Collection is
complete when the *.inprocess extension is removed.
Related concepts
Preparing to collect diagnostic data and tracing information on page 651

Contacting IBM Support

In addition to collecting diagnostic information with Support Assistant, you should
also attempt to provide answers to as many of the following questions as possible
before contacting IBM Support:
v What is the problem you are experiencing and can you reproduce it?
v What did you do to reproduce the problem with tracing enabled?
v Which datastores are affected?
v Which subscriptions are affected?
v Which tables or rows are affected?
v Can you provide a screen capture of the error?

The following support page contains the latest troubleshooting information and
details on how to open a service request with IBM Support:
v http://www.ibm.com/software/data/infosphere/support/change-data-capture/

For contact information in your region:

v http://www.ibm.com/planetwide/
Related concepts
Preparing to collect diagnostic data and tracing information on page 651

654 InfoSphere Change Data Capture Management Console: Administration Guide

Glossary
Access Manager. A functional area of the Management
Console used by the administrator to configure the
security model of InfoSphere CDC users and their
permissions.
Access Server. A background process on a Windows
or UNIX workstation that implements the InfoSphere
CDC security model.
adaptive apply. A method of applying data to a target
table which allows the target table to have incorrect
data. As data changes are replicated from the source
table the target table will become more accurate.
after image. The updated content of a source-table
column after the source operation has completed.
auditing. The process of tracking table and row-level
operations (insert, update, delete and clear operations)
that have been applied to a source table. The tracking
occurs in a target table.
before image. The content of a replication source-table
column prior to the source operation.
bidirectional replication. Replication in which
changes that are made to one copy of a table are
replicated to a second copy of that table, and changes
that are made to the second copy are replicated back to
the first copy. You must choose which copy of the table
wins if a conflict occurs.
bookmark. Information that InfoSphere CDC uses to
maintain transactional data consistency.
cascading replication. A replication topology where
changes are first replicated to a target table, and then
the changes made to that target table are further
replicated to one or more additional target tables (often
located in another database).
column function. An expression within a derived
expression that performs enhanced data manipulation.
Typically, column functions calculate statistical
aggregations, such as COUNT, SUM, AVG, or MAX,
based on the values of existing columns, and then place
the results in new columns.
column mapping. The action of choosing which
source columns are replicated to which target columns.
commitment control. A feature that maintains
transaction consistency during replication and ensures
that all transactions are applied to the target system.
Copyright IBM Corp. 2008, 2011
conflict detection. The process of detecting whether
the same row was updated by users or application
programs in both the source and target tables at
essentially the same time.
continuous mirroring. A method of mirroring data
where a change applied to a source table is
immediately replicated to the target table. You should
use continuous mirroring when it is important that
source and target tables are synchronized at all times.
critical column. A change to a critical column
indicates that the source operation is important and
should be replicated to the target environment. If a
source row is updated but no critical columns are
changed then this change won't be replicated to the
target table. The changes to the non-critical columns
will be replicated to the target the next time an
important update is done.
data type. Defines the type of data stored in a specific
database column, such as date, numeric, or character
data. Significant differences in data types exist between
different platforms' databases.
datastore. An instance of a InfoSphere CDC engine.
Instances are created using the configuration tool
provided for each engine
derived column. A column that is calculated from
other source column values using a derived expression.
differential refresh. A process that will synchronize
the target table with the current contents of the source
table by applying only the differences between the
target and the source table.
in scope objects. Objects that will be considered, or
included, for replication to the backup system.
filtering columns. The process of identifying which
source columns you want to include or exclude for
replication.
derived expressions. An expression that defines the
value placed in a column for each row inserted or
updated in a target table.
journal control fields. A set of fields that contain
different information about a journal entry associated
with a source table change. Journal control fields can be
assigned to target columns, as journal entry
information is replicated with source table data. In
Management Console, journal control fields are denoted
with an ampersand (&) before the name of the field
latency. The latency of the target table indicates how
closely synchronized it is with the source table. For
655
example, if all the changes that have occurred more
than thirty seconds ago on the source system have been
applied to the target table, but some changes that were
done in the last thirty seconds have not yet been
applied, then the table would be thirty seconds latent.
LiveAudit. A feature that maintains an audit trail of
table changes in the mapped target table.
Management Console. The administrator applications
that provide the necessary support to configure,
manage, and monitor an entire replication
configuration from a central location.
member identifiers. An expression identifying the
member in a multimember IBM i source table that is
the source of replicated data. You require member
identifiers to identify the member for each replicated
record so that data in the target table is not erased
during a refresh.
metadata. The internal set of tables that maintain the
entities, attributes, and characteristics of your
replication configuration.
mirroring. The process of continuous replication of
changed data from the source system to the target
system
scheduled end (net change) mirroring. Scheduled End
(Net Change) mirroring replicates changes (to the
target) up to a user-specified point in the source
database log and then ends replication. Use this type of
mirroring when business requirements dictate that you
only replicate your data periodically and you have a
clearly defined end point for the state of your target
database when replication ends. Scheduled End (Net
Change) mirroring allows you to end replication at the
following points in your source database log:
v Current time or Now
v User-specified date and time
v User-specified log position
These user specified end points ensure that your target
database is in a known state when replication ends.
notifications. A mechanism that generates a
notification in response to a generated product
message. A notification can be conveyed through
different methods (e-mail notification, user exit
program notification, and so on). This mechanism
allows a user to monitor replication activity in their
network.
out of scope objects. Objects that will not be
considered for, or will be excluded from, replication to
the target system.
persistent subscription. InfoSphere CDC will ensure
that a persistent subscription is restarted when the
engine is restarted after shutdown or after the
subscription ends with a recoverable error.
656 InfoSphere Change Data Capture Management Console: Administration Guide
propagation control. The process of preventing the
replication of data from a particular source. This is
useful if you are using a bidirectional replication
configuration and prevents subscriptions from
unnecessarily repeating operations like inserting data.
recursion. The process by which a perpetual series of
repetitive changes applied to the same record occurs
between two or more tables in a bidirectional
replication scenario.
recursion prevention. When performing bidirectional
replication, the ability to avoid a change to one table
from being repetitively applied to both tables without
termination.
refresh. A process that will synchronize the target
table with the current contents of the source table.
refresh order. The order in which source tables will be
refreshed.
replication. The process of maintaining a on-going
synchronization between the contents of source tables
and target tables
The process of sending changes from source table(s) to
the target system. In InfoSphere CDC this term
encompasses all methods of transferring data (refresh
and mirroring).
replication method. A property of table mapping that
indicates whether it performs mirroring or refresh
row filtering. The process of determining which rows
in a source table to replicate. Typically, an expression
tests one or more column values in each row and
returns a boolean result that replicates or discards the
row.
source database. A database from which replication
transfers captured changes.
subscription. A group of table mappings.
subscription promotion. The process of copying
replication definitions from one environment to another
environment without having to recreate the definitions.
subscription state. An indicator of the activity
involving a subscription defined in Management
Console. The subscription state indicates whether
replication operations to a subscription are starting,
refresh, mirror continuous, mirror net-change, ending,
inactive, or unknown.
subscription status. The subscription status indicates
how replication is progressing. The subscription status
can be Normal, Error, or Unknown.
summarization. A method of applying data to a target
table where numeric data in the table is incremented or
decremented based on the type of row-level operation
(insert, update, or delete) applied to the table.
Summarization allows you to aggregate data without
having to define expressions that will maintain the
equivalent results.

system parameter. A setting that can be modified to

change a certain behavior of InfoSphere CDC.

table mapping. A component of a subscription that

connects a source replication object with a target
replication object and specifies communication paths,
such as queues or TCP/IP connections.

target database. A database to which replication

software applies changes captured from a source
database.

throughput. A measure of the rate at which data

changes are retrieved, sent, and applied on the target
system.

transaction consistency. While mirroring data,

transaction consistency is the guarantee that if part of a
transaction has been committed to the target database,
then all other in-scope operations from that source
transaction will have been committed as well.

transformation. The process of manipulating

replicated data from a source to a target.

Glossary 657
658 InfoSphere Change Data Capture Management Console: Administration Guide
Notices
This information was developed for products and services offered in the U.S.A.

IBM may not offer the products, services, or features discussed in this document in
other countries. Consult your local IBM representative for information on the
products and services currently available in your area. Any reference to an IBM
product, program, or service is not intended to state or imply that only that IBM
product, program, or service may be used. Any functionally equivalent product,
program, or service that does not infringe any IBM intellectual property right may
be used instead. However, it is the user's responsibility to evaluate and verify the
operation of any non-IBM product, program, or service.

IBM may have patents or pending patent applications covering subject matter
described in this document. The furnishing of this document does not grant you
any license to these patents. You can send license inquiries, in writing, to:

IBM Director of Licensing

IBM Corporation
North Castle Drive
Armonk, NY 10504-1785
U.S.A.

For license inquiries regarding double-byte (DBCS) information, contact the IBM
Intellectual Property Department in your country or send inquiries, in writing, to:

IBM World Trade Asia Corporation

Licensing 2-31 Roppongi 3-chome, Minato-ku
Tokyo 106-0032, Japan

The following paragraph does not apply to the United Kingdom or any other
country where such provisions are inconsistent with local law:
INTERNATIONAL BUSINESS MACHINES CORPORATION PROVIDES THIS
PUBLICATION AS IS WITHOUT WARRANTY OF ANY KIND, EITHER
EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
WARRANTIES OF NON-INFRINGEMENT, MERCHANTABILITY OR FITNESS
FOR A PARTICULAR PURPOSE. Some states do not allow disclaimer of express or
implied warranties in certain transactions, therefore, this statement may not apply
to you.

This information could include technical inaccuracies or typographical errors.

Changes are periodically made to the information herein; these changes will be
incorporated in new editions of the publication. IBM may make improvements
and/or changes in the product(s) and/or the program(s) described in this
publication at any time without notice.

Any references in this information to non-IBM Web sites are provided for
convenience only and do not in any manner serve as an endorsement of those Web
sites. The materials at those Web sites are not part of the materials for this IBM
product and use of those Web sites is at your own risk.

IBM may use or distribute any of the information you supply in any way it
believes appropriate without incurring any obligation to you.

Copyright IBM Corp. 2008, 2011 659

 Licensees of this program who wish to have information about it for the purpose
of enabling: (i) the exchange of information between independently created
programs and other programs (including this one) and (ii) the mutual use of the
information which has been exchanged, should contact:

IBM Canada Limited Office of the Lab Director

8200 Warden Avenue
Markham, Ontario
L6G 1C7
CANADA

Such information may be available, subject to appropriate terms and conditions,

including in some cases, payment of a fee.

The licensed program described in this information and all licensed material
available for it are provided by IBM under terms of the IBM Customer Agreement,
IBM International Program License Agreement, or any equivalent agreement
between us.

Any performance data contained herein was determined in a controlled

environment. Therefore, the results obtained in other operating environments may
vary significantly. Some measurements may have been made on development-level
systems and there is no guarantee that these measurements will be the same on
generally available systems. Furthermore, some measurements may have been
estimated through extrapolation. Actual results may vary. Users of this document
should verify the applicable data for their specific environment.

Information concerning non-IBM products was obtained from the suppliers of

those products, their published announcements or other publicly available sources.
IBM has not tested those products and cannot confirm the accuracy of
performance, compatibility or any other claims related to non-IBM products.
Questions on the capabilities of non-IBM products should be addressed to the
suppliers of those products.

All statements regarding IBM's future direction or intent are subject to change or
withdrawal without notice, and represent goals and objectives only.

All IBM prices shown are IBM's suggested retail prices, are current and are subject
to change without notice. Dealer prices may vary.

This information is for planning purposes only. The information herein is subject to
change before the products described become available.

This information contains examples of data and reports used in daily business
operations. To illustrate them as completely as possible, the examples include the
names of individuals, companies, brands, and products. All of these names are
fictitious and any similarity to the names and addresses used by an actual business
enterprise is entirely coincidental.

COPYRIGHT LICENSE:

This information contains sample application programs in source language, which

illustrate programming techniques on various operating platforms. You may copy,
modify, and distribute these sample programs in any form without payment to
IBM, for the purposes of developing, using, marketing or distributing application
programs conforming to the application programming interface for the operating

660 InfoSphere Change Data Capture Management Console: Administration Guide

 platform for which the sample programs are written. These examples have not
been thoroughly tested under all conditions. IBM, therefore, cannot guarantee or
imply reliability, serviceability, or function of these programs.

Each copy or any portion of these sample programs or any derivative work, must
include a copyright notice as follows:

(your company name) (year). Portions of this code are derived from IBM Corp.
Sample Programs. Copyright IBM Corp. _enter the year or years_. All rights
reserved.

If you are viewing this information softcopy, the photographs and color
illustrations may not appear.

Trademarks
The following terms are trademarks of International Business Machines
Corporation in the United States, other countries, or both:

AIX
DB2
DataStage
IBM
InfoSphere
iSeries
solidDB
System i
Transformation Server
z/OS
zSeries

Microsoft, Windows, Windows NT, and the Windows logo are trademarks of
Microsoft Corporation in the United States, other countries, or both.

Java and all Java-based trademarks are trademarks of Sun Microsystems, Inc. in the
United States, other countries, or both.

Linux is a trademark of Linus Torvalds in the United States, other countries, or

both.

UNIX is a registered trademark of The Open Group in the United States and other
countries.

Other company, product, or service names may be trademarks or service marks of

others.

Notices 661
662 InfoSphere Change Data Capture Management Console: Administration Guide



Printed in USA