|
So if you forget your QSECOFR password and then want to re-enable SST so you can use it during a manual IPL......
The recommendation not to use QSECOFR operationally also reduces the temptation for the profile to be customised in such a way as to make a recovery more difficult. I seem to remember ages trying to recover a machine where the QSECOFR profile had had an initial program added to it to provide a menu, among other things. Unfortunately the initial program was in a user library that had not been restored yet which gave me some trouble when trying to sign on as QSECOFR in order to start the data restore process.
I've seen a lot of sites where the QSECOFR profile has a job description that lives in an application library - a practise I don't like for the reasons stated above, but also because my preference is to not have production libraries in the QSECOFR library list (or even any SECOFR class profiles used for admin) unless they are added. It seems to me that it reduces the possibility of a disaster at least marginally when the profile is in use.
Regards Evan Harris At 02:41 p.m. 16/06/2006, you wrote:
midrange-l-request@xxxxxxxxxxxx wrote: > 8. RE: Installing 3rd Party Software using QSECOFR?? (rob) > >But I'd argue that audit rules that forbid installation under QSECOFR but >think it's ok to use any user profile with the following special >authorities: *ALLOBJ *AUDIT *IOSYSCFG *JOBCTL *SAVSYS *SECADM *SERVICE >*SPLCTL; is simply doing "busy" work instead of "real" work. Much like >the silly audit rule about limiting your users to one 5250 session when no >rules are in place about accessing the data with multiple other tools, >like Excel, simultaneously from the same user.No disagreement there, Rob. I should emphasize that I'm not defending various rules from clueless auditors in that case, but only pointing at the directions things have been going.QSECOFR, though, is indeed a special case. There are aspects of QSECOFR that are unique such as the ability to logon at the console even when disabled or the retention of special authorities even when you try to remove them. E.g., compare a prompted CHGUSRPRF QSECOFR against any other profile and note that a number of attributes for QSECOFR are presented as [*SAME] where all other profiles show the actual retrieved attribute values (assuming you have authority).Alternative *SECOFR profiles can be more controlled. QSECOFR is not so easy.A minor area... The more often QSECOFR is in use, the more the risk (admittedly very minimal) of object damage to the user profile from unexpected system failures during work. The safekeeping of the profile itself can conceivably outweigh the desire for simplicity from not using a secondary *SECOFR profile in heavily audited and controlled environments. Today's OS/400 and i5/OS minimizes the risk and might even have eliminated it. There have been circumstances where a damaged (not just *DISABLED but damaged) QSECOFR was trouble though.And when there's no _need_ to use it? Why use it? Why risk it? It simply ought to be fundamental policy to use an alternative profile if possible. IBM's directions to "Signon as QSECOFR..." seems to be a reasonable exception.Barsa Consulting also seems a plausible additional exception. Though I'm unaware of a specific requirement to install under QSECOFR, there may be particular multi-system/LPAR/single-hardware-platform operational tasks that only QSECOFR can do.For audits, it's often the policy and adherence to that policy that are most important. I often have no valid idea _why_ some particular rules are involved, but auditors aren't always rational outside of their universe.Tom Liotta -- Tom Liotta The PowerTech Group, Inc. 19426 68th Avenue South Kent, WA 98032 Phone 253-872-7788 x313 Fax 253-872-7904 http://www.powertech.com
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.