× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Hi Paul

Maybe have the CL owned by a profile with *JOBCTL, then change the program to use USRPRF(*OWNER).

It should probably do nothing other than this action.

The owning profile should probably have no password and initial menu of *SIGNOFF

HTH
Vern

On 8/17/2016 3:18 PM, Default wrote:
This may not apply to you, but we just ran across this issue where a CL
program issues a CHGJOB command to change RUNPTY to 51. This CL never
had an issue until the program was allowed to be run by the user
community. Now it fails because our when our users run the job because
they do not have *JOBCTL authority.

---
Paul

On 2016-08-17 15:27, CRPence wrote:

On 16-Aug-2016 12:44 -0700, Rob Berendt wrote:

I ran these:
CPYAUDJRNE ENTTYP(AF) JRNRCV(*CURCHAIN)
RUNQRY QRYFILE((QTEMP/QAUDITAF))
I am seeing numerous authority failures for CHGJOB.

Definitely a batch job. Actually it's a job submitted by a Domino
agent from another system. So, it's not an interactive thing in which
someone with limited capabilities is trying to interactively run
CHGJOB.

Library Object Object Program Program
name name type name library
*N CHGJOB *CMD QWTCHGJB QSYS

Code Type
T AF

Job User Job
name name number
INV500S1 ORDINQ 136,491

Same job name, same job user, job number is never the same. Often
the increase is only 2 numbers.

Program Program
name library
QWTCHGJB QSYS

User
profile
ORDINQ

Violation
type
K
[http://www.ibm.com/support/knowledgecenter/en/ssw_ibm_i_72/rzarl/rzarlsecaudje.htm]
_Security auditing journal entries_
"An attempt was made to perform an operation for which the user did not have the required special authority."

Object . . . . . . . : CHGJOB
Library . . . . . : QSYS
Object type . . . . : *CMD
Object secured by authorization list . . . . . . . . : *NONE
Object
User Group Authority
*PUBLIC *USE
QSYS *ALL
CHRIS *ALL
QPM400 *ALL
QSRVAGT *USE

So user ORDINQ would be part of *PUBLIC.
Again, Special Authority, not private, public, adopt, et al.

No joblog currently available.

Does SBMJOB implicitly run CHGJOB? Even so, why the authority
failure?
Probably not.

cmd='SBMJOB CMD(CALL PGM(INV500S1) PARM(''B''))'
+ ' JOB(INV500S1) JOBQ(INV500S1)';
callp QCMDEXC(Cmd:%len(Cmd));
That appears to be data from the job that made the request to start [aka submit] the job in which the T-AF eventually was logged, not from the job for which the T-AF was logged.?

I can't see anything else here which indicates a CHGJOB

IBM i 7.3
User ORDINQ is lacking the necessary Special Authorities (SPCAUT) for which [some of] the specified parameters require the *JOBCTL special authority; i.e. for which the msg CPF1337 "&3/&2/&1 not authorized to change parameters." is expected for the failing request. You will want to find the error for the improper Change Job (CHGJOB) request, i.e. obtain and review a joblog [or trace] for the job from which that T-AF was logged.

--
Regards, Chuck


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.