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



Joe,

talking about business rules and all the big words,
and than showing to 'prove it' 
a dumb counter application without any data access 
to 'support your claims'
and at the same time attacking other people for being 'unsubstantiated'
is imho a bit over the top 

most business rules are a bit more complicated .

luc

  
message: 3
date: Fri, 12 Mar 2004 06:58:40 -0600
from: "Joe Pluta" <joepluta@xxxxxxxxxxxxxxxxx>
subject: RE: What is Performance

> From: Dieter Bender
> 
> thats one of the misteries, that might have been true some years ago,
or
> that might be true for a liitle 170. But today on recent hardware its 
> simply not the truth.

Prove it.


> For simple transactions (like read a record, or do one single update) 
> there might be an advantage for rpg, but you have to pay a price for 
> this, you have to code every line by hand and changes in database or 
> retrival logic has more maintenance afford, compared to modern 
> languages like java, where you can use mapping tools for instance.

This simply isn't the case.  I can still code business rules faster in RPG
than in Java.  And maintenance is easier in RPG.  You may not think so, you
may code faster in Java.  But that's okay, because it has NOTHING TO DO with
the performance of the program.  Let's stick to one subject at a time.


> This advantage would be in the range of 3 to 5
> times faster for rpg to well done java code. If you get 10 to 100
times,
> there must be a problem with the design of the java code.

Prove it.


> For complex transactions java might be even faster than rpg, if you
use
> multithreading in java to get benefit of parallelism.

Dieter, have you ever multi-threaded a real business transaction?  How, for
instance, would multi-threading provide you a benefit when entering an
order?  Please show us some example code that runs faster than RPG. And, as
you say, this means you can't use EJBs.  You also can't use tools, because
there are no tools that generated multi-threaded code.


> Putting this together today a rpg solution might be about 3 times
faster
> for one user compared to a well designed java application doing 
> comparable work. Besides the fact (some like others not) that green 
> screen is diappearing lets have a look how applications scale and 
> let's begin with 5250.

Prove it.


> And now lets have a closer look at the java rpg mix and ist
scalability.

(snip of a bunch of stuff about how calls to RPG aren't scalable.)

Dieter, your arguments are unsubstantiated.  You base them on some
assumptions about synchronization that simply aren't proven.  For example,
in my architecture each session gets its own job and communicates with the
JVM via data queues.

In any case, I no longer will respond to your general statements about
performance until I see some working code that supports your claims. Please
feel free to write some code that backs up your statements and present it
here.  Then we can talk.  Until then, it's all supposition and a waste of
time.

Joe


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.