RE: A question about record locks

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx 
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Pete Helgren
Sent: Tuesday, October 24, 2006 12:58 PM
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?  

Correct.

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?  

Yes, before you can update the record, it has to be read and locked via
a CHAIN/READ/READE/READP/READPE without the (N) extender.

You can't update a record you don't have locked.

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?

Yep.  SQL isn't magic.  It can't do anything RPG can't do.  It works
through the DBMS same as RPG native I/O.

SQL0913 - Row or object &1 in &2 type *&3 in use.
If a record is locked by another application process, try the SQL
statement again when the record is not in use. The Display Record Locks
(DSPRCDLCK) command will determine who is currently using the record.

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

Pete

Charles Wilt
--
iSeries Systems Administrator / Developer
Mitsubishi Electric Automotive America
ph: 513-573-4343
fax: 513-398-1121