Re: A question about record locks

Pete,
If you use a CHAIN(N) operation, you can not update the record without another 
CHAIN or READx operation.  The CHAIN(N) record does not lock the record for 
update.
If you use embedded SQL to FETCH records, you will not have a problem with 
record locks, but if you attempt to UPDATE, you have to deal with possible 
record locks.
 
Jeff Young 
Sr. Programmer Analyst
Dynax Solutions, Inc.
A wholly owned subsidiary of enherent Corp.
IBM -e(logo) server Certified Systems Exper - iSeries Technical Solutions V5R2 
IBM  Certified Specialist- e(logo) server i5Series Technical Solutions Designer 
V5R3
IBM  Certified Specialist- e(logo)server i5Series Technical Solutions 
Implementer V5R3 


  
 





----- Original Message ----
From: Pete Helgren <Pete@xxxxxxxxxx>
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Sent: Tuesday, October 24, 2006 12:58:10 PM
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.

Pete


Chris Bipes wrote:

You can have both applications updating the file, but only one program
can update a record at a time.  You can try changing the lock wait time
on the posting program to *nomax or something shorter than forever but
long enough for the user to complete their update.

The other way is to read the record in the maintenance program with no
lock, save the original image in a data structure, have the user make
their changes, then after all edits are passed, read the record with a
lock and see if anything has changed from the original saved image and
if not changes, update the file.  This way the lock is only for a second
under program control and not locked while the user is making changes or
home for the evening.

I have a sample somewhere that I can share showing how to code a simple
file update.


Christopher Bipes
Information Services Director
CrossCheck, Inc.