Happy Cows

(The uncertain future of CICS part 2)

I saw this commercial on television the other day. The commercial was trying to convince the viewer that happy cows produce more milk and that happy cows come from California.

The slightly goofy series of commercials show the cows getting up to various antics because they are so happy...

So I started to wonder how happy CICS customers are lately.

When I think of this there are some distinct subjects that come to mind:

1. Cost.
As far as the cost of running CICS is concerned I wonder what the average dollar is per MSU/MIP. If we really have about 10,000 mainframes in the world like this article claims: ( http://www.itjungle.com/big/big071007-story01.html )
And it is true that CICS brings in over one billion dollars a year as suggested here (http://masterterminal.wordpress.com/2008/04/15/cics-is-not-my-mother/ )
- The math would then suggest that the average CICS user (that means nothing) would be paying $100,000 a year for CICS.

Now a few years ago the argument would have been "well you get what you pay for and with CICS you get a lot of stability so it is worth the price... ".

Enter left stage - a local SUSE Linux box running in our enterprise. This box is our version control Subversion server. This poor dual processor Intel based machine is pummeled daily by the developers in our enterprise. The other day we lost some of our network drives and had to recycle the Linux box after 470 uninterrupted days of service! Meanwhile the mainframe is reloaded monthly for "maintenance"... Don't get me wrong, I still believe mainframes can be more stable than most Intel based servers but in reality rarely are.

"Those were the days" - when staying up for a month or three months gave the mainframe its reputation for stability. Those days are gone and the stable enough philosophy of the LUW (Linux, UNIX and Windows) platforms has become "good enough".

2. Ever the bridesmaid:
Remember when CICS was treated different than IMS? Oh - IMS was the darling of IBM, the flagship product and CICS... well it was shipped off to England to die a slow death. As we know the Phoenix never did die but rose from the ashes of losing the political war to become the de facto accepted product. "Phew! That was close! Glad we made it through that one...".

Well get ready for a feeling of "Groundhog Day" because once again IBM has a darling application server and once again (insert drum roll here) - it is not CICS. WebSphere Application Server has most definitely taken center stage in the marketing (if not also engineering) dollars that IBM is giving to the products.

So how do you keep a good man/woman down? How on earth would you hold back an engineering mega force like Hursley where CICS and MQ are developed? This place seems to breed people that can swing from building to building while creating extraordinary software. How would you prevent them from out-engineering and our-performing the WAS lab and in the process stealing the thunder from WebSphere Application Server? To understand this you have to look at the human body. If you look at Olympic sprinters you might see their bodies covered with rippling muscles and you might wonder how on earth do I control all that power? The answer of cause is nerves. Through thin wires spread throughout the body the brain keeps the body under control. The software nerves that IBM uses to keep control of its engineering force are the architects. If you control the architects and order them what they are allow to design then you can control the whole beast. I don't think the Hursley architects would deliberately damage CICS but I am guessing they are probably brow beaten until they do what the "brain" demands.

I believe the architects and inventors in Hursley are held back from competing with WAS. Some functionality is deemed inappropriate to go into CICS and when customers ask about it - the party line rings something like this: "Well that kind of workload would be totally inappropriate for CICS and would be much better suited for WAS". Why?

Why can Java Server Pages not work just as efficiently on CICS as on WAS? Don't tell me about the cost. Don't tell me horror stories of JIT compilations that might cost thousands of dollars. The cost of a technology is not a reason for not doing something it is a monetary result of a deliberate policy. The CICS architecture is certainly more than able to handle the nature of the functionality. No the real reason is that the Java functionality in CICS had to be hobbled (http://en.wikipedia.org/wiki/Hobble_%28device%29 ) so that the bridesmaid's dress does not shine brighter than the bride's... (But hey! let's give them some Java functionality so that the cows don't get unhappy)

Sometimes we just instinctively know something but to get the proof can be difficult. So what proof do I have of such an agenda?

- The amount of attention that CICS got at the 2007 (and to a lesser degree 2008) Impact conferences should be a clear indication of the internal agenda that is being played out.

- On a somewhat different level, look at the amount of work going on at IBM's AlphaWorks site. I did a search on WAS and got 116242 hits, CICS returned 13836 hits.

- Remember the heydays of J2EE where everybody talked about it and nobody had a clue what it meant? Somewhat like SOA today...Anyway those days the standard called for two types of servers, the one would be application container and execute the EJBs, the other would provide the Web serving or front end work. IBM successfully shoehorned CICS and WAS into the standard with CICS fulfilling the backend role. It was like an episode of "Dancing with the stars" that just seemed too peaceful to be true. Then the truth filtered through. You could ALSO run your EJBs in WAS. The immediate question was why? Party line: "Well for the new Java customer that does not have any legacy applications and does not want to run CICS – WAS will be the only server they need". The mask was off, the agenda was clear and CICS was relegated to the role of the bridesmaid. So new Java customers could not choose CICS and develop the whole application there (remember JSPs don't work there) but they could choose WAS for their whole application.

- And then there are the analysts: (http://www.gartner.com/DisplayDocument?doc_cd=125188 ). If the analysts preach it you better believe the CIOs will believe it, so CICS has probably (with help from IBM's management) lost the favor of the analysts.

3. CICS on non-mainframe platforms.
Ok so I get a young developer all excited about CICS and he emails me later that night. He wanted to know where he can download a community edition of CICS, you know like DB2 Express...

I respond with "Well there is the TXSeries version of CICS and it is not really free but even if it was... it is, well sort of different". The developer rings off and downloads a copy of JBoss...

Long restricted by an evil marriage with Encina (and probably lack of funding) - the Windows and UNIX version of CICS has been the ugly duckling of applications servers. It got some traction in sites where CICS system programmers grew up to be CIOs and then forced a younger workforce to work on CICS while at the same time trying to limit the cost of running mainframe CICS. Anywhere else it probably did not get a second look. Now they have a new drive to get rid of Encina and rejuvenate the product. We'll see if that is successful. The point here is this, while I cannot deploy my NetBeans, Cold Fushion, RAD, Google apps, Ruby on Rails, (insert your favorite application development tool here) application to CICS or TXSeries, why would I as a new application server user take this product serious?

The intention with the rejuvenation of TXSeries is right, but in my opinion the way they go about it is wrong. Can someone say virtualization? It seems that everyone and their uncle can "virtualize" the CICS functionality except the owners of CICS.
If you need an example, look here: http://www.sun.com/software/index.jsp?cat=Enterprise%20Computing&tab=3 .

I say virtualize CICS and spread it everywhere with free versions for the hobbyist developer. Make it easy to work with by adding good administration tools and stop engineering it for COBOL applications.

I mean it is good that it can run COBOL but new customers won't look for a COBOL application server, they need something that can run their brand new technology.

Secondly, don't step into the trap of creating a proprietary development tool that only works with CICS. Instead how about making sure that those IDEs mentioned above can deploy to CICS and then work with those companies in an unselfish, non greedy way to have them add CICS as a deployment target.

Third (sort of still the same point as above), take the shackles of the CICS Java implementation and have customers make up their own mind where they run their applications.

Lastly, the role of TXSeries in getting market share back for CICS cannot be overemphasized. In fact it is my opinion that if TXSeries fails it WILL ultimately cause CICS to become irrelevant simply because most people subscribe to the "stable enough" nature of non-mainframe platforms.

4. The software industry.
The software industry around the mainframe world has shrunk largely because few upstart companies can afford the operational costs to run a mainframe. All the small mainframe server ideas (P390, FLEX-ES) have just about been stopped and independent efforts (Hercules) have been the target of ruthless witch hunts.

Ok so how do you entice a new company to get a mainframe with CICS (and DB2, MQ, etc.) just so that they can develop CICS software?

Strategically virtualization will help but more tactically, IBM could do the following:
- Build the biggest parallel sysplex you can using fully configured Z10s. The potential power from such a configuration is not known to me but it would be impressive.
- Make this monster available on the internet and provide virtualization (Using PRISM or VM) with fully configured (albeit small) segments (I call them slivers) that will run the z/OS operating system with DB2, MQ and CICS.
- Provide subscription to this sliver service for individuals, small software companies and open source upstarts. The lowest level of subscription needs to be FREE! And the subsequent levels above that needs to be CHEAP!
- Then back off from buying up all the software vendors build so that we can reverse the black hole effect and yet again build a constellation of stars (read companies) that orbit around a friendly software giant.
- Give it a cool name and market it heavily on the web.
- Get universities involved so that their students can use these "slivers of z/OS reality" for their assignments.

5. The lifeline.
I believe all the recommended actions above will help but there is one more thing that could assure CICS of a future. CICS needs a lifeline. What do I mean? CICS need someone to designate the "next big thing" server architecture to run exclusively on CICS.

It was with dismay that CICS people watched how MQ got its own server/address spaces on the mainframe while it could have been forged into CICS and thereby created not just better application integration but also given CICS a reason to live. Do you think that was a fluke? It is happening again with new flavors of software that all get their own "runtime environment". WebSphere MQ Broker is another example.

For some reason people are reluctant to see CICS as a generic application server that can act as host for a new server runtimes. Maybe... here we have a reoccurring theme, because the LUW version of CICS is so different.

6. Stop NALC.
NALC ( http://www-03.ibm.com/servers/eserver/zseries/library/swpriceinfo/nalc.html ) is absolutely killing CICS. When mainframe customers can get discount for not creating CICS applications - you better believe that will become a pattern for applications. Before you know it that habit has become an addiction and people don't want to develop in CICS anymore. Or all the CICS people have left your enterprise out of frustration and you have no choice. Somebody is sacrificing CICS on the altar of hardware sales and that person needs to be shown the impact of their strategy on the future of CICS.

7. The not-so-happy cows.
I came across this website the other day (http://www.unhappycows.com/ ). This website alleges that the California cows are in fact, not as happy as the commercials would like to imply. In fact many of those cows live a miserable life crammed into huge lots where they live in mud and their own feces producing milk until its time to get slaughtered.

Again it made me think about CICS.

As demonstrated above, unless we get a different approach from IBM the future of CICS looks bleak. The pressure is not just from outside the CICS world but also from inside IBM. Will IBM step up to the challenge and rescue CICS?

People sometimes talk about CICS being a "cash cow". But in all honesty, it is the customers that are the cows. They produce the "milk" right? Well this "cow" is not so happy when I think about the future of CICS.