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

["Mr. Spock" <Spock%samson.cadr.dialnet.symbolics.com@RELAY.CS.NET>]

    Date: Thu, 10 Aug 89 10:41 EDT
    From: 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.

OK.  I see your point.  I hadn't thought about the unsupported masses.

		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?

Yes.  A disclaimer on messages sent from Symbolics employees to SLUG.
Nothing lengthy.  Just a short, sweet, "This is only my opinion, not
Symbolics' policy." statement.

	    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.

OK, but my point is:  Is there a way that Symbolics can assimilate and
centralize this information so that it can be used for future reference.
And I'm not only referring to e-mail but internally generated
information as well.

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