[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[JR@YUKON.SCRC.Symbolics.COM: Incremental tape re-use]
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?
PANgaro
****************************************************************
Date: Mon, 7 Aug 89 16:34 EDT
From: Johanna Rothman <JR@YUKON.SCRC.Symbolics.COM>
Subject: Incremental tape re-use
To: pan@Athena.Pangaro.Dialnet.Symbolics.Com, JR@YUKON.SCRC.Symbolics.COM,
DE@PHOENIX.SCH.Symbolics.COM, slug-liaison@RIVERSIDE.SCRC.Symbolics.COM
In-Reply-To: <19890729000716.7.PAN@Athena.Pangaro.Dialnet.Symbolics.Com>
Date: Fri, 28 Jul 89 20:07 EDT
From: Paul Pangaro <pan@Athena.Pangaro.Dialnet.Symbolics.Com>
Date: Fri, 28 Jul 89 09:41 EDT
From: Johanna Rothman <JR@YUKON.SCRC.Symbolics.COM>
[Bug-tape, bug-doc, customer-reports removed.]
Date: Tue, 25 Jul 89 11:31 EDT
From: Paul Pangaro <pan@Athena.Pangaro.Dialnet.Symbolics.Com>
Date: Mon, 24 Jul 89 14:59 PDT
From: DE@PHOENIX.SCH.Symbolics.COM (Doug Evans)
Date: Mon, 24 Jul 89 15:23 CDT
From: dmitchell@backus.trc.amoco.com (Donald H. Mitchell)
WARNING: NEW USER QUESTION--
I have a low volume of file changes on my lonely Symbolics and wanted to
minimize tape storage; therefore, I tried using the "leave" value for
the "tape when done" field on the incremental backup thinking that I
should be able to append the next backup at the end of the previous one.
Well, two or three cold boots later, I tried doing an incremental backup
and got the warning that doing so would be hazardous to my tape's life.
Did I miss something or should I infer that "leave" is very temporary?
Is there anyway to do more than one backup to the same tape?
[Added Bug-Tape and Bug-Doc]
This looks like another small but important piece of information that
fell thru the cracks.
[...]
[Bug-Tape: Is either of these things still true? ... or have they been
patched in some way?]
[Bug-Doc: I can't find any references to either of these items in the
on-line doc. I thought that the caution about no appends on cart tapes
was documented.]
[...]
Friends: This has been an outstanding problem since Release 4.5. I dont
want to be niggling but is there something to be learned here (at last)?
Given all the attrition at Symbolics and losses to corporate memory, can
it still be determined why/how this continues to be an issue? [I suspect
paper doc had something at some point, but on-line does not, or at least
it is not indexed properly.] This is a serious request for a report on
the detailed history, for all our sakes. This is a real symptom --- are
there analogous illnesses from which the patient (read: user) does not
survive?
Best,
PANgaro
Johanna: I appreciate your lengthy comments, but I seem not to have made
myself clear. New annotations below.
I've done some looking into this Paul, but I don't see the same
problem(s) you do. I see different ones. After you read this, let me
know what you think the issues are.
The Truth as I know it:
1. 36xx tape drives don't support appending to tape. They are not
physically capable of it.
Fine, great, no problem. Why doesn't the documentation say so? Since
1984, it can't get said? Since 1984, the corporation cant absorb even so
definitive and unambiguous a fact, such that the world can be told? That
is my point, the reason for my initial reply.
So, although I appreciate your research, the research I was referring to
was, how can such information get so lost, so as to not appear to the
user. This is 1not0 an isolated incident, since you or I or anyone can
analogize to other, known problems, defined as "The left hand doesnt
know what the right hand is doing." Ask me sometime how many times, in
my own experience on this very machine, I have had a new backplane
installed by my CE when the (better) answer was, "Oh yes, the
corporation remembers that problem, and the simple solution will take 5
minuters...."
2. MacIvory/XL400 tape drives physically support appending to tape. We
have not implemented this feature, even though it looks like the doc
thinks we have. We have reasons, which depending on your viewpoint are
good or bad. We are trying very hard not to introduce incompatibilities
betwee 7.2 and 7.4I, so allowing MacIvory and XL400 drives to append,
while not allowing it on 36xx machines looks like capricious
incompatibility to our customers. We also decided that given our time
constraints, this was not on the top of the list of things to do.
Fine, all well reasoned, as I know to expect from you, on the micro
level. Macro-wise, where does this information go? Into folks who, when
laid off or ticked off, leave with the information corporated
information storage device, their brains?
The issues I see are:
1. The doc does not reflect the current state of the system. This is
pretty serious.
Agreed.
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.
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.
See my above comment, and consider that ignorance is ignorance in this
case, not evidence that life is really ok.
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.
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.
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.
Understood.
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.
Best,
PANgaro
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.