rpp --automaticMigration
This command produces a command file that can be used to run a complete migration: import, Macro dispatch, optional modification of the default generation target, and migration help. You can indicate an option for general and z/OS® projects to generate the COBOL sources in different projects and separate the metadata files. By default, the synchronization of the source codes with their design is run for a journal import but you can specify an option to adapt this synchronization.
Syntax
rpp.bat --automaticMigration [options]Parameters
Options | Comments | Required | Default values |
---|---|---|---|
--data | Full path to the workspace | Yes | |
--log | Log file name The beginning of this file reminds the parameters that were entered to run the Pacbase migration procedures. |
No | trace.log |
--from | Name of the folder that contains the files required
for the migration:
|
Yes | |
--location | This parameter is used to replace the name of the target location for the import commands with the required value. It is also used to name the file that is produced by the automatic migration command: location.txt. | Yes | |
--separateCobolProject | Option available on general and z/OS projects. If this option is indicated, the COBOL sources will be generated in a separate project that is named after the project of its model instance, with a _COB suffix. |
No | |
--cobolProjectType | Type of the project that is to contain the COBOL sources:
|
No | G |
--separateMapFolder | Option to migrate Screen maps into a specific folder | No | map |
--separateMetadataFiles | Option to separate the metadata files | No | |
--pdpRootPath | Path name of the pdp metadata file | No | pdp |
--previousSessionFolder | Path to the COBOL files of a previous Pacbase session, if more than one session is migrated into the same
workspace. This parameter reduces the migration time because the COBOL files that are identical in both sessions (except for the Pacbase constants and the generation date) are not imported again. |
No | |
--validationFile |
Full path of the validation.xml file, which contains the validation types. This file is automatically recognized in the preferences of the migration validation. The migration validation then automatically runs at the same time as the migration help to reduce the migration time. |
No |
|
--projectsToSynchronize | List of the projects whose source codes must be synchronized with their
design. They must be separated with commas. This option is valid only when a journal is imported. If you specify this option and assign it the value NONE, no source code is synchronized. If this option is not specified, the source codes of all the projects are synchronized. |
||
--noMigratedFile | Full path to the file that contains the list of Programs,
Screens, or Servers whose COBOL files must not be migrated upon a multi-session migration
(MIBR procedure) or progressive migration (MIBJ procedure).
Each time one of the procedures is run, the updated list is reexported. You can take it into account
each time a session or the journal is imported by specifying the --noMigratedFile option. The COBOL files of the new instances that are integrated in the updated list are
then automatically removed from the workspace if they had been previously imported. The file that contains the instances list must have been previously copied into the migration directory, possibly renamed (userNMig for example), and assigned a .txt extension. You can specify the --noMigratedFile option in the automatic migration command. If you do not use this command, you can specify the option in the import command or journal import command. |
No |
- A file with a .ta2 extensionNote: The Pacbase version number is included in the .ta2 file. If the version in this file is not compatible with the current version of Rational® Programming Patterns, the import is not run and an error is generated. The control does not go down to the subversion level (Y09A for example).
If the migration results from the running of the MIBR or MIBA procedures, this file must be named MIBR.ta2.
If the migration results from the running of the MIBJ or MIBU procedures, the name of this file is not fixed but must be different from MIBR.ta2.
- MIMA.cblgen
Other .cblgen files with other names can exist in the folder. Such is the case, for example, if you changed the source code of a Macro manually. All the .cblgen files are then taken into account by the automatic migration.
- MIA1.txt
- MIA2.txt
- MIA3.txt
- MIA4.txt
- COBOL_MIA1.txt for the sources that contain the complete COBOL of Programs. These sources are produced by MIA1.
- COBOL_MIA2.txt for the sources that contain the complete COBOL of standard Screens. These sources are produced by MIA2.
- COBOL_MIA3.txt for the sources that contain the complete COBOL of TUI clients. These sources are produced by MIA3.
- COBOL_MIA4.txt for the sources that contain the complete COBOL of Servers. These sources are produced by MIA4.
- CONTROL_COBOL_MIA1.txt for the sources that contain the control COBOL of Programs. These sources are produced by MIA1.
- CONTROL_COBOL_MIA2.txt for the sources that contain the control COBOL of standard Screens. These sources are produced by MIA2.
- CONTROL_COBOL_MIA3.txt for the sources that contain the control COBOL of TUI clients. These sources are produced by MIA3.
- CONTROL_COBOL_MIA4.txt for the sources that contain the control COBOL of Servers. These sources are produced by MIA4.
- transform.txt if COBOL files have been generated with a Microfocus COBOL type (COBOL type 3 : UNIX, Windows). This file corrects the generated COBOL syntax to make it compatible with the IBM® compiler. It is available in the installation directory of your Rational Software Delivery Platform, under rpp/migration. You must copy it into the migration directory.
- errorLabels.txt if you want to create Error Message instances from the
Pacbase error message generation command lines. You must
create this file and add it to the migration directory. This file must contain as many lines as Error Message instances to be created. Each line
must conform to the following syntax:
- The Pacbase generation command (GED, GEO, GEC, or GES).
- The generation Library.
- After a space, the associated Data Structure or Dialog.
- After a space, an optional generation option (C1 to C4). If this option is not indicated, C1 is the default value.
- After a space, the name that will be given to the new Error Message instance.
Example: GEDCEN DD C1 ERROR1 - specificErrorLabel.txt if you want the Pacbase specific error message file (extracted with the MILA procedure) to be copied into your workspace and to be recognized by default in the Error Message instances. To do so, retrieve the MILA result file, rename it specificErrorLabel.txt, and add it to the migration directory.
- inputzCompMap.txt. This optional file is not automatically generated. If
you need it, you must create it manually and add it to this folder. You use it to map Pacbase sets of optional control cards with z/OS language definitions.
This file must contain one line for each mapping, according to the following format:
XX LangageDefinition.
XX is the set of control cards (front and back) in Pacbase on 2 characters. If there is no control card in front or back, you must enter a space in its place.
LangageDefinition is the target language definition in Rational Team Concert™. It is separated from the set of control cards by a space. - librariesFilter.txt file if you want to filter the results of the extraction to import the data of some Libraries only. This file must contain one Library per line. You can use it upon an initial migration (MIBR procedure) or a progressive migration (MIBJ procedure).
- A COBOL_FOLDER folder and a CONTROL_COBOL_FOLDER folder. These folders both contain four directories that correspond to the four patterns (pacprogram or MIA1, pacscreen or MIA2 for example). Each of these four directories contains a subdirectory for each Library. The .cbl files are stored in the subdirectory that corresponds to the initial Library of the generated instance.
- A location.txt command file (where location is the
name of the location). You must then run the rpp.bat --commands command with
this file as an option.
The migrated data is filtered if a librariesFilter.txt file is present in the migration input directory. The command file automatically sets the --librariesFilterFile option in the import commands (rpp --import and rpp --importJournal) to narrow the scope of the import. Moreover, the migration help command (rpp --migrationHelp) applies to the generatable entities of the migrated Libraries only, which reduces the duration of this phase.
- An ORIGINAL_COBOL directory if COBOL files have been modified by the
transform.txt files. This new directory contains the original version of these
COBOL files before the modification.Note: To restore the syntactic control on the modified COBOL files, you must select the preference COBOL syntax for type 3 (UNIX, Windows) certified as compatible with IBM COBOL for AIX syntax after the migration. You access it by selecting .
- A specificerrorLabel.txt in the .INTER project of the workspace. This file is the copy of the identically-named file that is present in the migration input directory. This file will then be recognized by default if no file is indicated in the Specific error message file field of the Error Message instances in the location.
- An outputzCompMap.txt file that maps Pacbase sets of optional control cards with z/OS language definitions. It is produced if the --cobolProjectType parameter is assigned the value Z and if the inputzCompMap.txt file exists in the folder. The outputzCompMap.txt will be used by the migration to create as many mapping files as z/z/OS COBOL projects for the rpp-zcompmap command. By default, these files will be generated in the metadata/zCompMap directory of the migration workspace.
- An MIBR_modified.ta2 file if you have indicated, in an errorLabels.txt file, that Error Message instances are to be created upon import. The MIBR_modified.ta2 file is a copy of the MIBR.ta2 file but it also contains the Error Messages to be created. If this file exists, it is automatically used instead of the MIBR.ta2 file when the import command is run.
At the end of the log file, a counter displays the number of created or modified COBOL files.