A method that is commonly used to permit printing at a site other than where the data is processed is called Mainframe-to-Mainframe communications. By transferring files from one computer to another, the output can be printed anywhere. There are two ways that this communication can be established. The first requires special communications software, front ends, and a mainframe computer at each site. The second method uses systems specially designed to support this mainframe-to-mainframe communications without the special software and front ends. However, the need for a mainframe in both of these options still makes them rather complicated and expensive.
One of the simplest methods used is off-line printing. The file to be printed is usually transferred to a tape medium. The tape is then shipped or carried to the off-line printer where the output is generated. This is usually done when the turnaround time of reports is not critical.
As more sophisticated electronic printers came into use, the communications speeds of the RJE terminals were insufficient to support the high data rates needed. A computer needed to be installed at the remote site to support electronic printers. At about the same time, deregulation and competition of the communications companies made higher speed communications lines more economically available. This is commonly called T-1 communications and can handle up to 1.544 million bits per second. The idea of supporting remote laser, microfiche, and ion-deposit printers over communications links became feasible.
The purpose of channel extension is to permit any device that can be connected to a mainframe’s local channel to be connected anywhere a communications line can extend. The goal here is to insert channel extender components between the mainframe and the locally attached peripherals without either the mainframe or the devices knowing that the environment has changed. No changes are needed on the mainframe’s application software to control the communications. Because the channel extender is external to the mainframe, the speed of light is the only limiting factor on how fast and complicated a channel extension system can be. The communications speed is limitless, and the line speed can be assigned as necessary to drive the devices at channel speeds. There is no limit on the type and number of devices a channel extension network can support; printers, CRTs, tapes, and document sorters can all share a single communications line.
One special concept that is associated with channel extenders is “Channel Emulation/Device Emulation,” which is occasionally referred to today as “spoofing.” The idea is to make the mainframe think that a local peripheral is connected to its local channel. This emulation is done by the channel extender at the host or mainframe site and is called “Device Emulation.”
The channel extender at the remote site performs the “Channel Emulation.” The goal is to make the peripheral think that it is connected to a local mainframe. This technique permits channel extenders to support devices on lower speed and longer length communication lines. In addition, channel extenders can obtain better utilization of the communications facility by using full duplex communications and compression techniques. Channel extenders can also be designed to compensate for delays in long communication lines with some of them even permitting use of satellite communications.
TYPES OF CHANNEL EXTENDERS
There are three different types of channel extenders currently offered today. The first type uses copper or fiber optics to connect the remote site to the host. These are called “Limited Distance” channel extenders. They are limited in the distance between the two sites because of the physical limitations of the signal or the additional delay as the line gets longer. The advantage, however, is that they are simple. They use higher communication speeds which permit them to support higher speed peripherals without any channel or device emulation. The configurations available are usually limited to one channel extension, one communication link, and one channel string of peripherals.
The second kind of channel extender is not limited to distance. These units use emulation and buffering techniques to allow channel extension anywhere. I will use printers as an example to describe how a channel extender would use these techniques to support an electronic printer.
The channel extender takes a line of data from the mainframe and, assuming everything is OK, responds as the peripheral would with a positive acknowledgement. This is done on the mainframe’s channel and is the device emulation part of the process. This information is then sent to the peripheral over the communication line. The channel extender takes responsibility for getting the data to the printer at the remote site intact. Along the way the data is buffered, converted to serial bits, and changed to bytes to be issued across the remote channel. At the same time that the data is being transmitted, the next line of data is taken from the mainframe. This overlapping of processes both permits high utilization of the communications line and also allows the line with long delays, such as satellite communications, to be used effectively. There are some channel extenders in this group that allow for multiple channel connections, multiple links, and multiple strings of peripherals.
These two types of channel extenders do not require any changes to the mainframe’s application or operating system software. Likewise, changes in the mainframe’s software do not affect the channel extenders. The interface between the mainframe and the channel extender is the channel specification that has remained constant throughout the years. The channel extender can be inserted between the mainframe and the peripheral without changing either one.
The third type of channel extender performs the device emulation in the mainframe. This software captures the data before it can be handled by the I/O channel. Then the data is formatted to be sent to the external host and remote channel extender units. It is transparent to the applications but is usally dependent on the version of the operation system.
PRINTERS OVER CHANNEL EXTENDERS
The simplest printers supported on channel extenders are impact line printers, which print one line of data at a time. These small blocks make device and channel emulation very straightforward. Examples of these impact printers include the IBM 1403, 3211, 4245, 4248 and 6262. The STK 2205 can also be easily supported along with any other printer that emulates printers in this family.
As electronic printers were developed, those that emulated these printers were easily included into the channel extension concept. All that is needed to support the higher speed printers is higher bandwidth communications lines. Some printers in this family include the Xerox 4050 and 9700, along with Komstar and Datagraphics microfiche machines.
The next level of electronic printers from an interface point of view is the 3800 and the latest IBM printers that use the Intelligent Printer Data Stream (IPDS) interface. The 3800, which was originally designed to emulate a line printer, had one major addition. While sending the data down in small blocks, it also sends back status information periodically for error recovery purposes. In effect, there are two computers communicating in both directions. This complicates the support of these printers over channel extenders because communication delays become more of a factor. The 3800 also supports a function called Advanced Function Printing (AFP) which increases the size of blocks being sent down and complicates the buffer methods. The IPDS interface is just an extension of the AFP mode from a channel extension point of view. Some members in this family are the IBM 3800, 3835, 3837, and the printers that are designed to emulate these devices.
Channel extenders support this family of electronic printers, but their performance depends on many factors. The delay on the communications link is a factor because of the status information that is sent from the printer back to the mainframe. Furthermore, the large number of bytes needed to print graphics and multiple page images per physical page can stress most channel extension systems.
There are a few printers that do not use either of these types of interfaces. Some emulate channel attached tape units. There are a few that would be considered as non-standard interfaces. Generally, however, if they can be attached to a channel as a local device, they are a candidate for channel extension.
Finally, I will present some real situations in which channel extension can be used to solve problems. It is most commonly used to replace a mainframe. By employing channel extenders, the input-output devices currently connected to a computer can be connected to a remote computer. The company now only needs to purchase and maintain one set of software and to service and maintain one computer. After this is done with a single site, multiple remote sites can be brought into the configuration. There is no limit on how many remote sites can be supported.
Channel extenders are also an important component of disaster recovery. If the goal is to back up the mainframe, channel extenders can be used to run the peripherals from the disaster recovery mainframe. The reverse is also true: if the peripherals need to be backed up, then a site with the backup devices can be connected to the company’s mainframe by using channel extension. One of the defacto benefits of channel extension is that once a channel extension network is employed, the remote sites do not care where the mainframe is located. It can be the company’s host or the disaster recovery host, and the users will not know the difference.
Channel extension should be considered as a viable means to solve the decentralized input/output problem. Channel extenders can support all of today’s electronic printers, along with the CRT terminals and other I/O devices needed to run a remote data processing center. Their performance is only limited by the bandwidth of the communications link. Complex networks can be designed to give users flexibility, reliability, and performance.
Written by Harry Levinson, Systems Engineering Manager for Computerm Corporation, Pittsburgh, PA.
This article adapted from Vol. 3 No. 1, p. 25.