NAMING dictates several things. Obvious one is dot vs slash syntax. Not so
obvious is that *SQL assumes single schema (library), frequently determined
by authorization ID (aka *USRPRF). If object is unqualified, it has to be
in current schema. This is much different than what you're used to with
*LIBL.
However, for things like UDFs, SPs and distinct types, DB2 actually searches
thru function path (CURRENT PATH or CURRENT FUNCTION PATH special
registers). You can set this yourself. See:
http://publib.boulder.ibm.com/infocenter/iseries/v5r3/topic/db2/rbafzmstsetp
ath.htm#setpath
There is a LOT more to this of course.
As to your specific scenario... if you're saying PGMB is a totally
independent call... prior run of the trigger should have no affect on the
PGMB. If PGMB is invoked by the trigger, it may.
In any case, you can check CURRENT PATH at different levels and verify what
is it that's changing it and not resetting it.
Elvis
Mike Cain - DB2 for i5/OS Temporary Indexes - The Good, The Bad, The Ugly
October 16
2007 System i Fall Technical Conference | Orlando | November 4-7
Celebrating 10-Years of SQL Performance Excellence on IBM System i, eServer
iSeries and the server affectionately known as the AS/400
-----Original Message-----
Subject: RE: trigger, UDF and SQL path
Thanks, Elvis & rob for your responses.
I recreated the trigger using RUNSQLSTM specifying NAMING(*SYS) and that
fixed the problem (after changing my delimiters). I guess it is my lack
of understanding exactly how NAMING is used. Using RUNSQLSTM cmd I
thought the NAMING(*SQL) was only referring to the syntax in source member
being processed. But it appears much more. But I am still at a loss as
to why it affected a pgm call after executing.
Scenario: PGMA and PGMB are in an OCL member (S36). PGMA fires the
trigger. PGMB uses the UDF. I have a SET OPTION in PGMB specifying
NAMING = *SYS. So, why did the naming of the trigger(SQL) affect the
naming in PGMB (SYS)? Thanks.
midrange.com
