Project

General

Profile

Gathering Inputs

To use FWD Code Analytics, the application source code, schemata and other inputs will be required. These must be gathered so that they can be placed into a well-defined structure in the analytics project.

Source Code

The most important (and obvious) input is the source code for the application. There are two types of source code: First, there are the callable procedures in the application. In a traditional Progress 4GL environment (both in a 4GL client or in an appserver), these are all the external procedure files. External procedures often have an extension of .p or .w, but there is no real limit to the naming convention that may be used. This also includes any TRIGGER-PROCEDURE files referenced in the schema. Any object oriented classes in use or referenced (these are always .cls files) must be included. If WebSpeed is in use, then the HTML files (perhaps including SpeedScript Embedded 4GL or HTML mapping) would need to be included. The following factors are important to remember:

  • All files that are in use must be included.
  • All files that are referenced (e.g. in a RUN statement) must be included.
  • The version that should be provided must be the original source code that has not been run through the Progress 4GL preprocessor (or the WebSpeed E4GL preprocessor). A better result is obtained without providing the source code in preprocessed form since during the conversion, the FWD preprocessor saves hints about its actions that are used downstream to make better conversion decisions.
  • Compiled (r-code) and/or procedure libraries cannot be used. If the code is part of the application, you must include the source files instead of the compiled files.
  • If ADM/ADM2 is in use, then the source code for those procedures must be included. Any version of ADM/ADM2 source code released under the Possenet license is legally safe to include.
  • REST or Web Services Adapter (WSA) artifacts and configuration for Classic Appserver (Web Services Adapter/SOAP Adapter, REST Adapter) or PASOE (SOAP Transport, REST Transport).
  • Do you require 3 rd party 4GL code in order to run properly? Those files must be converted or replaced in the resulting system. You will need to check on the licensing for those files if you wish to convert them. If the licensing allows you to create a derivative work of that code (modify/translate the code and distribute/use the result), then you can include those files in this project. Do not include the files if the license does not give you the rights to make a derivative work.

The second type of source code that is required are the include files referenced by all of the procedures. The FWD conversion process has a compatible preprocessor that will handle all include file processing and other preprocessor directives, so it is neither necessary nor desirable to provide preprocessed source code. It is very important to provide a complete set of include files. In a traditional Progress 4GL environment, these are files with a .i extension. Many applications use .f or .frm for include files that are a frame definition or .tt for include files that are temp-table definitions. There is no specific limit on the file name and any file that is included must be gathered.

It is just as important to have all of the source code gathered for conversion as it would be for building a runtime installation of the application in the Progress 4GL. Since this process does a static conversion of the entire application as a batch, into a replacement Java application, everything that is possibly linked into and executed as part of the application must be present at the time the conversion tools are run.

Do NOT forget the following:

  • All files that are referenced in an {include-file.i} directive must be gathered.
  • Include files can be nested arbitrarily deep. This means your search for includes may be an iterative process where you add files and recheck to see if anything else is missing. This continues until everything is found and no failures occur during compilation (in Progress) or during parsing (in FWD).
  • Any procedures in the application, including WebSpeed or TRIGGER-PROCEDURE files can also reference include files.
  • WebSpeed files can be treated as include files in any 4GL code.
  • Include files referenced in the database schema must be gathered either. For example, a field level VIEW-AS clause or VALIDATE expression.
  • If ADM/ADM2 is in use, gather any include files referenced by the application source code OR by any referenced ADM/ADM2 procedures. Any version of ADM/ADM2 source code released under the Possenet license is legally safe to include.
  • Calling 3 rd party code often requires include files. The dependencies must be satisfied or removed. If the 3 rd party code is intended to be converted, then you will need to check on the licensing for those files. If the licensing allows you to create a derivative work of that code (modify/translate the code and distribute/use the result), then you can gather those files in this project. Do not gather the files if the license does not give you the rights to make a derivative work. In such a case you must remove the references in the source code that is being converted.

Database Schemata

Due to the complete integration of database access into the core of the Progress 4GL language, it is not possible to even parse 4GL source code (that has any database usage) without having first parsed all database schemata to which that source file has references. Consider that even something such as a DEFINE VARIABLE x LIKE db.table.field clause is a database reference. In real applications, it would be a very rare source file that didn't have database references.

For each schema referenced in the application, that schema must have been exported from the Progress Data Dictionary in the .df format. To create this export file for a Progess database, follow these steps:

  1. Open the Data Dictionary
  2. If necessary, connect to the target database and make it the working database.
  3. Select from the menu: Admin --> Dump Data and Definitions --> Data Definitions (.df file)...
  4. Select all tables to be migrated to the new database (or use F5 and then specify * and ENTER to select all tables).
  5. Then press GO (generally F1).
  6. Select a target .df filename, use code page ISO8859-1, then choose OK.
  7. When the process completes, there should be a .df file that contains the schema for that database.

Repeat this process for each database schema to be exported. If the application uses multiple copies (or instances) of the same database schema, only one .df file is necessary.

The Progress database supports a set of metadata on each database. Metadata is a set of specially named tables (and fields of those tables) that are normally “hidden” in the Data Dictionary, but which are always there. The Progress database manager uses these tables to maintain the state, statistics and structure that is associated with each database. At least, this is the state/statistics/structure that is accessible using queries within the application itself. Applications that use this metadata, will require an additional “standard” metadata schema to be exported into .df format. Applications with no metadata references will not need to provide this .df file.

To create the metadata schema export file, follow these steps:

  1. Open the Data Dictionary
  2. If not already connected to a database, connect to any database and make it the working database. It doesn't matter which database is used, since each one shares the same metadata.
  3. Select from the menu: Admin --> Dump Data and Definitions --> Data Definitions (.df file)...
  4. Press F7 to show hidden tables (all the metadata tables start with an _ (underscore) character and will now appear at the bottom of the table list).
  5. Press F5 and then specify _* and then ENTER to select all metadata tables.
  6. Then press GO (generally F1).
  7. Select a target .df filename (such as standard.df), use code page ISO8859-1, then choose OK.
  8. When the process completes, there should be a .df file that contains the metadata schema.

While the metadata schema does not change often, it can change between Progress 4GL versions. It is important to export the metadata schema from the same version with which you application is designed to work.

For each of these database schemata (not the metadata schema since that is part of every database), the following additional information is needed:

  1. What is the logical database name for this database?
  2. Is this database connected automatically when the application is started (e.g. connected via a command line parameter)?

Keyword Ignore List

Since each new version of Progress 4GL may (and often does) bring new keywords, older applications can have conflicts between those new keywords and the user-defined symbols in the code. Progress provides a mechanism to disable any new keywords that conflict with older code. That mechanism is called the keyword ignore list. It is a text file that is created by the application programmer, one keyword per line.

Obtain this file if the application depends upon it. The FWD conversion tools will need to be configured to honor that file. This can be done using the keyword-ignore parameter in the global configuration file p2j.cfg.xml. See the Global Configuration section for details.


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

Next: Project Setup