RE: Call back procedures

We are rewriting part of our payment posting logic currently written in RPGIII as RPT programs. As part of the new design we are moving from monolithic edit and posting programs where both editing and posting for all transactions is in a single program to procedures for specific edits that can be used by multiple transaction types. These same edits can be used both in an interactive program and nightly batch posting. For interactive processes we want to list each error on a transaction and display them in a subfile for the end user to work with. For batch processing, any error causes that transaction to be rejected. The discussion is how to best write the edit procedures so that it would handle both scenarios.

At this point the design looks like this:
1) Service program containing edit procedures common across multiple transactions. One procedure per edit. Each procedure returns a pass fail indicator and an error message as the first parameter.
2) Service program containing a module for each transaction type. The module contains an edit procedure and a post procedure. The edit procedure will call the common edits as necessary.
3) Program doing the posting.

The thinking behind using a callback is that as the transaction edit procedure encounters an error it can call back to the posting program to let it know there is an error and receive a continue/stop response depending on what the posting program requires. If the requirement is to stop on the first error the edit module could be told to stop. If the requirement is to accumulate error for a subfile the edit module could be told to continue on.

Hope this helps.

-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Scott Klement
Sent: Friday, May 08, 2009 1:52 PM
To: RPG programming on the IBM i / System i
Subject: Re: Call back procedures

I've written massive amounts of code using call-backs. They are a good way to write tools intended for programmers, allowing those programmers to insert their own code at key points in the process. Making things much more flexible (usually at the cost of complexity)

The only real gotcha that I know of with callbacks themselves is that you end up defining the prototype for the procedure twice, and there's no system-provided tool that verifies that the prototypes match. Thus, it's relatively easy to have parameter mismatches (much like the old CALL/PARM/PLIST opcodes -- you eschew many of the advantages of prototypes)

Other than that... it's hard to find a "gotcha". I mean, callbacks are
plumbing. They are a way to call a routine. Sometimes they are the
right tool for the job, and sometimes they are not. But without any context, it's hard to list "gotchas" or "should-a/could-a".

So... what do you plan to do with your callback?

Privileged and Confidential. This e-mail, and any attachments there to, is intended only for use by the addressee(s) named herein and may contain privileged or confidential information. If you have received this e-mail in error, please notify me immediately by a return e-mail and delete this e-mail. You are hereby notified that any dissemination, distribution or copying of this e-mail and/or any attachments thereto, is strictly prohibited.