Re: External SQL procedure must be ILE?

CREATE PROCEDURE &LIB/MATCHANITEMCODE (
IN @STORER DECIMAL(4, 0) ,
IN @SUFFIX CHAR(2) ,
INOUT @ITEM CHAR(20) ,
OUT @LOT1 CHAR(20) ,
OUT @LOT2 CHAR(10) ,
OUT @LOT3 CHAR(10) ,
OUT @QUANTITY DECIMAL(7, 0) )
LANGUAGE RPG
SPECIFIC MATCHANITEMCODE
NOT DETERMINISTIC
NO SQL
CALLED ON NULL INPUT
FENCED
EXTERNAL NAME '*LIBL/ITP20R'
PARAMETER STYLE GENERAL ;

Here's the source that produces that message.


Remove *LIBL, then RUNSQLSTM fails with this message.
SQL0449 30 4 Position 74 External program name for routine
MATCHANITEMCODE in Z_PD3464 not valid.

On Tue, May 15, 2012 at 11:08 AM, Michael Schutte <mschutte369@xxxxxxxxx>wrote:

I was wrong, it was reason code 1. Program not found. *LIBL is not valid
on EXTERNAL NAME. However, check out reason code 3. It says "The external
program was not an ILE *PGM or
*SRVPGM"


Hence me asking the question.

Message . . . . : Routine MATCHANITEMCODE was created, but cannot be
saved
and restored.

Cause . . . . . : The routine MATCHANITEMCODE was created successfully
in
MSCHUTTE with a specific name of MATCHANITEMCODE, but the routine's

attributes could not be saved in the associated program or service
program
object. If the *PGM or *SRVPGM object is saved and then restored, the
SQL
catalogs will not be updated with the attributes for this routine.
Reason
code is 1. Reason codes and their meanings are: 1 -- The external
program
did not exist when the CREATE statement was issued. 2 -- The external

program schema is QSYS. 3 -- The external program was not an ILE *PGM or

*SRVPGM. 4 -- The external program was in use by another job. 5 -- The
SQL
associated space in the external program was in use by another job. 6 --
The
SQL associated space in the external program could not be expanded. 7 --
The
external program was compiled in a release prior to V4R4M0. 8 -- The SQL

associated space in the external program already contains the maximum
number
of routine definitions. Recovery . . . : Do one of the following based
on
the reason code: 1 -- Ensure that the external program exists when the

CREATE statement is issued. 2 -- Ensure that the external program schema
is
not QSYS. 3 -- Ensure that the external program is an ILE *PGM or
*SRVPGM. 4
-- Use WRKOBJLCK to ensure that the external program is available when
the
routine is created. 5 -- Ensure that the external program is available
when
the routine is created. 6 -- Try recompiling the external program to
rebuild
the program's associated space. 7 -- Recompile the external program in a

more recent release. 8 -- Drop one of the routines currently defined for
the
external program.



This isn't my issue, but the question still remains.

On Tue, May 15, 2012 at 11:01 AM, Michael Schutte <mschutte369@xxxxxxxxx>wrote:

cuz I thought it was a simple enough question.


On Tue, May 15, 2012 at 10:57 AM, CRPence <CRPbottle@xxxxxxxxx> wrote:

On 15 May 2012 07:19, Michael Schutte wrote:

I could of sworn that I've seen someone call an external RPG3 program
using external SQL procedure. I'm obviously wrong because I just
received a message in the joblog saying that it must be an ILE
program. <<SNIP>>

There are "data type" restrictions. For example with CLP, there is
no support for a VARCHAR parameter [even though the CL could easily
approximate its effect, just like was presumed\allowed for INTEGER.

Rather than merely stating "a message in the joblog saying...", why
not include specifically what was the error message identifier, the
associated first and second level text, and the context of the error
condition, by actually including the spooled\formatted message text in
the message; and the joblog header also includes the release level?

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.