Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rutgers!ames!hc!beta!cmcl2!brl-adm!brl-smoke!gwyn
From: gwyn@brl-smoke.ARPA (Doug Gwyn )
Newsgroups: comp.unix.wizards
Subject: Re: Determining the max number of open files on System V
Message-ID: <5937@brl-smoke.ARPA>
Date: Mon, 1-Jun-87 19:50:57 EDT
Article-I.D.: brl-smok.5937
Posted: Mon Jun  1 19:50:57 1987
Date-Received: Wed, 3-Jun-87 04:11:28 EDT
References: <3635@spool.WISC.EDU>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Distribution: world
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 12
Keywords: NOFILES, S5R3

In article <3635@spool.WISC.EDU> dave@romano.WISC.EDU (Dave Cohrs) writes:
>	"The following define is here for temporary compatibility
>	and should be removed in the next release.  It gives a
>	value for the maximum number of open files per process.
>	However, this value is no longer a constant."

It is quite possible that the value may become "limited only by
availability of kernel dynamic data pool space".  I would suggest
finding another approach that does not depend on there being a
constant limit for this.  However, in the meanwhile you could try
closing all the fds in sequence up to some large number like 128.
Very few programs would ever have fds that large.