System for automated interface generation for computer programs operating in different environments

[0002] A one card microfiche appendix containing 20 frames of source code of a computer program used with the present invention is appended hereto as Appendix A.

[0003] 1. Technical Field

[0004] The present invention relates to computer systems, and more particularly to an automated system for generating an interface between computer programs in different programming languages and operating in different environments.

[0005] 2. Prior Art

[0006] The trend in computing is towards systems which support multiple program environments. The support of multiple program environments provides a flexible computing platform. For example, computer programming languages supported by personal IBM compatible computers include JAVA, C⁺⁺, C, PASCAL, FORTRAN, COBOL, and BASIC running on DOS or OS/2 operating systems. Another trend in computer systems is the implementation of distributed computing systems. Distributed computing comprises a client-server model in which a client program and a server program run, and typically the client and the server execute on different systems in the computer network.

[0007] As computer systems become more open and flexible, the variety of program environments makes the sharing of information difficult. Associated with the addition of each program environment is a new way of handling data. In the context of COBOL, accessing existing or legacy COBOL on a mainframe or networked computer is typically performed through CICS (Customer Information Control System) transactions. In order to remotely access the COBOL program from another computer environment such as C⁺⁺ or JAVA requires the programmer to perform three tedious and time consuming tasks. First, the programmer must establish a mapping between the other language types and the COBOL data types. Second, the programmer must translate the data and semantics of the other language to the corresponding COBOL data type. This problem is compounded by the fact that the interaction of CICS programs is foreign to most JAVA users who are most familiar with components. In addition, the COBOL data must be formatted according to the alignment rules of COBOL so that the CICS transaction recognizes the data being passed. Third, the data passed between the two machines (i.e. computing environments) must be translated to the format of the target machine. In practical terms this means that a codepage translation must be done and native data such as floating point and integer data must be translated to the format of the target machine. The translation of the data must be performed in both directions, i.e. the call of the CICS transaction from the target machine, and the return to the CICS transaction from the target machine.

[0008] The present invention provides a system for generating an interface which defines the mapping from an existing COBOL program to computer programs written in other languages, and is particularly suited to the C⁺⁺ and JAVA platforms. The system according to the present invention creates an interface which defines the mapping of data types and different program semantics between COBOL and the other language, translates the data types between COBOL and the other language, and handles the conversion between codepages and machine architectures.

[0009] The system according to the present invention also incorporates the unit of work semantic into the created interface. The unit of work semantic is part of the CICS External Call Interface. The interface that is created and the code that is generated to implement the interface conform to the component model which allows for seamless integration with other tools.

[0010] In a first aspect, the present invention provides an import utility for interfacing a COBOL program through a CICS transaction to a program in another program environment, said import utility comprising: (a) scanner means for scanning the CICS transaction for said COBOL program and producing a data description of said CICS transaction; (b) parser means for parsing said data description into a corresponding token stream; (c) importer means for importing said token stream and generating a data model describing said CICS transaction in said other program environment, said data model including means for converting information between said CICS transaction and a program in said other program environment, and said data model being compatible for generating code for an invoking mechanism in a program for invoking said CICS transaction from said other program environment.

[0011] In a second aspect, the present invention provides a computer system having a first program environment and a second program environment, said computer system comprising: an importer having scanner means for scanning a transaction interface for a program running in said first program environment and producing an output describing the transaction interface for the program in said first program environment, parser means for parsing the output description from said scanner means and generating a token stream, creator means for creating a data model from said token stream, wherein said data model includes means for converting information from said transaction interface for a program running in said second program environment; a compiler having means for compiling a program in said second program environment and said data model to produce an executable program, said executable program including invoking means derived from said data model for accessing the program operating in said first program environment.

[0012] In another aspect, the present invention provides a computer program product for use in computer system having a first program environment and a second program environment, said first program environment providing an operating platform for a COBOL program and CICS transactions, said computer program product comprising: a recording medium; means recorded on said medium for instructing said computer system to perform the steps of, (a) scanning the CICS transaction in said COBOL program and producing a data description of said CICS transaction; (b) parsing said data description into a corresponding token stream; (c) creating a data model from said token stream wherein said data model describes said CICS transaction in said second program environment and includes means for converting information between said first and second program environments, and said data model being compatible for generating code for an invoking mechanism in a program for invoking said CICS transaction from said second program environment.

[0013] Preferred embodiments of the present invention will now be described, by way of example only, with reference to the accompanying drawing, in which:

[0014] FIG. 1 shows in diagrammatic form the components of a system for automated interface generation according to the present invention.

[0015] The present invention provides a system for automated interface generation for computer programs operating in different environments. The interface generated by the system allows an application program to seamlessly access a transaction in another program from a remote location. In the following description, the system is described in the context of a C⁺⁺ application accessing a COBOL program through the CICS transaction environment. (The CICS or Customer Information Control System is a known mechanism which controls the input/output access to a COBOL program.) It will however be understood that the system has wider applicability to other languages including JAVA, and the attached microfiche APPENDIX shows a generated client stub code in JAVA.

[0016] Reference is made to FIG. 1 which shows a COBOL importer 10 according to the present invention. The importer 10 interfaces to a COBOL program 1 by reading a CICS transaction interface 3 from the file system and creating mapping information (i.e. a model) for the Common Data Model (CDM) model 5. As will be understood by those skilled in the art, the CDM is a data structure for storing “meta-data” which is used by the builder for the C⁺⁺ or JAVA programming environments. The meta-data is used to generate C⁺⁺ and JAVA constructs which will provide the capability to seamlessly invoke the CICS transaction from an application program in C⁺⁺ (or JAVA) using an IBM CICS External Call Interface (ECI) to the CICS transaction 3.

[0017] As shown in FIG. 1, the COBOL importer 10 comprises a graphical user interface or GUI 11, a scanner 13, a parser 15 and an importer 17. The operation of these components results in the mapping of the CICS transaction 3 to a method in a user-specified class in the C⁺⁺ environment or JAVA.

[0018] The GUI 11 provides the facility to query the programmer (i.e. user) for the information needed for the COBOL importer 10 to generate the constructs for the CDM model 5. Through dialog generated by the GUI 11, the user is queried for the name of the class in C⁺⁺ which will contain the method (i.e. client stub 7) representing the CICS transaction, the method name to create in the class, the file name of the transaction, the name of the 01 Level record in the COBOL file, and the name of the transaction to run as identified to the ECI. Optionally, the user supplies an ID for the CICS transaction.

[0019] The scanner 13 interfaces to the CICS transaction 3 for the COBOL program 1 (specified by the user). The scanner 13 scans the file containing the CICS transaction 3 to produce a token stream for the parser 15. The scanner 13 produces the token stream expected by the parser 15. The scanner 13 is implemented to differentiate the various kinds of COBOL picture strings and produce different tokens for use by the parser 15.

[0020] The primary function of the parser 15 is to parse the records in the COBOL program 1 for the specified 01 Level records, for example DFHCOMMAREA 4 for the CICS transaction 3 to construct the representation of the “commarea” as C⁺⁺ data types in a C⁺⁺ class structure. The input and output data for the CICS transaction 3 are specified in the DFHCOMMAREA 4 of the COBOL program 1. The “commdata area” comprises a group of records which describe the format and size of the data expected by the CICS transaction 3. The commdata area is also used to return results back to the calling C⁺⁺ program.

[0021] In a typical implementation, the parser 15 will not be as semantically rich as an actual parser for COBOL programs, and the semantic actions are kept simple by creation of the class ‘Record’. As result, the COBOL importer 10 expects that the CICS transaction compiles cleanly with a COBOL compiler.

[0022] The importer module 17 provides a number of functions. First, the importer 17 contains the classes which drive the parsing of the COBOL program through the parser 15. Secondly, the importer module 17 stores the information generated by the operation of the parser 15, and thirdly, in response to the parser 15, the importer 17 adds the appropriate constructs and information into the CDM data model 5.

[0023] As described above the GUI 11 queries the user through a GUI dialog for the name of the C⁺⁺ class or JAVA to contain the method representing the CICS transaction 3 for the COBOL program 1, the name of the method and the name of the CICS transaction 3. The C⁺⁺ class named by the user in the GUI 11 is created on the first import of the transaction 3 to the class. The class contains the methods that will drive the transaction via the CICS/ECI (External Call Interface) and is marked in the CDM model 5 as having been created by the COBOL importer 10. If the class name is found to already exist in the CDM model 5 but was created using a method other than the COBOL importer 10, the GUI 11 prompts the user for another name. Similarly, the user provided method name is checked if it already exists in the named class. The COBOL importer 10 allows the user to add several transactions to the CICS/ECI class. The same CICS transaction 3 may be imported more than once as long as the user chooses a different method name for each import operation.

[0024] The COBOL importer 10 creates the following C⁺⁺ constructs for the CDM data model 5. The constructs are used to generate the code 6 for a client stub 7 in the C⁺⁺ program when the application is compiled. At runtime, the client stub 7 invokes the CICS transaction 3 through the IBM CICS External Call Interface (ECI).

[0025] The COBOL importer 10 creates a user-specified class: <user class>. The <user class> is created on the first import of a CICS transaction 3 to that class.

[0026] The importer creates a public method in <user class> using the user-specified name: <method>. The signature for the method is <method>(<parm class>* pParmBlock), (<parm class> is described below).

[0027] For each <method>, the importer creates a class: <parm class> which contains declarations for the parameters to the CICS transaction 3. The class <parm class> also provides inspector (‘get’) and manipulator (‘set’) methods for each elementary item in the data area DFHCOMMAREA 4.

[0028] For each group item in the DFHCOMMAREA 4, the importer 10 creates: a ‘nested’ class: <containing class>_ <group>, where <group> is the name of the group item in the COBOL program 1; a private data member: <group>_ of this class in the <containing class>; and a default constructor for the nested class having the form: <containing class>_<group>( ). It will be understood that in a CDM implementation, the COBOL importer 10 will utilize actual CDM scoped classes, and the CDM will handle the scoping of the class names.

[0029] For each elementary item in a group, the COBOL importer 10 also creates a private data member: <item>_ in the containing class, where <item> is the name of the elementary item in the COBOL program 1. If this item is not an array or a member of a group which is itself an array, the COBOL importer 10 also creates a manipulator (‘set’) method and an inspector (‘get’) method in the <parm class>. The get and set methods allow the user to access and manipulate data in the DFHCOMMAREA 4. The ‘set’ and ‘get’ methods preferably take the following form: void set<item>(const <basetype>& a<item>) and <basetype> <item>( ) const.

[0030] In the implementation of the COBOL importer 10 it is preferable that all items appear as public data members in the generated C⁺⁺ code, and not as private members. This allows a user to access records which are arrays using direct manipulation.

[0031] The importer 17 component in FIG. 1 comprises the following major classes: COBOLImporter, Record, ElementaryItem (derived from Record), Group (derived from Record), GroupItem (derived from Group), and CobolCommArea (derived from Group).

[0032] The COBOLImporter class also includes a method to create <parm class>. The method belongs to the COBOLImporter class as a private member.

[0033] The importer 17 includes the class ‘Record’ which is an abstract base class. The class Record encapsulates the behaviour and data associated with a single COBOL record from the CICS transaction 3. The Record class is designed to store information obtained by the parser 15 which is necessary to create the constructs for the CDM model 5 required to support CICS/ECI calls to the original CICS transaction 3. An instance of one of the classes derived from ‘Record’ is created by the parser 15 as each new record declaration is encountered in the COBOL program 1. The constructor for a ‘Record’ takes the owning COBOL group, the COBOL record name and the level as arguments. To ensure only derived classes are created, the constructor for ‘Record’ is specified as ‘protected’. The abstract base class ‘Record’ is described in more detail below.

[0034] Descriptions for the classes derived from ‘Record’, ‘ElementaryItem’, ‘Group’, GroupItem’ and ‘CobolCommArea’ are also described below.

[0035] The class ‘Record’ includes a number of public methods. The public methods comprise inspectors and manipulators for the following protected data members: name_, level_, owner_, filler_, alignment_, picString₁₃, cPlusPlusType_, usage_, sign_, and arrayBound_. The name_ data member contains the name of the COBOL record. The level_ data member contains the level of the COBOL record. The owner_ data member points to the group to which the COBOL record belongs. The filler_ data member indicates if the current record is designated as ‘filler’ in the COBOL program 1. The alignment_ data member indicates if the current record is designated as ‘sync’ in the COBOL program 1. The picString_ data member contains the picture string definition for the COBOL record.

[0036] The cPlusPlusType data member contains a pointer to the C⁺⁺ type for the COBOL record. The following type conversions were chosen for COBOL importer 10 based on published IBM Technical Disclosure Bulletin (Vol. 37 No.01 January 1994), titled: Cobol Data-Type Support in the Interface Definition Language. The type conversions are:

[0037] numeric type: 9(1-4) converted to unsigned short int

[0038] numeric type: 9(5-9) converted to unsigned long int

[0039] numeric type: S9(1-4) converted to short int

[0040] numeric type: S9(5-9) converted to long int

[0041] numeric type: {S}9(n)V9(m) converted to double

[0042] numeric type: {S}{V}P(n)9(m) converted to double

[0043] numeric type: {S}9(n)P(m){V} converted to double

[0044] usage comp-1 converted to float

[0045] usage comp-2 converted to double

[0046] alpha types converted to IString

[0047] alphanumeric types converted to IString

[0048] alphanumeric-edited types converted to IString

[0049] numeric-edited types converted to IString (Including numeric types using the ‘blank when zero’ clause).

[0050] Items enclosed in brace brackets ‘{}’ indicate optional items. The type of the cPlusPlusType member is ‘CPlusPlusType*’. There is an instance of this class declared for each ‘base type’ required by the COBOL importer 10. The base types comprise: IString, unsigned long int, unsigned short int, long int, short int, float, and double.

[0051] The usage_ data member indicates the usage for the COBOL record. The usage_ member may have the following values: nousage, display, displayNumeric, displayNonNumeric, comp, comp1, comp2, and comp3. The usage_ member is initialized to ‘noUsage’ when the record is constructed. The sign_ data member indicates the sign for the COBOL record. The sign_ can have the following values: nosign, leading, trailing, leadingseparate, and trailingseparate.

[0052] The arrayBound_ data member contains the arrayBound of the COBOL record. If the record in the COBOL program uses the ‘occurs’ clause, then arrayBound_ is set to the number of occurrences of the record. Otherwise, arrayBound_ is zero.

[0053] The alignment method for an elementary item returns the alignment for the group to which it belongs if no alignment is set for the item itself. Otherwise, the alignment method returns the alignment of this object.

[0054] The usage method for an elementary item returns the usage for the group to which it belongs if no usage is set for the item itself. Otherwise, the usage method returns the alignment of this object.

[0055] The sign method for an elementary item returns the sign for the group to which it belongs if no sign is set for the item itself. Otherwise, the sign method returns the alignment of this object.

[0056] The addAsAttribute method is also implemented for the ElementaryItem class. The addAsAttribute method contains all the actions necessary to add the item to the containing class as a private data member. If the item is not an array, the addAsAttribute method also adds an inspector and manipulator method to <parm class> to allow the user to access and manipulate the data member's value. The picture string, COBOL type (or PICAUGMENTOR), filler designation, and alignment properties are assigned for the data member in the CDM model 5.

[0057] The class CobolCommArea is a concrete class derived from the class ‘Group’. A single object of the CobolCommArea class is instantiated by the importer in the class COBOLImporter to represent the group record for the DFHCOMMAREA 4 from the CICS transaction 3. This object acts as the ‘root’ of the tree of records constructed by the parser 15. The constructor takes the name of the COBOL program file, the transaction name and transaction ID as arguments. The constructor for the base class ‘Group’ is invoked with the ‘owner’ set to 0 (NULL), the name ‘DFHCOMMAREA’ and ‘level’ equal to 1.

[0058] In order to generate the appropriate code (i.e. client stub) to utilize the CICS/ECI middleware, certain property/value pairs are expected in the model for various CDM model constructs. The model constructs include DMMOOClass, DMMethod, and DMDataMember.

[0059] The method for the model is DMMethod and the method is created in <user class>. The property value IDAECI TRANSACTION is set to the name of the CICS transaction for the method DMMethod. This property is also used on the methods ‘UOWCommitMethod’ and ‘UOWBackoutMethod’ (see below) which are automatically created in <user class>. The property is set to the method name in these cases. The property IDAECI TRANSID is set to the user provided transaction ID.

[0060] Properties are also used to indicate the inspector and manipulator methods created for the user in <parm class>. These properties are IDAECI_GET and IDAECI SET and are set in the model for the inspector and manipulator methods, respectively. The value of these properties is the fully qualified class name of the attribute to be inspected/manipulated. Each method also has the property ATTRIB_NAME set to the name of the attribute.

[0061] The data member for the model is DMDataMember. Each data member created for an elementary item from the DFHCOMMAREA 4 has the following three properties: (1) IDAECI_PICSTRING; (2) IDAECI_PICAUGMENTOR; and (3) IDAECI_ALIGNMENT.

[0062] The original COBOL picture string clause is assigned to the IDAECI_PICSTRING property. The value of IDAECI_PICAUGMENTOR is a string which comprises the ‘COBOL type’ as listed below possibly followed by “+FILLER” designation. The “FILLER” is a keyword in COBOL which allows the COBOL programmer to define the size of unnamed portions on a structure to ensure the correct packing of named records. The COBOL importer 10 names these record items as “fill<n>”, where <n> is the occurrence of the filler in the DFHCOMMAREA 4 minus one. The COBOL types are “SIGN_LEADING”, “SIGN TRAILING”, “SIGN_LEADING_SEPARATE”, “SIGN_TRAILING SEPARATE”, “DISPLAY”, “DISPLAY_NUMERIC”, “DISPLAY NONNUMERIC”, “COMP”, “COMP1”, “COMP2”, and “COMP3”.

[0063] In addition to the user-specified methods created in a CICS/ECI class by the COBOL importer 10, four methods are made available in the class to handle logical units of work. These methods are (a) _IDAStartUOWO Start a logical unit of work; (b) _IDAEndUOWO End a logical unit of work when the next user-specified method (i.e. transaction) is called; (c) _IDACommitUOWO Commit the current logical unit of work; and (d) _IDABackoutUOWO Backout the current logical unit of work. There can be a maximum of one logical unit of work outstanding in a class at any given time. It is noted that the unit of work semantic is achieved through inheritance.

[0064] It will be understood that while the COBOL importer 10 according to the present invention was described in the context of C⁺⁺, the importer 10 is readily adaptable to programs in the JAVA language by using JAVA code and data types. The attached APPENDIX shows the details of the generated code for a client stub in JAVA.

[0065] While the invention has been particularly shown and described with respect to preferred embodiments thereof, it will be understood by those skilled in the art that the foregoing and other changes in form and details may be made therein without departing from the spirit and scope of the invention.

[Inline image omitted. See PDF.]



[Inline image omitted. See PDF.]



[Inline image omitted. See PDF.]



[Inline image omitted. See PDF.]



[Inline image omitted. See PDF.]



[Inline image omitted. See PDF.]



[Inline image omitted. See PDF.]



[Inline image omitted. See PDF.]



[Inline image omitted. See PDF.]



[Inline image omitted. See PDF.]



[Inline image omitted. See PDF.]



[Inline image omitted. See PDF.]



[Inline image omitted. See PDF.]



[Inline image omitted. See PDF.]



[Inline image omitted. See PDF.]



[Inline image omitted. See PDF.]



[Inline image omitted. See PDF.]



[Inline image omitted. See PDF.]



[Inline image omitted. See PDF.]