Thanks for the clarification, Scott. I was trying not to be long-winded and may have been misleading. My point was to clue the OP that writing to puts() doesn't necessarily wind up in a spool file.
For instance, Apache sets the file descriptors before it calls any ILE programs. puts() in one of those is going to Apache and thence to the html stream. If you have QIBM_USE_DESCRIPTOR_STDIO set and one of those ILE programs calls a java object method (running in PASE) and that method writes to System.out, it's going to the web page.
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Scott Klement
Sent: Wednesday, December 21, 2011 5:27 PM
To: Midrange Systems Technical Discussion
Subject: Re: (see thread on RPG list) Re: Test program calls puts(), creates spool file here, but not on customer box
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...
--
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.
midrange.com
