티맥스소프트

 by Paul Bobak, Vice President, Technical Field Services

Your mainframe has been limping along for a while now. Because it’s still the IT engine for more than half the world’s enterprises, I’ll compare it to the engine of a car you’ve had for years. One day, it makes a clanking sound and there’s an odd smell. It’s obvious it’s dying. Your mechanic gives you three options: replace the engine with another, replace the parts that are about to stop working, or buy a brand-new car. You decide to replace the parts. However, your mechanic says your car is so old that the parts for its model year are unavailable and recommends using updated versions will work just as well.

It’s easy to find yourself in the same spot with your mainframe. Of the different options you have for modernizing it, one is changing your code to a language that you can support and that will work better with the new breed of apps and software designed for today’s agile businesses. This is called code conversion, and it sounds ideal, right? Unfortunately, it’s anything but. Most code conversion projects are fraught with problems, end up costing more than you think, and some even fail. Let’s look at five reasons why.

The Focus is Too Narrow

Code conversion projects focus on modern languages, IDEs, components, and platforms as the way forward for productivity improvements. They are staring at millions of lines of COBOL that encapsulate decades of business processes, protocols and lessons learned. Although there might be some efficiency gained with this kind of IT tunnel vision, a very important part of the puzzle is omitted: the business logic and technical use cases. By not taking them into account, the result is a slew of significant problems that are costly and frustrating to address after migration.

Eligibility Doesn't Mean What You Think It Means

In a conversion project, some workloads, often related to databases and TCP/IP, will be identified as “eligible” for conversion. However, that does not mean that these workloads will convert directly. Eligible simply means that the workloads can be directed to the processor hosting your converted code. So, there you are, in the middle of a conversion project, and suddenly you must address “direction.” You can “force” these workloads onto the processor, but at the expense of performance, and they are unlikely to meet critical response time SLAs.

It's Not the Same

No matter how you slice it, the results of your code conversion will not be exact. Your applications and software will act differently. Conversions tend to change the logic of COBOL and other legacy program languages due to the widespread use of many non-standard “workarounds,” or undocumented features. In addition, in a conversion project, little consideration is given to performance and there is no accommodation for decimal arithmetic, BCD conversions and other mainframe problem areas.

Converted code runs less efficiently and real-time response can become a distant memory. Therefore, if your company’s objective is to reduce costs, this is not the way to go. You end up paying for efficiency issues and such expenses can offset any savings you were hoping to achieve. Your source control management is also not likely to be up to the task for the new language or code. This will mean implementing a new tool, so there’s another

Oh, the Humanity: Overlooking the Human Element Increases Costs

Legacy systems are automated and transactional; however, human intervention is necessary to address exceptions. Code conversion projects do not factor in this human element. This is a recipe for logistical and costly disaster because the converted code creates modern solutions that do not behave like their legacy counterparts, nor are they “fixed” the same way. Your current IT resources who have been maintaining your legacy code are likely to lack experience with debugging in the new language, so you will need to invest in different tool sets and education or training. Also, your current program change methodology for your legacy code won’t apply to the new code, so the processes of fixing and changing the new code will take more time and cost more.

Why Risk It When You Don't Have To?

There’s a reason most people groan when they hear their car engine is on the brink of dying or already dead. They know they will have to make a significant investment. Most choose not to rebuild the engine because there is never a guarantee that the rebuilt engine will run the same, if at all, especially if different parts must be used.

You don’t have to make this kind of decision for your mainframe, either. Code conversion rarely delivers on its promise for the reasons described in this blog post, and you end up incurring more expense than you planned. Rehosting your mainframe is a solution with a much higher percentage of success. Because no new code is involved, there is no change in interface or function.

Instead, your apps move to a less expensive, open system environment, improving mainframe performance. Rehosting takes the legacy source code, recompiles the programs in a new environment without changes to the business logic, and then migrates the mainframe data into a new, more modern database environment. You can reuse existing security profiles, online and batch configurations and definitions, and data set system management profiles.

Want More Information on Rehosting

Rehosting with TmaxSoft OpenFrame enables your enterprise to move your mainframe confidently to a modern cloud-based infrastructure without any change to code or business logic. The migrations are low-risk, and they're fast compared to other modernization alternatives. Most OpenFrame projects can be completed in 6 to 12 months. Learn more about rehosting in the Three Paths to Mainframe Modernization guide.

About Paul Bobak

Paul Bobak is the Vice President, Technical Field Services at TmaxSoft. He has more than 30 years of IT and ISV senior management experience with global companies. At TmaxSoft, he has responsibility for pre- and post-sales support and services. Paul has a diverse mainframe, database, distributed and SOA technology background along with in-depth experience growing and managing teams in multi-platform enterprise-wide environments. He has consistently taken a consultative approach to solving client business challenges, while strategically aligning technology to support clients’ business objectives. Paul has a successful track record for hiring, motivating and retaining performance-driven teams and building a culture of doing what’s needed to ensure customer success. His leadership experience includes senior management roles at Legent, Oracle, Tibco and Netezza. He holds two degrees in Computer Science.