× 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.



Scott,

You are correct there is a bug that is not closing the
descriptors.
I assume this because there should not be so many
descriptors open that the job ends with an error
But I don't know for a FACT because I have not found the bug
yet (maybe these are supposed to be open and I need to
increase the Max open Descriptors allowed).

It's a complicated mess of a program so I was hoping I could
do something temporary to close only the current jobs open
descriptors (Do not want to close other jobs open
descriptors) without her signing off and back on.

The user is currently signing off and back on and this does
indeed allow the job to run for a while longer (sometimes
for days with the user signing off each night)

When I run the program QP0FPTOS I get a listing that shows
the File descriptors
Many of them have the file name associated with it (see
/TMP/MARY...)
Example1:
======Descriptor 33

/TMP/MARY/INVOICE 340822-05-PRT0017NM-15.04.58.PDF

fte E498C86712 016BA0 d_tag 0x000C8F41 d_flags
0x08 lockSc
File table entry:

f_valid 0x00 f_type VNODE f_seekCnt
0x000000
f_offset 0x0000000000000000 f_openFlags
0x000008000084004A f_
f_fOps D5A972A05B 002380 f_object FE0FBB609C 192000 f_ccsid
65535

But many of them have no file name associated with them
Example2:
======Descriptor 88

fte E498C86712 06B7E0 d_tag 0x000B4831 d_flags
0x00
File table entry:

f_valid 0x00 f_type SOCKET f_seekCnt
0
f_offset 0x0000000000000000 f_openFlags
0x00002000000000
f_fOps 0000000000 000000 f_object 0000000000 000000 f_ccsid


I cannot find anything that explains the data in this report
so I am assuming a lot when I look through it, but I am
trying to find something that points me in the right
direction for finding this bug
Do you know what it means when the report lists file
descriptors without a file name?
Can a descriptor get created without a file name associated?
Is there any place I can see/set/change the maximum number
of open descriptors allowed on the system?

Also, after she signs off and signs back on the job runs
again. But I can run QP0FPTOS against the old job number and
the report still lists all those open descriptors for that
old job.
Could these cause an issue later?
How are these descriptors removed/closed do I have to IPL?

Thanks again in advance for any help or information you can
give me

John




-----Original Message-----
From: Scott Klement [mailto:midrange-l@xxxxxxxxxxxxxxxx]
Sent: Tuesday, April 15, 2014 4:51 PM
To: Midrange Systems Technical Discussion
Subject: Re: How can I clear/deallocate open File
Descriptors

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





--
This is the Midrange Systems Technical Discussion
(MIDRANGE-L) mailing list To post a message email:
MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change
list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting,
please take a moment to review the archives at
http://archive.midrange.com/midrange-l.


As an Amazon Associate we earn from qualifying purchases.

This thread ...

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.