Re: Record locking 101 -- RPG400-L

Thanks John.

I omitted all the details on the implementation but checking the record before updating is part of the routine. I also have an IVR (Interactive Voice Response) application accessing the records as well so in this case the update may not of even had a human cause. But the check is there to make sure that something isn't lost (or at least the chance is minimized).

Thanks for that reality check though. It would be an ugly oversight.

Pete

John wrote:

Pete,

You have to also keep in mind that with your new method of
not locking the record that it will be possible for User A
to bring up the record for maintenance. Then before he/she
updates the record User B will be able to update that same
record. Then when user A presses <enter> to update the
changes done by user B can be lost.

What we do in our maintenance programs is:
A) Read record to be updated (Do not lock the record)
B) Store the record in a data structure A
C) Once the user makes changes and presses <Enter> to update
the program chains to the file for update (locks the record)
then compares the record it just retrieved to the Data
Structure A in Step B. If they are the same the program knows nobody else updated
the record and it proceeds with the update process.
If the values do not match then the program knows that
someone else updated the record and it releases the record
and a message is displayed that another user updated the
record press <Enter> to display the new values.

This process may cause someone to have to re-enter their
changes but it does not happen often that two users are
updating the record at the same time. But it can happen and
most likely will happen if you do not code for it.
But it is much better then having changes "lost"
(overwritten) because of a conflict when multiple users are
updating the same record at the same time. You do not want
to get a support call once a month with someone saying "they
know they updated the Customer Master file but there changes
are no longer there"
Because these calls will happen and they will happen very
infrequently causing the programmers to go crazy wondering
why the program does not update correctly some times.

John

-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Pete
Helgren
Sent: Monday, September 10, 2007 4:52 PM
To: RPG programming on the AS400 / iSeries
Subject: Record locking 101

I had a program that was originally written in such a way
that it would read/chain and lock a record while the user was in the
maintenance screen. That would cause problems for a posting program
that could also be run while records were being maintained. So I needed to
eliminate the lock in the maintenance program. Thanks to this list, I
modified the program so that the record data is now retrieved into a
data structure temporarily (with supposedly no lock on the
record) and then when the user presses enter the record is retrieved again
from the DB, the data updated and written without delay so that the lock
is very transitory.

Now comes time to test it. When this was originally
reported as a problem, I looked at the code and found the flawed design
and set about fixing it. I never looked at the job to see what the locks
on the record actually looked like. So now I am viewing the record
locks on the file and I am not sure what I *should* see. This is
what I do see when I am in the record in the "view" mode (shouldn't be a
lock on the record)

Record Lock Number Job User Number Status Type 494 QPADEV000R PETE 861530 HELD UPDATE

So I am guessing that I still have some more work to do,
yes?
An UPDAT or DELET after a CHAIN would effectively release
the lock on the record, correct?
What should the Lock Type be when you are just reading
through the records with no need to update?

Thanks,

Pete