Re: Question on QTEMP and CGI Jobs

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.

My original question was seeking clarity that this wasn't the case and your initial answer was not clear. Thanks for the clarity on time travel theories.

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.

OK, I'll bite, so you don't use the Apache web server and RPG in the applications that you write ? Do tell how you handle your HTTP serving and business logic.

Regards,


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

-----Original Message-----
Subject: Re: Question on QTEMP and CGI Jobs
From: Nathan Andelin <nandelin@xxxxxxxxx>
Date: Sat, 4 Mar 2017 12:33:06 -0700

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.