Re: Unable to allocate record in Physical File

True, but the reason that I did not do it that way that the 2nd program (the one that can't do the update because of the lock) is usually a billing or inventory update program. Here the warehouse has priority. If Cheryl wants to bring up a record and then dilly-dallies around, she, not the warehouse, will suffer.
* Jerry C. Adams
*IBM System i Programmer/Analyst
B&W Wholesale Distributors, Inc.* *
voice
615.995.7024
fax
615.995.1201
email
jerry@xxxxxxxxxxxxxxx <mailto:jerry@xxxxxxxxxxxxxxx>



Booth Martin wrote:

Agreed, but here is the counterpoint, and why it is a design decision and not a programmer decision: The boss may decide that he does not want the second user walking around trying to find Cheryl and then chit chatting with her, or sitting and waiting until she comes back from lunch. The boss might easily decide its just easier to have the information typed in again later.

Buck wrote:

Jerry Adams wrote:

Unfortunately, most of us, self included, are usually too lazy to do the work necessary for steps 2+. But that's the real solution, Booth, because the problem is Cheryl in Sales or Morgan in Purchasing going off into LaLa Land.

Respectfully, the other real solution :-) is to allow the lock, trap it and tell the second one in that Cheryl is updating the record. which job is holding the lock is available in the file information data structure.

This has the advantage(?) of not forcing someone to key their update in again. It has the disadvantage that if Cheryl is updating the birthdate and you want to update the address, the two updates can operate concurrently without 'collision.'

Just something to chew on.
--buck