Getting authorization to service a job.

465 pts.
Tags:
AS/400
authority issue
iSeries
Security
I'm trying to debug a bath program. But, I don't have authority to the job. Here's the error mesage:                         Additional Message Information                                                                                                      Message ID . . . . . . :   CPF3676       Severity . . . . . . . :   30        Message type . . . . . :   Diagnostic                                         Date sent  . . . . . . :   12/22/09      Time sent  . . . . . . :   11:10:51                                                                                Message . . . . :   Not authorized to service specified job.                  Cause . . . . . :   You do not have authority to service the specified job.     Servicing from another device or by someone else requires *USE authority to   user profile of the job to be serviced.                                     Recovery  . . . :   Obtain *USE authority to the user profile of the job to be   serviced from the security officer or the job owner, and then try the         command again.                                                              What command does my SECADMIN need to use to give me access to the job? I have *USE ability on the STRSRVJOB command.

Software/Hardware used:
AS400, iSeries, V5R4
ASKED: December 22, 2009  4:16 PM
UPDATED: March 3, 2010  2:36 AM

Answer Wiki

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

From the error message, it sounds like you need *USE authority to the user profile *USRPRF of the user that is running the job. Your SECADMIN can use a GRTOBJAUT with the following parameters

OBJ: The user profile of the batch job in question
OBJTYPE: *USRPRF
USER: Your user profile
AUT: *USE

There are more streamlined ways to organize the authorizations on your systems, but this should do the trick.

Discuss This Question: 11  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.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
  • Dcantwell
    *batch program... not a bath program! Sorry!
    465 pointsBadges:
    report
  • Dcantwell
    Thanks for the answer ElTerrifico. But, it didn't work. I'm still not authorized to the job and getting the same error.
    465 pointsBadges:
    report
  • TomLiotta
    Please show the job name of the job you want to service and also show the output from DSPOBJAUT for the *USRPRF of the job user from that job. Tom
    125,585 pointsBadges:
    report
  • ElTerrifico
    This is what the IBM manual has to say: Restrictions: To use this command, you must be signed on as QPGMR, QSYSOPR, QSRV, or QSRVBAS, or have use (*USE) authority to the user profile of the job being serviced. Since you tried the *USE approach and that didn't work, my next suggestion would be to log on as QPGMR or one of the other profiles mentioned and see if that works. It's been awhile since I've had to deal with authorities on a daily basis. I can't understand why the *USE authority didn't work. Sorry I couldn't be more help.
    620 pointsBadges:
    report
  • TomLiotta
    If the authority is shown to be set correctly against the job user, then there should be only a couple possibilities. Seeing actual details will give a solid basis for the next likely cause. Tom
    125,585 pointsBadges:
    report
  • TomLiotta
    Without verification, I'll add a general possibility. A common kind of job that might be running is a server job such as QZDASOINIT. It might be accessing a stored procedure that a programmer might want to debug through STRSRVJOB. The job commonly runs under user profile QUSER. However, whenever the job identity is actually QUSER, it's almost guaranteed that there is no useful debugging that can be done. It is only when a local user profile is being serviced that you're likely to be able to debug anything. Only local user profiles are likely to be requesting stored procedures that might be debugged. This principle applies to all host and TCP/IP server jobs. It can also apply to any local production jobs that might switch to other profiles in order to perform work. In short, it would be the Current User that you need *USE authority to, not the "job user". If a job has switched to QSECOFR, for example, and you started to service it, you could be altering variable values within a QSECOFR unit of work. That's why the *USE authority would have to be against QSECOFR rather than QUSER. But without seeing some distinct job and authority attributes, that's simply one possible guess. Other possibilities exist. Tom
    125,585 pointsBadges:
    report
  • Dcantwell
    OK... I did the DSPOBJAUT for the *USRPRF of QTMHHTTP and all I see is *PUBLIC/*EXCLUDE. I didn't go bother the security guy yet. The job is called AISERVER. I can easily get a QPGMR sign-on and go about my debugging. But, we'd like to just grant my *USRPRF the ability to do it (since I'll be doing it a lot).
    465 pointsBadges:
    report
  • ElTerrifico
    Setting the GRPPRF parameter on your user profile to QPGMR might work too.
    620 pointsBadges:
    report
  • TomLiotta
    I did the DSPOBJAUT for the *USRPRF of QTMHHTTP and all I see is *PUBLIC/*EXCLUDE. There should be at least two additional authority entries -- one for QSYS and one for QTMHHTTP. However, what you described is probably enough. The simple answer is to GRTOBJAUT AUT(*USE) to the QTMHHTTP user profile for you. As noted in the error message that you started with, it "...requires *USE authority to user profile of the job to be serviced." Since QTMHHTTP might be locked, it might be tricky getting that authority set. Probably better would be to add an authorization list to QTMHHTTP. Then you can add *USE authority for you to the authorization list. You could be added or removed from the list at any time without needing a lock on the profile itself. Further, someone else could be added or removed in the future without needing a lock on the profile. A more complex answer will be involved if the job ever switches to run under a different profile. But one step at a time. If the *USE authority is sufficient, that's as far as it will go. Tom
    125,585 pointsBadges:
    report
  • Dcantwell
    Looks like I had the wrong user. I don't really get it, but the job I was trying to service had a user of QTMHHTTP. But, I was granted *USE to another user for another reason and I decided to try running the strsrvjob command. Magically it worked! No idea why though. Thanks for all your help everyone!
    465 pointsBadges:
    report
  • TomLiotta
    Looks like I had the wrong user. I don’t really get it, but the job I was trying to service had a user of QTMHHTTP. But, I was granted *USE to another user for another reason and I decided to try running the strsrvjob command. Magically it worked! No idea why though. As noted earlier -- In short, it would be the Current User that you need *USE authority to, not the “job user”. Tom
    125,585 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.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

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

Following