Printing fun.

[sbrews]

I have a printer issue that is making my head hurt (among the many in this old environment).

Server A has a print que defined on it, print driver is net_genericprinter - all works as expected when sending print jobs.

Server B has had the same que created on it, same print driver, etc.  When configured in this manner, the queue never prints... even though the printer is otherwise reachable.

I can define the printer as a remote_print que and this works... albeit that it stair-steps on the output (and I have a fix for that).  I am waiting on user testing to see if this particular work-around will work for their check printing.

What I am trying to detemine is why it wont print when set up via hppi with the net_genericprinter driver or with the P2015 driver (printer is an HP P2015dn).  There is no useful info in /var/adm/lp/log.  What might I look at to determine why this works just fine on server A and not at all on server B?

[Matti_Kurkela]

The remote printer protocol uses TCP port 515, while hppi uses TCP port 9100.

Can you connect to the printer if you run "telnet <printer IP address> 9100" on server B?

If the above-mentioned telnet command does not report "Connection established" on server B, then there is a network issue: maybe a firewall that is configured to allow one print protocol but not the other?

You could use the "disable" command to make the printer queue stop printing while still accepting requests. If you do this on both servers and then print the same job on both of them, you should be able to compare the job files held in the queue directories to see if they have close-to-identical content. If not, there might be an application configuration issue. Use the "enable" command to resume normal printing.

You can find a list of downloadable HP printer model scripts at:

http://www.hp.com/pond/modelscripts/index2_printable.html

(wow, looks like this old link still works!)

It includes net_genericprinter. Perhaps it's an updated version, and it has been installed to one of your servers but not the other?

[Bill Hassell]

HP printers (with HP network cards) all use port 9100, although they will also respond to the primitive port 515 remote printing protocol. Start by deleteing and re-adding the printer using removequeue and addqueue:

removequeue -q printer_name

addqueue -q printer_name -h 12.34.56.78 -b off -r off -t off -i 123

where -i 123 is the ID number for the 2105 printer. Use the command:

addqueue -l 

to list the printer models with their ID.

Now trace the activity using hpnp:

hpnpf -l /var/tmp/hpnpf.log -x 12.34.56.78 /etc/profile

Check the log for the progress.

This will trace the actual network protocol.

You can also use hpnpadmin -v 12.34.56.78

In the above examples, 12.34.56.78 is your printer's IP address.

[sbrews]

I can telnet via port 9100 - so that part is good (no firewall blocking).  I have created test que based on the steps listed by Bill.  That test print appears to have worked - it didnt get hung up in the que as it has previously... however, I and waiting on my remote hands person (printer is not local to me) to verify that the test job did indeed print. 

[sbrews]

Using the addqueue as listed by Bill and the "driver" for the 2015 printer, it did print, but stairstepped... so 2 steps forward and 1 back.  I will work on getting the stair step address and try again.

interesting that the addqueue worked (printed) whereas the hppi created queue just sits there.

[Dennis Handly]

>but stairstepped

You need to configure it so that it adds a CR to that newline LF.

[Bill Hassell]

The 2015 driver is nothing more than a script. Try deleting the printer and add it back with the driver id -i 261 which is the generic net_ljx000. That script seems to work the best for most HP-compatible printers. Without reading the 2015 script, it is not possible to see if there is a CR-LF configuration. Out of the dozens of printer scripts for HP-UX, I've never seen one for an HP printer that required the CR-LF to be enabled -- it is always on.

The reason addqueue probably works better is the options to turn off Job Recovery and True EOJ were explicitly turned off on the command line.