CAST AIP Troubleshooting Guides
Page tree
Skip to end of metadata
Go to start of metadata
Purpose

This page helps you to troubleshoot issues when the value displayed for Lines of Code on dashboard is incorrect. In other words you are expecting the lines of code to be displayed as N but it is displayed as M or 0.


Observed in CAST AIP
Release
Yes/No
8.3.x(tick)


Observed on RDBMS
RDBMS
Yes/No
CSS(tick)
Action Plan
  1. The issue is visible under KLOC only, if so follow the page CAST Engineering Dashboard - Metrics - Lines of Code - Incorrect value - KLOC is displayed as 0
  2. Check if the issue you are facing is already reported under Known Issues
  3. Configuration\framework files like pom.xml, struts.xml, app.config etc does not contribute to LOC. These are generated files from IDE and hence will not add to LOC of an application.
  4. Verify that the level or version of the language being analyzed is supported as per the release notes for that CAST version.  If the language level or version is not supported, you may see a large amount of syntax errors in the analysis log which indicates that these items were not properly analyzed due to analyzer not supporting the newer syntax and can lead to a value for lines of code lesser than what is expected.
    For instance -
    For ABAP, inline declarations were introduced in ABAP 7.40 which is currently not supported in CAST 8.1.X or lower versions.  Refer to the release notes for any version beyond 8.1.X for support of  ABAP 7.X where X >= 40
    1. If you do not have a compatible version of CAST-AIP then please use the correct one to solve the issue.
    2. If you have a compatible version of CAST-AIP for the version of the technology that your source code is developed then go to next step
  5. Check if it is a Configuration Issue that led to this unexpected behavior
    1. If there is configuration issue then fix it using the remedies given under Configuration Issue
    2. If there is no configuration issue then go to next step

  6. Calculate the LOC in KB

    1. For all modules, if the Number of per module in the Knowledge Base is equal to the number shown in the CED, we can conclude that problem is in the analyzer.

      Look for any syntax errors (or some other message/warning/error for example : Table XXX is rejected because the first matching rule id 1 is ambiguous. This is useful info for Number of Table ) in the analysis log, which could explain why a lower number than expected was achieved. Please refer to CMS Snapshot Analysis - Run Analyzer - Non Fatal error  and CMS Snapshot Analysis - Run Analyzer - Warnings for further information.

    2. For all modules, if the Number of per module in the Knowledge Base is NOT equal to the number shown in CED then identify the missing objects in CB by following the below steps -

      1. Run the below query on Central database

        select dos.object_name,dmr.metric_num_value 
from dss_objects dos join dss_metric_results dmr
on dos.object_id = dmr.object_id
join dss_link_info dl
on dl.next_object_id = dos.object_id
where dmr.metric_id = 10151
and dmr.snapshot_id = <Snapshot_id>
and dl.previous_object_id = <Module_id>
and dl.link_type_id = 3

        Module_id can be fetched by using the page - SQL Queries - CAST Central Base - Queries on modules - How to get the ID of the functional module
        Snapshot_id can be fetched by using the page - SQL Queries - CAST Central Base - Queries on snapshots - How to get the ID and name of a snapshot for a given application

      2. Compare the list of objects retrieved on CB and KB
      3. Take one object present in KB but not present on CB and follow the below checks -
      4. Check if the object is part of module by following the page SQL Queries - CAST Knowledge Base - Queries on Module - Module content and properties
        1. If the object is not part of the module then navigate to the page - CMS Application - Modules
        2. If the object is part of the module then this is a bug during Compute Snapshot
      5. Check if the object is external or generated SQL Queries - CAST Knowledge Base - Queries on objects - How to check if objects are internal or external or generated from the application.
        1. If the object is external or generated then this is an expected behavior.
        2. If the object is internal then this is a bug during Compute Snapshot

  7. If the above steps do not solve your problem or give you an explanation, then please report your problem to CAST Technical Support and provide the below Relevant input:

 

If you are Comparing LoC of CAST with 3rd party applications then it is expected to get a difference as calculation of LoC by CAST AIP which is based on various parameters (commented lines /blank lines /...) and this can vary when compared to other applications calculation of LoC.


Relevant input

  • CAST Support Tool (CST) - alias Sherlock export with the following options CAST Bases Checker, Export Logs, Export Configuration files, Export Computer Environment, Export CAST Bases with Management Base, Knowledge Base, Central base
  • Complete screenshot of dashboard with URL pointing to the LOC that you are looking at
  • Expectations and justification for expectation

Known Issues

  1. If the technology is RPG DB400, check if this is your case CAST Engineering Dashboard - Metrics - Lines of Code - Incorrect value - RPG DB400 - Lines of Code LOC is doubled

  2. If the technology is JS, check if this is your case CAST Engineering Dashboard - Metrics - Lines of Code - Incorrect value - DOTNet - Number of Line Of Code not calculated for js Files

  3. If you are using the extension HTML5 funcrel 1.2.0 with other UA languages then this will prevent the LOC of other UA languages from being calculated. This issue is fixed in HTML5 funcrel 1.3.0 . Download HTML5 funcrel 1.3.0 from extension downloader and re-do the analysis + snapshot for LOC to be calculated.

  4. XHTML files are not taken into account by the Number of Line Of Code for J2EE although the file extension *.xhtml is declared as Web Server File Extension at the Technology level

    Figure 1

    There is an issue in 8.2.x (x< 6) : if you set the *.xhtml files as web server files at the JEE Technology level, then it is ignored by the JEE Analyzer

    The solution is to set it at the Analysis Unit level. To do this in an automated way, you may use the following query on the Management Base:

    Add xhtml to web server file extensions at the AU level
    UPDATE cms_j2ee_analysis
SET    jsp_fileextensions= jsp_fileextensions
              || ';*.xhtml'

    Then, run analysis and snapshot again.

  5. If LOC is duplicated for procedure/table/functions when using SQL Analyzer i.e. LOC is considered from the "file that contains source code type" as well as from individual procedure/function objects. If this is the issue please note that it is already fixed in SQL Analyzer 1.0.0-beta5 version.
    1. If you are using any lower version then upgrade it to latest one.
    2. If you are using version higher than fixed version but still facing the issue then you need to uninstall and reinstall the SQL Analyzer extension in your application.

    3. To confirm if the issue is resolved you can simply run the below query in KB which should give only the "file that contains source code object type" inheriting from APM sources as below:

      select *  from typcat  where idtyp in (1000007, 1101009)  and idcatparent = 10048

      Result:  

         

  6. LOC is displayed as 0 for HTML technology in Health Dashboard even though there are 2 files analyzed.

 

 In this case, first you need to check the type of the files analyzed. If it is '.aspx' files then it is expected to get this files analyzed by HTML as well as Dot Net analyzer( See doc) . When your application has both the technologies, then files will get analyzed by both analyzers but LOC will be considered for only one technology to avoid duplication. So in the above case, LOC was considered for Dot Net technology and LOC for HTML was showing as 0. Regarding discrepancy showed in HD i.e. artifacts showing as 2 and LOC as 0, it will mislead the customer unless they understand the analyzer behavior. So respective team will be correcting this display issue by implementing appropriate method.

7. LOC for SQL technology is displayed as 0 in dashboard

This issue can be due to the fact that SQL source files are not part of module. This is a known limitation with SQL LOC computation in central where it considers only objects of type source files part of modules and not other artifacts. You can check if the particular source file object is part of module using the following Query.

As an alternative, you can configure the module filter to the source file name instead of object name followed by full analysis which will include the SQL source file in the module and LOC will be computed.           

Configuration Issue

  1. C & C++

    LOC of C is displayed as 0, and the LOC of C is counted as C++ though the source code contains both C & C++ files.
    Note that if you have both C and CPP technologies in your source code then you need to be careful while selecting the option "Consider files as" in the analysis tab as shown below. When configuration is set to analyse both C & C++ then the LoC of C are counted in C++ and hence you will not get any LOC for C though you have C files in your source code. This documentation is planned to be updated in CAST-MS online help in 7.3.6.
    If you want to see the C and C++ to be counted in the LOC of C and C++ respectively then you need to change the configuration. You can split all the C & C++ files and create two separate analysis units and choose "C only" option for the C part of split part. For the C++ split part you can choose "C++ only" option.
    Figure 2

  2. After adding the include path there are some headers which would not be analyzed because those headers would be set to external and would not contribute to LOC.

    There are many reasons that can explain the header file is not considered as internal:
    It's not included anywhere
    It's empty, or almost empty (for instance, it only includes other headers)
    It's a third party header, only declaring some external functions, not defining anything
    So, if the headers are marked as external and not analyzed then you need to run the below query in your KB (take the backup of KB first) followed by CSV run and then take the snapshot with analysis again.

    UPDATE objpro
SET    prop=0
WHERE  idobj IN
       ( SELECT idobj
       FROM    objpro opfile
               JOIN keys k
               ON      k.idkey = opfile.idobj
       WHERE   k.objtyp        =512
       AND
               (
                       k.keynam LIKE '%.h'
               OR      k.keynam LIKE '%.hpp'
               )
       AND     opfile.prop > 0
       AND     EXISTS
               ( SELECT opos.idobj
               FROM    objpos opos
                       JOIN objpro op
                       ON      op.idobj=opos.idobj
               WHERE   op.prop         =0
               AND     opos.idobjref   =k.idkey
               AND     op.idpro        =opfile.idpro
               )
       )

    This issue has been fixed in 7.3.12, 8.2.2

  3. Siebel:
    If you are using Siebel, this issue is encountered when the delivery was done using the Generic extraction:


    instead of Siebel extraction:


    In that case, the *.SRC are not deployed. This is not the process described for Siebel, please follow the process described in the following page Siebel. 
    As a workaround you have to deploy the *.SRC files manually in the expected deployment folder. To know where is your deployment folder, do the following steps:

    • Open Cast-MS
    • Click on Window button
    • Choose 'Preferences'

    • New box will open

    • Choose 'Platform Settings'
    • You will find your Deployment folder

Calculate the LOC in KB

PLEASE NOTE:  THE QUERIES BELOW ARE ONLY VALID IN CAST AIP 8.3.36 AND BELOW.  FOR CAST AIP 8.3.37 AND ABOVE YOU MUST MODIFY THE QUERIES AS FOLLOWS:

  • change references:
    • properties = 0
  • to
    • properties & 255 = 0

Please follow the below steps to calculate the Number of line of code stored in Knowledge Base

Calculate the Number of code line per module in the Knowledge Base

  1. Get the technical module ID by running the below query on the Knowledge Base

    select s.idroot as "Module ID" , dos.object_name as "Module Name" 
from setroot s, dss_objects dos 
where s.idset = dos.object_id 
and dos.object_type_id = 20000 
order by s.idroot

    Output -
    389;"My Application full content"
     

  2. To get the value of the Number of code lines run the following query on the Knowledge Base. Note that only the application's non-external objects are considered.

    SELECT SUM(oi.infval)
FROM   objinf oi,
       keys k
WHERE  oi.idobj IN (SELECT ( object_id )
                    FROM   ctt_object_applications
                    WHERE  properties = 0
                           AND application_id = <Technical_module_id>)
       AND inftyp = 1
       AND infsubtyp = 0
       AND k.idkey = oi.idobj
       AND k.objtyp IN (SELECT DISTINCT t.idtyp
                        FROM   typ t,
                               typcat tc
                        WHERE  t.idtyp = tc.idtyp
                               AND tc.idcatparent IN (SELECT cat.idcat
                                                      FROM   cat
                                                      WHERE
                                   catnam LIKE '%APM Sources%'))
    Example
    SELECT SUM(oi.infval)
FROM   objinf oi,
       keys k
WHERE  oi.idobj IN (SELECT ( object_id )
                    FROM   ctt_object_applications
                    WHERE  properties = 0
                           AND application_id = 389)
       AND inftyp = 1
       AND infsubtyp = 0
       AND k.idkey = oi.idobj
       AND k.objtyp IN (SELECT DISTINCT t.idtyp
                        FROM   typ t,
                               typcat tc
                        WHERE  t.idtyp = tc.idtyp
                               AND tc.idcatparent IN (SELECT cat.idcat
                                                      FROM   cat
                                                      WHERE
                                   catnam LIKE '%APM Sources%'))

    Output - 2000

  3. Get the list of objects used to compute the Number of Code Lines per module for all modules

    SELECT k.*
FROM   objinf oi,
       keys k
WHERE  oi.idobj IN (SELECT ( object_id )
                    FROM   ctt_object_applications
                    WHERE  application_id = <application_id >
                           AND properties = 0)
       AND inftyp = 1
       AND infsubtyp = 0
       AND k.idkey = oi.idobj
       AND k.objtyp IN (SELECT DISTINCT t.idtyp
                        FROM   typ t,
                               typcat tc
                        WHERE  t.idtyp = tc.idtyp
                               AND tc.idcatparent IN (SELECT cat.idcat
                                                      FROM   cat
                                                      WHERE
                                   catnam LIKE 'APM Sources')
                       )
    Example
    SELECT k.*
FROM   objinf oi,
       keys k
WHERE  oi.idobj IN (SELECT ( object_id )
                    FROM   ctt_object_applications
                    WHERE  application_id = 389
                           AND properties = 0)
       AND inftyp = 1
       AND infsubtyp = 0
       AND k.idkey = oi.idobj
       AND k.objtyp IN (SELECT DISTINCT t.idtyp
                        FROM   typ t,
                               typcat tc
                        WHERE  t.idtyp = tc.idtyp
                               AND tc.idcatparent IN (SELECT cat.idcat
                                                      FROM   cat
                                                      WHERE
                                   catnam LIKE 'APM Sources')
                       )

    Output -

    "idkey";"keynam";"keylib";"keytyp";"keysubtyp";"keyclass";"keyprop";"objtyp";"idusrdevpro";"keydevdat";"keydevvlddat";"status";"sqlowner"
    462;"PG1004";"";"XXXXXX";-1;14080;4;545;"???";"1970-01-01 00:00:00";"";0;"" 

Notes/comments
 Ticket # 9304, 19634
Related Pages


  • No labels