Project

General

Profile

Data Export

This input is not needed during the code conversion process. But to put an application into testing or into production, it will be necessary to migrate each database instance which is needed to support such installations. To do this, each database instance to be migrated must have its tables exported in the .d (EXPORT) format.

Please see the chapter on Data Migration for details on how to export the data. The result would be a dump file for each table of each database instance being migrated. The base filename for each export file must match the DUMP-NAME attribute in the .df file ADD TABLE entry for the corresponding table.

Internationalization

Applications which use the Progress 4GL default settings for internationalization (I18N) can ignore this step. For other applications it is important to have an understanding of the internationalization requirements. I18N can effect everything from conversion processing to runtime support, from the client to the application server and the database server.

See the Internationalization chapter for details on how to encode these values for conversion.

Conversion Inputs Encoding

What is the encoding of the source files for the application (include files, procedures, classes)? This must be the same value for all files and it must match the encoding used by the FWD tools that are used to parse those files.

What is the encoding of the exported schemata? This should match the encoding of the source files because the same encoding type will be used to process the schemata as is used for the source files.

What is the encoding of the data export files (.d data dump files)? This must match the encoding specified in the FWD tools for data import.

Runtime Values

Does the application use any of the following?

  • DBCS
  • UNICODE
  • Translation Manager
  • country/locale-specific empty databases
  • country/locale-specific Progress message files
  • code page conversion features
  • customized character processing tables - character attribute tables, case tables, collation tables, code-page conversion tables (convmap.dat)
  • customized word break tables

What does OpenEdge report for the following:

  • code-page(s) used in the Progress database
  • SESSION:CPSTREAM
  • SESSION:CPINTERNAL
  • SESSION:CPTERM
  • SESSION:CPPRINT
  • SESSION:CPCASE
  • SESSION:CPLOG
  • SESSION:CPRCODEIN
  • SESSION:CPRCODEOUT
  • SESSION:CPCOLL
  • SESSION:DATE-FORMAT
  • SESSION:NUMERIC-DECIMAL-POINT
  • SESSION:NUMERIC-FORMAT
  • SESSION:NUMERIC-SEPARATOR

Process Environment

Some of the configuration or state of a Progress 4GL application is derived from the environment or command line used when the Progress runtime is started.

The most important of these values is the PROPATH. This specifies how external procedures and include files are to be found, so it has a huge impact on how the source code is preprocessed and how procedures link to one another (e.g. via the RUN statement). This is especially important when all references to include files or procedures are not relative to the root of the project's source code tree. In such a case, the PROPATH is essential for resolving otherwise ambiguous filenames. For example, the preprocessor may not find all include files if the PROPATH is not right, which could make the 4GL syntactically incorrect or logically incomplete (even if the code does syntactically parse properly).

In addition, the default processing of the Progress environment can be modified using command line options (or a profile or .pf file with options). The list of these options needs to be known. These values can normally be found by reviewing all startup scripts or command lines used to launch the environment.

In a GUI application, any .ini files should be gathered. These usually contain font definitions, color definitions, as well as defining other options or configuration.

A list of all Windows Progress-specific or application-specific registry keys/values that are set.

All scripts, batch files or other launcher programs should be gathered. Consider that the application may have batch programs, appserver or WebSpeed brokers/agents and multiple kinds of clients, all of which might use different launching mechanisms.

Appserver, WebSpeed and DataServer configuration files (e.g. the ubroker.properties).

Finally, any environment variables that are read from 4GL code should be known and the possible values should be enumerated. This is also often something that can be found by reviewing startup scripts, command lines and user/global profile scripts. These variables and values are not likely to be needed for properly converting the source code, but it is very likely that they will be needed when configuring the runtime environment for executing the converted application.

Terminal Configuration

For character user interface (ChUI) applications, the terminal types used and the terminal configuration have an important effect on how the application will behave. In a graphical user interface (GUI) environment, these can be ignored.

Gather the set of supported protermcap files. These files provide a mapping between each terminal type's features and such things as colors or the keys that will be reported to the application as input.

Make a list of all the supported terminal types that must be certified to work in the converted environment.

Neither of these are needed for running the code conversion or for handling data migration. Instead, these are used to customize the FWD client's runtime environment to match the expected behavior for the supported terminals.

HLC Source Code

If the application uses HLC (the High Level Call interface) to integrate 4GL code with native (usually C language functions) code, then it is important to review the HLC source code. The HLS source code is compiled into a static object using Progress 4GL header files and calling 4GL services to read and write variables. This resulting compiled object code is linked to create a custom Progress 4GL executable which can dispatch CALL language statements to the linked in HLC functions. Everything runs in the same process.

Such an approach will not work in FWD, however that code can be easily migrated to a shared library and the 4GL CALL statements can be rewritten to invoke the shared library functions. This change has the advantage that it can be automatically converted without losing any functionality. Three key points: the HLC code must be available for review; the HLC/4GL code will have to be modified by hand to use the shared library approach; and the FWD conversion/runtime does not yet have support for generic shared library usage.

Checklist

The following checklist can be used to ensure that everything is available:

Input Available
All Progress 4GL procedure files which are in use or are referenced.  
WebSpeed HTML files which are in use or are referenced.  
TRIGGER-PROCEDURE files referenced by the schema.  
OO class files referenced in the application.  
ADM/ADM2 procedures in use (Possenet license).  
3 rd party procedures or classes used in the application AND which are expected to be converted (must be appropriately licensed for this to be legal).  
All application code is not in r-code or procedure library form.  
All referenced Progress 4GL include files.  
WebSpeed HTML files that are used as include files by 4GL source code.  
Any include files referenced in the database schema.  
ADM/ADM2 include files in use (Possenet license).  
3 rd party include files used in the application AND which are expected to be converted (must be appropriately licensed for this to be legal).  
An exported .df schema for each AND every database (with unique data definitions) that is accessed by the application.  
The logical database name for each .df file.  
The database metadata schema exported in a .df format. This is necessary if the application has ANY references to metadata tables or fields.  
The list of databases that are connected by default when the application starts.  
Data exports in .d format for each table of each database instance to be supported as a test or production application environment.  
The application's PROPATH.  
The command line or .pf options in use to startup the Progress session.  
All .ini files used by the application (GUI only).  
A list of all Windows Progress-specific or application-specific registry keys/values that are set.  
Any scripts, batch files or other launching programs for the application. Consider that the application may have batch programs, appserver or WebSpeed brokers/agents and multiple kinds of clients, all of which might use different launching mechanisms.  
Appserver, WebSpeed and DataServer configuration files (e.g. the ubroker.properties).  
The list of ENVIRONMENT variables read by the application and their possible values.  
The set of supported and customized protermcap files.  
The list of supported terminal types.  
List of I18N features used.  
Customized I18N data files.  
List of code pages used.  
Date format(s) used.  
Numeric format(s) used.  
Keyword ignore list.  
HLC source code if used.  

Test and Development Environment

The developers working on the conversion must have access to a test/development systems where the original application can be run in the 4GL against representative test databases. At the beginning of the process, source code can be compared to determine if it is broken in the 4GL, the environment can be investigated, 4GL compiles and listings can be generated to understand the code. Once the code is converted, access is necessary as a baseline to compare against the converted code (to compare the look/feel, behavior and functionality of the 4GL and FWD environments). Accordingly, there are important uses of the comparison environment throughout the entire conversion project, so it is imperative that such an environment is available. That environment must also be as close to a production environment as is possible.