This chapter describes how to set up and operate the Capture and Apply programs on the following operating systems:
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).
Be sure to read the following sections before reading the sections on operating the Capture and Apply programs:
The user ID under which the Capture and Apply programs will run must have the following authorities and privileges:
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.
DB2 CONNECT TO database
where database is the source server database.
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.
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.
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:
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
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.
These commands create a list of packages, the names of which are in the files APPLYCS.LST and APPLYUR.LST.
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:
The password file must meet the following criteria:
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.
SERVER=server_name USER=userid PWD=passwordWhere:
For more information about authentication and security, refer to the IBM DB2 Universal Database Administration Guide.
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:
ASNINST x:\ASNSERV.EXE
ASNPATH=x:Important: Do not add a backslash to the ASNPATH variable.
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:
x:\instancenamedbname.trc
x:\APPLYtimestamp.trc
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.
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.
This section explains how to perform the following Capture program tasks:
This section also lists restrictions for running the Capture program.
Some actions cause the Capture program to terminate while it is running. Stop the Capture program before you take any of the following actions:
The Capture program cannot capture any changes made by DB2 utilities, because the utilities do not log changes that they make.
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:
To set the environment variables:
SET DB2INSTANCE=db2_instance_name
After you start the Capture program, it runs continuously until you stop it or it detects an unrecoverable error.
To start the Capture program using the NT Services:
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:
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.
>>-ASNCCP----+------------+---+--------+---+---------+---------->
'-src_server-' +-WARM---+ +-PRUNE---+
+-WARMNS-+ '-NOPRUNE-'
'-COLD---'
>-----+---------+---+---------+---+----------+---+----------+--->
+-NOTRACE-+ '-TRCFILE-' '-NOTRCTBL-' '-AUTOSTOP-'
'-TRACE---'
>-----+----------+---+-----------+---+---------+---------------><
'-LOGREUSE-' '-LOGSTDOUT-' +-ALLCHG--+
'-CHGONLY-'
Table 30 defines the invocation parameters.
Table 30. ASNCCP invocation parameter definitions for Windows and OS/2 platforms
| Parameter | Definition |
|---|---|
| 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 in its previous run if warm start information is available. If the Capture program cannot warm start, it switches to a cold start. |
| WARMNS | The Capture program resumes processing where it ended in its previous run if warm start information is available. 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 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). |
| 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 and then re-creating 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. |
| 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 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. |
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.
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). To stop the Capture program, enter the command:
If you set environment variable DB2DBDFT (see step 2):
>>-ASNCMD--STOP------------------------------------------------><
or, if you did not set environment variable DB2DBDFT:
>>-ASNCMD--src_server--STOP------------------------------------><
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). To suspend the Capture program, enter the command:
If you set environment variable DB2DBDFT (see step 2):
>>-ASNCMD--SUSPEND---------------------------------------------><
or, if you did not set environment variable DB2DBDFT:
>>-ASNCMD--src_server--SUSPEND---------------------------------><
Important: Do not use the SUSPEND command when canceling a replication source. Instead, stop the Capture program.
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 variables are set (see Setting environment variables for Capture for Windows and OS/2). To resume the Capture program, enter the command:
If you set environment variable DB2DBDFT (see step 2):
>>-ASNCMD--RESUME----------------------------------------------><
or, if you did not set environment variable DB2DBDFT:
>>-ASNCMD--src_server--RESUME----------------------------------><
Use the REINIT command to begin to capture changes from new source 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.
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 variables are set (see Setting environment variables for Capture for Windows and OS/2). To reinitialize the Capture program, enter the command:
If you set environment variable DB2DBDFT (see step 2):
>>-ASNCMD--REINIT----------------------------------------------><
or, if you did not set environment variable DB2DBDFT:
>>-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.
This command prunes tables once.
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). To begin pruning tables, enter the command:
If you set environment variable DB2DBDFT (see step 2):
>>-ASNCMD--PRUNE-----------------------------------------------><
or, if you did not set environment variable DB2DBDFT:
>>-ASNCMD--src_server--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.
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.
Before you display captured log progress, ensure that the environment variables are set (see Setting environment variables for Capture for Windows and OS/2). To display captured log progress, enter the command:
If you set environment variable DB2DBDFT (see step 2):
>>-ASNCMD--GETLSEQ---------------------------------------------><
or, if you did not set environment variable DB2DBDFT:
>>-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. |
An administrator can use the commands in the following sections to perform the following Apply program tasks:
Before you start the Apply program, ensure that:
After you start the Apply program, it runs continuously until:
To start the Apply program using the NT services:
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:
SET DB2INSTANCE=db2_instance_name
>>-ASNAPPLY--Apl_qual----+-----------+---+-----------+---------->
'-Ctrl_serv-' +-LOADXit---+
'-NOLOADXit-'
>-----+----------+---+---------+---+---------+---+----------+--->
+-INAMsg---+ +-NOTRC---+ '-TRCFILE-' +-NOTIFY---+
'-NOINAMsg-' +-TRCERR--+ '-NONOTIFY-'
'-TRCFLOW-'
>-----+---------+---+------------+---+----------+--------------->
+-SLEEP---+ +-DELAY(n)---+ '-COPYONCE-'
'-NOSLEEP-' '-ERRWAIT(n)-'
>-----+----------+---+-----------+---+----------+--------------><
'-LOGREUSE-' '-LOGSTDOUT-' '-TRLREUSE-'
Table 31 defines the invocation parameters.
Table 31. ASNAPPLY invocation parameter definitions on Windows and OS/2 platforms
| Parameter | Definition |
|---|---|
| Apl_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 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 control tables will reside. If you do not specify this parameter, the default is the default database or the value of DB2DBDFT. |
| 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. |
| NOLOADXit (default) | Specifies that the Apply program will not invoke ASNLOAD. |
| 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 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 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 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 Apply cycle when continuous replication is used, where n=0, 1, 2, 3, 4, 5, or 6. The default delay time is 6 seconds. |
| 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). |
| 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:
|
| LOGREUSE | The Apply program reuses the log file (*.app) by first deleting it and then re-creating it when the Apply program is restarted. If you do not specify this option, 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 standard output (stdout) and the log file. |
| TRLREUSE | The Apply program empties the Apply trail table when the Apply program is started. |
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.
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:
>>-ASNASTOP--Apply_qualifier-----------------------------------><
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--'
>-----+-----------------------------------------+--------------->
| .-------------------------------. |
| V | |
'- -c-----optional Capture parameter---+--'
>-----+---------------------------------------+----------------><
| .-----------------------------. |
| V | |
'- -a-----optional Apply parameter---+--'
| 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 and Table 31 respectively.
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.
|
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.
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.
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. For more information about programming your own resolutions, refer to the appropriate Microsoft documentation.
The following terms represent replication concepts as they pertain to Microsoft Jet database replication. For definitions of general replication terms, see Glossary.
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.
You prepare the server to use DataPropagator for Microsoft Jet just as you would for DB2 DataPropagator. To prepare the server:
To prepare the client, install the following software (if it is not already installed):
If the source or control server requires authentication, create a password file.
To create a password file:
The password file must meet the following criteria:
Where: APPLY_QUAL is the Apply qualifier, in uppercase. You specify a value for the Apply qualifier when you define a subscription set.
For example: DATADIR.PWD
Where: DATADIR is the Apply qualifier of the subscription set defined at the control server.
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.
You can use the commands in this section to operate DataPropagator for Microsoft Jet.
This section explains how to perform the following tasks:
Before you start DataPropagator for Microsoft Jet, you must start the Capture program on each DB2 source server, if applicable.
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---+
'-NOINAMSG-' +-TRCERR--+
'-TRCFLOW-'
>-----+----------+---+----------+------------------------------><
+-NOTIFY---+ +-MOBILE---+
'-NONOTIFY-' '-NOMOBILE-'
Table 33 defines the parameters.
Table 33. ASNJET command parameter definitions for DataPropagator for Microsoft Jet
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
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:
If you encounter errors when you run ASNJET, ensure that:
For error message information, see Capture and Apply messages. For more information about troubleshooting, see Troubleshooting.
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.
The parameters that DataPropagator for Microsoft Jet passes to ASNJDONE are:
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:
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 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 Table structures.