RE: Re: Resort back to RPG?

>if you can program an OO MRP generation, including
>coproducts and byproducts, dependent and
>independent demand, batch balancing, and all the
>other features we require in ERP systems, amd it
>runs as fast as it does in RPG, then you've reached a
>point where perhaps OO can be used for business
>programming (BTW, SQL still fails this particular
>benchmark).

Hi Joe!
I can only comment on two parts of your post, being of limited OO
experience.

Performance.  It is not farfetched to envision a hardware JVM that is VERY
efficient for Java and much less so for RPG.  It's not here today, but the
probability of better performance means that I feel somewhat at ease
disregarding the performance aspect of your challenge for the moment.

MRP generation.  Java may indeed pee a very poor fit for MRP generation, but
I don't think that because Java is poor at one sort of business application,
it's poor at all sorts of business applications.

I wouldn't use RPG for geographic based systems (say least cost truck
routing.)  I could, especially now that I don't have to write the higher
match functions myself, but it wouldn't be pretty, nor would it be a
screaming performer.  Just because RPG can't do THAT sort of business
programming doesn't mean it's bad at all sorts of business programming.

Far more typical than either of these extremes are customer care, order
entry, shipping, blah blah blah.  (And you can quote me on that.)  Let me
set up an example from my current industry - telecommunications.  We'd like
to extend our customer care application to the web (look Ma, I'm on topic!)
so that say, students can set up their phone service when the move into a
dormitory, change their service plans at a whim and check out/close the
account at the end of the school year.

Extending to the web is somewhat of a misnomer, because self-service is
quite beyond our existing green screen capabilities.  There are in fact,
very few existing functions that would support self-service.  So, there is
going to be some application development.  We have Delphi programmers who
can build a thick client (which actually looks and works great), we have
Java folks who can write applications, applets or servlets, we have RPG
folks who can write server-side programs.  We may end up with a mix of
languages on the iSeries, or nothing at all but a JDBC server there.  The
technical decision will ride on the business requirements.

There's no single answer that's 'right' of course, which is why I think the
blanket "Java isn't that good for business programming" needs some fine
tuning.
Best regards!
  --buck (cheerily using MHLZO since July 1978 and defending Java anyway...)