Replication Guide71 PDF

® ®
IBM DB2 Universal Database

Replication Guide and Reference
Version 7
SC26-9920-00
® ®
IBM DB2 Universal Database
Replication Guide and Reference
Version 7
SC26-9920-00
Before using this information and the product it supports, be sure to read the general information under
“Appendix C. Notices” on page 403.
This document contains proprietary information of IBM. It is provided under a license agreement and is protected by
copyright law. The information contained in this publication does not include any product warranties, and any
statements provided in this manual should not be interpreted as such.
Order publications through your IBM representative or the IBM branch office serving your locality or by calling
1-800-879-2755 in the United States or 1-800-IBM-4YOU in Canada.
When you send information to IBM, you grant IBM a nonexclusive right to use or distribute the information in any
way it believes appropriate without incurring any obligation to you.
© Copyright International Business Machines Corporation 1994, 2000. All rights reserved.
US Government Users Restricted Rights – Use, duplication or disclosure restricted by GSA ADP Schedule Contract
with IBM Corp.
Contents
About this book . . . . . . . . . . ix Data distribution . . . . . . . . . 19
Who should read this book . . . . . . . x Data consolidation . . . . . . . . . 20
How this book is structured . . . . . . . x Update anywhere . . . . . . . . . 21
Conventions . . . . . . . . . . . . x Occasionally connected . . . . . . . 22
Terminology . . . . . . . . . . . . xi Examples of replication configurations . . . 24
How to read syntax diagrams . . . . . . xi Archiving audit information . . . . . 24
Road map . . . . . . . . . . . . xii Consolidating data from distributed
How to send your comments . . . . . . xiii databases . . . . . . . . . . . . 24
Distributing data to remote sites . . . . 25
What’s new . . . . . . . . . . . . xv Distributing IMS data to remote sites . . 27
Compatibility . . . . . . . . . . . xv Accessing data continuously . . . . . 28
What’s new for Version 7 . . . . . . . xv Replicating operational data to decision
DATALINK replication . . . . . . . xv support systems. . . . . . . . . . 29
Replication for AS/400 . . . . . . . xv Using target tables as sources of updates
Replication for UNIX, Windows, and (update anywhere) . . . . . . . . . 30
OS/2 . . . . . . . . . . . . . xvi Updating data on occasionally connected
What’s new for Version 6 . . . . . . . xvi systems . . . . . . . . . . . . 31
DB2 Satellite Edition . . . . . . . . xvi Retrieving data from a non-DB2
Database currency . . . . . . . . xvii distributed data store . . . . . . . . 32
Performance features . . . . . . . xviii Replicating operational data to a non-DB2
Integration with DB2 . . . . . . . xviii reports and query database . . . . . . 33
Part 1. Introduction . . . . . . . . 1 Chapter 3. Data replication scenario . . . 35

Before you begin . . . . . . . . . . 35
Planning this scenario. . . . . . . . . 36
Chapter 1. Overview of data replication . . 3
Replication source . . . . . . . . . 36
DB2 data replication components . . . . . 3
Replication target . . . . . . . . . 37
Control tables . . . . . . . . . . . 4
Replication options. . . . . . . . . 37
Logical servers . . . . . . . . . . 4
Setting up the replication environment for
Administration interfaces . . . . . . . 5
this scenario . . . . . . . . . . . . 38
Change-capture mechanisms . . . . . . 6
Step 1: Customize control tables . . . . 38
Apply program . . . . . . . . . . 7
Step 2: Define a replication source . . . 39
How the replication components
Step 3: Define a subscription set and a
communicate . . . . . . . . . . . 7
subscription-set member . . . . . . . 40
DB2 data replication concepts . . . . . . 10
Step 4: Configure the source database . . 43
Replication sources. . . . . . . . . 10
Step 5: Bind the Capture and Apply
Subscription sets and subscription-set
programs . . . . . . . . . . . . 43
members . . . . . . . . . . . . 11
Step 6: Create a password file . . . . . 44
Apply qualifier . . . . . . . . . . 13
Step 7: Replicate the scenario data . . . 45
Data manipulation . . . . . . . . . 13
Operating in a replication environment . . . 47
Target tables . . . . . . . . . . . 14
Step 1: Update the source table . . . . 47
Schedule for applying updates . . . . . 17
Step 2: Prune the control tables . . . . 48
Step 3: Stop the Capture and Apply
Chapter 2. Data replication configurations 19 programs . . . . . . . . . . . . 49
Overview of replication configurations . . . 19
© Copyright IBM Corp. 1994, 2000 iii

Chapter 4. Data replication tasks . . . . 51 Chapter 6. Setting up your replication
Planning your replication requirements . . . 51 environment . . . . . . . . . . . 93
Setting up your replication environment . . 53 Using the DB2 Control Center to set up
Setting up the system . . . . . . . . 53 replication . . . . . . . . . . . . 93
Setting up the replication criteria . . . . 53 Configuring the Control Center for host
Performing the initial replication . . . . 54 RDBMSs . . . . . . . . . . . . 94
Adding to your replication environment 55 Setting replication preferences in the DB2
Copying your replication environment . . 55 Tools Settings notebook . . . . . . . 95
Operating in your replication environment . . 55 Customizing CD table, index, and
tablespace names . . . . . . . . . 95
Part 2. Administration . . . . . . 59 Using the DB2 DataJoiner Replication
Administration tool to set up replication . . 96
Installing DJRA . . . . . . . . . . 98
Chapter 5. Planning for replication. . . . 61
Setting preferences . . . . . . . . . 99
Capacity planning . . . . . . . . . . 61
Customizing DJRA. . . . . . . . . 99
Storage planning . . . . . . . . . . 61
Defining replication control tables . . . . 100
Database log and journal data . . . . . 62
Creating replication control tables using
Active log file size for Capture for VSE
DJRA . . . . . . . . . . . . . . 102
and VM and current receiver size for
Customizing and running replication SQL
Capture for AS/400 . . . . . . . . 63
files . . . . . . . . . . . . . . 103
Target tables and control tables . . . . 63
Setting up security for replication . . . . 104
Spill files . . . . . . . . . . . . 65
Authorization requirements for
Network planning . . . . . . . . . . 65
administration . . . . . . . . . . 104
Connectivity . . . . . . . . . . . 65
Authorization requirements for running
Where to run the Apply program: push or
the Capture program. . . . . . . . 104
pull configuration . . . . . . . . . 66
Authorization requirements for running
Data blocking for large volumes of
the Apply program . . . . . . . . 105
changes . . . . . . . . . . . . 68
Defining replication sources . . . . . . 105
Deciding what to replicate . . . . . . . 69
Defining replication sources for
Subsetting columns and rows . . . . . 70
update-anywhere replication . . . . . 106
Replicating joins using views . . . . . 71
Detecting conflicts . . . . . . . . 107
Replicating before and after images . . . 72
Defining views as replication sources . . 108
Renaming columns. . . . . . . . . 73
Enabling replication logical-partitioning-
Creating computed columns . . . . . 74
key support . . . . . . . . . . . 109
Using stored procedures for before and
Defining CCD tables . . . . . . . . . 111
after run-time processing. . . . . . . 74
Defining replication subscription sets . . . 112
Replicating large objects . . . . . . . 74
Defining subscription sets for
Replicating DATALINK values . . . . . 75
update-anywhere replication . . . . . 114
Key-update restrictions . . . . . . . 76
Choosing a target-table type . . . . . 115
General restrictions for replication . . . 77
Defining the target-table structure:
Capture triggers for non-IBM sources . . . 80
columns and rows . . . . . . . . 116
How the Capture triggers capture the data
Defining a subscription set with a
changes . . . . . . . . . . . . 80
user-defined table . . . . . . . . . 119
Capture Triggers and pre-existing triggers 81
Defining SQL statements or stored
Staging data . . . . . . . . . . . . 82
procedures for the subscription set . . . 121
Attributes of CCD tables . . . . . . . 82
Data-sharing considerations . . . . . 122
Using CCD tables as replication sources. . 84
Specifying a data-blocking value . . . . 122
Pruning the CD and CCD tables . . . . 88
Data currency requirements . . . . . 123
Auditing data usage . . . . . . . . . 88
Data consistency requirements . . . . 125
Planning for migration . . . . . . . . 89
Maintaining external CCD tables. . . . 126
iv DB2 Replication Guide and Reference

Loading target tables offline using DJRA . . 127 Problem determination for the Capture
Copying your replication configuration to program . . . . . . . . . . . . . 156
another system. . . . . . . . . . . 127 Capture-program trace table . . . . . 157
Setting up the Capture program . . . . . 128 Capture-program trace file . . . . . . 157
Specifying tuning parameters for the Capture-program log file . . . . . . 158
Capture program . . . . . . . . . 128 Other problem-determination facilities for
Restrictions when running the Capture the Capture program. . . . . . . . 158
program . . . . . . . . . . . . 130 Problem determination for AS/400 . . . . 159
Setting up the Apply program . . . . . 131 Gathering information about active jobs 159
Refreshing target tables with the Determining if the journal job is started 160
ASNLOAD exit routine . . . . . . . 131 Collecting data for problem determination 160
Using the ASNDONE exit routine . . . 132 Using the Replication Analyzer . . . . . 163
Using the ASNDLCOPY exit routine . . 133 Troubleshooting . . . . . . . . . . 166
Using the ASNDLCOPYD file-copy Problem-source identification questions . . 171
daemon . . . . . . . . . . . . 136
Setting up DB2 DataJoiner . . . . . . . 137 Part 3. Operations . . . . . . . 173
Chapter 7. Operating DB2 DataPropagator 139
Chapter 9. Capture and Apply for AS/400 175
Operating the Capture program . . . . . 139
Coexistence considerations . . . . . . . 175
Before you start the Capture program . . 139
Setting up the Capture and Apply programs 176
Starting or restarting the Capture
Installing DB2 DataPropagator for AS/400 176
program . . . . . . . . . . . . 140
Connecting to an AS/400 server . . . . 176
Operating the Apply program . . . . . 142
Verifying and customizing your
Improving Apply performance for Sybase or
installation of DB2 DataPropagator for
Microsoft SQL Server . . . . . . . . 144
AS/400 . . . . . . . . . . . . 177
Performing regular database maintenance 145
Specifying tuning parameters for Capture
Monitoring the replication environment . . 146
for AS/400 . . . . . . . . . . . 178
Resolving gaps between source and target
Authorization requirements for running the
tables . . . . . . . . . . . . . . 147
Capture and Apply programs . . . . . . 181
Modifying your replication configuration 147
Granting authority . . . . . . . . 181
Viewing or changing existing replication
Revoking authority . . . . . . . . 189
sources . . . . . . . . . . . . 147
Restrictions for running the Capture
Removing replication sources . . . . . 148
program . . . . . . . . . . . . . 190
Activating and deactivating subscription
The journal . . . . . . . . . . . . 191
sets . . . . . . . . . . . . . 148
Remote journal function . . . . . . 192
Cloning a subscription set to another
Creating journals for source tables . . . 192
server . . . . . . . . . . . . . 148
Managing journals and journal receivers 193
Viewing or changing an existing
Defining replication sources and subscription
subscription set . . . . . . . . . 149
sets . . . . . . . . . . . . . . 196
Removing subscription sets . . . . . 149
Using a relative record number (RRN) as a
primary key . . . . . . . . . . . 196
Chapter 8. Problem determination . . . 151 Operating Capture for AS/400 . . . . . 197
Problem determination scenario . . . . . 152 Starting Capture for AS/400 . . . . . 197
Problem determination for replication Determining the progress of the Capture
administration . . . . . . . . . . . 152 program . . . . . . . . . . . . 201
Problem determination for the Apply Scheduling Capture for AS/400 . . . . 202
program . . . . . . . . . . . . . 153 Stopping Capture for AS/400 . . . . . 202
Apply trail table . . . . . . . . . 153 Reinitializing Capture for AS/400 . . . 203
Apply-program trace file . . . . . . 155
Apply-program log file . . . . . . . 156
Contents v
Pruning the change data and unit-of-work User ID requirements for running the
tables and minimizing source server Capture and Apply programs . . . . . . 239
DASD usage . . . . . . . . . . 204 Setting up the Capture and Apply programs 239
Warm and cold starts . . . . . . . 205 Configuring the Capture program for
How the Capture program processes journal UNIX platforms . . . . . . . . . 239
entry types . . . . . . . . . . . . 205 Optional: Configuring the Apply program
Operating Apply for AS/400 . . . . . . 207 manually for UNIX platforms . . . . . 240
Creating packages to use with remote Other configuration considerations for
systems . . . . . . . . . . . . 208 UNIX-based components . . . . . . 241
Before you start the Apply program . . 210 Setting up end-user authentication at the
Starting Apply for AS/400 . . . . . . 210 source server . . . . . . . . . . 241
Scheduling Apply for AS/400 . . . . . 217 Operating Capture for UNIX platforms . . 243
Stopping Apply for AS/400 . . . . . 217 Restrictions for running the Capture
Additional Apply program operations . . . 220 program . . . . . . . . . . . . 243
Using the ASNDONE exit routine for Scheduling Capture for UNIX platforms 244
AS/400 . . . . . . . . . . . . 220 Setting environment variables for Capture
Refreshing target tables with the for UNIX platforms . . . . . . . . 244
ASNLOAD exit routine for AS/400 . . . 221 Starting Capture for UNIX platforms . . 244
Stopping Capture for UNIX platforms 247
Chapter 10. Capture and Apply for OS/390 225 Suspending Capture for UNIX platforms 247
Setting up the Capture and Apply programs 225 Resuming Capture for UNIX platforms 248
Applying DB2 maintenance . . . . . 225 Reinitializing Capture for UNIX platforms 248
Installing Capture and Apply for OS/390 225 Pruning the change data and unit-of-work
Configuring Capture and Apply for tables . . . . . . . . . . . . . 249
OS/390 after installing a new release of Displaying captured log progress . . . 249
DB2 . . . . . . . . . . . . . 226 Operating Apply for UNIX platforms . . . 250
Operating Capture for OS/390 . . . . . 227 Before you start the Apply program . . 250
Restrictions for running the Capture Starting Apply for UNIX platforms . . . 251
program . . . . . . . . . . . . 227 Scheduling Apply for UNIX platforms 254
Starting Capture for OS/390 . . . . . 227 Stopping Apply for UNIX platforms . . 254
Scheduling Capture for OS/390 . . . . 229
Stopping Capture for OS/390 . . . . . 230 Chapter 12. Capture for VM and Capture
Suspending Capture for OS/390 . . . . 230 for VSE . . . . . . . . . . . . . 255
Resuming Capture for OS/390 . . . . 230 Setting up the Capture program . . . . . 255
Reinitializing Capture for OS/390 . . . 230 Operating Capture for VM and Capture for
Pruning the change data and unit-of-work VSE . . . . . . . . . . . . . . 255
tables . . . . . . . . . . . . . 231 Restrictions for running the Capture
Displaying captured log progress . . . 231 program . . . . . . . . . . . . 255
Operating Apply for OS/390 . . . . . . 231 Starting Capture for VM and VSE . . . 256
Starting Apply for OS/390 . . . . . . 232 Stopping Capture for VM and VSE . . . 258
Scheduling Apply for OS/390. . . . . 234 Suspending Capture for VM and VSE . . 259
Stopping Apply for OS/390 . . . . . 234 Resuming Capture for VM and VSE . . 259
Rules for index types . . . . . . . . 234 Reinitializing Capture for VM and VSE 260
Using the DB2 ODBC Catalog . . . . . 235 Pruning the change data and unit-of-work
Setting up the DB2 ODBC Catalog . . . 235 tables . . . . . . . . . . . . . 260
DB2 ODBC Catalog tables . . . . . . 237 Displaying captured log progress . . . 261
Chapter 11. Capture and Apply for UNIX Chapter 13. Capture and Apply for
platforms . . . . . . . . . . . . 239 Windows and OS/2 . . . . . . . . . 263
vi DB2 Replication Guide and Reference

User ID requirements for running the DataPropagator for Microsoft Jet control
Capture and Apply programs . . . . . . 263 tables . . . . . . . . . . . . . 289
Setting up the Capture and Apply programs 263
Configuring the Capture program for Part 4. Reference information 291
Windows and OS/2 . . . . . . . . 263
Optional: Configuring the Apply program
Chapter 14. Table structures . . . . . 293
manually for Windows and OS/2 . . . 264
Tables at a glance . . . . . . . . . . 293
Setting up end-user authentication at the
List of tables used at the source server . . . 296
source server . . . . . . . . . . 265
List of tables used at the control server . . 298
Setting up the NT Service Control
List of tables used at the target server . . . 299
Manager . . . . . . . . . . . . 266
Tables used at the source server . . . . . 300
Operating Capture for Windows and
Register table . . . . . . . . . . 301
Capture for OS/2 . . . . . . . . . . 268
Register extension table for AS/400 . . . 308
Restrictions for running the Capture
Pruning control table. . . . . . . . 309
program . . . . . . . . . . . . 268
Tuning parameters table . . . . . . 312
Setting environment variables for Capture
Capture enqueue table (VM and VSE
for Windows and OS/2 . . . . . . . 268
specific) . . . . . . . . . . . . 313
Starting Capture for Windows and OS/2 269
Warm start table . . . . . . . . . 313
Scheduling Capture for Windows and
Critical section table . . . . . . . . 315
OS/2 . . . . . . . . . . . . . 271
Prune lock table . . . . . . . . . 316
Stopping Capture for Windows and OS/2 271
Trace table . . . . . . . . . . . 316
Suspending Capture for Windows and
Apply-qualifier-cross-reference table
OS/2 . . . . . . . . . . . . . 272
(AS/400 specific) . . . . . . . . . 317
Resuming Capture for Windows and
Register synchronization table . . . . 318
OS/2 . . . . . . . . . . . . . 273
Unit-of-work table . . . . . . . . 319
Reinitializing Capture for Windows and
Change data table. . . . . . . . . 321
OS/2 . . . . . . . . . . . . . 273
Tables used at the control server . . . . . 323
Pruning the change data and unit-of-work
Subscription set table . . . . . . . 323
tables . . . . . . . . . . . . . 274
Subscription-targets-member table . . . 326
Displaying captured log progress . . . 274
Subscription columns table. . . . . . 329
Operating Apply for Windows and OS/2 275
Subscription statements table . . . . . 331
Before you start the Apply program . . 275
Row-replica-target-list table (Microsoft Jet
Starting Apply for Windows and OS/2 275
specific) . . . . . . . . . . . . 333
Scheduling Apply for Windows and OS/2 278
Subscription-schema-changes table
Stopping Apply for Windows and OS/2 278
(Microsoft Jet specific) . . . . . . . 334
Replicating on demand (Windows 32–bit
Subscription events table . . . . . . 335
operating systems only). . . . . . . . 279
Apply trail table . . . . . . . . . 336
Using DB2 DataPropagator for Microsoft Jet 280
Apply job table (AS/400 specific) . . . 340
The advantages of using DataPropagator
Tables used at the target server . . . . . 341
for Microsoft Jet . . . . . . . . . 281
User copy table . . . . . . . . . 341
Data integrity considerations . . . . . 282
Point-in-time table . . . . . . . . 342
Terminology for DataPropagator for
Consistent-change-data table . . . . . 343
Microsoft Jet replication . . . . . . . 282
Replica table . . . . . . . . . . 345
Setting up DataPropagator for Microsoft
Base aggregate table . . . . . . . . 345
Jet replication . . . . . . . . . . 283
Change aggregate table . . . . . . . 346
Operating DataPropagator for Microsoft
Row-replica table (Microsoft Jet specific) 347
Jet . . . . . . . . . . . . . . 285
Conflict table (Microsoft Jet specific) . . 348
Returning control to users with the
Error information table (Microsoft Jet
ASNJDONE exit routine . . . . . . 287
specific) . . . . . . . . . . . . 348
Contents vii
Error messages table (Microsoft Jet Starting the Capture program using a
specific) . . . . . . . . . . . . 349 routine . . . . . . . . . . . . . 397
Error-side-information table (Microsoft Jet Starting the Apply program using a routine 398
specific) . . . . . . . . . . . . 349 Sample routine that starts the Capture and
Key string table (Microsoft Jet specific) 349 Apply programs . . . . . . . . . . 398
Synchronization generations table
(Microsoft Jet specific) . . . . . . . 350 Appendix B. Education and services for
DB2 data replication . . . . . . . . 401
Chapter 15. Capture and Apply messages 353 Services . . . . . . . . . . . . . 401
Capture program messages . . . . . . 353 Education . . . . . . . . . . . . 401
Apply program messages . . . . . . . 368
Appendix C. Notices . . . . . . . . 403
Chapter 16. Replication messages for Programming interface information . . . . 404
AS/400 . . . . . . . . . . . . . 381 Trademarks . . . . . . . . . . . . 404
Apply for AS/400 messages . . . . . . 381 Trademarks of other companies . . . . . 405
Capture for AS/400 messages . . . . . . 386
Other replication messages for AS/400. . . 390 Glossary . . . . . . . . . . . . 407
Part 5. Appendixes . . . . . . . 395 Index . . . . . . . . . . . . . 415
Appendix A. Starting the Capture and Contacting IBM . . . . . . . . . . 429

Apply programs from within an Product information . . . . . . . . . 429
application . . . . . . . . . . . 397
viii DB2 Replication Guide and Reference

About this book
This book introduces the concepts of DB2® data replication, and it describes
how to plan, configure, and administer a replication environment.
The DB2 DataPropagator™ product is the focus of the book. You can use it
with other products in the IBM® replication solution to tailor a replication
environment that suits your business needs.
You can replicate data from DB2 sources to DB2 targets. You can also replicate
data between DB2 and non-IBM sources and targets. Specifically, you can use
the following database management systems as sources, targets, or both:
DB2 servers Non-IBM servers

™ ®
DB2 Universal Database for AIX Informix®2
DB2 Universal Database for AS/400® Microsoft® Access3
DB2 Universal Database for HP-UX® Microsoft Jet3
DB2 Universal Database for OS/2® Microsoft SQL Server2
DB2 Universal Database Server for Oracle®2
OS/390®
DB2 Universal Database for Solaris™ Sybase®2
DB2 Universal Database for Linux® Sybase SQL Anywhere™2
DB2 Universal Database for NUMA-Q® Teradata®4
DB2 Universal Database for VM1
DB2 Universal Database for VSE1
DB2 Universal Database for Windows®
32–bit operating systems (such as Windows
95, 98 and NT®)
© Copyright IBM Corp. 1994, 2000 ix

Who should read this book
This book is written for database administrators, LAN administrators, and
others who must set up and maintain a data replication environment. It
assumes that you are familiar with standard database terminology, that you
have experience with database design and database administration, and that
you understand your applications and the data that you want to replicate.
How this book is structured

This book consists of the following parts:
Part 1: Introduction
Introduces the DB2 replication concepts and components, describes
the typical replication configurations, guides you through a simple
replication scenario using the DB2 Control Center, and outlines the
major replication tasks that are described in the book.
Part 2: Administration
Describes how to plan, set up, run, and maintain your replication
environment.
Part 3: Operations
Describes how to use DB2 data replication in particular operating
systems.
Part 4: Reference information
Provides reference information for control table structures (which are
relational database tables that DB2 DataPropagator uses during its
replication process), and messages.
Conventions
This book uses these highlighting conventions:
v Boldface type indicates commands or user interface controls such as names
of fields, folders, icons, or menu choices.
v Monospace type indicates examples of text that you enter exactly as shown.
v Italic type indicates variables that you should replace with a value. It is also
used to indicate book titles and for emphasis of words.
1. There is no Apply program for these products.

2. These products require DB2 DataJoiner® V2 or later and the DB2 DataJoiner Replication Administration (DJRA)
tool.
3. These products require DJRA.
4. There is no Capture program for this product.
x DB2 Replication Guide and Reference

Terminology
This book uses standard terminology for database, copying, and LAN
concepts. “Chapter 1. Overview of data replication” on page 3 explains many
concepts used in this book. For definitions of replication terms, see “Glossary”
on page 407.
How to read syntax diagrams

The following rules apply to the syntax diagrams used in this book:
v Read the syntax diagrams from left to right, from top to bottom, following
the path of the line.
The ─── symbol indicates the beginning of a statement.
The ─── symbol indicates that the statement syntax is continued on the
next line.
The ─── symbol indicates that a statement is continued from the previous
line.
The ─── symbol indicates the end of a statement.
Diagrams of syntactical units other than complete statements start with the
─── symbol and end with the ─── symbol.
v Keywords, their allowable synonyms, and reserved parameters, are either
shown in uppercase or lowercase, depending on the operating system.
These items must be entered exactly as shown. Variables appear in
lowercase italics (for example, column-name). They represent user-defined
parameters or suboptions.
When entering commands, separate the parameters and keywords by at
least one space if there is no intervening punctuation.
v Enter punctuation marks (slashes, commas, periods, parentheses, quotation
marks, equal signs, and so on) and numbers exactly as given.
v Footnotes are shown by a number in parentheses, for example, (1).
v Required items appear on the horizontal line (the main path).
required_item
v Optional items appear below the main path.

required_item
optional_item
v If you can choose from two or more items, they appear vertically, in a stack.
If you must choose one of the items, one item of the stack appears on the
main path.
About this book xi

required_item required_choice1
required_choice2
If choosing one of the items is optional, the entire stack appears below the
main path.
required_item
optional_choice1
optional_choice2
Road map
If you want to ... Refer to ...

Learn about the IBM data DB2 DataPropagator at
replication solution http://www.ibm.com/software/data/dpropr/
Data replication solution at

http://www.ibm.com/software/data/dbtools/datarepl.html
Database and data management at

http://www.ibm.com/software/data/
Learn about last-minute changes to The Installation Notes on the CD-ROM or the Release Notes that
the product are installed with the products.
Learn what’s new this release in “What’s new” on page xv.
DB2 data replication
Learn about the components of “Chapter 1. Overview of data replication” on page 3.
DB2 data replication
Learn about DB2 data replication “Chapter 1. Overview of data replication” on page 3.
concepts
Learn about typical replication “Chapter 2. Data replication configurations” on page 19.
configurations
Work through a simple replication “Chapter 3. Data replication scenario” on page 35.
scenario using the DB2 Control
Center on Windows NT
Get an overview of the types of “Chapter 4. Data replication tasks” on page 51.
replication tasks that you can
perform
Design and plan your replication “Chapter 5. Planning for replication” on page 61.
environment
Migrate from earlier versions of The online Migration Guide, which is on the DataPropagator Web
DPROPR to DB2 DataPropagator site: http://www.ibm.com/software/data/dpropr/
xii DB2 Replication Guide and Reference

If you want to ... Refer to ...
Read customer case studies The Case studies page of the DataPropagator Web site:
http://www.ibm.com/software/data/dpropr/
Set up your replication “Chapter 6. Setting up your replication environment” on page 93.
environment
Set up replication preferences in See the DJRA online help.
DJRA
Set replication preferences in the DB2 Control Center online help.
DB2 Control Center
Define and manage replication “Part 2. Administration” on page 59.
sources and targets
Configure and operate the Capture “Part 3. Operations” on page 173; see the chapter for a particular
and Apply programs operating system.
Learn about and run DB2 “Using DB2 DataPropagator for Microsoft Jet” on page 280.
DataPropagator for Microsoft Jet
Learn about data replication DB2 Universal Database Administering Satellites Guide and Reference.
support for satellites
Learn about the relational database “Chapter 14. Table structures” on page 293.
tables that control the DB2
replication process
Debug error messages for the “Troubleshooting” on page 166, and “Chapter 15. Capture and
Capture and Apply programs Apply messages” on page 353.
Find out about other DB2 The Information Center, which is available on all platforms on
information which the DB2 administration tools are available. Depending on
your system, you can access the Information Center from one of the
following places:
v Main product folder
v Toolbar in the Control Center
v Windows Start menu
v Help menu of the Control Center
How to send your comments

Your feedback helps IBM to provide quality information. Please send any
comments that you have about this book or other DB2 DataPropagator
documentation. You can use any of the following methods to provide
comments:
v Send your comments from the Web. Visit the Web site at:
http://www.ibm.com/software/data/dpropr/
The Web site has a feedback page that you can use to enter and send
comments.
About this book xiii

v Send your comments by e-mail to [email protected]. Be sure to
include the name of the product, the version number of the product, and
the name and part number of the book (if applicable). If you are
commenting on specific text, please include the location of the text (for
example, a chapter and section title, a table number, a page number, or a
help topic title).
xiv DB2 Replication Guide and Reference

What’s new
This section introduces the major features of DB2 DataPropagator for the two
most recent versions, 6 and 7. For Version 7 (V7), see “What’s new for Version
7”; for Version 6 (V6), see “What’s new for Version 6” on page xvi.
Compatibility
All releases of DB2 DataPropagator Relational Version 1 (DPropR V1) are not
compatible with this product. If you currently use DPropR V1, see “Planning
for migration” on page 89 for instructions on upgrading.
What’s new for Version 7

This section introduces the major features of DB2 DataPropagator Version 7
(V7), which are described in more detail in this book.
v “DATALINK replication”
v “Replication for AS/400”
v “Replication for UNIX, Windows, and OS/2” on page xvi
DATALINK replication
DB2 Universal Database provides a DATALINK data type that allows the
database to control access, integrity, and recovery for external files. DB2
DataPropagator V7 replicates DATALINK columns, but does not replicate the
external files to which the DATALINK columns point. To replicate the files,
the Apply program uses a user exit routine. See “Replicating DATALINK
values” on page 75 for more information about DATALINK support.
Replication for AS/400
DB2 Universal Database for AS/400 now supports:
v Replication of large objects (LOBs). See “Replicating large objects” on
page 74 for more information about LOB support.
v Replication of BIGINT data types.
v Replication of DATALINK data types.
The following features were added to improve the performance of your

AS/400 replication environment:
v The DPRVSN parameter lets you specify which version of the control tables
to create: Version 5 or Version 7.
v The STRDPRAPY command has a new parameter, GENCDROW. The
GENCDROW parameter is equivalent to the CHGONLY parameter that is
© Copyright IBM Corp. 1994, 2000 xv

used on the other platforms. For more information about the GENCDROW
parameter, see “Starting Capture for AS/400” on page 197.
v The STRDPRCAP command has two new parameters, DELAY and
RTYWAIT. The DELAY parameter specifies the time delay (in seconds) at
the end of each Apply program cycle when continuous replication is used.
RTYWAIT specifies in seconds how long the Apply program should wait
after it encounters an error before it retries the operation that failed.
Replication for UNIX, Windows, and OS/2
DB2 DataPropagator Version 7 is available for Linux and NUMA-Q operating
systems.
On Windows 32-bit operating systems, you can start the Capture and Apply
programs on demand using the ASNSAT command. For information about
this command, see “Replicating on demand (Windows 32–bit operating
systems only)” on page 279.
You can start both the Capture and Apply programs from within an
application by using the new asnCapture and asnApply application
programming interfaces. For information about these interfaces, see
“Appendix A. Starting the Capture and Apply programs from within an
application” on page 397.
What’s new for Version 6

This section introduces the major features of DB2 DataPropagator Version 6
(V6), most of which are described in more detail in this book.
v “DB2 Satellite Edition”
v “Database currency” on page xvii
v “Performance features” on page xviii
v “Integration with DB2” on page xviii
DB2 Satellite Edition
DB2 Universal Database Satellite Edition (DB2 Satellite Edition) brings the
power of DB2 Universal Database to environments containing occasionally
connected clients. It is supported on Windows 32–bit operating systems.
With DB2 Satellite Edition, you can replicate data between DB2 servers and
some non-IBM source servers (Oracle, Sybase, Informix, Microsoft), and you
gain the following benefits:
v Centralized group administration and problem determination
v Ability to easily support thousands of occasionally connected clients
v Capture and Apply programs that start and stop automatically, as required
xvi DB2 Replication Guide and Reference

Two new options let you run the Capture and Apply programs in batch
mode:
Capture program AUTOSTOP option
You can run the Capture program in batch mode by using the new
AUTOSTOP invocation parameter. The Capture program will run until
it captures all of the changes from the log and then it terminates.5
Apply program COPYONCE option
You can run the Apply program in batch mode by using the new
COPYONCE invocation parameter. The Apply program will try to run
all eligible subscription sets one time and then it will terminate.6
Database currency
DB2 replication now provides:
LOB support
You can use DB2 DataPropagator to replicate columns with
large-object (LOB) data. The Capture program flags information about
changed LOB data, but does not copy the LOB data to staging tables.
The Apply program copies changed LOB data directly from the source
table to the target table. You can replicate LOB data between DB2 for
OS/390 servers or between DB2 Universal Database servers for UNIX,
Windows, and OS/2 operating systems. If you have DB2 Connect™
Version 6, you can also copy LOB data between DB2 for OS/390 and
DB2 Universal Database servers for UNIX, Windows, and OS/2
operating systems.
ROWID support
DB2 for OS/390 V6 allows you to generate a unique identifier for
each row in a table and store that identifier in a ROWID column.
Using the ROWID, you can access a particular row without needing to
access an index or scan the table space. Usually a ROWID identifies a
row in the table that has the ROWID defined. However, by copying
ROWID values from the source table to set the target rows with the
same ROWID values, you can use the same ROWID value to identify
both the source and target row.
Version-independent capture
The Capture program can read the log for DB2 for MVS/ESA V4, DB2
for OS/390 V5, or DB2 for OS/390 V6. Therefore you can run
different versions of DB2 in a data-sharing environment, for example
during version-to-version migration, and have one Capture program
continue to capture transaction-consistent data.
5. The Capture program AUTOSTOP option is not available on the Capture program for AS/400.
6. The Apply program COPYONCE option is not available on the Apply program for AS/400.
What’s new xvii

ODBC support
This feature was added in DB2 for OS/390 V5 and updated in V6 to
support a new catalog table (SQLProcedureColumns).
Unicode support
DB2 DataPropagator for UNIX, Windows, and OS/2 operating
systems supports unicode.
Port to Linux
DB2 DataPropagator V6 runs on the Linux operating system.
Performance features
The following features were added to improve the performance of your
replication environment:
Option to capture only columns that are available for replication
You can start the Capture program using the CHGONLY parameter if
you want to capture changes only for those columns that you marked
available for replication. By default, the Capture program captures
changes that are made to the source table data for all columns.
Capture program sleeptime option
You can use the SLEEP=N invocation parameter to indicate how long
you want the Capture program to sleep before it reads the log again,
after it reaches the end of the log. To save on CPU, the Capture
program will sleep if no data is returned on the log. This parameter is
supported for DB2 for MVS™ 4.1 and later with data sharing. If you
use the SLEEP=N parameter with data sharing, and only a small
amount of data is returned, then the Capture will sleep for N seconds.
Continuous block fetch by the Apply program
The Apply program uses DB2 continuous block fetch to improve
data-transfer rates and overall performance for replicating data from
DB2 for OS/390 to other operating systems.
Automated use of RUNSTATS utility
For DB2 DataPropagator on UNIX, Windows, and OS/2 operating
systems, the RUNSTATS utility is run automatically after the Apply
program completes a full-refresh copy to the target tables. This utility
collects new statistics on the target tables and their indexes.
Integration with DB2
The replication components are integrated with DB2 Universal Database more
closely than before.
DB2 DataPropagator for OS/390 feature
When you order DB2 for OS/390 V6, you also receive a free trial
version of DB2 DataPropagator for OS/390. This trial version has all
the features and functions of the standard product. You can use the
trial version for 90 days without paying a licensing charge. After the
xviii DB2 Replication Guide and Reference

trial period ends, you must order a license for the DB2
DataPropagator priced feature to continue using the product.
Integrated installation for OS/390
You can install DB2 DataPropagator for OS/390 V6 using the DB2
Installer interface. The DB2 Installer is a workstation-based tool that
provides an easy-to-read map for the entire installation process. The
status of a task is denoted by the changed icons on the windows.
Help text is provided for each field, and ″Guide Me″ help text is
provided for each window.
Control Center
A Java® version of the DB2 Control Center is available that you can
use to perform administration tasks from a Web browser. It includes
improved support for administering replication environments for DB2
for OS/390. For more information about this new interface, see the
DB2 Universal Database documentation.
DataJoiner Replication Administration tool
The DataJoiner Replication Administration (DJRA) tool comes with
DB2 Universal Database and it runs on Windows 95, Windows 98, and
Windows NT operating systems. With DJRA, you can perform
administration tasks for replication configurations involving DB2
databases, non-IBM databases, or both. Using DJRA, you can easily
promote (copy) your replication criteria from one environment to
another. You can also start a replication monitor to help you monitor
replication activity and produce periodic reports about that activity. If
your files are stored on the AS/400 platform, you can use DJRA to
automatically generate relative record numbers (RRN) for replication
sources so that you can replicate data without user-defined unique
keys. The details about these and other benefits of DJRA are
documented in this book.
What’s new xix

xx DB2 Replication Guide and Reference
Part 1. Introduction
This part of the book contains the following chapters:
“Chapter 1. Overview of data replication” on page 3 describes the DB2 data

replication components and concepts.
“Chapter 2. Data replication configurations” on page 19 describes the basic

replication configurations and how to build on them with DB2 replication.
“Chapter 3. Data replication scenario” on page 35 lists steps that you can
follow to use the DB2 Control Center and the Capture and Apply programs to
perform a simple replication scenario on sample data in DB2 for Windows
NT.
“Chapter 4. Data replication tasks” on page 51 introduces the tasks that you
perform at various stages of the replication process.
© Copyright IBM Corp. 1994, 2000 1

2 DB2 Replication Guide and Reference
Chapter 1. Overview of data replication
Replication is a process of maintaining a defined set of data in more than one
location. It involves copying designated changes from one location (a source)
to another (a target), and synchronizing the data in both locations. The source
and target can be in logical servers (such as a DB2 database or a DB2 for
OS/390 subsystem or data-sharing group) that are on the same machine or on
different machines in a distributed network.
A number of IBM products enable you to replicate data. The product that is
the focus of this book—DB2 DataPropagator—is a replication product for
relational data. You can use it to replicate changes between any DB2 relational
databases. You can also use it with other IBM products (such as DB2
DataJoiner and IMS DataPropagator) or non-IBM products (such as Microsoft
SQL Server and Sybase SQL Server) to replicate data between a growing
number of database products—both relational and nonrelational.
The replication environment that you need depends on when you want data
updated and how you want transactions handled. You have the flexibility to
choose the locations of the replication components to maximize the efficiency
of your replication environment.
Before you go to Chapter 2 and begin designing your replication environment,

read this chapter to familiarize yourself with the DB2 replication components
and their associated concepts.
DB2 data replication components

DB2 DataPropagator consists of three main components: administration
interfaces, change-capture mechanisms, and the Apply program.
v You use the administration interfaces to create control tables, which store
your replication criteria.
v After you set up your replication environment, the change-capture
mechanism captures changes as they occur in the source database and
stores them temporarily in tables.
v The Apply program reads the tables and applies these changes to target
databases, or copies data directly from the source database to the target
databases.
This section describes the control tables that manage replication requests, the
logical servers that contain the replication components, as well as the main

components (administration interfaces, change-capture mechanisms, and the
Apply program) and how they communicate with each other.
Control tables
The replication components use control tables to communicate with each other
and to manage replication tasks (such as managing replication sources and
targets, capturing changes, replicating changes, and tracking how many
changes are replicated and how many remain to be done).
The change-capture mechanisms use the following control tables: register

table, unit-of-work table, pruning control table, prune lock table, critical
section table, warm start table, tuning parameters table, and change data
tables. For additional control tables that are platform-specific, see “Chapter 14.
Table structures” on page 293.
The Apply program uses the following control tables: Apply trail table, critical
section table, pruning control table, prune lock table, register table,
subscription set table, subscription statements table, subscription events table,
subscription-targets-member table, subscription columns table, unit-of-work
table, and change data tables.
Logical servers
All the replication components reside on a logical server. In this book, logical
servers refer to databases, not to servers in the client/server sense. For the
OS/390 operating system, logical servers are equivalent to subsystems or
data-sharing groups (that is, the domain of a single database catalog). There are
three types of logical servers:
Source server
The source server contains the change-capture mechanism, the source
tables that you want to replicate, and the control tables for the
Capture program that are also used by the Apply program.7
Target server
The target server contains the target tables.
Control server
The control server contains control tables for the Apply program.
The Apply program can reside on any of the logical servers in the network. It
uses distributed DB2 technology to connect to the control, source, and target
servers.
7. If you use the remote journal set up on DPROPR/400, the source server will not contain the source tables that you
want to replicate. For more information about the remote journal set up, see “The journal” on page 191.

Each Apply program is associated with one control server, which you specify
when you start the Apply program. Multiple Apply programs can share a
control server.
Administration interfaces
You use the administration interfaces to create control tables, which store your
replication criteria. Two user interfaces are available: DB2 Control Center and
DataJoiner Replication Administration (DJRA).
DB2 Control Center

The DB2 Control Center is a database administration tool that you can use to
administer the replication of data between DB2 servers. It automates many
initialization functions, such as creating target tables and control tables when
you specify target information.
You can use the Control Center to perform the following administration tasks
for replication:
v Define DB2 tables and DB2 views as replication sources.
v Define or remove subscription sets.
v Add subscription-set members to existing subscription sets.
v Remove subscription-set members from existing subscription sets.
v Remove replication sources.
v Clone subscription sets to other servers.
v Activate and deactivate subscription sets.
v Add or delete a call to a procedure or a SQL statement that runs before or
after data is replicated.
DataJoiner Replication Administration (DJRA)

The DataJoiner Replication Administration (DJRA) tool is a database
administration tool that you can use to perform various replication
administration tasks. You can use this tool for DB2-to-DB2 replication;
however, you must use it if your replication environment includes non-IBM
databases.
You can use DJRA to perform the following administration tasks:

v Create the control tables and put them on your source, target, and control
servers.
v Define DB2 tables, non-DB2 tables, non-IBM tables, and DB2 views as
replication sources.
v Alter the definitions for existing DB2 source and target tables to add new
columns.
v Remove replication sources.
v Define or remove subscription sets.
Chapter 1. Overview of data replication 5

v Add subscription-set members to existing subscription sets.
v Remove subscription-set members from existing subscription sets.
v Add or delete SQL statements or called procedures that run before or after
data is replicated.
v Monitor the replication process.
v Copy your replication environment to another system using the promote
functions.
v Load target tables off-line.
v Activate or deactivate subscription sets.
Change-capture mechanisms
The DB2 data replication solution offers these mechanisms for capturing data:
v The Capture program for DB2 source tables.
v Capture triggers for source tables in non-IBM databases, except Teradata,
Microsoft Access, and Microsoft Jet.
The following sections describe the Capture program and triggers. For more
information about how changes are replicated in Microsoft Access and
Microsoft Jet databases, see “Using DB2 DataPropagator for Microsoft Jet” on
page 280.
Capture program
When the source is a DB2 table, the Capture program captures changes that
are made to the source. The Capture program uses the database log8 to
capture changes made to the source database and stores them temporarily in
tables.
The Capture program runs at the source server. Typically it runs continuously,
but you can stop it while running utilities or modifying replication sources.
For instructions on using the Capture program, see “Part 3. Operations” on

page 173.
Capture triggers
When the source table is in a non-IBM database (other than Teradata,
Microsoft Access, and Microsoft Jet), Capture triggers capture changes that are
made to the source. Capture triggers are fired when a particular database
event (UPDATE, INSERT, DELETE) occurs.
8. The Capture program retrieves changed and committed information from the active and archive logs on DB2 for
MVS 4.1 or higher and DB2 Universal Database. Capture for VSE and VM 5.1 can read only the active log on DB2
for VSE & VM.

DJRA automatically creates the Capture triggers. These triggers capture the
changes made to tables defined as replication sources and store the changes
temporarily in tables.
Apply program
The Apply program reads data directly from source tables or views to initially
populate the target table. If the source tables are in a non-IBM database, the
Apply program reads the data from a nickname. If you want changes copied,
the Apply program reads the changed data that is stored temporarily in
tables, and applies the changes to target tables.
The Apply program generally runs at the target server, but it can run at any
server in your network that can connect to the source, control, and target
servers. Several Apply program instances can run on the same or different
servers. Each Apply program can run using the same authorization, different
authorization, or as part of a group of Apply programs where each Apply
program in the group runs using the same authorization (user ID).
Each Apply program is associated with one control server, which contains the
control tables that contain the definitions for the subscription sets. The control
tables can be used by more than one instance of the Apply program. For
example, if you have one source server and two target servers, you can have
separate Apply programs running at each target server. The two apply
instances can share the control tables, which will have the specific information
related to each Apply instance.
For instructions on using the Apply program, see “Part 2. Administration” on

page 59 .
How the replication components communicate
The replication components are independent of each other, so they rely on
information that is stored in control tables to communicate with each other.
The Capture and Apply programs and the Capture triggers update control
tables to indicate the progress of replication and to coordinate the processing
of changes.
The replication components communicate differently depending on whether

the source server is a DB2 server or a non-IBM server. For replication between
DB2 servers, the Capture program captures changes that are made to data in
source tables by reading the server log or journal. Then the Capture program
places the changes into tables called change data (CD) tables. For non-IBM
sources, Capture triggers capture changes and store them in
consistent-change-data (CCD) tables.
Each time that the Apply program copies data to the target database, the
contents of the target database reflect the changes that were made to the

source database. The Apply program works by applying transactions
accumulated since the Apply program last ran. The Apply program keeps
track of the latest update that it makes to each target.
Log-based communication
The Capture program uses some of the control tables to indicate what changes
have been made to the source database, and the Apply program uses these
control table-values to detect what needs to be copied to the target database.
Important: The Capture program will not capture any information until the
Apply program signals it to do so, and the Apply program will not signal the
Capture program to start capturing changes until you define a replication
source and associated subscription sets. See “Performing the initial
replication” on page 54 for more information about the steps that you must
perform so that the components communicate with each other and replicate
changes.
The following process describes how the Apply and Capture programs
communicate in a typical replication scenario to ensure data integrity:
Capturing data from a source database

1. The Capture program reads the register table to determine the replication
sources for which it needs to start capturing changes. If new replication
sources are defined while the Capture program is running, they won’t be
recognized by the Capture program until you either reinitialize, or stop
and restart the Capture program.
2. The Capture program monitors the DB2 log or journal to detect change
records from source tables that are defined as replication sources.
3. The Capture program adds one row (or two rows if updates are saved as
DELETE and INSERT operations) to the change data (CD) table for each
change that it finds in the DB2 log or journal. Each replication source has
a CD table.
4. The Capture program stores information about committed transactions in
the unit-of-work (UOW) table. The rows in this control table identify the
transactions that have been committed in the source server. With
log-based change capture, one UOW table exists for every DB2 source
server.
5. The Capture program updates the register table to record how much
committed data was captured for each replication source.
Applying data to a target database
6. For all new subscription sets, the Apply program first synchronizes the
target with the replication source by copying all the data from the source
table to the target table. This action is called a full-refresh copy. After the
full-refresh copy, the Capture program begins capturing changes at the
source.

7. If any subscription set is due for replication, the Apply program checks
the register table to determine whether there are changes that need to be
replicated.
8. The Apply program updates the pruning control table to synchronize the
capture of the related source table changes in the CD table.
9. The Apply program copies the changes from the join of the CD table and
the UOW table to the target table. By joining the two control tables, the
Apply program ensures that it copies only the changes that were
committed at the source.
Pruning the tables
10. The Apply program updates the pruning control table with a value that
indicates the point to which it copied changes to the target database.
11. When the Capture program prunes the CD and UOW control tables, it
determines which changes were applied and deletes them from the CD
table and the UOW table.
Trigger-based communication
DJRA, working through DB2 DataJoiner, creates Capture triggers on non-IBM
source tables when you define them as replication sources. Three types of
triggers are created on the source table: DELETE, UPDATE, and INSERT. Also,
UPDATE triggers are created on the pruning control table and the register
synchronization table. The Apply program uses these control tables to detect
what needs to be copied to the target database.
The following process describes how the Capture triggers and the Apply
program communicate in a typical replication scenario to ensure data integrity:
Capturing data from a source

1. Whenever a DELETE, UPDATE, or INSERT operation occurs at the source
table that is defined as a replication source, a Capture trigger records the
change in the consistent-change-data (CCD) table.
Applying data to a target
2. When the Apply program is started, the UPDATE trigger on the register
synchronization table updates the register table to record how much
committed data has been captured.
3. The Apply program gets the source table information from the register
table.
4. Before the Apply program can copy the changes to the target, it
synchronizes the target with the replication source by copying all the data
from the source table to the target table.9 This action is called a full-refresh
copy.
9. This is not true for noncomplete CCD tables.

5. The Apply program updates the pruning control table to synchronize the
capture of the related changes in the CCD table.
6. The Apply program reads the CCD table using DB2 DataJoiner nicknames,
copies the changes to the target server, and applies the changes to the
target table.
Pruning the tables
7. The Apply program updates the pruning control table with a value that
indicates the point to which it copied changes to the target database.
8. The UPDATE trigger on the pruning control table checks all of the CCD
tables that are at the source server and deletes those entries that were
replicated.
DB2 data replication concepts

This section introduces some of the important concepts of DB2 data
replication. You should read the whole section to get a complete overview.
Replication sources
A replication source is a user table or view from which you want data copied.
Before you can replicate data, you must define a replication source to describe
the information that the change-capture mechanisms will use. When you
define a replication source you must specify which columns you want to
replicate, and decide whether you want updates treated as UPDATE
operations or DELETE and INSERT operations. See “Enabling replication
logical-partitioning-key support” on page 109 for more information on how to
treat updates. In addition, you must decide:
v Whether you want before-image values for a column
v Whether you want to replicate with change capture (differential-refresh
copying) or without change capture (full-refresh-only copying)
v What level of conflict detection to use for update-anywhere replication
(where a replication source has read/write target tables)
After-image columns and before-image columns

An after-image column contains the value of a data column in a source table
after the value in that data column is updated. A before-image column contains
the value of a data column in a source table before that data column is
updated. When you define a replication source, you can choose to capture
only the after-image or both the after-image and the before-image. Your
decision will depend both on the way in which you plan to use the data and
on the types of tables that you are using.
Before-image columns are useful if your applications require auditing or

rollback capability. Some restrictions apply to how you use these columns,
and they are discussed later in this book (“Replicating before and after
images” on page 72).

Full-refresh and differential-refresh copying
The Apply program copies data from the source to the target either by
full-refresh only or differential-refresh copying.
During full-refresh only copying, the Apply program performs these tasks:
1. Deletes all of the rows from the target table
2. Reads all of the rows from the source table
3. Copies the rows to the target table
During differential-refresh copying, the Apply program copies only the changed
data to the target table.
Levels of conflict detection

Conflict detection pertains only to update-anywhere replication configurations.
It is the process of detecting if the same row was updated in the source and
target tables during the same replication cycle. With standard conflict detection,
the Apply program searches for conflicts in rows that are already captured in
the CD tables. With enhanced conflict detection, the Apply program locks all of
the target tables, thus ensuring that all changes are considered when checking
for conflicts. Row-replica conflict detection applies only to tables that are
maintained by DataPropagator for Microsoft Jet; where conflicts are detected
on a row-by-row basis instead of a transaction-by-transaction basis.
Subscription sets and subscription-set members
Before you can replicate data from the replication source, you must associate
the replication source with the target to which you want the changes
replicated. You define this information using subscription sets and
subscription-set members. The information that you provide is stored in
various replication control tables.
A subscription set contains the attributes of a replication subscription. When

you create a subscription set, you define the following attributes:
v A name for the subscription set
v The source server and the target server
v The Apply qualifier
v When to start replication, how often to replicate, and whether to use
interval timing, event timing, or both
v Data blocking, if you expect large volumes of changes
A subscription set must have one subscription-set member for each target table
or view. When you create a subscription-set member, you define the following
attributes:
v The source table or view and a target table or view
v The structure of the target table or view

v The columns that you want replicated (subselect columns)
v The rows that you want replicated (SQL predicates)
Subscription sets ensure that all subscription-set members are treated alike
during replication: either changes are applied to all targets or to none of them.
The changed data for all the subscription-set members in a subscription set is
replicated to the specified target tables in a single transaction. Subscription
sets optimize performance because the target tables in a set are processed in
one transaction against the target server. Subscription sets also preserve
referential integrity.
Each subscription set is processed by one Apply program; however, each

Apply program can process many subscription sets. The relationship between
a subscription set and subscription-set members is shown in Figure 1.
Figure 1. Subscription sets and subscription-set members. Example of the relationship between a
subscription set and subscription-set members.

Apply qualifier
The Apply qualifier associates an Apply program with one or more
subscription sets. You specify a case-sensitive string as the value for the Apply
qualifier when you define a subscription set.10
By using more than one Apply qualifier, you can run more than one instance
of the Apply program from a single user ID. The Apply qualifier is used to
identify records at the control server that define the work load of an instance
of the Apply program; whereas the user ID is for authorization purposes only.
For example, assume that you want to replicate data from two source
databases to the target tables on your computer. The data in source table A is
replicated using full-refresh copying to target table A, and the data in source
table B is replicated using differential-refresh copying to target table B. You
define two subscription sets (one for table A and one for table B), and you use
separate Apply qualifiers to allow two instances of the Apply program to
copy the data at different times. You can also define both subscription sets
using one Apply qualifier.
Data manipulation
You might want to replicate only a subset of your source table, use a simple
view to restructure the data from the source table to the target table, or use
more complex joins and unions.
Subsets of source tables

You can replicate certain columns or rows from the source table instead of
replicating the whole source table. This process, which is sometimes known as
table partitioning, is called column subsetting and row subsetting in this book.
Use column subsetting if you want to replicate only a subset of all of the
columns from the source. This type of subsetting is appropriate, for example,
if some of the columns in the source are very large, such as large objects
(LOBs), or if the column data types are not supported by the intended target
table.
Use row subsetting if you want to replicate only some of the rows from the
source database. For example, when you are replicating data to more than one
regional office, you might want to replicate only records that are relevant to
that particular regional office. To subset rows, use the WHERE clause when
defining the subscription-set member.
Views as sources
Simple views are useful in data warehouse scenarios if you want to
restructure copies so that data in target tables is easily queried.
10. The Apply qualifier appears in many control tables; therefore, do not attempt to change its value after you set it.

For example, assume that a database contains both a resume table and a
photograph table. The human resources department needs one table that
contains every employee’s resume and photograph. You can create a view that
contains both the resume and photograph tables, define that view as a
replication source, and create a subscription set to replicate the data from the
view to a target table in the human resources database.
Views are also useful for introducing related columns in other tables. You can
reference the columns in other tables in the subscription-set member
predicates, which facilitates the routing of updates to the appropriate target
sites.
Joins and unions for targets

You can create and maintain target tables with contents that are joins or
unions of existing source tables.
You can use the following types of joins:

v Simple inner-joins over one or more defined replication sources, possibly in
combination with other tables or views that are not themselves replication
sources.
v Simple inner-joins over CCD tables that are defined as replication sources.
These CCD tables can be maintained by the Apply program or they can be
maintained by another application for external data sources (such as IMS
DataPropagator).
You can use joins and unions to manipulate data in the following ways:
v Joins of tables from a single DB2 source server (by defining a DB2 view as
the join of certain tables)
v Unions of tables from one source server (by using multiple subscription-set
members in a set where each member has the same target table)
v Unions of tables from multiple source servers, sometimes referred to as
multisite unions (by creating multiple subscription-set members in multiple
subscription sets because there are multiple source servers)
Target tables
When you define a subscription-set member, you must specify the type of
target table that you want to use. The following types of tables are available:
v User copy tables
v Point-in-time tables
v Aggregate tables
v Consistent-change-data (CCD) tables
v Replica or row-replica tables
v User tables

The following sections describe the unique characteristics of each type of
target table.
User copy tables

These tables are read-only copies of the replication source with no replication
control columns added. They look like regular source tables and are a good
starting point for replication. They are the most common type of target table.
Point-in-time tables
These tables are read-only copies of the replication source with a timestamp
column added. The timestamp column is originally null. When changes are
replicated, values are added to indicate the time when updates are made. Use
these types of tables if you want to keep track of the time of changes.
Aggregate tables
These are read-only tables that use SQL column functions (such as SUM and
AVG) to compute summaries of the entire contents of the source tables or of
the recent changes made to the source table data. Rows are appended to
aggregate tables over time. There are two kinds of aggregate tables: base
aggregate tables and change aggregate tables.
Base aggregate tables summarize the contents of a source table. Use a base
aggregate table to track the state of a source table on a regular basis. For
example, assume that you want to know the average number of customers
that you have each month. If your source table has a row for each customer,
you would average the number of rows in your source table on a monthly
basis and store the results in a base aggregate table.
A base aggregate table does not track change information. For example,
assume you had an average of 500 customers in January and 500 in February;
however, in February you lost two existing customers and gained two new
ones. The base aggregate table shows you that you had the same average
number of customers in both months, but it does not show the changes that
were made during February. If you want to track change information, use a
change aggregate table.
Change aggregate tables work with the change data in the control tables, not
with the contents of the source table. Use a change aggregate table to track
the changes (UPDATE, INSERT, and DELETE operations) made over time. For
example, assume that you want to know how many new customers you
gained each month (INSERTS) and how many existing customers you lost
(DELETES). You would count the changes that are made to the rows in your
source table on a monthly basis and store that number in a change aggregate
table.

Consistent-change-data (CCD) tables
These tables contain data from committed transactions. They also contain an
indicator of whether the target table was changed using an INSERT, DELETE,
or UPDATE operation. They can contain both the old and new value of the
data. Each type of CCD table (local and remote, complete and noncomplete,
condensed and noncondensed, internal and external), has a different use.
“Attributes of CCD tables” on page 82 describes these types, when to use
them, and how to define them. You can use the different types of CCD tables
to collect and manipulate data in the following ways:
v Staging changes to remote locations. If you have many remote targets,
instead of replicating from the source to all of the targets, you can replicate
from the source to a CCD table, and then replicate from the CCD table to
the remote targets. By using the CCD table, the join of the CD table and
UOW table is done only once. If the CCD is remote but near the targets
then it might save network transfer time as well.
v Replicating only the net change for a row to the target. CCD tables can
reduce the load on your network and prevent updates from being made
repeatedly to the same rows over a short period of time.
v Collecting audit information.
v Acting as the source of change data from change-capture mechanisms other
than the Capture program, such as:
– IMS DataPropagator for change data from IMS
– Data Difference utility for change data from VSAM
– Capture triggers for change data from non-IBM data sources
Replica or row-replica tables

These are the only target tables that your applications can update directly.
Changes made to replicas and row-replicas are replicated to the associated
source table; the source table in turn replicates the changes to other replicas.
Replicas are supported only in DB2 databases. A row-replica table is a special
type of replica table for DB2 DataPropagator for Microsoft Jet. Use the replica
table types for update-anywhere replication.
User tables
You don’t actually specify a user table as a target; however, in
update-anywhere replication, a user table is automatically a target for the
replicas or row-replicas that are associated with it. The user table is the parent
of the replica, and its copies are dependent replicas. The parent of the replica
receives updates from a dependent replica and, if there are no conflicts
detected, it replicates the changes to the other dependent replicas. The parent
of the replica is the primary source of data. If there are any update conflicts
detected, the contents of the parent of the replica prevail. Typically your
applications access the dependent replica tables; however, they connect to the
server containing the user table when the replicas are not available.

Schedule for applying updates
Synchronous replication delivers updates continually. When a change is made to
the source data, it is temporarily stored and forwarded to the target at a later
time. A change is committed to the source database only after the change is
replicated to the target database. If for some reason the change cannot be
replicated to the target database, the change is not made to the source
database. This type of replication is also called real-time replication. If your
application requires synchronous updates, code your applications to update
tables in a single, distributed transaction instead of using the products
described in this book.
Asynchronous replication delivers updates in stages. When a change is made to

the source data, it is stored temporarily for a preset interval and forwarded to
the target at a later time. The interval can be a measure of time (seconds,
minutes, hours) or can represent a prescribed event (midnight, or some other
time of day). If changes cannot be made to a target database (for example, if
the target database is down or the network is down), they are stored and
applied later, in the order in which they were made to the source. This type of
replication provides many benefits over synchronous replication: better use of
network resources, less database contention, and the opportunity to enhance
data before it reaches the target database.
DB2 DataPropagator performs asynchronous replication; therefore, changes

made to the source are not made immediately to the targets. You can control
how frequently the changes are applied to the target by specifying time
intervals, events, or both. For environments that have occasionally connected
clients, you can replicate data on demand.
Interval timing
This is the simplest method of controlling the timing of replication. To use
interval timing, you choose a date and time for the Apply program to start
replicating data to the target, and set a time interval that describes how
frequently you want the data replicated. When the Apply program stops, it
will not start again until the time interval passes. The time interval can be a
period of time (from one minute to one year), or it can be continuous. A
continuous time interval means that the Apply program starts replication cycles
one after the other, with only a few seconds delay in-between (you can control
the delay with the start parameter). The intervals that you provide are
approximate. The interval actually used by the Apply program depends on
the number of updates that the Apply program has to replicate and on the
availability of resources (that is, database table, table space).
Event timing
This is the most precise method of controlling the timing of replication. To use
event timing, you specify the name for an event when you define the
subscription set. You then set the time when you want that event processed.

Optionally, you can set an end-of-period time; the Apply program will not
replicate any transactions committed after this time, but will defer their
replication until a future date.
You or your application must provide information for event timing. This
information is stored in the subscription events table. The Apply program
searches the subscription events table for the event name and the associated
time and end-of-period information.
On-demand timing
You can replicate data on demand by using the ASNSAT command. This
command starts the Apply program and, if necessary, it also starts the
Capture program. Each program self-terminates after it completes its part of
one replication cycle. This command is supported on Windows 32–bit
operating systems, and its invocation parameters are described in “Replicating
on demand (Windows 32–bit operating systems only)” on page 279.
ASNSAT is also used in replication configurations that include occasionally

connected systems. For details, see DB2 Universal Database Administering
Satellites Guide and Reference.

Chapter 2. Data replication configurations
This chapter describes the typical data replication configurations and provides
examples of replication solutions for common business needs. Some of these
configurations show how other products can be used with DB2
DataPropagator to create a unique replication solution. The replication
configurations covered here are not exhaustive because users are continually
developing new and creative implementations.
Important: DB2 replication is designed for asynchronous replication and is not

suitable for the following situations:
v Performing real-time replication: In real-time replication, sometimes called
synchronous replication, changes to the source system are made
immediately to the target tables. If synchronous data delivery is essential to
your application, code your application to update the application table and
all of its copies with a single transaction to ensure that both the source and
target are changed at the same time.
v Maintaining a backup server (hot-site backup): Do not use asynchronous
replication to maintain a backup server that can be accessed when your
primary server is down. If the source (primary) server becomes unavailable,
there is no way to guarantee that all updates were made to the target
(backup) server. If you must maintain a backup server, consider using other
tools or features. For example, for System/390® consider Peer-to-peer
remote copy (PPRC) hardware feature or the extended recovery component
(XRC).
Overview of replication configurations

You can combine configurations to suit your business needs. The following
sections describe these typical configurations, including some variations of
each:
v Data distribution
v Data consolidation
v Update anywhere
v Occasionally connected
Data distribution and data consolidation are easier to set up and maintain
than the other configurations.
Data distribution
In data distribution configurations, a primary data source resides on a source
server (see Figure 2 on page 20). Changes made to the data source are

replicated to one or more target tables that reside anywhere in a distributed
network. The target tables are read-only; therefore, you don’t need to set up
conflict detection because no update conflicts occur during replication.
Applications can use the target tables, which are local copies, so that they
don’t overload the network or central server. This configuration is useful if
you need to share data among several sites but you don’t want to reduce the
performance of your applications.
Figure 2. Data distribution. Changes made to a source table are replicated to read-only target
tables.
Data consolidation
In data consolidation configurations, a central data server is used as a
repository for data from many data sources (see Figure 3 on page 21).
Therefore, this configuration consists of many source tables or views and one
target table with multiple subset views. Changes made to each data source are
replicated to the central data server, which is read-only.
Restriction: If you consolidate data from more than one server into a CCD
target table, you must not use that CCD target table as a replication source for
other target tables. The original servers use separate log sequences that cannot
be distinguished in further replication.
Data consolidation configurations are useful for maintaining a local decision

support system (DSS) so that you can analyze data without competing for
production database resources. To ensure that there are no update conflicts,
you must design the replication environment so that there is only one source
for each data item. If each source updates a unique set of rows, you will never
encounter update conflicts.

Figure 3. Data consolidation. Each source table can update a unique set of rows in a read-only
target table.
Update anywhere
In update-anywhere configurations, a replication source has target tables that
are read/write copies. Changes made to a target table are applied to the
source table, which maintains the most up-to-date data. If a conflict occurs
between a source and target, the source wins. The source table then applies
the changes to all of its target tables. Unless you design your application
correctly, update conflicts can occur when the data is replicated (see Figure 4
on page 22). It is best to design your application so that a conflict can never
occur when data is replicated from the source to all the target tables (see
Figure 5 on page 22). You have the option of ignoring conflicts and rejecting
any conflicting updates. By rejecting conflicting updates, you risk losing some
information.
Chapter 2. Data replication configurations 21

Figure 4. Update-anywhere replication with risk of conflicts between target tables. This
configuration requires conflict detection because all rows can be updated at the source table or at
any target table.
Figure 5. Update-anywhere replication with no risk of conflicts between target tables. Each
read/write target table has a unique set of rows that can be updated locally; the source table at the
source server maintains the most up-to-date data.
Occasionally connected
In occasionally connected configurations, you have the flexibility to connect to
and transfer data to and from a primary source on demand. These types of
configurations allow users to connect to the primary data source only long
enough to synchronize their local database. The data source doesn’t require a
continuous connection for replication administration (see Figure 6 on page 23).

Occasionally connected configurations are well-suited for synchronizing data
on laptop computers or at computers in home offices. These configurations
minimize the frequency and duration of communication-line connections and
reduce telecommunication costs, yet the data is available for update. This type
of configuration also works well for replicating data to onsite computers that
are not constantly connected to the network (for example, if employees are in
the office only three days a week).
Figure 6. Occasionally connected configuration. The target servers are not continuously connected
to the source server; changes that are made to the tables are replicated when the target server is
connected to the source server.
You can use DB2 Universal Database Satellite Edition (or any other DB2
server that participates in a satellite environment) to administer satellites,
which are occasionally connected DB2 servers. DB2 data replication enables
you to synchronize data between a central control site and many satellites. At
the home office you set up the replication environment, test it, and when it is
ready to be rolled out to the occasionally connected systems, you store it in
the Satellite Administration Center database. You don’t access any of the
occasionally connected systems and only need to set up the environment once.
For information about setting up data replication for satellites, enabling the
satellite environment for replication, and testing replication on a satellite, see
the DB2 Universal Database Administering Satellites Guide and Reference.

Examples of replication configurations
You can build on the typical replication configurations to come up with
replication models that meet your specific needs. This section discusses
examples of some common business needs and the DB2 replication solutions
that address those needs. Design issues that are unique to each replication
solution are also described.
Archiving audit information
Requirements: A customer in a DB2-IMS Transaction Manager (TM)
environment generates audit data by writing audit information to the IMS log.
New applications access DB2 through DRDA®, bypassing IMS TM completely.
The customer needs to track all changes to relational tables for auditing
purposes to determine which users made particular changes to the data.
Replication solution: The Capture and Apply programs for DB2

DataPropagator are used to capture and store the DB2 for OS/390 changes in
target tables (see Figure 7).
Figure 7. Audit information. Audit data is replicated to a target table that can be read by the
customer’s application.
Design highlights: Both the before-image and the after-image values of each
row are captured and stored. The authorization ID of the user who changed
the data is also stored in the audit tables. All of this information is captured
from the DB2 for OS/390 log.
Consolidating data from distributed databases
Requirements: A large retail chain has almost 500 stores around the country,
each of which gathers purchase details through an electronic point of sale
(EPOS) system. Each store keeps its data in local databases on DB2 for AIX.
The data is transferred nightly to a central DB2 for OS/390 site using a
pre-existing file-transfer process from the EPOS terminals. The company
wants to enhance the data at the central site.

Replication solution: Data changes from each retail store are captured and
saved by the Capture program on DB2 for AIX (see Figure 8). The Apply
program on DB2 for OS/390 consolidates the data from all stores and
summarizes it.
Figure 8. Consolidating data from distributed databases. Data from three source servers is
replicated to two target tables on a target server.
Design highlights: The Apply program uses base aggregate and change
aggregate tables to summarize the consolidated store data. The base aggregate
tables summarize the contents of the source files. The change aggregate tables
summarize the results of the changes made between each refresh of the target
that is performed by the Apply program.
Distributing data to remote sites
Requirements: A small bank installed several new Windows NT client/server
applications in its 85 branches. A major source of data for the new
applications is the customer and financial reference data, which is derived and
held at a host site in two operational systems, one on DB2 for OS/390 and the
other on DB2 for AIX. If branches accessed the data directly from the host site,
network traffic would be congested and the availability of the production data
could be affected.

Replication solution: To minimize the network traffic, a local copy of the
database is maintained at each branch (see Figure 9). Therefore, each branch is
a target server. Changes are captured from DB2 for OS/390 and DB2 for AIX,
condensed in control tables on DB2 for AIX, and replicated to the branches
overnight.
Figure 9. Distributing data to remote sites. Source data is consolidated on an AIX server and replicated to the
branches. Each branch gets all of the financial data and some of the customer data. WHERE clauses are used to
ensure that each branch gets the records that pertain to their own customers only.
Design highlights: One Apply program resides on AIX and replicates from
DB2 for OS/390 and DB2 for AIX. There is one subscription set for replicating
from DB2 for OS/390 to DB2 for AIX and one for replicating from DB2 for
AIX to DB2 for AIX.
An Apply program also resides on the target servers at each branch. The
Apply program on the source server runs separately from the Apply

programs at the target servers. The Apply program at each of the branches
replicates from the control tables on DB2 for AIX at the host site. Each of the
Apply programs on the target servers has a subscription set for replicating
from the host site to its local database. Each branch gets all of the financial
data but only some of the customer data. WHERE clauses are used to ensure
that each branch gets the records that pertain to their own customers only.
The Capture and Apply programs maintain complete, condensed CCD tables
in DB2 for AIX. The administrator chose a condensed CCD table because that
type of staging table contains only the most recent change made to a row, so
network traffic is reduced during replication.
When the subscription sets were created for each branch, the administrator
put the control server on the Windows NT server. If the administrator had put
the control server on DB2 for AIX, the Apply program from each Windows
NT server would need to connect to the host site over the network to read
and update the control information about the subscription set, and to detect
changes to its control information.
Distributing IMS data to remote sites
Requirements: A large financial institution wants to improve the flow of
information from two legacy operational systems to its OS/2-based branches.
It wants to provide more accurate and timely data to help loan-application
research and to detect credit-card fraud. The data for loan applications is in
DB2 for OS/390, and the credit card details are in an IMS system. Previous
attempts to copy the legacy data consisted of an unworkable mixture of
ad-hoc reports and file transfer techniques.
Replication solution: IMS DataPropagator is used to capture and save the

changes to IMS data into CCD tables in DB2 for OS/390 (see Figure 10 on
page 28). The Capture program is used to capture and save the changes to
DB2 for OS/390 data. The data that is saved is historical—it records every
change made. The Apply program runs at the branches and uses the historical
data from IMS and DB2 for OS/390 to maintain DB2 for OS/2 tables.

Figure 10. Distributing IMS data to relational databases. IMS DataPropagator replicates IMS data
to target tables on an OS/390 source server. DB2 DataPropagator captures data from the OS/390
source server and replicates it to OS/2 servers.
Design highlights: IMS DataPropagator captures changes from the IMS log
and creates a noncondensed CCD table in DB2 DataPropagator format on the
OS/390 source server. DB2 DataPropagator uses this CCD table as a
replication source. The Capture program on the OS/390 server captures
information from the local tables that contain the credit-card and
loan-application data. The Apply program on the OS/2 target server pulls the
change data to the target tables.
Accessing data continuously
Requirements: An international bank wants to keep its system online 24
hours a day. Currently the system is online 23 hours 45 minutes a day. Every
day the bank stops the system to quiesce it for a batch application, which
requires exactly one day’s worth of data. During the 15 minutes when the
system is down, the required tables are extracted. After the extraction, the
system is made available for the next financial day.
Replication solution: Data changes made during the day are captured and
replicated to CCD tables (see Figure 11 on page 29). The batch application was
modified to process the changes in the CCD tables instead of the table
extracts. The online system does not need to be stopped to provide consistent
data for the batch application.

Figure 11. Batch application using replicated data. The source data is replicated to a CCD table.
The batch application extracts data from the CCD table when the source table is unavailable.
Design highlights: The CCD table includes a timestamp that is used to

identify the changes made during a time period (in this case, one day).
Replicating operational data to decision support systems
Requirements: A financial institution needs to replicate updates from its
customer information database on DB2 for AS/400 to a decision support
system that is also on DB2 for AS/400. Historical data about updates must be
saved and stored with no code changes to production applications and no
impact to the performance of those applications.
Replication solution: Updates are captured from the key operational tables
and, on an hourly basis, replicated to CCD tables in the decision support
system (see Figure 12).
Figure 12. Replicating operational data to decision support systems. The noncondensed CCD
target table is used to record all changes made to the source database.
Design highlights: The Capture and Apply programs maintain noncomplete,

noncondensed CCD tables. Noncondensed CCD tables are used because they

record all changes that are made to the customer information database.
Furthermore, noncomplete CCD tables are used because the financial
institution does not want to record the original contents of the source, it wants
only the changes.
The Capture and Apply programs are given job priorities such that replication
does not impact production CPU resources. The decision support system
could be implemented just as easily on any of the supported target platforms
and could still be ported to other platforms if required.
Using target tables as sources of updates (update anywhere)
Requirements: A financial institution has hundreds of agents at several
branches who must fill in online forms to set up and modify client accounts.
The agents base the quotation rates on information that was generated at the
head office and sent to the branch. The agents send reports back to the head
office, and the accounts are finalized only after the information is verified at
the head office. The agents would be more productive if they had access to
up-to-date data without the network problems of accessing the central
database directly.
Replication solution: A special type of target table, called a replica, is used to

set up circular subscriptions (see Figure 13 on page 31). Changes to the replica
are replicated back to the primary replication source, which is a user table. An
update that is made at one location is reflected in the databases at other
locations. Agents have the current information that they need to finalize
accounts while meeting with the client, and the head office has the new
business data generated that day.

Figure 13. Update-anywhere replication. The primary data source, or parent replica, is on an
OS/390 server; and the dependent replicas are on Windows NT client systems.
Design highlights: The primary replication source is a user table. It contains

the most up-to-date information.
This type of replication works best when transaction conflicts between the
central database and the updatable copies can be avoided, such as when
copies can update only key ranges at specific sites, or when sites can make
updates only during certain time periods.
DB2 DataPropagator detects conflicts that occur when the same row is
updated on the host system and on an agent’s system and neither change has
been replicated. If an agent made updates that are in conflict, these updates
are discarded during replication to ensure data integrity. The transaction
containing the conflict and all captured transactions that are found that are
dependent on the conflicting transaction are backed out.
Updating data on occasionally connected systems
Requirements: An insurance company wants to equip its sales agents, who
rarely visit the company’s home office, with a set of offers to attract both new
and existing customers—special introductory offers and personalized
packages. Much of the time, the agents’ computers will not be connected to

the home office. When they connect to the home office, they need to get any
updated information from the central database. Managing the potential
backlog of changes can be an issue.
Replication solution: The sales force is supplied with laptop computers

running DB2 Universal Database Satellite Edition. As a sales campaign is
launched, each agent downloads the customer profiles and history, as well as
the latest product offers. DB2 replication also solves the problem of keeping
the information up to date. Only new and changed data rows are copied
across the network.
Design highlights: DB2 Universal Database Satellite Edition is used because it

meets the replication requirements and can be administered by a central
administrator. An administrator at the home office sets up the replication
environment, tests it, and copies it to the occasionally connected systems. The
administrator also provides user IDs and passwords to the agents in the field
so that they can connect to the server at the home office from their laptop
computers. While they are logged on, the agents can synchronize the
information on their laptop computer with the information at the source
server by pressing a button.
Retrieving data from a non-DB2 distributed data store
Requirements: A manufacturing company uses an Oracle application to
process customer orders, and DB2 on OS/390 for its central operational data
store. The new order information is uploaded into DB2 in overnight batch
extracts. The company wants the data to be replicated sooner because
customers want their orders to be processed faster.
Replication solution: Triggers on the Oracle tables simulate the Capture

program by placing the changed records into CCD tables at the Oracle server.
Nicknames in DataJoiner make the Oracle source tables and CCD tables
appear to be tables in a DB2 database so that the Apply program on OS/390
can replicate them to the DB2 for OS/390 tables. The Apply program is set to
replicate every hour during the business day.

Figure 14. Retrieving data from a non-DB2 distributed data store. Triggers are used to capture
changes made to source tables in Oracle, and DataJoiner is used to replicate to target tables on
DB2 for OS/390.
Design highlights: DataJoiner Replication Administration (DJRA) is used to

define the Capture triggers and the CCD tables in the Oracle database. DJRA
also generates SQL statements to create all database objects and data type
mappings. DataJoiner lets the Apply program access non-IBM data as if it
were in DB2. The Apply program can also be run on DB2 for OS/390 to pull
data.
Replicating operational data to a non-DB2 reports and query database
Requirements: A large retail chain has their business operations applications
on a mainframe that uses a DB2 for OS/390 subsystem. Staff and
headquarters personnel need to query the operational data to create reports.
The retail chain wants to replicate the data needed for the queries and reports
to an Informix database management system on a UNIX server. The retail
chain needs the reports and query results to be based on data that is less than
four hours old.
Replication solution: The Capture program places the updates that are made
to the operational data in DB2 for OS/390 tables. The subscription timing
interval is set to four hours to make sure that the query results and reports
are based on current operational data. Using DataJoiner nicknames, the Apply
program replicates updates from the DB2 tables to the query and reports
tables in the Informix database.

Figure 15. Replicating operational data to a non-DB2 reports and query database example.
Changes made to source tables on DB2 for OS/390 are captured and replicated to target tables on
Informix using nicknames defined in DataJoiner.
Design highlights: DataJoiner Replication Administration (DJRA) is used to

create the target tables in Informix with the correct Informix data types. The
Apply program replicates data to Informix using DataJoiner nicknames and
any data type transformations that are needed.

Chapter 3. Data replication scenario
Use the scenario in this chapter to get some experience using the DB2 Control
Center and the Capture and Apply programs. Follow the steps in this simple
scenario to copy changes from a DB2 replication source to a target table in a
database on DB2 for Windows NT Enterprise Edition (EE) or Workgroup
Edition (WE).
The scenario consists of the following parts:

1. “Before you begin”
2. “Planning this scenario” on page 36
3. “Setting up the replication environment for this scenario” on page 38
4. “Operating in a replication environment” on page 47
Before you begin

If you want to work through this scenario on your computer, set up your
system using these steps:
1. Make sure that you have DB2 for Windows NT installed on your
computer.
2. Make sure that your DB2 Control Center uses the default settings. If you
explicitly changed the default settings, some of the steps described in this
scenario will not match what you see on your display.
3. Create the C:\scripts directory in which you will store the SQL files for
replication.
4. Use the DB2 Control Center to create a new database called COPYDB,
which you will use as the target and control server. To create the database,
right-click the Database folder and follow the instructions for creating a
new database using the wizard with default options.
5. Use the First Steps icon in DB2 Universal Database (or select Start ->
Programs -> DB2 for Windows NT -> First Steps) to create the SAMPLE
database. After the database is created, close the First Steps window. If you
did not install First Steps when you installed DB2 for Windows NT, go to
a DB2 command window and issue the db2sampl command to create the
SAMPLE database.
The steps in this chapter use the data in the DEPARTMENT table from the
SAMPLE database. The fully qualified name is userID.Department; where
userID is the user ID that created the table. Table 1 on page 36 shows the
DEPARTMENT table.

Table 1. DEPARTMENT table
DEPTNO DEPTNAME MGRNO ADMRDEPT LOCATION
A00 SPIFFY COMPUTER 000010 A00 -
SERVICE
B01 PLANNING 000020 A00 -
C01 INFORMATION 000030 A00 -
CENTER
D01 DEVELOPMENT - A00 -
CENTER
D11 MANUFACTURING 000060 D01 -
SYSTEMS
D21 ADMINISTRATION 000070 D01 -
SYSTEMS
E01 SUPPORT SERVICES 000050 A00 -
E11 OPERATIONS 000090 E01 -
E21 SOFTWARE SUPPORT 000100 E01 -
For the remainder of this exercise, use the user ID with which you created the
SAMPLE and COPYDB databases. Because you created the databases, you
have the authority (DBADM or SYSADM) to perform replication tasks.
Planning this scenario

Assume that an application that generates reports needs information that
exists in the DEPARTMENT table of the SAMPLE database. Instead of using
the data directly from the source table, you want to copy the changes to a
target table that can be read only by the report-generating application. For
ease of administration, you want to keep the target table on the same machine
as the source server.
You require a simple data distribution configuration, with changes from one
replication source being replicated to a single read-only copy. This section
describes the design and planning issues that you need to consider before you
perform any replication tasks.
Replication source
You already know that the replication source is the userID.DEPARTMENT
table in the SAMPLE database. Before you set up your environment, you must
decide what you want to replicate from that table. You decide to make all
columns available for replication; and you want to save before-image values
for each of them so that you can see what is changed.

Tip: You might want to always include before-image values when you define
a replication source. If you later change an update-anywhere
configuration, you won’t have to redefine your replication source.
Replication target
You decide that you want your replication target to be the COPYDB database,
which you created using DB2 for Windows NT earlier in this chapter.
Currently there is no target table in that database; you want the Control
Center to create the target table according to your specifications.
Using existing target tables: When you use the Control Center, the target
table is created if it doesn’t exist. This method of automatically generating a
target table is preferred because it ensures correct mapping to the replication
source. You can use existing target tables if they were created by any DB2
product.
Assume that you want the target table in COPYDB to contain the following
columns of information:
DEPTNO
Information from the DEPTNO column in the replication source (this
column will be the primary key of the target table)
DEPTNAME
Information from the DEPTNAME column in the replication source
MGRNO
Information from the MGRNO column in the replication source
ADMRDEPT
Information from the ADMRDEPT column in the replication source
LOCATION
Information from the LOCATION column in the replication source
Because the columns in the target table simply reflect the data from the source
table, and there is to be only one record in the target table for each record in
the source table, you can use a user copy type of target table.
Replication options
For the purpose of this exercise, you decide to store the target table and the
replication control tables in the default table space, USERSPACE1.
Logical server Table space Contents

Source server: SAMPLE USERSPACE1 Source replication control
tables, including the CD
table
Chapter 3. Data replication scenario 37

Control server and target USERSPACE1 Replication control tables
server: COPYDB and the target table
Typically you will want to put the UOW table and the CD tables (and CCD
tables if you are using them) in their own table spaces, with table or table
space locking. You can put all other replication control tables together in one
table space with row-level locking.
For scheduling replication, assume that you want DB2 replication to check for
any changes from the source table every minute and replicate them to the
target table. Although a report-generating application doesn’t require that
kind of turnaround, you want to test the replication environment that you set
up to make sure that everything is working correctly.
Also, you decide that after each replication cycle, you want to delete any
records from the Apply audit trail table that are older than one week (seven
days). This pruning prevents the table from growing too large.
You won’t need to set constraints because you have a read-only target.
Constraints are needed only when applications are updating a target table. In
this scenario, the updates are committed at the replication source, and they
must satisfy the constraints defined on that system. There is no reason for you
to reevaluate the same constraints at the target.
Setting up the replication environment for this scenario

After planning the replication model, you are ready to set up the replication
environment.
Step 1: Customize control tables
The Control Center automatically creates control tables at the source server
and at the target server. By default, it builds the control tables with default
settings (locking, table space) that are suitable for testing purposes but not for
production environments. To customize the control tables for your production
environment, you must edit and run the dpcntl.udb file before you perform
any other replication task.
To customize control tables:

1. On the drive where you installed the DB2 Universal Database, change to
the sqllib\samples\repl\ directory.
2. Open the dpcntl.udb file. If you were in your production environment,
you would edit and run this file to customize the control tables for your
needs. For the purpose of this exercise, do not edit this file.
3. Close the dpcntl.udb file.

Step 2: Define a replication source
After you customize the control tables, go to the Control Center to define the
DEPARTMENT table as a replication source.
To define a replication source:

1. In the object tree, click the Tables folder under the SAMPLE database. All
of the tables that exist in SAMPLE appear in the contents pane.
2. Right-click the DEPARTMENT table and select Define as Replication
Source -> Custom. A custom replication is one that lets you manipulate
the data before it is applied to the source. The Define as Replication
Source window opens.
3. For this exercise, don’t change anything on the Define as Replication
Source window because you want to use the default settings. Click OK.
4. The Run Now or Save SQL window opens. Use these steps from the Run
Now or Save SQL window:
a. You can run SQL now or later. Accept the default, which is to save the
SQL to a file and run it later, by clicking OK.
Tip: Most of the time you will want to use the default. By saving the
SQL to a file, you can look at the SQL to understand what it will
do, make any modifications that you require, save the file, and
run it after you are confident that it will do what you expect it to
do.
b. The System name window opens. Click OK.
c. Use the File browser window to create a file in which to save the SQL:
1) In the Drives field, select C:.
2) In the Directories list, select scripts by double-clicking it. (To move
up one directory level, double-click the two dots (..) at the top of
the list.)
3) In the Path field, type replsrc.sql.
4) Click OK.
Tip: By default, the SQL file is saved in the sqllib directory. When you
work in your own replication environment, you will want to keep
all the files in a separate directory instead of storing them in
sqllib.
d. View the file that you created. Go to the C:\scripts directory and open
the replsrc.sql file using an editor. For the purpose of this exercise,
don’t change anything in the file. Close the file.
Tip: When you set up your own replication environment, be careful

how you edit this file. If you change the name of the CD table or
the table space in which the CD table will be put, you must also

modify the CREATE INDEX statement for the CD table and
update the CD table entry in the ASN.IBMSNAP_REGISTER row.
5. Run the file to define the replication source:
a. Right-click the Replication Sources folder and select Run SQL Files.
b. Use the File browser window to select the SQL file that you saved in
step 4c on page 39:
2) In the Directories list, select scripts by double-clicking it.
3) In the Files field, select replsrc.sql.
4) Click OK.
6. Verify that DEPARTMENT is defined as a replication source by
right-clicking Replication Sources -> Refresh. The table name,
DEPARTMENT, appears in the contents pane of the Control Center.
The table DEPARTMENT is now defined as a replication source. When you
ran the SQL file, the Control Center created the change data (CD) table for
this replication source and it created the replication control tables in the
default table space (USERSPACE1) for the SAMPLE database.
Step 3: Define a subscription set and a subscription-set member
After you define the source, you need to define a subscription set. A
subscription set defines a relationship between the replication source
(DEPARTMENT in this scenario) and a target table (that you will call
DEPTCOPY in this scenario). It also defines some replication parameters.
To define a subscription set and a subscription-set member:

1. Select the Replication Sources object in the object tree, then right-click the
DEPARTMENT object that appears on the right pane of the Control
Center and select Define Subscription. The Define replication subscription
window opens.
2. Set up the target table and subscription set:
a. Name the subscription set that you are defining by typing DEPTSUB in
the Subscription name field.
b. Identify the database where the target table will reside by selecting
COPYDB in the Target server field.
c. Type DEPTQUAL in the Apply qualifier field. This string identifies the
definitions unique to the instance of the Apply program that will run
this subscription set.
Tip: The Apply qualifier is case-sensitive. If you want the Apply

qualifier to be in lowercase characters, you must delimit it when

you type it; for example "deptqual". If you simply type deptqual,
the Control Center converts the value to uppercase characters by
default.
d. Specify that you want the Control Center to create the target table by
selecting the Create table check box.
e. Click Change. The Change window opens.
1) Change the default target table from userid.DEPARTMENT to
userid.DEPTCOPY by typing over it.
2) Click OK to return to the Define replication subscription window.
f. Click Advanced. The Advanced Subscription Definition notebook
opens. Do the following steps:
1) Leave the default selections on the Target Type page because you
want to create a user copy target table.
2) On the Target Columns page, make DEPTNO the primary key of
the target table by selecting the Primary key check box next to
DEPTNO.
Tip: You might want to expand the window to view all of the
columns. Also, some rows have names beginning with the
letter X (for example, XDEPTNO). These rows store the
before-image column values that you requested.
3) On the Rows page, indicate that you want to replicate rows that
meet certain criteria by typing the following for the WHERE clause:
DEPTNO >='A00'
4) Click OK to save these settings and return to the Define replication
subscription window.
3. Define the SQL statements that will be processed when the subscription
set is run:
a. Click SQL to open the SQL window.
b. Click Add to open the Add SQL window.
c. Indicate that you want to delete any records in the Apply audit trail
table that are older than seven days by typing the following processing
statement in the SQL statement or Call procedure field:
DELETE FROM ASN.IBMSNAP_APPLYTRAIL WHERE LASTRUN
< (CURRENT TIMESTAMP - 7 DAYS)
d. Indicate that ″row not found″ is an acceptable SQL state by typing the
value 02000 in the SQLSTATE field and clicking Add. This value is
added to the Acceptable SQLSTATE values list box.
Tip: You can define up to ten SQL states that you want to ignore for
this subscription.

e. Specify that the SQL is to run before the subscription set is processed
by selecting the At the target server before subscription is processed
radio button. In this case, you must run the SQL at the target server
because the control server and target server are collocated and the
Apply trail table is at the control server.
f. Click OK. The SQL statement is added to the list box in the SQL
window and the Add SQL window closes.
g. Click OK in the SQL window to return to the Define replication
subscription window.
4. Click Timing and use the Source to Target page of the Subscription Timing
notebook to specify when and how often to replicate the subscription set.
a. Keep the default values for Start date, Start time, Time-based, and
Using relative timing.
b. Specify that you want the subscription set to run in 1-minute intervals:
1) Use the spin button on the Minutes field to select 1-minute
intervals (or type 1 in the field).
2) Use the spin button on the Hours field to change the default
number to 0 (or type 0 in the field).
c. Click the Data Blocking tab, and use the spin buttons to select 1 as the
number of minutes at a time that Apply will copy committed data.
Tip: The value that you set for data blocking depends on how much
free space you have on the workstation that runs the Apply
program. Typically, you would use a number from 5 to 20. If you
want to be very conservative, use 1 minute.
d. Click OK to save these values, close the Subscription Timing notebook,
and return to the Define replication subscription window.
5. Submit the subscription set.
a. Click OK in the Define replication subscription window. The Run Now
or Save SQL window opens.
b. Specify the control server, which is the database that will contain the
subscription set control information, by selecting COPYDB. This server is
the database in which you want to store the subscription control
information.
c. On the Run Now or Save SQL window, accept the default option,
which is to save the SQL file and run it later, by clicking OK.
d. The System name window opens. Click OK.
e. Use the File browser window to create a file in which to save the SQL:
2) In the Directories list, select scripts by double-clicking it.
3) In the Path field, type replsub.sql.

4) Click OK. The File browser window closes.
6. Run the file to define the subscription set:
a. Right-click the Replication Subscriptions object under the SAMPLE
database and select Run SQL Files.
b. Specify the SQL file, replsub.sql, which you named in step 5e on
page 42, and click OK.
7. Right-click the Replication Subscriptions object under the SAMPLE
database and select Refresh. The DEPTSUB subscription set appears as an
object on the contents pane of the Control Center.
Step 4: Configure the source database
Tip: If your source server were on another machine, you would need to log
on to the source server over the network. You would use a user ID that
has DBADM or SYSADM authority for the source server. However,
because the source server for this exercise is on your local machine, you
don’t need to log on again.
To configure the Capture program:

1. Right-click the SAMPLE database object and select Configure. The
Configure Database notebook opens.
2. Go to the Logs page, select the Retain log files for roll-forward recovery
and/or Capture parameter from the list. In the Value box, select the
CAPTURE radio button. By retaining the log, you ensure that DB2 won’t
overwrite log entries before the Capture program reads them.
3. Click OK to save the values.
4. Right-click the SAMPLE database object and select Disconnect.
5. Right-click on the SAMPLE database object and select Backup ->
Database. Follow the instructions in the window to back up now to a
directory on your system using the default options.
Tip: You must perform the backup action to make the database accessible.
The database was put in backup pending mode when you specified
that you want to retain log files for roll-forward recovery.
Step 5: Bind the Capture and Apply programs
Tip: For the purpose of this exercise, you will manually create and bind the
Capture and Apply program packages. However, DB2 DataPropagator
for all supported UNIX, Windows, and OS/2 operating systems can
automatically create and bind the packages for you.
To manually bind the Capture program

1. Select Start -> Programs -> DB2 for Windows NT -> Command Window
to open a DB2 command window.
2. Connect to the source server:
DB2 CONNECT TO SAMPLE
3. Go to the sqllib\bnd directory. All the bind files are located in that
directory.
4. Create and bind the Capture program package to the source server
database by typing the following command:
DB2 BIND @CAPTURE.LST ISOLATION UR BLOCKING ALL
The capture.lst file contains a list of the packages created.
Continue with the steps listed below.
To manually bind the Apply program:

1. Create and bind the Apply program package to the source server by
typing both of the following commands:
DB2 BIND @APPLYUR.LST ISOLATION UR BLOCKING ALL
DB2 BIND @APPLYCS.LST ISOLATION CS BLOCKING ALL
The applyur.lst and applycs.lst files contain a list of the packages that were
created.
2. Connect to the target server:
DB2 CONNECT TO COPYDB
3. Create and bind the Apply package to the target server database by typing
both of the following commands:
DB2 BIND @APPLYUR.LST ISOLATION UR BLOCKING ALL
DB2 BIND @APPLYCS.LST ISOLATION CS BLOCKING ALL
The applyur.lst and applycs.lst files contain a list of the packages that were
created.
Step 6: Create a password file
For end-user authentication to occur at the source server, you must create a
password file with an AUTH=SERVER scheme. The Apply program uses this
file when connecting to the source server. Make sure that the user ID that will
run the Apply program can read the password file.
To create a password file:

1. Go to the C:\scripts directory.
2. Open a file editing session for a new file.
3. Type the following records in the empty file:

SERVER=SAMPLE USER=userid PWD=password
SERVER=COPYDB USER=userid PWD=password
Where:
server
The name of the source, target, or control server, exactly as it appears
in the subscription set table. (In this example, SAMPLE and COPYDB.)
userid
The user ID that you plan to use to administer that particular server.
This value is case-sensitive on Windows NT and UNIX operating
systems.
password
The password that is associated with that user ID. This value is
case-sensitive on Windows NT and UNIX operating systems.
Password file format: Do not put blank lines or comment lines in this file.
Add only the server-name, user ID, and password information. This
information enables you to use different passwords or the same password
for each server.
4. Save and close the file as deptqual.pwd.
Password file naming convention:
The password file name is applyqual.pwd; where applyqual is a
case-sensitive string that must match the case and value of the Apply
qualifier (APPLY_QUAL) in the subscription set table. The file naming
convention from Version 5 of DB2 DataPropagator is also supported:
ApplyqualInstance_nameControl_server.pwd; which includes the
case-sensitive Apply qualifier, the instance name that the Apply program
runs under (the default name is DB2, in uppercase), and the name of the
control server in uppercase (for example, COPYDB).
For more information about authentication and security, refer to the IBM DB2
Administration Guide.
Step 7: Replicate the scenario data
After defining the replication source and the subscription set, you can submit
the copy request by starting the Capture and Apply programs.
To start the Capture program:

1. In a Windows NT command prompt window, go to the C:\scripts
directory.
2. Type the following command to start the Capture program using the cold
start option without automatic pruning:
ASNCCP SAMPLE COLD NOPRUNE

Tip: Usually you would not specify the cold start option; you would let
the Capture program determine whether it should cold start or warm
start. For this exercise, you are forcing the Capture program to cold
start to clean up the records in the CD and UOW tables.
The Capture program starts running but no new command prompt appears.
This action creates a *.ccp file. The Capture program is initialized but it does
not start capturing changes for the defined replication source until you start
the Apply program and it completes its initial full-refresh copy.
To start the Apply program:

1. From another Windows NT command prompt window, go to the
C:\scripts directory on the target server where you stored the password
file.
Tip: You must start the Apply program in the same directory in which
you stored the password file. If you try to start the Apply program in
another directory, you will get an error message.
2. Type the following command to start the Apply program:
ASNAPPLY DEPTQUAL COPYDB
Tip: The Apply qualifier, DEPTQUAL, is case-sensitive and must be

entered in uppercase for this exercise.
Tip: You can use the LOADX invocation parameter to call the ASNLOAD
program. Type the LOADX parameter after the database name
(COPYDB) in the command statement above. The default ASNLOAD
program uses the EXPORT utility to export data from the source table
and uses the LOAD utility to fully refresh the target table. You can
modify ASNLOAD to call any IBM or vendor utility.
The Apply program starts running, but no new command prompt appears.
You can check the Apply trail table (ASN.IBMSNAP_APPLYTRAIL) in
COPYDB for status information.
If you view the DEPTCOPY target table after one replication cycle, you should
see results that match the data shown in Table 2.
Table 2. DEPTCOPY table
SERVICE
C01 INFORMATION CENTER 000030 A00 -

Table 2. DEPTCOPY table (continued)
D01 DEVELOPMENT CENTER - A00 -
SYSTEMS
SYSTEMS
E21 SOFTWARE SUPPORT 000100 E01 -
Operating in a replication environment

After the replication environment is up and running, changes that are made to
the replication source will be replicated to the target table. You must prune
the control tables periodically to prevent them from growing too large.
Although the Capture and Apply programs can run continuously, there are
times when you will want to stop them (for example, to run utilities that use
the table spaces that contain the control tables).
Step 1: Update the source table
Assume that two new departments were created at the Spiffy Computer
Service: a technical writing department and a public relations department.
To update the source table:

1. Select Start -> Programs -> DB2 for Windows NT -> Command Window
to open a DB2 command window.
2. Connect to the source server:
3. Add two new rows, one for each department, by typing both of the
following commands:
DB2 INSERT INTO DEPARTMENT VALUES ('F01','TECHNICAL WRITING','000110','F01',NULL)
DB2 INSERT INTO DEPARTMENT VALUES ('G01','PUBLIC RELATIONS','000120','G01',NULL)
4. Connect to the target server:
DB2 CONNECT TO COPYDB
5. Verify that the new rows are replicated to the target database by typing
the following command:
DB2 SELECT * FROM DEPTCOPY
Tip: The replication process does not occur immediately. You should wait
approximately five minutes before checking the table.

Table 3 shows the results of the replication, with two new rows appended to
the table.
Table 3. DEPTCOPY table after changes are replicated
F01 TECHNICAL 000110 F01 -
WRITING
G01 PUBLIC RELATIONS 000120 G01 -
SERVICE
C01 INFORMATION 000030 A00 -
CENTER
D01 DEVELOPMENT - A00 -
CENTER
SYSTEMS
SYSTEMS
E21 SOFTWARE 000100 E01 -
SUPPORT
Step 2: Prune the control tables

The following steps assume that the Capture program is running. If the
Capture program is not running, the prune command will not work.
Tip: On Windows NT, you can use the Task Manager to determine if the
Capture program (ASNCCP) is running.
To verify that there is something to prune:

1. Open a DB2 command window. Use this window for the remainder of the
steps in this exercise.
2. Type the following command to connect to the source server:
3. Check that there are some rows in the unit-of-work table by typing the
following command:
DB2 SELECT COUNT(*) FROM ASN.IBMSNAP_UOW

There should be two rows in the unit-of-work table from the previous
replication.
To run the prune command:

1. Type the prune command; and include the name of the source server:
ASNCMD SAMPLE PRUNE
Tip: Usually you should prune during off-peak hours.

2. Verify that the prune command worked and the unit-of-work table is
empty by typing the following command:
DB2 SELECT COUNT(*) FROM ASN.IBMSNAP_UOW
There should be no rows in the table.

Step 3: Stop the Capture and Apply programs
An important part of maintaining your replication environment is regular
database maintenance. Sometimes that maintenance will require you to stop
the Capture and Apply programs. For example, you must stop the Capture
and Apply programs before you run utilities that directly use the table spaces
that are used by these programs.
Perform the following steps in the DB2 command window that you opened in
the previous step.
To stop the Capture program:
Type the following command: ASNCMD SAMPLE STOP
To stop the Apply program:
Type the following command: ASNASTOP DEPTQUAL (where DEPTQUAL is the

case-sensitive Apply qualifier).
You can run DB2 utilities on your database now that you stopped the Capture
and Apply programs. (Running the utilities is beyond the scope of this
exercise.)

Chapter 4. Data replication tasks
This chapter introduces the key replication tasks that you perform at various
stages in the replication process. The tasks are grouped into these major
stages:
1. Planning your replication requirements
2. Setting up your replication environment
3. Operating in your replication environment
After you read this chapter, go to “Part 2. Administration” on page 59 for
detailed information about these tasks. Also, see “Part 3. Operations” on
page 173 for specific information about using the Capture and Apply
programs on particular operating systems.
Planning your replication requirements

An important step in coming up with the appropriate replication environment
is determining the characteristics of your application data, who needs to
access the data, and how frequently they need to access it.
You can use DB2 data replication to maintain data in more than one location
and keep the various copies of it synchronized. You must determine where
your source data will be coming from. You must decide whether you want all
or some of the source information copied, or whether you want only changes
copied, and how many copies (or targets) you need. You also need to
determine where the copies will be located.
Although you cannot update the source tables and target tables
synchronously, you can schedule the updates to meet the needs of your
applications and your replication environment. The frequency of replication
depends on how much lag time is acceptable between the time that the source
is updated and the time that the targets are updated. Therefore, you must
decide how synchronized the copies must be with the source and with each
other before you can come up with a replication model.
After you understand your application data requirements, you can design the
replication model that will help you meet those requirements. There are many
facts that you need to consider when you design your model. These are some
of the more important decisions that you need to make:
The replication configuration
Based on your data needs, you must decide whether you need a
consolidation, distribution, update-anywhere, or occasionally

connected configuration. You have the flexibility to design your
environment so that it uses one of these configurations or some
combination of them.
Where to locate the control server
You will get slightly better performance if you place the control tables
on the same server as the Apply program instead of placing them
centrally, because the Apply program frequently reads the control
tables at the control server. You can have your Apply programs share
a single control server so that your control information is stored
centrally. The control server can be located at the source server, the
target server, or any database server that the Apply program can
connect to. A central control server is popular because it simplifies the
administration of large networks, but it has two drawbacks: the Apply
program must access the control information over the network and, if
the control server goes down, all of the Apply processes are affected.
However, if the source server is in a secure environment, locating the
control server at the source server can improve security and let you
manage and monitor replication subscriptions centrally.
The type of target tables to use
The type of target table that you use depends on your replication
requirements. Each type is best suited for specific situations. For
example, a replica is the only type of target table that you can use for
update-anywhere replication; and a row-replica is the only type of
target table you can use with DataPropagator for Microsoft Jet.
Whether to use existing target tables
You can let the administration interface create the target table for you
or you can use an existing table as a target. If the existing tables are
DB2 tables, the data types are supported by the DB2 data replication
components. If your replication environment includes non-IBM
databases, some of the data types might not map directly to the
source tables that you are using.
Which columns to make available for replication
You can choose to capture only the after-image column values or both
the before-image column values and the after-image column values. If
you will be using the targets for auditing purposes, or if you have
replica target tables, you must copy both the after-image and
before-image column values.
How to capture SQL operations
You might want to capture all updates as two rows in the CD table or
in the CCD table of a non-IBM source: a DELETE of the before-image
column values followed by an INSERT of the after-image column
values. This includes updates of columns that will be the primary key
of the target, columns that will be the partitioning key of the target, or

columns that are part of the WHERE clause or predicate of the
subscription set. You might need to adjust the size of the CD table to
accommodate this increased overhead.
The level of constraints
You must use referential constraints to enforce referential integrity
only if you have target tables that are replica tables. If you have a
read-only table, you do not need to set constraints at the target. The
referential integrity of other types of target tables is ensured if you
define your subscription sets appropriately.
Which joins to use
Joins are described in views, which in turn are defined in replication
sources. For example, you might use a view to change the name of
copied columns, to reference columns from related tables in the
WHERE clause in your subscription member predicate, to
incrementally maintain copies that are inner joins of two or more
tables, or to replicate information from one table when an update is
made to another table.
When you are ready to plan your replication environment, see “Chapter 5.
Planning for replication” on page 61 for detailed planning information.
Setting up your replication environment

After you design the replication model, you must set up your replication
environment. These steps are involved in setting up your replication
environment:
1. Setting up the system
2. Defining the replication criteria
3. Performing the initial replication
The rest of this section introduces the steps involved in setting up your
environment.“Chapter 6. Setting up your replication environment” on page 93
contains detailed instructions on setting up your replication environment.
Setting up the system
To set up the system, you perform the following steps:
1. Migrate from previous releases of DataPropagator products.
2. Grant access to the proper user IDs.
Setting up the replication criteria
To set up the replication criteria, you perform the following steps:
1. Configure the administration tool. For example, if you are using DJRA,
you need to associate passwords with databases.
2. Customize and create replication control tables.
Chapter 4. Data replication tasks 53

3. Customize change data (CD) tables. This step is optional. You can change
the default name and table space of your CD tables. If you are using the
DB2 Control Center, you must customize your CD tables before you define
a replication source. If you are using the DJRA tool, you customize the CD
tables when you define the replication source.
4. Define replication sources. This step includes identifying the table or view
from which you want data copied and the types of changes that you want
captured.
5. Define subscription sets and subscription-set members. This step includes
associating the replication source with the target to which you want the
changes replicated. You can define subscription sets and subscription-set
members at any time prior to starting the Apply program.
6. Configure the Capture program. This step includes enabling the source
server for logging; it also includes creating and binding the Capture
program package to the source server.
7. Configure the Apply program. This step includes creating and binding the
Apply program package to the source server; the target server, and the
control server, it also includes creating and binding the Apply program to
the target server.11
Performing the initial replication
Important: When you set up your replication environment, you must start the
Capture program and let it initialize fully before you start any Apply
programs.
To perform the initial replication, you must perform the following steps in the
exact order:
1. Make sure that at least one replication source is defined.
2. Start the Capture program. This step includes specifying invocation
parameters (such as NOPRUNE, which prevents automatic pruning of the
CD and UOW tables). After the Capture program is fully initialized, it will
not capture any changes until the Apply program signals it to do so.
3. If you haven’t already done so, define at least one subscription set and one
subscription set member.
4. Start one or more Apply programs. This step includes specifying
invocation parameters (such as LOADX, which calls ASNLOAD—an exit
routine to initialize target tables). Each Apply program will perform a
11. If the Capture program and the Apply program are not on OS/390, they will automatically bind.

full-refresh copy for all subscription-set members and the Capture
program will begin capturing changes for the associated replication
sources.12
Tip: Use the WARMNS option in the Capture program if you want to be able
to repair any problems (such as unavailable databases or table spaces)
that might prevent a warm start from occurring.
Adding to your replication environment
You probably need to add replication sources and subscription sets to your
replication environment from time to time.
To add to your replication environment, you must perform the following steps
in the exact order:
1. Define the new replication source.
2. Run the Capture reinit command, or stop the Capture program and warm
start it.
3. Define the new subscription sets and subscription set members.
4. The Apply program will automatically recognize the new subscription set
if the Apply program is already running and it uses the Apply qualifier
that is associated with the new subscription set. Otherwise, you must start
a new Apply program using the appropriate Apply qualifier before the
Apply program can recognize the new subscription set.
Copying your replication environment
After you define your replication environment on one system (for example, a
test system), you can copy the replication environment to another system (for
example, a production system). You use the promote functions to
reverse-engineer your tables, replication sources, and subscription sets and to
create a script file with the appropriate data definition language (DDL) and
data manipulation language (DML). For more information about the promote
functions, see “Copying your replication configuration to another system” on
page 127 and the on-line help for the administration interface.
Operating in your replication environment

After your replication environment is up and running and updates are
replicated, you need to perform periodic maintenance tasks. These include the
following tasks:
Configuring the pruning of control tables
The UOW and CD tables will grow too large if the contents are not
12. If you use non-IBM load utilities, it is recommended that you use the offline load feature in DJRA. For more
information on setting up the offline load feature with DJRA, see “Loading target tables offline using DJRA” on
page 127.

pruned regularly. You can configure your system to prune
automatically, or you can prune manually. You control how frequently
obsolete information will be removed from these tables. If the tables
aren’t pruned often enough, the table space that they’re in will run
out of space, which will force the Capture program to stop. If they are
pruned too often or during peak times, the pruning interferes with the
change capture process. You can use the optimal pruning frequency
for your replication environment.
Monitoring important criteria
Many factors determine how well your replication environment
performs. You can use the Replication Monitor, which is part of DJRA,
to generate a report that will help you monitor the activities of the
Capture and Apply components, as well as the status of the
subscription sets. For example, the report contains historical
information to help you determine trends about subscription latencies.
Dealing with data modification conflicts
If you are using update-anywhere replication, and you did not design
your configuration to prevent update conflicts, you must handle
update conflicts and rejected transactions.
Performing regular database maintenance
If you want your replication environment to run smoothly, you must
regularly perform database maintenance tasks. For example, use the
RUNSTATS utility against the DB2 catalog tables to collect new
statistics for tables and indexes. Also use the RUNSTATS utility once
after the CD and UOW tables have sufficient data in them so that the
DB2 Optimizer will use indexes on them. Periodically use the REORG
utility (or the RGZPFM command in AS/400) for the change data
tables, the unit-of-work table, and the target tables. You must also
delete rows from the Apply trail table, which contains subscription set
statistics and error information.
Coordinating with DB2 utility operations
If you want to run DB2 utilities (such as REORG, RUNSTATS, BIND
PACKAGE, and REVOKE) that will use the table spaces that contain
the replication control tables, you must stop the Capture and Apply
programs before running the utilities.
Changing your replication configuration as your business needs change
You are likely to need to modify your replication environment from
time to time. Whether you add a new column to an existing source
table, or drop a source table, you will need to modify your replication
criteria. Also, you will need to maintain password files. For more
information about modifying your replication configuration, see
“Modifying your replication configuration” on page 147.

Troubleshooting
If you find that your replication environment is not performing as you
expected, or if you can’t replicate data, you can run the Replication
Analyzer. The Replication Analyzer is a tool that is packaged with
DB2 Universal Database and the DataJoiner Replication
Administration tool. You can use the Replication Analyzer to analyze
the behavior of the Capture program or the Apply program. It can
answer such questions as: ″why is the Capture program not
capturing?″ and ″why is the Apply program not applying?″ The
Replication Analyzer can help diagnose problems, verify replication
setup, and offer suggestions for performance tuning. You can also
look in the Apply trail table for status information about the Apply
program, or in the Capture trace table for status information about the
Capture program. For details see “Chapter 8. Problem determination”
on page 151.
For general information about operating in a replication environment, see

“Chapter 7. Operating DB2 DataPropagator” on page 139. For information
about operating in a particular operating system, see the appropriate chapter
in “Part 3. Operations” on page 173.

Part 2. Administration
“Chapter 5. Planning for replication” on page 61 explains the information you

need to help you design your replication environment.
“Chapter 6. Setting up your replication environment” on page 93 describes the

steps for setting up and starting replication.
“Chapter 7. Operating DB2 DataPropagator” on page 139 describes how to

operate the Capture and Apply programs generally. Platform-specific
information is in “Part 3. Operations” on page 173.
“Chapter 8. Problem determination” on page 151 describes the available

problem-determination facilities.

Chapter 5. Planning for replication
This chapter explains the information that you need to help you design your
replication environment: capacity planning, storage requirements, network
requirements, deciding what to replicate, auditing requirements, staging data,
and planning for migration.
Capacity planning
The Capture program does not generally impact other applications and
requires a minimum of central processing unit (CPU) or central processing
complex (CPC) capacity. For example, you can schedule Capture for OS/390
at a lower priority than the application programs that update the source
tables. In this case, the Capture program lags behind when CPU resource is
constrained.
The Capture program does use CPU resources when it prunes the CD tables
and UOW table, but you can defer this activity to reduce system impact.
The Apply program affects CPU usage depending on the frequency of

replication, that is, on the currency requirement of the target database.
Because the Apply program reads data from the source server and copies that
data to the target server, it uses CPU resources on both systems.
In general, the DB2 Control Center and DJRA do not require many local CPU
resources. However, when you generate the SQL for replication sources and
subscription-set definitions, DB2 DataPropagator extensively searches the
catalogs of the source server. And for large sites, these searches can have a
noticeable CPU or database system impact.
Recommendations: Plan replication administration for times when impact to

the source and target database systems is minimal. Use filtering to minimize
the amount of data returned from the source server.
Storage planning
In addition to the storage required for DB2, replication requires storage for:
Database log and journal data
The additional data logged to support the replication of data.

Active log file size for Capture for VSE and VM and current receiver size
for Capture for AS/400
You need to ensure that the data needed for replication remains on
the active log, rather than on archived logs.
Target tables and control tables
The replicated user data and control tables (including change data
tables).
Spill files
The Apply program requires temporary space to store data. Apply for
OS/390 can use memory rather than disk space for the spill files; the
Apply program for all other operating-system environments uses disk
space for the spill files.
If there is insufficient disk space for the spill files, the Apply program
terminates. If you specify that Apply for OS/390 should use memory,
but there is not enough memory for the spill files, the Apply program
abends; in this case, specify that the Apply program should use disk
space and restart it. For more information about spill files, see “Spill
files” on page 65.
All of the sizes given in the following sections are estimates only. To prepare
and design a production-ready system, you must also account for such things
as failure prevention. For example, the holding period of data (discussed in
“Target tables and control tables” on page 63) might need to be increased to
account for potential line outage.
If storage estimates seem unreasonably high, reexamine the frequency interval

of the Apply program (how often your subscriptions run) and pruning.
Trade-offs frequently must be considered between storage usage, capacity for
failure tolerance, and CPU overhead.
Database log and journal data
Before you can replicate a table, you must create it (or alter it) with the DATA
CAPTURE CHANGES keywords. One of the effects of these keywords is that
DB2 logs full-row images for each UPDATE statement. For a replica table (in
an update-anywhere scenario), DB2 also logs the before-images for each
update to the table. Another increase to the log or journal volume comes from
DB2’s logging insertions to and deletions from the unit-of-work (UOW) and
change data (CD) tables.
Although estimating the increase in the log or journal volume is not easy, in
general you will need an additional three times the current log volume for all
tables involved in replication.
To make a more accurate estimate, you must have detailed knowledge of the
updating application and the replication requirements. For example, if an

updating application typically updates 60% of the columns in a table, the
replication requirements could cause the log records to grow by more than
half compared to a similar table that is not replicated. One of the replication
requirements that adds the most to the log is the capturing of before- and
after-images (as in the case of update-anywhere replication scenarios). One
way to reduce the log volume is to reduce the number of columns defined for
the replication source.
In addition to logging for the source database, there is also logging for the
target database, where the rows are applied. Because the Apply program does
not issue interim checkpoints, you should estimate the maximum amount of
data that the Apply program will process in one time interval and adjust the
log space (or the space for the current receiver for AS/400) to accommodate
that amount of data.
Active log file size for Capture for VSE and VM and current receiver size
for Capture for AS/400
For VM and VSE, when the active log is full, DB2 archives its contents. For
AS/400, when the current receiver is full, the system switches to a new one;
you can optionally save and delete old ones no longer needed for replication.
When a system handles a large number of transactions, the Capture program
can occasionally lag behind. If the log is too small, some of the log records
could be archived before they are captured. Capture for VSE and VM running
with DB2 for VSE & VM cannot recover archived log records. 13
For DB2 for VSE & VM, ensure that your log is large enough to handle at
least 24 hours of transaction data. For DB2 for AS/400, ensure that the current
receiver is large enough to handle at least 24 hours of data.
Target tables and control tables
The space required for a target table is usually no greater than that of the
source table (or tables), but can be much larger if the target table is
denormalized or includes before images (in addition to after-images) or
history data. The following also affect the space required for a target table: the
number of columns replicated, the data type of columns replicated, any row
subsets defined for the subscription-set member, and data transformations
performed during replication.
The CD tables and the UOW table also affect the disk space required for a
source database. The space required for the replication control tables is
generally small because each requires only a few rows.
13. Capture for OS/390 running with DB2 for MVS/ESA V4 or higher and DB2 Universal Database V5 or later can
recover archived log records.
Chapter 5. Planning for replication 63

The CD tables grow in size according to the amount of data replicated until
the Capture program prunes them. To estimate the space required for the CD
tables, first determine how long you want to keep the data before pruning it,
then specify how often the Capture program should prune these tables or
how often you issue the prune command. To determine the minimum size for
the CD table, use the following formula:
minimum_CD_size =
( (21 bytes) + sum(length of all registered columns) ) *
(number of inserts, updates, and deletes to source table) *
(exception factor)
When calculating the number of bytes of data replicated, you need to include
21 bytes for overhead data added to the CD tables by the Capture program. In
the formula, determine the number of inserts, updates, and deletes to the
source table within the interval between capturing and pruning of data. The
exception factor allows for such things as network failures or other failures
that prevent the Apply program from replicating data. Use a value of 2
initially, then refine the value based on the performance of your replication
environment.
Example: If the Capture program prunes applied rows from the CD table once
daily, your interval is 24 hours. If the rows in the CD table are 100 bytes long
(plus the 21 bytes for overhead), and 100,000 updates are applied during a
24-hour period, the storage required for the CD table is about 12 MB.
The maximum size of a CD table is dependent on the maximum number of

columns and maximum size of a row allowed by DB2 for a particular
platform. Table 4 shows how to calculate the maximum size for a CD table.
For replica tables, you must divide the maximum number of columns and
maximum row length by two, because the CD table for a replica table
includes columns for before images.
Table 4. Calculating maximum size for a CD table. The value maxCols represents the
maximum number of columns allowed by DB2 for a table; the value maxLength
represents the maximum row length allowed by DB2.
For read-only target tables For read-write (replica)
target tables
Number of columns maxCols – 3 columns (maxCols – 3 columns) / 2
Row length maxLength – 21 bytes (maxLength – 21 bytes) / 2
The UOW table grows and shrinks based on the number of rows inserted in a
particular time interval (the number of commits issued within that interval by
transactions that update source tables or by Capture for AS/400). You should
initially overestimate the size required and monitor the space actually used to
determine if any space can be recovered. The size of each row in the UOW

table is fixed at 79 bytes (except for DB2 for AS/400, where it is 109 bytes).
For a first approximation of the space needed for the UOW table, multiply 79
bytes (or 109 bytes) by the number of updates applied during a 2-hour period.
Use a formula similar to the one given above for CD tables to obtain a better
estimate for the space needed for the UOW table. For more information, see
“Unit-of-work table” on page 319.
Spill files
The Apply program stores updates to target tables in temporary files called
spill files. 14 These files hold the updates until the Apply program applies
them to the target tables. The Apply program uses multiple spill files for
subscription sets with multiple subscription-set members: one spill file for
each target table. The Apply program stores the spill file on disk for every
operating-system environment, but Apply for OS/390 can use virtual memory
instead. Unless you have virtual memory constraints, store the spill files in
virtual memory rather than disk.
The size of the spill file is equal to the size of the data selected for replication
during each replication interval. You can estimate the size of the spill file by
comparing the frequency interval (or data-blocking interval; see “Data
blocking for large volumes of changes” on page 68) planned for the Apply
program with the volume of changes in that same time period (or in a peak
period of change). The spill file’s row size is the target row size, including any
DB2 DataPropagator overhead columns. This row size is not in DB2 packed
internal format, but is in expanded, interpreted character format (as fetched
from the SELECT). The row also includes a row length and null terminators
on individual column strings.
Example: If change volume peaks at 12,000 updates per hour and the Apply
program frequency is planned for one-hour intervals, the spill file must hold
one-hour’s worth of updates, or 12,000 updates. If each update represents 100
bytes of data, the spill file will be about 1.2 MB.
Network planning
This section describes connectivity requirements, discusses where to run the
Apply program (using the push or pull configuration), and describes how
data blocking can improve performance.
Connectivity
Because data replication usually involves physically separate databases,
connectivity is important to consider during the planning stages. The
workstation that runs the DB2 Control Center or DJRA must be able to
14. If you are using the ASNLOAD utility, you have a load input file instead of a load spill file.

connect to the control, source, and target server databases to perform their
tasks. And the Apply program must be able to connect to the control, source,
and target server databases.
When the databases are connected to a network, connectivity varies according

to the platforms being connected:
v For connections between DB2 Universal Database databases, your choices
are TCP/IP, SNA, NetBIOS, or IPX/SPX.
v For connections between DB2 Universal Database databases and DB2 for
OS/390, DB2 for VSE, or DB2 for VM databases, you need DB2 Connect
Personal Edition (or DB2 Connect Enterprise Edition) on the same
workstation as the database to which you are connecting, or you need DB2
Connect Enterprise Edition (or DB2 Universal Database Enterprise Edition)
available through your network. You can use TCP/IP or SNA for any of the
following: DB2 for OS/390 V5 or later, AS/400 V4R2 or later, or DB2 for
VM V5 or later. For all other connections, you can only use SNA.
If you use password verification for DB2 for OS/390, use Data
Communication Service by adding DCS to the CATALOG DB statement. If
you connect using SNA, add SECURITY PGM to the CATALOG APPC NODE
statement. However, if you connect using TCP/IP, there is no equivalent
security keyword for the CATALOG TCPIP NODE statement.
If your replication design involves staging data at a server that is different

from the source database, you must carefully consider the communications
between the various servers. For example, in an occasionally-connected
replication scenario between DB2 Universal Database running on Windows 95
on a laptop PC and DB2 for OS/390, a good connectivity scenario might be
for the Windows 95 PC to dial a local server (for example, an AIX server with
DB2 Universal Database Enterprise Edition) using TCP/IP over a modem. The
AIX workstation then connects to DB2 for OS/390 to fulfill the request from
the Windows 95 machine.
Be sure to limit the layers of emulation, LAN bridges, and router links
required, because these can all affect replication performance.
Where to run the Apply program: push or pull configuration
You can run the Apply program at the source server or at the target server.
When the Apply program runs at the source server, you have a push
configuration: the Apply program pushes updates from the source server to the
target server. When the Apply program runs at the target server, you have a
pull configuration: the Apply program pulls updates from the source server to
the target server.
The Apply program can run in either or both configurations at the same time:
it can push updates for some subscription sets and pull updates for others.

If the target table is in a non-IBM database, the Apply program connects to a
DB2 DataJoiner database (with DB2 DataJoiner connected to the non-IBM
database) and applies the changes to the target table using DB2 DataJoiner
nicknames. In this case, the Apply program pushes updates from the DB2
DataJoiner source server to the target server or pulls updates from the DB2
DataJoiner source server to the target server. The Apply program cannot push
or pull directly from the non-IBM server.
Figure 16 shows the differences between the push and pull configurations.
Figure 16. Push versus pull configuration
In the push configuration, the Apply program connects to the local source
server (or to a DB2 DataJoiner source server for non-IBM sources) and
retrieves the data. Then, it connects to the remote target server and pushes the
updates to the target table. The Apply program pushes the updates row by
row, and cannot use DB2’s block-fetch capability to improve network
efficiency.
In the pull configuration, the Apply program connects to the remote source
server (or to a DB2 DataJoiner source server for non-IBM sources) to retrieve
the data. DB2 can use block fetch to retrieve the data across the network
efficiently. After all data is retrieved, the Apply program connects to the local
target server and applies the changes to the target table.

Generally, a pull configuration performs better than a push configuration
because it allows more efficient use of the network. However, under the
following circumstances a push configuration is a better choice:
v When there is no Apply program for the target server platform, for
example, as with VSE or VM.
v When you use remote journaling or relative record numbers (RRN) on your
AS/400 source servers and the target server is a non-AS/400 system.
v The source table changes very infrequently, but when it does change it
should be replicated as soon as possible.
To set up a push or pull configuration you need only to decide where to run
the Apply program. DB2 DataPropagator, the DB2 Control Center, and DJRA
recognize both configurations.
Data blocking for large volumes of changes
Replication subscriptions that replicate large blocks of changes in one Apply
cycle can cause the spill files or log (for the target database) to overflow. For
example, batch-Apply scenarios can produce a large backlog of enqueued
transactions that need to be replicated. Or, an extended outage of the network
can cause a large block of data to accumulate in the CD tables, which can
cause spill-file overflows.
Use the Data Blocking page of the Subscription Timing notebook in the DB2
Control Center or the Blocking factor field of the Create Empty Subscription
Sets window in DJRA to specify how many minutes worth of change data the
Apply program can replicate during a subscription cycle. The number of
minutes that you specify determines the size of the data block. 15 This value is
stored in the MAX_SYNCH_MINUTES column of the Subscription set table. If
the accumulation of change data is greater than the size of the data block, the
Apply program converts a single subscription cycle into many mini-cycles,
reducing the backlog to manageable pieces. It also retries any unsuccessful
mini-cycles and will reduce the size of the data block to match available
system resources. If replication fails during a mini-cycle, the Apply program
retries the subscription set from the last successful mini-cycle. Figure 17 on
page 69 shows how the changed data is broken down into subsets of changes.
15. If your subscription set includes tables with DATALINK columns, this value also specifies the number of files
passed to the ASNDLCOPY exit routine.

Figure 17. Data blocking. You can reduce the amount of network traffic by specifying a
data-blocking value.
By default, the Apply program uses no data blocking, that is, it copies all
available committed data that has been captured. If you set a data-blocking
value, the number of minutes that you set should be small enough so that all
transactions for the subscription set that occur during the interval can be
copied without causing the spill files or log to overflow. For AS/400, ensure
that the total amount of data to be replicated during the interval does not
exceed 4 MB.
Restrictions:
v You cannot split a unit of work.
v You cannot roll back previous mini-subscription cycles.
v You cannot use data blocking for full refreshes.
Deciding what to replicate

As part of planning for replication, you need to consider how the data will be
used at the target site. Often, the source data will need to be subsetted,
transformed, or enhanced for decision-support or data-warehousing
applications. This section sorts these requirements into those that are easily
fulfilled by using the DB2 Control Center or DJRA, and those that require
direct manipulation of the control tables.

The Control Center and DJRA support the following data manipulations:
v Subsetting columns and rows
v Replicating joins using views
v Replicating before and after images
v Renaming columns
v Creating computed columns
v Using stored procedures for before and after run-time processing
The following sections describe the data manipulations that you can perform
using the Control Center or DJRA. This chapter also describes replicating
large-object (LOB) data, limits for column names for before-image data, and
data-type restrictions.
Subsetting columns and rows
IBM Replication supports both column (vertical) and row (horizontal)
subsetting of the source table. This means that you can specify that only a
subset of the source table columns and rows be replicated to the target table,
rather than all of the columns and rows:
Column subsetting
In some replication scenarios, you might not want to replicate all
columns to the target table, or the target table might not support all
data types defined for the source table. You can define a column
subset that has fewer columns than your source table. Column
subsetting is available for all tables except replica tables.
You can define column subsetting at one of two times:
v When you define a replication source table for differential refresh.
Select only those columns that you want to make available for
replication to a target table. Because CD tables must contain
sufficient key data for point-in-time copies, you must include
primary-key columns in your subset. The columns that you do not
select will not be available for replication to any target table.
v When you define a subscription set.
For the Control Center, use the advanced subscription options to
select only those columns that you want to replicate to the target
table. For DJRA, you can select the columns when you add
members to the subscription set. The columns that you do not select
are still available for other subscription sets, but are not included
for the current subscription set.
Recommendation: When you define a replication source, select all
columns (that is, do not subset any of them). Create your column
subsets when you define subscription sets. By defining your column

subsets in the subscription sets rather than in the replication sources,
you will not have to redefine your replication sources if your
subscription requirements change.
Row subsetting
In some replication scenarios, you might want to replicate different
data from a source table to several target tables. You can define a row
subset that contains rows matching a certain condition (a WHERE
clause), for example, all rows for department “J35”.
Use the advanced subscription options to define a WHERE clause
when you define the subscription. All target table types support row
subsetting.
If the primary key values of the target table will be updated, or the
table (or view) contains a logical partitioning column that will be
updated, you must specify replication logical-partitioning-key support
when you define the replication source. Replication
logical-partitioning-key support performs an UPDATE as a DELETE
followed by an INSERT. See “Enabling replication
logical-partitioning-key support” on page 109 for more information.
Replicating joins using views
Join views fill many requirements, both for denormalizing (restructuring)
copies in data-warehouse scenarios, which enables simpler queries of copied
data, and also for addressing the routing problem, sometimes called the
database partitioning problem in distributed computing scenarios.16 Views are
also useful when you need to specify predicates for a row subset that exceed
512 bytes (the capacity of the PREDICATES column of the
subscription-targets-member control table). Thus, you can choose to manage
your subset predicates using views rather than as part of the subscription-set
definition.
To define a join view as a replication source using the Control Center, first
define all tables that participate in the join as replication sources (you do not
need to define subscriptions for them). To define a join view as a replication
source using DJRA, you can use existing views or you can define a join view
that includes tables that are not defined as replication sources. You can use
the Control Center or DJRA to define the view as a replication source; see
“Defining views as replication sources” on page 108. If the replication sources
defined in the join have CD or CCD tables, the Control Center or DJRA
creates a CD view from the replication sources’ CD tables.
16. For example, knowing where to send a bank account update may require a join of the account table with the
customer table to determine which branch of the bank the customer deals with. Typically, production databases
are normalized so that the geographic details, such as branch-number, are not stored redundantly throughout the
database.

IBM Replication supports the following types of view definitions:
v Simple views over a single table
Only views of tables that reside within DB2 databases are supported. Views
of tables that are stored on Oracle, Microsoft SQL Server, Sybase, Sybase
SQL Anywhere, Informix, or Teradata are not supported.
When defining DB2 views as a replication source, create them using a
correlation ID.
v Simple inner-joins over one or more defined replication sources
v Simple inner-joins over one or more CCD staging tables17 that are defined
as replication sources and maintained by an Apply program or an
application other than an IBM Replication component and an external data
source, such as IMS DataPropagator with IMS™ source data
Tip: If you define a view that includes two or more source tables as a
replication source, also define a CCD table for one of the source tables in the
join. This CCD table should be condensed and non-complete (or it can be
complete) and should be located on the target server. A view that includes
more than two source tables can be subject to the problem of “double deletes”
which DB2 DataPropagator cannot replicate.
For example, if you define a view that contains the CUSTOMERS table and
the CONTRACTS table, and if you delete a row from the CUSTOMERS table
and also delete the corresponding row (from the join point of view) from the
CONTRACTS table during the same replication cycle, you have a double
delete. The problem is that, because the row was deleted from the two source
tables of the join, the row does not appear in the views (neither base views or
CD-table views), and thus the double-delete cannot be replicated.
Defining a condensed and non-complete CCD table for one of the source
tables in the join solves this problem because you can use the
IBMSNAP_OPERATION column of this CCD table to detect the deletes. You
can add an SQL statement to the definition of the subscription set that should
run after the subscription cycle. This SQL statement removes all the rows from
the target table for which the IBMSNAP_OPERATION is equal to “D” in the
CCD table.
Replicating before and after images
You can define both before and after images in your replication sources and
subscriptions. A before-image column is a copy of a column before it is
updated, and an after-image column is a copy of a column after it is updated.
DB2 logs both the before-image and after-image columns of a table for each
change to that table. Replicating before images is required for
17. The CCD tables for simple inner-joins must be complete and condensed. See “Staging data” on page 82.

update-anywhere scenarios when you define the replica with standard or
enhanced conflict detection; in this case, the before images provide the
required information for automatic compensation of rejected transactions.
Replicating before images can also be useful for auditing purposes.
The before and after images have different values for different actions
performed against the target tables, as shown below:
Action Column Value
Full refresh All before-image columns have a NULL value.
Insert The before-image column has a NULL value.
Update Column values before the change are captured in the
before-image columns; values after the change are in the
after-image columns.
When you enable logical-partitioning key support, the
before-image column appears in the deleted column and the
after-image column appears in the inserted column. See
“Enabling replication logical-partitioning-key support” on
page 109 for more information.
Delete Both the before-image and after-image columns contain the
before-image value.
Before images do not make sense for base aggregate target-table types (there
is no before image for computed columns). All other target-table types can
make use of before-image columns.
Restriction: For columns that have a before-image defined, DB2

DataPropagator limits column names to 17 characters. Because DB2
DataPropagator adds a before-image column identifier (usually X) to target
tables and because you must ensure that each column name is unique, you
cannot use longer column names for those tables you replicate. For tables you
do not plan to replicate, you can use longer column names, but consider using
17-character names in case you might want to replicate these tables in the
future. For tables in DB2 for OS/390, you can use 18-character column names,
but DB2 DataPropagator will replace the 18th character with the before-image
column identifier in target tables, so you must ensure that the first 17
characters of the name are unique.
Renaming columns
You can rename columns for point-in-time and user-copy target-table types.
For other table types, you must define views in order to rename columns.

Creating computed columns
Using SQL, you can derive new columns from existing source columns. For
aggregate target-table types, you can define new columns by using aggregate
functions such as COUNT or SUM. For other table types, you can define new
columns using SQL expressions.
You can also create computed columns by referring to user-defined functions

when you create a view that will be used a replication source.
Using stored procedures for before and after run-time processing
You can define run-time processing statements using SQL statements or stored
procedures that can run before or after the Apply program processes a
subscription set. Such statements can be useful for pruning CCD tables and
controlling the sequence in which subscription sets are processed. You can run
the run-time processing statements at the source server before a subscription
set is processed, or at both the source and target servers before or after a
subscription set is processed. For example, you can execute SQL statements
before retrieving the data, after replicating it to the target tables, or both.
Stored procedures use the SQL CALL statement without parameters. The
procedure name must be 18 characters or less in length (for AS/400, the
maximum is 128). If the source table is in a non-IBM database, DB2 DataJoiner
processes the SQL statements. The run-time procedures of each type are
executed together as a single transaction. You can also define acceptable
SQLSTATEs for each statement.
Depending on the DB2 platform, the SQL before and after processing
statements can perform other processing, such as calling stored procedures.
Replicating large objects
DB2 Universal Database supports large object (LOB) data types, which
include: binary LOB (BLOB), character LOB (CLOB), and double-byte
character LOB (DBCLOB). This section refers to all of these types as LOB data.
The Capture program reads the LOB descriptor to determine if any data in
the LOB column has changed and thus should be replicated, but does not
copy the LOB data to the CD tables. When a LOB column changes, the
Capture program sets an indicator in the CD tables. When the Apply program
reads this indicator, it then copies the entire LOB column (not just the
changed portions of LOB columns) directly from the source table to the target
table.
To allow the Capture program to detect changes to LOB data, you must
include the DATA CAPTURE CHANGES keywords when you create (or alter)
the source table.

Because a LOB column can contain up to two gigabytes of data, you must
ensure that you have sufficient network bandwidth for the Apply program.
Likewise, your target tables must have sufficient disk space to accommodate
LOB data.
Restrictions:
v The Apply program always copies the most current version of a LOB
column directly from the source table (not the CD table), even if that
column is more current than other columns in the target table. Thus, there
is a small period of time during which the target row that includes a LOB
column could be inconsistent with the rest of the row. To reduce this small
period of time, ensure that the interval between Apply cycles is as small as
practical for your application.
v To copy LOB data between DB2 for OS/390 V6 (or later) and DB2 Universal
Database (for any other operating system), you need DB2 Connect 5.2 or
later.
v You can copy LOB data only to read-only tables. Thus, you cannot replicate
LOB data to replica or row-replica tables.
v The primary key for the source table and the subscription-set definition
must match. Code-page differences that affect key values can inhibit the
Apply program’s ability to locate the source-table row that contains LOB
data.
v You cannot refer to LOB data using nicknames.
v Before-image values for LOB columns are not supported.
v For DB2 for OS/390, any table that contains LOB columns must also
contain a ROWID column.
v Replication is not supported for DB2 Extenders™ for Text, Audio, Video,
Image, or other extenders where additional control files associated with the
extender’s LOB column data are maintained outside of the database.
v DB2 can replicate only a full LOB; it cannot replicate parts of a LOB.
Replicating DATALINK values
Accessing large files (such as multimedia data) over a remote network can be
inefficient and costly. If these files do not change, or change infrequently, you
gain faster access to the files and reduced network traffic by replicating these
files to remote sites. DB2 Universal Database provides a DATALINK data type
that allows the database to control access, integrity, and recovery for these
kinds of files. DB2 Universal Database supports DATALINK values on all
platforms except OS/390.
DB2 replicates DATALINK columns and uses the ASNDLCOPY user exit
routine to replicate the external files to which the DATALINK columns point.
This routine transforms each source link reference to a target link reference
and copies the external files from the source system to the target system. In

the sqllib/samples/repl directory, you can find a sample routine
(ASNDLCOPY.SMP) that can use FTP or the file-copy daemon
(ASNDLCOPYD.SMP) for the file transfer. For AS/400, you can find the
sample programs in the files QCSRC, QCBLLESRC, and QRPGLESRC in
library QDPR. See “Using the ASNDLCOPY exit routine” on page 133 and
“Using the ASNDLCOPYD file-copy daemon” on page 136.
Because external files can be very large, you must ensure that you have
sufficient network bandwidth for both the Apply program and whatever
file-transfer mechanism you use to copy these files. Likewise, your target
system must have sufficient disk space to accommodate these files.
Recommendation:
v Use a separate subscription set for DATALINK columns because the Apply
program waits for the ASNDLCOPY routine to complete its replication
before the Apply program completes replication of the subscription set. Any
failures in copying the external files will cause replication of the entire
subscription set to fail.
Restrictions:
v Because of the way DB2 supports DATALINK values, you can replicate
DATALINK values between DB2 databases on the following operating
systems:
– AIX
– AS/400
– Windows NT
You cannot replicate DATALINK values to platforms that do not support
them.
v If you use update-anywhere replication with DATALINK columns, you
must specify None for the conflict-detection level. DB2 does not check
update conflicts for external files pointed to by DATALINK columns.
v Before-image values for DATALINK columns are not supported.
v DB2 always replicates the most current version of an external file pointed to
by a DATALINK column.
v Target tables that are base-aggregate or change-aggregate tables do not
support DATALINK columns.
Key-update restrictions
If you are replicating to condensed target tables (user copy, point-in-time,
condensed CCD, or replica tables), do not use the syntax SET
KEYCOL=KEYCOL + n for updates. Data cannot be replicated correctly with
this form of key update. Use a different column in the source table as the key

in the subscription set. If no alternate key exists in the source table, you can
still replicate your data correctly using the following method:
1. Create a new column in the source table.
2. Assign unique values in the new column for the existing rows.
3. Define the table as a replication source.
4. Include the new key column in the subscription set for any condensed
target tables.
5. Whenever rows are inserted into the source table, assign unique key
values to the new column.
General restrictions for replication
Currently, DB2 DataPropagator has specific restrictions for certain
operating-system environments and for certain data types. The major
restrictions are:
v Table name length: DB2 supports table names and user IDs up to 30
characters in length, but replication only supports a length of 18 characters.
v Archive-log access restrictions with DB2 for VSE & VM
Allocate sufficient disk space for the active log because Capture for VSE
and Capture for VM cannot read archived logs.
v Data compression restrictions with DB2 for MVS/ESA
DB2 DataPropagator can replicate data that is compressed through DB2
software or hardware compression on DB2 for MVS/ESA V4 (or later) if the
dictionary used to compress the data is available. Before issuing REORG for
compressed replication sources, you must either:
– Ensure that the Capture program completed capturing all existing
changes.
– Use the KEEPDICTIONARY option on the REORG command to preserve
the existing compression dictionary.
DB2 DataPropagator cannot replicate data that is compressed using
EDITPROC or FIELDPROC.
v Restrictions using DB2 Enterprise - Extended Edition
DB2 Enterprise - Extended Edition can be a target server for the Apply
program. Also, DB2 Enterprise - Extended Edition can be the middle tier in
a 3–tier configuration. For example, you can capture changes at one
database (tier 1) and replicate them to a CCD table in a DB2 Enterprise -
Extended Edition database (tier 2), and then replicate the changes from the
CCD table to another database (tier 3).
You can capture changes on DB2 Enterprise - Extended Edition only if the
source table is nonpartitioned and it resides on the catalog node. Any
replication control tables must also be nonpartitioned and reside on the
catalog node.

The Control Center does not allow you to select DB2 Enterprise - Extended
Edition objects as replication sources or make them part of a subscription
set. However, DJRA does allow them.
v Restriction using AS/400 remote journaling
Because of how communications are handled, you can use DB2
DataPropagator with remote journaling and any SNA connection or you can
use DB2 DataPropagator with DRDA and any TCP/IP connection. Other
combinations are not supported.
v Restriction for partitioning keys
For DB2 for MVS V4 or earlier, if you have a target-tablespace partitioning
key, it must match the primary key.
v Restriction for stored procedures
DB2 DataPropagator does not capture stored-procedure calls, but does
capture row updates caused by stored procedures.
v Restrictions for referential constraints
DB2 DataPropagator only supports referential constraints for user tables
and replica tables.
DB2 DataPropagator does not support the following keywords of the SQL
CREATE TABLE statement for replica tables that are subject to
compensation: DELETE CASCADE, DELETE RESTRICT, and UPDATE
RESTRICT.
v Utility program restrictions
DB2 DataPropagator cannot capture updates made by any of the database
utilities. DB2 DataPropagator also cannot capture updates to data loaded
with the LOAD RESUME LOG YES options.
v Data encryption restrictions
DB2 DataPropagator cannot replicate data that is encrypted.
v Data type restrictions
DB2 DataPropagator cannot replicate the following data types under any
circumstances:
– Any column on which a VALIDPROC is defined
– Binary data types with precision
DB2 DataPropagator can replicate the following data types under certain
circumstances:
– Long variable graphic (LONG VARGRAPHIC) data requires that the
source and target tables be in DB2 for MVS/ESA, DB2 for VSE, or DB2
for VM.
– Long variable character (LONG VARCHAR) data requires either that the
source tables be in DB2 for OS/390 or both the source and target tables
be in DB2 Universal Database (for Windows, OS/2, and UNIX) Version

5.2 or later. See the Alter Table section of the DB2 Universal Database
SQL Reference to learn how to enable LONG VARCHAR data.
– Binary large objects (BLOBs), character large objects (CLOBs), and
double-byte character large objects (DBCLOBs) require DB2 for OS/390
V6 (or later) or DB2 for AS/400 V7 (or later). See “Replicating large
objects” on page 74.
– DB2 DataPropagator cannot capture changes to ASCII or Unicode tables
on DB2 for OS/390. DB2 DataPropagator can perform full refresh using
ASCII or Unicode tables.
User-defined data types (distinct data types in DB2 Universal Database) are
converted to the base data type before replication.
v DB2 DataJoiner restrictions
You must have one DB2 DataJoiner database for each non-IBM source
server. Although you can use one DB2 DataJoiner database for replicating
data to multiple non-IBM target servers, you need a unique DB2 DataJoiner
database for each non-IBM source server.
For DataJoiner for AIX, replication from Microsoft SQL Server 6.0 and 6.5
must use a DBLIB connection; for DataJoiner for NT, replication from
Microsoft SQL Server 6.5 must use the ODBC protocol.
When the data source is Sybase or Microsoft SQL Server and the source
table has a column of type timestamp, do not select before and after images
when you define the table as a replication source. SQL Server allows only
one column of type timestamp. If you require the before and after images,
do not select the column of type timestamp when defining the replication
source.
When the data source is Oracle, do not select before and after images if the
source table has column of type LONG. An Oracle table can contain only
one column of type LONG.
DJRA does not support replication of LOB columns in a heterogeneous
environment.
DJRA does not support update anywhere replication in a heterogeneous
environment.
You do not need to define nicknames for Microsoft Jet or Microsoft Access
tables in DB2 DataJoiner. See “Using DB2 DataPropagator for Microsoft Jet”
on page 280.
If you run DJRA in a Windows 9x environment, and you experience
TCP/IP-related connection problems (for example, a connection failure can
make client applications appear to be frozen), you can set network options
to control the interval before failure is detected. These are system-wide
parameters and can impact all TCP/IP applications. To set these options,
edit TCP/IP parameters in the Windows Registry. Be sure to back up your
Registry before making changes.

Recommendations for Informix:
– Enable transaction logging for Informix databases involved in replication.
– To set the synchpoint granularity to show fractions, set USEOSTIME in
the onconfig file (usually in the $INFORMIXDIR/etc directory) to 1. If it
is not set to 1, Informix displays only zeroes for the fraction.
Capture triggers for non-IBM sources

Capture triggers are used for replication from non-IBM databases. They
capture changed data from a source table and make the changed data
available for replication. Capture triggers perform the same task as the
Capture program does for DB2, but in a different manner. DJRA generates the
Capture triggers.
DJRA, working through DB2 DataJoiner, creates Capture triggers at the

non-IBM source database when you define the source tables as replication
sources. Capture triggers capture committed changes made to source data and
place the captured changes into a staging table, called the consistent change
data (CCD) table. DB2 DataJoiner has a nickname for the CCD table, and
programs that want to replicate the changes (for example, the Apply program)
can access this nickname. See “Staging data” on page 82 for more information
about CCD tables.
There are three triggers for each source table: DELETE, UPDATE, and INSERT.
How the Capture triggers capture the data changes
The Capture triggers work with the following objects: the CCD table, the
register control table, the pruning control table, and the register
synchronization control table.
DJRA generates SQL (when you define a table as a replication source) that,
when run:
v Creates Capture triggers on the source table.
v Creates the CCD table on the source server. There is one CCD table for each
source table.
v Inserts a row into the register control table (to represent the new source
table).
v Creates a nickname for the CCD table in the DB2 DataJoiner database.
Whenever a delete, update, or insert operation occurs at the defined source, a

Capture trigger records the change into the CCD table. When the Capture
triggers retrieve changed information, they can also obtain before and after
column data to put into the CCD table.

If the primary key values of the target table will be updated, or the table (or
view) contains a logical partitioning column that will be updated, you must
specify replication logical-partitioning-key support when you define the
replication source. Replication logical-partitioning-key support performs an
UPDATE as a DELETE followed by an INSERT. See “Enabling replication
logical-partitioning-key support” on page 109 for more information.
The Apply program then reads the CCD table (through DB2 DataJoiner
nicknames), copies the changes to the target server, and applies the changes to
the target table. Figure 18 shows the relationship between the Capture
triggers, the source table, the register control table, and the CCD table.
Figure 18. Capture triggers at the source server. The Capture triggers monitor source changes,
capture the changed data, and write the changed data to the CCD table.
Capture Triggers and pre-existing triggers

When DJRA creates and places Capture triggers on a non-IBM database, you
might encounter the following situations:
v On Oracle: If an attempt is made to create a Capture trigger on a table
where there is a pre-existing trigger with the same name, or where the
pre-existing trigger performs an identical event (insert-before, insert-after,
delete-before, delete-after, update-before, update-after), Oracle issues the
following message: ORA-04081 (trigger name already exists). If this error is
generated, the Capture trigger is not created.

v On Informix: If an attempt is made to create a Capture trigger on a table
where there is a pre-existing trigger with the same name, or where the
pre-existing trigger performs an identical event (insert, delete, update),
Informix issues an -741 error and will not create the Capture trigger.
v On Microsoft SQL Server or Sybase: If an attempt is made to create a
Capture trigger on a table where there is a pre-existing trigger with the
same name, or where the pre-existing trigger performs an identical event
(insert, delete, update), Microsoft SQL Server and Sybase do not generate
error or warning messages indicating a conflict. Microsoft SQL Server and
Sybase replace the pre-existing trigger with the new Capture trigger.
However, DJRA does check to see if a trigger already exists. If a trigger
with the same events exists, DJRA creates the new triggers but all lines
within the trigger body are commented out. You must determine how you
want to merge pre-existing triggers with the new triggers. Then you can
uncomment the lines in the new triggers.
Recommendation: If you anticipate conflict between DJRA’s Capture triggers
and pre-existing triggers, put the content of both triggers into one trigger. For
each table event, append the pre-existing business trigger to the end of the
Capture trigger script that is generated by DJRA.
Staging data
Typically during replication, changes to a source table are captured, the
changed rows are inserted into the CD table, and the related transaction
information is inserted into the UOW table. The CD table is joined with the
UOW table to determine which changes are committed and can therefore be
replicated to target tables. This joined output can be saved in a CCD table
from which changed data information can also be read. A CCD table contains
committed changes only. By using a CCD table, several subscription sets (and
their members) can refer to that information without each incurring overhead
for a join of the CD and UOW tables for each subscription cycle.18
There are other uses for CCD tables apart from eliminating the need to join
the CD and UOW tables. When you set up your replication environment, you
can choose the type of CCD table that is appropriate for your replication
environment. To help you determine whether or not you need to use CCD
tables, this section describes the attributes of CCD tables and the typical uses
of CCD tables.
Attributes of CCD tables
If you want to use a CCD table, you must decide where you want it located
and what change data it must contain.
18. CCD tables are not used in update-anywhere replication.

Local versus remote CCD tables
A local CCD table resides in the source database. A remote CCD table resides
away from the source database; that is, in any other database in the network
that the Apply program can access. If you have many remote targets, you can
use a remote CCD table as the source table to reduce network traffic from the
source.
Complete versus noncomplete CCD tables

A complete CCD table contains all rows that satisfy the source view and
predicates from the source table or view. The Apply program uses a complete
CCD table as the source for full refreshes or to replicate changes to other
target tables.
A noncomplete CCD table contains only changes that were made to the source
table. Thus, a noncomplete CCD table is initially empty and is populated as
changes are made to the source table. When a noncomplete CCD table is
initially created, or when the Capture program is cold started, the Apply
program does not refresh a noncomplete CCD table with all the rows of the
source table.19 The Apply program records changes that are made to the
source table but does not replicate the original rows. The Apply program
cannot use a noncomplete CCD table to refresh other target tables.
Condensed versus noncondensed CCD tables

A condensed CCD table contains only the most recent values for columns. For
example, if one row is changed 5 times in the source table, the condensed
CCD table would contain one row showing the results of all 5 changes to the
source table. Condensed CCD tables consolidate changes and reduce network
traffic for staged replication. A noncondensed CCD table contains one row for
each change that is made to a row in the replication source. In this case, if a
single row is changed 5 times in the source table; the noncondensed CCD
table would contain 5 rows (one for each change). That is, it represents the
history of changes to each row. Noncondensed CCD tables are useful for
auditing purposes.
Defining unique indexes: A condensed CCD table requires unique key values
for each row, but a noncondensed CCD table can have multiple rows with the
same key values. Because of the differences in key uniqueness, you must
define a unique index for a condensed CCD table, and you must not define
one for a noncondensed CCD table.
19. If changes are made to a source table while the Capture program is cold started, those changes might not get into
a noncomplete CCD table. To ensure that such changes get replicated to the noncomplete CCD table, you must
stop all activity against the source table when you cold start the Capture program.

Basic types of CCD tables
Table 5 summarizes the types of CCD tables based on the possible
combinations of attributes.
Table 5. Basic types of CCD tables. A CCD table can be local or remote, complete or
noncomplete, condensed or noncondensed, or any combination of these.
Location Complete Condensed Description
Local Yes Yes A CCD table that resides in the source
database and contains the same data as
the replication source.
No A CCD table that resides in the source
database and contains a complete
history of changes including the original
data from the replication source.
No Yes A CCD table that resides in the source
database and contains the latest change
data only.
No A CCD table that resides in the source
database and contains all change data
only.
Remote Yes Yes A CCD table that resides in a database
that the Apply program can access,
other than the source database, and
contains the same data as the user table.
No A CCD table that resides in a database
contains a complete history of changes
including the original replication source
data.
No Yes A CCD table that resides in a database
contains the latest change data only.
No A CCD table that resides in a database
contains all the change data only.
Using CCD tables as replication sources

You can use CCD tables as sources for replication to other target tables.20
20. You can define CCD tables as targets for non-IBM databases, but not as sources. Also, if the CCD target is in a
non-IBM database, it can be neither an internal nor external CCD table.

Internal and external CCD tables
Depending on your replication environment, you can choose to register your
complete CCD table as a replication source (an external CCD table), or you can
set up your CCD table so that it is used implicitly as a source for replication
(an internal CCD table).
External CCD tables: If you perform a full refresh on an external CCD table,
the Apply program performs a full refresh on all target tables that use this
external CCD table as a replication source. This process is referred to as a
cascade full refresh. You can define more than one external CCD table for a
replication source. An external CCD table can have any attributes you like
(local or remote, complete or noncomplete, condensed or noncondensed);
however, if you use it to stage data, you must use a complete CCD table
because the Apply program will use it to perform both full refresh and change
replication.
Internal CCD tables: Internal CCD tables are useful for staging changes. The
Apply program uses the original source table for full refreshes, and it uses the
internal CCD for change replication (instead of joining the CD and UOW table
each time changes are replicated).21
Use an internal CCD table as a local cache for committed changes to a source
table. The Apply program replicates changes from an internal CCD table, if
one exists, rather than from CD tables.
You can use an internal CCD table as an implicit source for replication
without explicitly defining it as a replication source. When you add a
subscription-set member, you can specify that you want an internal CCD table
if the table has the following attributes:
v It is a local CCD table. That is, the source server and the target server are
the same database.
v The CCD table is noncomplete.
v No other internal CCD table exists for this replication source.
Using CCD tables as replication sources in multi-tier staging

The following list shows all types of CCD tables and describes whether they
are suitable for staging data.
Complete, condensed CCD tables
You can define this type of CCD table as a replication source and use
it in the following ways:
21. If you define an internal CCD table, it is ignored by the Apply program when processing a subscription set with a
replica as a target.

v The staging table in a three-tier or four-tier distribution
configuration. In this case, targets are maintained entirely from
rows in the complete CCD table, with no additional overhead on
the original source database.
v A CCD table that is maintained by an external program (such as
IMS DataPropagator) and serves as a replication source for a CCD
table in DB2 replication. In this case, the change data comes from
an IMS database. (For more information, see “Using CCD tables
with nonrelational or non-IBM data” on page 87.)
Typically you would create this table nearer the targets rather than
local to the source to save network traffic during both change
replication and full refreshes. Also, multiple updates to a single source
table row will result in replication of a single row to all target tables.
Complete, noncondensed CCD tables
Do not define this type of CCD table as a replication source nor as an
internal CCD table.
Do not use this type of CCD table as a replication staging table
because of the space consumed by saving each and every change.
This table contains a complete set of rows initially, and it is appended
with each and every row change. No information is overwritten, and
no information is lost. Use this type of CCD table with applications
that need to process temporal queries (for example, as of last Tuesday,
a month ago, or yesterday) anytime following the initialization of the
CCD table. Also use this type of CCD table for auditing applications
that require a complete set of rows. (Other ways of auditing are
described in “Auditing data usage” on page 88.)
Noncomplete, condensed CCD tables
You can define this type of CCD table as an internal CCD table for the
replication source. By defining it as an internal CCD table, you access
the original source during full refreshes only, and use the CCD table
for updates. It is efficient because the join of the CD and UOW tables
happens only once, to populate the CCD table, and then changes are
replicated from the CCD table to all targets without the join overhead.
Because the CCD table is noncomplete, full refreshes must come from
the original source table. This type of table is also useful for
condensing change data from a CD table. Condensing reduces the
number of rows replicated to remote sites, and the number of SQL
operations against the target tables, by eliminating all but the last
change for each row.
Noncomplete, noncondensed CCD tables

In most cases, do not define this type of CCD table as a replication
source. Use this type of table for auditing applications that do not
require a complete set of rows, only the recently changed rows.
You might define the CCD table as an internal CCD for a replication
source when the remote targets themselves are noncondensed. In this
case, if there are many remote targets, you can benefit by avoiding
repeated joins of the CD tables with the UOW table, as long as this
benefit outweighs the cost of storing and maintaining the CCD table.
Using internal CCD tables with multiple targets

If you define an internal CCD table as a target, all other target tables
associated with the source table will have changes replicated from that
internal CCD table and not from the original source table. For this reason it is
important to plan all the potential target tables to make sure that you define
the internal CCD table correctly. If you do not include all the columns of the
source table in the internal CCD table, but a target table includes all of those
columns, then replication will fail. Similarly if the CD table used to maintain
the internal CCD table does not include all the columns of the source table,
but a target table includes all the columns, then replication will fail also.
Internal CCD tables do not support additional UOW table columns. If you
define target CCD tables (with UOW columns) as a replication source, you
cannot then define an internal CCD table. Do not use an internal CCD table if
you already defined a target CCD table that includes UOW columns.
If you want to use column subsetting in an internal CCD table, review all
previously-defined target tables to make sure that the internal CCD table
definition includes all appropriate columns from the source tables. If you
define the subscription set for the internal CCD table before you define any of
the other subscription sets from this source, the other subscription sets are
restricted to the columns that are in the internal CCD table.
Using CCD tables with nonrelational or non-IBM data

You can use CCD tables to replicate changes that are captured by application
programs or tools on other database management systems, such as Oracle.
Triggers on the Oracle tables simulate the Capture program by placing the
changes into Oracle CCD tables. Capture triggers for non-IBM sources also
use the internal CCD setup to replicate changes. For an example of this usage,
see “Retrieving data from a non-DB2 distributed data store” on page 32.
Similarly, changes captured by application programs or other tools, such as

IMS DataPropagator, can be defined as sources for subscription sets. The
application program must create and maintain a complete CCD table, and that
CCD table is considered to be an external CCD table. This CCD table must be
external, but can be condensed or noncondensed. For example, IMS
DataPropagator captures changes to IMS DB segments and updates its CCD

table. You define the CCD table as a replication source, and then you define
subscription sets using this CCD table, regardless of where the original
updates occur. For an example of this usage, see “Distributing IMS data to
remote sites” on page 27.
Pruning the CD and CCD tables
The Capture program can prune CD tables based on information inserted into
the pruning control table by the Apply program. You control whether the
Capture program prunes CD tables by using the PRUNE or NOPRUNE
parameter. You can also control when the pruning takes place and how the
prune interval is set by modifying the tuning parameters control table.
Some CCD tables can continue to grow in size, especially noncondensed CCD
tables. These tables are not pruned automatically; you must prune them
manually or use an application program. For some types of CCD tables, you
might want to archive them and define new ones, rather than prune them.
When the source table is a non-IBM table, the Capture triggers prune the CCD
table based on a synchpoint that the Apply program writes to the pruning
control table.
Auditing data usage

Auditing is the need to track histories of data use, in terms of before and after
comparisons of the data or identifying changes by time and by updating user
ID.
IBM Replication supports auditing in the following ways:

Before and after images
When you define replication sources, you can include before-image
columns of the updated rows in the target tables. A set of
before-image and after-image copies is useful in some industries that
require auditing or application rollback capability.
Maintenance of history
A noncondensed CCD table holds one row per UPDATE, INSERT, or
DELETE operation, thus maintaining a history of the operations
performed on the source table. If you capture UPDATE operations as
INSERT and DELETE operations (for partitioning key columns), the
CCD table will have one row per DELETE and INSERT and two rows
per UPDATE.
Important: Do not cold start the Capture program if you want to
maintain accurate histories of change data. A gap might occur if the

Apply program could not replicate changes before the Capture
program was shut down. See “Resolving gaps between source and
target tables” on page 147.
Use noncomplete, noncondensed CCD tables to keep a partial history
of updates to a source table or to maintain an audit trail of database
usage. For improved auditing capability, include the extra columns
from the UOW table.22
Use complete, noncondensed CCD tables to keep a complete history
of changes to a source table.
For more information see “Attributes of CCD tables” on page 82.
Transaction identification
Several columns in the CD tables and UOW table are available for
audit use. You can find the approximate commit time of the changed
row at the source server in the UOW table, and you can find the
operation type (INSERT, UPDATE, and DELETE) in the CD table. If
you need to keep this information, you can define noncomplete CCD
tables that include UOW columns using DJRA, and you can replicate
to these CCD tables. Normally, the Capture program prunes the CD
and UOW tables, but does not prune CCD tables.
If you need more user-oriented identification, columns for the DB2 for
OS/390 correlation ID and primary authorization ID or the AS/400
job name and user profile are available in the UOW table.
Planning for migration

Migration for AS/400:
You cannot run Version 1 of DPropR/400 concurrently with Version 7. If you

currently use Version 1, or if you use Version 1 replication components in a
Version 5 DPropR/400 environment, you must either:
v Migrate your Version 1 replication environment to Version 5. Instructions
are in the Migration Guide available from the Library page of the DB2
DataPropagator Web site (www.ibm.com/software/data/dpropr/).
v If your Version 1 replication environment is small (for example, if it
contains fewer than 50 source registrations and subscriptions), do not
migrate to Version 5. Instead, use DJRA to recreate your replication
environment in Version 7.
Migrating from DPropR/400 V5 to V7 does not require any special migration.
22. If you have target CCD tables defined for a replication source and you want to then define an internal CCD table,
note that internal CCD tables do not support additional UOW table columns. Do not use an internal CCD table if
you already defined a target CCD table that includes UOW columns.

You should use DJRA for all replication administration tasks. However, both
DJRA and the DB2 Control Center provide basic replication administration
functions for defining replication sources and subscription sets.
Migration for OS/2, UNIX, and Windows:
Beginning with Version 5 of DB2 Universal Database (for Windows, OS/2,

and UNIX), the replication component is automatically installed with DB2
(that is, it is not optional). After you install DB2 UDB Version 7, you cannot:
v Continue to use Version 5 or Version 6 of the Capture and Apply programs
on the V7 database instance.
v Install Version 7 of the Capture and Apply programs on a DB2 UDB
Version 6 (or earlier) system.
Migrating from DB2 UDB V6 to V7 does not require any special migration for
replication.
Important: Interoperability between Version 1 and Version 6 or Version 7

replication components is not supported. Therefore, you must complete all
Version 1 to Version 5 migrations before you introduce DB2 UDB Version 6 or
Version 7. Instructions are in the Migration Guide available from the Library
page of the DB2 DataPropagator Web site
(www.ibm.com/software/data/dpropr/).
The Version 5 Capture and Apply components can run alongside the Version 6
or Version 7 Capture and Apply programs; you do not need to migrate all
servers at the same time.
In addition:
v The Version 7 Capture and Apply programs are backward-compatible with
Version 5 or Version 6 sources and subscription sets. The Version 7
components will continue to use the critical section table in the same way
that the Version 5 or Version 6 Capture and Apply programs did if the new
prune lock control table is not present.
v The Version 7 Capture and Apply programs can use the invocation options
introduced for DB2 Universal Database Satellite Edition, even if the
administration component remains at the Version 5 or Version 6 level.
DB2 UDB supports the DB2 Universal Database Satellite Edition enabler
command ASNSAT. However, you cannot use the DB2 Universal Database
Satellite Edition SYNCH command in an existing replication environment
because the SYNCH command relies on centralized administration controlled
by a central control server. The central control server is not aware of any
existing replication environment administered without use of the SYNCH
command.

For more information about DB2 Universal Database Satellite Edition, see DB2
Universal Database Administering Satellites Guide and Reference.
Migration for OS/390:
Interoperability between Version 1 and Version 6 or Version 7 replication

components is not supported. Therefore, you must complete all Version 1 to
Version 5 migrations before you introduce DB2 for OS/390 Version 6 or
Version 7. Instructions are in the Migration Guide available from the Library
page of the DB2 DataPropagator Web site
(www.ibm.com/software/data/dpropr/).
Migrating from DB2 for OS/390 V6 to V7 does not require any special
migration for replication.
The Version 5 Capture and Apply components can run alongside the Version 6
or Version 7 Capture and Apply programs; you do not need to migrate all
servers at the same time.

Chapter 6. Setting up your replication environment
This chapter describes the steps for setting up and starting replication. It does
not include specifics about operating the Capture and Apply programs for
each operating system. See “Part 3. Operations” on page 173 for such specifics.
To set up the replication environment, you will complete the following

general steps:
1. Create control tables in the logical source, target, and control servers
2. Define replication sources
3. Create subscription sets and add members to the sets
You can use either the DB2 Control Center or the DB2 DataJoiner Replication
Administration (DJRA) tool to define sources and targets for replication, to set
the schedule for updating the targets, to specify the enhancements to the
target data, and to define any triggers that initiate replication. You can use the
DB2 Control Center to administer replication only when your source and
target tables are in DB2 Universal Database databases (for any
operating-system environment), but you can use DJRA to administer
replication when your source and target tables are in DB2 Universal Database
databases (for any operating-system environment) or in supported non-IBM
databases.
The administration tasks described in this chapter set up the control

information that both the Capture and Apply programs use to capture
changed data and replicate it to the target tables, in the proper format, and at
the appropriate interval.
Using the DB2 Control Center to set up replication

When setting up the replication environment, you can use the DB2 Control
Center to manage the source and target table definitions and the control
tables. Use the following high-level steps to administer your replication
objects:
1. Check, and optionally update, the default settings in the Tools Settings
notebook. See “Setting replication preferences in the DB2 Tools Settings
notebook” on page 95 for more information.
2. Review the DPCNTL file for your platform to determine whether you
need to customize the control tables for your site.

3. Optionally customize the DPCNTL file for your platform and site
requirements. See “Defining replication control tables” on page 100 for
more information.
4. Define and manage replication sources. See “Defining replication sources”
on page 105 for more information.
5. Define and manage replication subscriptions. See “Defining replication
subscription sets” on page 112 for more information.
After you create the control tables and define the replication sources and
targets, you need to configure and run the Capture and Apply programs to
begin replicating data.
You can access your replication sources and targets through the Control
Center. There are three containers in the Control Center for organizing the
objects that you use to set up and maintain your replication environment:
Tables folder
The folder containing DB2 tables.
Replication Sources folder
The folder containing tables that have been defined as replication
sources: DB2 tables, views, or target tables redefined as sources for
replication.
Replication Subscription folder
The folder containing subscription-set definitions for copying source
data or source-data changes to target tables.
Each object also has a menu for the actions that can be performed with the
object.
Configuring the Control Center for host RDBMSs
If you are connecting to a DB2 for MVS/ESA, DB2 for VSE, DB2 for VM, or
DB2 for AS/400 server from the Control Center, you must configure
connectivity to the remote database, catalog the remote databases, and bind
packages to the remote databases.
To bind the database:

1. Change to the directory where the Capture program bind files are located,
which is usually the \SQLLIB\BND directory on the drive where you
installed DB2 Universal Database or the client application enabler (CAE).
2. Create and bind the DB2 for MVS/ESA, VSE, VM, or AS/400 package to
the DB2 database by issuing the following commands:
DB2 CONNECT TO dbname USER userid USING password
DB2 BIND @DDCSxxx.LST ISOLATION CS BLOCKING ALL SQLERROR CONTINUE

Where CS specifies the cursor stability isolation level, and xxx specifies the
platform name: MVS, VSE, VM, or AS/400.
If the user ID and password are different than the local logon ID and
password for the Control Center workstation, you must explicitly connect
to the database server using the Connect menu choice from the pop-up
menu for your remote database object.
Setting replication preferences in the DB2 Tools Settings notebook
The Tools Settings notebook contains default preferences for the DB2
Universal Database administration tools. You can set replication default values
on the Replication page of the notebook, as shown in Figure 19. These default
values are used for all replication activities administered by the Control
Center.
Figure 19. The Replication Page of the Tools Settings Notebook. Use this page to specify default
preferences for replication.
Customizing CD table, index, and tablespace names

You can customize CD table names, index names, and tablespace names while
defining replication sources or subscription sets. You can edit the template file
DPREPL.DFT, found in the working directory for the Control Center
(\sqllib\bin or \sqllib\java), to change these names. See the instructions in
the file for syntax and examples.
You specify that you want to use this file from the Replication page of the
Tools Settings notebook. See Figure 19.
Chapter 6. Setting up your replication environment 95

Using the DB2 DataJoiner Replication Administration tool to set up replication
When you use the DB2 DataJoiner Replication Administration (DJRA) tool to
perform replication administration tasks, DJRA connects to the source, target,
or control server to create and update the control information and target
tables on the server (depending on the operation performed). The client
workstation where DJRA is located must be authorized and able to connect to
all source, target, and control servers that are managed by DJRA.
DJRA provides objects and actions that define and manage source and target
table definitions. Working through DB2 DataJoiner, DJRA creates:
v Capture triggers on the non-IBM source servers
v Nicknames in the DB2 DataJoiner database for the remote tables where the
changed data is to be captured
v Target tables (and their associated nicknames) in the non-IBM database for
the remote target tables
The Apply program reads from and writes to DB2 DataJoiner nicknames,
which eliminates the need to connect explicitly to non-IBM databases.
If the source database is a DB2 database, the Capture program for that
database captures the changes, therefore, the Capture triggers and DB2
DataJoiner are not involved. If the target database is a DB2 database, the
Apply program writes the changed data to the DB2 target database directly
and DB2 DataJoiner is not involved.
DJRA, working with DB2 DataJoiner, the Capture program, Capture triggers,
and the Apply program, replicates relational data from a variety of sources to
a variety of targets. The databases that DJRA supports as sources or targets
are:
v DB2 UDB (for UNIX, Windows, and OS/2) V5 or later
v DB2 UDB for AS/400 V5 or later
v DB2 UDB for OS/390 V5 or later
v DB2 DataJoiner V2 or later
v Oracle V7.3.4 or later
v Informix V7.2x or later
v Sybase V11.5 or later
v Sybase SQL Anywhere Version 6.0 or later
v Microsoft SQL Server V6.0 or later23
v NCR Teradata V2R4 or later (as target only)
23. For DataJoiner for AIX, replication from Microsoft SQL Server 6.x must use a DBLIB connection. For DataJoiner for
Windows NT, replication from Microsoft SQL Server 6.x is restricted to using the ODBC protocol.

v Microsoft Jet V3.5 or later (as target only)
For DB2 source, target, or control servers, DB2 DataJoiner’s distributed

database connection services (DDCS) or the DB2 Connect product provides
connectivity. For non-IBM sources and targets, DJRA uses DB2 DataJoiner to
connect to the non-IBM servers.
DJRA provides a user interface that is divided into areas that deal with
control tables, replication sources, subscription sets, and the running or
editing of SQL (see Figure 20 on page 98).
Using this interface, you can perform the following administration tasks:
v Create replication control tables and put them on your source, target, or
control servers
v Define DB2 tables, non-IBM tables, and DB2 views as sources
v Remove replication sources
v Change the definitions for existing DB2 source tables to add new columns
v Promote table, registration, and subscription definitions
v Define subscription sets and subscription members
v Activate and deactivate subscription sets
v Change existing subscription-set members for DB2 target tables to add new
columns
v Remove subscription sets or subscription-set members that are no longer
needed
v Add SQL statements or delete SQL statements or stored procedures that
should run before or after the target tables are replicated
v Run or edit SQL that is generated by DJRA
v Monitor replication
v Perform an offline load of a table
You can also customize the logic for most of the administration tasks listed
above.

Figure 20. The DJRA primary window
Installing DJRA
When you install DB2 UDB on a Windows system, the DB2 setup program
copies the DJRA setup program (djra.exe) to the \sqllib\djra directory. DJRA
also comes with DB2 DataJoiner V2; when you install DataJoiner on Windows
NT, you can also optoinally install DJRA. In addition, you can download
DJRA from the Web.24 When you install DJRA, if you do not already have
Object Rexx installed, DJRA will install it, otherwise DJRA will use your
existing copy.
DJRA runs in the following environments:

v Windows NT 4.0 with service pack 3 or later
v Windows 95 with service pack 2
v Windows 98
To install DJRA:
1. From the Windows Explorer, go to the \sqllib\djra directory, then
double-click the djra.exe file. This starts the DJRA setup program.
2. Follow the online instructions. Online help is available to help you with
the remaining steps. When you complete setup, DJRA appears in the
Windows Start menu.
3. To start DJRA:
a. Click the Start icon.
b. Select the Programs menu.
24. http://www.ibm.com/software/data/dpropr

c. Select either the DB2 for Windows NT or DataJoiner for Windows NT
menu (depending on whether you installed DJRA with DB2 or
DataJoiner).
d. Select the Replication menu.
e. Select Replication Administration Tools. The DJRA primary window
opens, as shown in Figure 20 on page 98.
Setting preferences
You can specify your preferences for:
v DJRA working directory
v Location of console or file output
v User IDs and passwords
v Tracing SQL execution activity and Replication Monitor activity
v Converting table and column names to uppercase or lowercase for Sybase
or Microsoft SQL Server targets
To set preferences, select File –> Preferences from the menu on the DJRA
primary window. You can change the preferences at any time.
On the Connection page of the Preferences notebook, you see a list of

databases that are currently cataloged on your system.
Restriction: If you are using Microsoft SQL Server in your replication

environment, do not use an alias user ID. Microsoft SQL Server will reject the
alias user ID.
Customizing DJRA
You can customize DJRA staging tables, indexes, predicates, and so on by
selecting the appropriate Edit Logic button from the following windows:
Create Replication Control Tables
Select the Edit Tablespace Logic button to specify the table spaces for
the control tables and the UOW table. Check this file to make sure
that the table spaces are being defined in the location where you want
them.
Define One Table as a Replication Source
Select the Edit Logic button to specify the owner and name of the CD
or CCD table and the table space in which the CD or CCD table is
placed. You can also customize index names for CCD tables.
Recommendation: If the source table is a non-IBM table, do not
change the owner for the CCD table.
You can also select the Edit Logic button from the Define Multiple
Tables as Replication Sources window. In this case, add a three-digit

number to the end of the CD_TABLE (or CCD_TABLE) parameter
value; DJRA automatically increments this number to ensure that each
table has a unique name.
You can specify where table spaces are created by changing the
default directory (C:\). Be sure to add a backslash (\) after the
directory name.
Add a Member to Subscription Sets
Select the Edit Predicate Logic button to specify which rows from the
source table can be replicated to the target table.
Select the Edit Create Table Logic button to specify the table space or
segment in which to create target tables.
You can specify where table spaces are created by changing the
default directory (C:\). Be sure to add a backslash (\) after the
directory name.
You can also select the Edit Predicate Logic or Edit Create Table
Logic button from the Add Multiple Members to Subscription Sets
window.
Defining replication control tables

Normally, the replication control tables are created in one of the following
ways:
v By selecting Create Replication Control Tables in DJRA.
v By customizing the DPCNTL file for your operating system and running
the file before initiating any actions from the DB2 Control Center.
See comments within the file for tailoring the SQL for a specific database
platform. You need to customize the DPCNTL file for the following
definitions:
– To define the location and size of DB2 for MVS/ESA table spaces and
databases for the control tables. The Control Center creates the control
tables in the default table space and database, unless you specify a
different table space or database.
– To define and size DB2 for VSE or VM dbspaces for the control tables.
The Control Center creates the control tables in the default dbspace,
unless you specify a different dbspace.
– To tailor the control tables for specific operating system environments
because not all definitions are supported for all operating systems.
– To place control tables in specific DB2 Universal Database table spaces or
in a DB2 EEE single node group.
v By using the Control Center to define replication sources and subscriptions;
these actions create default versions of the control tables.

If you use this option, you cannot customize the replication control tables
without dropping the existing control tables and customizing them. If you
are running OS/390, VSE/ESA, or VM/ESA, you must customize the
replication control tables.
When you create customized control tables, you must customize the CREATE
TABLE statements in the DPCNTL files. There is one DPCNTL file for each
operating system environment; these files are located in the
sqllib\samples\repl\ directory. The file names are:
DPCNTL.UDB
Creates control tables for DB2 Universal Database (for UNIX,
Windows, or OS/2).
DPCNTL.MVS
Creates control tables for DB2 for MVS/ESA and DB2 for OS/390.
DPCNTL.VM
Creates control tables for DB2 for VSE & VM.
DPCNTL.400
Creates control tables for DB2 for AS/400.
DPCNTL.SAT
Creates and drops control tables for DB2 Universal Database Satellite
Edition.
If, after creating customized control tables, you need to drop them, you must
customize the DROP TABLE statements in the DPNCNTL files. There is a
DPNCNTL file for each operating system environment located in the
sqllib\samples\repl\ directory. The files names are:
DPNCNTL.UDB
Drops control tables for DB2 Universal Database (for UNIX, Windows,
or OS/2).
DPNCNTL.MVS
Drops control tables for DB2 for MVS/ESA and DB2 for OS/390.
DPNCNTL.VM
Drops control tables for DB2 for VSE & VM.
DPNCNTL.400
Drops control tables for DB2 for AS/400.
To customize the SQL for creating or dropping control tables:

1. Open the appropriate file (sqllib\samples\repl\dpcntl.platform_name or
sqllib\samples\repl\dpncntl.platform_name, where platform_name is UDB,
MVS, VM, 400, or SAT.) in a text editor.
2. Read the commented areas for each operating system and table.

3. Edit the file for your site or application.
4. Close the file.
5. Connect to the database in which the control tables will be created (use the
DB2 CONNECT TO database-name command).
6. Run the file (DPCNTL or DPNCNTL) using one of the following
commands from a command window:
db2 -tf dpcntl.platform_name
db2 -tf dpncntl.platform_name
Creating replication control tables using DJRA

You must create control tables at each DB2 (and DataJoiner) system involved
in replication. 25 When you complete this step, DJRA places a register table, a
pruning control table, and a register synchronization control table at the
database source (and for non-IBM sources, creates nicknames for these tables
in DB2 DataJoiner).
From the DJRA primary window, click the Create Replication Control Tables.
The fields you complete to create a control table are:
Source, control, or target server
When you click the down arrow, DJRA checks to see what type of
server it is and then lists all databases and aliases that are cataloged
on the workstation from which you are running DJRA. If you select a
DataJoiner server from the list, the DataJoiner non-IBM source server
pull-down list becomes active. If you do not choose a DataJoiner
server, you will link directly to a DB2 database.
DataJoiner non-IBM source server
If you selected a DataJoiner alias from the Source, control, or target
server pull-down list and you have performed server mappings in
DataJoiner, then this list displays available remote server names.
Specify (None) if you want the control tables to be created in the
DataJoiner database rather than in the remote server database.
Edit Tablespace Logic
Click this push button to customize table space names for control
tables or for CREATE TABLESPACE options. The default table space
names for DB2 for OS/390 are:
v TS_UOW for the UOW table
v TS_CNTL for all other control tables
25. For DB2 Universal Database systems, you can use the DB2 Control Center or DJRA to perform this task; for other
systems, including DB2 for OS/390, DB2 for AS/400, and all non-IBM databases, you must use DJRA.

For other platforms, the default table space name is TSnnnnnn, where
nnnnnn is a unique identifier.
Generate SQL
Click this push button to generate SQL after you supply all the
information on this panel. While the SQL is being generated, a
window is displayed showing processing messages and error
messages, if any.
When the procedure completes successfully, save the file by selecting

File–>Save. You can now edit the generated SQL, if necessary, according to
the guidelines listed in “Customizing and running replication SQL files”.
When you are ready, run the SQL by selecting File–>Run. You must save the
generated SQL before you can run the SQL. You must run the SQL for
generating control tables before you generate and run SQL to create
replication sources or subscription sets.
Customizing and running replication SQL files

From the DB2 Control Center, you have the option to run a replication task
immediately or save the generated SQL file to run at a later time. From DJRA,
you can run or edit SQL files from the main window. The SQL files can be
customized for large scale replication actions such as defining subscription
sets, or customized for an application beyond implementations supported by
either the Control Center or DJRA.
You might want to save and customize the SQL files to:
v Create multiple copies of the same replication action, customized for
multiple servers.
v Customize CD table names.
v Define the location for CD tables (DB2 for OS/390 database, DB2 Universal
Database table spaces, DB2 for VSE & VM dbspaces).
v Set the size of the table spaces, databases, or dbspaces of the CD tables.
v Define site-specific standards.
v Combine definitions together and run as a batch job.
v Defer the replication action until a specified time.
v Create libraries of SQL files for backup, site-specific customization, or to
run stand-alone at distributed sites, such as for an occasionally-connected
environment.
v Edit create table and index statements to represent clusters and other
database objects.
v For Oracle and other remote servers, ensure that tables are created in the
existing table spaces that you want.
v For Microsoft SQL Server, create control tables on an existing segment.

v Review and edit subscription member predicates as a way of defining
multiple subscription sets at one time. You can use substitute variables in
your predicates and resolve the variables with programming logic.
If you save the definitions of a large replication subscription set in an SQL
file, you can rerun the definitions as necessary.
When editing generated SQL, be careful not to change special markers that
DJRA places within the SQL. For example, :ENDOFTRIGGER: or
:ENDOFPROCEDURE: is part of a comment that is necessary for DJRA to run
successfully. Altering create trigger blocks can result in incorrect SQL that
ends in error when run. If you add lines to the end of the file, be sure to add
an extra newline (CRLF) to the end of the file.
The DJRA Run SQL push button is intended to be used for SQL generated by
DJRA. SQL that you generate outside DJRA might not run successfully if you
use DJRA to start it. Likewise, you might not be able to run SQL generated by
DJRA at a DB2 command line.
Recommendation: Run DJRA-generated SQL from DJRA.
Setting up security for replication

Because DB2 DataPropagator is table driven, security for all replication objects
depends on the database security. The database administrator who defines
replication sources and subscription sets also defines security for them.
Additionally, the Capture program must be authorized to access the source
database and the Apply program must be authorized to access the control,
source, and target databases.
Authorization requirements for administration
When you define replication sources and subscription sets, the DB2 Control
Center and DJRA create many tables. Depending on the operating system,
they might also create table spaces or dbspaces. Because all of these actions
require a high level of database privilege, you should plan to have at least one
user ID that acts as the replication administrator and has the authority to
create objects, bind plans, and run generated SQL for each of the source
databases.
Authorization requirements for running the Capture program
The user ID that runs the Capture program must be able to access the DB2
system catalog, be able to access and update all replication control tables, and
have execute privileges on the Capture program packages. The user ID that
runs the Capture program can be the same as the administrator user ID, but
this is not a requirement.

For OS/390, the user ID that runs the Capture program should have either
SYSADM authority or have the following authorizations:
v SELECT, UPDATE, INSERT, and DELETE privileges for all Capture-related
tables created explicitly, and any Capture-related tables that the Control
Center or DJRA implicitly creates. See “Chapter 14. Table structures” on
page 293 for a list of these tables.
v SELECT privilege for the DB2 catalog (SYSIBM.SYSTABLES and
SYSIBM.SYSCOLUMNS).
v TRACE privilege.
v MONITOR1 and MONITOR2 privilege.
v EXECUTE privilege for the Capture plan.
For VM and VSE, the user ID that runs the Capture program must have DBA
authority. For all other operating systems, the user ID that runs the Capture
program must have either DBADM or SYSADM authority.
Authorization requirements for running the Apply program
The user ID that runs the Apply program must be a valid logon ID for the
source, control, and target servers, and for the workstation where the Control
Center or DJRA is installed. The user ID that runs the Apply program must be
able to access the source tables, access and update all replication control
tables, and update the target tables. This user ID must also have execute
privileges on the Apply program packages. The user ID that runs the Apply
program can be the same as the administrator user ID, but this is not a
requirement. With the proper authorization, any user ID can run any Apply
program instance.
An Apply program might require a password file to connect to the source or

target server. For more information about authorization requirements for the
Apply program, see the Capture and Apply chapter for your operating system
in “Part 3. Operations” on page 173.
Defining replication sources

To define a replication source using the DB2 Control Center:
Click the Tables folder for the source database to show all tables. Right-click
on a table object to show the pop-up menu and select Define as replication
source.
You can define replication sources using the Quick or Custom choices. Quick
allows you to define a replication source using default values. Custom allows
you to customize the defaults, such as specifying that certain columns should
not be captured.

After you define the replication source, an object is created in the Replication
Sources folder. The source table can now be defined in a subscription set.
To define a replication source using DJRA:
Click Define One Table as a Replication Source or Define Multiple Tables

as Replication Sources, then fill in the required information, such as source
server, source table names, and source columns.
For information about Capture triggers, see “Capture triggers for non-IBM
sources” on page 80. For data restrictions when defining replication sources
and subscription sets, see “General restrictions for replication” on page 77.
The Capture program does not recognize new DB2 replication sources until
you issue either the reinit command or stop and restart the Capture program.
The Capture program does not begin capturing changes for a replication
source until a subscription set is created for that replication source and the
subscription-set members have been fully refreshed.
Defining replication sources for update-anywhere replication
To define a replication source for update-anywhere replication using the
DB2 Control Center:
Define a custom replication source and use the following selections:

1. Select the Table will be used for update anywhere check box.
2. Select a conflict detection level:
None No conflict detection.
Attention: Conflicting updates between the source table and the
replica will not be detected. This option is not recommended for
update-anywhere replication.
Standard
Moderate conflict detection, in which the Apply program searches
rows already captured in the replica’s change data tables for
conflicts. Standard detection is the default value.
When you select this option, the DB2 Control Center also selects
the Define as Source and Capture before image check boxes for
every column.
Enhanced
Conflict detection that provides the best data integrity among all
replicas and the source table. The Apply program locks all replicas
in the subscription set against further transactions, and begins
detection after all changes prior to the locking are captured.

Even if you specify enhanced conflict detection, when the Apply
program runs in an occasionally-connected environment (started
with the asnsat command, or with the COPYONCE keyword), the
Apply program uses standard conflict detection.
To define a replication source for update-anywhere replication using DJRA:
Select the conflict detection level (described above) when you define a table as
a replication source, and select the replica target structure when you add the
member to the subscription set.
When to use update anywhere:
To reduce the risks of conflicts and costs of rejected conflicting transactions,

use update-anywhere replication under the following conditions:
Fragmentation by key
Design your application so that the replication source is updated by
replicas for key ranges at specific sites. For example, your New York
site can update sales records only for the Eastern United States (using
ZIP codes26 less than or equal to 49999 as the key range), but can read
all sales records.
Fragmentation by time
Design your application so that the table can be updated only during
specific time periods at specific sites. The time periods must be
sufficiently separated to allow for the replication of any pending
changes to be made to the site that is now becoming the master
version. Remember to allow for time changes, such as Daylight
Savings Time or Summer Time, and for time-zone differences.
Detecting conflicts
For update-anywhere replication, update conflicts can occur when:
v An update is made to a row in the source table and a different update is
made to the same row in one or more replica tables.
v Constraints are violated.
The Apply program detects update conflicts, after they occur, during the
subscription cycle. The source table is considered the primary table. That is, it
can receive updates from replica tables, but if there is a conflict, the source
table wins and the replica tables’ conflicting transactions are rejected. The
Apply program detects direct row conflicts by comparing the key values in
26. United States postal codes.

the CD tables with the source and target tables. If it finds any that match, it
marks the replica transaction as rejected in the UOW table and rolls back the
replica transaction.
The Apply program cannot detect read dependencies. If, for example, an
application reads information that is subsequently removed (by a DELETE
statement or by a rolled back transaction), the Apply program cannot detect
the dependency.
DB2 DataPropagator provides three levels of conflict detection: no detection,

standard detection, and enhanced detection. Each level has a numerical value
which is stored in the CONFLICT_LEVEL column of the register control table.
You must decide, based on your tolerance for lost or rejected transactions and
performance requirements, which type of detection to use. See “Defining
replication sources for update-anywhere replication” on page 106 for more
information about the levels of conflict detection and how to specify them.
Restriction: Although you set the conflict-detection level for individual

replication sources, the Apply program uses the highest conflict-detection
level of any subscription-set member as the level for all members of the set.
Use the rejection codes provided in the UOW table to identify the before and
after row values in the CD table for each rejected transaction. Because the
ASNDONE exit routine runs at the end of each subscription cycle, you can
add code to the routine to handle any rejected transactions. See “Using the
ASNDONE exit routine” on page 132 for more information on the ASNDONE
exit routine. Alternatively, because the change data rows and UOW control
table rows for rejected transactions are exempt from normal pruning (they are,
however, subject to RETENTION_LIMIT pruning), you could handle the
rejected transactions as a batch by using a program that scans the UOW table.
Defining views as replication sources
You can define replication sources that are views of other tables. After
defining each replication source table included in the view, you can create a
view replication source. The view replication source is then available for
replication to a target table.
You cannot use the DB2 Control Center to define an existing view as a
replication source; use DJRA instead. You can use the DB2 Control Center to
define a new view as a replication source.
To define a view using the DB2 Control Center:

1. Define the source tables to be used in the view (or join) as replication
sources.

2. Click on the Replication Sources folder. Select the replication sources to be
used in the view from the contents pane. Right-click the mouse button,
then select Define join from the pop-up menu. The Define Join window
opens.
3. In the CREATE VIEW field, type the SQL statement for the view. For
example:
USERID.VIEW_NAME AS SELECT A.COL1, A.COL2, B.COL6, B.COL5
Do not type the words CREATE VIEW. This part of the statement is
automatically supplied during processing.
4. In the FROM field, type table names that define the join. For example:
TABLEA A, TABLEB B
Do not type the word FROM. This part of the statement is automatically
supplied during processing.
5. If you want to use a row predicate, type the WHERE clause SQL statement
in the WHERE field. For example:
A.COL1=B.COL1
Do not type word WHERE. This part of the statement is automatically

supplied during processing.
6. Select OK to save the values and close the window. After you run the SQL
that defines the join view, it is available for replication.
To define a view as a replication source using DJRA:
Click Define DB2 Views as Replication Sources and fill in the required
information, such as source server, source view qualifier, and source view
name. You cannot define a join as a replication source using DJRA, but you
can define a view for the join and use DJRA to define the view as a
replication source.
Enabling replication logical-partitioning-key support
Generally, the Capture program captures an update to a source table as an
UPDATE statement. However, for the following conditions, you must instruct
the Capture program to capture updates as DELETE and INSERT statements
(that is, you must enable logical-partitioning-key support):
v Your source applications update one or more columns that are part of a
target table’s primary key.
Because the values for the target-table primary key come from the changes
captured on the source server, which reflect the new key values, these
values cannot be used to find the existing target table row (it doesn’t exist
yet). Converting the UPDATE to a DELETE and INSERT pair ensures that
the target table reflects the changes made at the source server.

v Your source applications update one or more columns referenced by a
subscription-set predicate.
In this case, the column included in the predicate need not be a
primary-key column. If a subscription set is defined with a predicate based
on a specific column value (for example, WHERE DEPT = ’J35’), and you
change that column (for example, to DEPT=’FFK’), the captured change will
not be selected for replication because it does not meet the predicate
criteria. That is, your new FFK department will not be replicated because
your subscription is based on department J35. Converting the UPDATE to a
DELETE and INSERT pair ensures that the target-table row is deleted.
v Your source applications update one or more columns of a target-table
partitioning key (either the target table is a partitioned database managed
either by DB2 Enterprise - Extended Edition (EEE) or DB2 for AS/400, or is
a table in a DB2 for MVS/ESA27 partitioned table space).
Enabling logical-partitioning-key support ensures that target rows are
moved from one node to another when the source column for the
logical-partitioning key is changed and replicated. The move is
accomplished by a DELETE at the old node and an INSERT at the new
node.
You can capture updates as updates or as delete/insert pairs for both DB2
and non-DB2 sources.
By default, when you update the primary keys of either the source or target
tables, the Capture program captures the changed row for the update. The
Apply program then attempts to update the row in the target table with the
new key value. This new key value is not found in the target table, so the
Apply program converts this update to an insert. In this case, the old row
with the old key value remains in the table (and is unnecessary). When you
enable replication logical-partitioning-key support, the Capture program
captures the change as separate DELETE and INSERT statements: delete the
old row and insert the new row.
For DATALINK columns defined as ON UNLINK DELETE, the unlink is

ignored because a DELETE and INSERT pair is handled within the same
transaction. The external file is not deleted, but is updated.
Each captured UPDATE is converted to two rows in the CD table for all
columns, non-key columns as well as key columns. You might need to adjust
the space allocation for the CD table to accommodate this increase in captured
data.
27. Version 4 or earlier only. This restriction does not apply to DB2 for OS/390 V5 or later.

When you use the DB2 Control Center to define the source table, select the
Changed data for partitioned key columns captured as delete and insert
check box on the Define as Replication Source window to specify that the
Capture program should capture updates as DELETE and INSERT statements.
When you use DJRA to define the source table, select the Updates as
delete/insert pairs radio button from either the Define One Table as a
Replication Source window or the Define Multiple Tables as Replication
Sources window.
Defining CCD tables

Recommendation: Use DJRA to define CCD tables. The DB2 Control Center
does create CCD tables, but does not allow you to define them directly.
To define a CCD table using DJRA, select CCD as the Target structure from
the Add Member to a Subscription Set window, then click the Setup
pushbutton. Select the type of CCD table you want from the Staging (CCD)
table property selection for target server window. This window prompts you
for all valid combinations of CCD tables.
For noncomplete CCD tables, you can include one or more of the UOW table
columns; these columns are useful for auditing and include Apply qualifiers,
authorization IDs, UOW ID, and so on.
If you are using a CCD table to stage replication (for example, in a three-tier
replication environment), complete the following steps:
1. Add the (complete and condensed) CCD table to a subscription set.
The Apply program that owns the subscription set populates the CCD
table based on the subscription-set definition.
2. If the CCD is defined as external, define it as a replication source.
From the DJRA Staging (CCD) table property selection for target server
window, select the Register as external replication source checkbox after
selecting a complete CCD table. See “Defining replication sources” on
3. Create a new subscription set.
This new set is the Apply program that applies changes from the CCD
table to the target tables. Usually, you use a different Apply qualifier than
the one used to populate the CCD, but you can use the same one.
See “Defining replication subscription sets” on page 112.
4. Define the target tables within the subscription set.
Select the source table depending on the type of CCD table you are using:

v Because an internal CCD table is an implicit source, specify the original
source table as the source. The Apply program automatically performs a
full refresh from the source table to the target tables, and uses the CCD
table as the source for change capture.
Restrictions: To register an internal CCD table, the source server must
be colocated with the target server. You can only register one internal
CCD for each source table.
v For an external CCD table, specify the CCD table as the source table.
The Apply program uses the CCD table for both full refresh and
changes.
For more information about CCD tables, see “Staging data” on page 82.
Defining replication subscription sets

To define a replication subscription set using the DB2 Control Center:
1. Click the Replication Sources folder for the source database to show all
tables and views defined as replication sources. The replication sources
appear in the contents pane.
2. Select one or more tables or views that you want to define as sources for
the subscription set, and right-click on one to show the pop-up menu and
select Define subscription. The Define Subscription window opens.
3. Give the subscription a name, specify the target server, and specify the
Apply qualifier for the subscription. You can also change the name of the
target table and specify whether the Apply program should create the
target table. Target-table names cannot exceed 18 characters in length.
If you specify that the Apply program should create the target table, and
that table will contain DATALINK columns, these columns will have the
default level of link control (none). If you want these columns to have a
different level of link control, edit the generated SQL to modify the
CREATE TABLE statement and specify a new level of link control, then
run the modified SQL.
4. Click the Advanced push button to specify the target type and to specify
specific columns and rows. See “Choosing a target-table type” on page 115
and “Defining the target-table structure: columns and rows” on page 116
for more information about these tasks.
5. Click the Timing push button to specify the frequency of replication and a
data blocking value. See “Specifying a data-blocking value” on page 122
for more information.
6. Click the SQL push button to add SQL statements or stored procedures
that you want to run before or after a subscription cycle. For example, you
can add a DELETE statement to prune the Apply trail control table.

7. Click the OK push button to complete the subscription definition. The
Subscription Information window opens. In that window, specify the
control server name.
To define a replication subscription set using DJRA:

1. From the main window, click Create Empty Subscription Sets to open the
Create Empty Subscription Sets window.
2. In this window, specify the source server, control server, target servers, the
Apply qualifier, the subscription set name, the subscription timing, and
blocking factor.
3. Add subscription-set members to the subscription set.
a. From the main window, click Add a Member to Subscription Sets or
Add Multiple Members to Subscription Sets to display either the Add
a Member to Subscription Sets window or the Add Multiple Members
to Subscription Sets window.
b. In either window, specify the subscription sets to which you want to
add a member, the tables and views to add to the subscription set,
whether the target table should be a column or row subset of the
source table (see “Defining the target-table structure: columns and
rows” on page 116), the target table type (see “Choosing a target-table
type” on page 115), and how the index for the target table should be
created.
When you add members to a subscription set, you can specify which primary
key to use for the target table. You can specify that DJRA should generate the
target primary key from the source primary key and source table indexes, or
you can specify the particular columns for the key, or you can specify the
source primary key.
After you create subscription sets for a non-IBM source server, the Apply
program connects to the DB2 DataJoiner database that is associated with the
non-IBM server and accesses (through nicknames) the information in the
register control table and the staging table on the non-IBM source server (see
Figure 21 on page 114).

Figure 21. DB2 DataJoiner in action. In a scenario where the source table is a non-IBM table (the
dark arrows), DB2 DataJoiner nicknames give the Apply program access to the non-IBM source
server and to changes made to the non-IBM source table (through the staging table). In a scenario
where the source table is a DB2 table (the light arrows), DB2 DataJoiner nicknames give the Apply
program access to the non-IBM target tables.
If you defined an event to start the Apply program, you must populate the
event table. See “Event timing” on page 124 for more information about this
task. To begin replicating data to the target tables, start the Capture program
at the source server, then start the Apply program using the name of the
control server that you specified in the Control Center Subscription
Information window or the DJRA Add a Member to Subscription Sets
window (or Add Multiple Members to Subscription Sets window).
Defining subscription sets for update-anywhere replication
To define a subscription set for update-anywhere replication using the DB2
Control Center, define a subscription set and use the following selections:
1. Select the replication sources that you want to be in the subscription set.
Include all sources affected by the replica tables being updated.
2. From the Subscription Definition window, select a target table to be
defined as a replica table.
3. Click Advanced to open the Advanced Subscription notebook. The
following selections are required on the Advanced Subscription notebook:
a. From the Target Type page, click on Target table is replica.
b. From the Target Columns page, repeat the following steps for each
target table:
1) Ensure that the Subscribe check boxes are selected for every
column. Do not create new columns for the replica table.
2) Specify a primary key for the replica table by clicking on the
Primary Key check boxes next to the key column names.

Make the primary key the same as the source-table primary key to
prevent conflicts. Do not use before-image columns as primary-key
columns for the target table.
Important: For existing target tables, you must select the
primary-key columns.
c. If you want the replica to be a subset of the source table, type a row
predicate in the WHERE field on the Rows page.
d. Click OK to close the Advanced Subscription notebook.
4. Click Timing to open the Subscription Timing notebook:
a. On the Source to Target page, fill in the subscription set timing
information for copying the source-table’s changed data to the target
tables.
b. On the Replica to Source page, fill in the subscription-set timing
information for copying the replica-table’s changed data to the source
tables.
c. Click OK to close the notebook.
5. If you want to define SQL or CALL procedures to run before or after the
subscription set is processed, click SQL and define the processing
statements.
To define a replication subscription for update-anywhere replication using

DJRA, select the replica target structure when you add the member to the
subscription set.
Choosing a target-table type
You can specify a target-table type if you do not want to accept the default
target type of user copy.
To specify a target-table type using the DB2 Control Center:

1. From the Define Subscription window, select a source and target table
combination, and click Advanced to open the Advanced Subscription
Definition notebook.
2. From the Target Type page, select one of the following table types:
v For read-only target tables, you can select:
User copy
A target table that matches the source table exactly at the time
of the copy.
Point-in-time
A target table that matches the source table, with a timestamp
column added.
Staging table
Also known as a CCD table. See “Attributes of CCD tables” on
page 82
page 82 for more information about CCD tables. If you select
this option without selecting either of the two options below, the
DB2 Control Center creates a noncomplete, noncondensed CCD
table.
Used as source for future copies
Select this option if you want a complete, condensed
CCD table.
Include Unit-of-Work (UOW) table columns
Select this option if you want a noncomplete, condensed
CCD table that includes extra columns from the UOW
table.
Base aggregate
A target table that contains aggregated data for a user table
appended at specified intervals.
Change aggregate
A target table that contains aggregated data based on changes
recorded for a source table.
v For updateable target tables, select Target table is replica to create an
updateable target table used for update-anywhere replication.
3. If you are finished using the Advanced Subscription Definition notebook,
click OK to close the notebook. Otherwise, use the other pages of the
notebook to define the target table columns and rows, as needed.
To specify a target-table type using DJRA:
Click Add a Member to Subscription Sets or Add Multiple Members to

Subscription Sets. Fill in the required information for the subscription-set
member. You can specify the target-table type from the Table structure
drop-down list. The available types include the same as those described for
the DB2 Control Center, plus choices for CCD table types.
Defining the target-table structure: columns and rows
For some applications, the target table does not need all of the rows or
columns that exist in the source table. You can define the target table to be a
column or row subset of the source table using the Control Center or DJRA.
For more information on subsetting, see “Subsetting columns and rows” on
page 70.
Restriction: Replica target tables must contain the same columns as the source
table: you cannot create subsets for them; you cannot add columns; and you
cannot rename columns.
Defining the target-table columns

To define the target-table columns using the DB2 Control Center:

combination and click Advanced to open the Advanced Subscription
2. From the Target Columns page, specify which columns should be the
primary-key columns for the target table; you can rename columns and
you can change column definitions.
If you want to specify a column as a primary-key column for the target
table, select the Primary Key check boxes next to the column names.
Attention: For the following target-table types you must select one or
more columns as part of a primary key: user copy, point-in-time, replica,
and condensed staging tables. If you do not select columns for the primary
key, DB2 uses the primary-key definition of the source table. However, if
the source table does not have a primary-key definition, the Apply
program issues an error message.
If you want to rename a column, select the column name and type over
the existing column name. A column name can have up to 17 characters
and can be an ordinary or delimited identifier.
If you want to change a column definition for the target table, click
Change to open the Change Column window. From this window, you can:
v Change the name of the column.
v Change the definition of the column by entering an SQL expression. For
example: COUNT(*) or EMP_SALARY – EMP_COMM.
The expression can contain up to 254 characters and can be any valid
SQL expression. This expression can contain ordinary or delimited
identifiers. Columns used in the expression must be valid after-image
columns from the source table. These column names are listed in the
Available columns box.
See the DB2 SQL Reference for information on valid SQL expressions.
Invalid SQL expressions cause an SQL error when the Apply program
processes the subscription.
v See examples of valid SQL expressions; click Examples.
If you want to remove a column from the target table, clear the Subscribe
check box next to the column name.
If you want to create a new computed column or use aggregation for the
target table:
a. Click Create Column to open the Create Column window.
b. Type the name of the column in the Column name field. The name can
have up to 17 characters and can be an ordinary or delimited identifier.
c. Type the SQL expression defining the new column.
d. Click OK to close the window.

select OK to close the notebook. Otherwise, use the Rows page to define
the target table rows, as needed.
To define the target-table columns using DJRA:
Click the Selected columns radio button from the Add a Member to
Subscription Sets window. Then select the columns you want replicated to the
target table.
Defining the target-table rows

To define the target-table rows using the DB2 Control Center:
combination and click Advanced to open the Advanced Subscription
2. From the Rows page, specify a WHERE clause that defines the row subset.
To specify which rows are copied to the target table, type an SQL
predicate in the WHERE field. The predicate can contain ordinary or
delimited identifiers. See the DB2 SQL Reference for more information
about WHERE clauses.
Row Predicate Restrictions:
v Do not type WHERE in the clause; it is implied. Type WHERE in the clause
only for subselect statements.
v Do not end the clause with a semicolon (;).
v You can use only those column names shown in the Target columns list
on the Target Columns page; these names are also listed in the
Available columns list.
v Do not use before-image columns, computed columns, or IBMSNAP
columns in the WHERE clause. Before-image columns are supported for
CD tables but not for user tables, point-in-time tables, or replica tables.28
v If you added computed columns (on the Target Columns page), you
must provide a GROUP BY clause. Both base aggregate and change
aggregate tables must have a GROUP BY clause.
v If your WHERE clause contains the Boolean expression OR, enclose the
predicate in parentheses; for example, (COL1=X OR COL2=Y).
v If the target table is a change aggregate table and contains before-image
columns, you must include the before-image columns in a GROUP BY
clause, even though these columns are not displayed in the Available
columns box on the Target Columns page.
28. If you use before-image columns or computed columns, for example, full refresh is no longer possible. You must
also modify the register control table.

v When both of the following conditions are true, you must provide a
dummy WHERE clause:
– You are creating an aggregate column that requires a GROUP BY
clause.
– You do not use any other predicate in the WHERE field.
The Apply program issues error messages if you do not provide the
dummy WHERE clause in this situation.
3. To see examples of SQL predicates, click the Examples button.
WHERE clause examples:
The following examples show WHERE clauses that you can use to filter
rows of the target table. These examples are very general and designed for
you to use as a model.
v WHERE clause specifying rows with specific values
To copy only the rows that contain a specific value, such as MGR for
employees that are managers, use a WHERE clause like:
EMPLOYEE = 'MGR'
v WHERE clause specifying rows with a range of values
To copy only the rows within a range, such as employee numbers
between 5000 and 7000 to the target table, use a WHERE clause like:
EMPID BETWEEN 5000 AND 7000
v Dummy WHERE clause
To support aggregation, use a WHERE clause like:
1=1
click OK to close the notebook.
To define the target-table rows using DJRA:
Add a WHERE clause in the Where clause field of the Add a Member to
Subscription Sets window.
Defining a subscription set with a user-defined table
DB2 DataPropagator allows you to use a previously-defined DB2 table as the
target table in a subscription set. That is, you can define a subscription-set
member to be a target table that is defined outside of the DB2 Control Center
or DJRA. This type of target table is known as a user-defined target table.
Restrictions:
v The subscription-set definition must contain the same number of columns
as exist in the user-defined target table.
v New columns in the subscription-set definition must allow nulls and must
not have defined default values.

v The target table and unique index must exist when you run the Apply
program.
To define a subscription with a user-defined target table:

1. Refer to “Chapter 14. Table structures” on page 293 to determine the
structure for the target-table type. For example, if you are defining a
subscription for a base aggregate table, refer to the table structure
definition for base aggregate tables.
2. Alter the target table to add any required columns, such as timestamp
columns.
3. For point-in-time, user copy, replica, and condensed CCD tables, create a
unique index.
4. Define the subscription-set member to match the user-defined target table
structure, including new columns, subset columns, changed column
names, and renamed before-image columns.
From the DB2 Control Center, in the Define Subscription window:
a. Clear the Create table check boxes next to the table names for which
you are providing the target tables.
b. Type the user-defined target-table name in the Target table field.
c. If you want to subset columns or rows, enhance data, or specify a
target-table type other than user copy, click Advanced to open the
Advanced Subscription Definition notebook.
If you want to select an alternate table type, see “Choosing a
target-table type” on page 115. If you want to modify the target-table
columns to match the user-defined target table, or subselect the rows or
use an aggregate expression, see “Defining the target-table structure:
columns and rows” on page 116.
DJRA tolerates existing target tables, and checks that the columns in the target
table match those defined for the subscription-set member.
DB2 DataPropagator does not check for inconsistencies between the

subscription definition and a user-defined target table. You must:
v Ensure that there is a target table that matches the subscription definition.
v Debug any inconsistencies that exist between the target table and the
subscription definition.
v If you want to use a CCD table between the source table and the
user-defined target table, define a subscription to match the attributes
specified for the target table. Then define a subscription for the target table
in which the CCD table is the source table.
v Ensure that there is a unique index for point-in-time, user copy, replica, and
condensed CCD tables.

Defining SQL statements or stored procedures for the subscription set
You can define SQL statements or stored procedures to be run before or after
the Apply program copies the data from the source to the target table. For
example, you can prune the Apply trail control table each day to remove
older entries.
To specify SQL statements or stored procedures for the subscription set using
the DB2 Control Center:
1. From the Define Subscription window, click SQL to open the SQL
window.
Use the SQL window to add or remove SQL statements or stored
procedures that run at the target or source server either before or after the
replication subscription is processed. The statements are processed in the
order that they appear in the list.
2. Click Add to open the Add SQL window.
3. Type the SQL statement or stored procedure name in the SQL statement
or Call procedure field. The stored procedure name must begin with CALL.
This field can contain ordinary or delimited identifiers.
4. If you know that the SQL statement or stored procedure will generate
SQLSTATEs that would otherwise terminate execution, specify these
SQLSTATEs so that the Apply program can bypass them and treat them as
successful execution. For example, a DELETE statement will generate a
SQLSTATE 02000 when attempting to delete nonexistent rows, but for new
tables you might not care about this error.
Enter valid 5-byte SQLSTATE values in the SQLSTATE field and click
Add. The value is added to the Acceptable SQLSTATE values box. You
can add up to 10 values.
5. Specify whether you want to run the SQL statement or stored procedure at
the source or target server before the subscription set is processed, or at
the target server after the subscription set is processed by clicking the
appropriate radio button in the Submit SQL statement field.
6. Click OK to add the statement to the box in the SQL window and close
the Add SQL window.
To specify SQL statements or stored procedures for the subscription using

DJRA:
1. From the main DJRA window, click Add Statements or Procedures to
Subscription Sets.
2. Specify the source server and subscription sets to which you are adding
SQL statements or stored procedures.

3. Type the SQL statement in the SQL statement field or type the stored
procedure name in the Stored procedure field. The stored procedure name
must begin with CALL. This field can contain ordinary or delimited
identifiers.
4. If you know that the SQL statement or stored procedure will generate
SQLSTATEs that would otherwise terminate execution, specify these
SQLSTATEs so that the Apply program can bypass them and treat them as
successful execution. For example, a DELETE statement will generate a
SQLSTATE 02000 when attempting to delete nonexistent rows, but for new
tables you might not care about this error.
Select a statement number from the Statement number spin box, and enter
valid 5-byte SQLSTATE values in the Acceptable SQLSTATE values field.
5. Specify whether you want to run the SQL statement or stored procedure at
the source server before the subscription set is processed, or at the target
server before or after the subscription set is processed by selecting the
appropriate radio button.
Data-sharing considerations
You can implement replication in an System/390 data-sharing environment. In
a data-sharing environment, you run one Capture program for each source
data-sharing group and one or more Apply programs for each target
data-sharing group.
The Capture program can read the data-sharing logs for all supported
vresions of DB2 for OS/390. That is, you can run different versions of DB2 in
a data-sharing environment, for example during version-to-version migration,
and have one Capture program continue to capture transaction-consistent
data. However, this mixed-version environment is not recommended for
long-term use, either for replication or for DB2. See the DB2 for OS/390
Administration Guide for information about data sharing with mixed versions
of DB2.
Specifying a data-blocking value
To specify how many minutes worth of change data DB2 DataPropagator can
replicate during a subscription cycle, use the Data Blocking page of the
Subscription Timing notebook in the DB2 Control Center, or set the Blocking
factor in the Create Empty Subscription Sets window in DJRA. The number of
minutes that you specify determines the size of the data block. See “Data
blocking for large volumes of changes” on page 68 for more information about
how to determine this value.
DB2 DataPropagator saves this value in the MAX_SYNCH_MINUTES column

of the subscription set control table. To change this value, execute the
following SQL statement:

UPDATE ASN.IBMSNAP_SUBS_SET
SET MAX_SYNCH_MINUTES=new_val
WHERE APPLY_QUAL=ApplyQual AND SET_NAME=name AND WHOS_ON_FIRST=val
where new_val is the new blocking factor value, ApplyQual is the current
Apply qualifier, name is the current subscription-set name, and val is either F
or S.
Data currency requirements
How up to date do you want target tables to be? How out of date can they be
without disrupting the application programs that use them? The answers to
these questions reveal your data currency requirements. You can control how
often the Apply program processes subscriptions and thereby control the
currency of the data. You can set an interval (or relative timing) schedule for
the Apply program, or define an event trigger that the Apply program uses to
start processing a subscription set.
You define subscription timing with the Subscription Timing notebook in the
DB2 Control Center or from the Subscription set timing field on the Create
Empty Subscription Sets window in DJRA. You can control the timing using
time-based or event-based scheduling, or you can use these timing options
together. For example, you can set an interval of one day, and also specify an
event that triggers the subscription cycle. For update-anywhere replication,
you can also specify different timing for source-to-replica and replica-to-source
replication.
Recommendation: When moving from a test environment to a production

environment, set a mid-range timing value (such as 2 hours) and tune your
system from there (to a more frequent or less frequent interval, as
appropriate).
Interval timing (relative timing)

The simplest method of controlling subscription timing is to use interval
timing. You determine a specific start time, date, and interval. The interval can
be specific (from one minute to one year) or continuous, but time intervals are
approximate. The Apply program begins processing a subscription set as soon
as it can, based on its workload and the availability of resources. If you
specify continuous timing, the Apply program replicates data as frequently as
it can.
Choosing a timing interval does not guarantee that the frequency of

replication will be exactly at that interval. Before specifying an interval, you
should determine whether it is possible to refresh all tables in the subscription
set within that interval: determine the amount of data that the Apply program
is likely to select for each interval and estimate the time that it will take to
copy the data.

You can set and change the interval using the DB2 Control Center, DJRA, or
by executing SQL statements against the subscription-set control table.
Event timing
To replicate data using event timing, specify an event name when you define
the subscription set in the DB2 Control Center or DJRA. You must also
populate (using an application program or the DB2 Command Center) the
subscription events table with a timestamp for the event name. When the
Apply program detects the event, it begins replication (either change-data
capture or full refresh).
The subscription events table has three columns, as shown in Table 6.

Table 6. The subscription events table
EVENT_NAME EVENT_TIME END_OF_PERIOD
END_OF_DAY 2000-05-01-17.00.00.000000 2000-05-01-15.00.00.000000
EVENT_NAME is the name of the event that you specify while defining the
subscription set. EVENT_TIME is the timestamp for when the Apply program
begins processing the subscription set. END_OF_PERIOD is an optional value
that indicates that updates that occur after the specified time should be
deferred until a future time. Set EVENT_TIME using the clock at the control
server, and set END_OF_PERIOD using the clock at the source server. This
distinction is important if the two servers are in different time zones.
In Table 6, for the event named END_OF_DAY, the timestamp value

(2000-05-01-17.00.00.000000) is the time when the Apply program is to begin
processing the replication subscription. The END_OF_PERIOD timestamp
value (2000-05-01-15.00.00.000000) is the time after which updates are not
replicated and will be replicated on the next day’s cycle. That is, the event
replicates all outstanding updates made before three o’clock, and defers all
subsequent updates.
Your application programs must post events to the subscription events table
to tie your application programs to subscription activity. When you post an
entry using CURRENT TIMESTAMP plus one minute for EVENT_TIME, you
trigger the event named by EVENT_NAME. Any subscription set tied to this
event becomes eligible to run in one minute. You can post events in advance,
such as next week, next year, or every Saturday. If the Apply program is
running, it starts at approximately the time that you specify. If the Apply
program is stopped at the time that you specify, when it restarts, it checks the
subscription events table and begins processing the subscription set for the
posted event.

Any event that occurs prior to the most recent time the Apply program
processed the subscription set (as specified by the value in the LASTRUN
column of the subscription-set control table), is considered to be an expired
event and is ignored. Therefore, if the Apply program is running, you should
post events that are slightly in the future to avoid posting an expired event.
Changing subscription-set timing

You can change subscription-set timing while both the Capture program and
Apply program are running by modifying values in the subscription set table.
For example, to change the interval value, execute the following SQL
statement:
SET INTERVAL_MINUTES=new_val
WHERE APPLY_QUAL=ApplyQual AND SET_NAME=name AND WHOS_ON_FIRST=val
where new_val is the new interval value, ApplyQual is the current Apply
qualifier, name is the current subscription-set name, and val is either F or S.
To change a subscription set to use event timing rather than interval timing,
execute the following SQL statements:
SET REFRESH_TIMING='E', EVENT_NAME='END_OF_DAY'
WHERE APPLY_QUAL=ApplyQual AND SET_NAME=name
INSERT INTO ASN.IBMSNAP_SUBS_EVENT

(EVENT_NAME, EVENT_TIME)
VALUES ('END_OF_DAY', 'timestamp')
where new_val is the new interval value, ApplyQual is the current Apply
qualifier, name is the current subscription-set name, val is either F or S, and
timestamp is the timestamp for when the Apply program should begin
processing the subscription set. If you already have an event named
END_OF_DAY, you do not need the INSERT statement shown above, but you
might need to modify the EVENT_TIME.
See “Subscription set table” on page 323 and “Subscription events table” on
page 335 for more information about these control tables.
Data consistency requirements
When planning and defining a subscription set, you need to be aware of the
following rules and constraints:
v If any member of the subscription set requires full-refresh copying for any
reason, the entire set is refreshed. For update-anywhere replication,
full-refresh copying occurs only from the replication source to the replica,
not from replica to source.
v A single synchpoint is maintained for the subscription set to indicate the
copy progress for the entire subscription set.

v You must refresh target tables that have referential-integrity constraints
using the ASNLOAD exit routine to bypass referential-integrity checking.
v Do not define referential constraints for read-only target tables.
v The first occurrence of any referential-integrity violation terminates the
current replication cycle. The subscription cycle is automatically retried,
after the transaction is rejected and compensated.
v For update-anywhere replication, you must specify a collision-detection
level when you define a replication source.
v For update-anywhere replication, each replica table must be of the same
generation as all other replicas in the subscription set, and they must all
have the same source table.
v For update-anywhere replication, because no single application program
updates both source and target tables, referential-integrity violations cannot
be detected in application logic, so you must use declarative
referential-integrity constraints.
v The administration tools do not copy referential-constraint definitions from
a source table to target tables. For update-anywhere replication, you must
include all referential constraints that exist among the source tables in the
replica tables to prevent referential-integrity violations. If you omit some
referential constraints, an update made to a replica table could cause an
referential-integrity violation when it is replicated to the source table.
v For a subscription that includes external CCD tables, all the external CCD
tables must have a common original source database.
Maintaining external CCD tables
If you maintain your own CCD table, you must update three columns in the
register control table: CCD_OLD_SYNCHPOINT, SYNCHPOINT, and
SYNCHTIME:
CCD_OLD_SYNCHPOINT
The synch point associated with when the CCD table was last
initialized or pruned.
Before a full refresh of the CCD table, set CCD_OLD_SYNCHPOINT
to NULL.
After a full refresh of the CCD table, set the
CCD_OLD_SYNCHPOINT to a value greater than the previous value
of SYNCHPOINT. If SYNCHPOINT has no previous value (in the case
of the initial load), set the CCD_OLD_SYNCHPOINT to
X'00000000000000000000'.
SYNCHPOINT
A sequence value useful for maintaining the state of CCD copies,
subscription states, and for controlling pruning.

Set the SYNCHPOINT for the CCD table to
MAX(IBMSNAP_COMMITSEQ) whenever you commit new changes
to the CCD table. Be sure also to set SYNCHTIME accordingly.
SYNCHTIME
The timestamp-equivalent of SYNCHPOINT.
Loading target tables offline using DJRA

DJRA guides you through the process of creating an offline load of a table or
database. The following procedure does not maintain the additional control
information required for loading external CCD tables, so for these tables you
must use the manual procedure.
To perform an offline load using DJRA:

1. Ensure that the Capture program is running.
2. Click Off-line load on the DJRA main window.
3. In the Off-line load — STEP 1 window, generate the SQL statements to
disable current subscriptions for the selected subscription sets. After you
load the target tables, you will re-enable these subscriptions.
4. Unload the source tables. Then click Next Step on the Off-line load —
STEP 2 window.
5. Load the target tables. Then click Next Step on the Off-line load — STEP 3
window.
6. In the Off-line load — STEP 4 window, generate the SQL statements to
re-enable current subscriptions for the selected subscription sets. Then
click Finished.
Copying your replication configuration to another system

When you define tables, replication sources, or subscription sets on one
system (a test system, for example), and you need to copy the replication
environment to another system (a production system, for example), you can
use the DJRA promote functions. These functions reverse engineer your tables,
replication sources, or subscription sets, to create script files with appropriate
data definition language (DDL) and data manipulation language (DML).
Table 7 on page 128 shows the three promote functions.
For example, use the promote functions to define subscription sets for remote
DB2 Personal Edition target databases. After you define a model target system
in your test environment, you can create subscription-set scripts (and modify
which Apply qualifier is used and so on) for your DB2 Personal Edition
systems, which are not otherwise supported from a central control point.

Table 7. Promote functions provided by DJRA
Promote function Description
Promote registration This function promotes source tables and views from a source
server.
Promote table This function promotes tables, table spaces, and indexes. It does
not promote constraints defined for a table.
This function is fully supported for DB2 UDB V5 and later, but
for the IBM Common Server you can promote only tables, not
table spaces.
Promote subscription This function promotes subscriptions: subscription sets,
subscription-set members, subscription columns, subscription
prune control, and subscription statements. It enables you to
create a new subscription set from an existing one.
From the Promote Subscriptions window in DJRA, you can

change your subscriptions (before promoting them) by setting
new values for any of the following fields: Apply Qualifier, Set
Name, Source server, Source alias, Target server, Target alias,
Control server, and Control alias.
Setting up the Capture program

This section describes setting the Capture program generally. See the
appropriate chapter for your operating system environment (in “Part 3.
Operations” on page 173) for specific information about setting up the Capture
program.
Specifying tuning parameters for the Capture program
To control the performance of the Capture program, you can specify the
following tuning parameters in the tuning parameters table:
Retention limit
The number of minutes to keep the CD table rows and the
unit-of-work (UOW) table rows. The default value is 10 080, which is
7 days.
For AS/400, you can keep the size of tables smaller by reorganizing
them using the RGZPFM command.
Lag limit
The number of minutes that the Capture program can be backlogged
from the current local time before shutting itself down. The default
value is 10 080, which is 7 days. If this value is exceeded, the Apply
program will perform a full refresh of all target tables.

Recommendation: Set a high value for the lag limit to ensure the
Capture program does not shut itself down unnecessarily.
If the database does not have or support an archive log, and the
Capture program shuts itself down, you should perform a cold start
of the Capture program.
Commit interval
The number of seconds that the Capture program waits before issuing
a COMMIT statement. The default value is 30 seconds.
If the Apply program is not running at the same time as the Capture
program, you can set the commit interval no higher than the DB2
timeout interval.
For AS/400, this value has a different meaning: it is the number of
seconds between the time that an application program updates a
source table and the time that the corresponding update in the CD
table is written to disk. The commit interval can range from 30 to 600
seconds, and the default is 180. If the value is too small, overall
system performance can be degraded.
Prune interval
The number of seconds that the Capture program waits before
pruning the CD and UOW tables. The default value is ten times the
commit value, or 300 seconds, whichever is larger. This parameter is
ignored if you start the Capture program with the NOPRUNE option;
however, you can override this option by using the prune command.
For AS/400, you can override this value by specifying a value for the
wait-time subparameter of the CLNUPITV keyword of the
STRDPRCAP command. If you specify *NO on the start-clean-up
subparameter of the CLNUPITV keyword, the prune interval value is
ignored.
For AS/400, if you start up the Capture program daily, *NO allows
you to defer pruning (for example, to the weekend). During the week,
you can use CLNUPITV (*DPRVSN *NO) on the STDPRCAP
command. On weekends, you can use CLNUPITV (*DPRVSN
*IMMED), which is the default.
Important: When you manually prune the CD table, do not delete the
most recent row. Always keep at least one row in the table.
To specify the tuning parameters, do one of the following tasks:

v Customize the DPCNTL.* file in the DB2 \sqllib\samples\repl directory
before you define the first replication source for a database.29
29. Customizing DPCNTL.400 is not necessary if you already installed DataPropagator for AS/400.

v If you want to change the default values, update the tuning parameters
table with the following SQL statement after you create it:
UPDATE TABLE ASN.IBMSNAP_CCPPARMS
SET RETENTION_LIMIT=number_of_minutes,
LAG_LIMIT=number_of_minutes,
COMMIT_INTERVAL=number_of_seconds,
PRUNE_INTERVAL=number_of_seconds
If you need to change the values and refresh the tuning parameters while
the Capture program is running, enter the reinit command after changing
the table values. For AS/400, enter the INZDPRCAP command; for more
information about the INZDPRCAP command, see “Reinitializing Capture
for AS/400” on page 203.
For information on the structure of the tuning parameters table, see

“Chapter 14. Table structures” on page 293.
v Run the AS/400 CHGDPRCAPA command. See “Changing Capture
program attributes” on page 179 for more information about this command.
Restrictions when running the Capture program
The following actions cause the Capture program to terminate while it is
running. Stop the Capture program if you want to perform any of the
following tasks:
v Remove an existing replication source table. If you remove an existing
replication source, the Capture program might attempt to insert data into a
CD table that no longer exists.
v Make changes (other than ALTER ADD changes) that affect the structure of
source tables or CD tables. This includes changes resulting from data
definition language or utilities. Structural changes can compromise the data
integrity of the copies.
Other Capture program restrictions include:

v If the Capture program shuts itself down, perform a cold start if the
database does not have or support an archive log.
v Source tables must be created or altered using the DATA CAPTURE
CHANGES option. The DB2 Control Center and DJRA automatically specify
these keywords when you define replication sources.
v Capture does not capture any changes made by DB2 utilities, even if you
specify LOG=YES.

Setting up the Apply program
This section describes setting the Apply program generally. See the
appropriate chapter in “Part 3. Operations” on page 173 for your operating
system environment for specific information about setting up the Apply
program.
Refreshing target tables with the ASNLOAD exit routine
The Apply program can call the ASNLOAD exit routine whenever it performs
a full refresh of a target table. Specify the LOADX parameter to cause the
Apply program to call this routine.
You can use the ASNLOAD routine as shipped with the Apply program, or
you can modify it. As shipped, the routine uses the DB2 EXPORT utility to
export data from the source table and uses the DB2 LOAD utility to fully
refresh the target table. You can modify the ASNLOAD routine to call any
IBM or vendor utility. See the prolog section of the sample program
(ASNLOAD.SMP) in the \sqllib\samples\repl directory for information about
how to modify this exit routine.
You must use the ASNLOAD routine to fully refresh tables with referential
integrity constraints in order to bypass referential integrity checking.
If your source servers are password protected, you must modify the
ASNLOAD routine to provide the password file. However, if the password is
administered by DB2 Universal Database Satellite Edition, the ASNLOAD
routine does not require a password file, and you can use the IBM-supplied
routine.
If your source tables include DATALINK columns, the Apply program does
not call the ASNDLCOPY exit routine. If you want external files (pointed to
by the DATALINK values) to be copied during a full refresh, you must
modify the ASNLOAD routine to call the ASNDLCOPY routine for these
columns.
See “Refreshing target tables with the ASNLOAD exit routine for AS/400” on
page 221 for information about using the ASNLOAD routine in an AS/400
environment.
Files generated on Windows and UNIX

When you run the ASNLOAD routine, it generates the following files:
v ASNA<userid><database_instance_name><cntl_server>.IXF
This file contains the data exported from the source.
v ASNAEXPT<userid><database_instance_name><cntl_server>.MSG
This file contains error, warning, or informational messages issued by the
EXPORT APIs.

v ASNAIMPT<userid><database_instance_name><cntl_server>.MSG
LOAD APIs.
Files generated on OS/2

When you run the ASNLOAD routine, it generates the following files:
v <apply_qual>.IXF
This file contains the data exported from the source.
v <apply_qual>.EXP
EXPORT APIs.
v <apply_qual>.LOA
LOAD APIs.
Error handling
If an error occurs while the Apply program calls the ASNLOAD routine, or if
the routine returns a nonzero return code, the Apply program issues a
message, stops processing the current subscription set, and processes the next
subscription set.
Restrictions
You can use the ASNLOAD routine only to refresh point-in-time and user
copy tables. Target tables have the following restrictions for the ASNLOAD
routine:
v The target-table columns must match both the order and data type of the
source tables.
v The target table cannot have a subset of the source columns nor extra
columns.
v The source table cannot be defined to include both before and after images
because the before images would add extra columns to the target table.
Using the ASNDONE exit routine
The Apply program can optionally call the ASNDONE exit routine after
subscription processing completes, regardless of success or failure. You can
modify this routine as necessary; for example, the routine can examine the
UOW table to discover rejected transactions and initiate further actions, such
as issuing a message or generating an alert. Another use for this exit routine is
to deactivate a subscription set that fails (status = -1), and thus avoid retry by
the Apply program until the failure is fixed.
See the prolog section of the sample program (ASNDONE.SMP) in the

\sqllib\samples\repl directory for information about how to modify this exit
routine. For AS/400, the following table indicates where you can find the

source code for this routine:
Compiler language Library name Source file name Member name

C QDPR QCSRC ASNDONE
COBOL QDPR QCBLLESRC ASNDONE
RPG QDPR QRPGLESRC ASNDONE
See “Using the ASNDONE exit routine for AS/400” on page 220 for more
information about using the ASNDONE exit routine in an AS/400
environment.
To use the ASNDONE exit routine:

1. Modify the ASNDONE routine to meet your site’s requirements.
2. Compile the program and place the executable in the appropriate
directory.
3. Start the Apply program with the NOTIFY parameter to call the
ASNDONE exit routine.
The parameters that the Apply program passes to the ASNDONE exit routine
are:
v Set name
v Apply qualifier
v Value for the WHOS_ON_FIRST column in the subscription set control
table
v Control server name
v Trace option
v Status value
Using the ASNDLCOPY exit routine
If a subscription set contains DATALINK columns, the Apply program calls
the ASNDLCOPY exit routine during processing for a subscription-set
member to copy the external file. You can modify this routine as necessary, for
example, to change the file transfer protocol.
Restrictions: The Apply program does not call the ASNDLCOPY routine if the
target table is a CCD table. Also, if you want external files (pointed to by
DATALINK values) to be copied during a full refresh, you must modify the
ASNLOAD routine to call the ASNDLCOPY routine for these columns.
See the prolog section of the sample program (ASNDLCOPY.SMP) in the

\sqllib\samples\repl directory for information about how to set up and
modify this exit routine. For AS/400, you can find the sample program in
library QDPR, source file QCSRC, member ASNDLCOPY.

To use the ASNDLCOPY exit routine:
1. Modify the ASNDLCOPY routine to meet your site’s requirements. See
“ASNDLCOPY parameters and input”.
2. Configure the ASNDLUSER and ASNDLSRVMAP files. See “ASNDLCOPY
configuration files” on page 136.
3. Optional: Modify the ASNDLCOPYD file-copy daemon to meet your site’s
requirements. See “Using the ASNDLCOPYD file-copy daemon” on
page 136.
directory.
When the ASNDLCOPY routine completes, it should return a return code to

the Apply program. A nonzero return code tells the Apply program that
replication failed for one or more of the files; in this case, the Apply program
issues a message, skips the current subscription set, and processes the next
subscription set. A zero return code tells the Apply program that replication
was successful.
Because the Apply program calls the ASNDONE exit routine after
subscription processing completes, regardless of success or failure, you can
use the routine to perform any necessary clean up if the ASNDLCOPY routine
fails to replicate any external files.
The ASNDLCOPY routine creates two files: a log file and a trace file (if trace
is enabled). The log file has the following name:
ASNDLApplyQualSetNameSrcSrvrTgtSrvr.LOG
where ApplyQual is the Apply qualifier, SetName is the subscription-set name,

SrcSrvr is the source-server name, and TgtSrvr is the target-server name. The
log file contains all messages generated by the ASNDLCOPY routine. The
trace file has the following name:
ASNDLApplyQualSetNameSrcSrvrTgtSrvr.TRC
The trace file contains any trace information generated by the ASNDLCOPY
routine.
ASNDLCOPY parameters and input

The parameters that the Apply program passes to the ASNDLCOPY exit
routine are:
v Set name
v Apply qualifier
v Source-table name
v Source-table owner
v Source-server name

v Target-table name
v Target-table owner
v Target-server name
v Input data file
v Result file
v Trace option
The input data file contains a list of link references captured from the source
table. The format for this file is:
length source_link_reference new_link_indicator
The fields are:

length
The length of the link reference.
source_link_reference
The reference to the source link in URL format.
new_link_indicator
A one-character link indicator. The link indicator is either Y to indicate
that the source file should be replicated, or N to indicate that the file
should not be replicated (for example, if the file is unchanged from a
previous replication).
Use the newline character to indicate the end of the input line.
Sample input file:

35 HTTP://S1.CDE.COM/data/yy/file1.avi Y
35 HTTP://S2.CDE.COM/data/qq/file2.avi N
The result file contains transformed link references that are valid for the target
system. The format for this file is:
length target_link_reference
where length is the length of the target link reference, target_link_reference is

the reference to the target link in URL format. If a source file cannot be
replicated, the ASNDLCOPY routine should set length to 0 in the result file
and set target_link_reference to blanks to ensure that no link is established in
the target table.
Sample result file:

35 HTTP://T1.XYZ.COM/data/yy/file1.avi
35 HTTP://T2.XYZ.COM/data/zz/file2.avi
The trace option can be either yes or no, to specify whether you want tracing.

ASNDLCOPY configuration files
The ASNDLCOPY routine requires two configuration files: ASNDLUSER and
ASNDLSRVMAP. The ASNDLUSER file contains the server address (URL
format), input port number, output port number, login user ID, and password.
The first port number is for the source FTP or file-copy daemon that the
ASNDLCOPY routine will connect to for retrieving files and the second port
number is for the target FTP or file-copy daemon for sending files. These port
numbers can be the same.
Sample ASNDLUSER file:

S1.CDE.COM 21 21 userA xxyyzz
T1.XYZ.COM 21 24 userB xkxkxk
The ASNDLSRVMAP file contains the server mappings for link references and
an optional directory path map. If you don’t specify a directory path map, or
if the path mapping cannot be found, the same path name will be used.
Sample ASNDLSRVMAP file:

HTTP://S1.CDE.COM HTTP://T1.XYZ.COM
HTTP://S2.CDE.COM HTTP://T2.XYZ.COM /data/qq /data/zz
All fields for a given entry must appear on the same line.
Using the ASNDLCOPYD file-copy daemon
The ASNDLCOPYD file-copy daemon extracts files for the ASNDLCOPY exit
routine. It is similar to a standard FTP daemon, but provides the following
functions for DATALINK replication:
v A command for extracting file information (such as file size and last
modification time)
v A command for retrieving the content of a particular file
Recommendation: Use the ASNDLCOPYD file-copy daemon to replicate a

DATALINK column that is defined with the ″read permission DB″ attribute.
Whereas standard FTP requires superuser access, the ASNDLCOPYD daemon
does not require such access.
You can configure the ASNDLCOPYD file-copy daemon to allow only certain
users to log in, and for each user, you can allow access to a subset of
directories. See the prolog section of the sample program
(ASNDLCOPYD.SMP) in the \sqllib\samples\repl directory for information
about how to set up and modify this program. For AS/400, you can find the
sample program in library QDPR, source file QCSRC, member
ASNDLCOPYD. If you need to add or change user logins, use the
ASNDLCOPYD_CMD tool.
You pass the following parameters to the file-copy daemon:

v Port number to listen to
v Directory that contains configuration files
To use the ASNDLCOPYD file-copy daemon:

directory.
2. Create two copies of the executable file (or for UNIX, create two symbolic
links) named ASNDLCOPYD_CHLD and ASNDLCOPYD_CMD.
3. Modify the configuration files to meet your site’s requirements.
4. Start the ASNDLCOPYD daemon, specifying both the port number and
the configuration directory.
The ASNDLCOPYD daemon must run with root (administrator) authority.
The ASNDLCOPYD file-copy daemon creates a log file for all the messages
generated by the ASNDLCOPYD program. This log file has the following
name: ASNDLCOPYDYYYYMMDDHHMMSS.LOG, where YYYYMMDDHHMMSS is the
time that the daemon started running.
Setting up DB2 DataJoiner

Install DB2 DataJoiner by following the steps described in the DB2 DataJoiner
Planning, Installation, and Configuration Guide. The Apply program is
automatically installed when you install DataJoiner. After you install
DataJoiner:
v Create an instance.
For AIX, identify the Apply user ID as a local client to DataJoiner.
v Set up environment variables.
If DJRA accesses DataJoiner for AIX, set the DB2CODEPAGE environment
variable from your DJRA workstation. The value that you set is based on
your country code. For example, if your country code is US, you would:
1. Select the My Computer icon.
2. Select the Select System icon.
3. From the System Properties folder, select Environment.
4. Type DB2CODEPAGE in Variable.
5. For US, type the value 437 in User Variables. For international English,
type 850.
v Create DataJoiner databases.
You must create one DataJoiner database for each non-IBM replication
source server. You can support many non-IBM replication target servers
with one DataJoiner database. The DataJoiner databases that you set up

reside on one DataJoiner instance. You must define server and user
mappings for each DataJoiner database that requires access to a source or
target.
For every non-IBM source, use the COLLATE USING parameter within the
CREATE DATABASE command. Use IDENTITY.
For Windows NT, you can automatically start your DataJoiner instance and
DB2 security service:
1. Select My Computer from the desktop.
2. Select Services.
3. Select the DB2 instance to be used for replication and the DB2 security
server.
4. Select Startup.
For more information, see DB2 DataJoiner Planning, Installation, and

Configuration Guide.

Chapter 7. Operating DB2 DataPropagator
This chapter describes how to operate the Capture and Apply programs
generally. For information about operating either of these programs (for
example, starting, stopping, or scheduling) in a specific operating system
environment, see “Part 3. Operations” on page 173. This chapter also describes
regular database maintenance, monitoring replication, handling gaps, and
modifying your replication configuration.
Operating the Capture program

This section describes what you need to know before you start the Capture
program, when you should perform a warm or cold start of the Capture
program, and how to stop the Capture program with an event.
Before you start the Capture program
Before starting the Capture program, make sure that you complete the
following post-installation tasks:
v Define one or more replication sources and subscriptions, as described in
“Defining replication sources” on page 105 and “Defining replication
subscription sets” on page 112. Defining replication sources and
subscriptions creates the following control tables in the source server
(where the Capture program runs):
– ASN.IBMSNAP_REGISTER (register table)
– ASN.IBMSNAP_PRUNCNTL (pruning control table)
– ASN.IBMSNAP_CCPPARMS (tuning parameters table)
– ASN.IBMSNAP_TRACE (trace table)
– ASN.IBMSNAP_WARM_START (warm start table)
– ASN.IBMSNAP_UOW (unit-of-work table)
– ASN.IBMSNAP_CRITSEC (critical section table)
– ASN.IBMSNAP_PRUNE_LOCK (prune lock table)
Defining replication sources and subscriptions creates the following control
tables in the control server:
– ASN.IBMSNAP_SUBS_SET (subscription set table)
– ASN.IBMSNAP_SUBS_MEMBR (subscription-targets-member table)
– ASN.IBMSNAP_SUBS_STMTS (subscription statements table)
– ASN.IBMSNAP_SUBS_COLS (subscription columns table)
– ASN.IBMSNAP_SUBS_EVENT (subscription events table)
– ASN.IBMSNAP_APPLYTRAIL (Apply trail table)

– REG_EXT (replication source extension table, for AS/400 only)
– AUTHTKN (Apply-qualifier-cross-reference table, for AS/400 only)
– APPLY_JOB (Apply job table, for AS/400 only)
You can also create these control tables manually by running the DPCNTL.*
file from the RUN SQL Files window.
v Bind the Capture program to the source server from which the Capture
program will capture changes. Capture for OS/390 includes bind JCL. Refer
to the Capture for OS/390 program directory for information on running
the bind program for Capture. For other operating systems, see the
configuration section within the operating system-specific chapters (see
“Part 3. Operations” on page 173).
v For OS/390: Ensure that you apply all relevant PTFs for your DB2
subsystem.
v Ensure that the register table has at least one entry in it by defining a
replication source with the DATA CAPTURE CHANGES option. See
“Defining replication sources” on page 105 for more information.
v For Windows NT: Decide whether you want to use the NT Service Control
Manager (SCM) to automatically run the Capture program as an NT
service. See “Starting Capture for Windows and OS/2” on page 269 for
information about operating the Capture program as an NT service.
v For VM: A Capture program ASNPARMS file is provided that contains
default values that the Capture program uses. Changing this file modifies
the defaults. If you need different values for a specific database, copy the
file to the Capture program virtual machine’s A-disk. The following default
values are contained in the Capture program ASNPARMS:
– ENQ_NAME CAPTURE
– LANGUAGE ASNLS001
v For VSE: The ASNS51CD job control member contains the name of the
messages file used. The default is American English. Modify ASNS51CD to
issue messages in a different language. See the Capture for VSE program
directory for a list of supported languages.
v For VM and VSE: By default, the messages are issued in American English
(ASNLS001). To issue messages in a different language, change the
LANGUAGE parameter in the ASNPARMS file. See the program directory
for the Capture program for a list of supported languages.
Starting or restarting the Capture program
When you start or restart the Capture program, you can include any of the
following keywords: COLD, WARM, or WARMNS. If you are starting the
Capture program for the first time, specify either COLD or WARM to cold
start the Capture program. If you are restarting the Capture program after
being shut down or after a failure, specify either WARM or WARMNS to
warm start the Capture program. The following sections describe cold and

warm starts, including how the Capture program handles warm starts, when
it switches to an automatic cold start, and how to prevent an automatic cold
start by forcing a warm start.
Cold start
When you cold start the Capture program, it deletes all rows from the CD
tables and the UOW table and begins reading the end of the database log.
Specify a cold start by including the COLD keyword when you start the
Capture program. A warm start can also become a cold start in certain
circumstances; see “Automatic cold start”.
After a cold start, the Apply program performs a full refresh of the target
tables. You can specify the LOADX keyword when you start the Apply
program to improve the performance of the full refresh, or you can use the
technique described in “Loading target tables offline using DJRA” on
page 127.
Warm start
When you stop the Capture program or if it fails, it writes information in the
warm start control table to enable a warm start. There are cases when the
Capture program cannot save warm start information. For example, an
operator might cancel the Capture program or stop DB2. In this case, the
Capture program uses information in the CD, UOW, or register tables to
resynchronize to the time it stopped and thus allow a warm start.
When you restart the Capture program with the WARM or WARMNS
keywords, it looks in the warm start table (or in the CD, UOW, or register
tables) to determine if it can warm start or if it must cold start. If there is
sufficient warm start information, the Capture program warm starts,
otherwise it attempts a cold start; see “Automatic cold start”.
After a successful warm start, the Capture program deletes old rows in the
warm start table.
Automatic cold start

If the Capture program cannot warm start, it attempts to perform a cold start.
But, if you specify the WARMNS keyword, the Capture program does not
cold start. The Capture program automatically switches to a cold start when:
v The warm start log sequence number lags behind the current log sequence
by more than the LAG_LIMIT value (as specified in the tuning parameters
table) or is not available from the database log.
v You start the Capture program for the first time.
The first time you start the Capture program, you see message ASN0102W,
indicating that warm start failed. The Capture program switches to a cold
start. You can ignore this message when first starting the Capture program.

In each of these cases, the Capture program issues an informational message
and performs a cold start. This cold start also causes a gap in the change data
capture sequence because the Capture program jumps to a new position in the
database log.
Preventing automatic cold start

To prevent the Capture program from attempting a cold start, specify the
WARMNS keyword when starting the Capture program. If the warm start is
not possible, instead of cold starting, the Capture program terminates. When
the Capture program terminates in this way, the control tables remain intact.
You must correct the problem that caused the Capture program to terminate
before you attempted to restart it. If you do not correct the problem, the
Capture program continues to terminate or performs a cold start every time
that you restart it.
Starting the Capture and Apply programs for the first time
If you are starting the Capture program for the first time, or after stopping
both the Capture and Apply programs, use the following steps:
1. Define replication sources and subscription sets.
See “Defining replication sources” on page 105 and “Defining replication
subscription sets” on page 112.
2. Start the Capture program.
Wait for the initialization message that indicates that the Capture program
is running. The Capture program does not capture changes until the Apply
program starts and completes a full refresh.
3. Start the Apply program.
The Apply program performs a full refresh for all subscription-set
members. When the full refresh is complete, the Capture program begins
capturing changes to the source tables.
Operating the Apply program

This section describes what you need to know before you start the Apply
program and how to use the Apply program for forward recovery. For
information about operating the Apply program (for example, starting,
stopping, or scheduling) in a specific operating system environment, see
“Part 3. Operations” on page 173.
Before you start the Apply program, ensure that:

v The control tables are defined.
v For Windows and UNIX: A password file has been created, if necessary, for
end-user authentication at the source server. See “Setting up end-user
authentication at the source server” on page 265 for more information.
v At least one subscription is created and activated.

v The Apply program package is created.
See the Apply for OS/390 program directory for information on BIND
programs to create the Apply program packages. You must bind the Apply
program to both the source and target databases.
See “Optional: Configuring the Apply program manually for Windows and
OS/2” on page 264 for information on bind programs to create the Apply
packages for Windows and OS/2.
See “Optional: Configuring the Apply program manually for UNIX
platforms” on page 240 for information on bind programs to create Apply
packages for UNIX platforms.
See “Creating packages to use with remote systems” on page 208 for
information about the CRTDPRPKG command, which creates the packages
that are necessary for DataPropagator Relational for AS/400 to work with
remote systems.
v The Capture program is started, and the ASN0100I initialization message
was issued (if you are running a Capture program).
v You have proper authorization.
v For OS/390:
– Ensure that all STEPLIB libraries of the Capture for MVS RUN JCL (if
you are running Apply for OS/390) are APF-authorized.
– Customize and execute the following JCL:
- The link-edit sample JCL
- The sample JCL to build the VSAM message file
- The Apply bind sample JCL
- The Apply Run/Invocation sample JCL
– You must have SYSADM or DBADM privileges at the source, control,
and target server. You must also have the proper authorization to run the
Apply program, including EXECUTE privileges for Apply program
packages.
– You must have DBADM or CONTROL or SELECT authority that meets
all requirements for defining a replication source and target.
v For AS/400: For Version 5, the Capture program is started on the source
server before you start Apply for the first time. The Capture program
updates the SYNCHTIME and SYNCHPOINT columns in the
ASN/IBMSNAP_REGISTER table before the Apply program is started. The
Apply program assumes that if a GLOBAL record is present in the
ASN/IBMSNAP_REGISTER table, the SYNCHTIME and SYNCHPOINT
columns are not null. For Version 1, the Apply program can be started
before the Capture program.

Improving Apply performance for Sybase or Microsoft SQL Server
If you run the Apply program using a DBLIB connection for either Sybase or
Microsoft SQL Server, and you have a slow network, you can significantly
improve your overall replication performance. DB2 DataPropagator can use
buffers to hold replicated data and send each buffer over the network rather
than sending individual updates. You set the size of the buffers using the
create server option statement. To take advantage of this improvement:
1. Retrieve the names of the packages for the Apply program. To find your
package names, issue the following SQL statement:
SELECT PKGNAME
FROM SYSCAT.PACKAGES
WHERE PKGNAME LIKE 'ASN%'
The package names change with each release and with each service
update, but this query retrieves names that are specific to your service
level.
2. If you have an apply_names.ini file (in the sqllib directory), replace the
package names with the ones that you retrieved in step 1. If you do not
have an apply_names.ini file, create one and list the package names. The
following lines show an example of an apply_names.ini file:
ASN6A001+
ASN6B001+
ASN6C001+
ASN6F001+
ASN6I001+
ASN6M001+
ASN6P001
3. Create server options for the Apply packet and buffer sizes. Sample sever
options for Sybase are:
create server option apply_packet_size for server type sybase setting 16384;
create server option apply_buffer_size for server type sybase setting 16384;
Sample sever options for Microsoft SQL Server are:

create server option apply_packet_size for server type mssqlserver setting 16384;
create server option apply_buffer_size for server type mssqlserver setting 16384;
You can set the packet and buffer size to any appropriate value less than
or equal to the maximum setting for Sybase or Microsoft SQL Server, and
adjust as necessary.
4. Set the following environment variable:
DJX_ASYNC_APPLY=TRUE
5. If you created or changed the apply_names.ini file, or if you changed the
DJX_ASYNC_APPLY variable, you must stop and restart DataJoiner before
these changes take effect. To stop and restart DataJoiner, issue the db2stop
and db2start commands.

Performing regular database maintenance
In addition to the regular maintenance that you perform for your databases,
running replication requires you to perform the following maintenance:
v Run the REORG utility for CD tables and the unit of work table
You should reorganize the CD tables and UOW table about once a week if
they are heavily used. For DB2 for OS/390 Version 5 or later, specify the
PREFORMAT keyword. Preformatting the table space speeds up the
Capture program’s insert processing. If the table space is compressed, you
must also specify the KEEPDICTIONARY keyword.
v Run REORG for target tables
Because subscription predicates are very selective and can filter out a
majority of the transaction updates, there is no general rule for how
frequently you should reorganize target tables, but it should be at least as
frequently as you reorganize the source tables.
v Delete old rows in the Apply trail control table
(ASN.IBMSNAP_APPLYTRAIL)
At the end of each subscription cycle, the Apply program inserts a row into
the Apply trail control table. To prevent this table from growing too large,
you need to delete these rows regularly. You can delete these rows
whenever you like because although the Apply program writes to this table,
it does not read from it. The subscription statistics and error diagnostics
written to this table are for your benefit, and they are used by the
Replication Monitor. An easy way to manage the growth of this table is to
add an SQL statement to the subscription set; for example:
DELETE FROM ASN.IBMSNAP_APPLYTRAIL
WHERE LASTRUN < (CURRENT TIMESTAMP - 7 DAYS);
v Prune CCD tables
Neither the Capture program nor the Apply program automatically prunes
CCD tables, and there is no command for pruning these tables. Condensed
CCD tables are updated in place, so do not grow continually.
Noncondensed CCD tables contain history, which you likely want to retain.
A condensed, noncomplete, internal CCD table grows, and with enough
update activity, can approach the size of a complete CCD table. Because
only the most recent changes are retrieved from it, there is no value in
letting this table grow. To prune transactions that have already been
replicated from this table, add an SQL statement to the internal CCD’s
subscription; for example:
DELETE FROM my.internal_ccd
WHERE IBMSNAP_COMMITSEQ <= (SELECT MIN(SYNCHPOINT) FROM ASN.IBMSNAP_PRUNCNTL);

This statement prunes the table based on the least active subscriptions, not
just those subscriptions that refer to the source associated with the internal
CCD table, so you might want to modify the statement for more aggressive
pruning.
The following operational procedures typically require exclusive use of DB2

table spaces or the catalog:
REORG
BIND PACKAGE
BIND PLAN
GRANT
REVOKE
Because these operational procedures do not coexist well with the Capture
and Apply programs’ issuing dynamic SQL (which implicitly locks catalog
tables) or accessing table spaces, you should stop both the Capture and Apply
programs when running utilities (and other similar operational procedures) to
avoid any possible contention.
Monitoring the replication environment

You can use the Replication Monitor, included with the DJRA, to periodically
generate a report that shows how your replication network is working:
v The color-coded report shows you whether your expectations for Capture
latency and subscription latency are being met.
v The Replication Monitor keeps historical statistics, so you can determine
whether end-to-end subscription latencies, for example, are staying
consistent.
v The report file is in HTML format, viewable through your Web browser.
You can publish the report on your company’s intranet for the benefit of
users who need the information but might not have database privileges.
After it is produced, the monitor report is completely independent of DB2,
requiring no database accesses to read.
To start the Replication Monitor, click Monitor replication on the main DJRA
window. From the Replication Administration Scheduler window, you can
schedule the monitor to run periodically or you can run it once.

Resolving gaps between source and target tables
Occasionally, a gap can occur during the capturing of changed data for a
source table. For example, if you shut down the Capture program and then
cold start it, it deletes all rows from the CD table. In this case, updates might
be made that the Capture program does not capture. Or, any updates that
were in the CD table could have been deleted (by the cold start) before the
Apply program could replicate them.
When a gap exists, the Apply program attempts a full refresh unless the target
table is a noncomplete CCD table. If the Apply program cannot perform a full
refresh, data integrity could be lost. For noncomplete CCD tables, you can
avoid potential data-integrity loss that could result from a cold start of the
Capture program by using the following steps:
1. Ensure all changes are replicated to the noncomplete CCD tables.
2. Stop all update activity for the source tables.
3. Cold start the Capture program.
4. Restart update activity for the source tables.
Modifying your replication configuration

After you begin replication, you can change the configuration, including
changing replication sources or subscriptions, removing sources or
subscriptions, deactivating subscriptions, and cloning subscriptions.
Viewing or changing existing replication sources
Using either the DB2 Control Center or DJRA, you can view an existing
replication source. With the Control Center, if you selected the Table will be
used for update anywhere check box, you can change the conflict-detection
level defined for the replication source. All other fields and controls are
unavailable for changes after you successfully define the replication source.
With DJRA, you can change the set of columns available for replication.30
If you plan to change the replication source definition, use the Capture
REINIT command. You can also stop or suspend the Capture program and
then warm start or reinitialize the Capture program to begin capturing
changes for the changed replication source. For information about the Capture
program for your operating system environment, see “Part 3. Operations” on
page 173.
30. You can change the set of columns available for replication only for DB2 sources, not for non-IBM sources.

Removing replication sources
When you no longer need a replication source, you can remove the object
from the DB2 Control Center or DJRA and remove its control information
from the control tables.
Attention:
v Stop the Capture program before deleting a replication source. Do not
merely suspend it. You can restart the Capture program after you have
finished removing the replication source.
v Although the Control Center removes dependent subscriptions, you should
check whether a dependent subscription table is being used as a source for
another subscription and cancel any such dependent subscription before
you delete a replication source. DJRA does not remove dependent
subscriptions, so you must delete any subscriptions that use the source for
copying.
The Control Center and DJRA drop the table space for a DB2 replication
source if it is empty. DJRA does not drop non-IBM database containers (table
spaces, dbspaces, or segments). For the Control Center, you can ensure that
the table space is never dropped by changing the settings on the Replication
page of the Tools Settings notebook.
Activating and deactivating subscription sets
From the DB2 Control Center or DJRA, you can control the active status of a
subscription set. This feature is useful when you want to temporarily
deactivate a subscription set without removing it. When you deactivate a
subscription set, the Apply program completes its current processing cycle
and then suspends operation for that subscription set. In the Control Center,
when you deactivate a subscription set, the icon for the subscription set is
greyed out.
Cloning a subscription set to another server
Using the DB2 Control Center, you can clone a subscription set to another
server. Cloning creates a copy of an existing subscription set on a different
target server, using a different Apply qualifier. This copy includes only
subscription information; it does not include copy table, table space, or index
definitions. You can clone one or more subscription sets at a time. The Control
Center updates the control tables at the control server.
For information about copying your entire replication environment to another

system, see “Copying your replication configuration to another system” on
page 127.

Viewing or changing an existing subscription set
Using the DB2 Control Center, you can change a subset of the subscription-set
values, primarily those that do not affect the structure of the target tables. You
can change the following values in the Change Replication Subscription
window and subwindows:
v The Row predicate in the Advanced Subscription notebook. The new
predicate is not applied to existing rows in the target table. The Apply
program uses the predicate starting with the next subscription cycle for the
subscription set. See “Defining the target-table rows” on page 118 for more
information and examples.
v The SQL or CALL procedure for before or after copying in the SQL
window. See “Defining SQL statements or stored procedures for the
subscription set” on page 121 for more information.
v The timing values in the Subscription Timing notebook.
v The data-blocking value in the Subscription Timing notebook. See
“Specifying a data-blocking value” on page 122 for more information.
To view or change existing subscription-set members using DJRA, click the

List Members or Add a Column to Target Tables button. Fill in the required
information in the window, such as source-server name and source-table
names, then optionally fill in the source-column name or SQL expression and
the target-column name to add new columns or add computed columns to the
target table.31
Removing subscription sets
Removing a subscription-set definition deletes information about it from the
control tables and, optionally, deletes the target tables from the target server.
For non-IBM target tables, you can choose whether to drop the nickname and
the corresponding target table when you remove the subscription set using
DJRA.
Using the DB2 Control Center, select one or more replication subscription
objects from the contents pane and select Remove from the pop-up menu.
Using DJRA, you must first remove all members from the subscription set,
then you can remove the empty subscription set.
31. You can change the set of columns available for replication only for DB2 sources, not for non-IBM sources.

Chapter 8. Problem determination
When replication fails or executes in an unexpected way, you need to
determine the cause of the problem and find a solution that fixes the problem.
DB2 DataPropagator provides error messages, trace records, log records, and
information stored in the control tables to assist you in the
problem-determination task. Using the information provided by the product,
you can often fix a problem yourself, but sometimes the best solution is to call
IBM Software Support. This chapter includes:
v “Problem determination scenario” on page 152 describes a set of typical
steps for problem determination.
v “Problem determination for replication administration” on page 152
describes problems that the DB2 Control Center and DJRA can encounter.
v “Problem determination for the Apply program” on page 153 describes
problem-determination tools for the Apply program, including the Apply
trail table and the trace and log files.
v “Problem determination for the Capture program” on page 156 describes
problem-determination tools for the Capture program, including the trace
table, trace file, and the log file.
v “Problem determination for AS/400” on page 159 describes
problem-determination tools for the AS/400 environment, including
gathering information about active jobs and determining if the journal job is
started.
v “Using the Replication Analyzer” on page 163 describes how to analyze the
behavior of the Capture program or the Apply program, and can help you
diagnose problems, verify replication setup, and tune replication
performance.
v “Troubleshooting” on page 166 lists various problems that can occur when
running the Capture and Apply programs and how to resolve those
problems.
v “Problem-source identification questions” on page 171 lists questions that
can help you to research an error condition before calling IBM Software
Support.
This book also includes other resources that can help you in problem
determination:
v “Chapter 15. Capture and Apply messages” on page 353 describes error
messages for the Capture program and the Apply program. “Chapter 16.
Replication messages for AS/400” on page 381 describes the error messages
for replication in an AS/400 environment.

v “Chapter 14. Table structures” on page 293 describes the Apply trail table
and other control tables.
Recommendation: When using problem-determination facilities to test or

debug your replication scenarios:
v When possible, stop replication activity that is unrelated to the problem
area while gathering information about a problem. Stopping other
replication activity reduces the volume of data you or IBM Software
Support must sift through.
v Set up a test environment to ensure that the solution fixes the problem
without introducing new problems.
Problem determination scenario

The following scenario shows how you might trace a replication error using
the facilities discussed in this chapter.
After you define replication sources and subscription sets, the SQL statements
for your replication requests complete satisfactorily, but the Apply program
does not replicate the data successfully. To determine the error, you could:
1. Examine any error messages returned directly to the terminal for the
Apply program job or process.
2. Run the Replication Analyzer to verify that the replication setup is correct.
3. Examine the Apply trail table (ASN.IBMSNAP_APPLYTRAIL) for any
indicators of the problem.
4. Examine the Capture program trace table (ASN.IBMSNAP_TRACE) for
indicators from the Capture program’s activity.
5. Examine the log files for the Capture and Apply programs for indicators
from their activities.
6. Examine the CD and UOW tables to verify that the Capture program is
capturing changes.
7. Rerun the Capture and Apply programs with the trace option and examine
the trace file for indicators of the problem.
Problem determination for replication administration

The DB2 Control Center or DJRA can encounter errors when it gathers
information from source servers, target servers, or control servers to create the
SQL statements for administration and when it is actually running the SQL
statements to set up the replication sources and subscription sets. The primary
indicators are SQL messages, SQLSTATE codes, and Capture- and
Apply-program messages (those that begin with the letters ASN) that
accompany the error. See the DB2 Universal Database Message Reference (or DB2
message reference for your platform) for more information about DB2 error

messages and SQL states. The ASN messages are also described in
“Chapter 15. Capture and Apply messages” on page 353 and “Chapter 16.
Replication messages for AS/400” on page 381.
The Capture- and Apply-program messages are issued or recorded in the

following locations:
v At the command-line-processor window or console from which you started
the Capture program or the Apply program
v In the Apply trail table and the Capture program trace table
v In the trace files for the Capture and Apply programs
v In the log files for the Capture and Apply programs
The Capture and Apply programs can also encounter problems while
capturing and replicating changed data, even though the SQL that the DB2
Control Center or DJRA generated for defining replication sources and
subscriptions ran without error. You can determine the cause of the errors
with information from the following sections: “Problem determination for the
Apply program”, “Problem determination for the Capture program” on
page 156, and “Troubleshooting” on page 166.
Problem determination for the Apply program

DB2 provides the following problem-determination tools for the Apply
program:
Apply-program messages
These messages describe errors from the Apply program. See
“Chapter 15. Capture and Apply messages” on page 353 and
“Chapter 16. Replication messages for AS/400” on page 381.
Apply trail table
This table contains SQLSTATE codes and SQL error codes for a failed
replication, as well as audit-trail information for the Apply program.
Apply-program trace file
This file contains a record of all Apply-program activity. There is one
trace file for each Apply-program instance at the server where the
Apply program is running. To get a trace file, you must specify one of
the trace parameters when you start the Apply program.
Apply-program log file
This file summarizes the activities of the Apply program and can be a
useful diagnosis tool.
Apply trail table
Each time the Apply program attempts to replicate a subscription set, it
inserts a new row in the Apply trail table (ASN.IBMSNAP_APPLYTRAIL).
Chapter 8. Problem determination 153

This table is located at each control server, along with other control tables,
and has one row for each successful or unsuccessful subscription cycle.
Because the Apply program appends to this table, you should prune it
periodically. For a description of the Apply trail table, see “Apply trail table”
on page 336.
For subscription sets that do not replicate successfully, the Apply trail table
records the SQL code and the SQLSTATE. Additional SQL codes and states
associated with the problem can be found in the Apply program trace file.
To query the Apply trail table for problem-determination information:
Use the Replication Analyzer to view information in this table; see “Using the
Replication Analyzer” on page 163. You can also query information in the
Apply trail table directly to gather problem-determination information for
failing subscription sets.
1. Ensure that the data in the Apply trail table is current:
v Temporarily disable subscription sets that are successful to ensure that
rows in the Apply trail table apply only to subscription sets that have
problems.
v Delete all unnecessary rows from the Apply trail table to remove
information from past replications.
2. To gather the problem-determination information, execute a query similar
to:
SELECT TARGET_TABLE, STATUS, SQLSTATE, SQLCODE, SQLERRM, APPERRM, LASTRUN, LASTSUCCESS
FROM ASN.IBMSNAP_APPLYTRAIL
WHERE STATUS <> 0
ORDER BY TARGET_TABLE, LASTRUN DESC, SQLCODE DESC, SQLSTATE ASC
This query returns the following columns from the Apply trail table:
TARGET_TABLE
The target table for the current subscription set.
STATUS
Contains -1 to indicate the failed subscription set.
SQLSTATE
Contains the error SQLSTATE for the failed subscription set.
SQLCODE
Contains the error SQLCODE for the failed subscription set.
SQLERRM
Contains the text of the error message that corresponds to the SQL
code.

APPERRM
Contains the text of the Apply program error message.
3. Read the error message text to determine the database to which the Apply
program was connected when the error occurred; for example, did the
error occur while the Apply program was connected to the source server
or the target server? Refer to the DB2 SQL Reference for information on the
SQL codes and states.
4. Be sure to reenable subscription sets that were successful.
Apply-program trace file
You can trace the operation of the Apply program to help isolate the causes of
certain kinds of replication errors. The Apply program creates a trace file
when you include a trace parameter to the Apply program start command.
See the Capture and Apply chapter in for your platform in “Part 3.
Operations” on page 173 for the syntax of the command.
While tracing its activity, the Apply program records the following kinds of
information in the trace file:
v Connections to the control server to obtain information for subscription sets
to be processed
v Connections to source servers to retrieve rows to be replicated from the CD
table to the target table
v Connections to the target servers to insert, update, and delete rows into and
from the target tables
The Apply program inserts error messages and indicators in the trace file at
points when it encounters an error.
To create a trace file:

1. Temporarily disable subscription sets that are successful to reduce the
volume of information in the trace file and ensure that data in the trace
file only applies to subscription sets that have problems.
2. Start the Apply program with the appropriate trace parameter:
trcflow
Provides very detailed information that is oriented toward helping
IBM Software Support diagnose errors.
trcerr Provides less detail and can be a better choice when you are new
to replication.
When you specify a trace parameter, you must also specify the name of a
trace file (for workstation systems, precede the trace file name with the

greater than symbol (>) to redirect the output to the file). For example, to
start Apply for Windows with trace, issue the following command from
the command line:
asnapply ApplyQual CtlSrvr trcflow > apply.trc
where ApplyQual is the Apply qualifier, CtlSrvr is the control server, and
apply.trc is the trace file. The trace file is created in the directory from
which you start the Apply program.
3. Let replication run until the problem recurs and the Apply program inserts
a row into the Apply trail table.
4. Stop the Apply program and restart it without the trace parameter. Be sure
to re-enable subscription sets that were successful.
5. View the trace file using any editor. You could also send the file to other
systems or print it.
Apply-program log file
For a summary of the Apply program’s activities, you can view the Apply
program log file. The log file is in the directory from which you start the
Apply program and contains messages issued by the Apply program. Because
the information in the Apply program log file is high level, it typically directs
you to the Apply trail table for more detailed information.
The name of the log file is ApplyQual.APP, where ApplyQual is the Apply
qualifier associated with the Apply-program instance.
Problem determination for the Capture program

DB2 provides the following problem-determination tools for the Capture
program:
Capture-program messages
These messages describe errors from the Capture program. See
“Chapter 15. Capture and Apply messages” on page 353 and
“Chapter 16. Replication messages for AS/400” on page 381.
Trace table
This table contains audit-trail information for the Capture program.
Capture-program trace file
This file contains a record of all Capture-program activity.
Capture-program log file
This file summarizes the activities of the Capture program and can be
a useful diagnosis tool.
This section also includes problem-determination for the Capture program on

the following operating systems: AS/400, OS/390, VM and VSE.

Capture-program trace table
The Capture program inserts a new row in the trace table
(ASN.IBMSNAP_TRACE) whenever it encounters an event for which it also
issues a message. This table is located at the source server and contains basic
information about the activities of the Capture program. For a description of
the trace table, see “Trace table” on page 316.
To query the trace table for problem-determination information:
Use the Replication Analyzer to view information in this table; see “Using the
Replication Analyzer” on page 163. You can also query information in the
trace table directly to gather problem-determination information for the
Capture program.
1. Ensure that the data in the trace table is current. You might want to delete
rows from the table to remove information from past Capture operations.
The Capture program deletes all rows from this table when you cold start
it, so if you want to keep trace information, you should copy the table
before you cold start the Capture program.
2. To gather the problem-determination information for the Capture program,
execute a query similar to:
SELECT *
FROM ASN.IBMSNAP_TRACE
ORDER BY TRACE_TIME
This query returns the following columns from the trace table:
OPERATION
The type of Capture-program operation, such as initialization,
capture, or an error condition.
TRACE_TIME
The time the current row was inserted into this table.
DESCRIPTION
The message ID and message text.
For AS/400 systems, this table also includes the following columns:
JOB_NAME
The fully-qualified name of the job that wrote the current entry.
JOB_STR_TIME
The starting time for the job listed in the JOB_NAME column.
Capture-program trace file
You can trace the operation of the Capture program to help isolate the causes
of certain kinds of replication errors. The Capture program creates a trace file
when you include a trace parameter to the Capture program start command.

See the Capture and Apply chapter in for your platform in “Part 3.
Operations” on page 173 for the syntax of the command.
The Capture program inserts error messages and indicators in the trace file at
points when it encounters an error.
To trace problems on AS/400 systems, view the job logs of the control and
journal jobs. See “Problem determination for AS/400” on page 159 for more
information.
To create a trace file:

1. Start the Capture program with the trace parameter and redirect the
output to a file. For example, to start Capture for Windows with trace,
issue the following command from the command line:
asnccp SrcSrvr trace > capture.trc
where SrcSrvr is the source server and capture.trc is the trace file. Because
this command does not include parameters for the type of start (WARM,
WARMNS, or COLD) or for pruning (PRUNE or NOPRUNE), the Capture
program uses the defaults (WARM and PRUNE). The trace file is created
in the directory from which you start the Capture program.
2. Let replication run until the problem recurs.
3. Stop the Capture program and restart it without the trace parameter.
4. View the trace file using any editor. You could also send the file to other
systems or print it.
Capture-program log file
For a summary of the Capture program’s activities, you can view the
Capture-program log file. The log file is in the directory from which you start
the Capture program and contains messages issued by the Capture program.
The name of the log file is SrcSrvr.CPP, where SrcSrvr is the name of the
source server.
Other problem-determination facilities for the Capture program
For OS/390, VM, and VSE, the Capture program provides the following tools:
Trace buffer
The Capture program puts a small amount of critical diagnostic data
in a wraparound trace buffer during processing. Each trace-buffer
entry describes the current status of data capture. If a severe error
occurs, the Capture program prints the trace buffer before terminating.
The trace buffer supplements the Capture program error message.
Trace output
When an error occurs, you can run the Capture program with the

TRACE option (see “Capture-program trace file” on page 157). When
you use this option, the Capture program writes trace information
logic flow to:
SYSPRINT (for OS/390)
the console (for VM)
STDOUT (for VSE)
This information can be used by IBM Software Support to diagnose
operational problems.
Storage dump
When the Capture program terminates with a severe error, it
generates a system dump in the SYS1.DUMP data set. This dump is
IPCS readable, contains more diagnostic information than the Capture
program trace, and can be used by IBM Software Support to diagnose
system problems.
For OS/390, the Capture program also provides:

Alert generation
If a severe error occurs, the Capture program for OS/390 alerts
NetView, if NetView is active. The alert uses the NMVT format for a
generic alert defined by the SNA generic-alert architecture. If NetView
is not available, the Capture program still writes error messages to the
MVS console.
Problem determination for AS/400

Capture for AS/400 has unique problem determination facilities because of its
dependency on journals and journal receivers as its primary source of input.
This section describes problem-determination facilities for the Capture
program for AS/400 and associated problem-recovery methods: gathering
information about active jobs, determining if the journal job is started, and
collecting data for problem determination.
Gathering information about active jobs
One of the first steps in problem determination is gathering information about
currently active jobs. Issue the Work with Submitted Jobs command
(WRKSBSJOB QZSNDPR) for a list of all active jobs in the subsystem. If you
fail to find a particular job, use the WRKSBMJOB command to locate and
view the job log for the job. The name of the Capture program control job is
QZSNCTL5. The name of the journal job is the same as the journal name
(either QSQJRN–the default journal name for SQL collections–or a name that
you specified for the journal).
Be sure to record the 6-digit job numbers because you might need them later
in the problem-determination process.

Determining if the journal job is started
If, five minutes (or more) after starting the Capture program, you discover
that only one job (QDPRCTL5) is running, check the following conditions:
v If you use the WRKSBSJOB or WRKACTJOB command to display active
jobs, enter option 7 on the command line for job QZSNCTL5. Message
ASN2017 might be waiting for a reply.
v Run the WRKJOB QSQJRN command (substituting the name of the journal
job for your system). The journal job might have started, and subsequently
ended for some reason (for example, if the lag limit was exceeded). If you
find a recent journal job, display its job log to confirm that it is the right job
and to determine why it ended.
v Check if the QDPRCTL5 control job found any replication sources that are
eligible for replication. Two conditions make a replication source eligible for
replication:
– The replication source must be included in at least one subscription set.
– The Apply program must start a full refresh to copy the original contents
of the source table to the target table, even if the source table is empty.
The full refresh synchronizes the target table with the source table. When
the Apply program starts the full refresh, the SYNCHPOINT column in
the pruning control table is set to hex zeroes for this replication pair.
When you first issue the STRDPRCAP command, there might be
replication pairs that meet the first condition, but not the second one. Both
conditions must hold before a journal job can start.
Every two minutes (or at the frequency that you specified for the WAIT
parameter of the STRDPRCAP command), the QZSNCTL5 job wakes up to
determine if any replication source exists that meets both conditions. If it
finds a replication source that is eligible for replication, it starts the journal
job.
To determine if the SYNCHPOINT column in the pruning control table is

set to hex zeroes for a particular replication pair, execute the following SQL
statement from the source server:
SELECT HEX(SYNCHPOINT) FROM ASN/IBMSNAP_PRUNCNTL
WHERE SOURCE_TABLE='SrcTbl' AND SOURCE_OWNER='SrcOwn'
AND SOURCE_VIEW_QUAL=SrcVwQual
where SrcTbl is the library name, SrcOwn is the table name, and SrcVwQual
is the source-view qualifier for the replication source in question. Both
SrcTbl and SrcOwn are case-sensitive.
Collecting data for problem determination
The following items are needed for problem determination for the Capture
program. The items are listed in order of importance:

1. The job log of the Capture-program control job QDPRCTL5.
2. The job log of the Capture-program journal job.
3. Old journal receivers. They are important because they contain important
time-sequence information. Save the journal receivers in a file or keep
them if a remote sign-on by IBM Software Support is likely. The journal
receivers for the following tables are useful for problem determination:
Control tables
These include the register table, the register extension table, the
pruning control table, the unit-of-work table, the critical section
table, and the warm start table. The journal for these tables is
ASN/QSQJRN.
Source table
These journal receivers are kept as long as the Capture program
needs them. Make sure that they are not deleted automatically by
the system because they are useful for problem determination.
Change data table of the replication source
Usually, the journal is named QSQJRN and is in the same library
as the source table. If it is not, find the library and the name of
the journal by issuing a DSPFD lib/sys command (where lib is the
library and sys is the system name of the CD table). To find the
system name of the change data table, execute the following SQL
statement:
SELECT DBXFIL
FROM QSYS/QADBXREF
WHERE DBXLFI = 'sqlname' AND DBXLIB = 'lib'
where sqlname is the SQL name of the CD table. Both sqlname and
lib are case sensitive.
4. A formatted dump of the user index QDPR/QZSNINDEX5. Issue the
following command before the Capture program ends:
DMPOBJ QDPR/QZSNINDEX5 *USRIDX
5. The contents of the rows in the register table and the register extension
table that correspond to replication sources that you want to know more
about. You can collect this information by executing the following SQL
statements:
SELECT A.*, HEX(CD_OLD_SYNCHPOINT), HEX(CD_NEW_SYNCHPOINT)
FROM ASN/IBMSNAP_REGISTER A
WHERE SOURCE_OWNER='SrcOwn' AND SOURCE_TABLE='SrcTbl'
SELECT *
FROM ASN.IBMSNAP_REG_EXT
WHERE SOURCE_OWNER='SrcOwn' AND SOURCE_TABLE='SrcTbl'

where SrcOwn is the library name and SrcTbl is the table name of the
replication source in question. Both SrcOwn and SrcTbl are case sensitive.
6. The contents of the global row in the register table. You can check the
progress of the Capture program by executing the following SQL
statement:
SELECT A.*, HEX(SYNCHPOINT)
FROM ASN/IBMSNAP_REGISTER A
WHERE GLOBAL_RECORD = 'Y'
7. Entries in the trace table for significant job events. To find entries for the
Capture program control job or the Capture program journal job, execute
the following SQL statement:
SELECT *
FROM ASN/IBMSNAP_TRACE
WHERE SUBSTR(JOB_NAME, 21, 6) = 'jobnum'
ORDER BY TRACE_TIME
where jobnum is the job number for the job you want to investigate. The
DESCRIPTION column provides important information about the job.
Examples:
To gather trace table entries after 7 a.m., March 31, 2000, execute the
following query:
SELECT *
WHERE TRACE_TIME > '2000-03-31-07.00.00.000000'
ORDER BY TRACE_TIME
To retrieve all ASN0303 (data capturing is interrupted...) trace entries

after 7 a.m., March 31, 2000, execute the following query:
SELECT *
WHERE TRACE_TIME > '2000-03-31-07.00.00.000000' AND
SUBSTR(DESCRIPTION, 1, 7) = 'ASN0303'
ORDER BY TRACE_TIME
8. Rows from the warm start table. There is a row for every journal that is
used by one or more replication sources. You can retrieve the row for the
journal job by executing the following SQL statement:
SELECT *
FROM ASN/IBMSNAP_WARM_START
WHERE JRN_LIB='JLib' AND JRN_NAME='JName'
where JLib is the library name and JName is the table name for the
journal. Both JLib and JName are case sensitive.
9. Data from the target server that can help determine how and why the
Apply program fails to replicate to the target table:

v The audit trail table
v The job log of the Apply program
v The subscription set table and its journal receivers (to find out how
some columns changed over time)
10. A formatted dump of the user spaces for the journal jobs. These jobs are
in library QDPR and they have the name QDPRxxxxxx, where xxxxxx is
the job number of the journal job. Issue the following command before
the Capture program ends:
DMPOBJ QDPR/QDPRxxxxxx *USRSPC
Using the Replication Analyzer

The Replication Analyzer analyzes the following tables for correctness,
consistency, and efficiency: replication control tables, change data tables, target
tables, and target-table indexes. It also checks database parameters for optimal
replication performance. You can use the Replication Analyzer to analyze the
behavior of the Capture program or the Apply program. It can answer such
questions as: ″Why is Capture not capturing?″ and ″why is Apply not
applying?″ The Replication Analyzer can help diagnose problems, verify
replication setup, and offer suggestions for performance tuning.
You can run the Replication Analyzer at any time after replication setup is
complete to analyze a failure by the Capture program or the Apply program,
or simply to verify your setup. You can find the Replication Analyzer in the
\sqllib\bin directory. The bind file for the Analyzer, analyze.bnd, is in the
\sqllib\bnd directory, but it is not necessary to bind the program because the
Analyzer is autobound for DB2 V6 and V7. If you run the Analyzer with DB2
V5, use the following command to bind the Analyzer:
bind analyze.bnd isolation UR
Important: The Replication Analyzer works only with DataPropagator Version

5 or later; it does not work with DataPropagator Version 1. Contact IBM
Software Support if you need a version of the Replication Analyzer that can
work with DataPropagator Version 1.
You run the Replication Analyzer from the Windows command line. Type the
name of the Replication Analyzer command file (analyze.exe) followed by a
list of DB2 alias names of source, target and control servers, separated by
blanks (each of these names must be eight or fewer characters in length).
Because the Replication Analyzer runs from the command line, you do not
need to have either DJRA or the DB2 Control Center running when you run
the Replication Analyzer.

If end-user authentication is required to connect to any server, you must
create a password file in the current directory. This file must be named
analyze.pwd and should contain one or more entries with the following
format:
SERVER=server_alias USER=userid PWD=password
IBM Software Support may ask you to run the Replication Analyzer and send
the generated file to someone within IBM to check the output for correctness.
Syntax:
analyze U DB_alias_name A
deepcheck
lightcheck
?
A:
U
q = ApplyQual f = directory
deepcheck
Specifies that the Analyzer perform a more complete analysis, including
CD and UOW table pruning information, DB2 for OS/390 tablespace
partitioning and compression detail, and analysis of target indexes with
respect to subscription keys. The analysis includes all servers. This
keyword is optional.
f Specifies the directory in which to store the output HTML file. If you do
not specify this keyword, the HTML file is created in the current directory.
No space is allowed between the keyword (f), the equal sign, and the
value. This keyword is optional.
lightcheck
Specifies that all column detail be excluded from the report, thus reducing
report generation time, saving resources, and producing a smaller HTML
file. This keyword is optional and is mutually exclusive with the
deepcheck keyword.
q Specifies the Apply qualifier to use as a filter to restrict analysis of
subscription sets. You can specify the q keyword more than once if you
want to analyze multiple Apply qualifiers. No space is allowed between
the keyword (q), the equal sign, and the value. This keyword is optional.

? Shows the syntax of the analyze command.
The keywords are not case sensitive.
Output: The Replication Analyzer creates an output HTML file, analyze.htm,

which you can open and view with any Web browser. This file is stored in the
same directory from which you run the Analyzer, or in the directory specified
by the f keyword. Messages from the Analyzer are sent to stdout. The output
HTML file contains the following information:
v Contents of replication control tables
v Information about packages and plans, including advice for the
ISOLATION level of the package or plan
v Change data table (CD) column analysis
v Consistent Change Data table (CCD) column analysis
v Subscription target key synopsis
v Number of rows in the CD and UOW tables, and the number of rows that
are eligible for pruning
v Selected DB2 for OS/390 SYSTABLEPART information
v Subscription history details
v Tablespace information
v Orphan table or view references; these are tables or views that are
referenced but do not exist (or their existence cannot be confirmed)
v Incorrect or inefficient indexes
v Incorrect or inefficient tablespace LOCKSIZE values
v Subscription errors, omissions, or anomalies
v Subscription SQL statement errors
v Apply process summary
v Why the Capture program is not capturing
v Capture tuning troubles
Some of this information is only included when the deepcheck keyword is
specified.
Examples:
analyze mydb1 mydb2
analyze mydb1 mydb2 f=mydirectory
analyze lightcheck mydb1 mydb2
analyze q=applyqual1 q=applyqual2 deepcheck mydb1 mydb2 f=mydirectory

Troubleshooting
This section describes various problems that can occur when running the
Capture and Apply programs and how to diagnose the cause of these
problems. You should also use the Replication Analyzer to determine general
and specific problems with the replication environment.
Problem: The Capture for OS/390 program does not start.
Ensure that APF authorization was performed for all STEPLIB libraries as
specified in the RUN JCL.
Problem: Capture for VM or Capture for VSE does not start.
Ensure that:
v Access was given for the database log and directory minidisks. Note that
the Capture program issues internal links to these minidisks.
v Access was given to the C Run Time Library.
v *IDENT authorization was given to the Capture program virtual machine.
v The ASNLMAIN package file was loaded to the database.
v For VM: *IDENT authorization was given to the Capture program virtual
machine.
Problem: The Capture program is not capturing updates.
Any of the following errors could prevent the Capture program from
capturing updates:
v Proper authorization was not granted to the user ID running the Capture
program.
v DATA CAPTURE CHANGES was not specified on the source tables to be
captured. At startup, the Capture program checks that registered tables
have DATA CAPTURE CHANGES specified. If tables are altered after the
Capture program is running, stop and restart the Capture program so that
it can find the tables altered to include DATA CAPTURE CHANGES.
v The proper order for starting the Capture and Apply programs was not
used:
1. Define replication sources and subscriptions before starting the Capture
program.
2. Start the Capture program and look for message number ASN0100I
(initialization completed) in the system console or in the trace table.
3. Start the Apply program so that it performs a full refresh before the
Capture program starts capturing updates.
Check the trace table for possible error messages.

Problem: I’m not sure if the Capture program is running successfully.
The first time that you start the Capture and Apply programs, the Apply
program performs a full refresh to populate the target tables. Then the
Capture program writes message ASN0104I to the trace table, providing
information related to table owner name, table name, and starting log
sequence number value. This information provides a point from which the
Capture program starts to capture updates.
Updates captured from then on are placed in CD tables. They are eventually
applied to target tables and pruned from the CD tables. After the Capture
program runs for some time, you should see rows in the CD tables if changes
are made to the sources. Periodically, check the trace table to see the progress
made by the Capture program. If it encounters errors, it sends them to the
console and also logs them in the trace table. Similarly, the Apply program
logs its information in the Apply trail table.
Problem: Capture for OS/390 issued message ASN0000E instead of the proper
message number.
Message ASN0000E is a generic message that is issued instead of a proper

message if the specified VSAM message file in the RUN JCL was not found.
See the Capture for OS/390 program directory for information on installing
the VSAM message file.
Problem: Capture for VM or Capture for VSE issued message ASN0000E instead of
the proper message number.
Message ASN0000E is a generic message that is issued instead of a proper

message if either the default message file, ASNLS001 MSG, or the specified
message file in the Capture startup JCL was not found. See the Capture for
VM or Capture for VSE program directory for information on installing the
message file.
Problem: The Capture program terminates.
The Capture program terminates either because of a severe error, or when you
issue the stop command. The Capture program terminates with a return code
that indicates successful or unsuccessful completion. Return codes are:
0 stop command issued
8 Error during initialization
12 Any other severe error
Problem: Capture for OS/390 failed while using the LE for OS/390 environment.

The Capture program runs in the LE for OS/390 environment and the
recommended minimum Capture job-step region size when starting Capture is
REGION=10M.
Problem: Error message 0509 was issued.
Error message 0509 occurs because multiple versions of DB2, or DB2 and
DataJoiner, are installed on the same system:
v 0509-0306 Cannot load program asnccp for the following errors:
v 0509-0222 Cannot load the library libdb2.a(shr.o)
v 0509-0026 System error: a file or directory does not exist
Ensure that the LIBPATH environment variable is set to the same environment
in which the Apply program starts.
Problem: Apply component for DB2 Universal Database stops with an SQLCODE=
-330, SQLSTATE=22517, ″A string cannot be used, because its characters cannot be
translated″.
When copying between DB2 for OS/390 and DB2 on another platform, the
CCSID translation can cause an INSERT to fail if a translated value is longer
than the DB2 column in which it will be inserted.
If you are running in a mixed environment, ensure that you have installed the
latest maintenance for the CCSID support of your DB2 for OS/390 program.
For more information on character translation, see the character conversion

appendix in the DB2 for OS/390: Installation Guide.
Problem: I received system error 1067 trying to start the Capture or Apply program
as a Windows NT Service.
Error code 1067 occurs under the following circumstances:

v You did not specify the user ID and password and the Capture or Apply
program is trying to run on the system account.
v You did not specify the ASNPATH environment variable correctly or you
did not reboot the computer after updating the value of ASNPATH.
v There is no NTSERV.ASN file in the path specified by ASNPATH.
v The NTSERV.ASN file does not have the line:
dbname pathname\asnccp.exe <parameters>
followed by CRLF.
Problem: The ASNSERV.LOG file in ASNPATH tells me that the Apply program
was started correctly, but the Apply process terminated.

To find out why the Apply program terminated, change the syntax of
NTSERV.ASN to:
...ASNAPPLY APPLYQUAL TRCFILE
The trace output will be written to the Apply trace file:

<ASNPATH pathname>ApplyQual.TRC
Problem: I performed a successful bind, but when running the Apply program, I still
get SQLCODE -805, SQLSTATE 51002.
Make sure that the user ID has EXECUTE privilege on the Apply program
packages, and make sure to bind both the Apply program packages to the
control, source, and target server databases.
Problem: The DB2 log filled to capacity because I copied a very large table.
If the error occurred during a full refresh, you can use alternative methods to
load large tables. You can either use the ASNLOAD exit routine, or you can
perform your own load, as described in “Loading target tables offline using
DJRA” on page 127.
If the error occurred while applying changed data, then you can change the
data-blocking parameter to break down large blocks of changed data. See
“Specifying a data-blocking value” on page 122.
Problem: Capture was cold started, which caused the Apply program to perform a
full refresh, but I don’t want a full refresh.
If your target table is very large, and in cases where you decided to use only
your own load mechanism, you might want to suppress any future full
refreshes of the Apply program. Set the DISABLE_REFRESH flag to 1 in the
register table at the source server for the source table. In this case, the Apply
program issues message ASN1016E and copies nothing until you perform a
full refresh.
If you want to bypass full refresh and also start capturing data as soon as
possible, you can use the offline load function of DJRA. In this case, you do
not need to unload and reload the tables, but just run the SQL generated for
step 1 and step 4. In addition to disabling full refresh, offline load also
deactivates the subscription until you complete step 4. See “Loading target
tables offline using DJRA” on page 127.
Problem: A gap was detected, so the Apply program won’t perform a full refresh of
my target table.

Force a full refresh by resetting the LASTSUCCESS, SYNCHTIME, and
SYNCHPOINT values in subscription set table to null.
Problem: I unsuccessfully tried to start a second Apply program instance.
You must run each instance with a unique Apply qualifier.
Problem: I received a security violation message, and the Apply program is not
authorized to connect to the database.
The control server name, user ID, and password definitions are case sensitive
and must match exactly those specified in the password file. Check your
definitions again.
Apply for AS/400 does not use a password file, so it attempts to connect to
the database using the user ID specified in the user parameter of the
STRDPRAPY CL command. Ensure that you correctly set up your DRDA
connectivity definitions.
Problem: I received error ASN1003 with SQLCODE = -1032 and SQLSTATE =

57019.
You must start the database manager before invoking the Apply program.
Problem: Apply receives SQLCODE -206 when fetching the source data.
If you use a CCD table to stage replication to multiple target tables, ensure
that the CD or CCD table includes all the columns expected in all target
tables. Subsetting columns or selecting UOW columns to be replicated to the
final targets can cause this problem when a CCD table is added to a
replication scenario after the target tables are defined.
This problem should only occur if you manually define target tables and do
not include all the columns when defining replication sources. You can avoid
this problem by defining all target tables (adding to subscription sets) after
defining any CD and internal CCD tables. DJRA does not allow columns in a
target table that are not in the predefined CD or internal CCD tables; DJRA
displays only a valid subset of the columns for the target table.
Problem: SQL1108 error while creating control table using DJRA
A SQL1108 error results if DB2 DataJoiner is installed on the same Windows

NT system as DJRA, and you try to create the control tables in DB2 for
OS/390. The problem is caused by a memory collision with the required
memory space for ddcs.dll, because this DLL is not loaded during application
initialization.

The workaround for this problem is to set the environment variable
DB2DBMSADDR (range is between 20000000 to 70000000). This tells DB2 to
put its memory in a different virtual address space to avoid collision with the
application address space.
Problem-source identification questions

If you call IBM Software Support, you will be asked the following types of
questions. You can save time, and perhaps diagnose the error yourself, by
researching the answers to these questions:
1. What was occurring at the time of the problem?
2. What has changed recently in the environment?
3. Describe the environment.
4. What is the maintenance level of DB2 Universal Database where the
Control Center is installed?
5. On what platform is the Capture program running?
6. What is the maintenance level of the Capture program?
7. What is the maintenance level of DB2 (or non-IBM DBMS) where the
Capture program is running?
8. On what platform is the Apply program running?
9. What is the maintenance level of the Apply program?
10. On what release of DB2 (or DB2 DataJoiner) does the Apply program
run?
11. What is the maintenance level of DB2 (or DB2 DataJoiner) where the
Apply program is running?
12. Is this an occasionally-connected user? A DB2 Satellite user? A DB2
Everywhere user?
13. What ASN messages were issued?
14. Are there other messages in SYSLOG (for AS/400, the QSYSOPR message
queue), on the screen, or in the trace file?
15. What is the complete message text for all messages issued? Be sure to
note all message numbers, database names, table names, user IDs, and
file names that appear in these messages.
16. Where does the failure occur?
a. The DB2 Control Center
v Is the problem with a replication source or subscription set?
v What messages appear?
v Can the user successfully connect to the source or target database
from a command line or DB2 command window?
b. DJRA

v What level of DJRA are you using? Click Help –򐂰 About from the
main window for this information.
v If accessing non-IBM data sources, what level of DB2 DataJoiner are
you using, and on which platform (AIX or Windows NT)?
v Did you save the generated script file and the output file?
c. The Capture program
v Is the Capture program running?
v If not, what happens when you try to warm start it?
v Is there error information in the trace table
(ASN.IBMSNAP_TRACE)?
v Is there error information in the Capture program log file?
v What is the DB2 configuration?
v Are data changes successfully inserted into the CD tables?
v Does the user ID running the Capture program have sufficient
privileges to run the Capture program?
d. The Apply program
v Is the Apply program running?
v If not, what occurs when the Apply program starts?
v What messages appear?
v Is there error information in the Apply trail table
(ASN.IBMSNAP_APPLYTRAIL)?
v Is there error information in the Apply program log file (for
AS/400, in the Apply job log)?
v Are data changes being successfully replicated to the target table?
v Do all tables in a subscription set have the same problem?
v What table types (for example, user copy, point-in-time, CCD) are
involved in the failure?
v Did you start the Apply program with the trace option?
v Are CALL procedures being used?
v Is a CCD table being used?

Part 3. Operations
This part of the book describes specific operating instructions for particular
operating systems:
“Chapter 9. Capture and Apply for AS/400” on page 175 describes how to
operate the Capture and Apply programs on the AS/400 operating system.
“Chapter 10. Capture and Apply for OS/390” on page 225 describes how to
operate the Capture and Apply programs on the OS/390 operating system.
“Chapter 11. Capture and Apply for UNIX platforms” on page 239 describes
how to operate the Capture and Apply programs on UNIX operating systems.
“Chapter 12. Capture for VM and Capture for VSE” on page 255 describes
how to operate the Capture program on the VM and VSE operating systems.
“Chapter 13. Capture and Apply for Windows and OS/2” on page 263
describes how to operate the Capture and Apply programs on the Windows
and OS/2 operating systems.

Chapter 9. Capture and Apply for AS/400
This chapter describes how to set up and operate the Capture and Apply
programs for DB2 DataPropagator for AS/400 Version 7.
Be sure to read the following sections before reading the sections on operating
the Capture and Apply programs for AS/400:
v “Coexistence considerations”
v “Setting up the Capture and Apply programs” on page 176
v “Authorization requirements for running the Capture and Apply programs”
on page 181
v “Restrictions for running the Capture program” on page 190
v “The journal” on page 191
v “Defining replication sources and subscription sets” on page 196
v “Using a relative record number (RRN) as a primary key” on page 196
Coexistence considerations
You cannot run Version 1 of DB2 DataPropagator for AS/400 concurrently
with Version 7. If you currently use Version 1, or if you use Version 1
replication components in a Version 5 DB2 DataPropagator for AS/400
environment, you must either:
v Migrate your Version 1 replication environment to Version 5. Instructions
are in the Migration Guide in the Library page of the DB2 DataPropagator
Web site (www.ibm.com/software/data/dpropr/).
v If your Version 1 replication environment is small (for example, if it
contains fewer than 50 source registrations and subscriptions), do not
migrate to Version 5. Instead, use the DataJoiner Replication Administration
(DJRA) tool to create your replication environment in Version 7.
You should use DJRA for all replication administration tasks. However, both
DJRA and the DB2 Control Center provide basic replication administration
functions for defining replication sources and subscription sets. Only DJRA
provides support for remote journals and the use of a relative record number
(RRN) as a primary key.

Setting up the Capture and Apply programs
Setting up the Capture and Apply programs consists of installing DB2
DataPropagator for AS/400 and tuning the Capture program for optimum
productivity. This section describes how to set up the Capture and Apply
programs.
Installing DB2 DataPropagator for AS/400
You install DB2 DataPropagator for AS/400 in the same way that you install
any other licensed program. Follow these steps for the regular installation:
1. Type GO LICPGM on the AS/400 command line.
2. Select option 11 (Install licensed programs).
3. Page down to locate DataPropagator Relational for AS/400 (5769DP3).
If the window does not contain the product ID number (5769DP3) on the
install screen, exit LICPGM and enter RSTLICPGM on the AS/400 command
line, and then specify 5769DP3 for the product ID.
If the window does contain the ID number, type a 1 next to it and press
the Enter key.
Connecting to an AS/400 server
Before you connect to an AS/400 server from a DB2 for Windows NT or
Windows 95 client, make sure that your workstation is set up correctly:
v You have a DB2 UDB or DB2 Client Application Enabler (CAE) client
installed on your workstation.
v You have TCP/IP set up on your workstation.
For example, use the following steps to connect to an AS/400 server from a
DB2 for Windows NT workstation:
1. Log on to the AS/400 server and locate the relational database:
a. Log on to the AS/400 server to which you want to connect.
b. Submit a dsprdbdire command, and then specify local for *LOCAL.
c. Locate the name of the relational database in the output. For example,
in the following output, the database is called DB2400E:
MYDBOS2 9.112.14.67
RCHASDPD RCHASDPD
DB2400E *LOCAL
RCHASLJN RCHASLJN
2. Catalog the AS/400 database in DB2 for Windows NT:
a. From your Windows NT workstation, click Start->Programs->DB2 for
Windows NT->Command Window. The DB2 CLP command window
opens.
b. In the command window, type the following three commands in exact
order:

CRTDPRTBL
db2 catalog tcpip node server_name remote server_name server 446 system
server_name ostype OS400
db2 catalog dcs database rdb_name AS rdb_name
db2 catalog database rdb_name AS rdb_name at node server_name

authentication dcs
Where server_name is the TCP/IP host name of the AS/400 system, and
rdb_name is the name of the AS/400 relational database that you found
in Step 1 on page 176.
3. In the command window, issue the following command:
db2 terminate
4. Ensure that the AS/400 user profile that you will use to log on to your
AS/400 system uses CCSID37:
a. Log on to the AS/400 system.
b. Type the following command, where user is the user profile:
CHGUSRPRF USRPRF (user) CCSID(37)
c. To make sure that DB2 for Windows NT and DB2 for AS/400 have
been connected, issue the following command:
db2 connect to rdb_name user user_name using password
5. Make sure that the DDM server is started on the AS/400 system by
typing:
STRTCPSVR SERVER(*DDM)
6. From your Windows NT workstation, use the Control Center or DJRA to
administer the AS/400 database.
Verifying and customizing your installation of DB2 DataPropagator for
AS/400
You should install DB2 DataPropagator for AS/400 before using the
replication administration tools, because the installation process issues the
CRTDPRTBL command to automatically create the replication control tables.
These tables are created in the DataPropagator Relational collection (named
ASN), if they do not already exist.
The installation program also creates an SQL journal, an SQL journal receiver
for this library, and work management objects. Table 8 lists the work
management objects that are created.
Table 8. Work management objects
Description Object type Name
Subsystem description *SBSD QDPR/QZSNDPR
Job queue *JOBQ QDPR/QZSNDPR
Job description *JOBD QDPR/QZSNDPR

CRTDPRTBL
A note on work management: You can alter the default definitions or provide
your own definitions. See OS/400 Work Management V4R3, SC41–5306 for more
information about changing these definitions.
Creating the replication control tables

If your replication control tables are accidentally deleted or corrupted, you can
create them manually using the Create DPR Tables (CRTDPRTBL) command.
You must have *ALLOBJ authority to run this command.
Important: The CRTDPRTBL command is the only command that you should
use to create AS/400 control tables. Do not use DJRA to create the control
tables.
CRTDPRTBL
7
DPRVSN( 5 )
Table 9. CRTDPRTBL command parameter definitions for AS/400

Parameter Definition and prompts
DPRVSN Specifies the version of the control tables to create.
7 (default)
Specifies Version 7 control tables. The system creates all of the
control tables for replication sources and targets along with the
default SQL journal.
5 Specifies Version 5 control tables.
Specifying tuning parameters for Capture for AS/400

To control the performance of the Capture program, you can adjust four
tuning parameters on the server by changing the values of columns in the
tuning parameters table.
To specify the tuning parameters, do one of the following tasks:

v Update the tuning parameters table manually. See “Specifying tuning
parameters for the Capture program” on page 128 for more information.
v Run the CHGDPRCAPA command. See “Changing Capture program
attributes” on page 179 for more information about this command.
v Customize the DPCNTL.400 file in the DB2 Control Center
\sqllib\samples\repl directory before you define the first replication source
for a database. You do not need to customize the DPCNTL.400 file if you
have already installed DB2 DataPropagator for AS/400.

CHGDPRCAPA
Changing Capture program attributes

The Change DPR Capture Attributes (CHGDPRCAPA) command changes the
global operating parameters in the tuning parameters table for the Capture
program.
You can see the current values of the Capture program attributes if you issue
the CHGDPRCAPA command with the F4 key to prompt on the command.
CHGDPRCAPA
RETAIN( *SAME ) LAG( *SAME )
minutes minutes

FRCFRQ( *SAME ) CLNUPITV( *SAME )
seconds 1-100
Table 10. CHGDPRCAPA command parameter definitions for AS/400

RETAIN Specifies the new retention limit, which is the number of minutes
that data is retained in the CD tables and the UOW table before it is
removed.
The value of this parameter works with the CLNUPITV parameter.

When the CLNUPITV value is reached, data in the CD and UOW
tables is removed if the UOW table row shows that the transaction
is older than the value of this parameter.
Ensure that the Apply intervals are set to copy changed information
before the value on the RETAIN parameter is reached. This prevents
your tables from becoming inconsistent. If they become inconsistent,
the Apply program performs full refreshes.
*SAME (default)
Specifies that the value remains unchanged.
minutes
Specifies the number of minutes that the CD is retained. The
maximum value is 35 000 000. The default value is 10 080
minutes (7 days).

CHGDPRCAPA
Table 10. CHGDPRCAPA command parameter definitions for AS/400 (continued)

LAG Specifies the new lag limit, which is the number of minutes that the
Capture program can fall behind before clearing out the CD tables
and starting over with change capture. When the lag limit is
reached (that is, when the timestamp of the journal entry is older
than the current time minus the lag limit), the Capture program
assumes that it is too far behind to catch up. It then initiates a cold
start for the tables that it is processing for that journal. The Apply
program then performs a full refresh to provide the Capture
program with a new starting point. Users typically set this value
high so that it has no effect.
*SAME (default)
minutes
Specifies the number of minutes that the CD entries are allowed
to fall behind. The maximum value is 35 000 000. The default
value is 10 080 minutes (7 days).
FRCFRQ Specifies approximately how often the Capture program writes

changes to the CD and UOW tables.
The Capture program makes the changes available to the Apply

program either when the buffers are filled or when this time has
expired, whichever is sooner.
Use this parameter to make source table changes more readily

available for the Apply program on servers with a low rate of
source table changes.
This is a global value, and is used for all defined source tables.
Setting this value at a lower number can affect processor usage.
*SAME (default)
seconds
Specifies the number of seconds that the Capture program
keeps CD table and UOW table changes in buffer space before
making them available for use by the Apply program. This
value can range from 30 to 600 seconds. The default value is
180 seconds.

CHGDPRCAPA
Table 10. CHGDPRCAPA command parameter definitions for AS/400 (continued)

CLNUPITV Specifies the maximum length of time before the Capture program
prunes old records from the CD tables and the UOW table, if it
exists. This parameter works with the RETAIN parameter.
The value of this parameter is converted from hours to seconds and

stored in the PRUNE_INTERVAL column of the tuning parameters
table. If the PRUNE_INTERVAL column is changed manually (not
using the CHGDPRCAPA command), you might see changes due to
rounding when you prompt using the F4 key.
*SAME (default)
1–100
Specifies the maximum number of hours that you want the
Capture program to wait before pruning. Valid values are
1–100.
Authorization requirements for running the Capture and Apply programs

This section describes the commands available for granting and revoking
authority to the replication control tables: “Granting authority” and “Revoking
authority” on page 189.
Granting authority
The Grant DPR Authority (GRTDPRAUT) command authorizes a list of users
to the replication control tables, so that the users can run the Capture and
Apply programs. For example, the authority requirements for the user who is
running the Capture and Apply programs might differ from the authority
requirements for the user who defines replication sources and targets.
You must have *ALLOBJ authority to grant authorities.

GRTDPRAUT USER( user-name ) AUT( *REGISTRAR )
*PUBLIC *SUBSCRIBER
*CAPTURE
*APPLY
7 *ALL
DPRVSN( 5 ) APYQUAL( *USER )
apply-qualifier

GRTDPRAUT
Table 11. GRTDPRAUT command parameter definitions for AS/400

USER Specifies the users who have authority.
user-name
Specifies the names of up to 50 users who have authority.
*PUBLIC
Specifies that *PUBLIC authority is granted to the file, but (if
insufficient for the task) is used only for those users who have
no specific authority, who are not on the authorization list
associated with the file, and whose group profile does not have
any authority.

GRTDPRAUT
Table 11. GRTDPRAUT command parameter definitions for AS/400 (continued)

AUT Specifies the type of authority being granted.
*REGISTRAR (default)
Specifies that the users are granted the authorities to define,
change, and remove subscription sets.
For a complete list of authorities with AUT(*REGISTRAR), see
Table 12 on page 185.
*SUBSCRIBER
Specifies that the users are granted authority to define, change,
and remove subscription sets.
For a complete list of authorities with AUT(*SUBSCRIBER), see
Table 13 on page 186.
*CAPTURE
Specifies that the users are granted authority to run the Capture
program.
For a complete list of authorities granted with
AUT(*CAPTURE), see Table 14 on page 187.
*APPLY
Specifies that the users are granted authority to run the Apply
program.
The command does not grant authority to any of the objects
that reside on other databases accessed by the Apply program.
When an Apply process is invoked, the user associated with the
DRDA application server job must also be granted *APPLY
authority. If the source is an AS/400 server, the GRTDPRAUT
command should be run on the source server system, with the
application server job user specified on the USER parameter
and the Apply qualifier specified on the APYQUAL parameter.
Authorities are not granted to the target tables unless the target
server is the same as the control server and both reside on the
system where the command is run.
For a complete list of authorities granted with AUT(*APPLY),
see Table 15 on page 188.
DPRVSN Specifies the version of DB2 DataPropagator for AS/400.

7 (default)
Specifies Version 7 of DB2 DataPropagator for AS/400.
5 Specifies Version 5 of DB2 DataPropagator for AS/400.

GRTDPRAUT
Table 11. GRTDPRAUT command parameter definitions for AS/400 (continued)

APYQUAL Specifies the Apply qualifier to be used by the user specified with
the USER parameter. This parameter is used only when
AUT(*APPLY) or AUT(*SUBSCRIBER) is specified.
*ALL (default)
Specifies that the user is granted authority to run the Apply
program or to define and remove subscriptions for all Apply
qualifiers.
*USER
Specifies that the users specified on the USER parameter are
granted authority to subscriptions with an Apply qualifier that
is the same as the user name.
apply-qualifier
Specifies that the user is granted authority to run the Apply
program or define and remove subscriptions for the Apply
qualifiers associated with this Apply qualifier.
v The user is granted authority to all replication sources, CD
tables, and CCD tables associated with records in the pruning
control table that have a value in the APPLY_QUAL column
matching the value input with the APYQUAL parameter.
v The user is granted authority to the subscriptions listed in the
subscription-targets-member table that reside on this system.
You cannot use the GRTDPRAUT command while the Capture or Apply
programs are running, or when applications that use the source tables are
active because authorizations cannot be changed on files that are in use.
Examples
Example 1: To authorize user USER1 to define and modify replication

sources:
GRTDPRAUT USER(USER1) AUT(*REGISTRAR) DPRVSN(7)
Example 2: To authorize user USER1 to define and modify subscriptions:

GRTDPRAUT USER(USER1) AUT(*SUBSCRIBER) DPRVSN(7)
Example 3: To authorize user USER1 to define and modify existing

subscriptions associated with Apply qualifier A1:
GRTDPRAUT USER(USER1) AUT(*SUBSCRIBER) DPRVSN(7) APYQUAL(A1)

GRTDPRAUT
Example 4: To authorize a user to run the Apply program on the control

server system for all subscriptions associated with Apply qualifier A1, where
the target server is the same as the control server:
1. Run the following command on the system where the Apply program will
run:
GRTDPRAUT USER(USER1) AUT(*APPLY) DPRVSN(7) APYQUAL(A1)
2. If the application server job on the source server used by the Apply
program runs under user profile USER1, run the following command on
the source server systems:
GRTDPRAUT USER(USER1) AUT(*APPLY) DPRVSN(7) APYQUAL(A1)
If the application server job on the source server used by the Apply
program runs under a different user profile; for example, QUSER, the
command is:
GRTDPRAUT USER(QUSER) AUT(*APPLY) DPRVSN(7) APYQUAL(A1)
The levels of authority

The following tables list the authorities granted when you specify:
v AUT(*REGISTRAR)
v AUT*(SUBSCRIBER)
v AUT(*CAPTURE)
v AUT(*APPLY)
on the GRTDPRAUT command.
The following table lists the authorities granted when you specify the
AUT(*REGISTRAR) parameter on the GRTDPRAUT command:
Table 12. Authorities granted with GRTDPRAUT AUT(*REGISTRAR)
Library Object Type Version Authorizations
QSYS ASN *LIB 57 *USE, *ADD
ASN QSQJRN *JRN 57 *OBJOPR,
*OBJMGT
ASN IBMSNAP_REGISTER *FILE 7 *OBJOPR,
*READ, *ADD,
*UPD, *DLT
ASN IBMSNAP_REGISTERX *FILE 7 *OBJOPR,
*READ, *ADD,
*UPD, *DLT
ASN IBMSNAP_REG_EXT *FILE 57 *OBJOPR,
*OBJMGT,
*READ, *ADD,
*UPD, *DLT

GRTDPRAUT
Table 12. Authorities granted with GRTDPRAUT AUT(*REGISTRAR) (continued)

ASN IBMSNAP_REG_EXTX *FILE 57 *OBJOPR,
*OBJMGT,
*READ, *ADD,
*UPD, *DLT
ASN IBMSNAP_UOW *FILE 57 *OBJOPR,
*OBJMGT,
*READ, *ADD
*DLT
ASN IBMSNAP_UOW_IDX *FILE 57 *OBJOPR,
*OBJMGT,
*READ, *ADD,
*DLT
ASN IBMSNAP_PRUNCNTL *FILE 7 *OBJOPR,
*READ
ASN IBMSNAP_CCPPARMS *FILE 57 *OBJOPR,
*READ, *UPD
ASN QZSNCTLBLK *USRSPC 5 7 *CHANGE
ASN ASN4B* *SQLPKG 7 *USE
ASN ASN4C* *SQLPKG 7 *USE
QSYS Source library *LIB 57 *USE
Source library Source table *FILE 57 *OBJOPR,
*READ
QSYS Control library *LIB 57 *USE, *ADD
Control library CDtimestamp - CD table *FILE 7 *USE, *OBJMGT,
*OBJEXIST
AUT(*SUBSCRIBER) parameter on the GRTDPRAUT command:
Table 13. Authorities granted with GRTDPRAUT AUT(*SUBSCRIBER)
QSYS ASN *LIB 7 *USE, *ADD
QSYS IBMSNAP_SUBS_SET *FILE 7 *CHANGE
ASN IBMSNAP_APPLYTRAIL *FILE 7 *CHANGE
ASN IBMSNAP_SUBS_COL *FILE 7 *CHANGE
ASN IBMSNAP_SUBS_EVENT *FILE 7 *CHANGE
ASN IBMSNAP_SUBS_STMTS *FILE 7 *CHANGE

GRTDPRAUT
Table 13. Authorities granted with GRTDPRAUT AUT(*SUBSCRIBER) (continued)

ASN IBMSNAP_SUBS_MEMBR *FILE 7 *CHANGE
ASN IBMSNAP_REGISTER *FILE 7 *USE, *UPD
ASN IBMSNAP_REG_EXT *FILE 57 *USE, *UPD
ASN IBMSNAP_PRUNCNTL *FILE 7 *USE, *ADD,
*DLT
ASN ASN4U* *SQLPKG 7 *USE
ASN ASN4A* *SQLPKG 7 *USE
QSYS Source library *LIB 57 *USE
Source library Source table *FILE 57 *OBJOPR,
*READ
QSYS Control library *LIB 7 *USE
Control library ASNtimestampPC - *LIB 7 *USE
pruning control table
Control library CD table *FILE 57 *OBJOPR,
*READ
Control library Internal CCD table *FILE 57 *OBJOPR,
*READ
QSYS Target library *LIB 7 *USE, *ADD
Target library Target table *FILE 7 *USE, *OBJMGT,
*OBJEXIST
AUT(*CAPTURE) parameter on the GRTDPRAUT command:
Table 14. Authorities granted with GRTDPRAUT AUT(*CAPTURE)
QSYS ASN *LIB 57 *USE, *OBJMGT
*OBJMGT,
*READ, *UPD,
*DLT, *ADD

GRTDPRAUT
Table 14. Authorities granted with GRTDPRAUT AUT(*CAPTURE) (continued)

*OBJMGT,
*READ, *UPD,
*DLT, *ADD
ASN IBMSNAP_PRUNCNTL *FILE 7 *USE, *UPD
ASN IBMSNAP_CRITSEC *FILE 7 *USE
ASN IBMSNAP_CCPPARMS *FILE 57 *USE
ASN IBMSNAP_UOW *FILE 57 *CHANGE
ASN IBMSNAP_TRACE *FILE 7 *CHANGE
ASN IBMSNAP_WARM_START *FILE 7 *CHANGE
ASN IBMSNAP_AUTHTKN *FILE 7 *CHANGE
ASN QZSBCTKBLK *USRSPC 5 7 *CHANGE
ASN ASNB* SQLPKG 7 *USE
ASN ASNC* SQLPKG 7 *USE
AUT(*APPLY) parameter on the GRTDPRAUT command:
Table 15. Authorities granted with GRTDPRAUT AUT(*APPLY)
QSYS ASN *LIB 57 *USE
ASN IBMSNAP_SUBS_SET *FILE 7 *CHANGE
ASN IBMSNAP_APPLYTRAIL *FILE 7 *CHANGE
ASN IBMSNAP_SUBS_COLS *FILE 7 *USE
ASN IBMSNAP_SUBS_EVENT *FILE 7 *USE
ASN IBMSNAP_SUBS_STMTS *FILE 7 *USE
ASN IBMSNAP_SUBS_MEMBR *FILE 7 *USE
ASN ASNA* *SQLPKG 7 *USE
ASN ASNU* *SQLPKG 7 *USE
ASN IBMSNAP_UOW *FILE 57 *USE, *UPD
ASN IBMSNAP_PRUNCNTL *FILE 7 *USE, *UPD,
*ADD

GRTDPRAUT
Table 15. Authorities granted with GRTDPRAUT AUT(*APPLY) (continued)

ASN IBMSNAP_CRITSEC *FILE 7 *USE, *ADD
ASN IBMSNAP_AUTHTKN *FILE 7 *USE, *ADD
Control library CD table *FILE 57 *USE
QSYS Target library *LIB 7 *USE
Target library Target table *FILE 7 *CHANGE,
*OBJMGT
Revoking authority
The Revoke DPR Authority (RVKDPRAUT) command revokes authority to
the replication control tables so that users can no longer define or modify
replication sources and subscriptions.
7
RVKDPRAUT USER( U user-name ) DPRVSN( 5 )
*PUBLIC
The command returns an error message if any of the following conditions

exist:
v If a specified user does not exist.
v If the user running the command is not authorized to the specified user
profiles.
v If the DB2 DataPropagator for AS/400 control tables do not exist.
v If the user running the command does not have permission to revoke
authorities to the DB2 DataPropagator for AS/400 control tables.
v If the Capture or Apply programs are running.

RVKDPRAUT
Table 16. RVKDPRAUT command parameter definitions for AS/400

USER Specifies the users whose authority is revoked.
user-name
Specifies the names of up to 50 users whose authority is
revoked.
*PUBLIC
Specifies that authority is revoked from all users without
specific authority, who are not on the authorization list, and
whose group profile does not have any authority.
DPRVSN Specifies the version of DB2 DataPropagator for AS/400.

7 (default)
Revoke authorities for Version 7 of DB2 DataPropagator for
AS/400.
5 Revoke authorities for Version 5 of DB2 DataPropagator for
AS/400.
Example
To revoke authorities to the control tables:
RVKDPRAUT USER(user-name) DPRVSN(7)
Restrictions for running the Capture program

If you perform any of the following actions while a Capture journal job is
running, it terminates with message ASN2301 or ASN2201 in the job log:
v Delete the subscription row from the register table.
v Prevent the Capture program from gaining normal access by locking any of
the control tables, user space, or user indexes needed for data capturing.
v Delete the user space ASN/QZSNCTLBLK.
v Delete the user index QDPR/QZSNINDEX5.
v Drop the index QDPR/IBMSNAP_UOW_IDX.
v Delete the message queue QDPR/QZSN5.
v Remove a message from the message queue QDPR/QZSN5 or send an
extraneous message to the message queue QDPR/QZSN5.
v Attempt to add new rows to the CD tables or the UOW table when the
user’s storage limit is exceeded.
v Unsuccessfully attempt to allocate memory.
To keep the Capture program running, use the following guidelines:

RVKDPRAUT
v Use the default system-wide delete-journal-receiver support to prevent

deletions of required journal receivers. See “Using the delete journal
receiver exit routine” on page 194 for more information.
v If you choose to manage journal receivers manually, delete journal receivers
used for journaling source tables only if you are certain that all the entries
on that receiver were processed by the Capture program.
When conditions make capturing data for a particular source table impossible,
the Capture program changes the state of the source table from capturing
changes to needing a full refresh. (See Table 20 on page 205 for a list of such
conditions.) Other conditions that prevent data capturing for a source table
are:
v An ALTER TABLE is performed on the source table or the CD table such
that either:
– A column in the CD table is no longer in the source table.
– The column in the CD table has different attributes (data type, length)
from its counterpart in the source table.
When you need to perform an ALTER TABLE on the source table, ensure
that you remove the subscription and define the source table again. Or you
can use the List or Change replication sources action in DJRA to fix the
changed data table. If you defined targets, you can also use the List
members or add a column to target table action in DJRA to alter the target
tables.
v A lock is placed on the source table or the CD table that prevents the
Capture program from accessing the needed information.
The journal
DB2 DataPropagator for AS/400 uses the information that it receives from the
journals about changes to the data to populate the CD and UOW tables for
replication.
DB2 DataPropagator for AS/400 runs under commitment control for most
operations and therefore requires journaling on the control tables. (The
QSQJRN journal is created when the CRTDPRTBL command creates a
collection.)
Administrators must manually create the QSQJRN journal in both the library
that contains the replication source control tables and the library that contains
the target tables. Administrators must also ensure that all the source tables are
journaled correctly.

RVKDPRAUT
Remote journal function

In previous versions of DB2 DataPropagator for AS/400, replication source
definitions (including the control tables associated with a source) and the
Capture program always resided on the same system. The remote journal
function makes it possible to move the replication source definitions and the
Capture program and its control tables away from the system on which the
source tables reside, leaving more resources available on that system. With the
remote journal function, processor usage can be reduced, DASD can be saved,
and performance can be improved significantly.
Important: The intention of this type of setup is to have the replication source
definitions on the same AS/400 system as the replication target.
A replication source definition that refers to a remote source table cannot be

subscribed to by other platforms such as the Apply program for OS/390 or
the Apply program for UNIX.
To define a replication source with remote journals, select Define One Table
as a Replication Source from the DJRA main window, select an AS/400
source table, then select the AS/400 policies tab. From this tab, select the
remote journal checkbox, and enter the remote journal library, remote journal
name, and Capture server.
For more information about the remote journal function, see AS/400 Remote
Journal Function for High Availability and Data Replication, SG24-5189.
Creating journals for source tables
To set up the source table journals, you must have the authority to create
journals and journal receivers for the source tables to be defined.
Important: Use a different journal for the source tables than one of those
created by DB2 DataPropagator for AS/400 (QSQJRN journals) in the ASN
library, the source library, the control library, or the target library.
To create a source table journal:

1. Create a journal receiver in a library of your choice using the Create
Journal Receiver (CRTJRNRCV) command. The following example uses a
library named JRNLIB for journal receivers.
CRTJRNRCV JRNRCV(JRNLIB/RCV0001)
THRESHOLD(50000)
TEXT('DataPropagator Journal Receiver')
Be sure to:
v Place the journal receiver in a library that is saved regularly.

RVKDPRAUT
v Choose a journal receiver name that can be used to create a naming

convention for future journal receivers, such as RCV0001. You can use
the *GEN option to continue the naming convention when you change
journal receivers. This type of naming convention is also useful if you
choose to let the system manage the changing of your journal receivers.
2. Create the journal by using the Create Journal (CRTJRN) command:
CRTJRN JRN(JRNLIB/DJRN1)
JRNRCV(JRNLIB/RCV0001)
MNGRCV(*SYSTEM) DLTRCV(*YES)
TEXT('DataPropagator Journal')
Be sure to:
v Specify the name of the journal receiver that you created in the first
step.
v Use the Manage receiver (MNGRCV) parameter to have the system
change the journal receiver and attach a new one when the attached
receiver becomes too large. If you choose this option, you do not need
to use the CRTJRN command to detach receivers and create and attach
new receivers manually.
v Specify DLTRCV(*NO) only if you have overriding reasons to do so (for
example, if you need to save these journal receivers for recovery
reasons). If you specify DLTRCV(*YES), these receivers might be deleted
before you have a chance to save them.
You can use two values on the RCVSIZOPT parameter of the CRTJRN
command (*RMVINTENT and *MINFIXLEN) to optimize your storage
availability and system performance. See the AS/400 Programming:
Performance Tools Guide for more information.
3. Start journaling the source table using the Start Journal Physical File
(STRJRNPF) command, as in the following example:
STRJRNPF FILE(library/file)
JRN(JRNLIB/DJRN1)
OMTJRNE(*OPNCLO)
IMAGES(*BOTH)
Specify the name of the journal that you created in step 2. The Capture
program requires a value of *BOTH for the IMAGES parameter.
Managing journals and journal receivers
The Capture program uses the Receive Journal Entry (RCVJRNE) command
to receive journals.
Specifying system management of journal receivers

It is recommended that you let the AS/400 system manage the changing of
journal receivers. This is called system change journal management. Specify
MNGRCV(*SYSTEM) when you create the journal, or change the journal to

RVKDPRAUT
that value. If you use system change journal management support, you must
create a journal receiver that specifies the threshold at which you want the
system to change journal receivers. The threshold must be at least 5000 KB,
and should be based on the number of transactions on your system. The
system automatically detaches the receiver when it reaches the threshold size
and creates and attaches a new journal receiver, if it can.
Specifying user management of journal receivers

If you specify MNGRCV(*USER) when you create the journal (meaning you
want to manage changing your own journal receivers), a message is sent to
the journal’s message queue when the journal receiver reaches a storage
threshold, if one was specified for the receiver.
Use the CHGJRN command to detach the old journal receiver and attach a
new one. This command prevents Entry not journaled error conditions and
limits the amount of storage space that the journal uses. To avoid affecting
performance, do this at a time when the system is not at maximum use.
You can switch journal receiver management back to the system by specifying
CHGJRN MNGRCV(*SYSTEM).
You should regularly detach the current journal receiver and attach a new one
for two reasons:
v Analyzing journal entries is easier if each journal receiver contains the
entries for a specific, manageable time period.
v Large journal receivers can affect system performance and take up valuable
space on auxiliary storage.
The default message queue for a journal is QSYSOPR. If you have a large
volume of messages in the QSYSOPR message queue, you might want to
associate a different message queue, such as DPRUSRMSG, with the journal.
You can use a message handling program to monitor the DPRUSRMSG
message queue. For an explanation of messages that can be sent to the journal
message queue, see OS/400 Backup and Recovery.
Using the delete journal receiver exit routine

When you install DB2 DataPropagator for AS/400 on a V4R2 (or later) system,
a delete journal receiver exit routine (DLTJRNRCV) is registered automatically.
This exit routine is called any time a journal receiver is deleted, whether or
not it is used for journaling the source tables. This exit routine determines
whether or not a journal receiver can be deleted. (You no longer need to do
this manually. Nor do you need to use the ANZDPRJRN command to delete
old receivers.)

RVKDPRAUT
To take advantage of the delete journal receiver exit routine and leave journal
management to the system, specify DLTRCV(*YES) and MNGRCV(*SYSTEM)
on the CHGJRN or CRTJRN command.
If the journal that the receiver is associated with has no association with any
of the source tables, this exit routine approves the deletion of the receiver.
If the journal receiver is used by one or more source tables, this exit routine
makes sure that the receiver being deleted does not contain entries that have
not been processed by the Capture program. The exit routine disapproves the
deletion of the receiver if the Capture program still needs to process entries
on that receiver.
If you must delete a journal receiver and the delete journal receiver exit
routine does not approve the deletion, specify DLTJRNRCV DLTOPT(*IGNEXITPGM)
to override the exit routine.
Removing the delete journal receiver exit routine: If you want to handle the
deletion of journal receivers manually, you can remove the delete journal
receiver exit routine by issuing the following command:
RMVEXITPGM EXITPNT (QIBM_QJO_DLT_JRNRCV)
FORMAT(DRVC0100)
PGMNBR(value)
To determine the PGMNBR value for the RMVEXITPGM command:

1. Issue the WRKREGINF command.
2. On the Work with Registration Information window, find the entry for exit
point QIBM_QJO_DLT_JRNRCV. Enter 8 in the Opt field.
3. On the Work with Exit Programs window, find the entry for Exit Program
QZSNDREP in library QDPR. The number that you need is under the Exit
Program Number heading.
Registering the delete journal receiver exit routine for upgraded systems: If
the 5769DP3 version of DB2 DataPropagator for AS/400 was installed on
V4R1 and the operating system was upgraded to V4R2 or V4R3 without
reinstalling the product, you must register the exit routine with this
command:
ADDEXITPGM EXITPNT(QIBM_QJO_DLT_JRNRCV)
FORMAT(DRCV0100)
PGMNBR(value *LOW)
CRTEXITPNT(*NO)
PGM(QDPR/QZSNDREP)

RVKDPRAUT
Defining replication sources and subscription sets

Before you define source tables as replication sources with DB2
DataPropagator for AS/400, you must be authorized to the control tables.
There are no commands in DB2 DataPropagator for AS/400 for defining

replication sources and subscription sets. Use the DB2 DataJoiner Replication
Administration tool (DJRA) to define replication sources and subscription sets.
Before you define a table as a replication source, the source table must be
journaled for both before-images and after-images, and the library where the
CD table is created must have a QSQJRN journal.
In DB2 DataPropagator for AS/400, the tables you define as replication

sources can contain approximately 2000 columns; the exact number of
columns depends on the length of the name of each column. This limitation
exists because character strings supplied by the Apply program for AS/400
cannot exceed 32K.
When you define tables as replication sources, the CCSID attributes of CHAR,
VARCHAR, GRAPHIC, and VARGRAPHIC columns in the CD table must be
the same as the CCSID column attributes of the source table.
Using a relative record number (RRN) as a primary key

In DB2 DataPropagator for AS/400, many source tables do not have a column
that can be identified as a primary key column. DB2 DataPropagator requires
primary key columns for the Apply program to track which updates are
applied to which target table rows. To meet this requirement, DB2
DataPropagator for AS/400 supports the use of relative record numbers (RRNs)
of source table rows as primary key columns. Both the CD table and the
target table have an extra column, IBMQSQ_RRN, of type INTEGER. This
column has the RRN of the source table row.
Because the RRN of a source table row does not change unless the source
table is reorganized, the RRN value can be used as a primary key for the
source table row if a source table is not reorganized. Any time that you
reorganize a source table (to compress deleted rows, for example), DB2
DataPropagator for AS/400 performs a full refresh of all the target tables.
Important: Only the Apply program for AS/400 can be used to maintain
copies that contain RRN columns, whether these copies are on an AS/400 or
other target DB2 platforms.

RVKDPRAUT
To define a replication source with a RRN column, select Define One Table as
a Replication Source from the DJRA main window, select an AS/400 source
table, then select the AS/400 policies tab. From this tab, select the RRN
checkbox.
Operating Capture for AS/400

The replication administrator user ID and users who have *CAPTURE
authority can use the commands in this section to perform the following
Capture for AS/400 tasks:
v Starting
v Checking program progress
v Scheduling
v Stopping
v Initializing
v Pruning
This section also describes how the Capture program handles warm and cold
starts, in “Warm and cold starts” on page 205.
Starting Capture for AS/400
Use the Start DPR Capture (STRDPRCAP) command to start capturing
changes to AS/400 database tables. Because this command processes all
replication sources in the register table, make sure that the user running this
command has the proper authority.
After you start the Capture program, it runs continuously until you stop it or
it detects an unrecoverable error.
STRDPRCAP
*YES
RESTART( *NO )

*LIBL/QZSNDPR 7
JOBD( library-name/job-description-name ) DPRVSN( 5 )

120 *DPRVSN *IMMED
WAIT( value ) CLNUPITV( *GLOBAL *DELAYED )
hours-to-wait *NO

STRDPRCAP

*ALL
JRN( U library-name/journal-name )

*ALLCHG
GENCDROW( *REGCOLCHG )
Table 17. STRDPRCAP command parameter definitions for AS/400

RESTART Specifies how the Capture program handles warm and cold starts.
*YES (default)
The Capture program continues processing the changes from
the point where it was when it ended previously. This is also
known as a warm start and is the normal mode of operation.
*NO
The Capture program removes all information from the CD
tables. The Capture program also removes all information
from the UOW table when you specify JRN(*ALL).
All subscriptions for affected source tables are full refreshed
before change capturing resumes. This process is also known
as a cold start.
At times you might want to cold start a subset of sources. By
specifying RESTART(*NO) and JRN(library-name/journal-name),
you can cold start the Capture program for specified journals.
When you cold start a subset of sources, the information in
the UOW table is not removed. When you use the
STRDPRCAP command to cold start a subset of sources, you
can end the Capture program after about 15 minutes and
warm start it again (this time, starting all the replication
sources).
JOBD Specifies the name of the job description to use when submitting
the Capture program.
*LIBL/QZSNDPR (default)
Specifies the default job description provided with DB2
DataPropagator for AS/400.
library-name/job-description-name
Represents the name of the job description used for the
Capture program.

STRDPRCAP
Table 17. STRDPRCAP command parameter definitions for AS/400 (continued)

DPRVSN Specifies the version of the Capture program to start.
7 (default)
Start Version 7 of the Capture program.
5 Start Version 5 of the Capture program.
WAIT Specifies the maximum number of seconds to wait before the

Capture program checks its status. You can use this value to tune
the responsiveness of the Capture program. A low value reduces
the time that the Capture program takes before ending or
initializing, but can have a negative effect on system performance.
A higher value increases the time that the Capture program takes
before ending or initializing, but can improve system performance.
A value that is too high can result in decreased responsiveness
while the Capture program is performing periodic processing. The
amount of the decrease in responsiveness depends on the amount
of change activity to source tables and the amount of other work
occurring on the system.
120 (default)
The Capture program waits 120 seconds.
value
The maximum number of seconds that the Capture program
waits. You can specify from 60 to 6000 seconds.

STRDPRCAP

CLNUPITV Specifies the maximum amount of time before the Capture
program prunes old records from the CD tables and the UOW
table, if it exists. This parameter works in conjunction with the
RETAIN parameter on the CHGDPRCAPA command.
*DPRVSN (default)
Specifies the interval. The value is *GLOBAL.
*GLOBAL
Specifies the interval as the same value as that of the
PRUNE_INTERVAL column of the tuning parameters table.
You can change this value by using the CLNUPITV parameter
on the CHGDPRCAPA command.
hours-to-wait
Specifies the interval as a specific number of hours.
*IMMED (default)
Specifies to prune old records at the beginning of the specified
interval (or immediately), and at each interval thereafter.
*DELAYED
Specifies that the Capture program prune old records at the
end of the specified interval, and at each interval thereafter.
*NO
Specifies that the Capture program does not prune records.
JRN Specifies a subset of up to 50 journals that you want the Capture

program to work with. The Capture program will start processing
all the source tables that are currently journaled to this journal.
*ALL
Specifies that the Capture program will start working with all
of the journals that have any source tables journaled to them.
library-name/journal-name
Represents the qualified name of the journal that you want
the Capture program to work with.

STRDPRCAP

GENCDROW Specifies what changes from the journals should be copied into the
change data table.
*ALLCHG
All of the insert, update, and delete records from the journal
are copied into the change data table.
*REGCOLCHG
The insert, update, and delete changes made to the registered
columns are journaled, and the changes are then copied into
the change data table. Changes that are made to columns that
are not defined for replication will not be captured in the
change data tables.
You can run the STRDPRCAP command manually, or you can automatically
run the command as a part of the initial program load (IPL startup program).
For information about including the STRDPRCAP command in a startup
program, see OS/400 Work Management V4R3, SC41–5306.
If the job description specified with the JOBD parameter uses job queue
QDPR/QZSNDPR, and the DB2 DataPropagator for AS/400 subsystem is not
active, the STRDPRCAP command starts the subsystem. If the job description
is defined to use a different job queue and subsystem, you must start this
subsystem manually with the Start Subsystem (STRSBS) command either
before or after running the STRDPRCAP command:
STRSBS QDPR/QZSNDPR
You can set up the system to start the subsystem automatically by adding the
STRSBS command to the program that is referred to in the QSTRUPPGM
system value on your system.
Determining the progress of the Capture program
To determine the progress of the Capture program, you must either determine
how much work remains between the last Capture process that was
performed and the last Apply process, or use the DJRA Replication Monitor.
If the Capture program has ended, you can determine its progress by
inspecting the warm start table. There is one row for each journal used by the
source tables. The LOGMARKER column provides the timestamp of the last
journal entry processed successfully. The SEQNBR column provides the
journal entry sequence number of that entry.
If the Capture program is still running, you can determine its progress by
completing the following tasks:

STRDPRCAP
1. For each source table being captured, find its CD table.

2. In the last row of the CD table, note the hex value in the
IBMSNAP_UOWID column.
3. Look in the UOW table for a row with the same IBMSNAP_UOWID value.
If no matching IBMSNAP_UOWID exists in the UOW table, repeat the
same process with the second-to-last row in the CD table. Proceed
backward through the CD table until you find a match.
4. When you find a matching IBMSNAP_UOWID, note the value in the
IBMSNAP_LOGMARKER column of the UOW row. This is the timestamp
of the processed journal entry. All changes to the source table up to that
time are ready to be applied.
5. Use the Display Journal (DSPJRN) command to determine how many
journal entries remain to be processed by the Capture program. Direct the
output to an output file (or to a printer for a printed report), as shown in
the following example:
DSPJRN FILE(JRNLIB/DJRN1)
RCVRNG(*CURCHAIN)
FROMTIME(timestamp)
TOTIME(*LAST)
JRNCDE(J F R C)
OUTPUT(*OUTFILE)
ENTDTALEN(1) OUTFILE(library/outfile)
In the example, timestamp is the timestamp that you identified in step 4.
The number of records in the output file is the approximate number of

journal entries that remain to be processed by the Capture program.
Scheduling Capture for AS/400
Use the SBMJOB command to schedule the start of the Capture program on
AS/400:
SBMJOB CMD('STRDPRCAP...') SCDDATE(...) SCDTIME(...)
Stopping Capture for AS/400
Use the End DPR Capture (ENDDPRCAP) command to end the Capture
program.
Use this command to end the Capture program before shutting down the
system. You might also want to end the program during periods of peak
system use to increase the performance of other programs that run on the
system.
ENDDPRCAP
*CNTRLD 7
OPTION( *IMMED ) DPRVSN( 5 )

ENDDPRCAP
Table 18. ENDDPRCAP command parameter definitions for AS/400

OPTION Specifies how to end the Capture program.
*CNTRLD (default)
Specifies that the Capture program complete all tasks and then
end normally.
The ENDDPRCAP command might take longer when you
specify the *CNTRLD option because the Capture program
completes all of its subordinate processes before ending.
*IMMED
Specifies that the Capture program complete all tasks with the
ENDJOB OPTION(*IMMED) command and end normally.
DPRVSN Specifies the version of the Capture program to end.

7 (default)
Specifies Version 7 of the Capture program.
5 Specifies Version 5 of the Capture program.
If you use the ENDJOB command, temporary objects might be left in the
QDPR library. These objects have the types *DTAQ and *USRSPC, and are
named QDPRnnnnnn, where nnnnnn is the job number of the job that used
them. You can delete these objects when the job that used them (identified by
the job number in the object name) is not active.
If the job QDPRCTL5 does not end long after issuing this command, use the
ENDJOB command with *IMMED option to end this job and all the journal
jobs running in the DB2 DataPropagator for AS/400 subsystem. Do not end
Apply jobs running in the same subsystem if you want to end only the
Capture program.
In rare cases when the job QDPRCTL5 ends abnormally, the journal jobs
created by QDPRCTL5 might still be left running. The only way to end these
jobs is to use the ENDJOB command with either the *IMMED or *CNTRLD
option.
Reinitializing Capture for AS/400
The Initialize DPR Capture (INZDPRCAP) command initializes the Capture
program by directing the Capture program to work with an updated list of
source tables.
Source tables under the control of the program can change while the Capture
program is running. Use the INZDPRCAP command to ensure that the
Capture program processes the most up-to-date replication sources.

INZDPRCAP
If you change the values of the tuning parameters while the Capture program
is running, enter the INZDPRCAP command to reinitialize the program using
the new values.
The Capture program must be running before you run this command.
INZDPRCAP
7
DPRVSN( 5 )

*ALL
JRN( U library-name/journal-name )
Table 19. INZDPRCAP command parameter definitions for AS/400

DPRVSN Specifies the version of the Capture program to initialize.
7 (default)
Specifies Version 7 of the Capture program.
5 Specifies Version 5 of the Capture program.
JRN Specifies a subset of up to 50 journals that you want the Capture

program to work with. The Capture program will start processing
all the source tables that are currently journaled to this journal.
*ALL (default)
Specifies that the Capture program works with all the journals.
library-name/journal-name
Specifies the qualified name of the journal that you want the
Capture program to work with.
Pruning the change data and unit-of-work tables and minimizing source
server DASD usage
The CLNUPITV parameter on the STRDPRCAP command specifies the
maximum number of hours that the Capture program waits before pruning
old records from the CD tables and the UOW table. For more information
about the CLNUPITV parameter, see “Starting Capture for AS/400” on
page 197.
Pruning does not recover DASD for you. You have to frequently issue
RGZPFM (Reorganize Physical File Member) commands against the CD tables

INZDPRCAP
and the UOW tables to recover the DASD. The RGZPFM command reclaims
deleted space by moving active rows forward. It requires an EXCLRD lock of
the file and member, and you must schedule it when Capture and Apply are
not running.
Important: Issue RGZPFM commands once a week.

Warm and cold starts
The value of the RESTART parameter on the STRDPRCAP command controls
how the Capture program handles warm and cold starts.
Warm start process

Warm start information is saved in most cases. Occasionally, warm start
information is not saved. In this case, the Capture program uses the CD
tables, UOW table, or the pruning control table to resynchronize to the time
that it was stopped.
Automatic cold starts

Sometimes the Capture program automatically switches to a cold start, even if
you specified a warm start. On AS/400 systems, cold starts work on a
journal-by-journal basis. So, for example, if a journal exceeds the lag limit, all
replication sources using that journal are cold-started, whereas replication
sources using a different journal are not cold started.
For more information about how the Capture program processes different
journal entry types, see Table 20.
How the Capture program processes journal entry types

The following table describes how the Capture program processes different
journal entry types.
Table 20. Capture program processing by journal entry
Journal
code3 Entry type Description Processing
C CM Set of record changes Insert a record in the UOW
committed table.
C RB Rollback No UOW row inserted.
F AY Journaled changes applied to Issue an ASN2004 message
physical file member and full refresh of file.
F CE Change end of data for Issue an ASN2004 message
physical file and full refresh of file.
F CR Physical file member cleared Issue an ASN2004 message
and full refresh of file.

INZDPRCAP
Table 20. Capture program processing by journal entry (continued)

Journal
F EJ Journaling for physical file Issue an ASN2004 message
member ended and full refresh of file.
F IZ Physical file member Issue an ASN2004 message
initialized and full refresh of file.
F MD Member removed from Issue an ASN2004 message
physical file (DLTLIB, DLTF, and attempt a full refresh.
or RMVM)
F MF Storage for physical file Issue an ASN2004 message
member freed and full refresh of file.
F MM Physical file containing Issue an ASN200A message
member moved (Rename and attempt a full refresh.
Object (RNMOBJ) of library,
Move Object (MOVOBJ) of
file)
F MN Physical file containing Issue an ASN200A message
member renamed (RNMOBJ and attempt a full refresh.
of file, Rename Member
(RNMM))
F MR Physical file member restored Issue an ASN2004 message
and full refresh of file.
F RC Journaled changes removed Issue an ASN2004 message
from physical file member and full refresh of file.
F RG Physical file member If the RRN of the source table
reorganized is being used as the
replication key, issue an
ASN2004 message and full
refresh of file.
J NR Identifier for next journal Reset the Capture program.
receivers
J PR Identifier for previous journal Increment the unique
receivers sequence number counter.
R DL Record deleted from physical Insert a DLT record in the CD
file member table.
R DR Record deleted for rollback Insert a DLT record in the CD
table.
R PT Record added to physical file Insert an ADD record in the
member CD table.
R PX Record added directly to Insert an ADD record in the
physical file member CD table.

INZDPRCAP
Table 20. Capture program processing by journal entry (continued)

Journal
R UB Before-image of record See note 1.
updated in physical file
member
R UP After-image of record updated See note 1.
in physical file member
R BR Before-image of record See note 2.
updated for rollback
R UR After-image of record updated See note 2.
for rollback
Notes:
1. The R-UP image and the R-UB image form a single UPD record in the CD table if
the PARTITION_KEYS_CHG column in the register table is N. Otherwise, the R-UB
image inserts a DLT record in the CD table and the R-UP image inserts an ADD
record in the CD table.
2. The R-UR image and the R-BR image form a single UPD record in the CD table if
the PARTITION_KEYS_CHG column in the register table is N. Otherwise, the R-BR
image inserts a DLT record in the CD table and the R-UR image inserts an ADD
record in the CD table.
3. The following values are used for the journal codes:
C Commitment control operation
F Database file operation
J Journal or journal receiver operation
R Operation on specific record
All other journal entry types are ignored by the Capture program.
Operating Apply for AS/400

A replication administrator user ID and users who have *APPLY authority can
use the commands in this section to perform the following Apply for AS/400
tasks:
v Creating packages to use with remote systems
v Starting
v Scheduling
v Stopping
This section also describes two additional Apply program operations:

INZDPRCAP
v “Using the ASNDONE exit routine for AS/400” on page 220

v “Refreshing target tables with the ASNLOAD exit routine for AS/400” on
page 221
Creating packages to use with remote systems
SQL and DPR packages can be created to use with remote systems. You can
create these packages by issuing the following commands:
CRTSQLPKG
The Create SQL Package (CRTSQLPKG) command creates the
packages that enable you to use Apply for AS/400 with remote
systems on platforms other than AS/400. For information about using
this command, see DB2 for AS/400 SQL Programming V4R3 or later.
CRTDPRPKG
You can use the Create DPR Packages (CRTDPRPKG) command to
create the packages necessary to use DB2 DataPropagator for AS/400
with remote systems. The following paragraphs contain more
information about using this command.
CRTDPRPKG
7 *ALL
DPRVSN 5 ) TYPE *APPLY )
*ADMIN

*ALL
RDB rdb-name )
Table 21. CRTDPRPKG command parameter definitions for AS/400

DPRVSN Specifies the version of the DB2 DataPropagator for AS/400 package
to use.
7 (default)
Specifies packages for Version 7 of DB2 DataPropagator for
AS/400.
5 Specifies packages for Version 5 of DB2 DataPropagator for
AS/400.

CRTDPRPKG
Table 21. CRTDPRPKG command parameter definitions for AS/400 (continued)

TYPE Specifies which DB2 DataPropagator for AS/400 packages are
created.
*ALL (default)
Specifies to create packages for all the DB2 DataPropagator for
AS/400 programs that do remote SQL.
*APPLY
Specifies to create the packages for the programs used by the
Apply program.
*ADMIN
Specifies to create the packages for the programs used by the
CL commands.
RDB Specifies the relational database where the packages are created. The
packages are not created in the following cases:
v The RDB is on an AS/400 system and the ASN library does not
exist on the remote system.
v The RDB is not on an AS/400 system and ASN is not defined as
an authorization ID on that RDB.
*ALL (default)
Specifies to create an SQL package on every RDB that is used as
a source server or a target server by DB2 DataPropagator for
AS/400.
rdb-name
Represents the name of the relational database. You can use the
Work with RDB Directory Entries (WRKRDBDIRE) command
to find this name.
When prompting on the CRTDPRPKG command, you can
press the F4 key to choose from the list of databases in the RDB
directory.
The packages are created using the ASN qualifier. They are created in the
ASN library for DB2 UDB for AS/400 platforms. For other platforms, the
authorization ID ASN is used.
After creating the DB2 DataPropagator for AS/400 packages, this command
grants *PUBLIC authority to the packages to allow them to be used by users
of DB2 DataPropagator for AS/400.
The system also produces a spool file that contains the SQL messages
associated with each attempt to create a package.

CRTDPRPKG
Before you start the Apply program

v The control tables have been created. If the tables do not exist, you can use
the CRTDPRTBL command to create them. For information about the
CRTDPRTBL command, see “Creating the replication control tables” on
page 178.
v You have the proper authorization to run the Apply program. See
“Granting authority” on page 181 for more information.
v At least one subscription set has been created and activated.
v All target tables have a primary key index. Differential refresh performance
is significantly affected if the primary key index is removed for a
subscription.
Important: The primary key index is built for you when you define a
subscription set. Do not delete it accidentally.
v The Apply program package has been created.
v The Capture program is started on the source server before you start the
Apply program for the first time. The Capture program updates the
SYNCHTIME and SYNCHPOINT columns of the GLOBAL record in the
register table before the Apply program is started. The Apply program
assumes that if a GLOBAL record is present in the register table, the
SYNCHTIME and SYNCHPOINT columns are not null.
Starting Apply for AS/400
The Start DPR Apply (STRDPRAPY) command starts an instance of the
Apply program on the local system. The Apply program continues running
until you stop it or an unrecoverable error occurs.
STRDPRAPY
*CURRENT
USER( *JOBD )
user-name

*LIBL/QZSNDPR 7
JOBD( library-name/job-description-name ) DPRVSN( 5 )
*LIBL/job-description-name

*USER *LOCAL
APYQUAL( apply-qualifier ) CTLSVR( rdb-name )

STRDPRAPY

*NONE *NONE
TRACE( *ERROR ) FULLREFPGM( library-name/program-name )
*ALL
*PRF

*NONE *YES
SUBNFYPGM( library-name/program-name ) INACTMSG( *NO )

*YES 6
ALWINACT( *NO ) DELAY( delay-time )

300
RTYWAIT( retry-wait-time )
Table 22. STRDPRAPY command parameter definitions for AS/400

USER Specifies the name of the user ID for which the Apply program is
started. When you run this command, you must be authorized
(have *USE rights) to the specified user profile.
The Apply program runs under the specified user profile. The
control tables (in ASN) are located on the relational database
specified with the CTLSVR parameter. The same control tables are
used regardless of the value specified on the USER parameter.
*CURRENT (default)
Specifies that the user ID associated with the current job is the
user ID associated with this instance of the Apply program.
*JOBD
Represents the user ID specified in the job description
associated with this instance of the Apply program. The job
description cannot specify USER(*RQD).
user-name (default)
Specifies the user ID associated with this instance of the Apply
program. The following IBM-supplied objects are not valid on
this parameter: QDBSHR, QDFTOWN, QDOC, QLPAUTO,
QLPINSTALL, QRJE, QSECOFR, QSPL, QSYS, or QTSTRQS.
When prompting on the STRDPRAPY command, you can press
the F4 key to see a list of users who defined subscriptions.

STRDPRAPY
Table 22. STRDPRAPY command parameter definitions for AS/400 (continued)

JOBD Specifies the name of the job description to use when submitting the
Apply program.
*LIBL/QZSNDPR (default)
Specifies the default job description provided with DB2
DataPropagator for AS/400.
library-name/job-description-name
Represents the name of the job description used for the Apply
program.
DPRVSN Specifies the version of the Apply program to start.

7 (default)
Start Version 7 of the Apply program.
5 Start Version 5 of the Apply program.
APYQUAL Specifies that an Apply qualifier be used by an Apply program

instance. All subscriptions that are grouped together with this Apply
qualifier will be run by this Apply program instance.
*USER (default)
Specifies the user name on the USER parameter as the Apply
qualifier.
apply_qualifier
Specifies the name used to group the subscriptions that are to
be run by this Apply program instance. You can specify a
maximum of 18 characters for the Apply qualifier name. This
name follows the same naming conventions as an RDB name.
The subscriptions to be run are identified by the records in the
subscription set table with this value in the APPLY_QUAL
column.
the F4 key to see a list of Apply qualifier names with existing
subscriptions.

STRDPRAPY

CTLSVR Specifies the control server where the common control tables are
located.
*LOCAL (default)
Specifies that the subscription control tables are located on the
local relational database.
rdb-name
Represents the name of the relational database where the
control tables are located. You can use the Work with RDB
Directory Entries (WRKRDBDIRE) command to find this name.
the F4 key to see a list of available RDB names.
TRACE Specifies whether the Apply program should generate a trace. If the
Apply program generates a trace, the trace is output to a spool file
called QPZSNATRC.
*NONE (default)
Specifies that no trace is generated.
*ERROR
Specifies that the trace should contain information for errors
only.
*ALL
Specifies that the trace should contain information for errors,
execution flow, and SQL statements issued by the Apply
program.
*PRF
Specifies that the trace should contain information that can be
used to analyze performance at different stages of the Apply
program execution.

STRDPRAPY

FULLREFPGM Specifies whether the Apply program should invoke an exit routine
to initialize a target table. When the Apply program determines that
a target table needs to be full-refreshed, it invokes the specified exit
routine rather than doing the full refresh itself.
When a full-refresh exit routine is used by the Apply program, the

value of the ASNLOAD column in the Apply trail table is Y.
For examples and more information, see “Refreshing target tables

with the ASNLOAD exit routine for AS/400” on page 221.
*NONE (default)
Specifies that a full-refresh exit routine is not used.
library-name/program-name
Represents the qualified name of the program that is called
when the Apply program determines that it is necessary to do a
full refresh of a target table. For example, to call program
ASNLOAD in library DATAPROP, the qualified name is
DATAPROP/ASNLOAD.
SUBNFYPGM Specifies whether the Apply program is to invoke an exit routine

when it finishes processing a subscription set. Input to the exit
routine consists of the set name, Apply qualifier, completion status,
and statistics including the number of rejects.
The notify program allows you to examine the UOW table to

determine the transactions that have been rejected and then allows
you to take further actions such as issuing a message or generating
an event.
For more information, see “Using the ASNDONE exit routine for
AS/400” on page 220.
*NONE (default)
Specifies that an exit routine is not used.
library-name/program-name
Represents the qualified name of the program to be called when
the Apply program completes processing a subscription set. For
example, to call program APPLYDONE in library DATAPROP,
the qualified name is DATAPROP/APPLYDONE.

STRDPRAPY

INACTMSG Specifies whether the Apply program should generate a message
whenever it completes its work and becomes inactive for a period of
time.
*NO (default)
Specifies that no message is generated.
*YES
Specifies that the Apply program generate message ASN1044
before beginning a period of inactivity. Message ASN1044
indicates how long the Apply program will be inactive.
ALWINACT Specifies whether the Apply program is able to run in an inactive

state (sleep).
*YES (default)
Specifies that the Apply program should sleep if there is
nothing to process.
*NO
Specifies that if the Apply program has nothing to process, the
job started for the Apply program should end.
DELAY Specifies the delay time (in seconds) at the end of each Apply
program cycle when continuous replication is used.
6 Specifies a delay time of 6 seconds.
delay-time
Specifies a delay time between 0 and 6 seconds inclusive.
RTYWAIT Specifies in seconds how long the Apply program should wait after
it encounters an error before it retries the operation that failed.
300
Specifies a retry wait time of 300 seconds.
retry-wait-time
Specifies a retry wait time between 0 and 35000000 seconds
inclusive.
You can set up the system to automatically start the subsystem by adding the
command that is referred to in the QSTRUPPGM value on your system. If you
will use the QDPR/QZSNDPR subsystem, it will be started as part of the
STRDPRAPY command processing.

STRDPRAPY
If the relational database (RDB) specified with the CTLSVR parameter is a

DB2 UDB for AS/400 database, the tables on the server are found in the ASN
library. If the RDB is not a DB2 UDB for AS/400 database, you can access the
tables using ASN as the qualifier.
Error conditions when starting the Apply program

The STRDPRAPY command issues an error message if any of the following
conditions occur:
v If the user does not exist.
v If the user running the command is not authorized to the user profile
specified on the command or the job description.
v If an instance of the Apply program is already active on the local system
for this combination of Apply qualifier and control server.
v If the RDB name specified with the CTLSVR parameter is not in the
relational database directory.
v If the control tables do not exist on the RDB specified with the CTLSVR
parameter.
v If there are no subscriptions defined for the Apply qualifier specified with
the APYQUAL parameter.
An Apply instance must be started for each unique Apply qualifier in every
subscription set table. You can start multiple Apply processes by specifying a
different Apply qualifier each time that you issue the STRDPRAPY
command. These Apply processes will run under the same user profile.
Identifying Apply program jobs

Each Apply process is identified using both the Apply qualifier and the
control server names. When run, the job started for the Apply process does
not have sufficient external attributes to correctly identify which Apply
process is associated with a particular Apply qualifier and control server
combination. Therefore, the job is identified in the following way:
v The job is started under the user profile associated with the USER
parameter.
v The first 10 characters of the Apply qualifier are truncated and become the
job name.
v DB2 DataPropagator for AS/400 maintains an Apply job control table
named IBMSNAP_APPLY_JOB in the ASN library on the local system. The
table maps the Apply qualifier/control server values to the correct Apply
program job.
v You can view the job log. The Apply qualifier and control server names are
used in the call to the Apply program.
In general, you can identify the correct Apply program job by looking at the
list of jobs running in the QZSNDPR subsystem if both:
v The first 10 characters of the Apply qualifier name are unique.

STRDPRAPY
v The Apply program is started for the local control server only.
Scheduling Apply for AS/400
Use the ADDJOBSCDE command to start the Apply program at a specific
time.
Stopping Apply for AS/400
The End DPR Apply (ENDDPRAPY) command ends an instance of the Apply
program on the local system.
You should end the Apply program before any planned system down time.
You might also want to end the Apply program during periods of peak
system activity.
ENDDPRAPY
*CURRENT *CNTRLD
USER( user-name ) OPTION( *IMMED )

7 *USER
DPRVSN( 5 ) APYQUAL( apply-qualifier )

*LOCAL
CTLSVR( rdb-name )
Table 23. ENDDPRAPY command parameter definitions for AS/400

USER This parameter is ignored unless the APYQUAL parameter has a
value of *USER, in which case this is the Apply qualifier associated
with the instance of Apply.
*CURRENT (default)
Specifies the Apply process of the user associated with the
current job.
user-name
Specifies the Apply process of the specified user.
When prompting on the ENDDPRAPY command you can press
the F4 key to see a list of users who defined subscriptions.

ENDDRPAPY
Table 23. ENDDPRAPY command parameter definitions for AS/400 (continued)

OPTION Specifies how to end the Apply process.
*CNTRLD (default)
Specifies that the Apply process complete all of its tasks before
ending. These tasks might take a considerable period of time if
the Apply program is completing a subscription.
*IMMED
Specifies that the Apply program complete all of its tasks with
the ENDJOB OPTION(*IMMED) command. The tasks end
immediately, without any cleanup. Use this option only after a
controlled end is unsuccessful, because it can cause undesirable
results. (Unless the Apply program was asleep when you issued
the ENDDPRAPY command, you should verify the target table
contents.)
If the Apply program was performing a full refresh to the target
table, the target table might be empty as a result of ending the
Apply program before the table was refreshed with the source
table contents. If the target table is empty, you must force a full
refresh for this replication target.
You might find that a subscription is considered IN USE (the
STATUS column in the subscription set table has a value of 1).
If it is, reset the value to 0 or -1. This allows the subscription to
be run again by the Apply program.
DPRVSN Specifies the version of the Apply program to end.

7 (default)
Specifies Version 7 of the Apply program.
5 Specifies Version 5 of the Apply program.

ENDDRPAPY
Table 23. ENDDPRAPY command parameter definitions for AS/400 (continued)

APYQUAL Specifies the Apply qualifier used by an instance of the Apply
program. All subscriptions that are grouped together with this
Apply qualifier are run by the instance.
*USER (default)
Specifies that the user name specified on the USER parameter is
the Apply qualifier.
apply_qualifier
Specifies the name used to group the subscriptions that this
Apply instance runs. You can specify a maximum of 18
characters for the Apply qualifier name. This name follows the
same naming conventions as an RDB name. You identify the
subscriptions being run by the records in the subscription set
table with this value in the APPLY_QUAL column.
When prompting on the ENDDPRAPY command, you can
press the F4 key to see a list of Apply qualifier names with
existing subscriptions.
CTLSVR Specifies the name of the relational database where the Version 7
control tables are located.
*LOCAL (default)
Specifies that the control tables are located on the local
relational database.
rdb-name
Specifies that the subscription control tables are located on this
relational database. You can use the Work with RDB Directory
Entries (WRKRDBDIRE) command to find this name.
When prompting on the ENDDPRAPY command, you can
press the F4 key to choose from the list of databases in the RDB
directory.
The ENDDPRAPY command uses the value of the APYQUAL and CTLSVR
parameters to search the Apply job table for the job name, job number, and
job user for the referenced Apply program, and ends that job.
ENDDPRAPY issues an error message if the following conditions occur:

v If the Apply job table does not exist or is corrupted.
v If there is no record in the Apply job table for the Apply qualifier and
control server name.
v If the Apply job already ended.

ENDDRPAPY
v If the user ID running the command is not authorized to end the Apply job.
Additional Apply program operations

This section provides information about performing two additional Apply
program functions: using the ASNDONE exit routine and refreshing target
tables with the ASNLOAD exit routine.
Using the ASNDONE exit routine for AS/400
The ASNDONE exit routine is a program that the Apply program can
optionally call after subscription processing completes, regardless of success or
failure. A separate subscription notify program can be provided for each
Apply qualifier. For general information about the ASNDONE exit routine, see
“Using the ASNDONE exit routine” on page 132.
This section provides information about customizing the ASNDONE routine

for an AS/400 environment.
When creating your subscription notify program, consider these activation

group concerns:
If the program is created to run with a new activation group: the Apply
program and the subscription notify program will not share SQL resources,
such as RDB connections and open cursors. The activation handling code in
the AS/400 operating system frees any resources allocated by the subscription
notify program before control is returned to the Apply program. Additional
resource is used every time that the Apply program calls the subscription
notify program.
If the program is created to run in the caller’s activation group: it shares SQL
resources with the Apply program. Design the program so that you minimize
its impact on the Apply program. For example, the program might cause
unexpected Apply program processing if it changes the current relational
database (RDB) connection.
If the program is created to run in a named activation group: it does not

share resources with the Apply program. Using a named activation group will
avoid the activation group overhead every time the subscription notify
program is called. Run time data structures and SQL resources can be shared
between invocations. Application cleanup processing is not performed until
the Apply program is ended, so the subscription notify program must be
designed to ensure that it does not cause lock contention with the Apply
program by leaving source tables, target tables, or control tables locked when
control is returned to the Apply program.

When you start the Apply program, specify the name of the subscription
notify program using the parameter SUBNFYPGM on the STRDPRAPY
command. For example, if the program is named ASNDONE_1 and resides in
library APPLIB, use the command:
SUBNFYPGM(APPLIB/ASNDONE_1).
Refreshing target tables with the ASNLOAD exit routine for AS/400
The ASNLOAD full-refresh exit routine is called by the Apply program:
v When it determines that a full refresh of a target table is necessary.
v If you specify the name of a full refresh program on the FULLREFPGM
parameter when you start the Apply program.
When a full refresh of a subscription set is necessary, the Apply program calls
the exit routine. The program then performs a full refresh of the target table
(if necessary), or of each target table listed in the subscription set.
You can use an exit routine instead of the Apply program to perform a full
refresh more efficiently. For example, if you are copying every row and every
column from a source table to a target table, you can design a full-refresh exit
routine that uses a Distributed Data Management (DDM) file and the Copy
File (CPYF) CL command to copy the entire file from the source table to the
target table.
If the exit routine returns a non-zero return code, the current subscription set
being processed by the Apply program fails. Processing of the remainder of
the subscription set is discontinued until the next iteration.
Guidelines for using ASNLOAD

The source for sample exit routines is included with DB2 DataPropagator for
AS/400. The samples for the C, COBOL, and RPG languages are:
Compiler language Library name Source file name Member name

C QDPR QCSRC ASNLOAD
COBOL QDPR QCBLLESRC ASNLOAD
RPG QDPR QRPGLESRC ASNLOAD
You cannot direct the Apply program to use another program unless you end
the Apply program and start it again with another STRDPRAPY command.
If you plan to use ASNLOAD, be aware of the following items:

v To avoid interference with the Apply program, compile the exit routine so
that it uses a new activation group (not the caller’s activation group).
v The exit routine should perform a COMMIT operation.

v The system calls the exit routine to perform a full refresh of each target
table associated with the subscription set. You can either:
– Design the program to distinguish between the different target tables
and subscription sets.
– Associate a single subscription set with a single member to one Apply
qualifier.
v You can compile the exit routine with a named activation group or with a
new activation group. To get better performance, use a named activation
group. With a named activation group, the exit routine must commit or roll
back changes as needed. The Apply program will not cause changes to be
committed or rolled back (unless it ends).
The exit routine should either explicitly commit changes, or it should be
compiled to implicitly commit changes when it completes. Any
uncommitted changes when the exit routine completes are not committed
until either:
– The Apply program calls another exit routine with the same activation
group.
– The job started for the Apply program ends.
Required parameters for ASNLOAD

Return code
Specifies whether the exit routine was successful, indicated by a return
code of 0. If the return code is not 0, the Apply program produces an
error. If trace is on, the Apply program produces trace output.
Reason code
Specifies a value that can be used to further describe the exit routine
failure. If the return code is not 0 and if trace is on, the Apply program
includes the reason code information as part of the trace output. The
values for the reason code should be specific to your user application.
Control server RDB name
Specifies the RDB name of the database where the subscription set tables
are located. The name is padded with blanks.
Target server relational database (RDB) name
Specifies the name of the database where the target table is located. The
name is padded with blanks.
Target table library
Specifies the name of the library that contains the target table. If the target
server RDB name is not an AS/400 database, this parameter is the
authorization ID of the target table, which is obtained from the
TARGET_OWNER column of the row of the subscription member table
that is currently processed by the Apply program. The name is padded
with blanks.

Target table name
Specifies the name of the target table, which is obtained from the
TARGET_TABLE column of the row in the subscription-targets-member
table that is currently processed by the Apply program. If the target server
is a database for AS/400, the name can be either an SQL table name or an
AS/400 system file name. The name is padded with blanks.
Apply qualifier
Specifies the qualifier used to start this instance of the Apply program.
This value is obtained from the APPLY_QUAL column of the row in the
subscription set table that is currently processed by the Apply program.
The name is padded with blanks.
Subscription set name
Specifies the name of the subscription set that the Apply program has just
completed. This value is obtained from the SET_NAME column of the
row in the subscription set table that is currently processed by the Apply
program. The name is padded with blanks.
Source server RDB name
Specifies the RDB name of the database where the source table is located.
The name is padded with blanks.
SQL SELECT statement
Specifies a variable-length SQL statement that you can use to select the
source table rows and columns to be copied to the target table. The
following table shows the structure of the SQL SELECT statement.
Offset (Hex or Decimal) Type Field

0 BINARY(4) SQL statement length
4 Char(*) SQL select statement
Trace indicator
Specifies whether the Apply program generates trace data. The exit
routine can use the trace indicator to coordinate its internal trace with the
Apply trace.
When the Apply program generates a trace, it prints to a spool file. If the
exit routine is running in a separate activation group, the results print to a
separate spool file. If the exit routine runs in the caller’s activation group,
the results print to the same spool file as the Apply trace.
The values for trace indicator are:
YES
Trace data is being produced.
NO
No trace data is being produced.

Other
No trace data is being produced.

Chapter 10. Capture and Apply for OS/390
programs for OS/390. It also contains information specific to replicating DB2
for OS/390 data:
v “Rules for index types” on page 234
v “Using the DB2 ODBC Catalog” on page 235

Setting up consists of applying DB2 maintenance; installing the Capture and
Apply programs and configuring the source, target, and control servers; and
configuring Capture and Apply after you install a new release of DB2.
Applying DB2 maintenance
Make sure to apply the correct DB2 maintenance before installing the Capture
and Apply for OS/390 programs. To apply the correct DB2 maintenance:
1. Install the maintenance listed in the Service Level Information section of
the DB2 UDB for OS/390 V7 Program Directory and review the Preventive
Service Planning (PSP) buckets before installing Capture or Apply.
2. Install the maintenance listed in the PSP buckets for Capture and for
Apply. Refer to the Preventive Service Planning section of the Program
Directory.
Installing Capture and Apply for OS/390
Capture for OS/390 and Apply for OS/390 are packaged in SMP/E format.
The installation sequence for each program consists of:
1. Customizing invocation JCL to suit your environment
2. Using SMP/E to install
3. Providing APF authorization
4. Creating and loading the VSAM messages file
5. Binding to the DB2 subsystem and target or control subsystems that the
DB2 subsystem will connect to
See the DB2 Universal Database for OS/390 Version 7 Program Directory for
complete installation instructions for the Capture and Apply programs.

Configuring Capture and Apply for OS/390 after installing a new release of
DB2
Capture and Apply load modules for OS/390 are automatically link-edited by
SMP/E using the DB2 DSN###.SDSNLOAD library specified for your DB2
release. The sample jobs ASNLDEF (Capture) and ASNADEF (Apply) are used
during install to define data sets to your SMP/E system. There is one load
module per program for each release of DB2, with the suffix representing the
DB2 release:
DB2 release Capture load module Apply load module

Version 5.1 ASNLRP75 ASNAPV75
To set up your SMP/E DDDEF entries during installation (in 2 on page 225),
refer to the Capture sample library SASNLBSE(ASNLDEF) and the Apply
sample library SASNABSE(ASNADEF).
When you installed the Capture or Apply program, each DDDEF entry was
set up to point to a corresponding DB2 DSN###.SDSNLOAD library, where
### referred to the product release (710 for Version 7.1, 610 for Version 6.1,
and 510 for Version 5.1). If any of the related releases of DB2 were not
installed, then the DDDEF entries were set up with the DB2 SDSNLOAD
library for ″DDDEF(SDSNLD##)″ to point to the highest installed level of DB2.
For example, if DB2 5.1 was not installed, then DDDEF entries were set up
with DDDEF(SDSNLD51) to point to the DSN710.SDSNLOAD library so that
SMP/E link-edit will complete with return code 4. Also, the Capture load
module ASNLRP75 in run job ASNL2RN5 or the Apply load module
ASNAPV75 in run job ASNA2RN5 cannot be executed.
If you install a new release of DB2 after installing the Capture or Apply
program:
1. Use the Capture sample DDDEF job SASNLBSE(ASNLDEF), Apply sample
DDDEF job SASNABSE(ASNADEF), or both, to change the DB2
DSN###.SDSNLOAD library data set for DDDEF(SDSNLD##) to the new
installed level of DB2. Note that SDSNLD## refers to the new DB2 release
(51, 61, 71 ) and DSN###.SDSNLOAD refers to the new DB2 release (510,
610, or 710).
2. Run an SMP/E APPLY job to reapply any recent Capture V7 PTF, any
recent Apply V7 PTF, or both, using the SMP/E REDO operand.

Operating Capture for OS/390
An administrator can use the commands in this section to perform the
following Capture for OS/390 tasks:
v Starting the Capture program
v Scheduling the Capture program
v Stopping the Capture program
v Suspending the Capture program
v Resuming the Capture program
v Reinitializing the Capture program
v Pruning the change data and unit-of-work tables
v Displaying captured log progress
You can submit the commands from TSO or the MVS console.
This section also lists restrictions for running the Capture program.
Capture for OS/390 cannot replicate certain types of data. See “General
restrictions for replication” on page 77 for a list of restrictions.
Only one instance of the Capture program can run on a subsystem. In a

data-sharing environment, only one of any member subsystems in a
data-sharing group can run the Capture program. In a data-sharing
environment, DB2 presents merged log records from all member subsystems.
Starting Capture for OS/390
it detects an unrecoverable error. You can start it either with JCL or as a
system started task.
To start the Capture for OS/390 program with JCL:

1. Prepare the JCL for OS/390 by specifying the appropriate optional
invocation parameters in the PARM field of the Capture job. Customize
the JCL in library SASNLJCL(ASNL2RN#) to meet your site’s
requirements.
An example of this line in the invocation JCL is:
//ASNL2RNx EXEC PGM=ASNLRPnn,PARM='DB2_subsystem_name NOTERM WARMNS SLEEP=2'
where x and nn indicate the level of the Capture program, as follows:

v For the Capture program running on DB2 for OS/390 Version 5 Release
1, x is 5 and nn is 75.
v For the Capture program running on DB2 for OS/390 Version 6, x is 6
and nn is 76.
Chapter 10. Capture and Apply for OS/390 227

v For the Capture program running on DB2 for OS/390 Version 7, x is 7
and nn is 77.
2. Submit the JCL from TSO or from the MVS console. Capture for OS/390
can run either as a batch job or a started task.
To start the Capture for OS/390 program as a system-started task:
1. Create a procedure (procname) in your PROCLIB. This procedure contains
the JCL (for example ASNL2RN5, ASNL2RN6, or ASNL2RN7 in library
SASNLJCL) required to run the Capture program.
2. Update module ICHRIN03 (RACF), which associates procname with the
user ID to be used to start the Capture program. Make sure that the
necessary DB2 authorization is granted to this user ID before you start the
Capture program.
3. Build this module in SYS1.LPALIB. You must re-IPL the MVS system to
activate these changes.
4. From the MVS system console, run the command start procname.
Table 24 defines the invocation parameters.

Table 24. Capture invocation parameter definitions for OS/390
Parameter Definition
DB2_subsystem_name Specifies the name of the DB2 subsystem that can
connect to the control server. The default for the
subsystem name is DSN. This parameter must be the
first parameter.
For data sharing, do not use the group attach name.

Instead, specify a member subsystem name.
TERM (default) Terminates the Capture program if DB2 is terminated.
NOTERM Keeps the Capture program running if DB2 is terminated
with MODE(QUIESCE). When DB2 initializes, the
Capture program starts in WARM mode and begins
capturing where it left off when DB2 terminated.
If DB2 terminates via FORCE or due to abnormal

termination, the Capture program terminates even if you
selected this parameter.
If you use the NOTERM option and start DB2 with

restricted access (ACCESS MAINT), the Capture program
will not be able to connect and will terminate.
WARM (default) The Capture program resumes processing where it ended
in its previous run if warm start information is available.
If the Capture program cannot warm start, it switches to
a cold start.

Table 24. Capture invocation parameter definitions for OS/390 (continued)
WARMNS The Capture program resumes processing where it ended
Otherwise, it issues a message and terminates. With
WARMNS, the Capture program does not automatically
switch to a cold start. The Capture program leaves the
trace, UOW, CD, and warm start tables intact. In case of
errors, the Capture program terminates instead of
switching to a cold start as when WARM is specified.
COLD The Capture program starts up by deleting all rows in its
CD table, UOW table, and trace table during
initialization. All subscriptions to these replication
sources will be fully refreshed during the next Apply
processing cycle. A full refresh is not done if the target is
a noncomplete CCD table (see “Resolving gaps between
source and target tables” on page 147).
PRUNE (default) The Capture program automatically prunes the rows in
the CD and UOW tables that the Apply program copied
at the interval specified in the tuning parameters table.
The Capture program also prunes the CD and UOW
rows that are older than the retention limit, even though
they have not been copied during warm start.
NOPRUNE Automatic pruning is disabled. The Capture program
prunes the CD and UOW tables only when you enter the
PRUNE command.
NOTRACE (default) No trace information is written.
TRACE Writes trace messages to the standard output, SYSPRINT.
SLEEP=n Specifies the number of seconds that the Capture
program will wait when it finishes processing the active
log, where n is the number of seconds. This parameter is
available for the Capture program running on DB2 for
MVS Version 4 Release 1 and later with data sharing.
The default is SLEEP=0.
ALLCHG (default) Specifies that an entry is made to the CD table whenever
any source table row changes.
CHGONLY Specifies that an entry is made to the CD table when a
source table row changes only if the columns defined for
replication (CD table columns) change values.
Scheduling Capture for OS/390

Use either the $TA JES2 command or the AT NetView command to start
Capture for OS/390 at a specific time. You must:
1. Create a procedure that calls Capture for OS/390 in the PROCLIB.

2. Modify the ICHRIN03 RACF module (or appropriate definitions for your
MVS security package) to associate the procedure with a user ID.
3. Link-edit the module in SYS1.LPALIB.
Stopping Capture for OS/390
Use the STOP command to stop the Capture program gracefully and commit
the log records that it processed up to that point. (See MVS System Commands
for details.)
F jobname ,STOP
Issue the STOP command before:

v Removing an existing replication source
v Opening and modifying an existing replication source
v Shutting down the database
Suspending Capture for OS/390
Use the SUSPEND command to relinquish OS/390 resources to operational
transactions during peak periods without destroying the Capture program
environment. This command suspends the Capture program until you issue
the RESUME command.
F jobname ,SUSPEND
Important: Do not use SUSPEND when canceling a replication source.

Instead, stop the Capture program by entering the STOP command.
Resuming Capture for OS/390
Use the RESUME command to resume the suspended Capture program.
F jobname ,RESUME
Reinitializing Capture for OS/390

Use the REINIT command to begin to capture changes from new source
tables if you add a new replication source. The REINIT command tells the
Capture program to obtain newly added replication sources from the register
table.
REINIT also rereads the tuning parameters table for any changes made to the
tuning parameters.

F jobname ,REINIT
Important: Do not use the REINIT command to reinitialize the Capture

program after canceling a replication source or dropping a replication source
table while the Capture program is running. Instead, stop the Capture
program and start it again using the WARM or WARMNS option.
Before you add a column to a replication source or CD table using the ALTER
TABLE statement, you must ensure that the Capture program has captured all
the changes for the table. After the ALTER TABLE statement, you must issue
the REINIT command.
Pruning the change data and unit-of-work tables
Use the PRUNE command to start pruning the CD and UOW tables.
This command prunes tables once.

F jobname ,PRUNE
The Capture program issues the message ASN0124I when the command is
successfully queued.
If you stop or suspend the Capture program during pruning, you must enter
the PRUNE command again to resume pruning. Pruning does not resume
after you enter the RESUME command.
Displaying captured log progress
Use the GETLSEQ command to get the timestamp and current log sequence
number. You can use this information to determine how far the Capture
program has read the DB2 log.
F jobname ,GETLSEQ
The Capture program issues the message ASN0125I indicating when the
current log sequence number is successfully processed.
Operating Apply for OS/390

An administrator can use the commands in the following sections to perform
the following Apply for OS/390 tasks:
v Starting the Apply program
v Scheduling the Apply program

v Stopping the Apply program
You can submit the commands from TSO or an MVS console.

Starting Apply for OS/390
After you start the Apply program, it runs continuously until:
v You stop it in an orderly way.
v You cancel it.
v An unexpected error or failure occurs.
To start the Apply for OS/390 program:
Prepare the JCL for OS/390 by specifying the appropriate invocation

parameters in the PARM field of the Apply job. Customize the JCL to meet
your site’s requirements. Invocation JCL in library SASNAJCL(ASNA2RN#) is
included with the Apply for OS/390 product.
An example of this line in the invocation JCL is:

//ASNARUN EXEC PGM=ASNAPVnn,PARM='Apply_qual DB2_subsystem_name DISK'
Where nn is the level the Apply program, as follows:

v For the Apply program running on DB2 for OS/390 Version 5 Release 1, nn
is 75.
v For the Apply program running on DB2 for OS/390 Version 6, nn is 76.
v For the Apply program running on DB2 for OS/390 Version 7, nn is 77.
Table 25. Apply invocation parameter definitions
Apply_qual Specifies the Apply qualifier that the Apply instance uses
to identify the subscription sets to be served. The Apply
qualifier is case sensitive and must match the value of
APPLY_QUAL in the subscription set table. This must be
the first parameter.
DB2_subsystem_name Specifies the name of the DB2 subsystem that can
connect to the control server. This parameter must be the
second parameter.
For data sharing, do not use the group attach name.

Instead, specify a member subsystem name.
Control_server_name Specifies the name of the server where the replication
control tables will reside. If you do not specify this
parameter, the default is the current server.

Table 25. Apply invocation parameter definitions (continued)
LOADXit Specifies that the Apply program is to invoke
ASNLOAD, an IBM-supplied exit routine that uses the
export and load utilities to refresh target tables.
Currently, no utility program is available for use by
ASNLOAD on DB2 for OS/390.
NOLOADXit (default) Specifies that the Apply program will not invoke
ASNLOAD.
MEMory (default) Specifies that a memory file stores the fetched answer
set. The Apply program fails if there is insufficient
memory for the answer set.
DISK Specifies that a disk file stores the fetched answer set.
INAMsg (default) Specifies that the Apply program is to issue a message
when the Apply program is inactive.
NOINAMsg Specifies that the Apply program will not issue this
message.
NOTRC (default) Specifies that the Apply program does not generate a
trace.
TRCERR Specifies that the Apply program generates a trace that
contains only error information.
TRCFLOW Specifies that the Apply program generates a trace that
contains error and execution flow information.
NOTIFY Specifies that the Apply program is to invoke
ASNDONE, an exit routine that returns control to the
user when the Apply program finishes copying a
subscription set.
NONOTIFY (default) Specifies that the Apply program will not invoke
ASNDONE.
SLEEP (default) Specifies that the Apply program is to go to sleep if no
new subscriptions are eligible for processing.
NOSLEEP Specifies that the Apply program is to stop if no new
subscription sets are eligible for processing.
DELAY(n) Specifies the delay time (in seconds) at the end of each
Apply cycle when continuous replication is used, where
n=0, 1, 2, 3, 4, 5, or 6. The default delay time is 6
seconds.

Table 25. Apply invocation parameter definitions (continued)
ERRWAIT(n) Specifies the number of seconds that the Apply program
waits before retrying after it encounters an error
condition, where n is the number of seconds. Do not
specify too small a number because the Apply program
will run almost continuously and generate many rows in
the Apply trail table. The default wait period is 300
seconds (5 minutes).
Scheduling Apply for OS/390

Use either the $TA JES2 command or the AT NetView command to start
Apply for OS/390 at a specific time. You must:
1. Create a procedure that calls Apply for OS/390 in the PROCLIB.
2. Modify the ICHRIN03 RACF module (or appropriate definitions for your
MVS security package) to associate the procedure with a user ID.
3. Link-edit the module in SYS1.LPALIB.
See MVS/ESA JES2 Commands for more information about using the $TA JES2
command, and the NetView for MVS Command Reference for more information
about using the AT NetView command.
Stopping Apply for OS/390
Enter the following MVS STOP command to stop the Apply for OS/390
program:
P jobname
Rules for index types

You can avoid deadlock and timeout problems in your applications if you
specify TYPE 2 indexes, because TYPE 2 indexes do not lock index pages.
TYPE 2 indexes also enable you to use other functions, such as parallel-query
central processor (CP) processing, improved partition independence, row
locking, and the ability to read through locks. If you specify TYPE 2 indexes,
all specifications of SUBPAGES are ignored, and an error message is issued.
If you do not specify an index type, the index type is determined as follows:
v If the LOCKSIZE is ROW, the default index type is TYPE 2, regardless of
the type specified on the installation panel DSNTIPE.
v If the LOCKSIZE is not ROW, the default index type is the type specified in
the field DEFAULT INDEX TYPE on the installation panel DSNTIPE. The
default value for that field is TYPE 2.

Recommendations:
v Specify TYPE 2 as the index type for all table indexes. For best
performance, bind the Capture program and the Apply packages using
isolation UR. When you specify isolation UR, all indexes on the control
tables must be TYPE 2 indexes. If source views are being used in
subscription sets, and the Apply package is bound using isolation UR, only
TYPE 2 indexes over the source tables involved in the source view can be
used by the Apply program.
v For DB2 for OS/390 source servers, specify TYPE 2 on every generated
CREATE INDEX statement and every CREATE INDEX statement in the
DB2 Control Center file DPCNTL.MVS. (DRJA creates TYPE2 indexes
automatically.)
Using the DB2 ODBC Catalog

The DB2 ODBC Catalog is designed to improve the performance of ODBC
applications. The tables in the DB2 ODBC Catalog are prejoined and indexed
to support faster catalog access for ODBC applications. IBM’s ODBC driver
also supports multiple views of the DB2 ODBC Catalog.
Support for use of the DB2 ODBC Catalog is provided by DB2

DataPropagator Version 5 and later. For information about Version 5 level
support, see the IBM Replication Guide and Reference V5. Enhancements to the
DB2 ODBC Catalog for DB2 DataPropagator Version 6 include:
v Support for the SYSIBM.SYSROUTINES table
v Support for the SQLProcedureColumns ODBC function call
You can eliminate data currency problems by using the DB2 ODBC Catalog
tables. DB2 DataPropagator for OS/390 Version 6 can keep data in the DB2
ODBC Catalog synchronized with the contents of the real DB2 catalog table.
The Capture program identifies log records that represent changes to the DB2
catalog and records these changed data records in a staging table. The Apply
program replicates the changed data records to the DB2 ODBC Catalog tables.
This section describes how to implement the DB2 ODBC Catalog using the
automatic mode. The automatic mode automatically replicates any DB2
Catalog changes to the DB2 ODBC Catalog tables.
Setting up the DB2 ODBC Catalog
The following section provides setup instructions needed to prepare your
client and server to run your ODBC queries.
Setting up the workstation client

To use the entire DB2 ODBC Catalog, add the entry CLISCHEMA=CLISCHEM to
the DB2CLI.INI file. To use your own set of views rather than the entire DB2

ODBC Catalog, add the entry CLISCHEMA=MYSCHEMA to the DB2CLI.INI file. The
following example contains both statements.
[tstcli1x]
uid=userid
pwd=password
autocommit=0
TableType="'TABLE','VIEW','SYSTEM TABLE'"
[tstcli2x]
Assuming dbalias2 is a database in DB2 for MVS
SchemaList="'OWNER1','OWNER2','CURRENT SQLID'"
[MyVeryLongDBALIASName]
dbalias=dbalias3
SysSchema=MYSCHEMA
[RDBD2205]
AUTOCOMMIT=1
LOBMAXCOLUMNSIZE=33554431
LONGDATACOMPAT=1
PWD=USRT006
UID=USRT006
DBALIAS=RDBD2205
CLISCHEMA=CLISCHEM
[RDBD2206]
AUTOCOMMIT=1
LOBMAXCOLUMNSIZE=33554431
LONGDATACOMPAT=1
PWD=USRT006
UID=USRT006
DBALIAS=RDBD2206
CLISCHEMA=MYSCHEMA
You must define views for all the DB2 ODBC Catalog tables when you use
your own schema. See Table 26 on page 237 for the list of the DB2 ODBC
Catalog tables for which you must define a view. Use the following VIEW
MYSCHEMA statement to define the DB2 ODBC Catalog views on
CLISCHEM.table_name ODBC tables.
CREATE VIEW MYSCHEMA.table_name FROM CLISCHEM.table_name
where TABLE_SCHEM=MYUSER
Where table_name is one of DB2 ODBC Catalog table names.
Setting up the server

To set up the server, define the following control information for replication:
1. Create the DB2 DataPropagator for OS/390 control tables, if they do not
already exist.
a. Review the header portion of the ASNL2CN6.SQL file and customize
the table spaces according to your site requirements.

b. Connect to the OS/390 RDB that contains the catalog from which you
want to create a new DB2 ODBC Catalog.
c. Run the ASNL2CN6.SQL file from either the client or the OS/390
server.
2. Create the source, subscription control, and table space information for the
DB2 ODBC Catalog.
a. Review the header portion of the ASNL2SY6.SQL, ASNL2RE6.SQL, and
ASNL2SU6.SQL files and customize the table spaces according to your
site requirements.
b. Replace all occurrences of SRCE in the ASNL2SU6.SQL file with the
OS/390 RDB name. You can also define additional views on the
predefined subscriptions to further qualify the subscriptions.
c. Connect to the OS/390 RDB that contains the catalog from which you
want to create a new DB2 ODBC Catalog.
d. Run the ASNL2SY6.SQL, ASNL2RE6.SQL, and ASNL2SU6.SQL files
from either the client or the OS/390 server.
3. Start the Capture and Apply programs on OS/390. Starting the Capture
and Apply programs populates the ODBC Catalog on OS/390.
DB2 ODBC Catalog tables
Table 26 lists the ODBC function calls that are supported by the DB2 ODBC
Catalog and explains how the function calls are implemented by DB2
Universal Database for OS/390 Version 7.
Table 26. ODBC function calls
ODBC function call ODBC catalog tables
SQLColumns The SELECT command is issued against preformatted data stored in
CLISCHEM.COLUMNS.
This call is implemented using the source table SYSIBM.SYSCOLUMNS.

SQLColumnPrivileges The SELECT command is issued against prejoined data stored in
CLISCHEM.COLUMNPRIVILEGES.
This call is implemented with source tables SYSIBM.SYSCOLUMNS,

SYSIBM.SYSTABAUTH, and SYSIBM.SYSCOLAUTH.
SQLForeignKeys The SELECT command is issued against prejoined data stored in
CLISCHEM.FOREIGNKEYS.
This call is implemented with source tables SYSIBM.SYSRELS,

SYSIBM.SYSFOREIGNKEYS, and SYSIBM.SYSCOLUMNS.
SQLPrimaryKeys The SELECT command is issued against the primary keys stored in
CLISCHEM.PRIMARYKEYS.
This call is implemented with the source table SYSIBM.SYSCOLUMNS.

Table 26. ODBC function calls (continued)
ODBC function call ODBC catalog tables
SQLProcedures The SELECT command is issued against CLISCHEM.PROCEDURES, which
contains only the columns required by the SQLProcedures function.
This call is implemented with source table SYSIBM.SYSROUTINES.

SQLSpecialColumns The SELECT command is issued against prejoined data stored in
CLISCHEM.SPECIALCOLUMNS.
This call is implemented with source tables SYSIBM.SYSCOLUMNS,

SYSIBM.SYSKEYS, and SYSIBM.SYSINDEXES.
SQLTablesPrivileges The SELECT command is issued against CLISCHEM.TABLEPRIVILEGES.
This call is implemented with source table SYSIBM.SYSTABAUTH.

SQLTables The SELECT command is issued against prejoined data stored in
CLISCHEM.TABLES.
This call is implemented with source table SYSIBM.SYSTABLES.

SQLStatistics The SELECT command is issued against prejoined data stored in
CLISCHEM.TSTATISTICS.
This call is implemented with source tables SYSIBM.SYSTABLES,

SYSIBM.SYSINDEXES, and SYSIBM.SYSKEYS.
SQLProcedureColumns The SELECT command is issued against prejoined data stored in
CLISCHEM.PROCEDURECOLUMNS.
This call is implemented with source tables SYSIBM.SYSROUTINES and

SYSIBM.SYSPARMS.

Chapter 11. Capture and Apply for UNIX platforms
programs on the following UNIX platforms:
v AIX
v HP-UX
v Linux
v NUMA-Q
v Solaris
the Capture and Apply programs:
v “User ID requirements for running the Capture and Apply programs”
v “Setting up the Capture and Apply programs”
User ID requirements for running the Capture and Apply programs

Before you set up the Capture and Apply programs, you must set up a UNIX
user account to run the programs. Ensure that the user ID under which the
Capture and Apply programs will run has the required privileges:
v Execute privilege on the Capture and Apply program packages
v DBADM or SYSADM authority for the source, control, and target servers

Setting up consists of configuring the source, target, and control servers. The
following sections provide instructions for configuring each server as well as
information about setting up end-user authentication at the source server.
Configuring the Capture program for UNIX platforms
1. Log on with a user ID that has sufficient privileges.
2. Connect to the source server database by entering:
db2 connect to database
where database is the source server database.

3. Prepare the source server database for roll-forward recovery by issuing the
update database configuration command and the backup database
command. For example:
db2 update database configuration for database_alias using logretain on
db2 backup database database_alias

or:
db2 update database configuration for database_alias using userexit on
db2 backup database database_alias
You might need to increase DBHEAP, APPLHEAPSZ, PCKCACHESZ,

LOCKLIST, and LOGBUFSZ based on your installation requirements.
4. Optional: The Capture program is bound automatically during execution;
however, if you want to specify options or check that all bind processes
complete successfully, complete the following steps:
a. Change to the directory where the Capture program bind files are
located, which is usually $HOME/sqllib/bnd.
b. Create and bind the Capture program package to the source server
database by entering the following command:
db2 bind @capture.lst isolation ur blocking all
where ur specifies the list in uncommitted read format for greater

performance.
These commands create a list of packages, the names of which are in the
file CAPTURE.LST.
Optional: Configuring the Apply program manually for UNIX platforms
Important: The Apply package is bound automatically during execution.
Therefore, the following steps for binding the Apply package on UNIX are
optional. If you want to specify options or check that all bind processes
completed successfully, complete the following steps:
2. Change to the directory where the Apply program bind files are located,
which is usually $HOME/sqllib/bnd.
3. For each source, target, and control server to which the Apply program
connects, do the following steps:
a. Connect to the server database by entering:
db2 connect to database
where database is the source, target, or control server .
Note: If the server database is cataloged as a remote database, you

might need to specify a user ID and password on the db2
connect to command. For example:
db2 connect to database user userid using password
b. Create and bind the Apply program package to the server database by
entering the following commands:
db2 bind @applycs.lst isolation cs blocking all grant public
db2 bind @applyur.lst isolation ur blocking all grant public

where cs specifies the list in cursor stability format, and ur specifies
the list in uncommitted read format.
Because the Apply program control tables use static SQL calls for the
control tables, the Apply bind process searches for the control tables at
each server that the Apply program is bound to, regardless of whether
these control tables are used at a server.
files APPLYCS.LST and APPLYUS.LST.
Other configuration considerations for UNIX-based components
Ensure that the user ID from which the Capture and Apply programs are
running has write privilege on the directories where you invoke the programs.
Write privilege is necessary because both the Capture and Apply programs
create files in the invocation directory.
The Capture program creates the following files in addition to the spill files:
instnameSRCSRVR.ccp
A log file for the messages issued by the Capture program. These
messages are also recorded in the trace table.
instnameSRCSRVR.tmp
A file that contains the process ID of this invocation of the Capture
program (to prevent multiple Capture programs from being started in
the same instance on the same source server).
The Apply program creates the following files:

APPLYQUAL.app
A log file for the messages issued by the Apply program. These
messages are also recorded in the Apply trail table.
ASNAPPLYAPPLYQUAL.pid
A file that contains the process ID of this invocation of the Apply
program. This prevents multiple Apply programs from being started
with the same Apply qualifier.
For more information about configuration of UNIX-based components, see

IBM DB2 Universal Database for UNIX Quick Beginnings.
Setting up end-user authentication at the source server
In some cases you must provide a password file for end-user authentication to
occur at the source server. The Apply program uses this file when connecting
to the source server. Give read access to only the user ID that will run the
Apply program. Environment-specific requirements include:
v If you installed Apply for HP-UX or Apply for Solaris, you must use an
AUTH=SERVER scheme and provide a password file.
Chapter 11. Capture and Apply for UNIX platforms 241

v If you installed Apply for AIX, you must provide a password file if you
want to use an AUTHENTICATION=SERVER scheme at any server that the
Apply program will connect to. If you use an
AUTHENTICATION=CLIENT scheme for all servers, you do not need to
provide a password file.
Creating a password file:
The password file must meet the following criteria:

v Be named applyqual.PWD
Where applyqual is a case-sensitive string that must match the case and
value of the Apply qualifier (APPLY_QUAL) in the subscription set table
exactly.
For example: DATADIR.PWD
This naming convention is the same as the log file name (APPLYQUAL.app)
and the spill file name (APPLYQUAL.nnn), but with a file extension of
.pwd.
v Reside in the same directory from which you will start the Apply program.
v Include no blank lines or comment lines. Add only the server-name, user
ID, and password information. This information enables you to use
different passwords or the same password at each server.
v Have one or more records using the following format:
SERVER=server_name USER=userid PWD=password
Where:
server_name
The name of the source, target, or control server, exactly as it
appears in the subscription set table.
userid The user ID that you plan to use to administer that particular
server. This value is case-sensitive.
password
The password that is associated with userid. This value is
case-sensitive.
If you do not create a password file:
The Apply program for UNIX must be able to issue an SQL CONNECT
statement without specifying the user ID and password. If the Apply program
needs to connect to an OS/390 database with SNA connectivity, these settings
are necessary:
v The DB2 for OS/390 database must be cataloged as
AUTHENTICATION=CLIENT.

v The login ID must belong to PRIMARY GROUP=SYSTEM.
v SECURITY=SAME for an MVS CPI-C node.
v You specify the following values when you define the LU name by using
the VTAM APPL:
– VERIFY=NONE to indicate that any LU can request an LU-LU session
– SECACPT=ALREADYV to indicate user ID and password checking at
the requester
Universal Database Administration Guide.
Operating Capture for UNIX platforms

An administrator can use the commands in this section to operate the Capture
program for UNIX platforms. Enter the commands or a key combination from
a UNIX command line.
This section explains how to perform the following Capture program tasks:
v “Starting Capture for UNIX platforms” on page 244
v “Scheduling Capture for UNIX platforms” on page 244
v “Setting environment variables for Capture for UNIX platforms” on
page 244
v “Stopping Capture for UNIX platforms” on page 247
v “Suspending Capture for UNIX platforms” on page 247
v “Resuming Capture for UNIX platforms” on page 248
v “Reinitializing Capture for UNIX platforms” on page 248
v “Pruning the change data and unit-of-work tables” on page 249
v “Displaying captured log progress” on page 249
Some actions cause the Capture program to terminate while it is running. Stop
the Capture program before you take any of the following actions:
v Remove an existing replication source.
v Drop a replication source table.
v Make changes that affect the structure of source tables, such as changes
resulting from data definition language or utilities. Structural changes can
compromise the data integrity of the copies. (Using ALTER ADD to add
new columns is an exception.)

The Capture program cannot capture any changes made by DB2 utilities,
because the utilities do not log the changes that they make.
Scheduling Capture for UNIX platforms
Use the at command to start the Capture program at a specific time. For
example, the following command starts the Capture program at 3:00 p.m. on
Friday:
at 3pm Friday asnccp warmns noprune
Setting environment variables for Capture for UNIX platforms

You must set two environment variables before you start the Capture
program. These variables must also be set when you use any of the following
functions:
v Stop the Capture program
v Suspend the Capture program
v Resume the Capture program
v Reinitialize the Capture program
v Prune change data or unit-of-work tables
v Display captured log progress
To set the environment variables:
1. Set the environment variable for the DB2 instance name (DB2INSTANCE)
as shown:
export DB2INSTANCE=db2_instance_name
2. Optional: Set environment variable DB2DBDFT to the source server.
Starting Capture for UNIX platforms
To start the Capture program for a UNIX platform:

1. Log in and make sure that the user ID under which the Capture program
is running has write privilege on the directory.
2. Ensure that you set the DB2 instance name as shown:
While the Capture program is running, a file with the name

Database_instance_nameDatabase_name.ccp is created in the directory from
which the Capture program is started. This file is a log file for the
messages issued by the Capture program; these messages are also
recorded in the trace table.
4. Set the LIBPATH environment variable to the directory in which the
Capture program starts. Note that in the following examples the language

environment variables depend on the language that you install, and that
db2homedir is the DB2 instance home directory.
AIX example:
export LIBPATH=db2homedir/sqllib/lib:/usr/lib:/lib
export LANG=en_US
HP-UX example:
export SHLIB_PATH=db2homedir/sqllib/lib:/usr/lib:/lib
export LANG=en_US
Linux example:
export LD_LIBRARY_PATH=db2homedir/sqllib/lib:/usr/lib:/lib:/db2/linux/lib
export LANG=en_US
NUMA-Q example:
export LD_LIBRARY_PATH=db2homedir/sqllib/lib:/opt/jse3.0/lib
export LANG=en_US
Solaris example:
export LD_LIBRARY_PATH=db2homedir/sqllib/lib:/usr/lib:/lib
export LANG=en_US
export NLSPATH=/usr/lib/locale/%L/%N:/db2homedir/sqllib/msg/en_US/%N
5. Enter the following command:
asnccp
src_server warm prune notrace trcfile
warmns noprune trace
cold

notrctbl autostop logreuse logstdout allchg
chgonly

Table 27. ASNCCP invocation parameter definitions for UNIX platforms
src_server Source server name must be the first parameter if
entered. If not specified, the value from the DB2DBDFT
environment variable is used.
warm (default) The Capture program resumes processing where it ended
a cold start.

Table 27. ASNCCP invocation parameter definitions for UNIX platforms (continued)
warmns The Capture program resumes processing where it ended
warmns, the Capture program does not automatically
switching to a cold start as when warm is specified.
cold The Capture program starts by deleting all rows in its
prune (default) The Capture program automatically prunes the rows in
the CD and UOW tables that the Apply program has
copied, at the interval specified in the tuning parameters
table. In addition, the Capture program also prunes the
CD and UOW rows that are older than the retention
limit even though they have not been copied during
warm start.
noprune Automatic pruning is disabled. The Capture program
prunes the CD and the UOW tables only when you enter
the prune command.
notrace (default) No trace information is written.
trace Writes trace messages to the standard output, stdout,
unless trcfile is also specified.
trcfile If both trcfile and trace are specified, the Capture
program writes trace output to the trace file (*.trc). If you
do not specify this option, the Capture program sends
trace output to the standard output, stdout.
notrctbl The Capture program messages are not logged in the
trace table.
autostop The Capture program terminates after it captures all
transactions logged before the Capture program was
started.
logreuse The Capture program reuses the log file (*.ccp) by first
deleting it and then recreating it when the Capture
program is restarted. If you do not specify this option,
the Capture program appends messages to the log file,
even after the Capture program is restarted.

Table 27. ASNCCP invocation parameter definitions for UNIX platforms (continued)
logstdout The Capture program sends all messages to both the
standard output (stdout) and the log file.
allchg (default) Specifies that an entry is made to the CD table whenever
chgonly Specifies that an entry is made to the CD table when a
Stopping Capture for UNIX platforms

Use the stop command or a key combination to stop the Capture program in
an orderly way and commit the log records that it processed up to that point.
You must stop the Capture program before removing or modifying an existing
replication source.
Before you stop the Capture program, ensure that the environment variables
are set (see “Setting environment variables for Capture for UNIX platforms”
on page 244). To stop the Capture program, enter the command:
If you set environment variable DB2DBDFT (see step 2 on page 244):

asncmd stop
or, if you did not set environment variable DB2DBDFT:

asncmd src_server stop
Suspending Capture for UNIX platforms

Use the suspend command to relinquish operating system resources to
operational transactions during peak periods without destroying the Capture
program environment. This command suspends the Capture program until
you issue the resume command.
Before you suspend the Capture program, ensure that the environment
variables are set (see “Setting environment variables for Capture for UNIX
platforms” on page 244). To suspend the Capture program, enter the
command:

asncmd suspend

asncmd src_server suspend
Important: Do not use the suspend command when canceling a replication

source. Instead, stop the Capture program.
Resuming Capture for UNIX platforms
Use the resume command to restart the Capture program if you suspended it
using the suspend command.
Before you resume the Capture program, ensure that the environment
platforms” on page 244). To resume the Capture program, enter the command:

asncmd resume

asncmd src_server resume
Reinitializing Capture for UNIX platforms

Use the reinit command to begin to capture changes from new source tables if
you add a new replication source or ALTER ADD a column to a replication
source and CD table while the Capture program is running. The reinit
command tells the Capture program to obtain newly added replication
sources from the register table.
reinit also rereads the tuning parameters table for any changes made to the
tuning parameters.
Before you reinitialize the Capture program, ensure that the environment
platforms” on page 244). To reinitialize the Capture program, enter the
command:

asncmd reinit

asncmd src_server reinit
Important: Do not use the reinit command to reinitialize the Capture program
after canceling a replication source or dropping a replication source table
while the Capture program is running. Instead, stop the Capture program and
restart it using the WARM or WARMNS option.
Use the prune command to start pruning the CD and UOW tables.
Before you begin pruning tables, ensure that the environment variables are set
(see “Setting environment variables for Capture for UNIX platforms” on
page 244). To begin pruning tables, enter the command:

asncmd prune

asncmd src_server prune
the prune command again to resume pruning. Pruning does not resume after
you enter the resume command.
Use the getlseq command to get the timestamp and current log sequence

Before you display captured log progress, ensure that the environment
platforms” on page 244). To display captured log progress, enter the
command:

asncmd getlseq

asncmd src_server getlseq
Tip: You can use the DB2 UDB Find Log Sequence Number command
(db2flsn) to identify the physical log file associated with the log
sequence number. You can use this number to delete or archive log files
no longer needed by the Capture program. For more information, see the
IBM DB2 Universal Database Command Reference.
Operating Apply for UNIX platforms

the following Apply program tasks:
v “Starting Apply for UNIX platforms” on page 251
v “Scheduling Apply for UNIX platforms” on page 254
v “Stopping Apply for UNIX platforms” on page 254
v You have the proper authorization. See “Authorization requirements for
running the Apply program” on page 105 for information about
authorization for the Apply program.
v At least one subscription set is created and activated.
v The Apply package is created.32
v A password file was created, if necessary, for end-user authentication at the
source server. See “Setting up end-user authentication at the source server”
on page 241 for more information.
32. Usually the Apply package is created automatically for you; however, if you configure the Apply program
manually, you must explicitly bind the Apply package.

Starting Apply for UNIX platforms
v You cancel it.
To start the Apply program on a UNIX platform:

1. Log on with the user ID that will run the Apply program.
2. Ensure that you set the DB2 instance name as shown:
3. Set the LIBPATH and language environment variables or edit the .profile
file in the same environment in which the Apply program starts. Note that
in the following examples the language environment variables depend on
the language that you install, and that db2homedir is the DB2 instance
home directory.
AIX example:
export LIBPATH=db2homedir/sqllib/lib:/usr/lib:/lib
export LANG=en_US
HP-UX example:
export SHLIB_PATH=db2homedir/sqllib/lib:/usr/lib:/lib
export LANG=en_US
Linux example:
export LD_LIBRARY_PATH=db2homedir/sqllib/lib:/usr/lib:/lib:/db2/linux/lib
export LANG=en_US
NUMA-Q example:
export LD_LIBRARY_PATH=db2homedir/sqllib/lib
export LANG=en_US
Solaris example:
export LD_LIBRARY_PATH=db2homedir/sqllib/lib:/usr/lib:/lib
export NLS_PATH= /usr/lib/locale/%L/%N:db2homedir/sqllib/msg/en_US/%N
export LANG=en_US
4. Enter the asnapply command and options:
asnapply apl_qual
ctrl_serv loadxit inamsg notrc
noloadxit noinamsg trcerr
trcflow

trcfile notify sleep delay(n) copyonce
nonotify nosleep errwait(n)

logreuse logstdout trlreuse

Table 28. ASNAPPLY invocation parameter definitions for UNIX platforms
apl_qual Specifies the Apply qualifier that the Apply instance uses
APPLY_QUAL in the subscription set table. This must be
the first parameter.
ctrl_serv Specifies the name of the server where the replication
parameter, the default is the default database or the
value of DB2DBDFT.
loadxit Specifies that the Apply program is to invoke
noloadxit (default) Specifies that the Apply program will not invoke
ASNLOAD.
inamsg (default) Specifies that the Apply program is to issue a message
noinamsg Specifies that the Apply program will not issue this
message.
notrc (default) Specifies that the Apply program does not generate a
trace.
trcerr Specifies that the Apply program generates a trace that
trcflow Specifies that the Apply program generates a trace that
contains both error and execution flow information.
trcfile If both trcfile and either trcerr or trcflow are specified,
the Apply program writes trace output to the trace file
(*.trc). If you do not specify this option, the Apply
program sends trace output to the standard output,
stdout.

Table 28. ASNAPPLY invocation parameter definitions for UNIX platforms (continued)
notify Specifies that the Apply program is to invoke
subscription set.
nonotify (default) Specifies that the Apply program will not invoke
ASNDONE.
sleep (default) Specifies that the Apply program is to go to sleep if no
new subscription sets are eligible for processing.
nosleep Specifies that the Apply program is to stop if no new
subscriptions are eligible for processing.
delay(n) Specifies the delay time (in seconds) at the end of each
seconds.
errwait(n) Specifies the number of seconds that the Apply program
copyonce The Apply program executes one copy cycle for each
subscription set that is eligible at the time the Apply
program is invoked, and then the Apply program
terminates. An eligible subscription set is such that:
v ACTIVATE > 0
v REFRESH_TIMING = R or B or REFRESH_TIMING =
E and the specified event has occurred.
MAX_SYNCH_MINUTES and END_OF_PERIOD are
honored if specified.
logreuse The Apply program reuses the log file (*.app) by first
deleting it and then re-creating it when the Apply
the Apply program appends messages to the log file,
even after the Apply program is restarted.
logstdout The Apply program sends all messages to both the
trlreuse The Apply program empties the Apply trail table when
the Apply program is started.

Scheduling Apply for UNIX platforms
Use the at command to start the Apply program at a specific time. For
example, the following command starts the Apply program at 3:00 p.m. on
Friday:
at 3pm Friday asnapply myqual
Stopping Apply for UNIX platforms

Use the asnastop command or a key combination to stop the Apply program
in an orderly way.
To stop the Apply program, perform the following steps from a window
where the Apply program is not running:
1. Set environment variable DB2INSTANCE to the value set when the Apply
program was started.
2. Set environment variable DB2DBDFT to the source server specified when
the Apply program was started (or the DB2DBDFT value used when the
Apply program was started).
3. Enter the command.
asnastop apply_qualifier

Chapter 12. Capture for VM and Capture for VSE
This chapter describes how to set up and operate the Capture for VM and
Capture for VSE programs.
Setting up the Capture program

Setting up consists of installing the Capture program and configuring the
source servers.
See the Capture for VM Program Directory or the Capture for VSE Program
Directory for Capture program installation instructions.
Operating Capture for VM and Capture for VSE

The administrator can use the commands in this section to operate Capture
for VM and Capture for VSE.
v Starting
v Stopping
v Suspending
v Resuming
v Reinitializing
v Pruning
v Displaying captured log progress
Capture program restrictions are:
v Tables with field procedures for columns (FIELDPROC specified on
CREATE or ALTER TABLE) are not supported by Capture for VM or
Capture for VSE unless you create a new one-way FIELDPROC based on the
existing FIELDPROC. The existing FIELDPROC doesn’t require any
changes. If the corresponding column(s) on the CD table are defined with
the new one-way FIELDPROC, and if the FIELDPROC does not change the
length of the data, replication can be performed successfully.
v Because the Capture program identifies itself as an APPC/VM resource,
you must specify appropriate IUCV VM/ESA® System Directory control

statements (such as IUCV *IDENT RESANY GLOBAL) for virtual machines
that run the Capture program. For more information, see the VM/ESA
Planning and Administration Guide.
v For VM only: There can be only one Capture program per database, and
each Capture program runs in its own virtual machine. The Capture
program identifies itself as an APPC/VM resource. By default, the resource
ID value is CAPTURE. To use a different resource ID or to allow multiple
Capture programs to run on the system for different DB2 databases, change
the ENQ_NAME parameter in the ASNPARMS file.
v For VM only: The Capture program requires access to the appropriate level
of the C Run Time Library. You must issue the GLOBAL LOADLIB
SCEERUN command in VM before starting the Capture program.
v For VSE only: Only one Capture program can be running per DB2 server
for VSE database, and each Capture program runs in its own partition.
Starting Capture for VM and VSE
To start the Capture program for VM:
Invoke the ASNCCP module from a VM user ID. Keywords must be

separated by one or more blanks:
ASNCCP
WARM PRUNE TERM NOTRACE ALLCHG
WARMNS NOPRUNE NOTERM TRACE CHGONLY
COLD

NOUSERID
USERID= auth_name/password
If conflicting invocation parameters are specified, the Capture program uses

the value of the last parameter specified. For example, if ASNCCP is started
using the COLD TRACE NOTRACE parameter string, no trace information is
written (NOTRACE).
Table 29 on page 257 defines the invocation parameters.
To start the Capture program for VSE:
Sample job control member ASNS51BD provides an example of how to start

the Capture program. Start the Capture program in a partition like a batch

job. You can specify ASNCCP invocation parameters in the PARM= field, in
the order shown, separated by one or more blanks:
// EXEC PGM=ASNCCP ,PARM= ’
WARM PRUNE TERM
WARMNS NOPRUNE NOTERM
COLD
Group 1 ’
NOTRACE ALLCHG
TRACE CHGONLY
Group 1:
USERID= auth_name/password
Dbname= databasename

Table 29. ASNCCP invocation parameter definitions for VM and VSE
a cold start.
switching to a cold start as when WARM is specified.
COLD The Capture program starts up by deleting all rows in its
CD table, the UOW table, and the trace table during
program processing cycle. A full refresh is not done if the
target is a noncomplete CCD table (see “Resolving gaps
between source and target tables” on page 147).
the CD and UOW tables that the Apply program copied,
at the interval specified in the tuning parameters table.
Chapter 12. Capture for VM and Capture for VSE 257

Table 29. ASNCCP invocation parameter definitions for VM and VSE (continued)
prunes the CD and UOW tables when you enter the
PRUNE command.
TERM (default) Terminates the Capture program if the DB2 server is
terminated.
NOTERM Keeps the Capture program running when the DB2
server is terminated. When the DB2 server initializes, the
Capture program starts in WARM mode and begins
capturing where it left off when DB2 terminated.
TRACE Writes trace messages to the standard output, stdout.
a source table row changes.
USERID=auth_name/password Specifies that the Capture program should connect to the
database as user ID auth_name, with password password.
The correct password must be provided or an error is
returned. The auth_name and password are both from 1 to
8 characters in length.
For VM/ESA, if you do not specify this parameter, the

Capture program connects to the database as the user ID
on which you issue ASNCCP.
Dbname=databasename For VSE only: Identifies the name of the DB2 server for
VSE database for which changes are to be captured. The
name is from 1 to 18 characters in length. If not
specified, the default is the database name as specified in
the DBNAME directory or SQLDS if a DBNAME
directory is not set up.
Stopping Capture for VM and VSE

Use the STOP command to stop the Capture program gracefully and commit
the log records that it processed up to that point.
Issue the STOP command before:

v Removing an existing replication source
v Opening and modifying an existing replication source
v Shutting down the database
To stop the Capture program for VM:

STOP
To stop the Capture program for VSE:

MSG partition ,DATA=STOP
where partition represents the partition that is running Capture for VSE.
If you stop the Capture program, it shuts itself down and issues an
informational message. If it detects an error, the program shuts itself down
after cleaning up the data in the affected tables so that the data will not be
used. Staging tables are pruned when it is appropriate. In the case of
abnormal termination, you must initiate a cold start because the warm start
information could not be saved.
Suspending Capture for VM and VSE
Use the SUSPEND command to suspend the Capture program until you issue
the RESUME command.
To suspend the Capture program for VM:

SUSPEND
To suspend the Capture program for VSE:

MSG partition ,DATA=SUSPEND
You can use this command to suspend the Capture program to improve
performance for operational transactions during peak periods without
destroying the Capture program run environment.
Important: Do not use the SUSPEND command when canceling a replication

Resuming Capture for VM and VSE
Use the RESUME command to resume the suspended Capture program.
To resume the Capture program for VM:

RESUME
To resume the Capture program for VSE:

MSG partition ,DATA=RESUME
Reinitializing Capture for VM and VSE
Use the REINIT command to reinitialize the Capture program.
To reinitialize the Capture program for VM:

REINIT
To reinitialize the Capture program for VSE:

MSG partition ,DATA=REINIT
tables if you add a new replication source or ALTER ADD a column to a
replication source and CD table while the Capture program is running. The
REINIT command tells the Capture program to obtain newly added
replication sources from the register table.
tuning parameters.
Important: Do not use REINIT to reinitialize the Capture program after

canceling or dropping a replication source table while the Capture program is
running. Instead, stop the Capture program and start it again using the
WARM or WARMNS option.
Use the PRUNE command to start pruning the CD and UOW tables if you
disabled pruning by using the NOPRUNE invocation parameter while
starting the Capture program.

To prune the tables for VM:
PRUNE
To prune the tables for VSE:

MSG partition ,DATA=PRUNE
During pruning, if you stop or suspend the Capture program, pruning does
not resume after you enter the RESUME command. You must enter the
PRUNE command again to resume pruning.
Use the GETLSEQ command to provide the timestamp and current log
sequence number. You can use this number to determine how far the Capture
To display captured log progress for the Capture program for VM:
GETLSEQ
To display captured log progress for the Capture program for VSE:
MSG partition ,DATA=GETLSEQ

Chapter 13. Capture and Apply for Windows and OS/2
programs on the following operating systems:
v Windows 32-bit operating systems (such as Windows 95, Windows 98, or
Windows NT)
v OS/2
This chapter also describes replication on demand for Windows 32–bit

operating systems. For detailed information about replication on demand, see
“Replicating on demand (Windows 32–bit operating systems only)” on
page 279.
the Capture and Apply programs:
v “User ID requirements for running the Capture and Apply programs”
v “Setting up the Capture and Apply programs”
User ID requirements for running the Capture and Apply programs

The user ID under which the Capture and Apply programs will run must
have the following authorities and privileges:
v Execute privilege on the Capture and Apply program packages
v DBADM or SYSADM authority for the source, control, and target servers

Setting up consists of configuring the source, target, and control servers, and
setting up NT services on Windows. The following sections provide
instructions for configuring each server, setting up end-user authentication at
the source server, and setting up the NT Service Control Manager.
Configuring the Capture program for Windows and OS/2
2. Connect to the source server database by entering:
DB2 CONNECT TO database
where database is the source server database.

3. Prepare the source server database for roll-forward recovery by issuing the
UPDATE DATABASE CONFIGURATION command and the BACKUP
DATABASE command. For example:

DB2 UPDATE DATABASE CONFIGURATION FOR database_alias USING LOGRETAIN ON
DB2 BACKUP DATABASE database_alias
or:
DB2 UPDATE DATABASE CONFIGURATION FOR database_alias USING USEREXIT ON
DB2 BACKUP DATABASE database_alias
You might need to increase DBHEAP, APPLHEAPSZ, PCKCACHESZ,

LOCKLIST, and LOGBUFSZ based on your installation requirements.
4. Optional: The Capture program is bound automatically during execution;
however, if you want to specify options or check that all bind processes
complete successfully, complete the following steps:
a. Change to the directory where the Capture program bind files are
located, which is usually drive:\SQLLIB\BND.
b. Create and bind the Capture program package to the source server
database by entering the following command:
DB2 BIND @CAPTURE.LST ISOLATION UR BLOCKING ALL
where UR specifies the list in uncommitted read format for greater

performance.
file CAPTURE.LST.
Optional: Configuring the Apply program manually for Windows and OS/2
Important: The Apply package is bound automatically during execution.
Therefore, the following steps for binding the Apply package on Windows
and OS/2 are optional. If you want to specify options or check that all bind
processes complete successfully, complete the following steps:
2. Change to the directory where the Apply program bind files are located,
which is usually drive:\SQLLIB\BND.
3. For each source, target, and control server to which the Apply program
connects, do the following steps:
a. Connect to the server database by entering:
DB2 CONNECT TO database
where database is the source, target, or control server. If the server

database is cataloged as a remote database, you might need to specify
a user ID and password on the DB2 CONNECT TO command. For
example:
DB2 CONNECT TO database USER userid USING password
b. Create and bind the Apply program package to the server database by
entering the following commands:

DB2 BIND @APPLYCS.LST ISOLATION CS BLOCKING ALL GRANT PUBLIC
DB2 BIND @APPLYUR.LST ISOLATION UR BLOCKING ALL GRANT PUBLIC
where CS specifies the list in cursor stability format, and UR specifies

the list in uncommitted read format.
Because the Apply program uses static SQL calls for the control tables,
the Apply bind process searches for the control tables at each server
that the Apply program is bound to, regardless of whether these
control tables are used at a server.
files APPLYCS.LST and APPLYUR.LST.
Setting up end-user authentication at the source server
For end-user authentication to occur at the source server, you must provide a
password file with an AUTH=SERVER scheme. The Apply program uses this
file when connecting to the source server. Give read access to only the user ID
that will run the Apply program.
Creating a password file:

v Be named as shown:
applyqual.PWD
Where applyqual is a case-sensitive string that must match the case and
value of the Apply qualifier (APPLY_QUAL) in the subscription set table
exactly.
This naming convention is the same as the log file name (applyqual.app) and
the spill file name (applyqual.nnn), but with a file extension of .PWD.
v Reside in the directory from which you will start the Apply program.
v Include no blank lines or comment lines. Add only the server-name, user
ID, and password information. This information enables you to use
different passwords or the same password at each server.
v Have one or more records using the following format:
SERVER=server_name USER=userid PWD=password
Where:
server_name
The source, target, or control server, exactly as it appears in the
subscription set table.
Chapter 13. Capture and Apply for Windows and OS/2 265
userid The user ID that you plan to use to administer that particular
server. On Windows, this value is case-sensitive.
password
The password that is associated with the userid. On Windows, this
value is case-sensitive.
Universal Database Administration Guide.
Setting up the NT Service Control Manager
You can operate the Capture and Apply programs for Windows by using the
DB2 command processor or by using the NT Service Control Manager (SCM).
The SCM enables you to automatically start the Capture and Apply programs
as services from the NT Control Panel.
If you want to operate Capture and Apply as services, you must install the
replication service manually (installation is not automatic). The following
steps explain how to install the replication service and set it up as an NT
service.
In this section, x:\ refers to the drive and directory containing executable
programs. These programs are usually located in the \sqllib\bin directory.
To install the replication service and set up the NT service:

1. Open a command window, and change to the directory containing the
executable file ASNINST.EXE.
2. Install the replication service by typing the following command:
ASNINST x:\ASNSERV.EXE
3. Set up the service from the NT Control Panel:
a. Double-click the Services icon. The NT Services window opens.
b. Select Replication and click STARTUP.
c. Ensure that the startup type is automatic.
d. Specify the local user ID and password and click OK. The user ID
must be the one that runs the Capture and Apply programs and has
the appropriate DB2 privileges.
4. Add the environment variable ASNPATH to specify the location of the
Capture and Apply program files:
a. Double-click the System icon on the NT Control Panel. The System
Properties window opens.
b. Click the Environment tab.
c. Type the ASNPATH string in the Variable field as shown in the
following example:
ASNPATH=x:

Important: Do not add a backslash to the ASNPATH variable.
d. Click OK.
e. Reboot the computer.
5. Create an ASCII file called ntserv.asn to run the Capture and Apply
programs:
a. Open a new file and enter the following records:
db_name x:\ASNCCP parameters
db_name x:\ASNAPPLY parameters
where db_name specifies the name of the source database for the
Capture program and the name of the control database for the Apply
program, x:\ is the location of the programs, and parameters specifies
one or more invocation parameters (such as the Apply qualifier).
To use the Capture program and Apply program trace facilities, specify
the invocation parameters in the file. For example:
DBNAME1 C:\SQLLIB\BIN\ASNCCP COLD TRACE<CRLF>
DBNAME2 C:\SQLLIB\BIN\ASNAPPLY APPLYQUAL DBNAME2 TRCFLOW TRCFILE<CRLF>
The TRCFILE invocation parameter is necessary, in addition to the

usual trace invocation parameter (such as TRCFLOW), to generate an
Apply program trace.
Do not specify an output file name for traces. These will be written to
default locations, with default file names, as follows:
v For the Capture program:
x:\instancenamedbname.trc
v For the Apply program:
x:\APPLYtimestamp.trc
b. Save the file to the following location:
x:\ntserv.asn
The Replication Services program stores all messages in x:\asnserv.log. If you
encounter any problems, check this log file for error messages.
To stop the Capture and Apply programs:
Important: After you start the service, the Capture and Apply programs run
independently of ASNSERV. Therefore, stopping ASNSERV does not stop the
Capture and Apply programs. Use the ASNCMD STOP command in a
command window to stop the Capture program. Use the ASNASTOP
command in a command window to stop the Apply program.
To remove the replication service from the NT service:
To remove Replication Services from the NT Control Panel, run the
ASNREMV program.
Operating Capture for Windows and Capture for OS/2

An administrator can use the commands in this section to operate the Capture
program on Windows and the Capture program on OS/2. Enter the
commands or a key combination from an NT or an OS/2 window.
v “Starting Capture for Windows and OS/2” on page 269
v “Scheduling Capture for Windows and OS/2” on page 271
v “Setting environment variables for Capture for Windows and OS/2”
v “Stopping Capture for Windows and OS/2” on page 271
v “Suspending Capture for Windows and OS/2” on page 272
v “Resuming Capture for Windows and OS/2” on page 273
v “Reinitializing Capture for Windows and OS/2” on page 273
v “Pruning the change data and unit-of-work tables” on page 274
v “Displaying captured log progress” on page 274
Some actions cause the Capture program to terminate while it is running. Stop
the Capture program before you take any of the following actions:
v Remove an existing replication source.
v Drop a replication source table.
v Make changes that affect the structure of source tables, such as changes
resulting from data definition language or utilities. Structural changes can
compromise the data integrity of the copies. (ALTER ADDs of new columns
are an exception.)
The Capture program cannot capture any changes made by DB2 utilities,
because the utilities do not log changes that they make.
Setting environment variables for Capture for Windows and OS/2
You must set two environment variables before you start the Capture
program. These variables must also be set when you use any of the following
functions:
v Stop the Capture program
v Suspend the Capture program
v Resume the Capture program
v Reinitialize the Capture program

v Prune change data or unit-of-work tables
v Display captured log progress
To set the environment variables:
1. Set the environment variable for the DB2 instance name (DB2INSTANCE)
as shown:
SET DB2INSTANCE=db2_instance_name
Starting Capture for Windows and OS/2
To start the Capture program using the NT Services:

1. Select Replication from the NT Services window.
2. Click the START push button. The Capture program starts according to
the ASCII file information that you provided.
You can also start the replication service by typing STRTSERV on the NT
command line.
To start the Capture program using the DB2 command window:

1. If you created one or more DB2 for NT or DB2 for OS/2 instances, use the
SET command to set the DB2INSTANCE environment variable to the DB2
for NT or DB2 for OS/2 instance with which you plan to run the Capture
program:
SET DB2INSTANCE=database_instance_name
While the Capture program is running, a file with the name

Database_instance_name Database_name.CCP (Windows) or
database_name.CCP (OS/2) is created in the directory from which the
Capture program is started. This file is a log file for the messages issued
by the Capture program; these messages are also recorded in the trace
table.
3. To start the Capture program, enter the ASNCCP command from the
Windows or OS/2 window where you issued the SET command. The
syntax is:
ASNCCP
src_server WARM PRUNE NOTRACE TRCFILE
WARMNS NOPRUNE TRACE
COLD

NOTRCTBL AUTOSTOP LOGREUSE LOGSTDOUT ALLCHG
CHGONLY

Table 30. ASNCCP invocation parameter definitions for Windows and OS/2 platforms
src_server Source server name must be the first parameter if
entered. If not specified, the value from the DB2DBDFT
environment variable is used.
a cold start.
switching to a cold start as when warm is specified.
COLD The Capture program starts by deleting all rows in its
the CD and UOW tables that the Apply program has
copied, at the interval specified in the tuning parameters
table. In addition, the Capture program also prunes the
CD and UOW rows that are older than the retention
limit even though they have not been copied during
warm start.
prunes the CD and the UOW tables only when you enter
the PRUNE command.
TRACE Writes trace messages to the standard output, stdout,
unless TRCFILE is also specified.

Table 30. ASNCCP invocation parameter definitions for Windows and OS/2
platforms (continued)
TRCFILE If both trcfile and trace are specified, the Capture
program writes trace output to the trace file (*.trc). If you
do not specify this option, the Capture program sends
trace output to the standard output, stdout.
NOTRCTBL The Capture program messages are not logged in the
trace table.
AUTOSTOP The Capture program terminates after it captures all
transactions logged before the Capture program was
started.
LOGREUSE The Capture program reuses the log file (*.ccp) by first
deleting and then re-creating it when the Capture
the Capture program appends messages to the log file,
even after the Capture program is restarted.
LOGSTDOUT The Capture program sends all messages to both the
Scheduling Capture for Windows and OS/2

For Windows: Use the AT command to start the Capture program at a
specific time. Before you enter the AT command, the Windows Schedule
Service should already be started. For example, the following command string
starts the Capture program for Windows at 15:00 (3:00 p.m.):
c:\>AT 15:00 /interactive "c:\SQLLIB\BIN\db2cmd.exe c:\CAPTURE\asnccp.exe warmns"
For OS/2: Use the Alarms program in the OS/2 Productivity set to start
Capture for OS/2 at a specific time.
Stopping Capture for Windows and OS/2
Use the STOP command or a key combination to stop the Capture program
in an orderly way and commit the log records that it processed up to that
point.
Stop the Capture program before removing for modifying an existing

replication source.
For Windows: If you started the Capture program as an NT service, the
Capture program runs independently of ASNSERV. By selecting Replication
from the NT Services window and clicking Stop, you can stop ASNSERV but
not the Capture program. Use the ASNCMD STOP command in a command
window to stop the Capture program.
For Windows and OS/2: Before you stop the Capture program, ensure that
the environment variables are set (see “Setting environment variables for
Capture for Windows and OS/2” on page 268). To stop the Capture program,
enter the command:

ASNCMD STOP

ASNCMD src_server STOP
Suspending Capture for Windows and OS/2

Use the SUSPEND command to relinquish operating system resources to
operational transactions during peak periods without destroying the Capture
program environment. This command suspends the Capture program until
you issue the RESUME command.
Before you suspend the Capture program, ensure that the environment
variables are set (see “Setting environment variables for Capture for Windows
and OS/2” on page 268). To suspend the Capture program, enter the
command:

ASNCMD SUSPEND

ASNCMD src_server SUSPEND
Important: Do not use the SUSPEND command when canceling a replication


Resuming Capture for Windows and OS/2
Use the RESUME command to restart the Capture program if you suspended
it using the SUSPEND command.
Before you resume the Capture program, ensure that the environment
and OS/2” on page 268). To resume the Capture program, enter the command:

ASNCMD RESUME

ASNCMD src_server RESUME
Reinitializing Capture for Windows and OS/2

tables if you add a new replication source or use ALTER ADD to add a
column to a replication source and CD table while the Capture program is
running. The REINIT command tells the Capture program to obtain newly
added replication sources from the register table.
tuning parameters.
Before you reinitialize the Capture program, ensure that the environment
and OS/2” on page 268). To reinitialize the Capture program, enter the
command:

ASNCMD REINIT

ASNCMD src_server REINIT
Important: Do not use the REINIT command to reinitialize the Capture

program after canceling a replication source or dropping a replication source
table while the Capture program is running. Instead, stop the Capture
program and restart it using the WARM or WARMNS option.
Use the PRUNE command to start pruning the CD and UOW tables.
Before you prune the change data and unit-of-work tables, ensure that the
environment variables are set (see “Setting environment variables for Capture
for Windows and OS/2” on page 268). To begin pruning tables, enter the
command:

ASNCMD PRUNE

ASNCMD src_server PRUNE
the PRUNE command again to resume pruning. Pruning does not resume
after you enter the RESUME command.
Use the GETLSEQ command to get the timestamp and current log sequence
Before you display captured log progress, ensure that the environment
and OS/2” on page 268). To display captured log progress, enter the
command:

ASNCMD GETLSEQ

ASNCMD src_server GETLSEQ
Tip: You can use DB2 UDB Find Log Sequence Number command
(DB2FLSN) to identify the physical log file associated with the log
sequence number. You can use this number to delete or archive log files
no longer needed by the Capture program. For more information, see the
IBM DB2 Universal Database Command Reference.
Operating Apply for Windows and OS/2

the following Apply program tasks:
v “Starting Apply for Windows and OS/2”
v “Scheduling Apply for Windows and OS/2” on page 278
v “Stopping Apply for Windows and OS/2” on page 278
v You have the proper authorization. See “Authorization requirements for
running the Apply program” on page 105 for information about
authorization for the Apply program.
v At least one subscription set is created and activated.
v The Apply package is created.33
v For Windows: A password file has been created for end-user authentication
at the source server. See “Setting up end-user authentication at the source
server” on page 265 for more information.
Starting Apply for Windows and OS/2
v You cancel it.
To start the Apply program using the NT services:
33. Usually the Apply package is created automatically for you; however, if you configure the Apply program
manually, you must explicitly bind the Apply package.
1. Select Replication from the NT Services window.
2. Click the Start push button. The Apply program starts according to the
ASCII file information you provided.
You can also start the replication service by typing STRTSERV on the
Windows NT command line.
To start the Apply program on a Windows or OS/2 platform:
Perform the following steps from a Windows or OS/2 window:

1. Log on with the IBM Replication user ID.
2. Ensure that you set the DB2 instance as shown:
SET DB2INSTANCE=db2_instance_name
3. Enter the ASNAPPLY command from the Windows or OS/2 window
where you issued the SET command:
ASNAPPLY Apl_qual
Ctrl_serv LOADXit INAMsg NOTRC
NOLOADXit NOINAMsg TRCERR
TRCFLOW

TRCFILE NOTIFY SLEEP DELAY(n) COPYONCE
NONOTIFY NOSLEEP ERRWAIT(n)

LOGREUSE LOGSTDOUT TRLREUSE

Table 31. ASNAPPLY invocation parameter definitions on Windows and OS/2 platforms
Apl_qual Specifies the Apply qualifier that the Apply instance uses
the APPLY_QUAL in the subscription set table. This
must be the first parameter.
Ctrl_serv Specifies the name of the server where the replication
parameter, the default is the default database or the
value of DB2DBDFT.

Table 31. ASNAPPLY invocation parameter definitions on Windows and OS/2
LOADXit Specifies that the Apply program is to invoke
NOLOADXit (default) Specifies that the Apply program will not invoke
ASNLOAD.
INAMsg (default) Specifies that the Apply program is to issue a message
NOINAMsg Specifies that the Apply program will not issue this
message.
NOTRC (default) Specifies that the Apply program does not generate a
trace.
TRCERR Specifies that the Apply program generates a trace that
TRCFLOW Specifies that the Apply program generates a trace that
contains both error and execution flow information.
TRCFILE If both trcfile and either trcerr or trcflow are specified,
the Apply program writes trace output to the trace file
(*.trc). If you do not specify this option, the Apply
program sends trace output to the standard output,
stdout.
NOTIFY Specifies that the Apply program is to invoke
subscription set.
NONOTIFY (default) Specifies that the Apply program will not invoke
ASNDONE.
SLEEP (default) Specifies that the Apply program is to go to sleep if no
new subscription sets are eligible for processing.
NOSLEEP Specifies that the Apply program is to stop if no new
subscription sets are eligible for processing.
DELAY(n) Specifies the delay time (in seconds) at the end of each
seconds.
Table 31. ASNAPPLY invocation parameter definitions on Windows and OS/2
ERRWAIT(n) Specifies the number of seconds that the Apply program
COPYONCE The Apply program executes one copy cycle for each
subscription set that is eligible at the time the Apply
program is invoked, and then the Apply program
terminates. An eligible subscription set is such that:
v ACTIVATE > 0
v REFRESH_TIMING = R or B or REFRESH_TIMING =
E and the specified event has occurred.
MAX_SYNCH_MINUTES and END_OF_PERIOD are
honored if specified.
LOGREUSE The Apply program reuses the log file (*.app) by first
deleting it and then re-creating it when the Apply
the Apply program appends messages to the log file,
even after the Apply program is restarted.
LOGSTDOUT The Apply program sends all messages to both the
TRLREUSE The Apply program empties the Apply trail table when
the Apply program is started.
Scheduling Apply for Windows and OS/2

For Windows: Use the Windows AT command to start the Apply program at
a specific time. Before you enter the AT command, the Windows Schedule
Service should already be started. For example, the following command string
starts the Apply program for Windows at 15:00 (3:00 p.m.):
c:\>AT 15:00 /interactive "c:\SQLLIB\BIN\db2cmd.exe
c:\SQLLIB\BIN\asnapply.exe qualid1 cntldb"
For OS/2: Use the Alarms program in the OS/2 Productivity set to start the
Apply program at a specific time.
Stopping Apply for Windows and OS/2
Use the ASNASTOP command or a key combination to stop the Apply
program in an orderly way.

To stop the Apply program, perform the following steps from a window
where the Apply program is not running:
1. Set environment variable DB2INSTANCE to the value set when the Apply
program was started.
2. Set environment variable DB2DBDFT to the source server specified when
the Apply program was started (or the DB2DBDFT value used when the
Apply program was started).
3. Enter the command.
ASNASTOP Apply_qualifier
Replicating on demand (Windows 32–bit operating systems only)

On Windows 32-bit operating systems, you can use the ASNSAT command to
replicate on demand. This command starts the Apply program and, if there
are any rows in the registration table, it also starts the Capture program. (You
cannot choose whether to start Apply only, Capture only, or both programs.)
When the Capture program is started by ASNSAT, it runs on the same server
as the Apply program. Each program self-terminates after it completes its part
of the replication cycle.
The optional Capture and Apply parameters for this command are optimized
for the satellite environment. For details on using the ASNSAT command in a
satellite environment, see Administering Satellites Guide and Reference. You can
override the optional parameters for the Capture and Apply programs if you
want to use the command in a non-satellite environment.
The syntax of the ASNSAT command is as follows:

ASNSAT
-q apply_qual -n cntl_srv -t trgt_srv

-c U optional Capture parameter

-a U optional Apply parameter
Table 32. ASNSAT options and invocation parameter definitions (only for Windows
32-bit operating systems)
Option Definition
-q apply_qual Specifies the Apply qualifier that the Apply program instance uses to
identify the subscriptions to be served. The Apply qualifier is case
sensitive and must match the value of the APPLY_QUAL column in
the subscription set table. This must be the first parameter.
-n cntl_serv Specifies the name of the server where the replication control tables
will reside. If you do not specify this parameter, the default is the
default database or the value of DB2DBDFT.
-t trgt_serv Specifies the name of the server where the target tables will reside.
-c Specifies the optional invocation parameters for the Capture program.
If you do not specify this option, the ASNSAT command uses the
following defaults: warm, prune, notrace, logreuse, logstdout, trcfile,
notrctbl, and autostop.
-a Specifies the optional invocation parameters for the Apply program. If
you do not specify this option, the ASNSAT command uses the
following defaults: noinam, notrc, nonotify, logreuse, logstdout, trcfile,
trlreuse, copyonce, loadx.
For more information about Capture and Apply parameters, see Table 30 on
page 270 and Table 31 on page 276 respectively.
Using DB2 DataPropagator for Microsoft Jet

DataPropagator for Microsoft Jet supports Microsoft Access and Microsoft Jet
databases in LAN, occasionally connected, and mobile environments. Without
any programming, you can replicate your server data into Microsoft Access
tables for both browsing and updating.
DataPropagator for Microsoft Jet is a single executable that contains both the
Capture and Apply capability and a portion of the administration facility.
DataPropagator for Microsoft Jet runs on a client machine under Microsoft
Windows NT or Windows 95, and reaches source databases via DB2 Client
Application Enabler (CAE). DataPropagator for Microsoft Jet is packaged as
part of DB2 DataJoiner Version 2 Release 2.1.1 (although you do not need to
install a DB2 DataJoiner server to use this software) but also works with DB2
Universal Database (DB2 UDB), DB2 Common Server V2, and DB2 Connect.
DataPropagator for Microsoft Jet requires the DataJoiner Replication
Administration tool (DJRA) at the control point.
DataPropagator for Microsoft Jet replicates relational tables to and from

Microsoft Jet databases, and detects and records any update conflicts (using
the Microsoft Jet replication model). The source server can be DB2 or any

non-DB2 replication sources defined through DB2 DataJoiner. The control
server must be a DB2 or DB2 DataJoiner database.
Figure 22 illustrates how DataPropagator for Microsoft Jet supports replication

of Microsoft Access and Microsoft Jet databases.
Figure 22. Microsoft Jet database replication. DataPropagator for Microsoft Jet extends IBM’s data
replication solution by supporting Microsoft Access and Microsoft Jet databases.
The advantages of using DataPropagator for Microsoft Jet

A small DBMS with a replicated subset of a larger corporate database enables
service employees and mobile professionals to run meaningful desktop
applications while disconnected from a server network. These users connect to
their corporate network only occasionally, and usually only long enough to
synchronize their desktop database, e-mail, and messaging services with the
corporate servers. For more information about subsets, see “Subsetting
columns and rows” on page 70.
DataPropagator for Microsoft Jet administration doesn’t require a direct

connection to a Microsoft Jet database for administration. DJRA maintains
control information in the control server database. DataPropagator for
Microsoft Jet running on a laptop is able to create Microsoft Jet databases,
tables, and additional columns, and drop tables and old columns based on the
current state of the control information in the server. To deploy a Microsoft Jet
application, the application, database, and replication software must be
installed before you distribute the laptop computers. However, the Microsoft
Jet database does not need to be created in advance.
You can define or redefine replication source and subscription definitions for a
Microsoft Jet database at any time, using DJRA, before or after you distribute
the laptops for asynchronous processing by DataPropagator for Microsoft Jet.
If you have problems with your laptop, you can rebuild your Microsoft Jet
database, tables, and contents by deleting the Jet database and
resynchronizing using DataPropagator for Microsoft Jet. DataPropagator for
Microsoft Jet can automatically rebuild your database.
For more information about usage scenarios involving mobile replication, see
“Occasionally connected” on page 22.
Data integrity considerations
Within a network of DB2 databases, DB2 DataPropagator supports an
update-anywhere model that is able to detect transaction conflicts.
DataPropagator for Microsoft Jet supports an update-anywhere model, but
with weaker row-conflict detection (similar to the standard Microsoft Jet
model). If you choose to use DataPropagator for Microsoft Jet, you should be
both familiar and comfortable with the standard Microsoft Jet replication
model.
DataPropagator for Microsoft Jet reports synchronization conflicts in conflict

tables in a very similar way to the built-in Microsoft Jet replication feature.
This process can result in a loss of updates. If you use the single-user version
of the DB2 Universal Database server on your laptop, for example, your
application is assured of all-or-nothing transaction semantics when
synchronizing with corporate servers. However, if you use Microsoft Jet as
your mobile database, synchronization conflicts are handled on a row-by-row
basis, so updates might be lost. Therefore, some updates might be flagged as
conflicting while other updates propagate to the corporate database. If this
situation is not acceptable, you need to program your own resolutions for all
potential update conflicts. For more information about how DataPropagator
for Microsoft Jet handles conflict errors, see “Error recovery” on page 288. For
more information about programming your own resolutions, refer to the
appropriate Microsoft documentation.
Terminology for DataPropagator for Microsoft Jet replication
The following terms represent replication concepts as they pertain to
Microsoft Jet database replication. For definitions of general replication terms,
see “Glossary” on page 407.

Client The Windows NT or Windows 95 machine on which DataPropagator
for Microsoft Jet is installed.
Design Master
In Microsoft Jet database replication, the original database, which is
saved as the master database. Each subsequent copy of the Microsoft
Jet database maintained by Microsoft Jet replication on another server
is called a Replica.
Row-replica
A type of update-anywhere replica maintained by DataPropagator for
Microsoft Jet. Conflicts are detected row by row, not transaction by
transaction, as they are for replicas. Row-replica is the only target
table type supported by DataPropagator for Microsoft Jet. The source
table type can be a DB2, Oracle, Sybase, Informix, or Microsoft SQL
Server user table, or a DB2 replica. The source can also be a view of a
DB2 user table or replica, including a join view with the restriction
that all copied columns must come from only one of the tables
referenced in the source view. The other columns in the source view
can be referenced in the subscription predicates, but cannot be
included in the row-replica.
Setting up DataPropagator for Microsoft Jet replication
To prepare the replication environment, you need to prepare the replication
sources, control servers, and client environment. The following sections
provide instructions for preparing your replication environment.
Preparing the replication source and control servers

You prepare the server to use DataPropagator for Microsoft Jet just as you
would for DB2 DataPropagator. To prepare the server:
1. Create the necessary replication control tables at the control server by
using DJRA.
2. Define replication sources by defining the source tables on each source
server by using DJRA.
3. Define subscription sets by using DJRA. From the Create Empty
Subscription Sets window, select the Microsoft Jet check box and enter the
Microsoft Jet target server name. The target server name must be different
from the control server name in this case.
4. Start the Capture program for each DB2 source server, if applicable.
Preparing the client environment

To prepare the client, install the following software (if it is not already
installed):
1. Install DB2 Client Application Enabler (CAE) and configure DB2
connectivity to the source and control servers for the appropriate
communication protocols.
2. Configure the DB2 ODBC driver by using the DB2 Client Configuration
Assistant window.
3. Install either one of the following:
v Microsoft Data Access Components (MDAC)
v Microsoft Access
4. Install the DAO component (downloadable from
http://www.nesbitt.com/bctech.html or available on the Microsoft Visual
C++ Version 5 CD-ROM).
5. Install DataPropagator for Microsoft Jet (during DB2 DataJoiner
installation).
v During installation you will be prompted to set the ASNJETPATH
environment variable to specify the directory where DataPropagator for
Microsoft Jet can create the log, trace, and password files. The file names
are:
– Apply_qual.LOG. Created by DataPropagator for Microsoft Jet.
– Apply_qual.TRC. Created by DataPropagator for Microsoft Jet.
– Apply_qual.PWD. Created by DataPropagator for Microsoft Jet.
DataPropagator for Microsoft Jet also creates the target database in this
directory if it does not already exist.
v Define the Microsoft Jet database source in the ODBC Data Source
Administration window, if it is not already defined.
Providing end-user authentication: If the source or control server requires

authentication, create a password file.
To create a password file:

v Be named APPLY_QUAL.PWD
Where: APPLY_QUAL is the Apply qualifier, in uppercase. You specify a
value for the Apply qualifier when you define a subscription set.
Where: DATADIR is the Apply qualifier of the subscription set defined at
the control server.
v Reside in the directory that is specified by ASNJETPATH.
v Contain all server-name/password pairs. This enables you to have a
different (or the same) password at each server.
v Have one or more records that use the following format:
SERVER=server_name PWD=password USER=userid
The file cannot include blank lines or comment lines.

For more information about authentication and security, refer to the DataJoiner
Administration Supplement.
Operating DataPropagator for Microsoft Jet
You can use the commands in this section to operate DataPropagator for
Microsoft Jet.
This section explains how to perform the following tasks:

v Starting the Capture program at the source server
v Starting DataPropagator for Microsoft Jet at the client
v Stopping DataPropagator for Microsoft Jet at the client
v Troubleshooting DataPropagator for Microsoft Jet at the client
Starting the Capture program at the source server

Before you start DataPropagator for Microsoft Jet, you must start the Capture
program on each DB2 source server, if applicable.
Starting DataPropagator for Microsoft Jet

Before you start DataPropagator for Microsoft Jet, you must establish any
required line or LAN connection. DataPropagator for Microsoft Jet does not
directly manage telephone connections, so you need to dial up the server
manually or use any software that provides auto-dialing to establish a
connection before you call DataPropagator for Microsoft Jet to perform
database synchronization.
To start DataPropagator for Microsoft Jet, use the ASNJET command. Enter
the ASNJET command from a command prompt.
ASNJET apply_qual ctrl_srvr
INAMSG NOTRC NOTIFY
NOINAMSG TRCERR NONOTIFY
TRCFLOW

MOBILE
NOMOBILE
Table 33 defines the parameters.

Table 33. ASNJET command parameter definitions for DataPropagator for Microsoft Jet
apply_qual Specifies the Apply qualifier that uniquely identifies this
client.
ctrl_srvr Specifies the control server alias.
Table 33. ASNJET command parameter definitions for DataPropagator for Microsoft
Jet (continued)
INAMSG Specifies that DataPropagator for Microsoft Jet issue an
inactivity message to the log whenever DataPropagator for
Microsoft Jet is going to sleep until the next copy cycle. This
option is ignored if you specify the MOBILE option.
NOINAMSG (default) Specifies that no inactivity message is issued.
NOTRC (default)
TRCERR Specifies that a trace file of minimal information is created.
TRCFLOW Specifies that a trace file of extensive information is created.
NOTIFY Specifies that DataPropagator for Microsoft Jet call the
ASNJDONE exit routine at the completion of each
subscription set, regardless of success or failure.
NONOTIFY (default) Specifies that DataPropagator for Microsoft Jet does not call
the ASNJDONE exit routine.
MOBILE Specifies that DataPropagator for Microsoft Jet run in mobile
mode (copy all active subscriptions only once, and then
terminate).
NOMOBILE (default) Specifies that DataPropagator for Microsoft Jet run
continuously until it is stopped with the ASNJSTOP
command.
Example 1: If you enter the following command from a command prompt,

DataPropagator for Microsoft Jet is invoked with the Apply qualifier
MYQUAL, the control server is CNTLSRVR, no inactivity message is
generated, no trace is produced, the ASNJDONE exit routine is not called, and
the active subscriptions are copied only once and then the program exits.
ASNJET MYQUAL CNTLSRVR MOBILE
Example 2: If you enter the following command from a command prompt,

DataPropagator for Microsoft Jet is invoked with the Apply qualifier AQ2, the
control server is CNTLSRV, an extensive trace is produced, and the program
runs continuously until you stop it with the ASNJSTOP command.
ASNJET AQ2 CNTLSRV TRCFLOW NOMOBILE
Stopping DataPropagator for Microsoft Jet

When you start DataPropagator for Microsoft Jet using the MOBILE option, it
runs until all active subscriptions are processed, and then terminates by itself.
If you want to stop DataPropagator for Microsoft Jet, you can use the

ASNJSTOP command to stop the program in an orderly way as soon as the
current subscription set is copied and commit the log records processed up to
that point.
Use the following command to stop DataPropagator for Microsoft Jet. Enter
the ASNJSTOP command from a command prompt.
ASNJSTOP apply_qual
Where apply_qual is the Apply qualifier that you used when you started
DataPropagator for Microsoft Jet with the ASNJET command.
Example: If you enter the following command from a command prompt,

DataPropagator for Microsoft Jet stops processing the Apply qualifier MQUAL
as soon as the current subscription set is processed.
ASNJSTOP MYQUAL
You can also use one of the following key combinations from the window
where the program is running to stop DataPropagator for Microsoft Jet:
v Ctrl+C
v Ctrl+Break
Troubleshooting DataPropagator for Microsoft Jet

If you encounter errors when you run ASNJET, ensure that:
v All replication sources and subscriptions are defined.
v The Capture program is started on the source server, if applicable.
v The control server and source server are defined as ODBC data sources.
v You supplied a password file in the ASNJETPATH directory.
v If you opened and updated a row-replica target table through Microsoft
Access, you closed the table.
For error message information, see “Chapter 15. Capture and Apply
messages” on page 353. For more information about troubleshooting, see
“Troubleshooting” on page 166.
Returning control to users with the ASNJDONE exit routine
If you specify the NOTIFY parameter when you start DataPropagator for
Microsoft Jet with the ASNJET command, DataPropagator for Microsoft Jet
calls the exit routine ASNJDONE at the completion of each subscription set ,
regardless of success or failure. ASNJDONE.SMP is a sample program
shipped with the product. You can modify it to meet the requirements of your
installation. For example, the exit routine can examine the error table to
discover rejected updates and initiate further actions, such as issuing a
message or generating an alert.
See the prologue section in the sample exit routine ASNJDONE.SMP for
instructions on how to modify the sample.
Parameters
The parameters that DataPropagator for Microsoft Jet passes to ASNJDONE
are:
Control server
The control server alias.
Set name
The name of the set just processed.
Apply qualifier
The Apply qualifier of this DataPropagator for Microsoft Jet instance.
Trace option
The trace option specified when DataPropagator for Microsoft Jet was
started.
Status value
Set to a value of 0 for success, and -1 for failure.
Error recovery
If the status value that DataPropagator for Microsoft Jet passes to ASNJDONE
is -1, conflicts or errors might have been recorded. You can set the exit routine
to examine the error codes and messages in the error message table. (There
can be more than one row in the error message table.)
When DataPropagator for Microsoft Jet detects an update conflict between the
RDBMS source and row-replica target table, it saves additional information for
the ASNJDONE exit routine as follows:
v Inserts a row into the conflict table. (This is not the same conflict table that
Microsoft Jet might detect between the Design Master and its Microsoft Jet
Replicas.) The conflict table contains the row data that conflicted with the
RDBMS update.
v Places the names of the conflict tables in the side information table. Each
Microsoft Jet target table has its own conflict table. If a conflict is detected,
the update to the row-replica loses while the source server update wins.
For other errors, such as referential integrity checks, DataPropagator for

Microsoft Jet places additional information in the error information table, if
applicable, to identify the row-replica table and the row that caused the error.
The exit routine can use this information to take remedial action. When the
exit routine returns, the status is still -1 in the subscription set table.
DataPropagator for Microsoft Jet does not expect any output or return codes
from the exit routine.

DataPropagator for Microsoft Jet control tables
DataPropagator for Microsoft Jet requires the following new control tables, in
addition to the existing DB2 DataPropagator control tables. For details about
the column and index definitions for each of these new control tables, see
“Chapter 14. Table structures” on page 293.
Control server tables

Row-replica-target-list table
Maintains the names of the row replica tables. This allows
DataPropagator for Microsoft Jet to maintain a list of known
row-replica tables in a stable DB2 or DB2 DataJoiner database.
DataPropagator for Microsoft Jet uses this information during schema
analysis to determine which, if any, row-replica tables should be
deleted because the corresponding subscription member was dropped
since the last synchronization.
Signals modifications to a subscription.
Target server tables

Conflict table
This table (one per target table, as needed at the target server)
contains row data for DataPropagator for Microsoft Jet-detected
conflict losers. If there is a conflict between the same row in the
Microsoft Jet database (target server) and the source server, the row in
the Microsoft Jet database ″loses,″ so it is added to the conflict table
and replaced by the row in the source.
Error information table
Contains additional information to identify the row-replica table and
row that caused an error.
Error messages table
Contains error codes and error messages.
Error-side-information table
Contains the names of the conflict tables.
Key string table
Maps Microsoft Jet table identifiers and row identifiers to primary key
values.
Used to prevent cyclic updates from propagating back to the RDBMS
from a Microsoft Jet database.
Part 4. Reference information
“Chapter 14. Table structures” on page 293 describes the source, control, and
target table structures.
“Chapter 15. Capture and Apply messages” on page 353 lists all of the
messages issued by all the Capture and Apply programs except those on the
AS/400 platform.
“Chapter 16. Replication messages for AS/400” on page 381 lists all of the
messages for data replication on the AS/400 platform.

Chapter 14. Table structures
This chapter describes the relational database tables that are used for
replication.
Table 34 on page 296, Table 35 on page 298, and Table 36 on page 299 provide
brief descriptions of the tables listed in this chapter. When you become
familiar with the tables, you can use Figure 23 on page 294 and Figure 24 on
page 295 as a quick reference for the source and control server tables, table
keys, and their parameters.
Important: You must not use SQL to update some of the control tables (see
particular table descriptions for details). Altering control tables
inappropriately can cause problems such as unexpected results, loss of data,
and reduced replication performance.
Tables at a glance
Figure 23 on page 294 and Figure 24 on page 295 show the tables at the source
and control servers, table keys, and their parameters.

Figure 23. Tables used at the source server. The tables used by the Capture program, Apply
program, and Capture triggers at the source server.

Figure 24. Tables used at the control server. The tables used by the Apply program at the control
server.
Chapter 14. Table structures 295

List of tables used at the source server
The following table provides a list of tables used at the source server during
DB2 replication.
Table 34. Quick reference for tables used at the source server
See
Table name Internal name and description page
Apply-qualifier-cross- ASN.IBMSNAP_AUTHTKN 317
reference table (AS/400
specific) Contains information to support
update-anywhere.
Capture enqueue table ASN.IBMSNAP_CCPENQ 313
(VM and VSE specific) Used to ensure that only one Capture program
is running per database.
Change data table CD 321
A table that contains changed data

information. Created when a replication source
is defined.
Consistent-change-data table userid.target_table 343
Contains additional columns to help identify

transactions. This table stores the individual
operations, transactions, and the approximate
times of those transactions.
Critical section table ASN.IBMSNAP_CRITSEC 315
Used to prevent circular replication for

update-anywhere replication.
Pruning control table ASN.IBMSNAP_PRUNCNTL 309
Coordinates synchpoint updates by allowing

the Apply program to communicate with the
Capture program and coordinates pruning of
tables. There is one pruning control table at
each source server and one row per
source-to-target copy.
Prune lock table ASN.IBMSNAP_PRUNE_LOCK 316
Used to serialize the access of staging tables

during a cold start or retention limit pruning.

Table 34. Quick reference for tables used at the source server (continued)
See
Register table ASN.IBMSNAP_REGISTER 301
Contains information about replication sources,

such as the names of the replication source
tables, their attributes, and their corresponding
CD and CCD table names.
Register extension table ASN.IBMSNAP_REG_EXT 308
(AS/400 specific)
An extension of the register table. Contains
additional information about replication
sources, such as the journal name and the
remote source table’s database entry name.
Register synchronization ASN.IBMSNAP_REG_SYNCH 318
table
When replicating from a non-IBM data source,
an update trigger on this table initiates an
update of the SYNCHPOINT value for all the
rows in the register table before the Apply
program reads the information from the
register table.
Trace table ASN.IBMSNAP_TRACE 316
Contains Capture program audit trail

information.
Tuning parameters table ASN.IBMSNAP_CCPPARMS 312
Contains parameters that you can modify to

control the performance of the Capture
program.
Unit-of-work table ASN.IBMSNAP_UOW 319
Contains information about committed

transactions. Used to maintain transaction
consistency.
Warm start table ASN.IBMSNAP_WARM_START 313
Contains information that enables the Capture

program to resume capturing from the point in
the log or journal where it last stopped. For
AS/400 platforms, this table is used to
determine the starting time of the RCVJRNE
(Receive Journal Entry) command.

List of tables used at the control server
The following table provides a list of tables used at the control server during
DB2 replication.
Table 35. Quick reference for tables used at the control server
See
Apply trail table ASN.IBMSNAP_APPLYTRAIL 336
Contains Apply program audit trail and problem

diagnostic information.
Subscription columns ASN.IBMSNAP_SUBS_COLS 329
table
Maps target table or view columns to the
corresponding source table or view column or
user-defined expression.
Subscription events table ASN.IBMSNAP_SUBS_EVENT 335
Contains user-defined event names that control

the execution of a subscription set. You modify
this table using SQL.
Subscription set table ASN.IBMSNAP_SUBS_SET 323
Contains processing information for a set of

subscription-set members, which are processed by
the Apply program as a group.
Subscription statements ASN.IBMSNAP_SUBS_STMTS 331
table
Contains SQL statements or stored procedure calls
that are defined in a subscription set.
Subscription-targets- ASN.IBMSNAP_SUBS_MEMBR 326
member table
Identifies a source and target table (or view) pair
and specifies processing information for that pair.
Row-replica-target-list ASN.IBMSNAP_SUBS_TGTS 333
table
Maintains the names of the row-replica tables.
(Microsoft Jet specific) Row-replica tables are a type of target table used
specifically with the Microsoft Jet database.
Subscription-schema- ASN.IBMSNAP_SCHEMA_CHG 334
changes table
Used to signal add or delete modifications to a
(Microsoft Jet specific) subscription.

List of tables used at the target server
The following table provides a list of tables used at the target server.
Table 36. Quick reference for target tables
See
Base aggregate table userid.target_table.target_table 345
Contains data aggregated from a source table.

Change aggregate table userid.target_table 346
Contains data aggregations based on changes

from a source table.
Consistent-change-data userid.target_table 343
table
Contains additional columns to help identify
transactions. This table stores the individual
operations, transactions, and the approximate
times of those transactions.
Point-in-time table userid.target_table 342
Identical to a user copy table, except that the

IBMSNAP_LOGMARKER column is included to
record a specific commit time from the source
server.
Replica table userid.target_table 345
A type of target table used for update-anywhere

replication.
Row-replica table userid.target_table 347
(Microsoft Jet specific) A type of Microsoft Jet target table that can be
updated.
User copy table userid.target_table 341
A copy of the user table.

Conflict table IBMSNAP_target_name_CONFLICT 348
(Microsoft Jet specific) Contains row data for DataPropagator for

Microsoft Jet-detected conflict losers.
Error information table IBMSNAP_ERROR_INFO 348
(Microsoft Jet specific) Contains additional information to identify the

row-replica table and row that caused an error.

Table 36. Quick reference for target tables (continued)
See
Error messages table IBMSNAP_ERROR_MESSAGE 349
(Microsoft Jet specific) Contains error codes and error messages. There
can be more than one row in this table.
Depending on the error code, additional
information will be available in the error
information, error-side-information, and conflict
tables.
Error-side-information IBMSNAP_SIDE_INFO 349
table
Contains the names of the conflict tables.
(Microsoft Jet specific)
Key string table IBMSNAP_GUID_KEY 349
(Microsoft Jet specific) Maps the Microsoft Jet table identifiers and row
identifiers to primary key values when the
following actions occur:
v Rows are deleted from Microsoft Jet database
tables.
v Deletes are recorded in MSysTombstone with
s_Generation, TableGUID and s_GUID (row)
identifiers, but without primary key details.
v The primary key values are needed to
propagate Microsoft Jet database deletes to an
RDBMS.
Synchronization IBMSNAP_S_GENERATION 350
generations table
Prevents cyclic updates from propagating back to
(Microsoft Jet specific) the RDBMS from a Microsoft Jet database.
Tables used at the source server

This section describes the tables used at the source server and the columns in
each table. These tables are created automatically the first time that you define
a replication source if you use the Control Center and if they do not already
exist on the source server. On the AS/400 platform, these tables are created
automatically in the following situations if they do not exist already on the
source server:
v When you install DB2 DataPropagator for AS/400.
v When you define the first replication source using the Control Center.

The administration tools use the information in the register, register extension,
and pruning control tables to define your source and target tables for
replication. After you define your replication sources, the Capture program
uses the tuning parameters, capture enqueue, warm start, critical section,
trace, and Apply-qualifier-cross-reference tables to control and audit your
data. In addition to all the Capture program control and audit tables
mentioned, the Capture triggers also use the register synchronization table to
control data. The UOW and CD tables track data that has not yet been
replicated.
Register table
This table contains information that you can update by using SQL.
ASN.IBMSNAP_REGISTER
The register table contains information about replication sources, such as the
names of the replication source tables, their attributes, and their staging table
names. A row is automatically inserted into this table every time a new
replication source is defined at this server. You must update this table to
maintain an external CCD table.
The register table is the place to look if you need to know how you defined
your replication sources.
Table 37 provides a brief description of the columns in the register table.

Table 37. Columns in the register table
Column name Description
SOURCE_OWNER The owner of the source table or view.
SOURCE_TABLE The source from which data is being captured.
SOURCE_VIEW_QUAL This value is set to 0 for physical tables that are defined as
sources and is greater than 0 for views that are defined as
sources. This column is used to support multiple
subscriptions for different source views with identical
SOURCE_OWNER and SOURCE_TABLE column values.
GLOBAL_RECORD A flag that indicates whether this row is the global record.
In the global record, only the SYNCHPOINT and
SYNCHTIME columns are set by the Capture program to
reflect its progress. If the Capture program has not been
running, then there is no global record.
Y This row is the global record.
N This row is not the global record.

Register table
Table 37. Columns in the register table (continued)

SOURCE_STRUCTURE A value that identifies the structure of the source table or
view:
1 User table
3 CCD table
4 Point-in-time table
5 Base aggregate table
6 Change aggregate table
7 Replica table
8 User copy table
9 Row-replica table
SOURCE_CONDENSED A flag that indicates:

Y For any given primary key, the CCD, replica, and
user tables show only one row.
N All changes must remain, retaining a complete
update history.
A Valid only for base aggregate or change aggregate
tables.
SOURCE_COMPLETE A flag that indicates:

Y The source table contains a row for every primary
key value of interest.
N The source table contains some subset of rows of
primary key values.
CD_OWNER The owner of the change data table or a view.

CD_TABLE The name of the change data table or view for captured
updates to the source table (set when you define the
replication source). This value is used by the Apply
program and can be the name of a table or a view. The
Capture program inserts one row into the CD table for
every committed and uncommitted change to this
replication source. The Apply program then joins this table
with the UOW table so that only committed changes are
replicated.

Register table

PHYS_CHANGE_OWNER The owner of the PHYS_CHANGE_TABLE. For a view
defined as a source, this value equals the value of a CD or
CCD table referenced in the change data view definition.
For non-view replication sources, the value equals the
CD_OWNER or the CCD_OWNER column. The Capture
program uses this value to properly maintain
CD_OLD_SYNCHPOINT and CD_NEW_SYNCHPOINT for
view replication sources. The Apply program uses this
value to properly maintain CCD_OLD_SYNCHPOINT and
SYNCHPOINT for view replication sources that are based
on CCD tables that the Apply program maintains.
PHYS_CHANGE_TABLE The name of the physical CD or CCD table. For a view
replication source, this value equals the value of the CD or
CCD table replication source definition referenced in the
change data view definition. For non-view replication
sources, the value equals the CD_TABLE or the
CCD_TABLE column. The Capture program uses this value
to properly maintain CD_OLD_SYNCHPOINT and
CD_NEW_SYNCHPOINT for view replication sources. The
Apply program uses this value to properly maintain
CCD_OLD_SYNCHPOINT and SYNCHPOINT for view
replication sources that are based on the CCD tables that
the Apply program maintains.
CD_OLD_SYNCHPOINT The approximate SYNCHPOINT value when the Capture
program begins to capture changes from the source table.
The Capture program sets this value to NULL during a
cold start. The Apply program sets this value to NULL for
a target replica when cascading a gap condition. If the
value is null when the synchpoint column of the pruning
control table is set to xX'00000000000000000000X', the
Capture program sets an initial value, and the same
sequence number is reflected back into the SYNCHPOINT
column of the pruning control table; this is the sequence
number associated with the pruning control table update.
Subsequent values are set by the Capture program when
old rows are pruned from the table.
CD_NEW_SYNCHPOINT The Capture program advances this column as it inserts
new rows into the CD table. If the Capture program did not
insert into the change data table recently, then the value
does not advance. The Apply program uses this column to
see if there are new changes to be replicated.

Register table

DISABLE_REFRESH When this column is created, it contains the 0 flag. If you
set the flag to 1, the Apply program is not allowed to
perform a full refresh of the source server until the flag is
set back to 0. This column is used to defer, not eliminate, a
full refresh for a subscription. For example, you might want
to defer a full refresh when the Capture program starts up
cold or a gap in the log is detected. The Apply program
will not process subscriptions to this replication source until
control table values are updated. This flag prevents full
refresh activity from overloading the source database
during peak periods. This column is initialized to 0. You
can use a program at the source database site to set this
flag.
0 Full refreshes are allowed.
1 Full refreshes are prevented.
CCD_OWNER The owner of the local CCD table.

CCD_TABLE The name of the staging table that contains committed-only
captured updates.

Register table

CCD_OLD_SYNCHPOINT This value is set in one of the following ways when the
CCD table is initialized:
v By the administration tool when the CCD table is
automatically defined as a source.
CCD_OLD_SYNCHPOINT is set to NULL.
v By the Control Center when a CCD table is defined as an
external replication source table (for example, the table is
maintained by IMS DataPropagator).
CCD_OLD_SYNCHPOINT is set to
MIN(IBMSNAP_COMMITSEQ) of the CCD table.
This column is related to full-refresh processing against

CCD tables. The value in this column needs to be changed
only when the CCD table is reinitialized or pruned of
change data that has not yet been processed by all
subscriptions which refer to it (as occurs in retention-limit
pruning). This value can be much older than any row
remaining in the CCD table, and it is maintained in one of
the following ways:
v Automatically by the Apply program or by another
external application that maintains the CCD table.
v Manually, for CCD replication sources that are not
created and maintained by the Apply program. This is
the case for CCD tables that contain changes generated
by IMS DataPropagator.
If this column is not maintained, the Apply program using

the CCD table as a replication source will not know that the
CCD table was reinitialized, so it will fail to reinitialize
complete copies of the CCD source.
SYNCHPOINT In the global row, where the GLOBAL_RECORD column is
set to Y, this is the log or journal identifier (synchpoint) of
the last log or journal record processed by the Capture
program. The Apply program compares this value to the
last synchpoint that it processed to see if there are new
changes available for replication.
For CCD source definitions, this is the equivalent to

CD_NEW_SYNCHPOINT and is updated by the Apply
program that maintains the CCD table. This column must
be set explicitly for a CCD replication source that is not
created and maintained by the Apply program. An example
is a CCD table of IMS changes generated by IMS
DataPropagator.

Register table

SYNCHTIME A source server timestamp. The Capture program or an
external program, such as IMS DataPropagator, updates this
timestamp whether there are changes to be processed or
not.
The Apply program uses this value when advanced conflict

detection is selected for update-anywhere replication to
ensure that the Capture program captured all outstanding
changes for a replication source table.
CCD_CONDENSED A flag that indicates:
Y This CCD replication source has only the last
captured change for a source table row.
N This CCD replication source has one row for each
source table row change.
CCD_COMPLETE A flag that indicates:

Y The CCD table contains a row for every primary
N The CCD table is initially empty and then is
populated as changes are applied.
ARCH_LEVEL The architectural level of the definition in the row. This

level is defined by IBM, and for Version 7 is 0201.
DESCRIPTION A field for comments that you enter when defining
BEFORE_IMG_PREFIX Represents the default character identifying before-image
column names in the CD table. The value can be NULL,
but must not match any leading character identifying
after-image user data column names in the CD table. The
length of BEFORE_IMG_PREFIX is:
1 For an ASCII or an EBCDIC single byte prefix
character.
2 For an ASCII double byte prefix character.
4 For an EBCDIC DBCS prefix character. This length
allows for shift-in and shift-out characters.

Register table

CONFLICT_LEVEL A flag that indicates:
0 The Apply program does not check for conflicts.
Data consistency must be enforced by your
application design to avoid potential conflicting
updates.
1 Standard detection with cascading transaction
rejection. The Apply program checks for conflicts
based on the changes captured to this point. The
Apply program will reverse any conflicting
transaction at the replica, as well as any
transactions with dependencies on the conflicting
transaction. Changes captured after the Apply
program begins conflict detection will not be
checked during this Apply cycle.
2 Enhanced detection with cascading transaction
rejection. The Apply program waits until the
Capture program captures all changes from the log
or journal (see description of the SYNCHTIME
column) and then does a standard conflict
detection (CONFLICT_LEVEL = 1). During the
wait time, the Apply program holds a LOCK on
the source tables to ensure that no changes are
made during the conflict detection process.

Register table

PARTITION_KEYS_CHG This value is assumed to be the same for all the user table’s
dependent replicas. A flag indicating:
N Updates to the source table are staged by the
Capture program as an update operation and
processed by the Apply program as an UPDATE
statement to the target table.
Y Updates to the source table are staged by the
Capture program as a delete and insert pair. The
Apply program processes the delete first and the
insert second. When this flag is set, every update
to a replication source is stored in the CD table as
two rows: a delete row and an insert row. This flag
ensures that an update to a key or partitioning
column is always processed correctly. Use this flag
when:
v The source columns for target table primary
keys can be updated at the source table.
v The source columns for target table partitioning
columns were defined in predicates.
v The target table is a DB2 Universal Database
Enterprise - Extended Edition table stored in a
multipartition nodegroup.
NULL If this is the global control row.
Register extension table for AS/400

Important: Do not use SQL to update this table. Altering this table
inappropriately can cause unexpected results and loss of data.
ASN.IBMSNAP_REG_EXT
This table is an AS/400-specific table that provides supplemental information

for the register table, ASN.IBMSNAP_REGISTER. For every register table row,
there is a matching row in the register extension table containing a few
additional AS/400-specific columns.
This table is maintained by a trigger program (program QZSNJRNL in library

QDPR) on the register table (ASN.IBMSNAP_REGISTER). The trigger is
defined at the time the register table is created.
Use this table to complete the information from the register table to track
where and how you defined your replication sources on an AS/400 server.

Register extension table
Table 38 provides a brief description of the columns in the register extension

table.
Table 38. Columns in the register extension table
SOURCE_NAME A 10-character source table (or view) system name, used to
issue commands.
SOURCE_MBR The name of the source table member being captured. Used
for issuing Receive Journal Entry (RCVJRNE) commands
and ALIAS support.
SOURCE_TABLE_RDB When using remote journals, this column contains the
database name of the system where the source table
actually resides. For non-remote-journal cases, this column
is NULL.
JRN_LIB The library name of the journal that the source table uses.
JRN_NAME The name of the journal used by a source table. An asterisk
followed by nine blanks in this column means that the
source table is not currently in a journal. Therefore, it is not
possible to capture data for this source table.
FR_START_TIME Time at which the full refresh starts. This column is
updated by Capture for AS/400, not the administration
tool, during operations.
SOURCE_VIEW_QUAL Supports the view of subscriptions by matching the similar
column in the register table. This value is set to equal 0 for
physical tables that are defined as a source and is greater
than 0 for views that are defined as sources. You must have
this column to support multiple subscriptions for different
source views with identical SOURCE_OWNER and
SOURCE_TABLE column values.
Pruning control table

ASN.IBMSNAP_PRUNCNTL
The pruning control table coordinates the pruning of the change data (CD)
tables, which have the potential for unlimited growth. For each new
subscription set, the Apply program first updates the pruning control table
and then it begins a full refresh of every member of the new subscription set.
After the full refresh, the Capture program begins capturing changes from the
replication source. When the Capture program begins to capture data, it

updates the pruning control table to notify the Apply program. During each
Apply cycle, the Apply program updates the pruning control table to indicate
the last change applied. The Capture program then uses the information to
prune the CD and UOW tables.
The rows in the pruning control table are not deleted during a cold start of
the Capture program. The administration tools use the values from the
pruning control table to provide a list of copies defined as source tables and
views.
There is one pruning control table at each source server and one row in the
pruning control table for each subscription-set member.
You can manually prune your table by issuing the prune command or have it
done automatically by updating the PRUNE_INTERVAL column in the tuning
parameters table. See “Tuning parameters table” on page 312 for more
information about using the tuning parameters table.
Use this table to monitor the pruning status of your CD and UOW tables.
Table 39 provides a brief description of each of the columns in the pruning

control table.
Table 39. Columns in the pruning control table
TARGET_SERVER The database name of the server where target tables or
views are stored.
TARGET_OWNER A qualifier for a target table or view.
TARGET_TABLE The target to which data is being applied.
SYNCHTIME A source server timestamp. The SYNCHTIME value equals
the SYNCHTIME field value in the subscription set table.
The Capture program or an external program, such as IMS
DataPropagator, updates this timestamp whether there are
changes to be processed or not.

ensure that the Capture program captures all outstanding
SYNCHPOINT The SYNCHPOINT value equals the SYNCHPOINT field
value in the subscription set table. This value is used to
coordinate the pruning of CD tables. The Apply program
sets this initial value to hex 0, indicating refresh. If the
Apply program sets a nonzero value, the CD table can be
eligible for pruning.

Table 39. Columns in the pruning control table (continued)

SOURCE_VIEW_QUAL Supports the view of physical tables by matching the
similar column in the register table. This value is set to 0
for physical tables that are defined as sources and is greater
than 0 for views that are defined as sources. This column is
used to support multiple subscriptions for different source
views with identical SOURCE_OWNER and
APPLY_QUAL A unique identifier for a group of subscription sets. This
case sensitive value is supplied by the user when defining a
subscription set. This column is part of the foreign key
from the subscription set table. See “Subscription set table”
on page 323 for more details.
SET_NAME An identifier for a group of subscription-set members. This
value is supplied when you define a subscription set. This
column is part of the foreign key from the subscription set
table. See “Subscription set table” on page 323 for more
details.
CNTL_SERVER The database name of the control server for the Apply
program updating this row.
TARGET_STRUCTURE A value that identifies the type of target table or view:
1 Source table
2 Not available
3 CCD table
7 Replica table
8 User copy table
9 Row-replica table
CNTL_ALIAS The DB2 Universal Database alias corresponding to the

control server named in the CNTL_SERVER column.

Tuning parameters table

ASN.IBMSNAP_CCPPARMS
This table contains parameters that you can modify to control the performance
of the Capture program. You can set these parameters to modify the length of
time that you retain data in the CD table, the amount of time that the Capture
program is allowed to lag in processing log records, how often data will be
committed, and how often your CD and UOW tables are pruned. These
modifications must be done manually because there are no DB2
DataPropagator processes that update this table after it is created. The
Capture program can read your modifications only during its start processing;
therefore, you should stop and start the Capture program if you want your
modifications to take effect.
Table 40 provides a brief description of the columns in the tuning parameters

table.
Table 40. Columns in the tuning parameters table
RETENTION_LIMIT The age limit, in minutes, for keeping CD table rows. This
value is used with the SYNCHPOINT column of the
pruning control table to determine the pruning limit. Any
change data rows older than this value are pruned, even if
they have not been copied to all targets. Transactions
rejected after update conflict detection will have their
changes pruned by RETENTION_LIMIT aging, not by
normal pruning. The default value is 10 080 minutes (which
equals seven days).
LAG_LIMIT The amount of time, in minutes, that the Capture program
is allowed to lag in processing log records before it shuts
itself down. During periods of high update frequency, full
refreshes can be more economical than updates. The default
value is 10 080 (which equals seven days).
COMMIT_INTERVAL The Capture program commit threshold, in seconds, for any
inserts, updates, or deletes to the global UOW table and
any pruning control tables. The default value is 30.
On systems that do not support ISOLATION (UR), this

value should be less than the DB2 lock timeout value to
prevent Apply program instances from timing out due to
contention with the Capture program.

Table 40. Columns in the tuning parameters table (continued)

PRUNE_INTERVAL The Capture program commit threshold, in seconds, for
automatic or manual pruning of CD and UOW rows that
are no longer needed. The default value is 300. Values set
lower save space, but increase processing costs. Values set
higher require more CD and UOW table space, but decrease
processing costs. There is no effect on table space or
processing cost when the NOPRUNE option is selected.
Capture enqueue table (VM and VSE specific)

ASN.IBMSNAP_CCPENQ
The Capture enqueue table is used in the VM and VSE environments only.
This table is used to ensure that there is only one Capture program running
per database.
Table 41 provides a list and a brief description of the Capture enqueue table
column.
Table 41. Capture enqueue table column
LOCKNAME Unique name of the resource for this database.
Warm start table

inappropriately can cause unexpected results and loss of data. If you delete all
the rows from this table, the Capture program will take longer to start
because it must calculate a restart position based on the contents of the CD
tables, the UOW table, and the control tables.
ASN.IBMSNAP_WARM_START
This table is created in the same database as the register table and contains
information that enables the Capture program to restart from the last log or
journal record read. Use the information in this table to avoid a full refresh of
your system.
You do not have to recover this table if it is damaged. Simply create an empty
table before warm starting the Capture program.

Warm start table
The following three tables show platform-specific layouts of the warm start
table:
v Table 42 shows the layout for all platforms other than VM/VSE and
AS/400.
v Table 43 shows the VM/VSE layout.
v Table 44 on page 315 shows the AS/400 layout.
Table 42. Columns in the warm start table
SEQ The last captured sequence number from the log or journal
record. Used for quickly restarting following a shutdown or
failure.
AUTHTKN The DB2 token for the unit of work associated with the
SEQ log or journal record. AUTHTKN length is 12
characters. If you supply a longer value, it is truncated.
AUTHID The DB2 authorization ID for the unit of work associated
with the SEQ log or journal record. AUTHID length is 18
characters. If you supply a longer value, it is truncated.
CAPTURED A flag indicating whether or not this unit of work was
captured.
Y This unit of work was captured.
N This unit of work was not captured.
UOWTIME The MVS clock, or Windows NT, HP-UX, Sun Solaris,

OS/2, and AIX Coordinated Universal Time (UTC) clock
indicating when the unit of work associated with the SEQ
position was captured (source server timestamp).
Table 43. Columns in the warm start table for VM and VSE platforms
SEQ The last captured sequence number from the log or journal
record. Used for quickly restarting following a shutdown or
failure.
UOWID The unit-of-recovery ID from the log record header for this
unit of work.
AUTHID The DB2 authorization ID for the unit of work associated
with the SEQ log or journal record.

Warm start table
Table 43. Columns in the warm start table for VM and VSE platforms (continued)
CAPTURED A flag indicating whether or not this unit of work was
captured.
Y This unit of work was captured.
N This unit of work was not captured.
UOWTIME The VSE and VM time-of-day clock indicating when the

unit of work associated with the SEQ log or journal record
was captured (source server timestamp).
For AS/400, the warm start table is used to determine the starting time of the
RCVJRNE (Receive Journal Entry) command. A row is inserted into the warm
start table for each journal that is used by a replication source or a group of
Table 44 provides a brief description of the columns in the warm start table
for the AS/400 platform.
Table 44. Columns in the warm start table for AS/400 platform
JRN_LIB The library name of the journal.
JRN_NAME The name of the journal used by a source table. An asterisk
followed by nine blanks in this column means that the
source table is not currently in a journal. Therefore, it is not
possible to capture data for this source table.
JRN_JOB_NUMBER The job number of the current job for a particular journal. If
the journal is not active, this column contains the job
number of the last job that was processed.
LOGMARKER The timestamp of the last processed journal entry.
UID A unique number that is used as a prefix for the contents of
the IBMSNAP_UOWID column located in the UOW table.
SEQNBR The sequence number of the last processed journal entry.
Critical section table

ASN.IBMSNAP_CRITSEC

Critical section table
This table is used to prevent circular replication in an update-anywhere

scenario.
table.
Table 45 provides a brief description of the critical section table column.

Table 45. Critical section table column
value is supplied by the user when defining a subscription
set. Each Apply process is started with an APPLY_QUAL
value. This value is used during update-anywhere
replication to prevent circular propagation of the changes
made by the Apply program. See “Subscription set table”
Prune lock table

ASN.IBMSNAP_PRUNE_LOCK
The prune lock table is used to serialize the access of staging tables during a
cold start or retention limit pruning. (Retention limit pruning is pruning after
the retention limit is reached. The default retention limit is 10 080, which
equals 7 days.) There are no rows in this table. The Capture and Apply
programs use this table as a logical lock to serialize their operations during
these critical phases. If a prune lock table does not exist, as on DB2 UDB
Version 5 servers, the critical section (ASN.IBMSNAP_CRITSEC) table is
locked instead. If a prune lock table does not exist, you can create one to
increase the concurrency of update-anywhere subscriptions.
table.
Trace table
ASN.IBMSNAP_TRACE
This table contains audit trail information for the Capture program.
Everything that is done by the Capture program is recorded in this table,
which makes it one of the best places to look if a problem with the Capture
program occurs. If you cold start the Capture program, all of the trace table’s
entries are deleted, so you might want to save a copy of this table before you
issue a cold start command.
The following two tables show platform-specific layouts of the trace table.
Table 46 on page 317 shows the layout for all platforms other than AS/400,

Trace table
and Table 47 shows the AS/400 layout.

Table 46. Columns in the trace table
OPERATION The type of Capture program operation, for example,
initialization, capture, or error condition.
TRACE_TIME The time that a row is inserted into the trace table.
DESCRIPTION The message ID followed by the message text. The message
can be informational or error. This column contains
English-only text. See “Chapter 15. Capture and Apply
messages” on page 353 for a detailed description of the
correlating message ID in the DESCRIPTION column.
Table 47. Columns in the trace table for AS/400

OPERATION The type of Capture program operation, for example,
initialization, capture, or error condition.
TRACE_TIME The time that a row is inserted into the trace table.
JOB_NAME The fully qualified name of the job that wrote this trace
entry.
Position
Description
1–10 QDPRCTL5 or the journal job name
11–20 The ID of the user who started the Capture
program
21–26 The job number
JOB_STR_TIME The starting time of the job named in the JOB_NAME

column.
DESCRIPTION The message ID followed by the message text. The message
ID is the first 7 characters of the DESCRIPTION column.
The message text starts at the 9th position of the
DESCRIPTION column. Refer to “Chapter 16. Replication
messages for AS/400” on page 381 for information about
messages.
Apply-qualifier-cross-reference table (AS/400 specific)

ASN.IBMSNAP_AUTHTKN

Apply-qualifier-cross-reference table
The Apply-qualifier-cross-reference table is used in the AS/400 environment

only. This table is used during update-anywhere replication to keep track of
the jobs run by a particular Apply qualifier. It is pruned by the Capture
program based on the retention limit. The default retention limit is 10 080,
which equals 7 days.
Table 48 provides a brief description of the columns in the

apply-qualifier-cross-reference table.
Table 48. Columns in the apply-qualifier-cross-reference table
APPLY_QUAL An Apply qualifier, which is a unique identifier for a group
of subscription sets. You supply this value when defining a
subscription set. Each Apply process is started with an
Apply qualifier. This value is used during update-anywhere
replication to prevent circular propagation of the changes
made by the Apply program. See “Subscription set table”
IBMSNAP_AUTHTKN The job name associated with a transaction. AUTHTKN
length is 12 characters. If you supply a longer value, it is
truncated. Capture for AS/400 matches this column with
the name of the job that issued the transaction to determine
if a transaction is issued by either the Apply program or a
user application. If the names match, then Capture for
AS/400 copies the value from the APPLY_QUAL column to
the UOW row. If the names do not match, then Capture for
AS/400 sets the APPLY_QUAL column of the UOW row to
blank. This column is not automatically copied to other
tables; you must select it and copy it as a user data column.
IBMSNAP_LOGMARKER The approximate commit time at the source server.
Register synchronization table

Important: Altering this table might result in wasteful pruning processing.
ASN.IBMSNAP_REG_SYNCH
There is an update trigger on this table that initiates an update of the

SYNCHPOINT value for all the rows in the register table when the Apply
program fetches data from a non-IBM data source.
Table 49 on page 319 provides a brief description of the register

synchronization table column.

Register synchronization table
Table 49. Register synchronization table column

TRIGGER_ME
Y A trigger was initiated to update the
SYNCHPOINT value for all rows in the register
table.
Unit-of-work table
ASN.IBMSNAP_UOW
The unit-of-work (UOW) table ensures data integrity by recording transactions

that were committed at the source server. The Apply program joins the UOW
and CD table based on matching IBMSNAP_UOWID values to ensure that
only committed changes are being copied. The results are ordered by the log
or journal record sequence number of the change in the CD table within the
committed units of work. If you cold start the Capture program, all of this
table’s entries are deleted.
For AS/400: Capture for AS/400 can start data capturing for only a subset of
the replication sources. Therefore, Capture for AS/400 does not
delete all the rows in the UOW table if you do a partial cold
start.
The Capture program requires that there is one UOW table for each source
server. The Capture program inserts one new row into this table for every log
or journal record that commits changes to replication sources.
For AS/400: There are some user programs that do not use commitment
control. In such cases, the Capture program arbitrarily inserts a
new UOW row after a number of rows are written to the CD
table. This artificial commitment boundary helps reduce the size
of the UOW table.
The Capture program also prunes the UOW table based on information
inserted into the pruning control table by the Apply program.
For AS/400: The UOW table is pruned by retention limits, not by the pruning
control table information.
Table 50 on page 320 provides a brief description of the columns in the UOW
table.

Unit-of-work table
Table 50. Columns in the UOW table

IBMSNAP_UOWID The unit-of-work identifier from the log record header for
this unit of work.
IBMSNAP_COMMITSEQ The log record sequence number of the captured commit
statement.
IBMSNAP_AUTHTKN The authorization token associated with the transaction.
This ID is useful for database auditing. For DB2 Universal
Database for OS/390, this column is the correlation ID. For
DB2 Universal Database for AS/400, this column is the job
name of the job that caused a transaction. This column is
not automatically copied to other tables; you must select it
and copy it as a user data column. This column can be
selected as a user data column for a noncomplete CCD
target table.
IBMSNAP_AUTHID The authorization ID associated with the transaction. It is
useful for database auditing. AUTHID length is 18
characters. If you supply a longer value, it is truncated. For
DB2 Universal Database for OS/390, this column is the
primary authorization ID. For DB2 Universal Database for
AS/400, this column has the name of the user profile ID
under which the application that caused the transaction
ran. This column holds a 10-character ID padded with
blanks. This column is not automatically copied to other
tables; you must select it and copy it as a user data column.
This column can be selected as a user data column for a
noncomplete CCD target table.

Unit-of-work table
Table 50. Columns in the UOW table (continued)

IBMSNAP_REJ_CODE This value is set only during update-anywhere replication if
conflict detection is specified as standard or advanced
when you define your replication source.
0 A transaction with no known conflict.
1 A transaction that contains a conflict where the
same row in the source and replica tables have a
change that was not replicated. When a conflict
occurs, the transaction will be reversed at the
replica table.
2 A cascade-rejection of a transaction dependent on a
prior transaction having at least one same-row
conflict. When a conflict occurs, the transaction
will be reversed at the replica table.
3 A transaction that contains at least one
referential-integrity constraint violation. Because
this transaction violates the referential constraints
defined on the source table, the Apply program
will mark this subscription set as failed. Updates
cannot be copied until the referential integrity
definitions are corrected.
4 A cascade-rejection of a transaction dependent on a
prior transaction having at least one constraint
conflict.
IBMSNAP_APPLY_QUAL This column prevents circular replication during

update-anywhere processing. It remains blank for local
updates, but contains the name of the associated Apply
program for updates that are made by the Apply program
for an update-anywhere subscription set. The Capture
program derives this value from the critical section table.
Change data table

CD
Change data (CD) tables record all changes made to a replication source.
Committed, uncommitted, and incomplete changes are inserted as rows into
the CD table. The CD table works with the UOW table to provide commit
information. (See “Staging data” on page 82 for more information.) Pruning of

Change data table
the CD table rows is coordinated by the pruning control table. (See “Pruning
control table” on page 309 for more information.)
CD tables are automatically created when you define a replication source. For
each replication source that is enabled for data capture, there is one CD table.
If you cold start the Capture program, all of the CD table’s entries are deleted.
Manually changing the CD table is not recommended. However, the CD table

can be a useful resource for problem determination. Knowing exactly what
changes were committed or not committed can help you understand where
the Capture program failed.
Recommendation: A unique ascending index is strongly recommended for the

IBMSNAP_UOWID and IBMSNAP_INTENTSEQ columns.
Table 51 provides a list and a brief description of each of the columns in the
CD table.
Table 51. Columns in the CD table
IBMSNAP_UOWID Unit-of-work ID for an update. The Apply program uses
this column to join the CD table with the UOW table so
that only committed changes are replicated.
IBMSNAP_INTENTSEQ Log or journal record sequence number that uniquely
identifies a change. This value is globally ascending.
IBMSNAP_OPERATION Character value of I, U, or D, indicating an insert, update,
or delete record.
DATA1 User column from source table specified when the
replication source was defined.
AFTER-IMAGE User column from source table selected when defining a
replication source. This column will have the same name,
data type, and null attributes as the source column. The
after-image column also contains the equivalent source
table column value after the change is made.
BEFORE-IMAGE User column from source table selected when defining a
replication source. This column will have the same name,
data type, and null attributes as the source column. The
name is the source column prefixed with the
BEFORE_IMG_PREFIX value from the register table. This
column contains the equivalent source table column value
before the change was made.

Tables used at the control server
The control server is the DB2 system that you chose to hold your subscription
definitions. The following section provides a brief description of the tables
used at the control server and the columns in each table. If you are using the
Control Center, these tables, which contain information about your
subscription definitions, are automatically created when you define a
subscription set if they do not already exist.
The subscription set, subscription-targets-member, subscription columns,

subscription statements, row-replica, and subscription-schema-changes tables
contain information about subscriptions. When a new subscription set is
defined, the administration tools simultaneously update rows in the
subscription set, subscription columns, subscription-targets-member, and
subscription statements tables.
The subscription events and Apply trail tables are used by the Apply program
to control and audit your data.
Subscription set table
ASN.IBMSNAP_SUBS_SET
The subscription set table lists all of the subscription sets defined at the
control server and identifies the source and target server pairs that are
processed as a group. Rows are inserted into this table when you create your
subscription set definition.
Use this table to identify subscription sets that are defined.
Table 52 provides a brief description of the columns in the subscription set

table.
Table 52. Columns in the subscription set table
APPLY_QUAL Uniquely identifies a group of subscription sets that are
processed by the same Apply process. This user-specified
value must be unique for the control server where the
subscription set table is located. For update-anywhere, this
value must be unique at the control server and at the
source server. This value is case-sensitive. You must specify
this value when you define a subscription set. See
“Defining replication subscription sets” on page 112 for
more details.

Table 52. Columns in the subscription set table (continued)

SET_NAME Identifies a group of source and target tables
(subscription-set members) that are processed by the Apply
program as a group. This user-specified value must be
unique within an Apply qualifier. Changes for subscription
members in a set are processed in a single transaction
during the Apply processing cycle.
WHOS_ON_FIRST The following values are used to control the order of
processing in update-anywhere replication scenarios.
F (first) The target table is the user table or parent
replica. The source table is the dependent
row-replica and, in the case of update conflicts
between the source table and the target table, the
source table will have its conflicting transactions
rejected. F is not used for read-only subscriptions.
S (second) The source table is the user table, parent
replica, or other source. The target table is the
dependent row-replica or other copy and, in the
case of update conflicts between the source table
and the target table, the target table will have its
conflicting transactions rejected. S is used for all
read-only subscriptions.
ACTIVATE The following values are flags set by either the

administration tool (0 and 1) or by the Apply program (2).
0 The subscription set is deactivated.
1 The subscription set is active indefinitely.
2 The subscription set is used for a one-time-only
subscription execution.
SOURCE_SERVER The database name of the source server where the source
tables and views are defined.
SOURCE_ALIAS The DB2 Universal Database alias corresponding to the
source server named in the SOURCE_SERVER column.
TARGET_SERVER The database name of the server where the target tables
and views are defined.
TARGET_ALIAS The DB2 Universal Database alias corresponding to the
target server named in the TARGET_SERVER column.


STATUS A value that represents in-progress and completed work
status for the Apply program.
-1 A failed execution.
0 A successful subscription definition.
1 A pending or in-progress execution. Do not modify
this definition or any rows related to this
subscription set in other control tables.
2 A continuing execution of a single logical
subscription set that was divided according to the
MAX_SYNCH_MINUTES control column and is
being serviced by multiple subscription cycles. Do
not modify this row or any row related to this
LASTRUN The estimated time that the last subscription set began. The
Apply program sets the LASTRUN value each time a
subscription set is processed. It is the approximate time at
the control server that the Apply program begins
processing the subscription set.
REFRESH_TIMING Sets the timing between statement executions.
R The Apply program uses the value in
SLEEP_MINUTES to determine replication timing.
E The Apply program checks the time value in the
subscription events table to determine replication
timing. Before any replication (change capture or
full refresh) can begin, an event must occur.
B Indicates that a subscription set has both relative
and event timing specifications. Therefore, this
subscription set can be eligible for a refresh based
on either the timer or event timing criteria.
SLEEP_MINUTES Specifies the time (in minutes), of inactivity between

subscription set processing when REFRESH_TIMING is R
or B.
EVENT_NAME A unique character string used to represent an event. Use
this identifier to update the subscription events table when
you want to trigger replication for a subscription set.
LASTSUCCESS The control server timestamp for the beginning of the last
successful processing of a subscription set.


SYNCHPOINT The Apply program uses the SYNCHPOINT value from the
global row of the register table at the source server if
GLOBAL_RECORD is Y. If data blocking is specified in the
subscription-set definition, then the SYNCHPOINT value is
the log or journal record sequence number of the last
change applied during the Apply process.
SYNCHTIME The Capture program or an external program, such as IMS

ensure that the Capture program captured all outstanding
MAX_SYNCH_MINUTES A time-threshold limit to regulate the amount of change
data to fetch and apply during a subscription cycle. The
Apply program breaks the subscription set processing into
mini-cycles based on the IBMSNAP_LOGMARKER column
in the UOW or CCD table at the source server and issues a
COMMIT at the target server after each successful
mini-cycle. The limit is automatically recalculated if the
Apply program encounters a resource constraint that makes
the set limit unfeasible. MAX_SYNCH_MINUTES values
that are less than 1 will be treated the same as a
MAX_SYNCH_MINUTES value equal to NULL.
AUX_STMTS The number of SQL statements that you define in the
subscription statement table that can run before or after the
Apply program processes a subscription set.
ARCH_LEVEL The architectural level of the definition contained in the
row. This field identifies the rules under which a row was
created. This level is defined by IBM, and for Version 7 is
0201.
Subscription-targets-member table
ASN.IBMSNAP_SUBS_MEMBR
This table or view contains information about the individual source and target
table pairs defined for a subscription set. Rows are automatically inserted into
this table when you create a subscription set member.

Use this table or view to identify a specific source and target table pair within
a subscription set.

subscription-targets-member table.
Table 53. Columns in the subscription-targets-member table
this value when you define a subscription set.
SET_NAME Identifies a group of source or target table pairs
members in a set are processed in a single transaction
during the Apply processing cycle.


Table 53. Columns in the subscription-targets-member table (continued)

TARGET_CONDENSED A flag indicating:
Y For any given primary key, the target table shows
only one row.
N All changes must remain, retaining a complete
update history.
A The target table is a base aggregate or change
aggregate tables.
TARGET_COMPLETE A flag indicating:

Y The target table contains a row for every primary
N The target table contains some subset of rows of
primary key values.
TARGET_STRUCTURE The structure of the target table:

1 User table
3 CCD table
7 Replica
8 User copy
9 Row-replica (Microsoft Jet specific)

Table 53. Columns in the subscription-targets-member table (continued)

PREDICATES Lists the predicates to be placed in a WHERE clause for the
table in the TARGET_TABLE column. This WHERE clause
creates a row subset of the source table. Predicates are
recognized only when WHOS_ON_FIRST is set to S. The
letter A is a predefined correlation-name for the physical
source table used in a correlated subquery. Cannot contain
an ORDER BY clause because the Apply program cannot
generate an ORDER BY clause. Aggregate tables require a
dummy predicate followed by a GROUP BY clause as a
predicate.
Subscription columns table

ASN.IBMSNAP_SUBS_COLS
This table contains information about the columns of the subscription-set

members being copied in a subscription set. The subscription columns table
contains supplemental information to the subscription-targets-member table.
Rows are automatically inserted or deleted from this table when information
contained in one or more columns of a source and target table pair is
changed.
Use this table if you need information about specific columns in a

subscription-set member.
Table 54 provides a brief description of the columns in the subscription

columns table.
Table 54. Columns in the subscription columns table
APPLY_QUAL Identifies the Apply program for the platform instance that
will run this subscription set. The value must be unique
among all Apply processes maintaining dependent replicas
of a user table or parent replica, and unique among all
Apply processes sharing a common set of control tables.
This value is case sensitive. You must specify this value
when you define a subscription set.
SET_NAME Names a subscription set. This value is unique within an
Apply qualifier.

Table 54. Columns in the subscription columns table (continued)


COL_TYPE A flag indicating:
A For an after-image column.
B For a before-image column.
C For a computed column without an
SQL-column-function reference.
D A DATALINK value or DATALINK indicator
column.
F For a computed column with an
SQL-column-function reference.
L A large object (LOB) column.
R Signifies a relative record number column,
provided by the system and used as a primary key
column. Used only by DB2 DataPropagator for
AS/400.
TARGET_NAME The name of the target table or view column. It does not
need to match the source column name.
Internal CCD column names cannot be renamed. They must

match the CD table column names.

Table 54. Columns in the subscription columns table (continued)

IS_KEY
Y The column is all or part of the primary key of the
target (all condensed copies must have primary
keys).
N The column is not part of a key of the target.
COLNO The numeric location of the column in the original source,

to be preserved relative to other user columns in displays
and subscriptions.
EXPRESSION The source column name or an SQL expression representing
the target column.
Subscription statements table

inappropriately can cause unexpected results and loss of data. The number of
entries for a subscription should be reflected in
ASN.IBMSNAP_SUBS_SET.AUX_STMTS. If AUX_SMTS is zero for a
subscription set, the corresponding entries in the subscription statements table
are ignored by the Apply program.
ASN.IBMSNAP_SUBS_STMTS
This table contains the user-defined SQL statements or stored procedure calls
that will be executed before or after each subscription-set processing cycle.
Execute immediately (EI) statements or stored procedures can be executed at
the source or target server only. This table is populated when you define a
subscription set that uses SQL statements or stored procedure calls.
Table 55 provides a brief description of the columns in the subscription

statements table.
Table 55. Columns in the subscription statements table

Table 55. Columns in the subscription statements table (continued)

SET_NAME Identifies a group of source and target table pairs
unique within an Apply qualifier. Changes for
subscription-set members in a set are processed in a single
transaction during the Apply processing cycle.
BEFORE_OR_AFTER A value indicating:

A The statement is executed at the target server after
all of the answer-set rows are applied.
B The statement is executed at the target server
before any of the answer-set rows are applied.
S The statement is executed at the source server
before opening the answer-set cursors.
G The statement is executed at the source server
before opening any cursors to either fetch
answer-set rows or fetch replication source details.
STMT_NUMBER Defines the relative order of execution within the scope of

BEFORE_OR_AFTER.

Table 55. Columns in the subscription statements table (continued)

EI_OR_CALL A value indicating:
E The SQL statement should be run as an EXEC SQL
EXECUTE IMMEDIATE.
C The SQL statement contains a stored procedure
name to run as an EXEC SQL CALL.
SQL_STMT One of the following values:

Statement
The SQL statement should run as an EXEC SQL
EXECUTE IMMEDIATE statement if EI_OR_CALL
is E.
Procedure
The 8-byte name of an SQL-stored procedure,
without parameters or the CALL keyword, that
runs as an EXEC SQL CALL statement if
EI_OR_CALL is C.
ACCEPT_SQLSTATES One to ten 5-byte SQLSTATE values that you specified

when you defined the subscription set. These non-zero
values are accepted by the Apply program as a successful
execution. Any other values will cause a failed execution.
Row-replica-target-list table (Microsoft Jet specific)

ASN.IBMSNAP_SUBS_TGTS
This table is necessary to identify when a member has been deleted from a
subscription set for a Microsoft Jet database target, so that the row-replica
table can be deleted from the Microsoft Jet database. The
row-replica-target-list table allows DataPropagator for Microsoft Jet to
maintain a list of known row-replica tables in a stable DB2 or DataJoiner
database. DataPropagator for Microsoft Jet uses this information during
schema analysis to determine if any row-replica tables should be deleted
because the corresponding subscription-set member was dropped since the
last synchronization.
Table 56 on page 334 provides a brief description of the columns in the

row-replica-target-list table.

Row-replica-target-list table
Table 56. Columns in the row-replica-target-list table

unique within an Apply qualifier.

LAST_POSTED This column is the timestamp of when this row was
inserted into the table. This column is for informational
purposes only.
Subscription-schema-changes table (Microsoft Jet specific)

ASN.IBMSNAP_SCHEMA_CHG
This table allows DataPropagator for Microsoft Jet to determine if some

relevant schema change has occurred since its last synchronization. If a
modification is made, DataPropagator for Microsoft Jet will drive a thorough

analysis of the replication control information. DataPropagator for Microsoft

Jet will then create or drop row-replica tables, or columns in row-replica
tables, to automatically converge the Microsoft Jet database schema with the
schema described by the replication control information. This schema
convergence occurs before data synchronization, so that new columns and
new tables are copied.

subscription-schema-changes table.
Table 57. Columns in the subscription-schema-changes table
members in a set are processed in a single transaction at the
target site during the Apply processing cycle.
LAST_CHANGED This column is the timestamp of when this row was last
changed in this table. This column is for informational
purposes only.
Subscription events table

This table contains information that you update using SQL.
ASN.IBMSNAP_SUBS_EVENT
This table contains information about the event triggers that are copied in a
subscription set. The subscription events table contains event names and
timestamps associated with the event names. You insert a row into this table
when you create a new event to start an Apply process. See “Event timing” on
page 124.
Table 58 on page 336 provides a brief description of the columns in the

subscription events table.

Subscription events table
Table 58. Columns in the subscription events table

EVENT_NAME When you replicate events between systems, this column
contains a globally unique character string in a global name
space configuration. Otherwise, this column contains a
control server unique character string.
EVENT_TIME A control server timestamp of a current or future posting
time. User applications signalling replication events provide
the values in this column.
END_OF_PERIOD A source server timestamp value that acts like an upper
boundary. Any transactions that are committed after this
period are not replicated until a later event is posted.
The only way to prevent eligible change data from

replicating during a subscription cycle is to make sure that
the value in this column is less than the CURRENT
TIMESTAMP value at the source server.
A unique index on EVENT_NAME and EVENT_TIME is created automatically

by the administration tool or by the DPCNTL file.
Apply trail table
ASN.IBMSNAP_APPLYTRAIL
The Apply trail table contains audit trail information for the Apply program.
This table records a history of updates performed against subscriptions. It is a
repository of diagnostic and performance statistics. The Apply trail table is
one of the best places to look if a problem occurs with the Apply program.
Because this table is not automatically pruned, it is up to you to do so.
Table 59 provides a brief description of the columns in the Apply trail table.
Table 59. Columns in the Apply trail table

Apply trail table
Table 59. Columns in the Apply trail table (continued)

members in a set are processed in a single transaction at the
target site during the Apply program processing cycle.
ASNLOAD Contains one of the following values:

Y Indicates that the Apply program was started and
that the LOADXit parameter and the ASNLOAD
exit routine were called to perform a full refresh
on a subscription set.
N Indicates that the ASNLOAD exit routine was not
called because either a full refresh was not needed
or the Apply program was not started with the
LOADXit parameter.
NULL Indicates that an Apply program error occurred
before the Apply program could determine
whether the ASNLOAD exit routine should be
called.

Apply trail table

MASS_DELETE A mass delete is always triggered during a full refresh. The
following are values for this column:
Y Indicates that a full refresh was done for a
subscription set.
N Indicates that a full refresh was not done for a
subscription set.
NULL Indicates that an error occurred before the Apply
program could determine whether or not a full
refresh was needed.
EFFECTIVE_MEMBERS The number of subscription-set members that are changed

during an Apply cycle, either by a full refresh or by the
replication of inserts, updates, and deletes. This number
ranges between zero and the number of defined
subscription-set members.
SET_INSERTED The total number of rows inserted into subscription-set
members during the subscription cycle.
SET_DELETED The total number of rows deleted from subscription-set
SET_UPDATED The total number of rows updated in subscription-set
SET_REWORKED The Apply program reworks changes under the following
conditions:
v If an insert fails because the row already exists in the
target table, the Apply program converts the insert to an
update of the existing row.
v If the update fails because the row does not exist in the
target table, the Apply program converts the update to
an insert.
SET_REJECTED_TRXS The total number of transactions rejected due to an
update-anywhere conflict. This column is used only for
update-anywhere subscription sets where conflict detection
is defined as standard or advanced.

Apply trail table

STATUS A value that represents in-progress and completed work
status for the Apply program.
-1 A failed execution.
0 A successful subscription definition.
1 A pending or in-progress execution. Do not modify
this definition or any rows related to this
2 A continuing execution of a single logical
subscription that was divided according to the
MAX_SYNCH_MINUTES control column and is
being serviced by multiple subscription cycles. Do
not modify this row or any row related to this
LASTRUN The estimated time that the last subscription began. The
Apply program sets the LASTRUN value each time a
subscription set is processed. It is the approximate time at
the control server that the Apply program begins
processing the subscription set.
LASTSUCCESS The control server timestamp for the beginning of the last
successful processing of a subscription set.
SYNCHPOINT The Apply program uses the SYNCHPOINT value from the
global row of the register table at the source server if
GLOBAL_RECORD is Y. If data blocking is specified in the
subscription definition, then the SYNCHPOINT value is the
log or journal record sequence number of the last change
applied during the Apply process.
SYNCHTIME The Capture program or an external program, such as IMS

ensure that the Capture program has captured all
outstanding changes for a replication source table.
SOURCE_SERVER The database name of DB2 for OS/390, DB2 for VSE, and
DB2 for VM where the source tables and views are defined.
SOURCE_ALIAS The DB2 Universal Database alias corresponding to the
source server named in the SOURCE_SERVER column.

Apply trail table

TARGET_SERVER The database name of the target server where the target
tables and views are defined.
TARGET_ALIAS The DB2 Universal Database alias corresponding to the
target server named in the TARGET_SERVER column.
SQLSTATE The SQL state code for a failed execution. Otherwise,
NULL.
SQLCODE The SQL error code for a failed execution. Otherwise,
NULL.
SQLERRP The database product identifier of the server where an SQL
error occurred that caused a failed execution. Otherwise,
NULL.
SQLERRM The SQL error information for a failed execution.
Otherwise, NULL.
APPERRM The Apply error message ID and text for a failed execution.
Refer to “Chapter 15. Capture and Apply messages” on
page 353 and “Chapter 16. Replication messages for
AS/400” on page 381 for detailed message information.
Otherwise, NULL.
Apply job table (AS/400 specific)

IBMSNAP_APPLY_JOB
This AS/400-specific table is used to guarantee a unique APPLY_QUAL value

for all instances of the Apply program running at the control server. A row is
added to this table every time an instance of the Apply program is started. If
you start a new instance of the Apply program with an APPLY_QUAL value
that already exists, the start command fails.

Apply job table
Table 60 provides a brief description of the columns in the Apply job table.
Table 60. Columns in the Apply job table
value is supplied by the user when defining a subscription
set. Each instance of the Apply program is started with an
APPLY_QUAL. This value is used during update-anywhere
replication to prevent circular replication of the changes
made by the Apply program. See the subscription set table
on page “Subscription set table” on page 323 for more
details.
CONTROL_SERVER Name of the database where the control tables and view are
defined.
USER_NAME Name of the user who started a new instance of the Apply
program
JOB_NAME The fully qualified name of the job that wrote this trace
entry:
v position 1-10: APPLY_QUAL, truncated to 10 characters if
necessary
v position 11-20: The ID of the user who started the Apply
program
v position 21-26: The job number
JOB_NUMBER The job number of the current job for a particular journal. If
the journal is not active, this column contains the job
number of the last job that was processed.
Tables used at the target server

The following section provides a brief description of the types of target tables
used at the target server and the columns in each table.
User copy table
Important: If you use SQL to update this table, you run the risk of losing
your updates when a full refresh is performed by the Apply program.
userid.target_table
The user copy table is identical to the point-in-time target table with the
exception of the IBMSNAP_LOGMARKER column, which is not included in
the user copy table.
Except for subsetting and data enhancement, a user copy table reflects a valid
state of the source table, but not necessarily the most current state. References

User copy table
to user copy tables (or any other type of target table) reduce the risk of
contention problems that results from a high volume of direct access to the
source tables. Accessing local user copy tables is much faster than using the
network to access remote source tables for each query.
Table 61 provides a brief description of the columns in the user copy table.
Table 61. Columns in the user copy table
user key columns The primary key of the target table, although it is not
necessarily a component of the primary key of the source
table. You can use predicates to prevent a NULL value from
being assigned to the key fields of any copies.
user nonkey columns The nonkey data columns from the source table or view.
The columns from the source table do not need to match
these columns, but the data types must match.
user computed columns User-defined columns that are derived from SQL
expressions. You can use computed columns with SQL
functions to convert source data types to different target
data types.
Point-in-time table
Important: If you use SQL to update this table, you run the risk of losing
your updates when a full refresh is performed by the Apply program.
userid.target_table
The point-in-time table is similar to the user copy table, but contains an
additional system column (IBMSNAP_LOGMARKER) containing the
approximate timestamp of when the particular row was inserted or updated
at the source system. Otherwise, a point-in-time table is much like a past
image of the source table. Point-in-time copies reflect a valid state of the
source table, but not necessarily the most current state.
Table 62 provides a brief description of the columns in the point-in-time table.

Table 62. Columns in the point-in-time table

Point-in-time table
Table 62. Columns in the point-in-time table (continued)

user nonkey columns The nonkey data columns from the source table or view.
The columns from the source table do not need to match
these columns, but the data types must match.
data types.
IBMSNAP_LOGMARKER The approximate commit time at the source server. This
column is NULL following a full refresh.
Consistent-change-data table
userid.target_table
CCD tables are staging tables that contain committed change data (for details,
see “Staging data” on page 82). Maintaining CCD tables requires updating the
CCD_OLD_SYNCHPOINT and SYNCHPOINT columns of the register table.
The CCD table can be:

v A staging table maintained by one Apply program
The result of a join between the CD and UOW tables can be stored here, so
that you perform the join step only once for replicating changes to multiple
targets. The CCD table can be maintained on a remote system. The
advantage of maintaining your CCD table remotely is that you reduce the
work load on your source. You replicate a set of changes from the original
source to the CCD table only once. The CCD table then acts as the source
and maintains all changes.
v External source table for nonrelational and multivendor data
External programs can create CCD tables to be used by DB2
DataPropagator as replication sources. An example is IMS DataPropagator,
which captures IMS changes and maintains a CCD table so that copies of
IMS data can be recreated in a relational database.
For CCD tables:

v The Capture program does not insert data into CCD tables and does not
prune them. Instead, your application requirements should determine the
history retention period for CCD tables (described in “Staging data” on
page 82 ). Therefore, pruning of CCD tables is not automatic by default, but
can be easily automated using an SQL statement to be processed after the
subscription cycle.

v For condensed CCD tables, a unique index is required for user-data

primary-key columns to maintain the CCD table.
v An internal CCD table is an alternate source for the original user table. The
user table does not include computed columns; therefore, computed
columns should not be included in the CCD subscriptions.
v If an external program, other than the Apply program, maintains the
external CCD table, the external program must initialize, maintain, and
supply the correct values for the control columns.
v Before-image user data columns must be nullable and therefore cannot be
part of a primary key for a condensed CCD table.
v Null attributes of the after-image user data columns should match the null
attributes of the source.
v Views of change data tables can be included in view replication sources.
v Views that are defined as replication sources can refer only to CCD tables
that are complete and condensed.
The originally captured operation code in the IBMSNAP_OPERATION column

and the sequence numbers IBMSNAP_INTENTSEQ and
IBMSNAP_COMMITSEQ are included in CCD tables. For condensed CCD
tables, only the latest values are kept for each row.
Special cases for condensed CCD tables
Because condensed CCD tables must have a unique index:

v Inserts to a row with a key that already exists will fail. The insert becomes
an update.
v Updates to rows that do not exist will fail. The update becomes an insert.
v A delete is always handled as an update and the row remains in the CCD
table.
Table 63 provides a brief description of the columns in the CCD table.

Table 63. Columns in the CCD table
IBMSNAP_INTENTSEQ Log or journal record sequence number that uniquely
identifies a change. This value is globally ascending.
IBMSNAP_OPERATION Character value of I, U, or D, indicating an insert, update,
or delete record.
IBMSNAP_COMMITSEQ The log record sequence number of the captured commit
statement. This value groups inserts, updates, and deletes
by the original transactions for the source table.

Table 63. Columns in the CCD table (continued)

user nonkey columns The nonkey data columns from the source table. The
columns from the source table do not need to match these
columns, but the data types must match.
data types.
Replica table
userid.target_table
The replica must have the same primary key as the source table. Because of
these similarities, the replica table can be used as a source table for further
subscription sets, making the target server a source server as well. Converting
a target table into a source table is done automatically when you define a
replica target type and specify the CHANGE DATA CAPTURE attribute. See
“Defining subscription sets for update-anywhere replication” on page 114 for
more information.
Table 64 provides a brief description of the columns in the replica table.

Table 64. Columns in the replica table
Base aggregate table

userid.target_table

Base aggregate table
Base aggregate tables are target tables that contain data aggregated from a
source table. Functions are performed on data located at the source table, and
the result of the function is inserted as a row in the base aggregate table.
For base aggregate tables:

v Before-image user data columns must be nullable.
v If the computation will never generate a null value, then the computed
columns should be NOT NULL.
v Null attributes of the after-image user data columns should match null
attributes of the source, except for primary key columns, which should
always be NOT NULL.
Table 65 provides a brief description of the columns in the base aggregate

table.
Table 65. Columns in the base aggregate table
user columns Columns computed from the source table.
IBMSNAP_LLOGMARKER The current source server timestamp when the data
was last aggregated.
IBMSNAP_HLOGMARKER The current source server timestamp when the data
was last aggregated.
Change aggregate table

userid.target_table
A change aggregate table is a target table that contains data aggregations

based on changes from a source table. This table is similar to the base
aggregate table, except that the functions being performed at the source table
are done only for changes that occur during a specific time interval. The
results of these functions are inserted as rows into the change aggregate table.
Before-image user data columns must be nullable in change aggregate tables.
Table 66 on page 347 provides a brief description of the columns in the change
aggregate table.

Change aggregate table
Table 66. Columns in the change aggregate table

table. You can use predicates to prevent a NULL value
from being assigned to the key fields of any copies.
functions to covert source data types to different target
data types.
IBMSNAP_LLOGMARKER The oldest IBMSNAP_LOGMARKER or
IBMSNAP_LLOGMARKER value present in the
(CD+UOW) or CCD table rows being aggregated.
IBMSNAP_HLOGMARKER The newest IBMSNAP_LOGMARKER or
IBMSNAP_HLOGMARKER value present in the
(CD+UOW) or CCD table rows being aggregated.
Row-replica table (Microsoft Jet specific)

Important:This table contains information that you can update by using SQL.
userid.target_table
This table is an update-anywhere replica table maintained by DataPropagator

for Microsoft Jet. Conflicts are detected row by row, not transaction by
transaction, as they are for replica tables. Row-replica is the only type of
target table supported by DataPropagator for Microsoft Jet. The source table
can be a DB2, Oracle, Sybase, Informix, or Microsoft SQL Server user table, or
a DB2 replica. The source can also be a view of a DB2 user table or replica
table, including a join view.
Table 67 provides a brief description of the columns in the row-replica table.

Table 67. Columns in the row-replica table

Row-replica table
Conflict table (Microsoft Jet specific)

IBMSNAP_<target name>_CONFLICT
This table is a conflict table for tracking synchronization conflicts and errors.
This Microsoft Jet database control table mimics Microsoft’s conflict tables.
This table contains the conflict loser’s row data. The columns are the same as
the corresponding row-replica table. This table can have more than one row.
The conflict table is created along with the row-replica table in the Microsoft
Jet database and dropped when the row-replica table is dropped.
Table 68 provides a brief description of the columns in the conflict table.

Table 68. Columns in the conflict table
target name The corresponding row-replica table’s name.
column names of A list of column names found in the corresponding
row-replica row-replica table.
Error information table (Microsoft Jet specific)

IBMSNAP_ERROR_INFO
This table identifies the row-replica table and row that caused the error. This
table can have more than one row. The error information table is created
along with the Microsoft Jet database and never dropped.
Table 69 provides a brief description of the columns in the error information

table.
Table 69. Columns in the error information table
TableName The name of the row-replica table that is the source of the
row that caused the error.
RowGuid The GUID of the row that caused the error.
Operation One of the following commands to identify the operation
that caused the error: INSERT, UPDATE, or DELETE.
Reason The DB2 DataPropagator error message number.

Error information table
Error messages table (Microsoft Jet specific)

IBMSNAP_ERROR_MESSAGE
This table identifies the nature of an error. It contains the error code and error
message. This table can have more than one row. The error messages table is
created along with the Microsoft Jet database and never dropped.
Table 70 provides a brief description of the columns in the error messages

table.
Table 70. Columns in the error messages table
Reason The DB2 DataPropagator error message number.
ReasonText The DB2 DataPropagator error message text.
Error-side-information table (Microsoft Jet specific)

IBMSNAP_SIDE_INFO
This table is a conflict table for tracking synchronization conflicts and errors.
This Microsoft Jet database control table mimics Microsoft’s conflict tables.
This table contains the names of the conflict tables created by DataPropagator
for Microsoft Jet.
Table 71 provides a brief description of the error-side-information table

column.
Table 71. Error-side-information table column
ConflictTableName The conflict table name created by DataPropagator for
Microsoft Jet.
Key string table (Microsoft Jet specific)

IBMSNAP_GUID_KEY

Key string table
This table maps the Microsoft Jet table names and row identifiers to primary
key values when the following changes occur:
v Rows are deleted from Microsoft Jet database tables.
v Deletes are recorded in MSysTombstone with s_Generation, TableGUID, and
s_GUID (row) identifiers, but without primary key details.
v The primary key values are needed to replicate Microsoft Jet database
deletes to an RDBMS.
When DataPropagator for Microsoft Jet replicates delete actions to another
Microsoft Jet database, only the internal row identifier is sent. To replicate
delete actions outside of the Microsoft Jet environment, DataPropagator for
Microsoft Jet needs to replicate a searched delete, with predicates referencing
primary key values. The key string table allows DataPropagator for Microsoft
Jet to maintain the key values needed to replicate a delete to an RDBMS, even
after the row is physically deleted from the row-replica table.
Table 72 provides a brief description of the columns in the key string table.
Table 72. Columns in the key string table
RowReplicaname Identifies the row-replica table where the row was inserted.
s_GUID Identifies the row in the specific row-replica table.
key_string The string of ″and-ed″ DB2 SQL predicates identifying the
key columns and their row values, with character constants
delimited by single quotation marks. The column names are
taken from the row-replica definition and can contain
uppercase letters, lowercase letters or both. The constant
values are taken from the rows themselves and the string
values can contain uppercase letters, lowercase letters,
numeric characters, or any combination of the three.
Microsoft Jet database supports ASCII, so the string
constants can contain single- or double-byte characters. For
example:
COL1=(character) AND COL2=(character)
Synchronization generations table (Microsoft Jet specific)

IBMSNAP_S_GENERATION
This table is used to prevent cyclic updates from replicating back to the
RDBMS from a Microsoft Jet database. When DB2 is the target, this function is
accomplished in a different way, using the APPLY_QUAL column of the

critical section table, which results in the Capture Program posting to the
APPLY_QUAL column of the UOW table.
The s_GENERATION column is maintained by Microsoft Jet and set to the

same generation number as any other updates made since the last
synchronization. If synchronization is successful, the synchronization
generations table will contain one row whose Update_Type value is F.
Due to the risk of partial failures during a DataPropagator for Microsoft Jet
synchronization cycle, and because the WHOS_ON_FIRST = S flow is handled
before the WHOS_ON_FIRST = F flow, multiple RDBMS-to-Jet generations can
be posted before any Microsoft Jet database changes replicate to the RDBMS.
In such a case, there is the possibility that a list of s_GENERATION values
will need to be skipped over when determining which s_GENERATION of
changes needs to be replicated to the RDBMS.
Table 73 provides a brief description of the columns in the synchronization

generations table.
Table 73. Synchronization generations table
Update_Type A value that indicates whether a generation of changes is:
L Local to the Microsoft Jet database
F Foreign
JetSynchtime This is a dummy column, set to the time of a forced

Microsoft Jet database synchronization.


Chapter 15. Capture and Apply messages
This chapter contains a list of the messages issued by DB2 replication for the
Capture and Apply programs on all of the database management systems
except DB2 for AS/400. The messages issued by DB2 replication for AS/400
are located in “Chapter 16. Replication messages for AS/400” on page 381. The
Replication Administration messages (DBA6001-DBA6110) are listed in the
DB2 Message Reference.
The replication messages have the following prefixes:

ASN0 The Capture program. These messages are listed in “Capture program
messages”
ASN1 The Apply program. These messages are listed in “Apply program
messages” on page 368
Unless otherwise stated, all error codes described in error messages are
internal error codes used by IBM Software Support. Also, unless otherwise
stated, error messages are issued with a return code of 8.
You can also obtain explanations for messages by typing the following
command at a DB2 command prompt:
db2 message_number
Capture program messages

When you get a Capture program error, verify that your DB2 maintenance is
at the most current level. The Capture program is an application program that
uses DB2 APIs. Many Capture program errors are due to DB2 maintenance
that is not current.
When you start DB2 with the cold start option, you must also start the
Capture program with the cold start option.
Note: For SQL errors, see the DB2 Message Reference for your platform.

Explanation: An error occurred when the
ASN0000S An internal error occurred for
Capture program issued:
message number “<number>”.
The error code is “<error_code>”. v a CONNECT function to DB2 for VSE & VM
The return code is v a CONNECT function to DB2 Call Attachment
“<return_code>”. Facility (CAF)
Explanation: The message file for the Capture v an implicit connect to DB2 Universal Database.
program was installed incorrectly, or the User Response: See DB2 codes in the messages
language environment variables are not set and codes publication of the DB2 database
correctly. This message is displayed because no manager on your platform for the appropriate
other Capture program message could be reason code.
formatted.
For DB2 for OS/390 errors, see the section in the
User Response: Refer to the installation and administration guide that describes the Call
configuration information in this book pertaining Attachment Facility. Contact your DBA for
to your platform. Make sure that the message file questions and diagnosis.
is installed in the correct directory, and the
language environment variables are set correctly. If you are running Capture under DB2 UDB for
If the language environment variables are set UNIX or under DataJoiner for UNIX, ensure that
correctly, contact IBM Software Support. the LIBPATH environment variable is set to the
same environment in which the Capture program
starts. See “Starting Capture for UNIX platforms”
ASN0001E The Capture program encountered on page 244 for more information.
an SQL error.
Parameters: ASN0003E The Capture program could not
v Routine name is “<name>” open the plan.
v SQL request is “<request>” Parameters:
v table name is “<table_name>” v Routine name is “<routine>”
v SQLCODE is “<sqlcode>” v Return code is “<return_code>”
v SQLERRML is “<sqlerrml>” v Reason code is “<reason_code>”
v SQLERRMC is “<sqlerrmc>” v Subsystem is “<subsystem>”
Explanation: A nonzero SQLCODE was v Plan name is “<ASNLPLAN>”
returned when the Capture program issued an
EXEC SQL statement. Explanation: An error occurred when the
Capture program tried to open the plan,
User Response: See the messages and codes ASNLPLAN.
publication of the DB2 database manager on
your platform for information about SQL return User Response: See the DB2 Codes section in
codes that use SQLERRML and SQLERRMC as the messages and codes publication of the DB2
substitution fields. Contact your DBA for more database manager on your platform to find the
information. appropriate reason code. See the section in the
administration guide that describes the Call
Attachment Facility.
ASN0002E The Capture program could not
connect to DB2.
Parameters: start the trace.
v Routine name is “<routine>” Parameters:
v SQLCODE is “<sqlcode>” v Routine name is “<routine>”

v Return code is “<return_code>” the administration guide publication of the DB2
v Reason code is “<reason_code>” database manager on your platform or contact
your DBA.
Explanation: An error occurred when the
START TRACE DB2 command was issued, or For Capture for VSE, see the VSE/VSAM
when Capture program read the DB2 log. Commands and Macros, VSE/ESA System Macro
Reference, and VSE/ESA V2R3 Messages and Codes
User Response: See the DB2 Codes section of in manuals for more information.
the messages and codes publication of the DB2
database manager on your platform to find the For VM/ESA, see the VM/ESA Programming
appropriate reason code. For more information, Services for more information.
see either of the following sections in the For Capture on UNIX, Windows, and OS/2, see
administration guide: the Call Attachment the active and archived database logs section in
Facility (CAF) for START TRACE DB2 errors, or the DB2 UDB Administration Guide or contact
the Instrumentation Facility Interface (IFI) for IBM Software Support.
DB2 log read errors, or contact your DBA. If the
CAF or the IFI returned a message, it is also
printed on the system display console. ASN0006E The Capture program encountered
an unexpected log error of
unknown log variation. The
ASN0005E The Capture program encountered routine name is “<routine>”.
an error while reading the DB2
log. Explanation: An unexpected log error not
reported by either:
Parameters:
v the Instrumentation Facility Interface (IFI) for
v Routine name is “<routine>” Capture program for OS/390, or
v LSN is “<log_sequence_number>” v the Asynchronous Read Log API for the
v Return code is “<return_code>” Capture program
v Reason code is “<reason_code>” occurred while the Capture program was
Explanation: An error occurred when the processing the DB2 log records. The Capture
Capture program read the DB2 log. There might program could not determine the type of SQL
be an SQL error. update associated with the log record.
For Capture program for OS/390, an MVS For Capture program for OS/390, an MVS
system dump is generated for this message that system dump is generated for this message that
is contained in MVS dump data set SYS1.DUMP. is contained in MVS dump data set SYS1.DUMP.
For DB2 DataPropagator, the “<return_code>” User Response: Contact IBM Software Support.
value is for the Asynchronous Read Log API.
For Capture for VSE, the “<return code>” is for ASN0007E The Capture program encountered
the VSE/VSAM GET macro. an unexpected log error of
For Capture for VM, the “<return code>” is for unimplemented data type. The
Diagnose X’A4’. routine name is “<routine>”.
User Response: See the DB2 Codes section in Explanation: An unexpected log error not
the messages and codes publication of the DB2 reported by either:
database manager on your platform for the v the Instrumentation Facility Interface (IFI) for
appropriate reason code. Capture program for OS/390, or
For Capture program for OS/390, see the v the Asynchronous Read Log API for the
Instrumentation Facility Interface (IFI) section in Capture program
Chapter 15. Capture and Apply messages 355

occurred while the Capture program was
ASN0010E The Capture program cannot
processing the DB2 log records. The Capture
obtain enough storage.
program could not determine the type of SQL
update associated with the log record. Parameters:
v Routine name is “<routine>”
For Capture program for OS/390, an MVS
v Storage required is “<amount>”
system dump is generated for this message that
is contained in MVS dump data set SYS1.DUMP. Explanation: The Capture program cannot
continue processing because not enough free
User Response: Contact IBM Software Support.
storage is available. Usually 2MB is enough
storage.
ASN0008I The Capture program was
User Response: For Capture program for
stopped.
OS/390, ensure that the REGION parameter has
Explanation: The IBM Replication administrator enough storage allocated to run your job. If
stopped the Capture program using one of the necessary, contact your OS/390 system
valid methods. programmer to determine the method for
requesting sufficient storage.
Explanation: This message is for your
information only. For Capture for VM, a request to obtain virtual
storage could not be satisfied. You might need to
User Response: No action is required. increase the size of the virtual machine in which
Capture program runs.
ASN0009E The table was created without the For Capture for VSE, all available GETVIS
DATA CAPTURE CHANGES storage has been exhausted. You might need to
(DCC) attribute. restart the Capture program after allocating a
Parameters: larger partition.
v Routine name is “<routine>” If you believe enough storage has been allocated,
v Table name is “<table_name>” contact IBM Software Support.
Explanation: The source table was defined

without the DCC attribute and the Capture ASN0011E The DB2 compression dictionary
program tried to capture changes for the is not available or the IFCID 306
replication source. buffer is invalid.
User Response: Parameters:

1. Stop the Capture program. v Routine code is “<routine_code>”
2. Delete the replication source. v Reason code is “<reason_code>”
3. Define the replication source again; if you do Explanation: In the case of the DB2
not have the Data capture is full-refresh compression dictionary not being available, the
only check box selected, the DB2 Control Capture program attempted to read log records
Center will alter the source table with the for an old compression dictionary. DB2 for
DCC attribute. OS/390 only retains one version of the
4. Start the Capture program. compression dictionary in memory. DB2 can only
decompress log records for a compressed table if
the compression dictionary used to compress the
log records is still the current compression
dictionary.
In the case of the IFCID 306 buffer not being

valid, the control information is missing from the
ASN0014E The processing of the Capture
buffer.
program has fallen below a
For Capture program for OS/390, an MVS minimum level. The log record
system dump is generated for this message that lags current time by “<number>”
is contained in MVS dump data set SYS1.DUMP. seconds. The routine name is
“<routine>”.
User Response: For the DB2 compression
dictionary error, to avoid an unwanted cold start Explanation: The Capture program terminated
of the Capture program, you must capture all log because a high DB2 transaction rate caused the
records for a compressed table before creating a Capture program to run slower than the defined
new version of the compression dictionary. Use minimum level.
the KEEPDICTIONARY option to retain the
User Response: Refer to the Capture and Apply
current version of the compression dictionary
chapter for your platform for more information
during routine REORG processing.
on the lag limit. Then you can:
When you want a new compression dictionary v Perform a cold start.
for the table, you must synchronize running the
v Alternatively, you can increase the lag limit.
REORG utility with running your updated
applications and the Capture program as follows:
1. Quiesce your updated applications. ASN0015E The Capture program encountered
a storage allocation error.
2. Let the Capture program capture all logged
updates for the compressed table. Parameters:
3. Use the REORG utility on the compressed v Routine name is “<routine>”
table, creating a new compression dictionary. v Storage required is “<amount>”
4. Release your updated applications.
Explanation: A storage allocation error was
For the IFCID 306 buffer error, ensure that all detected; sufficient storage is not available. The
DB2 maintenance is current. Capture program might have been installed
improperly.
If you believe neither of these problems is the
For the Capture program on AIX, you might not
case, contact IBM Software Support. Maintenance
have set the soft links for the component files to
could be the problem.
the shared directory.
User Response: Determine why storage could
ASN0013E The Capture program required a
not be allocated by looking at the operating
column that was not defined in
system and application task status. Contact your
the change data (CD) table.
system programmer to determine the method of
Parameters: requesting the storage listed in the error
v Routine name is “<routine>” message. Also verify that all C libraries are at the
current maintenance level. If you believe enough
v Table name is “<table_name>” storage space has been allocated, contact IBM
Explanation: The user did not define a required Software Support.
column in the change data table. For Capture for AIX, determine whether you
User Response: Ensure that the change data have set the soft links for the component files.
table definition is correct. Refer to “Change data For Capture for VM, a request to obtain virtual
table” on page 321 for more information. storage could not be satisfied. You might need to
increase the size of the virtual machine in which
Capture program runs.

For Capture for VSE, all available GETVIS message should have been issued. See the
storage has been exhausted. You might need to information about the error message in this
restart the Capture program after allocating a chapter to determine how to resolve the error.
larger partition. Consult the installation instructions for your
platform.
For Capture for OS/390 consult the program
directory for instructions and verification of the
appropriate C library level. ASN0018W The Capture program did not
process updates made to the
register table rows. The routine
name is “<routine>”; the table
begin capturing changes because
name is “<table_name>”.
there was no eligible replication
source. Explanation: The user changed a replication
source definition while the Capture program was
Parameters:
running and then issued a REINIT command.
v Routine name is “<routine>” The register table, which contains a row for each
v Table name is “<table_name>” replication source, might not match the other
replication source control tables.
Explanation: The replication source information
in the register table has not been defined. User Response:
The Capture program started but could not find 1. Stop the Capture program.
source tables that were: 2. Delete the replication source.
v Enabled with the DATA CAPTURE CHANGES 3. Redefine the replication source.
option of the CREATE or ALTER TABLE 4. Start the Capture program.
statement.
v Defined as replication sources with the Data
ASN0019E The Capture program libraries are
capture is full-refresh only check box cleared
not authorized for the Authorized
on the Define as Source window.
Program Facility (APF).
User Response: Ensure that the register table is
Explanation: The Capture program cannot
defined properly. For more information about the
process the STOP, SUSPEND, RESUME, or
register table, see “Register table” on page 301.
REINIT commands because the STEPLIB libraries
Verify that replication sources have been defined.
are not authorized for APF.
User Response: Authorize the Capture link
ASN0017E The Capture program encountered
library for APF.
a severe internal error and could
not issue the correct error
message. The routine name is ASN0020I Netview Generic Alerts Interface
“<routine>”; the return code is failure. The Netview return code
“<return_code>”; the error is “<return_code>”.
message number is
Explanation: The Network Major Vector
“<error_message_num>”.
Transport (NMVT) could not be sent to Netview
Explanation: The Capture program could not by the program because the program interface
retrieve the message from the Capture program failed. This is a secondary informational
error messages file. message.
User Response: Edit the Capture program error User Response: See the Netview programming
messages file. Locate the ASNnnnn error documentation for a description of the return
message number to determine which error code to determine the interface error. The

Capture program alerts will not be received by
ASN0025I The Capture program reinitialized
the System Services Control Point (SSCP) until
the register table. Table
the error is corrected.
“<table_name>” has “<number>”
potentially bad row(s).
ASN0021I Netview Program to Program
Explanation: This message accompanies
Interface unavailable. The
ASN0018W. Reinitialization was performed as
Netview return code is
requested despite potential problems reported in
“<return_code>”.
ASN0018W.
Explanation: Netview is unavailable. This is a
User Response: See ASN0018W.
secondary informational message.
User Response: See the Netview programming
ASN0026W The Capture program could not
documentation for a description of the return
allocate the trace buffer. The
code to determine the Netview problem. For
routine name is “<routine>”; the
example, the subsystem might not have been
storage required is
started.
<required_storage>”.
Explanation: A storage allocation error was
ASN0022E DB2 release “<release>” is not
detected; not enough storage is allocated for the
supported. The routine name is
trace buffer. The trace buffer is an
“<routine>”.
information-only feature of the Capture program
Explanation: The Capture program does not and the allocated storage is not required for the
support this release of DB2. Capture program to run.
User Response: Run the Capture program with User Response: Contact your system
the appropriate release of DB2. programmer to determine the method of
requesting the storage listed in the error
message.
ASN0023I The Capture program successfully
reinitialized the register table. For Capture for VM, a request to obtain virtual
The table name is storage could not be satisfied. You might need to
“<table_name>”; the routine name increase the size of the virtual machine in which
is “<routine_name>”. the Capture program runs.
Explanation: A REINIT command was issued For Capture for VSE, all available GETVIS
and the updates were successfully made to the storage has been exhausted. You might need to
Capture program internal control information. restart the Capture program after allocating a
This message is for your information only. larger partition.
User Response: No action is required.

ASN0027W The Capture program is already
active.
ASN0024I The Capture program did not
need to reinitialize the register Explanation: You tried to start more than one
table. Table “<table_name>”did the Capture program per DB2 subsystem or
not change. database.
Explanation: The REINIT command was issued. For VSE/ESA, Capture for VSE generates a
No updates were made to the register table since unique lock name for each database. This lock
initialization or the last REINIT. This message is name is already in use, indicating that Capture
for your information only. for VSE is already active for the database.
User Response: No action is required. For VM/ESA, Capture for VM has determined

that the resource ID used as a lock is already in v SUSPEND
use. The resource ID is specified on the v RESUME
ENQ_NAME parameter of the CAPTURE
v REINIT
ASNPARMS file.
v PRUNE
User Response: For DB2 for OS/390
v GETLSEQ
subsystems, either run only one instance of the
Capture program for all subsystems that are There are no parameters allowed for these
members of a data-sharing group, or run only commands.
one instance of the Capture program on any
stand-alone system. Display the ENQ resource to User Response: Use only valid Capture
determine the unique resource name violation. program commands.
For other DB2 database platforms, run only one

Capture program per database. ASN0031E The Capture program tuning
parameters table can have only
For Capture for VM, you can change the one row. The routine name is
ENQ_NAME parameter in the CAPTURE “<routine>”; the table name is
ASNPARMS to ensure unique values for each “<table_name>”.
Capture program if you want to run Capture for
VM for more than one DB2 database on a Explanation: The tuning parameters table was
system. not defined correctly or has been updated with
invalid rows.
ASN0028I The Capture program is User Response: Refer to “Tuning parameters

suspended by operator command. table” on page 312 to determine the correct
format of this table. Remove any invalid rows.
Explanation: The IBM Replication administrator
suspended the Capture program, and the
program has entered a wait state. This message ASN0033E The Capture program could not
is for your information only. reinitialize the register table. The
table name is ”<table_name>“.
tried to reinitialize the Capture program, but
ASN0029I The Capture program is resumed there was an error in the register table. A user
by operator command. might have tried to update a replication source
while the Capture program was running or
suspended, and the register table might not
resumed the Capture program from a suspended
match the other control tables.
state and the Capture program has continued
running. This message is for your information User Response: This is a secondary message.
only. See any preceding messages for more
information about the error. See the Capture and
Apply chapter for your platform for more
information about reinitializing the Capture
ASN0030I The Capture program command program, and “Register table” on page 301 for
entered by the operator was information about the register table.
unrecognized.
entered a command not recognized by the
Capture program. The only valid commands are:
v STOP

ASN0034E An incorrect value was supplied ASN0037W DB2 was terminated in QUIESCE
for column “<column>”of the mode. The routine name is
Capture program tuning “<routine>”.
parameters table. The routine
Explanation: DB2 was terminated while the
name is “<routine>”; the table
Capture program was still active.
name is “<table_name>”.
User Response: Start DB2 and start the Capture
Explanation: The tuning parameters table does
program.
not have the correct values. Values might be out
of range.
ASN0038E The disconnect to DB2 failed. The
User Response: Check the lag limit, retention
routine name is “<routine>”; the
period, and commit frequency. Refer to “Tuning
return code is “<return_code>”;
parameters table” on page 312, or to the Capture
the reason code is
and Apply chapter for your platform for more
“<reason_code>”.
information.
Explanation: DB2 was stopped in QUIESCE
mode, but the user wanted to leave the Capture
ASN0035W Some rows were found in the
program running. While terminating the
register table with an
connection to DB2, the Capture program received
unsupported architectural level.
an error returned code from the Call Attachment
The routine name is “<routine>”;
Facility (CAF).
the table name is “<table_name>”.
User Response: Restart the Capture program.
Explanation: The register table version does not
match the current version of the Capture
program. The current version of the DB2 Control ASN0040E An error was returned from the
Center is not compatible with the version of the FORK function of “<platform>”.
Capture program that you are running. The error is “<error_text>”.
User Response: Refer to “Register table” on Explanation: An AIX FORK function returned a
page 301 to check the required value for the negative value. “<Error_text>”describes the error.
ARCH_LEVEL column in the register table.
Verify that the value in the register table at the User Response: See AIX Calls and Subroutines
source server is correct. If not, use compatible Reference for information about FORK functions,
versions of the DB2 Control Center and the use the provided error text to determine the
Capture program. error, or contact IBM Software Support.
ASN0036E DB2 was terminated abnormally. ASN0041E An error was returned while
The routine name is “<routine>”. getting the instance name. The
reason code is “<reason_code>”.
Explanation: DB2 was terminated while the
Capture program was still active. Explanation: The SQLEGINS API of DB2
Universal Database returned an error.
For OS/390, VSE/ESA, or VM/ESA, DB2 was
terminated while Capture program was active User Response: See the DB2 Universal Database
and the user did not specify the NOTERM API Reference for information about the
invocation parameter. SQLEGINS API to determine the error, or contact
IBM Software Support.
User Response: Start DB2 and start the Capture
program.

ASN0042E An error was returned from the ASN0046E An error was returned from the
EXECLP function. The error is MSGGET function. The error is
“<error_text>”. “<error_text>”.
Explanation: The AIX EXECLP function Explanation: The function MSGGET returned an
returned a negative value. “<Error_text>” error. “<Error_text>” describes the error. This
describes the error. error occurs during message handling. This error
can be caused by an ASNCMD process failure.
User Response: See the AIX Calls and
Subroutines Reference for information about the User Response: Use the provided error text to
EXECLP function, or contact IBM Software determine the error, or contact IBM Software
Support. Support.
ASN0043E A child process of ASNLMAIN ASN0047E An error was returned from the
died. FTOK function of “<platform>”.
The error is “<error_text>”.
Explanation: The child process created by
ASNLMAIN terminated. Possible causes include: Explanation: The AIX function FTOK returned
v A user stopped the child process. an error. “<Error_text>” describes the error.
v There is an AIX system problem. User Response: See AIX Calls and Subroutines
Reference for information about the FTOK
User Response: Check the system processes for
function, use the provided error text to
conflicts, or contact your AIX system
determine the error, or contact IBM Software
programmer.
Support.
ASN0044E The child process has not called

the dummy process after an
open the log file. The error is
extended wait.
“<error_text>. The error code is
Explanation: The child process was unable to “<error_code>”.
call the dummy routine ASNLPVRF. The
Explanation: The Capture program could not
installation soft links might not have been set.
open the log file. Some possible reasons are:
User Response: Verify whether the installation v The Capture program log file was deleted.
soft links have been set, check the system for
v The user does not have the correct
problems, or contact IBM Software Support.
authorization for the Capture program
directory.
ASN0045E An error was returned from the
User Response: Contact your system
MSGRCV function. The error is
programmer to determine the error, or contact
“<error_text>”.
Explanation: The function MSGRCV returned
an error. “<Error_text>” describes the error. This
error can be caused by ASNCMD sending a
an error while writing to the error
message that ASNCCP could not process.
message file.
User Response: Use the provided error text to
Explanation: An I/O error occurred while
determine the error, or contact IBM Software
writing to the Capture program log file.
Support.
User Response: Check the trace table for error
messages.

and use the DB2 Control Center to define
ASN0053E An error was returned by the
replication sources to ensure that only valid
Asynchronous Read Log API
types are defined. Or, when manually defining
(SQLURLOG).
the replication source, ensure that the table
Parameters: contains only supported SQL types. See the
v Initial LSN is “<log_sequence_number>” messages and codes publication of the DB2
database manager on your platform to determine
v FIRSTRead LSN is “<first_read_LSN>”
the invalid SQLTYPE.
v lastRead LSN is “<last_read_LSN>”
v CurActive LSN is “<currently_active_LSN>”
ASN0056E ASN.IBMSNAP_UOW table does
v log Recswritten is “<log_records_written>” not exist.
v log Byteswritten is “<log_bytes_written>”
Explanation: The unit-of-work (UOW) table or
Explanation: The Asynchronous Read Log API the source server database might have been
returned an SQLCODE in the SQL error message dropped.
that preceded this message. The information in
this message provides additional information
about the SQL error.
ASN0100I The Capture program
User Response: See message ASN0001E for
initialization is successful.
information about SQLCODEs.
information only.
ASN0054E The Capture program did not
recognize the invocation User Response: No action is required.
parameter.
Explanation: An invalid invocation parameter ASN0101W The Capture program warm start
was entered with the ASNCCP command. failed because existing data is too
old; a cold start will be attempted.
User Response: Enter a valid invocation
parameter. Explanation: The data in the change data tables
is older than the value
See the Capture and Apply chapter for your
“<current_timestamp_lag_limit>”. A cold start
platform for information about valid invocation
will be performed.
parameters.
User Response: See “Starting or restarting the
Capture program” on page 140 for more
information about warm and cold starts to
an SQLTYPE that is not supported
determine why the Capture program could not
in the origin table.
warm start.
Parameters:
v Routine Name is “<routine>” ASN0102W The Capture program will switch
v Column Number is “<column_num>” to cold start because the warm
start information is insufficient.
Explanation: The Capture program encountered
an invalid SQL type. A table might have been Explanation: A problem occurred during the
defined as a replication source outside the DB2 retrieval of the warm start information. The
Control Center that contains unsupported SQL warm start table data was invalid. A cold start
types (for example, binary data types with will be performed.
precision).
For DB2 Universal Database, an Asynchronous
User Response: Delete the replication source Read Log API error occurred while reading the

log during warm start. For OS/390, an
ASN0105I Data that has been copied was
Instrumentation Facility Information (IFI) error
pruned from the change data table
occurred while reading the log during warm
and the unit-of-work table.
start.
User Response: See “Starting or restarting the
information only.
Capture program” on page 140 for more
information about warm and cold starts to User Response: No action is required.
determine why the Capture program could not
warm start.
ASN0106I The Capture program is waiting
for DB2 to come up.
ASN0103I The Capture program started
Explanation: When the Capture program is
with: “<server_name>”.
initially brought up, if DB2 is not up at that time,
Parameters: the Capture program waits until DB2 is up. After
v SERVER_NAME is “<server_name>” DB2 is up, the Capture program makes the
connection and begins to capture changes.
v ENQ_NAME is “<enq_name>”
v START_TYPE is “<start_type>” If the NOTERM option is specified in the
Capture invocation parameters, and DB2 comes
v TERM_TYPE is “<term_type>”
down smoothly, the Capture program waits for it
v PRUNE_TYPE is “<prune_type>” to come back up.
Explanation: This is an informational message User Response: No action is required.
that displays the DB2 server name and the
Capture program start up options.
ASN0110E Capture for OS/390 Storage
For Capture for VSE and VM, the ENQ_NAME Dump. The Control Address is
shows the name on which Capture program “<address>”.
locks to make sure that there is only one Capture
program running for any DB2 database. The lock Explanation: An MVS system dump was
name can be specified for VM/ESA by changing generated for a severe error message. The dump
the ENQ_NAME parameter value in the is contained in dump data set SYS1.DUMP. An
CAPTURE ASNPARMS file. IPCS readable system dump contains more
diagnostic information than the Capture program
User Response: No action is required. trace and can be used by IBM to diagnose
system problems.
ASN0104I Change capture started for owner User Response: No action is required.
“<owner>”, the table name is
“<copy_table>” at log sequence
number (LSN) ASN0115I The warm start control
“<log_sequence_number>”. information was not supplied.
The routine name is “<routine>”;
Explanation: The Capture program was started the table name is “<table_name>”.
for the table owner and table name at the
specified log sequence number (LSN). This Explanation: The warm start table is missing or
message is issued for each origin table for which corrupted. This table provides a faster warm
the Capture program captures changes. This start. The Capture program will warm start.
message is for your information only. User Response: No action is required.

WARMNS was specified.
ASN0116I The Capture program did not
reinitialize the tuning parameters
table. The routine name is ASN0123I The highest log sequence number
“<routine>”; the table name is of a successfully captured log
“<table_name>”. record is
“<log_sequence_number>”.
Explanation: The REINIT command was issued,
but tuning parameter information from the Explanation: The Capture program saved the
tuning parameters table was not available. The highest log sequence number (LSN) in the warm
previous tuning parameter values were retained. start table. This is the point at which the Capture
program finished successfully processing the log
data.
User Response: No response required; the
ASN0117W Warm start control information
Capture program will terminate.
was not saved. The routine name
is “<routine>”; the table name is
“<table_name>”. ASN0124I The prune command was
accepted; the pruning action is
Explanation: An error occurred that prevented
queued.
warm start information from being saved in the
warm start table. Warm start will take longer Explanation: The IBM Replication administrator
because other tables will be used. entered the PRUNE command and the Capture
program has queued the request. The Capture
program will prune the change data (CD) table
and the unit-of-work (UOW) table.
ASN0121E The Capture program warm start
User Response: No response required.
failed because existing data is too
old. The Capture program will
terminate. ASN0125I The current log sequence number
of successfully processed log
Explanation: The time of the warm start
records is
information exceeded the lag limit.
“<log_sequence_number>”. The
User Response: No response required; the log timestamp is “<timestamp>”.
Capture program will terminate because
Explanation: Capture program is processing the
WARMNS was specified.
DB2 log at the log sequence number provided.
ASN0122E An error occurred while reading
the warm start information or
DB2 log. The Capture program ASN0126E The Capture program encountered
will terminate. a syntax error. The Capture
program will terminate.
Explanation: A problem occurred while
retrieving the warm start information. The warm Explanation: The Capture program encountered
start table data was invalid or for OS/390, an the wrong combination of invocation parameters.
Instrumentation Facility Interface (IFI) error
occurred while reading the log during warm User Response: Check the Capture and Apply
start. When the error is resolved, you can restart chapter for your platform for more information
using the warm start option. about the START command.
User Response: No response required; the

Capture program will terminate because

DB2 DataPropagator product. No further use of
ASN0130I The user requested that the
the product is possible until you provide the
Capture program start reading
correct registration module.
from the end of the DB2 log.
User Response: Verify that the DB2
Explanation: The user specified the WRMSKPM
DataPropagator feature was installed without
parameter when invoking the Capture program.
errors. If errors occurred, correct them and try
User Response: No action is required. again.
If the DB2 DataPropagator feature installed
ASN0133I The Capture program reached the without error and you are correctly accessing the
end of the mobile transactions. feature-registration module (ASNLPR61), contact
information only.
ASN0138E The product trial module has
unexpected content.
Explanation: The content of the DB2
ASN0135E The trial period for the Capture
DataPropagator trial module is not as expected
program has expired.
for this version of the DB2 DataPropagator
Explanation: The trial period for the DB2 product. No further use of the product is
DataPropagator product has ended. You can no possible until you provide the correct trial
longer use this product until you order and module.
install the DataPropagator licensed feature of
User Response: Verify that the DB2
DB2 for OS/390.
DataPropagator feature was installed without
User Response: Contact the person responsible errors. If errors occurred, correct them and try
for ordering the DB2 DataPropagator product. again.
Note that even though the error message
ASN0017E is also issued, you should not follow
without error and you are correctly accessing it,
the suggested action for that message.
contact IBM Software Support.
ASN0136I The trial version of Capture will

end in nn days.
open the trace file. The error is
Explanation: You are using the trial version of “<error_code>”.
DB2 DataPropagator. After nn days have passed,
Explanation: The user specified the TRCFILE
you will no longer be able to use DB2
option, but the Capture program could not open
DataPropagator unless you install the
the trace file. Possible reasons are:
DataPropagator licensed feature of DB2 for
OS/390. v The directory specified in the ASNPATH
environment variable is incorrect.
User Response: None; however you might want
v The user does not have the correct
to contact the person responsible for ordering the
authorization for the directory.
DB2 DataPropagator product.
User Response: Contact your system
programmer, or IBM Software Support.
ASN0137E The product registration module
has unexpected content.
Explanation: The content of the registration
module (ASNLPR61) for the DB2 DataPropagator
feature is not as expected for this version of the

– The virtual machine in which the
ASN0200E An incorrect parameter
application is running does not have
“<parameter>” was passed to the
authority to connect to *IDENT.
Capture program.
– The virtual machine in which the
Explanation: For VM/ESA, one of the following application is running does not have the
situations caused an error: authority to declare the resource.
v An incorrect parameter was specified on the
On VSE:
ASNCCP command.
v For the GENCB, MODCB, OPEN, GET,
v The CAPTURE ASNPARMS file contained an
CLOSE, or ENDREQ function errors, the
invalid parameter.
Capture program encountered an error while
v An invalid parameter was specified on the trying to set up or read the database log or
:RESID tag in the RESID NAMES file for the directory.
:DBNAME. For example, the RESID could be
v For the GETVIS, FREEVIS, or XPCC function
too long.
errors, the Capture program encountered an
For VSE/ESA, an invalid parameter was error while trying to perform one of these
specified on the ASNCCP command. functions.
User Response: Verify that the parameters User Response: Correct the error as described
supplied are valid. See the Capture and Apply in the platform documentation. On VM:
chapter for your platform for more information v For the LINK function, see VM/ESA CP
about the ASNCCP command. Command and Utility Reference for more
information about the return code.
ASN0201E The Capture program encountered v For the FSREAD, FSPOINT, or FSTATE
a “<platform>” error. The routine function errors, see VM/ESA CMS Application
name is “<routine>”; the function Reference - Assembler.
name is “<function>”; the return v For the XCIDRM function, see VM/ESA CPI
code is “<return_code>”. Communications User Guide for more
Explanation: On VM: information the return code.
v For the LINK function, Capture program v For other functions, refer to the platform
encountered an error while attempting to product application development and
LINK the minidisks identified in the database command documentation.
SQLFDEF file. Where database is the database On VSE:
identified with the SQLINIT or SQLGLOB
v For the GENCB, MODCM, OPEN, GET,
commands, the default of SQLDBA.
CLOSE, or ENDREQ function errors, see
v For the FSREAD, FSPOINT, or FSTATE VSE/ESA Messages and Codes Referencefor more
function errors, the Capture program information about the IBM VSE/VSAM
encountered an error while trying to read macros.
CAPTURE ASNPARMS or the database
v For the GETVIS, FREEVIS, or XPCC function
SQLFDEF file.
errors, see VSE/ESA Systems Macro Reference.
v For the XCIDRM function, Capture program
was unable to obtain the resource ID it uses as
a lock to ensure that only one Capture ASN0202E The USERID parameter was not
program is active for a DB2 database. The specified.
error may have occurred for the following Explanation: The USERID parameter is required
reasons: in the PARM= field on the EXEC job control
statement that is passed to the Capture program.

User Response: Add the USERID= parameter, specified database minidisk.
specifying the user ID and password in the
User Response: If prompted, enter the minidisk
PARM= field, and resubmit the job.
password.
ASN0203I Linking to “<diskname>”

minidisk“<diskowner>”as
“<vdev>”.
Explanation: The Capture program is about to
issue an internal CP link command to the
Apply program messages

v server name is “<server_name>”
ASN1000S An internal error occurred for
message number “<number>”. Its v table name is “<table_name>”
substitution fields are Explanation: An error occurred during the
“<substitution_field_1>”, execution of an SQL statement.
“<substitution_field_2>”,
“<substitution_field_3>”, User Response: Refer to your database message
“<substitution_field_4>”, reference for an explanation of the SQL error
“<substitution_field_5>”, code.
“<substitution_field_6>”, and
“<substitution_field_7>”. The
ASN1002E The “<table_name>” could not be
error code is “<error_code>”. The
locked. ERRCODE is
return code is “<return_code>”.
“<error_code>”, SQLSTATE is
Explanation: The message file for the Apply “<sqlstate>”, SQLCODE is
program was installed incorrectly, or the “<sqlcode>”, SQLERRM is
language environment variables are not set “<sqlerrm>”, SQLERRP is
correctly. This message is displayed because no “<sqlerrp>”, server name is
other Apply message could be formatted. “<server_name>”, table name is
“<table_name>”
User Response: Refer to the installation and
configuration information in this book pertaining Explanation: The Apply program could not lock
to your platform. Make sure that the message file the table.
is installed in the correct directory, and the
User Response: Refer to your database message
language environment variables are set correctly.
reference.
If the language environment variables are set
correctly, contact IBM Software Support.
ASN1003E The Apply program could not
connect to the server “<server>”.
ASN1001E The Apply program encountered
an SQL error. Parameters:
Parameters: v error code is “<error_code>”
v ERRCODE is “<error_code>” v SQLSTATE is “<sqlstate>”
v SQLSTATE is “<sqlstate>” v SQLCODE is “<sqlcode>”
v SQLCODE is “<sqlcode>” v SQLERRM is “<sqlerrm>”
v SQLERRM is “<sqlerrm>” v SQLERRP is “<sqlerrp>”
v SQLERRP is “<sqlerrp>” Explanation: The Apply program attempted to

connect to the database and received a failing User Response: Verify that the DB2
return code. There are many reasons why the DataPropagator feature was installed without
Apply program could not connect to the errors. If errors occurred, correct them and try
database. For example, the Apply program again.
would receive a failing return code if the
database was down or too many users were
without error and you are correctly accessing the
accessing it.
feature-registration module (ASNAPR61), contact
User Response: Look up the SQLCODE in the IBM Software Support for assistance.
DB2 messages and codes manual to determine
why the connection failed. See “Setting up
ASN1007E The product trial module has
end-user authentication at the source server” on
unexpected content.
Explanation: The content of the DB2
Refer to your database message reference for an
DataPropagator trial module is not as expected
explanation of the SQL error code.
for this version of the DB2 DataPropagator
product. No further use of the product is
ASN1004I The trial version of Apply will possible until you provide the correct trial
end in nn days. module.
Explanation: You are using the trial version of User Response: Verify that the DB2
DB2 DataPropagator. After nn days have passed, DataPropagator feature was installed without
you will no longer be able to use DB2 errors. If errors occurred, correct them and try
DataPropagator unless you install the again.
DataPropagator licensed feature of DB2 for
OS/390.
without error and you are correctly accessing it,
User Response: None; however you might want contact IBM Software Support for assistance.
to contact the person responsible for ordering the
DB2 DataPropagator product.
ASN1008E The subscription set with Apply
qualifier “<qualifier>” and set
ASN1005E The trial period for the Apply name “<set_name>” is not
program has expired. defined correctly. ERRCODE is
<error_code>”.
Explanation: The trial period for the DB2
DataPropagator product has ended. You can no Explanation: The subscription set is not defined
longer use this product until you order and correctly.
install the DataPropagator licensed feature of
User Response: Make sure that the
DB2 for OS/390.
WHOS_ON_FIRST column in the subscription set
User Response: Contact the person responsible table is specified correctly.
for ordering the DB2 DataPropagator product.
ASN1009E There is no subscription set
ASN1006E The product registration module defined for Apply qualifier
has unexpected content. “<qualifier>”.
Explanation: The content of the registration Explanation: There is no subscription set
module (ASNAPR61) for the DB2 defined for Apply qualifier “<qualifier>”.
DataPropagator feature is not as expected for this
User Response: Define at least one subscription
version of the DB2 DataPropagator product. No
set for Apply qualifier “<qualifier>”.
further use of the product is possible until you
provide the correct registration module.

ASN1010E The Apply program could not ASN1014E The Apply program could not
insert row “<row>” into the audit find a source for the copy request
trail table due to the following because it could not find the
error: “<error_code>”. change data table. The error code
is “<error_code>”.
Explanation: This is an SQL return code
indicating that the audit trail table was not set Explanation: The change data table was not
up with the same structure as the table in defined in the register table because either the
“Apply trail table” on page 336. Apply program did not find the change data
table name in the register table or the source
User Response: Refer to “Apply trail table” on
table was not registered correctly.
page 336 and your database SQL manual.
User Response: Refer to “Register table” on
page 301 and verify that the change data table is
ASN1011E The copy request has
correctly defined in the register table
incompatible source and target
(CD_OWNER, CD_TABLE).
attributes. The error code is
“<error_code>”.
ASN1015I The Apply program is waiting for
Explanation: This is an SQL error code
the Capture program at server
indicating that the attributes of the target table
“<server_name>” to advance the
must be compatible with the attributes of the
global SYNCHTIME. Verify that
source table.
the Capture program is running.
User Response: Refer to the
SOURCE_STRUCTURE column in the register
information only.
table for the compatibility of the source and
target attributes. User Response: Verify that the Capture
program is running.
ASN1012E The source table structure is
invalid. The error code is ASN1016I Refresh copying has been
“<error_code>”. disabled. The error code is
“<error_code>”.
Explanation: This is an SQL return code
indicating that the source table structure in the Explanation: While attempting to perform a full
register table was not set up according to the refresh, the Apply program encountered a
SOURCE_STRUCTURE column in the register DISABLE_REFRESH column in the register table
table. which was set on.
User Response: Refer to “Register table” on User Response: Either turn off the
page 301, the SOURCE_STRUCTURE column in DISABLE_REFRESH column or bypass the Apply
the register table for valid source table structures. program and perform a manual refresh.
ASN1013E The target table structure is ASN1017E Apply could not find any target
invalid. The error code is column names. The error code is
“<error_code>”. “<error_code>”.
Explanation: The target table structure in the Explanation: The Apply program could not find
subscription-targets-member table was not valid. any columns in the subscription columns table.
User Response: Refer to “Subscription-targets- User Response: Redefine the subscription set
member table” on page 326 for valid target table and subscription-set members (see “Chapter 6.
structure.

Setting up your replication environment” on
ASN1022S The Apply program could not
page 93 for instructions).
write into the work file. The error
code is “<error_code>”.
ASN1018I The Apply program is processing
Explanation: Either the user does not have the
subscription set
proper access authority for one or all of the files
“<set_name>”(“<whos_on_first>”).
or not enough space is left after writing to the
(“<set_number>” of
target file.
“<total_sets>”).
User Response: Determine whether the problem
is caused by a lack of access authority or a lack
information only.
of space and contact your system administrator
User Response: No action is required. to obtain what is needed.
ASN1019E The target table does not have any ASN1023S The Apply program could not
key columns. The error code is open the work file. The error code
“<error_code>”. is “<error_code>”.
Explanation: The Apply program could not find Explanation: The Apply program could not
key column names in one of the columns open the work file.
requiring a primary key.
User Response: Redefine the subscription set
and the subscription-set members (see
“Chapter 6. Setting up your replication
close the work file. The error code
environment” on page 93 for instructions).
Explanation: The Apply program could not
close the work file.
reserve a storage block. The error
code is “<error_code>”. User Response: Contact IBM Software Support.
obtain the required (memory) storage. ASN1025I The Apply program completed
processing for subscription set
“<set_name>”(“<whos_on_first>”).
The return code is
ASN1021S The Apply program could not “<return_code>”.
read the work file. The error code
information only.
read the work file due to a system error.
User Response: Determine if the problem is
ASN1026I The Apply program encountered
caused by lack of space and contact your system
an error while trying to bind.
administrator to obtain what is needed.
SQLSTATE is “<sqlstate>”,
SQLCODE is “<sqlcode>”.
Explanation: An error occurred during the
execution of bind.

reference.
write to the Apply log file. The
error code is “<error_code>”; the
ASN1029E The SQL statement could not return code is “<return_code>”.
execute. The error code is
“<error_code>”.
write to the log file.
Explanation: The execution of the SQL
User Response: For more information on the
statement specified by the user was not
return code, refer to the manual that describes
successful.
problem determination for your particular
User Response: Refer to SQLSTATE, SQLCODE, platform.
SQLERRO, and SQLERRM in the apply trail
table and in your database SQL manual for
detailed information.
access the subscription columns
table.
ASN1030S The Apply program encountered
Parameters:
an OS/2 error. The error code is
“<error_code>”; the return code is v error code is “<error_code>”
“<return_code>”. v SQLSTATE is “<sqlstate>”
Explanation: The execution of an OS/2 API v SQLCODE is “<sqlcode>”
failed. v SQLERRM is “<sqlerrm>”
User Response: For more information on the v SQLERRP is “<sqlerrp>”
return code, refer to the OS/2 WARP Control v server name is “<server_name>”
Program Programming Reference. v table name is “<table_name>”
ASN1031E The SQL statement is empty. The execution of an SQL statement.
error code is “<error_code>”.
Explanation: The SQL statement is an empty reference for SQL.
string.
User Response: Specify the SQL statement to be ASN1036E The column type “<col_type>” for
executed. expression “<expression>” is
invalid. The error code is
ASN1032S The Apply program log file could “<error_code>”.
not be opened. The error code is Explanation: The value for the COL_TYPE
“<error_code>”; the return code is column in the subscription columns table is
“<return_code>”. invalid.
Explanation: The Apply program could not User Response: Change the value to A, B, C, D,
open the log file. F, L, or R.
User Response: For more information on the
return code, refer to the manual that describes
problem determination for your particular
platform.

ASN1037E The Apply program could not ASN1041I The Apply program was started
obtain the date and time. The using subsystem name:
error code is “<error_code>”; the “<subsystem>”.
return code is “<return_code>”.
Explanation: This is not an error message,
Explanation: The OS/2 API DosGetDateTime however, you should make sure that the
failed. displayed subsystem name is valid.
User Response: For more information on the User Response: Verify that the subsystem name
return code, refer to the OS/2 WARP Control is valid.
Program Programming Reference.
ASN1042W There are too many invocation
ASN1038E No column names or expressions parameters.
were specified in the subscription
Explanation: The number of parameters you
columns table.
specified when you invoked the Apply program
Explanation: Column names or expressions for exceeds the maximum allowed.
a copy statement must be specified.
User Response: Refer to the Capture and Apply
User Response: Refer to “Chapter 6. Setting up chapter for your platform for information on the
your replication environment” on page 93 for appropriate number of invocation parameters.
more information about requirements for
subscription definitions.
ASN1043E There is already one Apply
instance running with this Apply
ASN1039S The Apply program plan, program qualifier “<qualifier>”.
“<plan_name>”, could not be The error code is “<error_code>”;
opened. the reason code is
“<reason_code>”.
Parameters:
v error code is “<error_code>” Explanation: Verification attempt failed.
v return code is “<return_code>” User Response: Make sure that only one
v reason code is “<reason_code>” instance of the Apply program is running under
this user ID on this subsystem or database.
Explanation: The Apply program plan could
not be opened.
ASN1044I The Apply program will become
User Response: Refer to the Apply for OS/390 inactive for “<number>” minutes
Program Directory. and “<number>” seconds.
ASN1040S The Apply program encountered information only.
an OS/390 error. The error code is
“<error_code>”; the return code is User Response: No action is required.
Explanation: Execution of an OS/390 system ASN1045I The Apply program was started
operation failed. using database “<database>”.
User Response: Refer to your OS/390 system Explanation: This message is for your
library information. information only.
User Response: No action is required unless
this is not the intended database.

ASN1046S The Apply program libraries are ASN1051E The Apply program detected a
not authorized for the Authorized gap between the source
Program Facility (APF). “<source>” table and the target
table. The error code is
Explanation: The Apply program libraries must
“<error_code>”.
be APF authorized.
Explanation: The Apply program has detected
User Response: Authorize the Apply program
that the Capture program lost change data before
libraries.
the Apply program could copy it. For example,
the Capture program might have been cold
ASN1048E The execution of a copy statement started.
failed. See the Apply trail table
User Response: Check the control tables to
for full details: “<text>”
determine why the gap is present. Take proper
Explanation: A copy statement could not action to preserve data integrity before you reset
execute. In the message, “<text>” identifies the the control table information to execute the
“<copy_server>”, “<copy_owner, copy_table, definition again.
stmt_number>”, and “<cntl_server>”.
User Response: Check the APPERRM fields in ASN1052E The Apply program could not
the audit trail table to determine why the copy find the ASNLOAD program.
statement failed.
Explanation: The Apply program cannot find
the ASNLOAD program in the current directory.
ASN1049S The Apply program encountered a
User Response: Make sure that ASNLOAD is in
system error. The error code is
the directory from which you are invoking the
“<error_code>”. The return code
Apply program.
is “<return_code>”.
Explanation: Execution of a system operation
ASN1053E The execution of the ASNLOAD
failed.
program failed. The return code is
User Response: Refer to the system library “<return_code>”.
information for your platform.
Explanation: The ASNLOAD program detected
an error.
ASN1050E The Apply program encountered
User Response: Refer to the messages files
an invalid operation while
generated by the EXPORT and IMPORT utilities.
updating the target table. The
(Note that these files names are different for
error code is “<error_code>”. The
Apply for OS/2 and Apply for AIX.)
invalid operation to be applied is
“<operation>”.
Explanation: The operation field of a row
find the registration information
fetched from the source table is not valid.
for source owner “<src_ownr>”,
User Response: Contact IBM Software Support. source table “<src_tbl>”, and
source view qualifier
“<src_view_qual>”.
Explanation: The source table registration is
incorrect or incomplete.
User Response: Drop the registration and redo
it. Also make sure that the registration

information is in both the register table and the
pruning control table.
close the password file. The error
find the prune control
close the password file.
information for source owner
“<src_ownr>”, source table User Response: Contact IBM Software Support.
“<src_tbl>”, source view qualifier
“<src_view_qual>”, target owner
ASN1059E The Apply program detected
“<tgt_ownr>”, and target table
invalid syntax for line “<line>” in
“<tgt_tbl>”.
the password file. The error code
Explanation: The source table registration is is “<error_code>”.
incorrect.
User Response: Drop the subscription and redo recognize a line in the password file.
it.
User Response: Correct the syntax error in the
password file. See the Apply program section in
ASN1056E The Apply program could not the Capture and Apply chapter for your
connect to the server due to lack platform.
of user ID/password. The error
ASN1060E The dynamic allocation for the
Explanation: The Apply program could not find temporary work file failed. The
the password and user ID to connect to the error code is “<error_code>”.
server.
Explanation: A system error was encountered
User Response: Make sure that the Apply during dynamic allocation.
program password file exists. The Apply
program password file resides in the same
directory from which you start the Apply
program. If you are using DB2 Universal ASN1061E An invalid keyword parameter
Database Satellite Edition, make sure that the was specified. The error code is
password and user ID are defined to the client “<error_code>”.
systems.
Explanation: An invalid invocation parameter
was specified and ignored by the Apply
ASN1057E The Apply program could not program.
read the password in the Apply
password file. The error code is User Response: Correct the invocation
“<error_code>”. parameter. See the Apply program section in the
Capture and Apply chapter for your platform.
Explanation: The Apply program found no
password.
ASN1063E A subscription set cannot have
User Response: If you want to use the more than 200 members. The error
AUTHENTICATION=SERVER scheme, you must code is “<error_code>”.
provide a password, as described in the Apply
program section in the Capture and Apply Explanation: The number of subscriptions has
chapter for your platform. exceeded the maximum allowed number of 200.
User Response: Remove excess members from
the subscription set.

ASN1066S An internal Apply program error ASN1070E The Apply program could not
occurred. The error code is lock the target table.
“<error_code>”.
Parameters:
Explanation: An internal Apply program error v ERRCODE is “<error_code>”
occurred.
v SQLSTATE is “<sqlstate>”
User Response: Contact IBM Software Support. v SQLCODE is “<sqlcode>”
v SQLERRM is “<sqlerrm>”
ASN1067E The Apply program has detected v SQLERRP is “<sqlerrp>”
update conflicts and compensated
v server name is “<server_name>”
rejected transactions. See the
unit-of-work table for details. The v table name is “<table_name>”
error code is “<error_code>”. Explanation: The Apply program could not lock
Explanation: More than one application the target tables before it was to check update
updated the same row in a table from different conflicts.
locations. Some transactions have been rejected User Response: Verify that all the target tables
and compensated. are available before restarting Apply.
User Response: Refer to “Unit-of-work table”
on page 319 for details. ASN1071E The Apply program could not
reposition the work file. The error
ASN1068E The Apply program has code is “<error_code>”.
deactivated the subscription due Explanation: The Apply program has detected
to an RI violation. The error code an error while reading the temporary work file.
Explanation: A referential integrity violation
was detected when copying data from the source
table to a replica. The Apply program has ASN1072E The Apply program could not
terminated and the subscription has been find the ASNDONE program.
deactivated.
Explanation: The Apply program could not find
User Response: Correct the referential integrity the user exit program, ASNDONE.
error and reactivate the subscription.
User Response: Verify that the ASNDONE
program is located in the correct directory.
ASN1069E The Apply program has detected a
referential integrity violation and
ASN1073E The execution of the ASNDONE
compensated the rejected
program failed. The return code is
transactions. See the unit-of-work
table for more details. The error
code is “<error_code>”. Explanation: An error occurred while calling
the user exit program, ASNDONE.
was detected when replicating data from the User Response: Contact IBM Software Support.
replica to the user table.
User Response: See the unit-of-work table for
more details.

ASN1074E The Apply program could not ASN1097I The Apply program stopped due
find the ASNDLCOPY program. to the above error.
Explanation: The Apply program did not find Explanation: The error reported previously
the ASNDLCOPY program in the current search caused the Apply program to stop.
path.
User Response: Fix the error reported before
User Response: Add the ASNDLCOPY program this message.
to the search path and run the Apply program
again.
ASN1100I A user has stopped the Apply
program.
ASN1075E The ASNDLCOPY program failed.
Explanation: A user issued the STOP command
The return code is ″<error_code>″.
to stop the Apply program.
Explanation: The ASNDLCOPY program
detected an error.
User Response: Refer to the log file that was
ASN1109I Not all of the Jet database
generated by the ASNDLCOPY program for
changes are applied due to an RI
detailed information. The name of the log file is
violation.
asndlxxxx.log.
Explanation: There was at least one change in
the row-replica target list table that violates the
ASN1076E The Apply program cannot read
referential integrity (RI) of the source table.
the format of the result file that
was generated by the User Response: Refer to the Microsoft
ASNDLCOPY program. Jet-specific error information and error messages
tables for more details. See “Error information
Explanation: The result file that was generated
table (Microsoft Jet specific)” on page 348.
by the ASNDLCOPY program is not in an
expected format.
ASN1110I The Apply program created Jet
User Response: If you modified the
database “<db_name>”.
ASNDLCOPY program, check that your changes
are not causing the invalid format. If your Explanation: The target database <db_name>
changes are not the cause of the problem, check was created.
that your machine has enough space for the
result file. User Response: No action is required.
ASN1077S The Apply program encountered ASN1111I The Apply program converted Jet
an invalid DATALINK column Database “<db_name>” to a
value while updating the target Design Master.
table. The error code is Explanation: The database that you specified is
″<error_code>″. now a Design Master from which all Microsoft
Explanation: The DATALINK column field of a Jet Replicas will be created.
row fetched from the source table is not valid. User Response: No action is required.

User Response: Either activate the subscription
ASN1115I ODBC call was successful with
or select another one.
sqlcode “<sqlcode>”, sqlstate
“<sqlstate>”, and message
“<message>”. ASN1210E An Apply qualifier must be
specified following the keyword
Explanation: The ODBC call was successful, but
-q.
a message was issued. This message is for your
information only. Explanation: You must specify an Apply
qualifier following the keyword -q.
User Response: Specify an Apply qualifier
following the keyword -q.
ASN1116E ODBC call failed. sqlcode
“<sqlcode>”, sqlstate “<sqlstate>”,
and message “<message>”. ASN1212E A read-only set name
“<set_name>” is found following
the keyword “<keyword>”.
execution of an ODBC operation against either
the DB2 ODBC driver or the Microsoft Jet ODBC Explanation: A read-only set name was
driver. specified following the keyword U or D.
User Response: Refer to the appropriate ODBC User Response: Specify only replica for the
reference for more information. keywords U and D.
ASN1130E Execution of DAO call failed. ASN1221I Set “<set_name>” has been
ERRCODE “<error_code>”, DAO successfully refreshed with
error number “<error_number>”, “<number>”rows at “<time>”.
and DAO error message
“<error_message>”. Explanation: This message is for your
information only.
Explanation: An error occurred during a
Microsoft Data Access Object (DAO) execution. User Response: No action is required.
User Response: Refer to the Microsoft DAO

reference for more information. ASN1222I Set ″<set_name>″ has successfully
inserted ″<number>″ rows,
deleted ″<number>″ rows,
ASN1135E File operation failed. File name is updated ″<number>″ rows at
“<file_name>”, error code is ″<time>″.
“<error_code>”.
Explanation: Open, close, read, or write information only.
operations failed.
User Response: Verify that the user has
authority for the file operation. Also verify that
there is enough space in the system. ASN1223E The Apply program could not
copy for set “<set_name>”.
ASN1207E The subscription for Explanation: The Apply program encountered a

“<subscription>” was not problem while copying.
activated. User Response: Refer to the apply trail table to
Explanation: The selected subscription is determine the cause of the error.
inactive.

ASN1242E A SQL error occurred. ERRCODE ASN1305E The ASNSAT program terminated
is “<error_code>”, SQLSTATE is due to an Apply error.
″<sqlstate>″, SQLCODE is
Explanation: The Apply program returned an
″<sqlcode>″, SQLERRM is
error.
″<sqlerrm>″, SQLERRP is
″<sqlerrp>″, table name is User Response: Determine the error from the
″<table_name>″. Apply log file.
information only. ASN1309E Cannot find default control
database name.
Explanation:
ASN1243E There is no eligible subscription Satellite
in the ASN.IBMSNAP_SUBS_SET The default control server, SATCTLDB,
table. is not found from the database directory.
Explanation: Either a subscription set has not Non-Satellite
been selected or the apply qualifier is invalid. The user did not specify the default
control server name in DB2DBDFT.
User Response: Verify the subscription names
and apply qualifier. User Response: Specify the control server name
following the -n keyword.
ASN1244E User has not selected any set.
ASN1310E The ASNSAT program
Explanation: A subscription set has not been
encountered a system error while
selected from the ASNMOBIL dialog.
attempting to invoke the Capture
User Response: Select at least one subscription program. Return code is
set from ASNMOBIL dialog. “<return_code>”.
Explanation: An operating system error
ASN1303E The ASNSAT program occurred while calling ASNCCP.
encountered an incorrect
User Response: Make sure that the Capture
invocation keyword. The keyword
program is in the execution path.
is “<keyword>”.
Explanation: An unknown keyword parameter
ASN1311E The ASNSAT program
was specified.
encountered a system error while
User Response: Specify the correct keyword attempting to invoke the Apply
parameter. program. Return code is
ASN1304E The ASNSAT program terminated Explanation: An operating system error
due to a Capture error. occurred while calling ASNAPPLY.
Explanation: The Capture program returned an User Response: Make sure that the Apply
error. program is in the execution path.
User Response: Determine the error from the
Capture log file.

ASN1312E The default target server, ASN1317E An SQL error occurred while
DB2DBDFT, is not set. ASNSAT was getting the
CD_TABLE value from
Explanation: The user did not specify the target
ASN.IBMSNAP_REGISTER table.
server name, and the ASNSAT program could
not determine the default database name from
DB2DBDFT.
Explanation: An SQL error occurred while
User Response: Specify the target server name
selecting from the register table.
following the -t keyword.
reference.
ASN1314E An SQL error occurred while
ASNSAT was getting the default
Apply qualifier. SQLSTATE is ASN1318E An SQL error occurred while
“<sqlstate>”, SQLCODE is ASNSAT attempted to get the
“<sqlcode>”. DB2 node type. SQLSTATE is
“<sqlstate>”, SQLCODE is
Explanation: The user did not specify the Apply
“<sqlcode>”.
qualifier. The ASNSAT program encountered an
error while retrieving the USER special register. Explanation: An error occurred while retrieving
the node type configuration parameter.
User Response: Specify the Apply qualifier
following the -q keyword. User Response: Refer to your database message
reference.
ASN1315E Cannot connect to database server.
Explanation: An error occurred while
attempting to connect to the target database.
reference.
ASN1316E ASNSAT encountered an error

while trying to bind. The
Explanation: An error occurred while
attempting to auto bind.
User Response: Make sure that the bind file
exists in the sqllib\bnd directory.

Chapter 16. Replication messages for AS/400
This chapter contains a list of messages issued by DB2 replication for AS/400
for the Capture and Apply programs; the trigger programs for the register
table, the pruning control table, and the critical section table; and the delete
receiver exit routine.
The replication messages have the following prefixes:

ASN1 The Apply program. These messages are listed in “Apply for AS/400
messages”
ASN2 The Capture program. These messages are listed in “Capture for
AS/400 messages” on page 386
ASN3–ASN6
Other replication messages for AS/400 (these include the messages
issued by the trigger programs for the register table, the pruning
control table, and the critical section table, and messages issued by the
delete receiver exit routine). These messages are listed in “Other
replication messages for AS/400” on page 390
Unless otherwise stated, all error codes ″<error_code>″ described in error

messages are internal error codes used by IBM Software Support. Also, unless
otherwise stated, error messages are issued with a return code of 8.
You can also obtain explanations for messages by typing the following
command at a DB2 command prompt:
db2 message_number
Apply for AS/400 messages
ASN1001 The Apply program encountered ASN1002 Critical section table not
an SQL error. available.
Explanation: The SQL was statement was not Explanation: The Apply program could not lock
successful. the critical section table.
User Response: Check the messages in the job User Response: Try the request again when the
log to determine the cause of the problem. Try critical section table is available.
the request again.

″<src_ownr>″, source table ″<src_tbl>″, and
ASN1003 Apply program could not connect
source view qualifier ″<src_view_qual>″. The
to server ″<server_name>″.
error code is ″<error_code>″.
Explanation: The Apply program tried to
User Response: Examine the subscription and
connect to server ″<server_name>″ but was not
registration information. The data in the
successful.
ASN.IBMSNAP_PRUNCNTL table does not
User Response: Ensure the connection to the correspond to the data in the
server is active. Check the messages in the job ASN.IBMSNAP_REGISTER table for source
log to determine the cause of the problem. Try owner ″<src_ownr>″, source table ″<src_tbl>″,
the request again. and source view qualifier ″<src_view_qual>″.
The user should remove the source table
registration and try adding the source table
ASN1011 Copy request attributes not
registration again.
compatible.
Explanation: The attributes of the target table
ASN1055 Prune control information not
must be compatible with the attributes of the
found.
base table.
Explanation: The Apply program could not find
User Response: Change the incompatible copy
the prune control information for source owner
request values.
″<src_ownr>″, source table ″<src_tbl>″, source
view qualifier ″<src_view_qual>″, target owner
ASN1036 The column type is not valid. ″<tgt_ownr>″, and target table ″<trt_tbl>″. The
Explanation: The column type ″<col_type>″ for
expression ″<expression>″ is not valid. The error User Response: Examine the subscription and
code is ″<error_code>″. registration information. The data in the
ASN.IBMSNAP_PRUNCNTL table does not
User Response: Change the column type to a correspond to the data in the
valid value. The valid column types are: ’A’ is an ASN.IBMSNAP_REGISTER table for source
after-image column. ’B’ is a before-image column. owner ″<src_ownr>″, source table ″<src_tbl>″,
’C’ is a computed column without SQL column and source view qualifier ″<src_view_qual>″.
functions. ’F’ is a computed column with SQL The user should remove the source table
column functions. ’R’ is a relative record number registration and try adding the source table
after-image key column. registration again.
ASN1050 Refresh operation not valid. ASN1063 Maximum number of set members
Explanation: The Apply program encountered exceeded.
an operation during refresh that is not valid. The Explanation: The number of subscriptions has
operation is ″<operation>″. Error code exceeded the maximum allowed number of 200.
″<error_code>″. The error code is ″<error_code>″.
User Response: Record the message number, User Response: Remove excess members from
operation code and error code, and contact your the subscription set.
system administrator.
ASN1066 Synchpoint could not be

ASN1054 Registration information not determined.
found.
Explanation: The synchpoint value for the set
Explanation: The Apply program could not find could not be determined because an internal
the registration information for source owner

Apply error occurred. The error code is User Response: The user should verify that all
″<error_code>″. the target tables are available before restarting
the Apply program.
User Response: Record the message number
and error code, and contact your system
administrator. ASN1071 Internal error in Apply program.
Explanation: The Apply program detected an
ASN1067 Update conflicts detected. error while reading the temporary work file. The
Explanation: More than one application
updated the same row in a table from different User Response: The user should record the
locations. Some transactions have been rejected message number and error code, and contact
and compensated. The error code is their system administrator. The 7E00470E,
″<error_code>″. 7F004714, and 81004706 error codes, indicate that
the Apply program cannot read the format of the
User Response: See the unit of work table
file that was generated by the ASNDLCOPY
(ASN.IBMSNAP_UOW) for details. The user
program. If you modified the ASNDLCOPY
should refer to the product information for an
program, check to see if your changes are
explanation of the values in the
causing the invalid format.
IBMSNAP_REJ_CODE column.
ASN1073 Program ″<program>″ in library

ASN1068 Referential integrity violation
″<library>″ failed.
detected.
Explanation: The set completion notification
(ASNDONE) user exit program
was detected when copying data from the source
″<exit_program>″ in library ″<library>″ failed.
table to a replica. The subscription has been
The reason code is ″<reason_code>″, and the
deactivated. The error code is ″<error_code>″.
return code is ″<return_code>″. The error code is
User Response: Correct the referential integrity ″<error_code>″. This message also indicates that
error and reactivate the subscription. the DATALINK file copy (ASNDLCOPY) user
exit program ″<exit_program>″ in library
″<library>″ failed. The reason code is
ASN1069 Referential integrity violation ″<reason_code>″, the return code is
detected. ″<return_code>″, and the error code is
Explanation: A referential integrity violation ″<error_code>″.
was detected when replicating data from the User Response: If the reason code is -999, the
replica to the user table. All of the affected units resolve system pointer (RSLVSP) MI instruction
of work have been marked in the unit of work failed, or the call to the set completion
table (ASN.IBMSNAP_UOW) and compensated. notification (ASNDONE) user exit program
The subscription has been deactivated. The error failed. The user should refer to the job log to
code is ″<error_code>″. obtain information about the failure. If the reason
User Response: Correct the referential integrity code is not -999, the user should refer to the
error and reactivate the subscription. documentation for the set completion notification
(ASNDONE) user exit program
″<exit_program>″ in library ″<library>″ for an
ASN1070 Target table not available. explanation of the reason code and return code
Explanation: The Apply program could not lock values. If the exit program is ASNDLCOPY, refer
target table ″<tgt_tbl>″ in library ″<library>″ on to the log file that was generated by the
server ″<server>″ to check for update conflicts. ASNDLCOPY program for detailed information.
The error code is ″<error_code>″.
Chapter 16. Replication messages for AS/400 383

(ASN.IBMSNAP_REGISTER) for the source table.
ASN1110 Row could not be inserted into
The CD_OWNER and CD_TABLE columns must
apply trail table.
be specified for the registered table.
insert a row into the apply trail table
ASN1115 Apply program waiting for global
(ASN.IBMSNAP_APPLYTRAIL). The table
SYNCHTIME to advance.
structure of the apply trail table is not correct.
The error code is ″<error_code>″. Explanation: The Apply program is waiting for
the Capture program at server ″<server>″ to
User Response: The user should refer to the
advance the global SYNCHTIME. The error code
product information to obtain the correct table
is ″<error_code>″.
structure for the ASN.IBMSNAP_APPLYTRAIL
table. The ASN.IBMSNAP_APPLYTRAIL table User Response: Verify that the Capture
must be changed to have the table structure that program is running.
is documented in the product information.
ASN1117 No target column names were

ASN1112 Source table structure is not valid. supplied.
Explanation: The value in the Explanation: The Apply program could not find
SOURCE_STRUCTURE column in the register any columns in the subscription columns table
table (ASN.IBMSNAP_REGISTER) is not valid. (ASN.IBMSNAP_SUBS_COLS). The error code is
The error code is ″<error_code>″. ″<error_code>″.
User Response: The source table structure for User Response: Redefine the replication
the registration must be changed to a valid subscription.
value. A list of valid source table structure values
can be found in the product information.
ASN1120 Storage block could not be
reserved.
ASN1113 Target table structure is not valid.
Explanation: The value in the reserve a storage block. The error code is
TARGET_STRUCTURE column in the ″<error_code>″.
subscription targets table
(ASN.IBMSNAP_SUBS_MEMBR) is not valid. User Response: Record the message number
The error code is ″<error_code>″. and error code, and contact your system
administrator.
User Response: The target table structure for
the subscription must be changed to a valid
value. A list of valid target table structure values ASN1121 Apply program could not read
can be found in the product information. from work file.
ASN1114 Change data table not found. read a record from the work file. The user
probably does not have the proper access
Explanation: The Apply program could not find authority for one or all of the files. The error
a source for the copy request because it could code is ″<error_code>″.
not find the change data table. The change data
table was not defined in the register table User Response: Determine whether the problem
(ASN.IBMSNAP_REGISTER). The error code is is caused by a lack of access authority and
″<error_code>″. contact your system administrator to obtain what
is needed.
User Response: A change data table must be
correctly defined in the register table

ASN1122 Apply program could not write ASN1135 Subscription columns table not
into work file. available.
Explanation: The Apply program could not Explanation: The subscription columns table
write a record to the work file. Either the user (ASN.IBMSNAP_SUBS_COLS) could not be
does not have the proper access authority for one accessed.
or all of the files or not enough space is left in
User Response: Check the messages in the job
the work file for the record. The error code is
log to determine the cause of the problem. Try
″<error_code>″.
the request again when the
User Response: Determine whether the problem ASN.IBMSNAP_SUBS_COLS table is available.
is caused by a lack of access authority or a lack
of space and contact your system administrator
ASN1138 No column names or expressions
to obtain what is needed.
supplied.
Explanation: No column names or expressions
ASN1123 Work file could not be opened.
were specified in the subscription columns table
Explanation: The Apply program could not (ASN.IBMSNAP_SUBS_COLS). Column names or
open the work file. The error code is expressions must be supplied for a subscription.
″<error_code>″ The error code is ″<error_code>″.
User Response: Record the message number User Response: Specify column names or
and error code, and contact your system expressions for the subscription request.
administrator.
ASN1140 OS/400 system operation failed.
ASN1124 Work file could not be closed.
Explanation: The Apply program encountered
Explanation: The Apply program could not an error on an OS/400 system operation. The
close the work file. The error code is error code is ″<error_code>″. The return code is
″<error_code>″. ″<return_code>″.
User Response: Record the message number User Response: Record the message number
and error code, and contact you system and error code, and contact your system
administrator. administrator.
ASN1129 SQL statement was not successful. ASN1148 Subscription was not successful.
Explanation: The SQL statement that the user Explanation: The subscription did not run
specified to run as an EXECUTE IMMEDIATE successfully. The error code is ″<error_code>″.
SQL statement was not successful. The error code
is ″<error_code>″.
log or the apply trail table
User Response: Refer to the previous messages (ASN.IBMSNAP_APPLYTRAIL) to determine
in the job log and the apply trail table why the subscription failed. Correct the error
(ASN.IBMSNAP_APPLYTRAIL) for detailed and try the request again.
information.
ASN1151 Subscription was not successful.
Explanation: The Apply program determined
that a gap exists between the source table
″<src_tbl>″ and the target table. The error code is
″<error_code>″.

User Response: Check the control tables to User Response: Make sure that the
determine why the gap is present. Take proper WHOS_ON_FIRST column in
action to preserve data integrity before you reset ASN.IBMSNAP_SUBS_SET is specified correctly.
the control table information to run the definition
again.
ASN1B09 There is no subscription set
defined for Apply qualifier
ASN1B08 The subscription set with Apply ″<qual_name>″.
qualifier ″<qual_name>″ and set
Explanation: Define at least one subscription set
name ″<set_name>″ is not defined
for Apply qualifier ″<qual_name>″.
correctly. ERRCODE is
″<error_code>″. Explanation: The User Response: Define at least one subscription
subscription set is not defined set for Apply qualifier ″<qual_name>″.
correctly.
Explanation: The subscription set is not defined
correctly.
Capture for AS/400 messages

User Response: Check the job log of the
ASN200A User table ″<table_name>″
referenced job to determine why that job ended
registration not satisfied. The
unexpectedly. End the capture process
registration probably should be
(ENDDPRCAP command) and start it again
removed.
(STRDPRCAP command).
Explanation: There are many reasons that data
capturing for a replication source cannot
ASN2004 User table ″<table_name>″
continue. Depending on the severity, you can
registration not satisfied. The
receive either an ASN2004 or an ASN200A
registration probably should be
message.
removed.
Because a journal job is usually responsible for
Explanation: See ASN200A. This message was
capturing data from several replication sources,
displayed because the user table ″<user_table>″
the journal job is not affected by these messages.
in library ″<library>″ is registered in the Register
These messages were generated due to a specific
table, or the Change Data Control table, but it
replication source. After sending the ASN2004 or
could not be processed because of reason code
ASN200A message, the Capture journal job
″<reason_code>″. The reason codes and their
continues processing other replication sources.
meanings are located in the following list:
The program ends only if the last erring
replication source is the last journal job 60 Either the physical file ″<file_name>″ in
processing. library ″<library>″ has been renamed or
the member name for member
User Response: Use the DSPMSGD command
″<member>″ in that file has been
to determine the conditions that caused this
changed.
message. For example:
DSPMSGD ASN200A QDPR/QDPRMSG 70 Either the physical file ″<file_name>″ in
library ″<library>″ has been deleted or
member ″<member>″ has been removed
ASN2002 Turning Parameter table not from that file.
found.
140 Either the library ″<library>″ has been
Explanation: The journal job in the capture renamed or the physical file
process has ended unexpectedly.

″<file_name>″ has been moved from
ASN2029 Internal error in Capture program.
that library to a different library.
Explanation: The Capture program detected an
User Response: Use the DSPMSGD command
unexpected exception.
to determine the conditions that caused this
message. User Response: Record the exception code and
contact your system administrator. Refer to the
job log for additional information relating to that
ASN2017 Starting point not found for
exception.
journal ″<table_name>″ (C I G R).
Explanation: One of the first tasks in the
ASN2030 Cannot submit job.
Capture control job is to establish the starting
point with which to resume journal entry Explanation: The Capture controlling job could
processing. The journal receiver containing not submit a subordinate journal job to process
entries corresponding to that starting point must changes.
be online. If that receiver is deleted prematurely,
the control job sends message ASN2017 to ask
log to determine the problem. Correct the errors
you how you want to proceed.
and try the request again. If the problem recurs,
Response I tells the control job to ignore the fact contact the system administrator.
that a receiver is missing. Data capturing
resumes using the current receiver chain. If you
ASN2037 Cannot send data queue message
respond I, you are responsible for the integrity of
to job.
the replication. The Capture program can not
guarantee that all of the changes are made to the Explanation: The Capture controlling job could
replication targets. not send message to the data queue of a
subordinate job because the data queue is not
Response C cancels the Capture control job.
empty.
Response R retries establishing the starting point.
User Response: To resume normal operation,
User Response: In most cases, a response of G end data capture environment by issuing the
is appropriate. (Cold start all the replication ENDDPRCAP command and start it again by
sources using this journal.) issuing the STRDPRCAP command. It may be
necessary to end that subordinate job by using
the end-immediate option to allow the capture
ASN2019 Not authorized to Tuning
environment to be ended completely.
Parameters table.
Explanation: You are not authorized to the
ASN2038 Too many registrations for
IBMSNAP_CCPPARMS table in library ASN.
journal.
User Response: Ask the security officer to grant
Explanation: For the named journal, the
authority (GRTDPRAUT command) to you.
number of base tables that are being actively
captured exceeds the limit of 300.
User Response: Remove some registrations. If
Explanation: The Capture control job detected this is not possible, create a new journal and
an internal error and posted a reason code. have some registrations changed to use the new
journal.
User Response: Record the reason code and
contact your system administrator.

ASN2039 Lag limit exceeded. ASN2045 Data changes not captured for
table.
Explanation: Exceeding the lag limit causes the
Capture component to send an ASN2039 Explanation: User table is registered in the
message to the job log and to the system Register table but it could not be processed.
operator message queue.
User Response: Correct the problem and try the
User Response: By gathering system request again.
performance data, you can better determine what
action might be necessary. Some possible
ASN2046 Not authorized to Unit of Work
solutions are:
table.
v To increase the lag limit.
v To prioritize (by using a lower numerical
IBMSNAP_UOW table in library ASN.
value) the Capture jobs to a level identical to
or higher than that of the interactive jobs. User Response: Ask the security officer to grant
v To reschedule the work load to a time period authority to you by issuing the command
when the demand on the system is less, or to GRTDPRAUT specifying AUT(*CAPTURE).
move some of the work load to a different
system. ASN2047 Not authorized to index of
v To add more resources to the system (a system Pruning Control table.
upgrade).
Explanation: You are not authorized to index
IBMSNAP_PRUNCNTLX in library ASN.
ASN2042 No registrations were found to
process. User Response: Ask the security officer to grant
authority to you by issuing the command
Explanation: No registrations in the GRTDPRAUT specifying AUT(*CAPTURE).
IBMSNAP_REGISTER table met the selection
criteria provided on the Start DPR Capture
(STRDPRCAP) command. ASN2048 Not authorized to Capture Trace
table.
User Response: Change the selection criteria or
specify *ALL on the JRN keyword and try the Explanation: You are not authorized to the
request again. IBMSNAP_TRACE table in library ASN.
ASN2043 No registrations for the specified authority to you by issuing the command
journal. GRTDPRAUT specifying AUT(*CAPTURE).
Explanation: The journal specified for the JRN

keyword on either the STRDPRCAP command or ASN2049 Not authorized to Warm Start
the INZDPRCAP command is not one that has table.
any tables registered in the table Explanation: You are not authorized to the
IBMSNAP_REGISTER in library ASN. The IBMSNAP_WARM_START table in library ASN.
journal will be ignored.
User Response: Check for possible misspelling authority to you by issuing the command
of the journal name. If this is the case, reissue the GRTDPRAUT specifying AUT(*CAPTURE).
command with the correct name.

that row should have a valid time stamp. If this
ASN2050 Registration Extension table not
is not the case, there may be a few possibilities.
found.
One of which is that the row in table
Explanation: The IBMSNAP_REG_EXT table ASN/IBMSNAP_REG_EXT has been updated
was not found in library ASN. incorrectly. The other is that the table
ASN/IBMSNAP_PRUNCNTL does not have
User Response: Restore the ASN library from
program QZSNCAP5 in library QDPR as its
the previous save volume or call the QZSNCRTC
trigger program.
program (CALL QDPR/QZSNCRTC) or restore
the IBM DataPropagator Relation Capture and
Apply for OS/400 licensed program (5769-DP2). ASN2056 Registration for source table is
invalid.
ASN2051 Not authorized to Registration Explanation: There is a registration entry for the
Extension table. source table in question. That table name is an
SQL alias name. It has been altered since it was
first registered. It is now based on a different
IBMSNAP_REG_EXT table in library ASN.
physical file (or physical file member) from the
User Response: Ask the security officer to grant one it was based on at the time of registration.
authority (GRTDPRAUT command) to you. This difference cannot be tolerated.
User Response: If the alias name that was
ASN2052 Not authorized to index of registered has been changed since the
Register Extension table. registration, change it back to the way it was
when you registered it. If you cannot change it
Explanation: You are not authorized to index back, delete the registration and re-register it.
IBMSNAP_REG_EXTX in library ASN.
User Response: Ask the security officer to grant ASN2057 Not authorized to Authenticity
authority to you by issuing the command Token table.
GRTDPRAUT specifying AUT(*CAPTURE).
IBMSNAP_AUTHTKN table in library ASN.
ASN2053 Not authorized to index of Unit of
Work table. User Response: Ask the security officer to grant
Explanation: You are not authorized to index GRTDPRAUT specifying AUT(*CAPTURE).
IBMSNAP_UOW_IDX in library ASN.
User Response: Ask the security officer to grant ASN2058 Not authorized to Critical Section
authority to you by issuing the command table.
GRTDPRAUT specifying AUT(*CAPTURE).
IBMSNAP_CRITSEC table in library ASN.
ASN2055 Not able to find full refresh start
time. User Response: Ask the security officer to grant
Explanation: The attempt to start Capture for GRTDPRAUT specifying AUT(*CAPTURE).
Version 5 failed. The program is not able to find
the full refresh starting time for source table.
User Response: The full refresh starting time is
kept in the table ASN/IBMSNAP_REG_EXT. Explanation: An error occurred in the Capture
There should be a row in that table for each program.
source table. The FR_START_TIME column in
User Response: Check the job log to determine

the cause of the problem. Record the reason code DSPMSGD ASN2301 QDPR/QDPRMSG
and contact your system administrator.
Record the reason code and contact your system
administrator.
Explanation: This message is sent by the journal
ASN2501 Not authorized to register table.
job as an escape message before the journal job
ends. A condition exists that makes it impossible Explanation: You are not authorized to the
to continue capturing data. ASN/IBMSNAP_REGISTER table.
User Response: Check the job log to determine User Response: Ask the security officer to grant
the cause of the problem. To aid in problem authority to you or use the GRTDPRAUT
determination, use the DSPMSGD command to command with *REGISTRAR.
determine the conditions that caused this
message to be displayed. For example:
Other replication messages for AS/400

The other replication messages include:
Messages from trigger programs for the register table
DataPropagator puts database triggers on the register table (table
ASN/IBMSNAP_REGISTER). This trigger is called when any
replication administration tool tries to insert, update, or delete a
register table row. It is also called when someone tries to work with
the register table directly.
The purpose of this trigger program is to maintain the register
extension table (table ASN/IBMSNAP_REG_EXT, which exists only on
AS/400). A secondary purpose of this trigger is to maintain the
journal list in Capture program’s primary control table.
The messages issued from the trigger program may appear in any job
that works on behalf of the replication administration tools.
Messages from trigger programs for the prune control table
DataPropagator puts database triggers on the pruning control table
(table ASN/IBMSNAP_PRUNCNTL). This trigger is called when any
Apply program tries to insert, update, or delete a pruning control
table row.
The triggers are needed to reduce CPU overhead of the Capture
program and to maintain the FR_START_TIME column in the register
extension table (table ASN/IBMSNAP_REG_EXT).
These messages will most likely appear in the Apply job log (or the
equivalent of the jog log on other platforms).
Messages from trigger program for the critical section table

DataPropagator puts database triggers on the critical section table
(table ASN/IBMSNAP_CRITSEC). This trigger is called when any
Apply program tries to insert, update, or delete a critical section table
row.
The triggers are needed to support update anywhere.
The messages will most likely appear in the Apply job log (or the
equivalent of the job log on other platforms).
Messages from the delete receiver exit routine
The delete receiver exit routine errors are from the delete receiver exit
routine QZSNDREP in library QDPR. This routine is called when a
user tries to delete a journal receiver. It is usually called from a
database server job, QDBSRC0x, which handles automatically deleting
unneeded journal receivers. When the automated deleting of receivers
seems to be not working, use the WRKACTJOB command to find any
messages in these server jobs’ job logs. You might find one of the
listed messages or you might find other messages sent by the
operating system.
ASN3050 Change data table ″<table_name>″ ASN4502 Register table index not found.
not found.
Explanation: The index
Explanation: The change data table referred to ASN/IBMSNAP_REGISTERX is not found.
in the Register table was not found.
User Response: Remove the registration for that the previous save volume or run the Create DPR
source table. Then register the source table and Tables command (CRTDPRTBL).
try the STRDPRCAP command again.
ASN4503 Pruning control table not found.
ASN3053 Source table not found.
Explanation: The table
Explanation: There is a registration entry found ASN/IBMSNAP_PRUNCNTL is not found.
for the named source table. That source table is
not found.
the previous save volume or run the Create DPR
User Response: Delete the registration for that Tables command (CRTDPRTBL).
source table and register the source table again
when appropriate.
ASN4504 Pruning Control index not found.
ASN4501 Register table not found.
ASN/IBMSNAP_PRUNCNTLX is not found.
ASN/IBMSNAP_REGISTER is not found.
User Response: Restore the ASN library from Tables command (CRTDPRTBL).
the previous save volume or run the
CRTDPRTBL command or restore the IBM
DataPropagator Relational Capture and Apply
for OS/400 licensed program (5769-DP2).

ASN4505 Trace table not found.
Explanation: The table ASN/IBMSNAP_TRACE Tables command (CRTDPRTBL).
is not found.
User Response: Restore the ASN library from ASN4525 Apply qualifier cross reference
the previous save volume or run the Create DPR table not found.
Tables command (CRTDPRTBL).
ASN/IBMSNAP_AUTHTKN is not found.
ASN4506 Warm start table not found.
Explanation: The table the previous save volume or run the Create DPR
ASN/IBMSNAP_WARM_START is not found. Tables command (CRTDPRTBL).
the previous save volume or run the Create DPR ASN4526 Apply qualifier cross reference
Tables command (CRTDPRTBL). table index not found.
ASN4507 Critical section table not found. ASN/IBMSNAP_AUTHTKNX is not found.
Explanation: The table User Response: Restore the ASN library from
ASN/IBMSNAP_CRITSEC is not found. the previous save volume or run the Create DPR
Tables command (CRTDPRTBL). ASN4527 Unit of work table not found.
Explanation: The table ASN/IBMSNAP_UOW
ASN4508 Critical section index not found. was not found.
Explanation: The index User Response: Restore the ASN library from
ASN/IBMSNAP_CRITSECX is not found. the previous save volume or run the Create DPR
Tables command (CRTDPRTBL). ASN4529 Unit of work index not found.
ASN4509 Index for the unit of work table ASN/IBMSNAP_UOW_IDX is not found.
not found.
Explanation: The index the previous save volume or run the Create DPR
ASN/IBMSNAP_UOW_IDX is not found. Tables command (CRTDPRTBL).
the previous save volume or run the Create DPR ASN6063 Failed to update the PCB.
Explanation: The trigger program for Register
table issued a QUSCHGUS AP call in an attempt
ASN4510 Register extension index not to update the user space QZSNCTLBLK in
found. library ASN. The API call failed with an
exception.
ASN/IBMSNAP_REG_EXTX is not found. User Response: Record the reason code and try
to correct the problem. If the problem recurs,

ASN6069 Error detected in trigger program
for IBMSNAP_REGISTER.
ASN6064 Number of journals exceeds the
Explanation: An error occurred in the trigger
limit.
program (QZSNJRNL) for the Register table for
Explanation: An attempt was made to add an Data Propagator Relational/400. This trigger
entry to the journal list in user space program is needed to maintain a list of journals
QZSNCTLBLK in library ASN. It has a limit of that all the registered base table in the system
500 entries. That limit is exceeded. use. Additional message may be found in the job
log which can help determine the cause of the
User Response: Reduce the number of journals problem.
that all registered source tables use to be less
than the allowed limit. User Response: Check the job log of the job
that sent this message. Correct the problem and
try the request again.
ASN6065 Attempt to convert base table
name to system name failed.
ASN6071 Internal error in trigger program
Explanation: An attempt was made to convert for IBMSNAP_REGISTER.
the base table name from the SQL name to
system name for the subject source table. The Explanation: An error occurred in the trigger
conversion attempt failed. program (QZSNJRNL) for the Register table for
DataPropagator Relational/400. This trigger
User Response: Make sure the source table program is needed to maintain a list of journals
exists before retrying the request. that all the registered base tables in the system
use. Check the job log for possible additional
ASN6068 Cannot find a matching row in messages which can help determine the cause of
IBMSNAP_REG_EXT. the problem.
Explanation: An attempt was made to read a User Response: Record the reason code and
matching row for the named source table in table contact your system administrator.
IBMSNAP_REG_EXT. The matching row was not
found. ASN2401 Internal error in trigger program.
User Response: Ignore the error if you are Explanation: An error occurred in the trigger
trying to remove a registration. If you are not program for Pruning Control table
trying to remove a registration, insert a row in IBMSNAP_PRUNCNTL in library ASN.
table IBMSNAP_REG_EXT with VERSION set to
5. SOURCE_OWNER and SOURCE_TABLE are User Response: Record the reason code and try
set to the appropriate values. SOURCE_NAME is to correct the problem. For example, for reason
set to the system name of the source table. code 60 (Could not find a matching row for
JRN_NAME and JRN_LIB should have the source table in index
journal name and its library name of the journal ASN/IBMSNAP_REG_EXTX) and reason code 90
the source table uses. SOURCE_TABLE_RDB (Could not find a matching row for source table
should be NULL if the source table is in the in table ASN/IBMSNAP_REGISTER) your action
same system, and should have the RDB name of could be to register the source table before trying
the system where the source table is at otherwise. to insert a row in the Prune Control table. For
SOURCE_VIEW_QUAL is set to the some other reason codes, it is possible that the
corresponding value in the registration. referenced table is temporarily unavailable. Your
action could be just to retry the task at a later
time. If the problem recurs, contact your system
administrator.

ASN2403 Internal error in trigger program. ASN6068 Cannot find a matching row in
IBMSNAP_REG_EXT.
Explanation: An error occurred in the trigger
program for Pruning Control table Explanation: See above under ″Messages from
IBMSNAP_PRUNCNTL in library ASN. Trigger Program for Register Table″.
User Response: Record the reason code and try User Response: See above under ″Messages
to correct the problem. If the problem recurs, from Trigger Program for Register Table″.
ASN2023 Error occurred on file.

Explanation: An error occurred when
processing the named file.
and try the request again.
ASN6022 Failed to read the journal list

from the PCB.
Explanation: Attempt to read the journal list
from the user space QZSNCTLBLK in library
ASN (the Primary Control Block) failed.
User Response: Check the message in the job
and try the request again.
ASN6025 Could not open table.

Explanation: See message(s) in the job log for
additional information about the reason why the
open failed.
User Response: Correct the problem and try the
request again.
ASN6067 Program QZSNDREP gets an

unexpected exception.
Explanation: The DataPropagator for AS/400
registered an exit program for deletion of journal
receivers. This delete receiver exit program
(QZSNDREP) gets an exception unexpectedly.
User Response: Check the job log of the job
that sent this message. Contact your system
administrator.

Part 5. Appendixes

Appendix A. Starting the Capture and Apply programs
from within an application
Instead of using the asnccp command to start the Capture program or the
asnapply command to start the Apply program, you can start the Capture
and Apply programs from within your application by calling routines. To use
these routines you must specify the AUTOSTOP option for the Capture
program and the COPYONCE option for the Apply program because only
synchronous execution is supported with this API.
This chapter describes the routines and the return codes, and it gives a sample
routine that starts the Capture and Apply programs.
Starting the Capture program using a routine

You can start the Capture program from within your application by calling
this routine:
#ifndef ASN_INCLUDE
#define ASN_INCLUDE
#define MAXASNPARMLENGTH 128
struct asnParm
{
short byteCount;
char val[MAXASNPARMLENGTH];
};
struct asnParms
{
int parmCount;
struct asnParm **parms;
};
int asnCapture(struct asnParms *pAsnParms);

#endif
This routine returns the following return codes:

0 The program ran successfully.
-1 The program did not run successfully.

Starting the Apply program using a routine
You can start the Apply program from within your application by calling this
routine:
#ifndef ASN_INCLUDE
#define ASN_INCLUDE
#define MAXASNPARMLENGTH 128
struct asnParm
{
short byteCount;
char val[MAXASNPARMLENGTH];
};
struct asnParms
{
int parmCount;
struct asnParm **parms;
};
int asnApply(struct asnParms *pAsnParms);
#endif
This routine returns the following return codes:

0 The Apply program ran successfully.
1 The Apply program ran successfully; however, a conflict was detected
in at least one subscription set. As a result, one or more rejected
transactions were compensated.
-1 The Apply program did not run successfully.
Sample routine that starts the Capture and Apply programs

The following sample routine starts the Capture and Apply programs:
#include <stdlib.h>
#include <string.h> /* for strcpy, strlen */
#include <asn.h> /* replication API parameters */
/* helper function to dump out parameter contents */

int printParms( const struct asnParms parms )
{
int count = 0;
if( parms.parmCount > 0 )
{
for( count=0; count<parms.parmcount>val );
printf( " bytes = %d\n", parms.parms[count]->byteCount );
}
return(0);
}

else
return(-1);
}
int main(int argc, char** argv)

{
struct asnParms captureParms;
struct asnParms applyParms;
struct asnParm *currParm;
int rc = 0;
int count = 0;
/* allocate and initialize capture parameter structure */

captureParms.parmCount = 4;
captureParms.parms =
(struct asnParm **)malloc(captureParms.parmCount * sizeof(struct asnParm*));
currParm = (struct asnParm *)malloc(sizeof(struct asnParm));

strcpy( currParm->val, "SRCESRV" );
currParm->byteCount = strlen( currParm->val );
captureParms.parms[0] = currParm; /* first capture parameter */

strcpy( currParm->val, "WARM" );
captureParms.parms[1] = currParm; /* second capture parameter */

strcpy( currParm->val, "NOPRUNE" );
captureParms.parms[2] = currParm; /* third capture parameter */

strcpy( currParm->val, "AUTOSTOP" );
captureParms.parms[3] = currParm; /* fourth capture parameter */
rc = printParms( captureParms ); /* print parameters out to verify */
rc = asnCapture(&captureParms;);
if( rc!=0 )
printf("Capture failed with rc = %d\n", rc );
else
printf("Capture completed successfully\n" );
/* allocate and initialize capture parameter structure */

applyParms.parmCount = 3;
applyParms.parms =
(struct asnParm **)malloc(applyParms.parmCount * sizeof(struct asnParm*));

strcpy( currParm->val, "APPLYQUAL" );
applyParms.parms[0] = currParm; /* first capture parameter */
Appendix A. Starting the Capture and Apply programs from within an application 399
strcpy( currParm->val, "CNTLSRV" );
applyParms.parms[1] = currParm; /* second capture parameter */

strcpy( currParm->val, "COPYONCE" );
applyParms.parms[2] = currParm; /* third capture parameter */
rc = asnApply(&applyParms;);
if( rc!=0 )
printf("Apply failed with rc = %d\n", rc );
else
printf("Apply completed successfully\n" );
for(count = 0; count<= captureParms.parmCount; count++)

free( captureParms.parms[count] );
free( captureParms.parms );
for(count = 0; count<= applyParms.parmCount; count++)

free( applyParms.parms[count] );
free( applyParms.parms );
return(rc);
}

Appendix B. Education and services for DB2 data
replication
This appendix describes the services and education available for DB2 data
replication.
Services
IBM and IBM Business Partners offer consulting and services supporting the
DB2 data replication solution. Customized services are available in addition to
service offerings that help you:
v Plan and design your application.
v Install, configure, and integrate the products.
v Evaluate operational and tuning considerations.
v Evaluate application and data migration.
v Educate and train staff.
For additional information on IBM products and services, contact your IBM
software provider, or, in the U.S. and Canada, call 1-800-IBM-3333.
Education
The following classes are provided by IBM Education and Training:
v Data Replication: Basic Usage (DW140)
v Data Replication: Advanced Usage (DW150)
Details about these courses can be found at the following site on the World
Wide Web: http://www.ibm.com/software/data/dpropr/education.html
General Education Information on the Web
IBM Education and Training information is available on the Web. You
can access the entire curriculum of courses directly from the IBM
Global Campus Web site: http://www.training.ibm.com/ibmedu
Custom Classes
Replication courses can be tailored to address your unique
environment and needs. To find out more information, call
1-800-IBM-TEACH, Ext. CUSTOM (800-426-8322, Ext. CUSTOM).
IBM Employees: For complete course descriptions, see the
EDUCATION application on HONE or MSE.

Appendix C. Notices
Any reference to an IBM licensed program in this publication is not intended
to state or imply that only IBM’s licensed program may be used. Any
functionally equivalent product, program or service that does not infringe any
of IBM’s intellectual property rights may be used instead of the IBM product,
program, or service. Evaluation and verification of operation in conjunction
with other products, except those expressly designated by IBM, is the user’s
responsibility.
IBM may have patents or pending patent applications covering subject matter
in this document. The furnishing of this document does not give you any
license to these patents. You can send license inquiries, in writing, to the
IBM Director of Licensing
IBM Corporation
North Castle Drive
Armonk, NY 10504-1785
U.S.A.
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
1150 Eglinton Ave. East
North York, Ontario
M3C 1H7
CANADA
Such information may be available, subject to appropriate terms and

conditions, including in some cases, payment of a fee.
This publication may contain 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.

Programming interface information
This book describes intended programming interfaces that allow the customer
to write programs to obtain the services of IBM Replication. This information
is identified where it occurs by an introductory statement to a chapter or
section.
This book also documents information that is NOT intended to be used as

programming interfaces of IBM Replication. Do NOT use diagnosis,
modification, or tuning information as a programming interface. This
information is identified where it occurs by an introductory statement to a
chapter or section.
Trademarks
The following terms are trademarks or registered trademarks of the IBM
Corporation in the United States and/or other countries:
ACF/VTAM MVS/ESA
ADSTAR MVS/XA
AISPO OS/400
AIX OS/390
AIXwindows OS/2
AnyNet PowerPC
APPN QMF
AS/400 RACF
CICS RISC System/6000
C Set++ SP
C/370 SQL/DS
DATABASE 2 SQL/400
DataHub S/370
DataJoiner System/370
DataPropagator System/390
DataRefresher SystemView
DB2 VisualAge
DB2 Connect VM/ESA
DB2 Universal Database VSE/ESA
Distributed Relational VTAM
Database Architecture WIN-OS/2
Extended Services
FFST
First Failure Support Technology
IBM
IMS
Lan Distance

Trademarks of other companies
The following terms are trademarks or registered trademarks of the
companies listed:
C-bus is a trademark of Corollary, Inc. in the United States, other countries, or

both.
HP-UX is a trademark of Hewlett-Packard.
Java, HotJava, Solaris, Solstice, and Sun are trademarks of Sun Microsystems,
Inc.
Microsoft, Windows, Windows NT, Visual Basic, and the Windows logo are
trademarks or registered trademarks of Microsoft Corporation in the United
States, other countries, or both.
PC Direct is a trademark of Ziff Communications Company in the United

States, other countries, or both and is used by IBM Corporation under license.
ActionMedia, LANDesk, MMX, Pentium, and ProShare are trademarks of Intel

Corporation in the United States, other countries, or both.
UNIX is a registered trademark in the United States, other countries or both

and is licensed exclusively through X/Open Company Limited.
Other company, product, or service names, which may be denoted by a

double asterisk (**), may be trademarks or service marks of others.
Appendix C. Notices 405

Glossary
A multiple rows of information by the
communications subsystem so that each FETCH
after-image. The updated content of a source statement does not require the transmission of
table column that is recorded in a change data one row for each request across the network.
table, or in a database log or journal. Contrast Contrast with data blocking.
with before-image.
C
Apply program. A program that is used to
refresh or update a target table, depending on Capture program. A program that reads
the applicable source-to-target rules. Contrast database log or journal records to capture data
with Capture program and Capture trigger. about changes made to DB2 source tables.
Contrast with Apply program and Capture trigger.
Apply qualifier. A case-sensitive character
string that identifies subscription sets that are Capture trigger. A mechanism that captures
unique to an instance of the Apply program. delete, update, and insert operations performed
on non-IBM source tables. Contrast with Capture
archive log. The set of log files that are closed
program and Apply program.
and are no longer needed for normal processing.
These files are retained for use in roll-forward cascade rejection. The process of rejecting a
recovery. Contrast with active log. replication transaction because it is associated
with a transaction that had a conflict detected
audit trail. Data, in the form of a logical path
and was itself rejected.
linking a sequence of events, used for tracing the
transactions that affected the contents of a record. CCD table. Consistent-change-data table.
B CD table. Change data table.
change aggregate table. A type of target table

base aggregate table. A type of target table that
that contains data aggregations based on changes
contains data aggregated from a source table or a
recorded for a source table.
point-in-time table at intervals.
change data (CD) table. A replication control
before-image. The content of a source table
table at the source server that contains changed
column prior to a refresh, as recorded in a
data for a replication source table.
change data table, or in a database log or journal.
Contrast with after-image. character large object (CLOB). A sequence of
characters (single-byte, multibyte, or both) where
binary large object (BLOB). A sequence of
the length can be up to 2 gigabytes. This data
bytes, where the size of the sequence ranges
type can be used to store large text objects. Also
from 0 to 2 gigabytes. This string does not have
called character large object string.
an associated code page and character set. Image,
audio, and video objects are stored in BLOBs. client. Any program (or workstation that it is
running on) that communicates with and
BLOB. Binary large object.
accesses a database server.
blocking. An option that is specified when
CLOB. Character large object.
binding an application. It allows caching of

cold start. The process of starting the Capture control table. A table in which replication
program using an initial program load source and subscription definitions or other
procedure. Contrast with warm start. replication control information is stored.
complete CCD table. A CCD table that contains

all the rows that satisfy the source view and D
predicates from the source table or view.
database log. A set of primary and secondary
Contrast with noncomplete CCD table.
log files consisting of log records that record all
condensed. A table attribute indicating that the changes to a database. The database log is used
table contains current data rather than a history to roll back changes for transactions that are not
of changes to the data. A condensed table committed and to recover a database to a
includes no more than one row for each primary consistent state.
key value in the table. As a result, a condensed
database management system (DBMS).
table can be used to supply current information
Synonym for database manager.
for a refresh.
database manager. A computer program that
condensed CCD table. A CCD table that
manages data by providing the services of
contains only the most current value for a row.
centralized control, data independence, and
This type of table is useful for staging changes to
complex physical structures for efficient access,
remote locations and for summarizing hot-spot
integrity, recovery, data currency control, privacy,
updates. Contrast with noncondensed CCD table.
and security.
conflict detection. In update-anywhere
database server. A functional unit that provides
replication configurations;
database services for databases.
v The process of detecting constraint errors.
v The process of detecting if the same row was data blocking. The process of specifying how
updated in the source and target tables during many minutes worth of change data will be
the same replication cycle. When a conflict is replicated during a subscription cycle. Contrast
detected, the transaction that caused the with blocking.
conflict is rejected. See also enhanced conflict
detection, standard conflict detection, and DataJoiner Replication Administration (DJRA)
row-replica conflict detection. tool. DJRA tool.
consistent-change-data (CCD) table. A type of DBCLOB. Double-byte character large object.

target table that is used for auditing or staging
DBMS. Database management system.
data or both. See also complete CCD table,
condensed CCD table, external CCD table, internal delimited identifier. A sequence of characters
CCD table, noncomplete CCD table, and enclosed within quotation marks (″). The
noncondensed CCD table. sequence must consist of a letter followed by
zero or more characters, each of which is a letter,
Control Center. A graphical user interface that
a digit, or the underscore character.
shows database objects (such as databases and
tables) and their relationship to each other. From differential refresh. A process in which only
the Control Center you can perform tasks on changed data is copied to the target table,
DB2 database objects. Contrast with DJRA tool. replacing existing data. Contrast with full refresh.
control server. The database location of the distinct type. A user-defined data type that is
applicable subscription definitions and Apply internally represented as an existing type (its
program control tables. source type), but is considered to be a separate

and incompatible type for semantic purposes. See G
also user-defined type (UDT).
gap. A situation in which the Capture program
DJRA tool. A database administration tool that
is not able to read a range of log or journal
you can use to perform various replication
records, so there is potential loss of change data.
administration tasks. Unlike the Control Center,
the DJRA tool can also be used to administer group. In Satellite Edition, a collection of
replication for non-IBM databases. Contrast with satellites that share characteristics such as
Control Center. database configuration and the application that
runs on the satellite.
double-byte character large object (DBCLOB).
A sequence of double-byte characters, where the
size can be up to 2 gigabytes. This data type can H
be used to store large double-byte text objects.
Also called double-byte character large object string. hot-spot updates. Updates made repeatedly to
Such a string always has an associated code the same rows over a short period of time.
page.
I
E
internal CCD table. A CCD table that cannot be
enhanced conflict detection. Conflict detection subscribed to directly. It does not have its own
that guarantees data integrity among all replicas row in the register table; it is referenced as
and the source table. The Apply program locks CCD_OWNER and CCD_TABLE in the row for
all replicas or user tables in the subscription set the associated replication source. Contrast with
against further transactions, and begins detection external CCD table.
after all changes made prior to locking have been
captured. See also conflict detection, standard interval timing. The simplest method of
conflict detection, and row-replica conflict detection. controlling when to start a subscription cycle.
You must specify a date and a time for a
event timing. The most precise method of subscription cycle to start, and set a time interval
controlling when to start a subscription cycle. that describes how frequently you want the
Requires that you specify an event and the time subscription cycle to run. Contrast with event
when you want the event processed. Contrast timing and on-demand timing.
with interval timing and on-demand timing.
external CCD table. A CCD table that can be

J
subscribed to directly. It has its own row in the join. A relational operation that allows for
register table, where it is referenced as retrieval of data from two or more tables based
SOURCE_OWNER and SOURCE_TABLE. on matching column values.
Contrast with internal CCD table.
K
F
key. A column or an ordered collection of
full refresh. A process in which all of the data columns that are identified in the description of a
of interest in a user table is copied to the target table, index, or referential constraint.
table, replacing existing data. Contrast with
differential refresh.
Glossary 409
L an absence of a value. For example, a field for a
person’s middle initial does not require a value.
large object (LOB). A sequence of bytes, where
null value. A parameter for which no value is
the length can be up to 2 gigabytes. It can be any
specified.
of three types: BLOB (binary), CLOB (single-byte
character or mixed) or DBCLOB (double-byte
character). O
LOB. Large object. object. (1) Anything that can be created or
manipulated with SQL—for example, tables,
local database. A database that is physically views, indexes, or packages. (2) In object-oriented
located on the workstation in use. Contrast with design or programming, an abstraction consisting
remote database. of data and operations associated with that data.
lock. (1) A means of serializing events or access ODBC. Open Database Connectivity.
to data (2) A means of preventing uncommitted
changes made by one application process from ODBC driver. A driver that implements ODBC
being perceived by another application process function calls and interacts with a data source.
and for preventing one application process from
updating data that is being accessed by another on-demand timing. A method for controlling
process the timing of replication for occasionally
connected systems. Requires that you use the
locking. The mechanism used by the database ASNSAT program to operate the Capture and
manager to ensure the integrity of data. Locking Apply programs. Contrast with event timing and
prevents concurrent users from accessing interval timing.
inconsistent data.
Open Database Connectivity (ODBC). An API
that allows access to database management
M systems using callable SQL, which does not
require the use of an SQL preprocessor. The
member. See subscription-set member.
ODBC architecture allows users to add modules,
called database drivers, that link the application
N to their choice of database management systems
at run time. Applications do not need to be
nickname. A name that is defined in a DB2 linked directly to the modules of all the
DataJoiner database to represent a physical supported database management systems.
database object (such as a table or stored
procedure) in a non-IBM database. ordinary identifier. In SQL, a name that is
made up of a letter, which might be followed by
noncomplete CCD table. A CCD table that is zero or more characters, each of which is a letter
empty when it is created and has rows appended (a-z and A-Z), a symbol, a number, or the
to it as changes are made to the source. Contrast underscore character.
with complete CCD table.
noncondensed CCD table. A CCD table that P

contains the history of changes to the values for
a row. This type of table is useful for auditing package. A control structure produced during
purposes. Contrast with condensed CCD table. program preparation that is used to execute SQL
statements.
nullable. The condition where a value for a
column, function parameter, or result can have point-in-time table. A type of target table
whose content matches all or part of a source

table, with an added system column that type of table can accept copy requests and is the
identifies the approximate time when the source table in a subscription set. See also
particular row was inserted or updated at the subscription set.
source system.
remote database. A database that is physically
predicate. An element of a search condition that located on a workstation other than the one in
expresses or implies a comparison operation. use. Contrast with local database.
primary key. A unique key that is part of the row-replica. A type of update-anywhere replica
definition of a table. A primary key is the default maintained by DataPropagator for Microsoft Jet
parent key of a referential constraint definition. without transaction semantics.
row-replica conflict detection. Conflict

R detection done row by row, not transaction by
transaction, as is done for DB2 replicas.
RDBMS. Relational database management
system.
S
referential constraint. The referential integrity
rule that the nonnull values of the foreign key satellite. An occasionally connected client
are valid only if they also appear as values of a machine that has a DB2 server that synchronizes
parent key. with its group at the satellite control database.
referential integrity. The state of a database in Satellite Administration Center. A user

which all values of all foreign keys are valid. interface that provides centralized administrative
support for satellites.
refresh. A process in which all of the data of
interest in a user table is copied to the target satellite control server. A DB2 Universal
table, replacing existing data. See also full refresh Database system that contains the satellite
and differential refresh. control database, SATCTLDB.
registration. See replication source. serialization. (1) The consecutive ordering of

items. (2) In DB2 Universal Database for AS/400,
registration process. The process of defining a the process of controlling access to a resource to
replication source. Contrast with subscription protect the integrity of the resource.
process.
source server. The database location of the
rejected transaction. A transaction containing replication source and the Capture program.
one or more updates from replica tables that are
out of date in comparison to the source table. source table. A table that contains the data that
is to be copied to a target table. The source table
replica target table. A replication table at the can be a replication source table, a change data
target server that is a type of update-anywhere table, or a consistent-change-data table. Contrast
target table. with target table.
replication. The process of maintaining a spill file. A temporary file created by the Apply
defined set of data in more than one location. It program that is used as the source for updating
involves copying designated changes for one data to multiple target tables.
location (a source) to another (a target), and
synchronizing the data in both locations. staging table. A CCD table that can be used as
the source for updating data to multiple target
replication source. A database table or view tables.
that is defined as a source for replication. This
Glossary 411
standard conflict detection. Conflict detection action or result. Examples are the entry of a
in which the Apply program searches for customer’s deposit and the updating of the
conflicts in rows that are already captured in the customer’s balance.
change data tables of the replica or user table.
See also conflict detection, enhanced conflict trigger. In DB2, an object in a database that is
detection, and row-replica conflict detection. invoked indirectly by the database manager
when a particular SQL statement is run.
subscription. See subscription set.
two-phase commit. A two-step process by
subscription cycle. A process in which the which recoverable resources and an external
Apply program retrieves changed data for a subsystem are committed. During the first step,
given subscription set, replicates the changes to the database manager subsystems are polled to
the target table, and updates the appropriate ensure that they are ready to commit. If all
replication control tables to reflect the progress it subsystems respond positively, the database
made. manager instructs them to commit.
subscription process. A process in which you

define subscription sets and subscription-set U
members. Contrast with registration process.
UDT. User-defined type.
subscription set. The specification of a group of
uncommitted read (UR). An isolation level that
source tables, target tables, and the control
allows an application to access uncommitted
information that governs the replication of
changes of other transactions. The application
changed data. See also subscription-set member.
does not lock other applications out of the row
subscription-set member. A member of a that it is reading unless the other application
subscription set. There is one member for each attempts to drop or alter the table.
source-target pair. Each member defines the
Unicode. An international character encoding
structure of the target table and which rows and
scheme that is a subset of the ISO 10646
columns will be replicated from the source table.
standard. Each character supported is defined
using a unique 2-byte code.
T
unit-of-work (UOW) table. A replication control
target server. The database location of the target table at the source server that contains commit
table. Normally this is also the location of the records read from the database log or journal.
Apply program. The records include a unit-of-recovery ID that
can be used to join the unit-of-work table and
target table. The table on the target server to the change data table to produce
which data is copied. It can be a user copy table, transaction-consistent change data. For DB2, the
a point-in-time table, a base aggregate table, a unit-of-work table optionally includes the
change aggregate table, a consistent-change-data correlation ID, which can be useful for auditing
table, or a replica table. purposes.
temporary table. A table created during the UR. Uncommitted read.

processing of an SQL statement to hold
intermediate results. user copy table. A target table whose content
matches all or part of a source table and contains
transaction. An exchange between a only user data columns.
workstation and a program, two workstations, or
two programs that accomplishes a particular

user-defined type (UDT). A data type that is
not native to the database manager and was
created by a user. See also distinct type.
user table. A table created for and used by an

application before it is defined as a replication
source. It is used as the source for updates to
read-only target tables, consistent-change-data
tables, replicas, and row-replica tables.
V
view. A logical table that consists of data that is
generated by a query.
W
warm start. A start of the Capture program that
allows reuse of previously initialized input and
output work queues. Contrast with cold start.
work file. A temporary file used by the Apply

program when processing a subscription set.
Glossary 413
Index
Apply program (continued) Apply program (continued)
Special Characters configuring 44, 142 post-installation tasks 142
-1032 170
connectivity 65 problem determination 153
-206 170
data blocking 68 processing cycle 124
-330 168
for AS/400 processor requirements 61
-741 82
installing 176 push and pull configurations 66
-805 169
invocation parameters 210 run-time processing
$TA JES2 command 234
operating 207 statements 74
Numerics scheduling 217 setting up 131
0509 168 setting up 175, 176 spill files, storage
1067 168 starting 210 requirements 62, 65
1108 170 stopping 217 starting
22517 168 using remotely 207 after Capture program cold
51002 169 for OS/390 start 142
57019 170 installing 225 example for Windows 45
invocation parameters 232 instructions 142
A operating 225, 231 overview 54
activating subscription sets 148 scheduling 234 starting with event 114
active log size 63 setting up 225 stopping example for
ADDEXITPGM command 195 starting 232 Windows 49
ADDJOBSCDE command 217 stopping 234 synchronization with Capture
administration for UNIX platforms triggers 88
authorization requirements 104 binding 240 trace files 155
timing recommendation 61 configuring 240 user ID 105
administration interfaces invocation parameters 252 Apply qualifier 13, 40
Control Center 5 operating 239, 250 Apply-qualifier-cross-reference
DJRA (DataJoiner Replication scheduling 254 tables 317
Administration) tool 5 setting up 239 Apply trail tables
overview 5 starting 251 description 336
after-image columns 10, 72 stopping 254 problem determination 153
aggregate tables 15 for Windows and OS/2 archived log restrictions 77
See also base aggregate tables, binding 44, 264 archiving information, example 24
change aggregate tables 15 configuring 264 AS/400 server
analyzing invocation parameters 276 connecting to 176
Apply program performance 56, operating 263, 275 ASCII tables 79
163 scheduling 278 ASN0000E message 167
Capture program Service Control Manager for
ASNAPPLY command
performance 56, 163 Windows 266
for UNIX platforms 251
ANZDPRJRN command 194 setting up 263
for Windows and OS/2 276
APF authorization 143, 166 starting 275
application data prerequisites 51 ASNARUN command 232
stopping 278
Applications full versus differential refresh 10 ASNCCP command
starting Capture program gap detection 147 for UNIX platforms 245
from 397 introduction 7 for VM and VSE 256
Apply job tables 340 log file 156 for Windows and OS/2 269
apply_names.ini file 144 messages 152, 368 ASNCMD command
Apply program mini-cycles 68 for UNIX platforms 247
Apply qualifier 13 operating 142 for Windows and OS/2 271
authorization requirements 105 performance 144 ASNDLCOPY exit routine
capacity planning 61 configuration files 136

ASNDLCOPY exit routine authorization requirements Capture program (continued)
(continued) Capture and Apply for AS/400 (continued)
input 134 programs 104 current receiver size 63
parameters 134 for AS/400 181 error recovery 159
using 133 initializing 203
ASNDLCOPYD file-copy daemon B installing 176
using 136 base aggregate tables journal entry types 205
defining 116 journals and journal receivers,
ASNDONE exit routine
description 345 managing 193
for AS/400 220
introduction 15 operating 197
rejected transactions 108
before-image columns performance options 179
using 132
auditing 88 problem determination 159
ASNJDONE exit routine 287 change-aggregate tables 118 progress, determining 201
ASNJET command 285 introduction 10 pruning 205
ASNJSTOP command 286 replicating 72 restrictions 190
ASNL2RNx command 227 restrictions 73 scheduling 202
ASNLOAD exit routine binary data types 78 setting up 175, 176
error handling 132 binary large object (BLOB) 74, 79 starting 197
files generated 131, 132 BIND PACKAGE utility 56 starting automatically 201
for AS/400 binding stopping 202
parameters 222 Apply program tuning parameters 178, 179
samples 221 for UNIX platforms 240 warm start parameter 205
refreshing point-in-time for Windows and OS/2 264 for OS/390
tables 131 Capture program alert generation 159
restrictions 132 for UNIX platforms 240 captured log progress 231
ASNSAT command 279 for Windows 44 cold start parameter 228
ASNSTOP command for Windows and OS/2 264 installing 225
host RDBMSs 94 operating 225, 227
BLOB (binary large object) 74, 79 pruning 231
blocking factor 68, 122 reinitializing 230
asynchronous replication
restrictions 227
scheduling 17 C resuming 230
suitable configurations 19 CALL procedures scheduling 229
unsuitable configurations 19 before and after run-time setting up 225
AT command processing 74 starting 227
Apply program defining for subscription set 121 stopping 230
for UNIX platforms 254 capacity planning 61 suspending 230
for Windows 278 Capture enqueue tables 313 warm start parameter 228
Capture program Capture program for UNIX platforms
for UNIX platforms 244 authorization requirements 104 binding 240
for Windows 271 capacity planning 61 cold start parameter 245
AT NetView command cold start configuring 239
Apply for OS/390 234 automatic 141 log progress, displaying 249
Capture for OS/390 229 first 142 log sequence number 249
preventing 142 operating 239, 243
auditing
configuring 43, 139 pruning 249
archive information 24 connectivity 65
cold start 88 reinitializing 248
error recovery 158 restrictions 243
data usage 88 for AS/400 159
gap in data 88 resuming 248
errors 156 scheduling 244
using CCD tables 83, 86 for AS/400 setting environment
authentication, end-user attributes, changing 179 variables 244
for DataPropagator for Microsoft authorization setting up 239
Jet 284 requirements 181 starting 244, 397
for UNIX platforms 241 cold start, automatic 205 stopping 247
for Windows and OS/2 265 cold start parameter 205

Capture program (continued) Capture program (continued) CCD (consistent-change-data) tables
suspending 247 restrictions 130 (continued)
warm start parameter 245 setting up 128 types of 15, 84
for VM and VSE staging data 82 unique indexes 83
active log size 63 starting update-anywhere replication 82
cold start parameter 257 example for Windows 45 with DB2 Enterprise - Extended
log progress, displaying 261 instructions 139 Edition 77
log sequence number 261 overview 54 CCSID translation 168
operating 255 stopping CD (change data) tables
pruning 260 example for Windows 49 description 82, 321
reinitializing 260 storage dump 159 maximum size 64
restrictions 255 trace buffer 158 pruning 88
resuming 259 trace file 157 storage requirements 64
setting up 255 trace output 159 change aggregate tables
starting 256 trace table problem defining 116
stopping 258 determination 157 description 346
suspending 259 user ID 104 introduction 15
warm start parameter 257 warm start 141, 142 change-capture
for Windows and OS/2 Capture triggers components 6
binding 43, 264 capturing changes 80 for CCD tables 16
cold start parameter 270 introduction 6, 80 process
configuring 263 maintaining CCD tables 16 restarting 55
log progress, displaying 274 pre-existing triggers 81 starting 54
log sequence number 274 relationships to other tables 81 change data (CD) tables
operating 263, 268 synchronization with Apply description 82, 321
pruning 274 program 88 maximum size 64
reinitializing 273 captured log progress pruning 88
restrictions 268 for OS/390 231 storage requirements 64
resuming 273 for UNIX platforms 249 changing
scheduling 271 for VM and VSE 261 replication sources 147
Service Control Manager for for Windows and OS/2 274 subscription sets 149
Windows 266 character large object (CLOB) 74, 79
cascade full refresh 85
setting environment CHGDPRCAPA command 179
CCD (consistent-change-data) tables
variables 268 CHGJRN command 194
setting up 263 as replication sources 84, 111
classes, education 401
starting 269 attributes of 82
Capture triggers 80 clients, satellite 22
stopping 271 CLOB (character large object) 74, 79
suspending 272 change-capture mechanisms 16
complete 83 cloning subscription sets 148
warm start parameter 270
condensed 83, 343 CNTRLSVR.REX file 100
gap detection 147
defining 111, 116 cold start
introduction 6
description 82, 343 automatic 141
log file 158
external 85, 126 Capture program
messages 152, 353
internal 85 for AS/400 205
nonrelational data sources,
internal CCD for multiple for OS/390 228, 257
identifying 87
targets 87 for UNIX platforms 245
operating 139
local 83 for Windows and OS/2 270
post-installation tasks 139
maintaining external 126 general 141, 353
problem determination 156
non-IBM data sources 87 first 142
processor requirements 61
noncomplete 83 gaps 147
pruning
noncondensed 83 preventing 142
CD tables 88
example 48 nonrelational data sources 87 columns
reinit command 106 pruning 88, 145 after-image 10, 72
replication sources, recognizing remote 83 available for replication 70
new 106 restriction 20 before-image 10, 72
staging changed data 82 changing definition 117
Index 417
columns (continued) commands (continued) commands (continued)
computed 74, 118 CRTJRN 193 SUSPEND
creating new in target table 118 CRTJRNRCV 192 for OS/390 230
defining in target table 116 CRTSQLPKG 207 for UNIX platforms 247
names, restrictions 73 DB2FLSN for VM and VSE 259
primary key, specifying 117 for UNIX platforms 249 for Windows and OS/2 272
relative record numbers on DBFLFSN WRKRDBDIRE 209, 219
AS/400 196 for Windows and OS/2 274 WRKREGINF 195
removing from target table 117 DSPJRN 202 WRKSBMJOB 159
renaming 73, 117 ENDDPRAPY 217 WRKSBSJOB 159
subsetting ENDDPRCAP 202 commit interval 129
DB2 Control Center 116 ENDJOB 203 communication
DJRA 118 GETLSEQ log-based 8
introduction 13 for OS/390 231 trigger-based 9
planning 70 for UNIX platforms 249 complete CCD tables 15, 83
commands for VM and VSE 261 components
for Windows and OS/2 274 See also Apply program, Capture
$TA JES2 GRTDPRAUT 181
Apply for OS/390 234 program, Capture triggers,
INZDPRCAP 203 Control Center, DJRA (DB2
Capture for OS/390 229 LOADX 45
ADDEXITPGM 195 DataJoiner Replication
PRUNE Administration) tool 3
ADDJOBSCDE 217
for OS/390 231 administration interfaces 5
ANZDPRJRN 194 for UNIX platforms 249
ASNAPPLY communication between 7
for VM and VSE 260 introduction 3
for UNIX platforms 251 for Windows and OS/2 274
for Windows and OS/2 276 computed columns 74, 118
RCVJRNE 193 concepts
ASNARUN 232 REINIT
ASNCCP after-image columns 10
for OS/390 230
for UNIX platforms 245 Apply qualifier 13
for VM and VSE 256 before-image columns 10
for VM and VSE 260
for Windows and OS/2 269 change capture 6
ASNCMD column subsetting 13
replication sources,
for UNIX platforms 247 conflict detection 11
recognizing new 106
for Windows and OS/2 271 control tables 4
REORG 56
ASNJET 285 differential-refresh copying 10
RESUME
ASNJSTOP 286 full-refresh copying 10
for OS/390 230
ASNL2RNx 227 joins 14
ASNSAT 279 logical servers 4
for VM and VSE 259
ASNSTOP replication 10
for UNIX platforms 254 replication sources 10
REVOKE 56
for Windows and OS/2 278 row subsetting 13
RGZPFM 56
AT subscription-set members 11
RMVEXITPGM 195
Apply for UNIX subscription sets 11
RUNSTATS 56
platforms 254 subsetting source tables 13
RVKDPRAUT 189
Apply for Windows 278 table partitioning 13
SBMJOB 202
Capture for UNIX target tables 14
STOP
platforms 244 unions 14
for OS/390 230
Capture for Windows 271 user tables 10
AT NetView views as sources 13
for VM and VSE 258
Apply for OS/390 234 condensed CCD tables
Capture for OS/390 229 introduction 15
STRDPRAPY 210
BIND PACKAGE 56 overview 83
STRDPRCAP 197
CHGDPRCAPA 179 updating 343
STRJRNPF 193
CHGJRN 194 configuration, replication
STRSBS 201
CRTDPRPKG 207 changing 55
CRTDPRTBL 178, 210 copying 55

configuration, replication (continued) Control Center (continued) control tables (continued)
modifying 147 configuring for host RDBMSs 94 error-side-information 289, 349
operating 55 connectivity 65 granting authority for
planning, overview 51 introduction 5 AS/400 181
setting up, overview 53 processor requirements 61 introduction 4
configuring replication sources key string 289, 349
Apply program changing 147 location of 52
for UNIX platforms 240 defining 105 point-in-time 342
for Windows and OS/2 264 removing 148 prune lock 316
Capture program rows, defining 118 pruning control 309
for UNIX platforms 239 setting preferences 95 pruning of, overview 55
for Windows and OS/2 263 setting up replication 93 quick reference
connectivity 65, 94 SQL statements and stored at a glance 293
Control Center for host procedures 121 control server 298
RDBMSs 94 subscription sets source server 296
conflict detection activating 148 target server 299
levels of 11, 106 changing 149 register 301
mobile environment 107 cloning 148 register extension 308
overview 107 deactivating 148 register synchronization 318
conflict tables 289, 348 defining 112 replica 345
connecting removing 149 revoking authority for
to AS/400 server 176 timing 123 AS/400 189
connectivity 65, 94 target-table type, choosing 115 row-replica 347
consistent-change-data (CCD) tables tutorial 35 row-replica-target-list 289, 333
user-defined tables 120 storage requirements 63
as replication sources 84, 111
attributes of 82 control servers subscription columns 329
Capture triggers 80 for DB2 replication 4 subscription events 335
change-capture mechanisms 16 location of 52 subscription-schema-
complete 83 changes 289, 334
control tables
condensed 83, 343 subscription set 323
Apply job 340 subscription statements 331
defining 111, 116 Apply-qualifier-cross- subscription-targets-member 326
description 82, 343 reference 317
external 85, 126 synchronization
Apply trail 336 generations 289, 350
internal 85 at the control server 298, 323 trace 316
internal CCD for multiple at the source server 296, 300
targets 87 tuning parameters 312
at the target server 299, 341 UOW 319
local 83 authorization requirements for user copy 341
maintaining external 126 AS/400 196 warm start 313
non-IBM data sources 87 base aggregate 345
noncomplete 83 warm start for VSE and VM 313
Capture enqueue 313
noncondensed 83 copies, types of refresh 10
CCD target 343
nonrelational data sources 87 CD 321 copying replication
pruning 88, 145 change aggregate 346 configuration 127
remote 83 conflict 289, 348 creating control tables
staging changed data 82 creating CRTDPRTBL command 177
types of 15, 84 DJRA 102 DJRA 102
unique indexes 83 DPCNTL files 100 DPCNTL files 100
update-anywhere replication 82 for AS/400 178 critical section tables 315
consolidating data 24 critical section 315 CRTDPRPKG command 207
constraints, referential 53 CRTDPRTBL command 177
CRTDPRTBL command 178, 210
consulting and services 401 customizing, example 38
CRTJRN command 193
Control Center DataPropagator for Microsoft
authorization requirements 104 Jet 289 CRTJRNRCV command 192
capacity planning 61 error information 289, 348 CRTSQLPKG command 207
columns, defining 116 error messages 289, 349 current receiver size 63, 193
Index 419
customizing DB2 DataJoiner diagnosing errors 151
DJRA 99 restrictions 79 differential-refresh copying 10
SQL files 103 setup 137 distinct data type 79
SQL for control tables 101 DB2 DataJoiner Replication distributing
table names 95 Administration (DJRA) tool data to remote sites 25
See DJRA (DB2 DataJoiner IMS data 27
D Replication Administration) DJRA (DB2 DataJoiner Replication
data tool 5 Administration) tool
accessing continuously 28 DB2 Extenders authorization requirements 104
consolidation configuration 20 restrictions 75 capacity planning 61
distributing to remote sites 25 DB2 File Manager 75 columns, defining 118
distribution configuration 19 DB2 for OS/390 connectivity 65
IMS, distributing 27 Apply program control tables, creating 102
manipulating source 13 operating 225 customizing 99
manipulating target 69 Capture program editing
prerequisites 51 operating 225 logic 99
data blocking 68 CCSID translation 168 SQL 103
data compression restrictions 77 data sharing 122 installing 98
data consistency 125 DB2 ODBC Catalog 235 introduction 5
data currency 123 index types 234 offline load 127
data encryption restrictions 78 password verification 66 overview 96
data integrity DB2 ODBC Catalog preferences 99
DataPropagator for Microsoft function calls 237 processor requirements 61
Jet 282 setting up server 236 promote functions 127
setting up workstation Replication Monitor 146
resolving gaps 147
client 235 replication sources
data manipulations 13, 69
tables 237 changing 147
data restrictions 77
Version 6 enhancements 235 defining 105
data sharing 122
DB2 Tools Settings notebook 95 removing 148
data types, restrictions 78 DB2FLSN command rows, defining 119
databases for UNIX platforms 249 running SQL 104
maintenance tasks 56, 145 for Windows and OS/2 274 setting up replication 96
non-IBM target tables 52 DB2INSTANCE SQL
DATALINK values starting Capture for UNIX 244 editing 103
ASNDLCOPY exit routine 133 starting Capture for Windows running 104
ASNDLCOPYD file-copy and OS/2 269 SQL statements and stored
daemon 136 DBCLOB (double-byte character procedures 122
link control level 112 large object) 74, 79 subscription sets
planning 75 DBLIB connections changing 149
DataPropagator for Microsoft Jet improving performance 144 defining 113
ASNJDONE parameters 288 Microsoft SQL Server 96 removing 149
ASNJET parameters 285 deactivating subscription sets 148 timing 123
control tables 289 decision support systems 29 target-table type, choosing 116
data integrity 282 defining targets supported 96
error recovery 288 replication source joins 108 using for AS/400
operating 285 replication sources 105 defining replication sources
setting up 283 subscription sets 40 and subscription sets 196
starting 285 delete journal receiver exit relative record numbers 175,
stopping 286 routine 194 196
terminology 282 Design Master 283 Replication Monitor 201
troubleshooting 287 designing DJX_ASYNC_APPLY variable 144
DataPropagator NonRelational overview 51 double-byte character large object
maintaining CCD tables 16 replication configurations 19 (DBCLOB) 74, 79
DB2 Control Center unsuitable configurations 19 DPCNTL files 101
See Control Center 5 detecting a gap 147 DPNCNTL files 101

DPREPL.DFT file 95 exit routines (continued)
DSPJRN command 202 delete journal receiver
I
IBM Software Support 171
dummy WHERE clause 119 (AS/400) 194
IMS DataPropagator
dump, storage 159 external CCD tables 126
data distribution example 27
overview 85
E planning multiple targets 87
using CCD tables 87
index types, rules for OS/390 234
EDITPROC 77
education F Informix
restrictions 80
custom classes 401 FIELDPROC
IBM Global Campus URL 401 restrictions, general 77 initializing Capture program for
ENDDPRAPY command 217 restrictions for Capture for VM AS/400 203
ENDDPRCAP command 202 and VSE 255 installation
ENDJOB command 203 Capture and Apply programs
files
environment for AS/400 176
apply_names.ini 144
for OS/390 225
copying, overview 55 CNTRLSVR.REX 100
planning, overview 51 DPCNTL 101
for VM and VSE 255
setting up, overview 53 DPNCNTL 101
DJRA 98
environment Analyzer 163 spill 62, 65
restrictions 90
environment variables SRCESVR.REX 100
services and consulting 401
Capture program TARGSVR.REX 100
internal CCD tables
for UNIX platforms 244 TBLSPACE.REX 99
overview 85
for Windows and OS/2 268 fragmentation
planning multiple targets 87
error information tables 289, 348 horizontal 71
interval-based timing 17
error messages tables 289, 349 update-anywhere
invocation parameters
error recovery replication 107
Apply program
AS/400 159 vertical 70
for AS/400 210
Capture and Apply full-refresh copying for OS/390 232
programs 152 Apply for AS/400 196, 214 for UNIX platforms 252
DataPropagator for Microsoft external CCD table 85 for Windows and OS/2 276
Jet 288 forcing in Apply for OS/390 169 Capture program
for OS/390, VM, and VSE 158 internal CCD table 85 for AS/400 197
error-side-information tables 289, introduction 10 for OS/390 228
349 suppressing in Apply for for UNIX platforms 245
errors, diagnosing 151 OS/390 169 for VM and VSE 256
event-based timing 17, 124 for Windows and OS/2 269
examples
G INZDPRCAP command 203
gap detection 88, 147
See also replication
configurations 23 generated SQL J
CD table, pruning 64 editing 103 joins
spill file size, setting 65 running 104 defining as sources 108
SQL for columns 117 GETLSEQ command for targets 14
WHERE clauses 25, 119 for OS/390 231 planning to use 53
exit routines for UNIX platforms 249 replicating 71
ASNDLCOPY for VM and VSE 261 journal receivers
configuration files 136 for Windows and OS/2 274 creating for source tables 192
input 134 global record 301 current, size 63
parameters 134 GROUP BY clause 118 delete journal receiver exit
using 133 GRTDPRAUT command 181 routine 194
ASNDONE managing 193
for AS/400 220 H system management 193
using 132 history data 88 threshold 193
ASNJDONE 287 horizontal subsets 71 user management 194
ASNLOAD host RDBMSs, configuring the journaling requirements 62
for AS/400 221 Control Center 94 journals
using 131 hot-site backup 19 creating 193
Index 421
journals (continued) messages occasionally connected
default message queue 194 Apply for AS/400 381 environments (continued)
entry types 205 Apply program 353, 368, 381 description 22
managing 193 Capture for AS/400 386 example configuration 31
problem determination 160 Capture program 353, 368 introduction 22
QSQJRN journal 191 delete receiver exit program 394 offline load 127
remote journal function 192 for problem determination 152 on-demand timing 18
starting 193 Trigger Program for Critical operating
use 191 Section Table 394 Apply program
Trigger Program for Prune example 54
K Control Table 393 for AS/400 207
KEEPDICTIONARY keyword 145 Trigger Program for Register for OS/390 231
key string tables 289, 349 Table 390 for UNIX platforms 250
key-update Microsoft Jet 280 for Windows and OS/2 275
restrictions 76 Microsoft SQL Server overview 142
DBLIB connections 96 Capture program
L improving performance 144 example 54
lag limit 129 restrictions 79 for AS/400 197
large object (LOB) 74, 79 migration for OS/390 227
large replication jobs 68 planning 89 for UNIX platforms 243
LE for OS/390 environment 168 services and consulting 401 for VM and VSE 255
legacy data sources 27 mini-cycles for Windows and OS/2 268
LOADX command Apply program 68 overview 139
ASNLOAD exit routine 131 defining for subscription set 122 DataPropagator for Microsoft
example 45 mobile replication Jet 285
LOB (large object) 74, 79 see also Microsoft Jet 280 overview 55
local cache for committed monitoring options, performance 128
changes 85 Capture program progress for ORA-04081 message 81
local CCD tables 83 AS/400 201 Oracle
log-based communication 8 introduction 56 restrictions 79
log file replication environment 146 overview 22
Apply program 156 multi-tier staging 85
Capture program 158 multiple source tables 24 P
log records, archived before multiple target tables 87 parameter definitions
captured 63 DataPropagator for Microsoft
log sequence number N Jet 285, 288
network connectivity 65 partitioning key 78
for OS/390 231
non-DB2 distributed data store 32 password files
non-DB2 reports creating, example 44
for VM and VSE 261
query database 33 for Apply program
non-IBM data sources 87 for UNIX platforms 242
logging requirements 62
noncomplete CCD tables 15, 83 for Windows and OS/2 265
logic, editing DJRA 99
noncondensed CCD tables 15, 83 password verification, DB2 for
logical partitioning keys OS/390 66
nonrelational data sources 87
description 109 performance
NT Service Control Manager
row subsets 71, 81 improving 144
Apply for Windows 266
logical servers 4 Capture for Windows 266 options 128
LONG VARCHAR data type 79 NT Services troubleshooting, introduction 56
LONG VARGRAPHIC data type 78 starting Apply program 275 planning
starting Capture program 269 active log size 63
M capacity 61
maintenance O conflict detection 107
database 145 Object Rexx 98 migration 89
overview of tasks 56 occasionally connected environments multiple target tables 87
MAX_SYNCH_MINUTES 68, 122 See also satellite replication, network 65
members, subscription-set 11 Microsoft Jet 22 overview 51

planning (continued) prune interval 129 remote
security 104 prune lock tables 316 Apply program
services and consulting 401 pruning for AS/400 207
staging data 82, 85, 87 Capture program remote CCD tables 83
storage requirements 61 for AS/400 205 remote journal
point-in-time tables for OS/390 231 restrictions 78
defining 115 for UNIX platforms 249 remote journal function 192
description 342 for VM and VSE 260 remote journaling 68
introduction 15 for Windows and OS/2 274 removing
predicates, defining for target CCD tables 145 replication sources 148
tables 118 CCD tables, with Capture subscription sets 149
PREDICATES column capacity 71 triggers 88 renaming columns 73, 117
preferences, setting CD tables 88 REORG utility 56, 145
DB2 Control Center 95 control tables 55, 309 replica tables
DJRA 99 example 48 See also row-replica tables 16
PREFORMAT keyword 145 UOW tables 88, 319 defining 116
primary keys push and pull Apply program description 345
logical partitioning 109 configurations introduction 16
relative record numbers for choosing a configuration 68 Replication Analyzer 56, 163
AS/400 196 description 66 replication configurations
problem determination accessing data continuously 28
administration 152
Q auditing archive information 24
questions, problem data consolidation 20, 24
alert generation for OS/390 159
determination 171 data distribution 19, 25
Apply program 153
decision support systems 29
Apply trail table 153 R examples of 23
Capture program RCVJRNE command 193
for AS/400 159 IMS data, distributing 27
read dependencies 108
for OS/390, VM, and occasionally connected
real-time replication 19 systems 22, 31
VSE 158
receiver size, current 63 replicating operational data 33
Capture program trace table 157
referential constraints 53, 78 retrieving data 32
collecting data (AS/400) 160
referential integrity 125 typical 19
errors
Capture program 156 refresh update-anywhere 21
IBM Software Support 171 differential 10 replication environment
journal 160 full 10 copying 127
log file suppressing for Apply for operating 55
Apply program 156 OS/390 169 setting up 53
Capture program 158 register extension tables 308 starting to replicate 54
scenario 152 register synchronization tables 318 updating 55
storage dump 159 register tables 126, 301 replication messages 353, 381
trace buffer 158 REINIT command Replication Monitor
trace file for OS/390 230 introduction 56
Apply program 155 for UNIX platforms 248 overview 146
Capture program 157 for VM and VSE 260 using for AS/400 201
trace output 159 for Windows and OS/2 273 replication sources
WRKSBMJOB command 159 reinitializing Capture program CCD (consistent-change-data)
WRKSBSJOB command 159 for OS/390 230 tables as 84
programming interface for UNIX platforms 248 changing 147
information 404 for VM and VSE 260 DATALINK values 75
promote functions 127 for Windows and OS/2 273 defining
PRUNE command relative record numbers example 36, 39
for OS/390 231 as primary key for AS/400 196 for AS/400 196
for UNIX platforms 249 push configuration 68 joins 108
for VM and VSE 260 support for AS/400 175 overview 105
for Windows and OS/2 274 relative timing 123 introduction 10
Index 423
replication sources (continued) resuming Capture program Service Control Manager
large objects 74 (continued) Apply for Windows 266
removing 148 for VM and VSE 259 Capture for Windows 266
setting up, overview 53 for Windows and OS/2 273 services and consulting 401
subsetting 13 retention limit 128 setting environment variables
viewing 147 REVOKE utility 56 Capture program
restrictions Rexx 98 for UNIX platforms 244
archived log 77 RGZPFM command 56 for Windows and OS/2 268
AS/400 78 RMVEXITPGM command 195
setting up
ASCII tables 79 row-replica tables
Apply program
Capture program See also replica tables 16
for AS/400 175
for AS/400 190 description 283, 347
for OS/390 225
for OS/390 227 introduction 16
for UNIX platforms 243 row-replica-target-list tables 289,
for VM and VSE 255 333
Capture program
for Windows and OS/2 268 rows
for AS/400 175
general 130 defining in target table 118
for OS/390 225
CCD tables as sources 20 subsetting
column names, limits 73 DB2 Control Center 118
for VM and VSE 255
data compression 77 DJRA 119
data encryption 78 introduction 13, 71
replication
data types 78 run-time processing 74, 121
DB2 Control Center 93
DB2 DataJoiner 79 RUNSTATS utility 56
DJRA 96
DB2 Enterprise - Extended RVKDPRAUT command 189
replication criteria 53
Edition 77
EDITPROC 77 S source servers
FIELDPROC 77, 255 satellite clients 22 introduction 4
for DB2 Extenders large satellite replication 22 password file for 44
objects 75 satellites 22 source tables
general 77 SBMJOB command 202 See replication sources 10
Informix 80 scenarios spill files 62, 65
key-update 76 problem determination 152 SQL
Microsoft SQL Server 79 typical 19 editing 103
MVS 77 using Control Center 35 errors 353
Oracle 79 scheduling files, customizing 39, 103
partitioning key 78 Apply program running DJRA 104
referential constraints 78 for AS/400 217 statements
remote journal 78 for OS/390 234 defining for subscription
stored procedures 78 for UNIX platforms 254 set 121
Sybase 79 for Windows and OS/2 278 run-time processing 74
table-name length 77 Capture program SQLCODEs
Unicode tables 79 for AS/400 202
utility program 78 -1032 170
for OS/390 229 -206 170
VALIDPROC 78 for UNIX platforms 244
views 72 -330 168
for Windows and OS/2 271 -741 82
VM & VSE 77 subscription sets 123
WHERE clause 118 -805 169
timing 1108 170
RESUME command event 124
for OS/390 230 SQLSTATEs
relative 123
for UNIX platforms 248 security 104 22517 168
for VM and VSE 259 servers 51002 169
for Windows and OS/2 272 57019 170
control 4
resuming Capture program logical 4 SRCESVR.REX file 100
for OS/390 230 source 4 staged replication 111
for UNIX platforms 248 target 4 staging data 82

staging table STRDPRCAP command 201 subsetting (continued)
See also CCD (consistent-change STRJRNPF command 193 target tables 116
data) tables 116 STRSBS command 201 subsystems
defining 116 subscription columns tables 329 See logical servers 4
starting subscription cycle 68 suppressing full-refresh copying for
Apply program subscription events tables OS/390 169
for AS/400 210 description 335 SUSPEND command
for OS/390 232 populating 124 for OS/390 230
for UNIX platforms 251 subscription-schema-changes for UNIX platforms 247
for Windows and OS/2 275 tables 289, 334 for VM and VSE 259
using NT Services 275 subscription-set members for Windows and OS/2 272
with event 114 introduction 11 suspending Capture program
Capture program setting up, overview 53 for OS/390 230
for AS/400 197 subscription set tables 323 for UNIX platforms 247
for OS/390 227 subscription sets for VM and VSE 259
for UNIX platforms 244, 397 activating 148 for Windows and OS/2 272
for VM and VSE 256 changing 149 Sybase
for Windows and OS/2 269 cloning 148 restrictions 79
general 140 continuous 123 Sybase, improving performance 144
using NT Services 269 data consistency 125 synchronization generations
change capture 54 deactivating 148 tables 289, 350
DataPropagator for Microsoft defining synchronous replication 17, 19
Jet 285 columns 116 SYS1.DUMP data set 159
STOP command Control Center or DJRA 112 system change journal
for OS/390 230 example of 40 management 193
for VM and VSE 258
for AS/400 196 T
mini-cycles 122 table partitioning
for Windows and OS/2 271 rows 118 See column subsetting, row
stopping run-time processing 121 subsetting 13
Apply program target-table structure 116 table space, specifying in logic 99
for AS/400 217 target-table type 115 table structures 293
for OS/390 234 update-anywhere tables
for UNIX platforms 254 replication 114 See also control tables, source
for Windows and OS/2 278 introduction 11 tables, target tables 14
Capture program referential integrity 125 Apply job 340
for AS/400 202 removing 149 Apply-qualifier-cross-
for OS/390 230 run-time processing reference 317
for UNIX platforms 247 statements 74 Apply trail 153, 336
for VM and VSE 258 setting up, overview 53 base aggregate 345
for Windows and OS/2 271 timing Capture enqueue 313
DataPropagator for Microsoft changing 125 change aggregate 346
Jet 286 event-based 124 change data (CD) 82, 321
storage interval 123 complete, condensed CCD
active log size 63 relative 123 tables 85
Apply spill files 62, 65 subscription statements tables 331 complete, noncondensed CCD
CD table 64 subscription-targets-member tables 86
control tables 63 tables 326 conflict 348
database log and journal subscriptions consistent-change-data
data 62 See subscription sets, (CCD) 82, 343
dump 159 subscription-set members 11 critical section 315
planning 61 subsetting customizing names 95
target tables 63 columns 70, 116 DB2 ODBC Catalog 237
UOW table 65 horizontal 71 error information 348
stored procedures 74, 78, 121 rows 71, 118 error messages 349
STRDPRAPY command 210 source tables 70 error-side-information 349
Index 425
tables (continued) target tables (continued) update-anywhere replication
key string 349 update anywhere, defining 106 CCD (consistent-change-data)
Microsoft Jet target server 289 user 16 tables 82
noncomplete, condensed CCD user copy 15, 341 conflict detection 107
tables 86 user defined 119 defining sources 106
noncomplete, noncondensed CCD TARGSVR.REX file 100 defining subscription sets 114
tables 86 tasks, overview 49 example configuration 30
point-in-time 342 TBLSPACE.REX file 99 fragmentation for 107
prune lock 316 terminology introduction 21
pruning control 309 DataPropagator for Microsoft updated primary key columns 109
register 301 Jet 282 updates
register extension 308 DB2 DataPropagator 1 as inserts and deletes 109
register synchronization 318 three-tier replication asynchronous 17
replica 345 configuration 111 conflicts 107
row-replica 347 timing event-based timing 17
row-replica-target-list 333 event-based 17, 124 interval-based timing 17
staging 82 interval-based 17 on-demand timing 18
structures 293 on-demand 18 scheduling 16
subscription columns 329 subscription sets synchronous 17
subscription events 335 changing 125 user copy tables
subscription-schema- setting 123 defining 115
changes 334 Tools Settings notebook 95 description 341
subscription set 323 trace files introduction 15
subscription statements 331 Apply program 155 user-defined data types 79
subscription-targets-member 326 Capture program 157 user-defined tables 119
synchronization generations 350 problem determination 157 user ID
target types 14 trace tables Apply program 105
trace 157, 316 description 316 Capture program 104
tuning parameters 128, 312 problem determination 157 requirements
unit-of-work (UOW) 319 transaction identification 89 for UNIX 239
user 16 trigger-based communication 9 Windows and OS/2 263
user copy 15, 341 troubleshooting user-oriented identification 89
warm start 313 Capture and Apply user tables
target servers, introduction 4 programs 166 as targets 16
DataPropagator for Microsoft introduction 10
target tables
Jet 287 utilities
aggregate 15 introduction 56 BIND PACKAGE 56
base aggregate 15, 345 services and consulting 401 REORG 56
CCD (consistent-change-data) tuning parameters REVOKE 56
description 82, 343 Capture for AS/400 178, 203 RUNSTATS 56
introduction 15 specifying 128 utility program restrictions 78
change aggregate 15, 346 tuning parameters tables 312
columns, defining 116 tutorial for Windows NT 35 V
fragmenting 70 VALIDPROC 78
in non-IBM databases 52 U vertical subsets 70
offline load 127 Unicode tables 79 views
point-in-time 15, 342 unions for targets 14 defining as sources 13, 108
replica 16, 345 unit-of-work (UOW) tables description 71
row-replica 16, 347 Capture triggers 80 double delete 72
rows, defining 118 description 319 restrictions 72
storage requirements 63 pruning 319
structure, specifying 116 storage requirements 65 W
table structures, quick UOW (unit-of-work) tables warm start, Capture program
reference 299 Capture triggers 80 for AS/400 198, 205
type, specifying 115 description 319 for OS/390 228
types of 14 storage requirements 65 for UNIX platforms 245

warm start, Capture program
(continued)
for VM and VSE 257
forcing 142
general 141
warm start tables
description 313
for Capture for VSE and
VM 313
WARMNS keyword 142
Web pages 89
WHERE clause
dummy 119
examples 119
filtering rows 119
PREDICATES column
restriction 71
restrictions 118
row subsets 71
WRKRDBDIRE command 209, 219
WRKREGINF command 195
WRKSBMJOB command 159
WRKSBSJOB command 159
Index 427
Contacting IBM
If you have a technical problem, please review and carry out the actions
suggested by the Troubleshooting Guide before contacting DB2 Customer
Support. This guide suggests information that you can gather to help DB2
Customer Support to serve you better.
For information or to order any of the DB2 Universal Database products

contact an IBM representative at a local branch office or contact any
authorized IBM software remarketer.
If you live in the U.S.A., then you can call one of the following numbers:
v 1-800-237-5511 for customer support.
v 1-888-426-4343 to learn about available service options.
Product information
If you live in the U.S.A., then you can call one of the following numbers:
v 1-800-IBM-CALL (1-800-426-2255) or 1-800-3IBM-OS2 (1-800-342-6672) to
order products or get general information.
v 1-800-879-2755 to order publications.
http://www.ibm.com/software/data/
The DB2 World Wide Web pages provide current DB2 information
about news, product descriptions, education schedules, and more.
http://www.ibm.com/software/data/db2/library/
The DB2 Product and Service Technical Library provides access to
frequently asked questions, fixes, books, and up-to-date DB2 technical
information.
Note: This information may be in English only.

http://www.elink.ibmlink.ibm.com/pbl/pbl/
The International Publications ordering Web site provides information
on how to order books.
http://www.ibm.com/education/certify/
The Professional Certification Program from IBM Web site provides
information certification test information for a variety of IBM products
including DB2.

ftp.software.ibm.com
Log on as anonymous. In the directory /ps/products/db2, you can
find demos, fixes, information, and tools concerning DB2 and many
related products.
comp.databases.ibm-db2, bit.listserv.db2-l
These internet newsgroups are available for users to discuss their
experiences with DB2 products.
On Compuserve: GO IBMDB2
Enter this command to access the IBM DB2 Family forums. All DB2
products are supported through these forums.
For information on how to contact IBM outside of the United States, refer to
Appendix A of the IBM Software Support Handbook. To access this document,
go to the following Web page: http://www.ibm.com/support/, and then
select the IBM Software Support Handbook link near the bottom of the page.
Note: In some countries, IBM-authorized dealers should contact their dealer

support structure instead of the IBM Support Center.

Printed in the United States of America

on recycled paper containing 10%
recovered post-consumer fiber.
SC26-9920-00
Spine information:
® ®
IBM DB2 Universal
Database DB2 Replication Guide and Reference Version 7

Replication Guide71 PDF

Uploaded by

Copyright:

Available Formats

Replication Guide71 PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Replication Guide71 PDF

Uploaded by

Copyright:

Available Formats

® ®

IBM DB2 Universal Database

Part 1. Introduction . . . . . . . . 1 Chapter 3. Data replication scenario . . . 35

© Copyright IBM Corp. 1994, 2000 iii

iv DB2 Replication Guide and Reference

vi DB2 Replication Guide and Reference

Part 5. Appendixes . . . . . . . 395 Index . . . . . . . . . . . . . 415

Appendix A. Starting the Capture and Contacting IBM . . . . . . . . . . 429

viii DB2 Replication Guide and Reference

DB2 servers Non-IBM servers

© Copyright IBM Corp. 1994, 2000 ix

How this book is structured

1. There is no Apply program for these products.

x DB2 Replication Guide and Reference

How to read syntax diagrams

v Optional items appear below the main path.

About this book xi

If you want to ... Refer to ...

Data replication solution at

Database and data management at

xii DB2 Replication Guide and Reference

How to send your comments

About this book xiii

xiv DB2 Replication Guide and Reference

What’s new for Version 7

The following features were added to improve the performance of your

© Copyright IBM Corp. 1994, 2000 xv

What’s new for Version 6

xvi DB2 Replication Guide and Reference

What’s new xvii

xviii DB2 Replication Guide and Reference

What’s new xix

“Chapter 1. Overview of data replication” on page 3 describes the DB2 data

“Chapter 2. Data replication configurations” on page 19 describes the basic

© Copyright IBM Corp. 1994, 2000 1

Before you go to Chapter 2 and begin designing your replication environment,

DB2 data replication components

© Copyright IBM Corp. 1994, 2000 3

The change-capture mechanisms use the following control tables: register

4 DB2 Replication Guide and Reference

DB2 Control Center

DataJoiner Replication Administration (DJRA)

You can use DJRA to perform the following administration tasks:

Chapter 1. Overview of data replication 5

For instructions on using the Capture program, see “Part 3. Operations” on

6 DB2 Replication Guide and Reference

For instructions on using the Apply program, see “Part 2. Administration” on

The replication components communicate differently depending on whether

Chapter 1. Overview of data replication 7

Capturing data from a source database

8 DB2 Replication Guide and Reference

Capturing data from a source

9. This is not true for noncomplete CCD tables.

Chapter 1. Overview of data replication 9

DB2 data replication concepts

After-image columns and before-image columns

Before-image columns are useful if your applications require auditing or

10 DB2 Replication Guide and Reference

Levels of conflict detection