Page tree
Skip to end of metadata
Go to start of metadata

Overview

After translating your migration projects, you can generate Semantic Model Reports. Semantic Reports are similar to CodeScan reports but they are produced by analyzing the compiled code rather than by scanning the source code directly. They facilitate a much more detailed look into your system.

Semantics References

Semantic References: a detailed look at referenced symbols. Answers the question: what symbols are referenced and how are they used? Includes only those symbols that are actually used.

SrcName ' Migration Unit Name
RunDate ' Semantic Model Creation Date
RecType ' Report Type
MemName ' Member Name
MemClas ' Member Parent
MemLibr ' Member Library
MemType ' Member Type
Pos_Cnt ' Referring Location
LocText ' Referring Source
LocMemb ' Referring Member
LocFile ' Referring File
LocName ' Referring Type
LocType ' Referring File Type

Semantics Definitions

Semantic Definitions: a detailed look at defined symbols. Answers the question: what symbols are defined and how are they used? Includes all symbols defined in code and in referenced libraries.

SrcName ' Migration Unit Name
RunDate ' Semantic Model Creation Date
RecType ' Report Type
MemName ' Member Name
MemClas ' Member Parent
MemLibr ' Member Library
MemType ' Member Type
Pos_Cnt ' Definition Count (0 if not explicitly used; this can be used to help you identify dead code)
LocText ' Definition Text
LocFile ' Defining File
LocName ' Defining Type
LocType ' Defining File Type

Identifying Dead Code

The Analytics/Semantics Definitions reports can help with identifying dead code.  The Pos_Cnt field is the number of references detected by the tool.  So a zero means not used.

Another, more tedious, way to to identify unused symbols is to look for the symbol in the Analytics/Semantics References report.  If a symbol is NOT FOUND as referenced in the References report, then it may be dead and the corresponding record for the symbol in the Definitions report should have Pos_Count=zero. 

You need to be careful interpreting these results. Some things to be aware of: event-handlers may be needed but are rarely explicitly called, and late calls (CallByName and dynamic) are not detected either. So it is possible to detect 0 calls, but still have calls at runtime.  It is a critical to audit the code for late calls and refine the upgrade solution to enhance type inference hints if you are finding unexpected late calls. Also, the dead code analysis gets more difficult when dealing with members in COM DLLs. One must inspect all client code that might use the DLL to see if the member is called through COM.  This is only possible if you have source code for all clients. If you only have Standalone EXEs, this complexity is not a concern.
 

The Assessment Report workbook we prepare for a Smart Start includes a Member Counts report that combines the Definitions, References, and _MEMBER_ Search report data to compute a usage and facilitate dead code analysis.  The Smart Start Assessment Reports also accounts for multi-component systems and calls through COM.

Semantics Symbols

A dump of the symbol table. Includes all symbols defined in code or in referenced libraries.

SrcName         ' Migration Unit Name
RunDate         ' Semantic Model Creation Date
Lev             ' Symbol's Level in the Model Hierachry
Address         ' Symbol's Address
Parent          ' Symbol's Parent address
Type            ' Symbol's Type
FullIdentifier  ' Symbol's Fully-Qualified Identifier

Semantics Audits

A detailed report showing the internal semantic model contents in terms of symbol tables and low-level semantic operations. These reports can be useful for implementing advanced refactoring rules that manipulate operation streams.  There are two types of Semantic Audits:

  • Compiler Audit: reports the semantic model contents before it has been modified by Analyzer algorithms 
  • Analyzer Audit: reports the semantic model contents after it has been modified by Analyzer algorithms
  • No labels