|
Failure after RECON Reorg |
Scroll |
IMS RECONS are periodically reorganized by DBRC maintenance. This can cause Capture to fail because It doesn't know that we are also processing the IMS Logs. 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 sequencec 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.
1.Stop capture.
2.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 won't 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
3.Run SQDCONF modify --lsn=da3b961526c48da6.5046ee
4.Add the --log parameters to your normal capture SQDPARMS input and restart capture. Capture will terminate after processing the last input --log data set.
5.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's 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 isn't in the RECON anymore.
1.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. Remember to remove the --log statements and --continue from the input before the next normal restart.
