开发者

Creating MsSql table from Cobol fd file

开发者 https://www.devze.com 2023-03-26 07:18 出处:网络
I have the following COBOL files: .DAT, .IDX and fd (file definition) file. We are using COBOL Net Express from MicroFocus.

I have the following COBOL files: .DAT, .IDX and fd (file definition) file. We are using COBOL Net Express from MicroFocus.

  1. Now at first I would like to create MsSql table from this Cobol file definiton. The file defintion has this inside:

    FD PREGLA DATA RECORD IS FPG-REC.

    01 FPG-REC.

    02 FPG-STA PIC X(01).

    02 FPG-KEY.

    03 FPG-FRM PIC X(02).

    03 FPG-ODD PIC X(02).

    03 FPG-DOK PIC 9(08) BINARY.

    02 FPG-POZ PIC 9(06) BINARY.

    02 FPG-PRM.

    03 FPG-IND PIC 9(01) OCCURS 10 TIMES.

    .........and so on

Is it possible to import this file into Microsoft SQL server 2008? We are also using Sql server Managment studio. Now I tried SQL server import and export wizard, but it does not have import for this kind of file.

I have also looked in NET Express, but without any luck. Is it even 开发者_开发技巧possible to get SQL table definiton from COBOL fd?


Creating SQL table definitions from COBOL record layouts is not always a straight forward process (going the other way is pretty simple though).

The problem is that COBOL record layouts can be quite complex with various overlays (COBOL REDEFINES) and denormalizations (COBOL OCCURS). These pretty much defeat most attempts to automate the process of mapping a complex COBOL Record to an SQL table layout.

Data type mapping can also be a bit of a challenge. Net Express files may be created to target either ASCII or EBCDIC (IBM Mainframe) based environments. If your files are encoded in EBCDIC you will most likely have to write custom conversion software because your file contains mixed character/numeric data (there may be third party products that can automate, or partly automate, this type of conversion but I am not familar with them).

Try looking at one of the .DAT files with a simple text editor (e.g. notepad). If you can read the character data then it is ASCII based - and you have a fighting chance of loading the data without much additional conversion effort.

COBOL field definitions that are PIC X something contain character data and translate directly into SQL CHAR data of a similar length (i.e. PIC X(4) becomes CHAR(4)).

COBOL fields definitions defined as BINARY translate into SQL INTEGER. Whether the integer is long or short depends on the number of digits. For example PIC S9(8) BINARY specifies a signed binary integer of 8 digits - that would occupy 4 bytes. On the other hand, PIC S9(4) BINARY is only 4 digits so would occupy 2 bytes (short integer).

Another common COBOL field definition is PACKED-DECIMAL or COMP-3. These fields may translate into SQL DECIMAL data types.

SimoTime provides a very good overview for several COBOL field definitions. Working out the translation into the appropriate SQL data type should not be difficult.

Note 1: From the COBOL record layout fragment provided in your question I can see an OCCURS clause. Because of this, the resulting table will not even be in First Normal Form. These tables can be a real pain to manage in a database environment.

Note 2: The useable data will be found in the .DAT files. The record layout will correspond to the COBOL record definition. The .IDX files contain indexing data used by MicroFocus when reading/writing. You can ignore these.

0

精彩评论

暂无评论...
验证码 换一张
取 消

关注公众号