Re: Resolving *SRVPGM for ext stored proc

[Justin Taylor <jtaylor.0ab@xxxxxxxxx>]

Turns out one of the stored procs shouldn't have been there.  It looks like
I created it accidentally back at the very beginning of the project.  I
rebuilt and promoted, and only the stored proc in the correct library was
updated.  I deleted my faux pas, and it looks like we're good.

Thanks all!



On Thu, Mar 19, 2026 at 12:28 PM Javier Sanchez <
javiersanchezbarquero@xxxxxxxxx> wrote:

> Yes. but....
> 1. I believe that if in the CRTSQLRPI you do not specify *SYS as part of
> the OPTIONs where you see  *XREF, it defaults to SQL  and if
> SQLPATH(*NAMING) is specified, the SQLPATH will take the SQL value.  I
> suggested you use both values: *SYS in OPTION and SQLPATH(*LIBL).
> 2. In the CREATE OR REPLACE PROCEDURE there is an option that you have to
> include like "SET OPTION NAMING = *SYS"  along with other options.
> 3. Try to connect from the outside interface with a user profile that has a
> job description that includes those libraries, where the external sprocs
> are defined.
> 4. In the connection string, there is also something similar to
> "NAMING=*SYS" or so, see the .NET or Java documentation.
> 5. LANGUAGE has to be "RPGLE".
>
> Not sure either, but if you use a service program, I think I remember that
> the EXTERNAL NAME must include the library, or else it does not accept
> *LIBL.
> i.e. EXTERNAL NAME 'MYLIB/MYSRVPGM(MYROUTINE)'.
>
> If I am wrong with anything, please someone let me know.  I got rid of all
> these kinds of issues by standardizing like this, so I do not remember
> exactly what I had to face but I could resolve them.
>
> HTH.
> JS