Weird network printer problem

[Jeff_Traigle]

I've been fighting this issue for a few weeks now. The guy I've been filling in for worked on it for several months last year.

They have an IBM InfoPrint 32 Network Printer. The IBM Network Printer software (current version 3.1) is installed on two HP-UX 11.00 systems. The application resides on HostA. Trying to print from HostA directly to the printer results in longer print jobs not completing. (Our test case is 100 pages and it considtently stops at page 90.) If we setup the queue as a remote queue on HostB, the print job completes. HostB has the same version of IBM NP software installed. I even installed the current patch bundle we've tested so the OS patches are all at the same revisions as of last week. I noticed the MTU was set to 1450 on HostA (because of some client VPN connectivity issues, I'm told), whereas HostB was left at the default 1500. I was skeptical the smaller MTU had anything to do with the problem and a test of changing it to 1500 as it is on HostA failed to resolve the printing problem.

From the hosts side, I've pretty much run out of remotely possible causes. The servers are on different subnets and the printer is on a third subnet. I've thought from early in this troubleshooting that there is something in the network along the route from HostA to the printer that is different from what is along the route from HostB to the printer. (The printer obvious is capable of finishing the print job since it works from HostB and the job clears the queue on both servers so there appears to be no issue from that end either.) I'm just not enough of a network person to know what it might be to cause this symptom. The network guys claim their network is fine (as is typical, in my experience, though I don't know that they've actually looked at anything to verify this statement). I figured I'd see if anyone had any ideas on here.

The whole reason they want this working from HostA directly is because HostB is not a production server and is the oddball in the environment functioning as a print server.

[Ken wanderer · Accepted solution]

The answer may be in the print driver used.
You mentioned that when directly connected it stops at 90 pages but remotely it goes through?
Remotely would use the servers print driver.
Similar things happened to me and a new driver would solve the issue or more memory for the printer.
We solved the issue by loading a second print driver for the print jobs that were really large.

[Jeff_Traigle]

Hmmm. Maybe. But if HostB has the IBM Network Printer driver set up for the queue on that system, wouldn't the remote queue on HostA end up using it when the jobs get directed there? Guess I can try setting up a remote print queue to the printer directly from HostB and see what that does.

[Jeff_Traigle]

Well, without the IBM software in the mix, the formatting of the print jobs doesn't work so that's not an alternative.

One other piece of the puzzle that led me to believe something network-wise is causing the problem that I forgot to mention previously... Supposedly, printing was working fine directly from HostA to the printer when the printer was on the third floor of the building. The issue of some print jobs stopping midway only started when the printer was moved to the first floor last year.

[HRE]

Hi Jeff,

Have you tried the Print HostA=>HostB=>Printer only with the 100 pages you mentioned above. If yes, tried it with the 2.5 multiple amount pages and tell us the result.

Regards

HRE

[Jeff_Traigle]

Well, well, well. It did turn out to be the IBM software on HostA. They have a bad habit of using tarballs to install software in this place even when there is a perfectly good SD-UX depot available. It seems they installed one of these tarballs of an old version of the IBM Network Printer Administration software on HostA at some point and it was faulty causing the partial print problem. I thought I'd removed this old version before installing the latest version IBM released, but apparently I hadn't and everything didn't get overwritten during the install. I only noticed this morning because there were still some test files the previous guy had left behind. So after swremoving the software I'd installed, deleting the left behind directory structure, and reinstalling the depot, the problem print job worked when printed directly from HostA to the printer. Will have them monitor for a week to be sure that does the trick for all of the jobs, but I'm pretty confident if it fixed the one that was consistantly failing that it will take care of the rest too.