Gavin Scott ([log in to unmask]) wrote

>[log in to unmask] writes:
>> [...] even though to any sane person it is clear that what was produced
>> is unacceptable under all conditions.

>Since you've just said that Stan and I (who were involved with the Large
>Files design project) are insane, along with many people at HP whom I
>greatly respect, I must take exception to your statements.

That a value returned cannot be used is clearly erroneous.  When this point
was raised with the lab it was ignored.  (AIFFILELGET, 4010).

That said value can work flawlessly, in some cases 100% of the time, is a
sign of a bad design.

That a function to do A=B+x, was supplied, and not, x=A-B, is unexplainable.
When this was mentioned to the lab, was summarily ignored.  I cannot even
call
it dismissed, because that implies too much attention.

>> That management allowed a design and implementation that consistently,
>> knowingly, produces inconsistent results, would in some cultures result
>> in such "loss of face" as to have the problem be "self remediating".

>Now you're suggesting that all the CSY engineers commit ritual suicide
>because you can't figure out how to use large files?

It is not that I cannot figure out how to use large files.  That is not the
point.  With the new LARGE file intrinsics, code can be written that works
all
of the time on one machine and will not work on another.  The lab knows
this.
The call to get the FAR pointer for an open file only exists with 6.5.  Is
it not
reasonable to assume that it was added so that it may be used?  If it should
not
and cannot be used, why return it?  This one point is the clearest example.
These
and other issues were raised with the lab, and all of them were absolutely
discarded.
The point is that when these issues were raised, they were ignored for
reasons that
escape all logic.  To say that I was frustrated to the point of being
apoplectic is
to miss the point.  The point is that here are clear examples of a desire to
simply
get something out the door, without paying attention to proper design and
impact.
It makes the point of what is important to HP.  Good design and
implementation,
and its effects were not part of the equation.  When these bugs were noted
to the
lab, they refused to hear any of what was being communicated, either from me
or
from the HP support engineer on the call.


>> The human resources allocated to the MPE development are unskilled.

>So we're all blithering idiots because you can't make it work.  Hmmm.

See prior comment.

>Perhaps if you would describe in more specific detail what you are trying
to
>do and what it is that you think is not working, then maybe we can see
>exactly where the problem is.

See prior comment.


Also, Gavin, it might be helpful if you would read Jerry Fochtmans comments
as well.
He experienced the same level of support from the lab ;-), as I did.  The
point is
that we should not have to hit them over the head with a sledge hammer to
get their
attention.  That it does, and repeatedly so, is not the effect of an
individual, but
the effect of the goals of management, which is what my original point was.
Management
determines what is an appropriate response.  This is the job of management.
This is
their function.  After reading Jerry Fochtmans comments, I believe that what
is
more likely is that nothing but triage is really going on at the lab.  Those
that scream
the loudest get attended to.  Those that do not, get ignored.  If I am
correct then it is
not a sound corporate strategy.  If I am correct, then it speaks even louder
to the overall
tone of the comments posted here that the MPE is being ignored by HP.  Were
appropriate
levels of commitment forthcoming from HP to the MPE, then the lab would not
be using
triage as a basic tactic with us, and would have available the resources to
do the job
at hand.

Ken Graham.