Re: Journal management

Le 13/02/2026 à 17:15, Patrik Schindler a écrit :

Journals also can manually be used to reset fatal changes to a table, such as an SQL UPDATE or DELETE with a missing WHERE. Caveat: To reset changes to an arbitrary point in time, both before and after images need to be written to the journal receiver, and the receiver with the fatal change must be on disk, with the whole chain to "now", which might require a restore from backup.
If you don't use images(*both) but the default *after, and want to reset a change, you need the whole chain of receivers from the very beginning of when a table was last journaled (strjrnpf). If you have already overwritten older tapes, you can't undo the change.
Note: This is to my understanding. I have not yet taken time to play around with the possibility to reset fatal changes, but it's on my list of things to learn about.

I, only one time, did use journalling to recover an entire Movex M3 database library residing on an IASP. This IASP was using external storage and, by mistake, a guy ran a flash copy to some of the volumes of the IASP. This one was fully corrupted.

Fortunately, we were saving to tape the receivers every hour before deleting them, and we had a recent backup to tape of the IASPs libraries as well. So we restored all the libraries from the nightly backup, then restored all the receivers that we had (luckily, the more recent receivers backup was only a couple of minutes before the IASP corruption).

After that, it was a matter of APYJRNCHX RCVRNG(*LASTSAVE *CURRENT) FROMENT(*LASTSAVE) TOENT(*LASTRST) [not absolutely sure, but something like that] command and being patient :-). The database state was the one at last saved receiver.

In that case, IMAGES(*AFTER) is enough to perform the recovery.

FWIW.