4-21-89 X3T9.2/89-53 Thomas Wicklund Ciprico, Inc. 2955 Xenium Lane Plymouth, MN 55441 612-559-2034 SCSI-2 R8 comments: Target routines: Target routines are described very briefly in sections 5.6.7 (IDENTIFY message) and section 7.1.1.3. As far as I can tell, the only thing a target routine can do is return INQUIRY data about the target independent of logical units and report sense data from errors when trying to get INQUIRY data. Target routines seem very incompletely defined. I see the following problems: - For INQUIRY data, a target routine has no Peripheral Device Type. Since a target routine is independent of the logical unit, it can't be the type of any logical unit, and the target routine won't accept the commands of any pre-defined Peripheral Device Type. Therefore, the the first byte of Inquiry is undefined. - If a target routine truely talks directly to the target, commands such as SEND DIAGNOSTIC, RECEIVE DIAGNOSTIC RESULTS, WRITE BUFFER, and READ BUFFER seem like they should be allowed. - There's no reason given for more than one target routine. Only one is required to return INQUIRY data. Personally, I think target routines should be removed from the standard as they don't add any functionality. If they aren't ignored in implementations, they will either be minimally implemented and become an orphan feature or result in a wide variety of divergent implementations which will come back to haunt SCSI-3. Page 5-31, section 5.6.22, TERMINATE I/O PROCESS: The 6th paragraph says that if TERMINATE I/O PROCESS is received before the CDB or with no active / queued I/O process then the I/O process is terminated "as defined above". Two problems: - If there's no active or queued I/O process, how do I terminate an I/O process? This is largely semantics in the description. - The preceeding paragraph defines terminating in the normal manner, while before that an error recovery is described. Which one does "as defined above" refer to? In the following paragraph (I/O process currently in the queue), it again refers to the ambiguous "as defined above". Page 7-2, section 7.1.2.4, Using the TEST UNIT READY Command: The comment that a READ command can be substituted for TEST UNIT READY is not valid. I suggest it be removed for the following reasons: - Only 4 of the 9 device types implement a READ command in a manner which TEST UNIT READY can use (sequential changes tape position, printer is write only, etc). - The description of TEST UNIT READY contains a table of specific sense responses. This implies that TEST UNIT READY might return more detailed sense data than some other command. - Finally, a READ command on a cached, battery backed disk might not look at the medium at all. A new wording might be the following. It's not perfect either, help is welcome. The TEST UNIT READY command allows the initiator to poll a logical unit until it is ready without altering the logical unit. It is especially useful for logical units with removable media. Targets are expected to execute this command in a prompt fashion (i.e., the target should aviod lengthy disconnections). Page 7-47, Sense data Field Pointer Bytes: The description of which byte is returend when a multi-byte field is in error refers to the "most significant (left-most) byte of the field." Since all SCSI data in the standard is shown byte wide, top to bottom, the term "left-most" has no meaning. I suggest different wording implying smallest byte number offset from the start of the structure, but can't think of anything appropriate at the moment. Page 7-49, last line (deferred errors): "logical unit's" should read "logical units". There's no possesive here. Page 7-80, Control Mode Page, RAENP bit: According to this explanation, if the target is to issue an AEN upon completing the initialization sequence it must also set a unit attention condition. I don't think this is the intent and the text should instead read: A ready AEN permission (RAENP) ... initialization sequence instead of creating a unit attention condition. Page 8-28, READ command: The FUA bit description tells what write commands should do. This seems out of place. If the FUA and DPO bits are to have a single description, it should not be part of a specific command description. Other descriptions don't refer back to previous sections. For instance, section 6 describes how to interpret Transfer Length fields, but this description is repeated for each command which has a Transfer Length. Page 8-34, READ LONG command: I don't understand the logic of allowing a byte transfer length of 0 with no error. This appears to make READ LONG a no-operation command or perform some subtle, implementation specific operation. Instead, I think zero should return an error as any other invalid length does. This simplifies the command and eliminates an undefined condition (does zero length READ LONG do nothing, read the sector and discard, etc?) This also applies to WRITE LONG. Also, if zero remains a valid value, the paragraph describing byte transfer lengths should be changed to specify "non-zero" transfer lengths, as WRITE LONG does. Page 8-34, READ LONG command: There is a potential implementation difficulty with READ LONG. The READ LONG command reads a logical block. This can be more than one physical sector. Thus, READ LONG data might contain multiple sectors with ECC embedded periodically. The unwary might assume READ LONG applied to a single sector only. Page 8-36, REASSIGN BLOCKS command: The last paragraph on this page says that if an unexpected unrecoverable read error would cause data loss, the address of the unrecoverable block is returned in the information field of the sense data and "the valid bit shall be set to one." In REQUEST SENSE, it states that the valid bit is one if the sense data is in the standard format. I suggest that the statement about the valid bit be removed from REASSIGN BLOCKS since it implies a different use for valid than in REQUEST SENSE. Alternately, if there's a different bit being refered to, clarify the statement. Page 8-38, third party RELEASE: The IMPLEMENTORS NOTE for third party RELEASE describes how third party RESERVE causes a unit attention condition. This seems like it should be in the IMPLEMENTORS NOTE for third party RESERVE instead.