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.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 the Rehosting Workbench to Oracle databases: VSAM RRDS, ESDS and KSDS.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.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.Table 5‑1 lists the examples of COBOL description format.
Table 5‑1 COBOL Description Format Example Listing 5‑1 COBOL COPY ExampleListing 5‑2 COBOL COPY Discrimination RulesThe copy name of the COBOL description is: <COPY name>.cpyListing 5‑3 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 5‑4 Related Discrimination RulesListing 5‑5 Technical Redefinition Initial SituationThis 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.
• Oracle Tuxedo Application Rehosting Workbench adds a technical column: *_SEQ_NUM NUMBER(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 VSAM files to Oracle tables:
Table 5‑2 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 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).
• $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 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:unixIn this example, fields longer than 29 characters become VARCHAR, fields shorter than 30 characters become CHAR fields.
Table 5‑3 Datamap Parameters
Note: 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.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 5‑4 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: 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.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 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‑5 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> 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.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 5‑6 lists environment variables that should be set on the target platform.
Table 5‑6 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 of the Rehosting 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: