> From: srichter
>
> >From: "Joe Pluta" <joepluta@PlutaBrothers.com>
> >>
> >> Once you start trying to optimize and mix programing models you
> >> really start
> >> to muck things up.
> >
> >Only if you don't understand them.
> >
>
> Not sure what that means.

It means that I mix OOP and procedural all the time, and I don't muck things
up.  In fact, OOP is a superset of procedural, because at the base of
things, you still execute code one instruction at a time.


> >I categorically disagree.  RPG is great for database access and business
> >logic programming, while OOP is great for user interface design and
> >middleware.
>
> How is:
>
> Eval ItPo# = OhPo#
> Eval ItComp = OhComp
> ItKey2  Chain  InTranL1
> If not %Eof
> **  Display ItPo#, ItComp, Itrqty, ItItem
> EndIf
>
> Better than:
>
> InTranL1.Chain( OhPo#, OhComp )
> If InTranL1.RcdFound( ) == TRUE
> ** Display IntranL1.Po#, InTranL1.RcvQty, ...
> End

Um... because one exists and the other does not?  What language is that
second paragraph supposed to represent?  If it's a Java-like language, then
you haven't shown the code that actually implements the Chain operation, or
indeed the rest of the InTranL1 class, which, since it's not RPG, you'll
have to write yourself.  The fact that the CHAIN opcode is intrinsically
part of the RPG syntax is one of the major reasons that it's so superior to
most other HLLs (COBOL'ers please don't hit me!).  The other is that, if the
code under your "Chain" method in option two is some ODBC derivative, then
the RPG CHAIN opcode is much faster.


> I think the OOP version is more clear and "building blockable".
> The only advantage to the RPG version is that is uses less CPU.
> And the AS400 is the only platform on which the CPU disadvantage
> of the OOP version matters.

I think the OOP version is a figment of your imagination, whereas the RPG
version is actually available and thousands of programmers know exactly what
it means.


> > I use Java to web enable legacy applications written in RPG and
> >the result is subsecond response time for applications that look
> like they
> >were designed for the web.
> >
>
> Any estimate on how much CPW is needed for each concurrent user ?

Yeah - zero interactive CPW.  But I suspect it's more than the pure 5250
approach.  On the other hand, it's far cheaper for the user because they can
afford to buy a far larger machine, since they don't have to pay the
interactive tax.  At the same time they get browser-based access to their
legacy applications.  Also, if I feel that the workload on the host machine
is too much, I can easily offload the web server to another machine, at
which point the CPW load will actually be less on the AS/400, since there's
no 5250 workload.


> The as400 could meet these requirements much better if the CPU
> was as fast as it could be ( can even keep the price the same ).
> IBM would make more money, colleagues of mine would not be
> leaving the platform because of the lack of work and we could
> prove to the rest of the computer world that our platform is the
> best on the market.

Thank you for your opinion.  Got nothing to do with your original statement:

"This is not trivial.  The slow cpu of the iSeries prevents modern
programming languages from being used on our system."

I'd rather not wander too terribly into opinions.  Opinions are like...
well, everybody's got one, anyway.  And your opinion and mine are worth
exactly the same thing - the paper they're written on.  I try to deal in
facts, and given the turn in your argument, I'll just leave it here.

Joe Pluta
www.plutabrothers.com



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.