IMS Connect Extensions V3.1 (available in December 2018) offers a powerful new off-host analytics capability called the IMS Connect Extensions feed. The “feed” allows you to forward IMS Connect transaction performance and summary data to an analytics platform of your choice. To demonstrate the utility of this data feed for monitoring, analyzing, and understanding the nature of the OTMA workloads that pass through your IMS Connect systems, the IMS Connect Extensions team has created the IMS Connect transaction analysis app for Splunk. This Splunk app gives you five dashboards that report on several different aspects of IMS Connect. The dashboards can be used “as-is” or as a basis for your own customizations.

Setting up your PC for a walkthrough of the dashboards (no mainframe required)

In this article, we’ll give you a walkthrough of each dashboard in the app. To follow along,simply download our free Docker image – no mainframe is required, simply run it on your PC. The Docker image contains everything you need to try the dashboards: Splunk, our Splunk app, and sample data generated by the IMS Connect Extensions feed. Of course, if you’d like to see your own data in the app, you can always go the extra step of setting up the IMS Connect Extensions feed.

A walk amongst the dashboards

The IMS Connect transaction analysis Splunk app comes with the following fully-functional sample dashboards for you to try. As you experiment with the dashboards, keep in mind that Splunk allows you to customize and create your own dashboards – if you see something you want to change, or you want to correlate the data supplied by IMS Connect Extensions with data from other products, you can easily do that within Splunk.

Overview dashboard

The Overview dashboard provides a transaction performance summary for OTMA-based workloads that pass through IMS Connect. To do this, select the time range you are interested in, and then select an identifier. The Identifier dropdown on this dashboard lets you choose the performance aspect in which you are interested. You can, for example, view transaction performance broken down by:

  • Transaction code
  • IMS Connect system. Useful if you have multiple IMS Connect systems and you want to see which IMS Connect system processed a request or to see which systems are “working harder” than others.
  • IMS Connect port number
  • Read exit name
  • Client IP address
  • Client ID or User ID (as specified in the IRM or generated by the user exit)
  • IMS data store ID. Use “IMS data store (original)” to see the DATASTORE connection ID requested by the client. Use “IMS data store (target)” to see the DATASTORE connection ID that was actually used – useful when IMS Connect Extensions rules-based routing is in effect.
  • IMS Tmember name (the IMS system that processed the transaction)
  • IMS transaction pipe (Tpipe) name
IMS Connect overview dashboard

As you play with this dashboard, you’ll notice the following things:

  1. Selecting IMS Connect system in the Identifier field reveals that we have two IMS Connect systems in our environment (ICOND01 and ICOND02). ICOND01 has processed a slightly higher number of transactions than ICOND02.
  2. Selecting Tmember shows us how many IMS systems are involved. Here we have four: XCFMIFDA, XCFMIFDB, XCFMIEDA, and XCFMIEDB.
  3. Selecting IMS data store (target) gives us the names of the physical DATASTORE connections between IMS Connect and IMS. Here we can see eight DATASTORE connections were used: D1FA, D2FA, D1EA, D1FB, D2FB, D2EA, D2EB, and D1EB.
  4. Selecting IMS data store (original) reveals the names of the IMS data stores requested by TCP/IP clients. Note that they are different to the DATASTORE connections we saw above. This is because in this environment, our clients are sending “virtual” destination IDs that are then remapped to physical DATASTORE connections using IMS Connect Extensions routing rules. Here we can see there were more requests for virtual destination IMOB (mobile) than IWEB (web) or IBUS (internal business). The Transaction rate chart shows the rate at which requests were received over the designated time period.
  5. Now, switch back to IMS data store (target) and wait for the Transaction rate chart to reload. Note the period of time in the center of the chart where processing stopped on four of the DATASTORE connections and the transaction count dropped to zero. During this period, the IMS administrator performed a data store drain and suspended routing on those data stores. Note also how the transaction count rose on the remaining data stores to compensate for the suspended connections.
  6. Switch again to Tmember. You’ll see the same drop in processing on the Transaction rate chart. During this period, two IMS systems were processing whilst the other two were idle (or were taken offline for maintenance).

* Note that on the Overview dashboard, only the Top 10 values are shown

Workload distribution dashboard

The Workload distribution dashboard shows the distribution of transaction counts. Use this dashboard to see how requests coming from TCP/IP clients (such as z/OS Connect, WebSphere, and others) are distributed across IMS Connect systems and physical DATASTORE connections to IMS.

This dashboard contains a time-based line chart of transaction rates and a Sankey chart that shows the flow of transactions through different IMS Connect systems, target IMS data stores, and IMS systems.

IMS Connect workload distribution dashboard sankey

As you play with this dashboard, you’ll notice the following things:

  1. You can use the Identifier dropdown to reveal different aspects of the transaction flow and to change the starting element of the Sankey diagram. Selecting IMS data store (original) will show you how IMS Connect Extensions routing has remapped and rebalanced the workload coming into IMS Connect so that it is shared evenly across IMS systems. Here, we see how the requests for three original IMS data stores (IMOB, IBUS, and IWEB) are processed by two IMS Connect systems (ICOND01 and ICOND02, routed to several different target data stores (D1EA, D1EB, etc.), and then processed by four IMS systems (XCFMIEDA, XCFMIEDB,..). The Sankey layout shows you the topology of your IMS Connect environment. Note also the width of the ribbons. See how there were more requests for IMOB than IBUS or IWEB? Notice also how if we follow this diagram from left to right, we can see how the imbalance has been corrected, first by even distribution to IMS Connect systems, and then by even distribution across DATASTORE connections so that the IMS systems all receive a near-equal share of the work.
  2. You can limit the Sankey chart to one or more identifier values, to show a more focused view of the transaction flow. To do this, enter one or more values into the box next to the Identifier dropdown. For example, remove Select All and enter IMOB to show only the activity for TCP/IP requests that specify IMOB as its virtual destination.

For another example of how this Sankey diagram looks when routing to a fallback IMS, watch the IBM Z YouTube video Routing OTMA workload to a fallback IMS with IMS Connect.

Workload mapping dashboard

The Workload mapping dashboard shows the relationship between two identifiers.

As you play with this dashboard, you’ll notice the following things:

  1. Selecting IMS data store (original) and IMS data store (target) highlights the way IMS Connect Extensions rules-based routing has been configured. Here you can see how the destinations requested by the client have been mapped to physical DATASTORE connections to IMS.
  2. Selecting IMS data store (original) and Tmember reveals the DATASTORE configuration across your IMS Connect environment.
  3. Selecting IP address and IMS data store (original) shows you which IP addresses are the most active and the (virtual) data stores they are requesting.

Performance comparison dashboard

The Performance comparison dashboard shows transaction rates and average elapsed time components.

As you play with this dashboard, you’ll notice the following things:

  1. Selecting Transaction code from the Identifier dropdown reveals the transaction rates of each transaction code, which transaction code has the highest transaction count, and which transaction code has the highest average response time. In this example, JLMTRAN1 is used far more than the other transaction codes.
  2. Select Tmember to compare the performance of your IMS systems. Scrolling down, you can see transactions per day for each IMS, average elapsed times broken down by response time, input elapsed time, OTMA elapsed time, and output elapsed time.

Elapsed time components dashboard

The Elapsed time components dashboard is for detailed analysis of transaction performance. To use this dashboard, you need to select both an identifier and a specific value for that identifier. In addition to showing charts of various elapsed time components, this dashboard contains a table of individual transaction instances.

IMS Connect elapsed time components

To understand more about how elapsed times are calculated, watch the IBM Z YouTube video Analyzing elapsed time in IMS Connect OTMA transactions.

As you play with this dashboard, you’ll notice the following things:

  1. Selecting IMS Connect ICOND02 shows the transaction rate for ICOND02. Scrolling down to the Transaction elapsed time components, you can see there are spikes in response time. OTMA elapsed time has increased, whilst input and output elapsed time has remained steady.
  2. Dragging the mouse from the start of a spike to its end will zoom in on the selected time range. Now the spike becomes clearer. Scroll down to the smaller charts that break down the response time into input elapsed time, SAF elapsed time, OTMA elapsed time, and others. You’ll notice that some of these charts contain the same spike and others do not. This gives you an indication of where a problem may have occurred. For example, if you see a spike in Elapsed time waiting for client, it means that the client acknowledgement took longer than usual. If you see a spike in OTMA elapsed time, there might be a delay in IMS that needs investigating.
  3. Scrolling to the bottom of the dashboard will show you the individual transactions that occurred during the selected time period. Use this list to locate a transaction that caused a delay. To continue your analysis, use IMS Problem Investigator or IBM Transaction Analysis Workbench to browse the events in IMS Connect Extensions journal and IMS log. Use the Logon token field in the dashboard to find the events associated with this transaction in the journal.
IMS Connect elapsed time transactions

To understand more about the events you can see in the IMS Connect Extensions journal, watch the IBM Z YouTube video The Lifecycle of an IMS Connect Transaction.

Learn more

The IMS Tools playlist on the IBM Z YouTube channel hosts several instructional videos that show you how to get the most out of IMS Connect and IMS Connect Extensions. To learn more about the dashboards, watch the IBM Z YouTube video Analyzing IMS Connect OTMA transactions in Splunk.
If you already own IMS Connect Extensions, simply set up the IMS Connect Extensions feed to forward data from your own systems to Splunk. Visit Forwarding a live feed of IMS Connect events to Splunk for setup instructions and more. For a complete list of fields supplied in the field, visit IMS Connect Extensions feed fields in the IBM Knowledge Center.

Join The Discussion

Your email address will not be published. Required fields are marked *