Re: Question on QTEMP and CGI Jobs

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.