CA2201254C - A system for automated interface generation for computer programs operating in different environments - Google Patents
A system for automated interface generation for computer programs operating in different environments Download PDFInfo
- Publication number
- CA2201254C CA2201254C CA002201254A CA2201254A CA2201254C CA 2201254 C CA2201254 C CA 2201254C CA 002201254 A CA002201254 A CA 002201254A CA 2201254 A CA2201254 A CA 2201254A CA 2201254 C CA2201254 C CA 2201254C
- Authority
- CA
- Canada
- Prior art keywords
- program
- cics
- environment
- transaction
- cobol
- Prior art date
- Legal status (The legal status 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 status listed.)
- Expired - Fee Related
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/54—Interprogram communication
- G06F9/541—Interprogram communication via adapters, e.g. between incompatible applications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/30—Creation or generation of source code
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
- Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10S707/00—Data processing: database and file management or data structures
- Y10S707/99931—Database or file accessing
- Y10S707/99933—Query processing, i.e. searching
- Y10S707/99934—Query formulation, input preparation, or translation
Abstract
A system for automated interface generation for computer programs operating in different environments. The system comprises a utility which imports a CICS COBOL transaction source file, parses the communication area of the CICS file, and generates modelling information. The modelling information represents the nature and structure of data in the CICS
transaction source file, and is written to a persistent data store. The utility uses the information in the persistent data store to generate an application programming interface. The application programming interface takes the data values from the other language and translates them to a formatted CICS COBOL
communications area. This format is derived from the definition of the CICS communications area contained in the imported CICS
program. After the translation runs, the resulting CICS COBOL
communications area is translated back to the data values of the other language. This translation step also handles the data conversion between different codepages and machine architectures and program semantics. The resulting language values represent the result of the transaction. The CICS transaction is accessed using the CICS External Call Interface mechanism.
transaction source file, and is written to a persistent data store. The utility uses the information in the persistent data store to generate an application programming interface. The application programming interface takes the data values from the other language and translates them to a formatted CICS COBOL
communications area. This format is derived from the definition of the CICS communications area contained in the imported CICS
program. After the translation runs, the resulting CICS COBOL
communications area is translated back to the data values of the other language. This translation step also handles the data conversion between different codepages and machine architectures and program semantics. The resulting language values represent the result of the transaction. The CICS transaction is accessed using the CICS External Call Interface mechanism.
Description
.. 2~'a '(2 ~
A SYSTEM FOR AUTOMATED INTERFACE GENERATION
FOR COMPUTER PROGRAMS OPERATING IN DIFFERENT ENVIRONMENTS
FIELD OF THE INVENTION
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.
BACKGROUND OF THE INVENTION
to 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.
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.
BRIEF S~JNIMARY OF THE INVENTION
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.
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.
In a first aspect, the present invention provides an import utility method for interfacing a COBOL program through a CICS transaction to a program in another program environment, said import utility method comprising: (a) scanning the CICS
transaction for said COBOL program and producing a data description of said CICS transaction; (b) parsing said data description into a corresponding token stream; (c) 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 means in a program for invoking said CICS transaction from said other program environment.
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.
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 means in a program for invoking said CICS transaction from said second program environment.
BRIEF DESCRIPTION OF THE DRAWINGS
Reference will now be made, by way of example, to the accompanying drawing, which shows a preferred embodiment of the present invention, and in which:
Fig. 1 shows in diagrammatic form the components of a system for automated interface generation according to the present invention.
, DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
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 l0 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 APPENDIX shows a generated client stub code in JAVA.
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.
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.
z~~ ~~ ~~~
A SYSTEM FOR AUTOMATED INTERFACE GENERATION
FOR COMPUTER PROGRAMS OPERATING IN DIFFERENT ENVIRONMENTS
FIELD OF THE INVENTION
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.
BACKGROUND OF THE INVENTION
to 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.
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.
BRIEF S~JNIMARY OF THE INVENTION
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.
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.
In a first aspect, the present invention provides an import utility method for interfacing a COBOL program through a CICS transaction to a program in another program environment, said import utility method comprising: (a) scanning the CICS
transaction for said COBOL program and producing a data description of said CICS transaction; (b) parsing said data description into a corresponding token stream; (c) 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 means in a program for invoking said CICS transaction from said other program environment.
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.
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 means in a program for invoking said CICS transaction from said second program environment.
BRIEF DESCRIPTION OF THE DRAWINGS
Reference will now be made, by way of example, to the accompanying drawing, which shows a preferred embodiment of the present invention, and in which:
Fig. 1 shows in diagrammatic form the components of a system for automated interface generation according to the present invention.
, DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
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 l0 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 APPENDIX shows a generated client stub code in JAVA.
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.
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.
z~~ ~~ ~~~
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.
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.
The primary function of the parser 15 is to parse the records in the COBOL program 1 for the specified O1 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.
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.
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.
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.
_ g _ 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) .
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.
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).
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.
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.
i ~~o ~2~
For each elementary item in a group, the COBOL
importer l0 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.
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.
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).
The COBOLImporter class also includes a method to create <parm class>. The method belongs to the COBOLImporter class as a private member.
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 ~Q '~2 4 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. Descriptions for the classes derived from 'Record', 'ElementaryItem', 'Group', GroupItem' and 'CobolCommArea' are also described below.
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 , icStrin _ _ _ p g_.
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.
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 (Vo1.37 No.01 January 1994), titled: Cobol Data-Type Support in the Interface Definition Language. The type conversions are:
numeric type: 9(1-4) converted to unsigned short int numeric type: 9(5-9) converted to unsigned long int numeric type: S9(I-4) converted to short int - numeric type: S9(5-9) converted to long int numeric type: {S}9(n)V9(m) converted to double numeric type: {S}{V}P(n)9(m) converted to double - numeric type: {S}9(n)P(m){V} converted to double - usage comp-1 converted to float usage comp-2 converted to double - alpha types converted to IString - alphanumeric types converted to IString - alphanumeric-edited types converted to IString numeric-edited types converted to IString (Including numeric types using the 'blank when zero' clause).
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.
The usage- data member indicates the usage for the COBOL record. The usage- member may have the following values: noUsage, display, displayNumeric, displayNonNumeric, comp, compl, 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.
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.
~2a 1~5~
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.
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.
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.
The addAsAttribute method is also implemented for the Elementaryltem 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.
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_ 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_ 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.
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.
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.
~2Q'f2~~.
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".
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.
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.
22~ ~2 ~
The present invention may be embodied in other specific forms without departing from the spirit or essential characteristics thereof. Therefore, the presently discussed embodiments are considered to be illustrative and not restrictive, the scope of the invention being indicated by the appended claims rather than the foregoing description, and all changes which come within the meaning and range of equivalency of the claims are therefore intended to be embraced therein.
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.
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.
The primary function of the parser 15 is to parse the records in the COBOL program 1 for the specified O1 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.
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.
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.
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.
_ g _ 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) .
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.
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).
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.
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.
i ~~o ~2~
For each elementary item in a group, the COBOL
importer l0 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.
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.
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).
The COBOLImporter class also includes a method to create <parm class>. The method belongs to the COBOLImporter class as a private member.
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 ~Q '~2 4 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. Descriptions for the classes derived from 'Record', 'ElementaryItem', 'Group', GroupItem' and 'CobolCommArea' are also described below.
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 , icStrin _ _ _ p g_.
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.
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 (Vo1.37 No.01 January 1994), titled: Cobol Data-Type Support in the Interface Definition Language. The type conversions are:
numeric type: 9(1-4) converted to unsigned short int numeric type: 9(5-9) converted to unsigned long int numeric type: S9(I-4) converted to short int - numeric type: S9(5-9) converted to long int numeric type: {S}9(n)V9(m) converted to double numeric type: {S}{V}P(n)9(m) converted to double - numeric type: {S}9(n)P(m){V} converted to double - usage comp-1 converted to float usage comp-2 converted to double - alpha types converted to IString - alphanumeric types converted to IString - alphanumeric-edited types converted to IString numeric-edited types converted to IString (Including numeric types using the 'blank when zero' clause).
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.
The usage- data member indicates the usage for the COBOL record. The usage- member may have the following values: noUsage, display, displayNumeric, displayNonNumeric, comp, compl, 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.
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.
~2a 1~5~
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.
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.
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.
The addAsAttribute method is also implemented for the Elementaryltem 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.
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_ 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_ 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.
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.
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.
~2Q'f2~~.
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".
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.
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.
22~ ~2 ~
The present invention may be embodied in other specific forms without departing from the spirit or essential characteristics thereof. Therefore, the presently discussed embodiments are considered to be illustrative and not restrictive, the scope of the invention being indicated by the appended claims rather than the foregoing description, and all changes which come within the meaning and range of equivalency of the claims are therefore intended to be embraced therein.
Claims (12)
1. An import utility method for interfacing a COBOL
program through a CICS transaction to a program in another program environment, said import utility method comprising:
(a) scanning the CICS transaction for said COBOL
program and producing a data description of said CICS
transaction;
(b) parsing said data description into a corresponding token stream;
(c) 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 means in a program for invoking said CICS transaction from said other program environment.
program through a CICS transaction to a program in another program environment, said import utility method comprising:
(a) scanning the CICS transaction for said COBOL
program and producing a data description of said CICS
transaction;
(b) parsing said data description into a corresponding token stream;
(c) 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 means in a program for invoking said CICS transaction from said other program environment.
2. The import utility method as claimed in claim 1, wherein said invoking means comprises a method call for accessing said CICS transaction through an External Call Interface.
3. The import utility method as claimed in claim 2, further including;
selecting a CICS transaction in the COBOL program, and;
specifying a class in said program for said method.
selecting a CICS transaction in the COBOL program, and;
specifying a class in said program for said method.
4. The import utility method as claimed in claim 2, wherein said program environment comprises a C++ environment.
5. The import utility method as claimed in claim 2, wherein said program environment comprises a JAVA environment.
6. 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.
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.
7. The computer system as claimed in claim 6, wherein said data model includes means for converting data types between said first and second program environments.
8. The computer system as claimed in claim 7, wherein said data model includes means for converting codepages for said first and second program environments.
9. The computer system as claimed in claim 7, wherein said data model includes means for converting between CICS program semantics and JAVA programming semantics.
10. A computer program product for use in a 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;
computer readable code means recorded on said medium for enabling 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 means in a program for invoking said CICS transaction from said second program environment.
a recording medium;
computer readable code means recorded on said medium for enabling 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 means in a program for invoking said CICS transaction from said second program environment.
11. The computer system as claimed in claim 10, wherein said second program environment comprises a C++ environment.
12. The computer system as claimed in claim 10, wherein said second program environment comprises a JAVA environment.
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CA002201254A CA2201254C (en) | 1997-03-27 | 1997-03-27 | A system for automated interface generation for computer programs operating in different environments |
| US09/046,366 US6230117B1 (en) | 1997-03-27 | 1998-03-23 | System for automated interface generation for computer programs operating in different environments |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CA002201254A CA2201254C (en) | 1997-03-27 | 1997-03-27 | A system for automated interface generation for computer programs operating in different environments |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CA2201254A1 CA2201254A1 (en) | 1998-09-27 |
| CA2201254C true CA2201254C (en) | 2002-08-20 |
Family
ID=4160282
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CA002201254A Expired - Fee Related CA2201254C (en) | 1997-03-27 | 1997-03-27 | A system for automated interface generation for computer programs operating in different environments |
Country Status (2)
| Country | Link |
|---|---|
| US (1) | US6230117B1 (en) |
| CA (1) | CA2201254C (en) |
Families Citing this family (49)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6412082B1 (en) * | 1997-12-17 | 2002-06-25 | Sony Corporation | Method and apparatus for selecting computer programs based on an error detection mechanism |
| US6453464B1 (en) * | 1998-09-03 | 2002-09-17 | Legacyj. Corp., Inc. | Method and apparatus for converting COBOL to Java |
| US6931623B2 (en) * | 1999-08-30 | 2005-08-16 | Touchnet Information Systems, Inc. | Method of accessing data and logic on existing systems through dynamic construction of software components |
| US6973639B2 (en) * | 2000-01-25 | 2005-12-06 | Fujitsu Limited | Automatic program generation technology using data structure resolution unit |
| US6993745B1 (en) | 2000-03-09 | 2006-01-31 | Electronic Data Systems Corporation | Method and system for modeling a legacy computer system |
| US7111233B1 (en) | 2000-03-09 | 2006-09-19 | Electronic Data Systems Corporation | Method and system for applying XML schema |
| US6687873B1 (en) * | 2000-03-09 | 2004-02-03 | Electronic Data Systems Corporation | Method and system for reporting XML data from a legacy computer system |
| US7114147B2 (en) * | 2000-03-09 | 2006-09-26 | Electronic Data Systems Corporation | Method and system for reporting XML data based on precomputed context and a document object model |
| WO2001069423A1 (en) * | 2000-03-15 | 2001-09-20 | Hiawatha Island Software Co., Inc. | System and method for providing computer network search services |
| US8600783B2 (en) | 2000-08-18 | 2013-12-03 | The Crawford Group, Inc. | Business to business computer system for communicating and processing rental car reservations using web services |
| US7899690B1 (en) | 2000-08-18 | 2011-03-01 | The Crawford Group, Inc. | Extended web enabled business to business computer system for rental vehicle services |
| US20030125992A1 (en) * | 2001-12-26 | 2003-07-03 | The Crawford Group, Inc. | Web browser based computer network for processing vehicle rental transactions on a large scale |
| AU2001294555A1 (en) * | 2000-09-14 | 2002-03-26 | Bea Systems Inc. | Xml-based graphical user interface application development toolkit |
| AU2002351577A1 (en) * | 2001-06-29 | 2003-03-03 | Convergys Cmg Utah Inc. | Method for creating application programming interfaces for internal applications |
| US20030093551A1 (en) * | 2001-10-17 | 2003-05-15 | Graham Taylor | Adaptive software interface |
| KR100456023B1 (en) * | 2001-12-19 | 2004-11-08 | 한국전자통신연구원 | Method and apparatus for wrapping existing procedure oriented program into component based system |
| US7243334B1 (en) | 2002-01-16 | 2007-07-10 | Prelude Systems, Inc. | System and method for generating user interface code |
| CN100390731C (en) * | 2002-03-07 | 2008-05-28 | 霍尼韦尔国际公司 | Interaction design system |
| US8108231B2 (en) | 2002-06-14 | 2012-01-31 | The Crawford Group, Inc. | Method and apparatus for improved customer direct on-line reservation of rental vehicles |
| US20040039612A1 (en) | 2002-06-14 | 2004-02-26 | Neil Fitzgerald | Method and apparatus for customer direct on-line reservation of rental vehicles |
| US7219338B2 (en) * | 2003-03-25 | 2007-05-15 | Microsoft Corporation | Multi-language compilation |
| US7620958B2 (en) * | 2003-06-30 | 2009-11-17 | Microsoft Corporation | Transaction interoperability using host-initiated processing |
| US20050240354A1 (en) * | 2003-08-27 | 2005-10-27 | Ascential Software Corporation | Service oriented architecture for an extract function in a data integration platform |
| US8060553B2 (en) * | 2003-08-27 | 2011-11-15 | International Business Machines Corporation | Service oriented architecture for a transformation function in a data integration platform |
| US20050222931A1 (en) * | 2003-08-27 | 2005-10-06 | Ascential Software Corporation | Real time data integration services for financial information data integration |
| US20050232046A1 (en) * | 2003-08-27 | 2005-10-20 | Ascential Software Corporation | Location-based real time data integration services |
| US8041760B2 (en) * | 2003-08-27 | 2011-10-18 | International Business Machines Corporation | Service oriented architecture for a loading function in a data integration platform |
| US20050262193A1 (en) * | 2003-08-27 | 2005-11-24 | Ascential Software Corporation | Logging service for a services oriented architecture in a data integration platform |
| US8307109B2 (en) * | 2003-08-27 | 2012-11-06 | International Business Machines Corporation | Methods and systems for real time integration services |
| US20050228808A1 (en) * | 2003-08-27 | 2005-10-13 | Ascential Software Corporation | Real time data integration services for health care information data integration |
| US20060069717A1 (en) * | 2003-08-27 | 2006-03-30 | Ascential Software Corporation | Security service for a services oriented architecture in a data integration platform |
| US20050223109A1 (en) * | 2003-08-27 | 2005-10-06 | Ascential Software Corporation | Data integration through a services oriented architecture |
| US7814142B2 (en) * | 2003-08-27 | 2010-10-12 | International Business Machines Corporation | User interface service for a services oriented architecture in a data integration platform |
| US20050108690A1 (en) * | 2003-11-17 | 2005-05-19 | Tira Wireless Inc. | System and method of generating applications for mobile devices |
| US7953769B1 (en) * | 2004-01-21 | 2011-05-31 | Computer Associates Think, Inc. | XML data packaging system and method |
| US7970801B1 (en) * | 2004-01-21 | 2011-06-28 | Computer Associates Think, Inc. | Data packaging system and method |
| US20050251533A1 (en) * | 2004-03-16 | 2005-11-10 | Ascential Software Corporation | Migrating data integration processes through use of externalized metadata representations |
| US7761406B2 (en) * | 2004-03-16 | 2010-07-20 | International Business Machines Corporation | Regenerating data integration functions for transfer from a data integration platform |
| US20050243604A1 (en) * | 2004-03-16 | 2005-11-03 | Ascential Software Corporation | Migrating integration processes among data integration platforms |
| US7653905B1 (en) | 2004-09-08 | 2010-01-26 | American Express Travel Related Services Company, Inc. | System and method for management of requests |
| US7386840B1 (en) * | 2004-09-09 | 2008-06-10 | Lockheed Martin Corporation | Method, apparatus, and program for source code translation from COBOL to object-oriented code |
| US8271309B2 (en) | 2006-03-16 | 2012-09-18 | The Crawford Group, Inc. | Method and system for providing and administering online rental vehicle reservation booking services |
| KR100791303B1 (en) * | 2006-08-22 | 2008-01-04 | 삼성전자주식회사 | Apparatus and method for making component of build block |
| US8533689B2 (en) * | 2008-10-10 | 2013-09-10 | The Boeing Company | Method, apparatus and computer program product for creating inter-language interface |
| FR2944366B1 (en) * | 2009-04-09 | 2012-02-03 | Bull Sas | METHOD AND DEVICE FOR PERFORMING HETEROGENEOUS TRANSACTIONAL COMPONENTS |
| US9317266B1 (en) * | 2014-11-12 | 2016-04-19 | Bank Of America Corporation | Leveraging legacy applications for use with modern applications |
| DE102015204751A1 (en) * | 2015-03-17 | 2016-09-22 | Robert Bosch Gmbh | DEVICE AND METHOD FOR CREATING APPLICATIONS FOR APPLICATIONS FOR A COMMUNICATION BETWEEN A SERVER AND A CLIENT OF AN AUTOMATION PLANT |
| GB201518949D0 (en) * | 2015-10-27 | 2015-12-09 | Richardson Andrew J And Openiolabs | Communications protocol |
| US10042622B2 (en) * | 2016-02-19 | 2018-08-07 | International Business Machines Corporation | Methods and systems of generating ease of use interfaces for legacy system management facilities |
Family Cites Families (11)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6006277A (en) * | 1987-11-06 | 1999-12-21 | Bea Systems, Inc. | Virtual software machine for enabling CICS application software to run on UNIX based computer systems |
| CA2025142A1 (en) * | 1989-09-28 | 1991-03-29 | John W. White | Portable and dynamic distributed applications architecture |
| ES2106771T3 (en) * | 1989-11-30 | 1997-11-16 | Seer Technologies Inc | COMPUTER ASSISTED SOFTWARE ENGINEERING UTILITY. |
| US5301270A (en) * | 1989-12-18 | 1994-04-05 | Anderson Consulting | Computer-assisted software engineering system for cooperative processing environments |
| US5329619A (en) * | 1992-10-30 | 1994-07-12 | Software Ag | Cooperative processing interface and communication broker for heterogeneous computing environments |
| US5634127A (en) * | 1994-11-30 | 1997-05-27 | International Business Machines Corporation | Methods and apparatus for implementing a message driven processor in a client-server environment |
| US5761494A (en) * | 1996-10-11 | 1998-06-02 | The Sabre Group, Inc. | Structured query language to IMS transaction mapper |
| US6094688A (en) * | 1997-01-08 | 2000-07-25 | Crossworlds Software, Inc. | Modular application collaboration including filtering at the source and proxy execution of compensating transactions to conserve server resources |
| US5987247A (en) * | 1997-05-09 | 1999-11-16 | International Business Machines Corporation | Systems, methods and computer program products for building frameworks in an object oriented environment |
| US5923879A (en) * | 1997-07-02 | 1999-07-13 | Ncr Corporation | Conversion system and method between corba and c/c++ architectures for corba data pairs/couples |
| US6014517A (en) * | 1998-01-06 | 2000-01-11 | Emc Corporation | Automatic creation of C to assembler interface |
-
1997
- 1997-03-27 CA CA002201254A patent/CA2201254C/en not_active Expired - Fee Related
-
1998
- 1998-03-23 US US09/046,366 patent/US6230117B1/en not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| CA2201254A1 (en) | 1998-09-27 |
| US6230117B1 (en) | 2001-05-08 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CA2201254C (en) | A system for automated interface generation for computer programs operating in different environments | |
| US6430556B1 (en) | System and method for providing a query object development environment | |
| Bolton | Pure Corba | |
| JP4146983B2 (en) | Process method and data processing system for calling method of server object | |
| EP0861467B1 (en) | An object oriented programming based global registry system and method | |
| US6611844B1 (en) | Method and system for java program storing database object entries in an intermediate form between textual form and an object-oriented form | |
| US6609130B1 (en) | Method for serializing, compiling persistent textual form of an object-oriented database into intermediate object-oriented form using plug-in module translating entries according to grammar | |
| US5459868A (en) | Interpretive object-oriented facility which can access pre-compiled classes | |
| US6298354B1 (en) | Mechanism and process to transform a grammar-derived intermediate form to an object-oriented configuration database | |
| Troelsen | Pro C# 2008 and the. NET 3.5 Platform | |
| US6542899B1 (en) | Method and system for expressing information from an object-oriented database in a grammatical form | |
| EP1030250A1 (en) | An intelligent object-oriented configuration database serializer | |
| EP1030251A1 (en) | Process for transforming configuration database grammar into intermediate form that simplifies database generation | |
| JPH10111802A (en) | Code generator in application field in distribution object system | |
| JP2000515281A (en) | Method and apparatus for describing interfaces, operations and data types defined by an interface definition language | |
| Oberleitner et al. | The Vienna Component Framework enabling composition across component models | |
| Drayton et al. | C# in a Nutshell | |
| Dewan et al. | An approach to support automatic generation of user interfaces | |
| Boshernitsan | Harmonia: A flexible framework for constructing interactive language-based programming tools | |
| Orr et al. | OMOS-an object server for program execution | |
| Zajac et al. | An open distributed architecture for reuse and integration of heterogeneous NLP components | |
| US20050177818A1 (en) | Integration of external tools into an existing design environment | |
| Auerbach et al. | The mockingbird system: A compiler-based approach to maximally interoperable distributed programming | |
| Nash | Accelerated C# 2008 | |
| US7934193B2 (en) | Processing a module specification to produce a module definition |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| EEER | Examination request | ||
| MKLA | Lapsed |