CMS Snapshot Analysis - Compute Dependency Dataset - Performance issue

This page will help you to troubleshoot the performance problems you may face at the "Compute Dependency Dataset" step.

This is generally due to a big amount of objects involved in the computation of dependency dataset for external links.

Action Plan

To troubleshoot this issue, you need the following Relevant input

Perform the below actions:

1. Clean up table WORK_SELECTION If this does not solve the issue, you may proceed to step 2
2. Check the object types in table WORK_SELECTION. If the most numerous objects are CAST_COBOL_GenericData, then you might consider proceeding to step 3 Else proceed directly to step 4
3. Set the option "Data Structures" to "Don't save data"
4. Use a Refined Target to restrict the Dependency Dataset

Relevant input

• CAST Support Tool (CST) - alias Sherlock with backup of the Knowledge Base and Management Base at least, OR access to the customer server
• Source code OR access to the customer server

Step 1: Clean up table WORK_SELECTION

This table is a working table. It should always be empty between two analysis. There may be remaining objects in the table, due to an analysis crash or abnormal termination.

The consequence can be a burst of the number of objects in the Dependency Dataset, leading to a performance issue.

To clean up the table, run the following query on your Knowledge Base :

set search_path=<YOUR_KB>;
truncate table WORK_SELECTION;

Then relaunch analysis. If the performance issue is not solved, you may proceed to Step 2 -Check the object types in table WORK_SELECTION

Step 2: Check the object types in table WORK_SELECTION

Wait for the analysis to get stuck at step "Compute Dependency Dataset", then run the following query on your Knowledge Base :

set search_path=<YOUR_KB>;
 
select count(k.idkey) as count, t.*
from keys k join work_selection wk 
on k.idkey=wk.key_id
join typ t 
on t.idtyp=k.objtyp
group by k.objtyp, t.typnam, t.typdsc, t.status
order by count desc;

The results should show you a list of object types with the corresponding number of objects in table WORK_SELECTION.

6122343;831;"CAST_COBOL_GenericData";"Cobol Data";"ACTIVE    "
599209;890;"CAST_COBOL_SavedConditionalTest";"Cobol Conditional Test";"ACTIVE    "
279567;114021;"CAST_COBOL_Literal";"Cobol Literal";"ACTIVE    "
61854;809;"CAST_IMS_DatabaseProgramControlBlock";"IMS DB PCB";"ACTIVE    "
54952;151005004;"IMSDCProgram";"IMS Program";"ACTIVE    "
23684;151005005;"IMSDCTransaction";"IMS Transaction";"ACTIVE    "
22888;138832;"CAST_Oracle_TableColumn";"Oracle table column";"ACTIVE    "
18204;138315;"CAST_Oracle_CheckConstraint";"Oracle check table constraint";"ACTIVE    "
15480;102;"JV_METHOD";"Java Method";"ACTIVE    "
10760;103;"JV_FIELD";"Java Field";"ACTIVE    "
...

If the most numerous objects are CAST_COBOL_GenericData, you might consider proceeding to step 3- Set the option "Data Structure" to "Don't save data".

Otherwise, proceed directly to step 4 - Use a Refined Target to restrict the Dependency Dataset

Step 3: Consider setting the option "Data Structure" to "Don't save data"

If your application contains Mainframe technology, this option can be found at Production tab, Mainframe tab.

By default, it is already set to "Don't save data". Data should be shaved only in case of impact analysis because it leads to a huge volume of objects being created, and significantly increases the duration of the mainframe analyses.

These objects are Cobol internal objects and cannot be the target of external links, so they are useless for the computation of external links.

Once you have set it to "Don't save data", then relaunch analysis (the first re-analysis may be long because the former objects will have to be cleaned up from the Knowledge Base).

If for some reason you do not want to configure this option as indicated, then please proceed to  step 4 - Use a Refined Target to restrict the Dependency Dataset

Step 4: Use a Refined Target to restrict the Dependency Dataset

• If during step 2, you found that the most numerous objects are CAST_COBOL_GenericData, but for some reason you want to keep these objects saved into database, then you have to exclude them from the Computency Dataset through a Refined Target.
  Create a Refined Target for Mainframe Technology as shown below, by checking "Filter by object type" and then selecting every type of object but "Cobol Data", "Cobol Conditional Test" and "Cobol Literal".
  Then apply your Refined Target to all the Dependencies whose target is Mainframe Technology.
  
  
  

• If during step 2, you found that the most numerous objects where not CAST_COBOL_GenericData, then you must first identify which technology the object type belongs to.
  To identify the technology, run the following query on your local base, where <OBJECT TYPE ID> is the first column of the first row in the results of Step 2

  Identify the technology

  set search_path=<YOUR_KB>;
   
  select c.idcat as "Technology ID" , c.catnam as "Technology Name" , c.catdsc as "Technology Description"from cat c 
  join typcat tc on c.idcat=tc.idcatparent
  join catcat cc on cc.idcat=c.idcat
  where tc.idtyp=<OBJECT_TYPE_ID>
  and cc.idcatparent=6000;

  Knowing the technology and the object type of the most numerous objects in the Dependency Dataset, you may decide to exclude this object type, depending whether it can be the target of an external link or not.
  For this, use a Refined Target for the technology and exclude the object type by proceeding as explained in the example for Mainframe technology and CAST_COBOL_GenericData example.

Ticket # 6844