Andrew writes:

> I have a LJ4 (just 4 no extension)It hangs off my DTC and I have mapped my
>  PC printer config to it. ie. \\sharename\l04 (104 is the device no) and in
>  the HP Samba printcap file as lp|104|HP3000 system lp. I have an equate in
>  the INETD job of file rawlp=rawlp;dev=104,13;env=lp4.hpenv.sys. I've tried
>  it with and without the env parm.
>
>  I have been living with it printing an extra blank page every time I print
>  for quite a while now but my patience has run out.

Off the subject, but I thought about being a physician for a bit of time, and
I had the same response: my patients ran out, too.

More appropriate to the subject (which is "someday your prints will come" --
with an extra blank page), it is only speculation on my part, but I strongly
suspect that your PC-based application/samba shared-printer program is
generating a full page of output, possibly even appending a FF (form feed) to
the end of its final page. Or, alternatively, your PC application is line
counting and insuring that every line of every page it produces is filled,
even if it has to append blank lines to the last printed line in order to
insure that the page is completely filled.

If that's true, the problem you're seeing is because the HP3000 -- at no
additional cost, and without asking -- ALSO appends a CR/LF/FF sequence to
every bit of output that's driven through a DTC (or ATP or ADCC) printer
port. This helpful bit of behavior has been in the HP3000 since almost its
earliest days -- and it is particularly irritating if your application also
insures that the final piece of paper is filled and ready to be ejected.

If your application quit where ever its last line was printed on the page,
rather than working to complete the page itself, you'd only get an extra
blank piece of paper ejected on those odd conditions where the last printed
line was also by chance the final line of the page. Otherwise, the HP3000's
auto-appended FF would merely cause the partially completed page to skip out
normally.

In our HP3000-based report writer, we also complete the page, and have always
felt it necessary to do so. But, as a consequence, we've had to live with
these *&#^$% blank sheets for years now. We've never found any way to
suppress MPE from adding these three bytes of extra code.

However, there is some good news in all of this. The problem only seems to
happen on DTC-connected printers. Line printers on GIC/TIC/HPIB-like channels
don't seem to get this extra bit of code. More importantly yet, neither do
network connected printers.

Further, PostScript printers, when put in PS-mode only, don't know what to
make of the CR/LF/FF sequence, so they don't eject the extra piece of paper
under any circumstance.

If everything I've said here is correct, if you change your printer from
being DTC-based to network-connected, the problem should go away. Your PC
program can fill out the page as it sees fit -- and the HP3000 won't do
anything to change the basic data stream that your PC application is
generating.

Wirt Atmar