Confliction of ASC/ASCQ 2C/05
ralphoweber at CompuServe.COM
Tue Jun 27 12:08:35 PDT 2000
* From the T10 Reflector (t10 at t10.org), posted by:
* Ralph Weber <ralphoweber at compuserve.com>
I find it interesting that notifying the SPC-2 editor of the ASC/ASCQ
usage is not in the list of corrective actions. So long as the SPC-2
editor is not notified, SPC-2 tables will not be updated and possible
duplicate assignments of ASC/ASCQ values will result.
One cannot help but wonder about how many MMC-3 ASC/ASCQ codes are
not reflected in SPC-2. Can this be the only case?
keiji_katata at post.pioneer.co.jp wrote:
> * From the T10 Reflector (t10 at t10.org), posted by:
> * keiji_katata at post.pioneer.co.jp
> Hello all,
> Fuji3 (not INF8090i rev.3.6) and Fuji4 (INF8090i rev.4.0) have a conflict
> ASC/ASCQ with RBC. In
> Mt.Fuji, ASC/ASCQ=2C/05 is PERSISTENT PREVENT CONFLICT error on PERSISTENT
> RESERVATION. At the discussion of this error, SPC did not defined any error
> on this code, but RBC uses this code as 2C/05=ILLEGAL POWER CONDITION
> REQUEST, and SPC has this code now. MMC does not have PERSISTENT PREVENT
> CONFLICT error description at all. Current morphing control in
> Multi-Initiator environment, this kind of error code is necessary. So I
> propose that:
> 1. Assign new code 05/2C/06 for PERSISTENT PREVENT CONFLICT error.
> 2. Make Proposal to NCITS plenary from MMC3.
> 3. Revise incorrect error code table in MMC3.
> Kohda of PIONEER made request about No.3 at MMC meeting several times, but
> it is not done yet. Bill, please add these issues in the next MMC agenda.
> Thank you,
> Keiji Katata
> PIONEER CORP.
> * For T10 Reflector information, send a message with
> * 'info t10' (no quotes) in the message body to majordomo at t10.org
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org
More information about the T10