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



Richard

if you know the programs that causes the problem put a call to CL as first
statement in the RPGLE program
it should give you the info for each call you need ...

PGM

DSPJOB OUTPUT(*PRINT)
DSPLIB LIB(QTEMP) OUTPUT(*PRINT)

ENDPGM

On Sun, Mar 5, 2017 at 2:35 AM, Scott Klement <web400@xxxxxxxxxxxxxxxx>
wrote:

Richard,

I agree with what everyone else has said, Apache never uses the same job
two run two CGI requests concurrently via threads.

It does have the capability to start CGI jobs as "multiple thread capable"
(there's an Apache directive to enable this). But, this only marks the job
as capable of multiple threads so that the CGI job can internally spawn
threads if it desires. Apache does not call it in a multiple concurrent
thread manner.

Are you "absolutely" sure that the programmer isn't confusing a request
(or a "call" as you've phrased it) with a session? Because within the
scope of a session, it's very possible (and likely) that other sessions
will also be serviced by the same job with the same QTEMP. And conversely,
it is also true that a single session will be handled by multiple jobs with
different QTEMPs.

This is a very common mistake that people make. And, it can be hard to
detect during testing, because frequently the load on the test HTTP server
isn't very high, so it may come back with the same job for all requests in
the session just by "luck." But in production server where there are more
requests, it'll almost certainly switch jobs during a session, and re-use
the same job for other sessions.

In fact, if your programmer does in fact understand the difference between
requests and sessions and knows that the QTEMP is used in a valid manner
(i.e. only during the space of a single REQUEST) then I'm having a hard
time even understanding what value QTEMP provides? Since the data can only
reside there (legimately, anyway) for a very small time, and you can't use
it to keep data persistent within the session, what purpose does it serve
to use QTEMP? Something like an *OUTFILE option that you're going to
immediately process and then delete would be one legitimate use... but
that's about it.

Of course, if we're talking about persistent CGI, that's a different
story...

-SK


On 3/4/17 12:33 PM, Richard Schoen wrote:

I was chatting offline with someone else here from the list and this
has brought up the following follow on question in my head:

Are we "absolutely" sure that each individual synchronous CGI call
through the Apache server gets serviced by a separate single job
instance and not potentially by multiple threads within a single CGI
job instance ?

If the latter condition occurs within the modern Apache Server then
the argument NOT to use QTEMP is very valid because two threads in
the same job would have access to the same QTEMP instance.

Regards,


Richard Schoen
Director of Document Management
e. richard.schoen@xxxxxxxxxxxxxxx
p. 952.486.6802
w. helpsystems.com


--
Scott Klement
http://www.scottklement.com

--
This is the Web Enabling the IBM i (AS/400 and iSeries) (WEB400) mailing
list
To post a message email: WEB400@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/web400
or email: WEB400-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/web400.





As an Amazon Associate we earn from qualifying purchases.

This thread ...

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.