Process not relinquishing a LAT device...

[Chaim Budnick]

Unfortunately, Alon jumped the gun a little and the problem still exists. In fact now it appears that the problem is NOT with just one specific printer, but rather with a second printer at this site. However, the volume of printing on the second printer is much much less so the problem is less often and less bothersome.

So, we are back to the drawing boards!

Chaim

[Wim Van den Wyngaert]

Just a possibility : could it be that the decserver has been plugged in a full duplex network instead of half duplex ? Once had very strange things with that (most of the time working correctly but sometimes "it" went wrong, MOP boot behaving bad etc).

Also : did you try a reboot of the decserver ?

Wim

[Basil Hendroff]

As the problem is only occurring with printers offsite, it could be that the multiplexor/modem arrangement may be introducing a problem. What models are being used? Can you supply the configuration data for mux ports/modems at both ends? In particular, it will be interesting to see how buffer overflow protection and terminal flow control have been set up at both ends of the link.

The other possible problem area to check is that modem configurations may be 'almost' correct. Under normal operating conditions, things will appear okay. However certain AT commands are pertinent under unusual conditions. It's easy to forget to include these special AT commands in the modem init string.

[John Gillings]

Chaim,

>Here is what I get from SHOW:
>
>Name PORT_8
>Speed 9600
>In Flow ENA/on
>Out Flow ENA/on


Consider the print speed of an LA36 printer - I mean the effective baud rate of characters onto paper. Is it anywhere near 9600baud? (=~1000 characters per sec) No!

XON/XOFF protocol is not designed for "high" speed and really doesn't work very well at anything over 4800 baud, ESPECIALLY when exercised heavily. By the time the poor slow printer realises it's deluged and the XOFF reaches the sender, the wire has already filled up with too many characters.

So, first step is to reduce the line speed between the printer and whatever it's directly plugged into to something closer to the real output rate. Choose the lowest speed that's more than the paper speed - maybe 1200, but certainly no more than 2400. You won't slow down the output, but you will take a LOT of stress of the poor little printer trying to deal with too many characters being thrown at it.

If you still have a problem, reduce the speed again to something LESS than the paper speed. Make sure you can SEE a slow down in the output at the printer. That pushes the flow control issue back to other components further up the wire because the printer is no longer the slowest component. If the problem goes away at very slow speeds then return to the slowest failing speed and start to analyze the characters flowing across the wire to check what XON/XOFF is doing.

If the problem remains at very slow speeds, then start talking to your network support folk as you've revealed something wrong with the MUXes or modems. Walk back up the wire making sure all the logical "ends" of the pairs of devices on the wire agree on protocols.

[Chaim Budnick]

The plot thickens !!!

The DSM application also allows the option of printing via an OpenVMS queue, and I implemented this option, hoping that if the problem is an application problem that LATSYM will behave better.

After several jobs the queue went into a "Stalled" status. This lasted for some 10 minutes. Then the status changed, I believe they powered off/on the printer. At this point jobs on the queue would process but physically NOTHING printed, until the printer was powered off/on again.

Does this information add any elements which might point to the crux of the problem.

What has me puzzled (among many things) is the fact that other than the XON there do NOT appear to be any other problems such as missing text/characters etc. to my thinking if there are comm problems we should be seeing other manifestations.

[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.