LongEx Mainframe Quarterly - February 2011
As Communications Controllers, or Front End Processors (FEPs) come to the end of their life, SNA subarea network users are faced with the hard task of migrating to other networking technologies. This article discusses the end of the 3745/3746 Communications Controller, and what migration options are available.
This will take no-one by surprise. From the moment TCP/IP became mainstream on the mainframe, network workloads have been quickly lured away from SNA. IBM officially surrendered to TCP/IP in 2002, when it removed the last 3745/3746 Communications Controllers from marketing. So what are the migration choices for those with a Communications Controller quietly humming away in the corner? 1. Migrate to TCP/IPThe obvious solution is to migrate to TCP/IP, and associated connectivity and telecommunications products. And most mainframe sites have already moved in this direction. 3270 terminal and printer access has now standardised to TN3270. TCP/IP printing options such as Infoprint Server and LRS VPS/TCP/IP have all but removed the need for remote SNA printers. And FTP solutions are commonplace for file transfers. However migrating from SNA is rarely a simple process. Many sites will have large numbers of lines from Communications Controllers that must be indivdually identified, checked and migrated. Many of these lines will be used by legacy applications with SNA APIs. In these cases applications will need to be reworked, and new communications options tested before the line can be cut. Other lines will connect to legacy networking equipment requiring an SNA subarea connection. In these cases, the legacy equipment will need to be replaced, or a solution that will allow it to run on TCP/IP found. Perhaps the most difficult connections to migrate are SNI connections to external agencies. These must be re-negotiated, and security, audit and other requirements revisited. For many users, migrating from SNA will be a long and difficult task. 2. Do NothingThe fact is that there is no immediate requirement to retire Communications Controllers. Although IBM is discontinuing support, others are more than hapyy to fill the gap, at least for now. Hardware resellers such as Computer Merchants continue to supply used equipment. And the Australian hardware support company Interactive states that it will continue to support Communications Controller hardware for the next 12-18 months. Communications Controllers have traditionally been very stable and reliable equipment, so they will work for some time to come. IBM is also continuing to support Communications Controller software such as AFP/NCP and NPSI. In fact this software is required for IBMs Communications Controller for Linux. However the Communications Controller itself is not necessarily the problem. SNA/SDLC telecommunications products are being withdrawn from marketing, if not dropped altogether. Telstra Australia discontinued their Austpac X.25 service in 2008, and their DDN leased line services were withdrawn from marketing in 2009. This mirrors other telecommunications giants such as AT&T. Network equipment company RAD Data offers networking equipment for legacy networks to use other WAN solutions, however the termination of traditional networking products is yet another nail in the SNA subarea coffin. Connectivity to mainframe processors is another problem facing Communications Controller customers. Communications Controllers only use obsolete Bus and Tag channels or the 1990s-era fibre ESCON connections to the mainframe. Bus and Tag has not been supported by IBM for years, and IBM has announced that the z196 zEnterprise mainframe will be the last supporting ESCON. 3. Convert to APPNSNA APPN networks have no use for legacy Communications Controllers. So converting SNA subarea to APPN may solve many problems. What's more, IBMs Enterprise Extender solution allows APPN High Performance Routing (HPR) networks to seamlessly work over TCP/IP. However APPN is still an IBM protocol, and doesn't come close to the popularity of TCP/IP. So choosing APPN limits the ease of communicating with non-IBM servers. Many users may be hesitant to invest more time and resources on another SNA network. A conversion to APPN may also face many of the problems of a conversion straight to TCP/IP. It is difficult to choose APPN over TCP/IP without large savings or other benefits.
4. SNA over TCP/IPOptions have existed for some time to send SNA over TCP/IP. Enterprise Extender has been mentioned before for APPN HPR. Data Link Switching (DLSw) capable routers can also transparently send SNA subarea and APPN traffic over TCP/IP; without any changes to the mainframe or networking equipment. X.25 users also have an option with X.25 over TCP/IP (XOT) capable routers. However a Communications Controller is still needed at the mainframe end for X.25 communications. Both DLSw and XOT require the acquisition of expensive, dedicated routing equipment. And they do not necessarily remove the need for a Communications Controller. 5. CCLOne of the most difficult Communications Controller-reliant connections to migrate from are SNI connections – particularly between different organisations. For SNI there is no way around it: you need a Communications Controller. For SNI and other features (like X.25) that still need Communications Controller functions, IBMs Communications Controller for Linux is the solution. It is a Communications Controller emulator that runs on z/Linux. It connects to other mainframe partitions over the OSA adapter, and runs the same software as traditional Communications Controllers. However this solution may not be cheap. Aside from the costs of CCL itself, users must setup a dedicated z/Linux partition or image on a mainframe. Users will also continue to pay for Communications Controller software such as ACF/NCP and NPSI. ConclusionThere are many different solutions for users that still use a 37x5 Communications Controller. However none will be trivial, and all will require considerable planning and migration effort. Users moving away from a Communications Controller may also be unpleasantly surprised by an increase in CPU usage, as workloads traditionally offloaded come back to the mainframe. References
|
