Re: list of open descriptors

Played with an indirect way of finding this based on the fcntl procedure/api.

Using a very short test of duplicating a descriptor using fcntl(0,F_DUPFD, 0) and then closing them is certain sequences within a C program called from QSH, the descriptors are assigned in order starting with the lowest open descriptor. So, based on a couple of assumptions about how your programs open and close these descriptors, a routine that checks for X number of closed descriptors would reveal approximately how many you have (count-X).

Further reference, there is a way to dump the open file descriptors to print. Apparently an unpublished knowledge base article?

There is not a direct way of getting from an open descriptor to a file name. The fstat procedure can use file descriptors and will return inode but there is no index on inode (inode apparently being a unique entry to a file) to find the file name. A dump of the fstat information by directory could be used to create an indexed file on inode.

There are exit points that can be applied to open and close that could be used to track the file names in a serious debugging effort. Or if you know that your program is the problem, you can do as someone suggested and just write the open information to another file and delete the entry when you close the file. Even keeping them in an array would work, because then when the program dumped due to not enough descriptors, the dump would reveal the "open file descriptors" in the array dump.




________________________________
From: Vernon Hamberg <vhamberg@xxxxxxxxxxxxxxx>
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Sent: Thursday, June 6, 2013 7:35 PM
Subject: Re: list of open descriptors


Point of clarification - the file descriptors are zero-based - same as
in Unix, etc. There is always a zero-value descriptor.

In interactive jobs, stdin = 0, stdout = 1, and stderr = 2 - always. In
batch jobs, there is no display device and no entry device (keyboard),
so none of these FDs are set. The FDs start at 0.

I have seen this repeatedly when debugging a sockets application running
in batch and interactive jobs.

This brings up a thought - the FD is just an integer - it could be
stored in code at each open, whether of a file or a socket.
On 6/6/2013 7:16 PM, CRPence wrote:
-snip-

Ignoring the possibility of a zero-value descriptor, ignoring any
special processing that might occur for zero to three

-snip-