For a comprehensive view of the migration process, see the Oracle Tuxedo Application Rehosting Workbench Reference Guide for the chapters Data Conversion and Cobol Conversion as well as the the Rehosting Workbench Cobol Converter chapter of this guide.The Oracle Tuxedo Application Rehosting 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 Oracle Tuxedo Application Rehosting Workbench File-to-File Converter.The migration of data in VSAM files to Oracle tables is dependant on the results of the Oracle Tuxedo Application Rehosting Workbench Cataloger. 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 the Rehosting Workbench Cobol converter, subject to the limitations described in COBOL description.
Listing 5‑1 Cobol COPY sampleListing 5‑2 Cobol COPY discrimination rulesListing 5‑3 Non-equivalent redefinition exampleListing 5‑4 Related discrimination rulesListing 5‑5 Technical redefinition initial situation
This section describes the reengineering rules applied by the Rehosting 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.the Rehosting Workbench adds a technical column: *_SEQ_NUM NUMBER(8).the Rehosting Workbench adds a technical column *_RELATIVE_NUM.
Table 5‑1 Picture clause reengineering
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 5‑7 Example VSAM copy descriptionListing 5‑8 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).
•
•
• 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 the Rehosting 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 5‑9 db-param.cfg example
• target_rdbms_name: oracle
•
• target_os:unix
Table 5‑2 Datamap parameters 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 5‑10 Example datamap file: Datamap-STFILEORA.re
Table 5‑3 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. Listing 5‑11 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 the Rehosting 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 the Rehosting Workbench.Installation option. Places the components in the installation directory. This operation uses the information located in the file-move-assignation.pgm file.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 the Rehosting Workbench File-To-Oracle 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 5‑4 Location of components Example: loadfile-ODCSF0.ksh RELFILE-ODCSF0.cbl The generation log files Mapper-log-<configuration name> can be used to resolve problems. $HOME/trf/SQL/file/<schema name> This section describes the tasks of unloading, transfer and reloading using the components generated using the Rehosting 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/rdbms/<schema name>) should be installed on the target platform (runtime).
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.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).When executing file.sh -gmi $HOME/trf STFILEORA the following message appears:When executing file.sh -gmi $HOME/trf STFILEORA1 the following message appears:When executing: file.sh -gmi $HOME/trf STFILEORA the following message appears:When executing: file.sh -gmi $HOME/trf STFILEORA the following message appears: