Table of Contents Previous Next PDF


File Convertor: Introduction

File Convertor: Introduction
This chapter introduces the Rehosting Workbench File Convertor used to migrate files from the source platform (z/OS) to Unix/Linux Micro Focus or COBOL-IT files or to RDBMS tables, it contains common explanations and usages for specific behaviors of those File Convertors.
You can combine the conversion target between files and RDBMS tables, depending on an optional clause in a Configuration file.
The File Convertor documentation is split into four parts:
File Convertor: Introduction: introduces the file convertors and explains common behavior.
File-to-File Converter: describes File-to-File conversion.
File-to-Oracle Converter: describes File-to-Oracle conversion.
File-to-Db2/luw (udb) Converter: describes File to Db2/luw conversion.
This chapter cdescribes the migration tools that are generated. The conversion is performed in the context of other components translated or generated by the other Oracle Tuxedo Application Rehosting Workbench tools.
Several configuration files need to be set, see List of the Input Components, before launching the conversion process.
The different objects generated are described in the target specific sections. Some objects are only generated when migrating VSAM files to Oracle, you can find PCO programs for Oracle, SQB programs for Db2/luw, SQL files, relational module, logical module, utilities, configuration files,unloading JCL and COBOL program conversion, ...
Overview of the File Convertor
Purpose
The purpose of this section and the target specific File Convertor sections is to describe precisely all the features of the Rehosting Workbench File Convertor tools including:
Detailed description of converted files and Oracle tables or Db2/luw (udb) tables on the target platform for each file.
Structure
See Also
The conversion of data is closely linked to the conversion of COBOL programs, see:
For information about the specific output components generated see:
File Organizations Processed
Note:
z/OS File Organizations
The Oracle Tuxedo Application Rehosting Workbench File Convertor supports different file organizations on the target platform.
Table 5‑1 lists the file organizations handled by z/OS.
 
File Conversion to File or to RDBMS Table
When migrating files 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 RDBMS table. For example, permanent files to be later used via Oracle or Db2/luw databases or files that needs locking at the record level.
Oracle Tuxedo Application Rehosting Workbench Configuration Name
A configuration name is related to a set of files to be converted. Each set of files can be freely assembled. Each configuration could be related to a different application for example, or a set of files required for tests.
File Descriptions and Managing Files With the Same Structure
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.
Once built, the list of files to migrate can be purged of files with the same structure in order to save work when migrating the files by limiting the number of programs required to transcode and reload data.
Using the purged list of files, a last task consists of building the files:
Datamap-<datamap name>.re
mapper-<mapper name>.re
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.
This COBOL description will often be more developed than the COBOL file description (FD). For example, an FD field can be described as a PIC X(364) but really contain a three times defined area including, in one case a COMP-3 based numerals table, and in another case a complex description of several characters/digits fields etc.
It is this developed COBOL description which describes the application reality and therefore is used as a base to migrate a specific physical file.
The quality of the file processing execution depends on the quality of this COBOL description. From this point, the COBOL description is not separable from the file and when referring to the file concerned, we mean both the file and its representative COBOL description. The description must be provided in COBOL format, in a file with the following name:
<COPY name>.cpy
Note:
COBOL Description Format
The format of the COBOL description must conform to the following rules:
COBOL Description and Related Discrimination Rules
Within a COBOL description there are several different ways to describe the same area, which means to store objects with different structures and descriptions at the same place.
As the same zone can contain objects with different descriptions, to be able to read the file, we need a mechanism to determine the description to use in order to interpret correctly this data area.
We need a rule which, according to some criteria, generally the content of one or more fields of the record, will enable us to determine (discriminate) the description to use for reading the re-defined area.
In the Rehosting Workbench this rule is called a discrimination rule.
Any redefinition inside a COBOL description lacking discrimination rules presents a major risk during the file transcoding. Therefore, any non-equivalent redefined field requests a discrimination rule. On the other hand, any equivalent redefinition (called technical redefinition) must be subject to a cleansing within the COBOL description (see the example below COBOL Description Format).
The discrimination rules must be presented per file and highlight the differences and discriminated areas. Regarding the files, it is impossible to reference a field external to the file description.
The discrimination rules are provided in the mapper file. The syntax is described in chapter Mapper File of this document.
List of the Input Components
The File Convertor needs input components to generate the migration components to be used on the source and target platforms. The Input Components required are:
List of templates: file-template.txt or file-template-db2luw.txt.
Transfer of components generated: file-move-assignation.pgm or file-move-assignation-db2luw.pgm.
Configuration file: Datamap-<configuration name>.re.
Configuration file: mapper-<configuration name>.re.
The two configuration files (mapper and datamap) are described in this section. The others are described in detail for each target output:
Datamap File
This is a configuration file used by the Rehosting Workbench file converter to add or modify information on the physical files of a system.
Each ZOS file to be migrated must be listed in this file; the file only contains the list of files to be migrated.
The Datamap file must be created in the directory: $PARAM/file with the complete name:
Datamap-<configuration name>.re
Where <configuration name> is the name of the current configuration used.
Datamap Syntax and Parameters
Listing 5‑1 Datamap File
data map <configuration name>-map system cat::<project name>
file <physical file name>
organization <organization>
[is-gdg limit <p> [scratch/noscratch] [empty/noempty]
[keys offset <n> bytes length <m> bytes primary]
[relkey size <m> bytes]
 
 
is-gdg limit <p> [scratch/noscratch] [empty/noempty]
p parameter value is used to specify the total number of generations that the GDG may contain.
scratch/noscratch parameters are mutually exclusive. Scratch parameter specifies that whenever an entry of the GDG is removed from the index, it should be deleted physically and uncataloged. Noscratch parameter specifies that whenever an entry of the GDG is removed from the index, it should be uncataloged but not physically deleted.
empty/noempty parameters are mutually exclusive. Empty specifies that all existing generations of the GDG are to be uncataloged whenever the generations of GDG reaches the maximum limit . Noempty specifies that only the oldest generation of the GDG is to be uncataloged if the limit is reached.
For indexed files, this clause is used to describe the key; where <n> is the start position and <m> is the length of the key.
Listing 5‑2 Datamap Example
data map STFILEORA-map system cat::STFILEORA
%% Datamap File PJ01AAA.SS.QSAM.CUSTOMER
file PJ01AAA.SS.QSAM.CUSTOMER
organization Sequential
%% Datamap File PJ01AAA.SS.VSAM.CUSTOMER
file PJ01AAA.SS.VSAM.CUSTOMER
organization Indexed
keys offset 1 bytes length 6 bytes primary
file PJ01AAA.SS.VSAM.CODPAY
organization Relative
relkey size 6 bytes
 
Mapper File
This is a configuration file used by the Rehosting Workbench File Convertor to associate each file to migrate with:
Each z/OS file listed in the Datamap File, must be described in the mapper file.
Mapping File Clause
Mapping files consists in choosing, for each physical file to be treated, the associated COBOL description and discrimination rules.
Listing 5‑3 Mapper File Clause Structure
file <Physical file name>
[converted] [transferred]
table name <Table Name>
include <"path/Copy name">
map record <record name> defined in <"path/Copy name">
source record <record name> defined in <"path/Copy name">
logical name <logical file name>
converter name <converter name>
[attributes <attribute clause>]
[mapping strategies clauses]
 
 
 
Indicates file is to be converted to an RDBMS table or via an access function (converted clause can be combined with transferred clause)
record name: corresponds to the level 01 field name of the copy description.
path/COPY name: corresponds to the access path and name of the descriptive copy of the file to migrate.
record name: corresponds to the level 01 field name of the copy description of the file to migrate.
path/COPY name: corresponds to the access path and name of the descriptive copy of the file to migrate.
Note:
Listing 5‑4 Mapper File Example
ufas mapper STFILEORA
file PJ01AAA.SS.VSAM.CUSTOMER converted transferred
table name CUSTOMER
include "COPY/ODCSF0B.cpy"
map record VS-ODCSF0-RECORD defined in "COPY/ODCSF0B.cpy"
source record VS-ODCSF0-RECORD defined in "COPY/ODCSF0B.cpy"
logical name ODCSF0B
converter name ODCSF0B
attributes LOGICAL_MODULE_IN_ADDITION
 
In this example the mapper file is named STFILEORA. The file processes only one file named PJ01AAA.SS.VSAM.CUSTOMER that is migrated to an Oracle RDBMS table using the convert option. The ODCSF0B.cpy copy file used to describe the file is one of the source copy files.
Choice of Oracle or Db2/luw (udb) is made in the db-param.cfg configuration file.
COBOL Description
Oracle Tuxedo Application Rehosting Workbench File Convertor needs a description associated with each table, so a first step generates a COBOL copy description.
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 COBOL Description), then it is the location of the copy book that is directly used.
POB Files
These files are created during cataloging, for further information see POB Files for ASTs.
Symtab File
symtab-<schema name>.pob
This file is created during cataloging, it must be up-to-date and present so that File Convertor can migrate DB2 objects to Oracle. See The Cataloger Symtab and Other Miscellaneous Files.

Copyright © 1994, 2017, Oracle and/or its affiliates. All rights reserved.