This troubleshooting describes the steps to follow when observing a global change in metric grades after migration from 7.0.x to 7.2.x or 7.3.x
Release | Yes/No |
|---|---|
| 7.3.x |  |
| 7.2.x | |
| 7.0.x |  |
RDBMS | Yes/No |
|---|---|
| Oracle Server | |
| Microsoft SQL Server | |
| CSS2 | |
| CSS1 | |
- Perform a migration from 7.0.x to 7.2.x or 7.3.x
- Observe a huge change in metric grade in the dashboard.
- #Relevant customer's input
- #Check if module content drastically change after migration
- If no change in the module content, for CAST support #Transmit the problem to R&D team else contact CAST Technical Support with input
- Sherlock, before and after migration
- LISA folder if PL/SQL analysis is part of the migrated application
- Screenshots showing issue on the dashboard
The first thing to check when their is a global change in metric grade is to check if the content of the application is the almost the same in the 2 versions. Indeed, if their is a huge change in one or several functional modules of the application, this will impact the whole dashboard results
How to check whether the module content is the same between the two version?
- In the dashboard, go to the quick access,
- Select the two latest version of the functional module
- Click on "Monitor",
- Then, expand the last section of the page "Value Comparison table" that list the "number of" in each version of you functional module to check if there is a big change in the module content. If you have several module, you will need to repeat the same operation for each module.
- If you identify one or more modules having with big changes between the two latest version. Please move to next section "Why the module content changes when migrating from 7.0 if no change has been made in the module definition?"
Why the module content changes when migrating from 7.0 if no change has been made in the module definition?
If you observe a big change in one module content. You need to first check the difference between the module subsets defined in 7.0.x and the filters generated in 7.2.x/7.3.x. For this you need to open the module definition in 7.2.x/7.3.x.
After checking the MB of 7.3.x, First check if some of object filters defined for this User Defined Module have no filters (for example here, see SUBSET_JOB#258_STRUTS_MAPPING_TO_FORWARD.bmp filter screenshot)
Because none of the filter mode is activated for this filter, it will be default contain the whole analysis results. This explains the huge difference in this module content between the two versions)
When looking at the definition of the "STRUTS_MAPPING_TO_FORWARD" tool, it only refer to a job creating a link:
Since this UI job is only creating links, after migration, it is put in the tool after analysis and there is no corresponding analysis unit created. This is why the filter is coming as empty in 7.3.1.
What does this empty filter means?
If the functional need behind adding this tool results to the module content is to include generated links to the functional module in order to ensure that links are taking into account in transactions. All links in the KB (except some internally escalated links) are taking into account by TCC when creating transaction. Hence, no need to try to add the links to the functionnal module. This issue is coming as a side effect, since we are supposed to only add objects to modules. In the same time, only jobs with analysis units generates jobs.
How to avoid this change of module content?
You should not add jobs that does not create any object to your modules. Please remove this tools results from the module definition to avoid the issue. You can either do it before or after migration (ie: remove all filters associated to this tool jobs that do not generate any object)
CALL 29395.