Process not relinquishing a LAT device...

[John Gillings]

Chaim,

Have you tried a lower line speed?

Even if it's not the cause this time, it really should be reduced to something closer to the printer speed. It's been a while since serial printers have gone out of fashion, but back then this used to be an FAQ in the CSC

Q:why doesn't my printer work?
A:because you're feeding it too fast

[Alon Jacob]

John.

We tried lowering the printer's speed to 2400, and though it appeared to help, after a few hours it came back.

[John Gillings]

Chaim, Alon,

>We tried lowering the printer's speed
>to 2400, and though it appeared to
>help, after a few hours it came back.

OK, next step is to go even lower. Try 1200 or even 600. Make sure you're sending data significantly SLOWER than the printer's paper output rate. You should be able to SEE that the printer is running slower than normal. This SHOULD eliminate all flow control between the DECserver and the printer. If you STILL have a problem, it must be further upstream.

Repeat the exercise of slowing stuff down between other pairs of components further up the wire.

I seem to remember situations where an XOFF could be sent as data through a MUX, confusing the flow control logic and hanging the port. I had some code to force an XON onto the wire to unblock it. Are you sure there isn't any binary data creeping into the data stream? Time to break out the data scope?

(or, a "poor man's data scope" - get a VT220 or similar terminal and a hardwired OR "Y" cable, connect it in parallel with the printer, disable flow control and turn on "DISPLAY CONTROLS")

[Alon Jacob]

John.

At this point we suspect something with the voice that mixes with the data using the DV-MUX unit.
For various reasons (not technical) we cannot lower the speed to 1200 or 600, but the next step would be to change the communication to this branch to a full TCPIP (which we planned to do anyway) and seperating the voice from the data.

I'll keep you posted.

[Basil Hendroff]

As I suspected earlier, the problem appears to be centre around the networking between the two sites.

The way to confirm this once and for all is to now point the queue that has been set up for the remote printer to point a local printer port. If that works without stalling the queue (at full printer speed [9600baud?]), the muxing equipment is almost certainly contributing to the problem.

Now that its been revealed that a voice mux is involved, the following might help explain the random nature of the problem.

LAT is timing sensitive. It is a LAN protocol. It is not designed for use on the WAN. As it is not a routable protocol, if you choose to deliver it out to the WAN, it has to be bridged if using a router. Unless the bandwidth allocated to LAT through the MUX can be fixed, at times of high voice activity, bandwidth that would otherwise be available for LAT through the MUX/modem arrangement will be squeezed and at some point LAT will choke and stop working between sites. The problem will manifest itself in symptoms not unlike what you have been observing both with direct port printing and printin via queues.

I now can't believe that the problem is related to XON/XOFF or the printer baud rate, but is related to the sensitivies of LAT over a WAN, particularly where there is a shared bandwidth arrangement in delivering LAT to remote locations.

As you are dealing with stat MUXs, its highly unlikely that you can hive off part of the composite link bandwidth for LAT.