Changes made to an agent configuration are not effective until they are applied. The "apply" operation instructs the agent to process the SQDconf commands that have been previously issued but not yet actually processed by the agent itself. Separating the apply step from the add/modify/remove steps provide for the staging of a production change in advance of its deployment. It minimizes the risk of accidentally impacting production operations.
Example
Imagine that a new application will be rolled-out next weekend:
That application requires the capture of a couple of new tables and drops the capture of another table. If changes were effective immediately or automatically at the next start, then these changes could not be performed until the production capture is stopped for the migration during the weekend. Without provision for staging changes the risk exists that the capture agent may be stopped or fail unrelated production issues (like an unexpected disconnection from DB2), and the new changes would be activated prematurely.
Forcing a distinct and explicit apply step, insures that such changes can be planned and prepared in advance, without putting the current production replication in jeopardy. This allows capture agent maintenance to be done outside of the critical upgrade path.
//*----------------------------------------
//*- STOP THE CAPTURE AGENT
//*----------------------------------------
//STOP EXEC SQDCONF,OWNER=&SYSUID
//SQDPARMS DD *
stop /home/user/db2cdc.cab
//*
//*----------------------------------------
//*- APPLY UPDATED CONFIGURATION FILE
//*----------------------------------------
//APPLY EXEC SQDCONF,OWNER=&SYSUID
//SQDPARMS DD *
apply /home/user/db2cdc.cab
//*
//*----------------------------------------
//*- START THE CAPTURE AGENT
//*----------------------------------------
//START EXEC SQDCONF,OWNER=&SYSUID
//SQDPARMS DD *
start /home/user/db2cdc.cab
//*
- There are a few exceptions, like --pause, --resume and --disconnect which are effective immediately.
- The SQDconf create command defines the location of the agent's configuration CAB file. Once created, this command should never be run again unless you want to destroy and recreate the agent. This is because of the processing state information stored in the configuration file including things like the position in a database log being mined for change data.
- After the initial creation of a configuration file has been completed with all the associated source and target items specified, the apply command should only be used when changes have been staged and they are intended to take effect the next time the agent is started. The stop, apply and start sequence illustrated can be run in different SQDconf jobs or scripts.