Re: Performance of ODBC vs. other access methods

Steve has probably been beaten enough for one day, but I wrote a set of 
procedures for manipulating dynamically sizable arrays (linked lists), using 
ALLOC and DEALLOC op codes, which I packaged in a service program and use in 
most applications I write, and the performance is great, even on my development 
box, which is an older model 170, which has a CPU geared down to about 35 MHz.

As far as iSeries price / performance is concerned, the ball is in IBM's court. 
 IBM could easily lower the price and increased performance, and that would 
make most ISVs and customers happy, and would lead to more market share, but 
may lower the profitability for IBM.

Randall Munson, the iSeries marketing guru makes a point that the box has a 
higher value, which is reflected in the price.  The main problem is that IBM 
homogenizes all their servers in branding as well as technical features (SQL, 
Webshpere, J2EE, open standards, etc.), which diminishes any message about 
distinctive features that add value.

Most people on this list recognize the problem.  The platform has steadily lost 
market share in recent years, but the ball is in IBM's court.

ISV's and customers can also take up some slack.  For example, rather than 
complaining about a feature being missing in RPG, it's not too difficult to 
extend the language with your own service programs.  Thank goodness that one 
feature of RPG is that people can extend the language in just about any 
direction they need.

Nathan.



 

----- Original Message ----
From: Jon Paris <Jon.Paris@xxxxxxxxxxxxxx>
To: midrange-l@xxxxxxxxxxxx
Sent: Thursday, September 7, 2006 10:26:01 AM
Subject: RE: Performance of ODBC vs. other access methods 

In PHP the key can be either numeric or associative. RPG does not have

this feature because it requires more CPU than marketing is willing to sell.

True RPG doesn't have it as a single operation - although one could ague
that compile time and run time arrays provide similar load capability.  RPG
doesn't have dynamically sizable arrays and that can be useful and will
probably come at some point.  

RPG requires that you specifically use a lookup operation against a key
array to obtain the element number, that is then used for subsequent access.
This admittedly requires a little more code.  However, to relate the lack of
such features to horsepower is sheer bull excrement.  There is very little
horsepower required to run associative arrays.  

But I know this is a waste of breath - you'll simply change the argument as
usual.

Jon Paris
Partner400

www.Partner400.com