Re: Encapsulating Stored Procedures with adopted authority

DSPPGM of the CLP shows the proper adoption; i.e. *OWNER and the owner is the expected *USRPRF name which has the necessary object & special authorities to perform the requested CHGUSRPRF? Does the CLP function outside of the SQL? That is, does a CL request to CALL CLP function, whereas the SQL request to CALL CLP does not function? What is the error encountered that suggests an inability to "get the authority to work" correctly? As an external procedure with a LANGUAGE other than SQL, there is no support for SET OPTION; i.e. the manner of effecting "options" are specific to a language, such that for a CLP the USRPRF(*OWNER) is what gives the adopted authority setting on a request to CRTCLPGM REPLACE(*NO). Note: the DSPPGM noted first should be verified, because the default is REPLACE(*YES) such that if a prior version of the CLP existed before CRTCLPGM was issued, and only some later invocation include the option USRPRF(*OWNER), the program will not have that setting regardless that it was requested; i.e. a diagnostic is logged to suggest that the request was ignored.

Regards, Chuck

Vanderhook, George wrote:

I have a CL program that I'm using as a stored procedure. I need
to put *SECADM authority on this stored procedure so that when
accessed by users on a Windows server, they are able to run the
procedure via a JDBC connection. My problem is that I cannot get
the authority to work. I created the CL program with User:
*OWNER and created it with a *SECADM sign-on. I see how SQL
stored procedures can have SET OPTION USRPRF to do this but when
I try this option for an external procedure it doesn't work. I'm
simply using the STRSQL console from the iSeries and a CREATE PROCEDURE statement. Any ideas?