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 Oracle Tuxedo Application Rehosting Workbench COBOL Converter chapter of this guide.The following file organizations handled by z/OS can be migrated using the Rehosting Workbench to Oracle databases: VSAM RRDS, ESDS and KSDS.The Oracle Tuxedo Application Rehosting Workbench File-To-Db2/luw (udb) 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 Db2/Luw(udb) tables is dependant on the results of the Oracle Tuxedo Application Rehosting Workbench 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 the Rehosting Workbench COBOL converter, subject to the limitations described in COBOL Description.
Listing 6‑1 COBOL COPY SampleListing 6‑2 COBOL COPY Discrimination RulesListing 6‑3 Non-equivalent Redefinition ExampleListing 6‑4 Related Discrimination RulesListing 6‑5 Technical Redefinition Initial Situation
This section describes the reengineering rules applied by the Rehosting 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.
• Oracle Tuxedo Application Rehosting Workbench adds a technical column: *_SEQ_NUM NUMERIC(8).
•
• Oracle Tuxedo Application Rehosting 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 6‑1 Picture Clause Re-engineering 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 6‑7 Example VSAM Copy DescriptionListing 6‑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).
• $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 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 6‑9 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.Each VSAM file to be migrated must be listed.
Table 6‑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 6‑10 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 6‑3 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. Listing 6‑11 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 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.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 the Rehosting Workbench File-To-Db2/luw (udb) 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 6‑4 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 $HOME/trf/SQL/file/<schema name> 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 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/file/<schema name>) should be installed on the target platform (runtime).
Table 6‑5 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: