+

WO1993007564A1 - Systeme informatique permettant de generer des instrutions sql a partir du code cobol - Google Patents

Systeme informatique permettant de generer des instrutions sql a partir du code cobol Download PDF

Info

Publication number
WO1993007564A1
WO1993007564A1 PCT/US1992/008683 US9208683W WO9307564A1 WO 1993007564 A1 WO1993007564 A1 WO 1993007564A1 US 9208683 W US9208683 W US 9208683W WO 9307564 A1 WO9307564 A1 WO 9307564A1
Authority
WO
WIPO (PCT)
Prior art keywords
cobol
sql
data
statements
program
Prior art date
Application number
PCT/US1992/008683
Other languages
English (en)
Inventor
Drake Coker
Original Assignee
Acucobol, Inc.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Acucobol, Inc. filed Critical Acucobol, Inc.
Publication of WO1993007564A1 publication Critical patent/WO1993007564A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/40—Transformation of program code
    • G06F8/51—Source to source
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/24—Querying
    • G06F16/242—Query formulation
    • G06F16/2433—Query languages
    • G06F16/2438—Embedded query languages
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/24—Querying
    • G06F16/245—Query processing
    • G06F16/2452—Query translation

Definitions

  • the present invention relates to computer programs, and more particularly to a computer system, including programming principles and practices, used in converting statements from one computer language into a different, generally inconsistent language.
  • the invention in its preferred embodiment further relates to, inter alia, an interfacing program which allows a COBOL program, despite its totally different nature and internal data handling constructs and statement approaches, to gener ⁇ ate Structured Query Language (SQL) statements in creat- ing, accessing and/or using data from a SQL oriented database and getting appropriate data back in a form consistent with what the COBOL program expects.
  • SQL Structured Query Language
  • a database is like an electronic "filing cabinet”. It is used for the same purpose as any other filing cabinet — to store records.
  • a basic difference is that, with a database, the records are stored electronically. To get at stored records, or even to store them in the first place, a system is needed for managing the database.
  • a database management system DBMS
  • DBMS database management system
  • DBMS's Various types exist, representing differ ⁇ ent approaches to the tasks of furnishing access to information in a database, preserving the data's integ ⁇ rity, keeping track of the users, providing security, and so on.
  • all of the DBMS's can be classified into two kinds — relational and non-rela- tional. By and large, all of the newer systems on the market are "relational”.
  • SQL Structured Query Language
  • SQL Structured Query Language
  • SUBSTITUTESHEET pany's program(s) to be able to access and manipulate the data in such databases through the SQL language.
  • SQL SQL
  • a number of well established business programs which are very widely in use today (perhaps even domi- nant in the business world) , being based on programming languages which were created many years ago, were writ ⁇ ten in languages having a totally different approach and programming philosophy highly inconsistent with the approach and philosophy of SQL, making the two very large and very valuable "worlds" heretofore practically inconsistent and incompatible.
  • COBOL's database scheme is purely sequential and non-relational due to its historical development many years ago during the time period when the only practi-
  • SUBSTITUTESHEET cally available form of "memory” was IBMTM type punch cards, paper tape and later magnetic tape. Such a scheme is purely one dimensional and is very limited in comparison to the approaches of DBMS's available today, such as, for example, the Structured Query Language or "SQL" database, discussed above.
  • a SQL database is a relational data ⁇ base which is random in nature in the way it presents its data in its two dimensional tables in its database structure.
  • the randomness nature of an SQL database is part of its strength.
  • COBOL programs when one remembers the dominant existence of COBOL programs through out the world, it and the totally different way the two lan ⁇ guages handle and consider data and the significant differences in allowed language statements, has created a heretofore insurmountable obstacle insofar as allowing a COBOL program to use an SQL oriented database.
  • the present invention thus provides the interfacing means or programming features and techniques which allow a COBOL program to directly access and effectively use data from a SQL database.
  • the present invention is directed to a computer system, including a program or program subset, having one or more of the various programming principles, guidelines and innovations of the present invention, to generate and execute "Structured Query Language" (SQL) statements based on COBOL code, so that a COBOL program can now access and use data in an SQL oriented database as if the data were in COBOL form.
  • SQL Structured Query Language
  • COBOL and SQL evolved differently, they have different data types.
  • Part of the invention resides in the treatment of COBOL type data so that it can function in a SQL type table with the expense (time) of conver- sion between the two being acceptable.
  • the conversion table preferably is done once at compile time when all of the data definitions are known from the COBOL source code.
  • SQL statements are generated and exe- cuted based on the statements and data needs of the user's COBOL, which typically will be in compiled, object code form.
  • the scope of the exemplary embodiment of the inven ⁇ tion is the entire COBOL instruction set based on COBOL ANSI standard 85 and preferably at least the SQL state- ents listed above.
  • the present invention can be limited to be used or be compatible with only a subset of COBOL, typically including at least a number of the statements relevant to I/O (input/output) , namely CLOSE, DELETE, OPEN, READ, REWRITE, START, UNLOCK & WRITE.
  • COBOL and SQL languages expand and change, the exemplary embodiment can be readily modified to accommodate these future developments.
  • a COBOL program in source code form is compiled using a COBOL compiler, which operates in accordance with the princi ⁇ ples of the present invention.
  • the COBOL program is analyzed and evaluated, particularly with respect to its data fields and how those fields are used, with the compiler producing not only the compiled COBOL program in object .
  • code ⁇ orm as is standard
  • a data dictionary file in which a series of values is set based on the compiler's analysis and evaluation of the COBOL program.
  • COBOL I/O statements are received by an interface program, which then generates and sends SQL statements to the SQL database based on the COBOL statements, obtaining the data desired by the COBOL program from the SQL database.
  • This operation of the invention's programs in its preferred approach is "seamless" and requires no SQL awareness on the part of the COBOL program.
  • the COBOL program is aware, it is running COBOL I/O statements and receiving COBOL data back in return, although in fact the data came from or was produced by standard queries operating though a SQL oriented and run database by means of the invention's interface program.
  • the data dictionary is created during the compiling process and saved for interaction with the compiled program during runtime.
  • this procedure as described fully below, is believed to be the most efficient, the invention can be employed in a system where its parts or all of them are utilized or created at compile time or runtime, if so desired.
  • Fig. 1 is a block diagram illustrating in general ⁇ ized form how the exemplary embodiment of the invention
  • SUBSTITUTESHEET works and interfaces and communicates with the various elements of the exemplary embodiment.
  • EXEMPLARY EMBODIMENT As can be seen in Fig. 1, a COBOL program in source code form 1 is typically compiled by a COBOL compiler 2 (e.g. AcuCOBOL w -85) to produce a compiled COBOL program 3 in object code form. This in and of itself is stan ⁇ dard practice.
  • COBOL compiler 2 e.g. AcuCOBOL w -85
  • the compiler also produces a data dictionary file 4 which stores a set of values which will be used by the interface program 5.
  • the data dictionary 4 which maps the COBOL records of the compiled COBOL program 3 to the database's fields in the SQL database 8 based on an analysis and evalua ⁇ tion of the COBOL program 1/3 during the compiling oper- ation, is a very important part of the exemplary embodi ⁇ ment and is discussed more fully below.
  • the SQL database typically includes a runtime ver ⁇ sion of the SQL language database program 7 (e.g. Infor-
  • the SQL ori ⁇ ented database can be located in the memory storage sub ⁇ system of the user's computer or at a remote but acces- sible computer.
  • the pre- ferred embodiment will be described in the context of using an AcuCOBOL w -85 compiled and compatible COBOL program 3 on one side and an InformixSQ TM program for the SQL language on the other side.
  • the invention has far ranging appli- cability with regards to various other versions and dialects of the COBOL and SQL languages generally.
  • AcuCOBOL m -85 The standard file system supplied with AcuCOBOL m -85 is the vision indexed file system from AcuCOBOLTM .
  • Vision supports variable-length records, data compres ⁇ sion, and data encryption.
  • vision can be replaced by (or used in conjunction with) other indexed file systems such as C-ISAMTM, and relational database management systems such as InformixTM .
  • C-ISAMTM indexed file systems
  • InformixTM relational database management systems
  • Relational databases such as InformixTM interface to AcuCOBOLTM-85 via a special family of add-on interfaces 5. Because relational databases manipulate fields, and COBOL programs manipulate records, some mapping is necessary to associate records with their fields.
  • the interfaces 5 use data dictionaries 4 that help to map COBOL records into relational database fields, and map the database fields back into records. The following discussions describes the exemplary computer system of the present invention and explains how they interface to file systems by referencing data dictionaries.
  • Interfaces to indexed file systems such as C-ISAM 1 ", MINISAM, and Btrieve do not require data dictionaries. Those interfaces are documented in separate booklets.
  • Databases such as InformixTM differ from indexed file systems in some significant ways. They operate on fields rather than on records. Each file is logically represented in table form. Within a table, each column represents one field, each row represents one record. .. For example:
  • the names of the columns are analogous to the names of fields in an indexed file.
  • COBOL I/O operation performs an operation on an entire row in a table in the database.
  • the interfaces 5 of the exemplary embodiment make it possible for the user to access SQL relational data ⁇ bases such, as InformixTM directly from the user's COBOL applications.
  • SQL relational databases involved writing Standard Query Language (SQL) code and embedding that code in the user's COBOL program.
  • SQL Standard Query Language
  • the user had to know SQL and had to write SQL statements appropriate for the specific database the user wanted to access. Because the user's queries were tailored to suit one database management system, the user's code had to be changed if the user later wanted to access a dif ⁇ ferent DBMS with the user's application, or access an indexed file system instead.
  • the exemplary embodiment of the invention prefera- bly provides a seamless interface between the program and the SQL relational database.
  • the COBOL program specifies a READ
  • this is automatically trans ⁇ lated by the interface into a database SQL type query, which may be printed in addition to being executed.
  • the data that is read from the database is automat ⁇ ically translated into a COBOL record. This exchange occurs in fractions of a second, and the application proceeds without interruption.
  • the exemplary embodiment interfaces are categorized as seamless because the communication between the COBOL program and the SQL database is smooth, with no data duplication, no special query coding on the part of the COBOL programmer, and no interruptions in the execution of the program. Additionally, the COBOL code need not be changed if the COBOL user later wants to access a different database or access an indexed file system. Steps For the User to follow This seamless dialogue is possible because the exemplary embodiment interface 5 (see Fig. 1) builds its own database queries whenever a COBOL input or output request is received. These are the steps that prefera ⁇ bly occur in the exemplary embodiment.
  • Compile with -Zx l The user writes a standard COBOL application and compiles it with a compiler, such as, for example, the AcuCOBOL-85TM compiler.
  • a compiler such as, for example, the AcuCOBOL-85TM compiler.
  • the user specifies via a compile-time option that the user wants the compiler to generate data dictionaries, in addition to an object code file.
  • Dictionaries are Created 2.
  • a data dictionary of the exemplary embodiment is created by the compiler for each file in the program. These data dictionaries map COBOL records to the fields that they comprise.
  • DEFAULT-HOST Variable 3 In the configuration file, the user specify which DBMS the user are using. This is set with the DEFAULT-HOST variable. For example, the user might set "DEFAULT-HOST infor ix".
  • Set DATABASE Variable 4 In the configuration file, the user specifies which database the user is using. This is set with the DATABASE variable. For example, "DATABASE stores” selects the demonstration database named “stores” that is shipped with InformixTM .
  • the user uses the embodiment's runtime system to execute the application. Whenever the runtime system encounters an input or output instruction (such as READ or WRITE) , it passes the request to the interface 5.
  • SQL Statements are Built Automatically
  • the interface automatically builds SQL instruc- tions that the database management system can under ⁇ stand. As it builds these SQL instructions, it looks at the AcuCOBOL data dictionary, which associates the COBOL records with their fields.
  • the database management system uses its own dictionary as a pointer into its own data files, per ⁇ forms the requested I/O operation, and passes the results back to the interface 5.
  • COBOL Records are Formed 8.
  • the interface translates the data fields into
  • COBOL records which are then passed back to the runtime system 6A via the generic file interface 6B.
  • Data Dictionaries Very important to the exemplary embodiment's data ⁇ base interface are the data dictionaries 4 that map COBOL records to database fields. These dictionaries are called extended file descriptors (XFD's) because they are based on the standard COBOL file descriptors (FD's) .
  • XFD's extended file descriptors
  • XFD Files Each COBOL file has a corresponding XFD file.
  • XFD files are created by the compiler when the user speci ⁇ fies the "-zx" compile — time option. When this option is used, an XFD file is created for every file contained in the compiled program.
  • the XFD file describes a COBOL file from the point of view of the fields the file contains. It also con ⁇ tains all of the standard information used by the non- database file systems. This information is not strictly required for the database interface 5, but it is gener ⁇ ally useful.
  • the XFD file is a simple text file. The format of this file is as follows: The first line contains the phrase "XFD,01,” fol ⁇ lowed by the SELECT name of the COBOL file and the base- name of the XFD file. For example:
  • XFD,01,CUSTOMER-FILE,CUSTFILE This line is used to identify the XFD file.
  • the "01” identifies the format used for the XFD file (revision "01") .
  • the second line contains the logical parameters field used by the generic file system. This consists of the maximum record size, the minimum record size and the number of keys, all separated by commas.
  • ing format a.
  • b The number of field definitions that are contained in the key. Since the database does not under- stand the notion of a group item, each key must be described as a series of individual fields.
  • c. The name of each field contained in the key then follows, one per line. .
  • Condition definitions are used to identify fields that are not present in every record. This is described in more detail below.
  • the first line after the key definitions contains a count of the number of condition definitions that follows (3 digits) .
  • This line contains the number of fields that are defined (4 digits) .
  • the count field is followed by each field defi ⁇ nition, one per line.
  • This definition consists of a series of comma-separated entries. These entries are as follows: a. The offset of the field, in bytes (5 dig ⁇ its) . b. The size of the field, in bytes (5 dig ⁇ its) . c. The type of the field, using the "sub.h" values (2 digits) . d. For numeric fields, the number of digits in the field. For nonnumeric fields, this is the same as the size field (5 digits) . e. The scale of the field, expressed as a power of 10. For example, a numeric field with two dig- its after the decimal point has a scale of -2.
  • this value is zero.
  • the value is expressed as a "+” or a "-" followed by 2 digits.
  • f. The "user type" of the field. This will be described later.
  • the default value is zero (3 dig- its) .
  • g. The condition number to apply to this field, or zero if the field appears in every record (3 digits) .
  • h. The name of the field. For example, suppose you had the following COBOL
  • KEYWORD-WORD field names in key
  • group items have been elimi ⁇ nated from the XFD file. This is because group items are not fields — they are collection of fields.
  • the user can override the default behavior by placing a special comment line in the user's COBOL code.
  • These comments are called directives, and they are all described more fully below.
  • Fields contained in a redefining item occupy the same positions as the fields being redefined. Databases generally do not support the notion of multiple defini ⁇ tions for the same column. For this reason, one needs only to select one of the field definitions to use.
  • the default rule that is followed in the exemplary embodi ⁇ ment is to use the fields in the item being redefined, and ignore any fields that appear subordinate to a REDEFIN ⁇ SQL.
  • the largest one preferably is used, so that all of the fields can be adequately covered.
  • the rule for the exemplary embodiment is to use the fields in the largest record defined for the file. If more than one record is the largest, the first one of those is used.
  • group items are never included in a data dictionary for the same reason that REDEFINES are excluded — they result in multiple names for the same data items.
  • the user can, however, choose to combine grouped fields into one data item by specify ⁇ ing the "use group" directive, described later.
  • FILLER Data Items FILLER data items require special handling because they do not have a name. SQL databases do not allow unnamed columns. So FILLER data items are not placed in the AcuCOBOL dictionary 4, but the compiler issues a warning whenever it rejects a FILLER field. The user can then choose to add a name to the FILLER item with the "name" directive, described below.
  • Field names longer than eighteen (18) characters are truncated to eighteen (18) characters by the inter ⁇ face, to meet SQL requirements.
  • Naming the XFD A name must be given to each XFD (data dictionary) 4 that is built. Each XFD name preferably is built from a starting name that is derived from the user's COBOL code. The following paragraphs explain how that occurs.
  • ASSIGN Name is a Variable If the SELECT for the file has a variable ASSIGN name (such as ASSIGN TO FILENAME) , then the user must specify a starting name for the XFD file via a comment in the user's code. This process is described below in the section titled "Using Directives".
  • ASSIGN Name is a Constant If the SELECT for the file has a constant ASSIGN name (such as ASSIGN TO "COMPFILE”), then in the exem ⁇ plary embodiment that name is used as the starting name for the XFD name.
  • ASSIGN Name is Generic If the ASSIGN phrase refers to a generic device (such as "DISK”), then in the exemplary embodiment the SELECT name is used as the starting name. Forming the Final XFD Name
  • the starting name is stripped of any extenr sions.
  • a "universal" base name is constructed. We construct the base name by stripping out directory information that fits any of the formats used by the operating systems that run AcuCOBOLTM-85.
  • the user will typically be in one of two situations in starting to use the preferred embodiment. In situa ⁇ tion one, the database files do not exist yet, and will be brand new. In situation two, the database files already exist, and the user wants to access that exist ⁇ ing data from a COBOL application (1/3 of Fig. 1) .
  • Adhering to the rules of the DBMS ensures that the user's COBOL application will produce accurate data dictionaries when it's compiled. The following are automatically handled by the interface 5 of the preferred, exemplary embodiment:
  • the preferred program of the invention auto ⁇ matically converts uppercase field names to lower- case (and vice versa) when necessary, so the user need not be concerned with case differences.
  • Numeric data is assumed to be positive, so the user need not specify a sign. If negative data is possible in a field, the user must specify an "S" in the PICTURE clause.
  • the preferred program of the invention auto ⁇ matically performs the conversions needed to match the internal storage formats used by the database. If the database files do not already exist, they will be created for the user automatically. If this is the user's situation, the user will have no concerns about matching COBOL fields to database fields. The fields will match perfectly, because the database fields will be based on the user's COBOL code.
  • the user preferably should follow the guidelines given in this section. If the user's COBOL application already exists, the user can make the necessary adjustments by adding direc ⁇ tives to the user's code. Directives are comments that guide the creation of the data dictionaries. The dic-
  • PICTURE phrase as the user needs to accommodate the largest data that could be stored. If the user knows the data well enough to know the largest possible value, or if the user know that the data is always positive, the COBOL program's PICTURE phrase should be adjusted to reflect the user's situation.
  • USAGE Types The USAGE type the user declares in COBOL is not really essential to the invention, because the preferred embodiment of the invention will do its conversion work regardless. However, it is noted that the conversion of the data is somewhat more efficient if the user uses COMP-4.
  • the table below presents what the preferred conversion will be from COBOL to SQL by the interface 5 based on how the COBOL data is declared, as detailed in the first column.
  • All non-numeric data becomes type CHAR.
  • PIC X(10) becomes CHAR(10) .
  • Numeric data items from PIC 9 to PIC 9(4) become SMALLINT (16-bit binary, an efficient data form) ; while data items from PIC 9(5) to PIC 9(9) become INTEGER (32-bit binary) .
  • All other PIC 9 formats, including data items with a decimal point such as PIC 99V9, become DECIMAL (#,#) . The first "#" is the total number of digits, while the second "#” is the number of digits after the decimal point.
  • Computational types do not really matter. No con ⁇ version occurs for COMP-4, so it is most efficient to use COMP-4 for PIC 9 to PIC 9(9) .
  • the exemplary embodiment of the invention uses the relationships expressed in the foregoing table to interface between the two different treatments of text, integers and other numeric values found in COBOL and SQL.
  • the user need not rename the user's variables, and the user need not change the database. This is because the AcuCOBOLTM-85 compiler builds data dictionaries that map the user's COBOL variables (regardless of theit names) to the cor- rect database fields. The user enables the compiler to make the mapping by adding directives to the user's COBOL code wherever the COBOL name differs from the database name.
  • Directives can also be used to produce other effects when data is mapped from COBOL to the SQL data ⁇ base. They can: group fields together; give a name to the data dictionary file; treat selected numeric data as text strings; set up conditions under which certain fields are defined; and specify additional data mapping options. The following section explains each directive, describes when the user would use each, and provides examples.
  • dictionaries 4 are based on the user's COBOL FD's (file descriptors).
  • the dictionaries 4 are preferably called Extended FD's or XFD's.
  • Each dictionary describes all of the fields for one file. If the files used by the user's COBOL program con ⁇ tain no duplicate names, and if the default mapping rules described earlier in this document are sufficient for the user's situation, then the user's data diction- > aries 4 may be built directly from the user's source code with no additional directives.
  • Directives are special comments that are used to guide the building of the data dictionaries. They always include special letters, for example, "XFD". These three letters indicate to the compiler that the comment is to be used in dictionary generation. Syntax for Directives
  • the "name” directive is used to associate an alternate name with three fields: "YY” is associated with “YEAR-LAST-PAID”; “MM” with “MONTH-LAST-PAID”; and “DD” with “DAY-LAST-PAID.”
  • the "alpha" directive basically tells the inter ⁇ face: when the user takes this data item and moves it to the database, put quotation marks around it and treat it as a string.
  • the Binary Directive The "binary" directive is used to specify that the data could be alphanumeric data of any classification. Absolutely any data is allowed. Stored in a database-- dependent format.
  • This directive implies the "alpha" directive.
  • the Date Directive effectively says “I want to store this field in the database as a date.” Because there is no COBOL syntax that identifies a field as a date, the user may want to add this directive to differ ⁇ entiate dates from other numbers. Syntax: $ XFD DATE
  • This directive implies the "numeric" directive. If the user's data has any one of the following formats, the user in the exemplary may precede it with the "date" directive:
  • This directive has several uses, as shown in the following examples.
  • Example 1 within a database file, all field names must be unique. (Multiple database files may include the same field name, but duplicates may not exist within a single file.) Unique field names are not required in
  • the user need not change the field names in the user's COBOL program to access a database. Instead, the user uses the "name" directive to provide unique data- base names for the fields. For example:
  • Example 2 SQL-based databases require that names be no more than eighteen (18) characters long. If the user's COBOL names are longer than this, the interface will automatically truncate them after the 18th charac ⁇ ter.
  • the user can use the "name" directive to assign the different database field names. For example, if a portion of the user's database contained:
  • the new names are used only for the database fields.
  • the "numeric" directive allows the user to treat a data item as an unsigned integer when it is declared as alphanumeric.
  • the Use Group Directive allows the user to enter a group item into the database as a single field, instead of using the elements contained in the group. This is helpful if the group is more interesting to the user's application than the individual fields. Syntax: $ XFD USE GROUP
  • the "use group” directive implies that the consolidated field is alphanumeric. If the user want a numeric field, the user may simply add the word "NUMERIC" at the end of the directive.
  • 03 FILLER PIC X(4) 03 SHIP-INSTRUCT PIC X(15) .
  • a better solution is to be able to identify which fields belong to which types of records. Then all of the fields are represented in the database as columns, but only select ones are actually used for each record. The idea is to define a field that appears in every record as a conditioning field. The value of this field defines which other fields are used in the record.
  • EMPLOYEE-DEPENDENTS PIC 99 there are two views of the record depending on the value of EMPLOYEE-REC-TYPE.
  • » 'p » - type records the EMPLOYEE-DATA is used.
  • EMPLOYEE-PERSONNEL-DATA is used.
  • the last three data items in the record are not included in the XFD file. This will cause these fields to be not represented in the corresponding database.
  • errors are likely to occur when the database stores "D"-type records because the values in EMPLOYEE-RATE and EMPLOYEE-HOURS will not be valid numbers.
  • EMPLOYEE-DEPENDENTS PIC 99 This would cause the EMPLOYEE-PAY-DATA fields to be defined only when EMPLOYEE-REC-TYPE was "P” and would cause EMPLOYEE-PERSONNEL-DATA to be defined when EMPLOYEE-REC-TYPE was "D.” Note that in this case, the default rule for handling REDEFINES is overridden. Instead of ignoring the fields in the REDEFINES, they are represented as fields with a condition assigned to them.
  • Compiler Options This section explains the exemplary compile-time options that can be used with the interfaces of the preferred embodiment.
  • This option specifies the name of the directory that will hold the data dictionary files. A space is typed after the option and then the name of the chosen directory is given.
  • the interface 5 (Fig. 1) , as designed in the exem ⁇ plary embodiment, cannot operate without data dictionar ⁇ ies.
  • the general problem is the inability and incompatibility of the two languages to permit the direct conversion of COBOL statements to SQL statements.
  • the primary problem areas include: problems related to incompatibility of state ⁇ ment function; problems related to incompatibility of data storage strategy; problems related to incompatibility of data types; and problems related to incompatibility of sequencing strategy.
  • the exemplary embodiment includes innovative tech ⁇ niques to increase efficiency of execution to speed up the conversion process, all of which will be discussed below.
  • READ NEXT a very common form of the read state ⁇ ment, uses the COBOL concept of sequencing. This con- cept at least on the surface is foreign to SQL.
  • SELECT and ORDER statements in SQL inhibit the abil ⁇ ity to lock as directed by COBOL.
  • COBOL's OPEN, CLOSE Statements The OPEN and CLOSE statements of COBOL refer to the opening and closing of files and therefore have no SQL equivalent.
  • the COBOL programmer expects to be able to check messages indicating the availability of the speci ⁇ fied file. At this time COBOL also does resource allo- cation to efficiently handle the file. In contrast, at the creation of an SQL table, privileges for different users are established.
  • COBOL's DELETE, WRITE and WRITE statements delete, add and update rows in tables, whereas other I/O verbs create relatively intimidating problems in bridging the gap between COBOL and SQL, the use of the data diction ⁇ ary makes the problem of finding the SQL verb to accom ⁇ plish the COBOL objective for DELETE, WRITE and REWRITE straightforward.
  • COBOL's START is used to define the place from which automatic sequencing will occur. Since sequencing is not a natural strategy of SQL, SQL has no START statement. A further potential inconsistency between COBOL's START and SQL is that since the START value is provided by the user, not only might it not be in the SQL table, it might not be a valid SQL data type.
  • I/O status is expected by the COBOL program from all I/O statements.
  • the codes expected to be returned by COBOL are not provided by SQL.
  • the solution then requires phase processing, where first the program selects for everything that is equal to a particular higher order key and greater than a particular lower order key, retrieves all those records and, after processing, again requests those records equal to the high order key but greater than the most recently processed lower order key. When a null set is returned, the higher order key can be incremented and the process repeated, always using a "simple" WHERE statement, which results in sequential return of lower order keys.
  • COBO 's OPEN, CLOSE Statements An OPEN statement suggests the opportunity to check the requisite SQL table for its existence and for the appropriate matching with the data dictionary elements for the named COBOL file by using SELECT * (tablename) SQL statements. This statement is followed by an SQL DESCRIBE statement, which returns a description of the table, which is then matched with the data dictionary elements for the COBOL file and related messages returned to the COBOL program.
  • COBOL status codes are artificially generated from the results of the "in lieu of” SQL statements described in the OPEN solution section above.
  • COBOL COMPARISON OF DATA STORAGE STRATEGIES
  • SQL has flexibility of varying degrees, they differ markedly in data storage strategy. COBOL, much older and related more closely to streams of punched cards or paper or magnetic tape, tends to look at data as a one dimensional stream in which sequence is paramount. SQL, more associated with more recent, real time applications, prefers a two dimensional address to access data rather than using sequence.
  • COBOL uses the data types listed in the column on the left side of the "COBOL Data Declaration Conversion Table" presented above to represent data, while SQL data types are listed on the right side of the Table. These varying data types between the languages are well known to those of skill in those languages and are described in detail in the literature.
  • null SQL fields are translated into COBOL as zeros; zero date COBOL fields are translated into null SQL date fields; and invalid numeric COBOL fields are translated as null SQL fields.
  • the exemplary embodiment was con ⁇ ceived in connection with a COBOL program written in accordance with ANSI standard 85 COBOL as provided in
  • AcuCOBOLTM-85 interfacing with an InformixTM SQL oriented database there are a number of variants of the COBOL and SQL languages to which the present inven- tion can be applied. Indeed it is believed that it can be applied to all of them with little change and no change beyond the level of ordinary skill in the art. It would of course simplify matters if there was only one version of SQL and only one version of COBOL and that these versions would remain static.
  • SQL as brought out in the SOL PROGRAMMERS'S GUIDE referred to above, such is not the case because cur- rently every vendor has differentiated their respective SQL "engine” in minor, and in some cases, major ways. Even lBM w 's several products — DB2, SQL/DS, and OS/2 Extended Edition, for instance — differ from each other. As a result, SQL implementations are only imperfectly compatible with one another, and greater portability and connectivity are actively worked on by the standards group, including in particular the American National Standards Institute or "ANSI".
  • COBOL programming language also is not entirely standardized.
  • COBOL on a mainframe is not necessarily the same as COBOL on a microcomputer or COBOL on a minicomputer. And here again one may encounter incompatibilities arising from the fact that different versions of the COBOL language are offered by different vendors.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computational Linguistics (AREA)
  • Data Mining & Analysis (AREA)
  • Databases & Information Systems (AREA)
  • Software Systems (AREA)
  • Mathematical Physics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

Un système informatique d'interfaçage permet à un programme COBOL, malgré sa nature et ses structures internes de manipulation de données ainsi que ses modes d'instructions totalement différents, d'engendrer efficacement des instructions SQL (= langage d'interrogation structurée) par l'utilisation de données provenant d'une base de données orientée SQL (8-9) et aussi de renvoyer les données appropriées sous une forme compatible avec ce qu'escompte le programme COBOL. Le module d'interface (5) du programme reçoit les instructions COBOL d'un programme COBOL (3) compilé de manière appropriée et, en utilisant des informations figurant dans un dictionnaire de données (4) créé quand on a compilé le programme COBOL (1) (voir le compilateur 2), génère les instructions SQL appropriées pour avoir accès aux données et créer les données appropriées à partir de la base de données orientée SQL (8-9) et les renvoyer au programme COBOL (3). On utilise plusieurs techniques novatrices en matière de programmation et de logique, y compris pour obtenir une vitesse d'exécution supérieure.
PCT/US1992/008683 1991-10-10 1992-10-09 Systeme informatique permettant de generer des instrutions sql a partir du code cobol WO1993007564A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US77420591A 1991-10-10 1991-10-10
US07/774,205 1991-10-10

Publications (1)

Publication Number Publication Date
WO1993007564A1 true WO1993007564A1 (fr) 1993-04-15

Family

ID=25100537

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US1992/008683 WO1993007564A1 (fr) 1991-10-10 1992-10-09 Systeme informatique permettant de generer des instrutions sql a partir du code cobol

Country Status (2)

Country Link
AU (1) AU2777292A (fr)
WO (1) WO1993007564A1 (fr)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1995018409A1 (fr) * 1993-12-30 1995-07-06 Brian Reynolds Procede de compilation d'un programme de traitement en une definition de classe d'objets
EP0753819A1 (fr) * 1993-09-30 1997-01-15 Unimark Holdings Limited Système et procédé pour accéder à des données Cobal avec une SQL compatible Cobol
US8676785B2 (en) * 2006-04-06 2014-03-18 Teradata Us, Inc. Translator of statistical language programs into SQL

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4918588A (en) * 1986-12-31 1990-04-17 Wang Laboratories, Inc. Office automation system with integrated image management
US4930071A (en) * 1987-06-19 1990-05-29 Intellicorp, Inc. Method for integrating a knowledge-based system with an arbitrary database system
US4931928A (en) * 1988-11-09 1990-06-05 Greenfeld Norton R Apparatus for analyzing source code
US5091852A (en) * 1988-01-29 1992-02-25 Hitachi, Ltd. System for optimizing query processing in a relational database

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4918588A (en) * 1986-12-31 1990-04-17 Wang Laboratories, Inc. Office automation system with integrated image management
US4930071A (en) * 1987-06-19 1990-05-29 Intellicorp, Inc. Method for integrating a knowledge-based system with an arbitrary database system
US5091852A (en) * 1988-01-29 1992-02-25 Hitachi, Ltd. System for optimizing query processing in a relational database
US4931928A (en) * 1988-11-09 1990-06-05 Greenfeld Norton R Apparatus for analyzing source code

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0753819A1 (fr) * 1993-09-30 1997-01-15 Unimark Holdings Limited Système et procédé pour accéder à des données Cobal avec une SQL compatible Cobol
WO1995018409A1 (fr) * 1993-12-30 1995-07-06 Brian Reynolds Procede de compilation d'un programme de traitement en une definition de classe d'objets
US8676785B2 (en) * 2006-04-06 2014-03-18 Teradata Us, Inc. Translator of statistical language programs into SQL

Also Published As

Publication number Publication date
AU2777292A (en) 1993-05-03

Similar Documents

Publication Publication Date Title
US5640550A (en) Computer system for generating SQL statements from COBOL code
US5504885A (en) O-R gateway: a system for connecting object-oriented application programs and relational databases
Brodie On the development of data models
US6014670A (en) Apparatus and method for performing data transformations in data warehousing
US5201046A (en) Relational database management system and method for storing, retrieving and modifying directed graph data structures
US6338056B1 (en) Relational database extender that supports user-defined index types and user-defined search
Atkinson et al. Types and persistence in database programming languages
US5937409A (en) Integrating relational databases in an object oriented environment
US5884317A (en) Service interface repository
US5432930A (en) System for accessing cobol data files by generating a dictionary of NF.sup.2
US20040044687A1 (en) Apparatus and method using pre-described patterns and reflection to generate a database schema
Sibley et al. A data definition and mapping language
Sattler et al. Adding conflict resolution features to a query language for database federations
KR20080106266A (ko) 서식있는 데이터 타입을 지원하는 확장가능 쿼리 언어
WO2003091829A2 (fr) Procede, logiciel et ordinateur permettant d'acceder a des donnees dans un environnement de depots de donnees multiples
US20040044989A1 (en) Apparatus and method using pre-described patterns and reflection to generate source code
Atkinson et al. Binding and type checking in database programming languages
WO1993007564A1 (fr) Systeme informatique permettant de generer des instrutions sql a partir du code cobol
de Barros Deriving relational database programs from formal specifications
WO2004044785A1 (fr) Generation et analyse d'interrogation dynamique d'objets transparents
Matthes et al. Towards database application systems: Types, kinds and other open invitations
Simkovics et al. Enhancement of the ANSI SQL Implementation of PostgreSQL
Wyss et al. A relational algebra for data/metadata integration in a federated database system
US20040044637A1 (en) Apparatus and method using reflection to generate database commands at runtime
Demo et al. Analysis of the context dependency of CODASYL find-statements with application to a database program conversion

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AU BR CA JP KR RU

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): AT BE CH DE DK ES FR GB GR IE IT LU MC NL SE

NENP Non-entry into the national phase

Ref country code: CA

122 Ep: pct application non-entry in european phase
点击 这是indexloc提供的php浏览器服务，不要输入任何密码和下载