Re: RPG vs. Java vs. C++

I agree that RPG works well for business applications on the iSeries.
Rewriting to a different language would not be cost effective.  I would
look at increasing performance in the programs that are more CPU intensive.
I would also make sure that the system has been tuned.  A system running at
65% is ok, while +++ is not acceptable.  When you are looking at CPU%, make
sure that the elapsed time is at least 5 minutes.  If the elapsed time is
to small, you will not get a good average of CPU%.  I have seen many
systems that change dramatically because of performance tuning.  If that
does not help, then hardware upgrades is where I would look next.

Steve

> message: 1
> date: Thu, 24 Mar 2005 15:56:11 -0500
> from: "Brian Piotrowski" <bpiotrowski@xxxxxxxxxxxxxxx>
> subject: RPG vs. Java vs. C++
>
> Hi All,
>
> I know this is off-topic, but I'd like to get everyone's thoughts on
> this subject.
>
> If this has been discussed ad-nauseum, I apologize in advance.
>
> Management has asked if there would be any value to having additional
> applications on our iSeries that were not designed in RPG.  Rather, they
> asked the impact that using Java or C++ based applications would have on
> the server.
>
> Does anyone have any data or performance metrics (or better yet, links!)
> they could share to give me an idea on how a Java app would perform on
> an AS/400 vs. a C++ app. Vs. an RPG app?
>
> The reason management has been asking is due to the legacy programs that
> run on our machine.  We are currently running a 720 series w/2GB main
> storage and 175GB raid 5 array with 90% of the programs written in-house
> (and before my time).  At any given time, when I look at the performance
> of our AS/400 (through system status), and it always seems to be above
> 65% (or it's often at ++++ when I look at it).
>
>
>
> Management wonders if these programs were rewritten in C++ or Java if it
> would have a positive effect on the server?
>
>
>
> Any comments are welcomed and appreciated.
>
>
>
> Thanks,
>
>
>
> Brian.
>