Missing last page on non-HP printers

[Willem Grooters]

This applies to OCE-Kyocera multi-functional printers, these printers are shared by several systems, including VAX, OpenVMS 7.1, TCPIP 5.0a (no patches). Print queues on the VAx systems use either the TELNET or LPD symbiont, default form is either HP4, HP4_PORTRAIT or HP4_LANDSCAPE, reset form is HP4_RESET on all.

Where real HP printers are used (different types), all is well.
The OCE printers (claiming to be PCL5 compliant) however, when multi-page documents are printed, the last page is not printed at the end of the report.

Some investigation has been done, and it was found that the PCL5 reset sequence seems not honoured by the printer.
Creating a reset-page containing an explicit formfeed and PCL5 reset sequence (ESC-E) resulted in no print at all.

Adding an explicit formfeed at the end of the report solves the problem.

It should be possible to solve this without code change, since the problem is not the code, but the printer.

I could partly reproduce the problem on another system using definitions that closely matched the ones that seem to cause problems; the printer, OCE-Kyocera (OP1016 / KM-1650), is likely to be of another type than production uses, so it's not completely representative.

I print a 2-page file to each of the queues I defined.

Last results:

TELNETSYM does not cause a problem at all.
LPDSYM - LOCAL doesn't print at all.
LPDSYM - REMOTE is prints just the first page on the first attempt, both on second, first only on third.

At this point, I printed a dingle-sheet document from the Windows machine. It resulted in that sheet - and another first page of the last printed file from the VMS box!!! But on the remote (windows-based) printer server, there wasn't anytrhing left in the queue:

$ lpq MFP10295_REMOTE
displayq_remote

Windows LPD Server
Printer \\aaa.bbb.ccc.ddd\MFP10295

Owner Status Jobname Job-Id Size Pages Priority
---------------------------------------------------------------------------
$

(That the local LPD queue doesn't work may be a matter of configuration - but that's another question)

Logfiles show nothing more than the lines that the server has started....
I tried debug but since I don't have the 5.0 manuals at hand, I don't have additional information.

A final twist is adding a formfeed to the report (done elsewhere), but it makes no difference.

Since different types of printers are in use, it's not impossible that these have a different behaviour; it has been reported that TELNETSYM may cause similar problems on other printers. The extra formfeed may help there, but it will make the software dependent on the hardware and might cause problems when hardware is replaced. This is considered
inacceptable for a near-realtime system.

Our idea is that these printers do not, incorrect or incomplete handle ESC-E, as I've been told, the PCL5 code for RESET.

If this is true, does anyone have a solution except contacting the supplier (that will be done anyway)?

Queue definitions and printap file (latest versions) added in attachement.

[Phil.Howell]

I have found that increasing the timeout value to 900 can help with some devices where vms unix and windows (and various methods of each) are sharing printers.
This can be set on hp printers by telnetting to the device, but I don't know about your OCE model, have you tried using its web browser interface? or hpwebjetadmin?
Phil

[Willem Grooters]

It might be interesting to test but I have no facilities to test it.
As it turrned out, it seems I'm testing on an older type of printer than is used on the plant. I've could do some testing on a printer that equals such one and from DCL there seems to be no problem: all pages are delivered, with, or without terminating formfeed, regardless the protocol. Emulation configuration of the printer might be an issue but again, I cannot test, nor can I do any 'load testing'.
I do have the impression that size matters. A 2K document over 3 pages prints fine - without a problem, where a 3.5K document over 2 pages causes the problem.
On the older printer, that is, using a remote LPD-server. I couldn't test on the site-equal printer, alas.
But does it make sense?

[Hoff]

Some options...

1: replace the printers with ones that work as required.

2: use telnetsym for these printers. The usual local assumption: the only difference in telnet and lpd daemons in printers is in the particular printer-specific bugs found; if one fails, try the other.

3: use print modules specific to the Kyocera printers. HP printers have had requirements around blank-page handling off and on for eons; you might well have hit the reverse case here, where tossing an HP sequence at the Kyocera

4: get the vendor to figure out why they're not doing PCL the same way as HP.

And according to the local IT dictionary, "compatible" is defined as "different". If the devices were truly "identical", they'd be marketed as that and not as "compatible".

[Willem Grooters]

1. Obvious. That is my recommendation - and the OCE technician's as well. It may well be that this is the final solution, but company standards dictated these printers.

2. TELNETSYM is being used, and wheer 'my' printer has no problem, others have, appearantly.

3. Meaning ...??? Do you mean writing a symbions espcially for these printers? Ok, it IS a possible solution but I hardly thing I'll get the resources (= time, money and facilities).
Or use Kyocera-specific pages in the prin library. Another possibility that has been considered but testing is difficult without the proper printer. But workable. (Kyocera doesn't supply them...)
I learned about a method today that seemed to solve the problem but the guy who did the investigation wasn't here today..

4. I did, but they insist that they do it right. "Compatible" has been their wording.

[Wim Van den Wyngaert · Accepted solution]

2. Then try passing your telnetsym to a LPD queue. Could work. Other symbiont, other problems but also missing problems.

Wim

[Hoff]

3: printers have historically had some implementation differences (even from the same vendor), and that can mean using specific forms (modules) to deal with the device idiosyncrasies.

Here, I'd look to see if there's something in an existing reset or separation module processing (if any), or if adding differences into same would provide printer-specific processing.

Look around for the HP blank page fix; here's a write-up on device control libraries that touches on that discussion and on related topics, and some printing materials:

http://64.223.189.234/node/129

Printing topics:

http://64.223.189.234/taxonomy/term/77

I've also chased firmware-level issues with printers from various vendors, so standard procedures with printer errors involves looking for firmware upgrades.

[Willem Grooters]

@Phil:
There will surely be such a facility, but since we (developers) have no control over the printer settings, and all printers should be equally configured (easy for operation department - no education required :( ) this is no option.
@Hoff:
1: Against company policy but accepted as a last resort.
2: The problem occurs with telnetsym....
3: Since neither Kyocera nor OCE has any clue (it seems) we will have to create forms ourselves, and test them. Not a big deal but considered too costly.
4: Answered already.
@Wim:
I found out someone had already set things up and tried it. And this indeed did the trick. Not optimal, not the best solution (server gone = printer gone) but fot the time, it's fine.

When we get our own printer of that type, we'll look for a better solution. This is where Hoff's contributions to the issue will be used.

[Willem Grooters]

default orientation set in printer config is "landscape". Printer name MFP10210 is defined in DNS.

Add to printcap:

MFP10210|mfp10210:\
:lf=/SYS$SPECIFIC/TCPIP$LPD/MFP10210.LOG:\
:lp=MFP10210:\
:rm=:\
:rp=mfp10210:\
:sd=/SYS$SPECIFIC/TCPIP$LPD/MFP10210:\
:cr:

Init queue as:

$ INITIALIZE /QUEUE /PROCESSOR=TCPIP$LPD_SMB MFP10210 -
/BASE_PRIORITY=2 /DEFAULT=(FORM=DEFAULT, FLAG, FEED) -
/DESCRIPTION="Oce/Kyocera KM-4050 MFP (LPD)"

and this works.

[Jan van den Ende]

Willem,

>>>
Not optimal, not the best solution (server gone = printer gone)
<<<

Please note, that you can make your VMS box the LPD server, and then that will not be an issue.

hth

Proost.

Have one on me.

jpe