RE: Do I understand USRPRF *OWNER USEADPAUT *YES correctly?

["Wilt, Charles" <CWilt@xxxxxxxxxxxx>]

Pete,

Ok, I understand why/how your are using the overrides.

But I don't see how the program you are call can affect the authority.

USRPRF(*OWNER) is only in affect while the program is active, ie. in the call 
stack.  I don't know how this would be of any use to your JDBC job.

Is this actually working for you?  If it is, then either I don't know what I 
think I do, or I'm missing something in your explanation.

Does the program your JDBC job is calling do a profile switch or something?

Charles Wilt
iSeries Systems Administrator / Developer
Mitsubishi Electric Automotive America
ph: 513-573-4343
fax: 513-398-1121
 
> -----Original Message-----
> From: midrange-l-bounces@xxxxxxxxxxxx
> [mailto:midrange-l-bounces@xxxxxxxxxxxx]On Behalf Of Pete Helgren
> Sent: Friday, April 08, 2005 11:44 AM
> To: Midrange Systems Technical Discussion
> Subject: Re: Do I understand USRPRF *OWNER USEADPAUT *YES correctly?
> 
> 
> Thanks Charles (and Don) for the clarification on the 
> USEADPAUT.   That 
> explains something else I had a problem with.....
> 
> But going back to your question about "What am I doing?"...
> 
> If we just issue a standard JDBC connection the iSeries, we have a 
> couple of problems (at least, I think so...)
> 
> 1. No overrides are set (we have multiple membered files and creating 
> alias's is a needless hassle when we can just override the 
> files).  So 
> we have to set overrides.
> 2. We have some authority issues to deal with.  The user 
> profile used in 
> the JDBC connection may not have authority to the 
> files/libraries in the 
> application.
> 
> If we connect to the iSeries, we get a persistent QZDASOINIT 
> job as long 
> as the connection exists.  That is a good thing because we 
> are pooling 
> connections.  So, once the connection is established, we just 
> call the 
> program that sets the overrides and, since the program is properly 
> owned, those overrides persist with the correct authority as 
> long as the 
> connection is in place. Cool! That is just what we want because the 
> servlet(s) need to access the data.  The pooling mechanism we 
> wrote is 
> "smart" enough recognize when the member requirements or library list 
> has changed and when they do change, we create a new pool 
> entry and call 
> a program that sets the new overrides. 
> 
> It was the override/authority issue we wanted to solve.  Since the 
> program, called at the time of the JDBC connection, sets the 
> overrides 
> and is properly owned, everything is good.  We were running 
> into issues 
> where we were getting "Not authorized to file XXXXX" messages and I  
> *think* it was because the CL program we called to set the 
> overrides was 
> set to *USER rather than *OWNER.  I'll know as soon as I stop 
> Tomcat and 
> shoot the JDBC pooled connections and restart.
> 
> We haven't yet gone to a three tiered solution yet: Java ---> stored 
> procedures --> database.  It adds some additional work up 
> front that we 
> haven't had time to do and since the bulk of the work I do is 
> at 30,000 
> feet (while traveling), writing programs and testing them in Linux is 
> much easier in the Java --> database realm.  I can run them against 
> MySQL while I write and test and then deploy the WAR file when I get 
> home and I am done.  (OK, there is some laziness there....).
> 
> Thanks again on the USEADPAUT tip....I need to change a couple of 
> programs and test this....
> 
> Pete
> 
>