Re: What is the best way to allow this to work?

On 29/08/2008, at 2:28 AM, Steve McKay wrote:

You are correct, sir! Eventually, a CL program gets called which changes
the Run Priority of the job (CHGJOB RUNPTY(11)), adds the physical file
member, then changes the Run Priority back to the original priority. This
CHGJOB command is what causes the error message, not the OVRDBF. I suppose
the changing of the Run Priority is for performance reasons (the entire
process is vendor-supplied) and whether it should be used is open to debate.
Nevertheless, what would one do to allow this to work (given that the
program itself cannot be modified)?

A number of options I guess:

1) Give the user in question *JOBCTL (which is the JDE solution to this problem and really not a good choice).

2) Change the owner of the CL program (the one that issues the CHGJOB) to a profile that does have *JOBCTL and issue CHGPGM USRPRF (*OWNER) on that CL program.

3) Since the default for program creation is to use any adopted authority from higher in the call stack then , as long as the CHGJOB CL program has not explicitly stopped using adopted authority, you could create an intermediary program whose sole purpose is to adopt suitable authority and then call the CHGJOB CL program. For example:

CL program A: OVRDBF stuff then calls
CL program B: adopting authority then calls
CL program X: vendor CHGJOB stuff

4) Use the profile token APIs to swap the current user to one with *JOBCTL, invoke the CHGJOB CL program, and swap back to the original user.

Regards,
Simon Coulter.
--------------------------------------------------------------------
FlyByNight Software OS/400, i5/OS Technical Specialists

http://www.flybynight.com.au/
Phone: +61 2 6657 8251 Mobile: +61 0411 091 400 /"\
Fax: +61 2 6657 8251 \ /
X
ASCII Ribbon campaign against HTML E-Mail / \
--------------------------------------------------------------------