× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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.



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.