Here is a BIG problem with the IBM i restore process. If I have a file which has been saved while it was journaled to JRNA and try to restore it over the same file which was journaled to JRNB the restore works just fine with no errors but the restored object is NOT journaled to the same journal as the restored object, even if the target object is no longer journaled it is still not journaled to the original journal. The problem is as we have described before IBM does not guarantee object consistency only data consistency for a restored object.
Even if we do not enter the ALWOBJDIF(*ALL) parameter the restore still does not restore the journal information with the object. For the restore to work and bring with it the journal information you have to delete the object on the target and restore, this then starts journaling to the correct journal and everything is as it should be.
But what about those objects with Logical files built over them? Before you can delete a physical file you have to delete all of the logical files that have been built over it. That can be achieved with a simple command to look for the related logical files or even an API to identify them before you delete the offending items. Then you can delete the actual physical file and restore the new object with the expected result that it will be journaled and it will be journaled to the right journal. Seems simple enough until you then have to go through and re-create all of the logical files which you just deleted to allow the restore to work correctly. Hopefully you have a save or can copy them from the source system in the instance we have where the journaling is required for High Availability.
I think this is a very bad design and IBM should fix it, but unless people get off their butts and make some noise IBM will sit happily behind the Working as designed clause it brings out for such occasions.