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



If the PHP interface were "nice" [as I recall it is for REXX in CMS] then I would expect the following to function more directly than having to prepare and execute using parameter markers [i.e. the question marks] and their respective variables:
"CALL GEMLIB.XXX111(:$Item , :$Desc)"
or "CALL GEMLIB.XXX111('". $Item . "' , :$Desc)"

In a prepared statement, it would be more like the following:
s01 = "CALL GEMLIB.XXX111('". $Item . "' , ? )"
odbc_prepare( s01 ...
odbc_execute( s01 ... with effective USING for the $Desc

However perhaps like suggested in "Support for INOUT and OUT parameters of stored procedures" at the following link, the return value will need to instead, be fetched from a result set; i.e. an SQL procedure is introduced as a wrapper to invoke the original procedure with the INOUT value, the result which is then returned as an expression on the SELECT cursor.
http://www.ibm.com/developerworks/data/library/techarticle/dm-0502scott/

Regards, Chuck

Gqcy wrote:

This is where I am getting confused. I think this is the reason some examples do the "question mark thingie" to position and load
the parameters, with a odbc_prepare...

But I haven't found out how to get that to work either.
I see that in some examples of using odbc_prepare it tells me
that if you want to use INOUT, or OUT, you may need to use the
"native extensions" for that database...

CRPence wrote:
Is that "CALL GEMLIB.XXX111('$Item''$Desc')" or "CALL GEMLIB.XXX111('$Item' '$Desc')"? Either way is problematic. The
apostrophes suggest the values passed are literals.? A literal
is not addressable for OUT; nor would an omitted parameter be addressable, but that would require the procedure was overloaded.

Gqcy wrote:
CRPence wrote:
i.e. time would be better spent actually examining the what
& why of any difficulties in using the ODBC with stored
procedures.


here is where I get stuck:

how my procedure is created:
CREATE PROCEDURE XXX111
(IN PARM1 CHAR(15),
INOUT PARM2 CHAR(30))
EXTERNAL NAME GEMLIB.XXX111
LANGUAGE RPGLE ;

My PHP:

<? $Item = '30019590 ' ;
$Desc = ' ' ;
$con = as400connect();
$sqlqte = "CALL GEMLIB.XXX111('". $Item . "''" . $Desc. "') ";
SResultq = odbc_exec($con, $sqlqte) or die ("db Query Error");
echo 'SResultq = ' . $SResultq ;
echo 'Description: ' . $Desc ;
?>

My RPGLE program:
FXXXL01 IF E k disk
FQSYSPRT O F 132 printer
**
C *ENTRY PLIST
C Parm inprod 15
C Parm outdesc 30
**
C inprod CHAIN(e) XXXL01
C if %found(XXXL01)
C Eval outdesc = XDESC
C EndIF
C Except detail
C Eval *inLR = *on
**
oQSYSPRT E Detail 1
o INPROD +0001
o OutDesc +0001


RESULTS:
My program gets called. INPROD = '30019590'.
HOWEVER I get a PARM error, OUTDESC is NOT ADDRESSABLE.


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

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.