<<< EVMS::DOCD$:[NOTES$LIBRARY]SCSI_ARCHITECTURE.NOTE;1 >>> -< SCSI ARCHITECTURE >- ================================================================================ Note 54.5 Problem Statement candidate for SCSI "get well" 5 of 5 EVMS::EVERHART 40 lines 24-OCT-1995 14:41 -< Problem statement after wordsmithing. >- -------------------------------------------------------------------------------- SCSI Subsystem Proactive Maintenance PROBLEM STATEMENT The OpenVMS SCSI subsystem has become difficult to maintain, understand, and extend. These problem areas, which are visible to internal users and to customers, need to be simplified and improved. Specifically, existing SCSI subsystem flaws include the following: 1. No comprehensive written high-level OpenVMS SCSI design or indvidual component designs exist, except the code sources themselves. Although some oral design tradition is available, it is weak and partial---mostly because all the key individuals who originated the oral tradition have left. Most of the SCSI components were implemented with no overall picture of the subsystem at the top level. Therefore, no comprehensive OpenVMS SCSI design exists at all. 2. Without a project design, the SCSI code base has had a long history of changes that have not been implemented consistently. Not surprisingly, component interfaces are not clean or consistent, and information passed by side effects of data manipulations is common. 3. Understanding the complex SCSI code environment makes the process of implementing changes slow, and changes are often fragile when implemented. Some areas of code remain maintainable, but the difficulty of maintenance is growing. These change implementation and maintenance problems sometimes create schedule pressures that result in partial and incomplete fixes for important problems. As a result of these issues, the SCSI group has difficulty making fixes or enhancements to the code base. People new to the SCSI group undergo a long process of code-reading to get up to speed. This steep learning curve sharply reduces the amount of resources available to design, review, or implement code, which means that OpenVMS customers see desired SCSI enhancements slowly or not at all. Most notably, support is delayed for features such as wide SCSI, extra SCSI LUNs, enhancements on disks and tapes, new device types, and commodity SCSI devices. It is also difficult to distribute necessary information to third parties writing new OpenVMS SCSI class drivers or to provide quick responses to the customer problem report backlog.