Sep 1 ’03

TCP/IP Printing Protocols

by Editor in z/Journal

We don’t often think of the z/OS system as a very large print server, but in some ways that is exactly what it is. The end result of many mainframe applications is information in the form of a report. In some cases, the report may be viewed and/or archived, but quite often the report needs to be printed on paper.

 In the distant past, each mainframe application controlled its own printers. For example, a printer that was connected to one CICS production system was not available to any other application, including another CICS system. During the 1980s, printers were moved to a VTAM/SNA environment, where they could be shared between different applications. This was a major improvement. Beginning in the 1990s, many companies moved a major portion of their devices from SNA to TCP/IP networks. They found it relatively easy to replace screen-type devices but more difficult to move their printing to a TCP/IP environment.

This article addresses the printing protocols used on TCP/IP networks today and examines some common problems that users face when moving mainframe printing into the TCP/IP environment  


RFC 1179 documented the most commonly supported TCP/IP print protocol, one that was widely used by Line Printer Daemon (LPD) clients and servers. The RFC was intended for informational purposes only and did not specify an Internet standard. Consequently, there are many variations in the way that print clients and servers have implemented LPD protocol.

LPD protocol is described as a print server with a spool and multiple print queues. The LPD server listens on port 515. RFC 1179 indicates that the client should be sending from a port in the range from 721 to 731. Some LPD servers will not accept connections from clients connected at ports other than those in this range; however, most LPD servers do not enforce this restriction.

Commands must be sent from the client to the server, including one to name the printer for which the file should be queued. The client sends a “data file” with the print data and a “control file” with information that will assist in formatting and printing the data. Confirmations are requested and received for the control file and the data file. Figure 1 shows a typical sequence of LPD commands and responses.

Most TCP/IP hosts support a server that will receive data using LPD protocol and then place that data on a spool or print queue to be delivered to a printer. In addition, many printers have the capability of emulating the LPD server and printing the data file as it is received. When a printer is providing the LPD services, the control file is often ignored.

If an LPD client is intended to send to different kinds of remote TCP/IP hosts, the client needs the flexibility to send the data and control files in multiple ways. For example, some LPD servers require that the data file be sent before the control file, while others require that the control file be sent first. An LPD server running on z/OS should be able to accept data from multiple types of clients, which means it should be flexible enough to accept the data file and control file in any order.

The main advantage of using LPD protocol is that it is widely supported. However, there are several disadvantages. LPD protocol does not support checkpoint/restart because confirmations can only be requested at the end of the print data file. In addition, the confirmation indicates only that the print file has been received at the remote host. The print file may or may not have been printed. It can be difficult to determine the reason for an error when using LPD protocol, since there are no defined negative responses.

Another disadvantage of using LPD protocol is that there is no way to query a TCP/IP printer to obtain any configuration or status information, because the LPD protocol is intended to support communication with a print server that would spool the data; the LPD protocol does not describe any direct communication with the printer itself.


Some printers support a direct TCP/IP connection, which provides a “socket-to-socket” connection for a client program to send print files to a printer. This connection is often referred to as “sockets” protocol, and it allows for twoway communication directly with the printer, instead of communication with a print server. The printer has a specific port that is used to listen for a direct TCP/IP connection; for many devices, this port is 9100.

The sender can verify that a print file has been received and that it has been printed successfully by sending commands to the printer and obtaining responses. Because these commands can be used to verify when each page has been printed, this type of connection can support checkpoint/restart. A direct connection can also provide information about the status of the printer, including a condition that requires operator intervention, such as an “out of paper” state. One type of printer-specific command that can be used to communicate with a printer using a direct TCP/IP connection is Printer Job Language (PJL). PJL was developed by Hewlett-Packard (HP) and is supported by most HP-compatible laser printers.

Figure 2 shows an example of a direct TCP/IP connection using PJL commands to communicate with the printer. The print server sends PJL INFO commands to obtain information about the printer, including what printer languages it supports (e.g., PCL or PostScript), whether it supports duplex, etc. Then, the print server sends PJL USTATUS commands to indicate that the sender wants to receive unsolicited status responses when the device status changes, when each page is printed, when the job is complete, and on timed intervals. The server sends a PJL JOB command to indicate the beginning of the print file, followed by the buffers of the print file, and the PJL EOJ command to indicate the end of the print file. The printer responds to the JOB START and then sends a USTATUS PAGE response as each page is printed. When the last page is printed, the printer sends the USTATUS JOB END response with a total page count.

If there are any changes in the device status while the job is printing, the printer will report the status to the print server. For example, the printer will report states that may require intervention, including empty paper trays or a paper jam. When the printer is returned to ready state, it will report the new status and continue printing. If a printer error occurs that does not allow continuation, the print server can remember which pages have printed successfully and resume printing at the next sequential page when the print job is restarted. In the example in Figure 3, the printer responds to the JOB START and then sends a USTATUS PAGE response as each page is printed. When the printer runs out of paper after page 1, the printer sends an abnormal status condition (CODE=41202) to the print server, and the abnormal status code is displayed for the operator. When paper is placed in the proper tray, the printer sends a normal status code (CODE=10001), and the server continues printing. When the last page is printed, the printer sends the USTATUS JOB END response with a total page count.

The most important advantage to using a direct TCP/IP connection is that the print server can ensure that each file has been successfully printed. In addition, the print server can report normal or abnormal printer status to operators; for example, the “empty paper tray” status can be displayed to notify an operator to put paper in the printer. A direct TCP/IP connection also allows the print server to obtain details about the printer configuration. If the print server determines that a file is queued to a printer in a printer language (e.g., PCL or PostScript) that is not supported by the printer, an error can be reported and the file can be held or redirected to a printer that supports the requested language.

The only disadvantage to using a direct TCP/IP connection is that there are a few printers that do not support this type of connection.


Other protocols can be used to deliver print jobs to remote TCP/IP hosts. Some vendors have implemented their own protocols for print file delivery to print servers on other platforms. Control information to describe the file and how it should be processed can be sent, along with the print file. In some cases, the data can be compressed and encrypted.

As an alternative, e-mail protocols can be used to deliver print files to e-mail recipients who can then decide whether it is necessary to print the file. Files that were manually decollated and mailed to various sites can be automatically sent by e-mail, saving time and printing costs. In many cases, the recipient only needs to browse the data and no printing is required.


One of the concerns for TCP/IP printing is that the print file may flow over public networks and might be captured and read by someone other than the intended recipient. Some print servers and printers support encryption and decryption of print files, which can eliminate this problem. The sender encrypts the print file using a special algorithm and the encryption key that is defined at the printer. The receiving printer decrypts the print file before printing.


The print servers on z/OS must be able to send to TCP/IP devices print files that were originally meant for SNA printers, including normal line data (EBCDIC) and Advanced Function Presentation (AFP) files. In some cases, the files must be converted to other printer languages (e.g., PCL or IPDS) and delivered to TCP/IP printers.

Special problems arise when a mainframe application creates print files designed for a VTAM printer, but which now should be delivered to a printer on the TCP/IP network. For example, it may be necessary to redirect a report to a TCP/IP device that CICS or IMS is currently sending to a VTAM-controlled printer. There are print server applications available which emulate a VTAM printer to receive a report and modify the print file so that the report can be queued for delivery to a TCP/IP device. Functions performed could include data translation, processing form feed, line feed and carriage restore characters, understanding commands for vertical or horizontal formatting, handling transparency sequences (for embedded printer commands that are already ASCII), etc.

Tracking files received from other TCP/IP hosts can also be a requirement. Operators need to be able to track files that are queued for a TCP/IP printer to determine the current print status. When a user sends a print file to the z/OS system, that user would like to be able to determine if the file is still queued, is currently printing, or has been printed successfully. In some cases, the person who created the report would like to be notified when the report has printed or when an error has occurred. Print servers running in the z/OS environment should support these tracking options.

The z/OS system is a very large and sophisticated TCP/IP host. Therefore, print servers running in the z/OS environment must be able to handle large volumes of print data as well as large numbers of printers. There may be thousands of printers to support and millions of lines of print data. Accounting for the printing of these reports to bill the appropriate users may be a requirement. In order to quickly diagnose problems with printers in the TCP/IP network, a print server should incorporate a sophisticated monitor and control facility to allow operators and end users to respond to printing problems as they occur.


In order to provide TCP/IP printing in a z/OS environment, you need the flexibility to be able to send print files using different protocols, and in the proper printer languages and character sets. This may mean datastream conversion as well as character-set translation. Your print server should be able to ensure that each file has been received and printed successfully, has the capability to track print files that are queued for a printer, and can monitor the status of each printer. In addition, your print server should provide sophisticated error recovery and be able to handle the large number of print files and TCP/IP printers that the enterprise requires.

TCP/IP printing protocols have evolved over the last decade and many changes will be coming in the next few years. A print server running in the z/OS environment should support the older TCP/IP protocols while embracing any recently developed protocols that could improve performance, reliability, or security. Z