Moving From Coax (3270) or Twinax (5250) SNA to TCP/IP Ethernet for Host Connectivity: A Strategic Guide to Implementation

Moving From Coax (3270) or Twinax (5250) SNA to TCP/IP Ethernet for Host Connectivity: A Strategic Guide to Implementation

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 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 continued as PC's were introduced. Printers, especially impact printers, remain an obstacle. Many users continue to operate terminals attached to the controllers because they need the controller for the printers. With the options presented here, all issues can be addressed with simple, inexpensive, and incremental changes.

For situations in which SNA over IP is an appealing alternative, the IBM 2074, Visara SCON, and IDG 9074 offer replacement campaigns for 3174 and 3274 for consolidation and/or replacement. The prospect of reducing the sheer number of machines to consolidate as many as 32 local controllers with a single "network processor" is quite tempting. Additionally, this technology may allow up to 8,192 SNA sessions to be consolidated into a singe network processor. There are many reasons offered for replacement of 3174 controllers including requirements for multiple LPARs and/or multiple consoles. Some of the issues regarding multiple consoles can be resolved with the existing controllers. Documentation on changes necessary to the microcode configuration, while buried in the documentation, often allows the continued use of existing local 3174 hardware. The IDG 9074, together with their SecureAgent client software, offers the advantage of encryption if ethernet connectivity is contemplated.

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.

a) The physical layer including cables, hubs, switches, routers, etc., and
b) The protocol layer e.g. 3270, 5250, VT100, 3151, ASCII, etc. and
c) The network layer: Synchronous vs. Packet-Switched.

Internal cards such as Attachmate (IRMA) solutions offered a combination of hardware and software which allowed continued use of the controller connections via a coax interface and the client-based applications to emulate a standard 3270 session. Later, software and emulation products matured allowing emulation via an ethernet TCP/IP connection, obviating the need for the controller. The ability to move from dumb terminals to PC's via software or hardware/software combinations is well documented. The hardware requirements of a PC introduce a significantly more sophisticated (and problematic) platform to achieve terminal-like function. There are many applications and locations for which a full-fledged PC adds too much complexity and long term support costs. The ET2000 product line offered by ComputerLab International (CLI) provides an ethernet connection for 3270 (and 5250) connectivity as a direct ethernet connection to your host. The host sees the device as if it were a native terminal. This is a unique and elegant solution which offers easy, seamless transition from a 3270 (or 5250) coax terminal to an equal ethernet-attached device.

Many users have come full circle and desire the simplicity of a fixed function device without sacrificing the advanced functions that users have asked for. Server-based thin-client computing is attracting attention because of its ability to solve some of the most vexing problems facing IT: the staffing shortage, data privacy and security, and the quest for value from technology purchases. Because thin clients address all these problems, it's no wonder that experts say the market for thin- client technology will grow nearly 500 percent from the year 2000 to 2004.* The staggering long-term costs associated with PC networks can be resolved as the move toward an ethernet-based network is achieved. Microsoft's Terminal Server and Citrix's Metaframe products offer full PC-like functionality from a stable, permanent, and scalable, desktop-support platform. The "thin clients" offer PC function without the significant problems associated with PC's ("Fat Clients"]. Existing PC's can be used until replacement time while long term replacement with thin clients is achieved.

There are many entrants in the thin client market, but the maturity of the emulation client is the cogent decision, primarily because most thin clients use the same Microsoft operating systems, and are therefore virtually identical in all but the most fundamental physical characteristics. I-O Corporation offers the TC4000, with an excellent thin client based emulation product. For continuity also consider the enhancements to the CLI product line (ET3000, ET5000 ) which add thin client functions to there stable of mature emulation clients.

Host printing via Ethernet TCP/IP continues to be a vexing issue. Each proposed work-around (PCL transforms, SNA job buffering, etc.) offers a 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 Advanced Function Printing (AFP) 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.

Fortunately, there are upgrades, retrofits, and add-ons that often allow existing printers to accommodate addition of IPDS function over Ethernet TCP/IP. Currently, the only impact printers available from IBM that allow internal, native IPDS and ethernet support are the IBM 6400 series of console shuttle matrix printers. Neither Tally nor Genicom offer a desktop solution with these functions. The 4230-602, based on IBM's 4230 printer, offers internal ethernet and IPDS. IBM's solution for the desktop is the 4247 with internal IPDS and coax, and the addition of the I-data LanBrick for the ethernet connection. We find this too expensive and complicated.

An alternative is the implementation of Microsoft's HIS (Host Integration Server, formerly called SNA Server). In this case, a job is sent via SNA over IP to the HIS server and then spooled to the printer using Windows drivers and spool control. Error recovery, control, monitoring, etc., will be from the HIS server, not the host. The host addresses the PC-Server running the HIS software as an SNA device. The HIS server addresses the printers as TCP/IP devices.

Internal IPDS solutions for laser printers are offered by MPI (I-Data) and I-O Corporation. External IPDS solutions for laser printers include Print 4Sight (Intermate), OnePrint, and others. For a full overview see

Recommendations depend on the details of the particular requirements and installed equipment. In general, though, we propose that we can remove or replace all IBM and compatible terminal/printer controllers by using the suggestions below. This can be done by using most of your existing printers and PC's. This low-invasive approach allows a planned roll-out 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.
* Common Sense About Thin Clients, 3-25-03

David Mendelson
Argecy Computer Corporation