management: Goodbye 3745 - The End of the Communications Controller
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.
|
Communications Controllers, or Front End Processors (FEPs), have been
the SNA subarea workhorse for decades. Offloading networking processing
from the System z mainframe, Communications Controllers have performed
everything from network consolidation and multiplexing to inter-network
communications and switched and leased line management.
On 31-Dec-2010, IBM ended support for the last of its ageing Communications
Controllers for Japan and EMEA. Although support continues for Americas
and Asia Pacific customers, it is clear that the sun has set on SNA subarea
networks.
|
 |
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/IP
The 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 Nothing
The 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 APPN
SNA 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/IP
Options 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. CCL
One 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.
Conclusion
There 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
David Stephens
|
Home
| Press
Room | Contact
Us | Site
Map
