X3T9.2/87-163    
                                          Sept. 10, 1987

To: X3T9.2 Committee (SCSI)

From: Gerry Houlder   MPI/CDC

Subject: Proper Response for Nonchangable Mode Parameters 

It has come to my attention that there are three slightly 
different interpretations of how the target should respond if an 
initiator sends (via MODE SELECT command) a value to a non-
changable MODE parameter.  (Note: a nonchangable parameter is one 
that returns ones in all of the bit positions of that parameter 
in the "changable values" data returned via MODE SENSE.)  These 
different interpretations mean a big difference in the way an 
initiator must prepare data for a MODE SELECT command.  Thus, if 
the initiator and target use different interpretations it can 
cause every MODE SELECT command to end with CHECK CONDITION 
status. 

In this proposal, I will describe the three interpretations and 
try to describe the advantages and disadvantages of each.  It is 
clear to me that one of these methods should be officially 
accepted for the SCSI-2 Standard and the wording clarified 
accordingly.  If all three continue to exist in the marketplace, 
many products will not be interchangable between systems without 
software driver changes.

Version 1: Target accepts only its current value for nonchangable 
parameters.

With this method the initiator can do a MODE SENSE command 
requesting current values for the desired page; set a new value 
into a parameter; and send the new data in a MODE SELECT command.  
Since all other parameters (nonchangeable and changeable) are 
simply reloaded with their previous values the initiator doesn't 
need to be concerned with them at all.  If the MODE SELECT 
command is rejected, it should only be because the new value sent 
is not supported by the target.

If only one parameter is being changed, this method allows the 
simplest algorithym for the initiator.  The changable values 
don't need to be read from the drive (as required for version 2) 
for such simple cases and a positive indication of whether the 
target will perform the change (GOOD status if yes, CHECK status 
if not) is always there (version 3 will respond with GOOD status 
whether the target will do the change or not).  Once a system has 
been configured, any MODE SELECT commands will usually change 
just one parameter at a time to adjust for nontypical situations.  
Thus we should make it as easy as possible for the initiator to 
change just one parameter at a time.  
Version 2: Target accepts only zero for nonchangable parameters.

With this method the initiator must do a MODE SENSE command 
requesting the current values for the desired page; change the 
proper parameter as desired; do another MODE SENSE requesting the 
changable values for the desired page; check the changable value 
to see if the desired parameter can be changed (if not, don't 
bother with the rest of the procedure); do a masking operation 
that transforms all nonchangable parameters to zero; do a MODE 
SELECT command with the new mode values.  None of these steps can 
be skipped if you desire a general algorithym that will work with 
different vendors or different versions from the same vendor 
(that might have different levels of changability).  If you did 
everything right, a CHECK status result to the MODE SELECT 
command means that you sent an unsupported value to the changable 
field.

This method has the disadvantage of requiring a complicated 
initiator algorithym even for simple, one bit changes in order to 
guarantee that zero values are sent to all nonchangable 
parameters (most nonchangable parameters have a nonzero default 
value).  Also, an algorithym that requires changing parameters 
other than the one you want to change, just to satisfy a target 
controller, seems like a bad philosophy.  The only advantage of 
this version is that the target's procedure for handling 
nonchangable parameters is slightly easier.

Version 3: Target ignores any value sent to a nonchangable 
parameter.

With this method the initiator must do a MODE SENSE command 
requesting the current value of the desired page; do a MODE SENSE 
requesting the changable values for the desired page (if the 
desired parameter isn't changable don't bother doing the rest of 
the procedure); set the new value of the desired parameter; send 
the new data in a MODE SELECT command.  If the initiator doesn't 
care whether the target really does the change or not, he can 
skip the step where the changable values are read.  A CHECK 
status result to the MODE SELECT command means that you sent an 
unsupported value to the changable field.  Any unsupported value 
sent to a nonchangable parameter will be ignored.

This method's advantage is that it is simple for the target and 
fairly easy for the initiator also.  The disadvantage to ignoring 
many fields is that the initiator might believe that the target 
has accepted the change and will do it, when in fact the target 
is not doing the change as requested.  The resulting misunder-
standing can be a serious problem for the initiator.

My recommendation is to select version 1.  This is what the 
Common Command Set group (in which I participated) intended to 
create and it is still the best alternative from the initiator's 
view.  I regret that unclear or erroneous wording in the CCS 
document has caused other interpretations to exist, and we must 
act to permit only one interpretation in the SCSI-2 Standard.