Too Many Open Files (was Re: The CLOSE command)

[Fairlight]

This public service announcement was brought to you by Kenneth Brody:
> 
> As I said in my previous post, it simply narrows the window of
> opportunity for shooting oneself in the foot.
> 
> User A looks up to record 1 w/o a lock.
> User B looks up to record 1 w/o a lock, and gets it.
> User A modifies a field in the lookup, and filePro automagically locks
>     the record.
> User B modifies a field in the lookup, and filePro attempts to lock the
>     record.  Since it's already locked by A, it waits.
> User A releases the lock (write/getnext/close/etc).
> User B now continues, and locks the record.
> 
> Note, however, that B continues using the original version of the
> record, not the version as modified by A.

Ewwwww.  -Precisely- the situation vipw (and -p of course) were designed to
avoid.  Nasty.  Relying on auto is just about as unhealthy as it not being
there.  You're right about minimising collateral damage.  I mean, it helps,
but not much.

> However, if user B doesn't do the lookup within the window between A
> doing the lookup and subsequently locking it, then the problem has
> been avoided this time around.

Right.

> I guess it depends on the definition of "this batch of lookups".  If
> you are in output processing, and you are done with the file for this
> particular record, are you done with "this batch" if the next record
> in the output will perform another lookup to this file?

Nah, then it'd just be extra overhead.

> On the other hand, you may be in *clerk, performing a lookup to the
> inventory file when the user enters an invoice item.  Once the info
> in the inventory file is read/updated, you may not need that file
> again for some time.  And, even if it will be only a few seconds later,
> the fact that you are limited by the human typist, the overhead of
> closing and reopening the file may be insignificant.

That's the kind of situation I had in mind.

mark->