VisualAge Generator to Enterprise Generation Language Migration Guide
Common code is code that is shared between subsystems or programs.
The following figure shows common code that is shared by two
subsystems.

In this case, there are one or more Java projects or Smalltalk configuration
maps that contain Corporate Common Code. The code in these projects or
configuration maps can be shared by multiple subsystems. In this
example, SubsystemA and SubsystemB use subsets of the common code. Some
of the Corporate Common Code is used by both subsystems. For example,
Corporate Common Code might include SQL record definitions that are used by
many subsystems.
The next figure shows the same basic sharing of Corporate Common Code by the
two subsystems, with SubsystemA shown in more detail.

SubsystemA has SubsystemA Common Code that used by multiple programs within
SubsystemA, but only by programs within SubsystemA. In this case,
Program1 and Program2 each make use of some of the SubsystemA Common Code as
well as some of the Corporate Common Code. Between the two programs,
there is some overlap of both the SubsystemA Common Code and the Corporate
Common Code, including overlap with Corporate Common Code that SubsystemB
uses. For example, SubsystemA Common Code might include SQL record
definitions that are used only by programs within SubsystemA.
SubsystemA Common Code might also include a map group definition that is used
by several programs within SubsystemA.
To facilitate the use of common code, VisualAge Generator determines at test
and generation time how a particular piece of source code should be
interpreted. The advantage of this is that each subsystem or program
can make slight variations in the code, just by varying the specific map group
that a program uses or by varying data item or record definitions that are in
the workspace during generation. The following are three
examples:
-
Much of the same logic can be shared by an online program that interacts with
a terminal and a batch program that prints a similar report as follows:
-
ProgramA is main transaction program using MapGrpA which contains display maps
named HEADER, DETAIL, and TRAILER. ProgramA displays the partial HEADER
map, displays DETAIL lines in a floating area, and then converses the TRAILER
map which contains an input field where the user can request the next
report. ProgramA uses the SET HEADER PAGE statement to clear the
screen.
- ProgramB is a main batch program using MapGrpB which contains printer maps
named HEADER, DETAIL, and TRAILER. Program B produces a hardcopy
version of the same report that ProgramA displays on a terminal.
ProgramB displays the partial HEADER map, displays the DETAIL print lines in a
floating area, and then displays the TRAILER map at the bottom of the
page. ProgramB uses the SET HEADER PAGE statement to force a page
eject.
- The number of lines in the floating area differs between the main
transaction and the main batch programs. However, the logic for data
retrieval, data manipulation, and displaying the HEADER and DETAIL maps is the
same for both programs.
Because of this, ProgramA and ProgramB were designed to use common functions
to retrieve data from the database, manipulate the data, and display the
HEADER and DETAIL maps.
-
This common code technique works in VisualAge Generator because the same
DISPLAY I/O option can be used for both display and printer maps. In
addition, the same SET HEADER PAGE statement can be used for both display and
printer maps. VisualAge Generator interprets the DISPLAY I/O option and
the SET map PAGE statement based on the specific program it is testing or
generating.
- EGL requires different statements for display and print forms -- display
and clearScreen for a text form; print and pageEject for a print
form. In VisualAge Generator Compatibility mode, the display statement
is tolerated for a print form. However, clearScreen only applies to
text form output, even in VisualAge Generator Compatibility mode.
-
A less typical example is the use of a common error handler function called
SET-MESSAGE-TEXT which retrieves message text from a VAGen table called
MSGTBLE and stores it in a function parameter called MESSAGE-TEXT, where
MESSAGE-TEXT is a shared data item.
-
Assume that SubsystemA and SubsystemB run in different CICS regions. In
this case, the two subsystems can each provide their own definition of the
MSGTBLE and their own definition of the MESSAGE-TEXT function
parameter. This might occur if the subsystems provide different size
error message fields on their respective map definitions.
-
VisualAge Generator uses the definition that is currently loaded in the
workspace when it generates a program. As long as each subsystem always
loads its own definition of the MESSAGE-TEXT data item into the workspace
before test or generation, VisualAge Generator will use the definition that is
correct for that subsystem. The disadvantages of this technique are
that you must control what is in the workspace when you generate and you
cannot have both subsystems in the workspace at the same time.
- EGL permits you to have both subsystems in the workspace at the same
time.
In this situation, EGL uses a combination of the EGL build path, import
statements, and the containerContextDependent property for the
SET-MESSAGE-TEXT function to resolve the reference to the MESSAGE-TEXT data
item definition.
-
A slightly different example is the use of a common error record called
ERROR-RECORD which contains a shared data item called MESSAGE-TEXT2.
- Assume that SubsystemA and SubsystemB have different definitions of
MESSAGE-TEXT2. This might occur if the subsystems need to build message
text for different screen sizes.
-
VisualAge Generator uses the definition that is currently loaded in the
workspace when it generates a program. As long as each subsystem always
loads its own definition of MESSAGE-TEXT2, VisualAge Generator will use the
definition that is correct for that subsystem. The disadvantages of
this technique are similar to the SET-MESSAGE-TEXT function example.
You must control what is in the workspace when you generate and you cannot
have both subsystems in the workspace at the same time.
- EGL permits you to have both subsystems in the workspace at the same
time.
In this situation, EGL uses a combination of the EGL build path, import
statements, and the containerContextDependent property for the ERROR-RECORD to
resolve the reference to the MESSAGE-TEXT2 data item definition.
Common code is generally code that is used in many programs. You
need to include the common code in every migration set because it influences
the migration tool in the following ways:
- If common code is available, the migration tool is able to resolve most
ambiguous situations. This minimizes or eliminates the code changes you
must do manually.
-
If common code is available the migration tool can properly set the EGL build
path for projects and include the correct import statements for your EGL
files. This minimizes the number of EGL build path changes and
additional import statements you must do manually.
-
The first time the migration tool migrates a part version, the tool stores the
EGL created for the part into the migration database. The original
External Source Format is also retained in the migration database. If
another migration set uses the same part version, the migration tool uses the
original External Source Format for reference when creating EGL for the new
parts in the additional migration set, but does not convert the part to EGL
again. The migration tool also uses the EGL for the part version when
building the EGL projects, packages, and files for the additional migration
set.
This technique provides the necessary reference information for the migration
tool to resolve ambiguous situations during cross-part migration, while
improving performance by only migrating each part version one time.
To ensure the best possible migration, when you are migrating a subsystem, you
should always include Corporate Common Code and the Subsystem Common Code in
your migration set.
[ Top of Page | Previous Page | Next Page | Table of Contents | Index ]
(C) Copyright IBM Corporation 1992, 2005. All Rights Reserved.