QSYSOPR does not have authority to perform upgrade

1005 pts.
Tags:
AS/400
AS400 iseries
IBM iSeries
QSYSOPR
we were trying to perform the Prepare for Install from GO LICPGM and loaded the CD'S as QSYSOPR and we were NOT AUTHORIZED, is OS upgrade on iSeries not a part of QSYSOPR profile?
1

Answer Wiki

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

It has always been my understanding that you do a system upgrade signed on as Qsecofr. I Do Not think the Qsysopr Profile has all of the necessary authority.

Hope this helps,
Bill Poulin

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.
  • TomLiotta
    As Bill noted, QSYSOPR should not have authority to do system upgrades. The upgrade instructions should direct you to sign on with QSECOFR. Follow the instructions for the upgrade and there should be fewer problems. Tom
    125,585 pointsBadges:
    report
  • Rrbond07
    The only profile that should be used when upgrading the OS is QSECOFR.
    750 pointsBadges:
    report
  • ToddN2000
    Agreed, QSECOFR is the only profile that should be used for system upgrades. QSYSOPR may have some of the same authorities but not all of them.
    134,930 pointsBadges:
    report
  • TheRealRaven
    A big part of this is that many system objects that may be replaced during an upgrade require QSECOFR ownership/authority. An operator should not have that level of authority.

    System upgrades are among the very few functions where QSECOFR should ever be used after a system is initially installed and running. The upgrade instructions should specify QSECOFR, and QSECOFR should only be used at IBM's instruction.

    That includes avoiding assigning ownership of non-IBM objects to QSECOFR (or really any IBM-supplied profile), running jobs, setting as group profile, etc. During initial system install, QSECOFR would be used to create a local *SECOFR profile and initial DST profiles, and the local *SECOFR profile would be used from then on instead of QSECOFR. That's except when IBM says otherwise in supplied instructions.

    Technically, this often also means questioning IBM support during general problem help if they tell you "Sign on as QSECOFR." Verify that a local *SECOFR can't be used because they tend to assume that sites have not properly set up security. And it should always be done for 3rd-party problem support. No 3rd-party vendor should ever require QSECOFR. If they do, it indicates potential significant problems with their capabilities.
    36,115 pointsBadges:
    report

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.

Following

Share this item with your network: