From:	STAR::S_SOMMER     "Sue Sommer ZKO3-4/U14 381-0316" 29-OCT-1995 11:45:26.59
To:	US2RMC::"EVERHART@gce.mv.com"
CC:	S_SOMMER,EVERHART
Subj:	RE: Approach DRAFT. Comments? (I'm working @home this pm)

Glenn,

After procrastinating all day yesterday about sitting down to take a stab
at capturing Thursday's meeting as I said I would, I've just now logged in
for the first time this weekend and have found your message.  It looks *very*
good from my point of view.  Rather than my writing anything on the same
topic from scratch, it seems better to me at this point to put in a few
responses to what you've already laid out quite well:

From:	US2RMC::"EVERHART@gce.mv.com" 28-OCT-1995 04:54:48.58
To:	star::s_sommer
CC:	
Subj:	Approach DRAFT. Comments? (I'm working @home this pm)

SCSI Proactive Maintenance

Approach:

Rejected approaches:

The first approach to dealing with SCSI system maintainability problems
was to simply document the existing SCSI code base as is. This was
rejected because in the opinion of the SCSI group, the existing code base
lacks a consistent and comprehensive design to document. Some parts of
the base do have such designs, but there is no overall principle which
ensures they are mutually consistent. This precludes complete limitation

>>>Could you just clarify the phrase 'precludes complete limitation'?
>>>Also, maybe something could be worked into this paragraph about how
>>>this approach fails to address the 3 major concerns (documentation,
>>>maintainability, extensibility) raised by the Problem Statement.

to the existing base.

The second approach is an opposite of the first, namely to rewrite the
entire SCSI subsystem to a new and unconstrained design. While the
process of creating such a thing can produce a complete document set and
drivers consistent with it, and would cause third party impact only once,
it provides no benefit for a long time. New functionality would be
delayed and the current code base would all have to be maintained as is
for the full development period, with no short term reduction in the
effort needed to do this.

>>>Also, my biggest concern with this approach is its possibility (if
>>>not probability) of generating a larger set of new problems.  SCSI
>>>is more vulnerable to rewrites (in my opinion anyhow) than most 
>>>other OpenVMS components, because there is such a large and
>>>inconsistent variety of implementations by third-party vendors to
>>>be accommodated.  No matter how good the design/implementation, some
>>>vendors are likely to be broken by newness.	 

Selected approach:

The selected approach is a hybrid. It begins with a high level design
document which is broad but not deep in details, which has rules of thumb
for handling known SCSI issues, but little specific internals
information. This document represents a complete vision of what the best
way to implement SCSI on VMS is, subject to the constraint that it be
possible to implement incrementally. It must, finally, contain external
interface descriptions and data descriptions in a high-level form.

Once the high level document has these data and interface descriptions, a
second document will be begun. It will choose a number of areas of

>>>Just a logistical consideration here.  I agree that the list-of-projects
>>>document should be a separate document.  But I'm also thinking about
>>>Pat's comment on Thursday that the separate document sounds like it
>>>could be exactly the Project Plan.  *If* we decide to do it that way,
>>>then we would probably rearrange the Proj Plan dates.  Maybe set both
>>>the high-level doc and Proj Plan deadlines for end of Jan?  But have
>>>enough of a sense of the "top 6" by end of Dec to allow LOPs to begin
>>>in early January?  I'm sort of thinking out loud here...but my main
>>>point is, I think we may miss 7.2 if we wait until after the initial
>>>document is absolutely complete to start identifying projects.  It'd
>>>be nice to plan some sort of overlap instead.

investigation, based on CLDs, QARs, and other maintenance experience and
based on the interface descriptions. Approximately 6 such areas will be
chosen. These areas will then be subjects of subsidiary projects whose
objectives will be to rework those areas so they are consistent with the
high level documentation and to document the design of the areas reworked
for the future. The scope of this project will be deemed satisfied once
these projects are also done, though it is expected that future SCSI work
will reflect, and be reflected in, the high level document. 

>>>Just a question about the phrase 'be reflected in' -- does that suggest
>>>the initial document will be revisited?

The overall result will be a SCSI documentation set covering high level
design principles, selected areas of SCSI which need work most, and

>>>Again, just another question of clarity:  it's clear that this commits
>>>to delivering "SCSI documentation" and "reworked code," but it's less
>>>clear what "selected areas" means...is this the proposal that we will
>>>be delivering detailed design specs over time?

reworked code for the "worst problem" areas in the system (plus glue as
needed so that the rest of the SCSI subsystem will continue to work).

This approach has the advantages that all work will have a top level
design available. Some areas will be reworked for each new VMS release,
and customer impact will be localized to change areas, and made minimal
in any case due to the constraint that it be possible to use existing
code along with the new.

The major theoretical drawback to this approach is that the constraint on
high level design could preclude some conceptual breakthrough. Since the
group has sought such and not found it, though, the risk of this is

>>>By the way, it occurs to me that prior to this section of the Investigation
>>>report, it might be a good idea to have some paragraph describing
>>>"methodology used to do the investigation", or something like that,
>>>where you could mention the combination of notesfiles/group discussions/
>>>investigations/QAR & CLD analysis that have been done so far.  

small. More practically, the SCSI code in this approach may never fully
match the design, though it will approach it, and the time to overhaul
every bit of the system may be greater than a "clean sweep" rework.

>>>Maybe some more clarity around that last phrase above?  Also
>>>around the next sentence to follow:

In practice, some parts of the SCSI system might never need to be
updated, so the overall time issue may be a red herring. At any rate,
feature enhancements and fixes are needed sooner than a clean sweep
approach could deliver them.

>>>Maybe replace the phrase 'clean sweep' with something like 'total rewrite'
>>>so that it's clear you're referring to the extreme approach?

>>>The following paragraph seems to digress a bit from the original topic
>>>of "why we chose this" and gets into resource estimates -- maybe that
>>>should be a separate chapter (or set of paragraphs) in the report.
>>>The very last sentence (about committing to 7.2 deliverables) does
>>>relate to why we've chosen this alternative, so maybe that could be
>>>woven into the justification section above.  Other than that, maybe just
>>>leave the rest of it to some "resource estimate" chapter.

Resources available for writing these documents are considerable. There
exist design documents for parts of some of the drivers which, while out
of date and incomplete reflect parts of the designs. Also a top level
design document exists and much detail was assembled in connection with
deriving a new SCSI architecture. While it has not described interfaces
or data structures in detail, it does describe some general features and
satisfies the constraint on incremental implementability. Group members 
have also listed numbers of areas needing improvement in the past. Since
there is considerable overlap in these problem areas, selection of a few
top candidates should be straightforward. The entire project should be
possible to get to beginning its subordinate projects by the end of
1995 so that some new code can be in place for the projected VMS 7.2
release.

>>>Overall, this looks like it's really taking shape.  Does it still feel as
though the Nov 10 deadline is realistic?  It occurred to me that if necessary
we might consider scheduling a couple of extra (and optional?) meetings
this wed/Fri/and/or Mon to keep it on track.  Rick mentioned he thought a
couple of folks were less interested in this phase, and maybe it's okay
to have a sub-team working on this.  Also, the Tues Nov 7 mtg is mostly 
reserved for our monthly team mtg with Ken, right?  It'd be nice to have
a real good handle on the basic chapter headings and content of the report
by that Nov 7 mtg, since the rest of the week will fly by.
I'll be in class tomorrow and Tuesday, but available to do stuff early AM
as well as Monday evening (forget Halloween though!).  Let me know if there's
anything you want to me do specifically, otherwise I'll talk to you tomorrow --

Sue



% ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ======
% Received: from crl.dec.com by us2rmc.zko.dec.com (5.65/rmc-22feb94) id AA03874; Fri, 27 Oct 95 15:44:06 -040
% Received: by crl.dec.com; id AA13354; Fri, 27 Oct 95 14:56:13 -0400
% Date: Fri, 27 Oct 1995 14:54:48 -0400 (EDT)
% From: EVERHART@gce.mv.com
% To: star::s_sommer
% Message-Id: <951027145448.d8@gce.mv.com>
% Subject: Approach DRAFT. Comments? (I'm working @home this pm)