You can close an open descriptor with the close() API.

The trick is knowing which ones to close! If your IFS program is failing to close them under some circumstances (presumably, a bug) then how do you know which ones should be closed and which ones are still being used and should be kept open?

But, if you know which ones should be closed, somehow, then just call close() and pass the descriptor number as a parameter.

Or, if you think all should be closed, do this:

D close PR 10I 0 ExtProc('close')
D fildes 10I 0 value

for x = 3 to 256;
callp close(x);

NOTE: I'm not recommending this!! If you close descriptors that are still in use, it could cause "unpredictable results".

(This is skipping 0,1,2 which are often used as standard I/O streams... but who knows, maybe you should close those too?)

It might be safer to just end/restart the job having the issues.

On 4/15/2014 12:10 PM, John Allen wrote:
Running V6.1 We have system that creates a lot of files in
the IFS, recently we started getting an error (lots of them

CPF9897 socket(): Too many open files for this process.

Apparently there are a lot of File Descriptors being left
allocated during this process.

I have not tracked down the program at issue here (I am
thinking some program is not closing the file)

But my question is, until I can find the culprit and get it
fixed is there a way to force all the open file descriptors
to close or deallocate (not sure of the correct term)

'999999')(where 99999 is the job number from the job getting
this error)

A lot of foreign stuff in the report but I do see:

Max Number of Descriptors Allowed (size) 524282

Max Number of Descriptors Allocated 47

Min Deallocated Descriptor 45

1) I need something to do short term to get this
program running

2) Then I will need to track this issue down

Any Suggestions on #1 or #2 would be greatly appreciated


This thread ...


Return to Archive home page | Return to MIDRANGE.COM home page