asked on

IBM i Lan Attached Printers failing to print after running out of paper

I am the system administrator on the IBM i platform. We have hundreds of printers throughout our enterprise. I recently came on board and have a couple of people that handle day to day operations. One area they spend a significant amount of time on is printer support. It seems when a printer runs out of paper, instead of a simple loading of the paper here are the steps required (sometimes) to get the printers functional again: ENDWTR *IMMED, Vary it off, physically unplug the printer, plug it back in, vary it on and STRPRTWTR. Wow!! This doesn't happen all the time but quite often. If we don't follow these steps, the writer looks active but a spooled files will sit in a PND status and never get to a WTR status. However, with the printer in this status I can use an LPR command to send a SCS spooled file to the printer and it prints fine.

I should state that we are on V7R2 with the latest PTF's applied.

Attached are two pdf's. The configuration of one of our printers and a joblog when the above condition exists.

copyassetcfg.pdf

copyassetlog.pdf

I guess what I'm asking is this... Has anyone else run into this? And if so, is there any solution beyond what we are doing? I even tried a vary on with a reset to no avail.

Gary Patterson, CISSP

Unfortunately, this is documented behavior, though I can tell you from first-hand experience it doesn't happen in every environment.

http://www-01.ibm.com/support/docview.wss?uid=nas8N1019003

Questions and suggestions:

1) Do the problem printers have anything in common (model, location, driver, etc?)

2) Is there a NAT firewall between the IBM i host and the problem printers? Firewall session timeouts can cause some annoying behavior.

3) Open PMR with IBM and gather and submit the info they ask for.

4) Try alternate drivers, based on what the problem printers can support. You didn't provide a specific model number for the example printer, but I saw a note it was a Konica. Some Konicas support other protocols than PJL.

For example, if the PJL driver configured on the example you provided is being used on one of the problem printers, try switching to the SNMP, IPP, or LPR driver (in that order).

http://www-01.ibm.com/support/docview.wss?uid=nas8N1019517

5) Write a "printer reset" program to simplify the recovery process after a PND problem. It is the work of a few minutes to write a CL or custom command that ends a writer, varies off/on a device, and restarts a writer.

6) Update the firmware on the problem printers.

7) If all else fails, you might want to test delegating printing responsibilities to your Windows print server, should you have one.

http://www-01.ibm.com/support/docview.wss?uid=nas8N1018931

Post back with additional info if you like. Might be able to provide additional specific guidance.

Scott Lewis

ASKER

Hi Gary, thanks for the feedback. I also have seen this in different shops but not this bad. I will step through your list and will report back results. I have a company I partner with for sysadmin stuff and I will share your ideas with them.

Scott Lewis

ASKER

I did write a program to handle the ending immed...varying and restarting. My operators are happy for now. I am still pursuing the other points as I have time. I checked with our network admin and there are no firewalls between the i and the printers.

Gary Patterson, CISSP

If the problem frequently happens with the same printers, suggest next step is to pick one that supports SNMP or IPP and reconfig it from PJL to SNMP or IPP, and see if that has an impact.

Scott Lewis

ASKER

Sounds reasonable. I have reached out to the person that handles printers on a day to day basis to see what their problem printers are. And I'm checking with ACOM because that is software that handles our special forms.

ASKER CERTIFIED SOLUTION

Scott Lewis

membership

This solution is only available to members.

To access this solution, you must be a member of Experts Exchange.

Start Free Trial