RE: How to unlock a record. . .

["Chris Wolcott" <CWolcott@xxxxxxxxxxxxxxxxxxxxxx>]

What we do is put a 'Z' Timestamp field in the record.  Save the value
in the TimeStamp in a hidden field with the data on the display.  (Works
for sub-files too.)  When the user wants to update, re-read as below and
compare the timestamp in the record to what is in the display file.  If
it is the same, update the timestamp and then the record.  Saves time on
worrying about roll-over errors, and you don't have to compare the
entire DS.  Most folks want a LAST MODIFIED field anyway, so this
doubles as that.  (Add a usrprf field and you have WHO & WHEN.)
 
------------------------------

message: 7
date: Thu, 7 Oct 2004 10:42:04 -0500
from: rob@xxxxxxxxx
subject: re:How to unlock a record in an interactive job after 'x'
        amount

I think I saw this technique in an ancient book by IBM.  It was some
sort 
of design concepts book and I think it came out in S/34 time or earlier.
You read the file without a lock, spash the data on the screen and wait 
for input, saving a copy of the original data in a data structure or
some 
such thing.  When it comes time to update the record you chain again and

compare for any critical updates.  Like if they were changing the
customer 
address and someone else has changed it in the meanwhile.  If there was 
another update you error back to the screen.  If not, you update the 
record.  In the olden days you opened the file twice in your program;
once 
as read only and once as update.  Now we have the no lock option on a 
chain on an update file.

Rob Berendt

------------------------------------------------------------------
message: 8
date: Thu, 7 Oct 2004 17:03:11 +0100
from: "Jonathan Mason" <jonathan.mason@xxxxxxxxxxxxxxxx>
subject: RE: How to unlock a record in an interactive job after
        'x'amountoftime has passed


In the good old days we used to have a logical with the same key
structure
as the physical.  The physical was always used for the update/locking
reads
and the logical for input only.

These days I use the (N) extender on the chain/read opcodes so that the
record isn't locked, and don't use when I want to lock the record.  On
every
file I always code an Update No field (3.0 packed) which I increment by
1
before updating the record.  That way when I read for the update, I can
compare the value of the field against the value when I read without
locking
the record and if it's different I know somebody else has updated the
record
between times.