RE: Pase environment from a batch cl

You may have a problem to include the redirection character '>' in the QP2SHELL 
parameters.

Try the following trick:
Create a PASE script file - an ASCII file that contains the PASE command that 
you want to run. You should use the full path to the PASE command.
For example, let's try to remove non-existent file foo. 
We create a new ASCII file called myscript.sh (the CCSID must be ASCII or PASE 
cannot use it..) by running 

touch /yourfolder/myscript.sh

in a PASE environment.

Then, use EDTF to place the following command inside the newly created file:

/QOpenSys/bin/rm  foo  2> /tmp/error.log 

Now run the following: 

CALL PGM(QP2SHELL) PARM('/QopenSys/bin/sh' '/yourfolder/myscript.sh') 

When you look inside /tmp/error.log you should see the error message

rm: foo: No such file or directory



Regards, 
Shalom Carmel
-----------------------
www.venera.com - Exposing iSeries insecurity



----- Original Message -----
From: midrange-l-request@xxxxxxxxxxxx
To: midrange-l@xxxxxxxxxxxx
Sent: 9/3/05 4:33 PM
Subject: MIDRANGE-L Digest, Vol 4, Issue 1662


> 
> ------------------------------
> 
> message: 7
> date: Sat, 3 Sep 2005 15:12:36 -0500 (CDT)
> from: Scott Klement 
> subject: RE: Pase environment from a batch cl
> 
> > 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.
> 
> 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?
> 
>