perry@omepd.UUCP (02/19/87)
In article <1500@im4u.UUCP> jai@im4u.UUCP (Jai Srinivasan) writes: >I have a C program run from a Procomm command file. The program >runs fine when called directly from DOS. When called by Procomm >from the command file, it exits saying that it cannot open a file. >Naturally, I suspected that Procomm left several files open before >executing the program; so I closed stdprn and stdaux at the start >of the program and tried it again. And got the same results. >Finally, I increased the number of FILES in CONFIG.SYS; the program >is executed properly now when called from Procomm. It seems that you and many others don't realize that MSDOS actually imposes TWO DIFFERENT kinds of limits on the number of file handles you can successfully open. These two limits are related but must be distinguished: First, there is a limit on the number of handles IN THE ENTIRE COMPUTER. This is what you set with the FILES=nnn directive; it puts a cap on the number of handles that can be simultaneously open IN ALL PROGRAMS TOGETHER. Second, there is a limit on the number of handles IN ONE PROGRAM. This limit is frozen solid at 20 (twenty) and cannot be changed (short of patching the MSDOS system files - not COMMAND). As long as you are running one program at a time (from COMMAND.COM), these two limits apply essentially to the same thing. This means that you can usually use the lesser of 20 and the FILES=nnn number. Note that a FILES argument of more than 20 makes no sense under these circumstances. If, however, you execute one program from another one (as from PROCOMM in your case), the FILES= limit applies to the TOTAL OF DIFFERENT HANDLES in both programs. Any files open in resident programs count toward the FILES limit, too (e.g., the PRINT spooler has two files open when running). Closing inherited handles (standard or otherwise) is freeing them up both towards the program limit (20) and the total limit (FILES). In your case, though, closing only two handles just wasn't enough. Consider that if PROCOMM has 5 non-preset handles opened, it is already occupying 10 handles (5 standard plus 5 more)! Another two (or more) go to the COMMAND.COM that started your PROCOMM, and there isn't that much left. So, the lesson to remember: THE FILES=nnn CONFIGURATION PARAMETER LIMITS ALL FILE HANDLES IN ALL PROGRAMS TOGETHER. If you are frequently calling programs from programs, use a reasonable value for FILES. By the way, raising the FILES limit by one costs you only 48 bytes, so you really can afford it. If in a crunch, sacrifice one BUFFER - that allows you another 10 handles... ------------------------------------------------------------------------ << Perry The Cynic >> ...!tektronix!ogcvax!omepd!inteloa!perry ...!verdix!omepd!inteloa!perry (Peter Kiehtreiber) -or try- perry@inteloa.intel.com
jai@im4u.UUCP (02/20/87)
In article <421@omepd>, perry@inteloa.intel.com (Perry The Cynic) writes: >In article <1500@im4u.UUCP> jai@im4u.UUCP (Jai Srinivasan) writes: >>I have a C program run from a Procomm command file. The program >>runs fine when called directly from DOS. When called by Procomm >>from the command file, it exits saying that it cannot open a file. >>Naturally, I suspected that Procomm left several files open before >>executing the program; so I closed stdprn and stdaux at the start >>of the program and tried it again. And got the same results. >>Finally, I increased the number of FILES in CONFIG.SYS; the program >>is executed properly now when called from Procomm. > <some text deleted> > >Closing inherited handles (standard or otherwise) is freeing them up both >towards the program limit (20) and the total limit (FILES). In your case, >though, closing only two handles just wasn't enough. Consider that if PROCOMM >has 5 non-preset handles opened, it is already occupying 10 handles (5 standard >plus 5 more)! Another two (or more) go to the COMMAND.COM that started your >PROCOMM, and there isn't that much left. > That still does not explain the anamoly. I should have mentioned that the program, when run from ProComm, always succeeded in opening one file and then failed to open the next one. If the above is correct (closing a file frees the handle for both the program and the system limit), the program should have run with stdaux and stdprn closed as 2 files were being closed in an attempt to open one. But closing stdprn and stdaux made no difference: it yet opened one and failed to open the next. The conclusion would appear to be that closing standard files (or at least stdprn and stdaux) does not free handles for the system limit. Anyone care to comment? Some additional info may help: The number of FILES in CONFIG.SYS was 20 and then was increased to 25 to get the program running from ProComm. ----------------- Jai Srinivasan, UUCP: {gatech,harvard,ihnp4,pyramid,seismo}!ut-sally!im4u!jai ARPA: jai@im4u.UTEXAS.EDU, jai@sally.UTEXAS.EDU
bmarsh@cod.UUCP (02/20/87)
In article <1511@im4u.UUCP> jai@im4u.UUCP (Jai Srinivasan) writes: > >The conclusion would appear to be that closing standard files (or at >least stdprn and stdaux) does not free handles for the system limit. >Anyone care to comment? > Sure! Since the first 5 file handles are opened for everybody, they are basically dup'ed (sys call 45H) instead of re-opened for each child task. All dup'ed file handles refer to the same system file handle, (if you look up the lseek sys call 42H, you will notice that it has only one read/write pointer per open file, even if it is dup'ed), these standard file handles only take up 'user' file handles and not 'system' file handles. Closing these file handles only freed up user handles, not system handles. As Peter the cinic (or whatever he called himself, sorry I didn't save that part ;-) mentioned, system file handles are cheap, only 48 bytes. Bill ----------- Bill Marsh, Naval Ocean Systems Center, San Diego, CA {arpa,mil}net: bmarsh@cod.nosc.mil uucp: {ihnp4,akgua,decvax,dcdwest,ucbvax}!sdcsvax!nosc!bmarsh "If everything seems to be coming your way, you're probably in the wrong lane."
ralf@b.gp.cs.cmu.edu.UUCP (02/21/87)
In article <1511@im4u.UUCP> jai@im4u.UUCP (Jai Srinivasan) writes: > >>Closing inherited handles (standard or otherwise) is freeing them up both >>towards the program limit (20) and the total limit (FILES). In your case, >>though, closing only two handles just wasn't enough. Consider that if PROCOMM >>has 5 non-preset handles opened, it is already occupying 10 handles (5 standard >>plus 5 more)! Another two (or more) go to the COMMAND.COM that started your >>PROCOMM, and there isn't that much left. >> > >That still does not explain the anamoly. I should have mentioned that >the program, when run from ProComm, always succeeded in opening one >file and then failed to open the next one. If the above is correct >(closing a file frees the handle for both the program and the system >limit), the program should have run with stdaux and stdprn closed as 2 >files were being closed in an attempt to open one. But closing stdprn >and stdaux made no difference: it yet opened one and failed to open the >next. > >The conclusion would appear to be that closing standard files (or at >least stdprn and stdaux) does not free handles for the system limit. >Anyone care to comment? That is exactly correct, since the standard files are inherited from the process which loads the current process. When a program is loaded with DOS function 4BH, it inherits all of the currently open files (this is what allows the COMMAND.COM I/O redirection operators < and >). While the new process has its own file handles for them, internally they refer to the same file descriptor. Thus closing handles is like deleting files in UN*X: the DOS-internal file descriptor is only freed when the last handle referencing it it closed. >Jai Srinivasan, UUCP: {gatech,harvard,ihnp4,pyramid,seismo}!ut-sally!im4u!jai >ARPA: jai@im4u.UTEXAS.EDU, jai@sally.UTEXAS.EDU Ralf Brown ARPA: RALF@B.GP.CS.CMU.EDU -- +=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=+ | ARPA: RALF@B.GP.CS.CMU.EDU "Teaching COBOL ought to be | | AT&T: (412) 268-3053 (school) regarded as a criminal act" | | Snail: Ralf Brown --- Edsger Dijkstra | | Computer Science Department | | Carnegie-Mellon University DISCLAIMER? Who ever said I claimed | | Pittsburgh, PA 15213 anything? | +=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=+