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



On 5/12/06, web400@xxxxxxxxxxxxxxxx <web400@xxxxxxxxxxxxxxxx> wrote:

> CGI - Pros:
> You probably already know RPG.
> Easy to start with.

If you change "CGI" to "CGIDEV2" then I'll agree with that!  Getting
started with CGI when you aren't using CGIDEV2 (or a comparable toolkit)
is not easier.

I figured that if he's doing RPG-CGI, he's using a framework like
CGIDEV2, or Cozzi's XTOOLS, Brad Stone's stuff, etc.



> CGI - Cons:
> Doesn't always scale well.
> Locks you into using iSeries as your webserver and as your back-end.
> HTTP server and web application must be in same tier.
> Tough to hire people that know anything about RPG-CGI.

These are more the cons of RPG than they are of CGI.  Most of your
restrictions come from the fact that RPG really only runs on iSeries
systems.

It doesn't really lock you into using the iSeries as both the web server
and back-end...   The web server does need to be iSeries to run RPG, but
an RPG program can talk to other computers to get the data.  You could
have a back-end computer running DB2 and query it from RPG.  Or RPG could
run a web service on another computer, or communicate with another
computer using data queues or sockets.

Very true.  Hadn't thought about it that way.

Like I said, your restrictions are really because of RPG, not CGI.

The major cons of CGI itself are:

a) It requires starting up a separate process outside of the web server.

On most platforms this is very expensive.  It'd be like submitting a new
job for every RPG program you run, waiting for it to finish before doing
the next step.  The overhead of submitting the job is significant.

However, on the iSeries it isn't such a big problem because the CGI jobs
remain active and are re-used.  You don't have to start new ones over and
over.  Plus, iSeries programs can remain in memory with their files open
and variables intact so that they can be called again very quickly.  In
RPG we think of this as ending with *INLR = *OFF, but it's available via
activation groups in other ILE languages as well.  Since no other platform
has this functionality, and iSeries is such a tiny niche of the market,
this is still considered a huge blemish on CGI in general.

I'm going off of memory on this one, from posts by Andrew Borts on the
ignite400.org list.  He had (has?) an extremely active site and was
complaining about the expense of upgrading his systems to do the
webserving.  Now this was a few years ago, so maybe the less expensive
boxes have enough horsepower to handle even the most active of sites.

> JSP Pros:
> Easy to find people who know it.
> Can run web app tier on just about any platform.
> Can connect to multiple back-end databases.
> Can separate HTTP server tier from web app tier.
> Lots of open-source resources.

I actually haven't had much problem findint people familiar with CGIDEV2
programming.

I can't even find "regular" RPG developers in Richmond, VA, much less
ones who know anything like CGIDEV2.  If you know any, send them my
way ;-)

And drastically more open source resources, since 95% of the
iSeries community still doesn't understand open source.

Which is a huge hindrance to us.

However, there's even more PHP open source out there.  PHP is also
extremely widely used, at least as widely used as Java.

That's why I think people may want to consider PHP as an alternative.
I can't speak to how it scales, but I'm sure it's a pretty viable
alternative, at least for sites that are not getting millions of hits
daily.

Another Pro of using Java that you didn't list is that there's lots and
lots of functionality available.  By that, I mean routines that assist you
with writing web applications.  Far more tools than CGIDEV2 provides.
(Though, again, .NET and PHP have most of the same tools as Java)

That's what I was referring to in open source resources.

Also, for a small shop, performance can be a big problem with Java.
That's my biggest gripe about it.

Are you talking about Java, or WAS?  Because if you don't have a nice
new box loaded with memory, I'd probably recommend using Tomcat over
WAS.  Again, I'm lucky, I have lots of nice boxes to play with.

Mike E.


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.