Re: 3rd party app failed to start on IPL, because QPGMRpasswordwasset to *NONE

On 06-Jul-2016 15:29 -0500, Joe Wood wrote:

On 06-Jul-2016 15:11 -0500, Paul Nelson wrote:

On 06-Jul-2016 13:53 -0500, Paul Nelson wrote:

On 06-Jul-2016 13:44 -0500, Steinmetz, Paul wrote:

<<SNIP>> This issue only occurs during IPLs, which default to
QPGMR running the QSTRUP job.

I would really like to change QSTRUP to run as a different
user, would solve this and many other issues related to QPGMR
having insufficient authority to run a process.

If QSTRUP is "owned" by QSECOFR or a profile with QSECOFR's
authority, your issues will go away. QPGMR and others will adopt
the authority for the duration of QSTRUP running.

Recompile the program as QSECOFR or equivalent. Delete the program
first. Change the user profile parameter to *OWNER. Change the
replace parameter to *NO.

When you read the help text for the user profile parameter, you
will know why the program needs to be deleted first. You'd be
amazed how many "seasoned" programmers don't know about this, and
wonder why they have authority problems at program execution time.

+1 to Paul Nelson

That's the technique we utilize for our QSTARUP program running
under QPGMR... no issues.

Recompiling the QSTRUPPGM to adopt *SECOFR authority is generally of no assistance for influencing a function that must /run as/ a user. What would typically be resolved by use of adopted authority, i.e. what some specific subset of "issues will go away", would be issues with a direct origin of the user QPGMR having insufficient authority to some /QSYS.LIB objects [at least when using access methods outside of those using IFS root naming].

Specifically, the OP [with the uncorrupted Subject] was not about lacking authority to invoke, but about an invocation failing for the lack of a password for user QPGMR under which the process is being run; i.e. likely, per QPGMR as the current-user of the job. Having changed the program adoption will have no influence on what is the current user running the process, thus no influence also, on the user associated with the Java class for access on a connection [which presumably, by default, runs as the current-user for the job].

p,s. I kept the effect of what I suppose was some crappy email client whereby some [space] characters were dropped from the [somewhat long] Subject line; in that way, my reply sorts with those other messages having that same\matching corrupted subject-line.