You are both on the right track.
> I may be wrong, but I have a vague memory that in the very early days, > multivalue databases (Pick?) didn't have record level locking.
Martin you are not wrong. And it wasn't the "very early days" :) Well maybe it was and I'm just a dinosaur ...
It was the early days until some of the PICK variants started doing record locks.
At any rate, Pick did group locking, not record locking. The entire group
a record is in was locked and held locked until the process was finished and
did it's WRITE or Release. So it's possible the use of LOCK is related to
that. Alternatively perhaps the program was trying to LOCK the entire FILE (!)
So in effect maybe it's doing a FILELOCK ?
The group locks were not a problem in low volume situations with little activity. In large applications (Like MMC - Manufacturing Management and Control - the predecessor of about 1/3 of the Manufacturing packages) processing was complex enough and high volume enough that group locks on multiple file updates often lead to deadlock situations.
Each file was assigned a semaphore lock. These semaphore locks were often used
in conjunction with record locking via Escom user modes and a LOCK file
to produce pseudo record locks.
Mark you said that the LOCKs are assigned to particular files, so if I
tried to read another record from that file I have to wait right? So this sounds
like a primitive form of FILELOCK to me.
It was more of a LOCK on updates to the LOCK file for records pertaining to a particular database file.
Bob Gerrish Kingsgate Enterprises, Inc. ------- u2-users mailing list [EMAIL PROTECTED] To unsubscribe please visit http://listserver.u2ug.org/
