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?
> 
_______________________________________________
This is the Security Administration on the AS400 / iSeries (Security400) mailing list
To post a message email: Security400-Zwy7GipZuJhWk0Htik3J/[email protected]
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/security400
or email: Security400-request-Zwy7GipZuJhWk0Htik3J/[email protected]
Before posting, please take a moment to review the archives
at http://archive.midrange.com/security400.