CICS is great, but is it needed with DB2 for z/OS?

Opening statement: I like CICS. I really do. IBM's flagship mainframe-based transaction management subsystem has a lot going for it, including:

• Legs - CICS is a veteran player. It's been handling big transactional workloads around the world for more than 30 years - that's 30+ years of transaction management expertise built into the product through regular releases of new versions of the code.
• Scalability - I worked with an organization that went from about 100 CICS-DB2 transactions per second during peak hours to well over 1000 per second over the course of a two- to three-year period, and the system scaled beautifully. Response times remained excellent through the more-than-an-order-of-magnitude growth of the application workload.
• Great tools - With CICS having been on the scene for so long, and being so widely installed, you'd think that there'd be a rich ecosystem of complementary tools from IBM and other vendors, and you'd be right in so thinking. Performance monitors, diagnostic tools, and other products abound.

If you already have CICS, you probably ought to keep it, especially if you have a lot of programs running in that environment.

That said, there is a question that intrigues me. Suppose that your organization wants to build a mainframe DB2-based application system. The system will handle a large workload, in excess of 1000 DB2 database-accessing transactions per second at peak. Excellent performance is a must, and high availability is of critical importance. Here's my question: given this situation, would success depend on front-ending the DB2 for z/OS database with CICS? Here's my answer: no. A high-volume, mission-critical system can be successfully implemented without CICS being in the mix.

Absent CICS, where would the transaction programs originate? Well, think about it. Where would transaction programs originate if the database platform were something other than a mainframe (e.g., DB2 on a Solaris server, or Oracle on a Linux server or SQL Server on a Windows system)? In those cases, you'd have the transactions coming in from application servers running on boxes separate from the one on which the DBMS is housed, right? You would do that for reasons of scalability (often, you can have several application servers running flat-out, and the target database server will barely be breaking a sweat) and availability (the app servers are workload conduits for the database server, and if one of these "pipes" goes offline, work can continue to flow through the others). Why would you want to do things differently, just because the database server happens to be a mainframe? Why not front the mainframe with application servers (e.g., WebSphere, WebLogic, Windows .NET) running on Intel- or RISC-based systems?

This I will concede: I would not have wanted to implement an enterprise-class, DB2 for z/OS-based transactional application without CICS as recently as a few years ago. Server-side SQL-issuing programs are a key to scalability when transaction volume is high, and absent CICS transaction programs, server-side SQL in a mainframe environment means DB2 stored procedures invoked via CALL statements coming through the DB2 Distributed Data Facility (DDF). Not so long ago, DDF and DB2 stored procedures had some limitations that made them less attractive as components of large, mission-critical applications, to wit:

1. It was not possible to assign different priorities (with respect to WLM, the z/OS Workload Manager) to different classes of work coming through the DB2 DDF - everything ran at the priority of the DDF address space.
2. One could not get detailed DB2 accounting data (i.e., trace data used by a DB2 monitor product to generate a DB2 accounting detail report or display a screen of DB2 thread detail information) for stored procedure programs, because such detailed data was not available at the DB2 package level, and all work coming through DDF ran under the one DB2DIST plan name.
3. Stored procedures could run in only one address space (an address space managed by DB2).
4. There was a dearth of vendor tools that could be used to facilitate the development, debugging, and monitoring of DB2 stored procedure programs.

ALL of those limitations have been swept away as stored procedure functionality was enhanced through multiple releases of DB2 (and the enhancements keep on coming: check out the "What's New?" books for DB2 for z/OS Version 8 and Version 9). Referring to the numbered list, above, of former shortcomings:

1. Different z/OS workload management priorities can be assigned to different, user-specified classes of DDF-routed application work.
2. Detailed DB2 accounting data is available at the package level, whether the package is executed as a stored procedure or in any other z/OS address space.
3. DB2 stored procedure execution can be spread across multiple WLM-managed address spaces, and instances of a given stored procedure execution environment can be instantiated on demand by WLM in response to workload volume changes.
4. The DB2 stored procedure tool scene looks great these days. To give you just a few examples: IBM's DB2 Development Center, a component of the DB2 Management Clients Package (a comprehensive stored procedure development tool); Compuware's Xpediter/DB2 Stored Procedures (a popular tool for stored procedure testing); and CA's TRILOGexpert TriTune (very useful for performance analysis of stored procedures and of DDF-related work in general).

What about the language used to code the stored procedure-invoking transaction programs that will run on the off-mainframe application servers? Are you concerned that your choices in that regard may be limited by the DB2 for z/OS back-end? Don't be. Want to use Java? Go ahead - the JDBC (Java Database Connectivity) drivers provided with IBM's DB2 Connect are just the ticket. Want to call DB2 stored procedures from C# programs running on Windows .NET application servers? No problem - again, DB2 Connect is there with a great ADO.NET driver. Want to use one of the popular open-source programming languages? You have quite a few options in that case, as I pointed out in my recent DB2 Magazine column titled "News from the Client Side."

Again, CICS is a great piece of software, and if you have it, go ahead and leverage it; however, if you're wondering whether or not a high-volume, highly available transactional application can be successfully implemented with a DB2 for z/OS data server fronted exclusively by application servers running on Intel- and/or RISC-based computers, wonder no more. It can.

Wanted: Better Technical Professional Career Tracks

Welcome to my blog. I'm Robert Catterall, President of Catterall Consulting, and while I think of myself as a technology-oriented person, I will sometimes create posts that are not particularly technical with respect to content. This is one such entry.

I have long been interested in organizational behavior, thanks largely to a terrific professor I had for a course I took en route to receiving my MBA from Southern Methodist University (go Mustangs) back in 1987. I am particularly fascinated by the management of people within IT organizations. Something that has eaten at me for years now is the dearth of attractive career paths for talented and committed technical professionals. Too often, a DBA (or application developer or systems programmer or network engineer or whatever) finds that he or she has "topped out," in a career sense, at a relatively young age - thirty-something, perhaps. By this I mean to say that the individual has advanced as far as he or she can within the IT organization, and this after having reached a level that might equate, compensation and perk-wise to a first-line manager. What is this person to do at that point? The options, as I see them, are not good for the employing organization:

• The employee can soldier on for years at the end-of-the-line career level, all the while losing more and more of the motivation to excel as he perceives a growing gap between the value of his work contributions and the rewards of his labors.
• The employee can elect to move over to the management career track within the IT organization so as to have higher job levels towards which he can work (e.g., Director, Vice-President, etc.). These advancement opportunities offer the potential for rewards that the employee seeks (e.g., salary increases, stock options, an office instead of a cube, access to more information about the company's business strategy, etc.), but negative side-effects can emerge. For one thing, the skills that make for a top-notch technical professional are not necessarily those that portend success as a manager of people. Another potential problem: the manager decides that he wants to have it both ways, managing a team of techies while refusing to defer to their technical judgment (this can be a huge de-motivator for the tech folk who report to the manager).
• The employee quits, taking with him years of experience and attendant domain knowledge.

Not good - not for anyone involved. What I would like to see: a career path that would enable an organization's best technical professionals to advance to an executive-level position - say, a VP-level position - without having to take on people management responsibilities. And when I say executive-level, I mean the whole shebang: window office, non-cash compensation, access to corporate brass, and so on. There are some companies that do this. The top-most technical professionals at these companies tend to report to the CIO or to a Senior VP, and they often have the word "fellow" somewhere in their job title. They have vast knowledge and experience (often twenty-plus years), and - here's a really important point - they are not only recognized for their technical leadership, they are motivated to build on their past achievements, becoming ever-more valuable assets to their employers. They are difference-makers, they are mentors, they are the stars whose company the organization's up-and-coming technical professionals aspire to join.

If some organizations have such technical professional career paths and receive resultant benefits, why do so many companies fail to follow suit? It could be a reluctance on the part of senior managers to "share the wealth," so to speak. It could be that IT execs are loathe to deal with the jealousies that could quickly surface with the implementation of a tech all-star career path ("Why should HE get that reward?"). It's possible that IT organizations' leaders can't see how to define and adhere to a process that governs ascension to the executive-level technical professional position, and know that absent such a process, promotions will be perceived as being related to the currying of the right people's favor.

I don't pretend to believe that implementing an executive-level career path for top technical professionals is a piece of cake. I do believe that it is an investment that can - and does - pay significant dividends for an IT organization and for a company as a whole. I also believe that people should be able to go from technical professional to management, but that choice should be based on a desire and an aptitude to do the hard work of effective people management, versus an effort to receive recognition and rewards that are not available to top tech pros.