I recently did the following to safely change QCRTAUT to *USE on our production and development systems:
1. Changed the CRTAUT value for library QSYS to *CHANGE
2. Changed the command default for the CRTLIB command to AUT(*USE) 3. Changed QCRTAUT to *USE
After having done this we have found that the SAVRSTOBJ command no longer works. Error CPFAD8D is received. If the SAVRSTOBJ command is run with QSECOFR authority it will work. If the remote location has QCRTAUT = *CHANGE the SAVRSTOBJ command also works.
Any ideas on what the problem could be?
I can't tell you exactly what the problem is, but hopefully the following suggestions will get you the information you need to be able to make that determination.
CPFAD8D is a rather non-descript (read that, not helpful) message until you look at the second-level help. That's where the system gives an indication if this is a problem on the save, restore or both. With the information that you gave me, I'm guessing that the failure is occurring on the remote system and that you don't have sufficient authority to some object.
Whenever you have a problem that looks like an authority problem there are two resources to turn to - OS/400 auditing and Appendix D in the Security Reference manual, SC41-5302. I suggest that you turn on OS/400 auditing. In the QAUDLVL system value, make sure to specify *AUTFAIL to audit for authority failures. Try the failing operation, then look in the QAUDJRN journal for an "AF" (authority failure) audit entry. This should tell you the exact object for which you don't have authority.
Next we have to figure out what authority you need. This is where Appendix D comes in. Appendix D contains a table of all OS/400 commands and the authority required to run those commands. If you look at Appendix D for SAVRSTOBJ, it says that you need the same authority as either the RSTOBJ or SAVOBJ commands. You said that the command works if you change the QCRTAUT system value on the remote system back to *CHANGE from *USE so I'm assuming that we need to look in the RSTOBJ table. Since I didn't have the name of the object from the audit entry, I looked for something for the RSTOBJ command that would require more than *USE authority. The RSTOBJ table indicates that you need *EXECUTE and *ADD to the To-Library. Since *USE is composed of *OBJOPR, *READ and *EXECUTE authorities, but not *ADD, my guess is that the problem is the library you're restoring the object into. (It is always the case that you need *ADD authority to the library to create an object into it.) If this is not the object you're having a problem with, try taking a look at Appendix D for other objects that I might have missed and that might be indicated in the audit journal entry.
Dig Deeper on iSeries system and application security
Related Q&A from Carol Woodbury
Before changing password levels and upgrading operating systems on the AS/400, ensure the clients connecting to the NetServer do not need the old ... Continue Reading
When error messages arise concerning attempts to use a permanent system object without authority, find the source of the issue by looking for an AF ... Continue Reading
The UPPWEI field corresponds to the password expiration interval field, and its values "0" and "-1" represent the *SYSVAL and *NOXMAX commands. Continue Reading