× 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.



Okay, So, I'll try setting the path before the create statement and leave
the external name softcoded.

Then when the call is made, it will adopt the path and search for the
unqualified CL in the PATH?


On Thu, Dec 13, 2012 at 12:45 PM, CRPence <CRPbottle@xxxxxxxxx> wrote:

On 13 Dec 2012 10:15, Michael Schutte wrote:
<<SNIP>> if I'm using system naming and library
list. Should the call look like this...

DECLARE @VALUE CHAR(80);
SET @VALUE = '';
CALL ODWPROD.GetNextWorkingOrder(@VALUE);

instead of

CALL GetNextWorkingOrder(@VALUE);

The latter should be fine, when using NAMING=*SYS and PATH=*LIBL

<<SNIP>>

CREATE PROCEDURE ODWPROD/GETNXTWRKORD
( INOUT NXTWO CHAR(80) )
LANGUAGE CL SPECIFIC ODWPROD/GETNXTWRKORD
NOT DETERMINISTIC NO SQL CALLED ON NULL INPUT
EXTERNAL NAME EBI001C /* <-- *i <ed: note: unqualified!> i* */
PARAMETER STYLE GENERAL ;

This is how I would prefer it to be <<SNIP>> letting the system find
unqualified objects based on the library list.

That being said, I don't see how I can specify the SET PATH on this
particular CREATE PROCEDURE statement.


The CURRENT PATH that is defined when the CREATE PROCEDURE is
performed will define the PATH for that routine. Because the routine is
EXTERNAL and not a LANGUAGE which allows SQL information to be stored,
there is no option to use PRTSQLINF to show the PATH. See the results
of the following query to show the current attribute of SQL PATH for
routines with that name:

select varchar(specschema, 10) rtn, varchar(sql_path, 33) path
from qsys2.sysroutine
where specname='GETNXTWRKORD'

Thus, the feature that is utilized to effect the CREATE PROCEDURE
could issue a SQL request to SET PATH *LIBL prior to the SQL request to
CREATE PROCEDURE. If using RUNSQLSTM and NAMING(*SYS), with no SET
[CURRENT] PATH being issued, the default is implicitly PATH=*LIBL used
for the statements in the source member.

--
Regards, Chuck
--
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.



As an Amazon Associate we earn from qualifying purchases.

This thread ...

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.