Dynamically activing bound programs (was RE: Calling a Function from RPG 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.
> 
>