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

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