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



Bob,



I'm glad to know that IBM experts evaluated the idea of extending DDS to support Web Apps, but I'm not sure why you say that IBM rejected it. It appears to me that IBM's Webfacing product was an implementation of the idea.

However, I understand that a lot of RPG programmers have been pounding on IBM for a 100% native implementation (one that didn't involve Websphere), but I'm not one of them. Moreover I delineated a few reasons why I didn't implement that idea, myself. For now, I'll assume that you mean that IBM rejected the idea of implementing a 100% native version of Webfacing.

Regarding your assertion that RPG use is declining, I'll admit that
you're in a much better position to know. IBM has been reporting
declining System i sales, so the news about the use of RPG declining is
not surprising. In my opinion, the System i is a victim of IBM's
server homogenization strategy, but I'll defer to IBM's judgment in
running its businesses.



Regarding your assertion that CGI doesn't scale well, I've made the same assertion in the past, and written a lot about it, and even implemented an HTTP server plug-in that bypasses the native CGI interface, but I've stopped saying that CGI doesn't scale well because it's an overly broad statement, and the scalability of CGI depends on what you compare it to. And contrary to your assertion, I think that if you compared the native CGI interface with J2EE architecture, you'd find that the CGI interface scales better than J2EE in many if not most cases. So now if a programmer is using CGIDEV2 or one of the available CGI frameworks, I tend to encourage it.

I acknowledge that there are cases where J2EE will scale better than CGI. In cases where a specific application is hit with hundreds or thousands of requests per second the CGI interface will falter. My personal framework is ILE based, but uses an HTTP server plug-in which bypasses both CGI and J2EE, so I deal with a different set of considerations.

While Net.Data runs under the native CGI interface, I think the scalability of Net.Data is a lot different than the scalability of applications written with CGIDEV2, for example. Net.Data could be hosting hundred's or even thousands of scripts, while a CGIDEV2 application may have very narrow scope. I suspect that Net.Data and PHP deal with comparable scalability issues.

I read a study where Websphere wouldn't scale on a multi-CPU server until the company deployed their applications under multiple instances of Websphere and used a load-balancer to route requests to each instance. My point, is that saying one architecture scales better than another architecture is often misleading, so I've stopped using that argument, myself.

Nathan M. Andelin


----- Original Message ----
From: Bob Cancilla <bob.cancilla@xxxxxxxxx>
To: Web Enabling the AS400 / iSeries <web400@xxxxxxxxxxxx>
Sent: Tuesday, December 18, 2007 7:24:03 AM
Subject: Re: [WEB400] The Truth About EGL


Nathan,

Many of the pundits that advocate extending DDS to support Web Apps
should
know better. This approach has actually been very carefully evaluated
by
experts from both the languges, tools, and i5/OS teams. Nathan, what
you
say about extending DDS is true on the surface and would certainly
provide
an easy to code approach for RPG programmers. Unfortunately it would
not
scale or perform within the i5/OS architecture.

While many customers run 2000 or more 5250 user sessions, our customers
have
instances during their day where you have over 100,000 users accessing
your
web sites. An i5 machine running 100,000 interactive jobs would be the
System i sales person's dream.

Nathan, look at your DDS keywords and you will find that you can in
fact and
have been able to embed HTML in DDS since about 1995. Also keep in
mind
that DDS and RPG provides the ease of use that it does because you are
running full conversational code. You send the screen to the terminal
and
your program and its supporting job waits on the user for a response
and
then execute the next line of code.

As you well know, I was a Net.Data advocate for many years. It was
easy and
did the job in the early days of the web with a simple CGI based
approach
leveraging service programs to provide some degree of performance.
Ultimately it would not scale. CGI simply does not scale. You need
the
advanced system management capabilities of an Application Server. You
can
still call RPG programs that are written in such a manner so that you
can
call them, and quite frankly I see this as an excellent balance
leveraging
existing people and skills.

Also keep in mind that while I said RPG is far from dead, it is also on
the
decline. The number of RPG programmers is rapidly diminishing as is
the
case for COBOL also. Many of our customers are coming to us asking us
to
help migrate away from RPG or COBOL.

Look RPG is an outstanding language and better than it has ever been at
the
V5R4 level of the language and will be even better at V6R1 and beyond,
but
facts are facts. It is an old language and no amount of wishing or
marketing will turn it into a popular modern language. RPG as I said
before
has at least a strong 10 year life, maybe much longer. It is however
on the
decline. Just look around your shop. How many young people (20's or
even
30's) do you have in the shop? Who is teaching RPG? or COBOL for that
matter.

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

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.