Sign on with QSECOFR at the system console. You can sign on with QSECOFR when it is disabled if you have access to the configured system console. After you re-enable it, the first thing you should do is create one or two other *SECOFR class profiles and stop using QSECOFR except when directions from IBM say to use it. — Tom
If you cannot log in as QSECOFR you need to log on with another profile that has SECADMIN authority and enable the QSECOFR profile. You can also do it through the service tools if you can log into them. We had a problem here a way back where ops changed the QSECOFR password before a long weekend. When they cam back they could not remember it.. 3 invalid logon attempts and the profile was disabled and were were dead in the water. IBM had to come in to resolve it. We now have a backdoor it it happens again. Take Toms advice if you do get in… create atleast 1 additional profile with the same authority.
Note that *SECADM is not sufficient; authority to the QSECOFR profile is also needed. And a secondary *SECOFR profile shouldn’t be considered a ‘backdoor’; it should be the primary security officer access. The QSECOFR profile itself should be the ‘backdoor’. — Tom
I know back doors are a security risk. It was not my call to do so. IBM spent about 6 hours here getting our QSYSOPR sign on back in working order. IBM set up the back door and I believe they have the login information. If it happens again we just need to place a service call. I think you also need a profile with *IOSYSCFG authority as well to reset QYSYOPR.
IBM spent about 6 hours here getting our QSYSOPR sign on back in working order.
Good example from experience. This relates to why IBM-supplied “Q” object types such as user profiles should not be used by applications. QSECOFR is the most important example, but others can also be significant trouble.
When objects are in use, there is higher risk of object damage. The QSECOFR profile is one of a couple critical profiles that the system relies on for basic operation. QSYS is the other. Those two can be needed simply to start the system.
If QSECOFR suffers any damage, it can be costly to fix it. The cost can be both in lost system time and in IBM consulting services. Damage due to system flaws may be repaired under normal maintenance. But recovery from damage due to customer choices in using QSECOFR instead of a secondary *SECOFR can be chargeable services.
It’s too easy just to create your own *SECOFR and use it for running security functions and owning customer objects. Ownership of objects should not be assigned to QSECOFR nor any other IBM profile.
For others threads here, similar consideration should go to using objects such as the QSYSOPR *MSGQ for application messages. Although the message queue can be used, it should be limited to operational functions, e.g., “Load tape” or “Restart printer” kinds of actions. The system itself expects QSYSOPR *MSGQ to be available for its messaging at all times. Use it with care. If you want to “log” messages, then create a MYLOG *MSGQ. It’s too easy, and it’s simply good practice to avoid interfering with the system itself.
In a previous job, I created a program to enable QSECOFR and QSYSOPR. It was created and owned by QSECOFR. Only my boss and I knew of this program. Later I added a parameter to reset the password (or just enable them) as the user name and set to change on next sign on. (Never told the auditors about it and they never asked.)