![]() |
![]() |
![]() |
![]() |
![]() |
There are five clearly distinct environments necessary to carry-out a rehosting project. These include two source (pre-migration) environments and three target (post-migration) environments as described below:
1. A current production source environment for the assets to be converted.
2. A test source environment for storing and isolating the operations extracted from the production environment and for creating a test database.
3. A test target environment for running, tuning and testing the converted assets.
4. An integration target environment, which is used to host all activities such as integration, operations migration or pre switch-over processing.
5. A production target environment for the converted and tested assets.
Table 1‑1 Project Environments
Table 1‑2 Project Phases Figure 1‑1 Project Phases and ProcessesFigure 1‑2 Language MigrationFigure 1‑3 Data MigrationFigure 1‑4 Migration Architecture
• Run Eclipse using the "-clean" option.To install the plug-in you must copy the com.oracle.tuxedo.wbplugin_x.x.x.x.jar file (located in utils/eclipse_plugin sub-directory under the Tuxedo ART Workbench installation directory) to the $ECLIPSE_HOME/plugins directory and then restart Eclipse.
•
• The cataloger output reports are shown in the report view (as shown in Figure 1‑5), with tabs for each report. The view is integrated with ART perspective. Click the Close button to close it or re-open it from main menu.Figure 1‑5 Report View Example
•
Table 1‑3 Color Warning
• You can also refresh the content by clicking the Refresh button on the menu bar of report view.The progress monitor view allows you to see which source file or schema is being processed. A source tree is initially displayed to show the structure of sources or schemas in the current project organized by source types as shown in Figure 1‑6.Figure 1‑6 Sample of Progress Monitor ViewThe Plug-in has a Migration Process Cheat Sheet to guide you though the conversion tasks step-by-step. To open the cheat sheet click “Help->Cheat Sheets” on main menu, and then select the cheat sheet Create ART migration project for STDB2ORA sample under ART group.For a more detailed menu item example, see Appendix B: Appendix C: Oracle Tuxedo Application Rehosting Workbench Logs
•
•
•
•
•
•
•
• Figure 1‑7 provides an Tuxedo ART Workbench high-level workflow illustration.Figure 1‑7 Tuxedo ART Workbench High-Level Workflow
Table 1‑4 Preparation Tasks
Table 1‑5 Analysis Tasks
Table 1‑6 Conversation Tasks
Table 1‑7 Configuration Tasks
Note: Currently, only the connection to Oracle Database as a client is supported. The connection string is "sqlplus user/password@connect_identifier".
Table 1‑8 Tasks
Table 1‑9 Deployment Tasks The process of running the converted application on the target platform for testing. Missing "Run tasks are listed in Table 1‑10.
Table 1‑10 Run Tasks
Table 1‑11 Reset Tasks Figure 1‑8 Select a WizardFigure 1‑9 Project NameFigure 1‑10 Select the Workbench install Directory.Figure 1‑11 Specify Root Directory Source FilesFigure 1‑12 Choose Database and CompilerAfter creating a new ART project, you must configure the project properties in the project properties page as shown in Figure 1‑13.Figure 1‑13 Project Properties PageMost of the configurable options in Tuxedo ART Workbench can be configured in the project properties pages. It provides an easy way for to view and modify Tuxedo ART Workbench configuration options. Those options are organized by type. For more information, see "Description of Configuration Files" in the Tuxedo ART Workbench Reference Guide.
Tip: Type command "uconv -l" in the shell lists encoding names.The newline marker is different between DOS systems (using 0x0D0A) and UNIX/Linux systems (using 0x0A).
• *.cpy - COPYBOOK*.cbl - COBOL Source Program, including CICS, Batch and Sub*.jcl - JCL Script*.bms, *.map - BMS Map*.sysin - SYSIN files*.rdo - RDO files*.proc, *incl - JCL libraries
In order to illustrate all of the migration activities performed and how to use Tuxedo ART Workbench Cataloger to determine whether the asset is consistent and can be migrated to the target platform, the Simple Application STFILEORA will be used. STFILEORA is provided with Tuxedo ART Workbench set of tools.Listing 1‑1 Sample Application Hierarchy
•
•
•
•
•
• It is recommended that each time you work on a project using Tuxedo ART Workbench to set certain environment variables that will be useful later. The only environment variable that is mandatory is REFINEDISTRIB; others can be used for simplification reasons.Table 1‑12 explains the usage of proposed variables.
Table 1‑12 Rehosting Workbench Environment Variables Variable used by Tuxedo ART Workbench Listing 1‑2 Extract from Simple Application .project File:
2. Copy a sample of the configuration (system.desc, version.mk, options-catalog, etc.) files from Simple Application to $PROJECT/param directory to make any necessary modifications.
3. Copy the makefile from the source (SimpleApp) into $PROJECT/source.
4. Create a file .project under $PROJECT and initialize it with variables listed in Setting Environment and Working Variables. Variables in the file are to be exported each time you work on the project.
5. Copy the prepared source files to $PROJECT/sourceListing 1‑3 System Description for Simple ApplicationIn the Simple Application example we use only three options, of course other options can be used; see the Tuxedo ART Workbench Reference Guide for a full list of options.Listing 1‑4 Global Options File for the Simple Application
• ${REFINEDIR} is the directory where Tuxedo ART Workbench tools are installed.
• $(CATALOG) is the version of the Cataloger to be used
• $(SYSTEM) is the path of the system description file.From directory $LOGS/catalog execute the command:Listing 1‑5 Parsing ExamplesThe result of this step is the binary file named symtab-SampleApp.pob that represents inter-component information.Listing 1‑6 Analysis ExampleListing 1‑7 Print Reports ExampleIn the Simple Application reports are generated in $PROJECT/source/Reports-SampleApp:
Table 1‑13 Inventory Status make is a UNIX utility intended to automate and optimize the construction of targets (files or actions).We highly recommend using make to perform the different operations that compose the migration process because this enables you to:You should have a descriptor file named makefile in the source directory in which all operations are implemented (a makefile is prepared in the source directory during the initialization of a project).The following two sections describe the make configuration and how to use the Cataloger functions through make.The version.mk configuration file in $PARAM is used to set the variables and parameters required by the make utility.Listing 1‑8 Extract From version.mk for Simple ApplicationThe contents of the makefile summarize the tasks to be performed:From the $SOURCE directory execute the command:The log file is generated in $LOGS/parseSample: parsing the program BATCH/PGMMB02.cblThe log file is generated in $LOGS/parseThe log file is generated in $LOGS/catalogFor example, if you developed you own script (report.sh) to generate a customized report based on basic cataloguing reports, place your script in $TOOLS directory.
2. Modify makefile.debug changing REAL_CMD to COMMENTWhen migrating from a z/OS source platform to a target platform, the first question to ask, when VSAM is concerned, is whether to keep a file or migrate the data to an Oracle table.Table 1‑14 lists the file organizations handled by z/OS and indicates the organization proposed on the target platform:
Table 1‑14 z/OS to UNIX File Organizations Files that are part of a PDS are identified as such by their physical file name, for example: METAW00.NIV1.ESSAI(FIC).Generation Data Group (GDG) files are handled specially by the unloading and reloading components in order to maintain their specificity (number of GDG archives to unload and reload). They are subsequently managed as generation files by Oracle Tuxedo Application Runtime Batch (for more information, see the Oracle Tuxedo Application Runtime Batch Reference Guide). On the target platform these files have a LINE SEQUENTIAL organization.The migration of z/OS files to UNIX/Linux is dependant on the results of the Tuxedo ART Workbench Cataloger (for more information, see Analyze). It does not have any impact on the conversion of COBOL components or the translation of JCL components.For each candidate file for migration, its structure should be described in COBOL format. This description is used in a COBOL copy by the Tuxedo ART Workbench COBOL converter, subject to the limitations described in COBOL Description.
Note: The populate.sh utility (located in REFINEDIR/scripts/file/populate.sh), can be used to help generate these two configuration files automatically. For more information, see REFINEDIR/scripts/file/README.txt.
•
Listing 1‑9 COBOL COPY SampleListing 1‑10 COBOL COPY Discrimination RulesThe copy name of the COBOL description is: <COPY name>.cpyListing 1‑11 Non-equivalent Redefinition ExampleListing 1‑12 Related Discrimination RulesListing 1‑13 Technical Redefinition Initial SituationListing 1‑14 Technical Redefinition Potential Expected Results
• $PARAM for:
•
• $PARAM/file for:
•
• For a File-to-File conversion you must create these files yourself.are automatically placed in the file structure during the installation of Tuxedo ART Workbench . If specific versions of these files are required for particular z/OS files they will be placed in the $PARAM/file file structure.The following examples show the configuration of three files; two QSAM files and one VSAM KSDS file. There are no discrimination rules to implement for these files.Listing 1‑15 db-param.cfg ExampleSpecifies a mapping table file between EBCDIC (z/OS code set) and ASCII (Linux/UNIX code set) hexadecimal values; if hexa-map-file is not specified, a warning will be logged.
Table 1‑15 Datamap Parameters
Note: In the following example, the first two files are QSAM files, the organization is therefore always sequential. The PJ01AAA.SS.VSAM.CUSTOMER file is a VSAM KSDS file and the organization is therefore indexed. The parameters, keys offset 1 bytes length 6 bytes primary, describe the key. In this example, the key is six bytes long starting in position 1.Listing 1‑16 Example Datamap File: Datamap-FTFIL001.re
Table 1‑16 Mapping Parameters During the generation, the string #VAR:RECS-SOURCE# will be replaced by the directory name where the copy files are located: $PARAM/file/recs-sourceThe name of the copy file BCOAC01E.cpy is freely chosen by the user when creating the file. REC-ENTREE corresponds to the level 01 field name in the copy file.
Note: You cannot use hyphens (-) in logical names.
Notes: Listing 1‑17 Example Mapper File: mapper-FTFIL001.reCreate a $PARAM/file/recs-source directory to hold the copy files.Once the COBOL Description files have been prepared, the copy files described in the mapper-<configuration name>.re file should be placed in the $PARAM/file/recs-source directory.If you use a COBOL copy book from the source platform to describe a file (see note in COBOL Description), then it is the location of the copy book that is directly used in the mapping parameter file as in the "COPY/ODCSF0B.cpy" example above.To generate the components used to migrate z/OS files Tuxedo ART Workbench uses the file.sh command. This section describes the command.file.sh — Generate z/OS migration components.file.sh [ [-g] [-m] [-i <installation directory>] <configuration name> | -s <installation directory> (<configuration name>,...) ]file.sh generates the components used to migrate z/OS files using Tuxedo ART Workbench .Generation option. The unloading and loading components are generated in $TMPPROJECT using the information provided by the configuration files.Installation option. Places the components in the installation directory. This operation uses the information located in the file-move-assignation.pgm file.Not applicable to File-to-File migration except when the attributes clause is set to LOGICAL_MODULE_ONLY.The unloading and loading components generated with the -i $HOME/trf option are placed in the following locations:
Table 1‑17 Location of Components The generation log files Mapper-log-<configuration name> can be used to resolve problems.When present, this file will be automatically executed at the end of the generation process. It will be called using the <configuration name> as an argument.The version.mk configuration file in $PARAM is used to set the variables and parameters required by the make utility.In version.mk specify where each type of component is installed and their extensions, as well as the versions of the different tools to be used. This file also describes how the log files are organized.The following general variables should be set at the beginning of migration process in the version.mk file:
• In addition, the FILE_SCHEMAS variable is specific to file migration, it indicates the different configurations to process.The make FileConvert command can be used to launch Tuxedo ART Workbench File-To-File Converter. It enables the generation of the components required to migrate z/OS files to a UNIX/Linux target platform.The make file launches the file.sh tool with the -g, -m and -i options, for all configurations contained in the FILE_SCHEMAS variable.When migrating VSAM files from a source platform to an Oracle UNIX target platform, the first question to ask, when VSAM is concerned, is whether to keep a file or migrate the data to an Oracle table.The following file organizations handled by z/OS can be migrated using Tuxedo ART Workbench to Oracle databases: VSAM RRDS, ESDS and KSDS.The Tuxedo ART Workbench File-to-Oracle Converter is used for those files that are to be converted to Oracle tables. For files that remain in file format, see Executing the File-to-File Generated Converter Programs.The migration of data in VSAM files to Oracle tables is dependant on the results of the Tuxedo ART Workbench Cataloger (for more information, see Analyze). The File-to-Oracle migration impacts the COBOL and JCL conversion and should be completed before beginning the COBOL program conversion work.For each candidate file for migration, its structure should be described in COBOL format. This description is used in a COBOL copy by Tuxedo ART Workbench COBOL converter, subject to the limitations described in COBOL Description.
Note: The populate.sh utility (located in REFINEDIR/scripts/file/populate.sh), can be used to help generate these two configuration files automatically. For more information, see REFINEDIR/scripts/file/README.txt.A COBOL description is related to each file and considered as the representative COBOL description used within the application programs. This description can be a complex COBOL structure using all COBOL data types, including the OCCURS and REDEFINES notions.
• Some words are reserved. A list is supplied in the Appendix of the Oracle Tuxedo Application Rehosting Workbench Reference Guide.Table 1‑18 lists the examples of COBOL description format.
Table 1‑18 COBOL Description Format Listing 1‑18 COBOL COPY ExampleListing 1‑19 COBOL COPY Discrimination RulesThe copy name of the COBOL description is: <COPY name>.cpyListing 1‑20 Non-equivalent Redefinition ExampleIn the above example, two fields (FV15-ZNPCP3 and FV15-ZNB2T) have different structures: an EBCDIC alphanumeric field in one case and a field composed of EBCDIC data and COMP2, COMP3 data in a second case.Listing 1‑21 Related Discrimination RulesListing 1‑22 Technical Redefinition Initial SituationListing 1‑23 Technical Redefinition Potential Expected ResultsThis section describes the reengineering rules applied by Tuxedo ART Workbench when migrating data from VSAM files to an Oracle database.
• Each table name is stipulated in the mapper-<configuration name>.re file using the table name clause.
• Tuxedo ART Workbench adds a technical column: *_SEQ_NUM NUMBER(8).
• Tuxedo ART Workbench adds a technical column *_RELATIVE_NUM.
• Tuxedo ART Workbench does not add a technical column unless duplicate keys are accepted; the primary key of the VSAM file becomes the primary key of the table.The following rules are applied to COBOL Picture clauses when migrating data from VSAM files to Oracle tables:
Table 1‑19 Picture Clause Re-engineering Becomes CHAR if length <= 2000Becomes VARCHAR2 if length > 2000
Note: If the parameter: file:char_limit_until_varchar is set in the db-param.cfg file, it takes precedence over the above rule.
•
• In the following example, the indexed VSAM file described in ODCSFOB uses as a primary key the VS-CUSTIDENT field.Listing 1‑24 Example VSAM Copy DescriptionListing 1‑25 Oracle Table Generated From VSAM FileVS_CUSTIDENT NUMBER(6) NOT NULL,VS_SEQ_NUM NUMBER(8) NOT NULL,VS_CUSTLNAME VARCHAR2(30),VS_CUSTFNAME CHAR (20),VS_CUSTADDRS VARCHAR2(30),VS_CUSTCITY CHAR (20),VS_CUSTSTATE CHAR (2),VS_CUSTBDATE NUMBER(8),VS_CUSTEMAIL VARCHAR2(40),VS_CUSTPHONE NUMBER(10),VS_FILLER VARCHAR2(100),
Note: The copy book ODCSFOB contains a field redefinition: VS-CUSTBDATE-G PIC 9(008), as this is a technical field, no discrimination rule is implemented. In this case, only the redefined field is created in the generated table VS_CUSTBDATE NUMBER(8).
• $PARAM for:
•
• $PARAM/file for:
•
• For a File-To-Oracle conversion you must create the Datamap-<configuration name>.re and mapper-<configuration name>.re files yourself.are automatically generated in the file structure during the installation of Tuxedo ART Workbench . If specific versions of these files are required for particular z/OS files they will be placed in the $PARAM/file file structure.For the db-param.cfg file, only the target and file parameters need to be adapted.Listing 1‑26 db-param.cfg Example
• target_rdbms_name: oracle
•
• target_os:unixIn this example, fields longer than 29 characters become VARCHAR, fields shorter than 30 characters become CHAR fields.Specifies a mapping table file between EBCDIC (z/OS code set) and ASCII (Linux/UNIX code set) hexadecimal values; if hexa-map-file is not specified, a warning will be logged.
Table 1‑20 Datamap Parameters
Note: The description of the different parameters used is provided in the Oracle Tuxedo Application Rehosting Workbench Reference Guide - File To File Convertor.The PJ01AAA.SS.VSAM.CUSTOMER file is a VSAM KSDS file and the organization is therefore indexed. The parameters, keys offset 1 bytes length 6 bytes primary, describe the key. In this example, the key is six bytes long starting in position1.Listing 1‑27 Example Datamap File: Datamap-STFILEORA.reA file parameter and its options must be included for every VSAM file to convert to an Oracle table. The following parameters must be set:
Table 1‑21 Mapping Parameters (ufas mapper STFILEORA) The name and path of the copy file BCOAC01E.cpy is freely chosen by the user when creating the file. VS-ODCSF0-RECORD corresponds to the level 01 field name in the copy file.
Note: The description of the different parameters used is provided in the Oracle Tuxedo Application Rehosting Workbench Reference Guide - File To File Convertor.Listing 1‑28 Example mapper File: mapper-STFILEORA.reOnce the COBOL Description files have been prepared, the copy files described in the mapper-<configuration name>.re file should be placed in the $PARAM/file/recs-source directory.If you use a COBOL copy book from the source platform to describe a file (see note in COBOL Description), then it is the location of the copy book that is directly used in the mapping parameter file as in the "COPY/ODCSF0B.cpy" example above.To generate the components used to migrate data from VSAM file to Oracle tables Tuxedo ART Workbench uses the file.sh command. This section describes the command.file.sh [ [-g] [-m] [-i <installation directory>] <configuration name> | -s <installation directory> (<configuration name>,...) ]file.sh generates the components used to migrate VSAM files by Tuxedo ART Workbench .Generation option. The unloading and loading components are generated in $TMPPROJECT using the information provided by the configuration files.Installation option. Places the components in the installation directory. This operation uses the information located in the file-move-assignation.pgm file.Enables the generation of the configuration files and DML utilities used by the COBOL converter. All configuration files are created in $PARAM/dynamic-config and DML files in <trf>/DML directory.The version.mk configuration file in $PARAM is used to set the variables and parameters required by the make utility.In version.mk specify where each type of component is installed and their extensions, as well as the versions of the different tools to be used. This file also describes how the log files are organized.The following general variables should be set at the beginning of migration process in the version.mk file:
• In addition, the FILE_SCHEMAS variable is specific to file migration, it indicates the different configurations to process.The make FileConvert command can be used to launch Tuxedo ART Workbench File-To-File Converter. It enables the generation of the components required to migrate z/OS files to a UNIX/Linux target platform.The make file launches the file.sh tool with the -g, -m and -i options, for all configurations contained in the FILE_SCHEMAS variable.The unloading and loading components generated with the -i $HOME/trf option are placed in the following locations:
Table 1‑22 Location of Components Example: loadfile-ODCSF0.ksh RELFILE-ODCSF0.cbl The generation log files Mapper-log-<configuration name> can be used to resolve problems. Nine COBOL programs are generated, their usage is described in the Oracle Tuxedo Application Rehosting Workbench Reference Guide.When present, this file will be automatically executed at the end of the generation process. It will be called using the <configuration name> as an argument.The following file organizations handled by z/OS can be migrated using Tuxedo ART Workbench to Oracle databases: VSAM RRDS, ESDS and KSDS.The Tuxedo ART Workbench File-To-File Converter is used for those files that are to be converted to Oracle tables. For files that remain in file format, the Oracle Tuxedo Application Workbench Reference Guide, File-to-File Converter.The migration of data in VSAM files to DB2/Luw(udb) tables is dependant on the results of the Cataloger. The File-To-Db2/luw (UDB) migration impacts the COBOL and JCL conversion and should be completed before beginning the COBOL program conversion work.This section describes the steps to be performed before starting the migration of VSAM files to DB2/Luw(udb) tables.For each candidate file for migration, its structure should be described in COBOL format. This description is used in a COBOL copy by Tuxedo ART Workbench COBOL converter, subject to the limitations described in COBOL Description.
Note: The populate.sh utility (located in REFINEDIR/scripts/file/populate.sh), can be used to help generate these two configuration files automatically. For more information, see REFINEDIR/scripts/file/README.txt.
• Some words are reserved. A list is supplied in the Appendix of the Oracle Tuxedo Application Rehosting Workbench Reference Guide.
Listing 1‑29 COBOL COPY SampleListing 1‑30 COBOL COPY Discrimination RulesListing 1‑31 Non-equivalent Redefinition ExampleListing 1‑32 Related Discrimination RulesListing 1‑33 Technical Redefinition Initial SituationListing 1‑34 Technical Redefinition Potential Expected Results
This section describes the reengineering rules applied by Tuxedo ART Workbench when migrating data from VSAM files to a DB2/Luw(udb) database.
• Each table name is stipulated in the mapper-<configuration name>.re file using the table name clause.
• Tuxedo ART Workbench adds a technical column: *_SEQ_NUM NUMERIC(8).
• Tuxedo ART Workbench adds a technical column *_RELATIVE_NUM.
• Tuxedo ART Workbench does not add a technical column unless duplicate keys are accepted; the primary key of the VSAM file becomes the primary key of the table.The following rules are applied to COBOL Picture clauses when migrating data from VSAMfiles to Oracle tables
Table 1‑23 Picture Clause Re-engineering PIC S9(4) BINARY is migrated as NUMERIC(5) Becomes CHAR if length <= 255Becomes VARCHAR if length > 255
Note: If the parameter: file:char_limit_until_varchar is set in the db-param.cfg file, it takes precedence over the above rule.
•
• In the following example, the indexed VSAM file described in ODCSFOB uses as a primary key the VS-CUSTIDENT field.Listing 1‑35 Example VSAM Copy DescriptionListing 1‑36 Oracle Table Generated From VSAM File
Note: The copy book ODCSFOB contains a field redefinition: VS-CUSTBDATE-G PIC 9(008), as this is a technical field, no discrimination rule is implemented. In this case, only the redefined field is created in the generated table VS_CUSTBDATE NUMBER(8).
• $PARAM for:
•
• $PARAM/file for:
•
• For a File-To-Db2/luw (UDB) conversion you must create the Datamap-<configuration name>.re and mapper-<configuration name>.re files yourself.are automatically generated in the file structure during the installation of Tuxedo ART Workbench . If specific versions of these files are required for particular z/OS files they will be placed in the $PARAM/file file structure.For the db-param.cfg file, only the target and file parameters need to be adapted.Listing 1‑37 db-param.cfg Example
• target_rdbms_name: udb
• target_os:unixIndicates the maximum field length of a COBOL alphanumeric (PIC X) field before the field be transformed into an DB2/Luw(udb) VARCHAR data type.In this example, fields longer than 29 characters become VARCHAR, fields shorter than 30 characters becomes CHAR fields.Specifies a mapping table file between EBCDIC (z/OS code set) and ASCII (Linux/UNIX code set) hexadecimal values; if hexa-map-file is not specified, a warning will be logged.Each VSAM file to be migrated must be listed.
Table 1‑24 Datamap Parameters
Note: The description of the different parameters used is provided in the Tuxedo ART Workbench Reference Guide, File To File Convertor.The PJ01AAA.SS.VSAM.CUSTOMER file is a VSAM KSDS file and the organization is therefore indexed. The parameters, keys offset 1 bytes length 6 bytes primary, describe the key. In this example, the key is six bytes long starting in position1.Listing 1‑38 Example Datamap File: Datamap-STFILEUDB.reA file parameter and its options must be included for every VSAM file to convert to an DB2/Luw(udb) table. The following parameters must be set:
Table 1‑25 Mapping Parameters (ufas mapper STFILEUDB) The name and path of the copy file BCOAC01E.cpy is freely chosen by the user when creating the file. Provide a name for the DB2/Luw(udb) table to be created. VS-ODCSF0-RECORD corresponds to the level 01 field name in the copy file.
Note: The description of the different parameters used is provided in the Oracle Tuxedo Application Rehosting Workbench Reference Guide - File To File Convertor.Listing 1‑39 Example Mapper File: mapper-STFILEUDB.reOnce the COBOL Description files have been prepared, the copy files described in the mapper-<configuration name>.re file should be placed in the $PARAM/file/recs-source directory.If you use a COBOL copy book from the source platform to describe a file (see note in COBOL Description), then it is the location of the copy book that is directly used in the mapping parameter file as in the "COPY/ODCSF0B.cpy" example above.To generate the components used to migrate data from VSAM file to DB2/Luw(udb) tables Tuxedo ART Workbench uses the file.sh command. This section describes the command.file.sh [ [-g] [-m] [-i <installation directory>] <configuration name> | -s <installation directory> (<configuration name>,...) ]file.sh generates the components used to migrate VSAM files by Tuxedo ART Workbench .Generation option. The unloading and loading components are generated in $TMPPROJECT using the information provided by the configuration files.Installation option. Places the components in the installation directory. This operation uses the information located in the file-move-assignation-db2luw.pgm file.Enables the generation of the configuration files and DML utilities used by the COBOL converter. All configuration files are created in $PARAM/dynamic-config and DML files in <trf>/DML directory.The version.mk configuration file in $PARAM is used to set the variables and parameters required by the make utility.In version.mk specify where each type of component is installed and their extensions, as well as the versions of the different tools to be used. This file also describes how the log files are organized.The following general variables should be set at the beginning of migration process in the version.mk file:
• In addition, the FILE_SCHEMAS variable is specific to file migration, it indicates the different configurations to process.The make FileConvert command can be used to launch Tuxedo ART Workbench File-To-File Converter. It enables the generation of the components required to migrate z/OS files to a UNIX/Linux target platform.The make file launches the file.sh tool with the -g, -m and -i options, for all configurations contained in the FILE_SCHEMAS variable.The unloading and loading components generated with the -i $HOME/trf option are placed in the following locations:
Table 1‑26 Location of Components The programs and JCL used for each unloading are generated for each <configuration name>. The programs and KSH used for each loading are generated for each <configuration name>.Example: loadtable-ODCSF0.ksh RELTABLE-ODCSF0.sqb Nine COBOL programs are generated, their usage is described in the Oracle Tuxedo Application Rehosting Workbench Reference Guide.One Embedded-SQL program for accessing the DB2/luw (udb) CUSTOMER table is generated:When present, this file will be automatically executed at the end of the generation process. It will be called using the <configuration name> as an argument.This section describes the reengineering rules applied by Tuxedo ART Workbench when migrating data from a DB2 database to an Oracle database.The list of DB2 objects that are included in the migration towards Oracle are described in Creating the Generated Oracle Objects.Migrated DB2 objects keep their names when migrated to Oracle except for the application of Tuxedo ART Workbench renaming rules (see Preparing and Implementing Renaming Rules).
Table 1‑27 DB2 to Oracle Data Types
Table 1‑28 DB2 to Oracle Column Properties <value> depends on DB2/z/OS data type. Renaming rules should be placed in a file named rename-objects-<schema name>.txt. This file should be placed in the directory indicated by the $PARAM/rdbms parameter.
•
• Tuxedo ART Workbench permits the download of CLOB and BLOB data types. The DB2 unloading utility downloads each row of CLOB or BLOB columns into a separate file (PDS or HFS dataset type). This utility (DSNUTILB) downloads data of all columns and NULL technical flags into a unique MVS member file, excepted for CLOB or BLOB columns which are replaced by the file name of the CLOB or BLOB separate file.Based on those two constraints, you should set correct parameters in db-param.cfg configuration file (see Implementing the Configuration Files).Tuxedo ART Workbench provides the transcoding for single byte data. However, if your DB2 data contains MBCS characters, you should choose DSNUPROC unloading utility and set csv data format. The MBCS transcoding is done by the transfer tools.Based on this constraint, you have to set correct parameters in db-param.cfg configuration file (see Implementing the Configuration Files).Listing 1‑40 DDL Example Before MigrationListing 1‑41 Oracle Table Example After MigrationListing 1‑42 Oracle Index Example After MigrationListing 1‑43 Oracle Constraint Example After MigrationFor a DB2-To-Oracle migration, a parameter must be set in the system.desc System Description File in the Cataloger that is used by all of Tuxedo ART Workbench tools:By default, if the SQL commands of the DB2 DDL are prefixed by a qualifier or an authorization ID, the prefix is used by Tuxedo ART Workbench as the name of the schema—for example, CREATE TABLE <qualifier or authorization ID>.table name.The schema name can also be determined by Tuxedo ART Workbench using the global-options clause of the system.desc file.The schema name can also be determined for each DDL directory by Tuxedo ART Workbench using the directory options clause of the system.desc file. For more information, see options-clause in Cataloger.options SQL-Schema = "<schema name>".
• are automatically generated in the file structure during the installation of Tuxedo ART Workbench . If specific versions of these files are required, they will be placed in the $PARAM/rdbms file structure.
• export TMPPROJECT=/$home/tmpListing 1‑44 Example db-param.cfg File
• target_rdbms_name: oracle
• Specifies a mapping table file between EBCDIC (z/OS code set) and ASCII (Linux/UNIX code set) hexadecimal values; if hexa-map-file is not specified, a warning will be logged.The following rdbms parameters indicate the date, timestamp, and time formats used by z/OS DB2 and stored in DSNZPARM:
• rdbms:date_format: YYYY/MM/DD
• rdbms:timestamp_format:YYYY/MM/DD HH24 MI SS FF6
• rdbms:time_format:HH24 MI SSThese parameters impact the reloading operations, COBOL date, and time manipulations. They are optional and only necessary if the DB2 database contains the DATE, TIME or TIMESTAMP fields.
WARNING: Correct setting of these parameters is essential.The following rdbms parameters are optional and only necessary if the DB2 schema contains CLOB or BLOB data types.
• If the length of target MVS dataset name is equal to “MIGR.SCH1.TAB1.COLUMN1” (22 characters), the maximum length of the string created by the JCL would be 32: 22 + 2 (parenthesis characters) + 8 (member name).
• If the length of target MVS directory name is equal to “/LOB/SCHEMA2/TABLE2/SECOND2” (27 characters), the maximum length of the string created by the JCL would be 36: 27 + 1 (slash character) + 8 (file name).
Note:
•
• If the database contains MBCS characters, you should choose "dsnuproc" as the unloading utility and "csv" as the unloading format.To generate the components used to migrate data from DB2 databases to Oracle databases, Tuxedo ART Workbench uses the rdbms.sh command. This section describes the command.rdbms.sh generates Tuxedo ART Workbench components used to migrate z/OS DB2 databases to UNIX Oracle databases.The following components are generated in $TMPPROJECT: DDL Oracle, the SQL*LOADER CTL files, the XML file used by the COBOL converter, and configuration files (mapper.re and Datamap.re). If an error or warning is encountered, the process will not abort.See Executing the Transcoding and Reloading Scripts for information about the SQL scripts created during the generation operation.This option has the same result as the -C option except the process will abort if an error or warning is generated.The unloading and loading components are generated in $TMPPROJECT using the information provided by the configuration files. You should run the rdbms.sh command with -C or -c command before this option.Removes the schema name from the generated objects (create table, table name, CTL file for SQL*LOADER, KSH). When this option is used, the name of the schema can also be removed from the COBOL components by using the option: sql-remove-schema-qualifier located in the config-cobol file (COBOL conversion configuration file) used when converting the COBOL components.Places the components in the installation directory. This operation uses the information located in the rdbms-move-assignation.pgm file.Enables the generation of the COBOL convertor configuration file. This file takes all of the unitary XML files of the project. All these files are created in $PARAM/dynamic-config.Example: rdbms-conv.txt rdbms-conv-PJ01DB2.xmlThe version.mk configuration file in $PARAM is used to set the variables and parameters required by the make utility.In version.mk specify where each type of component is installed and their extensions, as well as the versions of the different tools to be used. This file also describes how the log files are organized.The following general variables should be set at the beginning of migration process in the version.mk file:
• In addition, the RDBMS_SCHEMAS variable is specific to DB2 migration, it indicates the different schemas to process.The make RdbmsConvert command can be used to launch Tuxedo ART Workbench File-To-File Converter. It enables the generation of the components required to migrate a DB2 database to Oracle.The make file launches the rdbms.sh tool with the -C, -g, -r, -m and -i options, for all schemas contained in the RDBMS_SCHEMAS variable.The unloading and loading components generated with the -i $HOME/trf option are placed in the following locations:
Table 1‑29 Location of Components The generation log files produced when using the -c or -C options. rdbms-converter-<schema name> can be used to resolve problems. Location by <schema name> of the COBOL programs for DB load/unload. For the example in this chapter, there're two programs:When present, this file will be automatically executed at the end of the generation process. It will be called using the <schema name> as an argument.The main configuration file for translation is config-COBOL. It references other additional configuration files including:
• post-translation-file used when there is a need to perform some specific transformations. This file is to write manually.
• rdbms-conversion-file used when migrating DB2 to an Oracle database. This file is generated by the DB2-to-Oracle Convertor.
• conv-ctrl-list-file used when there are files to be converted to Oracle tables. This file should be generated by the File-to-File Converter.Listing 1‑45 config-cobol FileListing 1‑46 Sample Keywords FileThe tr-hexa.map file is a mapping table between EBCDIC (z/OS code set) and ASCII (Linux/UNIX code set) hexadecimal values.This script is located in REFINEDIR/scripts/convert-hexa-copy-to-map.sh.The script generates a tr-hexa.map file inside the current directory (it should be the PARAM directory).Listing 1‑47 Hexadecimal Code TranslationListing 1‑48 Sample of tr-hexa.mapThe rename-call-map-file is a mapping file between the old call name and the new one.It is used by some translation rules like Tr-Rename-External-Call and allows the user to make specific changes if needed.Place the following entry in the main configuration file config-cobol:Listing 1‑49 Example rename-call-map-fileThere are many possibilities allowed by the conversion command options (for more information, see theOracle Tuxedo Application Workbench Reference Guide). In this section the following examples are described:The distinction between programs (Batch and CICS) and sub-programs is mandatory; the option -cobol-type takes the following values:
• Batch programs: batch
• CICS programs: tpr
• Sub-programs: sub
Table 1‑30 Conversion Variables The COBOL Converter knows which are the batch programs to be translated from the system description file which describes all components. Where version is the release version, for example M2_L5_7
• To translate one program, for example the CICS program PGMM002.cbl, invoke the command:The log file is generated in the directory from where the command line is executed. If you want to have logs in a specific directory or file use -log-file-base followed by the path and name of the file to store the execution logs.In this example, the logs file will be generated in $LOGS/trans-cbl/translate-cobol-datetime. The logs directory should be previously created.Reconciliation of copybooks can be executed implicitly by the COBOL Converter or can be performed separately (through usage of the dcrp option, see Configuring config-COBOL) after allListing 1‑50 Copy Reconciliation
Table 1‑31 Compilation Variables Initializes environment variables (PATH.LD_LIBRARY_PATH...) Defined LD_LIBRARY_PATH Listing 1‑51 MF Compilation Options ExampleThe command to compile the programs BATCH/PGMMB00.cbl:Listing 1‑52 MF Compilation Example
• Update the version.mk configuration file according to your project properties and organization.Before using the make commands, the user should check the values in the version.mk supplied with the Simple Application:Listing 1‑53 version.mk ExampleAdd the missing configuration file or disable the line in the main configuration file if the file requested (in this example, tr-hexa.map) is unnecessary.Either the programs is not catalogued yet or the .pob file was wrongly deleted. Recatalog to generate the requested file.
•
• Generated by other Oracle Tuxedo Application Rehosting Workbench tools, the DB2-to-Oracle Convertor provides the JCL translator with the list of files to be converted to Oracle tablesIn addition to the AST of the JCL(s) to convert produced by the Cataloger, Tuxedo ART Workbench JCL Translator takes as input a main configuration file that specifies various aspects of the translation, such as:The main configuration file for the JCL translation is called config-trad-JCL.desc in this guide for use with the Simple Application application.The sub-files specified by the two options top-skeleton and bottom-skeleton represent respectively a header file and a footer file for the generated script. You can customize these files.Listing 1‑55 Example of top-ksh.txt Prolog CodeWhen files are converted to Oracle tables, the main configuration file must reference a sub-configuration file such as:This sub-file is generated by the File-to-File Converter. This file indicates to the JCL Translator, which are the files that will be converted to Oracle tables in order to correctly translate the steps involving these files. In our example PJ01AAA.SS.VSAM.CUSTOMER is the file to be converted.For example, when the JCL source involves files that will be converted to Oracle tables, the corresponding shell script uses the Batch Runtime function m_ProgramExec with the -b option to execute a COBOL program. The -b option indicates a connection to the database must be opened before executing the program. For example:The general options root-skeleton, target-proc, label-end, management of FSN, etc. are described in the JCL Translator section of the Oracle Tuxedo Application Workbench Reference Guide.Listing 1‑56 JCL Translator Configuration File for STFILEORA Simple Application (config-trad-JCL.desc ):Listing 1‑57 Launcher Entry in Main Configuration FileListing 1‑58 Example of Launcher CodeThe general options root-skeleton, target-proc, label-end, etc. are described in the JCL Translator section of the Oracle Tuxedo Application Rehosting Workbench Reference Guide.
Table 1‑32 Translator Variables The following commands can be used to execute the translation. Logs file are generated in $LOGS/trad-jcl.Listing 1‑60 Single JCL Translation ScriptListing 1‑61 List of JCL Translation ScriptListing 1‑62 All JCL Translation ScriptTo illustrate post-translation usage the following example add a comment after line containing m_ProgramExec IEFBR14 "" in the /prtvcust.ksh JCL script.
1. Write the following rule in renov-jcl.desc:To translate all the JCL in the $SOURCE file systemFrom the $SOURCE directory launch the command:The configurable items include Tuxedo location, IPC KEY, Machine Name, APPDIR and so on. For more information, see Oracle Tuxedo 12c Release 2 (12.2.2).For more information, see Oracle Tuxedo Application Runtime for CICS and Batch 12c Release 2 (12.2.2).Main function of Batch wizard is to generate jesconfig and setenv file for Batch runtime. The configurable items include Batch runtime location, JESROOT and so on.For more information, see Oracle Tuxedo Application Runtime for CICS and Batch 12c Release 2 (12.2.2).Prepare the environment of Batch runtime. For more information, see Oracle Tuxedo Application Runtime for CICS and Batch 12c Release 2 (12.2.2).Prepare the environment of CICS runtime. For more information, see Oracle Tuxedo Application Runtime for CICS and Batch 12c Release 2 (12.2.2).Prepare the environment of IMS runtime. For more information, see Oracle Tuxedo Application Runtime for IMS 12c Release 2 (12.2.2).After click "Finish", all the result of reloading will be placed in the location which user specify.This section describes the tasks of unloading, transfer and reloading using the components generated using Tuxedo ART Workbench (see Generating the Components).The components used for the unloading (generated in $HOME/trf/unload/file) should be installed on the source z/OS platform. The generated JCL may need adapting to specific site constraints including JOB cards, library access paths and access paths to input and output files (Data Set Name – DSN).The components used for the reloading (generated in $HOME/trf/reload/file) should be installed on the target platform (Runtime).
Table 1‑33 Variables and Their Target Platform The location of the generic reload and control scripts ($HOME/trf/reload/bin) If you choose COBOL-IT as target COBOL compiler and you use BDB as ISAM files in an open system, you must set these two environment variables, so that BatchRT can generate BDB format file, otherwise Micro Focus COBOL compatible file will be generated:export COB_EXTFH_LIB=/path_to_Cobol-IT/lib/libbdbextfh.soAn unloading JCL is generated for each z/OS file listed in the Datamap Parameter File (Datamap-<configuration name>.re). These unloading JCLs are named <logical file name>.jclunload
Note: The .jclunload extension should be deleted for execution under z/OS.For the example provided in Mapping Parameter File (mapper-<configuration name>.re), the generated programs are:When migrating a sequential file, a target COBOL LINE SEQUENTIAL output file is generated:When migrating a VSAM KSDS file, an INDEXED output file will be generated:For the example provided in Mapping Parameter File (mapper-<configuration name>.re), the generated scripts are:By default, the input file is located in the directory indicated by $DATA_SOURCE, and the output file is placed in the directory indicated by $DATA.These files are named with the logical file name used in the Mapping Parameter File (mapper-<configuration name>.re).This check uses the following option of the loadfile-<logical file name>.ksh
• If the Mapper-log-<configuration name> file contains any errors (see Common Problems and Solutions).When executing file.sh -gmi $HOME/trf STFILEORA the following message appears:The contents of the Mapper-log-STFILEORA log file include:A file to be migrated is present in the mapper-<configuration name>.re file and absent from the Datamap.<configuration name>.re file.When executing file.sh -gmi $HOME/trf STFILEORA1 the following message appears:The contents of the Mapper-log-STFILEORA1 log file include:When executing file.sh -gmi $HOME/trf STFILEORA2 the following message appears:The contents of the Mapper-log-STFILEORA2 log file include:When executing file.sh -gmi $HOME/trf STFILEORA3 the following message appears:The contents of the Mapper-log-STFILEORA3 log file include:The variable $PARAM has not been set.This section describes the tasks of unloading, transfer and reloading using the components generated using Tuxedo ART Workbench (see Generating the Components).The components used for the unloading (generated in $HOME/trf/unload/file) should be installed on the source z/OS platform. The generated JCL may need adapting to specific site constraints including JOB cards, library access paths and access paths to input and out put files (Data Set Name – DSN).The components used for the reloading (generated in $HOME/trf/reload/file) should be installed on the target platform (runtime).The components used for creating the Oracle objects (generated in $HOME/SQL/file/<schema name>) should be installed on the target platform (runtime).Table 1‑34 lists environment variables that should be set on the target platform.
Table 1‑34 Environment Variables and Their Platform The location of the generic reload and control scripts ($HOME/trf/reload/bin) The location of the SQL scripts used to create Oracle objects ($HOME/trf/SQL/file/<schema name>).
• An unloading JCL is generated for each z/OS file listed in the Datamap Parameter File (Datamap-<configuration name>.re). These unloading JCLs are named <logical file name>.jclunload. These JCL use the REPRO function of the IDCAMS utility to unload the files.
Note: The .jclunload extension should be deleted for execution under z/OS.These COBOL programs should be compiled with the target COBOL compiler using the options described in the COBOL converter section ofOracle Tuxedo Application Workbench Reference Guide.For the example provided in Mapping Parameter File (mapper-<configuration name>.re), the generated script is:By default, the input file is located in the directory indicated by $DATA_SOURCE, and the output file is placed in the directory indicated by $DATA.These files are named with the logical file name used in the Mapping Parameter File (mapper-<configuration name>.re) configuration file.This check uses the following option of the loadtable-<logical file name>.ksh
• If the Mapper-log-<configuration name> file contains any errors (see Common Problems and Solutions).Error messages and associated explanations are listed in the appendix of the Oracle Tuxedo Application Rehosting Workbench Reference Guide.When executing file.sh -gmi $HOME/trf STFILEORA the following message appears:The variable $PARAM has not been set.When executing file.sh -gmi $HOME/trf STFILEORA1 the following message appears:When executing file.sh -gmi $HOME/trf STFILEORA2 the following message appears:The contents of the Mapper-log-STFILEORA2 log file include:When executing: file.sh -gmi $HOME/trf STFILEORA the following message appears:When executing: file.sh -gmi $HOME/trf STFILEORA the following message appears:The name of the file to convert to an Oracle table does not correspond to the name present in the Datamap file.This section describes the tasks of unloading, transfer and reloading using the components generated using Tuxedo ART Workbench (see Generating the Components).The components used for the unloading (generated in $HOME/trf/unload/file) should be installed on the source z/OS platform. The generated JCL may need adapting to specific site constraints including JOB cards, library access paths and access paths to input and out put files (Data Set Name – DSN).The components used for the reloading (generated in $HOME/trf/reload/file) should be installed on the target platform (runtime).The components used for creating the Oracle objects (generated in $HOME/SQL/file/<schema name>) should be installed on the target platform (runtime).
Table 1‑35 Environment Variables on Target Platform The location of the generic reload and control scripts ($HOME/trf/reload/bin) The location of the SQL scripts used to create Oracle objects ($HOME/trf/SQL/file/<schema name>). This UNIX/Linux variable has to contain the directory of Oracle Tuxedo Application Runtime for Batch utilitiesAn unloading JCL is generated for each z/OS file listed in the Datamap Parameter File (Datamap-<configuration name>.re). These unloading JCLs are named <logical file name>.jclunload. These JCL use the REPRO function of the IDCAMS utility to unload the files.
Note: The .jclunload extension should be deleted for execution under z/OS.For the example provided in Mapping Parameter File (mapper-<configuration name>.re), the generated script is:By default, the input file is located in the directory indicated by $DATA_SOURCE, and the output file is placed in the directory indicated by $DATA.These files are named with the logical file name used in the Mapping Parameter File (mapper-<configuration name>.re) configuration file.This check uses the following option of the loadtable-<logical file name>.kshThe COBOL and Embedded-SQL access routines should be compiled using the target COBOL compilation options described in the Oracle Tuxedo Application Rehosting Workbench Reference Guide.
• If the Mapper-log-<configuration name> file contains any errors (see Common Problems and Solutions).When executing file.sh -gmi $HOME/trf STFILEUDB the following message appears:External Variable PARAM is not set!The variable $PARAM has not been set.When executing file.sh -gmi $HOME/trf STFILEUDB1 the following message appears:When executing file.sh -gmi $HOME/trf STFILEUDB2 the following message appears:The contents of the Mapper-log-STFILEUDB2 log file include:When executing: file.sh -gmi $HOME/trf STFILEUDB the following message appears:When executing: file.sh -gmi $HOME/trf STFILEORA the following message appears:The name of the file to convert to an DB2/luw (udb) table does not correspond to the name present in the Datamap file.This section describes the tasks of unloading, transfer and reloading using the components generated using Tuxedo ART Workbench (see Generating the Components).The components used for the unloading (generated in $HOME/trf/unload/rdbms) should be installed on the source z/OS platform. The generated JCL may need adapting to specific site constraints including JOB cards, library access paths and access paths to input and output files (Data Set Name – DSN).The COBOL programs for DB Load/Unload (generated in $HOME/trf/DSNUTILS/<schema name>) should be compiled and installed on the target platform (runtime).The components used for the reloading (generated in $HOME/trf/reload/rdbms) should be installed on the target platform (runtime).Table 1‑36 lists environment variables that should be set on the target platform.
Table 1‑36 Variables and Their Platform The location of the generic reload and control scripts ($HOME/trf/reload/bin) Directory containing the <table name>.ctl files used by the SQL*LOADER ($HOME/trf/reload/rdbms/<schema name>/ctl). Set according to the instructions in Oracle Tuxedo Application Workbench Reference Guide and other Oracle documentation. Set according to the instructions in Oracle Tuxedo Application Workbench Reference Guide and other Oracle documentation.The following variable should be set according to the information in the Oracle Tuxedo Application Rehosting Workbench Installation Guide:The reloading script loadrdbms-<table name>.ksh uses the SQL*LDR Oracle utility. Because this utility can access to ORACLE servers only, this script should be used in ORACLE servers and not with client connection. This variable should not contain an @<oracle_sid> string, especially for this reloading step.The package functions called by COBOL programs (converted by the COBOL Converter) should be installed on the target platform (runtime).The packages are located in REFINEDIR/convert-data/fixed-components/MWDB2ORA.plb and REFINEDIR/convert-data/fixed-components/MWDB2ORA_CONST.plb. You should adapt the MWDB2ORA_CONST.plb package and install these packages under SQLPLUS as documented in the DB2-to-Oracle Convertor.These files are written in another dataset or directory if the parameter rdbms:jcl_unload_lob_file_system is respectively set to pds or hfs.
• Example:ODCSF0X1.jclunloadThe files transferred to the target UNIX platform should be stored in the $DATA_SOURCE directory.The CLOB and BLOB data files should be transferred in binary mode and stored in the $DATA_SOURCE/<schema_name>.<column_name> directory.The MBCS data files should be transferred in text mode and properly transcoded by transfer tools. For more information, see Oracle Tuxedo Application Workbench Reference Guide.
Note: On MVS, the Rehosting Workbench attributes a six-character name to <column_name> to the dataset or directory, added with a digit number (1 for the first CLOB or BLOB column of the table, 2 for the second, ...). On UNIX/Linux platform, the loadrdbms.sh script uses the real column_name.The scripts creating Oracle objects (tables, index, constraints, …) are created in the $HOME/trf/SQL/rdbms/<schema name> directory. They should be executed in the target Oracle instance.The <schema name>.lst file contains the names of all of the tables in hierarchical sequence (parent table then child tables).Table 1‑37 lists the DB2 objects managed by Tuxedo ART Workbench and the name of the script used to create them:
Table 1‑37 DB2 Objects This file contains all the CREATE INDEXes associated with the table <target_table_name>. This file will not be generated if there are no indexes defined on the table <target_table_name> The programs should be compiled using the target COBOL compiler and the options documented in the Oracle Tuxedo Application Rehosting Workbench Reference Guide.The programs produce RECORD SEQUENTIAL files on output that will then be read by the SQL*LOADER utility.Listing 1‑65 FILE CONTROL Example – Extracted from Program: MOD_ODCSF0.cblloadrdbms-<table name>.ksh<table name>.ctl.For the example provided in Example of a Migration of DB2 Objects, the generated script is:
• If the rdbms-converter-<schema name>.log file contains any errors (see Common Problems and Solutions).Error messages and associated explanations are listed in the appendix of the Oracle Tuxedo Application Rehosting Workbench Reference Guide.When executing $REFINEDIR/$VERS/rdbms.sh -Cgrmi $HOME/trf PJ01DB2 STFILEORA the following message appears:When executing $REFINEDIR/$VERS/rdbms.sh -Cgrmi $HOME/trf SCHEMA the following message appears:When executing $REFINEDIR/$VERS/rdbms.sh -Cgrmi $HOME/trf PJ01DB2 the following message appears:When executing $REFINEDIR/$VERS/rdbms.sh -Cgrmi $HOME/bad-directory PJ01DB2 the following message appears:When executing $REFINEDIR/$VERS/rdbms.sh -c WWARN the following message appears:The DDL contains some unsupported features. Check the warning files. You can ignore this abort by replacing the -c option with -C option.
• Tuxedo ART Workbench Reference Guide