Changes made to the CDCzLog Publisher Configuration (.cab) file are not effective until they are applied. The apply operation instructs the Publisher agent to begin processing based on the changes previously issued but not yet actually applied to the agent itself. The reason for formally separating the apply step from the add/modify/remove steps is to prepare for the deployment of a production change in advance, without taking the risk of accidentally impacting production.
Example: The new application requiring the capture of FILEB will be rolled-out next week-end.
- If changes were effective immediately or automatically at the next start, then these changes could not be performed until the production Publisher is stopped for the migration during the week-end. Otherwise, the risk exists that the Publisher may go down for unrelated production issues, and the new change 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 process in jeopardy. This allows Publisher maintenance to be done outside of the critical upgrade path.
- In order to apply changes, the agent must first be stopped. This operation in effect pauses the agent task and permits the additions and/or modifications to the configuration to be applied. Once the agent is restarted, SQDCONF commands are actually processed by the agent itself.
//*---------------------------------------- //* STOP THE AGENT //*---------------------------------------- //STOP EXEC SQDCONF //SQDPARMS DD * stop <cab_file_name> //* //*---------------------------------------- //* APPLY UPDATED CONFIGURATION FILE //*---------------------------------------- //APPLY EXEC SQDCONF //SQDPARMS DD * apply <cab_file_name> //* //*---------------------------------------- //* START THE AGENT //*---------------------------------------- //START EXEC SQDCONF //SQDPARMS DD * start <cab_file_name> //*