Figure 6.8 The Print Monitor Component
Print monitors are components that the local print provider uses to transmit completed print jobs to various ports and the print devices attached to those ports. The five print monitors supplied with Windows NT — Local, Macintosh, Digital, HP, and LPR — are described in this section.
The next section is an overview of how to use Print Manager to create a port to use one of the Windows NT print monitors. Following sections discuss many of the major configuration issues associated with these monitors, but you can get additional detailed information by choosing the Help button in the dialog box for each monitor.
In the Printer Properties dialog box, the Print To listbox lists the default Windows NT ports.
By default, the list in the Print To box includes only standard ports controlled by the local print monitor, LOCALMON.DLL. When you want to print over other communications channels (to a network-attached printer, for example), you must create a new port. To create a port, select Other from the Print To box. The Print Destinations dialog box then lists the available print monitors.
Note Monitors often depend on other software components and do not appear in this list unless you have loaded the components they require. For example, the Hewlett-Packard Network Port monitor transmits print jobs using the DLC network protocol, and you will see this monitor in the list only if you have installed DLC.
Select the monitor that controls the type of communications channel you want to use, and then choose OK. The monitor then displays its own user interface, which you use to create a new port. After you have created the new port and configured a printer to use that port, the Settings option in the Printer Properties dialog launches the monitor user interface again, if the monitor allows reconfiguration of a port.
When you read details about each monitor in the following sections, remember that each print monitor is concerned with a data communications channel, not with the print device at the other end of that channel. In most cases, the print monitor does not know the make or model of print device it is communicating with, nor does it need to know. Also, different print monitors may use the same network protocol, but this does not make them interchangeable. For example, both the Digital Network Port monitor and the LPR Port monitor use the TCP/IP protocol, but they send data over that protocol in very different ways.
The local print monitor, LOCALMON.DLL, is responsible for sending print jobs to local devices. These include familiar ports like LPT1: and COM1:, as well as several others described below.
The FILE: port appears in the default port list in the Printer Properties dialog. When you send jobs to a printer that uses this port, the local print monitor prompts you for the name of a file in which it will store the print job.
If you select Other from the list of ports in the Print To box of the Printer Properties dialog, and then select the Local Port option, the local print monitor prompts you to enter a port name. Some possibilities include:
The Macintosh print monitor, SFMMON.DLL, is responsible for transmitting jobs over a network, using the AppleTalk protocol, to network-attached print devices such as the Apple LaserWriter family. It also lets you send jobs to AppleTalk spoolers, regardless of the print device that the spooler is attached to.
The configuration dialog for this monitor is shown below. It displays the available network zones, lets you choose a zone, and then shows the available printers in that zone.
This monitor is available on both Windows NT Workstation and Windows NT Server computers, letting any Windows NT-based computer send local print jobs to AppleTalk printers. However, only Windows NT Server has a Macintosh print server component, so only a Windows NT Server computer can receive print jobs from Macintosh clients.
The Digital Print Monitor, DECMON.DLL, sends print jobs to Digital Equipment Corporation's Digital PrintServer print devices, and other Digital Equipment Corporation print devices such as the DEClaser 5100 and the DECcolorwriter 1000. This monitor's user interface lets you select the print devices you want to print to, and the network protocol to use.
Windows NT supplies the TCP/IP network protocol, but does not supply the DECnet™ protocol. If you want to use DECnet, you must contact Digital Equipment Corporation to obtain it.
The Hewlett-Packard Network Port monitor, HPMON.DLL, is responsible for sending print jobs to HP JetDirect adapters. This includes both the network adapters commonly installed in printers such as the LaserJet 4 Si and the JetDirect EX device, which lets you connect any parallel print device to the network.
Many JetDirect devices can communicate over several different network protocols, including DLC, IPX, TCP/IP, and AppleTalk. HPMON.DLL is specific to DLC: you must load the DLC protocol in order to use this print monitor, and it is not able to transmit jobs over other protocols.
This monitor has several operating parameters to be aware of.
Note If you configure two Windows NT print servers to send jobs to the same JetDirect device, configure both servers for Job Based connections. If you configure one of the print servers for Continuous connections, then when it sends its first print job, it will "claim" the JetDirect for itself, preventing the Job Based server from connecting.
LPR is one of the network protocols in the TCP/IP protocol suite. It was originally developed as a standard for transmitting print jobs between computers running Berkeley UNIX. The LPR standard is published as Request For Comment (RFC) 1179. Windows NT complies with this standard, as do most Berkeley UNIX operating systems. However, most System V UNIX operating systems do not comply with this standard, so in most cases Windows NT will not be able to send print jobs to System V computers, or receive print jobs from them. Exceptions are System V computers that are configured to accept BSD jobs; these computers can accept Windows NT print jobs.
The LPR protocol lets a client application on one computer send a print job to a print spooler service on another computer. The client application is usually named "LPR" and the service (or "daemon") is usually named "LPD." Windows NT 3.5 supplies a command line application, the LPR.EXE utility, and it supplies the LPR Port print monitor. Both act as clients sending print jobs to an LPD service running on another computer. As mentioned previously, Windows NT also supplies an LPD service, so it can receive print jobs sent by LPR clients, including UNIX computers and other Windows NT computers.
The LPR protocol was not designed to pass detailed error status information back to the LPR client. If anything goes wrong, from severe problems (such as the server being too busy to process requests) to print device problems (such as running out of paper), the LPR protocol reports the same error condition. As a result of this protocol limitation, Print Manager cannot provide detailed information when an error occurs printing on an LPR port.
In order to send print jobs, the LPR client needs to know the network address of the LPD server computer, and it needs to know the name that the LPD service associates with its print device. Given this information, LPR sends print jobs to the LPD service, along with instructions on how to process the print job, and the name of the print device that should receive the job. The user interface shown below lets you tell the Windows NT LPR Port monitor which computer should receive the job, and which of the computer's print devices ("queues" in UNIX terminology) the job should go to.
Use the Name Or Address of Host Providing LPD box to tell the LPR Port monitor which UNIX computer it should send print jobs to. You can supply either the IP address or the host name of the UNIX computer.
For example, suppose you want to send jobs to a printer named "lablaser" on a UNIX machine whose IP address is 111.222.333.444, and whose name (defined in the hosts file on your Windows NT computer) is "unixbox". In the dialog above, you could enter either "unixbox" or "111.222.333.444" (without the quotation marks) in the Name Or Address Of Host Providing LPD box, and you would enter "lablaser" in the Name Of Printer On That Machine box.
If you don't know a valid name for the printer, you can often find it by looking at the /etc/printcap file on the UNIX computer. The printcap file is a flat-file text database of print queue information. Each entry corresponds to a print queue on the UNIX computer. Fields in these entries are separated by ":" characters, and for readability an entry may be broken over several lines by ending a line with a "\" character and beginning the next line with a space or tab character. The first field of each entry lists valid names for the queue, separated by "|" characters. The remaining lines in each printcap entry describe the queue's characteristics, such as communications parameters, spool file location, error log file location, and so on.
Continuing the lablaser example, we might find entries like the following in the printcap file on the computer named unixbox:
lp|lablaser|The_Lab_Printer:\ :lp=/dev/ttya:br#9600:\ :lf=/usr/spool/lpd/lablaser-err:\ :sd=/usr/spool/lpd/lablaser:
Note This example is provided for illustrative purposes only. Your UNIX system documentation is your best source of detailed information on your system's printcap file.
The first line in this example defines a print queue with three valid names: "lp", "lablaser", and "The_Lab_Printer". You can use any of these names in the second field of the LPR Port dialog shown above.
Once you tell the LPR Port monitor the LPD server's network address and the proper queue name, it can send print jobs (data files) and processing instructions (control commands contained in a control file). RFC1179 defines 29 control commands, but the three described below are particularly important. Note that all the control commands defined in RFC1179 are case sensitive.
Note Many printer languages, including PCL, rely heavily on the ESC control character, which the f control command causes to be filtered from the print job. Do not use the f control command when sending print jobs that contain printer commands.
The LPR Port monitor sends the l command by default, while the command line LPR.EXE utility sends the f command by default. With the LPR.EXE utility, you can use the -o switch if you want to override the default on a job-by-job basis. If you want to change the default command for a particular printer controlled by the LPR Port monitor, you need to modify a registry parameter. Use the Registry Editor (REGEDT32.EXE) to find the key named HKEY_LOCAL_MACHINE\SYSTEM
\CurrentControlSet\Control\Print\Monitors\LPR Port\Ports. Next, select the port whose default control command you wish to change, and then select its Timeouts key. In this key, add a value named PrintSwitch with type REG_SZ, and enter the control command you want to use. For instance, enter the letter "f" (without the quotation marks) if you want to use the "f" command by default.
Some UNIX computers do not follow the control commands alone when deciding how to process a print job. For instance, if you send an ASCII text file directly to a PostScript printer, it will not print correctly. As a result, many UNIX systems have additional software that converts ASCII text jobs into PostScript jobs which will print correctly. System administrators are wary of jobs that arrive with a l command, because they could be non-PostScript jobs accidentally sent with an l command, which would let them bypass the PostScript software and print incorrectly. To avoid this possibility, some LPD services scan jobs that arrive with the l control command, looking for known PostScript commands: if the scanner finds these commands, then it passes the job directly to the printer as requested; otherwise, it assumes the user sent the wrong control command, and it sends the job through the PostScript software. If you send PostScript jobs from Windows NT using LPR, and the printer controlled by the UNIX server prints the PostScript code instead of interpreting it, then the UNIX server may have a scanner that does not recognize the output from the Windows NT PostScript driver as valid PostScript code. If this happens, you may need to reconfigure Windows NT to use the "o" control command by default.