Concurrent image copy recovery

A concurrent image copy is fuzzy because while IMS makes the image copy of the database, IMS might also be updating the database at the same time.

For example, IMS might could update the database:

Before the start of the concurrent image copy, and IMS might not have written those updates to the DBDS yet
While the concurrent image copy is being taken

After restoring the data set from the concurrent image copy, IMS applies changes which occurred while the image copy was being taken from the log. Therefore, to recover a DBDS that has fuzzy image copies, you might need to supply logs to the recovery job which have time stamps that precede the start of the concurrent image copy. The DBRC GENJCL.RECOV command generates JCL with the correct logs listed.

If you use the database recovery service to recover a DBDS that has fuzzy image copies, the database recovery service automatically processes all the necessary logs required for the recovery.