              FPServer: THE Fast Novell NetWare Print Server
                                Version 5.1
                Problems and Solutions File (PROBLEMS.TXT)
            ==================================================
                           Skillnet Corporation
                 Novell Registered Professional Developer
             915 West Second Avenue, Spokane WA 99204-1598 USA
                     www.fpserver.com   ftp.fpserver.com
                   509-744-0900 Voice   509-744-0909 Fax
                76350,2275 CompuServe   mail@fpserver.com


===========================================================================
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.
