Re: SQL call qsys2.qcmdexc

On 2021-08-25 10:06 p.m., smith5646midrange@xxxxxxxxx wrote:

I have an SQLRPGLE program (call it ABC) that is owned by QSECOFR and the
user profile is set to *OWNER.

I have a service program that has an ExecuteCmd function that does an SQL
"call qsys2.qcmdexc(.)" to execute whatever command is passed to it. The
commands are soft coded in a file so I do not know ahead of time what they
will be.

Program ABC has this service program bound (probably not the right word)
into it. However, from an error that I am seeing from the ExecuteCmd
function, it looks like qcmdexc does not adopt the authority of ABC.

What does the service program have for USEADOPT?

I tried this with the qsys2.qcmdexc call in my srvpgm set to
exec sql call qsys2.qcmdexc('DSPPFM BMORRIS/ADOPTF');
where the file has *EXCLUDE authority for *PUBLIC.

My test program and srvpgm are all owned by a *SECOFR profile.

The test caller does not have authority to the file.

Scenarios:
1. - PGM has USRPRF(*USER)
- SRVPGM has USRPRF(*USER), USEADOPT(*YES)
Result: The DSPPFM command fails
2. - PGM has USRPRF(*OWNER)
- SRVPGM has USRPRF(*USER), USEADOPT(*YES)
Result: The DSPPFM command succeeds
3. - PGM has USRPRF(*USER)
- SRVPGM has USRPRF(*USER), USEADOPT(*NO)
Result: The DSPPFM command fails
4. - PGM has USRPRF(*OWNER)
- SRVPGM has USRPRF(*USER), USEADOPT(*NO)
Result: The DSPPFM command succeeds

I thought that my scenario 2 would be the same as your scenario, but in my case, the call to qsys2.qcmdexc did adopt the authority that the srvpgm is running under.

I'm not expert in adopted authority, so maybe there is some other attribute of the program or service program that controls this.