RE: Call back procedures

Scott,

I think you are real close in your perception of what we are doing. Let me try to fill in the missing bits.

We are at the atomic level with the edits. If an edit fails it returns an error. Each edit is a procedure. These procedures make up a service program.

Each transaction has an edit procedure unique to that transaction which makes the specific atomic level procedure calls in a predetermined order. It is possible there may be some editing here unique to the transaction but we are trying to remove it if possible. This procedure combined with it's companion posting procedure makes up a service program. One for each transaction.

The controlling program processes one or more transactions and will make the call to the transaction edit program. This is where the determination of failing on a single error or grouping them for display will be made. It has been suggested that this be passed to the transaction edit procedure so it can make the decision as that is where the editing logic is being handled. If the edit checks all pass then the posting procedure is called. Very much like your last example.

Rick


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

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.

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.