Making A request to IBM

Robin Wilson robin at pensoft.uucp
Thu Apr 4 00:46:28 AEST 1991


In article <1991Apr1.135433.26762 at bellcore.bellcore.com> jona at iscp.Bellcore.COM (Jon Alperin) writes:
>1. When a person is designing a software product that executes under a
>specific OS level, it is often unacceptable to tell a client to upgrade
>an entire system  to fix an AIX bug which is underlying your code. It is
>much simpler to convince them to "simply apply patch XXXX".

Clearly the best answer is to design software to work with the entire system.
You will always be expected to "update" your machine to the latest level when
you receive a patch.  This is due to the fact that software is dynamic, not
static.  It is constantly evolving, and you certainly don't want to limit
your application to working on out-of-date system software.

>2. When supporting multiple users doing software developement, it is
>often necessary to apply a patch to solve a single users problem. However,
>when multiple fixes are provided in a patch, its hard to tell users what has
>been fixed or upgraded.

Actually, you can select individual lpps to update.  So the only really "big"
lpp is the "BOS" (Base Operating System).  The update procedure provides you
with some level of control over the update, but most importantly, if your
code doesn't work with the "latest and greatest" how are you going to hold
your customers back to the "old" level that you used to used?  You really 
need to make your software work with the current version of th system 
software.

>3. If IBM is going to provide multiple fixes, then they should be just that...
>fixes. No new code should be in those non-mandatory releases. I am not sure
>if IBM is doing this, but I figured that I would stay up here on the soapbox
>just a little longer.

Most of the time, IBM gets beat up for just the opposite argument:

"The 'design' was flawed, so my design change should be implemented right now!"

Your very argument is why IBM trys so hard to avoid putting 'design' fixes into
the APAR process.  They don't want to break things that aren't already broken.
Sometimes, it is just plain required... times change.. people expect new things.But by-and-large IBM avoids adding "enhancements" to the current release.


+-----------------------------------------------------------------------------+
|The views expressed herein, are the sole responsibility of the typist at hand|
+-----------------------------------------------------------------------------+
|UUCP:     pensoft!robin                                                      |
|USNail:   701 Canyon Bend Dr.                                                |
|          Pflugerville, TX  78660                                            |
|          Home: (512)251-6889      Work: (512)343-1111                       |
+-----------------------------------------------------------------------------+



More information about the Comp.unix.aix mailing list