You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@httpd.apache.org by Joshua Andrews <ja...@exeter.com> on 2007/04/14 01:45:29 UTC

[users@httpd] Calling COBOL via CGI

I am reviewing technical possibilities for calling COBOL programs via CGI to
read mainframe flat-file data. I would probably compile the COBOL to
executables and then pass parameters.
 
My main questions are:
 
1. Has anyone else done something like this?
2. I've heard of performance issues associated with CGI and the usage of
FastCGI to alleviate this. However, CGI (and FastCGI) seem so 1999 --
although, if it works, it works. I'm just wondering if there's a better way
to do this now, with better security and less performance overhead.
 
Thanks,
 
Josh
 

Re: [users@httpd] Calling COBOL via CGI

Posted by Jaqui Greenlees <ja...@yahoo.ca>.
--- Joshua Andrews <ja...@exeter.com> wrote:

> I am reviewing technical possibilities for calling
> COBOL programs via CGI to
> read mainframe flat-file data. I would probably
> compile the COBOL to
> executables and then pass parameters.
>  
> My main questions are:
>  
> 1. Has anyone else done something like this?
Any executable can be used as cgi, if you want.
You could write the app in any language, as long as it
was capable of accessing the files it needs to parse
it can be used as cgi.


> 2. I've heard of performance issues associated with
> CGI and the usage of
> FastCGI to alleviate this. However, CGI (and
> FastCGI) seem so 1999 --
> although, if it works, it works. I'm just wondering
> if there's a better way
> to do this now, with better security and less
> performance overhead.
>  
CGI is no more or less secure than any other web
technology by default. if the application was written
with both system and network security in mind then it
is a secure cgi application.

Performance wise, cgi is a heavier draw on the server
than a static page or client side page. all server
side processing does slow down the server, if the load
is to much then it might be better to redesign the
entire app to bring it into a current database model
and serve the data from your current database engine.
[ presuming such would be separate hardware ]

I actually know of several community sites with large
memberships that are using cgi for the site scripting,
they are about as fast as the php + db or asp.net +db
sites are, the site owners have put the money into the
hardware to support the server side processing.

There is a benefit to cgi, in that since your app will
be processing user supplied data on the server, you
have to pay more attention to sanitizing user supplied
data than has been the case in recent years with a lot
of website scripts. This reduces cross site scripting
and sql injection risks dramatically.

Jaqui


Jeff Henager: "If the average user can put a CD in and boot the system and follow the prompts, he can install and use Linux. If he can't do that simple task, he doesn't need to be around technology."


      Be smarter than spam. See how smart SpamGuard is at giving junk email the boot with the All-new Yahoo! Mail at http://mrd.mail.yahoo.com/try_beta?.intl=ca


---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
   "   from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org