RE: A question about record locks

["Chris Bipes" <chris.bipes@xxxxxxxxxxxxxxx>]

Correct, after a Chain(N) you cannot do an update directly.  You must
re-read the record with a standard Chain allowing the lock.  Between the
second chain and the update your code should only check for changes from
the original to the re-read, if no changes, move the updated image to
the file image and write.

So the Pseudo code:
Chain(N)
Move to original image data structure
Load to user screen
Edit user changes
When pass edits,
Chain (with lock)
Check file image to original image (compare data structures if using
RPG)
If no changes,
Move user image to file image and write
Else 
Notify user of changes previously made and cancel update.

Now you can go to field level if you want
Original has O prefix
User update has U prefix
File has F prefix

Compare Ufield to Ofield
If changed:
Compare Ofield to Ffield
If no changes
Move Ufield to Ffield
Else 
Error Message and release record

Do this for each field the user can update.

If the user makes no changes to a filed, you are not updating the file
field and do not care if someone else has previously updated the record,
you have a lock and no one can read for an update until you release the
lock.  There is no user intervention during this process.  The coding
can be long but the logic is simple.  I like making it a module for file
update passing original and updated record images and forcing everyone
to use the module for file updates.  Then your application only opens
the file for input, not update.  (the module opens the file for
updates.)

 
Christopher Bipes
Information Services Director
CrossCheck, Inc.


-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Pete Helgren
Sent: Tuesday, October 24, 2006 9:58 AM
To: Midrange Systems Technical Discussion
Subject: Re: A question about record locks

Chris, Simon, Wilt,

If program 1 issues a CHAIN(N) on the record then it cannot issue an
update immediately after?  I understand that using a chain(N) and then
an update is dangerous, someone else could have updated the record, but
are you saying a chain(n) and then update would fail because it cannot
be done?  I'll have to go back at look at the code, seems to me it does
do a chain(n) and then an update but as Wilt said, maybe I missed
another chain somewhere.

How about SQL ?  If embedded SQL was used to read through the records in
the posting program B, when someone was maintaining a record in program
A, would the SQL fetch fail for the same reason?

Thanks for the information.  I'll have to review the code and ponder
this a bit more.