How to Trace Cross-Process Transactions

As a system administrator, your responsibilities often include monitoring systems, addressing known issues, and then triaging these issues. You trace these systems issues using CA Introscope® to find the components that caused them. To find these components, you construct filter criteria on the Transaction Trace screen. You then analyze the results to determine the problem.
ccapm105
As a system administrator, your responsibilities often include monitoring systems, addressing known issues, and then triaging these issues. You trace these systems issues using CA Introscope® to find the components that caused them. To find these components, you construct filter criteria on the Transaction Trace screen. You then analyze the results to determine the problem.
Use this scenario to guide you through the process:
How to Trace Cross-Process Transactions Gliffy 10.2
How to Trace Cross-Process Transactions Gliffy 10.2
Running a transaction trace can have a negative impact on the performance of the monitored application.
Completing this process lets you understand which filters criteria to select to find the problematic components and how to analyze the results.
Enable Cross-Process Transaction Tracing
The
CA Cross-Enterprise Application Performance Management
(CA Cross-Enterprise APM) component provides transaction tracing across the multiple tiers of an application that invokes transactions on the mainframe. The currently supported communications methods available out of the box are:
  • CICS Transaction Gateway using Channels invoking the CICS transactions
  • HTTP invocations from Java applications that extend HttpURLConnection which invoke CICS transactions
  • HTTP invocations from Java applications that extend HttpURLConnection which invoke Java servlet applications extending HttpServlet
  • Web Services Calls into CICS
  • WebSphere MQ Series messages sent to CICS or IMS transactions which the mainframe transaction retrieves using function MQget()
When properly configured, traces can be generated from all instrumented tiers of an application. These traces are then shown in the Workstation together in the Trace View tab. The Trace View tab is accessible from the Transaction Trace Viewer launched during a Transaction Trace session. The Trace View tab is also accessible from the Agents tab of the Cross-Enterprise APM agent in the Investigator.
The Workstation can correlate the separate traces that run together into one view through a correlation ID. This correlation ID is generated in the first tier of the application. The ID is then passed to the agents instrumenting transactions invoked on subsequent tiers using the supported communications methods. For this process to work, each tier must be instrumented and every used communications method must be supported and instrumented.
To instrument the application tiers for the communications methods, ensure that you have installed and enabled the CA Application Performance Management (CA APM) Java agent components.
Select Event Duration and Type Filters
In the CA Introscope Workstation, select the event duration and type transaction filters to construct your trace filter criteria.
  • Event duration
    Allows you to select the minimum amount of time an event runs before it is added to the trace results.
    Filtered Property:
    The Event duration filter does
    not
    use a property but is instead applied against the duration of the transaction.
    Value:
    Minimum duration of the transaction in milliseconds
    Supported Trace Sources:
    Web Services, CTG or MQ front-end, and CICS or IMS back-end traces
    Note:
    The minimum granularity for the duration filter is one millisecond. This duration can be longer than the typical back-end z/OS transaction runs. To get the microsecond duration filter granularity on back-end transactions, omit this filter and use the Microsecond Lifetime filter instead. If you use the Microsecond Lifetime filter, the Workstation does
    not
    receive transaction traces from the front-end distributed tiers of the application. Run multiple transaction traces in parallel to get the traces you want from the different tiers.
    A duration filter that is applied to a front-end agent causes all transaction correlated to any front-end transaction to be returned from the Cross-Enterprise APM Agent or any other back-end agent. This behavior can have a substantial negative impact on the performance. Applying this filter to a subset of available front-end agents mitigates the performance degradation.
  • Type Transaction Filters
    Allows you to select the transaction filters types including user ID, URL, URL Query, header, parameters, and session attributes.
    Note:
    If you want to correlate traces across the tiers, match at least one trace session to transactions running on your front-end tier. Ensure that all filters include the transactions that you are interested in generating traces from on the front-end tier of your application. If the agent decides to generate a trace on the front-end tier, it communicates with the back-end agents. This communication informs them to propagate this decision and generate correlated traces on the other tiers. A propagation flag is passed using the instrumented communication method that informs downstream agents of this decision.
Follow these steps
:
  1. Log in to the CA Introscope Workstation.
  2. Select Workstation and then New Transaction Trace Session.
  3. Select the Minimum transaction duration check box.
  4. Enter the Minimum transaction duration value and from the drop-down list select Milliseconds or seconds.
    Specify the minimum time that a transaction is traced.
    Format:
    Numeric milliseconds or seconds.
  5. (Optional) Enter transaction filters.
    Note:
    Data is only available for use in these filters if the CA Introscope Agent is configured to capture it.
    Click the check box, and select
    one
    of the following filter criteria:
    • User ID
      Select user ID from the drop-down list and enter the user ID value.
      Filtered Property:
      user ID
      Value
      : User ID property of the transaction trace (that is, the user ID that ran the transaction)
      Supported Trace Sources:
      IMS back-end only
      Note:
      Data is only available for use in these filters if the CA Introscope Agent is configured to capture it.
    • URL
      Select URL from the drop-down list and enter the URL.
      Value:
      The portion of the URL that is passed through to the servlet or JSP.
      Supported Trace Sources:
      Not applicable to any trace source. Entering a value for this filter results in no trace results.
      Format:
      Remove the leading protocol specifier, computer name, and port number.
      Example:
      /ExampleAppClientV6Web
    • URL Query
      Select URL Query from the drop-down list and enter the URL.
      Value:
      The portion of the URL that specifies query parameters in the HTTP request.
      Supported Trace Sources:
      Not
      applicable to any trace source. Entering a value for this filter results in no trace results.
      Format:
      Remove the leading protocol specifier, computer name, and port number.
      Example:
      /ExampleAppClientV6Web
    • Request Header
      Enter Request Header from the drop-down list and enter the request header value.
      Value:
      The HTTP request header.
      Supported Trace Sources:
      Not
      applicable to any trace source. Entering a value for this filter results in no trace results.
    • Request Parameter
      Enter Request Parameter from the drop-down list and enter the request parameter value.
      Supported Trace Sources:
      Not
      applicable to any trace source. Entering a value for this filter results in no trace results.
    • Session Attribute
      Enter a session attribute from the drop-down list and enter the session attribute.
      Value:
      Your session information that consists of a name and value.
      Supported Trace Sources:
      Not
      applicable to any trace source. Entering a value for this filter results in no trace results.
  6. (Optional) Enter conditional error-matching-processing Boolean filters.
These transaction filters can negatively affect the performance.
The event duration and type filters are set. Proceed to selecting the CICS or IMS filters.
Select CICS or IMS Filters
After entering the event duration and type filters on the Transaction Trace screen, enter the CICS or IMS filter criteria. You can skip this step if you do
not
want to restrict the trace generation to the mainframe system. If you want to generate traces from the front end distributed tiers, it is best to skip this step.
Note
: The CICS and IMS filters are mutually exclusive.
Select the check box, and enter the value for each filter as needed.
  • CICS server name (CTG) equals
    Filtered Property:
    Job Name or Server Name
    Supported Trace Sources:
    CICS back-end traces that were invoked using CTG.
    Value:
    The name of the server that was used to invoke the CTG call.
  • CICS/IMS communication method equals
    Filtered Property:
    Communication Method
    Supported Trace Sources:
    CICS or IMS back end
    Value:
    Cross-process tracing is available for the front-end application that invokes the transaction through the following communication CICS or IMS methods.
    Enter
    one
    of these methods:
    • CICS methods
      • Web Service
        The web services CA SYSVIEW® Performance Management (CA SYSVIEW) tracer is installed on top of the Service-Oriented Architecture (SOA) tracer. A correlation ID with the front-end transaction trace enables matchup with the corresponding back-end trace from the mainframe.
        Recommend filter criteria:
        Select the minimum transaction duration, enter a numeric value, and then select a duration unit from the drop-down list.
        Example:
        5000 milliseconds
        (Optional) Select URL of the application from the drop-down list and enter the URL.
        Note:
        Remove the leading protocol specifier, computer name, and port number.
        Example URL:
        /ExampleAppClientV6Web
      • CTG Channel
        The CTG CA SYSVIEW tracer includes a correlation ID with the front-end transaction trace that can be associated with the corresponding mainframe back-end trace.
        Recommend filter criteria:
        Select the minimum transaction duration, enter a numeric value, and then select a duration unit from the drop-down list.
        (Optional) For CTG front-end traces with the Program Name and Transaction Name properties, select CICS Program Name (CTG) equals, and enter the program name or transaction name.
        Note:
        CTG front-end traces never have server name, web service name, or microsecond lifetime properties. If these properties are entered in the filter criteria, no front-end traces appear in the Trace Viewer.
      • MQ Trigger Message
        The traces into the MQ Series do
        not
        use correlation IDs. The front-end and back-end correlation cannot be made using this correlation ID. Instead, the correlation is done using a preexisting MQ message ID and MQ correlation ID.
        Recommend filter criteria:
        Select the minimum transaction duration, enter a numeric value, and then select a duration unit from the drop-down list.
        This filter restricts the display to those transactions that run longer than the specified time.
        Example:
        5000 milliseconds
        Note:
        The IBM WebSphere MQ Connectors and Messaging System Extension tracer is used as the MQ series front-end tracer.
      • HTTP
        The HTTP CA SYSVIEW tracer includes a correlation ID with the front-end transaction trace that can be associated with the corresponding mainframe back-end trace.
        Recommend filter criteria:
        Select the minimum transaction duration, enter a numeric value, and then select a duration unit from the drop-down list.
        Example:
        5000 milliseconds
        (Optional) Select CICS/IMS Communication Method equals HTTP.
        (Optional) Select URL of the application from the drop-down list and enter the URL. Be careful when using the URL because it is specific to the tier being traced. If used, set the URL of the servlet of first tier of the application that has an installed HTTP tracer.
        Note:
        Remove the leading protocol specifier, computer name, and port number from any URL.
        Example Servlet URL:
        /HTTPTest/servlet/FrontEndClient
        Example CICS URL:
        /CICS/CWBA/DFJ$JWB1
    • IMS methods
      • MQ IMS Bridge
        The front-end application used the IMS Bridge Queue to invoke the IMS transaction.
      • MQ IMS Adapter.
        The MQ IMS Adapter was used to get the MQ message that was sent from the front-end application.
  • CICS program name (CTG) equals
    Filtered Property:
    Program Name
    Supported Trace Sources:
    CTG front end; CICS back end
    Value:
    The name of the program that was executed on the CICS region.
  • IMS transaction ID equals
    Filtered Property:
    Transaction ID
    Supported Trace Sources:
    IMS back-end
    Value:
    The transaction name.
  • IMS job name equals
    Filtered Property:
    Job Name (Dependent Region)
    Supported Trace Sources:
    IMS back-end
    Value:
    IMS-dependent region job name that processed the transaction.
  • CICS web service name equals
    Filtered Property
    : Web Service Name
    Supported Trace Sources:
    Web Services front end; CICS back end
    Value:
    Name of the web service that is used to execute this transaction. This property is applicable only to web service transaction tracers.
  • CICS/IMS transaction lifetime lasting longer than
    Filtered Property:
    Microsecond Lifetime
    Supported Trace Sources:
    CICS or IMS back end
    Value:
    The transaction lifetime in microseconds
    Minimum value:
    One microsecond
  • CICS/IMS transaction processor name equals
    Filtered Property:
    Transaction Processor
    Supported Trace Sources:
    CICS or IMS back end
    Value:
    The transaction processor that ran the transaction, CICS or IMS
  • IMS PSB name equals
    Filtered Property:
    PSB Name
    Supported Trace Sources:
    IMS back end
    Value:
    The PSB name that is associated with the transaction.
  • CICS transaction name (CTG) equals
    Filtered Property:
    Transaction Name
    Supported Trace Sources:
    CTG front end; CICS back end
    Value:
    Name of the transaction on the CICS region.
The CICS/IMS filters are set. Proceed to setting the trace duration and agents filters.
Select Trace Duration, Agent Filters, and Start Trace
After you enter the CICS or IMS filters on the Transaction Trace screen, enter the trace duration and agent filters. At the end of this procedure, start the trace.
  • Trace Duration
    Allows you to set the maximum time in minutes a trace session can take.
  • Agent Filters
    Allows you to select the agent you want to trace.
    You can apply different filters to the front-end application transactions, and the back-end z/OS transactions. In this case one or more transaction traces can be run simultaneously where each selects different agents. For example, use a duration filter on the front-end traces, while using the Microsecond Lifetime filter on the back-end traces.
Follow these steps
:
  1. Enter the trace session duration in minutes.
    Values:
    Numeric
  2. Click either the Trace all supported Agents or Trace Selected Agents check box.
    • Trace all supported Agents
      Traces supported agents that are currently connected, and any that connect during the Trace session.
    • Trace selected Agents
      Select the agents from the list. Use CTRL + click to select multiple agents.
  3. Click OK to start the Transaction Trace session.
    The Transaction Trace Viewer opens.
You have now set the filter criteria for:
  • Event duration
  • Type
  • CICS or IMS
  • Trace Duration
  • Agents
Narrow Trace by Excluding Front-End Elements
You can exclude front-end elements from the trace by selecting options on the New Transaction Trace session.
To exclude front-end traces
  1. Create a transaction trace session.
  2. Click the following check boxes and enter the value for each filter.
    • CICS/IMS transaction lifetime lasting longer than
    • CICS transaction name (CTG) equals
    • CICS server name (CTG) equals
    • CICS program name (CTG) equals
  3. Enter any other needed information and click OK.
To return CTG front-end traces
  1. Create a transaction trace session.
  2. Click the following check boxes and enter the value for each filter.
    • CICS/IMS transaction name (CTG) equals
    • CICS program name (CTG) equals
  3. Enter any other needed information and click OK.
To exclude CTG front-end traces
  1. Create a transaction trace session.
  2. Click the following check boxes and enter the value for each filter.
    • CICS/IMS transaction lifetime lasting longer than
    • CICS web service name equals
    • CICS server name (CTG) equals
  3. Enter any other needed information and click OK.
To exclude HTTP front-end traces
  1. Create a transaction trace session.
  2. Click the following check boxes and enter the value for each filter.
    • CICS/IMS transaction lifetime lasting longer than
    • CICS/IMS Communication Method equals
    • CICS server name (CTG) equals
    • CICS program name (CTG) equals
  3. Enter any other needed information and click OK.
To exclude MQ front-end traces
  1. Create a transaction trace session.
  2. Click the following check boxes and enter the value for each filter.
    • CICS/IMS transaction lifetime lasting longer than
    • CICS transaction name (CTG) equals
    • CICS server name (CTG) equals
    • CICS web service name equals
    • CICS program name (CTG) equals
  3. Enter any other needed information and click OK.
Analyze Trace Results
Use the information in this section to understand your trace results.
Change Duration Time Intervals
Set the display units that are used for duration and call time by right-clicking the Duration column header on the Transaction Trace Viewer window. Select
one
the following units from the drop-down list:
  • Microseconds
  • Milliseconds
  • Seconds
Cross-Process Traces Time Alignment
Time alignments between system clocks in a cross-process trace often are
not
synchronized. Cross-process traces align the trace with the front-end trace that invoked it.
Note:
Usually traces display in an order that is based on the system clock where they originated. All back-end traces that are sourced from the same Cross-Enterprise APM agent can be synchronized properly relative to each other but
not
the correlated front-end transaction.
  • CTG and web services
    CTG and web services calls are not displayed relative to their actual synchronization with the front end calling transaction. The associated events for these back-end traces are group together, enlarged, and aligned to the left in the Trace View.
  • MQ calls
    MQ calls are asynchronous and occur after the front-end application terminates. The delay is shown regardless of discrepancies that clock synchronization introduces. In the Trace View, these events are not aligned, enlarged, or grouped.
  • IMS transaction trace timestamp
    The IMS transaction trace timestamp starts when the transaction is placed on the input queue.
    When searching for the corresponding IMS SMF record for a transaction trace, always use the Unit of Work ID from the trace and the command:
    IMSTLOG UOW <value_of_Unit_of_Work_ID>;
    Do
    not
    use the timestamp from the IMS transaction trace in the Workstation to find the corresponding IMS SMF record in CA SYSVIEW. The IMS SMF record time shows process start time instead. For the transactions that stay on the input queue for a long time, these two values can differ significantly.
About Transaction Trace View
You could organize the information in one of two ways here.
The Transaction Trace View consists of top and bottom panes that help you analyze your trace results. The top pane contains all the transaction trace events that are selected from the filter criteria. The bottom pane contains a set of views that let you view the transaction trace results in different ways.
Summary View
The Summary View shows metrics for the components in the selected transaction, such as:
  • Path
  • Number of calls
  • Length of the call in milliseconds
  • Minimum, average and maximum call times
The Call Time (ms) column is the duration that is spent in the component. The duration excludes any time that is spent in any child components.
Note:
The first time that you select a transaction in the transaction table, the Summary View opens. When you select a previously opened transaction, it opens in the most recently selected view.
This information appears for the currently selected transaction:
  • Fully qualified agent name
  • Start time, in the agent computer system clock, of the invocation of the root component
  • Execution time of the root component in milliseconds
Trace View
The Trace View shows the selected transaction trace in a graphical stack display. To expand and collapse the stack of components, click the triangular arrow to the left of a transaction. When you select
one
of the components of a transaction, you can see component details in the bottom pane. The details include any properties from the component. Most properties are located in at the top component of the stack, however subcomponents can also contain properties.
In addition to the selected transaction trace, this view shows any correlated cross-process transaction traces. To make a trace the focus and investigate its components further, click the trace. For more information, see Trace and Analyze Events.
The transaction traces generated from front-end agents where the CTG CA SYSVIEW Tracer is installed have options that allow the launching of a back-end trace session. For more information about launching a back-end trace, see Launch a New Back-End Transaction Trace Session from an Existing One.
Tree View
The Tree View is a hierarchical view of the components of the currently selected transaction trace. Each component represents a Java method or mainframe timing that the transaction completed. A component shows its duration and a percent of the total transaction lifetime that that duration represents.
The front-end traces that are generated from an instrumented Java application have the usual components that represent methods in the Java call stack. To drill down to the methods that invoked the back-end applications on the mainframe, expand the call stack in the tree.
Note:
For the back-end traces generated by the Cross-Enterprise APM agent on z/OS, the tree view does
not
represent an actual Java call stack. Instead, it is a set of nested timings that are taken during processing of a CICS or IMS transaction.
The hierarchical structure of the transaction traces generated when processing a CICS or an IMS transaction are as follows.
The Transaction traces consist of a series of CICS and IMS components.
CICS Transaction Traces
Provides information about how time was spent in CICS transactions. Tracing a CICS transaction can produce three types of traces:
  • CICS Suspend traces
  • CICS Programs traces, if enabled.
  • CICS DB2 trace, if enabled and the transaction invokes DB2 queries
The following property in the Cross-Enterprise_APM_Dynamic.properties file controls the generation of the CICS Programs trace:
SYSVIEW.CICS.Transaction.Trace.Programs
Additionally you can also control the maximum number of program components reported in the CICS Programs trace using the following property:
SYSVIEW.CICS.Transaction.Trace.Programs.MaxReported
The following property in the Cross-Enterprise_APM_Dynamic.properties file controls the generation of the CICS DB2 trace:
SYSVIEW.CICS.Transaction.Trace.DB2
The CICS Suspend trace has the following hierarchy of components as identified by their paths:
CICS Regions|
region
|
transaction_name
|
task_number
|Suspend|Transaction Lifetime Dispatch Time   Program Load Time  Suspend Time   <Optional suspend time components>
The CICS Programs trace has the following hierarchy of components as identified by their paths:
CICS Regions|
region
|
transaction_name
|
task_number
|Programs Program[|remote_sysid]|
program_name
The CICS DB2 trace has the following hierarchy of components as identified by their paths:
CICS Regions|
region
|
transaction_name
|
task_number
|DB2|Transaction Lifetime  Program
program_name
|SSID
ssid
|
statement_type
Stmt #
statement_number
The CICS transaction traces have the following components:
  • Transaction Lifetime
    Indicates the total time or transaction lifetime that equals the sum of input, processing, and output time.
    Note:
    For more information, see CICS Transaction Lifetime Component Properties.
  • Dispatch Time
    Is a child of a Transaction Lifetime and represents time spent dispatched and doing work. The CPU time is the portion of dispatch time when the task is using processor cycles.
    Note:
    For more information, see CICS Dispatch Time Component Properties. 
  • Program Load Time
    Is a child of Dispatch Time that shows how long the program took to load.
  • Suspend Time
    Accompanies Dispatch Time and represents time that is wasted in waiting for system resources.
    Suspend Time has extra child components representing nonoverlapping timings.
    Suspend Time also includes various overlapping timings that cannot be represented as a hierarchy. These timings are represented as properties in the lower pane of the Trace View tab.
    Zero duration time properties and components are
    not
    represented.
    Tip:
    High suspend times on a running transaction indicate an issue.
    Note:
    For more information, see CICS Suspend Time Component Properties.
IMS Transaction Trace
Specifies the information about how time was spent in an IMS transaction. Tracing an IMS transaction produces a single trace.
The IMS trace has the following hierarchy of components  (identified by their paths):
IMS Subsystems|
subsystem_name
|Transaction|
transaction_name
|Transaction Lifetime  Input Queue Time  Process Time
optional_components
 Output Queue Time
The IMS transaction trace has the following components:
    • Transaction Lifetime
      The total time or transaction lifetime equals the sum of input, processing, and output time which are its child components.
      Note:
      For more information, see IMS Transaction Lifetime Component Properties.
    • Input Queue Time
      The amount of time the input transaction waited in the message queue before being scheduled.
    • Process Time
      Process Time has extra child components representing nonoverlapping timing events. These optional components are IMS Monitor type events such as:
      • IWAIT
      • DL/1
      • External Subsystem calls that occur during the transaction lifetime
      A single optional child component that contains properties for Event Count and Maximum Event Time represent multiple events. The Event Count property indicates the number of events. The Maximum Event Time property has the duration of the slowest instance of the event.
    • Output Queue Time
      The amount of time the transaction output waited in the output message queue before being forwarded to its destination.
Sequence View
The Sequence View tab displays the caller-callee relationship between the segments of a transaction. The view makes the sequencing order of the calls visually apparent.
Use the Sequence View if any of the following conditions are true:
  • A transaction with asynchronous calls
  • Call processes running on agents that are
    not
    synchronized in time with each other
  • Complex synchronous calls across multiple JVMs or CLRs
CICS with MQ Trigger Message Example Using the Tree View
This example shows the results from the following filter selections.
  • Duration time greater than 40 microseconds
  • CICS/IMS communication method equals CICS with MQ Trigger Message
The following procedure explains how to analyze these trace results using the tree view.
Follow these steps:
  1. Click the Tree View tab in the Transaction Trace Viewer window.
    The tree structure of the web service transaction trace components appears.
  2. Highlight the transaction trace component.
    The properties that are associated with that component appear.
Web Services Example Using Large Duration Time
This example shows how to analyze a duration time using the Trace View. The duration time on the transaction trace screen was set to time greater than 5000 milliseconds.
The Transaction Trace Viewer shows a front-end task with a 5063-millisecond duration.
1868950.png
The Trace View shows that the front-end transaction calls a correlated back-end CICS transaction. The CICS transaction has a 3675-millisecond duration. Over 70 percent of the transaction time was spent waiting on completion of the CICS transaction. Most of that time was spent with the program dispatched.
1868951.png
CTG Example for High Suspend Time
This example shows how to analyze a high suspend time using the Trace and Tree Views.
The filter criteria that was used for this example was an event duration of 78. The results for this selected criteria follow.
Follow these steps
:
  1. Highlight the transaction with the high duration time.
  2. Click the Trace View.
  3. The Trace View opens displaying the correlated front end and back-end traces.
    1868972.png
    To diagnose the problem, select the Tree View tab. To see the  associated properties, highlight the transaction trace component.
    The following example shows that the CICS transaction spends 77 percent of its time suspended. The dispatch time is longer than the run time. Correct this issue.
    1869289.png
Problematic Transaction for Unit of Work
If the transaction is problematic, use the Unit of Work ID to investigate the back-end transaction using CA SYSVIEW. The CA SYSVIEW administrators can find the corresponding SMF record for this transaction using the CA SYSVIEW GUI.
The value in this field can be used to look up the associated SMF record in CA SYSVIEW.
  • For the IMS transactions:
    IMSTLOG UOW <value_of_Unit_of_Work_ID>;
  • For the CICS transactions:
    CTRANLOG; SELECT UOWID EQ <value_of_Unit_of_Work_ID>;
You can also view extra transaction trace events that show the transaction activity within the back-end system from the Workstation. These events are produced from the CA Cross-Enterprise APM agent running on the mainframe. The events are correlated with traces generated from the front-end agent.
The CICS back-end trace events provide information about the performance of transactions that run on CICS. Trace events provide the following information in the Trace Viewer to help you diagnose the problem:
  • Transaction name
  • Transaction lifetime
  • CPU time
  • Suspend time
  • Dispatch time
The IMS back-end trace events provide information about the performance of transactions that run on IMS. Trace events provide the following information in the Trace Viewer to help you diagnose the problem.
Launch a New Back-End Transaction Trace Session from an Existing One
Correlating front-end and back-end traces can be challenging when the filter is
not
narrowed to include fewer traces. When there is a heavy volume of traces, you can launch a new transaction trace session from an existing one. This launch creates a back-end transaction trace session from the selected web service or CTG front-end transaction trace, and makes correlation more likely.
Follow these steps
:
  1. Click the problematic web service or CTG front-end transaction trace, on the Transaction Trace Viewer.
  2. Highlight the last item on the Trace View tab, right-click, and select Launch New Trace from the pop-up menu.
    A New Transaction Trace Session window opens with populated fields from the front-end trace.
  3. Click OK to view transactions that meet the specified criteria in the Transaction Trace Viewer window:
    1425161.jpg
    The returned trace is the correlated front-end and back-end trace.