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

[Kelly Cookson <KCookson@xxxxxxxxxxxx>]

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.