Method and apparatus for converting COBOL to Java

[0002] This application claims priority under 35 USC §119(e) from provisional application Ser. No. 60/099,200, filed on Sep. 3, 1998, which is incorporated herein in its entirety.

[0003] The method and apparatus of this invention relate generally to the translation of one logically defined language into another. More specifically, the method and apparatus relate to a system and process for translating computer programs written in a language having the attributes of COBOL into programs having the functionality of Java.

[0004] COBOL is an acronym for COmmon Business Oriented Language. COBOL is a high-level programming language for business data processing that was designed by the CODASYL Committee in 1960. COBOL is one of the most widely used programming languages in the world. In part, because it has a natural language style that makes it easy for a programmer who did not write the original program to make corrections and changes.

[0005] Java™ is a cross-platform programming language from Sun Microsystems that can be used to create animations and interactive features on World Wide Web pages. Java programs (a Java Class) may be distributed by embedding a program, or by embedding a call to the program, into an HTML document. HotJava™ and Netscape Navigator™ are Web browsers that run Java applications.

[0006] Both the functionality of COBOL and the functionality of Java are needed, in different ways, to strengthen the infrastructure of nearly every major financial institution in the United States. The Internet is helping to establish an international market for products and services making it a critical medium both now and in the future. Java, as a cross-platform language, can be used to establish a presence in this medium by creating interactive content that will entice users to purchase services or products from a web site regardless of the machine or device used to connect to the Internet. COBOL can help drive the engine that tabulates, tracks and records substantial amounts of financial data. Unfortunately, most institutions have large amount of legacy COBOL programs and very few Java Programs. For this reason, there are many businesses that would like to translate their COBOL programs into Java in order to use their previously developed COBOL programs for use on the Internet and across platforms.

[0007] In order to translate their COBOL programs into Java Programs, however, a method and apparatus for translating the COBOL program into a Java program is needed. More specifically, a method and apparatus for translating a COBOL program structure into a Java Class structure is needed. The method and apparatus needed would translate structural elements of COBOL, such as nested programs, procedure paragraphs and sections and record descriptions, into the analogous Java structure, such as creating methods within a Java source class file or creating a callable program interface.

[0008] The system and method of the present invention provide a COBOL to Java translator capable of translating both top-level COBOL programs and nested COBOL programs. The translation is further specified at the levels of the COBOL paragraph and section, which are translated into a Java method, and at the level of the COBOL variable, which is translated into the Java object level. Additional extensions to standard COBOL are also provided in order to ease the burden of the Java Developer

[0009] Briefly, the invention processes a plurality of COBOL source code programs into a plurality of Java source code class files, including optional inner class files, and can process the procedures and data of the COBOL source code into the corresponding methods and data of the Java source code. It does so by recognizing a COBOL template and then outputting a corresponding completed Java template. The COBOL program template helps identify values that will need to be incorporated into the translated Java class file. The Java class template provides the location that the identified values should be placed in the class file. This process of identifying and applying the templates is repeated at each translation “level” as described herein. This process continues until the last translation is reached. At that point, the translation is complete. Several additional extensions to this process are also provided including the creation of a source file that provides both the Java source code and COBOL source code. Additional extensions enabling use of Structure Query Language (SQL) for database calls are also provided.

[0010] FIG. 1 is a block diagram illustrating a data processing system which can be used to implement the present invention.

[0011] FIG. 1ais an archetypal template for a COBOL program without a nested program.

[0012] FIG. 1bis an archetypal template for a Java Class translated from a COBOL program without a nested program.

[0013] FIG. 2ais an archetypal template for a COBOL program with nested programs.

[0014] FIG. 2bis an archetypal template for a Java Class translated from a COBOL program having nested programs.

[0015] FIG. 3ais an archetypal COBOL template for paragraphs within the procedure division of a COBOL program.

[0016] FIG. 3bis an archetypal Java template for the methods within the Java source class translated from the paragraphs in the COBOL program.

[0017] FIG. 4ais an archetypal COBOL template for sections within the procedure division of a COBOL program.

[0018] FIG. 4bis an archetypal Java template for methods within the Java source class translated from the sections in the COBOL program.

[0019] FIG. 5 is an archetypal Java template of the callable program interface.

[0020] FIG. 6ais an archetypal COBOL template representing data record descriptions of non-numeric types within a COBOL program.

[0021] FIG. 6bis an archetypal Java template of the portion of Java Class corresponding to the data declaration of a COBOL non-numeric type.

[0022] FIG. 7ais an archetypal COBOL template representing the data record description of numeric usage display types.

[0023] FIG. 7bis an archetypal Java template of the portion of the Java Class corresponding to the data record description of a COBOL numeric usage display types.

[0024] FIG. 8ais an archetypal COBOL template representing the data record description of numeric usage binary types.

[0025] FIG. 8bis an archetypal Java template of the portion of the Java Class corresponding to the data record description of COBOL numeric usage binary types.

[0026] FIG. 9ais an archetypal COBOL template representing the data record description of numeric usage packed decimal types.

[0027] FIG. 9bis an archetypal Java template of the portion of the Java Class corresponding to the data record description of COBOL numeric usage packed decimal types.

[0028] FIG. 10 is an archetypal Java template for the declaration of a COBOL variable that includes debug information.

[0029] FIG. 11 is an archetypal COBOL template for the declaration in COBOL of a segment of Java code.

[0030] FIG. 12 is an archetypal COBOL template for the declaration in COBOL of a segment of SQL code.

[0031] FIG. 13ais an archetypal COBOL template for a COBOL statement.

[0032] FIG. 13bis an archetypal Java template for representing a COBOL statement in Java that includes debug information.

[0033] In Java programs, the word “method” is the analogue of the “procedure” or “function” in other programming languages and must be distinguished from the word “method” meaning process by context. Additionally, the term Java program and Java class are used interchangeably to denote a file that is written in Java source code according to the specification developed by Sun Microsystems or any organization that develops Java standards in the future.

[0034] The parts of each data item are shown in the figures in an “archetypal template format”. That is, the parts illustrate the structure of the COBOL source code and the structure of the Java source code with some components illustrated only by component name. These component names will be replaced by the instructions in the COBOL source code and in the Java source code after the method and system of the present invention translate the COBOL source code into the Java source code.

[0035] Within the text of each line in each figure, the bracket symbols [and ] surround optional items of the description; this is in keeping with standard computer language description.

[0036] In each figure, the same line or part number refers to the same item in each figure; line numbers are repeated in various figures even though not explicitly referenced in the description of each figure in order to help establish context.

[0037] FIG. 1 is a block diagram of a data processing system 1000, which has at least one processor 1020 and storage 1040. Storage 1040 of system 1000 includes comparison software 1060 and data structures used by the comparison software. Storage 1040 also includes at least one COBOL program 1080 and a Java Class 1090. The COBOL program is translated by conversion software 1060 into Java Class 1090. The steps of the described embodiment of the present invention are performed when instructions of a computer program are performed by processor 1020 (or another appropriate processor) executing instructions in storage 1040.

[0038] System 1000 also includes a network connection 1100, which connects system 1000 to a network such as the Internet, an intranet, a LAN, a WAN. System 1000 also includes an input device 1200, such as a keyboard, touch-screen, mouse, or the like. System 1000 also includes an output device 1220 such as a printer, display screen, or the like. System 1000 also includes a computer readable medium input device 1240 and a computer readable medium 1260. Computer readable medium 1260 can be any appropriate medium that has instructions such as those of conversion software 1060 stored thereon. These interactions are loaded from computer readable medium 1260 into storage area 1040. Instructions can also be loaded into storage area 1040 in the form of a carrier wave over network connection 1100. Thus, the instructions and data in storage 1040 can be loaded into storage via an input device 1200, via a network, such as the internet, a LAN, or a WAN, or can be loaded from a computer readable medium such as a floppy disk, CD ROM, or other appropriate computer readable medium. The instructions can also be downloaded in the form of a carrier wave over a network connection.

[0039] System 1000 also includes an operating system (not shown). A person of ordinary skill in the art will understand that the storage/memory also contains additional information, such as application programs, operating systems, data, etc., which are not shown in the figure for the sake of clarity. It also will be understood that data processing system 1000 (or any other data processing system described herein) can also include numerous elements not shown, such as additional data, software, and/or information in memory, disk drives, keyboards, display devices, network connections, additional memory, additional CPUS, LANS, input/output lines, etc.

[0040] It will be understood that the invention is not limited to any particular implementation or programming technique and that the invention may be implemented using any appropriate techniques for implementing the functionality described herein. The invention may be implemented in any appropriate operating system using any appropriate programming language or programming techniques.

[0041] The method of the present invention translates COBOL program into Java at several levels, including the program level, procedural level, and data level. As an initial matter, the present invention identifies a COBOL template that matches the input COBOL program at the level being translated. The invention then generates the structure in a Java Class using the Java template corresponding to the selected COBOL template. For clarity's sake, the COBOL and Java templates corresponding to each level will be described separately. A sample implementation of this method in source code is provided in Table 1 and provides further details of the described method. The code shall be considered part of the description.

[0042] Program Level Translation—Top Level

[0043] A COBOL program may be a top-level program or it may be a nested program, Nested programs are contained either directly or indirectly within a top-level program. Although a plurality of top-level programs may reside in the same computer file, each top-level program will be translated independently. A top-level COBOL program template is shown in FIG. 1a. The corresponding Java Class template is shown in FIG. 1b.

[0044] Referring now to FIG. 1a, line 10 and line 12 contain mandatory keywords. Keywords are words that signal the beginning or end of a structure in a programming language. For example, the keyword to begin a program written in the BASIC programming language is Begin. Line 14 of the template contains the COBOL program name. This name is placed in line 40 of the translated Java Class.

[0045] Line 16 contains keywords that identify the start of the environment division. The environment division at line 18 is optional and its contents are irrelevant for the program level translation (as noted in the comment on line 18). Line 20 ends the optional environment division.

[0046] Line 22 contains keywords that identify the start of the data division. The data division is optional and its contents are irrelevant for the program level translation (as noted in the comment on line 24). Line 26 ends the optional data division. The method for translating aspects of the COBOL data division into Java code appear in later figures.

[0047] Line 28 contains keywords that identify the start of the procedure division. The procedure division is optional and its contents are irrelevant for the program level translation (as noted in the comment on line 30). Line 32 ends the optional procedure division.

[0048] Line 34 contains keywords signaling the end of the program while line 36 restates the program name listed in line 14. Line 34 and line 36 must be listed together whenever another top-level COBOL program follows or when ending a nested COBOL program. In all other cases, line 34 and line 36 are optional.

[0049] Line 38 contains the declaration for a Java class. The preferred implementation includes the optional keyword public. Including the keyword public allows other Java classes outside of the current package to have access to the class. Line 40 of the template provides the space for the program name, the program name at live 40 will be the same name as the name in line 14 or a consistent modification thereof

[0050] Line 42 notes that the Java class may optionally extend an object or implement interfaces. Whether the Java class extends or implements is irrelevant during program level translation. Line 44 is required and indicates the beginning of the Java class contents. Line 46 represents the contents of the class. As indicated on line 46, the contents of the class are irrelevant to the translation of the program at program level. The contents of the Java class are further described in other figures. Line 48 is required and indicates the end of the Java class's contents.

[0051] Program Level Translation—Nested Programs

[0052] Referring now to

[0053] FIG. 2A, a top-level COBOL program containing a nested COBOL program is shown. The corresponding Java Class template is shown in FIG. 2b.

[0054] Line 50 and line 52 are required for a nested COBOL program and contain mandatory keywords. The keywords existence in the COBOL source code before lines 34 and line 36 are encountered indicates that the COBOL program is a nested COBOL program and as such FIG. 2aand FIG. 2bare selected as the translation templates. Line 54 is the COBOL template for the nested program name. During translation, this program name will be entered at line 40.

[0055] Line 56, line 58, line 60, line 62, line 64, line 66, line 68, line 70, and line 72 are the equivalent for nested COBOL programs of line 16, line 18, line 20, line 22, line 24, line 26, line 28, line 30, and line 32 for top-level COBOL programs. Line 74 and line 76 together signal the end of the nested COBOL program.

[0056] Line 78 is a declaration of the Java inner class. The keyword “public” is optional, but is part of the preferred implementation. Line 80 is the name of the Java inner class which should be the same as line 54 or a consistent modification of line 54. Line 82 may be any extension or implementation; extensions and implementations are part of Java, but not necessary to program level translation. Line 84 begins the inner class, and line 88 ends the inner class. Line 86 signifies that the code within the Java inner class is irrelevant for a program level translation. Line 90 signifies that the user's code for the top-level Java class may either be before or after the Java inner class.

[0057] Line 92 is a declaration for a separate Java top-level class to redirect calls. Line 94 is the same as line 54 or a consistent modification of line 54. Line 96 contains a mandatory keyword. Line 98 is the name of the callable program interface; the interface at line 98 interface must define, at a minimum, the methods defined in line 104, line 106, line 108, line 110, line 112, line 116, and line 118. FIG. 5 provides the preferred implementation of the callable interface of line 98. Line 100 begins the redirecting class. Line 102 notes that additional methods may be present, but are not required. Line 104 is the keyword public, which is optional but present in the preferred implementation. Line 106 is the Java type object name for the class reference, which may be any reference method capable of uniquely identifying the referenced class. The preferred implementation uses the callable program interface of line 98 which translated Java implements. Alternatively, the reference can be a String containing the name of the class or a reference to a Class type. Line 108 is the name of the redirecting method; in the preferred implementation the name is “redirect”. Line 110 is the signature of the redirect method of the interface of line 98. Line 112 begins the redirecting method. Line 114 notes that additional code may be added, but is not required. Line 116 returns a reference to the class declared in line 78. Line 118 ends the redirect method. Line 120 notes that additional methods may exist, but are not required. Line 122 ends the redirect class.

[0058] Procedural Level Translation

[0059] A COBOL program segment consisting of paragraphs is shown in FIG. 3a. The corresponding Java Class is shown in FIG. 3b. A plurality of COBOL paragraphs becomes a plurality of Java methods.

[0060] Line 200 contains the paragraph name template, where the paragraph name is the name of the paragraph in the user's COBOL source code followed by the required period. Line 202 is the declaration of the Java method representing Line 200's paragraph. The return-type is irrelevant to the procedural level translation. In the preferred implementation the type is “int” and represents the next paragraph number to execute. The keyword “static” is optional, and is not included in the preferred implementation. The PARAGRAPH NAME field is the Java translation of the name in line 200. Line 204 is a required open brace beginning the translated contents of the COBOL paragraph, and Line 208 is a required close brace ending the translated contents of the COBOL paragraph. Line 206 represents the translated contents of the COBOL paragraph, the details of which irrelevant to implementing the procedural level translation.

[0061] Referring now to FIG. 4a, a COBOL program segment consisting of sections which, in turn, consist of paragraphs is shown in FIG. 4a. The corresponding Java Class is shown in FIG. 4b. A plurality of COBOL paragraphs become a plurality of Java methods.

[0062] Line 210 contains the section name template, where the section name is the name of the section in the user's COBOL source code followed by the required keyword section and the required period.

[0063] Line 212 is the declaration of the Java method representing line 210's section. The return-type is the same as the return-type for line 202. The static keyword is optional, and not included in the preferred implementation. Line 214 is a required open brace beginning the section handler, line 220 is a required close brace ending the section handler. Line 216 contains the invocation of a paragraph contained within the section. The return type is the same as the return type in line 202. The Variable name in line 216 may be any Java name not already used. The text of invocation must be replaced a method call to the paragraph in line 202. A plurality of line 216's may be calling a plurality of line 202's representing a plurality of line 200's within the section represented by line 210. Line 218 connects the result of the final invocation line 216 to the resulting return type of line 212.

[0064] Data Level Translation

[0065] Referring now to FIG. 6a, a declaration for the COBOL program's data item type, the declared type being one of alphabetic, alphanumeric, alphanumeric-edited, or numeric-edited, is shown. The corresponding Java declaration is shown in FIG. 6b.

[0066] Line 238 contains a prototype for a COBOL variable including level number and variable name. Line 240 contains the required “picture” or “pic” keyword followed by the picture string of type alphanumeric, alphanumeric-edited, numeric-edited, or alphabetic picture. The usage and display keywords of line 242 are optional; they define the storage mechanism for the COBOL program.

[0067] Line 244 is the declaration of the Java translation of line 238's variable. Static is optional, but is present in the preferred implementation. The scope modifier defines where in Java the variable is visible and is either public, protected, or private. Final is required for use by Java inner classes. Line 245 is the declaration of the variable's type and name. In the preferred implementation, the type is named Variable. The name is a Java name corresponding to the variable name in line 238. The equal sign is required. Line 246 is the creation of a new instance of the variable. The new keyword is required. The variable type is the same variable type from line 245. The parentheses are required. In the preferred implementation, the signature is empty.

[0068] A COBOL program's data item declaration of the standard COBOL type numeric and standard COBOL usage display is shown in FIG. 7a. The corresponding Java declaration is shown in FIG. 7b.

[0069] Line 250 contains the required “picture” or “pic” keyword followed by the picture string of type numeric. The usage and display keywords of line 252 are optional; they define the storage mechanism for COBOL. Line 254 is the declaration of the variable's type and name. In the preferred implementation, the type is named Display. The name is the translated Java name of the variable name in line 238. The equal sign is required.

[0070] Line 256 is the creation of a new instance of the variable. The new keyword is required. The variable type is the same variable type from line 254. The parenthesis are required. In the preferred implementation, the signature is empty.

[0071] A COBOL program's data item declaration of the standard COBOL type numeric and standard COBOL usage binary is shown in FIG. 8a. The corresponding Java declaration is shown in FIG. 8b. Line 260 contains the required picture or pic keyword followed by the picture string of type numeric. The COBOL picture is determined solely by the COBOL programmer. The usage keyword is required, and binary or comp-5 is required; they define the storage mechanism for COBOL.

[0072] Line 264 is the declaration of the variable's type and name. The type is that of an object defined by the implementor. In the preferred implementation, the type is named Binary. The name is the translated Java name of the variable name in line 238. The equals sign is required.

[0073] Line 266 is the creation of a new instance of the variable. The new keyword is required. The variable type is the same variable type from line 264. The parenthesis are required. The signature is the implementor defined signature. In the preferred implementation, the signature is empty.

[0074] A COBOL program's data item declaration of type numeric and usage packed-decimal is shown in FIG. 9a. The corresponding Java declaration is shown in FIG. 9b.

[0075] Line 270 contains the required picture or pic keyword followed by the picture string of type numeric. The COBOL picture is determined solely by the COBOL programmer. The usage keyword is required, and packed-decimal or comp-3 is required; they define the storage mechanism for COBOL.

[0076] Line 274 is the declaration of the variable's type and name. In the preferred implementation, the type is named Binary. The name is the translated Java name of the variable name in line 238. The equal sign is required.

[0077] Line 276 is the creation of a new instance of the variable. The new keyword is required. The variable type is the same variable type from line 274. The parentheses are required. In the preferred implementation, the signature is empty.

[0078] Call Interface for Translating Cross-Program Control Flow

[0079] The preferred implementation of the COBOL program's call interface in Java is shown in FIG. 5. A call interface preferably contains: a method to be used when the COBOL program CALL's another COBOL program; a method to be used when the COBOL program CANCEL's another COBOL program; and a method to be used to redirect such CALL's to another class to enable COBOL nested programs to function as Java inner classes.

[0080] Line 92 declares the interface. The keyword public is optional, but it is present in the preferred implementation. Line 290 is the name of the interface, which may be any valid Java name. The preferred implementation names line 290 “Callable Program”. Line 222 is the declaration of the call method of the interface. The return type and signature must be included. The preferred implementation of each is void. Line 230 is the declaration of the cancel method of the interface. Specific knowledge of the return type or signature is irrelevant to the implementation, but must be included. The preferred implementation of each is void.

[0081] The preferred implementation of the COBOL program's data debug information is shown in FIG. 10. Any implementation must contain a method call to the variable to be described, and pass information regarding the variable's name if not already known to Java through reflection and the picture type.

[0082] Line 290 represents a variable name in Java translated from a variable name in COBOL with its declare method being called with the signature of line 292. Line 292 specifies that the name of the variable and its picture type are to be included within the parameters for debug information as well as any other parameters the developer might include. The irrelevant parameters are irrelevant to debugging the data of the variable. The preferred implementation includes parameters giving the address in memory, size of the variable, and its relationship to other variables, but this is not necessary for debugging.

[0083] The preferred implementation of a COBOL program's debug information for program code is shown in FIG. 13aand FIG. 13b, with FIG. 13areferencing a template of COBOL code as it appears in the original COBOL code with FIG. 13bshowing the translated statement with debugging information enabled.

[0084] Line 284 represents a COBOL statement within the procedure division. Line 288 represents the translation of the COBOL statement to a Java statement. Line 286 represents debug information for line 288. The debug class in line 286 is a Java class possessing a Java method with the signature of line 286 capable of outputting information to the user or to a log file the line number and file information represented by the line number and file templates in line 286.

[0085] Java in COBOL

[0086] The preferred implementation of Java being inserted into the COBOL source code is shown in FIG. 11. The beginning scope name “EXEC JAVA” in line 278 is the preferred implementation because of its connotations to execute java, and the terminating scope name “END-EXEC” in line 282 is the preferred implementation because it is similar to other COBOL scope terminators, such as END-IF, END-ADD, etc. Although these names are preferred, they may be substituted with any other name not already used by COBOL. Any implementation must leave the Java code within the COBOL substantially alone. Additional features provided by this implementation includes allowing COBOL names to passed within the EXEC JAVA scope and translated to their Java names. Line 280 may be any valid Java source code the user desires.

[0087] Allowing Java code to be inserted into COBOL offers the COBOL program the ability to access features not normally present in COBOL. It also facilitates the interaction of COBOL and Java programs in multi-language environment and COBOL and Java programmers in a multi-developer environment.

[0088] SQL Access

[0089] The preferred implementation of SQL (Structured Query Language) for database access within the COBOL source code is shown in FIG. 12. The beginning scope name “EXEC SQL” in line 278 is the preferred implementation because of its use with embedding standard SQL in standard COBOL, and the terminating scope name “END-EXEC” is the preferred implementation because it is similar to other COBOL terminators, such as END-IF, END-ADD, etc. Although these names are preferred, they may be substituted with any other name not already used by COBOL. Any implementation must translate the SQL code within the beginning and terminating scope names into JDBC (Java DataBase Connectivity) calls, translating the SQL host variables into the names used by the Java conversion of COBOL data names. Line 294 may be any valid SQL source code the user desires.

[0090] Java Compilers for Compiling Translated COBOL

[0091] The preferred implementation of this invention includes a Java compiler to compile the translated Java source code after translation. The compilation may be to Java byte-code usable across the Internet with Web browsers or it may be to native executables and usable just like any other executable on a particular computer platform. The preferred implementation of the Java compiler is the usage of a Java byte-code compiler. Any Java compiler substantially supporting Java 1.1 or above is sufficient.

[0092] Operation

[0093] A computer program developed according to the specifications of this invention operates on a general purpose computer reading a COBOL source code program and analyzing it grammatically using known tools. This analysis can be done by hand-coding a parser as described in Aho, et al. (pp.215-259), or it can be done using an automatically generated parser, also as described in Aho, et al. (pp.259-266). The preferred implementation uses the yacc tool to do this analysis described by Aho, et al. (pp.259-266).

[0094] After analyzing the COBOL program, the appropriate template is chosen from the figures and claims. Upon recognizing a COBOL template, the corresponding Java template is completed using the data described within the description section, and then that completed template is output.

[0095] With each line of COBOL input, the program increases a COBOL line counter to track the COBOL line number. With each line of COBOL output, the program increases a Java line counter to track the Java line number. This line counters information can be used when outputting debugging information in order to complete the statement debugging template.

[0096] To summarize, the invention processes a plurality of COBOL source code programs into a plurality of Java source code class files, including optional inner class files, and can process the procedures and data of the COBOL source code into the corresponding methods and data of the Java source code. It does so by recognizing a COBOL template and then outputting a corresponding completed Java template.

[0097] Although the description above contains many detailed descriptions, these descriptions should not be construed as limiting the scope of the invention but merely as providing illustrations of some of the presently preferred implementations of this invention. For example, names generated by the invention may be consistently modified, spacing between tokens in the templates is irrelevant and may be modified, and order of methods within a class does not effect the integrity of the invention. Thus the scope of the invention should be determined by the appended claims and their legal equivalents, rather than by examples given.