Re: list of open descriptors -- MIDRANGE-L

As to the default, I seem to remember actually running into the 32K limit - I saw the 200 in one of the docs that I looked at today, but I thought I also saw different limits for different environments - not important to me, so I'll take whatever.

I'll submit that I like using fcntl() with a non-changing (reading-only) command, starting at 0 and going up - this would not have a problem with less than 10 - in fact, I'm inclined to think there would not often be THAT many. The only question I had was, can there be closed files that used an FD smaller than the max in use? This would be a problem.

As to reading carefully, well, I did not see any DIRECT return code or the like to say what was set - I was wondering if there is any indication of just what the change was.

As to QShell and PASE, these jobs are not necessarily in those environments, and, since they usually start a different thread or job, any result there would not seem to apply to the job for which the request is being made.

OK, back to bed and getting over this cold!

On 6/6/2013 6:20 PM, CRPence wrote:

On 06 Jun 2013 13:17, Vernon Hamberg wrote:

I saw that - it says to use 0 to get the current maximum for the job
- 32K by default.

Actually I believe the documented number is 200 by default; i.e. the
API would need to have been called to increase the count by 31800 to
establish a maximum of 32K:
http://pic.dhe.ibm.com/infocenter/iseries/v7r1m0/topic/rzamp/rzamp.pdf
"...
Default maximum number of socket and file descriptors per job: 200
Maximum number of socket and file descriptors per job: 2 500 000
..."

I didn't see that the function returns what anything like what is in
USE - that is, how many open files there are.

Reread carefully, both of the "A request to decrease the maximum",
plus my implementation suggestion [following the i.e. in my earlier
quoted message]. That starts with the known maximum, tries to decrease
the maximum to 20, then resets the maximum. It should become obvious
when rereading the docs, paying *close attention* to the references to
the word "open".? Or perhaps I misread the documentation.? Or perhaps
the following pseudo-code [thus obviously untested] helps; and someone
could test by converting to actual code, to verify the effects in a job
with more than 20 open files [or active descriptors] and a job with
fewer than 20 open files [or active descriptors]:

// the "@" implies a pointer; the implementation may be different
// according to the prototype. The variable name without the "@"
// represents the integer value at that location
fDescErr = DosSetRelMaxFH( 0 : fDsecMax@ ) ; // set fDescMax
if fDescErr < 0 ; // all bad; bail!
endif ;
fDescAdd = 20 - fDescMax ; // "decrease by" this value
fDescErr = DosSetRelMaxFH( fDescAdd@ : fDescNbr@ ) ;
if fDescErr < 0 ; // all bad; bail!
endif ;
// at this point fDescNbr has the number of in-use descriptors,
// *or* the value of 20
fDescAdd = fDescMax - fDescNbr ; // "increase by" this value
fDescErr = DosSetRelMaxFH( fDescAdd@ : fDescOrg@ ) ; // Reset to
Original
if fDescErr < 0 ; // all bad; bail!
endif ;
if fDescMax <> fDescOrg ; // assert; if true, then logic error
endif ;

This is still an interesting function!

And per the reference in another message to the Software Technical
Document 631474304 with Document Title: File Descriptor Limits In the
Qshell and PASE Environments, that may be _the_ way to get the count if
the count is greater than 20. My interpretation of the final line about
opening "a service request with IBM Software Support" is that the
inquiry will result not in access to some undocumented API, but a means
to find the information via some kind of dump, possibly only within SST:
http://www-912.ibm.com/s_dir/SLKBase.nsf/1ac66549a21402188625680b0002037e/4d634afb140069dc862579e60055f256?OpenDocument

Regards, Chuck

On 6/6/2013 11:08 AM, CRPence wrote:

On 05 Jun 2013 19:59, Mike Krebs wrote:

<<SNIP>>

What is the command or API that will show the list of open
descriptors or the number of open descriptors in a job?

For the latter question, "the number of open descriptors in a
job", the DosSetRelMaxFH() (Change Maximum Number of File
Descriptors) API *apparently could be used* [probably not a
desirable means] to determine that information for any value over
twenty; i.e. by requesting to decrease the maximum number of file
descriptors to twenty... and then presumably, to reset the maximum
to its original value that was saved on a prior invocation to
retrieve that maximum.

http://pic.dhe.ibm.com/infocenter/iseries/v7r1m0/topic/apis/dossrmfh.htm
_i DosSetRelMaxFH()--Change Maximum Number of File Descriptors i_
"...
The DosSetRelMaxFH() function requests that the system change the
maximum number of file descriptors for the calling process (job).
The system preserves all file descriptors that are currently open.

...

A request to decrease the maximum number of file descriptors will
succeed. The resulting maximum will be the smallest number
possible, but may be more than what you expected. For example,
assume that the current maximum is 200 and there are 150 open
files. A request to decrease the maximum by 75 results in the
maximum being decreased by only 50, to 150, to preserve the open
file descriptors.

A request to decrease the maximum number of file descriptors to
below 20 will succeed, but the maximum will never be decreased
below 20.

To retrieve the current maximum number of file descriptors,
without any side effects, the value pointed to by pcbReqCount
should be set to zero.
..."