IBM Destination Z - Group home

What’s the Future for IMS?

By Destination Z posted Mon December 23, 2019 03:29 PM

The idea of IMS has been around since 1966, when a bill of materials system was needed for the Apollo space program. And the first ‘IMS READY’ message turned up in August 1968. In fact, for many people, IMS has provided the database of choice because it’s been able to not only store large amounts of data, it’s been able to access that information very quickly.

But 1968 was a long time ago, and things have moved on. Hasn’t IMS pretty much had its day? Isn’t it really just doing what it’s always done and no more? The answer to both those questions is a resounding no.

The “trouble” with mainframes is that they’re very secure. If you were a biologist, you might think of mainframes like an island ecology that’s separated from the mainland by a stretch of water that has dangerous currents. And that means that the flora and fauna on the island has grown and developed in a unique way that is quite different from the mainland.

So, our mainframe island has created unusual species such as IMS, CICS, COBOL, Assembler, VSAM, DL/I, PL/I, etc., which don’t exist on the mainland. And that dangerous current would be the firewalls and other security that’s wrapped round the mainframe. On the mainland—or perhaps it’s just another very large island (it all depends on your point of view)—we find more familiar creatures such as REST/JSON, SOAP, JDBC and ODBC.

The secret for IMS to have a great future ahead of it is to find some way to build a bridge from one island to another so that the plants and animals can mingle and coexist. We need a bridge that can keep the mainframe data secure, but allow IMS to communicate with these other creatures.

For those of you who tuned in late, IMS comes in two parts. There’s the database part mentioned above (e.g., Full Function, Fast Path and High Availability Large Databases), and there’s the transaction management part that allows users to access the data and update it.

Originally, people would be working from 3270 screens to kick off their transactions, but now they can start them from browsers. And those browsers can be running on any devices (e.g., laptops, tablets, smartphones, smart TVs). And information can also be stored in IMS databases from Internet of Things devices that could be monitoring temperatures, blood pressure or whatever. So that’s an example of IMS starting to build bridges that allow for two-way communication with the creatures outside.

But what next? For many people, the future involves Agile working, speedy delivery of new or improved applications, and embracing the API economy. To do that, IMS needs to find away for developers who are familiar with REST/JSON and the other acronyms (creatures) listed above to be able to work with IMS database and IMS Transaction Manager. They need to find a way that everyone can be speaking the language they’re familiar with and communicate with each other.

Sometimes, when technical folk (from whatever background) get in a room, the air is full of acronyms. What the business needs to do is think of these APIs in terms of business function. That makes it easier for everyone to understand what’s going on and how their part fits in. All that needs to happen is that APIs need to be available to allow external products to talk to mainframe-based products. That way, everyone is speaking a language that they are familiar with, plus non-mainframers are able to access mainframe data and transactions. The mainframe is an essential part of the whole transaction. It does what it does best: running transactions on large databases, the transaction can be called from a remote device running quite different software, and the results of the transaction can be returned to that or a different, device.

So now, rather than being behind a firewall (or, using our metaphor, deep sea currents), the mainframe has bridges linking it to other technologies.

So, moving from the metaphorical approach to real software, how can this bridging be achieved? IBM’s API Connect is a management solution for creating, running, managing and securing APIs for external and internal consumers to accelerate an organization’s API program and capture new revenue through compelling new customer experiences. And there’s z/OS Connect, which works well with REST Uniform Resource Identifiers and JSON data.

Your mainframe data can now be linked to business analytics tools; extract, transform and load tools; data warehousing; cloud services or anything else.

And it’s not just IMS from your isolated mainframe island creatures that can bridge to the rest of the IT creatures. The mainframe can be part whole IT infrastructure—and that’s very important for the success of organizations moving forward.

Trevor Eddolls is CEO at iTech-Ed Ltd, an IT consultancy. A popular speaker and blogger, he currently chairs the Virtual IMS and Virtual CICS user groups. He’s editorial director for the Arcati Mainframe Yearbook, and was an IBM Champion between 2009 and 2016.