[JR@YUKON.SCRC.Symbolics.COM: Incremental tape re-use]

[Johanna Rothman <JR@YUKON.SCRC.SYMBOLICS.COM>]

    Date: Wed, 9 Aug 89 08:31 PDT
    From: Mr. Spock <Spock@SAMSON.CADR.DIALNET.SYMBOLICS.COM>

	Date: Wed, 9 Aug 89 01:02 EDT
	From: pan@Athena.Pangaro.Dialnet.Symbolics.Com (Paul Pangaro)

	[...]

		The Truth as I know it:

		1. 36xx tape drives don't support appending to tape.  They are not
		physically capable of it.

    This is something I don't understand.  How can a tape drive be
    physically incapable of appending?

36xx machines have streaming cart drives.  The actual problem is that
the tape cannot space backwards.  To append, you must space forward
until you find the end-of-tape (two consecutive filemarks), reverse
space past the second filemark, and then write your data.  QIC-11 drives
cannot space in reverse.  You can append after the second file mark, but
then there is no way to know where the end of tape is.

		3. I have to assume this is not an isolated incident, but to be honest,
		I don't know of any others.  I'm sure DE and Reza will let me know if
		there are others.

    The notorious 3600 IFU is another similar issue.  We had to educate our
    local support people on the seriousness of the problem after we found
    out about it.  There isn't any documentation that I know of on this
    (internal or otherwise).  But, I have been assured that Symbolics is
    aware of the problem (a race condition on the IFU) and is working on it.

	    See my above comment, and consider that ignorance is ignorance in this
	    case, not evidence that life is really ok.

    Yes, ignorance is definitely ignorance.

		4. The real problem here is that a customer sent bug mail to the slug
		mailing list.  Then, one of our support, but not software support people
		sent an answer that was not completely correct.  Either we should have
		not answered the question, or we should have redirected the mail to
		customer-reports.

    Please, please, please don't opt for unresponsiveness.

Sorry, I didn't mean that we should be unresponsive, I meant we should
use the proper channels for answering bug reports, for us to answer them
at all.

Some people don't buy software support, and use the SLUG mailing list as
a way to get support.  That's fine with me.  But, if we as a corporate 
entity feel we should answer a bug report, we should do it in the approved
manner, i.e. redirect the bug mail to customer-reports.

	    Yes, and I realize SLUG generally gets added value from answers given on
	    e-mail, and 1gratis0. Controlling information flow has improved (i.e.,
	    become more controlled and hence more consistent and maybe, in general,
	    I find more reliable). This is an internal policy issue. I think it is
	    the case that e-mail coming from foo@xxx.symbolics.com will be
	    taken as correct.

		There are any number of things Symbolics should do about this.  Hiring
		more developers, writers and SQA people are a good first step, to see
		that the problems don't creep/continue in the system.  Then, we need to

	    So far as QA on documentation, maybe, that is your province; so far as
	    the corporate memory goes, no, no, no and again no. This is the old,
	    "throw more resources at it" solution, which, lets face it, aint gonna
	    happen and aint gonna improve the situation anyway. Lets get someone
	    with a concept, an epistemology even, of the corporate needs of
	    corporate memory, and do something to address that problem.

    I agree with Paul here.  This is a methodology issue not a resource issue.

Ok.  Let me paraphrase what I think you want: If you ask any product
questions, send bug mail, request product features, etc., and a
Symbolics employee answers the mail, you want to assume that the answer
is correct.  That's an eminently reasonable request.  That means we have
to determine that all mail sent to SLUG on behalf of Symbolics is
correct.  

Unfortunately, the only ways I can see to do this are to either restrict
access to SLUG or to have every message proof-read before the message is
sent.  The first alternative is against everything an open system stands
for, and the second alternative introduces delays.  Is there an
alternative I haven't mentioned?

	If you feel there is something to be gained, sure.  If you have
	suggestions about this issue, I sure would like to hear them.

    How about an object-oriented, knowledge-based, neural-networked
    corporate memory?  This is the company with the leading AI technology,
    isn't it?  I would assume that Symbolics tracks all Symbolics-related
    information (electronic and paper).  What happens to these bits?  Do
    they just get archived?  Is SLUG mail a part of the QA process?  If not,
    why not?  It's a good feedback loop.

The information comes in a variety of sources.  Bug mail gets tracked by
developers.  Some bug mail gets tracked by SQA.  I track the SLUG mail
that looks appropriate to SQA.  We have a slug-liaison who tracks mail 
for other parts of the company.

    Thanks for your openness.  It is appreciated.
    --Mark Alexander