×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
I think test environments in CGI are one of the best things about it.
--Test Apache listening on a non-standard port
--Manually start on demand
--Points to a test CGI library
--Test library list
--CGI programs read job name (which corresponds to server name) to determine where to locate CGIDEV2 templates
-----Original Message-----
From: Nathan Andelin [mailto:nandelin@xxxxxxxxx]
Sent: Wednesday, September 14, 2016 1:51 PM
To: Web Enabling the IBM i (AS/400 and iSeries) <web400@xxxxxxxxxxxx>
Subject: Re: [WEB400] Apache vs Express for Node
CGI is kind of a "special snowflake" and not even IBM is behind it still.
CGI interfaces and their derivatives do fine in a pinch, when the workload is small-scale and narrowly-scoped. They fail architecturally when applications are broadly scoped, subjected to thousands of concurrent users, require multiple runtime environments for say development, test, and production or hosting many tenants on a single server.
One reason for this, is that architecturally you're combining socket I/O, request routing, application framework code, application code, and DB code in a single process, or a set of tightly-bound child processes. Under this model it is possible to deploy one errant component which destabilizes the whole shebang.
One solution to this problem is to stop running application frameworks and applications in HTTP server jobs. Relegate the HTTP server to communications. Use some form of inter-process communications to forward client requests to essentially independent outside jobs for processing, then returning responses to HTTP clients.
midrange.com
