RE: Record locking 101

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