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



I appreciate your candor Joe. I'm starting to suspect something along the same lines. When the Rochester folks starting pointing at our applications (which haven't changed), I know they are grasping at straws. There must be something going on. I'm hoping to get some other input from other 570 users.

Joe Pluta wrote:

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



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

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.