RE: How to unlock a record. . .

That's a good idea.  May not work for all situations.  For example, if you 
are just updating a customers address and other applications updated 
balances, etc, you may not care.  Just update the fields in question.  But 
then again, maybe your maintenance application is the one that updates the 
timestamp field, and not a trigger that get's fired whenever any update 
occurs.

Goes to show why some vendors break down their files into multiple files 
and then use views to join them all together.  Static information might be 
in CUSTSTATIC, balances might be in CUSTBAL, etc.



Rob Berendt
-- 
Group Dekko Services, LLC
Dept 01.073
PO Box 2000
Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com





"Chris Wolcott" <CWolcott@xxxxxxxxxxxxxxxxxxxxxx> 
Sent by: rpg400-l-bounces@xxxxxxxxxxxx
10/07/2004 11:18 AM
Please respond to
RPG programming on the AS400 / iSeries <rpg400-l@xxxxxxxxxxxx>


To
<rpg400-l@xxxxxxxxxxxx>
cc

Fax to

Subject
RE: How to unlock a record. . .






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.

--
This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.