Re: 'green screen' not sellable --> WE(?) are the problem

Henrik,

Your first two points (must have an OS profile, must have OS object access) is not exclusive to persistent CGI. It's true of all CGI, and indeed, all HTTP access through Apache.

The way it works is that if you don't sign in and give a user profile, CGI programs use QTMHHTP1 for the OS user profile, and that's used to check access... it's exactly the same with persistent CGI as it is with regular CGI.

I don't understand the bit about FTP services -- persistent CGI has absolutely nothing to do with FTP, and in no way grants users access to FTP.

You wouldn't use a persistent session for AJAX... Persistent sessions are only activated when you send a special HTTP header, so with each request you can tell the server if it's to use the persistent session or not. In Profound UI we use a mix of persistent and non-persistent CGI. The persistent stuff is done for Open Access where the RPG program is sitting on an opcode like EXFMT waiting. When AJAX calls are made from customer's applications, it doesn't use persistent. These mix together seamlessly and work very nicely.

I have never seen a job closed down when reaching MaxCGIJobs. What happens is that no new jobs can be started, causing poor performance -- but it does not shut down the existing ones.

With regard to the problems of keeping many jobs active for statefulness... this part, at least, we can agree on. This can be a problem, but consider this: It's no worse than having people use 5250 emulators (which also require a job to be kept open all the time.) So if you are migrating from a 5250 application, you aren't losing anything here. We have customers running 10000 simultaneous users this way, and it works well. Granted, they do need to make sure they tune their system, have sufficient memory, network resources, etc... but once set up properly, it works great.

Of course, for a public facing web site (as opposed to a business app) when you can't control how many people will hit the site at once, you're much better off not using persistent CGI, which is why we offer alternatives. We have both persistent and non-persistent ways of doing things, use the right tool for the job.





On 6/11/2015 4:53 PM, Henrik Rützou wrote:

Some more remarks about Apache persistence CGI jobs.



* Users must have an *OS user profile, in many web applications users don’t.

* Users must have *OS object access to all objects used in the web system

* Users also gain access to other services that run on the server such as
FTP etc. unless extensive user controle is applied.

* Using internal user profiles and passwords in a web system that may be
accessed by a browser from any device opens for sniffing.

* Persistence is only pseudo persistence as described earlier

* Persistence is not designed for concurrent AJAX and may cause
unpredictable results. You will either need to remember to set the async:
false property in the AJAX request or has an AJAX queuing mechanism in your
web application.

* Jobs are closed down when MaxCGIJobs are reached causing closing and
reopening of programs and files and also loosing persistency and causing
poor performance.

* Persistence requires large pools of active IBM I jobs that even if they
are paged out of memory into the memory disk based work area takes up
resources.

On Thu, Jun 11, 2015 at 11:44 PM, Holger Scherer <hs@xxxxxxx> wrote:

that's the reason i put some entries into my hosts file like

127.0.0.1 facebook.com

;-)



Am 11.06.15 um 23:43 schrieb Henrik Rützou:

This is not hidden in a cookie it is delivered by google addwords

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