![]() |
![]() |
![]() |
![]() |
![]() |
• 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.Several configuration files need to be set, see List of the Input Components, before launching the conversion process.
• Detailed description of converted files and Oracle tables or Db2/luw (udb) tables on the target platform for each file.Table 5‑1 lists the file organizations handled by z/OS.
Table 5‑1 z/OS File Organizations
Note: When "enable-buffer-converter" or "enable-reverse-converter" are set in system description file, the file migration is different to the above description, for detail please refer to File to File chapter.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.
• Datamap-<datamap name>.re
• mapper-<mapper name>.re
Note: To simplify the process of building these two files, the populate.sh utility (located in REFINEDIR/scripts/file/populate.sh) can be used to help generate them automatically. Do the following steps:
2.
6. Execute populate.sh utility again (with -p option) to generate the final configuration file $populate.sh -pFor more information, see REFINEDIR/scripts/file/README.txt.
• 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 are provided in the mapper file. The syntax is described in chapter Mapper File of this document.
• Configuration file: db-param.cfg.
• Script modifying the generated components: file-modif-source.sh.
•
•
• 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:The Datamap file must be created in the directory: $PARAM/file with the complete name:Where <configuration name> is the name of the current configuration used.Listing 5‑1 Datamap File
Table 5‑2 Datamap File Parameters For sequential files, <mode> can be set to: record or line. This clause is used to describe the target organization (record sequential or line sequential). For variable record length file, <min> is the minimum length of the record, <max> is the maximum length of the record. 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. For relative files, this clause is used to describe the key, where <m> is the length of the key. Listing 5‑2 Datamap ExampleEach z/OS file listed in the Datamap File, must be described in the mapper file.Listing 5‑3 Mapper File Clause Structure
Table 5‑3 Mapper File Parameters 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.
Note: “map record” and “source record” parameters must use the same “record name” and “descriptive copy”. They are used for forward compatibility.
• 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: “map record” and “source record” parameters must use the same “record name” and “descriptive copy”. They are used for forward compatibility.
Table 5‑4 Mapper File Attributes In this case only the ASG_<logical file name> access function is generated. This access function can be called by Oracle Tuxedo Application Runtime for CICS.
Note: Listing 5‑4 Mapper File ExampleIn this example the mapper file is named STFILEORA. The file processes only one file named PJ01AAA.SS.VSAM.CUSTOMER that is migrated to a 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.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.