Perceptions – The Filtered View

As with all glimpses of the world, we all see things through our own filters. Our filters exist due to many influences including, but not limited to, our childhoods, circle of friends, schooling, professional experiences, and marketing hype.

What are the perceptions today related to costs of software for mainframe and the various other server platforms?

Ask your manager his or her perceptions. They will probably state answers that fall into two main themes.

1) Server software is cheaper than mainframe software. Thus the total cost of ownership is less for the server environment, and

2) Mainframe software does not play well in the world of the web and e-commerce.

Let’s take a look at these two perceptions and see if there may be some flaws in that thinking today.

Mainframe Does Plays Well In Web Applications

We believe that we have beaten to death the latest z/Series software products inclusion of SOA capabilities. CICS may now be a Server or a Client and fully participate in all aspects of SOA. See these previous articles for detail on SOA implementations for CICS and SOA as a general topic:

· So What Is SOA and Why Does CICS Care?

· The Demise of the Mainframe

· Nine Reasons for CICS V3.1

If you review all of these previous papers, you should be easily able to state some facts that will begin to erode the perception that at least CICS TS 3.1 plays well in the web world! Finally the RAS aspects of CICS and z/OS applied to the web world. We now have the industrial strength SOA server all enterprises are looking for. When was the last time anyone told you to reinstall a product and reboot your z/OS system? That is another double standard, but we will address that one in a future paper.

We will focus our attention on the other perception that the mainframe software is much more expensive than the “other guys’”.

Software is More Expensive For the Mainframe

Most people tend to look at the monthly or one-time licensing costs, annual service costs as their main criteria for comparing a mainframe to say a smaller INTEL based platform. Maybe this is not the whole story? Hmm?

We are seeing more and more Independent Software Vendors starting to take this strategic move. They will introduce a version of their application as say Program X 2003. Then they set a 3-year End Of Service and bring out Program X 2006. This is normally more than a simple EOS. It is a sunset of the previous version. They also take away any ancillary support functions you might be using until you move to the new version.

A good example of this is Intuit’s QUICKBOOKS PRO. Our company’s version was 2003 still running on Windows 98 platform. We send our invoices and handle our payroll through e-commerce connected functions provided by Intuit. We were notified in December that we would have to upgrade because PRO 2003 was to EOS in April 2006. With this EOS, we would no longer be able to send invoices or have our payroll serviced. This really does not appear to be technical matter. It appears that this ISV cannot continue to support the back level version and is cutting all ties to it.

We ran into a further problem that the PRO 2006 version required WINDOWS 2000 as a minimum to be in a supported environment. We are not year ready to move the company business system past 98 level due to other application issue we need to resolve and replace first. But here was an ISV basically forcing us in a three year period to address reversioning and replacing all of our old software.

We did finally settle on interim installation of PRO 2005 that does support Windows 98. This buys us two more years until EOS and gives us time to gracefully replace the older applications.

We cannot remember any IBM mainframe software that ever had a three-year EOS from initial release date. Even when EOS has occurred, applications have continued to be used for at least ten years following EOS. An example of this is OS/VS COBOL. It went EOS in 1994 and was finally removed from operational support in CICS TS 3.1 in 2005.

Another variation on this is when a component of a system has their security certificate expire. An example of this was APC, the UPS vendor. If their clients were using POWERCHUTE version 6, they were forced marched to version 7 by an expired certificate.

APC’s written statement was:

In order for PowerChute Business Edition to remain functional, users must upgrade to any version of 7.x. Due to expiration of the Sun Java Runtime Environment certificate, versions 6.x of PowerChute Business Edition will cease to operate normally as of July 27, 2005. If you fail to upgrade, Powerchute Business Edition will no longer provide monitoring and graceful shutdown of your system.

(See the entire problem write up at http://nam-en.apc.com/cgi-bin/nam_en.cfg/php/enduser/std_adp.php?p_faqid=7202 ).

You might enjoy seeing a problem record that was created for this situation. It is titled: System with APC Powerchute 6.x UPS Software gives strange symptoms. Click this link to get it: http://support.microsoft.com/kb/555386/en-us .

ColdFusion MX also had a similar problem with runtime. It was simply a release upgrade to fix that problem. Of course, we have only found one user product feed announcing the failure would occur on July 28, 2005. That feed was dated July 27, 2005. We would hope there was more notice than that to the users in the future.

Now, granted the expiration of certificates for runtimes is less than the bulk of the expired certificates, it does occur. At best, the user will start receiving error messages about expired certificates. At worst the application will fail.

One could look at this as a pure downward compatibility issue. When was the last time you had a serious downward compatibility issue with a z/OS system? OK, OK. There was the old Language Environment issue in OS/390 between version 1 and version 2, but that was finally resolved in OS/390 V2R10 and IBM did provide a cumbersome workaround prior to that. In fact, IBM mainframes have been heralded for over 40 years on their downward compatibility that has protected user application investments.

So what are we seeing?

We are seeing PC and non-mainframe Server software vendors shortening their EOS cycle and physically removing functions at EOS time. This is causing a forced march of users to upgrade on an almost three year basis in many cases. The EOS cycle of the mainframe appears to be about the same as it has been for at least the last fifteen years.

We are seeing expiring security certificates of one vendor causing versioning issues with another. Some of these issues have not been well published, nor known to user until the time of failure. This causes extra expense to an enterprise to drop everything in plan and address the reversion problem (or upgrade to release) when it occurs.

Summary

We hope you have some general feel now for the existing double standard facing mainframe professionals in a non-mainframe based management mentality world. If you can put a small doubt in the mind of management that the non-mainframe world is truly a less expensive solution, you have an opportunity to make larger strides in making the z/Series the Enterprise Server of Servers.