Implement segment changes - connect_cdc_sqdata - Latest

Changes in segments most often involve only the reuse of existing FILLER at the end of the COBOL copybook. That type of change can be effectively ignored unless the new data is needed in a Target datastore because, while the IMS capture will include the new data, the Apply Engine can continue to use the old Source Description. Other changes that may have no impact on the Capture or Engine include the addition of a new segment or increasing the length of an existing segment, unless the new data is needed by a Target datastore.

Other types of changes such as modification to the key fields of an existing segment or when new source data must also be added to a Target datastore will require the Apply Engine script and/or associated parts to be modified, the script to be re-parsed and the Apply Engine to be stopped and re-started.

Either scenario above can be complicated if more than one IMS subsystem is involved and the change is not implemented simultaneously in all the subsystems. That is because an Engine can only support a single version of a Source Description at one time. If each subsystem has its own LogStream and Publisher this is not a problem, as illustrated by the following sequence of steps:

1. IMSA Publisher is Stopped, causing IMSA Apply Engine to Stop
2. IMSA is brought down, DBDGENs are run
3. IMSA Apply Engine is reparsed with updated Parts
4. IMSA is brought back up, Capture Resumes to LogStream A
5. IMSA Publisher is restarted
6. IMSA Apply Engine is Started and CDC Apply processing resumes

Simultaneously or whenever scheduled the same series of steps are followed for IMSB:

1. IMSB Publisher is Stopped, causing IMSB Apply Engine to Stop
2. IMSB is brought down, DBDGENs are run
3. IMSB Apply Engine is reparsed with updated Parts
4. IMSB is brought back up, Capture Resumes to LogStream B
5. IMSB Publisher is restarted
6. IMSB Apply Engine is Started and CDC Apply processing resumes
7. Implementation completed

In large environments there may be multiple subsystems based on geography or other factors. Connect CDC SQData can accommodate all known configurations and may be configured to use a single LogStream, Publisher and Engine to service all the subsystems. In that case an alternative implementation plan might look like this:

1. IMSA is brought down, DBDGENs are run; Capture is reconfigured to write to LogStream 2
2. IMSA is brought back up, Capture begins writing to LogStream 2
3. IMSB capture continues to LogStream 1, Publisher continues to process LogStream 1 and Engine continues (but with no data coming from IMSA)
4. IMSB is brought down, DBDGENs are run; Capture is reconfigured to write to LogStream 2
5. Publisher is reconfigured a) with the LogStream Cleaner turned off using --ptk=8, b) with --safe-restart=0 on the START Parm and c) to read LogStream 2
6. Apply Engine is reparsed with updated Parts
7. Publisher and Apply Engine are restarted, initially finding only published CDC from IMSA
8. IMSB is brought back up, Capture begins writing to LogStream 2
9. Apply Engine begins to process published CDC from IMSB
10. Implementation completed
11. IMSB Apply Engine is Started and CDC Apply processing resumes
12. After confirmation of successful implementation, Publisher is stopped momentarily; LogStream Cleaner turned back on by removing the --ptk=8 start Parm; Publisher restarted; Apply Engine restarted

Notes:

• The second scenario provides a relatively simple method for scheduling a common DBD/Segment change that affects multiple IMS subsystems. Steps 1 and 2 above would be repeated for each subsystem until the last one is brought down in step 8. Steps 9 - 13 would be performed after the last subsystem was brought down, completing the implementation.
• It is critical that the --ptk=8 parm be REMOVED once the Implementation has been confirmed to be successful so that the Cleaner will resume cleaning
• If the volume of data or the elapsed time between Step 1 and Step 13 are estimated to create too much latency, Steps 9 through 11 could create a new Publisher and Apply Engine that would process the reconfigured subsystems in parallel with those not yet updated. Visit Precisely https://www.precisely.com/support prior to executing a complicated change implementation.