RE: A question about record locks

["Wilt, Charles" <CWilt@xxxxxxxxxxxx>]

> -----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