Introduction
In the world of enterprise database management, disaster recovery automation is crucial for maintaining business continuity. With the release of IBM Db2 Analytics Accelerator for z/OS v8.1.1, we’re introducing a powerful enhancement that directly addresses a common challenge faced by customers: managing IBM Integrated Synchronization (InSync)endpoints during disaster recovery scenarios. This improvement streamlines recovery processes, reduces complexity, and strengthens resilience for mission-critical workloads.
The Challenge
Many organisations rely on automated batch jobs to manage their disaster recovery processes on z/OS systems. However, until now, there was a manual bottleneck, changing the InSync replication endpoint required administrators to manually access the Admin Console and update the configuration. This manual step interrupted otherwise seamless automation workflows and introduced potential delays during critical recovery operations.
The Solution: Enhanced ACCEL_CONTROL_ACCELERATOR Stored Procedure
We've extended the existing `SYSPROC.ACCEL_CONTROL_ACCELERATOR` stored procedure with new functionality that allows you to programmatically change the replication endpoint. This enhancement enables batch jobs to invoke the procedure directly, eliminating manual intervention and streamlining your disaster recovery automation.
What Can You Do?
With this new capability, you can:
- Change the IP address by which a Db2 subsystem can be reached
- Update the secure DDF port for IBM Integrated Synchronisation
- Automate endpoint changes as part of your disaster recovery workflows
Important prerequisite: You must stop replication on all attached accelerators before changing the IP address or secure port.
How to Use It
Basic Syntax
CALL SYSPROC.ACCEL_CONTROL_ACCELERATOR
(accelerator_name,
command,
result,
message)
Parameters Explained
- accelerator_name: The unique name of your accelerator (must be previously defined via `SYSPROC.ACCEL_ADD_ACCELERATOR2`)
- command: An XML input string specifying the new InSync endpoint
- result: Output parameter containing the operation result
- message: Output parameter with detailed status messages
Command Structure
The command parameter uses XML format to specify the new endpoint:
<?xml version="1.0" encoding="UTF-8" ?>
<aqt:controlCommand xmlns:aqt="http://www.ibm.com/xmlns/prod/dwa/2011"
version="1.0">
<changeReplicationEndpoint ip="192.168.1.100" port="5035" />
</aqt:controlCommand>
Real-World Example
Here's a complete example of changing a replication endpoint:
CALL SYSPROC.ACCEL_CONTROL_ACCELERATOR
('MY_ACCELERATOR',
'<?xml version="1.0" encoding="UTF-8" ?>
<aqt:controlCommand xmlns:aqt="http://www.ibm.com/xmlns/prod/dwa/2011"
version="1.0">
<changeReplicationEndpoint ip="192.168.1.100" port="5035" />
</aqt:controlCommand>',
?,
?)
Error Handling and Best Practices
Common Error Scenarios
Understanding potential errors helps you build robust automation:
1. Missing Parameters (AQT20158E): Both IP address and port must be specified
2. Invalid IP Address (AQT20158E): IP addresses with unsupported characters will be rejected
3. Unreachable Endpoint (AQT20157E): The system validates that the new endpoint is accessible
4. Active Replication (AQT20007E): Replication must be stopped before changing endpoints
5. Configuration Issues (AQT20159E): Ensure all required configuration files are in place
Best Practices
1. Always stop replication first before attempting to change endpoints
2. Validate your IP and port before calling the procedure
3. Use secure DDF ports for production environments
Benefits for Your Organisation
This enhancement delivers tangible benefits:
- Reduced Recovery Time: Eliminate manual steps during disaster recovery
- Improved Reliability: Reduce human error in critical operations
- Better Automation: Integrate endpoint changes seamlessly into existing batch workflows
- Enhanced Flexibility: Quickly adapt to infrastructure changes without manual intervention
Getting Started
To leverage this functionality in your environment:
1. Ensure your IBM Db2 Analytics Accelerator for z/OS is updated with version 8.1.1
2. Review your existing disaster recovery automation scripts
3. Identify where manual endpoint changes currently occur
4. Replace manual steps with calls to the enhanced stored procedure
The ability to programmatically change replication endpoints represents a significant step forward in disaster recovery automation for Db2 on z/OS. By eliminating manual intervention, organisations can achieve faster recovery times, reduce errors, and build more resilient systems.
We encourage you to explore this enhancement and integrate it into your disaster recovery workflows. As always, thorough testing in non-production environments is essential before deploying to production systems.
References
Contribution
This blog is contributed by
@Neema John , IBM Db2 Analytics Accelerator Development Team, IBM ISL Lab, Kochi
@Shanila K S, IBM Db2 Analytics Accelerator Development Team, IBM ISL Lab, Kochi