Moving From Terminals and Printers [Coax (3270) or Twinax (5250)] SNA to TCP/IP
The Information technology infrastructure that many firms have relied on for more than 20 years is changing. The move from stable and mature SNA based network toward an IP-based platform creates significant issues for the mainframe and for the peripheral equipment to be transitioned. Through a three pronged approach outlined below, the best-of-breed technologies are introduced which allow a methodic and measured transition for the enterprise seeking long term, incremental investments in a TCP/IP ethernet environment.
IBM designed protocols and network architectures to assure secure and dependable "end-to-end" communications for terminals and printers with its development of the 32xx family for the S/390 based mainframe systems. There are direct corollaries for AS/400 based systems�, but this paper uses the 3270-based platforms for further elucidation. IBM's product lines, originally introduced in the late 1970's, have matured into the products commonly used, even today (e.g. IBM 3178, 3179...3472, 3482, etc. for terminals; IBM 3287, 4230, 6262, etc. for printers; IBM 3274, 3174, 2074 for controllers). The support for host access for terminals has continued as PC's were introduced. Adding a graphical user interface (GUI) as either a web-based solution or as a terminal emulation application has been an ongoing project for many users. Printers, especially impact printers, remain an obstacle. Many users continue to operate terminals attached to the controllers simply because they still need the controller for the printers. With the options presented here, all issues can be addressed with simple, inexpensive, and incremental changes. You can remove the 3174 and SNA architecture behind it.
SNA architecture was based on a synchronous connection between devices, usually in a cascade (the host "synched" with a controller; the controller synched with the terminal, etc.). In the move away from dedicated fixed function terminals (aka "dumb" terminals), software and hardware, which resided on a PC, allowed the PC to emulate a terminal. The Controller (3174 for example) would see the PC as if it were a terminal and continue to use the native coax connection back to the controller. The move from 3270 and its coax cabling to an ethernet-based network presents three challenges simultaneously.
One solution we favor for direct terminal replacement is an Ethernet Terminal. There are three main products in this doman. We prefer the CLI ET2000.
Host printing via Ethernet TCP/IP continues to be an issue. Each proposed work-around (PCL transforms, SNA job buffering, etc.) offers another set of variables and their associated complications.
IBM host systems use a character set called Extended Binary Coded Decimal Interchange Code (EBCDIC). Each character or command sent to a printer is represented by a two digit hexadecimal code (For example, the number "7" is represented by hex "F7"]. By specifying the character set, size, pitch, etc., it is possible to send the two digit hex code to represent any character. Custom character sets could be created to offer any combination of "dots" in a character matrix. Laser printer support was introduced on host systems, which would print via ethernet using PCL (Print Control Language) interpretations. Ethernet attached lasers, printing from a host typically require a "host print transform" which converts the EBCDIC data stream into a PCL command structure. In order to create a document with a resolution of 300 dots per inch (dpi), a whopping 9,000 data points per square inch must be defined. The PCL data stream creates a picture of the document. Instead of sending a string of two character hex codes, one for each character to be printed or interpreted, the output is generated as an image. This brings an enormous strain on the network bandwidth requirements. Incremental replacements belie the significant demands placed on network infrastructure. This is quite inelegant and creates an undo burden on system resources. Additionally, PCL functions are not universal; They are not available on impact printers.
When a host outputs to an IP based printer without IPDS (Intelligent Printer Data Stream) functionality, the print jobs are immediately dumped to the ethernet, without regard for the status of the destination device. Something as simple as a "paper out" error, may cause jobs to be permanently lost. The host must regenerate jobs. Further, users may be unaware that an error has occurred. This is because the printer does not automatically send acknowledgment back to the host, nor is the host listening for such a response. There is no good way to measure the cost of a job not printed or misprinted.
Efficient and complete host printing demands an intelligent design such as IBM's Print Services Facility (PSF), or LRS's VTAM Print Services (VPS). The host-based solution uses Intelligent Printer Data Stream (IPDS) for its AFP support, which when implemented, allows a data set to be generated by the host which sends the printer the data that is to be interpreted (to control the output characteristics) along with the characters to be printed. While originally developed to support advanced graphics, bar coding, etc., IPDS also offered the addition of error recovery, control, monitoring, and job completion acknowledgment via TCP/IP. By giving the printer the intelligence to interpret the data stream, the host and network carry orders of magnitude less data while offering complete host-control and assured job status. These error control functions had been accommodated by SNA protocols, but are lost in the ethernet environment. With the inclusion of IPDS support, no jobs are lost and both the printer and the host acknowledge job status and completion.Conclusions:
Recommendations depend on the details of the particular requirements and installed equipment. In general, though, we propose that we can upgrade, remove or replace all IBM and compatible terminal/printer controllers by using the suggestions herein. This can be done by using most existing printers, terminals and PC's. This low-invasive approach allows a planned rollout and consolidation without significant complication or investment. Each locale can be transitioned conveniently.
If you need SNA for host terminal access then the IDG 9074 offers encrypted sessions and controller consolidation benefits while employing TCP/IP networks or SNA connectivity.
If you need a replacement for a terminal or a PC for host access then the CLI or I-O product lines offer mature 3270/5250 emulation with industry-standard thin client operating systems. Existing PC's can be given full access to thin client applications via the RDP client available with Terminal Server or via the addition of Metaframe to the PC-server.
If you need continued support for your impact printers then the ACC, I-O and Ebox lines of upgrades and converters can augment acquisitions to provide ethernet/IPDS connectivity.
�Please contact your Argecy rep for a roadmap for your AS/400 infrastructure.
� David T. Mendelson, Argecy Computer Corporation 1998, 2005