Re: Call back procedures -- RPG400-L

Rick,

Obviously, I don't know your business as well as you do. I'm not exactly sure how many potential errors exist in a given transaction. Is a transaction made up of multiple pieces, each one can have an error? Or is a transaction something as simple as "debit XXX dollars from account YYYY"?

I guess my suggestion is to go down to the atomic level. The level where it'll either pass, or you'll have one error (not a list of them)

So if you had a single transaction, you might do something like this:

if TRANS_edit(XXX: YYY) = FAIL;
errorMsg = TRANS_getError();
endif;

If you had a whole batch of transactions to process, and you wanted all errors loaded into a subfile, it would just be a matter of doing this:

read TRANS;
dow not %EOF(TRANS)
if TRANS_edit(XXX:YYY) = FAIL;
errorMsg = TRANS_getError();
// add errorMsg to subfile here.
endif;
read TRANS;
enddo;

If you wanted to process all transactions in batch, and stop as soon as ANY transaction has failed, you'd do it more like this:

read TRANS;
dow not %EOF(TRANS)
if TRANS_edit(XXX:YYY) = FAIL;
errorMsg = TRANS_getError();
// send error message to operator
LEAVE; <-- to exit loop
endif;
read TRANS;
enddo;

To me, this seems simpler than monkeying around with callbacks. Posting your transactions should be done in a separate step. (Possibly immediately after you've found that you have no errors while editing)

read TRANS;
dow not %EOF(TRANS)
if TRANS_edit(XXX:YYY) = FAIL;
errorMsg = TRANS_getError();
// send error message to operator
LEAVE; <-- to exit loop
endif;
read TRANS;
enddo;

setll *START TRANS;
read TRANS;
dow not %EOF(TRANS)
if TRANS_post(XXX:YYY) = FAIL;
// shouldn't happen because they passed the
// edit, above... but just in case...
TRANS_writeToRejectList(XXX: YYYY);
errorMsg = TRANS_getError();
// log error message somewhere
endif;
read TRANS;
enddo;

Seems to me the only reason you want to add the complexity of a callback (or array or whatever) is because you're trying to make your transaction edit routine (or transaction post routine) handle the whole list instead of handling one at a time.

If a transaction consists of multiple smaller pieces, then write your subprocedure for those smaller pieces, instead of writing them at the transaction level.

Again, I don't know your business logic as well as you do... so I might be completely off base. But please give it some thought.

Rick.Chevalier@xxxxxxxxxxxxxxx wrote:

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.