RE: MVC Architecture and transactions

-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Joe Pluta
Sent: Tuesday, August 21, 2007 2:06 PM
To: 'RPG programming on the AS400 / iSeries'
Subject: RE: MVC Architecture and transactions

From: Nathan Andelin

If the program is written correctly, the files will get updated.

Programs written correctly? That can be a tall order. Some Yahoo
will come along and place and retain a lock on one of the records
within your transaction boundary, or forget to set the SIZE

parameter

on your file to *NOMAX records, or mess up some other configuration
directive, or push the little white button on the UPS...

I still think a competent programmer can handle this stuff,
just like we did for YEARS before commitment control even
existed. Record locks should be coded for. SIZE parameter
is a recoverable error. The little white button is going to
cause a lot more problems than just a record lock.

Joe,

I don't disagree that you don't absolutely need commitment control. Particularly in an all RPG
environment.

However, it would seem to me, that whatever workaround you come up with comes pretty close to
duplicating what commitment control provides.

Lets say that your process is updating a half dozen files, even if you get a lock on each record you
need before hand, you should still check for errors after each UPDAT, or have a monitor, or *PSSR to
handle unexpected errors right?

One big issue, is that RPG can only maintain one record lock per file. What happens if you're
updating multiple records in the same file?

The other problem, is nobody is 100% RPG anymore. Thus, the likelihood of "unexpected" has gone up I
think.

So what happens if something unexpected occurs in the middle of the process? You probably don't want
to leave the DB half updated, so your program needs to undo anything it had done to that point. Now
you could roll your own, or you could simply make use of the commitment control built into the OS.

I think I have to say that nowadays, if you're dealing with transactions, you should probably be using
commitment control.

Just my opinion of course,
Charles





This e-mail transmission contains information that is intended to be confidential and privileged. If you receive this e-mail and you are not a named addressee you are hereby notified that you are not authorized to read, print, retain, copy or disseminate this communication without the consent of the sender and that doing so is prohibited and may be unlawful. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please delete and otherwise erase it and any attachments from your computer system. Your assistance in correcting this error is appreciated.