RE: SQL question on default *LIBL at connection

["Lowary, Jim" <jlowary@xxxxxxxx>]

Well we found where our last problem was in the iNavigator!  When we to
run the SQL script and it wouldn't run saying the statements it
generated weren't in the right convention.  We had to on the Run SQL
panel select Connection and then select JDBC Setup and change the Format
tab to also be *SYS (makes since if you know that it is there!).

Now when they can call the stored procedure and if it doesn't use
derived parameters it works!  However if they try and do a call using
DeriveParameters then they get this message:

"Test method SDI.Point.Admin.Test.AgentManagerTest.GetByCodeTest threw
exception:  System.ArgumentException: The stored procedure cannot be
found in SYSPROCS, or the procedure name is ambiguous.."

What is seems like (again I'm only guessing) is that it is finding every
instance of that stored procedure in the *LIBL and then trying to find a
match base on parms and finding more than one procedure that fits the
bill.  Rather than taking the first one it finds in the *LIBL.  

This may be the way it works as it is setup using *SYS, but I would have
expected it to work much like an iSeries find for a program; searching
each library in order of the *LIBL.  This way you could have multiples
and have your *LIBL structured like: Development/QUA/Production,
allowing CMS to handle moving the objects to the next level as it passes
testing, and only need those objects that are changed in the Dev/QUA
libraries.

I guess this is my question; is this working as designed (with the
DeriveParameters)? or is there some other setup issue that could be
changed to make it work more like what we are use to with *LIBL and
finding the object to run. 

Again thanks for all the help and suggestions!

Regards,
-- Jim Lowary
Mo Farm Bureau