Previous Table of Contents Next Step 1: Check the Application Your first step when facing a printing problem will be to check the application. Although this sounds rather silly, I see a lot of printing problems where, say, a database is producing no output for the spooler to process. One would think that the database manufacturer might clue the user in that his or her report parameters produced no output, but that's not always the case. (You can always disable the queue and print again to see whether a job is even being generated.) ______________________________________________________________ This might sound crazy, but check to make sure that a Windows 95 user has logged in to the network before you do any of these steps. Windows 95 allows a user to bypass the login window by pressing Esc; therefore, a user might be trying to print to a network printer without being logged in to the network. ______________________________________________________________ More complex problems can occur when an application is either improperly configured or has DLL problems that do not manifest themselves in other ways. For example, I have seen an application that needed special DLLs to print a file; when these DLLs were corrupted, either by another application installing its own versions of these DLLs or by simple hard drive problems, the application stopped printing, even though it otherwise behaved flawlessly. You can find out whether the printing problem stems from the application by printing from another application-for example, Notepad or the WordPad. In UNIX, type the following to check printing outside of a given application: lp -dprintername /etc/services Step 2: Check the Driver If two programs on a given workstation are not printing, I like to introduce another printer into the picture. In particular, I like to set up a local printer with a destination of LPT1. If the workstation has no printer attached to LPT1, don't despair-just set it up with a destination of FILE, which will simply direct the output to the hard drive. You can then view that file and make sure it's okay. ______________________________________________________________ To make sure that the print file is actually okay, you can transfer it to another workstation that does have a printer directly attached and then type something such as this: copy /b PRINTFILE LPT1: ______________________________________________________________ To rule out driver problems, make sure to use a different driver for your test printer. I like to use "Generic/Text only" for some things, but, of course, this won't work too well if your application is graphical. Because you're ruling out the driver, it doesn't really matter which print driver you use, as long as you're fairly confident that it's a good driver. ______________________________________________________________ Sometimes, even though you have a good driver, your workstation might be running out of gas while the driver is processing the metafile. Check the resources as we discussed in Hour 8, "Hard Basics: Guide to Being a Hardware Geek." ______________________________________________________________ Step 3: Check the Spooler Can someone else spool to the server queue? If so, your first guess might be that the problem lies with the workstation. In this case, I want to make darn sure that the printer, as set up on the workstation, is going to a valid queue and has not lost its mind. To do this, I usually go ahead and set up another printer on this workstation-pointing to the correct server queue-just to make sure. If that doesn't work, I set up another queue to another server, just to prove that queuing is messed up on this workstation. If this works, it means that the problem might not lie with the workstation; you've probably got some sort of communication or security problem between this workstation and the original server queue. Check whether you can see the server in any other way: Can you log in to it? Ping it? Check your security rights to this queue, or, even better, try to spool to it as someone else. Step 4: Check the Server The server might show that it's getting the spool file just fine-whereupon the output just disappears into thin air. A couple things might cause this that aren't limited to communication errors between the workstation and the server. In this case, you might want to rule out a communications problem. One way you can verify that the server is getting passed a good spool file is by taking a look at it at the moment the server gets it. You can do this by putting the printer in question offline, because the server will delete the spool file after it thinks the printer has processed it. Because you're blocking the printer, spool files will be left alone. You can then take a gander at the spool file that's being passed to the server. Where does the spool file live? Table 18.1 gives you an idea. CAPTION: Table 18.1 Spool File Locations _________________________________________________________________ Operating System Spool Files Kept In _________________________________________________________________ Windows 9x %WINSYSDIR%\spool\printers\jobnum.spl Windows NT %SYSTEMROOT%\system32\spool\printers\jobnum.spl (Intra)NetWare QueueVol:SYSTEM\QUEUENUM.QDR UNIX /usr/spool/lp/temp (actual queue files) /usr/spool/lp/requests (control files) _________________________________________________________________ Previous Table of Contents Next