Upgrade????? Was: Why does this fail?

[John F Haugh II]

In article <1991Jun11.120248.18730 at bellcore.bellcore.com> jona at iscp.Bellcore.COM (Jon Alperin) writes:
>In article <19371 at rpp386.cactus.org>, jfh at rpp386.cactus.org (John F Haugh II) writes:
>|> By the way - you should always mention version number.  The answer
>|> to many problems may be as simple as "Upgrade to the newest level",
>|> but without that level information there is no way to make that
>|> determination.
>
>  I think you are trivializing the case. I have well over 100 machines, and
>often cannot upgrade to the next release of a whim. It takes planning and
>coordination (not to mention time and patience) to upgrade all these machines.
>I for one, still want the fix to the problem I reported, not an additional
>week of work to fix a "bug". Your answer is not only trivial, it may be 
>impossible for some people to do easily.

Not to sound confrontational (it really is hard to sound otherwise ;-),
but if you don't provide a version and release and so on, the problem
determination part of Software Support may be next to impossible.  Even
in the case of providing a single bug fix, without the version number
the developer has no way of knowing what level of code you are going to
need a fix for.

By way of anecdotal evidence, a major chip manufacturer that uses IBM
mainframes running AIX as their development platform recently requested
a fix for an APAR for their system.  They too couldn't upgrade on a
moments notice and informed me that their next chance to shutdown and
upgrade was some time in July.  I went ahead and sent them the kernel
module they required, not knowing their exact software level.  The
module turned out to be at the wrong level, wasting several hours of
my time, the customer's support persons time, and countless user-hours
at the customer's site.  The solution was very simple - find out the
correct level and let the LCC person responsible for the account build
the module for that exact level.  The problem was fixed the first time
out and the customer was very satisfied.

The moral of this story is that if you tell me what version of code
you are running, I can work all manner of miracles.  If you don't,
not only will you waste my time, but I will manage to waste a lot of
yours asking needless questions, starting with, what version are you
running?

>p.s. I do agree, however, that people should include the release they are
>encountering problems on. 

So, why the disagreement?

>p.p.s. Now that I think about it, I do have one gripe with these fixes.
>Why does AIX Defect Support always want me to reboot a machine after
>applying a fix. Don't they realize that people can just enter the commands
>from the .rc files and apply most of the fixes without having to get
>everyone to log off and then reboot a machine? If IBM is serious about
>supporting distributed computing, then they better realize that rebooting
>machines to apply fixes is not the way to go.
>(just wanted to get my two sense in...) 

Some fixes require you to reboot the system.  Generally speaking it is
best to reboot since that insures that everything is working correctly
and will continue to work correctly the next time you try to reboot.
Given IBM's conservative approach to software support, it is natural for
them to take the safest course of action.
-- 
John F. Haugh II        | Distribution to  | UUCP: ...!cs.utexas.edu!rpp386!jfh
Ma Bell: (512) 255-8251 | GEnie PROHIBITED :-) |  Domain: jfh at rpp386.cactus.org
"If liberals interpreted the 2nd Amendment the same way they interpret the
 rest of the Constitution, gun ownership would be mandatory."