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

[Pete Helgren <Pete@xxxxxxxxxx>]

I'll know in a bit if it IS working.  But here is what I thought was 
happening:

We set the overrides at *JOB scope using this program at entry time.  
The overrides DO persist, I can use the wonderful WRKODBCJOB by Bryan 
Dietz and see them all there as long as the job persists.  I assumed 
(perhaps wrongly) that because it was the program owned by FUSER the set 
the overrides that all transactions using the overrides were under the 
FUSER authority.  I guess my question would be, if the overrides set by 
the program owned by FUSER don't carry FUSER's authority, then, at that 
point, who's authority do the overrides carry?

Always dangerous to assume things...That is why I went to the list.  
I'll know a bit later after we make some changes and bounce Tomcat.

Pete


Wilt, Charles wrote:

> 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
> >
> >
> >    
>
>