On Sat, Mar 4, 2017 at 9:32 AM, Richard Schoen <
Richard.Schoen@xxxxxxxxxxxxxxx> wrote:

Since the CGI request/response cycle is synchronous and performing a
single CGI transaction why would steering away from QTEMP be bad ? I'm not
following your time slicing theory.


I admit that the time-slicing idea was a theory. As I reflect more, it
doesn't really stand up. It's true that an essentially unlimited number of
programs can become and remain active in a single CGI Job. But my
understanding is that CPU time-slicing pertains to Job threads - not active
programs. And your CGI jobs are probably single threaded, as most are.

Ultimately I may suggest that the developers place the additional session
data into the session database we already have, but your response seems
contradictory on whether QTEMP is unique or not.


In regard to my response being contradictory to whether QTEMP is unique or
not - so was your original premise about one job's QTEMP object getting
clobbered by another job.

You seem to advise against it, yet isn't QTEMP a hallmark of IBMi jobs and
unique across jobs as we've been discussing ?


To be blunt, I advise against using CGI for business applications, because
faulty program logic can destabilize the entire HTTP service. Similarity, I
advise against embedding an HTTP service within applications (i.e. Node.js).

I believe that HTTP should be used only for communications; that business
applications should run in separate processes; and that there should be
some way for both to communicate with each other. IBM i CGI kind of does
that - but not well enough IMHO. CGI Jobs are too tightly coupled with HTTP
server threads.

This thread ...

Replies:

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

This mailing list archive is Copyright 1997-2019 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].