[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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

    Anyone from SLUG have any opinions on this? What about useful
    suggestions?  Can the community of users help Symbolics invent ideas on
    how it can create a viable corporate memory. Users are already part of
    it (since it already acts in that capacity, by responding to slug e-mail
    from users), but how should such a mechanism be instrumented?


I have on perhaps 2 or 3 past occasions run into the same sort of
problem and raised my voice to Symbolics in hopes that it would be heard
just as you have.  I find their response these days to be satisfactory.
There will always be cracks that information will fall into.


	    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?


	    The issues I see are:

	    1. The doc does not reflect the current state of the system.  This is
	    pretty serious.



	    2. Our support people do not know the answers to these questions (sorry,
	    DE).  Unfortunately they don't know everything.  I don't want to sound
	    flippant about this, but people do make mistakes.  We need to limit
	    those mistakes.

	A general problem. If I was callow I would say this is
	apparently in-soluable by Symbolics in our lifetime.

I, for one, don't mind when people make mistakes.  If they don't learn
from their mistakes, well, that's a whole different ball game.  Just
update the documentation for 7.5.

	    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

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

	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.

	    advertise our positions on responding to slug mail (who should answer
	    what). I won't air any of our laundry, dirty or otherwise, but I will
	    say that I think we are trying to address these issues.


	    We are trying to be very responsive to our customers.  We are attempting
	    to make 7.5 be a very high quality release.  I will put these issues on
	    the task list for 7.5.  Please continue to let slug-liaison (and me if
	    you wish) know about any other problems you see, and I will endeavor to
	    solve them.

	Thank you, and I know you are working very hard on all this. My message
	was not to niggle you about your own internal QA business, but to point
	out something as an external user: a company without a good memory cant
	be so smart as it oughta.



	P.S. With you permission I would like to post this reply to slug. Please
	let me know if I can include your comments as they appear above. Thanks.

    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.

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