a_dent@vaxa.uwa.oz (06/11/90)
I've been working in FoxBASE+/Mac and one of my databases is really complicated, the easy way out has been to leave 9 datafiles and 19 indexes permanently open. The only trouble with this is the limit on open files - the standard boot block setting is TEN files (apparently regardless of machine size - CPU, RAM, diskspace - you name it). My choices are: 1) A lot of painful coding to try to keep within the limit of 10 files. 2) Write a utility to set the limit (no problems technically). I've already had an argument with one Mac support person (Richard, are you reading this?) about the safety/validity of step 2). So, what's the Net's opinion on increasing the number of open files? Would you be happy to run a "setup program" of this nature, if you bought an off-the-shelf package? Also, for the techies, what IS the impact of "n" open files. Does it cost much memory (I can't think of anything else it could affect)? By the way, the limit seems to apply across the entire Mac system, not just to one program, under Multifinder. This seems a ridiculous restriction - a 5Mb Mac with two applications running could easily get close to 10 files just by handling a couple of documents per application. Thanks in advance Andy Dent A.D. Software phone 09 249 2719 Mac & VAX programmer 94 Bermuda Dve, Ballajura a_dent@vaxa.uwa.oz Western Australia 6066
jwwalker@usceast.UUCP (Jim Walker) (06/12/90)
In article <1990Jun11.195357.1886@vaxa.uwa.oz> a_dent@vaxa.uwa.oz writes: [stuff deleted] |So, what's the Net's opinion on increasing the number of open files? Would |you be happy to run a "setup program" of this nature, if you bought an |off-the-shelf package? It wouldn't be the first program to provide such an option (Suitcase II does) though it might be the first to REQUIRE a larger open file limit in order to run. I wouldn't object to it, though. -- Jim Walker jwwalker@usceast.cs.scarolina.edu 76367.2271@compuserve.com
urlichs@smurf.sub.org (Matthias Urlichs) (06/12/90)
In comp.sys.mac.programmer, article <1990Jun11.195357.1886@vaxa.uwa.oz>,
a_dent@vaxa.uwa.oz writes:
< I've been working in FoxBASE+/Mac and one of my databases is really complicated,
< the easy way out has been to leave 9 datafiles and 19 indexes permanently open.
<
< The only trouble with this is the limit on open files - the standard boot
< block setting is TEN files (apparently regardless of machine size - CPU, RAM,
< diskspace - you name it).
<
< My choices are:
< 1) A lot of painful coding to try to keep within the limit of 10 files.
< 2) Write a utility to set the limit (no problems technically).
3) Use System 7 which makes this number dynamic. ;-)
4) Write a small utility which looks at the number of FCBs and increases it if
necessary. Package it as an XCMD and call it from FoxBase.
5) Install an INIT like "Up your FCBs" (I don't know who wrote that one)
to increase that number, or do it yourself.
The ten files limit is actually multiplied by something like 2 or 4, depending
on how much memory you have.
When increasing the number of FCBs, remember to (a) turn off interrupts, (b)
treat the appropriate low-memory globals correctly, (c) don't dispose of the
old FCB list because you don't know where it might have come from. (Is this
guaranteed to be a pointer from the System heap? Apple?)
Aside: System 7 dynamically increases the number of FCBs if necessary.
The preliminary documentation says that in order to do so, calling _Open (with
a file) from interrupt level is now forbidden.
This strikes me as a bad idea; it'd be better to return an error if necessary.
Something like that already happens if an async operation needs an offline
disk; an error is returned instead of popping up the dialog (which can't
happen from an interrupt).
<
< By the way, the limit seems to apply across the entire Mac system, not just to
< one program, under Multifinder. This seems a ridiculous restriction - a 5Mb
< Mac with two applications running could easily get close to 10 files just
< by handling a couple of documents per application.
<
As I remember, that mac would have 20 or possibly 40 FCBs. Still not enough in
some cases.
--
Matthias Urlichs -- urlichs@smurf.sub.org -- urlichs@smurf.ira.uka.de
Humboldtstrasse 7 - 7500 Karlsruhe 1 - FRG -- +49+721+621127(Voice)/621227(PEP)alexis@panix.UUCP (Alexis Rosen) (06/12/90)
Actually, the standard limit is 40 open files. The number in the boot blocks is multiplied by four to get the real number. As for changing this number, there is no reason not to. Several programs, such as Fedit and Suitcase, do so. It consumes a very small amount of memory and should not cause any problems. (Of course, there's always that one-in-a- thousand case where you're running with two free bytes in the system heap. In that case, upping the number of files will blow up your mac. This will probably never happen to you, but you could always give the system heap a couple of extra K to make sure this doesn't happen.) When System 7 arrives, this will no longer be a problem, as the data structures required for opening files will be allocated dynamically. If you're going to integrate this into a Foxbase app, the smartest thing to do is write an XCMD that alters the open-files value (and maybe the system heap) if it's not already set high enough, and then reboots. Your users won't know what you're talking about if you ask them permission, and this really can't hurt them. I would mention this somewhere in the docs, though. Alexis Rosen apple!panix!alexis
george@huntsai.UUCP (George Williams) (06/13/90)
a_dent@vaxa.uwa.oz writes: ... >So, what's the Net's opinion on increasing the number of open files? >Would you be happy to run a "setup program" of this nature, if you >bought an off-the-shelf >package? >Also, for the techies, what IS the impact of "n" open files. Does it >cost much memory (I can't think of anything else it could affect)? ... I routinely (each time I install a new system) increase the number of open files & windows on my machine (MacII w/8Mb, 2 monitors) to about 30 each. Of course this (and my dozen or so inits) requires more system heap, so I bump that also until I get about 30% free in a quiescent system. I've never bothered to figure out the actual heap impact of all of this, but this technique seems to work without problems. I use FEDIT+ to adjust this stuff in my boot block, but I sure would like a better way to do it. In particular, the system heap adjustment is a guess and reboot until it comes close to being right, since the OS seems to readjust to more available space. I've tried the HeapFixer (correct name?) program available in the archives, but it doesn't seem to work very well for some reason. Seems like this is a ripe area for a utility and some guidance from Apple. Any comments from DTS? -- George Williams E-Mail: george@huntsai.boeing.com Phone: 205+461-2597 BTN: 861-2597 USMail: Boeing Computer Services, POBox 240002, JA-74, Huntsville AL 35824-6402 << Disclaimer: Boeing is not responsible for my opinions, nor I for theirs. >>