Hi,
I have a question regarding the necessity of buffer identifier (or
sequence number) in the ORB command.
In the Annex E. of SBP-2 Rev.3a, the following is described.
E.4 Status FIFO write request
When the target detects a missing acknowledgement after a write to
an initiator's status FIFO, it should take no error recovery
actions. Any target resources allocated to the ORB should be
released by the target. The initiator is expected to discover the
error by means of a higher-level mechanism, such as a command
time-out and to initiate appropriate error recovery. The nature of
the error recovery undertaken by the initiator likely depends
whether or not the target processes ORB's and returns their status
in order, but in any event is beyond the scope of this description.
If this happened and followed by bus reset, it seems initiator loses
synchronization with target. I suppose the sequence number or
something may be useful in this situation to avoid duplicated ORB.
Am I missing something?
Akihiro Shimura
On Fri, 20 Feb 1998 12:15:40 -0800 (PST)
Greg Shue <gregs at sdd.hp.com> wrote:
> >
> > I don't believe the entire printer model has to be standardized,
> > we just need a way to communicate basic operational steps, such
> > as start a job, report status, report errors, etc. Within such
> > a framework, and number of formats, protocols, etc, are possible.
>> Agreed. The PWG has already agreed (?) that a print job is
> a separate data path than device status. No one has raised
> the topic of reporting formatting errors. I don't know if
> it's a general issue or not.
>> > If after running out of paper you'd like to load more and continue,
> > you can just requeue the same ORB and let the printer pick up from
> > where it left off. (I would design the native printer profile so
> > that the printer can remember where it was in that ORB, and not
> > execute the same parts twice.) My statement shouldn't be read to
> > imply that any error causes a total shutdown - just that the
> > printer will wait for further instructions.
> >
> > --------------------------------------
> > Eric Anderson ewa at apple.com> > Apple Computer, Inc. 408-974-8187
> > --------------------------------------
>> I was trying to avoid the printer having to verify that the
> same ORB was requeued and remembering the offset into it. I've
> always had the impression that it would be more problematic
> than breaking the data up into transport-level blocks. Perhaps
> you can convince me otherwise. Would you try?
>> --
> Greg Shue
> Hewlett-Packard Company
> Office Products Division gregs at sdd.hp.com> ----------------------------------------------------------------
>
--
Akihiro Shimura (shimura at pure.cpdc.canon.co.jp)
Office Imaging Products Development Center 3
CANON INC.