× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.


  1.  Home
  2. MIDRANGE-L
  3. October 2006

Re: A question about record locks

So it seems like Chris' approach, or something similar, will always be the safest bet since the time between chain and update will always be minimized (nearly eliminated). The user who retrieves a record for maintenance and wanders off somewhere, won't prevent a process from proceeding by locking a record.
The posting routine may delete records, so I'll need to take that into account, as well as an update that changes the record from another source.
This will take some time to change the program but seems the best all around approach. I'll dig into the archives for examples. 
Thanks.

Pete


Wilt, Charles wrote:

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

As an Amazon Associate we earn from qualifying purchases.

This thread ...
Follow-Ups:
Replies:
Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.