Monday, September 27, 2010

Remote Task Information (or Transaction life mapping) feature in TXSeries : What is it?

Well, if you have been using TXSeries, one of the difficult problems that you would have come across is to debug transaction error scenarios that span across multiple regions. Co-relating critical data for a transaction or a task across all the involved regions is always important while debugging such scenarios. In most situations, a TXSeries setup involves multi-region setup that are all connected using inter system communication facilities (DPL, TR etc). So, if you imagine a typical setup, 3 TXSeries regions are connected with each other and workload is distributed across these three TXSeries regions using LINK command or API.
Remote task information (or also called as Transaction life mapping) feature in TXSeries 7.1 helps gather information about corresponding task in the immediate front end region and the originating region. For example, in the above figure, if you are looking for information for CPMI transaction in region “C”, you will be able to get task information about CPMI running in region “B” and information on the task T1 running in region “A”. Critical information such as, Process ID, Task ID, Program name, Terminal ID (originating terminal) and Task start time are generated. Today, this feature logs data in an extra partition TDQ under /var/cics_regions//data directory.

This was for what this feature is, now let’s just look at a few scenarios where this new feature comes in handy…
Making sense of the monitoring data…
Usually, whenever a user reports the problem of transaction response time being large (i.e slow transactions), one of the immediate request is to generate monitoring information. This information comes along with various parameters such as transactions start time, elapsed time and so on, which is quite handy in figuring out where the delay is caused. However, in the case of transactions spanning across multiple regions, just this monitoring information usually would not help. Yes, if the problem is occurring within the span of any given region, it would still be alright, but if the monitoring information does not show any apparent issue, that’s when co-relation across various regions becomes important.

The data generated by remote task information feature helps the user to understand the behavior of the transaction prior to landing into this current region. For example, using the data such as PID, TID, Transaction / task start time and so on, it’s easy to understand where the transaction spent how much time. If the transaction response within a given region is alright, the co-relation allows us to see if the delay happens to be over the network for example.

Sometimes, if all the transactions in the backend region run under the CPMI name , the remote task information comes in handy to differentiate each one of them while relating the monitoring data across regions. Typically, PID and task ID of each of those transactions can be mapped using the remote task information data for differentiation.
Task/Transaction hanging in the backend region…
On many occasions, we see transactions hanging on the backend due to some issue on the corresponding front end transaction. For example, an application server process on the front end may either have got terminated (possibly due to timeout and force-purge) or the application server process could be hanging for some reason. To be able to relate the hanging backend transaction to the front end transaction, the data generated by the remote task information can be used to identify the triggering PID and transaction ID. This co-relation can help isolate the problem to a particular region or a process. One such scenario could be, backend transaction hanging as the front end process went away due to forcepurge as a result of client timeout. Just tweaking the timeout value can solve this problem as well. Even if the problem is slightly more complex, co-relating the data can help isolate processes with hang situations and map the overall life of that transaction, thus helping understand the scenario better.

There are some more cases in which this feature can be handy. For example, one of the data that you can get to know is the terminal ID from where the transaction got initiated. This information that can help identify branches or end clients which are initiating the transactions.

Remote task information is not enabled automatically in your TXSeries 7.1 region. Parameters “EnableTaskInfo”, “SendTaskInfo” and “DumpRemoteInfo” need to be set to “yes” in the region stanza.

Overall, a very handy feature – especially for troubleshooting. This feature is currently supported with CICS_TCP and PPC_TCP protocols and across TXSeries regions running on TXSeries 7.1. Not supported with prior versions of TXSeries. Also, since the remote task information generates lots of data, you might want to use it based on the need appropriately to avoid any degradation in performance.
TXSeries library @ http://publib.boulder.ibm.com/infocenter/txformp/v7r1/index.jsp would help find more information on usage of this feature.

Do comment on the feature and let me know if any of you readers have any suggestions…

No comments:

Post a Comment