Monster Media 1993 #2/Image.iso/lan/fps32d.zip/FPSERVER.DOC

Text File | 1993-07-12 | 139KB | 2,988 lines

              FPServer: THE Fast Novell NetWare Print Server
                                Version 3.2
                     Documentation File (FPSERVER.DOC)
           ====================================================
                         Richard L. Hartman (RLH)
                 Novell Registered Professional Developer
             5205 North Mulvaney Court, Spokane, WA 99212-1611
     509-924-6576 (Voice)   509-926-4626 (Fax)   CompuServe 76350,2275


===========================================================================
INTRODUCTION
===========================================================================

FPServer implements an EXTREMELY FAST, easy to use print server on a
standard IBM compatible personal computer.  In this manner, it is very
similar to Novell's own PSERVER.EXE.  However, unlike Novell's product,
FPServer has been optimized for ultra-high data throughput and ease of
control.

I carry out a great deal of research in the area of network printing.  I
have spoken with equipment manufacturers, dozens of Network Administrators,
and hundreds of users to obtain an understanding of what is important in a
networked printing environment.  FPServer is one result of this research:
THE definitive print server for Novell NetWare networks.

This file contains background information, a description of FPServer's
features, a complete command list with examples, and technical data on
design and architectural decisions.  There is a lot of data here, and it
does not have to be read sequentially.  Feel free to "scan around"!



===========================================================================
BACKGROUND (WHY IT EXISTS)
===========================================================================

FPServer is a high-speed alternative to "black box" print servers,
in-the-printer print server interfaces, and Novell's PSERVER.EXE.
FPServer's primary design goal is ULTRA-HIGH DATA THROUGHPUT; its secondary
design goal is EASE OF USE.

With all due respect to Novell (they write excellent network operating
systems), their PSERVER.EXE is simply too slow for today's printing
environments.  Running on an 80386DX-40 PC with light network traffic,
Novell's PSERVER.EXE might attain 6K bytes per second on a parallel port (a
more typical figure is 1500-2000 bytes per second).  With a typical 300x300
DPI A-size graphic being 400K-500K or larger, Novell's PSERVER can consume
four minutes or more just transferring the data to the printer.  Its
console (screen and keyboard) also leave a lot to be desired.

Standalone, "black box" print servers (such as Intel's NetPort and
Datacom's Series 8000, among others) also provide too little bandwidth for
today's applications.  Their data rates (typically 8000 bytes per second)
are only marginally better than Novell's PSERVER.EXE - still far too slow
for near-megabyte print jobs - and they are generally limited to one or two
printers per box.

Furthermore, neither "black box" nor in-the-printer interface cards have
means for intelligent local control.  Their consoles are even worse than
Novell's PSERVER - they have none at all.  Controlling these devices
involves running back and forth between the printer and a PC: You can't see
what's happening when you're at your workstation, and you can't do anything
about it when you're at the printer!  Such inconvenience and limited speed
hardly justifies a price tag of $500 or more EACH.

In contrast, FPServer can sustain data rates of 100,000 BYTES PER SECOND on
a 386DX-40's parallel ports.  This reduces the transfer time of that 500K
graphic from four minutes to FIVE SECONDS (assuming the printer can accept
data that rapidly).

FPServer can drive up to SEVEN printers from a single host PC.  And
FPServer suffers little or no throughput impact when servicing multiple
print devices.  A dynamic linking/unlinking algorithm eliminates the
overhead associated with idle print devices, and a real-time throughput
analysis algorithm optimally distributes available bandwidth between active
print jobs.

FPServer puts the limiting factor where it belongs: your printer, instead
of your network.  FPServer's data rate is nearly always faster than that of
the printers it is driving, which means shared printers are kept busy more
of the time and users are kept waiting less of the time.  Even an old
8088-based 4.77MHz IBM PC can sustain nearly 10,000 bytes per second -
faster than Novell's PSERVER and most other devices - while providing
superior on-the-spot job control.

The bottom line: FPServer eliminates the network printing bottleneck and
gives users control over their print jobs.



===========================================================================
ASSUMPTIONS ABOUT THE READER
===========================================================================

The material in this file has been written with the assumption that the
reader has a solid understanding of the IBM Personal Computer architecture,
DOS usage, and Novell NetWare operation.  In particular, it is assumed that
you already have an operational NetWare network with established print
queues running through some form of existing print server.

Many of the operations associated with setting up and maintaining printing
services on a NetWare network require Supervisor-level authority.  If you
are not your Network's Administrator, you may need to involve him/her in
the process of installing FPServer the first time.  (Subsequent changes to
FPServer's operation may be implemented without Supervisor assistance.)

Please consult the documentation for these other products if you have
questions regarding them.



===========================================================================
NECESSARY EVILS
===========================================================================

My apologies for the following sections, but they are unfortunately
necessary in today's world.  Please read them and then move on to the more
interesting material which follows.



COPYRIGHT
---------------------------------------

All of FPServer's files and materials are copyrighted.  The UNALTERED,
UNMODIFIED self-extracting file is hereby placed in the public domain; it
may be copied, distributed, and used without restriction as long as it is
not changed or modified in any way.  You are free to upload the unmodified
self-extracting file, IN ITS ENTIRETY, to bulletin boards and other "common
access" systems.  All other rights to FPServer are specifically reserved.

Registration and the purchase of one or more SoftKeys is required to obtain
uninterrupted use of FPServer.  The above release to the public domain does
NOT include such uninterrupted use nor the availability of SoftKeys.
Please read the REGISTER.DOC file for complete registration information.

FPServer represents a significant investment of my time and effort.  It is
my sincere hope that you will benefit from your use of this program.  I
would appreciate you giving copies of FPServer to anyone (everyone!) you
know that uses Novell NetWare.  Doing so costs you exactly nothing and
makes it possible for me to continue writing such software.

Constructive comments may be incorporated into future upgrades, so your
input is valuable.  Please submit them via (in order of preference)
CompuServe, fax, mail, or voice (see above for numbers and addresses).

Please see "About the Author" at the end of this file for more information
on my consulting services.  OEM and custom versions of FPServer are also
available.  Thank you for your support!



DISCLAIMER
---------------------------------------

FPServer, and all of its associated files and programs, is provided without
warranty of any kind.  The user of this software is solely responsible for:
A) determining its suitability for any purpose, B) the accuracy of its
operation, and C) the results obtained by its use.

As written, FPServer does not contain any "viruses" or other malicious
routines.  However, such routines do exist and can be "attached" to
otherwise benign and beneficial programs, often without obvious indication.
FPServer does not attempt to detect the presence of such additions.  It is
solely the user's responsibility to determine the "purity" of this software
and its associated files.



===========================================================================
DESIGN PHILOSOPHY AND FEATURE LIST
===========================================================================

As stated above, FPServer has two design goals: Ultra-high data throughput
and ease of use.  All Engineering projects involve some compromises (to
which we refer as "design decisions" or "tradeoffs").  For FPServer, every
such compromise was resolved primarily in favor of speed and secondarily in
favor of ease of use.

Based on this philosophy, FPServer includes many features not available in
other print server environments - and does NOT include some which are less
important.  So that you may obtain better insight into the philosophy of
FPServer, the following feature list describes some of these differences
(and my reasons for them).



CONSOLE I/O
---------------------------------------

The FPServer console (screen and keyboard) system includes a detailed
display for each port and queue being serviced.  This is in sharp contrast
to the consoles offered by other programs (which often include little to no
useful data) or "black boxes" and their printer-interface lookalikes (which
offer no console at all!).

FPServer's main display includes:

    * The name of the print queue being serviced by each port

    * Each port's hardware status lines, including OFFLINE, PAPEROUT,
      ERROR, and DTR OFF

    * The owner, print job title, and print job size of the job currently
      being printed

    * The number of bytes which have been transmitted for the job currently
      being printed

    * The owner, print job title, and average throughput for the most
      recently completed print job


You may "zoom" on any of FPServer's ports to obtain a closer look at that
particular print queue.  The zoomed view includes all of the information
described above, and adds a display of pending print jobs in the queue.

Once in the zoomed view, you may select the current or a pending job (if
any) and perform various job-related operations right from FPServer's
console.  That's right - you are able to control your printing while still
standing next to the printer, instead of running back and forth between the
print server and your PC.



DELETE PRINT JOBS - GRACEFULLY
----------------------------------------

If you've ever experienced a runaway print job, you know how inconvenient
such a situation can be.  The print job data is spread out all over - some
still in the print queue on the file server, some in the print server, and
some in the printer.  To delete the job and stop wasting paper, you have to
stop the printer, stop the print server, rush back to your PC, run Novell's
PCONSOLE, delete the job from the print queue, restart the print server,
and restart the printer.  What's worse, other print jobs being serviced by
the print server are interrupted when you shut it down to clear its memory
(this can make you VERY unpopular!).

FPServer eliminates the "runaway runaround" by allowing you to delete print
jobs right from the print server console.  When "zoomed" on a single port,
you may delete any print job (including the current one) by highlighting it
and selecting Delete from a menu.  ALL traces of the job are deleted: The
printer (if parallel) is reset, FPServer's buffer is emptied, and the job
is deleted from the print queue.  A message reminding you to reset the
printer manually (if necessary) is displayed on-screen and the port is held
idle for a programmable period of time so you may reset the printer or
manually flush its input buffer.



RESTART PRINT JOBS - CONVENIENTLY
----------------------------------------

FPServer's ability to delete print jobs is nice when you want to completely
discard a runaway print job.  But what if you still need a copy of it?  You
probably sent it because you needed it - and the fact that something went
wrong doesn't mean you don't need it anymore.

For this reason, FPServer also allows you to RESTART print jobs.  When you
select this option, FPServer holds the port idle for a programmable length
of time - long enough for you to reset the printer, reposition the paper,
or whatever - and then restarts the job from the very first byte.  A
special message is displayed during the reset pause as a reminder to reset
the printer.



PRIORITIZE PRINT JOBS - IMMEDIATELY
----------------------------------------

For those occasions when there's a large number of jobs ahead of yours -
but YOU'RE the only person willing to stand by the printer and wait -
FPServer allows you to prioritize your job to the top of the queue.  The
current print job will be finished as usual (FPServer will not interrupt a
job in progress) but the NEXT job to be serviced will be the newly
prioritized one.



SIMPLE CONFIGURATION
---------------------------------------

FPServer's operational characteristics are controlled by two methods:
commands in an ASCII configuration file (FPSERVER.CFG) and commands
included on the DOS command line when FPServer is started.  All FPServer
commands are "human readable", allowing you to easily review the print
server's configuration.

Other file servers obtain their data from encoded files which can be
manipulated only through ADDITIONAL programs.  The need to run separate
software to change - or even just review - the print server's configuration
makes setup and maintenance a lengthy, frustrating process.

FPServer first processes the contents of its FPSERVER.CFG file (if
present), then interprets command line parameters (if any).  Later commands
take precedence over earlier versions of the same command so you may
temporarily modify FPServer's behavior via the DOS command line without
editing any files or running any other programs.  You do not even need to
be logged in to the network; just override (or supplement) the FPSERVER.CFG
file right on the command line and press Enter.



CLEAN EXIT TO DOS
---------------------------------------

FPServer allows its execution to be terminated via an exit menu, just as
any other well-behaved program.  Doing so immediately returns the machine
to DOS - cleanly, with no "resident" code modules or "captive" memory.
Other print server programs offer no clean exit to DOS, and sometimes even
require the machine to be rebooted - an inconvenient and sometimes lengthy
process.

The ability to cleanly exit to DOS is particularly helpful when used in
conjunction with FPServer's command line parameters (see above).  You may
experiment with various configurations by just exiting back to DOS,
pressing F3 (get last command line), editing the command line parameters,
and pressing Enter to restart FPServer.



INTELLIGENT REAL TIME OPTIMIZATION
---------------------------------------

FPServer's primary design goal is high bandwidth.  Unfortunately, the best
way to achieve high performance is dependent on many different parameters.
Some, like machine type, clock speed, and average network latency, do not
vary greatly and could be entered by the user.  However, other parameters
such as typical job size and the speed at which print devices accept data
can vary dramatically from day to day and print job to print job.  To make
matters worse, those parameters which have the greatest effect on
throughput are also those which are the most difficult to predict - and
that have the widest spectrum of possible behavior.

To address this, FPServer incorporates a two layer real-time optimization
algorithm based on actual network and print device performance.  Port
throughput (the speed at which each print device is accepting data) and
network throughput/latency (the speed at which the network can supply data)
are used to control the amount of processor resource dedicated to each
task.  FPServer constantly monitors these conditions and adjusts its own
operating parameters to assure that the maximum possible data rate is
maintained on all ports.



NUMBER OF PORTS
---------------------------------------

FPServer will support up to seven ports on a single machine - three
parallel and four serial.  These ports do not require interrupt lines
(IRQ's) and may be based at any address in the host machine's I/O space.
The mixture of three parallel and four serial allows a print server host to
be constructed using commonly available and inexpensive "combo I/O" cards.

Further increasing the number of supported ports would have forced many
other design decisions to be adversely compromised. Ultimately, I decided
that if FPServer could be made to run fast enough, it would be more
effective to use another old PC with standard (and inexpensive) parallel
and serial hardware as a second Print Server.



MULTIPLE FILE SERVERS
----------------------------------------

More installations are moving to multi-server environments as networks
become more common.  In support of this, FPServer now services up to seven
separate file servers simultaneously.  Each port may be service jobs from a
separate print queue on a separate file server - you do not need to
consolidate all of your print jobs on a single file server.

You can also have multiple ports service a common print queue to reduce
print job dwell time.  If you have duplicate printers, you can multiply the
bandwidth of print job servicing by specifying the same print queue for
multiple ports.



PROGRAMMABLE PORT ADDRESSES
----------------------------------------

FPServer allows you to explicitly specify the I/O addresses for each active
port.  In addition to providing support for hardware which uses
non-standard I/O, this allows you to logically rename ports regardless of
their physical addresses.

Programming port addresses is an option, not a requirement.  If you do not
specify an address for a port, FPServer will automatically derive the
address from the BIOS data area in low memory.

Regardless of where the address originated (your command or BIOS), FPServer
always confirms the presence of physical hardware before enabling it for
use.  This prevents "artificial" ports which are generated by some programs
from causing print server or network problems.



PORT INTERRUPT LINES NOT REQUIRED
---------------------------------------

FPServer does not require interrupt-driven parallel or serial ports, and
ignores such interrupts if they are generated.  FPServer's architecture
runs without interrupts for three reasons: 1) Many host PC's do not have
seven interrupt lines available for such ports; 2) Most I/O cards do not
support seven individual interrupt choices; and 3) FPServer's output
routines are so tightly optimized for speed that the latency associated
with servicing interrupts would actually REDUCE throughput!



DIRECT SUPPORT FOR FIFO'D PRINTERS
----------------------------------------

A recent development in high-speed (and especially laser) printers is the
use of a small FIFO as the front end of the parallel port.  These buffers
generally accept 8-32 bytes at extremely high data rates, store them
internally, then interrupt the printer's microprocessor only when the FIFO
is full.  This dramatically improves the efficiency of the printer's CPU.

To get maximum performance from these new printers, FPServer analyzes the
data-reception behavior of parallel printers and optimizes its output
algorithm for FIFO-based operation if detected.



ROBUST VIDEO SYSTEM
----------------------------------------

This release incorporates a vastly improved video system that has proven
compatible with ALL video interfaces available for testing (even those
non-standard AT&T 6300's!).  The new system automatically detects the type
of interface and modifies its behavior accordingly.  All standard video
systems are supported: MDA, MGA, CGA, EGA, VGA, and SVGA, on any type of
monitor compatible with the video interface.

Active refreshing is also incorporated to maintain image accuracy.  Even if
no data has changed, the screen is completely rewritten on a periodic basis
in case shell errors or other anomolies cause display corruption.



FULL COLOR SCREEN DISPLAY
----------------------------------------

The new video system includes FULL COLOR support for machines equipped with
color interfaces and monitors.  Colors are used to highlight information
and warning messages; blinking is used to highlight errors and
time-sensitive conditions.

Of course, monochrome-equipped systems are detected and accommodated as
well.  Brightness and blinking are used in place of the color system's
color attributes.



PROGRAMMABLE PRINTER RESET DELAY
----------------------------------------

When you delete or restart a print job, it may take you a few seconds to
reset the printer, reposition the paper, and otherwise prepare to continue
servicing print jobs.  Since every printer is different, FPServer allows
the duration of the "job delete" and "job restart" delays to be programmed
individually for each port.  Any value from 1-999 seconds may be specified,
and during the delay the affected port will display a special message
reminding you of the reason for the pause in job servicing.



PROGRAMMABLE QUERY DELAY
----------------------------------------

FPServer queries file server(s) periodically for new print jobs which
require servicing.  While the amount of network cable traffic generated by
such queries is small, a separate query is generated for each active port.
Such constant scanning of print queues can generate a tremendous amount of
network traffic - more than is justified for the few seconds saved at the
start of a print job.

Therefore, when a print queue query finds no print jobs to service,
FPServer delays before checking that print queue again.  FPServer allows
you to increase this delay, if you wish, from its default of one-half
second to any value in the range 1-999 seconds.  A separate value for each
port allows you to tune the delays based upon the type of printer and its
frequency of use.  More active printers may benefit from shorter delays
(more frequent querying), while less-active printers may do just fine with
only an occasional query.

Note that setting a port's query delay only affects the potential delay
until a print job is started.  Once a job has been initiated, it runs at
full speed regardless of the query delay setting.



PROGRAMMABLE POST-JOB DELAY
----------------------------------------

Here's another network printing suggestion straight from the people who
know best: You, the actual users.  More and more printers are providing
multi-language support (PCL, PostScript, etc.) by "analyzing" the first few
bytes of print data to determine which emulation is being used.  Once the
decision is made, the printer switches to that emulation and completes the
print job.

When the printer is connected to a single PC with a single user, the pause
at the end of each print job helps the printer decide when it must resume
analyzing the data and choosing an emulation.  But in a shared (networked)
environment, multiple print jobs can be sent to the printer back-to-back -
making it impossible for the printer to distinguish between jobs even
though they may be in different emulations.

To provide better support for these "auto-switching" printers, FPServer
allows you to specify a post-job delay of 1-999 seconds.  This delay is
inserted by FPServer immediately after each print job's last byte of data
is sent to the printer.  A separate delay value is maintained for each port
so that you may add the delay to those printers which require it without
imposing it on those which do not.  By default, this delay is zero; but it
is easy to add if your printer requires it.



AUTO-REBOOT ON MISSING SHELL
----------------------------------------

Network resources should operate autonomously, even when problems arise.
File servers are a shared resource upon which many people depend.  For this
reason, they are often equipped with uninterruptable power supplies (UPS's)
so, if the power fails, they can shut down and then restart gracefully
without operator involvement.

Print servers are also a shared resource, and they too should operate
autonomously when problems arise.  When power is lost and then restored,
PC-based print servers with AUTOEXEC.BAT files will automatically reboot
into DOS, often faster than the file server itself reboots.  Since the PC
is now "ahead of" the file server in its boot sequence, the PC's network
shell will fail to find a file server and the print server software will
fail to start.  A manual reboot of the print server - AFTER the file server
is running - is then required.

FPServer solves this problem by confirming the presence of the network
shell - and a valid connection to a file server - before initializing.  If
no connection exists, or if the shell is not loaded, FPServer will display
a message, wait 30 seconds, and automatically reboot the PC.  For debugging
convenience, you may abort the reboot process and return directly to DOS
during the 30 second pause by simply pressing any key.

FPServer will continue the "scan, delay, reboot" cycle until it finds an
active file server, no matter how long the file server takes to reboot
itself.  In this manner FPServer becomes a completely autonomous resource;
if power is momentarily interrupted during the night, chances are your
users will never know about it.



PROGRAMMABLE AUTO-REBOOT ON LOST NETWORK
----------------------------------------

Another problem which has traditionally plagued print servers is the "lost
network".  This can be caused by anything from a file server going down to
a temporary break in the network cable.  The result is the same: the shell
loses contact with the file server, sometimes resulting in the message
"Network Error: Abort, retry" appearing on the screen.  Such situations are
confusing to users and have always required human intervention - until now.

FPServer now detects "lost network" and other lockup conditions.  Whether
the shell reports it or not - with or without a "Network Error" message -
FPServer will automatically cold-boot the PC after a programmable delay as
long as the basic operation of the PC is not impaired.

This feature, in combination with Auto-Reboot on Missing Shell above, makes
FPServer immune to almost all forms of network lockup and reboot failures.
Simply stated, FPServer does not passively hope that everything goes well;
it aggressively works to make SURE print services are available to all
network users 24 hours a day.



LOW MEMORY REQUIREMENTS
----------------------------------------

FPServer incorporates a memory management system which takes advantage of
traditional DOS memory.  However, even with all ports active, no more than
400K free DOS memory (as reported by the DOS utilities CHKDSK or MEM) is
ever required.  This small memory requirement means that DOS, the network
interface drivers, and the network shell itself can still be loaded into
traditional DOS ("low") memory - exactly as they should be for maximum
performance.



NOTIFY FOR JOB COMPLETE AND DELETE
---------------------------------------

FPServer supports the optional Notify parameter which sends a broadcast
message to the job owner when a print job has been successfully completed.
Unlike other print server software, however, FPServer sends this message to
the originating WORKSTATION (rather than the specific username) in case the
user has logged in under a different name since the job was submitted.

FPServer further enhances the Notify concept by notifying users of job
deletion.  If the current print job is deleted from the queue before being
successfully completed, FPServer will send a broadcast message to the
originating workstation to notify it of the premature deletion.



BANNERS
---------------------------------------

FPServer supports optional "banner pages" which are printed at the start of
a job.  Three fields are printed on four lines of enlarged (over one inch
high) text: The name of the job owner, the description of the print job,
and the date/time when the job started printing.

Unlike the banners provided by most other print server software, however,
FPServer's banners ALWAYS present accurate information.  The job's owner
and description are derived from data embedded in the job itself, rather
than from data supplied by the user's CAPTURE or NPRINT statements.
Date/time information is obtained directly from the file server (network
time) instead of the print server's host PC (whose local clock may not be
accurately set). In addition, the banner displays the date and time in a
alphanumeric "DD Mon YY" format to avoid confusion over whether the day or
month should be printed first in a purely numeric representation (different
countries have varying standards).



FORMFEEDS
---------------------------------------

FPServer supports the optional FormFeed parameter which helps assure that
new print jobs start at the top of a new page.  And FPServer's FormFeed
option (when enabled) generates a new page at the end of EVERY COPY within
the job so that each starts on its own new page.  This is in contrast to
other print server software which only emits a formfeed at the END of the
job, thus causing multiple-copy jobs to suffer from the same problem that
the FormFeed option was intended to eliminate.



SOFTKEY-BASED LICENSING
---------------------------------------

There is only one "version" of FPServer: The fully operational version
which includes all features and capabilities.  No handicapped "demo"
versions exist, and no features are "hidden" until you spend money.  My
idea is simple: You should base your decision to pay for and use FPServer
on an examination of the complete product in your own environment.

This is made possible with "SoftKeys".  A SoftKey is a numeric key derived
from the serial number of the copy of NetWare running on a file server.
FPServer obtains your NetWare serial numbers directly from the file
server(s) to which it is connected, and compares them with the SoftKeys you
have supplied to it in its configuration file or on its command line.  If
all connected file servers have correct SoftKeys, FPServer runs without
interruption.

However, if one or more file servers have missing or incorrect SoftKeys,
FPServer terminates after twenty minutes.  You can restart it as many times
as you like - the program does not "destroy itself" or leave datestamps
on your network drives - but every run of the program will terminate after
twenty minutes.

This demonstration period allows you to experience what the terms
"ultra-high throughput" and "ease of use" mean IN YOUR OWN ENVIRONMENT.
You can completely configure FPServer for your network - fine tune all of
its parameters, let other users play with it - on your own schedule and
without any pressure.

As an example, in twenty minutes you can send 48 MEGABYTES to a Hewlett
Packard LaserJet 4 (which accepts data at 40,000 bytes per second).  So you
can test even those BIG jobs that leave other print servers gasping for
breath.

If, after testing it in your own real-world environment, you decide that
FPServer is not for you, simply stop using it.  There's no up-front
expense, no refund hassles, no paperwork, no phone calls, no explanations
to salesmen, no restocking fees - just stop using it.

But when you decide that YES, FPServer really does make a difference in
your networked printing, simply register your file server serial number(s)
via modem with FPServer's online registration system.  The NWSerial utility
(NWSERIAL.EXE), included with FPServer, makes it easy to list your NetWare
serial numbers; and complete registration instructions appear when you exit
FPServer's demo (whether by timeout or keystroke).

Please read the REGISTER.DOC file for complete registration information.



MISCELLANEOUS ISSUES
---------------------------------------

FPServer does not support tab translation.  This capability is seldom used
with today's software and printers, and with thousands of users worldwide I
have NEVER received a request for it.

FPServer allows each port to service a single print queue.  Some other
programs allow a port to service multiple queues.  Frankly, there are few
sites where this capability is used; those that do are usually prioritizing
time-sensitive print queues because network printing is so slow.  I chose
to delete this capability because of its low usage, the impact it had on
overall throughput, and the fact that FPServer's higher speed eliminates
the need for queue prioritization.

FPServer does not support the concept of "forms".  But FPServer's ease of
reconfiguration makes it easy to simulate it.  If you are actually swapping
media in a single printer, set up separate print queues for each type of
form, let users send their print jobs to the correct queue, and switch
FPServer to that queue with a command-line override when you change the
forms.

FPServer cannot be configured with Novell's PCONSOLE.EXE.  FPServer's many
enhancements and options are completely unsupported by PCONSOLE, and
FPServer's human-readable configuration file and command line parameters
allow faster and more flexible setup and experimentation without it.

FPServer's status cannot be determined using Novell's PSC.EXE for the same
reasons that PCONSOLE is inadequate.  Unlike Novell's PSERVER.EXE, FPServer
provides complete status information directly from its console; a separate
program is not required.

FPServer does not support the RPRINTER protocol.  By definition, RPRINTER
is a slower process: data must pass through the network a second time, and
then through another workstation, before reaching the target printer.
FPServer's design goal was speed - and thus support for this inherently
slower process was deleted.

FPServer does not "advertise" its presence on the network with NetWare's
Service Advertising Protocol (SAP).  To be more specific, FPServer does not
issue Server Identity Broadcasts nor respond to Service Advertising
Queries.



===========================================================================
HARDWARE REQUIREMENTS
===========================================================================

HOST PC (PRINT SERVER)
---------------------------------------

FPServer may be used on virtually any PC which conforms to the generally
accepted standards for IBM Personal Computer compatibility. There is no
minimum processor architecture or speed; an 8088-based PC running at
4.77MHz is quite adequate.  A numeric coprocessor is neither required nor
used, and if present will be ignored.

A video subsystem (interface and monitor) is required for initial setup.
During operation, FPServer will display printer status and queue contents
and allow users to manipulate jobs if a display is present.  Technically
speaking, however, FPServer does not require a display for day-to-day
operation.

FPServer does not require a keyboard if you are willing to go without some
of its console interaction capabilities.  If you wish to use the host PC
for other functions in addition to being a print server, a keyboard may be
used to gracefully exit and later restart FPServer (a keyboard is probably
also required for your other purposes).  However, for dedicated print
server applications that power-up directly into FPServer, a keyboard is
strictly optional as long as the host PC will successfully boot without
one.

A disk drive is required to hold FPServer and its configuration file (both
of which are relatively small).  A floppy drive is more than adequate for
this task; in fact, if DOS and other required files (AUTOEXEC.BAT,
CONFIG.SYS, etc.) will fit together with FPServer on a single floppy, that
disk can serve as the boot device and no hard drive is required at all.

One or more ports are required for communication between FPServer and the
print devices.  FPServer can support up to three parallel and four serial
ports at any I/O address within the IBM PC's 64K I/O address range.  The
interrupt lines normally associated with these ports (typically IRQ's 3, 4,
5, and 7) are completely ignored by FPServer and may instead be used for
other purposes such as the network interface card.

FPServer requires no more than 400K free memory even when running its full
compliment of three parallel and four serial ports.  FPServer does not
require Extended memory (XMS) or Expanded memory (EMS) and ignores it if
present.  Loading DOS and other programs in "high memory" (as allowed by
later versions of DOS) provides no additional functionality and is not
required unless the host machine otherwise has less than 400K free memory
for FPServer.

Based on the above, a minimum hardware specification for an FPServer host
PC would be an 8088 running at 4.77MHz with 1MB of memory, one low density
floppy drive, one or more parallel and/or serial ports, no hard drive, no
keyboard, and no video.  A disk in the floppy drive would contain the
following:

     Bootable DOS (disk formatted with the /S option)
     CONFIG.SYS file
     AUTOEXEC.BAT file which loads network drivers and invokes FPServer
     Novell's IPX.COM or the ODI environment programs
     Novell's NETx.COM
     SHELL.CFG (optional as required by Novell's software)
     FPSERVER.EXE
     FPSERVER.CFG (containing appropriate configuration data)


...all of which can comfortably fit on a 360K low density floppy.  Such a
host PC would cost less than $300 even if purchased NEW.



PRINT DEVICES
---------------------------------------

FPServer may be used with any external device that supports hardware
handshaking.  Device types are not limited to printers; any parallel or
serial device which conforms to the requirements below may be used with
FPServer.  Examples of "non-printer" devices include plotters, CRT
terminals, modems - any device which can make use of queued data.

Parallel devices must conform to the generally accepted Centronics
"standard" for parallel interfaces.  This well understood protocol
incorporates hardware handshaking as part of its basic definition.
FPServer has two parallel modes: "Safe" and "Fast".  Refer to the
"Technical Details" section for more information.

Serial devices must provide hardware handshaking via the DTR (Data Terminal
Ready) signal.  This is the most common form of hardware handshaking for
serial devices and is supported by virtually every printing device
available.  Most PC compatibles expect DTR on pin 6 of the standard 25 pin
D-connector used for RS-232C; consult your computer's documentation for
more information regarding the pinouts used on its serial ports.

FPServer does not support software handshaking.  This includes X-On/X-Off,
ETX/ACK, ACK/NAK, and other purely software-based protocols.



PRINTER CABLES
---------------------------------------

The cables used to connect from the host PC on which FPServer executes
to the print device(s) must meet certain minimum requirements.  These
requirements differ for parallel and serial connections; each is detailed
below.

For parallel connections, the cable must carry the following signals
between FPServer's host PC and the printer (pin numbers refer to those
traditionally used at the Centronics connector):

        STROBE      (pin 1)
        DATA 1-8    (pins 2-9)
        BUSY        (pin 11)
        GROUND      (pins 19-30)


Parallel cables should also connect the following signals, although they
are not strictly required for successful operation:

        PE          (pin 12)
        SLCT        (pin 13)
        INIT        (pin 31)
        ERROR       (pin 32)


For serial connections, the cable must carry the following signals (typical
pin numbers are not specified for serial connections due to the wide
variety of connectors and pinouts used for RS-232C interfaces):

        Printer             Host PC
        =======             =======
          TxD --------------> RxD
          RxD <-------------- TxD
          DTR --------------> DSR
          GND --------------- GND


The arrows are included to clarify the direction of signal travel, since
both ports have signals with identical names.  It is important to note that
you CANNOT connect pins with the same name to each other; each must be
connected to its "complementary" pin.  The sole exception is Ground, which
has no direction or polarity.

Pay close attention to the DTR-DSR connection.  The PRINTER's DTR (which is
an output) must drive the HOST PC's DSR (which is an input).  Connecting
the opposite signals together - even though the names are the same - will
prevent FPServer (and most other software) from functioning correctly.

Some serial devices, notably Engineering plotters, use the Clear To Send
(CTS) signal instead of the more common DTR signal.  While CTS is more
sensible (it accurately describes the function being performed), devices
which use it are definitely in the minority.  If your device uses CTS
instead of DTR, you must wire the cable so that the device's CTS signal
appears at the host PC's DSR input.

All pin numbers should be confirmed with your equipment's own
documentation.  In many cases wire "swapping" is necessary to move signals
to the correct pins.

The DOS COPY command, unfortunately, is not a good indication of correct
handshake wiring; it is often so slow that there is no possibility of
filling the serial device's input buffer. A cable which works fine with the
DOS COPY command may fail with FPServer simply because FPServer can supply
data so much faster than DOS.  If the first part of your print job prints
successfully, and then things seem to go wrong, it's quite likely that no
hardware handshaking signals are being passed back to FPServer from the
printer.  In this case, everything goes well until the serial device's
buffer overflows - and then data loss takes over.



FASTER CLOCKS AND WIDER BUSES
---------------------------------------

FPServer's throughput performance is much less dependent upon the host PC
than other print server software.  Most of its theoretical maximum
throughput can be achieved on machines with (relatively) low processing
power.  While an increase in speed will be realized by using a faster host
PC, the advantage is that older, less expensive, less "user-desirable" PC's
can be used as print servers with little or no performance penalty.

There are several reasons why a machine which is "twice as fast" does not
yield a doubling of throughput.  First, PC parallel and serial ports are
eight bit devices; all I/O involving these ports occurs eight bits at a
time regardless of the processor's bus width.  An AT's 16 or 32 bit bus is
still forced to interact with the port hardware eight bits at a time.

Second, most AT-style BIOS's insert wait states for eight bit I/O
operations - and thus offset the advantage of increased clock speeds.  Most
I/O cards are designed for operation in an 8MHz (or at most 12MHz) bus; a
25, 33, or 40 megahertz processor simply idles while its wait states time
out during each input and output operation.

Because the code between port operations will be executed faster, some
increase in maximum throughput will be obtained with faster machines.
However, the relationship is not linear; a doubling of bus width or clock
speed will not yield twice the data rate.

For example, FPServer running on an 80386DX-40 PC can sustain parallel data
rates of 100,000 bytes per second.  An original IBM PC (8088 @ 4.77MHz) has
only 1/50th the processing power of the 386 machine, and yet can still run
FPServer at 10,000 parallel bytes per second.  In other words, a machine
with only 2% of the processing power can still sustain 10% of the data
rate.

Furthermore - and this is the most important consideration - print devices
are almost ALWAYS the limiting factor.  Very few can accommodate FPServer's
maximum output rate even when the host machine is just that 8088-based PC.
Even Hewlett Packard's LaserJet 4, with its new 80960-based controller, is
limited to approximately 40,000 bytes per second.  FPServer running on an
80386DX-40 has 2.5 TIMES that bandwidth.  Only the fastest output devices
will find themselves waiting between bytes received from FPServer.

Before spending money on a faster PC host, be sure to run FPServer on a low
end machine and compare its test mode performance with the rates obtained
when driving a "real" printer.  Your oldest, slowest PC may be more than
fast enough for the printers in question.



===========================================================================
CONFIGURATION COMMANDS
===========================================================================

FPServer's operation is controlled by commands which appear in a
configuration file and on the DOS command line.  All commands, regardless
of their location, use a common format.

For consistency, all commands which affect a specific port begin with the
port's name (LPT1, LPT2, LPT3, COM1, COM2, COM3, or COM4).  Those which
affect the overall operation of the software do not incorporate port names.

FPServer recognizes the following commands:

    portQUEUE           ...specifies print queue to be serviced
    portMODE            ...specifies parallel port timing mode
    portBAUDRATE        ...specifies serial port baud rate
    portPARITY          ...specifies serial port parity
    portDATABITS        ...specifies number of serial data bits
    portSTOPBITS        ...specifies number of serial stop bits
    portBASE            ...specifies parallel/serial I/O base address
    portQUERYDELAY      ...specifies delay between print queue queries
    portPOSTJOBDELAY    ...specifies delay after print job completion
    portRESETDELAY      ...specifies delay for manual printer reset
    BOOTDELAY           ...specifies delay before auto-reboot
    REMARK              ...allows remarks in FPSERVER.CFG file
    REM                 ...same as REMARK

Commands are processed in the order that they appear.  Those in the file
FPSERVER.CFG are processed first, followed by any which appear on the
command line.  Later commands take precedence over earlier, making it
possible for command line parameters to temporarily override the contents
of FPSERVER.CFG (this is extremely useful for experimentation and early
setup).  No warning is issued if multiple, redundant commands are detected;
the later commands (if valid) are processed and the earlier commands simply
overridden.

Spaces may surround equal signs ONLY in the file FPSERVER.CFG.  Including
spaces around equal signs on the command line will confuse DOS's command
line parser and result in error messages.  Since spaces are never REQUIRED
for any command, it is recommended that commands not include spaces at any
time.  Examples in this file omit spaces in the recommended fashion.

All commands and their parameters are converted to capital letters prior to
interpretation and are thus case-insensitive.



portQUEUE COMMAND
---------------------------------------

The portQUEUE command defines the print queue to be serviced by a hardware
port.  Its format is as follows:

    portQUEUE=fileserver/printserver/printqueue,softkey

...where:   port = LPT1, LPT2, LPT3, COM1, COM2, COM3, or COM4
            fileserver = the name of the file server
            printserver = the name of a print server on that file server
            queuename = the name of a print queue on that file server
            softkey = the SoftKey for the specified file server

All three names - the file server, the print server, and the print queue -
MUST be included in every portQUEUE command in the exact format shown above
(separated by forward slashes and no extra spaces).  There are no default
values; if any of the names are missing, invalid, or incomplete, the
associated port is disabled.

During startup, FPServer logs in to the specified file server as the
specified print server and attaches to the specified print queue.  The
print server object must not require a password, and it must be authorized
to service the specified print queue.  If not, an error will be reported on
the port's screen display and the port will be disabled.  Network
Supervisors can create print server objects and remove print server
passwords using Novell's PCONSOLE utility; refer to Novell's documentation
for more information regarding the creation of print server objects.

The print server object should also have Operator rights to the specified
print queue, or several FPServer features will not be available.  Network
Supervisors can grant print queue Operator rights to print server objects
using the QRights utility (QRIGHTS.EXE) included with FPServer; refer to
the separate documentation file QRIGHTS.DOC for more information.

If a SoftKey is available for the specified file server, it must follow the
print queue's name with a separating comma (again, no extra spaces are
allowed).  A file server's SoftKey must be included in EVERY portQUEUE
command which references that file server; even a single portQUEUE command
without a valid SoftKey will cause FPServer to terminate after the demo
period.

The following example illustrates the correct use of the portQUEUE command.
If you wish FPServer to log in to the file server named FILE1, as the print
server object named PRINT6, and use LPT2 to service the print queue named
QUEUE3, you would use the following command:

    LPT2QUEUE=FILE1/PRINT6/QUEUE3

Because no SoftKey is supplied, this command would allow FPServer to print
jobs which appear in QUEUE3 only until the demo period expired.  If you
then register FILE1's serial number for use with FPServer and receive the
SoftKey 0123-4567:89AB-CDEF (for example), you would add it to the above
command as follows:

    LPT2QUEUE=FILE1/PRINT6/QUEUE3,0123-4567:89AB-CDEF

VERY IMPORTANT: You must select a single print server object for each file
server and use that print server object in every portQUEUE command which
references that file server.  Due to a limitation in Novell's NetWare, you
cannot be logged in to one file server as multiple print servers
simultaneously.  Failure to heed this limitation will result in inoperative
ports.

There is no default for the portQUEUE command.  A port must have a valid
portQUEUE command to prevent that port from being disabled.  In addition,
even a single portQUEUE command without a valid SoftKey will cause FPServer
to terminate after the demo period.



portMODE COMMAND
---------------------------------------

The portMODE command defines the parallel port strobe timing mode.  Its
format is as follows:

    portMODE=method

...where:   port = LPT1, LPT2, or LPT3 (not COM1, COM2, COM3, nor COM4)
            method = either SAFE or FAST

FPServer supports two operational modes for the parallel ports: "Safe" and
"Fast".  Values other than SAFE or FAST are ignored.

The difference between them involves the timing of the Strobe signal and
the way that Centronics-equipped print devices are designed.  This subject
is discussed more thoroughly in the "Technical Details" section.

Generally, you should always specify FAST unless doing so results in
printer errors or garbled data.  No print devices tested to date have been
incompatible with the FAST setting, and using it significantly increases
FPServer's maximum throughput.  However, should the printer report an "I/O
Error" or start dropping characters, change that port's mode to SAFE and
compare the results.

The default for the portMODE command is FAST.



portBAUDRATE COMMAND
---------------------------------------

The portBAUDRATE command defines the baud rate for a serial port.  Its
format is as follows:

    portBAUDRATE=value

...where:   port = COM1, COM2, COM3, or COM4 (not LPT1, LPT2, nor LPT3)
            value = 110, 300, 600, 1200, 2400, 4800, 9600, 19200, or 38400

FPServer supports the nine baud rates shown above.  The full baud rate
value - three, four, or five digits - must be supplied including trailing
zeroes (i.e. "96" is invalid).  Values other than those shown above are
ignored.

There is no default for the portBAUDRATE command.  UART baud rates are
not initialized unless this command is specified.



portDATABITS COMMAND
---------------------------------------

The portDATABITS command defines the number of data bits for a serial port.
Its format is as follows:

        portDATABITS=value

...where:   port = COM1, COM2, COM3, or COM4 (not LPT1, LPT2, nor LPT3)
            value = 7 or 8

FPServer supports either 7 or 8 data bits.  Values other than 7 or 8 are
ignored.

There is no default for the portDATABITS command.  UART data bits are not
initialized unless this command is specified.



portPARITY COMMAND
---------------------------------------

The portPARITY command defines the parity for a serial port.  Its format is
as follows:

    portPARITY=value

...where:   port = COM1, COM2, COM3, or COM4 (not LPT1, LPT2, nor LPT3)
            value = ODD, EVEN, or NONE

FPServer supports the standard ODD and EVEN parity options in addition
to no parity at all.  Values other than ODD, EVEN, or NONE are ignored.

If ODD or EVEN parity is specified, FPServer will program the UART to
calculate and insert an additional bit into each serial word.  Specifying
NONE will disable parity and reduce the length of each serial word by one
bit.

There is no default for the portPARITY command.  UART parity is not
initialized unless this command is specified.



portSTOPBITS COMMAND
---------------------------------------

The portSTOPBITS command defines the number of stop bits for a serial port.
Its format is as follows:

    portSTOPBITS=value

...where:   port = COM1, COM2, COM3, or COM4 (not LPT1, LPT2, nor LPT3)
            value = 1 or 2

FPServer supports either 1 or 2 stop bits per serial word.  Values other
than 1 or 2 are ignored.  Please note that the UART associated with the
specified port may impose limitations on the number of stop bits allowed in
certain modes.

There is no default for the portSTOPBITS command.  UART stop bits are not
initialized unless this command is specified.



portBASE COMMAND
---------------------------------------

The portBASE command defines the base of the I/O hardware address range for
a parallel or serial port.  Its format is as follows:

    portBASE=value

...where:   port = LPT1, LPT2, LPT3, COM1, COM2, COM3, or COM4
            value = a hexadecimal value of up to four digits

The value may be any legal hexadecimal value from one to four digits in
length in upper or lower case, with the exception of zero.  No
"punctuation", such as a leading "0x" or trailing "H", is required or
allowed.  Invalid values are ignored.

Most IBM PC-compatible hosts contain BIOS code which scans for parallel and
serial ports at industry-standard addresses and stores them for program
use.  FPServer normally uses these BIOS defaults for port I/O addresses,
and under most circumstances there is no reason to override them.

In reality, though, FPServer does not care what specific address is
associated with a given port name.  LPT1, COM3, etc. are just convenient
shorthand for "the first parallel port, the third serial port," and so
on.  Given no commands to the contrary, FPServer will match port names
to their industry-standard addresses just like any other software; but
the portBASE command allows you to force address values if you wish.

One use for the portBASE command is to support multi-port I/O cards which
pack a large number of parallel and/or serial channels into a single board.
Such interfaces commonly use non-standard I/O addresses which standard PC
BIOS's do not detect.  The portBASE command makes it possible to use such
interfaces with FPServer.

Another use for the portBASE command is to "move" port names.  For example,
if your host PC contains two parallel ports, they will most likely be
addressed at 3F8 hex (LPT1) and 2F8 hex (LPT2).  However, you can "swap"
the two ports - and thus the printers they drive - by specifying opposite
addresses as follows:

    LPT1BASE=2F8
    LPT2BASE=3F8

FPServer does not blindly accept hexadecimal values.  A detailed analysis
is performed at the specified address to confirm the presence of
industry-standard parallel or serial hardware.  If such hardware is not
present at the specified address, the portBASE command is ignored.

The default values for port base addresses vary from machine to machine,
and FPServer defaults to the addresses detected by BIOS for maximum
compatibility.  For reference, the addresses most commonly used for
parallel and serial ports are as follows (all values are in hexadecimal):

    Port    Mono System     Color System
    ----    -----------     ------------
    LPT1        3BC             378
    LPT2        378             278
    LPT3        278         not available
    COM1        3F8             3F8
    COM2        2F8             2F8
    COM3        3E8             3E8
    COM4        2E8             2E8

COM3 and COM4 are often not supported by BIOS code.  You may find that
COM3BASE and COM4BASE commands are required by your host PC even though
they reside at the "industry standard" addresses of 3E8 and 2E8.

The difference in parallel port addresses between monochrome and color
systems is due to the common practice of including a parallel port on
monochrome video interfaces.  Such mono-printer interfaces typically use a
special address, 3BC hex, which is normally ignored by separate parallel
interfaces.  If a parallel port is present at 3BC hex, most BIOS's will
treat it as LPT1 and move all other parallel ports "up" one position to
compensate.  (Serial ports are not affected by video type.)



portQUERYDELAY COMMAND
----------------------------------------

The portQUERYDELAY command defines the amount of time, in seconds, a given
port will wait between print queue queries.  Its format is as follows:

      portQUERYDELAY=ddd

...where:   port = LPT1, LPT2, LPT3, COM1, COM2, COM3, or COM4
            ddd = delay in seconds

Values from 1-999 are accepted; the entry is truncated to the first three
digits.  Invalid values, including zero, are ignored.

Larger values will reduce network overhead but increase the delay from the
submission and the actual start of a print job.  Smaller values will cause
print jobs to start faster at a slight increase in network traffic.

The default queue query delay is one-half second; however, the minimum
value which may be specified with the portQUEUEQUERY command is one second.
For the absolute minimum delay, simply do not specify a portQUEUEQUERY
command.



portPOSTJOBDELAY COMMAND
----------------------------------------

The portPOSTJOBDELAY command defines the amount of time, in seconds,
FPServer will delay after the completion of a print job before beginning a
new one.  Its format is as follows:

      portPOSTJOBDELAY=ddd

...where:   port = LPT1, LPT2, LPT3, COM1, COM2, COM3, or COM4
            ddd = delay in seconds

Values from 1-999 are accepted; the entry is truncated to the first three
digits.  Invalid values, including zero, are ignored.

The specified delay is ADDED to the query delay defined by the
portQUERYDELAY command for the specified port (if any).

The default value for the portPOSTJOBDELAY command is zero (no additional
delay after job completion).



portRESETDELAY COMMAND
---------------------------------------

The portRESETDELAY command defines the amount of time, in seconds, FPServer
will delay after a job is manually restarted or prematurely deleted.  Its
format is as follows:

      RESETDELAY=ddd

...where:   port = LPT1, LPT2, LPT3, COM1, COM2, COM3, or COM4
            ddd = delay in seconds

Values from 1-999 are accepted; the entry is truncated to the first three
digits.  Invalid values, including zero, are ignored.

The RESETDELAY command allows you to tailor the amount of time required for
you to help your printer recover from a restarted or prematurely deleted
print job.  Since different printers may require different amounts of time,
FPServer allows you to specify separate values for each port.

If a job has been restarted from FPServer's console, the next data to be
sent will be the restarted job.  If the current job has been prematurely
deleted, the next data will be the next job in the print queue.  If no jobs
are pending, no additional data will be sent.

The default value for the portRESETDELAY command is 10 seconds.



BOOTDELAY COMMAND
---------------------------------------

The BOOTDELAY command defines the amount of time, in seconds, FPServer will
allow for a "lost file server" before rebooting the host PC.  Its format is
as follows:

      BOOTDELAY=ddd

...where:   ddd = delay in seconds

Values from 1-999 are accepted; the entry is truncated to the first three
digits.  Invalid values, including zero, are ignored.

The default value for the BOOTDELAY command is 30 seconds.  This is
generally a good compromise between too small a value (which can cause
frequent resets in networks with heavy traffic) and too large a value
(which can needlessly delay restoration of printing services after power
outages, etc.).  You may, however, need to optimize this value for your
particular environment.



REMARK AND REM COMMANDS
---------------------------------------

Remarks may be included in the FPSERVER.CFG file in the format:

    REMARK This is a comment

...or:

    REM This is a comment


The space after the REMARK or REM command MUST be included.  REM and REMARK
lines are simply ignored by FPServer.



A MINIMAL FPSERVER.CFG FILE
---------------------------------------

(Note: The SoftKeys in the following examples are not valid.  They are
included only for illustrative purposes.)

As noted in their individual descriptions, many of FPServer's configuration
commands default to standard values.  The number of commands actually
required for proper operation is therefore quite small.  In fact, a
completely operational print server can be established with a single
command: a portQUEUE command which specifies a print queue and the port
which is to service it.

An FPSERVER.CFG file containing the command:

    LPT1QUEUE=FILE1/PRINT6/QUEUE3,0123-4567:89AB-CDEF

...will yield a print server which attaches to the File Server FILE1, logs
in as the print server PRINT6, obtains jobs from the print queue QUEUE3,
and outputs them on the first parallel port using FAST mode.  All other
parallel and serial ports, if present, are disabled by default.

For a truly minimal configuration, the FPSERVER.CFG file can be eliminated
completely by including required commands on the command line itself.
Entering the following command at a DOS prompt:

    FPSERVER  LPT1QUEUE=FILE1/PRINT6/QUEUE3,0123-4567:89AB-CDEF  <enter>

...will satisfy FPServer's minimal parameter needs and yield exactly the
same operation as if the FPSERVER.CFG file mentioned above were present.
Note that no spaces are present around the equal sign, in keeping with
DOS's command line parser requirements.



A TYPICAL FPSERVER.CFG FILE
---------------------------------------

The following is an example of a more typical FPSERVER.CFG file for a
hypothetical network which uses many of the commands described above:

    Rem ****************************************************************
    Rem !!! PLEASE CONTACT JOHN DOE IN MIS BEFORE CHANGING THIS FILE !!!
    Rem ****************************************************************
    Rem - Print Server in Admin area is PS-ADMIN on file server ADMIN
    Rem - Admin. LaserJet IIID's queue is named PQ-LASERJET3D
    LPT1Queue=ADMIN/PS-ADMIN/PQ-LASERJET3D,0000-1111:2222-3333
    Rem - LaserJet IIID works fine with Fast parallel ports
    LPT1Mode=FAST
    Rem ----------------------------------------------------------------
    Rem - Admin. PaintJet's queue is named PQ-PAINTJET
    Rem - Print Server is identical; can only use one on each file server
    Rem - SoftKey is identical, because it's the same file server
    LPT2Queue=ADMIN/PS-ADMIN/PQ-PAINTJET,0000-1111:2222-3333
    Rem - PaintJet likes Fast parallel too
    LPT2Mode=FAST
    Rem ----------------------------------------------------------------
    Rem - Drafting's HP7580 plotter queue is PQ-HP7580, and...
    Rem - ...Drafting has its own file server named DRAFTING, and...
    Rem - ...they named their print server PS-DRAFT, and...
    Rem - ...SoftKey is different, because it's a different file server
    COM1Queue=DRAFTING/PS-DRAFT/PQ-HP7580,1111-2222:3333-4444
    Rem - Plotter is set up for 19200 baud, 8 data, no parity, 1 stop
    COM1BaudRate=19200
    COM1DataBits=8
    COM1Parity=None
    COM1StopBit=1
    Rem - It takes more than 10 seconds to put new paper in the plotter
    COM1ResetDelay=60
    Rem ----------------------------------------------------------------


Notice that uppercase and lowercase are mixed freely in this example.  As
mentioned above, FPServer capitalizes all alphabetic characters prior to
processing them.  Feel free to make the file "human readable".



===========================================================================
INSTALLATION
===========================================================================

INSTALLING FPSERVER.EXE
---------------------------------------

There is no complicated installation procedure for FPServer.  The program
file itself, FPSERVER.EXE, may be placed in any subdirectory.  However,
since most host PC's will be dedicated to the task of print servers, it is
recommended that FPSERVER.EXE be placed in the root directory of the boot
device (probably either A: or C:) to reduce the size and complexity of the
AUTOEXEC.BAT file.



CREATING THE FPSERVER.CFG FILE
---------------------------------------

The FPSERVER.CFG file, if used, may be created with any editing program
that can produce a "pure" ASCII file on disk.  Pure ASCII, in this context,
indicates that the file must not contain word processing commands or other
non-human readable information (essentially, it should include only
numbers, letters, and standard punctuation characters).  DOS's EDLIN and
EDIT programs and all text editors work in this manner; most word
processing programs also have a "text output" or "ASCII output" option that
prevents the inclusion of special formatting characters.

FPSERVER.CFG must reside in the default subdirectory in effect when
FPServer is invoked.  This does not mean that they must reside in the SAME
subdirectory, although that is definitely the most desirable (and least
error-prone) configuration.  What it DOES mean is that if, before typing
FPServer at the command line, you type "DIR <enter>", FPSERVER.CFG must be
one of the files shown in the current subdirectory.

Obviously, the best situation is to have both FPSERVER.EXE and FPSERVER.CFG
in the same subdirectory, and make that subdirectory the current one, when
starting FPServer.  The easiest way to insure this is to place both files
in the root directory of the boot device and be in that root directory.



TEMPORARY MODIFICATIONS
---------------------------------------

One of the most convenient features of FPServer's configuration system is
the ability to temporarily override the contents of the FPSERVER.CFG file
with entries on the command line.  The fact that you need not be logged in
to the File Server between "sessions" of FPServer streamlines this even
further.

As an example, to change the queue being serviced by a printer-resident
interface, Novell's PSERVER, or a "black box" print server, you would have
to perform the following steps (assuming that the print server in question
already has sufficient rights to service the new queue):

    * Reboot the print server (since Novell's PSERVER.EXE does not provide
      a "clean" exit to DOS)

    * Log in using an account with sufficient rights to modify the
      parameters of the print server in question

    * Run Novell's PCONSOLE.EXE

    * Work your way down through the menu system until you reach the level
      at which the "Queues to be Serviced" can be edited

    * Delete the old queue and enter the new one, specifying the correct
      parallel or serial port as you do so

    * Back out of the menu system until you reach DOS again

    * Restart the print server


Through all of this, you will have to reboot the print server at least once
and run two separate programs - just to try something a little different.
If you do not like the results, you get to go through the entire routine
again just to put things back the way they were.

In contrast, FPServer can be reconfigured the same way with the following
steps:

    * Exit to DOS by pressing Escape, then Y on the print server's host PC

    * Press F3 to recover the "FPServer" command line that last started the
      software

    * Add the appropriate "portQUEUE=" command to the end of the command
      line (which will override any similar command in FPSERVER.CFG)

    * Press Enter!

This amounts to 14 keystrokes plus the queue specification.  There is no
need to reboot the host PC, or log in as someone else, to change FPServer's
operation - just a few keystrokes and a few seconds completely reconfigures
its behavior.

To restore things back to the way they were, simply exit again, type
FPServer on the command line, and press Enter.  Eleven keystrokes and
everything reverts back to the configuration you originally specified in
FPSERVER.CFG.  Neither Novell's PSERVER.EXE nor any "black box" can touch
FPServer for ease of use!



PERMANENT MODIFICATIONS
---------------------------------------

To make configuration changes permanent, simply modify the FPSERVER.CFG
file using your ASCII text editor.  Again, this may be done by simply
Escaping out of FPServer, running the editor, and restarting FPServer. It
is not necessary to reboot the host PC nor even log in to the File Server.



===========================================================================
NORMAL OPERATION
===========================================================================

STARTING THE PRINT SERVER
---------------------------------------

FPServer may be started by typing its name at any DOS prompt and pressing
Enter.  However, in most installations, the PC will be dedicated to the
print server application.  In such environments, FPServer may be included
as the last command in the PC's AUTOEXEC.BAT file to completely automate
its startup.

Configuration commands may optionally follow FPServer's name up to the
limit that DOS imposes on the length of the command line.  See the
"Controlling PSERVER's Operation" section earlier in this file for more
information regarding configuration commands and their parameters.

Regardless of the startup method chosen, the FPSERVER.CFG file must reside
in the default directory when FPServer is invoked.  See "Creating the
FPSERVER.CFG File", above, for more information.



Console Response Time
---------------------------------------

A note about console response time: During especially high speed print
jobs, FPServer's console operations may slow somewhat.  This occurs when
FPServer has detected the opportunity to establish a high-bandwidth path to
one or more printers and is redirecting processor resources accordingly.
Since FPServer ALWAYS favors throughput over everything else (ease of use
is secondary, remember), response to the keyboard and screen may slow when
a high speed job is being serviced.

If FPServer seems to be ignoring your keystrokes, don't worry - they are
being stored in an internal buffer until the print job has an idle moment.



THE MAIN SCREEN
---------------------------------------

The main print server screen is separated into eight regions: a title block
at the top which contains text information, and seven port displays - one
for each of the seven hardware ports supported by FPServer.  All port
displays are identical in their content.  The following description is
applicable to all.



The Status Line
---------------------------------------

The top, or status, line of each port display contains the traditional name
for the associated hardware port (LPTx or COMx).  This is followed by the
name of the print queue to which this hardware port is logically attached
(as specified by the portQUEUE command in either the FPSERVER.CFG file or
the command line).  The print queue's name is truncated, if necessary, to
fit on the status line.

The right side of the status line displays port information.  The first
parameter reports throughput limitations:

     Printer Limited    (Parallel only.)  FPServer is capable of
                        transferring data more quickly, but the printer's
                        BUSY line is not allowing it to do so.  The printer
                        asserts BUSY when it is unable to accept another
                        byte of data. This occurs after each byte is
                        transmitted and during intensive printer
                        processing.  FPServer must wait for BUSY to go
                        inactive again before transmitting the next byte.
                        This is the most common limiting factor for
                        parallel printers.

     Baud Limited       (Serial only.)  FPServer is capable of transferring
                        data more quickly than the selected baud rate will
                        allow.  Increasing the baud rate may improve
                        printing speed somewhat.

Each port's status line also displays printer information to the extent
that it is available from the printer itself (more data is available from
parallel devices than from serial devices):

     OFFLINE            (Parallel only.)  The printer is off line.

     PAPEROUT           (Parallel only.)  The printer is out of paper.

     ERROR              (Parallel only.)  The printer is in an error
                        condition, other than Off Line and Paper Out, for
                        which no further information is available.  This
                        may be caused by an access cover being open, low
                        toner or ink, erroneous data, or loss of power.
                        Many printers indicate such errors on their front
                        panels.  Consult the printer's documentation.

     DTR Off            (Serial only.)  The printer is momentarily not
                        accepting data.  This generally occurs when the
                        baud rate is faster than the printer's effective
                        throughput rate.  With data coming in faster than
                        it can be printed, the input buffer fills until
                        eventually the printer can accept no more data.
                        The printer then "turns off" the DTR line to
                        prevent further transmission until it has emptied
                        the buffer to some extent.

For parallel devices, the BUSY line is the only parameter which controls
the transfer of data.  OFFLINE, PAPEROUT, and ERROR are reported by
FPServer but do not affect data flow.  Many printers - especially those
with large input buffers - are capable of accepting data while offline
and/or out of paper, and FPServer supports them without limitation.

Serial devices use DTR as their sole means of flow control, and thus
FPServer must cease sending data when DTR goes "off".



The "Former" Line
---------------------------------------

The Former line appears immediately beneath the status line.  It displays
the owner, description and average speed (in bytes per second) of the most
recently completed print job.

The average speed is calculated by dividing the job's size by its duration
in integer seconds.  A job's duration is considered to start when the first
byte of data is received from the print queue and end when the last byte of
data is transferred to the printer.  ANY event which lengthens this amount
of time - and thus adversely affects the overall amount of time consumed by
the job - will correctly result in a decrease of the average speed.  This
includes running out of paper, going off line, and other "normal"
occurrances.



The "Current" Line
---------------------------------------

The Current line appears beneath the status line.  It displays the owner,
description, size, and progress of the job currently being printed.

The progress display appears on the right side of the Current line and
indicates the number of bytes which have been sent to the printer.  The
value is updated as the device accepts more data from FPServer.
Interruptions in data flow will cause this value to stop increasing (since
the device is not accepting data).

A job remains on the Current line until the last byte of data is accepted
by the printer.  When the last byte has been successfully transferred,
FPServer notifies the file server that the job has been completed (so it
can be removed from the print queue) and passes the completion information
to the Former line (described above).



THE PORT SCREEN ("ZOOMED" VIEW)
---------------------------------------

When the main screen is displayed, a highlight appears on the left and
right sides of the image.  This highlight can be moved up and down using
the cursor keys, thus allowing you to select one of the seven ports.

A note on the highlight: The choice of "arrows" was made for maximum
compatibility with the widest variety of video monitors.  It is common for
old, phosphor-burned (and usually monochrome) monitors to be used on print
servers.  Such units often have difficulty displaying colors, fine
contrasts, and sometimes even differences in brightness.  A
moving-character highlight was therefore used to insure compatibility with
almost ANY monitor.  If you can even barely distinguish individual
characters on the screen, you can use that monitor with FPServer!

Once an individual port has been selected, pressing Enter will "zoom" on
that port.  The area previously devoted to displaying all seven ports will
be used to display information on just the selected port.

The zoomed view includes the selected port's Status, Former, and Current
lines.  The remaining lines form a queue display showing pending jobs ready
to be printed.  Multiple pending jobs are shown in the order they will be
printed, with the topmost job being first.  Each pending job displays its
owner and its description.

Jobs appear in the Pending area only when they are complete and ready for
service.  This differs from other print server programs, which often
display jobs still being uploaded to the file server.  The problem with
including such incomplete jobs is that a prioritized list, such as the one
in the Pending area, can be rendered inaccurate at any moment by a smaller
job which started later but finished queuing first.  Such a job can "jump
ahead" of the incomplete jobs - seeming to "pop" into the Current line
without ever having been in the queue.  FPServer prevents this problem by
only displaying those jobs which are complete and ready to go: the order in
which they are displayed is the order they will be printed.

The one exception to this rule is delayed or "deferred" print jobs. NetWare
allows the printing of jobs to be delayed until some future date and time.
FPServer honors this feature, but includes such jobs in the Pending display
for two reasons: 1) So you know they are there, and 2) So you can
Prioritize them if you wish (described below).  If print jobs appear which
seem "stuck" in the queue, the most likely explanation is that they have a
future print date/time specification.  (Novell's PCONSOLE can be used to
confirm this.)



THE PORT MENU
---------------------------------------

The zoomed port view incorporates a highlight much like the one on the main
screen.  In this case, however, the highlight is used to select the Current
print job or one of the Pending print jobs.

Once the Current or a Pending job is selected, pressing Enter will display
a menu of job-related options.  From here, you may choose to Delete, Restart,
or Prioritize the highlighted job.

The following sections describe the options available from the port menu.
Please note that the QRights utility, which accompanies FPServer, must be
used to grant print queue Operator rights to FPServer before any of these
features can be used.



Deleting Print Jobs
---------------------------------------

You may delete either the Current or any Pending print job.  This is a very
powerful capability which saves you from running back and forth between the
printer and a workstation running Novell's PCONSOLE.

Deleting a Pending print job simply removes it from the print queue.  There
is no effect on the Current print job (if any).

Deleting the Current job immediately stops data transmission to the
printer, flushes the job from FPServer's local buffers, deletes the job
from the print queue, and issues a hardware reset to the printer (if
parallel).

There is no industry-standardized method for issuing a hardware reset to
serial printers.  Worse yet, not even all parallel printers obey the
parallel port's INIT line.  The most glaring exception is Hewlett Packard's
LaserJet printers: not a single model in their entire line supports the
INIT signal, even though its function was recognized and supported YEARS
before the first LaserJet shipped.  Extensive discussions with HP's Boise,
Idaho facility (where the LaserJet product line originates) has never
yielded a reason for this omission.  The effect on HP's customers: it is
impossible for FPServer, or any other software, to asynchronously reset a
LaserJet with a hardware signal - even when the data stream is "lost" and a
software reset command would be ignored.  Most other parallel printers will
react to FPServer's hardware reset and flush their buffers automatically;
but YOU have to manually reset a LaserJet.

When you delete a print job from within FPServer, a broadcast message is
sent to the originating workstation if the job's owner enabled the Notify
option.



Restarting Print Jobs
---------------------------------------

Restart is another port menu option.  It is available only when the Current
job is highlighted (not when a Pending job is selected).  Restart behaves
much like the Delete option described above - data transmission is halted,
FPServer's buffers are flushed, the printer is reset - but instead of the
job being removed from the print queue, it is restarted from the beginning
after the port's reset delay times out.

Restart is handy for obtaining a "good" copy of a runaway print job.  If
you believe the data in the print job is accurate and the problem stems
from a one-time data phasing error, Restart allows you to reset the
printer, "clean up" everything, and try again without having to completely
regenerate the print job.  (If the problem persists, you can always decide
to Delete it anyway.)



Prioritizing Print Jobs
---------------------------------------

Prioritize allows you to move the highlighted print job to the "top" of the
Pending job list.  If you send a print job to a busy print queue, you may
find it nested deep in the Pending list, and it may take minutes or even
hours for the printer to reach your job.

On the premise that the person standing at the print server must be in a
greater hurry than one who is not, selecting Prioritize will advance the
highlighted job ahead of all others in the print queue.  The Current job
(if any) will not be interrupted, and the relative order of the other
Pending jobs will not be altered - but the highlighted job will move
directly to the top of the print queue and be the next job serviced by
FPServer.

Prioritize works on all print jobs, including those which have been
specifically "deferred" to a date or time in the future.  This can be used
in interesting ways: For example, you can submit print jobs with a target
print date far in the future (thus causing them to sit in the queue
indefinitely), then "print on demand" by walking up to FPServer's console
and Prioritizing the desired job(s).

If you are REALLY in a hurry, you can force FPServer to start a specific
Pending job immediately.  First, Prioritize the desired job; then, Delete
the Current job.  This is a bit extreme, however - and may cause future
printing difficulties as co-workers take revenge on YOUR print jobs!



STOPPING THE PRINT SERVER
---------------------------------------

Execution of FPServer may be stopped by pressing Escape (as noted in the
title at the top of its screen) and answering Y to the confirmation query.
FPServer stops servicing active jobs, frees allocated memory, and cleanly
returns control to DOS.

Jobs which were being printed when Escape was pressed are reset, at the
File Server, and will be serviced when FPServer is restarted (or another
authorized print server notices them).  Exceptions to this can occur if
requested by the software which originated the job, but NetWare's standard
methods for queuing print data (CAPTURE and NPRINT) both allow prematurely
terminated servicing to restart without data loss.

If FPServer was running in demo mode (because of bad or missing SoftKeys),
it will display the unlicensed ports, file servers, and serial numbers when
exiting.  However, if multiple, conflicting portQUEUE commands (different
print server names for the same file server) have been supplied for a
single port, the file server name and serial number may not appear if
FPServer cannot resolve the correct file server/print server relationship.



===========================================================================
ERROR MESSAGES
===========================================================================

FPServer uses two classes of error messages: "DOS-level", which are issued
outside of its console environment (i.e. at the DOS command line level),
and "operational", which appear on the console screen.

This section lists FPServer's error messages, the reasons that can cause
them to be displayed, and recommended actions.



DOS-LEVEL ERROR MESSAGES
--------------------------------------------

These messages generally involve network shell problems and SoftKey issues
which will cause FPServer to prevent or terminate its execution.  They
generally prevent or terminate program execution and are displayed at the
DOS command line level.



Workstation is not attached to a network
System will auto-reboot in 30 seconds
--------------------------------------------

REASON: Upon receiving control from DOS, FPServer confirms that the host
workstation is "attached" to a File Server.  ("Attached", as defined by
NetWare, means that the physical and logical connections exist which allow
the workstation to log in to the File Server.)  The host workstation does
NOT have to be logged in - but the logical attachment to at least one file
server, as normally established when Novell's NETX loads, must be present.
This message is displayed if such an attachment cannot be found.

ACTION: Confirm that the workstation successfully connects to a file server
when Novell's NETX shell loads (it will issue a message stating the name of
the file server to which it attached).  Again, it is not necessary to be
logged in.



Insufficient memory
---------------------------------------

REASON: There is insufficient free conventional ("low" or "DOS") memory for
FPServer to initialize and support the specified ports.  128K, PLUS a
minimum of 16K for each active port, must be available when FPServer is
started.  This message is displayed if enough memory is not available.

ACTION: Just before the host PC starts FPServer, run DOS's CHKDSK or MEM
program to determine the amount of free conventional memory.  (FPServer
does not use extended or expanded memory, and ignores it if present.) If
the amount is less than required: 1) confirm the PC has the standard one
megabyte of base memory, 2) reduce memory consumption by other programs, or
3) reduce the number of active ports on this particular print server.



<server> not provided with a SoftKey
---------------------------------------

REASON: FPServer was running in demo mode, and has terminated, because one
or more portQUEUE commands is missing a valid SoftKey for the specified
file server.

ACTION: Register your NetWare serial numbers and obtain SoftKeys for each
file server to be serviced by an FPServer.  Once the SoftKeys have been
purchased, confirm that the correct SoftKey is included on EVERY SINGLE
portQUEUE command in the FPSERVER.CFG file and on the command line.  Even
one portQUEUE command with a missing SoftKey will cause FPServer to
terminate after its demo period.

Please read the file REGISTER.DOC for complete registration information.



<server>'s SoftKey is Invalid
---------------------------------------

REASON: FPServer was running in demo mode, and has terminated, because one
or more portQUEUE commands contained an invalid SoftKey for the specified
file server.  This differs from the error message above, which indicates
that the SoftKey was completely missing.

ACTION: Confirm that the correctly typed SoftKey is included on EVERY
SINGLE portQUEUE command in the FPSERVER.CFG file and on the command line.
Even one portQUEUE command with an invalid SoftKey will cause FPServer to
terminate after its demo period.

Please read the file REGISTER.DOC for complete registration information.



<server>'s NetWare Serial Number is...
---------------------------------------

REASON: FPServer was running in demo mode, and has terminated, because one
or more portQUEUE commands did not include a valid SoftKey for the
specified file server.  Since you will need your file server's serial
number during registration, this message is displaying that number for your
convenience.  (You may also obtain file server serial numbers with the
NWSerial utility.)

ACTION: Register your NetWare serial numbers and obtain SoftKeys for each
file server to be serviced by an FPServer.  Once the SoftKeys have been
purchased, confirm that the correct SoftKey is included on EVERY SINGLE
portQUEUE command in the FPSERVER.CFG file and on the command line.  Even
one portQUEUE command with a missing SoftKey will cause FPServer to
terminate after its demo period.

Please read the file REGISTER.DOC for complete registration information.



OPERATIONAL ERROR MESSAGES
--------------------------------------------

These messages include those problems which do not cause FPServer to
terminate its execution.  They generally affect only a single port, and
appear on the "Current" line of the affected port's display.



Not in use
---------------------------------------

REASON: The port is not in use.  It is not connected to a print queue and
cannot service print jobs.

ACTION: This is the normal message for inactive ports.  If you expected the
port to be active, this indicates some type of configuration error occurred
which could not be diagnosed more completely.  The most likely problem is a
invalid or missing portQUEUE command containing this port's name.



Bad or missing port hardware
---------------------------------------

REASON: No valid port hardware could be found at the address specified by
this port's portBASE command.  If no portBASE command was provided, this
command indicates that the default I/O base for this port (as supplied by
BIOS) did not address acceptable hardware.

ACTION: Confirm portBASE address values are valid (pure hexadecimal values
without leading "0x" or trailing "H"), and confirm that the associated
physical port hardware is actually installed in the host machine.  Also
confirm that the port hardware is compatible with the industry-standard IBM
PC parallel and serial ports.



Invalid FServer/PServer/PQueue Spec
---------------------------------------

REASON: The value associated with the portQUEUE command for this port
contained bad syntax or too few parameters.

ACTION: Confirm that all three names are specified in the portQUEUE
command.  A file server, AND a print server, AND a print queue must be
explicitly included.  Confirm that forward slashes are used to separate
each of the three names, and that no spaces appear anywhere within the
portQUEUE command.



Error attaching to server
---------------------------------------

REASON: FPServer could not successfully attach to the file server specified
by the associated portQUEUE command.

ACTION: Confirm that the specified file server is accessible via the cable
attached to the host PC.  Confirm that the specified file server is
actually running and accepting new attachments/logins (Network
Administrators sometimes disable new connections during maintenance).



Error logging in as <PServer>
---------------------------------------

REASON: FPServer is unable to log in to the specified file server using the
print server object name specified in the portQUEUE command.

ACTION: Confirm that the print server object's name is spelled correctly.
Confirm that the print server object actually exists on the specified file
server.  Confirm that the print server object does not require a password.



<PServer> not authorized to service...
---------------------------------------

REASON: FPServer was able to attach to the specified file server, and log
in as the specified print server, but that print server is not authorized
to service print jobs in the specified print queue.

ACTION: Confirm the print queue name is spelled correctly.  Run Novell's
PCONSOLE or QRights to grant service rights to the specified Print Server
object for the specified queue.  Run Novell's PCONSOLE and confirm that the
print queue is enabled and that new print servers may attach to it.



Error attaching to queue <PQueue>
-----------------------------------------------

REASON: The file server will not allow FPServer to attach to the specified
print queue.

ACTION: Confirm that the print queue name is correctly spelled.  Confirm
that the print queue exists on the File Server to which the host PC is
attached.  Run Novell's PCONSOLE and add the specified Print Server object
to the list of print servers allowed to service the specified print queue.
Confirm that fewer than 25 print servers (NetWare's limit) are already
attached to the print queue.  Run Novell's PCONSOLE and confirm that the
specified print queue's operating parameters are acceptable.  Refer to
Novell's documentation for further information.



RESET printer to flush job
-----------------------------------------------

REASON: The Current print job has been Restarted or Deleted, but some data
from the cancelled job may still remain in the printer's buffer.  FPServer
is reminding you to take action, as necessary, to flush the printer's data
buffer.

ACTION: Do what is necessary (which may be nothing at all) to assure the
printer's buffer is flushed of all prior data.  This message will
disappear after the number of seconds defined by the portRESETDELAY command
has expired (default = 10).



...query delay...
-----------------------------------------------

REASON: FPServer is delaying the number of seconds specified by the
portQUERYDELAY command before requesting another job from the print queue.
This is not an error.

ACTION: None; just wait for the query delay to time out.  If the query
delay is too long, you may modify it with the portQUERYDELAY command.



===========================================================================
FINE TUNING FOR MAXIMUM PERFORMANCE
===========================================================================

FPServer is seldom the limiting factor in a network printing system.  Many
other components and subsystems conspire to limit the ultimate printing
bandwidth.  This section discusses some of the more common limiting factors
and offers improvement suggestions.  Some, none, or all of these may be
applicable to your situation; consult your equipment's documentation and
manufacturer(s) for more specific information.



PRINTER DATA RATES
---------------------------------------

The most common limiting factor is the print device itself.  Different
printers accept data at different rates.  In fact, the same printer will
often accept data at varying rates depending upon the data's formatting,
content, and other factors.

If the device has an input buffer, its initial data rate can be very high
while the buffer is being filled.  This is because the printer simply
stores the data (rather than processing and printing it) and writing data
into memory is a relatively fast operation.  Ultimately, however, the
buffer will be filled and the data rate must then drop to the speed at
which the device can generate an image on the output media - since that is
the rate at which new buffer space becomes available.

The type and content of the data is also significant.  For example: A fully
rasterized image, sent to a laser printer, places very little burden on the
printer's microprocessor and is basically transferred directly into the
page buffer.  The limiting factor in this case is often the engine speed;
the printer can move the paper only so fast regardless of how quickly data
can be accepted from the host and placed into memory.

The fastest data rates are generally achieved with single pages of fully
rasterized (graphics) laser printer data.  In these cases, the last byte of
data is transferred before the engine begins operation and thus the
mechanism speed is factored out.

"BPS" values drop when the print job exceeds a single page.  The first page
will still transfer into the empty page buffer very rapidly, but subsequent
bytes must wait for room to appear in the page buffer as its current
contents (the first page) are transferred to paper.  In addition, the
printer's microprocessor will devote less time to data reception since it
will also be running the engine (a workload which was not present during
the transfer of the first page's data).

High level printer "languages", such as Hewlett Packard's PCL 5 and
especially Adobe's PostScript, can yield even lower data transfer rates.
Unlike pure graphics - where one bit generally equals one pixel - very
small amounts of high level printer languages can create an ENTIRE PAGE of
rasterized data.  The conversion is handled by the printer's
microprocessor, which may accept a small amount of data and then "go deaf"
while those few bytes generate an entire page.  The dramatically reduced
"BPS" values that result from this condition do not mean that your printing
throughput is poor, but that each byte of data is generating a lot of
rasterized output.

Pure text can produce the lowest "BPS" values, again due to mechanism
speed.  As an example: Assume a laser print job contains ten pages of 25
characters each.  The data for the first page will transfer - and the
rasterized image will be created - almost instantly.  However, the second
(and subsequent) pages will be limited by the printer's need to physically
print the previous page.  Since a laser's engine speed is a constant, each
page takes the same amount of time to pass through the mechanism - and thus
fewer characters per page yields lower "BPS" values even though throughput
(as measured in PAGES) is constant.

In any case, FPServer is almost certainly capable of supplying data faster
than your print device is able to accept it.  The appearance of the
"Printer Limited" message on the port's Status Line indicates that the
printer is refusing data when FPServer offers it.  You may confirm this -
and determine FPServer's maximum data rate in your environment - by using
FPServer's "Test" mode (described below).



FPSERVER'S TEST MODE
---------------------------------------

FPServer's parallel port routines have a special mode which can be used to
determine the maximum throughput possible in the tested environment. This
mode may be invoked by using the portMODE command as follows:

     LPT1MODE=TEST   <for LPT1>

...or:

     LPT2MODE=TEST   <for LPT2>


Selecting "Test" mode causes FPServer's parallel port routine to act as if
an infinitely fast print device were connected to the designated port.  All
of the same routines are used - and the print job data is actually
transmitted - but printer-induced delays are ignored.

This is a complete bandwidth test which involves the disk drives on the
File Server, the network cabling and interfaces, the clock rate of the
print server's processor, the speed of the print server's parallel port
hardware - EVERYTHING associated with transferring a print job from the
File Server to the connector on the back of the print server.  The
resulting bytes per second (BPS) values indicate the absolute maximum
throughput of which FPServer is capable in the test environment.

Some notes regarding "Test" mode:

     * Files of sufficient size must be used for "Test" mode results to be
       significant.  The most accurate values will be obtained with jobs at
       least 500KB in size.

     * Multiple jobs should be run through "Test" mode so that the File
       Server's job startup overhead can be factored into the results.
       Multiple, back-to-back jobs should be queued up and ready to go
       prior to starting FPServer in "Test" mode.

     * Most printers will report errors if connected during "Test" mode.
       This is because FPServer does not honor their BUSY line and thus
       transmits the data faster than the printer can accommodate it.  It
       is recommended that printers be disconnected during "Test" mode to
       prevent erratic operation.

     * Printer status signals, such as OFFLINE, PAPEROUT, and ERROR are
       still reported in "Test" mode even though they have no effect on
       FPServer's operation.  They may be safely ignored.

     * Test mode may be temporarily invoked by including the portMODE=TEST
       command on the DOS command line.  Normal FPServer operation will
       resume the next time it is started without the additional command.

     * Test mode may be used only with parallel ports.  Few serial devices
       support "dynamic" baud rates or per-byte hardware handshaking, and
       thus FPServer cannot obtain useful information from such a test.



PRINTER SPEED SETTINGS
---------------------------------------

One way to improve printer throughput is to optimize the printer's
configuration.  Many printers have setup options which can increase (or,
when incorrectly set, decrease) data throughput.

For example, the Hewlett Packard LaserJet IIISi's parallel port has an
optional HIGH SPEED mode which can be configured from the printer's front
panel.  Setting HIGH SPEED=NO causes the IIISi to use a BUSY signal with a
minimum duration of 10 microseconds.  Setting HIGH SPEED=YES reduces the
minimum BUSY duration to 1.5 microseconds - a significant reduction which
has a dramatic impact on data throughput.

Be sure to review your print device's documentation for speed-enhancing
configuration options.  You may wish to contact the manufacturer for
specific recommendations or suggestions.



BRIDGES
---------------------------------------

Bridges, used to connect multiple networks, can impose limitations on
overall throughput.  To understand why, it is useful to review the "data
path" for queued print data.

When a workstation requests that a job be printed, the data is directed
into a print queue.  The print queue resides on a file server - one of the
file servers to which FPServer attaches during initialization.  During job
servicing, the data is retrieved from the file server's hard drive, sent
through the network interface card, over the cable, into FPServer's network
interface card, and out to the print device.  At a minimum, therefore,
queued print data must pass through two software programs (the file
server's operating system and FPServer) and two network interface cards
(one each on the file server and FPServer's host PC).

Internal bridges - i.e. multiple interface cards installed in the File
Server's backplane - are already in a "minimum" configuration.  The fact
that the data was received on one network interface card and is transmitted
on another is unimportant, since it is buffered to hard disk in the
meantime.  As a result, internal bridges do not restrict bandwidth.

In contrast, external bridges can impose significant bandwidth limitations.
The presence of an external bridge in the data path inserts at least one
more software program (the bridge operating system) and two more network
interface cards (one in and one out of the bridge).  In many installations
this is probably compounded by the fact that bridges are often slower 80286
systems with inherently poorer throughput.

Self-contained bridges often have higher throughput than PC's used as
bridges.  However, to maximize throughput, it is strongly recommended that
FPServer's host PC be connected to a network cable which runs directly to
the file servers containing the serviced print queues.



DEDICATED NETWORK CABLES
---------------------------------------

Contrary to popular belief, it is NOT necessary to connect a PC-hosted
print server to a file server via a dedicated network cable.  Under most
circumstances (with most printers), the print server can share its cable
with other workstations and will not place an undue burden on the total
cable bandwidth.



MULTIPLE PORTS PER PRINT SERVER
---------------------------------------

Many times the first approach to increasing print server throughput is to
reduce its number of active ports.  This is often very effective on other
print server software - but is COMPLETELY UNNECESSARY with FPServer.

FPServer incorporates a "dynamic linking/unlinking" algorithm which reduces
the overhead on inactive ports to ZERO.  Whenever the queue associated with
a given hardware port is empty, FPServer unlinks the associated software
routines from its service chain as if the port had never been activated.
Only when a job is ready for service does FPServer relink the associated
hardware's service routines and begin devoting resources to it.

Careful design has also lessened the impact of multiple simultaneous jobs.
Reductions of under 10% are typical - rather than the 50% loss often
experienced with other print server software.  As stated earlier, FPServer
generally has far more bandwidth capability than the print devices which it
drives, and that bandwidth is automatically optimized across currently
active devices in real time.

FPServer's high throughput also reduces the likelyhood, and duration, of
coincident jobs.  Jobs are completed faster and are thus less likely to
incur even FPServer's small multi-job throughput degradation.

The bottom line is: There is little to no penalty when connecting multiple
devices to FPServer simultaneously.  What may have required multiple
dedicated print servers in the past can now be handled with a single PC.



16 BIT NETWORK INTERFACES AND DRIVERS
---------------------------------------

The print server's network interface card can have more effect on overall
throughput than any other physical component.  Recommendations can be
summarized into the following: Use a 16 bit network interface card with a
16 bit optimized driver.

16 bit network interface cards have been shown to have significantly
higher effective bandwidth than their 8 bit counterparts.  While parallel
and serial port hardware is, by definition, 8 bits in width, the interface
to and from the network interface card's buffer memory has no such
architectural restriction and should thus be as wide as possible.

16 bit network interface cards should have drivers optimized for use in a
16 bit environment.  It is possible to write a driver which is compatible
with both 8 bit and 16 bit hosts and interfaces.  Such "universal" drivers
do not take adequate advantage of the host PC's 16 (or 32) bit processor.
Call the network interface card manufacturer, if necessary, and confirm
that the driver is specifically intended for use on 16 bit (read: 80286 and
up) microprocessors.

It is not my intention to give preferential treatment to any single vendor,
but I will report that 3Com's EtherLink III "Parallel Tasking" network
interface card has produced some of the most dramatic throughput values I
have measured to date.  This performance, combined with an extraordinarily
low cost (under $130 street price), makes it an excellent choice for high
bandwidth applications such as FPServer.



EMM386.EXE AND DOS'S LOADHIGH
---------------------------------------

DOS 5.0, and many third-party utilities, allow drivers and portions of the
operating system to be loaded above the traditional 640K DOS memory area
(into a region commonly known as "high memory").  This is traditionally done
in an effort to release memory in the lower 640K for use by applications
software.

FPServer requires, at most, 400K of free memory.  Amounts greater than that
are unused while FPServer is in operation and therefore wasted.  If, just
prior to running FPServer, CHKDSK reports 400K or more free, loading
programs "high" will yield absolutely no advantages.

Loading programs "high" CAN yield disadvantages, however.  A special device
driver is typically required to handle the redirection to software loaded
in "high" - and this driver can severely impact overall PC performance.
Measurements on DOS 5.0's EMM386.EXE show a 50% DECREASE in I/O bandwidth -
presumably because EMM386.EXE was intercepting I/O operations in case they
were intended for a program loaded "high".  (This test was run without ANY
programs actually loaded high; just EMM386.EXE's presence in memory cut I/O
throughput in half.)

Use of Novell's XMSNETx.EXE and EMSNETx.EXE programs can impact throughput
because they too make use of memory outside the standard 640K.  While very
useful in memory-bound environments, these programs are a detriment to
FPServer's bandwidth; furthermore, they are unnecessary since FPServer's
400K is seldom too great a demand on the host machine's resources.

In summary, FPServer will operate perfectly with DOS, network drivers, etc.
loaded "high".  However, the low memory thus freed will very likely go
unused - and overall print server throughput will suffer needlessly.  It is
strongly recommended that the host PC load all software in the standard
640K DOS memory area for maximum performance.



BUS CLOCK SPEEDS
---------------------------------------

*******************************************************************************
*                               CAUTION!!!                                    *
*                                                                             *
*    The following section discusses altering the fundamental operating       *
*    characteristics of the host PC.  Only individuals VERY EXPERIENCED       *
*    with PC's and their internal operation should modify these parameters.   *
*    Incorrect settings can render your PC inoperative.  If you are not       *
*    COMPLETELY familiar with the architecture of your PC, please obtain      *
*    the assistance of a qualified PC Technician.                             *
*                                                                             *
*    Not all BIOS's allow these parameters to be modified.  Please consult    *
*    your computer's documentation or manufacturer for more information and   *
*    specific recommendations.                                                *
*******************************************************************************

Most AT-class PC's of recent vintage are fabricated using high integration
chipsets, where four or five "mega-chips" are equivalent to hundreds of
small- and medium-scale integration IC's.  The BIOS included with PC's of
this type generally have a secondary setup screen where operational
parameters may be manipulated to fine tune the machine's performance.  One
of these parameters, the Bus Clock, affects the speed with which operations
may be performed on the backplane - where the parallel, serial, and network
interfaces reside.

(For technical accuracy, it should be pointed out that there is no actual
"clock" signal, as such, on the backplane.  Instead, this signal serves as
the fundamental for the various timing and control signals which actually
run the asynchronous AT bus.)

The Bus Clock is usually derived from the processor clock via division by a
value selected in the BIOS setup screens.  Manipulating this divisor
inversely affects the Bus Clock (increasing the divisor decreases the speed
of the Bus Clock, and vice versa).

Typical Bus Clock divisor values which may be selected include 2, 3, and 4
which, on a 25MHz machine, would yield "bus speeds" of 12.5MHz, 8.33MHz,
and 6.25MHz respectively.  The early IBM AT used an "8MHz" bus clock, thus
defining the lowest speed at which cards intended to be compatible must
operate.  Since virtually all cards compatible with the AT backplane can
therefore be expected to run with an 8MHz Bus Clock, BIOS's for faster
(33MHz and 40MHz) processors usually include higher numbers to allow the
bus speed to reach the 8MHz range.

Since, as stated above, all AT cards are designed to accommodate 8MHz,
FPServer's host should always run its bus at 8MHz or above.  FPServer's
throughput MAY be improved by decreasing the divisor value, and thus
increasing the Bus Clock, to operate the backplane cards at a faster speed.
Reduce the divisor ONE INCREMENT AT A TIME and carefully observe the
effects.  You should reboot the machine multiple times to confirm reliable
operation at the new bus speed.

Regarding the Bus Clock's "upper limit": there seems to be an industry
threshold at 12MHz.  While cards do exist which have been designed to
operate beyond that speed, they are definitely the minority.  For safety,
consider 12MHz as the top end of the bus speed range.

Be sure to record the original values of all parameters before altering
them.  It may become necessary to restore them in the future as other cards
are added to the system.



I/O WAIT STATES
---------------------------------------

*******************************************************************************
*                               CAUTION!!!                                    *
*                                                                             *
*    The following section discusses altering the fundamental operating       *
*    characteristics of the host PC.  Only individuals VERY EXPERIENCED       *
*    with PC's and their internal operation should modify these parameters.   *
*    Incorrect settings can render your PC inoperative.  If you are not       *
*    COMPLETELY familiar with the architecture of your PC, please obtain      *
*    the assistance of a qualified PC Technician.                             *
*                                                                             *
*    Not all BIOS's allow these parameters to be modified.  Please consult    *
*    your computer's documentation or manufacturer for more information and   *
*    specific recommendations.                                                *
*******************************************************************************

I/O Wait States are another set of parameters which, like the Bus Clock
described above, affect the speed with which operations may be performed on
the backplane.

Many AT-compatible cards cannot accommodate the I/O speeds of which current
microprocessors are capable. The limiting factor is often the IC's used on
the cards; many logic families, fast enough for 4.77MHz 8088's, simply
cannot sustain the command and data rates of later generation
microprocessors.

Recognizing this, the high-integration chipsets used in so many AT-class
machines allow the insertion of "wait states" into input and output
operations.  Simply stated, a wait state causes the processor to idle for a
known length of time - thus giving the external device a chance to react to
the processor's instruction.  The slower the device, the greater the number
of wait states.

Wait states impose a heavy penalty on performance - not surprising since
the microprocessor is essentially being told to "hurry up and wait".  Early
80286-class PC's, often advertised as 12MHz (or even 16MHz) machines, had
wait states on MAIN MEMORY and thus ran little faster than zero-wait-state
8MHz or 10MHz PC's.

The accepted norm is now to place all memory on the motherboard and run it
at full speed without wait states (or to include a cache which offsets some
of the impact of slow memory).  The same is not true, however, of ports,
video boards, and other peripherals.  Even when mounted directly on the
motherboard, the processor communicates with these components via I/O
instructions - rather than memory reads and writes - and thus any I/O Wait
States will directly impact their communications bandwidth.

As with the Bus Clock, acceptable values for I/O Wait States will vary
between different PC's, processor clock speeds, and combinations of
external cards.  Empirical analysis (read: trial and error) is the best
method, since the goal is to obtain the fastest reliable operation for the
machine in question.  Many BIOS's allow independent numbers of wait states
to be specified for 8 bit I/O operations (parallel and serial ports) and 16
bit I/O operations (most network interfaces), and different values may be
required for optimal performance.

FPServer's throughput MAY be improved by reducing the number of I/O Wait
States.  Reduce the number of wait states ONE INCREMENT AT A TIME and
carefully observe the results.  You should reboot the machine multiple
times to confirm reliable operation with the new values.

Be sure to record the original values of all parameters before altering
them.  It may become necessary to restore them in the future as other cards
are added to the system.



===========================================================================
ERRORS AND TROUBLESHOOTING
===========================================================================

This section discusses some common problems and possible solutions.


PARALLEL PORT RUNS WITH PRINTER TURNED OFF
-----------------------------------------------

FPServer's parallel ports use the BUSY line to control data flow.  A
printer holds its BUSY line inactive when it is ready to receive another
byte of data.

Depending upon the design of the printer's parallel port circuitry, the
printer may allow the BUSY line to "float" to its inactive state when
turned off.  Since FPServer never sees the BUSY line go active, it assumes
the printer is ready to accept data and faithfully transmits it.

If you are experiencing this, you may confirm that the printer is floating
BUSY to its inactive state by turning off the printer, starting FPServer,
letting it begin transmitting a job to the printer, and then disconnecting
the cable from the back of the printer.  Most likely, FPServer will stop
transmitting immediately.  (Hewlett Packard LaserJet 4's behave in exactly
this manner.)



DISPLAYED JOB SIZE CHANGES DURING PRINTING
-----------------------------------------------

FPServer displays the size of the Current job while it is being serviced.
Initially, the size of the job is the number of bytes in the print queue.
However, the ACTUAL number of bytes can increase if either the banner or
formfeed options are enabled.

FPServer works hard to display accurate data.  If a banner is generated for
the job, the number of bytes associated with it are added to the job size
display.  If multiple copies are selected and the formfeed option is
enabled, the job size display will increment at the end of every copy.
This is normal, correct behavior and does not represent an error.



MESSAGE "Network Error: Abort, retry" APPEARS
-----------------------------------------------

FPServer's auto-reboot feature tracks the state of the host PC and will
perform a reset if it appears that the shell has lost connection with the
file server(s).  The length of time that FPServer will wait before
auto-rebooting is programmable with the BOOTDELAY command.

If the value you specify with the BOOTDELAY command is too long, though, it
may exceed the timeout delay of the shell itself.  In this case, the shell
will most likely display its infamous "Network Error: Abort, retry" message
and sit there waiting for you to answer the question.

The appearance of this message has no effect on FPServer's auto-reboot;
once the specified number of seconds has elapsed FPServer will still reboot
the host PC.  If the message causes concern for you or other users,
progressively reduce the value in the BOOTDELAY command until FPServer
reboots the machine before the shell notices what's wrong.  Please note,
however, that this is strictly an OPTIONAL step and is not necessary for
successful operation.



FLOPPY DRIVE SEEKS AT START OF EVERY JOB
-----------------------------------------------

FPServer print servers which boot from a floppy drive may seek that floppy
when print jobs start.  This is caused by a bug in Novell's NETX shell:
When trying to open the NETQ device, the default drive is always checked
for a file of that name prior to the shell intercepting the error and
handling it as a network operation.

This bug is completely unnecessary and entirely fixable.  Unfortunately,
Novell's official position on this bug is Yes, they do acknowledge it
exists, but No, they are not going to fix it in NETX.  Instead, they
recommend that sites experiencing this problem change their shell from the
NETX environment to the NetWare v4.0-style "VLM" environment (which does
not exhibit the problem).

I am currently developing a workaround to this problem which may appear in
a future release of FPServer.  In the meantime, you may safely ignore this
phenomenon; it is irritating, but does no damage.



PRINT JOBS START IN MID-LINE
-----------------------------------------------

FPServer generally acts as a straight wire between the print queue and the
printer: It passes the data exactly as found, adding and subtracting
nothing.

If the application which generated the print job did not include a printer
reset at the beginning of the data, the printer will most likely start
printing the job from the last printed position of the most recent job.
Often this is right in the middle of a line.

The easiest way to solve this problem is to use Novell's PRINTDEF and
PRINTCON utilities to define reset commands for the printer(s).  When
finished, be sure to invoke the resulting printer definitions in your
CAPTURE and NPRINT statements.

Note that enabling the formfeed option does not change this behavior.  A
formfeed is a single byte which does exactly that: Feeds a single form,
without changing the current printing position.  No carriage return nor
linefeed is issued, and most printers do not automatically reset the
print position just because a formfeed was received.

Banners, however, DO generate a trailing carriage return.  Since the
printer will have been printing the contents of the banner, its print
position must be reset to some known position - and the carriage return
provides this service.



CAN'T LOG IN AS MULTIPLE PRINT SERVERS
-----------------------------------------------

You may only use a single print server name with any one file server. Even
if all seven ports are servicing print jobs from a single file server, the
print server's name must be identical on EACH AND EVERY portQUEUE command.

This limitation is imposed by Novell.  NetWare will not allow you to log in
to a file server as multiple entities simultaneously.  You must select a
SINGLE print server object on each file server, give it rights to service
all desired print queues on that file server, and use that
fileserver/printserver pair in each portQUEUE command which refers to that
file server.



MESSAGE "<1 BPS" APPEARS
-----------------------------------------------

FPServer determines a job's data rate by dividing its total size by the
number of seconds it took to transmit.  If the job took an extraordinary
length of time - or if the job is very small - the number of seconds may
exceed the number of bytes in the job.  When this happens, FPServer
displays "less than one byte per second", or <1 BPS, because the job really
DID average less than one byte per second.

A common reason for jobs taking longer than their byte count is that
the printer was left offline.  By the time someone notices it, the job
may have been "started" for quite a while - and enough time will have
passed to generate the "less than" message.



LASERJET DOESN'T AUTOMATICALLY RESET
-----------------------------------------------

When you Delete or Restart a print job using FPServer's console, the
parallel port's INIT line is activated to inform the printer that it
should reset itself and flush any data left in its buffers.

Unfortunately, Hewlett Packard has chosen to ignore the INIT line on
its family of LaserJet printers.  It is impossible for any software -
including FPServer - to send a hardware-based asynchronous reset to
a Hewlett Packard LaserJet.

Hewlett Packard's suggestion is to send a PCL software reset command (ESC
E) to the printer.  However, this will not work if the printer is "lost" in
its data stream (for example, in the middle of a graphics or font
transfer).  To cover all possible problem cases, the printer must provide
support for a reset at any time... and the industry-standard way to do this
since the 1970's has been the parallel port's INIT line.

There is no workaround for this problem; you must reset your LaserJets
manually.  (One of the main reasons for the portRESETDELAY command was to
specifically allow users enough time to manually reset LaserJets.)



PRINT JOBS APPEAR "STUCK" IN THE PRINT QUEUE
-----------------------------------------------

These are most likely print jobs with a target print date or time which is
still in the future.  Such jobs may "bubble" to the top of the print queue,
yet remain unserviced while other, "later" jobs pass them by.  You may
confirm this by running Novell's PCONSOLE and examining the job's target
date and time fields.

FPServer's Pending job display generally shows only those jobs which are
actually ready for printing.  Print jobs which are still under construction
("Adding", as shown by Novell's PCONSOLE) or those which specifically
request service by a different print server are not shown.

The one exception to this rule is print jobs which meet all other
requirements but have a deferred print date or time.  FPServer includes
these jobs so you may use its Prioritize option to immediately print them.
If this were not so, you could not highlight them and thus the Prioritize
option would not be available.



CONSOLE RESPONSE IS SLOW DURING PRINTING
-----------------------------------------------

FPServer optimizes throughput over everything else.  If a print job is
being serviced which the target printer is willing to accept at a high rate
of speed, FPServer will allocate more resources to that port.  These
resources are thus unavailable for processing keystrokes and the display.
Normal console response will return when the high speed job is finished.



PROBLEMS WITH SERIALLY-CONNECTED PLOTTERS
-----------------------------------------------

Most serial devices provide hardware handshaking (or "flow control") via
the Data Terminal Ready (DTR) signal.  However, some devices - especially
pen, thermal, and electrostatic plotters - use the Clear To Send (CTS)
signal instead.  The specific name of the signal is not important - but it
is CRUCIAL to connect the correct output of the print device to the DSR
input of the host PC.  Be sure to review the documentation for your print
device if you are experiencing handshaking problems.



TIMING PROBLEMS AFTER SEVEN YEARS
-----------------------------------------------

FPServer's internal timebase overflows after approximately 7.5 years of
continuous execution.  Be sure to stop, and then restart, FPServer as you
approach 7.5 years of uninterrupted operation! (smile)



===========================================================================
TECHNICAL DETAILS
===========================================================================

VALID PARALLEL AND SERIAL HARDWARE
---------------------------------------

FPServer always confirms the presence of valid parallel and serial
hardware. This is necessary because some software (including Novell's NETX
shell) can attempt to "simulate" ports for which no actual hardware exists.
Since FPServer interacts directly with port hardware, its absence could
cause operational problems and loss of data.

The verification process is based upon the circuit design used by IBM for
their original Personal Computer in 1981.  Later variations on this design
have appeared in various platforms, but most attempt to remain downward
compatible with the original.  Since the original IBM design is the only
one which can be considered a "standard", FPServer only requires that basic
level of capability.

For parallel ports, FPServer confirms the presence of an eight bit latch
and an eight bit readback buffer.  On the original IBM PC's parallel port,
a 74LS374 octal D-style flip flop was used to store data written to the
port's data address.  The outputs of these eight flip flops drove the data
pins on the output connector - and they also drove the inputs of a 74LS244
octal buffer.  This buffer provided "read back" capability to the parallel
port hardware which was tested by the BIOS during initialization.  FPServer
confirms the presence of a valid parallel port by writing various bit
patterns to the octal flip flop and reading them back via the octal buffer.
If the write and read data match, the port is assumed to be valid.

For serial ports, FPServer confirms the presence of an 8250-style UART
device at the specified address.  8250-style UART's contain read-write
registers, some of which have bits which are forced to a known state.
FPServer tests several of these registers, and if their behavior is as
expected the port is assumed to be valid.



INTERRUPTS
---------------------------------------

FPServer uses software interrupt 1C hex, the Timer Service Routine, for
various purposes.  It does NOT use nor redirect hardware interrupt 8 (IRQ
0), the hardware Timer Tick, but instead lets the Timer Tick service
routine call it via interrupt 1C hex.  FPServer's Int 1C routine "chains"
itself into the call sequence in the appropriate manner, and passes control
to the original Int 1C vector upon completion.  When FPServer is terminated
by pressing Escape, the original Int 1C vector is properly restored.

FPServer does not use any hardware port interrupts.  All of the IRQ lines
normally associated with parallel and serial ports (typically IRQ's 3, 4,
5, and 7) are ignored.  FPServer does NOT disable them at the 8259A
interrupt controller, however, so they may be used for other purposes (such
as the network interface card) if necessary.  Please note that, if the
interrupt lines are in use by another program, an appropriate driver must
be installed to service them.



"SAFE" VS. "FAST" PARALLEL OPERATION
---------------------------------------

There is no universally recognized timing diagram for a "Centronics"
parallel port.  Different manufacturer's specifications offer a variety of
minimum and maximum pulse widths for Strobe, Busy, Acknowledge, and the
other signals which comprise the hardware handshaking system for this
industry "standard".  Even different product manuals from Centronics itself
do not agree on a single set of values.

The vast majority of modern print devices treat Strobe as an "edge
sensitive" signal, which can be briefly interpreted as meaning that the
width of the pulse is less important than the fact that a pulse actually
occurred.  FPServer's "Fast" parallel mode takes advantage of edge
sensitive devices to dramatically increase data throughput.

However, print devices may exist which are "level sensitive", meaning that
they expect to see Strobe stay active for a some minimum period of time.
Since there is no industry standard for a Centronics port's strobe pulse
width, FPServer's "Safe" parallel mode uses a value of 500 nanoseconds as
stated in the original IBM Personal Computer Technical Reference manual
(IBM document number 6025005), page 2-81.

FPServer's "Fast" parallel mode has been tested with a wide range of
parallel devices and, to date, none have proven incompatible.  All parallel
ports default to "Fast" mode unless a corresponding portMODE=SAFE command
appears in the FPSERVER.CFG file or on the DOS command line.

"Safe" mode has been included to guarantee compatibility with the maximum
number of different parallel devices.  However, for maximum throughput,
"Fast" mode is highly recommended.



===========================================================================
BUGS AND OTHER ANOMOLIES
===========================================================================

There are no known bugs in FPServer.  However, that does not mean that none
exist!  Bugs will be corrected as they are discovered (by me) or reported
(by you).

Please be sure to retry any failed operation before assuming it is a bug.
Any number of events can corrupt data flowing over a network cable (failing
network interface card, accidental disconnection of the cable, etc.).  If
it happens once, and you cannot repeat it, it probably isn't a FPServer
bug.

If you have what appears to be a legitimate bug, I WOULD LIKE TO HEAR ABOUT
IT!  Please be sure to document the hardware and software environment of
the bugs, along with (if possible) copies of the files which were being
printed at that time.



===========================================================================
ABOUT THE AUTHOR
===========================================================================

My name is Richard L. Hartman.  I have over 12 years of formal experience
in the Electronics industry which started in analog circuitry and
progressed through the disciplines of discrete digital, integrated digital,
microprocessor, software, and management.  My employment history includes
both Engineering and Marketing departments for everything from five-man
startups to companies with thousands of employees.

Along the way I have designed many successful products - the most prominent
of which is probably the Key Tronic KB5151 Enhanced PC Keyboard, the first
to have separate cursor and numeric keypads.  Over 250,000 KB5151's have
been sold and its standard continues to influence keyboard design to this
day.

My consulting efforts are now concentrated in the area of Local Area
Networks - specifically the development of software which runs with, and
takes advantage of, Novell's NetWare Operating System.  I am a Novell
Registered Professional Developer and actively pursue all topics, in all
disciplines, which involve this market segment.

Products like FPServer are my answer to the extremely high cost of
advertising in magazines and trade journals.  I simply cannot justify the
money necessary to elevate myself and my services above the "noise floor"
established by multi-million dollar companies and their multi-page color
advertisements.  Instead, I invest my TIME writing software which
(hopefully) has broad appeal and allows potential clients the opportunity
to sample my work without risk or expense.  Then, if you like it, you can
pay for it.  You incur zero up-front expense and zero risk.

My consulting services include:

     Conceptual: A confidential, objective sounding board for new ideas
    Feasibility: Assessment of technical viability
    Engineering: Actual product design and development
   Modification: Adding network intelligence to existing products
        Testing: Verifying network compatibility
       Training: Adding network programming to your staff's skill set
 Recommendation: Network-oriented analysis of your current/future products

If you create network software - or are planning to - please contact me:

                         Richard L. Hartman (RLH)
                 Novell Registered Professional Developer
             5205 North Mulvaney Court, Spokane, WA 99212-1611
     509-924-6576 (Voice)   509-926-4626 (Fax)   CompuServe 76350,2275