Novell is now a part of Micro Focus

Tracking Down Print Corruption

Articles and Tips: tip

Contributed by Novell Services and Support

01 Feb 1996


This information is based on TID (Technical Information Document) 1000476 and applies to NetWare versions 2.2, 3.11, 3.12, and 4.02.

Print corruption can be defined broadly as "unexpected output from the printer." Corruption can manifest itself as no characters, extra characters, incorrect characters, extra pages, incorrect formatting, error messages, blinking lights on the printer, or no printing at all.

A basic methodology for troubleshooting print corruption problems consists of ten steps, shown in Figure 1.

Figure 1: Ten-step method for troubleshooting print corruption.

Step 1: Check the obvious.

Start by checking the following "obvious" causes of printing problems:

  1. Make sure there are no IRQ or I/O address conflicts with the printer port.

  2. Make sure you have tried both the polled option and the correct IRQ configuration when defining the printer in the PCONSOLE utility.

  3. Make sure you set the No Tabs, No Banner, and No Form Feed options when printing with MS Windows, CAPTURE.EXE, and NPRINT.EXE.

  4. Make sure the LPT (parallel printer) cable is not longer than 3 meters (9.8 feet).

  5. Use parallel or serial ports on the computer's system board, if at all possible.

  6. Remove any third-party print buffer products or cable extenders.

Step 2: Eliminate print configuration files.

The corruption could be caused by something wrong in the user's print job configuration file. To eliminate this as a possible cause, follow the steps outlined below.

  1. For users on a NetWare 2.x or 3.x server, the file is named PRINTCON.DAT and it is found in the SYS:MAIL\<USERID> directory. Rename this file to PRINTCON.OLD.

  2. For users on a NetWare 4.x server logged in as bindery users, the file is named PRINTJOB.DAT and it is found in the SYS:MAIL\>USERID> directory. Rename this file to PRINTJOB.OLD.

  3. For users logged in as an NDS (NetWare Directory Services) users on a NetWare 4.x server, there could either be a print configuration definition for the user or for the container where the user enters the tree. You can see the definition by using the NWADMIN.EXE or PRINTCON.EXE utilities. If the print configuration definition is present, make sure it isn't designated as a "default" print configuration. If it is, simply unmark the definition as the default. You can do this by using PRINTCON.EXE as follows:

    1. Type PRINTCON <Enter> at the workstation prompt.

    2. Select the "Change Current Object" option.

    3. Press the Ins key.

    4. Walk the tree until you locate the correct container.

    5. Highlight the user or container object and press the F10 key.

    6. Select the "Select Default Print Job Configuration" option.

    7. Highlight the print job configuration that has an asterisk by it.

    8. Press the Del key.

    9. Escape out of the PRINTCON utility and save changes if asked.

  4. There could also be a PRINTCON.DAT or PRINTJOB.DAT file in the SYS:PUBLIC directory or anywhere in the search path. To locate these files, user the NDIR command as follows:

    1. For NetWare 2.x and 3.x, change to the root level on volume SYS and type NDIR PRINTCON.DAT /SUB <Enter> at the command line.

    2. For NetWare 4.x users logged in under bindery mode, change to the root level on volume SYS and type NDIR PRINTJOB.DAT /SUB <Enter> at the command line.

    Ignore any PRINTCON.DAT or PRINTJOB.DAT files that are in the SYS:MAIL\ <USERID> directories. If you find a PRINTCON.DAT or PRINTJOB.DAT file anywhere else, rename it to PRINTCON.OLD or PRINTJOB.OLD for now.

    Note that you'll find PRINTCON.DAT or PRINTJOB.DAT files outside of the user's mail directory only if the CAPTURE or NPRINT utilities have been configured using a non-default SMODE setting in the user's NET.CFG file. By default, the CAPTURE and NPRINT utilities only look for the PRINTCON.DAT or the PRINTJOB.DAT file in the user's mail directory.

Step 3: Print to a file and see if that file prints.

Many applications allow you to send the print output to a file rather than to a printer port. You can also use the NetWare CAPTURE command to do this. For example, to send the print output to a file named GOODFILE.EXT, type CAPTURE CR=f:\public\goodfile.ext NT NB NFF TI=60 <Enter> and then print as you normally would in your application.

If you are using Windows, try printing to the LPT1.DOS device instead of LPT1. To do this, go into the Control Panel and follow these steps:

  1. Double-click on the "Printers"" icon.

  2. Make sure there isn't an X in the "Use Print Manager" box.

  3. Select the proper printer driver in the Installed Printers list. Avoid printer emulation of a different printer. For example, don't choose the Apple LaserWriter driver if you are printing to an HP LaserJet IIISi PostScript printer. Even though both printers can handle PostScript, they initialize differently.

  4. Click on the "Connect" button.

  5. Scroll down the Ports list and select either "LPT1.DOS" or "FILE." When you select LPT1.DOS, you are actually printing to a file named LPT1.DOS. If you select FILE, you won't be prompted for a filename until you print in the Windows application.

  6. Make sure there isn't an X in the "Fast Printing Direct to Port" box.

  7. Click on the "Network" button.

  8. Select the printer button on the button bar at the top of the NetWare Printer Connections window..

  9. Look through the Ports list. If any of the LPT ports show a small printer icon to the left of the port name, it means that the logical LPT port capture is set permanently. You don't want this feature active at this time. To make the capture non-permanent, highlight the LPT port and click on the "Permanent" toggle button at the bottom of the window.

  10. Click on the "LPT Settings" button.

  11. Make sure the following boxes don't have an X in them:

    1. Enable Tabs

    2. Enable Banner

    3. Form Feed

  12. Print as you normally would from your Windows application. The output will go to the specified file rather than to the printer.

Now try to print the file you just created. If the output comes out okay, something in the print configuration is not set correctly. Check the escape code sequences defined in the NetWare PRINTDEF utility. Also recheck the CAPTURE/Windows environment. Having tabs conversion enabled is a very common cause of corruption, as is trying to use a text banner on a PostScript printer.

Step 4: Make sure the file prints locally.

If the job is still corrupt, it's time to see if the job will print directly from the application to a locally-attached printer. To do this, attach the printer directly to the appropriate port on a network workstation. Issue an ENDCAP (NetWare 3.x) or CAPTURE /ENDCAP (NetWare 4) command to cancel print job redirection. Then see if you can print the job from the application without any corruption.

If the corruption persists, you need to take out the application part of printing. Print to a file called GOODFILE.EXT from the application, as explained in Step 3. Then from the network prompt, go to the directory that contains GOODFILE.EXT and enter TYPE GOODFILE.EXT >LPT1 >Enter>. If this file doesn't print as expected (no corruption), either the application's print driver or Windows print driver is corrupt and is not sending the print job to the printer correctly. Reinstall the print driver and try again.

If you have the same problem on other workstations if you attach the printer to them, either the printer cable is faulty or the printer itself is not working correctly. Try replacing the printer cable, making sure it is the right length (see Step 1). If necessary, send the printer to be repaired.

If local printing works, move the printer back to the NetWare environment (reattach the printer to the file server or to a workstation running the remote printer software) and continue with the next procedure.

Step 5: Put the print queue on hold.

Steps 5 through 10 describe a technique that has proven very effective in detecting print job corruption. The first thing you need to do is put a "hold" on the print queue. For NetWare 2.x or 3.x servers, perform the following steps:

  1. Enter the PCONSOLE utility.

  2. Select the "Print Queue Information" option.

  3. Select the print queue that the printer is servicing.

  4. Select the "Current Queue Status" option.

  5. Set the "Servers can service entries in queue" entry to No.

  6. Press Escape until you are back at the Available Options menu.

If you are running the NetWare 4.x printing software, perform the following steps:

  1. Enter the PCONSOLE utility.

  2. Select the "Print Queues" option.

  3. Select the print queue that the printer is servicing.

  4. Select the "Status" option.

  5. Set the "Allow service by current print servers" entry to No.

  6. Press Escape until you are back at the Available Options menu.

    You also need to find out the print queue ID. To do this, perform the following steps:

  7. Select the "Print Queue Information"option (NetWare 2.x/3.x) or the "Print Queues" option (NetWare 4.x).

  8. Select the print queue you are concerned with.

  9. Select the "Print Queue ID" option (NetWare 2.x/3.x) or the "Information" option (NetWare 4.x).

  10. Write down the print queue (object) ID.

  11. Exit the PCONSOLE utility.

Step 6: Send the good file to the print queue.

Now you need to send the good file that printed fine locally (GOODFILE.EXT) to the print queue. To do this, first type CAPTURE Q=<queue name> NB NT NFF <Enter> at the network prompt. Then enter TYPE GOODFILE.EXT > LPT1 <Enter> to send the file to the queue.

Step 7: Compare the print job in the print queue with the good file.

To do this, go to the print queue directory in the following locations:

  • On a NetWare 2.x server, the path is SYS:SYSTEM\<QUEUEID>.

  • On a NetWare 3.x server, the path is SYS:SYSTEM\<QUEUEID.QDR>.

  • On a NetWare 4.x server, the path is <volume>:QUEUES\<QUEUEID.QDR>. If this is an upgraded NetWare 3 server, the volume will be SYS.

Type DIR in the print queue directory and you will see a file (now referred to as a print job) with a hexadecimal name and an extension of ".Q" (for example, 05160001.Q). Compare the GOODFILE.EXT DOS file with the print job file in the queue. With MS-DOS 6.x or Novell DOS 7, use the following syntax:

FC GOODFILE.EXT PRINTJOB.Q /B

If the two files are not exactly the same, the corruption is occurring somewhere between the workstation and the print queue.

Step 8: Remove the hold from the print queue and print the print job.

If the two files are the same, you should next remove the hold from the queue and allow the print server to service the queue. The procedure for doing this is the same as that given in Step 5, except this time you set the "Servers can service entries in queue" entry to Yes in Step 5E.

If the print job prints without errors, either the application's print driver or Windows print driver is corrupt and is not sending the print job to the printer correctly. Reinstall the print driver.

Step 9: Salvage the print job in the print queue.

If the print job is still corrupt, try salvaging the print job file back into the queue (this can't be done on a NetWare 2.x server) so you can run another file comparison. To salvage the file on a NetWare 3.x server, perform the following steps:

  1. From the print queue directory, type SALVAGE <Enter> at the network prompt.

  2. Select the "View/Recover Deleted Files" option.

  3. Use the search pattern "*", which is the default.

  4. Select the newest file, which is the file with the newest date and time.

  5. Answer "Yes" to recover this file.

  6. Exit the SALVAGE utility.

On a NetWare 4.x server, salvage the print job file by performing the following steps:

  1. From the print queue directory, type FILER <Enter> at the network prompt.

  2. Select the "Salvage Deleted Files" option.

  3. Select the "View/Recover Deleted Files" option.

  4. Use the search pattern "*", which is the default.

  5. Select the newest file, which is the file with the newest date and time.

  6. Answer "Yes" to recover this file.

  7. Exit the FILER utility.

Step 10: Compare the salvaged print job in the queue with the good file.

At this point, perform another DOS file compare as explained in Step 7.

If all efforts thus far have not shown where the corruption is coming from, it must be a printer hardware or communication problem: bad cable, wrong pin-out for the cable, bad port, or bad printer. There could be a third-party printer buffer between the printer port and printer that is causing problems.

Besides the no tabs and no banner issues, faulty hardware is the most common source of corruption. In many cases attaching the printer to a different port will solve the problem.The preferred port to use is a port on the system board. Avoid using multi-port I/O cards if at all possible.

If the printer is on a workstation using RPRINTER/NPRINTER, there could be network communication problems. Check for the latest LAN drivers on the workstation. There could also be TSR or memory manager conflicts with the printing software. Make the workstation as "plain vanilla" as possible that is, nothing loaded high, no memory managers other than HIMEM.SYS if the workstation is running Windows, and no loading other TSRs except those needed for the LAN adapter to communicate with the network.

Sometimes the printer is on the network using a third-party printing solution (such as JetDirect, Netport, Castelle, and others) that is configured in a Print Server/Queue Server mode. If you suspect these are the source of your problem, contact the manufacturer especially if you are running them on a NetWare 4 network. Most of the time the third-party product isn't configured properly, or you may need to get updated drivers that are NDS aware. Refer to the third-party documentation for installation and NetWare 4 Directory Services issues.

If the third-party product is in RPRINTER/NPRINTER mode, there could be a network communication problem, or the printing device may not be configured correctly.

* Originally published in Novell AppNotes


Disclaimer

The origin of this information may be internal or external to Novell. While Novell makes all reasonable efforts to verify this information, Novell does not make explicit or implied claims to its validity.

© Micro Focus