YET Another Exclusive Interview with

Mac Devine

Lead Solutions Architect - ESAB Chair
Enterprise Platform Software Development
Architecture, Strategy and Design, IBM
 

IBM's Communications Controller for Linux on System z9 and zSeries (CCL/z) V1R2 was released in November 2005.

CCL/z V1R2.1 was introduced in May 2006.

V1R2.1 includes the following enhancements:

This Mac Devine interview with Anura Guruge, IT In-Depth's editor at large, is all about V1R2.1 and talks about these new capabilities -- in particular DLSw and IP TG.

Mac Devine: a synopsis

Mac Devine is a 1989 graduate of Clemson University with a Master's degree in Mathematical Sciences. Mac spent 7 years in VTAM development working on a variety of APPN/HPR functions and was the Chief Programmer of several major releases. Mac then transitioned into the Communications Server Architecture, Design and Strategy group and spent 4 years designing TN3720E and Sysplex functions and served as the Chief Designer of several  major releases. Mac then served 2 years as the lead solutions architect for networking alliances (Cisco, Nortel, etc.) responsible for the development of joint solutions which leverage IBM's eServer and e-business framework. After spending 2 years managing the Enterprise  Networking Solutions Architecture and the Linux Networking Solutions Development teams, Mac was recently appointed the Lead Solutions Architect for Enterprise Platform Software Development and is responsible for the architecture, design and strategy of solutions which leverage IBM's zSeries and e-business framework.

Q1.  Mac, in your 4th interview with me in December we addressed and covered the new functionality (e.g. enhanced Ethernet support, IP TGs, XOT etc.) that was included in CCL/z V1R2 that was released in November 2005. I see that as of May 2006 we now have V1R2.1 – which had been alluded to in prior statements of direction, as well as in your last interview. So, Mac, can you please tell us in your own words, with a fair amount of detail, what is new and exciting in V1R2.1 … which I see is slated to be available as of May 12, 2006?

A1:  Our intent for the first releases of the CCL/z product was to provide a straightforward migration path from 3745/6 hardware via the emulation of many 3745/6 functions used by VTAM and NCP. With CCL/z V1R2.1, our emphasis was on building the "next generation" of IBM Communication Controller while preserving current applications, definitions, automation, and operations.

       New CCL/z functions such as data center DLSw and XOT (a.k.a x.25 over TCP/IP) allow NCP and NPSI customers to take full advantage of IP connectivity all the way into the mainframe by removing dependencies on "last generation" networking technologies like ESCON and Token Ring and allowing exploitation of all of the benefits of IP connectivity (e.g. GbE, VLAN, IPSec/VPN, etc.). These CCL/z V1R2.1 functions are not only RFC compliant but have undergone extensive testing with our networking partners, Eicon and Cisco, to ensure interoperability with branch routers performing DLSw and XOT functions.

       The inclusion of native LAN emulation support in CCL/z V1R2.1 is also very significant. Customers will now be able to migrate all resources off 3746 TICs to CCL/z without having to make any changes to NCP GENs or VTAM definitions. In addition, customers will also benefit from its superior performance vs NTRI emulation. In previous CCL releases, NTRI emulation allowed a little better than a 1 to 1 mapping between a busy 3745 CCU and an IFL running CCL/z. However, CCL/z V1R2.1 using native LAN emulation optimizes internal processing to the point where a customer can now consolidate 4 or 5 busy NCPs onto one IFL while significantly increasing throughput and reducing response times.

Q2.  Mac, while I know you, quite understandably, are a big proponent of EE … I over the years came to “love” DLSw … mainly because there was so much of it around and it got to the point that it was easier to embrace it and “hug” it than try to defy that onrushing wave of popularity. Mainframe DLSw is something that I wanted to see 10 years ago. Now that we have it, albeit with CCL/z as a prerequisite (as opposed to say within Comm. Server), I still have this slightly ‘tingly’ feeling that it is a somewhat important networking breakthrough and that “we” (meaning the SNA community) can somehow really exploit this. You have been much closer to this than I have, so I am curious as to how you would characterize the significance of DLSw and whether people will really get around to simplifying their data center network configurations exploiting this capability?

A2:  The primary reason, I am a big proponent of EE is because it allows pure IP connectivity to the VTAM SNA applications. Until now, the same could not be said for "data center" DLSw because DLSw routers in the data center still depended on SNA connectivity to the mainframe via ESCON and/or Token Ring.

       With CCL/z's data center DLSw support, customers now have the missing technology piece they needed to complete the transition from SNA to IP network connectivity to the mainframe. I can just hear your "Big Iron" readership saying "wasn't EE the missing piece" or "isn't DLSw in Communications Server the missing piece" so let me explain.

       While EE is an excellent solution and many customers have reaped its benefits, most VTAM customers have not been able to use it to completely transition from SNA to IP network connectivity for reasons ranging from lack of platform support (e.g. VSE) to lack of APPN/HPR skills at the branch, data center and/or business partner(s).

       The vast majority of the remaining SNA access from the branch (i.e. what couldn't easily be migrated to EE in the branch) as well as SNI access is or soon will be (i.e. due to the withdrawel of SNA leased lines support by companies like AT&T) via DLSw routers downstream from 3745/6 Communciation Controllers.

       CCL's data center DLSw support can use "virtual MACs" to allow customers to transparently (from the branch's and/or business partner's perspective since the same MAC addresses can be maintained) eliminate the need for the "aggregation SNA layer" within routers in the data center so that these routers (or new GbE switches!) can be fully dedicated to high performance IP routing. This data center DLSw virtualization allows CCL to minimize the customers' risks and costs while maximizing the performance and flexibility of their data centers.

Q3.  Mac, this is a follow-on question to my previous one. would you (and by that I also mean IBM in general) advocate CCL/z purely as a means for realizing mainframe DLSw … for example in the case of customers that have a ton of OSA-E attached data center routers that are there to provide DLSw termination?

A3:  In order to answer this question, I must first take us on a "quick trip down memory lane."

       When Cisco first burst onto the SNA data center scene with CIP and DLSw, there were, no doubt, many sleepless nights for IBMers working on 3745/6 Communication Controllers and NCP. After all, most large enterprise customers had already determined that both SNA and IP applications would be needed for their future business needs and the CIP router could handle both SNA and IP effectively over ESCON (note: I have chosen to block certain painful memories from this trip down memory lane - like IP routing support via the 3745/6 << smile >>).

       Fortunately (at least for the sleep deprived IBMers mentioned earlier), this mass exodus of large SNA customers to directly attached, DLSw enabled Cisco routers never materialized.

       This lack of a mass movement can be contributed to the high costs and lack of scalability associated with this configuration. In other words, removing the NCP boundary function and NCP subarea had the nasty effect of raising mainframe software costs while reducing the overall scalability (new configuration only allowed for the definition of less than 64K subarea resources (PUs, lines, LUs, APPLs, etc.) while the old configuration allowed 64K subarea resources for VTAM and 64K subarea resource for each NCP). Fortunately (this time for the customers as well as IBM and Cisco), these issues were easily resolved by connecting the DLSw enabled Cisco routers via Token Ring to the existing 3745/6 Communication Controllers.

       Years later when OSA Express replaced ESCON as the strategic network attachment for the mainframe, a few SNA customers dared to venture into these waters again but quickly discovered it was even more shark infested than before. Specifically, the OSA Express SNA LAN access was limited to LSA which was not available on Cisco DLSw capable routers and burned more CPU and network addresses than ESCON.

       Therefore, the bottom line reality of today is that there is very little need for data center DLSw support except downstream of NCP and there are major advantages (e.g. management) with making this a "virtual downstream" via CCL's data center DLSw support.

Q4.  Mac, I see that there are some new Linux-centric management opportunities for the CCL/z. Could you please tell us a bit about these (without going into undue detail)?

A4:  Management of CCL/z truly benefits from the best of both worlds, the old and the new. Existing tools, operations and automation currently being used by customers to monitor and manage NCP in the 3745/6 environment will continue to work in the CCL environment. This includes tools such as NTuneMon, NPM, and Tivoli NetView for z/OS.

       But with NCP now running in a new zLinux environment, customers can also take advantage of the centralized monitoring/management capabilities of zLinux. Some examples include:

       It is also worth noting that since Linux is a general-purpose operating system, it has many monitoring/management features and the number of these types of features will continue to grow.

Q5.  Mac, could you, if possible, on a purely speculative basis (i.e. meaning it is definitely ‘off-the-official-record’ and we are here just talking potential, pie-in-the-sky and I can’t think of anymore wiggle room I can give you that is greater than that) hypothesize whether it is at all conceivable that we might (some day) see IP-TG support outside the CCL/z (for example in Comm. Server or on routers from some unnamed vendor) given that we (and by that I include myself) claim that IP-TG is an optimized DLSw?

A5:  The use case scenarios for IP TG support was heavily debated by my architecture/design team during the early days of CCL. The debate centered around 2 critical decision points:

       The first decision point of the debate was quickly and painlessly resolved. As I described earlier, we quickly realized that data center DLSw support in CCL/z was the missing technology piece needed to complete the transition from SNA to IP network connectivity to the mainframe. Once we settled on the absolute need for data center DLSw support, rewarding our CCL customers with optimized CCL/z-to-CCL/z IP communication was a no brainer.

       The resolution of the second decision point of the debate did not succumb quite so easily. At first, there appeared to be plenty of potential use case scenarios for IP TG outside of CCL/z but as we examined each more carefully, the need for all of them evaporated except for the optimized CCL/z-to-CCL/z IP communication. I'll explain by breaking down the demographics of the most common SNA connections.

Q6.  Mac, I know that this is also a ‘tricky’ question and I fully understand how hamstrung you are due to IBM legal requirements etc. But is there some way that you can, in some semi-meaningful way, indicate to us the adoption level (and rate) for the CCL/z and please don’t even go close to IBM’s usual ‘formula’ of saying “well we plan to ship twice as many this year as we did last year” … because I will have to tell you, what I told Jim Boyle in 1995 when he gave me that answer when I asked him about “Nway ATM switch” sales … which was “Oh. OK. So you shipped 1 last year and you plan to ship 2 this year” and I won’t even go into the very sad irony of that retort.

A6:  As you indicated, I am hamstrung by IBM's business conduct guidelines concerning divulging specifics about customer and/or product usage.

       However, I can say that many enterprise customers over the last year have been evaluating and testing CCL/z. The adoption rates for CCL/z continue to grow and we view this as a sign that customers recognize the importance of CCL in their overall networking strategy.

       As we have discussed in this article, we believe that CCL/z V1.2.1 has provided the technology needed for enterprise customers to complete the transition to IP network connectivity to the mainframe.

       Thanks for giving me the opportunity to share this news with your readers << smile >>

Thank you SO very much Mac.

Mac, I have had the privilege and the pleasure of interacting with you for the last 6 years.  During that time I have come to realize that you exceptionally gifted even by the high standards that we associate with and expect from the crème de la crème of IBM.  Mac, as you know, over the years I have dealt with and interviewed many, many IBMers -- even some Senior VPs and division heads.  But I have to say that this was, indubitably, the BEST interview I have ever had with an IBMer.  You were candid, factual, precise and even resorted to humor.  It was a delight.  Mac, thank you.  You are such an asset to IBM and a good friend to us in the SNA community.  We wish you all the best.