file table full - linux - 5.0.11aR4 - PFREADONLY

[Yes! Tech Support (Doug)]

<beats dead horse until it begins to stir, and then speaks>

I have scanned all of my archived mail messages in this list (back to 
7/1/03)
but I couldn't find a definitive resolution for the question. While I 
certainly
admire Brian's creative workaround, it won't resolve my standard use for
the PFREADONLY environment variable.  That use is primarily as an incentive
to extract money from a client who is seriously delinquent.  I don't 
want to be
unprofessional or unethical, and certainly not LIABLE, by making the system
completely unusable, so I use the READONLY env-var.

It has worked for me in the past on SCO 5.0.x and fp 4.8.x, but I 
recently had
to use it on a new installation of linux and 5.0.11aR5 .  I get the same 
"File Table Full"
error message as included in the reference messages below.  The user is 
able to
access the primary data file using an auto index.  The master record is 
auto-joined
with data from a few other detail tables, and the user can _view_ the 
data normally.
When using <Enter> or down arrow to scroll down the indexed records, the 
user
gets the "File Table Full" message after viewing 5-6 records.  Once the 
error message
is displayed, there is no getting out of its loop without using the 
<ctrl>\ to QUIT.

Without PFREADONLY in the environment, of course, the app runs without 
issue.

Forgive me if this issue has been resolved, but I have searched as much 
self-help
info as I have access to, with no avail.  Thanks for any insight any of 
you might
have.

Doug Campbell
Yes! Tech Today

Brian K. White wrote:

>I got the following error message.  Can anyone tell me what this error
>message means and what one could do to fix the problem?
>  
>
>>>>File Table Full
>>>>
>>>>On File: /u/csd/appl/att/filepro/att_cla_tea/index09.A
>>>>
>>>>Too many filePro files open at once.?
>>>>Maximum is 60.?
>>>>
>>>>Standard Input Redirected
>>>>
>>>>        
>>>>
>>Here is a copy of the php script that calls it.
>>
>><?php
>>$fname = date("His");
>>$rp = "/appl/fp/rreport";
>>$fname = "/appl/fpmerge/unit" . $fname;
>>$command = "PFDIR=/u/csd/appl/att export PFDIR;";
>>$command .= "PFMBTO=1 export PFMBTO;";
>>$command .= "TERM=xterm export TERM;";
>>$command .= "_unitcd=$_unitcd export _unitcd;";
>>$command .= "_month=$_month export _month;";
>>$command .= "$rp att_stu -u -y none -f class_sel_html -m $_month -a -v
>>class_sel_html.s -p $fname";
>>$command .= " > /dev/null;cat $fname";
>>print $command ;
>>system($command);
>>?>
>>
>>if I add the -ro to the command, it gets the error.  If I remove it it
>>runs just fine (thanks Bill McEachran).
>>
>>    
>>
>Interesting...
>For a recent project of mine, I also could not use either -ro or
>PFREADONLY in a cgi script. This was ksh and sco unix. I didn't see the
>same error. I think all I got was segmentation violation and core dump.
>This was a simple read through a file, records selected via a very simple
>small selection table (could have been a simple one-line selection set,
>except it needs to be variable) and an equally simple and direct export
>process. at first there were no lookups in the output process, I just ran
>one export command for every record the -v table selected. Now it's more
>complicated, but it was failing even when it was dirt simple. I posted all
>about it here some months ago.
>
>/me checks to see what I did to get it working...
>
>....
>I cheated like a dirty rat bastard :)
>
>I cannot take credit for the idea, but until I see what public opinion on
>this solution is, I'll only give credit where it's due if it looks like
>they will get more credit than insults :)
>
>I made symlinks of the key, data, and indexes in the data file to simulate
>a new qualifier, and then I used that qualifier in the cgi script with
>PFQUAL.
>
>  
>