Lexmark T622 - HPUX

[Jim Lewis_8]

I have installed a new printer on a system consisting of B180L workstations with HP-UX10.20. I have run across an inconsistent problem where if print jobs are interrupted at the printer, then once corrected the spool starts repeating the last job (or part of a previous job) over and over again before finishing the complete spool process. Mostly occurs overnight especially when the printer runs out of paper. Could this be a printer or printer driver problem? Any help is greatly appreciated.

Thank you.

[Helen French]

Hi Jim,

Will the command 'cancel' help u?

before loading paper see the ouput of 'lpstat -t' and check out the pending jobs.
If you doubt the printer, try connecting the printer with any other system and test the same scene !

HTH,
Shiju

[Rodney Hills · Accepted solution]

If you are using Jetdirect network card or box for communication to the printer, then modify the print driver that executes the program "hpnpf" by adding a "-w" option. This will force the print driver to wait until a print job is truely complete before sending the next job down.

-- Rod Hills

[Jim Lewis_8]

Rodney - in the printer control script the following is found: # pack all options for hpnpf,
HPNPFOPT="-j $job+$user $TEOJ $TOJMON $ONUSTATUS $xPORT -x $PERIPH $HPNPFLOG $topazopt"
...should I place the "-w" option in the beginning of this line? Thanks....

[Rodney Hills]

The variable $TEOJ (for true end of job) is what you want set to "-w".

Look in the script for where is is assigned and assign it there.

-- Rod Hills

[Chuck Zearfoss]

I am involved in a similar situation with a Lexmark T620 printer. Did you ever resolve this issue? Regarding the issue of running out of paper or getting a jam, or even just pulling the tray on the printer causing the report job to restart from the beginning: we seemed to have solved this by changing settings in the printer. Go to the printer's web page (http://), hit Configure- Setup, and change the Wait Timeout to 300 and the Autocontinue to 10. Don't know if other combinations will work, or if it was one or the other or both that fixed it.
One twist to our situation is that in addition to the remote jobs going to the printer via the HP-UX print server, users local to that printer also print directly to it from Windows using the Lexmark TCP/IP port (which goes to port 9100 just as the HP-UX queue does). If a local print job is sent to the printer when the report is printing, the local job will interrupt it and print, and the the remote HP-UX job will start again from page 1! We have not solved this one yet.
TOEJ is already =" " but we are going to try to change JRECOV="yes" to JRECOV="no". We anticipate that this will just keep the job from reprinting, but it will not prevent the interuption.
The Queue we are dealing with printed remote reports and local windows jobs flawlessly to an HP4000n (which was replaced with the T620)

[Sandip Ghosh]

If it is a Network printer I had faced same type of problem with HP Printer. Do a telnet to the printer and increase the idle timeout/telnet timeout from 90sec to 300sec. I think it will solve your problem.

Sandip

[Chuck Zearfoss]

Actually this is a T620"n" and has an integrated NIC. The "End-of-Job Timeout" setting has already been set to "0" (default is 90) meaning disabled, meaning the printer will not close a network session due to a timeout situation. Per Lexmark, a log from the printer seems to indicate that host is initiating the printing port session closure, possibly due to the host not receiving appropriate back channel communication from the printer (port 9100 supports bi-di comms). Hypothesis is that port 9100 becomes "open", and when the local job starts it uses 9100 and cuts off the remote print job. We are exploring network issues and hope to get a network trace of the host to printer interaction. Even though comms is over frame relay, could the MTU setting of 1500 be too high? We may try to back down to 576, but I hate relying on random config changes.
Thanks
Chuck

[Chuck Zearfoss]

I changed the MTU setting (under printer's webpage->configuration->TCP/IP->Advanced) to 576(it was 1500), and this seems to work. This indicates that there was some packet
fragmentation or loss going on over the WAN connection between the print server and the printer at the local office. The hypothesis being that this was causing
the communication errors between the printer server and the printer, and was why
the print server thought the job didn't complete, etc. Given the cisco
equipment that is in use, and the fact that there is a frame relay connection
between printer and print server (which supports MTU of 1500), I thought this
MTU change had an outside chance of effecting anything.... but thought it was
worth a try.
NOTE - we still need to change it back to 1500 again, run the report, and attempt
interruption, just to verify that this setting change did it. However it is the only thing that was changed, so looks like this is the fix.

[Chuck Zearfoss]

OK, the previous configuration changes I mentioned all help the situation, but definitely does not get rid of it. It looks like the way to fix this is to change the community name string. 2 Ways -
1)Use telnet: Telnet 9000
2)Use Lexmark's MarkVision Professional software
a) under settings-network-tcp/ip, at the bottom
b) create a device policy for a print server (if you want to change alot of printers at one time)

JetAdmin and HPPI does SNMP GETs before the print data, one with community string of internal (which Jetdirect cards will answer, but no other vendor), and one with community string of public, which asks for the private mib location. If a printer responds to this one (as the lexmark does with the OID for it's private mib .641.), then the JetAdmin/HPPI will tend to do "status checks" by requesting SNMP OIDs when it detects a dataflow issue (don't know what kicks that off...). Anyway lexmark responds to the status OID request with "no such name" (cuz the OIDs are in HP's private MIB .11.) and then Jetadmin/HPPI restarts the print job from page one. If the community string name in the lexmark is changed from the default of public, JetAdmin/HPPI still performs the initial SNMP GETs, but gets no response in either case, and thus evidently thinks the printer is "dumb" and never does the status checks in the middle of the job, but instead just keeps sending data...
Hope this helps
Chuck