topic Re: Process not relinquishing a LAT device... in Operating System - OpenVMS

Process not relinquishing a LAT device...

Chaim Budnick — Thu, 03 Mar 2005 02:25:30 GMT

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

Re: Process not relinquishing a LAT device...

Wim Van den Wyngaert — Thu, 03 Mar 2005 02:46:38 GMT

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

Re: Process not relinquishing a LAT device...

Volker Halle — Thu, 03 Mar 2005 03:07:41 GMT

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.

Re: Process not relinquishing a LAT device...

Chaim Budnick — Thu, 03 Mar 2005 04:19:38 GMT

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

Re: Process not relinquishing a LAT device...

Robert Gezelter — Thu, 03 Mar 2005 05:33:35 GMT

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

Re: Process not relinquishing a LAT device...

Chaim Budnick — Thu, 03 Mar 2005 06:06:07 GMT

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

Re: Process not relinquishing a LAT device...

Wim Van den Wyngaert — Thu, 03 Mar 2005 06:09:39 GMT

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

Re: Process not relinquishing a LAT device...

Chaim Budnick — Thu, 03 Mar 2005 06:18:50 GMT

What do you mean by:

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

Thanks,

Chaim

Re: Process not relinquishing a LAT device...

Volker Halle — Thu, 03 Mar 2005 06:28:52 GMT

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.

Re: Process not relinquishing a LAT device...

Wim Van den Wyngaert — Thu, 03 Mar 2005 06:41:02 GMT

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

Re: Process not relinquishing a LAT device...

Wim Van den Wyngaert — Thu, 03 Mar 2005 06:44:18 GMT

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

Re: Process not relinquishing a LAT device...

Wim Van den Wyngaert — Thu, 03 Mar 2005 06:46:17 GMT

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

Wim

Re: Process not relinquishing a LAT device...

Chaim Budnick — Thu, 03 Mar 2005 07:06:29 GMT

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

Re: Process not relinquishing a LAT device...

Volker Halle — Thu, 03 Mar 2005 07:12:25 GMT

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.

Re: Process not relinquishing a LAT device...

Chaim Budnick — Thu, 03 Mar 2005 07:48:22 GMT

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

Thanks,

Chaim

Re: Process not relinquishing a LAT device...

Volker Halle — Thu, 03 Mar 2005 08:11:31 GMT

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.

Re: Process not relinquishing a LAT device...

Chaim Budnick — Thu, 03 Mar 2005 08:31:52 GMT

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

Re: Process not relinquishing a LAT device...

Chaim Budnick — Thu, 03 Mar 2005 08:34:46 GMT

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

They are both ENA

Thanks,

Chaim

Re: Process not relinquishing a LAT device...

Volker Halle — Thu, 03 Mar 2005 08:38:48 GMT

Chaim,

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

Volker.

Re: Process not relinquishing a LAT device...

Alon Jacob — Sun, 06 Mar 2005 08:47:31 GMT

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.