RE: Weird problems with Qp2RunPase

Thanks Scott!

Comments inline...

-----Original Message-----
From: rpg400-l-bounces+wiltc=cintas.com@xxxxxxxxxxxx 
[mailto:rpg400-l-bounces+wiltc=cintas.com@xxxxxxxxxxxx] On 
Behalf Of Scott Klement
Sent: Monday, March 19, 2007 2:27 AM
To: RPG programming on the AS400 / iSeries
Subject: Re: Weird problems with Qp2RunPase


You probably already know this, but...  Just to make sure 
we're on the same page, what you're doing is running a 
program.  When you type this:

      gpg --no-tty --yes --batch -oSomeFile

That's the Unix way of performing a program call. It's 
equivalent to the following command in our traditional i5/OS 
environment:

      CALL PGM(gpg) PARM('--no-tty' '--yes' '--batch' '-oSomeFile')

So it's nothing more than a program call with parameters 
passed.  That might seem strange to an i5/OS programmer, 
where a *CMD object would be required to call a program 
without using the CALL command -- but in Unix there's no such 
thing as a *CMD object.  A command name is nothing more than 
a program that's run.

In the absence of any quotes (which is the case here) the 
Unix shell breaks up the parameters by any spaces or tabs in 
the command line. So each time you see a space in the above 
Unix command-line, it separates it into a another parameter.

Okay -- on to your program....

         parms(1) = ENCRYPT_PROGRAM + x'00';
         parms(2) = '--no-tty' + x'00';
         parms(3) = '--yes' + x'00';
         parms(4) = '--batch' + x'00';
         parms(5) = '-o' + destFile + x'00';
         parms(6) = '-e' + x'00';
         parms(7) = '-r' + recipient + x'00';
         parms(8) = '--no-permission-warning' + x'00';
         parms(9) = sourceFile + x'00';

You'll note that when you use this API, there's no Unix shell 
involved. 
  You are invoking the program directly, rather than going through a 
shell like you are on the command line.   There's no code to separate 
that parameters out by the spaces in them.  YOU have to do 
that by putting each parameter in it's own array element.

And you've done that in the example above.

But if you change the example to this:

           parms(5) = '--output ' + destFile + x'00';

Now you've created a problem.  A Unix shell would not have 
passed both --output and "destFile" in the same parameter.  
Why not?  Because there's a space between them.  So a Unix 
shell would've done this instead:

           parms(5) = '--output' + x'00';
           parms(6) = destFile + x'00';

Because of the space, it separates it into two parameters.  
While GPG COULD have been written to handle this situation, 
it wasn't, because it was designed with the assumption that 
it'll be called from a Unix shell.

Ah, I see.  That makes perfect sense.

I figured the space was the problem, I just didn't understand why.

Since I don't get to work much in Linux/UNIX, I tend to forget about the 
"extras" that are provided by
the shell.

Personally, I find it easier to use the shell included with 
PASE, and let it handle the parsing of the command for me.  
That way, I don't have to muck around with separating the 
parameters according to these rules. 
To do that, make the first parameter be the shell rather than 
the program.  Use -c for the second parameter (this tells the 
shell to run a
command) and pass the whole command string, just like you'd 
type it interactively, as the 3rd parameter.

For example (untested):

           parms(1) = '/QOpenSys/usr/bin/-sh' + x'00';
           parms(2) = '-c' + x'00';
           parms(3) = 'gpg --no-tty --yes --batch'
                    + ' -o' + destFile
                    + ' -e'
                    + ' -r' + recipient
                    + ' --no-permission-warning'
                    + ' ' + sourceFile + x'00';

In this circumstance, the actual program you're running is 
the shell itself (-sh is the PASE version of the Korn Shell). 
 You're only passing two parameters to the shell.  -c to tell 
it to run a command, and the WHOLE command string in the 3rd 
parameter (that's why you only need to add x'00' once, at the 
end of the whole command string)

This is basically the Unix equivalent of calling QCMDEXC.  
You send a whole command string in one parameter, and it'll 
take care of parsing the command and passing the right 
parameters to the program.  It'll also search your PATH for 
the program, so it's no longer necessary to specify a 
fully-qualified path for the 'gpg' program name.  (though, 
you can if you really want to.)

I like this, hard coding the path to gpg was something I didn't like doing.

But hard coding the path to '-sh' wouldn't be so bad.

Question: what about the environment variables?
I assume that if I'm getting the PATH, I'm getting any other PASE environment 
variables that would be
set if I had done a CALL QP2TERM to get the interactive shell.

How about if I pass an extra, 
  environ(1) = 'PASE_SYSCALL_NOSIGILL=plock=0' + x'00';

In my call to the shell, I assume that will still exist when gpg gets called.

Thanks again for your help Scott.

Charles





This e-mail transmission contains information that is intended to be 
confidential and privileged.  If you receive this e-mail and you are not a 
named addressee you are hereby notified that you are not authorized to read, 
print, retain, copy or disseminate this communication without the consent of 
the sender and that doing so is prohibited and may be unlawful.  Please reply 
to the message immediately by informing the sender that the message was 
misdirected.  After replying, please delete and otherwise erase it and any 
attachments from your computer system.  Your assistance in correcting this 
error is appreciated.