Project

General

Profile

Wiki » Documentation » Conversion Handbook »

Gap Analysis

Introduction

This chapter is still being written, but the current content provides a starting point for interpreting the Code Analytics reports for the purpose of Gap Analysis.

Gap Analysis is the process by which a project's compatibility with FWD is assessed. Not all Progress 4GL features are supported in FWD or those features may only be partially supported. Likewise, there may be portability issues that occur when the application is being moved to a new hardware and/or operating system. Engaging in gap analysis is a crucial part of the project planning process. Knowing the gaps that need to be resolved allows the effort of the project to be more accurately estimated and the optimal approach to be chosen in advance.

Most importantly, a developer engaged in gap analysis must have a comprehensive understanding of the issues on which to check. The following are good resources to gain that understanding:

It is best to make a checklist of the potential issues that need to be investigated.

Before spending any significant time analyzing the reports, it is critical to ensure that all of the code and schemas that are necessary to represent the complete application are present. If there is anything missing, add it to the project and rerun the reports.

From there the developer deeply inspects the application using the reports and cross referencing items in the checklist with the level of support in FWD. A list of the gaps is developed with the results.

Sometimes a given canned report is only the first step. Specific questions may be raised which can best be answered by searches, ad-hoc reports, custom reports or by other forms of analysis. The process can be tedious but if one carefully and comprehensively, a proper gap analysis will eliminate many problems and wasted time in the future.

Golden Code Development, the creators and maintainers of the FWD technology, provide a wide range of services in support of Progress ABL conversions. Gap analysis is one of the services that their conversion experts can provide. Please see www.goldencode.com for more details.

Understanding Support Levels

Many of the Code Analytics built-in reports provide two Support Level columns (one for Conversion and another one for Runtime). Reports with these columns have a value displayed there to indicate the lowest support level available for the 4FL feature being reported. Use the descriptions below to help evaluate the meaning of the support levels.

During execution of the conversion front-end, there is a phase called Gap Analysis Marking. This is a set of rules that match specific 4GL language features to AST nodes and leave behind an annotation called support_level of data type Long (although only the least significant 32-bits are used). This is really just a bit field with two sections. The conversion section can be seen by the CVT_LVL_MASK which is 0x001F or 0000 0000 0001 1111 in binary. This means that bits 0 through 4 are associated with the conversion section. The runtime section can be seen by the RT_LVL_MASK which is 0x7F00 or 0111 1111 0000 0000 in binary. This means that bits 8 through 14 are associated with the runtime section.

The reason there are two sections is because it is possible for there to be conversion support for something that has a different level of runtime support and vice versa. Since these factors are independent of each other, they must be tracked separately.

If the annotation does not exist or its value is 0x0000, then the support level is unknown (LVL_UNKNOWN). Otherwise, there should be two bits turned on. One bit is in the conversion support level section and the other bit is in the runtime support level section.

The TRPL rules use constants that are bitwise OR'd together to create the support level. The following maps out the constants that are used and their meanings (the name and color can be seen in the reports).

Constant Value Name Meaning
LVL_UNKNOWN 0x0000 Unknown The support level is not known.
CVT_LVL_MASK 0x001F n/a This is used to isolate the conversion section using bitwise operations, it does not correspond with a real support level.
CVT_LVL_NONE 0x0001 None There is no support for this feature.
CVT_LVL_PARTIAL 0x0002 Partial Partial conversion support is implemented but there is at least some implementation missing.
CVT_LVL_BASIC 0x0004 Basic A basic conversion implementation is available but there are limitations which require more work before having a complete implementation. This is typically a statement of more compatibility testing being needed.
CVT_LVL_FULL_RESTR 0x0008 Full (R) Full conversion support is implemented, but there are permanent restrictions. This is typlically due to some feature that does not make sense or is not needed in Java.
CVT_LVL_FULL 0x0010 Full Full conversion support is implemented. It is expected to be fully compatible.
RT_LVL_MASK 0x7F00 n/a This is used to isolate the runtime section using bitwise operations, it does not correspond with a real support level.
RT_LVL_NONE 0x0100 None There is no support for this feature.
RT_LVL_STUB 0x0200 Stubs Runtime functionality stubbed out, but not implemented. This means that there are placeholder classes and methods in the Java code, sufficient for any converted code to compile. BUT these classes and methods have no real implementation inside, they are just there to satisfy the javac compiler.
RT_LVL_UNTESTED 0x0400 Untested A runtime implementation exists, but it needs testing. It is likely there are issues to resolve to achieve compatibility.
RT_LVL_PARTIAL 0x0800 Partial Partial runtime support is implemented but there is at least some implementation missing.
RT_LVL_BASIC 0x1000 Basic A basic runtime implementation is available but there are limitations which require more work before having a complete implementation. This is typically a statement of more compatibility testing being needed.
RT_LVL_FULL_RESTR 0x2000 Full (R) Full runtime support is implemented, but there are permanent restrictions. This is typlically due to some feature that does not make sense or is not needed in Java.
RT_LVL_FULL 0x4000 Full Full runtime support is implemented. It is expected to be fully compatible.

At this time, not all language features have gap marking rules implemented. This means that some reports cannot yet show the support levels. Many of the most important aspects of the language have been marked and their reports upgraded to show the support level columns.

By reviewing those reports, gap analysis is made much simpler because one can quickly identify which features need work.

Review Process

The specific list of reports to review is going to be different for different applications. The following is a good "starting point" for gap analysis:

  • Base Language
    • Language Statement Usage
    • Database Field Usage (By Data Type)
    • Schema Metadata Field Usage (By Name)
    • Builtin Function Usage
    • Builtin Global Variable Usage
    • Attribute Usage
    • Handle Based Method Usage
    • Inner Block Options
    • RUN Statement Options
  • Platform Specific
    • Look at anything with non-zero matches.
  • I/O Usage
    • Look at anything with non-zero matches.
  • User Interface
    • This can be ignored if the application has NO UI usage, but it cannot be ignored if redirected terminal is used.
    • You should check this regardless, because you may find it is used OR that you have dead code you can remove.
    • Format Strings
    • Color Phrases and Explicit Color Keyword Options
    • Widget Options
    • Dynamic Widget Options
    • Browse Options
    • Frame Options
    • Dynamic Frame Options

TBD: ECF add reports to list above.
TBD: Provide more details of the process, what we are looking for, how to double check if something is supported or not.

© 2004-2022 Golden Code Development Corporation. ALL RIGHTS RESERVED.