• Subject: Trusting Vendors??? -Reply
  • From: Scott Cornell <CORNELLS@xxxxxxxxxxxxxxx>
  • Date: Tue, 30 Sep 1997 09:27:25 -0400

>>> "david.gibbs@silvon.com" wrote>>>
>I'm curious as to how many people actually
>TRUST their software 
>package vendors?

Generally, to the extent that I, not the
vendor, am the one who gets the call at
2:00AM when day-end pukes, I wouldn't care
if God himself wrote the package - I'd test
it anyway, if for no other reason than to
familiarize myself with the changes and
their ramifications.

>1. How vigorously do you test your
>application software when you get
>a minor update (less than 10 problems
>fixed)?  Major update / new release?

First, our EDP auditors have really come
down hard on our internal QA process,
leading us to implement a semi-rigourous
system of testing/signoffs just so's we can
avoid having new bodily orifices created at
audit time.  Second, if the update package
is really so minor, we usually hold on to
it until we get 2-3 minors to make a major
- lass hassle to deal w/1 install process
in 6 months rather than 1 evey 2 months. 
Third, our particular vendor has a (IMHO)
really bad quality control process (maybe
even a non-existant one) - we routinely get
objects that don't match source, level
checks (shudder!), etc.  Finally, our
particular packages have transferred
vendors about 3 times in 7 years - much of
the code is still RPGIII w/some very
bizzare techniques that the current
vendor's programmers (and, to be fair, the
same could be said of me too) have never
seen before and can't seem to touch w/o
trashing 3 other important areas.  Soooo,
yup we test EVERYTHING, no matter how

>2. How vigorously do you plan on testing
>your application software for Y2K

We're currently working on proposals to
aquire a seperate AS/400 specifically for
Y2K testing.  Our current thought is to
load the Y2K compliant stuff, IPL w/a date
of Jan 1, 2000 (or, probably better Dec 31,
1999 then go through a routine day end
w/the century change) and then use some
"real good" test scripts to beat the stuff
to death for a week or two.  'Course, as I
keep pointing out to anyone w/in earshot,
the "real good" test scripts better be
really REALLY good w/real good data (not
the messed up crap we have in our
development environment), or the whole
thing is probably for naught.

>3. How vigorously do you test your utility
>software when you get a minor update (less
>than 10 problems fixed)?  Major update? 
>Y2K update?

See 1) above and multiply it by a factor of
2-3.  Our package has a general purpose
library w/things like date routines, menu
drivers and whatnot in it - every system we
own uses these routines, so if they puke,
everything from Payroll to Patient Accounts
to Lab Orders is down - not a pretty sight.

>4. What about HARDWARE vendors???

>5. What about PC software vendors?

Both of these are, IMHO, under empahsized
here.  I think the robustness of the AS/400
has lulled some people to sleep in this
area ("Ahhh, that thing never dies"),
whilst our PC's are the baliwick of a
seperate department which (to give them
credit) has gone a long way towards
standardizing desktops and improving LAN up
time and so on, but still seems to me (from
my outside looking in viewpoint) to be kind
of haphazardly put together.  Not being
part of that team, I can't really comment
what the official policy is toward PC
vendors though.


Scott Cornell
Mercy Information Systems
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to "MIDRANGE-L@midrange.com".
| To unsubscribe from this list send email to MAJORDOMO@midrange.com
|    and specify 'unsubscribe MIDRANGE-L' in the body of your message.
| Questions should be directed to the list owner/operator: david@midrange.com

This thread ...

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2019 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].