Transaction Configuration Center - Enhancement - Data Function - Status Variation - Data Function status is MODIFIED with unchanged source code

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

Step by Step scenario

1. Run analysis and take a snapshot.
2. Run another analysis and take another snapshot.

1. Check if the Data Function is a root Data Function of merged Data Functions in the current run and previous run. For this, run the query from the page SQL Queries - CAST Knowledge Base - Queries on Data Functions - How to get the Merged object of a Main object in a Data Function Merge  on the current run and the previous , If the query returns rows in one of the 2 runs but not the other one then it's expected to get a MODIFIED Data Function.
2. Read the Status in the DF of all the objects that compose the Data Function from the snapshot where the transaction is MODIFIED
3. If the Status in the DF of all the objects of the Data Function are UNCHANGED:
   1. Read the object status itself of objects:
      1. If the status of the objects itself are UNCHANGED:
      2. Check if the Data Function new type have not changed between the 2 runs.If it is changed then it is an expected behavior to get modified.
         
         If yes then it's expected to get a MODIFIED Data Function, this option is manually performed by the user.
      3. Check if the Data Function computed type objects have not changed between the 2 runs:
         
         If yes then check the type of the incomming links to the Data Function in the 2 runs, for this do the following:
         1. Open Enlighten with the current and previous run
         2. Put the object in the view of the current and previous run
         3. Put all the incoming links to the Data Function in the view
         4. If the computed type of the Data Function in one of the 2 runs have the type EIF (External Interface Files) but all the incoming links to the Data Function in the 2 runs are of type Update/Delete/Insert/Write links, then check the valididty of the links by following the page ENL - Link Examples:
            1. 1. If the links are valid then this is an issue of wrong Data Function type in the run from where the type is  ILF (Internal Logical File), contact CAST Technical Support and provide the Relevant input.
               2. Else if the links are invalid then this is an issue of wrong links in the run from where the incoming links to the Data Function are of type Update/Delete/Insert/Write, refer to CMS Snapshot Analysis - Run Analyzer
         5. If the computed type of the Data Function in one of the 2 runs have the type ILF (Internal Logical File) but all the incoming links to the Data Function in the 2 runs are not of type Update/Delete/Insert/Write links then. Check the valididty of the links by following the page ENL - Link Examples:
            1.  If the links are valid then this is an issue of wrong Data Function type in the run from where the type is  ILF (Internal Logical File), contact CAST Technical Support and provide the Relevant input.
               
            2. Else if the links are invalid then this is an issue of wrong links in the run from where the incoming links to the Data Function are of type Update/Delete/Insert/Write, refer to CMS Snapshot Analysis - Run Analyzer
         6. If the computed type of the Data Function in one of the 2 runs have the type  EIF (External Interface Files) knowing that all the incoming links to the Data Function in this run are of type Update/Delete/Insert/Write links, and If the computed type of the Data Function in the other run have the type ILF (Internal Logical File) knowing that all the incomming links to the Data Function in this run are not of type Update/Delete/Insert/Write then check the valididty of the links in the 2 runs by following the page ENL - Link Examples.
            
            1. If the links are valid in the 2 runs then it is expected to get a MODIFIED Data Function.
            2. Else if the links are not valid in one of the 2 runs, then refer to CMS Snapshot Analysis - Run Analyzer
      4. As we have said in the description, Data Function checksum is calculated based on the checksums of the objects inside the Data Function and the type of the Data Function, so it's not normal to get MODIFIED Data Function while all the objects have the status unchanged inside the Data Function and the type of the Data Function is unchanged between the 2 runs. However, there is a functionality in TCC that forces the Data Function 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 Data Function (somehow we may decide that the modifications of a certain object must not impact the global status of the Data Function, 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 Data Function (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:
         
         
         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.:
         
         
         If this don't resolve your issue then contact CAST Technical Support and provide the Relevant input
4. If the Status in the DF  of at least one object of the Data Function is ADDED or DELETED or MODIFIED, then this explains why the Data Function is MODIFIED, follow the steps below to understand why the Status in the DF of objects is ADDED or DELETED or MODIFIED:
   
   1. Read the object status itself
   2. 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 refering to  CAST Engineering Dashboard - Object - Missing objects
   3. if the object status itself  is ADDED:
      This means that the status of the object itself is added to the last snapshot, investigate the root cause of the missing object from the previous run by refering to CAST Engineering Dashboard - Object - Missing objects  

   4. 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 retreved 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 page CMS Snapshot Analysis - Run Analyzer

Ticket  # 7578 , #18918