Re: Calling a stored procedure that exists on the As/400 from PHP

I would be happy with a PHP-ILE compiler. PHP would become another syntax available for developing ILE program like CL, COBOL, and RPG.

Of course, you would be running ILE programs at that point, not PHP web scripts. A PHP-ILE program would be no better at creating a web-faced GUI than a CL, COBOL, or RPG program.

The advantage would be letting a shop use one syntax and one set of programming tools for all their needs. Develop PHP-ILE programs for batch processing on the back end, and develop PHP scripts for web-based GUIs on the front end. I might still use CL to set up program run environments. But I would be able to stop using COBOL and RPG at that point.

And I'd be happy to win the lottery...

Kelly Cookson
Senior Programmer/Analyst
Dot Foods, Inc.
217-773-4486 x12676
www.dotfoods.com


-----Original Message-----
From: web400-bounces@xxxxxxxxxxxx [mailto:web400-bounces@xxxxxxxxxxxx] On Behalf Of CRPence
Sent: Friday, March 12, 2010 2:14 PM
To: web400@xxxxxxxxxxxx
Subject: Re: [WEB400] Calling a stored procedure that exists on the As/400 from PHP

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.