Re: Procedure pointer

Hi Alan,

With the *PGM approach, the code would look like this:

/copy plugin_h

// Actually the Pgm name would probably come from
// a config file or something -- but here it's
// hardcoded...

PluginPgm = '*LIBL/PGMNAME';
Plugin_Load(PLUGINPTRS);

Plugin_Proc1( whatever: whatever);
Plugin_Proc2( whatever: whatever);


You say passing a data structure is ugly. I don't understand that. Why is it ugly? What's ugly about it? In my opinion data structures are a very elegant way to store a list of related fields.

Your code is (at the machine level) doing the same thing that mine is. You're calling a procedure by it's address in memory, and you're storing that address in memory. The difference is (a) how you're obtaining that address, and (b) you're storing the address in a series of standalone pointer variables, instead of a structure that groups them together.

As I said in my previous message -- you aren't getting any of the advantages of a service program when you do the logic this way. You aren't getting the value of signatures, export lists, etc.

As I also said -- really the only difference between the two approaches is that with a *SRVPGM you have to call _RSLVSP, QleActBndPgm and QleGetExp (multiple times). You say you have that all wrapped up in a service program so it's easy for you to do -- well that's a great way of dealing with extra complexity, encapsulate it into a reusable routine. Good job!

But isn't eliminating the complexity even better? Why should I do all of the work of searching for a disk object and activating it when the OS will do it for me?

Honestly, I don't want to get embroiled in a "holy war" with you (as seems to be the normal course of events on Midrange.com). I just want to present a technique that I find valuable.

I also want to emphasize that code that works this way is something that your average RPG programmer isn't going to do regularly. Indeed, many (most?) will go their entire careers without doing something like this. But in a niche situation where this makes sense, the technique I'm presenting works very nicely.

For ordinary situations where the code you're calling is known at bind-time, then a *SRVPGM is definitely the way to go.


On 4/7/2010 3:14 PM, Alan Campin wrote:

Just my opinion. Returning data structures with addresses of procedures seem
really ugly. Add a new procedure and new data structure.

Seems service program are designed to do exactly what you want. Expose
multiple procedures and I can add new procedures at anytime. I have the
QLEACTBNDPGM api in a service program so nothing to loading the procedure. I
am doing it all over the place.

/copy *libl/qsrcf,xvdynl_pr

d pptrCallProcedure...
d s Like(StdPrcPtr)
d CallProcedure...
d pr ExtProc(pptrCallProcedure)
d PR_DataString...
d 32767a Varying
d pptrTriggerProcedure...
d s Like(StdPrcPtr)

// If not loaded before, load the service program.
If Not ProgramLoaded;
pptrTriggerProcedure =
DYNL_LoadServiceProgramProcedure(ServiceProgramName :
ServiceProgramLibrary:
ServiceProcedure );

// Call the procedure to handle this message.
pptrCallProcedure = pptrTriggerProcedure;
Monitor;
CallProcedure(SendData);
On-Error;




On Wed, Apr 7, 2010 at 1:21 PM, Scott Klement<rpg400-l@xxxxxxxxxxxxxxxx>wrote:

Service programs can do the same thing -- though it's a little more
complex. I've used service programs as well.

But I don't know why you said they'd be "better". Remember, signature
checking isn't going to be done, since the service program library/name
isn't known at compile/bind time. So what does using a service program
gain you?

Using a *PGM means you don't have to resolve a system pointer (using MI
builtins) and call the QleActBndPgm/QleGetExp APIs. Other than
eliminating that bit of extra code, the work is the same...


On 4/7/2010 1:42 PM, Alan Campin wrote:

Sounds like service programs would work better.

--
This is the RPG programming on the IBM i / System i (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.