Re: A question about record locks

Hi:

The program-enforced locking system used by CA's PRMS (I believe sold by CA
since we last paid for maintenance) is to create a record in a locking file
that has the User ID - alternatively the workstation, depending on module -
and all of the key field values necessary to uniquely identify the "locked"
record in the data file. When that record is no longer in use, the program
that was using it deletes the locking record. Any program that can update
the data file must first check the locking file. If a matching locking
record is found, the program cannot proceed; the user (if interactive) is
notified; and a "soft landing" is performed as necessary and appropriate.

Importantly, this system can be used to enforce relational integrity
programmatically. Even when a record is not locked by the operating system,
it can be protected from changes that would affect other files (such as
deletion of a record in a header file when related records in a detail file
exist).

This approach is the safest, if properly implemented, I think. However, it
really ratchets up the complexity of programs that open and modify multiple
related files. Maintenance is a degree of difficulty greater than otherwise
equivalent programs.

Darrell

Darrell A. Martin  -  630-754-2187
Manager, Computer Operations
dmartin@xxxxxxxxxxxxx

midrange-l-bounces@xxxxxxxxxxxx wrote on 10/24/2006 01:03:03 PM:

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