Forwarded: SCSI DCC bit

Gary_Peterson at Gary_Peterson at
Mon Jan 29 12:51:04 PST 1996

* From the SCSI Reflector, posted by:
* Gary_Peterson at

From: Gary Peterson:DGC
Date: ## 01/29/96 15:51 ##
More comments on the SCSI DDC bit discussion that has been going on.
Please send replies to:  Gary_Peterson at
or post them to the reflector.

Previous comments:
From: Mike Foster
Date: ## 01/29/96 15:55 ##
Please forward this to the SCSI reflector.  My latest note is at the 
end of the attached message.  There is more to consider than what I 
provided last time on the DCC bit in SCSI page 0Fh.

CEO document contents:  
* From the SCSI Reflector, posted by:
Jorgen Johanson writes:

>* From the SCSI Reflector, posted by:
>* JOJO <jojo at>

> We have some questions regarding medium partitions and data compresssion. 
> We are looking at a sequential access device (like a tape streamer). In 
> this case the medium is typically removable. It is also typical that the 
> device is able to operate on medias of diffent types. The different medium 
> types have different capabilities (like different capacities, varying 
> possibilites of storing information other then the bare data etc.)
> Medium Partition Page
> ---------------------
> We have a question regarding the Medium Partition Page(1) specified in 
> X3T10/997D rev.5 page 54 (section
> The description of the "Maximum Additional Partitions" field indicates that 
> the value of this field is "a logical unit-defined value indicating the 
> maximum number of additional partitions supported by the LOGICAL UNIT".
> In our case however, the maximum number of partitions is determined by the 
> type of the MEDIUM currently inserted into device (a QIC-1000 type medium 
> allows a maximum of 2 partitions while a QIC-5010 type medium allows 36 
> partitions). In some ways this is also more logical in that the both the 
> actual total capacity and the how the total capacity is structured (into 
> partitions) are both typically determined by the medium and not by the 
> device (partitioning is a medium attribute).
> 1) Should not the "Maximum Additional Partitions" field be a medium 
> type-defined value (and not a logical unit-defined value)? As it is now it 
> is not possible to determine the maximum number of partitions allowed by 
> the medium?
> Data Compression Page
> --------------------- 
> We have two questions regarding the Mode Select Data Compression Page 
> specified in X3T10/997D rev.5 page 48 (section
> In our case we have some medium types that do not have the possebility 
> of indicating that the data on the medium have been compressed (and 
> because of this there is no indication of the compression algorthm 
> used).
> 2) When such a medium is inserted into the device, what should a Mode 
> Sense command report in the Data Compression Page?
> Since there may be possible problems related to using compression on 
> such mediums (like reading back data without knowing if it has been 
> compressed or not), we would like to dissallow using compression 
> altogether on these media types.
> 3) How should a device indicate that compression is currently not 
> allowed?
> We have three suggestions, we but are not sure which one is 
> appropriate:
>   A)  The Data Compression Capable (DCC) field may be used. However, 
>   ANSI defines this field as a "non-changable" field. The field is 
>   related to the device and not to the currently inserted medium.
>   B)  The Data Compression Enable (DCE) field may be used and a Mode 
>   Select with this bit set can give Check Condition when the currently 
>   inserted medium has a type that we do not want to use for compressed 
>   data. However, DCE may be enabled BEFORE the medium is inserted 
>   (before we know the medium type).
>   C)  The Decompression Algorithm field may be used. If the inserted 
>   medium is not blank, the host may give a READ 1 block command and 
>   issue a Mode Sense to get the Decompression Algorithm. A 
>   Decompression Algorithm of zero indicates no compression (the medium 
>   type is such that compression is not allowed). If the inserted tape 
>   is blank, a single dummy block may be written (DCE=1) and read again. 
>   As above, the Decompression Algorithm may indicate if compression was 
>   used (that is if was allowed by the device or not).
> Bjarte Myrold via
> =========================================================================
> Jorgen Johanson            jojo at
> P.O Box 134 Kjelsas
> N-0411 Oslo, NORWAY

Medium Partiton page
While the capacity and number of partitions may be determined by the medium 
type and data format type for QIC drives it is not true for all tape devices. 
DAT drives in particular will physically format the tape based on values 
supplied by the host in the Medium Partition page.  In this case it is not 
the medium type which determines the number or size of the partitions and 
therefore partitioning is not a medium attribute.
I am not sure what you mean by the sentence," As it is now it is not possible 
to determine the maximum number of partitions allowed by the medium?" If the 
QIC-5010 spec. is similar to other QIC specs. then the number of and size of 
partitions is fixed and unalterable by the host. If this is the case, then 
maybe you know the max. number of partitions because you have read the data 
format type on the tape.  

Data Compression Page
The answer to this problem is to not allow a Mode Select complete 
successfully until the drive is ready.  This forces the host to wait until 
you have read the tape before a Mode Sense has 'real' data.  I think a Mode 
Select should return Not Ready or Illegal Request when a drive is 
initializing a tape.  Your customers shouldn't have a problem with this, they 
can't use the drive until it is ready anyway.  Another option would be to 
disconnect when the Mode Sense cdb is issued and don't return until the tape 
is read.
I think it is perfectly acceptable to set the DCC field to one and the DCE 
field to zero.  The DCC field relates to the logical unit, as it should, and 
the DCE field relates to the data to be written.  Again, don't allow the host 
to set any fields before you have read the tape.
I disagree with your interpretation of what a Decompression Algorithm value 
of zero means.  If the value is zero after you read a block then you read 
uncompressed data.  It does not mean that compression is not allowed.  In the 
QIC formats that I am aware of compressed data is written into a 'Compression 
Block Group'.  A Compression Header will identify the QIC compression 
algorithm, and whether or not the data in the group is compressed or 
uncompresed.  If you read a block and the data is formatted into compression 
group blocks you still could have uncompressed data and have a value of zero 
in the Decompression Algorithm field.  Again, as long you don't let the host 
complete a Mode Select cdb before you are ready ( or hold off on Mode Sense ) 
you shouldn't have any problems.  Writing a block to tape isn't worth the 
effort.  How is the host going to know what you support without issuing 
another Mode Sense anyway?

By the way, if you are making this a SCSI-3 compatible drive you need to look 
at the Report Density Support command which will be mandatory.

Note to SSC group: Do we need to add field(s) for compression information?


To:    SCSI Reflector
Fm:    Mike Foster, Data General Corporation; Westboro, Mass
Dt:    1/26/96

Sbj:   reply to questions on Data compression Page question.

       This is my input with respect to the interpretation of the DCC bit in
the Mode Select page 0Fh.
       SCSI-3 indicates:
               "A data compression capable (DCC) bit of one indicates that the
device supports data compression and shall process data sent to it for
transferral to the medium using the selected compression algorithm when the
DCE bit is one.  A DCC bit of zero indicates that the device does not support
data compression.  This shall be a non changable field."
       That is a good definition of the DCC bit, but it does not appear to be
complete enough to cover a device that is emulating a non-data compression
capable device, due to the insertion of a media cartridge whose format does
not support data compression.  ie: when a QIC-150 cartridge is inserted into a
higher technology QIC drive that is compression capable.
       I propose that when a compression capable device is emulating a
non-compression capable technology, that device should report the DCC bit off
on the return of page 0Fh in Mode Sense.  This will indicate to the host that
it should not attempt to turn the DCE bit on in a subsequent Mode Select to
page 0Fh.
       The emulation of the drive/media should be COMPLETE in all respects:
the media should be properly written/read and the SCSI control/reporting
should be per the emulated technology.

                                Mike Foster


To:    SCSI Reflector
Fm:    Mike Foster, Data General Corporation; Westboro, Mass
Dt:    1/28/96

Sbj:   Second reply to questions on Data compression Page question.

       I have two points of information that need to be considered on the
status of the DCC bit for page 0Fh.  
       First of all, if the DCC bit is to reflect the data-compression
capabilities of the drive only (and does not change irregardless of the media
installed), a write command issued to a drive/media combination that does not
support data-compression MUST fail if the DCE bit of page 0Fh is on.
       Secondly, assuming for a moment that we embrace the concept that the
DCC bit should reflect the drive/media subsystem's capability to support
data-compression.  A problem may arise for some host operating systems:  When
a host initially configures it's system peripherals, if the media (installed
in a compression capable device) does not support compression, the drive will
be permanently configured within the host as a non-data-compression capable
device, due to DCC off during initial host configuration process.  This is
fine, as long as the host operator continues to use the same media.  But, if
the host operator decides to insert a piece of media that supports data
compression (into the compression capable device), the previously configured
operating system will not provide the data compression option to the operator,
since it only looks at the DCC bit during initial system configuration time.
The only alternative here for the host, is to react to the resultant unit
attention, due to medium change, and go through a reconfiguration process
based upon the page 0Fh DCC bit information (not desireable).
       I still support the concept that the DCC bit should reflect the
drive/media subsystem's capability to support data-compression, as I described
in my last note, but it may pose problems for some operating systems, as
described above. 

                               Mike Foster

More information about the T10 mailing list