Re: Restoring user profiles and QUSRSYS

James Rich wrote:

<<SNIP>> Now I'm at the point of bringing over the user profiles
from v5r3 to v6r1. I have saved them on the old system using
SAVSECDTA but I'm unsure if I should bring them over for a couple
of reasons:

1. Many user profiles are no longer in use and now seems like a
good time to get rid of them.

2. The old system was at security level 20 and the new one is at level 40 and many of the old profiles had *SECOFR authority. Now
seems like a really good time to end that poor practice.

Any thoughts? Should I just bring over the old profiles or should
I create new ones and make everyone recreate their passwords?

I used to re-create the users on my systems in order to forcibly lose all private authorities; these were test systems in the lab, and invariably some idiot would issue a GRTOBJAUT QSYS/*ALL *ALL AUT(*ALL) USER(IDIOTuser) to bypass some authority issue. There is unlikely to be many systems, test or production, where losing all private authorities is desirable; on some later release IIRC, those authorities could have been saved with the objects, but not v5r3.? Anyhow even if loss of private authorities were acceptable, I stopped the recreate of users due to the difficulties caused for users. Using CRTUSRPRF vs RSTUSRPRF, many customizations are lost. For example customizations from both the CHGPRF and to the IPE [Interactive Profile Entries; that which "remembers" preferences, esp. for *PREV or *PRV special values on commands, and F##=Set Default]. I discovered that it was better for me to just restore all of the users, then before RSTAUT to delete any users that were no longer desired; additionally to eventually change any user profiles as required to meet whatever security guidelines.

Secondly, I need to bring over old output queues and printer configurations. These are stored in QUSRSYS I believe. Obviously
the new system already has a QUSRSYS and I don't want to replace
the v6r1 QUSRSYS with objects from v5r3. What is the best way to
handle this?

The devices are part of SAVCFG as Lukas noted; only the associated output queue objects are saved with the QUSRSYS library.

Anyhow, the option exists to save just what is of interest using the SAVOBJ, e.g. with something like OBJTYPE(*MSGQ *OUTQ). Or even to restore just was is of interest with OMITOBJ and\or using the OPTION(*NEW) from the selective save. If any restore would include database files that have the character 'Q' as prefix, then be sure to *not* specify the single value *ALL for the ALWOBJDIF() parameter; i.e. only specify each desired special value separately, even if effecting the seemingly equivalent to *ALL.

Typically for this N+2 upgrade+data-migration, the entire *LIB object QUSRSYS would have been saved with SAVLIB and then RSTLIB in its entirety into the empty library QUSRSYS that had been created by the install of *only* the OS. Having done so the "user data" in that pseudo-system library would not be lost in the upgrade to the other system. Note that at least the two pseudo-user-libraries QGPL & QSYS2 have similar issues for possible user data loss in a migration where the RSTLIB was not effected at the correct time in the migration, and could be similarly negatively impacted for restore [esp. of database files, and worst with ALWOBJDIF(*ALL)] into those libraries. If these libraries are empty, then probably best to just restore the entire libraries from the v5r3 system; then like with user profiles, delete the user objects that are either not needed or not wanted.

Regards, Chuck