The team at HostBridge Technology periodically receives inquiries from IT teams that are tasked with decommissioning the mainframe, either in entirety or by migrating a specific set of applications to the middle-tier. These inquiries typically come when the projects hit a barrier, usually in the form of existing CICS transactions that display information online (at a presumed terminal), and where complex, application logic is involved in creating the display. In other words, the transactions involve more than simply retrieving data from DB2 or other mainframe databases.
These decommissioning projects are familiar territory for the HostBridge team, because we understand precisely the challenges of migrating complex terminal-oriented CICS transactions, and the data they “hold hostage,” to other platforms. The HostBridge solution set provides several options for accomplishing these projects.
Option 1: The Base XML HostBridge Solution. Using the HostBridge Base product to retrieve CICS data screen-by-screen, or record-by-record, and return it as an XML document to middle-tier applications represents one option. Implementing this solution involves the use of non-mainframe tools to mine the XML output HostBridge provides and reconstitute the data according to the desired data model. This option is a “1:1” approach – a distributed program sends one request to HostBridge, one CICS transaction runs, and one XML response is returned. This process occurs for each transaction that holds data. By the way, HostBridge enables this 1:1 approach without using screen-scraping.
For example, let’s assume that we need to retrieve data for inventoried parts at a large manufacturer. And, let’s assume that the complete information for each part can be obtained by running 10 transactions. Using this Option, a middle-tier program will need to submit 10 requests through HostBridge, and “knit together” the data from the 10 XML documents HostBridge returns. This may or may not be a simple programming task.
Regardless, the key consideration is volume. Let’s assume that there are 100,000 parts. As a result, the middle-tier must send 1,000,000 requests to HostBridge to fetch the required mainframe CICS data. Now the picture changes: The middle-tier programs must parse 1,000,000 XML documents and build a cohesive data model. As you can imagine, depending on the number of transactions required, and the sophistication of the non-mainframe tools to mine the resulting XML documents, this approach may work well – or not!.
- A distributed program sends one web service request to HB.js (running under CICS)
- The request invokes a script. In this example, we’ll call the script getPart and assume the CICS transactions are related to a person. A part identification (“PID”) number is provided as input.
- The getPart script does the following:
- Invoke ALL transactions required to obtain all data for the PID (all this is occurring under CICS and at memory-to-memory speeds).
- Organize all the data fields obtained from each CICS screen into a single JSON data object (per your specifications).
- Return that JSON document as a single response.
Our experience suggests that this second approach has numerous benefits:
- Since the data aggregation is being performed under CICS, it creates an opportunity: If there are other, non-transactional sources of data that you would like to include in the JSON document, you certainly can. Perhaps there are some fields in a VSAM file that are important but not available via the CICS transaction screens. The getPart script could read such a VSAM file directly and incorporate fields into the JSON document.
- Depending on your new target database, it is certainly within reason that you can format the JSON document emitted by the getPart script to load DIRECTLY into the new target database. Even if it’s not possible to format the JSON document for compatibility with the target database, there are many JSON transformation tools on the market. Thus, a JSON document with all the data is a much better starting point than a folder full of XML documents.
- Since you would not be using the 1:1 approach, you don’t have to write a program(s) for the distributed side that will: (a) walk through all the transactions required to extract all CICS data for a single person, and (b) consolidate all the XML docs into a consolidated view of the person.
- It’s easier to conceive of a phased implementation plan (where a clean cut over is not possible or desirable). Imagine that there was one department who still needed to use the current CICS apps for a period of time. Provided you knew the PID of the record(s) they updated, all you would need to do is run getPart for those PIDs and re-acquire the data.
- While this may be overkill for some situations, it is also possible to go one step further: Depending on the version of CICS you are running, it may be possible to position a bit of code under CICS that will automatically send a notification to the distributed system when someone has used the existing CICS transactions to update a part. That notification could prompt the distributed system to run the getPart service to obtain a fresh copy of the data for that part. Again, automated mechanisms like these are for those situations where a clean cutover is not possible or desirable.
While HostBridge is a strong supporter of the IBM mainframe platform, we certainly understand that organizations do migrate applications off the mainframe. And, when migrating applications off the mainframe, HostBridge provides multiple approaches that are fast and easy to develop, and which result in durable, high-performing integrations because they do not rely on screen scraping technology. Whether the integration need is short-term and tactical, or long-term and strategic, there is a HostBridge license that will accommodate the full spectrum of usage described in this post. To learn more about how HostBridge or evaluate it for your project, contact us.