Evangelizing Mainframe
Print Email

What’s the Future for IMS?

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.

Posted: 6/20/2017 12:00:58 AM by Trevor Eddolls | with 1 comments

Print Email

Please sign in to comment.

Sign In


Comments
Thanks Trevor, for addressing this important topic: that IMS is open and connected, and that it shows no signs of slowing down. As the Chief Architect for IMS, I'd like to share my perspective as well.

In the early days of IMS, applications and data were co-located on the Mainframe and life was good. That is what we needed back in the early days of computing. As I/T needs have evolved, so has IMS. Today our clients can access IMS transactions and data using open and standard interfaces that support the API Economy. Let's take a quick look back at some of the ways we have opened up IMS and allowed connectivity to bridge to other platforms.

We first introduced remote access to IMS transactions through TCP/IP in 1998 using the IMS TM Resource Adapter (IMS TMRA) then known as the IMS Connector for Java. It communicated with IMS Connect to provide TCP/IP access to IMS transactions. IMS Connect continues to be enhanced for additional types of TCP/IP access to IMS assets. IMS 7 in 2000 added the ability to write IMS applications in Java. IMS 11 introduced the IMS Open Database Manager which provides standard JDBC access to IMS data from any platform. Using TCP/IP connectivity through IMS Connect, our clients have enabled open access to both IMS transactions and data for almost two decades.

The mobile ecosystem has exploded over the last few years and continues to grow. Many of our clients' mobile applications need access to IMS transactions and data.

Using z/OS Connect Enterprise Edition, ( https://www.ibm.com/us-en/marketplace/connect-enterprise-edition ) you can easily enable IMS applications with RESTful APIs with JSON data with no code changes required. APIs can be created using the visual API editor toolkit with point and click mapping that automatically conforms to OpenAPI 2.0. API can be tested with the tooling, deployed to z/OS Connect Enterprise Edition server dynamically, published to developer portal for API discovery and be integrated and governed by API management products such as IBM API Connect ( https://www-03.ibm.com/software/products/en/api-connect ).

With the latest z/OS Connect EE V3.0.1, ( https://developer.ibm.com/mainframe/2017/07/17/zos-connect-ee-v301-released/ ) IMS applications can now call out to external APIs.

Application developers can jump start with z/OS Connect to access free trial, sample code, tooling, videos and tutorials from the z/OS Connect EE Development Center
( https://developer.ibm.com/mainframe/products/zosconnect/ )

Today it is common for IMS clients to have an integrated enterprise where IMS interacts with other IBM Z and/or distributed systems on a daily basis. Our clients are driving IMS transaction workload and accessing IMS data from distributed platforms. IMS applications can access remote services. Whether you are using IMS TM, IMS DB or both, there are options for you to open up transactions and data. If you haven't yet opened up your IMS to the outside world, now is a great time to get started.

To get started with z/OS Connect and IMS see the IMS API Economy Solution Kit ( https://www.ibm.com/support/knowledgecenter/SSEPH2_15.1.0/com.ibm.ims15.doc.sk/ims_apie_ovr.htm )
To get started with opening up your IMS data, see the IMS Open Access Solution Kit. ( https://www.ibm.com/support/knowledgecenter/SSEPH2_15.1.0/com.ibm.ims15.doc.sk/ims_openaccovr.htm )

We just launched an IMS Developer Center ( https://developer.ibm.com/zsystems/ims/ ) and are working to add content, code, tutorials, and more to help you succeed with IMS. If there is something specific you need, let us know.

Betty Patterson Bucci
IBM IMS Chief Architect
Posted: 7/31/2017 4:12:11 PM by Betty Bucci

Join Now!