[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[JR@YUKON.SCRC.Symbolics.COM: Incremental tape re-use]
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
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
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 email@example.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
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.