10-5-88 X3T9.2/88-126 Thomas Wicklund Ciprico, Inc 2955 Xenium Lane Plymouth, MN 55441 612-559-2034 Comments on SCSI-2, Revision 5 document. - Section 2: Should the ASCII standard be included as a referenced standard? - Page 7-35, Mode Select / Mode Sense support: According to the last paragraph of this page and the description of MODE SENSE(10) on page 7-39, a target may implement the 10 byte MODE commands without implementing the 6 byte MODE commands. Is this correct? Are there compatibility problems? - Page 7-39, MODE SENSE(10): The DBD bit is not included in this command. Why not? - Page 7-54, section 7.2.15.1, second paragraph: The phrase "data out" is not capitalized. - Page 7-55, Field Pointer: Which byte of a multiple byte parameter which is in error should be specified in the field pointer? The bit pointer gives the most significant bit. Should the field pointer indicate the most significant byte? - Page 7-72, Log Page Descriptor: The first paragraph ends with the statement "The 4-byte heder is illustrated in table 7-_." It should read "The LOG Page Descriptor is illustrated in table 7-_." The table shows both the header and page specific parameters. - Page 7-74, TSD bit: I'm confused by the explanation. Why can't both the TSD and DS bits be set to 1? They both disable saving. I can see a problem with DS of 1 and TSD of 0, is this what's intended? - Pages 7-73, 7-74, parameter bits: Three of the four bits are disables. Would it be more consistent to define the fourth as "disable threshold"? It seems odd that they aren't consistent. The descriptions are also incomplete. The TSD bit has no definition for LOG SENSE. The LOG SENSE usages listed are only for default values. What is returned with Threshold Values or Cumulative Values? - Page 7-74, paragraph after table 7-61: "criterion" is the singular or criteria and should be used in this paragraph. - Page 7-75, FP bit description: This page says "The same value of the FP bit is returned for all parameter types." Is this all parameter types of the current page or all parameter types of all pages? Under the description of an FP bit of one, what does "ASCII, non-graphic, bytes containing data in a non-counter form" mean? ASCII non-graphic codes are from 00H through 1FH and 7FH. Why only allow these values? The next paragraph describes how two list parameters are handled on a single page. They must be in ascending order, with a provision for wrap around. On page 7-82 (LAST n ERROR EVENTS LIST) only ascending order is allowed, wrap is not provided for. This conflict should be resolved. - Pages 7-84, 7-86, and 7-87: The first byte of the various mode parameter page tables is inconsistent. I suggest all use the standard mode parameter page format of table 7-34, page 7-43. - Page 7-87, Common Device-Type Control Parameters: Table 7-77 defines bit "EQ". The text later refers to bit "EQue". These should be consistent. - Page 7-87, AEN bits: Should UANEP instead be UAENP? - Page 7-88, last paragraph: The word "a" is mistyped "s". - Page 7-93, Operating Definition Description VPD Page: The 256 byte limit on VPD page length is going to be a problem. This page contains text describing all operating definitions. Assuming it's lines in the form "# xxxx" and 40 character lines, the page will only hold 6 operating definitions. Normally this should be sufficient, but 256 operating definitions are allowed. - Inquiry VPD pages in general: There is no obvious logic or consistency to the VPD page formats. Why do they all differ? Wouldn't a single basic page format make a lot more sense? - Page 8-16, PREVENT ALLOW MEDIUM REMOVAL command: The last paragraph of this description mentions a "FLUSH CACHE" command. Should this be "SYNCHRONIZE CACHE"? - Page 8-25, Read Defect Data, paragraph on returning data in user inaccessable areas: This paragraph is rather confusing. The first sentence says logical block and physical sector format may not include user inaccessible areas of the disk. Does the term "may not" mean "must not", or "allowed not to"? This isn't clear. The third sentence then allows physical sector format (but apparently not logical block format) to include areas not accessable to the user. I think that creative interpretation of this paragraph says "any defect format may return any information desired". If this is the intent, the paragraph should be deleted. I interpret "user inaccessable" to mean inter-sector gaps, in which case the alternate wording in the editor's note won't work. One might interpret "user inaccessable" to mean that the defect is in a flawed out area, in which case the defect list after mapping is empty. Not intended but I think it's allowed by the wording. I'd like to propose an alternate wording, but I have no idea what is intended. Finally, should the term "user" be replaced by "initiator"? - Page 8-27, Reassign Blocks: This command appears unique in having a DATA OUT phase with no length specified in the CDB. Is this intentional? I'd think it much simpler if the target were given a length. - Page 8-43, START STOP UNIT: The description of the Immed bit specifies when status is returned. Is this supposed to time when the STATUS phase occurs or when the command completes? An implementation could return GOOD status immediately then hold off the COMMAND COMPLETE message until the operation completes. I don't think this is the intent. - Page 8-44, SYNCHRONIZE CACHE: The end of the first paragraph refers to a "flush" operation. This should state "synchronize". - Page 8-45, VERIFY command: There is no way to specify "verify to end of media" in order to implement a full disk verify. Instead, one must issue verify commands every 65K blocks, which is annoying. I suggest redefining a Verification Length of 0 to mean "to end of media". This is consistent with WRITE SAME. - Reserve / release: The descriptions of READ and WRITE document handling of reservation access conflicts. No other commands include these descriptions. However, logical unit reserve applies to all commands except REQUEST SENSE and INQUIRY. Should the descriptions remain in READ and WRITE only? I suggest they be removed and the RESERVE command be clarified if necessary. If the intent is to specifically document reservation for media data access commands, then add the "reservation access conflict" description to WRITE AND VERIFY, WRITE SAME, COPY, COPY AND VERIFY, COMPARE, PRE-FETCH, FORMAT, READ LONG, SEARCH DATA, WRITE LONG, and possibly SYNCHRONIZE CACHE. - Page 8-52, WRITE SAME: The action when both the PSdata and LBdata bits are one is not defined. Should it be? Also, under the PSdata description, it states that the "physical address" of the sector be placed in the first 4 bytes. When describing defect lists and the translate address diagnostic page, the term "physical sector address" refers to an 8 byte cylinder / head / sector value. Should the PSdata section use a different term, or does it mean an 8 byte c/h/s address? - Page 8-57, Table 8-45: This table doesn't match the table for all device types in section 7.5. Specifically: - Page 8 is now caching parameters. - Page 9 should be Peripheral Device Parameters, not Reserved. - Page 0A is now called "Common Device-Type Control Parameters". - Sections 8.3.x: Is there any logic to the order of these sections? If so, I can't find any. They aren't numeric or alphabetic. - Page 8-83, pre-fetch: The text refers to the "AMS" bit. Earlier text refers to the "MS" bit. These should be consistent. - Page 8-84, section 8.4.1: The first sentence of the RECEIVE DIAGNOSTIC Translate Address section uses the term "translate logical physical address page". Shouldn't this just read "translate address page"? The same is true in the next section. - Page 8-84, diagnostic pages: This section is confusing. RECEIVE DIAGNOSTIC pages are before SEND DIAGNOSTIC, but the list of valid pages is specified in SEND DIAGNOSTIC. This list should be moved earlier. Section numbering also isn't consistent, with RECEIVE DIAGNOSTIC using sections 8.4 and 8.4.1 while SEND DIAGNOSTIC is a level down with 8.4.2 and 8.4.2.1. I suggest that 8.4 be "Diagnostic Pages" with the list of page codes here, then pair each specific send and receive page together. - Page 9-11, sequential device commands: An ACCESS LOG command is listed. Wasn't that turned into LOG SENSE / SELECT? If not, there isn't an ACCESS LOG command in section 7 as specified here. - Page 9-11, sequential device commands: Any sequential device which requires the RECOVER BUFFERED DATA command has a latency between completion of the last write and data being written on the medium. Does this imply the need for a SYNCHRONIZE BUFFER command? - Page 10-2, the SYNCHRONIZE BUFFER command isn't in alphabetical order. - Page 10-3, SYNCHRONIZE BUFFER command: In a multiple initiator environment, does this command apply to all buffered data or buffered data from the current initiator only? The problem I see with the first interpretation is that another initiator may be queuing print commands for a long time, even though the SYNCHRONIZE BUFFER initiator's data has been printed. If the latter interpretation is used, SYNCHRONIZE BUFFER cannot be used to determine when the printer is idle (I don't know if this is useful or not). - Page 10-6, RECOVER BUFFERED DATA command, third paragraph, it isn't explicit that a request for less than the full buffer should return data before CHECK CONDITION status. Perhaps change it to read: "If an attempt is made to recover more data than is contained in the buffer, the command shall first transfer the requested amount of data. It shall then be terminated with CHECK CONDITION status ..." I think this also applies to RECOVER BUFFERED DATA for sequential devices. My concern is that many other commands abort without data transfer if the length is wrong (e.g. READ LONG, WRITE LONG) and this reduces the chance of confusion. - Page 10-10, STOP PRINT command: How does this interact with queued commands? The SCSI-1 STOP PRINT command assumed that there weren't any active commands on the device. It merely controlled unprinted buffered data. It isn't clear what to do with currently active PRINT commands which haven't completed and may not have transfered all data from the initiator.