VisualAge Generator to Enterprise Generation Language Migration Guide
When you are first getting accustomed to WebSphere Studio and setting up your
environment, you might want to migrate just a few programs to verify your
environment, ensure generation and preparation are working properly, and
ensure your runtime environment is properly configured for EGL. In this
case, you might not want to go through the full Stage 1 to 3 migration.
The Stage 2 migration tool provides a mechanism for you to migrate programs
using what is called single file migration as shown in the following
figure:

Single file migration is a more manual process than Stage 1 to 3
migration. In single file mode, you use VisualAge Generator to export
External Source Format source code to a file. Then you use WebSphere
Studio to create an EGL project and EGL package. From WebSphere Studio,
you can then use the Import wizard to import the External Source Format
file. The single file migration tool runs and does the following:
-
Creates the target EGL source file, if it does not exist. If the file
does exist, you have the option to overwrite or append to the file.
Depending on your preferences and the parts contained in the External Source
Format file, the migration tool might create additional EGL files.
- Converts the External Source Format source code to EGL source code.
-
Creates a log file of any potential problems that are encountered, including
generatable parts that conflict with the EGL reserved word list or ambiguous
situations that the migration tool is unable to resolve.
The External Source Format to EGL conversion that occurs during single file
migration is essentially the same syntax conversion that occurs during Stage 2
of the Stage 1 to 3 migration. However, single file migration has
several limitations that do not make it suitable for large scale
migrations. The limitations include:
- Only parts in the single External Source Format file are considered during
migration. To achieve the best possible migration, include a program
with all its associates in the External Source Format file.
-
The placement of VAGen parts into files is different from that of Stage 1 - 3
migration. In single file mode, assuming you specified
targetFile.egl as the target EGL file name, the following
occurs:
-
All control parts are placed in a file called targetFile.eglbld.
- If you do not select the preference to separate generatable parts into EGL
files, all the remaining parts are placed in a file called
targetFile.egl.
- If you select the preference to separate generatable parts into EGL files,
the following occurs:
- Each program part is placed in a file called programName.egl, where
programName is the name of the program.
- Each table part is placed in a file called tableName.egl, where
tableName is the name of the table.
-
Each map group and all maps in the map group are placed in a file called
mapGroupName.egl, where mapGroupName is the name of the map
group.
- All the remaining parts are placed in a file called
targetFile.egl. targetFile can be the same as
programName.egl if you want to place all the remaining parts in the
same file as the program. There is no attempt to determine which parts
are shared by multiple generatable parts.
-
All the files are placed in same EGL project, source folder, and
package.
-
Because all the output files are placed in the same EGL package, the migration
tool does not include any import statements. In addition, because all
the parts are placed in the same EGL package, your original Java project and
package structure are not preserved.
Similarly, your original Smalltalk configuration map and application structure
are not preserved.
-
If the same part occurs multiple times in the External Source Format file,
only the last definition is migrated.
-
There are two alternative techniques for dealing with common parts when
migrating in single file mode. Be sure you understand the disadvantages
of each technique before choosing one of them. The two techniques are
as follows:
-
If you migrate two External Source Format files to the same EGL package and
the two files contain the same part, you will have duplicate parts that cannot
be resolved by EGL. This happens if you migrate a file with Program1
and its associates and a second file with Program2 and its associates and the
two programs share some common parts. You can avoid this problem by
migrating each program with its associates to a separate EGL package.
This will still result in duplicate parts in the workspace, but because they
are in different packages, EGL will be able to resolve the part
references.
-
If you split the common parts out into a separate External Source Format file,
you might not have all the information necessary to do a good VisualAge
Generator to EGL migration on a single-file basis. For example, if you
have an SQL record in one file, and a function that uses modified SQL for the
record is in a different file, the migration tool cannot completely build the
I/O statement for the function. In addition, if the common parts are in
a different package, you must add EGL import statements to each file that
needs to reference the common package (or packages).
-
Additional processing that is done by Stages 2 and 3 is also not performed in
single file mode. Some examples are as follows:
- Forms are not nested within form groups.
-
Parts are not sorted by part name within part type in the file.
-
Only one line is included between the parts in the output files.
See "Migration challenges" and Techniques used by the VisualAge Generator to EGL Migration Tool for a better understanding of the differences
between single file migration and Stage 1 to 3 migration.
[ Top of Page | Previous Page | Next Page | Table of Contents | Index ]
(C) Copyright IBM Corporation 1992, 2005. All Rights Reserved.