HP3000-L Archives

January 1995, Week 3

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Eero Laurila <[log in to unmask]>
Reply To:
Eero Laurila <[log in to unmask]>
Date:
Wed, 18 Jan 1995 21:46:40 GMT
Content-Type:
text/plain
Parts/Attachments:
text/plain (92 lines)
Rodolfo Lopez ([log in to unmask]) wrote:
: I am sorry to port some bad news but at the same time a workaround to make
: model 8646 Intermec printers work properly with an HP3000.
 
:      1) It is not possible to connect this Intermec printer to the 3000
:         spooler and make it work right.
 
I felt that I need to respond to this as it is clear that Xon/Xoff works
correctly on HP3000.  If that would not be the case, no serial printers
could be used on HP3000's anywhere.  However, there are loads and loads
of different printers from several manufacturers connected to hp3000's
and as long as configurations match, they just work and work and work...
no data overruns.
 
: I was told that the technical reason for this is that  the 3000 can not
: acknowledge the  DC3 (Xoff) signals from the printer correctly and the
: printer is not aware that the 3000 ignored it.
 
- DC3 characters cannot be "acknowledged" by anything or anyone.  It is an
  absolute stop sign - nothing should be sent upon reception of an Xoff.
  Once an Xoff is received, the sender has to stop and only resume sending
  after an Xon received.
 
- I have lots of personal experience in tracing serial ports on both classic
  and MPE/iX machines and I know that a 3000 stops sending data as soon
  as it sees an Xoff.  If this is not the case, I would recommend you to
  contact HP response center and for sure they can explain what's going on.
  There is nothing special about hp3000's Xon/Xoff, it works just like
  any other Xon/Xoff implementation.
 
- The cases that I have seen where data overruns were taking place were
  setups where an HP3000 (classic or RISC) was printing through a mux
  network (or another type of network) that did not have any Xon/Xoff
  handshaking and the serial port was sending data faster than the printer
  could print.  In these cases the data was filling up network buffers
  and by the time the Xoff was sent, it got to the hp3000 right away and the
  hp3000 stopped sending data, however, the network in between kept emptying
  it's buffers without slightest idea about Xoff and caused a printer to
  overrun it's buffers and mess up the printing.  However, I would like to
  stress that there is no reason to think that Xon/Xoff would not work on
  HP3000 - it does.  If that is not the case, please contact the HP response
  center to find out what's wrong!
 
- Other cases have all fallen into the category of mismatches between the
  serial port configurations causing Xoff's to not look like Xoff when
  arriving to HP3000.
 
 
:                                              I was even told that some
: HP3000 equipment sends on purpose many DC3 signals to make sure that the
: HP3000 acknowledges it and pauses.
 
- This is probably a reference to some of the intelligence in printers
  built since introduction of first Xon/Xoff implementations.  Early
  implementations sent one Xoff when receive buffer was full or almost full -
  without thought that it might not make it back to the host...  What often
  happens is that there is some device or network between the printer and
  the sending host that does not do handshaking.  Another alternative is
  that there is a significant network delay in between.  Both causing a
  scenario where a printer can overflow it's buffer if the Xoff was sent
  by the printer at the time it's receive buffer was full.  Some printers
  used to do this - i.e. send the Xoff when it was already too late...
 
- A more appropriate approach is to have the printer to send the Xoff when
  it figures that it's receive buffer is filling up faster than it can print
  data out but it has still enough buffer space to hold incoming data to
  accomodate the time it takes for the Xoff to make it all the way back to
  the sender and the sender stops.
 
- Some HP printers (for example) send the first Xoff at 75% of buffer space
  used and this works most of the time.  However, there's a feature built
  in some of these printers that if for some reason the Xoff did not get acted
  upon (e.g. Xoff got "broken" or lost on the way back) - the incoming data
  flow did not stop - the printer sees it's buffers filling up even more,
  at 90% buffer usage the printer starts sending an Xoff after every (byte or
  record??) it receives at this condition.
 
 
:                                     Who is responsible, the operating
: system(spooler) or the hardware on the 3000? I do not know.
 
- Neither, the problem is not the 3000 hw nor sw (99% sure) unless there's
  some recently introduced bug.I'm positive that Xon/Xoff works okay on 3000.
  Please have the real cause tracked down;- HP response center can and will
  help you to identify the cause.  I also checked with terminal I/O lab, there
  have been no reports on Xoff not working from the worldwide hp3000 installed
  base.
 
 
Best regards,
Eero Laurila - HP CSY Networking lab, NS services.

ATOM RSS1 RSS2