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
THE LPD PROTOCOL
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.