Re: opnqryf question - opnid, joins, overides, etc.

John,

see inline.

>>the query still runs, and it appears that it builds the access path more
>>quickly than the other way around.  but now I've lost the opnqryf/rpg
>>connection.  the rpg is reading the the whole of FILE1, not the subsetted
>>records from the opnqryf, even though the override is still in place, and
>>i've named my OPNID the same.
>>
>>any ideas?  Thanks,

>Run the job,  and before it starts,  STRDBG on that job.  You don't even
>have to give it a program name.   Then,  Look at the SQL Optimizer
messages
>on in the joblog.  It probably contain this message;

>CPI4321
>"Access path built for file xxxxxx"

>The second level text on that message will tell you why it was building an
>index(ie what path you should have out there already).

I haven't been given permission (yet) to build logicals over the files.
this WOULD be the best way to solve the problem, but I have yet to convince
the powers that be.

>Other messages will help you too.

I'm getting the SQL optimizer messages, but they don't explain why my RPG
program isn't using the access path built by the opnqryf statement.

>Use this command  PRTSQLINF on the CLP program and look at the spool file
>created for clues.

PRTSQLINF doesn't work on the cl program - it says the program contains no
sql statements.

>John Carr

does the file name in the shared override that points the program to the
proper access path HAVE to be the primary file in the opnqryf join?

thanks,

rick