Process not relinquishing a LAT device...

[Chaim Budnick]

I am not certain that it will be possible to get an absolute solution from the forum, but I'll give it a shot !

One of our customers has a DSM application which has its own internal "spooler" and prints by issuing direct IO to the printer device. One particular printer is causing problems. Under normal circumstances the DSM application allocates the device, does its IO, and relinquishes the device. Usually this takes at most several seconds. Every so often the process does NOT relinquish the device and remains the owner process on the device. This of course prevents anyone else from printing. When I do a "sho proc" on this process it is in LEF state; with a /contin it appears that the process is doing nothing (i.e. the PC remains the same). I assume that the process is awaiting an XON/XOFF indicating that the IO has completed, and for some as yet umknown reason is NOT receiving it (or the printer is not sending it as expected). The printer in question is an LA36 dot matrix (since this printer needs to impact as the feed is a 3 copy with carbon paper).

We have tried everything from switching the physical printer, the decserver port, the decserver. The ONLY thing that is different between this printer and other LAT device printers is that this particular printer is located at a customer site which is NOT on the same LAN as the ALPHA server and the other printers. This means that the IO is being done via multiplexor to modem - to telephone line - to modem - to multiplexor.

We have requested from the company that services the networking HW devices to come on-site and check the devices.

Does anyone see that the problem could be other than HW? Is there anything that I can check?

Thanks,

Chaim

[Wim Van den Wyngaert · Accepted solution]

Chaim,

We have something simular in DSM.
The application opens a LAT device, writes some data to it and closes the devices. But the device is spooled (set device/spooled) and thus is injected into a print queue.
The program normally uses a logical name that points to the device.

Is that what you do too ? If so, did you do a set device/spool for the device ? If not, the data is written directly to the LAT device, what should be avoided, IMHO.

Wim

[Volker Halle]

Chaim,

XON/XOFF is handled between the printer and the DECserver port. You can check the status of the port with Local> SHOW PORT n STATUS

When the process owning the LTA device is in LEF, you could try to check it's state with SDA>

$ ANAL/SYS
SDA> SET PROC/ind=xxx
SDA> SHOW PROC/CHAN
SDA> SHOW PROC/LOCK
SDA> CLUE CALL

This might give an indication what the process is waiting for.

Volker.

[Chaim Budnick]

Thanks for your replies !!!

I will check with the third party who are responsible for the application, however, I have a feeling that they are writing directly to the LTA device.

Thanaks,

Chaim

[Robert Gezelter]

Chaim,

On XON/XOFF over multiplexors.

I have seen situations where there was a loss of synchronization due to buffer overflow on a remote printer.

It can cause a variety of symptoms (typically, lost characters, but in theory almost anything is possible).

The LA36 has a VERY finite buffer (check specs). If the sender keeps sending characters past that point (as perceived by the LA36) a problem can occur. In the case that I investigated, using an LA100, the modem/multiplexor in question had a synchronous comm link, and the resulting delays in propogating the XOFF, measured in characters, exceeded the printer/terminals buffer (later model VTxxx terminals, if I recall correctly, had a larger -- 256?? byte buffer). Tracking this problem correctly required two datascopes -- one at each end of the "serial link" -- with the multiplexor link in between the datascopes.

Then again, the problem could be a bug in the printer management software.

It is hard to be more specific without a lot of details.

I hope that this is helpful.

- Bob Gezelter, http://www.rlgsc.com

[Chaim Budnick]

I would like to attempt to utilize the /spooled mentioned earlier.

If I understand correctly this is totally transparent to the DSM application, is this correct?

I will need to define a printer queue on the specific LTA device, is this correct?

Then I will set dev ltaxxx/spool=the-queue, is this correct?

At this point, the DSM application will continue to "write" to the LTA device, but VMS will "take over" and print via the queue, is thix correct ?

Thanks ,

Chaim

[Wim Van den Wyngaert]

Yes on condition that the program only writes to the device (otherwise it is a symbiont program).
When the device is spooled to a print queue (via an intermediate disk), the file will be printed by that print queue. It may even be an IP printer !

There is no command to see if it is spooled !

Wim

[Chaim Budnick]

What do you mean by:

"Yes on condition that the program only writes to the device (otherwise it is a symbiont program)." ??

Thanks,

Chaim

[Volker Halle]

Chaim,

if using the spooled device approach, please note that the 'print job' is only created when the DSM program closes it's channel to the LTA device. So if there would be something wrong with that program and it will hang with a channel assigned to the LTA device (like now), the spooled device approach won't help.

If there is some kind of synch XON/XOFF problem when communicating with the remote LA36, that same problem would then manifest itself in the LATSYM print symbiont (queue stalled). The spooled device approach will just allow other users to print on that device concurrently.

So it still may be a good idea to try to find out what's wrong...

Volker.

[Wim Van den Wyngaert]

Never tried it but I guess that you could communicate with a printer.

But I guess it is a dummy printer that doesn't do communications (e.g. LPD printer do communicate).

Wim

[Wim Van den Wyngaert]

Chaim,

To verify if the device is spooled : do show dev ltaxxx/fu. It should show "spooled". But the details (disk+queue) are not shown.

But as Volker said, find out what's wrong.

Wim

[Wim Van den Wyngaert]

And note that your problem is the normal behaviour for a non-spooled printer that ran out of paper or is offline.

Wim

[Chaim Budnick]

Thanks for all te replies!

Of course we are attempting to solve the problems and not the symptom. However, it will be interesting to see if at least the users will be happier. Currently, at the point where the DSM application owns the device, any user attempting to print is unable and receives a "Line Busy" error, until someone either stops the owner process or someone repowers the printer. On the other hand according to one of the replies it appears that setting the device as spooled may not really prevent this.

Thanks,

Chaim

[Volker Halle]

Chaim,

'repowering the printer' - that sounds like a lost XOFF. You can see this with Local> SHOW PORT n STATUS (it should say Output XOFFed: YES).

With a spooled solution, your users won't get the 'line busy' errors, but the print-queue will occasionally enter the STALLED state and you might need to monitor that...

Good luck,

Volker.

[Chaim Budnick]

The DECservers are 90L and I don't think I can get this particular information.

Thanks,

Chaim

[Volker Halle]

Chaim,

the DECserver 90L should have a SHOW PORT command and it should show:

In Flow: ENA/on
Out Flow: ENA/on

for all the ports. ENA or DIS will show whether flow control is enabled/disabled, /on or /off will show the current state.

So Out Flow: ENA/off would indicate that the output to the printer is currently XOFFed.

Volker.

[Chaim Budnick]

Here is what I get from SHOW:

Name PORT_8
Speed 9600
In Flow ENA/on
Out Flow ENA/on
Type PRINTER
Break LOCAL
Rem Mod DIS
Test NO
AutoConf DIS
ODL DIS
Status LOCAL
Service
Node
Port
Fram Err 0


That's all!

Thanks,

Chaim

[Chaim Budnick]

Please disregard my last reply, I was a little dyslectic !

They are both ENA

Thanks,

Chaim

[Volker Halle]

Chaim,

just wait until the program hangs again. Then repeat the SHOW command and see whether /on has changed to /off ...

Volker.

[Alon Jacob]

Hello All.

After the STM multiplexer was replaced on both sides it looks like the problem's solved (Yes, I work with Chaim).

Not surprising - there was no problem from the VMS side.

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