[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?


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)


		    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


    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

	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.


	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

    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.


	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.