IBM i - System synchronization

Content

The preferred method to migrate to a new system at a higher release than the source system, is to upgrade the source system to the higher release, perform a full system save (such as a GO SAVE 21) of the source system and then follow Appendix D in the 'Recovering your system' manual to restore the entire system to the target system.

If it is not possible to upgrade the source system to the higher release and the target system does not support the current release of the source system, then follow the steps in the 'Previous release to current release support' section of the 'Release-to-release support' chapter in the 'Recovering your system' manual: https://www.ibm.com/docs/en/ssw_ibm_i_74/rzarm/sc415304.pdf

The migration steps on the target system involve the following steps:

1. Start with installing only the LIC and Base OS on the new system. This can be accomplished by ordering the new system with the 0205 feature code, OR manually installing the LIC and the Base OS for the current release on the target system(Do not install QGPL, QUSRSYS,  57xxSS1 options, or other LPPs at this point).

2. Restore system and user data to the target system from the full save of the source system.

3. Update the system information on the target system (UPDSYSINF).

4. Install QGPL, QUSRSYS and all licensed program products (LPPs) from the target release distribution media.

Step-by-step instructions are found in the topic  ‘Restoring previous release user data to a new system’ in the ‘Recovering your system' manual.

 After the migration is done and a testing period is over now there is a need to synchronize/refresh your data. To accomplish that, follow the steps listed in the “System synchronization: Planning and procedures” section in the 'Recovering your system' manual. The section “System synchronization: Planning and procedures” can be used to synchronize even when the systems are running the same release! Be very careful about restoring data over the top of existing data, even if the data was saved at the same release.

When there is a need to sync more than just a few user libraries and/or IFS directories, OR you are NOT certain what exactly needs to be synchronized - consider syncing the system by performing the migration again (in other words that would mean to follow the "Refreshing your new system" method in the "System Synchronization" chapter from the recovering your system manual). In many occasions, the refreshing your new system method might take the same time as if you synchronize individually (libraries, IFS, DLO etc.). The refresh process consists of scratching the system or clearing the system ASP. If the system ASP is cleared, then LIC remains installed on the target system and and you can continue with step 20 (restore the OS) in the topic  ‘Restoring previous release user data to a new system’ in the ‘Recovering your system manual’.

System synchronization tips:

•  -        IBM strongly recommends that both the source and the target systems are saved after the initial migration is completed and before any synchronization is attempted. These saves will be helpful if data gets overlaid that should not have been.
• -        During a testing period after an initial migration, do not make any changes to the system data on the source system. For instance, do not install PTFs on the source system or make configuration changes. If NOT following this practice and the save changed object method is what will be used to synchronize the target system, it is likely that system data and products could be backleveled when restoring changed system data. Supported synchronization methods at this time would consist of bringing over specific libraries or user objects. One could also consider redoing the migration.
• -        If it is desired to synchronize changes made to the objects in libraries QUSRSYS and QGPL, or to synchronize IFS and DLO data,  follow the “Moving changed objects” method outlined in the recovering your system manual in Chapter 15 (https://www.ibm.com/support/knowledgecenter/ssw_ibm_i_73/rzarm/sc415304.pdf?view=kc ). Note: IBM strongly advises against making any changes (PTF activity or any configuration activity) to the system during the testing period after an initial migration is done. By avoiding changes to system data, IBM supplied objects should NOT have changed on the source system and the changes since the initial migration would only be user data changes. This will reduce/eliminate the chance that system objects are brought over from the previous release that could back-level IBM i products at the current release. If that recommendation is not followed and changes are made, the user will have to come up with another way of moving the changed objects on their own, being careful NOT to back-level any system objects. The only method supported to synchronize DLO and IFS data is the “Moving changed objects” method. The longer the span between initial migration and synchronization, the more likely some IBM objects may have changed.
• -        Do not clear and restore library QUSRSYS to synchronize it from a previous release. QUSRSYS is a special library and clearing this library is NOT recommended. This should only be considered in rare circumstances and even then we document the procedure as an "as is" basis. This library has ties for all the LPPs installed on the system and is the main library that stores TCP and communication information. We do have a document titled 'QUSRSYS: Clearing and Rebuilding' which provides a guideline for what needs to be done should this library be cleared: https://www.ibm.com/support/pages/node/640351. Clearing the QUSRSYS library would also clear the installed LPP references and all the LPPs will need to be re-installed. IBM highly discourages using this method and it is well documented in the synchronization chapter to NOT clear QUSRSYS or QGPL in the “Moving entire libraries” method;
• -        Synchronization of QSYS2, QGPL and QUSRSYS from previous to current release notes: Do not synchronize library QSYS2 as this library has the DB cross-reference files and if you restore from previous release this can cause problems. For QGPL and QUSRSYS – the sync chapter suggests that you could try to sync, BUT only for new objects/members using the “Moving changed objects” method;
• -        To move just specific user libraries data – follow the “Moving entire libraries” method in the “System synchronization: Planning and procedures” chapter in the recovering your system manual.
• -        GO SAVE 23 to save all user data and then GO RESTORE 23 to refresh the data is not supported or recommended. This is a very bad idea for synchronization because it will back-level IBM supplied user libraries (such as QGPL, QUSRSYS & QSYS2), IBM supplied DLOs and IBM supplied user directories. This method will cause renamed (duplicate) files if the user libraries were NOT cleared prior to the restore as ALWOBJDIF(*ALL) is used when indicating that data is being restored to another system. Cleaning up duplicate files is a timely process, AND should there be a need to recover from such an operation – a scratch install (full system restore) or clearing the system ASP and starting the restore from OS install will be recommended.  When using the clearing the system ASP method, this process will leave the LIC and disk configuration intact on the system. After the system ASP has been cleared, the recovery of the system starts with restoring the OS and then the rest of the system data.
• -        If someone incorrectly restored system libraries from the previous release to synchronize the new system with the changes that occurred during the testing period – the recommendation is to perform the migration again due to the duplicate file issues and backleveled objects. Many times trying to clean up the duplicate files and backleveled objects would take the same or more time to fix compared to performing the migration from the beginning.
• -        IBM always recommends to follow the documented and tested processes (the “Release-to-release support” and the “System synchronization: Planning and procedures” support chapters in the 'Recovering your system' manual). When there are deviations to the documented processes, users need to know that there may be risks of issues when using their own methods for synchronizing – IBM may advise that they need to start fresh from the beginning.
• -        If production work is done on the target system before the final synchronization from the source system and this production work needs to be saved, the user will have to make a decision on their own, because there is no method that will sync/merge with the same existing objects from the prod system. The options usually are to move only the changed objects (that is since the initial full system save that they used to migrate), or perform an OPTION(*NEW) restore. When using OPTION(*NEW) be aware that this will not restore an object that exists on the migrated system even if it has changed on the source system. Usually when refreshing data, you do NOT preserve what is already there (on the migrated system being tested). If you want to preserve changed data on the target system – you could save the current data that you want to preserve, and after the synchronization – choose what version to keep (or restore one of the data that you want preserved into another library). Also consider the methods in “Part 4. Tips for merging two or more IBM i operating systems” in the recovering your system manual…check “Guidelines for restoring information from the development system”: https://www.ibm.com/docs/en/ssw_ibm_i_74/rzarm/sc415304.pdf

  Troubleshooting migration issues:

•  Check “Table 1. Data migration problems and resolutions” in the “Troubleshooting the data migration” section in the migration manual: https://www.ibm.com/docs/en/ssw_ibm_i_74/rzarm/sc415304.pdf, for specific SRCs and error messages like CPF3717: File not selected. File label or file name mismatch for file filename. The CPF3717 message occurs most frequently when the incorrect tape is inserted into the tape drive or when you have incorrect parameters for the RESTORE command. DSPTAP DATA(*SAVRST) will list what objects are saved to the tape being used. It is suggested to spool the result as the command is lengthy and having the result in a report to look at is useful if you need to refer to it more than once.
• Subsystem descriptions, access path recovery times and RJE configs are not restored on migration. You need to use PRTSYSINF and configure those manually. Check step 33 of the previous to current release migration steps in the release-to-release support chapter in the recovering your system manual;
•  Table 31. Recovery checklist for complete system loss–Checklist 20: https://www.ibm.com/docs/en/ssw_ibm_i_74/rzarm/sc415304.pdf
•  -        WRKJOB cannot be used to find joblogs as that info is NOT migrated; it is only restored if the restore is to the same system. If a new system, the job table is not brought over because that is a system specific object and can't be migrated because those job numbers did not run on the new system and would result in having duplicate job numbers if it was restored. There is no way to rebuild the association. Check: https://www.ibm.com/support/pages/node/685997;
• -        Restore the Jobs on the WRKJOBSCDE Screen Back to the System: https://www.ibm.com/support/pages/restore-jobs-wrkjobscde-screen-back-system
• -        Migrating distribution queues (QSNADS and SNDNETF) - Saving the SNADS Objects:
• https://www.ibm.com/support/pages/saving-snads-objects
• -        Job Logs, Job Dumps, and Service Dumps No Longer in QEZJOBLOG or QEZDEBUG Output Queue after Operating System Installation or Upgrade: https://www.ibm.com/support/pages/job-logs-job-dumps-and-service-dumps-no-longer-qezjoblog-or-qezdebug-output-queue-after-operating-system-installation-or-upgrade;