Shareware Supreme Volume 6 #1

home *** CD-ROM | disk | FTP | other *** search

/ Shareware Supreme Volume 6 #1 / swsii.zip / swsii / 410 / FPS32D.ZIP / FPSERVER.DOC < prev next >

Wrap

Text File | 1993-07-12 | 136.2 KB | 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