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



> Performance was only one reason for supporting SQL.  In any programming
> language, the hallmarks of good code are functionality and documentation.
> Performance is a distant 3rd (or maybe 4th and 5th).

And I submit that as Manager of Architecture at SSA, at the time the largest
AS/400 application developer in the world, the complaints I heard most often
were not about functionality or documentation, but about performance.  Pure
and simple.  Performance on MRP gens, performance on order entry,
performance on month-end close.  If rewriting month-end close in RPG saved
the end user four hours, you better believe they wanted it rewritten.  They
could care less what the code looked like.

> What I hear you saying is that in your experience, you have found that RPG
> is gives you a needed performance boost that your customers demand.  You
> have choosen a pragmatic approach that works well in your
> environment.  Fair
> enough; I'm just pointing out that your solution may not be the best
> solution is *all* cases.  Honestly, I get some pretty good
> performance from
> the JDBC driver.  I really don't see much difference between SQL and RPG.

While JDBC is adequate for queries, it doesn't perform nearly as well as RPG
in transaction processing; I've posted plenty of benchmarks to that effect
over the last year or so.  It certainly makes THE PROGRAMMER'S job faster,
but the user could care less how easy your job is, as long as it gets the
THEIR job done as quickly as possible.

> Anyway, I think we both agree that "n-tier" development is a great way to
> develop web-based systems.  I think we just differ where the lines of
> demarcation are drawn....  I value maintainability, you value performance.
> In my experience, those two attributes are usually at odds, anyway....  It
> maybe a product of my education; both my undergrad and masters are in
> business, not in computer science.....

Maintainability is an issue, but properly designed n-tier code is just as
maintainable as SQL code, and in many cases more maintainable.  There is
better visibility into file usage using native database access, and for
complex statements native code is easier to debug (although I suppose the
last is a bit of an opinion - however, I submit that 20 lines of RPG is alot
easier to read than a five-line OUTER JOIN with subselects).

Anyway, we both have opinions.  Yours is as valid as mine.  Neither of us
blathering marketing hyperbole, but sharing opinions based no our personal
experiences, so we can just agree to disagree, and implement the solution
best suited to our individual preferences.

Joe



As an Amazon Associate we earn from qualifying purchases.

This thread ...

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.