PE> I have a new theory.  The theory is that the MSC CRT has a fixed array 
 PE> of 20 FILE's.  Now instead of doing as I would have 
 PE> expected, ie store the file number as one of the 
 PE> elements of the FILE structure, and not have any 
 PE> restriction on the number itself, e.g. 5975, what it 
 PE> is doing is getting the file number from DosOpen, e.g. 
 PE> 7, and then going to the 7th element of the array, and 
 PE> storing it there!  And if it gets a return file number

This is true (and so do all of the other CRT's i've seen the source code
 for; it's an easy way to get the fileno(), getc(), etc macros to work).

 PE> from OS/2 > 19, it can't put it anywhere, and fails!  
 PE> So in the extreme, a device driver may have set the 
 PE> maximum file handles to 500, and then proceeded to

It would not be a device driver,  but any global-context dll's you have
loaded (for example, key-popup programs,  PM hooks (they affect full screen
sessions too (wrt file handles),  since OS/2 2.x),  and probably a few
other things I can't think of right now.  Local filters (for example MORE
or SORT) may affect it too.

Do you have a lot of baggage running?  I simple test is to run:

 void nextfh(void)
 {
     FILE *f = fopen("out", "wb");
     fprintf(stderr, "fh = %u\n", fileno(f));
     fclose(f);
 }

If your system has no file-handle-bagage,  and you run this from main(),it
should display 3.




PE> And actually, the objective of all this is not to 
PE> create a program that 
PE> opens >14 files, the objective is to get MSC 6.00 
PE> to compile a program with 
PE> >5 include file depth in a TCP/IP environment,

Try moving all of the tcpip RUN= and CALL= from config.sys into a batch
file (as DETACH for RUN=) that you run later.  I'll bet the problem goes
away.


--- Maximus/2 3.00