To Run Unsupported – That is the Question.

By
Don Fowler
ÓMCE Inc, July 2005

 

To be, or not to be: that is the question:
Whether 'tis nobler in the mind to suffer

The slings and arrows of outrageous fortune,

Or to take arms against a sea of troubles,

William Shakespeare’s Hamlet

 

The Unsupported Quandary

Willie Shakespeare summed it up well, don’t you think? As software vendors end support of versions of products, do you as a user migrate to supported levels or run exposed to “outrageous fortune”. 

 

There was a recent spate of messages on IMS-L about the ramifications of staying at IMS Version 7 when support ends this November. There appears to be some organizations questioning should they move to IMS V8 or V9 now or can they wait for some period of time or just run exposed for the foreseeable future.

 

Running unsupported doesn’t mean you will experience a problem, it means that if you do experience a problem, it belongs to you.

 

Dougie Lawson’s (IBM) reply to this question states the situation very nicely. He said, “If folks want to run IMS (V7) beyond 8th Nov, then they take the full burden of that risk (assuming they don't have a service extension in place with the IMS Lab). Do you want to take that risk? Unsupported means unsupported, it doesn't mean 'almost supported if there is an "R" in the month', when it breaks you get to keep both pieces.”

 

You can review IBM’s support policy for all of their software at their Software Support Lifecycle web page.

 

Basically, you get the following policies from Big Blue for your software: 

 

• Provide support for all products for a minimum of three years, beginning at the date the product is available for purchase (general availability date).
• Provide notice at least twelve months before product support is withdrawn, giving you a reasonable period of time to use the software before migrating to a new version or release.

• Establish effective dates for withdrawal of product support in either April or September

• Display all information on lifecycle dates in one location, enabling you to effectively plan your migration

 

So you have had a year already since IBM announced Version 7 was going away. I’m sure you are busy, but really…. It took you almost a year to figure out you need to ask a question about running unsupported? And you wonder why your management looks at you like that when you walk in the room?

Just kidding folks, but look at it this way. If you are asking a question like that in July for a product ending support in early November, you will be running unsupported in production for some period of time whether you like it or not.  Version upgrades in a properly controlled and tested manner require more than a few days or weeks to complete.

Determining If Running Unsupported Is Acceptable

So what criteria should you use to decide if you could risk running in the unsupported environment?

We suggest you might apply the following types of criteria:

1.        Are you upgrading other components in your system that might impact the unsupported environment? Upgrading or even applying service to components such as DFSMS or z/OS might cause a problem in IMS, CICS, DB2, or other strategic software components of your system. If you are not doing any service or upgrades anywhere else in your system, you might consider running unsupported for some small period.

2.        Government regulations require your industry to stay current in your business enabling software. Could a failure in your unsupported environment lead to a violation of Sarbanes-Oxley (SOX act) as an example? You might be put in the situation where the unsupported environment introduces an “operating deficiency”. In SOX terms, an operating deficiency occurs where a properly designed control does exist but is not operating, as it should. Typically these occur, because the responsible employee does not have the required permissions or qualifications. Alternatively there may be a technical fault. If a technical fault is caused by unsupported software left in place by management decision, and that software is involved with financial systems, there is an exposure to the fault being considered a SOX violation. Consider also if HIPPA compliance may be violated if a technical glitch occurs between servicers and providers root caused by the unsupported software..

3.        What is the impact to the business if the applications running in the unsupported environment become unavailable? How much in terms of real dollars is effected by these applications? How long can you tolerate such outages? Many of these types of numbers can be obtained from your disaster recovery (or business continuity plan) documentation. 

4.        Is there any maintenance or enhancements planned for the applications using the unsupported software? What is the probability that these changes may introduce a new problem?

5.        How qualified is the support staff to resolve the problem or provide a work around within a reasonable period of time? 

 

Once you have gotten the answers to the above questions, you can weight the answers to size your true exposure. We suggest you apply decision-making weighting as follows:

 

Item 1 = 10% (System should remain stable until any upgrades are applied)

Item 2 = 25% (Based on possible regulatory penalties)

Item 3 = 25% (Based on these applications percent vs. total dollar impact of all applications)

Item 4 = 15% (Will changes to application possibly introduce untried product functions?)

Item 5 = 25%  (Look at your problem logs and see when the last time staff contacted the vendor on a problem. Check how many times in the last eighteen months staff members have used the vendor’s support structure.)

 

If your answer is equal to or greater than 50%, consider immediate migration to a supported environment. 

 

This is only an example and is not intended to be the end all and be all answer to this question of running unsupported. You will probably want to add you own criteria and adjust the threshold amount that would indicate running unsupported is not a good idea.

 

End of Service on a Software Product

Doing migrations between versions of software is one thing, but the other unsupported issue to be faced by users is when a vendor ends support of a product.

 

This is happening in September to the IBM CICS/DMS product. The most important thing one must consider in this environment is if you are moving forward on upgrades and services for the underlying enabling software products used by the now defunct product your application requires.

 

If you are, you will quickly reach an environment where the defunct software will no longer run (a.k.a. ABEND). Such is the case of old COBOL/VS. It will no longer run at CICS 3.1 level. So any CICS applications using this COBOL must be migrated. Not next year, next month or next week. But right now!

 

If your mainframe is now an integral part of the web enablement strategy for your company, you will be upgrading components (z/OS, CICS, etc.) on a regular basis, so your exposure is MAJOR.  A product like CICS/DMS/VS may run fine for one or two more CICS upgrades, but it will finally fail. If you are using old COBOL language exits for your DMS exits, you are already at failure point.

 

The same decision making criteria are still valid. Just apply a different weighting for this type of End Of Service scenario. Make the weighting for underlying enabling component upgrades heavier.

 

EOS Via Certificates

There is one additional type of End of Support scenario that should be considered. While not truly an “End of Support”, the expiration of a digital certificate is effectively the same situation. Certificates help ensure that software applications installed on a PC or transactions conducted over the Web (and even Websites) are what they claim to be. These ‘X.509’ certificates are digitally signed by an independent third party (like VeriSign) to verify the authenticity or identity of an entity. A trusted public key is used as part of the process. Microsoft Authenticode and Java ARchives are among the code-signing mechanisms.