RE: Dynamically activing bound programs (was RE: Calling a Function fromRPG Program having multiple Functions)

>What am I missing?
Let's say I have an RPG Web Service program running under Apache named
RPGWEBSRV. I want RPGWEBSRV to receive in SOAP XML requests and place the
xml in the IFS for other programs to use further "down stream". Based on any
number of criteria RPGWEBSRV CHAIN's out to a PF and learns that service
program PARSE and its exported sub-procedure ADDPOSTADR should be
dynamically activated so the xml just read in and placed in the IFS can be
passed off and processed by PARSE.ADDPOSTADR.

When you dynamically activate a service program there is already an agreed
upon interface (the prototype) just as if it were bound during compile time.
In my case the prototype is as follows:

     D ADDPOSTADR      pr                  like(Error)
     D  pInXml                             value like(FilePath)
     D  pOutXml                            like(FilePath) 

So when RPGWEBSRV makes a call to PARSE.ADDPOSTADR it needs to have a
generically named prototype defined that matches the parameters above.  For
instance RPGWEBSRV could have this for a prototype to call PARSE.ADDPOSTADR:

     D handOff         pr                  like(Error)
     D  pInXmlFile                         value like(FilePath)
     D  pOutXmlFile                        like(FilePath)


Inside of PARSE.ADDPOSTADR the xml file name is received in, it then parses
the xml file for its data, and finally composes an xml IFS file to place in
the second parameter which was passed by reference. PARSE.ADDPOSTADR at this
point is complete and passed control back to RPGWEBSRV which in turn uses
the IFS file specified in the pass-by-reference parm and writes it to
standard out which is essentially the xml response to the remote requesting
program.

In that scenario RPGWEBSRV didn't know anything about parsing specific xml
data nor composing the response, it only cared that it read in the XML and
placed it in the IFS, and then received an outbound xml file to be sent to
standard out. The link between RPGWEBSRV needs to be dynamically activated
at runtime because a number of variables will determine which program to
call.

Does that describe it better?
Aaron Bartell

-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx]
On Behalf Of Wilt, Charles
Sent: Tuesday, May 09, 2006 1:17 PM
To: RPG programming on the AS400 / iSeries
Subject: Dynamically activing bound programs (was RE: Calling a Function
fromRPG Program having multiple Functions)

Aaron,

I can maybe think of a couple of places where Jon's dynamic activation is
useful.

But I don't understand what you're saying.

> PGM1 receives in a request and determines what program should be
called to
> process the xml based on DB2 entries. PGM1 then "activates" PGM2
> SUBPROCEURE1 and "hands off" the parsing of the request and the
composing of
> the response.

> Sure one could just stick to *PGM objects, but I find myself doing 
> more and more *SRVPGM's with multiple modules and sub-procedures, 
> which then necessitates the dynamic activation of those 
> sub-procedures.

I don't see anything here that requires the manual activation of a service
program and the use of procedures pointers to call the procedures.

What am I missing?

Charles Wilt
--
iSeries Systems Administrator / Developer Mitsubishi Electric Automotive
America
ph: 513-573-4343
fax: 513-398-1121
  

> -----Original Message-----
> From: rpg400-l-bounces@xxxxxxxxxxxx
> [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of albartell
> Sent: Tuesday, May 09, 2006 12:14 PM
> To: 'RPG programming on the AS400 / iSeries'
> Subject: RE: Calling a Function from RPG Program having multiple 
> Functions
> 
>  >Not that there are APIs for dynamically resolving the procedures in 
> a Service Program, this is not needed as often, but it has its uses.
> 
> Just to reinforce what Jon is saying, I find it beneficial to be able 
> to dynamically call a service program's sub procedure when doing web 
> services.
> PGM1 receives in a request and determines what program should be 
> called to process the xml based on DB2 entries. PGM1 then "activates" 
> PGM2
> SUBPROCEURE1 and "hands off" the parsing of the request and the 
> composing of the response.  To quote a hype phrase: "This creates 
> separation of concern", what happened to "modular programming"? :-)
> 
> Sure one could just stick to *PGM objects, but I find myself doing 
> more and more *SRVPGM's with multiple modules and sub-procedures, 
> which then necessitates the dynamic activation of those 
> sub-procedures.
> 
> 
> Aaron Bartell
> 
> -----Original Message-----
> From: rpg400-l-bounces@xxxxxxxxxxxx
> [mailto:rpg400-l-bounces@xxxxxxxxxxxx]
> On Behalf Of Jon Paris
> Sent: Tuesday, May 09, 2006 10:12 AM
> To: rpg400-l@xxxxxxxxxxxx
> Subject: RE: Calling a Function from RPG Program having multiple 
> Functions
> 
>  >> You can't do it that way.
> 
>  >> You need to place your functions into a service program. 
> 
> I agree that for most cases a Service program is the way to go - after 
> all that is what they were designed for.
> 
> However, your basic "You can't do it ..." statement is incorrect.  I 
> can and have done it several times.  In fact it is not even necessary 
> to bind the modules - you can treat _any_ PGM object as a service 
> program if you wish.
> 
> The basic requirement is that you have a means to call the PGM and it 
> responds by supplying one or more procedure pointers to its internal 
> procedures.  You then make subsequent calls via those procedure 
> pointers.
> 
> We have used the technique a number of times to get the effect of a 
> dynamically loaded "service program" - it also allows for
> semi) dynamic
> swapping of the "service program".  Not that there are APIs for 
> dynamically resolving the procedures in a Service Program, this is not 
> needed as often, but it has its uses.
> 
> 
> Jon Paris
> Partner400
> 
> www.Partner400.com
> www.RPGWorld.com
> 
> --
> This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing 
> list To post a message email: RPG400-L@xxxxxxxxxxxx To subscribe, 
> unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
> or email: RPG400-L-request@xxxxxxxxxxxx Before posting, please take a 
> moment to review the archives at http://archive.midrange.com/rpg400-l.
> 
> --
> This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing 
> list To post a message email: RPG400-L@xxxxxxxxxxxx To subscribe, 
> unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
> or email: RPG400-L-request@xxxxxxxxxxxx Before posting, please take a 
> moment to review the archives at http://archive.midrange.com/rpg400-l.
> 
>