× 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,

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.



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.