Re: QP2SHELL Prestart Jobs

Well, the garbage we see is in our SQL results. I am not exactly sure how
the DB2 extension works, but I know it communicates to those QSQSRVR jobs
and I would have to assume it is using stdio to do that. Perhaps that's a
bad assumption

Maybe the issue we were having has nothing to do with stdio, but there was
definitely something going on here that needed a clean job. Having
QP2SHELL run the shell script (which is what Zend recommends) results in
PHP running in a "child" job instead of the job that is running the CL.
When I call php-cli, I have no issues. If feels similar, but perhaps it is
just a coincidence. Regardless, I seem to have a solution.

Thanks for all the information.


--




*Matt Lavinder Programmer AnalystData Management Inc.Phone: (336)
573-5045Fax: (336) 573-5001*


On Fri, Jun 5, 2015 at 4:10 PM, Scott Klement <midrange-l@xxxxxxxxxxxxxxxx>
wrote:

Matt,

I think the shell script is for a different issue. At least, if I look at
the copy of Zend Server scripts that I'm running, they set up a bunch of
environment variables, and then call the binary.

Most importantly, they set LIBPATH to look in /usr/local/ZendSvr6/lib so
it can find it's dependencies (libraries; the Unix equivalent of service
programs.)

I don't think this is at all related to what I was describing. The issue I
was describing is related to whether the binary is multi-threaded and
whether it attempts to use the stdio of the job it's running in...


On 6/5/2015 2:25 PM, Matt Lavinder wrote:

You know, this has me thinking, my whole issue here might have been this
very thing. Zend seems to recommend running calling PHP via a shell
script
they provide as opposed to calling the PHP binary directly (which is what
you do on other platforms). Calling the binary directly has worked for us
until this last upgrade, but using their shell script seems to be the most
effective way to fix the issue we have been having.

- I can still use use QP2SHELL and call the PHP binary directly if I only
call the binary ONCE and then the job ends.
- If the CL or RPG has to call the PHP binary directly more than once,
bizarre things happen.

Dang it, I probably just fixed the very issue you were describing without
even knowing it.

OK, I take it back. I am willing to bet it is the same issue with a
different solution (shell script wrapper as opposed to QSH).


--




*Matt Lavinder Programmer AnalystData Management Inc.Phone: (336)
573-5045Fax: (336) 573-5001*


On Fri, Jun 5, 2015 at 1:27 PM, Scott Klement <
midrange-l@xxxxxxxxxxxxxxxx>
wrote:

Matt,

The problem with threadsafety issues is that they are unpredictable, it
all depends on timing. I've seen Unix (PASE) server-type programs
started
with QP2SHELL that worked fine in production for months, and then
suddenly
started failing so that all the user would get is garbage on the screen
--
with no explanation why. Nasty problem. Turned out to be the
threadsafety
issue.

On the other hand, if the PASE program you're launching is written to
handle the situation properly, than this would be a non-issue. Maybe
Zend
Support knows that PHP is written in a safe manner, here? (Or maybe they
just haven't run into the problem like I have?)

This is a non-issue with UNIXCMD, as it does set up a second job
connected
with thread-safe pipes. So it's perfectly safe to use UNIXCMD with the
QP2SHELL option (by setting 'mode=P' in the special file's PLIST)

This is also a non-issue with QP2TERM, as QP2TERM also spawns a
background
job connected with pipes. But, of course, QP2TERM can only be used
interactively. QSH does the same thing, but can be run in a batch job as
well.

You're right that QP2SHELL does not start the extra background job -- and
that's actually what causes the threadsafety issue to begin with. If you
know your program will run properly that way, then I can see the
advantage
of doing it this way for your 'strict rules' subsystems.


On 6/5/2015 11:28 AM, Matt Lavinder wrote:

Zend Support seems to recommend using QP2TERM and QP2SHELL. I don't

believe I need the prestart jobs now because I found another way around
my
issue.

Keep in mind, I use your UNIXCMD utility sometimes and I definitely use
QSH
in those cases (I have prestart jobs that work for those cases). I use
QP2SHELL when I simply have a CL program running a PHP script that is
self
contained and has no output (at least nothing to process). Some of our
subsystems have strict rules on how many jobs can run and using QP2SHELL
prevents an extra job from starting when I run the PHP script.

If I am not processing the output, are there still issues with running
PHP
scripts using QP2SHELL? I am curious because I've not experienced any
"strange" issues that could not be fixed by setting the right
environment
variable before calling QP2SHELL. Still, knowing the limitations might
save me a LOT of time down the road.


--




*Matt Lavinder Programmer AnalystData Management Inc.Phone: (336)
573-5045Fax: (336) 573-5001*



On Fri, Jun 5, 2015 at 11:23 AM, Scott Klement <
midrange-l@xxxxxxxxxxxxxxxx>
wrote:

I would not recommend using QP2SHELL for this unless you plan to go

through the effort of calling spawn() and pipe() to set up your own
stdio
descriptors.

Otherwise, QP2SHELL will fall back to the ILE descriptors in the same
job,
which are not threadsafe, and this can result in very strange and
unexpected errors.

That's why you normally see people use QSH for this.. because QShell
does
the work of setting up the descriptors for you.



On 6/5/2015 9:53 AM, Matt Lavinder wrote:

I am trying to create prestart job entries for QP2SHELL for some PHP

scripts to use. I have seen how to do it for QSHELL, but not for
QP2SHELL. I have always used QP2SHELL to run my scripts and I am not
sure
what impact switching to QSHELL would have. I'd rather stick with
what
works.

There seems to be examples for how to add prestart jobs for QSHELL,
but
for QP2SHELL and PASE, I have not seen good examples. Does anyone
know
what the entry needs to look like?

--

*Matt Lavinder *

--

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.


--

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.


--

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.