RE: RE: Visual Basic and AS/400

["Schenck, Don" <Don.Schenck@xxxxxxxxxx>]

Walden --

I have RPG "objects" that can receive an "Operation" and a list of
parameters (which map one-to-one to the fields in the underlying table -- if
a table is used) and returns stuff.


Stateless objects are fine; I'm looking at this as an academic exercise
which eventually I may use. Right now we use MTS and links to the AS/400
through ADO. I'd LOVE to be able to call the AS/400 objects directly.


In your example: How can I do this:

MsgBox c.TelephoneNumber



(BTW ... your "pseudo code" looks STRANGELY like VB <wink>)

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

> -----Original Message-----
> From: Walden H. Leverich [mailto:WaldenL@TechSoftInc.com]
> Sent: March 15, 2001 3:30 PM
> To: 'MIDRANGE-L@midrange.com'
> Subject: 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
> +---
> 
+---
| 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
+---