× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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-l-bounces@xxxxxxxxxxxx wrote on 10/10/2007 03:20:02 PM:

Tough to say what the culprit is without more info.

I assume there is a PGMC somewhere in the picture, one that runs PGMA,
then
PGMB. Is it possible PGMC is compiled with *SQL naming? Or PGMB?

If as you say SQL trigger is causing it because of *SQL naming, perhaps
you
can change it so it uses *SYS naming. You can do that by putting SET
OPTION
NAMING =*SQL just before the BEGIN statement in the trigger source.

All that said, UDFs are searched by SQL path. You can set the SQL path
explicitly, using SET OPTION statement, i.e.:

SET OPTION SQLPATH='QSYS,QSYS2,QGPL,MYLIBRARY,YOURLIBRARY'

That way you can be sure no matter what naming is used, your UDF is
always
located by the PGMB. SQL path is different from schema and libl path as
it
pertains to UDFs, SPs and like.

Lots of speculation I'm afraid. Perhaps if you share the message ids
you're
getting we'll be able to narrow down on it.

Well, let us know what it turns out to be.

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: trigger, UDF and SQL path

I have a UDF created in a lib that is on the system portion of my libl,
so
that it is always available to all users. The UDF is unqualified in the

SQL SELECT stmt in my pgm and is always found. I have added a SQL
trigger
to a file to monitor changes to a specific field and write an audit rec.

My issue: PGMA to change the field value is run and the trigger is
fired
and the pgm ends. PGMB is called that uses the UDF and it cannot find
the
UDF (Function UDF1 not found in library *N. ) Additional error info
states: A library name of *N indicates that the current SQL path was
used. So, somehow the firing of this trigger has caused my SQL stmts in

PGMB to no longer use the libl. It appears to be an issue with naming
(*SYS v. *SQL) but I am not sure where to look. Any help is
appreciated.


--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.






This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. Unless you are the addressee (or authorized to receive for the addressee), you may not use, copy or disclose to anyone this email or any information contained in this email. If you have received this email in error, please advise the sender by replying to this email, and delete this email immediately. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Western Dental Services, Inc. Finally, the recipient should check this email and any attachments for the presence of viruses. Western Dental Services, Inc. accepts no liability for any damage caused by any virus transmitted by this email.

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.