X3T9.2/88-138 October 20, 1988 To: X3T9.2 Membership From: James Semenak, AT&T Subject: SCSI-2 Revision 5, Section 9 Comments Included are my comments after reviewing section 9 of SCSI-2 Revision 5. I would like the committee to address these issues at the next working group or plenary meeting. I view most of the comments as editorial. I would like to thank the committee for taking the time to address my issues. SPACE Command Page:9-31 First Paragraph The descriptions of forward and backwards have been removed. They seemed appropriate since they were used to indicate the general direction and not confuse it with actual medium movement. I suggest that "forward (toward end-of-medium)" and "backward (toward beginning of medium)" be added back in the document. Page 9-33 First and Second Paragraph The statement describing the "information bytes are not valid" when Valid bit is zero has been removed. This was removed. It provided some clarification to confusion that has previously occurred in the definition of the information bytes. Third Paragraph In addition to the WRITE command this also applies to the WRITE FILEMARKS command. I suggest that this be changed to "write type operations". Also the word "position" is spelled incorrectly in line 2. WRITE Command Page 9-35 First Paragraph The standard uses the terminology "from current position on logical unit". This doesn't seem to apply to buffered tape drives and is not necessarily the position of the medium. I don't have better wording though at this time. Page 9-36 First Paragraph Fixed-mode has become mandatory in revision 5. It seems to have gotten in as an editorial change. I don't see any need to identify a mandatory mode here. Second Paragraph There used to be detailed descriptions linking the fixed bit with the MODE SENSE block-length and READ BLOCK LIMITS. Also indicating which modes were valid with reference to those fields. I would to see this added back in as done in revision 4. A description indicating the out of range error cases when fixed bit is zero related to the values reported in READ BLOCK LIMITS. This should be added back in, it provides clarification of valid block length modes. Also should add for fixed bit equal zero that "transfer length specifying block length in bytes". Paragraph 4, page 9-37 of revision 4 has been removed. I feel it should be added back because it provides definition of the fixed bit and the cases it is valid. Fourth Paragraph Last Sentence The word "buffer" could be modified to either "target's buffer" or "logical unit's buffer". Sixth Paragraph The early-warning condition sense key definition for drives in unbuffered mode has been changed from NO SENSE to VOLUME OVERFLOW. This seems more than just an editorial change however and I wanted to make sure everyone was alerted. I agree with the changed version (R5) that VOLUME OVERFLOW should be reported if any data is remaining to be written for unbuffered mode. For unbuffered and buffered mode if all data is written after early-warning is encountered the target should return a CHECK CONDITION status and the sense key set to NO SENSE. This seems to have been removed. Eighth Paragraph This is more of a question and depending how it is answered it could affect other sections. Are there any drives that will write a partial block before stopping and reporting early-warning or EOM conditions? Page 9-37 Fifth Paragraph I don't agree with requirement of Implementors Note. This is implementation specific. As a matter of fact this is controllable by a MODE SELECT parameter in the Device Configuration Parameters Page. I believe it is the Buffer Size at Early Warning field. Note(2) seems to be redundant. It seems to be covered in paragraphs 7 and 8 on page 9-36. Page 9-38 Note(3) seems to be redundant. It seems to be covered in paragraph 9 and 10 on page 9-36. WRITE FILEMARKS command Page 9-38 First Paragraph The standard uses the terminology "from current position on logical unit". This doesn't seem to apply to buffered tape drives because it is not necessarily the position on the medium. I don't have better wording though yet. A change has been made to limit the mandatory implementation of WRITE FILEMARKS to Immed bit equal to zero. This seems to me to be a technical change. I would prefer both to be mandatory . Is there a reason paragraph 2 was removed from revision 5? It seemed to provide some definition to implementors on how filemarks should be handled. I would prefer to see it added back into the document in some form. Page 9-39 First Paragraph The definition of the CHECK CONDITION has been removed for this case. The definition should be extended from just being merely "rejected". Fourth Paragraph The sense key for the case of encountering EOM when writing filemarks and all data and filemarks have been written seems to be missing. The sense key should be NO SENSE I believe. For Case(2) and Case(3) didn't we say that the values of the information bytes were dependent on the current mode (fixed or variable) of the logical unit when the CHECK CONDITION occurred. I thought this was the case because data could be written in both modes on the medium and that the standard did not provide a clear indication what the information bytes should reflect. Ninth Paragraph The sense key definition seems to be missing for the first case. I believe it should be NO SENSE. LOAD/UNLOAD Page 9-14 Second Paragraph Should "peripheral device" be changed to "logical unit"? Fourth Paragraph The statement indicating that the Re-Ten bit implementation is optional has been removed. A statement which indicates this should be added. READ Command Page 9-17 Second Paragraph I don't agree that the only mandatory implementation is fixed-block mode. This could preclude devices that support only variable, although I don't know of any today. Also, SCSI provides what I feel is a good mechanism to inform the initiator which modes are supported by the device. This mechanism can be used for generic drivers. Third Paragraph The two cases which describe when the device is in fixed mode (see R4, page 9-20 and 9-21) have been removed. They provided a good definition of fixed-mode. That definition seems to be lost now. I would prefer that this be added back in some manner. The error cases for fixed bit have been moved to the end of this command. It seems to me that that the errors should be defined where the fields are defined instead of at the end of the section. Also providing the table at the end is not consistent because many of the error cases are still left in the body of text. Fourth Paragraph The error case which describes the SILI=1 and the fixed-bit=1 has been moved to the table at the end of the section. It seems it would do better here. It seems to follow the format of the section better. Page 9-18 First Paragraph The sense key is not defined for this case. I believe it should be NO SENSE. Third Paragraph The sense key is not defined. I believe it should be NO SENSE. What is supposed to be reported in the information bytes when the SILI bit is one and a filemark is encountered on a read operation? I don't believe this has been defined. The following sentence could be added to the last sentence in this paragraph. If the SILI bit is one and a filemark is encountered the information bytes shall be set to zero? Seventh Paragraph Again, the definition for SILI bit equals one is not provided. Page 9-19 First Paragraph Again, the definition for SILI bit equals one is not provided. READ POSITION Page 9-23 Third Paragraph First sentence should read "...indicates that the first and last block locations are not known...". It should be the plural, I know this is picky. Fifth Paragraph The definition for the position when performing a READ REVERSE has been removed. Sixth Paragraph Revision 4 indicated that the last block position was relative to the first block within a partition, assuming that there are multiple partitions. The definition has been changed I believe. It seems that the new definition indicates that the last block position is relative to the first block position in the buffer. Isn't this different than the revision 4 definition when you have multiple partitions? READ REVERSE position definition has been removed. READ REVERSE Page 9-24 First Paragraph Section 9 uses various combinations of "peripheral device", "device" and "logical unit", and they seem to be all used to refer to the same thing. Although the definition indicates that there is sometimes a one- to-one mapping between peripheral device and logical unit I suggest that the section use one or the other. In this case I suggest "logical unit". For example PREVENT/ALLOW MEDIUM REMOVAL says, "... enable or disable the removal of the medium in the logical unit." and the LOAD/UNLOAD command uses "... indicates that the medium in the peripheral device shall be positioned for removal ...". Fifth Paragraph The sense key should be NO SENSE when BOP is encountered. Also the same issue with the SILI bit = 1 and the information bytes definition. Is the residue zero or non-zero but different than the requested transfer length? Page 9-25 Entire Page This seems redundant since the READ command is referenced already these can be referenced also it seems. RECOVERED BUFFERED DATA Command Page 9-26 Fourth Paragraph In the second sentence I believe that it should read "If the requested transfer length is smaller than the actual data length to be recovered, the requested transfer length shall be returned to the initiator and the remaining data shall be discarded." Page 9-27 First Paragraph Again, the case of when the SILI bit = 1, fixed bit = 0, the requested transfer length does not match the actual block length and a filemark is encountered is not defined. I believe that in this case a CHECK CONDITION status is reported, position is after the filemark, filemark bit is set to one and the information bytes are set to zero. Second Paragraph Same case as above. Third Paragraph I would prefer to see the error conditions in the text as it has been. At the least it seems that this stuff could be referenced in the READ command in the manner same as SILI bit description. RESERVE command Page 9-29 Seventh Paragraph There seems to be an implication that targets that support independent mode select parameter are required to copy those parameters of the initiator that issues the 3rd party reservation to the MODE SELECT parameters of the 3rd party. I haven't found anywhere a statement of what should be done, if anything, once the 3rd party RELEASE is issued. At the least I suggest that an implementors note be added to the RELEASE command description to indicate that the original parameters may not be restored and that the initiator may be responsible for restoring those values. VERIFY Command Page 9-35 The statement that the Byte Compare function is optional has been removed. I don't remember a proposal removing this statement.