Re: Number of problems by platform (was: DB2/400 comparisons with oth errelational databases (specifically Oracle and SQL Server))

You've kind of hit that one on the head.  Development versus production.
On one major SQL issue, IF we had done some extensive testing on our
development machine then we should have discovered this months earlier.
However, when we upgraded several production machines that weekend and
noticed the problem on all of them, and then duplicated that on
development, and had the same situation work successfully on a V4R5
machine, then yes, we discovered better testing was in order.  And you know
what, even with all that duplication effort, and IBM able to duplicate it
in the lab, they still forced us to open a consult line contract.  All that
person did was duplicate it, physically walk over to developments office
and slap them silly.

This resulted in a meeting with myself, some key department members and our
VP of IS on what needs to be done to perform better testing on new
releases.

Rob Berendt

==================
A smart person learns from their mistakes,
but a wise person learns from OTHER peoples mistakes.



                    Buck Calabro
                    <Buck.Calabro@comms       To:     midrange-l@midrange.com
                    oft.net>                  cc:
                    Sent by:                  Fax to:
                    midrange-l-admin@mi       Subject:     Number of problems 
by platform (was: DB2/400 comparisons
                    drange.com                 with oth    er relational 
databases (specifically Oracle and SQL
                                               Server))

                    09/28/2001 10:18 AM
                    Please respond to
                    midrange-l






>> 1)  I don't take grief.  I see a problem - I report it.
>> 2)  Maybe we push the envelope a little harder.  More data, different
>> applications, more sql.
>
>I don't take grief, either.  I just don't seem to run into the
>problems you do.  And I was the Manager of Architecture for the
>world's largest AS/400 software company - we pushed the
>envelope, too.  BPCS, AS/SET and AS/NET definitely used some
>of the more advanced features of the AS/400, but that was a while ago.

I spent 17 years with a local wholesale paper distributor.  We opened
several APARs over those years (multiple midrange platforms.)  Now that I
work for a software developer, I have never had to open an APAR _here_.  I
have had customers open APARS because something that worked fine here did
not work out there.

This incredibly sophisticated analysis <grin> would seem to indicate that
the larger the operation is, the more chances there are to run into an
unexpected situation.  The developers simply don't have that large and
diverse a database that gets hammered 24x7.  My experience with customer
support bears this out as well.  Our small clients rarely report problems
with our software and almost never with IBM software.  The big ones manage
to find something with every release; some bugs are years old but haven't
surfaced until the right combination of drivers, data and storage
conditions
were met.  It's the big customers who find the PTFable situations, too.

Some of this is because the client is back-level on OS/400 or on PTFs, but
some of it is because it's an IBM bug that takes precise circumstances to
materialise.

My thought for the month.  Good thing, too - I was afraid I wasn't going to
have one at all this month!
  --buck
_______________________________________________
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@midrange.com
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l
or email: MIDRANGE-L-request@midrange.com
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.