RE: Performance Issues on 570 -- MIDRANGE-L

> From: Nelson Smith
> 
> The one question I have not been able to get a straight answer out of
> any of these engineers, and the reason for this post, is what has been
> the experience of other recent converts to the 570?  Or, what has been
> the experience of other upgraders from V5R2 to V5R3? Particularly in
> relation to long-running batch jobs.  I can't think of anything unique
> in what we are running.  We have very little, if any, embedded SQL.
> That's the only thing I've seen any complaints about on this list.
Has
> anyone else going to a 570 experienced any sort of major slowdown?  At
> this point, we are willing to look at anything.

I am about to do something I NEVER like to do.  Ever.  The act in
question is to forward any unsubstantiated information about a problem.
I hate saying things like "I heard from someone that the RPG compiler
sends out Martian death rays."  Obviously, without any corroboration,
such talk is little more than rumor mongering.

However, circumstances dictate that I at least share what I have heard
unofficially.  Nelson, you are not the first person to indicate that,
especially on high end machines with the large databases, performance
has taken a significant hit from V5R2 to V5R3.  Lots of theories have
been presented to account for this alleged performance bottleneck.
There is a particularly pernicious rumor wafting about that so much
attention has been paid to SQL that the database engine actually
performs worse on native I/O than in the previous release.

I don't know if this is the case.  I certainly don't have the sort of
machine that even holds a candle to a 570, and I don't have access to
one going through an upgrade.  However, if there is anyone getting ready
to move from V5R2 to V5R3, I think it would benefit the community
greatly to take some serious before and after performance snapshots.

And if it turns out that native I/O performance has suffered, then I
believe a great hue and cry should be raised.  I don't mind IBM spending
a ton of dollars on SQL; that's their own business.  But damaging the
performance of existing applications, especially in the light of IBM's
more Draconian OS/400 upgrade policies, is simply unacceptable.

It's possible that we're coming to some sort of juncture where
architecture forces decisions that trade off between SQL and native I/O
performace.  If that's true and it comes down to a choice between better
performing SQL and better performing native I/O, I would argue that
reducing a unique strength of the box in favor of giving it a little
extra performance in an area already loaded with competition is a poor
business decision.

Joe

I find it hard to believe that there's really a situation where one has
to choose between better performing SQL and better performing native
I/O.  Any competent system architect would be able to make the two data
access methods work synergistically (just as they have been doing for
the past decade or two).