hi Dan,
On 12/21/2011 4:04 PM, Dan Kimmel wrote:
The stdio file descriptors can easily be set to files when the
descriptors are established and opened.
new_desc = open ('/dev/null' : mode : aut);
new_desc is 0 for the first file opened, 1 for the second and so on.
Just FYI:
The open() API will use the next available descriptor. So if descriptor
0 is not yet opened, this code will return 0, as you say. But if fd 0
is already open, it'll return the next one available (1, 2, 3, etc...
whatever the lowest available number is.) And this won't necessarily be
associated with stdin. (But it will be open!)
You could, of course, use the close() API to close descriptors 0-2 so
that the calls to open() would be more likely to return 0-2.
dev/null is a special value that assigns the descriptor to the
operating system. In ILE this is the default behavior as assigned
above. Easy to replace this with '/somepath/somefile.txt' and the
output (or input) will go to (or come from) some other path.
I'm not sure that I understand what you're saying, here... but /dev/null
is what's known as the "bit bucket". Anything written to it will be
discarded by the OS. (NOT displayed on the screen as you imply.)
Likewise, you cannot read from /dev/null.... the read() API would
immediately get an "end of file" condition.
So if you opened the descriptors pointed to /dev/null, you'd get no
output when calling puts().
Once established in a job the file descriptors stay pretty much in
place. You can even pass the descriptors to QSH or PASE by setting
environment variable QIBM_USE_DESCRIPTOR_STDIO to "Y".
QIBM_USE_DESCRIPTOR_STDIO doesn't control whether descriptors are passed
to PASE/QSH or not. Rather, QIBM_USE_DESCRIPTOR_STDIO controls whether
stdin, stdout or stderr are associated with file descriptors 0, 1 and 2.
By default (when this variable isn't set) stdin/stdout/stderr are not
associated directly to file descriptors. They are just open streams
that (by default) will be connected to the display.
When you set QIBM_USE_DESCRIPTOR_STDIO, they are associated with the
file descriptors 0, 1 and 2.
The QP2TERM environment of PASE, or the QShell environment will always
associate 0=stdin, 1=stdout, 2=stderr, no matter what the variable is
set to. They do that because they run commands in a background job,
and have a "virtual terminal" that runs in the foreground job and prints
the stuff on the screen.
But if you are using the ILE environment or running PASE via
Qp2RunPase(), QP2SHELL or QP2SHELL2, then if QIBM_USE_DESCRIPTOR_STDIO
is set to Y or I, you'd better make sure you've got 0, 1 and 2 opened,
or you could have some problems, because when QIBM_USE_DESCRIPTOR_STDIO
is set to Y or I, then stin/stdout/stderr will try to use those numeric
descriptors.
There's also a threadsafety issue (I can't recall the details) with
stdin/stdout/stderr in an ILE environment. So when running
multithreaded programs (sshd is an example) it's advised that you use
QShell or QP2TERM which won't directly connect stdin/stdout/stderr to
the (not always threadsafe) ILE display streams.
Anyway... i'm going off on a tangent. But, I thought some of your post
was misleading, so hopefully what I've said above serves to clarify...
midrange.com
