Q Users in the iSeries – enabled or disabled?

5 pts.
iSeries User Profiles
OS/400 and iSeries
Where can I find a list of Q Users IDs and if they need to be disabled or enabled by default?

Software/Hardware used:

Answer Wiki

Thanks. We'll let you know when a new response is added.


Profiles starting with Q are usually set up by IBM and come with the recommended default enabled / disabled setting. The password for these profiles should be changed from their default password to something known only to those in IT that need to use the profiles.


Appendix B., IBM-Supplied User Profiles, in the Security Reference manual covers IBM profiles. The general STATUS() default for all IBM profiles is *ENABLED. Table 144 in Appendix B lists differences for each IBM profile for defaults. For example, the QCLUMGT profile is one of those that is supplied as STATUS(*DISABLED).

Note that the default is not the same as what the value ought to be for any profile. If you don’t want logons to be processed for an IBM profile, then set it to STATUS(*DISABLED) regardless of any default.

Also note that IBM believes that a number of profiles should not have passwords. For example, the CFGSYSSEC command will set QSYSOPR, QPGMR, QUSER, QSRV and QSRVBAS to PASSWORD(*NONE) because they should not be logged onto except in unusual circumstances.


Discuss This Question: 4  Replies

There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when members answer or reply to this question.
  • Batman47
    Type GO SECURITY, option 8 then option 2. This is will give you a list of the IBM profiles that begin with 2 and will be excluded from being disabled from the password expiration interval. You can add or remove profiles from this list by using the CHGACTPRFL command. It is not recommend that you mess with IBM profiles unless you are changing IBM default passwords (like QSECOFR).
    1,050 pointsBadges:
  • graybeard52
    QSYSOPR is used heavily most places I have been. Why would you NOT want a password for it ?
    3,115 pointsBadges:
  • TomLiotta
    QSYSOPR... Why would you NOT want a password for it ? Bear in mind that I reported the CFGSYSSEC command actions, which is as supplied by IBM. I can't supply reasoning for them. I can see possible reasons though. In my opinion -- In general, objects that supply basic system functions should be left alone. I prefer not to use default objects except as sources from which to create my own copies. It has become more common to create local *SECOFR profiles rather than to rely on QSECOFR itself for example. Why should other profiles be any different? Consider that the risk of damage to an object rises in mostly direct relationship to the amount of time that the object is in use. Why subject "master versions" of objects to added risk when it's so easy to use copies? How difficult is it to create an operator's profile? What happens during an upgrade if a profile such as QSYSOPR had previously had some internal damage during a power failure? (I have no idea, but I don't want to find out.) If QSYSOPR isn't in use, damage to a local operator profile won't have much effect on system operation. But the system makes some special use of QSYSOPR and related objects by itself. If I have production printed output from RPG, it won't be to QSYSPRT or QPRINT. I'll create a PRTF of my own or use one (of mine) that was already created. IBM objects are subject to IBM control. Long-term stability and predictability comes from having known objects with known attributes that are under your control. Those thoughts are just from my general opinions. I don't recall working at a site in my career with AS/400s that actually made use of QSYSOPR (among others) as a live profile. I am fully aware that those sites were unusual -- having as many varied customers as we've had in the past 10 years keeps me mindful of the state of things. Beyond simple opinion, also note that QSYSOPR would be an obvious target. Simply being a known profile on any system should be reason enough for PASSWORD(*NONE). If it can't be logged onto, it's a lot safer to have around. In any case, IBM is where the value comes from. I suspect they have good reasons. Making it a default action of CFGSYSSEC should at least get sites thinking about it. Tom
    125,585 pointsBadges:
  • Rayj1031
    From an Audit standpoint, QSYSOPR does not (or should not) relate to a single individual. If you are serious about security, each of your system operators should have their own unique user ID and password. As soon as more than one person knows the password to a single profile, then you lose the ability to accruately audit who did what on the system. For true system accountability, each person should have their own unique and unshared USERID.
    335 pointsBadges:

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

To follow this tag...

There was an error processing your information. Please try again later.

Thanks! We'll email you when relevant content is added and updated.


Share this item with your network: