TOO MANY FILES
OPEN
- Check your CONFIG.SYS for any FILES= command. Edit
CONFIG.SYS so that FILES=99 or more. FILES=150 is often necessary if Windows is being
used.
- Check CONFIG.DB for any FILES= command.
- Network environment?
NOVELL What is FILE HANDLES = in SHELL.CFG or the NET.CFG? No .CFG file means default
values. For example Netware version 2.2 allows 40 by default. Run NETGEN to increase file
handles default.
dBASE 5 for DOS now defaults to FILES = 250 in the CONFIG.DB opposed to dBASE IV FILES=99.
This means that the config.sys may contain a line that says FILES=250. This allows us to
open more files in more work areas than in previous versions.
The problem is the NET allocates a number of these files as well. The total number of
files in the Config.sys PLUS "Handles = ..." in the NET.CFG must NOT exceed 254.
So if you change your "FILES = .." to FILES = 254 in the Config.sys, you will
not be able to log into the net. However, this can be set to 200 and the "HANDLES =
..." line in the NET.CFG can be set to 54 as well. This gives a grand total of 254.
PC-NFS PC-NFS by default only allows a handful of open files. However, the PCNFS.SYS
driver has a /f parameter which allows you to increase the number of open files up to 127.
LANTASTIC or another DOS/SHARE-based Peer-to-Peer network Is SHARE loaded? In some cases
the defaults for SHARE need to be increased. See #4 below and GO ARTISOFT - SHARE.TXT.
- SHARE [/f:space] [/l:locks]
*> The /F Parameter <* The /F parameter allocates the storage area (in bytes) used
to keep track of filename, filepath and 11 bytes housekeeping information for EACH file
opened. The default value for the /F option is 2048. Using an average length of a filename
and path of 20 bytes (average is per DOS 5 Users Guide - SHARE), the default value is
sufficient for 66 simultaneously open files:
2048 / (20+11) = 66.06
If your FILES= statement specifies more than 66 files, or your average path length is
longer than 20 characters, you may want to adjust the /F parameter.
On a network server that uses SHARE, you will need to allocate enough space for all the
files that will be opened by all the users on the network.
You can calculate the maximum needed space required by multiplying the number of files in
your CONFIG.SYS by 31 (20 bytes avg. pathname + filename + 11 bytes). For a system with
FILES=255 in CONFIG.SYS, with all 255 files opened, SHARE will require 7905 for /f:space.
If the /F option is too low, you may receive a "File not Found" error.
*> The /L Parameter <* The /L parameter specifies the maximum number of simultaneous
locks that SHARE can handle. For DOS 5 and 6 the default is 20. If running Windows, or
working on a Network you may quickly exceed the default.
The /L setting should be at LEAST the number of files you've specified in your CONFIG.SYS.
Each open file can grab a lock but could potentially have dozens. If you're running a
multi-user program you have to keep in mind the maximum number of files you may have open
as well as the maximum number of record locks that may be issued. Each time an application
requests a record lock, a lock on that portion of the file is issued.
Programs may behave in an unpredictable manner when SHARE runs out of locks. If the value
used in the /L option is too low, you can expect to receive an error "Too many files
open", "File Access Denied", "Sharing Violation", and in some
cases a lock up.
Example:
SHARE /f:5200 /l:167
* sufficient storage area (/f:) for 167 files and 167 locks (/l:).
*> If you experience problems with SHARE <* - Try loading SHARE at the TOP of your
AUTOEXEC.BAT before other devices. - If loading SHARE in the upper memory, load Share in
conventional memory instead. Change:
loadhigh c:\dos\share.exe /L:# /F:#
to:
c:\dos\share.exe /L:# /F:#
According to MicroSoft you should not use the MS-DOS loadhigh command when you run a
third-party upper memory manager such as Qemm. - Make sure there is not more than one
Share line in AUTOEXEC.BAT or CONFIG.SYS and that it does not exist in both AUTOEXEC.BAT
and CONFIG.SYS. - If you are low on available memory or perhaps have a memory conflict,
and have SHARE /f: /l: set, try decreasing the values.
- WINDOWS
Windows has a setting in the SYSTEM.INI file called PERVMFILES= This sets the number of
file handles Windows allocates to each virtual machine. In the [386Enh] section of the
SYSTEM.INI file, modify the line:
PerVMFiles=
The default is 10. It can be up to 255.
- OS/2 If your dBASE application returns the error message
"Too many files open", make sure to check the DOS_FILES setting for your dBASE
program object. The DOS_FILES setting establishes the maximum number of file handles that
the DOS program is able to open. The default setting is 20. dBASE III PLUS can only open
15 files so you can leave the setting at its default of 20. On the other hand, dBASE IV
can open up to 99 files, so it can be set to 99. Please note that each file handle
allocated uses 39 bytes of conventional memory. So set the DOS_FILES according to the
maximum number of files your dBASE application will open. Also make sure DOS_VERSION is
set for the program object you are running dBASE IV from.
- QEMM Check files option
- Under the assumption that there may be something else
causing a problem in the environment TEST with a minimum setup. Create a bootable floppy
and add only the following:
CONFIG.SYS AUTOEXEC.BAT
FILES=99 PATH=C:\DBASE
BUFFERS=15 PROMPT $P$G
ONLY add other lines REQUIRED to boot the computer ( disk partitioning, compression, etc.)
- To see if there is a problem within your code run the
following program to see how many files you can open:
*- PRG TO SEE HOW MANY FILES YOU CAN OPEN
*- If you error out with "Too many files are open"
*- choose SUSPEND and then DISPLAY STATUS.
*- Check the line that says "Number of files Open"
CLOSE ALL
CLEAR ALL
Z=1
DO WHILE Z<100
fname = "X_"+LTRIM(STR(Z))+".TXT"
fhandle = FCREATE(fname)
junk = FPUTS(fhandle,"x")
Z=Z+1
ENDDO
DISPLAY STATUS
dBASE uses some file handles internally. The above code should easily create greater than
80 files. * Remember to clean up the disk after this test. You will have files named
x_1.txt, x_2.txt .... As long as you have no files name x_*.txt of your own delete these
by issuing !DEL x_*.txt.
- If #9 above opens more than enough files, check your
database and index files for any possible corruption. Download:
Lib:6 - DBFCLN.EXE Title : Dbfclean
utility
Lib:6 - DBTCHK.EXE Title : Checks for
corrupted memo fields
Run these utilities against your DBF and DBT (if any). After checking these files for
corruption. CLOSE ALL and delete and remake any NDX or MDX file associated with them. At
this point we should have clean data files and indexes.
- Make sure your programs aren't calling themselves
recursively. This can be the result of issuing a DO statement to go back to a previous
procedure, instead of issuing RETURN. For example:
* prg_AA.PRG
DO prg_BB
RETURN
* prg_BB.PRG
DO prg_CC
RETURN
* prg_CC.PRG
DO prg_AA
RETURN
Program AA calls BB, BB calls CC, and CC calls back to AA..., each program will occupy a
file handle. The programs keep getting pushed on top of stack waiting to be popped off.
The stack will eventually be filled up, and the operating system will run out of file
handles. You will then see one of these messages depending what the application does:
"Too many files are open"
"Insufficient memory"
"Procedure nested too deep"
"Internal: Virtual Stack Overflow"
If a DO command is used in this manner, it is termed recursive programming. This involves
a circle of programs or menus instead of a chain or hierarchy. In the above example,
program AA calls program BB with the DO command. Program BB calls CC in a similar manner.
Up to this point, there is a proper hierarchical chain of programs: AA-BB-CC. If program
CC then calls AA with a DO command, a full circle would have been completed: AA-BB-CC-AA.
This causes problems in dBASE as each opening of a module in this way uses a file handle.
Only the file handle for the latest opened instance of a given module name can be
released, other instances become irretrievably lost and the limited number of available
file handled is quickly expended.
In this chain of programs, AA-BB-CC, module CC would ordinarily have a RETURN command at
the point where its processing is considered complete. This automatically returns control
to BB, at the first command line after the command line DO CC. Similarly, when a RETURN
command in BB is encountered, control returns to AA.
* prg_AA.PRG
DO prg_BB
RETURN
* prg_BB.PRG
DO prg_CC
RETURN
* prg_CC.PRG
* ... code ...
RETURN
There is one exception to this, and that is the need to go directly from CC back to AA,
but closing all intermediate open modules in the process. This can be accomplished with
the RETURN TO MASTER command (in CC). This would have the same apparent effect as DO AA
(invoked in CC), but does go back through each open intermediate module in the hierarchy,
closing each, until the topmost level is reached.
* prg_AA.PRG
DO prg_BB
RETURN
* prg_BB.PRG
DO prg_CC
RETURN
* prg_CC.PRG
* ... code ...
RETURN TO MASTER
A good way to spot recursive calling is to use a program code documentor such as SNAP.
LIB 14: SNP502.ZIP
Title : Snap! Version 5.02 - Program Documentor for xBase
Within dBASE you can do something along the following to see if you can spot recursive
calls:
SET TALK ON
SET ECHO ON
SET ALTERNATE TO list.txt
SET ALTERNATE ON
DO program
* Cancel from too many files open error
SET ALTERNATE OFF
SET ALTERNATE TO
CLOSE ALL
MODIFY COMMAND list.txt
- Long shot but possible: Delete and re-install the dBASE
software for any possible corruption.
[Home] [FAQ Index] |