FPServer: THE Fast Novell NetWare Print Server Version 3.4 Problems and Solutions (PROBLEMS.TXT) ================================================== Richard L. Hartman Novell Registered Professional Developer 5205 North Mulvaney Court, Spokane WA 99212-1611 509-924-6576 Voice 509-926-4626 Fax 76350,2275 CompuServe rlh@iea.com Internet =========================================================================== PURPOSE OF THIS FILE =========================================================================== This file describes many common network printing problems and their solutions. While this file ships with FPServer, most of the problems are not specific to FPServer and can occur with any network printing utilities. You may locate a reference to a particular problem by thinking of words which describe it (other than cursing!) and performing a text search. Since there may be more than one problem which references a given keyword, you may have to perform several searches to find the problem you are seeking. This file may be updated at any time - network printing problems do not wait for the next revision of FPServer! =========================================================================== General List of "Things to Check" =========================================================================== Here is a general list of things to check when encountering problems. If you do not find an obvious problem here, move on to the more specific problems and solutions later in the file. * Do NOT use VLM's on a dedicated print server PC * Do not use other utilities or TSR's, such as keyboard stuffers, screen savers, etc. on dedicated print server PC's * Memory management utilities such as HIMEM.SYS and EMM386.EXE may be used, but will probably not improve printing performance * Do not leave LPTxTEST= commands in your FPSERVER.CFG file unless you are actually running a test * Be sure to run the QRIGHTS.EXE utility on each and every print queue to be serviced by FPServer =========================================================================== Jobs print OK, then "stall" on the Current line Some or all of job transmits "instantly", but nothing gets printed FPServer locks up when job appears in the queue VLM's are loaded on FPServer's host PC ...and MANY other problems =========================================================================== As of the date of this file, there is STILL a bug in the VLM's which affects Print Services. This bug has been reported by hundreds of sites worldwide and causes many different effects. Some of the most common are: Jobs which print correctly but then "stall" and must be deleted manually; print server lockup when jobs are sent to the queue; and runaway traffic on the network. Novell personnel have acknowledged that the bug exists, but have not given a date when a solution will be available. The only 100% reliable solution is to remove the VLM's and use NETX.EXE. VLM's should NOT be used on any PC which hosts a shared printer. If a PC is connected to a printer which can be accessed by other network users, use NETX.EXE as the network shell. This is true whether the PC is being used as a dedicated print server host (FPServer, Novell's PSERVER) or someone's workstation (RPRINTER). =========================================================================== FPServer's PC Keeps Rebooting =========================================================================== FPServer will reboot the host PC if the network shell reports problems communicating with the file server. However, certain conditions can "fool" the shell into assuming problems that don't really exist - and this can cause FPServer to needlessly reboot the host PC. You can tell the shell to be more tolerant of non-fatal network and cable problems by including the following lines in the PC's NET.CFG file (sometimes called the SHELL.CFG file): IPX RETRY COUNT=100 SPX ABORT TIMEOUT=2000 SPX LISTEN TIMEOUT=500 SPX VERIFY TIMEOUT=200 After making these changes, you must manually reboot the PC so that the network shell will read the file and take your adjustments into account. The shell will display the above lines on the screen during bootup to confirm that they have been processed. Please refer to your Novell NetWare installation manuals for complete information regarding the NET.CFG file. =========================================================================== Short Jobs Print Successfully, But Long Jobs Fail =========================================================================== TEST mode, if left enabled, may allow short jobs to print successfully but cause longer jobs to fail. Be sure that TEST mode is not in effect. (Hint: There should NEVER be a TEST mode command in your FPSERVER.CFG file during normal operation.) The bug in Novell's VLM's can cause long jobs to be corrupted or lost. Be sure that VLM's are NOT loaded on any PC's acting as dedicated print servers. =========================================================================== Security Concerns Leaving Print Server Logged In as Supervisor Logging In To Network Prior to Starting FPServer =========================================================================== FPServer does NOT require that the PC be logged in to a file server before you start the FPSERVER.EXE file. The normal sequence of events in the print server PC's AUTOEXEC.BAT file is to load the network interface card's driver, load the network shell, and run FPSERVER.EXE. And that's all. If you must log in to a file server before running FPSERVER.EXE (for example, if you're using a diskless workstation as a print server), you may do so. While FPServer does not require the PC to be logged in, it also does not PREVENT it. But under most circumstances, logging in is neither necessary nor recommended. And a PC that can log in to a normal user account without someone supplying a password presents something of a security risk. UNDER NO CIRCUMSTANCES should you allow a print server PC log in as Supervisor "automatically". This is a SERIOUS breach of network security that invites abuse, tampering, and disaster. FPServer does NOT require this. And no OTHER professional-caliber software should require it, either. For reassurance, here is a review of FPServer's login/logout behavior: * Upon startup, the very first thing FPServer does is log the PC out of any and all file servers, just in case someone WAS logged in when they started FPSERVER.EXE. * Next, FPServer logs in to the file server(s) specified in the FPSERVER.CFG file (or the command line) under the specified print server account name(s). * During operation, Ctrl-Alt-Del and Ctrl-Break are disabled so no one can "terminate to DOS" and leave the PC logged into the print server account(s). * When FPServer is terminated, it logs out of all file servers and leaves the PC completely logged out, but ready to be logged in manually. As the above description shows, FPServer works very hard to preserve security and make sure no one gains unauthorized access to the network. =========================================================================== Printing Works, but Delete/Restart/Prioritize Does Not =========================================================================== This happens when the QRIGHTS.EXE utility has not been run on the queue(s) being serviced by FPServer. QRIGHTS.EXE, which is included with FPServer, must be run, one time, on each and every queue to be serviced by FPServer. QRIGHTS.EXE sets the rights necessary to enable FPServer's higher order functions (job delete, restart, and prioritize). Without running QRIGHTS.EXE, FPServer will still be able to service print jobs - but its delete, restart, and prioritize functions will not work. If you find it necessary to delete a print queue, you will also delete the changes that QRIGHTS.EXE puts into place. If you then recreate the print queue, you must run QRIGHTS.EXE on it again. Please refer to the QRIGHTS.TXT file for more information. =========================================================================== Print Server Stops when Booting with QRIGHTS.EXE =========================================================================== QRIGHTS.EXE does NOT need to be run each time you run FPServer. You do not need to place QRIGHTS.EXE in the print server's AUTOEXEC.BAT file. Doing so will force you to press a key every time the PC reboots, since QRIGHTS.EXE must be logged in as Supervisor and will complain if it is not. QRIGHTS.EXE only needs to be run ONE TIME on each print queue to be serviced by FPServer. Please refer to the QRIGHTS.TXT file for more information. =========================================================================== PostScript Job Doesn't Print =========================================================================== The most common cause of this problem is sending non-PostScript data to the printer, often because the wrong printer driver has been selected. For example, selecting a standard Hewlett Packard LaserJet driver will generate PCL, rather than PostScript, data when the job is sent to the print queue. When a PostScript printer receives non-PostScript data, it discards it immediately. If the print job contains no valid PostScript data at all, the entire job is discarded and nothing is printed. The result can appear as a job which is "printed" VERY quickly, and yet produces no output! If this appears to be happening, confirm that the printer driver being used does, in fact, generate PostScript data. Next, print the data to a file instead of a network print queue, and examine it with a text editor. A PostScript file will be more "human readable" than a PCL file. PCL files will contain sequences like "&180t70P", whereas PostScript will contain (semi-) normal words and number values. =========================================================================== Upgrading to Newer Versions of NetWare =========================================================================== The standard rule of thumb when upgrading is to delete all existing print server objects and print queues, then recreate them using the new tools which shipped with the newer version of NetWare. There have been many, many documented cases of print-related objects not transferring successfully from one version to another. Save yourself the grief - take the time and just recreate them from scratch. =========================================================================== My Application is Done, but the Print Job Doesn't Start Printing Jobs Print Without Selected Fonts, Formatting, etc. CAPTURE and PRINTCON Timeout Problems =========================================================================== If your application is "done printing", but the job doesn't actually start transferring to the printer for quite a while, chances are the application is not formally initiating and terminating the print job. This can also cause your printer to print your job in "default" fonts and formats, even though you have selected all types of special formatting. There are basically three ways an application can send a print job to a network print queue: Formally send the job to the queue (best); open the DOS device named LPT1, write to it, and then close the device (OK), or just start sending bytes to "LPT1" until all bytes have been sent (poor). The first two methods are the best, because there is a definite start and stop to the print job. Since the network is formally notified when the job is finished, it can begin servicing the job as soon as it is complete. The third method, however, is haphazard because there is no formal notification when the print job is complete. This is why the CAPTURE and PRINTCON timeout exists - the only way the network can guess when the job is finished is when enough time has elapsed after what appears to be the "last" byte. If the timeout is set too long, the network will wait needlessly for additional bytes of print job data that do not exist. Eventually, the timeout will elapse and NetWare will finally allow FPServer to begin servicing the print job. A timeout which is too large is mostly an annoyance. You'll end up waiting longer than necessary for your print jobs to start, but they'll probably be printed successfully. If the timeout is set too short, any little pause taken by the application during printing may be misinterpreted by the shell as the "end of job" - and cause the network to cut the job off at that point. Subsequent bytes of data are then treated as a separate print job... in extreme cases, one printout with a few delays can generate several small, separate print jobs! Short timeouts are not just an annoyance - they can cause print job corruption. For example, assume you have selected special formatting or downloaded fonts. Your applications software will probably send those to the printer first, before any "printable" data. Then your application will begin composing pages and sending actual print data. If your application pauses between pages or sections of pages (and many do), the delay may be long enough to "fool" a short timeout into thinking that the job is finished. Everything up to that point will print correctly. But the next section or page to be printed will probably not be what you expect, for any of several reasons. For one thing, the printer may have printed everything it received up to that point and then ejected the page, which means the next section will end up on a different sheet of paper. Another common result is that the printer may be reset between print jobs. This means that all of your application's special setup data at the start of the printout is cancelled and does not affect the rest of the job. The application does not know that the timeout caused its printout to be treated as two jobs, so it does not bother to send setup information twice. You end up with a printout that is split into multiple sections, none of which are formatted correctly. Choosing a timeout value is a matter of compromise. Good starting values are from 30 to 45 seconds; you can fine-tune as you gain experience with your particular combination of PC's, applications, and network performance. =========================================================================== Jobs Take Forever to Start Printing =========================================================================== Delays from hitting "Print" to starting transfer of data to printer are often caused by application not formally terminating output of print data. This can be confirmed with Novell's PCONSOLE utility. From a separate PC, set up PCONSOLE to watch the queue in question. Then tell your application to start printing the job. The job will appear with a status of "Adding" as the application dumps data into the queue. When your application has finished printing, look at the PCONSOLE display again. If the job is still shown as "Adding", your application has not formally terminated the print job. The job will thus be dependent upon the timeout value set with your CAPTURE command. Eventually, the timeout will occur and the job status will change from "Adding" to "Ready". =========================================================================== Jobs Disappear When Printer is Turned Off =========================================================================== The parallel ports on many printers allow their hardware handshaking lines to "float" to illegal levels when the printer is turned off. This situation can appear exactly like a very high speed printer which never says "stop" - it just takes data as fast as the print server can send it. (The Hewlett Packard LaserJet 4 does is one example.) In this situation, the print jobs are not actually disappearing. They are actually "printing" at super-high data rates to a printer that is turned off! The end result is the same, however... the job is there for a moment, then vanishes when it is "done". Unfortunately, poor standardization of "Centronics" parallel ports has resulted in no clearly accepted method for confirming that a printer has power applied. In researching this problem, I found at least three different ways that printers "indicate" they have power. In other words, there is no 100% foolproof solution. =========================================================================== Graphic Jobs are Corrupted =========================================================================== If pure text jobs print fine, but jobs which contain graphics are being corrupted, it is very likely that the CAPTURE statements have left banners and tab translation enabled. Review the CAPTURE statements and confirm that the NB and NT command line switches are being specified. If you are using PRINTCON job configurations, make sure "No Tabs" and "No Banner" are selected. CAPTURE timeouts which are too short can cause graphics corruption, too, by allowing a single printout to be split into multiple queue jobs and separating graphics data from their associated setup and header commands. Review the "Timeout" section elsewhere in this file for more information. =========================================================================== Jobs Sent to Imagesetter are Corrupted =========================================================================== Some imagesetters - the Varitype/AM Int'l 4990 in particular - have parallel ports whose BUSY line is not asserted until after data loss has already occurred. Engineers at the Varitype company report that they purchased OEM controllers from Adobe Corporation (the PostScript people) for use in their imagesetting equipment, and Adobe's controllers contained an error in their parallel port hardware design. There is no fix. Controllers with this design error may lose data at high transmission rates. The only solution, ironically enough, is to use a SLOWER dedicated host PC or to switch dual-clock PC's to their lower clock speed. =========================================================================== FPServer Acts as if no SoftKey is Present =========================================================================== Command-line portQUEUE= commands override the FPSERVER.CFG file. If your SoftKey(s) are in the file, but you are using command line arguments to override the file, you MUST include the SoftKey(s) in the command-line portQUEUE= commands as well or they will cause FPServer to terminate after the demo period. Another possible problem relates to batch files. If you are starting FPServer from a batch file, remember that the DOS command line is limited to 127 characters. If a SoftKey appears near the end of the command line, and the line exceeds 127 characters, the SoftKey will be truncated and cause FPServer to terminate after the demo period. =========================================================================== Leading Edge Model D Doesn't Work =========================================================================== Leading Edge Model D PC's appear to be incompatible, even with latest Phoenix replacement BIOS. Extensive testing has found no way to make these computers compatible with FPServer. =========================================================================== Serial Printer Losing/Corrupting Data Serial Printer works in DOS, but not with FPServer =========================================================================== Some serial printers can have their ports set at a fast baud rate, but cannot actually accept bytes back-to-back. The reason is based on the difference between "baud rate" and "throughput". "Baud rate" refers to the speed at which individual bits are transmitted over a serial line. 9600 baud means that 9600 bits can be transmitted per second. With eight bits to a byte, plus start, parity, and stop bits, each byte can take up to 11 "bit times" to transmit. Most printers use a UART (a dedicated serial transmit/receive chip) to handle this high speed bit work. Once a full "start+data+parity+stop" group is received, the UART must interrupt the printer's microprocessor to process the new byte. If a subsequent byte is received before the first one is completely processed, either of the bytes may be lost. This is known as a framing or overrun error. "Throughput" refers to the total number of bytes that can be received in a given amount of time (usually one second). While the baud rate is set by the printer's UART, the printer's processor sets the throughput limit. And while the UART may be able to accept 9600 bits per second, the printer's CPU may NOT be able to handle nearly a thousand interruptions per second. In theory, serial handshaking will prevent data overruns. But at high baud rates, and with FPServer's ability to send serial bytes back-to-back, the printer's processor may not have enough time to send the handshaking signal before overrun occurs. This is also the reason that FPServer can be having serial problems, but the DOS COPY command will successfully send a file to the printer at the same "baud rate". While the BYTES are going out at the specified "baud rate", there is a lot of dead time between the bytes (DOS is no speed demon!). And that dead time gives the printer's processor enough time to process each byte before the next one comes in. The solution is to slow down the baud rate until the printer's processor can keep up with the incoming data. If you are having problems at 9600 baud, try slowing down to 4800 to give the printer's CPU a little more time to process each byte. In most cases this isn't really a problem; you won't suffer any real printer throughput loss. If the printer's microprocessor cannot handle fast data, the printer itself is probably limited too. (Manufacturers don't slow down fast printers with slow CPU's.) As an example, some older dot-matrix printers won't run reliably above 2400 baud - which is still fast enough, since 2400 baud is roughly 240 characters a second and the printers are rated at 200 CPS or less. =========================================================================== Jobs Visible in PCONSOLE, but Not Being Serviced by FPServer =========================================================================== Jobs may be visible in a queue, but be "skipped" by FPServer while other jobs in the same queue are serviced without incident. Some of the reasons for this behavior include: * PRINTCON job configurations may be requiring a specific print server. Check the "Print Server" field of PRINTCON's edit screen and confirm that "Any" print server may service the job. * The job's print date and/or time may be set to the future. PCONSOLE can display and edit the print date and time. * The application generating the job may not be finished creating it. (PCONSOLE shows the status of such jobs as "Adding".) NetWare will not allow FPServer to begin printing a job until it is 100% complete and in the queue, ready to be serviced. =========================================================================== Job sits on "Current" line, display shows PAPER OUT, "0 bytes sent" =========================================================================== This can occur when FPServer is configured properly, and everything is fine - except that the printer cable is plugged into the wrong connector on the back of the host PC! All of those DB-25 connectors look similar from the outside of the enclosure. Many users have reported this problem, and upon investigation discovered that they had accidentally plugged the printer into LPT2 when they meant to use LPT1, etc. FPServer's response in this situation is to grab the next print job, get ready to service it, then wait for the printer to accept data. Since no printer is connected to the port, the "printer" is NEVER ready... and no data is ever sent (hence the "0 bytes sent" display). The "PAPER OUT" message appears because the hardware status lines on the connector are also disconnected. There are several hardware-related messages which can be displayed; PAPER OUT is just the highest priority. =========================================================================== AT&T 6300 has Video Problems =========================================================================== The AT&T 6300, a very popular PC from the mid-80's, has bugs in its original BIOS which affect video operation. AT&T has solved those and released a new BIOS, Version 1.43, which can be installed by end users. Dial 800-645-8684 and order part number 105-203-7800, for which AT&T will charge $33.00 plus tax. The kit includes two EPROM's and a PAL, plus instructions. Once they have the new V1.43 BIOS, AT&T 6300's make great print servers when running FPServer. =========================================================================== Unreliable Network Connection, Problems during Startup =========================================================================== The most common problems involving networks are interrupt (IRQ) and I/O address conflicts. Network interface card (NIC) I/O addresses are a classic problem. Most NIC's require a 16 byte address range that starts at some selectable base address. That means, for example, that if you switch your NIC to address 360h, it actually consumes addresses 360h through 37Fh. However, LPT1's standard address range is 378h-37Bh, right in the middle of the NIC's range. This situation is virtually guaranteed not to work. Here are the address ranges used by standard parallel and serial ports: LPT1: 378h-37Bh LPT2: 278h-27Bh LPT3: 3BCh-3BFh COM1: 3F8h-3FFh COM2: 2F8h-2FFh COM3: 2E8h-2EFh COM4: 2E0h-2E7h Assuming that NIC's use 16 bytes beginning at the address you specify for them, you can use the above chart to make sure your NIC's do not conflict with the I/O range consumed by your parallel and serial ports. (Note: Other devices in your PC may consume additional address ranges, so the above chart is not 100% inclusive of all possible conflicts.) As a general rule of thumb, 300h is a reasonably safe address to use when installing a NIC. Keep in mind, however, that many manufacturers of OTHER hardware cards know that, too, and recommend 300h as THEIR default. Interrupts are another area of conflict. There are very few open IRQ lines in most PC's. Fortunately, FPServer does not require IRQ lines for its parallel and serial ports, so you can use IRQ's normally reserved for ports IF YOU MAKE ABSOLUTELY SURE THE PARALLEL AND SERIAL PORT CARDS ARE NOT JUMPERED TO USE THEM. Some parallel and serial cards will not allow you to defeat the use of their interrupts, so you may not be able to use those interrupts for other purposes. Try to configure NIC's to use interrupts above 9. No standard parallel or serial ports use IRQ's in the upper ranges, so this will assure that you avoid conflict with them. =========================================================================== When All Else Fails: Here are some WEIRD ones =========================================================================== Two users have reported the following: A NetWare 2.x file server crashes for some reason. Afterward, FPServer appeared to attach successfully but timed out after 20 minutes even with a previously workable SoftKey. Upon investigation, it was found that the NetWare serial number was reporting 00000000! Deleting and recreating the queue fixed the problem. No one knows how or why the print queue affected the NetWare serial number. One user reported the following: A Hewlett Packard LaserJet 4 reporting Error 40 was fixed by putting a MODE command in the AUTOEXEC.BAT file to set the baud rate of the serial port prior to starting FPServer. The only explanation anyone has thought of is that some versions of MS-DOS contained MODE commands which were unique to special hardware in the system (Sperry shipped some PC's this way). The MODE command may have been initializing special hardware associated with the serial ports that industry-standard serial ports do not possess.