× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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.

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.