Re: user with a record lock

Another choice is to find where in the program the record has a situation
where there is a prolonged lock. Then change the code. Generally there is
little business need to create an extended locking period.
 
Here is an algorithm that works in most situations:
Define 3 data structures, the first externally described with the record
format, the other two like the first one. I use "OriginalValuesDS", 
CurrentValuesDS", and "NewValuesDS"
read the record (don't lock it) and move the data into "OriginalValuesDS".
do the processing. Move the new values into "NewValuesDS".
chain again, locking this time. Move the record values to "CurrentValuesDS"
If CurrentValuesDS = OriginalValuesDS then do the update.
if CurrentValuesDS <> OriginalValuesDS then the record was changed at
another workstation and you can decide what happens then. You can even do a
field by field compare, and if the changed fields don't conflict, do the
update. For example, if one user changes the phone number and the another
user changes the zip code then there's no conflict to resolve. Accept both
changes.
 
This may take a little while to implement, but probably not all that much
longer than establishing who has the record locked, and in my opinion it is
a much more elegant solution.
 
 
---------------------------------------------------------
Booth Martin http://www.MartinVT.com
Booth@xxxxxxxxxxxx
---------------------------------------------------------
 
-------Original Message-------
 
From: RPG programming on the AS400 / iSeries
Date: Friday, August 08, 2003 10:17:08 AM
To: rpg400-l@xxxxxxxxxxxx
Subject: user with a record lock
 
I am having difficultly with what I thought would be a simple thing to do.
 
When a user tries to update a record that is locked by another job, I want
to tell the user not only that the record is locked but who has the record
locked. I am trying to use the the API QDBRRCDL since it would return all
the info I would need.
 
I can get the Library/File/Member name from the INFDS but the all alusive
relative record number I don't have because I didn't have a successful
file operation. The RRN comes back as a big fat ZERO.
 
I could do a CHAIN(N) right after my error to get the proper RRN but that
seems very cumbersome and expensive. I also could leave the RRN at ZERO
and it would send all the records that a have a lock. That again would
seem cumbersome and expensive to figure out which one I really want.
 
Am I missing something???? Is there another API?
 
Daniel