RE: CALL QP2SHELL variables

Thanks for explaining the "why it doesn't work" as well as the rest. In this case, I don't need STDIN/STDOUT/error detection, etc. It's just an email being sent internally, and I need the parameter to know what data to put in the email. It's one of those temporary/transitional things.

I was just baffled that it worked from a command line and not in a program. Normally we see the opposite (due to parameter lengths assumed on CALL).
--
Sean Porterfield


-----Original Message-----
From: Scott Klement
Sent: Monday, November 19, 2012 16:08
To: Midrange Systems Technical Discussion
Subject: Re: CALL QP2SHELL variables

Hi Sean,

You need to null-terminate your &CALL# variable. Make the code look something like this:

DCL VAR(&CALLZ) TYPE(*CHAR) LEN(31)
DCL VAR(&NULL) TYPE(*CHAR) LEN(1) VALUE(x'00')

CHGVAR VAR(&CALLZ) VALUE(&CALL# *TCAT &NULL)

CALL PGM(QP2SHELL) PARM('/usr/local/zendsvr/bin/php-cli' +
'/home/qpgmr/help2rt.php' &CALLZ)


Having said that -- I strongly discourage you from using QP2SHELL this way. QP2SHELL does not create proper stdio descriptors (stdin, stdout,
stderr) but rather uses whatever the calling job has set up. In this environment, that's either "nothing", or "the ILE C ones". Neither of these are threadsafe.

For this reason, I recommend using QShell to launch programs like this
-- QShell will spawn a background job and create pipes connected to the stdio descriptor, and these are threadsafe, thus the problem is solved.

CHGVAR VAR(&CMD) VALUE('/usr/local/zensvr/bin/php-cli +
/home/qpgmr/help2rt.php *BCAT &CALL#) QSH CMD(&CMD)

Using QShell, it's not necessary to do the null-termination, et al.
QShell just takes a single string for the command to run, and parses it into the components and null-terminates them properly before calling the program.

QShell is also much better for retrieving/handling errors.


On 11/19/2012 2:34 PM, Porterfield, Sean wrote:

Fresh upgrade to V7.1 with latest PTFs as of a few weeks ago (so not the latest anymore).

I can probably find another way to make this work, but I'm not sure why it doesn't work the way I'm trying.

I have an existing RPGLE program that calls an existing CL program.
I'm modifying that CL program to run a PHP script instead of what it
used to do (which was print a report and use FastFax to email a PDF of
it.)

Simple test to see what's happening, RPGLE program replaced with:

DTSNO07 S 10 INZ('0000120137')
DEMAIL S 30 INZ('valuenotused')
C CALL 'MYCLPGM'
C PARM TSNO07
C PARM EMAIL
C RETURN

I wanted to rule out any command line CALL parameter issues by having RPGLE call the CL like the original.

The CL program has the parameters defined the same:
PGM PARM(&CALL# &EMAIL)
DCL VAR(&CALL#) TYPE(*CHAR) LEN(10)
DCL VAR(&EMAIL) TYPE(*CHAR) LEN(30)

CALL PGM(QP2SHELL) PARM('/usr/local/zendsvr/bin/php-cli' +
'/home/qpgmr/help2rt.php' &CALL#)

If I DMPCLPGM, I can see the &CALL# contains what it should. When my PHP script gets it, it has garbage at the end, but only one character visible in the error that prints. It doesn't come over to text based email when I copy/paste from the screen.

I thought maybe I should put single quotes around it, and I did manage to get that to PHP correctly when I built a *CHAR 12 field in CL, but then the value passed in has quotes and doesn't match the field in my database that doesn't have quotes.

The part I don't understand is &CALL# above not being just 10 characters when it gets over to PHP.

If I run it from a command line, it works fine:
CALL PGM(QP2SHELL) PARM('/usr/local/zendsvr/bin/php-cli'
'/home/qpgmr/help2rt.php' '0000120137')
--
Sean Porterfield

This email is confidential, intended only for the named recipient(s) above and may contain information that is privileged. If you have received this message in error or are not the named recipient(s), please notify the sender immediately and delete this email message from your computer as any and all unauthorized distribution or use of this message is strictly prohibited. Thank you.