I was setting up the RAP demo environment again after it became corrupted with the testing of the new version when I came across what I thought was a problem? I demo the capabilities of the APYJRNCHG command with respect to IFS data by auto journalling the directory structure on the source system and ensuring all new objects below the required directory get journalled to the right journal. The programs simply delete links, add directories and copy objects between directories to show how they are automatically created on the target. I also update the object manually on the source to show how normal updates flow across.
I tried to be a bit lazy and created the objects manually on the target and journalled them to the journal on the target. This does not work because the JID on the source will be different from the JID on the target, thus stopping the APYJRNCHG command from recognizing the object as a valid candidate for updates to be applied to. So I thought OK I will save the objects on the source and restore them on the target, this should give them the right JID and the APYJRNCHG command will recognize them, but it didnt! I was confused, I had saved the objects and restored them so why did the command ignore them both? thinking I had made a mistake in the save and restore process I carefully went through the entire process again making sure I read through each of the parameters and how they should be set, again it didnt work! I then manually went through the process RAP uses to apply the changes, it too failed even after specifically entering the actual objects I was interested in!
So I decided to save the directory above the directory I was trying to get the updates to work on, I then deleted the entire directory structure before doing the restore. This time it all worked and the APYJRNCHG command did its job!
One other thing I did do was set the ALWOBJDIF to *ALL on the original restore and changed it to *NONE this time, however the objects didnt exist so the parameter was not part of the issue. But if the *ALWOBJDIF *ALL allows the JID to be different this could be the problem? I have asked IBM for feedback and will update the Blog when I get the information back.
Another problem I found was the RST command has a problem with teh PF10 command, if I press PF10 on the initial screen and page down I dont see any additional parameters even after pressing the key again on the second page. however if I paged down from the original screen and pressed PF10 the additional paremters showed up OK.. I will pass this in as a problem to IBM.
One thing which I find interesting after doing all this analysis is that IBM uses Commitment Control on the IFS journalled objects! Dont know why they do it but it does add a lot of entries to the journal, so if you see your journal receivers grow significantly after journalling the IFS this could be the culprit?
Chris…