Showing posts with label IMS. Show all posts
Showing posts with label IMS. Show all posts

Monday, August 03, 2026

Why "Cloud-Only" Strategies Fail for Mission-Critical Workloads

 

The Future Isn't Cloud or Mainframe—It's Cloud and Mainframe


For more than a decade, many organizations have pursued what sounded like an irresistible vision: move everything to the cloud. The promise was compelling—lower costs, greater agility, virtually unlimited scalability, and freedom from maintaining expensive on-premises infrastructure. Industry analysts proclaimed that the data center was dead, and vendors eagerly promoted "cloud-first" and, eventually, "cloud-only" strategies as the inevitable future of enterprise computing.

Today, reality is beginning to catch up with the marketing. An increasing number of organizations are discovering that a cloud-only strategy works quite well for some workloads, but not for all of them. In particular, mission-critical operational systems continue to demand characteristics that are difficult, expensive, or simply impractical to reproduce entirely in the cloud.

The issue isn't whether the cloud is valuable. It certainly is. The real question is whether it should become the exclusive home for every enterprise workload. For many organizations, the answer is no.

Mission-Critical Means Different Things

One of the biggest mistakes I see is treating every application as though it has identical requirements. Of course, they don't. A marketing website has very different availability requirements than a bank's transaction processing system. A departmental reporting application is not held to the same standards as an airline reservation system. An internal collaboration tool does not carry the same consequences as a healthcare claims processing application.

Mission-critical systems typically require:

  • Continuous availability
  • Extremely high transaction throughput
  • Consistent response times
  • ACID transaction integrity
  • Comprehensive security
  • Extensive auditability
  • Predictable operational behavior
  • Recovery measured in seconds—not hours

These characteristics have defined enterprise computing for decades.

They're also the reason IBM Z, Db2, IMS, and CICS continue to run some of the world's largest businesses.

Reliability Is an Architectural Property

One misconception is that reliability can simply be purchased. Experienced users know that it can't. Reliability emerges from architecture, operational discipline, software maturity, governance, and decades of engineering refinement.

Mainframe systems have evolved specifically to deliver extraordinary levels of availability while processing millions of business transactions every day. And that is no accident! It is the result of engineering decisions that have been refined over generations of hardware and software.

Simply moving an application to the cloud does not automatically transfer those architectural qualities.

Latency Matters More Than People Think

Cloud advocates often focus on compute capacity. But mission-critical applications care just as much about latency. It is not uncommon for financial transactions, for example, to involve multiple application servers, databases, authentication services, security components, messaging systems, and external interfaces. 

Adding unnecessary network hops introduces delay. Sometimes that delay is insignificant, but sometimes it isn't.

When thousands of transactions occur every second, small increases in latency accumulate into measurable business costs.

The Economics Are Often Misunderstood

Cloud providers have become extraordinarily efficient. But that doesn't mean every workload becomes less expensive after migration. Consider:

  • Operational databases generate enormous volumes of I/O.
  • Large enterprises execute billions of SQL statements.
  • Data is replicated.
  • Backups are created.
  • Logs are archived.
  • Storage grows.
  • Network traffic increases.

High availability configurations multiply infrastructure requirements. And organizations often discover that the monthly operating expense exceeds what they originally projected.

This is one reason cloud repatriation has become an increasingly common topic. Some workloads simply cost less to operate where they already run efficiently.

Data Gravity Is Real

One of my recurring themes is data gravity. Applications can move relatively easily but it is not always that easy for data. Operational databases become deeply integrated with hundreds or even thousands of applications. Moving those databases affects:

  • Batch processing
  • Replication
  • CDC pipelines
  • Reporting
  • AI platforms
  • Security controls
  • Regulatory compliance
  • Disaster recovery
  • Data governance

In other words, the database is rarely an isolated component. It sits at the center of an enterprise ecosystem.

Ignoring that reality leads to expensive modernization projects that deliver far less value than expected.

AI Is Changing the Conversation

Ironically, artificial intelligence has strengthened the business case for retaining mission-critical operational systems. Why is that so? Well, it is because AI depends upon trusted data.

Large language models are becoming commodities... trusted enterprise information is not. Organizations increasingly recognize that their operational databases represent their most valuable information assets.

Db2 databases running on IBM Z often contain decades of highly governed, audited, transactionally consistent business information. The same can be said for IMS databases, which yes, still exist (though are less common).

The trusted data stored in Db2 and IMS is exactly the kind of data AI needs.

Moving it unnecessarily introduces complexity, synchronization challenges, governance concerns, and additional cost.

Modernization Does Not Mean Migration

Perhaps the most important lesson is this: modernization is not synonymous with migration.

Modernization can include:

  • API enablement
  • Event streaming
  • Change Data Capture
  • Hybrid cloud integration
  • AI enablement
  • REST interfaces
  • Data virtualization
  • Kubernetes integration

Notice what isn't required. Moving the operational database.

Many organizations are discovering that exposing trusted operational data through modern interfaces produces better business outcomes than relocating the underlying systems.

The Hybrid Enterprise Has Already Won

The enterprise architectures I encounter today rarely resemble the all-or-nothing visions presented a decade ago. Most commonly, they are hybrid. Operational systems remain on platforms where they perform best. Cloud platforms provide elasticity for analytics, AI experimentation, web applications, and new digital services. Streaming technologies connect everything together. APIs expose business capabilities. Data virtualization reduces unnecessary duplication. AI consumes trusted enterprise information regardless of where that information physically resides.

That isn't a compromise... it is a good architecture.

Final Thoughts

Technology decisions should always begin with business requirements not industry trends and hype. The cloud is an extraordinary platform for many workloads. But so is the mainframe!

The objective should never be to force every application into a single architectural model. It should be to place each workload where it delivers the greatest business value while minimizing risk, cost, and operational complexity.

After more than forty years working with enterprise databases, I've learned that the most successful architectures rarely chase the latest trend. Instead, they build upon proven strengths while selectively adopting new technologies where those technologies genuinely improve the business.

For mission-critical workloads, that often means embracing a hybrid strategy that combines the resilience and transactional integrity of IBM Z and Db2 with the flexibility and innovation of cloud services.

That may not be as catchy as "cloud-only," but it is far more likely to succeed.

Wednesday, April 20, 2022

Moving from IMS to Db2?

As a Db2 consultant and regular blogger I often receive questions about technical things, but also on strategy and industry trends. I try to help but I always make it clear when answering that I cannot predict the future, only make educated guesses... So with that introduction out of the way, one of the regular questions that I get involves comparing IMS to Db2, or helping to determine if it makes sense to convert from IMS to Db2. Here is the text of a recent question that was posed to me:

"My customer is wondering about the possible advantages of converting his IMS DB/DC system to IMS DC/Db2. The application currently performs well with an internal response time of less than .5 seconds on average. Even with an arrival rate of 425 full-function transactions per second, the queue count rarely goes above 10. This system typically peaks at 12.5 million transactions per twelve-hour day against HDAM and HIDAM databases totaling close to 1 terabyte. The application itself is currently a bit over seven million lines of code. Can you comment on the relative cost vs. advantage of moving an existing application from IMS DB to Db2 along with relative CPU capacity requirements?"

Here is my response:

Well, the main advantages of converting from IMS/DB to Db2 would be the better support for ad hoc query, support of standard SQL (instead of non-standard DL/1) for writing queries and a deeper pool of talent to support the Db2 environment. There are many more skilled Db2 developers out there than there are IMS techies these days. 

The primary benefit of sticking with IMS is the good and predictable performance you currently enjoy. And, of course, there would be no need to convert the database structures or the more difficult-to-achieve rewriting the necessary application code.

So, the high-level metric to keep in mind as you make your decision comes down to this: a well-designed IMS application will perform very fast, perhaps faster than a well-designed Db2 application (but that does not mean that Db2 is slow). On the other hand, it will be easier to develop applications for Db2, especially when data needs to be accessed multiple ways and in an ad hoc manner. 

I guess it boils down to this: How happy are you with the current application, are you able to support it properly and how many other IMS/DB databases do you support? If this is the last IMS/DB database and you are looking to convert away in order to rid yourself of the IMS license, then it makes sense to consider converting. But you should do a project plan and cost/benefit analysis before making your final decision (conversion can be very costly). If you have a lot of other IMS/DB databases, then don't convert to Db2 unless you cannot support the needs of your end users (management, ad hoc support, etc.) using IMS.

In terms of CPU requirements, Db2 will consume more CPU than IMS. Db2 optimizes queries internally whereas IMS programmers construct access paths to data. This additional requirement will cause Db2 to consume more CPU. But, of course, that additional CPU brings with it the enormous benefit of database optimization and better ad hoc query support.

Furthermore, if you do decide to convert from IMS to Db2, be sure to use Db2 as it was intended to be used. In other words, don't just convert segments to tables and be done. Make sure that you normalize your design and come up with a good "relational" Db2 database design. Also, be sure to train your programmers to write SQL queries. That means changing mindsets from the record-at-a-time processing of IMS to the group-at-a-time processing of Db2 and SQL.

For example, if you have master file processing logic it needs to be re-examined in Db2. Instead of open file, read record from file, use key to read record from database... you should be joining tables and reading from the join. This requires a different mindset and coding technique. 

As an additional consideration, keep in mind that Db2 is a much "newer" database technology than the hierarchical infrastructure used by IMS. So it stands to reason that newer capabilities and features will likely be implemented in Db2 before they are implemented in IMS; for example, AI and machine learning capabilities. That does not mean that IMS is obsolete, it isn't; IBM still maintains and upgrades IMS (at the time of writing, the current version is IMS 15.2 which was released for GA in March 2020).

Summary

Of course, this answer has been necessarily brief. I encourage you to read up on Db2 and understand its many differences with regard to IMS before jumping into a "go"/"no go" decision. Best of luck...

Thursday, July 30, 2009

Discount on IBM Information on Demand Conference

The IBM Information on Demand (IOD, for short) conference is rapidly approaching. The conference will be held in Las Vegas, Nevada the week of October 25 – 30, 2009 at the Mandalay Bay casino and hotel.

The IOD conference is IBM’s signature event for their data and information management product lines. By attending IOD 2009 you can gain unique perspectives from IBM experts, technical leaders and visionaries as well as peers in your industry. Many of the developers of IBM’s offerings, such as DB2, Informix, and IMS, will be delivering educational sessions at IOD. And over 200 customers will share real-world experiences detailing how they have unlocked the value of their information and realized tangible and immediate return on investment.

OK, so what about that discount? IBM has been kind enough to provide me with a discount code that I can share with my readers. You will need to provide the code, G09MULL, when your register for the conference and you will get a $100 discount off of your registration!

Here’s how to register on-line:

  • An IBM userid and Password are required to register. If you have an existing IBM.com account ID, please select 'Register for the Conference' and sign on. If you do not have an IBM.com account ID, please follow the link 'MY IBM ID' to obtain one. Complete the form and click 'SUBMIT'. You will then be allowed to continue as a registered IBM user. Click 'Continue' and select 'Register for the Conference' and sign on with your new userid and password.
  • Select registration type of 'Customer' and click 'Continue'
  • Complete the appropriate fields on the enrollment form
  • Under the 'Promotion Code Information' section, enter PROMOTION CODE G09MULL. You must enter this code to receive your $100 discount.
  • Complete the form with attendee, arrival and payment information clicking 'Continue' at the bottom of each section.
  • Click 'Submit Registration'

Note: Credit card information is required to guarantee your registration regardless of your method of payment and/or discount amount.

That’s all there is to it. And you can use the promotion code multiple times for all of the folks at you company that will be attending the Information On Demand conference in 2009.

Cheers!

Thursday, March 26, 2009

Cost vs. Advantage of Moving From IMS DB to DB2

As my regular readers know, every now and then I like to share Q+A exchanges I've had with folks. Today, the question I was asked is as follows:

My customer is wondering about the possible advantages of converting his IMS DB/DC system to IMS DC/DB2. The application currently performs well with an internal response time of less than .5 seconds on average.

Even with an arrival rate of 425 full-function transactions per second, the queue count rarely goes above 10. This system typically peaks at 12.5 million transactions per twelve-hour day against HDAM and HIDAM databases totaling close to 1 terabyte. The application itself is currently a bit over seven million lines of code.

Can you comment on the relative cost vs. advantage of moving an existing application from IMS DB to DB2 along with relative CPU capacity requirements?

And here is my short response:

Well, the main advantages of converting from IMS/DB to DB2 would be to gain better support for ad hoc queries, standard SQL (instead of non-standard DL/1) for writing queries and a deeper pool of talent to support the DB2 environment (there are more DB2 folks out there than IMS folks now-a-days).

The benefit of sticking with IMS is the good performance you currently enjoy as well as no need to convert the database structures or the 7 million lines of application code. Converting database structures is not horribly difficult, but there are some gotchas that can arise. The bigger problem is converting all of those DL/1 calls to appropriate SQL. This will not be a simple 1 to 1 conversion and it will very likely be quite time-consuming.

I guess it boils down to this: How happy are you with the current application, are you able to support it properly and how many other IMS/DB databases do you support? If this is the last IMS/DB database and you are looking to rid yourself of the IMS license, then it might make sense to convert. But you should do a project plan and cost/benefit analysis before making your final decision (conversion can be very costly). If you have a lot of other IMS/DB databases, then it probably doesn't make a lot of sense to convert to DB2 unless you cannot support the needs of your end users (management, ad hoc support, etc.) using IMS.

In terms of CPU requirements, DB2 will consume more CPU than IMS. DB2 optimizes queries internally whereas IMS programmers construct access paths to data. This additional requirement will cause DB2 to consume more CPU. But, of course, that additional CPU brings with it the enormous benefit of database optimization and better ad hoc query support.

You might also want to take a look at a product like DL/2. I have never used it so I cannot recommend for or against its functionality, but it looks like it might save you some work.