Resources

Barr Solutions:TCP/IP Printing From the Mainframe

High-volume production printing introduces unique challenges to the attempts by many customers to integrate the TCP/IP environment with their mainframe environment. This article addresses some of the challenges that arise when companies attempt to connect PC-based Print Servers that support legacy print streams to the mainframe over TCP/IP.

The Job Entry System and TCP/IP

The Job Entry System (most commonly JES2) functions as the print spooler on an IBM mainframe and controls the printers directly. It was designed to control channel-attached and SNA-attached printers, and was not designed to communicate with TCP/IP printers or ASCII-based systems. To print to TCP/IP printers or ASCII-based systems, companies have to make changes or additions to their printing infrastructure.

The standard way to resolve this inherent incompatibility between JES and TCP/IP is to introduce a printing software package on the mainframe. The printing software operates on the output side of JES and uses various techniques to get the print jobs out of the JES output or SYSOUT queue. Then it delivers the output to printers or print servers over TCP/IP, often manipulating or transforming the print data in the process. In this way, the new printing software package supports TCP/IP so that JES doesn't need to.

Some common mainframe printing software packages that support TCP/IP include: IP PrintWay from IBM; PSF from IBM; VPS/TCPIP from Levi, Ray and Shoupe (LRS); and XPAF from Xerox. All of these software packages have options to support sending the print jobs over TCP/IP, both through the LPR/LPD protocol and also through a direct TCP/IP socket.

When using these software packages to send print jobs to a remote print server, rather than directly to a printer, several considerations arise:

• Data Integrity: are the data and carriage control passed through intact?

• Job Attributes: will the print server receive job information?

• Dataset Grouping: are multiple datasets within a job grouped appropriately and transmitted as a single unit?

Let's address each of these questions, and see what solutions are available.

Data Integrity

One of the premises of this discussion is that legacy data, such as Line Data, Xerox LCDS or Metacode, or AFP data needs to be sent to a remote print server without translation. The mainframe printing software packages typically offer a 'binary' option, but this results in the loss of record structure information for all legacy formats except fully composed AFPDS.

There is no single standard format for transmitting this mainframe print data, but a couple of de facto standards are emerging. The best format uses a two-byte length field followed by carriage control and then data, which in BEPS is called the 'Mainframe IP Record Format.' It is supported by XPAF, IP PrintWay, VPS/LCDS and also by Xerox EPS printers. The bottom line is that you will need to test the data transfer format between the print software on the host and the print server software.

Job Attributes

The second concern in getting jobs to a remote print server is passing useful job attributes or header information along, so that the print server has job information to work with. The bare minimum is a job name or file name. In the mainframe environment, the typical work selection criteria of Destination, Form name and Class are also important to the users in their workflow and decision making.

The LPR/LPD print protocol provides the job name through the Control File mechanism, as well as a queue name and user name, but not the mainframe fields such as Form and Class. IBM’s IP PrintWay has solved this problem by extending the Control File with –o options to pass all the job attributes.

If you use the direct socket connection, the situation is even worse, since a socket connection has no mechanism at all for passing job information, even for the job name. Some vendors have worked out techniques such as passing a header record in the data, but this is another aspect that needs to be investigated and tested.

Dataset Grouping

On the mainframe, a 'job' (which originates as a set of JCL instructions) can generate multiple pieces of output, or datasets. The datasets within a job that share the same print attributes, such as Destination, Form, Class and FCB, will be bundled together by JES as if they were a single unit of print, called an 'output group.' JES will display the output group as a single entry in the JES queue to allow operators to release or route the group as a unit. When JES prints an output group to a traditional channel-attached or SNA-attached printer, it will again treat it as a unit of print, printing a single banner at the beginning and a single trailer at the end of the group (if separators are turned on).

The problem arises when the new printing software on the mainframe gets multiple dataset jobs out of JES and sends them out through TCP/IP. Most of the software packages mentioned have options to group the datasets just like JES would, but the user has to make sure that these options are properly enabled so that the printing software sends the output group as a single transmission over TCP/IP, and handles the banners and trailers appropriately.

An Alternative: 'Virtual' Channel Extension over TCP/IP

Barr Systems offers a unique alternative for TCP/IP-based mainframe printing that does not involve any special printing software package on the mainframe. This alternative can be described as 'Virtual Channel Extension over TCP/IP,' and is illustrated in the diagram (shown on right).

The concept is simple: instead of installing special printing software on the mainframe, the user installs a channel-attached BEPS with BARR/PRINT CHANNEL using Barr channel adapters for either ESCON or Bus & Tag connections. The BARR/PRINT CHANNEL option emulates an IBM 3211 channel-attached printer, which is native to the IBM mainframe and understood by JES. With this solution, JES can print directly to the print server over the channel, but without the need for any special printing software on the mainframe. BEPS then routes the data over the TCP/IP network to any other BEPS at remote sites to drive network or channel-attached printers.

Here are a few of the advantages of this Virtual Channel Extension solution:

• The connection to the mainframe is native, and requires no additional printing software on the host.

• The data transfer is secure. In BEPS version 4.0, Barr supports encryption in server-to-server transfers over TCP/IP.

• All of the issues regarding data integrity, job attributes and dataset grouping are addressed.

Virtual Channel Extension provides customers an alternative to implementing printing software on the mainframe in order to use TCP/IP. With many vendors beginning to support de facto standards, Virtual Channel Extension uses the existing capabilities of the mainframe without large scale changes. If you think Virtual Channel Extension can help your organization, please contact Barr…

We take pride in customer Service and Support