Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!natinst!sequoia!uudell!pensoft!robin
From: robin@pensoft.UUCP (Robin Wilson)
Newsgroups: comp.unix.aix
Subject: Re: Making A request to IBM (Was: Re: How does one compile to assembly?)
Message-ID: <3299@pensoft.UUCP>
Date: 20 Mar 91 14:33:31 GMT
References: <96@softpro.stgt.sub.org> <1296@dkunix9.dk.oracle.com> <1991Mar15.123532.8036@odi.com>
Organization: Pencom Software, Austin, TX
Lines: 45

In article <1991Mar15.123532.8036@odi.com> benson@odi.com (Benson I. Margulies) writes:
>Further, the developer can decide that your problem, while a bug, is a
>"permanent restriction," (i.e., too hard to fix) and decline to fix
                                 ^^^^^^^^^^^^^^^
>it, ever. This is what happened to me when I reported that AIX dbx,
>unlike any other, can't trace the stack below a sigaction-established
>SIGSEGV handler.

Well, here is the REAL story from someone who works inside of the system.
I used to work at IBM Level 2 Defect support for AIX version 3.  I now 
work at IBM Level 3 (also called, "the change team") RT Defect support
(AIX version 2.2.1).  To start with, a "permanent restriction" (PRS) isn't 
really just a problem that is "too hard to fix".  Actually, a permanent
restriction closing means 1 (or more) of several criteria were met:
1) the problem is isolated to a specific type of application, that is 
   not widely used, AND the problem can be worked around through some
   other method (other than a code change), AND the fix for this problem
   would take a significant code re-write to fix.  (The reason a 
   "significant code re-write" is required to make a PRS closing is to
   prevent a developer from just saying, "that's too hard, I don't want to
   fix it".  The reason this is justified is because a "significant code
   re-write" may cause other "un-forseen" problems, and could seriously
   impact other customers who depend on that program.)
2) Making the requested fix would put AIX in a position to be "out-of-
   specification" from either our published specifications, or the published
   standard for a given program.
3) The requested fix is in reality a "design change" but the design was clearly
   flawed in the first place.  (This is the "greyest" area of a PRS, but it
   serves a definite purpose.  The PRS closing code indicates that IBM has
   evaulated the code AND found it to be defective, but chose not to drop a
   fix at this time.  So calling something a PRS really means that IBM has
   acknowledged a "bug" in the code.)
4) The code is already being re-written for the next release, and spending
   significant "man-hours" making a major change would consitute a 
   serious duplication of effort.

In all cases, the programmer that decides to make a PRS closing is 
required to get 4th line manager approval before the closing is accepted.
This assures that IBM management has reviewed the problem and is aware of
the impact to customers.  BTW, the Level 2 representative is your (the 
customer) advocate in these proceedings, but once the "change-team" has 
decided to close the problem, Level 2 has no say in the matter anymore.

I will provide a complete description of the IBM software support process
in another post...  Coming soon to a news reader near you....