Authority to job logs

[Guest.Visitor]

The operators do not have authority to view job logs. They have *JOBCTL; isn't this enough? Is authority controlled somewhere else? Chris Stafford

[Guest.Visitor]

Authority to job logs

Chris, Add *SPLCTL to their authority list. This should work. When OUTQs are created they have specifications assigned identifying whether or not they are Operator Controlled, and wh has the authority to view the contents (OWNER, DTAAUT). The default is *OWNER. The creator is the only one who can view if *OWNER is used. *DTAAUT says anyone can. HTH.

[Guest.Visitor]

Authority to job logs

Job Control is usually enough authority for the operators. The only limitations are: 1. They may not view the job log of currently signed-on security officers. 2. They may not view the spools inside a secured output queue. If you wish to allow specific operators to view secured output queues, just give them the *SPLCTL special authority in their user profiles.

[Guest.Visitor]

Authority to job logs

The operators have *JOBCTL *SAVSYS & *SPLCTL and they still don't have enough authority. Most of operation jobs run with *ALLOBJ. This is probably the problem. -Chris

[Guest.Visitor]

Authority to job logs

Chris, As far as I know only profiles can have *ALLOBJ. I don't know how you assign that to jobs. Do the operators have access to any OUTQs, or are they restricted from all of them? If it's only a particular set, then they were probably created with specific ownership rules. If it takes someone with ALLOBJ authority to view the contents, there might be a reason for the way they were created. If they just contain normal everyday spool files then you can do something else. In this case I would create a new OUTQ called something, move the spools from the restricted OUTQ to the new one, delete the "bad" one, re-create it with default rules, and move the spools back. This should work. If any of the restricted Qs are for payroll or checks, or confidential financial data of any sort then leave them alone. Create a special profile with authority to view them and turn on auditing of the profile to protect the one who uses it. HTH

[Guest.Visitor]

Authority to job logs

Chris, Since your operators already have *SPLCTL, they obviously can see all spools. Your operators cannot view the joblogs of the running production batch jobs because the *ALLOBJ authority of the production jobs makes them "security officer" jobs. You can either give the operators *ALLOBJ authority, or else create for them a generic user-id with security officer authority, but with limited capabilities and a mandatory menu (also of your own design).

[Guest.Visitor]

Authority to job logs

Listen to Ricardo, he's on the right track. In order to view the joblog of a *ALLOBJ user's job, you must run with *ALLOBJ authority. If you don't want to gice *ALLOBJ to your operators (a good idea) create a quick and dirty CL wrapper for the DSPJOBLOG command and grant the operators authority to run it. jte MC Security Editor