From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.5-pre1 (2020-06-20) on
	ip-172-31-74-118.ec2.internal
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=3.0 tests=BAYES_00 autolearn=ham
	autolearn_force=no version=3.4.5-pre1
Date: Sat, 5 Jun 1993 06:28 EDT
From: SAHARBAUGH@ROO.FIT.EDU
Subject: Re: Meridian and Ada (not ADA)
Message-ID: <9306051038.AA19983@ajpo.sei.cmu.edu>
List-Id: <comp.lang.ada>

Robert Dewar writes:
Of course no vendor
can spend time finding bugs in arbitrary user programs

To get vendors attention I have often (sigh!) used this technique.
Blow away portions of your program until it works, then
put back portions until it no longer works.  Apply this
technique recursively until the offending source code
is "obvious".  Another parameter is that it fit on a one
page fax.  A fax may get more attention than e-mail because
it will be seen (and immediately understood) by the people
handling the one page of paper on its way to the proper
person to handle the problem.

If that fails carry the one page to the next trade show, go
to their booth, type in the program (when there is a good
crowd around) and leave the source code and the error
messages on the screen.  [here comes an old story] In the
old days when people didn't know how to do arithmetic
on binary machines, when I visited trade shows I would
type in a small program that computed "e" for progressively
more accurate approximations.  Some vendors systems would
converge nicely to the right answer (2.7 something), some would
oscillate and never converge, some would diverge etc.  After
a year or so I was prevented from touching the terminals in
some booths the excuse being that I my method was not a valid
way to compute "e".

The point is don't ask the vendor to understand your program,
ask them only to understand their problem.
sam harbaugh SAHARBAUGH@ROO.FIT.EDU