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?