Products   Support   Download   Contact

LPD NOTES, PARTICULARLY FOR SCRIPTSERVER® FOR OPENVMS V5.0-6 OR LATER

revised: 12-Aug-2002

Contents | Index | About the Icons

Purpose of this Memo

This memo primarily documents the pitfalls of supporting LPD with current versions of one particular product, ScriptServer for OpenVMS. LPD support is implemented differently in our ScriptServer PAN Printing System product and for a variety of reasons we haven't seen any need to write a separate memo addressing possible issues there.

Nonetheless, the pitfalls are instructive and there is some good general information about the vagaries of various LPD implementations in the content which follows.

In all of what follows, unadorned use of the name ScriptServer should be interpreted to mean specifically ScriptServer for OpenVMS.

What is LPD?

LPD stands for line printer daemon protocol, which is one of several ways to exchange print jobs between hosts on a network. LPD is also implemented by many printer manufacturers as one possible way to connect to their printers.

The kinds of connections that can be used to send print jobs across the network include:

ScriptServer for OpenVMS has direct support for TCP, LPD and LAT connections. Other network protocols can usually be supported via routing to a foreign queue.

When ScriptServer software sends jobs using LPD protocol, it implements the LPR, or client side, of the protocol.

LPD versus TCP

ScriptServer can do its best when it has a true bidirectional connection with the RIP engine in the printer. Especially in the case of PostScript RIPs, this allows ScriptServer to query PostScript environment variables to determine the capabilities and status of the printer.

LPD does not provide the sort of open-ended dialogue with the printer that a TCP stream connection provides. Consequently ScriptServer has to make some guesses (defaults) and you have to configure the capabilities of your printer if you want anything special from it. LPD also doesn't provide fault notification, such as paper-out conditions; to get that with LPD, you need to configure syslogd.

LPD is a protocol that runs on top of a TCP connection. But it does not establish a bi-directional connection to the RIP engine. Instead it establishes a connection with a queue manager within the printer/server.

The "NOS"

If you call vendor technical support for help configuring your printer, you may be asked what network operating system, or "NOS", you're using. Usually what they're referring to is which workstation protocol you're using. However you're not using a workstation protocol.

Documentation

The documentation for using LPD protocol and ScriptServer is the collective set of the following documents, plus the documentation for your line printer daemon if you are sending ScriptServer output to an LPD queue on a VMS, Unix or NT server.

NOTE: You don't need any documentation on your OpenVMS TCP/IP stack's implementation of LPD to print from Scriptserver using LPD/LPR. ScriptServer has its own implementation of LPR.

V5.1 Addendum

The ScriptServer V5.1 User Guide Addendum contains a chapter on LPD setup. This is the best reference for ScriptServer v5.0-6 or later.

You can obtain this addendum in both PostScript job (.PS) or Adobe Acrobat (PDF) format by visiting our download page.

This memo, Technical Memo number 84

This memo supersedes Technical Memo #65. We recommend that anyone using ScriptServer with LPD/LPR upgrade to ScriptServer version 5.0-6 or later.

RFC 1179

The LPD protocol grew piecemeal from the evolving need for distributed and remote queue management on Unix systems. RFC 1179, Line Printer Daemon Protocol states that it is "..not a standard..". Nonetheless it is a good faith attempt to document the implementations of LPD/LPR in practice.

Using ScriptServer's LPD Compatibility

You may need information beyond what is available in the ScriptServer documentation to successfully configure LPD/LPR. Familiarity with the particular implementation of line printer daemon as well as a familiarity with the concepts in RFC 1179 will aid you immeasurably.

Specifying the Printer Service or Queue with /ON

You need to specify the line printer daemon (LPD) queue name. On Unix systems, the system manager usually sets up the names of the queues. On printers, the default queue names are usually coded into firmware.

When starting a ScriptServer queue on a networked printer with the lpd protocol, the "device" on which to start a queue must be designated in the following format:

START/QUE/ON="remote_queue@tcpip_address" etc..

NOTE: The device (remote queue) specification is case sensitive. If you are using ScriptServer's "gethostbyname" support, the printer node name can be substituted for the tcpip_address. Device-specific logical names for controlling options are also case-sensitive.

Queue Names can be used to Identify Job Format

The remote queue name varies with each network printer card manufacturer. There are usually at least two "queues" on every card, one for text files that inserts linefeeds after each line, and one for PostScript that will not alter the data. ScriptServer requires that you select the PostScript or "raw" remote queue.

Robust LPD

ScriptServer has what it refers to as Robust and Non-Robust transmission modes. Non-robust is the default. This can be controlled with the SSV$queue_ROBUST_LPD logical name. The Control File and the Data File are described in RFC 1179.

Non-robust LPD

In non-robust mode, ScriptServer sends the Control File and then it sends the Data File. When sending the data file, it sends the length as zero because it can't calculate the exact length in bytes of the job without spooling it first. Then it sends the print file. Then it sends a null (all zeros) octet to terminate the data file.

Robust LPD

In robust mode, ScriptServer spools the job in order to compute the exact byte count. The Data File is sent first, with an accurate byte count. Then the Control File is sent.

LPD Data Type

Line printer daemons can process many different types of job streams depending on the implementation (at least in theory). RFC 1179 calls out quite a number of them.

In practice very few or possibly only one will be supported in the the majority of instances; sometimes the data type is ignored and the type of data being sent in the stream is implied by which queue or service it is sent to as described previously.

The output of a default ScriptServer configuration is PostScript; whether it received a PostScript file for printing or converted ASCII text into a PostScript job. So: on one hand we have PostScript output from ScriptServer and somewhere on the other side of an LPD queue we have a printer that expects to "see" PostScript as input. Based on experience in the field, three values will work most of the time:

use
ASCII
(decimal)
when the strategy is..
o 111 The LPD queue manager knows that it is talking to a PostScript printer and allows PostScript jobs to be forwarded to it for spooling to the printer.
l 108 Sometimes a queue manager isn't capable of dealing with a PostScript job or is simply unaware of what one is. When both the printer and ScriptServer are "playing dumb".
f 102 If neither "o" nor "l" works, try this.

NOTE: You should only have to resort to these recommendations if your vendor or unix system manager has been unable to supply you with the correct value to use.

The data type is usually equated with the queue using the SSV$queue_LPD_DATA_TYPE logical. But for the purposes of testing alternate values on the fly (or for special cases where other job formats are being passed through) you can specify the LPD data type with the job being printed:

PRINT/PARAM=LPD_DATA_TYPE="l" etc...

Table of Possible Settings To Try

The following examples use a TCP/IP printer with an address of "192.100.10.2" Some of this information can be entered in the SSV$CONFIG queue creation procedure. Oftentimes however you will have to create some additional logicals with either $ DEFINE/SYSTEM or with entries in SCRIPTSERVER:SSV$CONFIG.SSV. You may find it easier to create LPD queues with $ INIT/QUEUE.

These settings are provided under the advisement that they are presented for you to try. They may not work, and the information for some of them is incomplete. You may have to experiment with several settings or combinations of settings to get the one that works, depending on what information is available to you about the LPD implementation that you're trying to communicate with.


Card
Printer
Server

Robust
LPD?

LPD
Data Type

Remote Queue

Example

Notes

           
DEC PrintServer TRUE l lp $ START/QUE/ON="lp@192.100.10.2" etc... Your printer's loadhost must be running LPS v5.1 or later.
Microsoft Windows NT v3.51 or 4 TRUE l,o shared printer name $ START/QUE/ON="<printer>@192.100.10.2" etc...  
XCD XJetIV     HP_PRINTER $ START/QUE/ON="HP_PRINTER@192.100.10.2" etc...  
HP JetDirect TRUE   RAW $ START/QUE/ON="RAW@192.100.10.2" etc... On some cards the queue name can be omitted or is ignored.
QMS/Crown     lp $ START/QUE/ON="lp@192.100.10.2" etc... For lpd protocol to work properly on QMS/Crown printers, SPOOLING must be turned ON in the TCP/IP - DECNET sub-menu. This will prevent jobs from being lost on the printer.
Dataproducts     queue name $ START/QUE/ON="lpd_queue@192.100.10.2" etc... lpd is a "lpd gateway" on the Dataproducts VPT printers that must be configured to point to a lpd server queue, in this example, "lpd_queue".
Emulex NETJet     PASSTHRU $ START/QUE/ON="PASSTHRU@192.100.10.2" etc...  
Axis Print Server 560     PR1,PR2, or PR3 $ START/QUE/ON="PR1@192.100.10.2" etc...  
Canon     xjprint $ START/QUE/ON="xjprint@192.100.10.2" etc...  
ScriptServer® PAN LPD Gateway TRUE  

queue name

-or-

queue name/form name

$ START/QUE/ON="queue@192.100.10.2" etc...

-or-

$ DEFINE/SYSTEM PAN "queue/form@192.100.10.2"
$ START/QUE/ON=PAN etc...

See Technical Memo #102.
YourCompany's card or RIP         We encourage vendors to do their own testing and tell us what works best. We'd be glad to list you here.


TCP/IP Compatibility Issues

One of the TCP/IP protocol options is packet coalescence, where the send operation will be delayed to fill up the send buffer for more efficient I/O operations. Whether or not packets are coalesced is determined by the combination of the TCP/IP stack being used and the TCP/IP card on the printer. In some cases, packet coalescence can break the lpd protocol. To prevent this, ScriptServer does not coalesce packets by default, but allows the use of a logical to explicitly enable packet coalescence as follows:

DEFINE/SYSTEM SSV$queue_name_LPD_COALESCE TRUE

ScriptServer also may be connected to a printer or another system that is unable to send the appropriate acknowledgment packets. This will disable the ScriptServer queue. If you wish to attempt to run the queue without these "ACK" packets, disable ScriptServer from attempting to read them with the logical:

DEFINE/SYSTEM SSV$device_LPD_READ FALSE

NOTE: A non-zero Ack is not the same as no Ack. A non-zero Ack is the LPD server telling you it doesn't like something you did. You should not disable Ack receipt when you get non-zero Acks; heed the server's admonishments and determine the source of the problem.


Privileged LPD Mode

Some LPD implementations that require strict conformance to RFC 1179 require that the TCP/IP port from which the LPD connection is made lies within the privileged range of port numbers (less than 1024.) To cause the ScriptServer to use a port number in this range, use the PRIVILEGED_LPD logical name in either the queue-specific, device-specific or system-wide modes, as follows

DEFINE/SYSTEM SSV$queue_PRIVILEGED_LPD TRUE

DEFINE/SYSTEM SSV$device_PRIVILEGED_LPD TRUE

DEFINE/SYSTEM SSV$PRIVILEGED_LPD TRUE
© 2020 GrayMatter Software Corporation