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
to the existing base. If a consistent design existed for the full current
code base, one could document it and improve maintainability and extensibility
in this way. However, documenting the current code base would only codify
the inconsistencies whose presence demonstrates that a coherent top level
picture cannot be drawn using only the current code base. A coherent top
level picture of the code base must go beyond what is there now if only
to eliminate inconsistencies.

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. This approach also would be most vulnerable to
the continual flood of new SCSI implementations from vendor devices. To
the extent current code had to be patched to handle these, a from scratch
approach would accumulate a larger number of to-be-addressed issues which
would have to be handled before deployment than other approaches, which
involve less of a delay before first code.

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
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. (Note: choice
of the projects can overlap the document completion, considering that
much work on a high level document has been done already.)

The overall result will be a SCSI documentation set covering high level
design principles, selected areas of SCSI which need work most, and
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
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 in principle be greater than a "clean sweep"
rework due to need to keep un-updated components working. (You don't need
to write glue code in a clean sweep approach.)

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.


		Resources Available

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.