RE: RE: Visual Basic and AS/400

Don,

Why would XML and HTTP make your program an object? If your definition of an
object is "I can call it, pass it some parameters, and get back some data"
isn't any program an object. I'd almost argue that the answer is yes, all
programs are objects, but they are stateless objects.

Now, through the careful use of the LR indicator you could make a program
"remember" data from call to call, however you could have only one instance
of this object in a job. It would be roughly akin to a "static" object in
C++ and (i think) Java. Now, C++ and (I think) Java allow multiple instances
of an object though a hidden "this" pointer that is passed on all calls. 

You can accomplish the same thing by passing back and forth a parameter to
identify the object. This is called a "magic cookie." The rule behind the
magic-cookie is that you don't care what it is, what it means or how it's
used, you just pass it to each call. It is a bunch of bytes that you don't
attempt to interpret.

I've created "objects" in RPG before where I have a creation program, a
bunch of programs that operate on the object and a destruction program. Look
at this Object Oriented psuedo-code:

dim c as Customer
set c = new customer
c.load(27)
c.deleteorders
c.deletepayments
c.deletecustomer
set c = nothing

This declares a variable called 'c' as a Customer object. The next line
creates a customer object, then we associate that customer object with
customer # 27. Next we tell that object to delete all the orders for that
customer, then all the payments and then delete the customer itself. The
object is then destroyed. Fairly generic OO stuff.

Now try this psuedo-RPG Code:

D       MagicCookie             S               7,0
C       call            crtCustObj
C       parm                            MagicCookie
C*
C       call            lodCust
C       parm                            MagicCookie
C       parm                            27
C*
C       call            dltOrd
C       parm                            MagicCookie
C*
C       call            dltPay
C       parm                            MagicCookie
C*
C       call            dltCust
C       parm                            MagicCookie
C*
C       call            dltCustObj
C       parm                            MagicCookie

This is OO RPG. Now this begs the question "What is MagicCookie", well the
wiseass answer is "You don't care", but the real answer is MagicCookie is
the key to a file that stores the member variables of a instance of the
Customer Object. 

There is no magic to OO, just a "this" pointer.

-Walden

PS. In my implementation of an Object, all objects are persistent. That is
to say they survive job termination and IPL. As long as you have the
MagicCookie value you can get back the object and call it's methods.

-----Original Message-----
From: Schenck, Don [mailto:Don.Schenck@pfizer.com]
Sent: Thursday, March 15, 2001 2:37 PM
To: 'MIDRANGE-L@midrange.com'
Subject: RE: RE: Visual Basic and AS/400


Hmmmm ... okay ... here's the problem:

I want to create an RPG program that acts as an "object"; I can call it,
pass it some parameters, and get back some data.

I guess the answer at this point is to use XML and the HTTP "Post" operation
and write the CGI in RPG so that it returns an XML string.

??

-- Don Schenck
   Schenck Technical Consulting
   DonS@SchenckTech.com / www.SchenckTech.com 

> -----Original Message-----
> From: Hall, Philip [mailto:phall@spss.com]
> Sent: March 15, 2001 2:14 PM
> To: 'MIDRANGE-L@midrange.com'
> Subject: RE: RE: Visual Basic and AS/400
> 
> 
> > But ... but ...
> > 
> > I thought the idea of ILE was several entry points???
> 
> Yes, but to call the various entry points in a *SRVPGM you 
> need a *PGM (ILE)
> you can't call them directly from the command line.
> 
> You could of course write a generic dispatcher *PGM that took 
> parameters
> similar to;
> 
> PARM1 --> *SRVPGM name
> PARM2 --> Entry point name within the above *SRVPGM
> PARM3 --> 'real' parm 1 to entry point function
> ...
> PARMN --> 'real' parm N to entry point function
> 
> The dispatcher would then invoke the entry point. Of course, 
> you'll need to
> handle returning any data from the function and pointers, but 
> it would be
> similar to how OS/400 allows the OS/400 API's to be called 
> from the Client
> Access toolkit API's
> 
> --phil
> +---
> | This is the Midrange System Mailing List!
> | To submit a new message, send your mail to MIDRANGE-L@midrange.com.
> | To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
> | To unsubscribe from this list send email to 
> MIDRANGE-L-UNSUB@midrange.com.
> | Questions should be directed to the list owner/operator: 
> david@midrange.com
> +---
> 
+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator:
david@midrange.com
+---
+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---