Failure after RECON reorganization - connect_cdc_sqdata

IMS RECONS are periodically reorganized by DBRC maintenance. This can cause Capture to fail because It does not know that the IMS logs are being processed. If DBRC happens to replace SLDS entries with "compressed data set" entries, or just outright deletes them, then we can't find the next data set to read resulting in an error:

In a production environment this almost never causes an issue. There is however a possibility that recycling the IMS Log Capture following RECON maintenance (REORGS) could produce the following sequence of error messages:

05.13.22 STC10396 SQDI100I Capture initiated for IMS subsystem TST0 
05.13.22 STC10396 SQDI120I Processing log for IMS subsystem TST0 229 
 229 dsn=TS.ARCHIVE.TST0SLDS.A.V210829 
05.13.22 STC10396 SQDI714E Subsystem TST0 log missing at 230 
 230 sequence number 00000000005046EF 
05.13.33 STC10396 SQDI121I Completed processing for IMS subsystem TST0 231 
 231 dsn=TS.ARCHIVE.TST0SLDS.A.V210829 
05.13.33 STC10396 SQDI120I Processing log for IMS subsystem TST0 232 
 232 dsn=TS.ARCHIVE.TST0SLDS.A.V210829 
05.13.33 STC10396 SQDI714E Subsystem TST0 log missing at 233 
 233 sequence number 00000000005046EF 
...

This sequence of Errors can continue for a long time before finally terminating with the"imsc_log_not_found" error

11.03.43 STC10396 SQDI714E Subsystem TST0 log missing at 948 
 948 sequence number 0000000000505393 
11.03.53 STC10396 SQDI121I Completed processing for IMS subsystem TST0 969 
 969 dsn=TS.ARCHIVE.TST0SLDS.A.V210829A 
11.03.53 STC10396 SQDI120I Processing log for IMS subsystem TST0 970 
 970 dsn=TS.ARCHIVE.TST0SLDS.A.V210829A 
11.03.53 STC10396 SQDI714E Subsystem TST0 log missing at 971 
 971 sequence number 0000000000505393 
11.04.03 STC10396 SQDI714E Subsystem TST0 compressed PRILOG at 179 
 179 sequence number 00000000005046EF 
11.04.03 STC10396 SQDI103E Capture failed for IMS subsystem TST0 180 
 180 log not found  
11.04.03 STC10396 SQDI101I Capture terminated for IMS subsystem TST0 
11.04.03 STC10396 IMSCUFX was called 0 times for PROCESS action 
11.04.03 STC10396 IMSCUFX termination complete 
11.04.03 STC10396 IMSCUJX was called 0 times for PROCESS action 
11.04.03 STC10396 IMSCUJX termination complete 
11.04.03 STC10396 SQDC016I sqdimsc(pid=0x955) terminated with Return Code 8, Reason Code=
11.04.03 STC10396 SQDC016X 0x214c00a (IMSC_LOG_NOT_FOUND)

There are two possible procedures for recovery. Perform them in following sequence.

Procedure 1:

Determine what the safe restart point was at the time capture was started, for example: da3b961526c48da6.5046ee. If that happens to be at the end of SLDS data set TS.ARCHIVE.TST0SLDS.A.V210829, then Capture will position itself at that LSN and tries to read the next record, which has sequence number 5046ef as in the first message above at 05.13.22

Capture cannot read sequence 5046ef because it cannot determine from the RECON the name of the SLDS that contains it. That is because the SLDS data set name(s) were removed from the RECON by DBRC maintenance and replaced with a compressed data set entry.

To recover, first determine if the SLDS data sets containing sequence numbers 5046ef through 505392 still exist. Based upon the ranges shown for your OLDS, there should be two of them. If they exist, recovery is possible.

Stop capture.
Prepare --log statements for restart, one for each SLDS that contains records from sequence 5046ef through 505392. The format is:
--log <subsystem>:<data_set_name>[:[0x]<start_lsn>][:[0x]<stop_lsn>][:]
Note: Since the compressed range is comprised of one or more whole data sets, you will not need to specify the start or stop lsn. You need subsystem and SLDS name for each of the two SLDS that are no longer known to the RECON, e.g:
```
--log TST0:TS.ARCHIVE.TST0SLDS.A.Vnnnnnn
```
Run SQDCONF modify --lsn=da3b961526c48da6.5046ee
Add the --log parameters to your normal capture SQDPARMS input and restart capture. Capture will terminate after processing the last input --log data set.
Remove the --log parameters and restart capture with the normal input.
This procedure will only work correctly if the --log statements include the first SLDS that is still in the RECON. If there is not one (maybe because the current OLDS hasn't switched yet), issue a /SWITCH OLDS command to create it. Then include a --log statement for it. Since it exists in the RECON, the next restart will be able to find it for safe-restart positioning.
If this procedure is followed and restart encounters another "log not found", just run it again specifying the subsequent SLDS up through the first one still in the RECON. Then restart normally when that completes.

Procedure 2:

Procedure 1 could still result in "log not found" upon the final restart. The reason "log not found" could occur is because of safe-restart positioning. Capture will look for that last missing SLDS from the last --log parameter, but it is not in the RECON anymore.

Add the --continue parameter to SQDPARMS along with the two --log statements in Procedure 1.
This will allow the capture to continue without having to stop and restart.
Remove the --log statements and --continue from the input before the next normal restart.

Failure after RECON reorganization - connect_cdc_sqdata - Latest

Connect CDC (SQData) Troubleshooting