Real inventory that we refurbish and stand behind, since 1985.

Moving From Terminals and Printers [Coax (3270) or Twinax (5250)] SNA to TCP/IP

›About us›Cool stuff›Library, White Papers, etc.
Moving From Terminals and Printers (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.

Controllers:
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.

For situations in which SNA over IP is an appealing alternative, there are several options as 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.  We recommend the IDG 9074 because of the secure nature of its protocols: all sessions can be easily encrypted in order to allow remote console and user access.  This is the technology that has IBM's 2074 line trumped.  There are a myriad of reasons to replace the 3174/3274's.  Call us for information.

Terminals:
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.  Browser based GUI�s, running over IP networks are the current favorite development projects. The ability to move from dumb terminals to PC's via software or hardware/software combinations is well documented.  The hardware requirements of PC�s introduces 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.

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.  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 functionalities 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.

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.

Printers:
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
27280 Haggerty Road C21
Farmington Hills, MI 48331
248-324-1800 x122
248-324-1900 fax
www.argecy.com
dave@argecy.com

 

� David T. Mendelson, Argecy Computer Corporation 1998, 2005