gerry@dialogic.dialogic.com (Gerry Lachac) (08/07/90)
Has anyone had any success increasing the number of filehandles for an OS/2 protectmode process? I have tried using the DosSetMaxFH API call to set the number of file handles to various numbers between 50 and 255, but I never seem to have more than 20. DosSetMaxFH does not return any errors. I'm probably overlooking something really easy, so any help is much appreciated.
dans@microsoft.UUCP (Dan SPALDING) (08/08/90)
In article <1266@dialogic.UUCP> gerry@dialogic.dialogic.com (Gerry Lachac) writes: > >Has anyone had any success increasing the number of filehandles for an >OS/2 protectmode process? I have tried using the DosSetMaxFH API call >to set the number of file handles to various numbers between 50 and >255, but I never seem to have more than 20. DosSetMaxFH does not >return any errors. if you are using the c-runtime for opening files, you also have to increase the number of handles the c-runtime can handle as well as the FILEBUF table for the buffered io calls (fwrite, fopen, etc.). this is documented in the c startup code in crt*.asm fairly close to _astart. also need to check _file.c. Dan Spalding
nathan@yatton.inmos.co.uk (Nathan Sidwell) (08/13/90)
In article <1266@inmos.co.uk> gerry@dialogic.dialogic.com (Gerry Lachac) writes: > >Has anyone had any success increasing the number of filehandles for an >OS/2 protectmode process? I have tried using the DosSetMaxFH API call >to set the number of file handles to various numbers between 50 and >255, but I never seem to have more than 20. DosSetMaxFH does not >return any errors. > I had this problem for ages, and attempted to use DosSetMaxFH to sort it. The problem is not with OS/2 but with the language libraries. [At least in my case, MSC 5.0]. The file libraries work by using the file handle returned by OS/2 (or DOS for that matter) as an index into a table which contains the file access mode, buffer pointers etc. The size of this table is fixed by the run time kernel, which is normally taken from the library linked into your code. There are alternatives called [if memory serves] CRT255.OBJ, in an appropriate memory model directory. Specifying this as an additional object module to the linker will replace the standard one. It performs the call to DOSSETMAXFH at startup for you. Hope this helps. You can confirm whether this is the problem, by opening files by directly calling DosOpen, and seeing when it fails. Nathan Sidwell, INMOS Ltd, UK JANET: nathan@uk.co.inmos Generic disclaimer applies UUCP: ukc!inmos!nathan My indicision is final (I think) INTERNET: nathan@inmos.com