Saturday, December 12, 2009
Widening my options?
Growing up in Sydney, a little west of the northern beaches, winter in the US was summertime in the antipodes, and a time for swimming, snorkeling, and sailing. For laughing at the Santa’s at the shopping malls still clothed in red and trimmed with fur as if they were still ensconced in the northern hemisphere. Although this is my fourteenth winter in Colorado, winter in the Rockies is still an amazing novelty for me, so far removed from what I had grown used to for most of my life.
Today, we can just head for the airport and know that within a day, we can put winter behind us and step into the bright sunshine of summer. We have options, and we have the opportunity, to pretty much arrange our lifestyles so we are no longer constrained by the seasons. And with each year I wonder whether it will be last time I step out onto my front porch to be chilled to the bone and struggling to retain my footing, all because I want a cup of coffee from the local village café.
A few days ago Marty Turner emailed me with a pointer to archived copies of the Tandem Systems Review: http://www.hpl.hp.com/hpjournal/tandem/vol5num2sep89.pdf
It took me to the September 1989 issue that included an article by Marty that provided a technical overview of the latest SNAX offering – SNAX/CDF (Cross-Domain Facility). In the preface of that issue, Editorial Director Susan Thompson introduced Marty’s article with the observation “connecting networks from different vendors is becoming increasingly important … users need the ability to quickly access other networks without taking the time to learn a new set of interfaces.”
Fast-forward twenty years, and we still have SNA with us despite all the naysayers and futurists having predicted its demise for fifteen or more of those twenty years. True, SNA networks of client SNA devices have pretty much been eliminated. Many of these networks, particularly in the financial services and retail industries, have seen wholesale migration of their client devices to low-cost PC technology and with TCP/IP – Ethernet connectivity became the preferred networking solution. Inside the data center however, it was another story entirely.
The bulk of today’s mainframe applications continue to depend on legacy IBM Transaction-Processing Monitors (TPM), including CICS and IMS. Mission-critical transactions, implemented using either CICS or IMS, were exposed to a lot of the infrastructure supporting the transactional environment, including the critical SNA “Virtual Terminal” access method (VTAM). Migrating these mission-critical applications over to support a modern networking topology like TCP/IP necessitated considerable code changes and given the critical nature (to the corporation) of these applications, any number of protocol convertors, network bridges and gateways, as well as terminal emulation packages were deployed rather than risking the potential impact a network outage could have had on the business.
Technologies like Local Area Networks (LANs), and protocols like Data Link Switching (DLSw) and High Performance Routing / IP (HPR/IP), all brought with them some measure of utilization of a TCP/IP fabric, but they all suffered with the ongoing presence of SNA – either higher up the protocol stack or inside the application itself. Adding extra controllers, running TCP/IP and SNA, and retaining skilled technical staff capable of sorting it all out, eventually drove the prices of these data center networks to exorbitant levels and corporations felt trapped within silos with few options for a way out of the tangled mess.
Finally, hardware vendors took some of the options away altogether. The new high-speed controllers, standard with most large servers today, simply stopped supporting even the switching and bridging options – yes, they could still connect, but not at the speeds of other TCP/IP components. One statement Marty made in his article stood out as I re-read it this week “SNAX/CDF widens the options available to users when they plan their distributed OLTP applications, and design the networks, that best suit their business needs.” At the time, these options for NonStop users were well-received and today, it’s not how wide a choice of options we have that is the issue, as we no longer think in terms of canyons to be bridged or seas to be crossed; now that the islands have disappeared, but rather the issue now is how to best capitalize on the one network fabric that ties it all together!
There’s a new product under development in Sydney called uLinga – an Australian aboriginal word for “to fly!” It’s an appropriate product name, under the circumstances, as it’s leveraging new technology on the IBM mainframe to allow SNA applications to communicate without the presence of the SNA “stack” – essentially, for the purposes of supporting mainframe to NonStop communications, removing the need to retain VTAM! uLinga is a product for the HP NonStop server that, when installed (replacing products like SNAX and ICE that may still be present in support of connectivity to the IBM Mainframe), makes the HP NonStop server a peer to the IBM mainframe as though it was another deployment of the same IBM mainframe technology.
No programming changes are required. Nothing! And there’s only configuration changes required on the NonStop side – the support for native TCP/IP across the latest high-speed controllers and adapters is immediate. The creation of uLinga is being undertaken by the team at Infrasoft Pty Limited and includes some of the original architects and developers that brought the ICE product to market in the early ‘90s. For those who may have missed the news releases earlier this week, comForte GmbH and Infrasoft announced a joint development and marketing agreement and already a number of conference calls and webex presentations have been completed.
According to Dr Michael Rossbach, “we are responding to customer demand for such a solution and by leveraging Infrasoft’s highly skilled development team with a lot of experience in developing solutions for the communication between HP NonStop and IBM mainframe systems, and comForte’s expertise in communication middleware and security solutions, we are well positioned to offer a best in class yet cost-effective software solution.” uLinga has been in the works for some time now and I expect to see it generate considerable interest.
I have been involved with communications products and technologies for nearly thirty years. And in the spirit of full disclosure I have to admit that I am on the board of Infrasoft, as well under contract to comForte. So I will exhibit some restraint over my enthusiasm for this new product, and leave it to others to provide more detailed information. But what really encouraged me to develop this post is that there continues to be infrastructure development being undertaken for the HP NonStop server!
Too many times I read commentary on how few companies elect to focus new development on the NonStop platform. Too often it’s easy to dismiss the NonStop platform for consideration as the centerpiece of a new solution! The Infrasoft developers had the opportunity to work on other platforms but, being experienced developers familiar with many other platforms, they have once again turned their hands to addressing current-era connectivity opportunities on NonStop.
Not every user will opt for the uLinga product. Just as not every user will feel compelled to pull the plug on SNA. However, knowing that there will be even more choices on offer shortly is something that encourages me as, after all, one of the key messages for NonStop is modernization and nothing will contribute more to this initiative than to see the need for a legacy protocol like SNA removed.
Sure I like options, but I like simple solutions a lot more! Connecting networks should not be the stuff that still demands the infrastructure complexity it once did, and with the increased loads of data that need to be transported fast – if we think there’s any potential for enterprise clouds forming behind the firewall, there’s just no room for SNA to retain a presence. And, the long-a uLinga on the option for an all-TCP/IP infrastructure the more, I think, we will see uLinga fly!