Path: utzoo!attcan!uunet!husc6!uwvax!dogie!uwmcsd1!mailrus!ames!pasteur!ucbvax!amdcad!philip
From: philip@amdcad.AMD.COM (Philip Freidin)
Newsgroups: comp.sys.ibm.pc
Subject: Answers!!! not questions
Keywords: Files=xxx
Message-ID: <22648@amdcad.AMD.COM>
Date: 18 Aug 88 00:14:44 GMT
Organization: Advanced Micro Devices, Inc., Sunnyvale, Ca.
Lines: 84



Many moons ago I posed the problem of a sort package that I had, that
had suddenly stopped working, and had run out of file handles. In my
article, I gave a VERY complete description of all the things that I
had tried to resolve the problem, and it was exhaustive. The responses
were entertaining/irritating, as most of them were irrelevant, as
would have been obvious if my original description of what I had tried
had been read carefully. People seem to read up to the point that they
can form an oppinion, and then post. This mode seems to permeate the
Net, so there you are. I will treat it as an epidemic of:

			Deafness of Eye-balls.

So anyway, so as not to bore you all to death with my ramblings, here
is a synopsis of the problem, and the surprizing resolution. (P.s. it
turns out that that I lied in my original posting, with regard to "I
didn't change Nuthin, an' now it don't work".)

Synopsis of problem:
	Bigsort is a program I wrote that does a poly-phase
	quicksort/mergesort, while pretending that the disk is
	multiple tape drives. This works well because, disks being read
	sequentially, transfer data quite fast.
	Program opens about 8 scratch files, and several others, such
	as input, index, and report. Input file is about 700K ascii.
	Program crashes now, and reports it can't open all it's files.
	I tried games involving TSR's, AUTOEXEC.BAT, and CONFIG.SYS.
	The most misleading thing I did was to boot off a virgin
	distribution floppy, and even that didn't work. The only thing
	that worked was to bump up the FILES=xxx in the config.sys
	file, but why was it needed????? every thing used to work.

The solution:
	Turns out I had changed autoexec.bat to make it quieter. 
	An ECHO OFF at the begining, and for each TSR that was loaded,
	I shut them up as well, like this:
	c:>MARK ALL >nul:
		    ^^^^^
	What was happening was each of the TSR's was holding onto the
	file handle associated with the output redirection, regardless 
	of the fact that it never used it again. The solution was to 
	either increase files=xxx, or put up with a noisy autoexec.bat.
	I chose the latter.

Discussion:
	The default files=xxx is 8.  So when I booted from the floppy,
	without any config.sys, it failed.
	My normal config.sys had it set to 20, so my redirects in the
	autoexec.bat was eating up about 6 of them. Increasing the
	value in config.sys, fixed the problem, as did removing the
	redirects to nul:. The increase of files=xxx was unacceptable
	as I couldn't afford the memory.
	I tracked down the problem by writing a program that reports
	how many file handles are left. Placing this into the
	autoexec.bat file at multiple stategic places revealed the
	problem.

Discovery:
	When msdos starts a program, 5 handles are
	allocated, no matter what you do. STDIN, STDERR, STDOUT,
	STDAUX:, and STDPRN:. ( I am talking about programs written in
	Microsoft C versions 4.0, 5.0, and 5.1 . I am not aware what
	happens with just run of the mill programs)
	BIG SURPRISE: although you can get at
	these handles, if you do a close on them, the handle is not 
	released for other uses. Msdos allows 20 file handles max 
	per program, and these are allocated from the pool defined 
	by files=xxx. Therefore programs are in big trouble if they 
	need more than 15 open files at one time. You can have a pool
	bigger than 20 file handles, but only 20 per program. There
	are certainly kludges around this but I am not interested.

I hope this is of some interest to someone, since I spent way to long
isolating the problem, let alone typing in this monalogue.



Philip Freidin @ AMD SUNYVALE on {favorite path!amdcad!philip)
Section Manager of Product Planning for Microprogrammable Processors
(you know.... all that 2900 stuff...)
"We Plan Products; not lunches" (a quote from a group that has been standing
				 around for an hour trying to decide where
				 to go for lunch)