Exclusive Interview with

Mac Devine

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

As discussed in the Dec. 08. 2005 BLOG entry, an 'advertorial'-oriented, print media, mainframe publication dated ‘October/November 2005’ contained an article entitled “Alternatives for Replacing IBM’s 37x5 for z/OS Users: A Comparison – CCL or Enterprise Extender?".

Since this article was based on CCL V1R1, as opposed to V1R2 that has been available since November 2005, many weaknesses attributed in this article to the CCL approach, as well as the CCL CPU usage claims cited, are no longer applicable; for example the lack of support for QDIO or fibre-based OSA(-E) ports.

Please refer to the CCL/z V1R2 White Paper for the new features available with V1R2 as well as for an exclusive, 2-page table on “CCL/z V1R2: What is Possible, What is Not” (on pages 10-11 of this White Paper).

Mac Devine, IBM’s Lead Solutions Architect - ESAB Chair for Enterprise Platform Software Development, Architecture, Strategy and Design, a well known figure to this audience, has been actively involved with both EE and CCL.  Mac, 1st talked to us about CCL, albeit V1R1, over a year ago in November 2004 – even before V1R1 was officially released.

Now with V1R2 shipping, and his White Paper on V1R2 (also available directly at www.ibm.com) being widely circulated, Anura Guruge, IT In-Depth's editor at large, tackles Mac on his personal, and uniquely qualified, take on EE vs. CCL/z V1R2 vis-à-vis 3745 replacement.

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, this article alludes that EE still is IBM’s preferred solution when it comes to 3745 displacement.  While I know that that was indeed the case a couple of years ago, prior to CCL/z … what is your take now when it comes to EE vs. CCL/z V1R2?

A1:  I think a little IBM "behind the scenes" information might be helpful for your readers to understand the current IBM recommendations concerning 3745/6 replacement. In early 2002, coinciding with the marketing withdrawal of the 3745/6, IBM published a Redbook called the "Communication Controller Migration Guide" in which we made a clear statement that Enterprise Extender was the strategic/preferred solution for 3745/6 Communication Controller replacement. In early 2004, I challenged my architecture and design team to provide additional 3745/6 migration options for customers who were unable to implement Enterprise Extender either due to their own installation's limitations or the limitations of their SNI connected business partners. These limitations included dependence on VSE, VM, or TPF and/or the lack of APPN/HPR support. Also as part of my challenge, I emphasized the following requirements for any solution alternative:

  1.  Available to all VTAM and TPF customers

  2.  Allows each of the SNI connected business partners to migrate independently/transparently from one another

  3.  Simple deployment from both a SNA application and IP network perspective

  4.  Co-exists with and complements our customers' Enterprise Extender solution deployments

As you and your readers have no doubt guessed by now, this challenge was the genesis of the Communication Controller for Linux on System z9 and zSeries (a.k.a CCL) product but it was also the genesis of another important work effort, the 2nd edition of the Communication Controller Migration Guide Redbook, whose publication coincided with the GA of CCL. I highly recommend this Redbook for anyone looking to migrate off 3745/6 since its primary goal is to provide customers with all of their migration choices and give recommendations about which choice (EE or CCL) should be chosen based on a customer's goals, timeline, skills, limitations, etc. We also believe that there will be installations which will use both technologies - EE for intranet SNA connectivity and CCL NCP for business partner SNI connectivity.  There will also be those who use EE for business partner connectivity and the CCL NCP to retain selected existing SNA boundary function access.  The point is that we do not see a battle between two competing technologies but two technologies which can peacefully coexist and complement each other.
Bottom line is that IBM believes that both EE and CCL are strategic solutions for 3745/6 displacement and we view these as complementary.

Q2. Mac, as a noted Linux on mainframe evangelist, do you ever see CCL/z as the ‘killer’ Linux starter app. for mainframe customers that have not as yet got around to looking at mainframe Linux?

A2:  Yes, I do view CCL in this way for three primary reasons:

       We work with customers every day who have validated these reasons and who have told us that it is because of the CCL solution they have moved in their plans to depoly Linux on the mainframe (i.e. from 'something to consider in the future' to 'something to consider now').

Q3. Mac, this article makes a big deal about how CCL/z negates the 37xx concept of mainframe ‘off-load’ (though mainframe EE also consumes mainframe resources).  While mainframe ‘off-load’ was extremely germane in the 1970s, what is your current take on the cost of mainframe ‘MIPS’ with all of the huge progress that has been made with CPs, IFLs, zAAPs, LPARs etc on the modern zSeries machines?

A3:  The term "mainframe off-load", whenever it is used to mean saving money by moving MIPs off the mainframe, has always been more real in articles than in actual DataCenters. In the 1970s, the 3745/6 was not developed to off-load the mainframe of cycles and their associated cost (after all, the cycles on the 3745/6 still had associated costs) but to act as consolidation point for the remote network connectivity which required individual lines for point to point SNA communications. This separation of the "network control" processing I/O  and the processing I/O associated with access to VTAM applications and their data allowed the mainframe to deliver superior qualities of service (e.g. security, business resiliency, scalability, etc.).  As customers have migrated from dedicated point-to-point SNA networks to routed TCP/IP networks, the need for specialized external hardware for terminating lines has been significantly reduced. At the same time, technology advances on the mainframe have allowed us to maintain our superior qualities of service via the separation of workloads with diverse processing I/O needs but now without the requirement for external hardware.   OSA Express QDIO, IFLs, and zAAPs are some of these technology advances of the mainframe and I'd expect to see this technology trend continue as we focus on integrating new workloads with our traditional SNA and IP business applications and data.

Q4. Mac, this article also makes a rather dramatic claim about security exposures, with clear text data flowing across IP links.  Mac, with all of the security options now available on mainframes can you please, very, very succinctly explain to our readers that security really is not an issue when it comes to SNA-over-IP.

A4:  Security will continue to be a top priority for zSeries as evidenced by the recent IP security enhancements in z/OS V1R7 which Lin Overby described in your recent interview.  The reason for this focus is simple. The security demands for today's networks are greater than ever before due to government and industry specific regulations for data privacy and unified threat management as well as the easy access and extended reach of the Internet. Since both EE and CCL are designed as SNA-over-IP solutions, each can take advantage of many of these IP network security enhancements. In particular, our EE customers will be able to utilize our new IPSec support in z/OS CS V1R7 to secure their EE workloads and CCL customers will be able to utilize our new TCP secure connection support in CCL V1R2. This support allows 2 CCL NCPs to utilize a secure TCP connection (e.g.  Transport Layer Security (TLS)) for INN/SNI traffic. These IP security features can be used instead of or in conjunction with the traditional SNA Session Level Encryption (SLE) support for both CCL and EE workloads. Bottom line from a security perspective is that transporting SNA over an IP network (regardless of whether you are using EE or CCL) increases the security of the SNA data since you can validate the IP end-points, authenticate the message integrity, and protect the data with the latest encryption technologies (e.g. AES) instead of just being able to protect the data via SNA SLE (i.e. with pure SNA there are no authentication/validation capabilities).

Q5. Mac, with the holidays upon us I want to keep this short.  So this will be my last question.  With the Statements-of-Direction, and the short blurb in my White Paper, we all know that mainframe DLSw will be available with CCL/z next year.  How will the availability of mainframe DLSw change the dynamics when it comes to EE vs. CCL/z?

A5:  The availability of DLSw will not change the dynamics. We are targeting CCL's DLSw support as an additional tool for CCL customers to help remove their dependence on SNA networking equipment (e.g. CIP, Token Ring, ESCON, etc.) in the DataCenter. EE customers have already made the transition to a pure IP network transport via OSA Express.  I'm looking forward to telling your readers more about our CCL DLSw support in the coming months.

Thank you very much Mac.

Mac, I do know and appreciate it that you obliged us with this interview, at very short notice, at a time when you were extremely busy trying to get things wrapped up before the holidays.  But we all knew that this was a topical and important issue and nobody else could have given us this unique perspective.  I guess from your last sentence above, that you will be game for yet another of these interview in 2006.  That is great news.  Mac, thank YOU.  We wish you continued success in 2006.