Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site ut-ngp.UUCP
Path: utzoo!watmath!clyde!cbosgd!cbdkc1!desoto!packard!edsel!bentley!hudson!ihnp1!ihnp4!mhuxn!mhuxm!sftig!sftri!sfmag!eagle!ulysses!allegra!bellcore!decvax!genrad!teddy!panda!talcott!harvard!seismo!ut-sally!ut-ngp!oacb2
From: oacb2@ut-ngp.UUCP (oacb2)
Newsgroups: net.micro.cpm
Subject: Re: possible problems with large numbers of open files simultaneously?
Message-ID: <1223@ut-ngp.UUCP>
Date: Sat, 19-Jan-85 22:00:36 EST
Article-I.D.: ut-ngp.1223
Posted: Sat Jan 19 22:00:36 1985
Date-Received: Wed, 23-Jan-85 07:47:58 EST
References: <7291@brl-tgr.ARPA> <1311@orca.UUCP>
Organization: U.Texas Computation Center, Austin, Texas
Lines: 31

> Just the opposite.  You should take pains NOT to do a CLOSE of a file
> that was used only for reading.  This is because all a CLOSE does is
> copy the FCB back out to the directory.  If you haven't modified the
> file, this is an unnecessary disk access, and will prevent your program
> from running when the file or the disk is read-only.

The BDOS (CP/M 2.2 and, I assume, CP/M Plus) is smart enough to not rewrite
the FCB if it's not been changed.  Not closing input files is just asking
for trouble if you ever upgrade to a multiuser or multiprocessor system.

> If you're absolutely sure that you're not going to write (or otherwise
> modify) the file while it's temporarily closed, it suffices to do a
> CLOSE and keep the FCB, then resume WRITING with the FCB later.  This
> is because CLOSE doesn't cause the file to no longer be OPEN in the
> usual sense; all CLOSE really does is update the directory.  In fact,
> if you have a transaction processing program which adds records to an
> open file, it should CLOSE the file whenever it knows that it will be
> idle for awhile (waiting for another line of terminal input), to make
> sure that the entire file will be there if the system crashes or
> someone removes the floppy.

Again, this may cause trouble if you upgrade to a multiuser or multiprocessor
system.

I strongly recommand that all files be closed after processing and that
I/O never be done to a "closed" FCB.  Closing an input file causes negligible
overhead.  Opening a closed file does require some overhead, but I think it's
worth it.
-- 

	Mike Rubenstein, OACB, UT Medical Branch, Galveston TX 77550