VisualAge Generator to Enterprise Generation Language Migration Guide
The Stage 1 tool is shipped as a sample program with WebSphere Studio.
You install the sample program to run on either VisualAge Generator Developer
on Java or VisualAge Generator Developer on Smalltalk, depending on the
VisualAge Generator Developer 4.5 product that you currently
use. The two sample programs differ somewhat due to the differences in
the Java and Smalltalk environments. However, the basic steps for using
the Stage 1 sample programs are the same in both environments. The
basic steps for Stage 1 are:
-
Step 1. Define rules and preferences to direct the Stage 1
migration.
- Step 2. Run the tool and produce one or more of the following
outputs:
-
One or more migration plan files
-
A report showing how each migration plan file will be migrated
-
A log file containing messages about any problems detected
-
A migration database
Define rules and preferences that provide the Stage 1 tool with information
about what you want to migrate, including the following:
-
How to filter Java project names so that only the projects you want to migrate
will be considered. For Smalltalk, you specify how to filter the
Smalltalk configuration map names. This improves performance for Stage
1 because the tool only processes those Java projects or Smalltalk
configuration maps that match your filters.
-
From those Java projects that match your filters, the Stage 1 tool selects any
Java projects that contain a high-level Project List Part. A Java
project contains a high-level Project List Part (PLP) if the Java project is
not referenced by any other PLPs.
- From the Smalltalk configuration maps that match your filters, the Stage 1
tool selects any high-level configuration maps. A high-level
configuration map is one that is not listed as a required map by any other
configuration map.
-
Whether you want to create one migration plan that reflects everything that
could migrate based on your filter, or whether you want to create multiple
migration plans, with one migration plan for each Java high-level PLP project
version or Smalltalk high-level configuration map version.
-
How to create the EGL project, package, and file names from the Java project
and package names or from the Smalltalk configuration map and application
names. The information you can specify includes the following:
-
Rules that indicate which Java projects and packages or Smalltalk
configuration maps and applications contain common code.
-
Renaming rules to be used when creating the EGL project and package
names.
-
Names to be used for the EGL files that contain common parts or unused
parts.
-
The name of the migration database and the user ID and password that are
needed for access to the database.
-
Which outputs you want the Stage 1 tool to produce in Step 2. You can
choose to create all the outputs in a single step or you can create the
outputs in sequence so that you have a chance to review your rules and
preferences before creating the next, more time-consuming output.
Based on the rules and preferences you have defined, the Stage 1 tool
produces the following possible outputs:
-
Migration plan file (or files). A migration plan file
contains migration sets. Each migration set is one high-level PLP
project version from the Java repository or one high-level configuration map
version from the Smalltalk repository. The dependent Java project
versions or the required Smalltalk configuration map versions are specified in
the migration set.
- If the migration preference file does not specify a value for the
migration plan filename option, then multiple migration plan files are
created. Each high-level PLP project version for Java results in one
migration plan file that contains one migration set. Similarly, each
high-level configuration map version for Smalltalk results in one migration
plan file that contains one migration set version.
- If the migration preference file specifies a value for the migration plan
filename option, then each high-level PLP project version for Java results in
a migration set entry within the single migration plan file. Similarly,
each high-level configuration map version for Smalltalk results in a migration
set entry within the single migration plan file.
-
For example, consider an Order Entry system that is made up of 5 Java projects
and a sixth Java project that contains a PLP that specifies the versions of
the other 5 projects. If you request multiple migration plans and 3
versions, then 3 migration sets will be created -- one for each version of the
Java Order Entry project that contains the PLP part. Similarly for
Smalltalk, if you want to migrate 3 versions of a configuration map that
reflects that code that makes up the Order Entry system, there will be 3
migration sets -- one for each version of this high-level configuration map
You can direct the Stage 1 tool to stop at this point so you have the
opportunity to review the migration plan file (or files) to ensure that the
Java project versions or Smalltalk configuration map versions that you want to
migrate are correctly reflected in the migration plan file (or files).
-
A report showing how each migration set will be migrated.
The Stage 1 tool can produce this report without loading the
database. This helps you ensure that your filters and preferences
select the correct set of Java projects or Smalltalk configuration maps and
that you are satisfied with the naming conventions of EGL projects, packages,
and files that resulted from your renaming rules. Reviewing the report
gives you an opportunity to refine your rules and preferences if you are not
happy with the proposed EGL structure before the Stage 1 tool actually loads
the database. You can iterate through the previous steps as many times
as necessary until you are satisfied with what will be migrated and the
proposed EGL structure. The report shows the following:
- For Java, each migration set lists the project versions that are
included. For each project version, you can see the package versions,
and for each package version, you can see a list of the VAGen parts.
-
For Smalltalk, each migration set lists the configuration map versions that
are included. For each configuration map version, you can see the
application versions, and for each application version, you can see a list of
the VAGen parts.
For each VAGen part, you can see the corresponding EGL project, package, and
file name where the part will be placed. See section Placing parts in EGL files for information on how the VAGen parts are assigned to files
during Stage 1 - 3 migration.
-
A log file provides messages if any of the VAGen program, table,
map group, or control part names conflict with the EGL reserved word
list. These parts are not renamed during migration. You can
either rename the parts in VisualAge Generator or wait until you have migrated
to EGL.
-
A migration database loaded with the information and VAGen source
code based on the migration plan files. You can select one migration
plan to use in loading the database or all the migration plan files in a
directory. The Stage 1 migration tool loads the data base with the
following:
- Information about each migration set within the selected migration plan
file (or files).
-
The set of associated Java projects or Smalltalk configuration maps for the
migration set.
-
The VAGen part definitions in External Source Format for each VAGen part in
the set of Java projects or Smalltalk configuration maps.
-
The corresponding EGL project, package, and file names for each Java project,
package and VAGen part or each Smalltalk configuration map, application and
VAGen part.
-
A report is also created during this step so that you have a complete record
of what was loaded into the migration database. This report is in the
same format as the previous report.
The Stage 1 tool is shipped as a sample program for both the Java and
Smalltalk versions of VisualAge Generator. You can use the Stage 1 tool
"as is" or you can modify the sample program to better fit your
environment. For example, you might currently store configuration
information outside the Java repository or Smalltalk library. This
configuration information might specify which versions of your source code are
required for generation.
In this situation, you could use the sample programs as a guide to writing
your own tool to load the migration database from a combination of your
configuration information and your Java repository or Smalltalk
library.
If you modify the Stage 1 sample programs, you might want to modify the
migration database to include additional information to assist in the analysis
of your code. You can add additional columns to the existing SQL tables
or you can add additional tables to the migration database. However,
these new columns and tables will not be used in Stages 2 and 3 of
migration. Additionally, if you modify the Stage 1 sample programs, you
must be sure to populate the SQL tables with the information shown in the
sample programs. If you do not, Stages 2 and 3 will not be able to
migrate your code.
See Stage 1 - Extracting from Java for details about installing and running the Stage 1 tool on
VisualAge Generator Developer on Java. See Stage 1 - Extracting from Smalltalk for details about installing and running the Stage 1 tool on
VisualAge Generator Developer on Smalltalk.
[ Top of Page | Previous Page | Next Page | Table of Contents | Index ]
(C) Copyright IBM Corporation 1992, 2005. All Rights Reserved.