|
I've run across a number of questions similar to "How do I avoid the terminal display?" I have a strong feeling that I saw an answer in at least one case that related to environment variable settings, but I don't think it was directly related to this kind of situation.
Hmmm... I suspect that you're thinking of QIBM_QSH_CMD_OUTPUT. When you set it to NONE it'll disable the terminal output. But, it's for QShell, not PASE.
However, can you describe how the QIBM_USE_DESCRIPTOR_STDIO environment variable should be used? What circumstances might it be used within?
In Unix and MS-DOS, each program has 3 standard i/o channels available.One called STDIN (standard input) reads data from the terminal, but can be redirected to get it's input from a file or script.
One called STDOUT (standard output) writes results to the terminal, but aain, can be redirected to write output to a file.
One called STDERR (standard error) also writes the results to the terminal. The problem with STDOUT is, if you're attempting to populate a file, but the program wants to write an error message, that error message ends up in the file -- that's not usually desirable. So error messages are written to a separate channel, STDERR.
These three standard input/output streams are collectively referred to as "STDIO"
Since the C programming language grew up around Unix (and Unix around C) it has these constructs built into it. Other Unix children do as well (such as Java, Perl, etc.) They're also used to allow communications between a web server and a CGI program, since those also grew up around the Unix environment.
So, when C was implemented on the iSeries, they created these stdin, stdout, stderr channels as well. They're buffered streams, compatible with those you'd use with the fopen(), fgets(), fputs(), etc APIs from the ILE C runtime.
When the iSeries added the IFS to it's repetoire in V3R1, they also implemented descriptor I/O, and the whole new set of APIs, open(), read(), etc. And they added a 2nd set of fopen(), fgets(), etc routines that work with the IFS.
Well, on a Unix system, there's only one implementation of fopen() and friends, and under the covers they call the open() and friends. When you work with stdin, it's always using descriptor 0, when you use stdout, it's always descriptor 1, when you use stderr, always descriptor 2.
That wasn't the case on the iSeries -- the iSeries had the stdin/stdout/stderr streams before they even had descrptors, so they didn't do it that way. That really screws up shell scripts (such as those for QShell or PASE) since they rely on those descriptor numbers.
So, they added the QIBM_USE_DESCRIPTOR_STDIO envvar. When this is set to Y, the system will act in a manner compatible with Unix, using those 3 descriptors for the STDIO streams.
midrange.com
Indeed, in a previous message someone told the OP to do the following:
scp source host:target 2> /tmp/error_log
What that "2>" means is that you want it to write the output of descriptor
2 to a file called /tmp/error_log. But for some reason, the OP couldn't
get that to work.
I don't think that sort of redirect works with qp2shell, because it doesn't submit a background job to run the commands in like QShell does, but maybe it's just me.
I ask in order to get info but also in case it sparks someone else's memory of a different envvar. Maybe there is an obscure technique out there. (And maybe not.)
What about my suggestion of using spawnp()? Wouldn't that work?
As an Amazon Associate we earn from qualifying purchases.
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.
