Re: QTEMP objects and Different Users on the Same Job

Joining the thread a bit late.

This sounds like a cgi program question. The http server starts up a number of prestart type jobs based on how you configure the http server.

When a http client calls in, 2 situations are possible. The first is a persistent connection as we all experience when writing a interactive program. The job remains with the caller until the job or program ends.

The second which is the default is non persistence. In this case the call comes in, the server determines which job is available to service the request and sends the call to that job. In this type of scenario, the caller may route through he same job or it may go to one of the other jobs. Whatever job it uses, you cannot expect the system to initialize the job each time. It simply does not as this was designed to save overhead. So you need to manage your own overhead and do your own housekeeping and setup with each and every call. In my experience, the system is fast enough to allow you to replace the library list, clear qtemp, etc and run the program.


Darryl Freinkel
iPad

On Mar 23, 2016, at 2:36 PM, Arco Simonse <arco400@xxxxxxxxx> wrote:

And I'm very glad that CGI jobs don't do a kind of reset after each
request. In our shop we load a couple of 'handler' serviceprograms at the
first request, and they stay active in named activation groups until the
CGI job ends or when they are ended explicit. And we like that approach for
performance reasons.

Regards,
Arco Simonse

Op dinsdag 22 maart 2016 heeft Nathan Andelin <nandelin@xxxxxxxxx> het
volgende geschreven:

And perhaps CGI jobs
are a bit different that an OS prestart job.

Yes, that's right. CGI JOBS are not the same as prestart JOBS. CGI JOBS
remain active - and visible from the WRKACTJOB command. They just go into a
wait state, until an HTTP server thread decides to forward another request.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx <javascript:;>
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx <javascript:;>
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxx <javascript:;> for any subscription
related questions.

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

Please contact support@xxxxxxxxxxxx for any subscription related questions.