Remote Task Information (or Transaction life mapping) feature in TXSeries : What is it?
namasevi 110000PUWU Visits (877)
Well, if you have been using TXSeries for Multiplatforms (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
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 of data across various regions becomes important.
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.
TXSeries library @ http