Re: Migrate system distribution directory entries

I realize a CLP to ADDDIRE etc. was decided already, but ...
Just an FYI about expectations for restore of database files with user data into the quasi-system libraries like QUSRSYS. I would recommend to *never* do that unless there is a _full_ understanding of what is being done and why; few will have that ability. I am not trying to generate any responses nor scold anyone, merely to provide some comments as education.

As a simple statement "save these files from the old system and restore them to the new one" might work for one scenario but not the next, for any number of reasons. I infer the suggestion means to DLTF before, but that is not clear, and there is no warning to *not* use ALWOBJDIF(*ALL) which could be very problematic if DLTF were omitted. And for having done DLTF, then private authority recovery becomes an issue that then needs to be resolved. Many people end up purchasing consulting contracts to clean up messes from having ignored the upgrade/migration roadmaps, having incorrectly inferred the solution to the original concern was just a simple save & restore.

There are conversion routines allowing for up to N+2 installations of QUSRSYS [& qgpl & qsys2]. There are upgrade 'migration' paths documented to take advantage of this. Effectively if the new system is no more than N+2, to mimic a valid upgrade, the new system can have the old objects placed in the quasi-system library [quasi-user, as user data is stored there; QSYS2 is now also in this category] such that an install of QUSRSYS will then effect the upgrade of those old objects. The trick is ensuring that the old objects are there, correctly; not an exercise for the novice when there is already a valid current release copy of the database files with user data. This is easiest accomplished when the new system was scratch installed with LIC and i5/OS only, and then the restore into an *empty* QUSRSYS would occur -- and then it is acceptable to use ALWOBJDIF(*ALL)