Printer 'blocked'

[Willem Grooters]

About a year ago, the printing environment has changed from HP lasers to OCE/Kyocera MFP printers, as a straight replacement; our TELNETSYM-based queues have not changed, since these printers are officially PCL5/PCL6 compliant.
Apart from a few printing problems still under investigation, they do their job for some time now.
However, since a few weeks users complain that prints are not delivered. In our investigation we found the queue is in state 'busy', and the job on top of the queue is in state "starting" blocking any subsequent printjob - a situation that can last for hours.
$ STOP/QUEUE will cause this job to enter state 'aborting' which can take some time to disappear. $ START/QUEUE/NEXT mostly helps, all remaining jobs (possibly many) will be processed in seconds. Sometimes it's required to specify this command twice.
But it's also possible that the next job wil enter the same state: job in state "starting" and queue in state "busy".

It's not just one queue, it can be any, but it occurs on some queues more often than others. It's obvious that queues that serve printers that are most active, have the most problems.

Operator.log shows a lot of messages like:

%%%%%%%%%%% OPCOM 18-JUL-2008 15:46:34.90 %%%%%%%%%%%
Message from user QUEUE_MANAGE on NODEA
%QMAN-I-INVSMBMSG, invalid data 0 in message from symbiont on queue MFP10210 is being ignored

and

%%%%%%%%%%% OPCOM 18-JUL-2008 15:46:34.90 %%%%%%%%%%%
Message from user QUEUE_MANAGE on NODEA
%QMAN-I-INVSMBMSG, invalid data 0 in message from symbiont on queue MFP10210 is being ignored

but we found no relation between these messages, but the number is related to the number of known 'stalls' as described.

(Environment: VMS 7.1 on VAX, not clustered)

[Wim Van den Wyngaert · Accepted solution]

Have/had the same problem on 6.21h3 and 7.3. LPD and telnet symbionts. Improved when the symbionts were reset once a day. But still happens from time to time.
And on all types of printers (have no Kyo's, only HP and Lexmark and tally). And state of queue can also be "processing".

fwiw

Wim

[Jon Pinkley]

Any idea what changed "a few weeks ago"?

Did these OPCOM messages just start recently?

If I understand your report, things have been working fine for almost a year, then the behavior changed a few weeks ago. Any known new patches on VMS/TCPIP, or firmware upgrades on the MFP printers (possibly automatic updates via the internet?).

Jon

[Anton van Ruitenbeek]

Willem,

Are these printers the so called 'secure printing environment' ?
If so, the remote printer is a MS-Windows box.

AvR

[Willem Grooters]

All these printers are accessed directly over their netwok interface - not over a Windows box. (That is: AFAIK).

As it turned out: we found similar problems on HP printers as well, so it's not restricted to the printers we first encountered these problems.

Another possible cause has been fouind last Friday: Batch jobs, scheduled to start on a given time, were started but will not enter an executio state. Deleting the entries put the jobs in Aborting state; since no action is taken afterwards, these are still in this state.
Since critical processes are running on this batch queue, it could not be stopped like the print queues. Recreating the queue database is an option we may take.

[Thomas Ritter]

Why Telnet over LPD ?

If other clients are trying to print then telnet typically runs into problems. Are other sources trying to print while VMS is trying to print ?

I think the only advantage of Telnet based printing is that it's firewall friendly.

The printers may have a management interface which you could use to see what is happening. I dont have my notes with me, but something like $telnet /port=9000 or such. The printer manual will have the information.

[Willem Grooters]

I tried telnet to these printers, no immediate disconnect, but no response either; Any input is 'accepted' without echo - though I haven't waited for timeout (next time I will).
If these OCE/Kyocera printers allow LPD only, it's feasable to use LPD. But since the same problem arose with HP printers just a few days ago - and these never gave a problem - I think there is more to it than just the protocol.
It's our estimation that problems began when printers were shared between Windows and "other operating systems".
I don't see how that would relate to the same issues on BATCH queues....

We rebooted the machine this afternoon (not because of this problem alone :) so I'll have to wait and see what will come out.

(TBC)

[Wim Van den Wyngaert]

HELP/MESSAGE INVSMBMSG

May be the printer is following a newer/different version of the protocol ?
Or a bug ?

Checked my log files for the "ignored" messages : we get that message about 250 times in 6 months (1 cluster).
220 of the 250 concern printers located in a special remote site. And the strange thing : the printer giving the error isn't printing anything because it's a DRP printer (verified it with accounting). And it's restarted every day but uses a LPD queue as target.
The remaining 30 are for normal user telnet queues using HP printers.

fwiw

Wim

[Wim Van den Wyngaert]

TCPIP$TELNETSYM_STREAMS defines the number of execution queues handled by each TELNETSYM process.

May be put it on 1 to see if the multi-threading is the cause ? Trying to handle 16 queues must be more difficult than 1.

Wim

[Willem Grooters]

Just learned that there has indeed been firmware updates. It was after one of these that this problem came to the attention of system management; so it's tempting to assume it has been that update that causes the problem, but there is no proof that it did not occur before. It also happens on HP printers. Just a

Thinking of it: Would it matter whether these (network) printers are accessed directly, or as a shared printer on a Windows server?

[Jon Pinkley]

RE:"Why Telnet over LPD ?"

Thomas, if what you meant by that is "Why do you prefer to use queues with /PROCESSOR=TCPIP$TELNETSYM instead of /PROCESSOR=TCPIP$LPD_SMB, I can think of several reasons. The primary reason is that LPR/LPD queues don't behave the same as normal VMS print queues. If you use print/form= it has a totally different meaning. Also things like flag pages are different. It is a UNIX implementation hung on the side of VMS. If you are just printing source code listings, then they are ok, but if you have preprinted stock, getting LPR/LPD to work like a LATSYM queue is a pain. (Yes, there are relay queues, but even if you can get them to work, you have to have two queues. Here's one thread concerning LPR queues on VMS. Ian's first response in that thread was spot on in my opinion.

https://community.hpe.com/t5/operating-system-openvms/bd-p/itrc-293#.X36hD0czY2x

So, if it is possible to get telnetsysm to work, that is what we use.

I don't see how firewall configuration for LPR/LPD vs. raw tcp on some other port like 9100 would be any more or less difficult. In general we never allow access to our printers from the Internet except via VPN, so it isn't an issue for us.

Jon

[Wim Van den Wyngaert]

BTW : I prefer the telnets over lpd.

In DCPS doc you find several notes on printers reacting badly. May be also applicable to telnetsym.

Look for "starting" in
https://support.hpe.com/hpesc/public/km/search#q=DCPS%20&t=Documents&sort=relevancy&layout=table&numberOfResults=25&f:@kmdoclanguagecode=[cv1871440]&hpe=1

Wim

[Jon Pinkley]

RE:"Would it matter whether these (network) printers are accessed directly, or as a shared printer on a Windows server?"

Willem, I am assuming you are asking about sharing the printer between VMS and windows users, and are asking if the windows PCs are directly accessing the printer, or if they are spooling through a windows server. Different printers handle multi-threading differently. In general, sharing among non-coordinated clients can be problematic, especially for things like resetting the printer. I would guess there would be fewer problems if all the windows jobs came from a single server, but I guess it depends on how the server's print driver deals with the printer vs. how PC print drivers do.

I have never attempted to access a printer from VMS via a Windows server, if that is what you were suggesting.

Jon

[Hoff]

Host-based (served) printers are not worth any cost savings that might be accrued, IMNSHO supporting these things.

Network-based printers are much more manageable, more maintainable, and generally much easier to deal with, and more reliable.

The telnet and lpd paths are largely interchangeable; I find myself choosing and using one over the other basically only when a daemon or client bug is encountered.

I've seen queues get stuck like this when the Windows UI for selecting printers confuses somebody. If you use a stale Windows driver or if you mis-connect the printer, it is easily possible for the Windows box to either skewer the printer, or to allocate the printer to itself. And IIRC, the path that you might think it is to get to the printer using Windows 2000 and Windows XP -- network -- is the wrong path.

On the OpenVMS host side, ensure that your ECOs for OpenVMS and for the queue manager and for whichever IP stack is involved are all current. (The INVSMBMSG implies there's a (usually minor) bug in the symbiont, but whether that is the proximate cause or a symptom here...)

[Anton van Ruitenbeek]

Sorry Willem that I didn't react earlier on your answer of my quenstion ;(

But as I can recall there were in the begin of IP printing (around 1990) a lot of problems because of the implementation of 9100 on some printers.
This had to do with the printers were accepting IPX/SPX, AppleTalk, IP and some also LAT and most also 'that MicroSoft other printer protocol'. It was MS propriaty. Because all these differences sometimes the printerprocessor didn't get the 'end of job' message. So the printer wasn't released from the remote server. You get the same behavior when your printer was connected via LAT on a DECServer and didn't set the protocol to LAT. If you started to print, the connection was made, but never released.

But to make a very long story short (because I can add still a lot of reasons more), maybe a option is to shutdown (remove) all the protocols which aren't used. This to release the printer overhead.
Make sure the timeout on the printer for IP is (lets say) 90 sec.
Also check on the printer the printer 'remote' name and socketnumber. Name is mostly RAW and socket is normaly 9100. But this will be correct otherwise you wouldn't get the first printout.
If you got the option, try to let all the other platforms use the same printprotocol (TELNETSYM), althou I don't think the YouNix guys will follow. But for the MS-Windows it's no problem (sometimes even faster).

AvR

[Willem Grooters]

The problem occurs too random to reproduce it at will on a specific printer; there are too many variable factors (number of prints, from a number of different systems, network issues).
We now run a batch job at regular intervals that checks queues and top job on status and resets the queue when needed. Not what we want but it seems to bypass most problems.

There is another issue with LPD queues, but that's another story.