This page explains the case when the transaction is flagged as MODIFIED in the evolution node, while there is no change in the analyzed code source.

Technically, transaction status is based on the transaction checksum. In a given snapshot, if a transaction has a different checksum than in the previous snapshot, then it is considered as MODIFIED. Transaction checksum is calculated based on the checksums of the objects inside the transaction.

For more information on checksum value, refer to the following page SQL Queries - CAST Central Base - Queries on objects - How to get the Checksum value of an object

Step by Step scenario

1. Run at least 2 snapsots
2. Connect to TCC
3. Observe the variation

Action Plan

1. Check if the Transaction is a root Transaction of merged Transactions. For this, run the query from the page SQL Queries - CAST Knowledge Base - Queries on Transactions - How to get the Merged object of a Main object in a Transaction Merge on the current run.

   1. If the query returns rows in the current run but not the previous one, then the Transaction is merged as a root Transaction with another one in the current run but not in the previous run. The query provides you the name of the Transaction merged with the MODIFIED one. and this eplain why you are getting a MODIFIED Transaction.

   2. If the query does not returns rows in the current nor in the previous run then the Transaction is not merged as a root transaction in the current nor the previous run.
   3. If the query returns rows in the previous run but not the current one, then Transaction could not be MODIFIED.
      
2. Read the status in the TF of all the objects that compose the transaction from the snapshot where the transaction is MODIFIED
   Figure 1
   
3. If the status in the TF of at least one object of the transaction is ADDED or DELETED or MODIFIED, then this explain why the Transaction is MODIFIED, follow steps below to understand why the status in the TF of objects is ADDED or DELETED or MODIFIED:
   
   1. Read the object status itself
   2. If the object status itself  is UNCHANGED:
      This means that the object is part of the application but not part of the transaction
      1. Check if the object have the Role "FULL_GRAPH_OBJECT":
         Figure 2
         If the object have the Role "FULL_GRAPH_OBJECT", then check if there is a change in the measurement mode between the snapshots from where you are observing the status variation:
         Figure 3
         If the mode have changed from EFP mode to AEP mode or vice versa, then this is expected. In fact AEP-EFP snapshots are not comparable with each other. when you plan to change the measurement mode, it is necessary to recreate a new baseline snapshot. So, after you change the measure you must generate a new snapshot for the same Application version but it must not be considered as consistent for the new measure. The next snapshot you generate for the Application will be consistent and can be used as the first snapshot using the new enhancement measure. For more detailed explanation refer to Transitioning from EFP to AEP.
         
         
      2. If the object do not have the Role "FULL_GRAPH_OBJECT":
         here we are probably facing an issue of "nude" object (From current run or previous run). In what follows, we will define the "nude" object, explain the reason to get a "nude object", then we will provide the methodology of identifying the "nude" object.
      • Definition of "nude" object:
        In order to easlly explain this, we take the following sample:
        Let us consider that the transaction was having the following Call graph in the previous run:
        Figure 4
        The object "L22" will be "nude" object if the Entry point "L0" cannot reach the End point "L4" by way of the branch "L0"→ "L12"→ "L22" → "L32" → ""L4
        
        
      • How can this be possible?
        The path from "L0" to "L4" will be truncated by way of the branch "L0"→ "L12"→ "L22" → "L32" → ""L4, in one of the following cases:
        • Object "L12" or "L32" are deleted between the 2 runs
        • Link "L0"→ "L12" or "L12"→ "L22" or "L22"→ "L32", or  "L32"→ "L4" are deleted between the 2 runs
          Figure 6
        • How to identify the nude object?
          
        1. 1. Open TCC with current run and previous run
           2. View the full call graph of the Transaction from the current and previous run
           3. Identify The Missing path by comparing the 2 full call graphs
           4. If we take as example the illustration above the call graphs will be as follows:
              Figure 7
           5. Open Enlighten with the knowledge base from where the path is missing from the call graph
           6. Try to trace the missing path:
              
              1. Place the object corresponding to the entry point in the Graphical View
              2. Add Linked Objects of the object corresponding to the entry point as seen in the full call graph of TCC
              3. Place the objects corresponding to the linked objects in the Graphical View
              4. Add Linked Objects of the linked objects as seen in the full call graph of TCC
              5. Do point c and d until:
              1. 1. You are not able to trace the Transaction because of missing link then refer to CMS Snapshot Analysis - Run Analyzer - Missing or Wrong links between two objects
                 2. Or you are not able to trace the Transaction because of missing objects then refer to CMS Snapshot Analysis - Run Analyzer - Missing objects
                 3. Or you are able to trace the missing path then refer to Transaction Configuration Center - AFP Calibration - Transactional Functions - Missing Links
   3. if the object status itself  is DELETED:
      This means that the status of the object itself is deleted from the last snapshot, investigate the root cause of the missing object from the current run by referring to CAST Engineering Dashboard - Object - Missing objects
   4. if the object status itself  is ADDED:
      This means that the status of the object itself is added to the last snapshot,
      1. If this is a migration case going from a version below CAST 8.3.9 to a version at 8.3.9 or above, then it can be expected behavior as it is now expected to get objects which do not belong internally to the module in the call graph due to the improvement done in 8.3.9.  Confirm this be investigating if the object was present in the previous run in the knowledge base but has just been added to the central in the current migration run, and if it was not associated with a module in both the previous and current runs.    The following can assist with this task:
         1.  SQL Queries - CAST Knowledge Base - Queries on Module - How to check if an object is part of any module
         2. SQL Queries - CAST Knowledge Base - Queries on objects - How to get the ID of an object from its object name or full name
         3. SQL Queries - CAST Central Base - Queries on Objects - How to check if an object is modified between two snapshots
      2. Otherwise, investigate the root cause of the missing object from the previous run by referring to CAST Engineering Dashboard - Object - Missing objects

   5. if the object status itself  is both ADDED AND DELETED:This means that the object was considered changed between the current and previous snapshot.  Investigate the root cause by referring to:  CAST Engineering Dashboard - Object - Incorrect Object Status - Same object seen as added deleted

   6. if the object status itself  is MODIFIED:
      This means that the status of the object itself is MODIFIED, CAST AIP determines whether an object has changed between successive snapshots by comparing the checksum value of the object between the successive snapshots,run the following query in order to check this (All the information needed to compute the query can be retrieved from the TCC GUI, refer to screenshot above or TCC - Enhancement node - Right hand panel): SQL Queries - CAST Central Base - Queries on Objects - How to check if an object is modified between two snapshots

      If the checksum is the same between the 2 snapshots then contact CAST Technical Support with the following Relevant input. Else, as the checksum is computed in analysis step, we need to compare the checksum of the object between the 2 runs. For this run the following query (note that the query runs on the current central base, the current local base and the previous local base)  - SQL Queries - CAST Central Base - Queries on Objects - How to check if an object is modified between two snapshots due to analyzer

      If the checksum is the same between the 2 snapshots then contact CAST Technical Support with the following Relevant input. Else this means that Checksum of the object have changed between the 2 runs during Analysis step, please refer to the following pages: CMS Snapshot Analysis - Run Analyzer and CAST Engineering Dashboard - Object - Incorrect Object Status

4. If the status in the TF of all the objects of the transaction are UNCHANGED:
   1. Read the object status itself of objects:
      1. If the status of the objects itself are UNCHANGED:
         1. Check if the object have the Role "FULL_GRAPH_OBJECT":
            Figure 8
            If the object have the Role "FULL_GRAPH_OBJECT", then check if there is a change in the measurement mode between the snapshots from where you are observing the status variation:
            Figure 9
            If the mode have changed from EFP mode to AEP mode or vice verca, then this is expected. In fact AEP-EFP snapshots are not comparable with each other. When you plan to change the measurement mode, it is necessary to recreate a new baseline snapshot. So, after you change the measure you must generate a new snapshot for the same Application version but it must not be considered as consistent for the new measure. The next snapshot you generate for the Application will be consistent and can be used as the first snapshot using the new enhancement measure. For more detailed explanation refer to Transitioning from EFP to AEP.
         2. If the object do not have the Role "FULL_GRAPH_OBJECT":
            As we have said in the description, transaction checksum is calculated based on the checksums of the objects inside the transaction, so it's not normal to get MODIFIED Transaction while all the objects have the status unchanged inside the Transaction. However, there is a functionality in TCC that forces the transaction checksum calculation to ignore the checksum of objects (we don't ignore the object itself but the checksums of this object), this functionality is Exclusion
            Usually this is done to prevent certain MODIFIED objects from causing a modified transaction (somehow we may decide that the modifications of a certain object must not impact the global status of the transaction, and thus we exclude it). Therefore, if we modify the list of exclusions between two snapshots (by adding/removing excluded objects), we can expect a variation in the checksum of the transaction (some objects' checksums will be now ignored/considered in the calculation) and that may cause a different checksum in the transaction (and thus a MODIFIED status) even if all objects are UNCHANGED. 
            You can check this easlly from TCC GUI:
            Figure 10
            You are getting this incoherence, because in the previous run after manually excluding the object the Recompute checksums and snapshot statuses was not done from TCC GUI. In order to correct this Incoherence you need to Recompute checksums and snapshot statuses in the current run.
            Figure 11
      2. If the object status itself  are ADDED/DELETED/MODIFIED, contact  CAST Technical Support and provide the Relevant input
         
         

If the above steps do not resolve your issue, then contact CAST Technical Support with the following Relevant input, support will replicate the issue by performing steps given in the following page Tools - How to synchronize CAST databases triplet.