× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



+1

I suggest that everything that opens something should take care of closing it when done. Basic housekeeping.

A complication you know about, Scott, is that sockets come out of the same pool - again, unpredictable disasters - I couldn't soften it by calling them results.

:)
Vern

On 4/15/2014 3:51 PM, Scott Klement wrote:
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);
endif;

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
actually)

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)

I ran the program CALL PGM(QP0FPTOS) PARM(*DUMPLFS
'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



John







As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.