Trevor Eddolls April 21, 2022
Information Management System (IMS) was developed by IBM, with Rockwell and Caterpillar Inc., starting in 1966 as a bill of materials system for the Apollo space program. It went live in 1968, making it over 50 years old. Like everything else on the mainframe, it has been updated and extended since that time.As you know, IMS comes in two parts: the database system and the transaction manager. The types of IMS databases available were initially designed to optimize the speed of data access. IMS databases were the fastest available. You may have heard of full-function databases, fast-path databases, and high availability large databases (HALDBs). The transaction manager part (sometimes called IMS DC) is similar to CICS. Users can enter information on their screen, which kicks off transactions that read, delete or update data in the database. All of these transactions occur very quickly.Thus, if you have an amazing piece of software running on your mainframe that can access huge amounts of data that you have stored there incredibly quickly, wouldn’t you want to share it with other platforms? Wouldn’t you want to make your data available to the cloud to run analyses on that data to help your company derive more valuable information from it? In addition, wouldn’t you want people to be able to run IMS transactions from their phones or tablets? And might not you want to run completely new applications that use something from IMS and something from another platform? With an IMS database, you can put the two (or three or four) components together and you have something new and amazing that’s available to customers and potential customers.That all sounds brilliant, but most non-mainframers would consider that to be impossible. After all, they’d say the mainframe is fairly arcane in the way it works, and IMS is even more so—which is why IMS databases retrieve data so quickly. The answer is, of course, that this is entirely possible using APIs. In essence, an API allows one program to connect to another.
IBM z/OS Connect Enterprise Edition
IBM supplies the IBM z/OS Connect Enterprise Edition (z/OS Connect EE), now at Version 3, which allows organizations to open their IMS data and other mainframe data to cloud, mobile and web customers. z/OS Connect EE comes in two parts: an Eclipse-based API toolkit user interface, and the z/OS Connect EE runtime. The Eclipse-based z/OS Connect EE API toolkit supports the creation of z/OS Connect EE services. API and service artifacts for IMS can be created using the toolkit. Services can be dynamically deployed as service archive (SAR) files, which eliminates the need for specific per-service entries in a z/OS Connect EE server configuration file. More details are available from IBM.
IMS Operations API
Another way of working with APIs is through the IMS Operations API, which is available from GitHub. GitHub defines the IMS Operations API as a service that provides RESTful APIs to manage the IMS resources that are required to deploy IMS applications. As a result, the REST APIs initiate the IMS commands that are required to operate and query the IMS application resources.The IMS Operations API can be used with the Zowe CLI plug-in for IMS. When the IMS Operations API and the Zowe CPI plug-in for IMS are used together, the REST APIs that are delivered with the IMS Operation API enable two different things. It enables the communication between the Zowe CLI and an IMS system, and it enables you to use the Zowe CLI commands to interact with IMS resources. Alternatively, instead of using the Zowe CLI plug-in for IMS, you can call the APIs from any REST client.Since you can write scripts that use the Zowe CLI commands, and as a result, call the IMS Operations API, the Zowe CLI commands and RESTful APIs can then be used to enforce an automated CI/CD pipeline for building, testing, and delivering your IMS applications.Zowe is a way to make using and controlling a mainframe more accessible for IT personnel that may not be mainframe specialists.
IMS and RESTful APIs
It’s also possible to expose IMS transactions as RESTful services, allowing them to connect to applications outside the mainframe as Subhasish Sarkar, senior product manager at BMC Software, explains in an article titled, “Expose Existing IMS Transactions as RESTful APIs.” To securely expose your existing IMS transactions as RESTful APIs, Sarkar lists three practical steps to begin implementation.The first step is to create an IMS RESTful API. This involves creating a service to enable RESTful access to IMS transactions through the IMS service provider, also referred to as the IMS Mobile feature. There are four components to this step:
- In part 1, IMS Connect acts as the TCP/IP gateway, allowing the transactions to access IMS DB. It can also access Db2 and other external subsystems.
- Part 2 uses zCEE. This is a WebSphere Liberty-based server housing RESTful services, necessary artifacts and connection properties, as well as profiles needed to expose IMS transactions as a RESTful service.
- Part 3 uses IBM IMS Enterprise Suite Explorer for Development (E4D). This is Eclipse-based tooling and is needed to manage, deploy and test IMS RESTful services in z/OS Connect.
- In part 4, the zCEE API toolkit is required in order to create IMS services and RESTful APIs to act on those services.
The second step is to call an IMS RESTful API from a z/OS application. The API can be called from mainframe-based programs.The third step is to call an IMS RESTful API from outside the mainframe. IMS completes this on the backend and quickly sends the response from the transaction back to the specific application or program that initiated the call.
IMS Complexities
In February of 2022, Dusty Rivers, Adaptigent’s Director of z Systems, advises a Virtual IMS user group on navigating IMS as a client in the new world. Rivers explains that there are several complexities when connecting legacy IMS applications to the outside world, including:
- Attributes
- Message switching/multiple program calls
- Multiple input and output messages
- Variable length, multi-part messages, different layouts
- Complex structures such as REDEFINES and Occurs Depending on Object (ODO)
- Null terminations, non-standard code x’3fff’
- Screen macros (zero or numeric fill)
- Conversational dialogs
- External and other 3270 applications
- Complex conversational transactions
To address these complexities, there must be a way to connect to any application on any platform. While the transaction in IMS could be using call formats such as COBOL, PL/1 or Assembler, it could be talking to Java, JSON, WSDL, OpenAPI, or XML. There is a need for some way to import OpenAPI/WSDL Docs, generate native language stubs, add them to existing or new programs, and add a process to handle the calls. Additionally, there may be other requirements too.Rivers pointed out the following IMS outbound considerations:
- Segregate the outbound MP regions
- Think of payload sizes
- COBOL PL/1 Data-types mapping
- Specify timeout values
- Consider the endpoint
To illustrate the problem-solving solutions that can be done, Rivers described some real-life examples. He had a customer using an API server product for printer inventory servers. Other customers are utilizing it to connect to SAP and Salesforce. Some customers are connecting IMS to AWS applications, and others to third-party software. In fact, they are connecting to anything with an API, including certain streaming apps like Kafka.
Connecting IMS to the Outside World
Those are just a few examples of how IMS can connect to other IT platforms for the benefit of customers and an organization’s bottom line. So, to answer the question in the title: Yes, Virginia,there is a way to connect IMS to the outside world!
