Minutes of SSC/SMC working group 11/9/95

[tedl at smtplink.exabyte.com]

SSC/SMC Working Group Minutes - November 1995        X3T10/95-359r0


To:                Membership of X3T10

From:              Edward Lappin
                   Exabyte Corporation
                   tedl at exabyte.com
                   (303) 417-7718

Date:              November 9, 1995
Subject:           SSC/SMC Working Group Minutes

1.    Opening Remarks

Ted Lappin, the SSC Technical Editor, called the meeting to order at 
9:05 a.m., Thursday, November 9, 1995.  He thanked Jeff Stai of Western
Digital for arranging and hosting the meeting.

As is customary, the people attending introduced themselves and a copy 
of the attendance list was circulated.

The draft agenda was approved.

2.    Attendance and Membership

Attendance at working group meetings does not count toward minimum 
attendance requirements for X3T10 membership.  Working group meetings
are open to any person or organization directly and materially affected 
by X3T10's scope of work.

The following people attended the meeting:

Name               S        Organization            Email Address
Mr. Edward Lappin  P        Exabyte Corp.           tedl at exabyte.com
Mr. Bill Dallas    A        Digital Equipment Corp. dallas at zk3.dec.com
Mr. Pat LaVarre             Iomega                  p.lavarre at ieee.org
Mr. Wesley Hale             Unisys Corp.            wes.hale at mv.unisys.com
Mr. Ken Hallam     P        Unisys Corp.            ken.hallam at mv.unisys.com
Mr. Ralph Weber    A        ENDL                    roweber at acm.org

6 People Present

Status Key:        P    -  Principal
                   A    -  Alternate
                
3. SSC Topics

3.1 Soft Write Protect

Wes talked about why the soft write protect bit is where it is.  We 
moved it according to Arlan Stone's document last time but there was 
activity on the reflector about why it should be moved back.  Bill 
Dallas asked about whether or not that this bit is savable as a Mode 
parameter.  Other devices, but not all, could use this bit.  In 
particular, CD ROM may want to use it.

Arguments for device configuration page:

1. More appropriate for the page.  It is a configuration.
2. May not want to save this field.  If don't save, should be on 
   page that is also not saved.
3. Read/write recovery page is only superficially the same for 
   different devices.

Arguments for read/write recovery page:

1. More consistent with disk and CD-ROM drives.

Other arguments:

1. May be useful to write protect and save for the cartridge.  
   However, still have to write to it to save the mode parameter.
2. If really want to save parameter on media, should be command 
   since Mode parameters are not necessarily saved on the drive.
3. Writing to media for a non-write command upsets some users.  
   This also is a problem with savable Mode parameters.
4. Argument about when UA for mode parameters occurs.  Question 
   about how many UAs are OK.  For example, doing both power-on 
   and media changed, many cheap drivers cannot take multiple 
   check conditions (they don't check for the reason).

Conclusion is that we cannot guarantee commonality and we should not 
worry about it at this time.  Therefore, due to better location, we 
should have it in the device configuration page (no change).  This page 
fits the functionality better.

3.2 Clarification on Report Density

Ken wants clarification on defaults.  In particular, for the media 
default density (not drive default), what will be written if we are 
writing.  The media bit indicates the capabilities of the drive in 
combination with the currently loaded media.   The command is for 
reporting capabilities, not written data.  

Also noted, this may apply to other command sets.  However, it is up to 
other command sets to adopt this mechanism.

3.3 Write Buffer

Ken does not like the current Write Buffer proposal.  Clarity is 
required.  Ken wants to know why we did Write Buffer mode 7 the way it 
is done.  Loading may require looking at file (Bill) to make sure file 
is already correct.

3.4 Samonize the document

To do this, need to make sure:

1. Data in/out phase converts to "Data-In buffer" or "Data-Out 
   buffer".  This is in section 4.1 (The request -response model) 
   in SPC.
2. Initiator converts to application client or initiator.  
   Application client does most of the commands.  If initiator and 
   not the thing sending the command or getting status back, then 
   it is probably the initiator.  If sending or receiving, 
   probably the application client.
3. Target converts to device server or logical unit or target.  
   Logical unit is for thing that contains information for the 
   LUN.  The device server is the typical target.  For SPC, Mode 
   pages went to the logical unit or target, depending on the 
   scope of the data.

3.5 Locate

I pointed out that the valid bit is not set on a Locate failure.  This 
is because there is not a residual on a Locate since there is no concept 
of residual because blocks are not numbered in a particular way.

3.6 Block numbering

Bill would like to specifically specify that blocks are numbered 
sequentially.  He needs to bring a proposal to change this aspect of the 
model since, while not violated by current drives that we know of, it is 
a major change.

4. SMC Topics

There were no SMC topics.  The editor of SMC, Erich Oetting, was not 
present.

5. Adjourned at 11:00 AM.