CA2290167C - Automated interface generation for computer programs in different environments - Google Patents
Automated interface generation for computer programs in different environments Download PDFInfo
- Publication number
- CA2290167C CA2290167C CA002290167A CA2290167A CA2290167C CA 2290167 C CA2290167 C CA 2290167C CA 002290167 A CA002290167 A CA 002290167A CA 2290167 A CA2290167 A CA 2290167A CA 2290167 C CA2290167 C CA 2290167C
- Authority
- CA
- Canada
- Prior art keywords
- ims
- program
- message
- transaction
- environment
- 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
- 238000004590 computer program Methods 0.000 title claims abstract description 33
- 238000000034 method Methods 0.000 claims abstract description 56
- 238000004519 manufacturing process Methods 0.000 claims abstract description 7
- 230000008569 process Effects 0.000 claims description 6
- 230000008676 import Effects 0.000 abstract description 31
- 238000006243 chemical reaction Methods 0.000 abstract description 2
- 230000000007 visual effect Effects 0.000 description 9
- 241000412750 Cicones Species 0.000 description 4
- 238000011161 development Methods 0.000 description 4
- 230000003993 interaction Effects 0.000 description 4
- 239000000203 mixture Substances 0.000 description 4
- 238000010586 diagram Methods 0.000 description 3
- 238000007726 management method Methods 0.000 description 3
- 238000013507 mapping Methods 0.000 description 3
- 238000012545 processing Methods 0.000 description 3
- 230000007246 mechanism Effects 0.000 description 2
- 230000003287 optical effect Effects 0.000 description 2
- 241000518994 Conta Species 0.000 description 1
- 230000005540 biological transmission Effects 0.000 description 1
- VTTONGPRPXSUTJ-UHFFFAOYSA-N bufotenin Chemical compound C1=C(O)C=C2C(CCN(C)C)=CNC2=C1 VTTONGPRPXSUTJ-UHFFFAOYSA-N 0.000 description 1
- 230000001413 cellular effect Effects 0.000 description 1
- 230000008859 change Effects 0.000 description 1
- 238000004891 communication Methods 0.000 description 1
- 238000010276 construction Methods 0.000 description 1
- 238000013075 data extraction Methods 0.000 description 1
- 238000013499 data model Methods 0.000 description 1
- 230000001419 dependent effect Effects 0.000 description 1
- 239000012530 fluid Substances 0.000 description 1
- 239000000463 material Substances 0.000 description 1
- 230000003340 mental effect Effects 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 230000002085 persistent effect Effects 0.000 description 1
- 238000011084 recovery Methods 0.000 description 1
- 239000007787 solid Substances 0.000 description 1
- 230000003068 static effect Effects 0.000 description 1
- 239000000126 substance Substances 0.000 description 1
- 238000012795 verification Methods 0.000 description 1
Classifications
-
- 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
- G06F8/38—Creation or generation of source code for implementing user interfaces
-
- 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
Abstract
Automated interface generation for computer programs operating in different environments is provided. An automated interface generation system, method, computer program product and article of manufacture is provided comprising an import utility and a runtime environment. The import utility imports a COBOL IMS transaction source file, parses the specified input and output message records, and generates an application programming interface.
The application programming interface operates with the runtime environment to take the data values from the language of a different environment and translate them to a formatted IMS
input message. This format is derived from the definition of the input message record in the COBOL
IMS transaction source file. After the IMS transaction has executed, the resulting IMS output message is translated back to the data values of the language of the different environment, said values including the results of the transaction. The translation step handles data conversion between different code pages, machine architectures, and program semantics, and handles the dynamic nature of IMS messages.
The application programming interface operates with the runtime environment to take the data values from the language of a different environment and translate them to a formatted IMS
input message. This format is derived from the definition of the input message record in the COBOL
IMS transaction source file. After the IMS transaction has executed, the resulting IMS output message is translated back to the data values of the language of the different environment, said values including the results of the transaction. The translation step handles data conversion between different code pages, machine architectures, and program semantics, and handles the dynamic nature of IMS messages.
Description
AUTOMATED INTERFACE C'.ENERATION FOR COMPUTER PROGRAMS IN
DIFFERENT ENVIRONMENTS
FIELD OF THE INVENTION
The invention relates to automated generation of interfaces to programs in different environments. Particularly, the invention relates to automated generation of interfaces to programs designed for and operating; on IBM Corporation's IMSO (Information Management System) transaction and database server system so as to support the dynamic composing and reading of data messages exchanged between an interfacing program and the program operating on the IMS system.
BACKGROUND OF THE '.INVENT ION
An attribute of modern corriputer systems is that they support many programming environments, such as the JavaTM, C, C++, PASCAL, FORTRAN, COBOL and BASIC
computer language environments. Further, many distributed computing systems today provide a client-server model in which a client program can run and interact with a server program, where often the client program and server program run on different systems in a computer network.
Thus, in a distributed environment including possibly many different computer systems supporting any number of different programming environments, sharing of data between different program environments is becoming increasingly important.
Particularly, there is a need in new program environments to access services or data provided by older program environments often through distributed computing systems.
An example of where there is a need for such cross-environment access is with modern object-oriented languages having access to data or services of IMS systems. An IMS system is a complete online transaction processing environment that provides continuous availability and data integrity. An IMS systern comprises a database and a data communication system. The IMS
database system provides for management and storage of data and processes concurrent database calls. The IMS data cornmunication system provides high-volume, high-performance, high-capacity transaction processing for the IMS database system.
In IMS systems, many IMS legacy programs are written in COBOL. In order to perform transactions with these COBOL IMS programs using programs in another computer programming language environment such as a C++ or Java language environment, a programmer must:
= Map between the other computer language data types and the COBOL data types;
= Translate the data and semantics of the other computer language into data corresponding to the COBOL data type(s), wherein the data must be aligned according to COBOL
alignment rules;
= Connect the IMS system and the system containing the programs in the other language in order to allow passage of data between the systems;
= Format the data passing from the programs written in the other language to the IMS system into an IMS message forniat; and = Translate the data returned from ttie IMS system, which is in an IMS message format with its contained COBOL data types, to data corresponding to the other computer language data type(s).
An IMS connection feature called CICON of the IBM@ VisualAge for Smalltalk application development product provides access to transaction applications having MFS
(message formatting services) panels running under an IMS system. Notably however, CICON
only allows access to panel driven applications defining at least one panel using MFS. To provide such access, the VisualAge for Smalltalk product provides a parser for importing the MFS definitions and tools to recreate panel navigation based on user input.
The parser and tools provide the capability to enibody a series of interactions, without any user access, into one navigation and provides a way of mapping this navigation to an object developed in the VisualAge for Smalitalk environment. However, a disadvantage of CICON is that only transactions with defined MFS panels can be accessed. Since it is not required for an IMS
transaction to define such pai:iels, CICON does not optimally allow access to all legacy business applications.
A second tool that allows access to legacy applications is the CICS@/ECI
access tool included with the IBM VisualAge for Java, Enterprise Edition application development product.
This tool allows access to COBOI, transactions running under the IBM CICS
(Customer Information Control System) software system. This tool uses a parser to import a COBOL
program in the CICS system and to generate stubs for communicating and exchanging data with the CICS system. The disadvantage of this tool is its static definition of the data to be exchanged with the CICS system. Once the stubs are generated, the contents of the data buffer to be sent or received from the CICS system cannot be changed. Rather, an IMS system uses input and output messages for interacting with IMS transactions and the content of these messages is dynamic, in that the message defines its size and layout. The COBOL IMS transaction source file input and output message records define data types and also, in part, the layout, but not the actual size of, the messages exchanged. Therefore, it is not possible to use the CICS tool to access COBOL
transactions running in an IMS system.
Thus, it would be advantageous to provide a program runtime capable of reading and composing the IMS message data stream of an IMS system (or any analogous system or environment) as well as providing an import utility with the capability of generating interface stubs capable of handling the dynamic nature of that message data stream.
SUMMARY OF THE INVENTION
The invention provides for automated generation of interfaces to programs in different environments. Particularly, the invention provides for automated generation of interfaces to programs designed for and operating; on IBM Corporation's IMSO (Information Management System) transaction and database server system so as to support the dynamic composing and reading of data messages exchanged between an interfacing program and the program operating on the IMS system.
There is provided a niethod for interfacing a program on an IMS system to a program in another program environment, comprising the steps of scanning an IMS
transaction with the program on the IMS system; and generating a program interface, the program interface providing means for invoking the IMS transaction and converting data between the IMS
transaction and the program in another program environrnent. The above method may also be provided wherein the interface comprises a transaction part which provides for invoking the IMS
transaction; a message part which provides for composing or reading an IMS message; and a ipage part which provides for dynamic composing or reading of an IMS message. The above methods may also further comprise the step of providing a runtime, the runtime comprising means for translating data types of the program in another program environment to data types used in a message to the IMS system; means for composing the message to the IMS system; means for translating data types used in a message from the IMS system to data types of the program in another program environment; and means for reading the message from the IMS system. And the runtime may further comprise means for accessing the IMS transaction via the MQSeries messaging interface.
Further, the above methods tnay comprise the step of compiling the program interface into the program in another program environrnent. And some of the above methods may further comprise the step of compiling the runtime into the program in another program environment. And, the above methods may further comprise the step of providing means for converting code pages between the another program enviromnent and the IMS system.
There is also provided a computer program product for interfacing a program on an IMS
system to a program in another program environment, comprising instruction means for scanning an IMS transaction with the program on the IMS system; and instruction means for generating a program interface, the program interface providing means for invoking the IMS
transaction and converting data between the IMS transaction and the program in another program environment.
The above computer program product may also be provided wherein the interface comprises a transaction part which provicles for invoking the IMS transaction; a message part which provides for composing or reading an IMS message; and a lpage part which provides for dynamic composing or reading of an IMS message. The above computer program products may further comprise instructions means for providing a runtime, the runtime comprising means for translating data types of the prograni in another program environment to data types used in a message to the IMS system; means for composing the message to the IMS system;
means for translating data types used in a message from the IMS system to data types of the program in another program environme at; and naeans for reading the message from the IMS
system. And, the runtime may further comprise means for accessing the IMS transaction via the MQSeries messaging interface. And the above computer program products may further comprise instruction means for compiling the program interface into the program in another program environment.
And some of the above computer program products may further comprise instruction means for compiling the runtime into the program in another program environment. And, the above computer program products may further comprise instruction means for converting code pages between the another program environrnent and the IMS system.
Further, there is provided a computer program product for interfacing a program on an IMS system to a program in anothei- program environment, comprising instruction means for scanning an IMS transaction with the program on the IMS system producing a data description of said IMS transaction; and instruction means for using said data description to generate code for invoking said IMS transaction. The above computer program product may further comprise instruction means for using said data description to generate code to process message elements of said IMS transaction for use with the program in another language environment.
Also provided is a computer program product for interfacing a program on an IMS
system to a program in another program environment, comprising instruction means for invoking an IMS transaction with the program. on the IMS system; and instruction means for converting data between the IMS transaction and the program in another program environment. The above computer program product rnay also be provided wherein the instruction means for converting further comprises instruction. means fbr translating data types of the program in another program environment to data types used in a message to the IMS system; instruction means for composing the message to the IMS sys tem; instruction means for translating data types used in a message from the IMS system to clata types of the program in another program environment; and instruction means for reading the message from the IMS system. The above computer program products may also be provided wherein the instruction means for converting further comprises instruction means for accessing the IMS transaction via the MQSeries messaging interface. And the above computer program products may further comprise instruction means for converting code pages between the another program environment and the IMS system.
There is also provided an article of manufacture comprising a computer usable medium having computer readable program code means therein for executing the method steps of any one of the above methods.
Also provided is a system for interfacing a program on an IMS system to a program in another program environment, comprising means for scanning an IMS transaction with the program on the IMS system; and meains for generating a program interface, the program interface providing means for invok:ing the IMS transaction and converting data between the IMS
transaction and the program in another program environment. The above system may further comprise means for providing a runtime, the runtime comprising means for translating data types of the program in another program environment to data types used in a message to the IMS
system; means for composing the message to the IMS system; means for translating data types used in a message from the IMS system to data types of the program in another program environment; and means for :reading the message from the IMS system.
There is further provided a system for interfacing a program on an IMS system to a program in another prograrei environment, comprising means for scanning an IMS
transaction with the program on the IMS systemi producing a data description of said IMS
transaction; and means for using said data description to generate code for invoking said IMS
transaction. The above system may further comprise means for using said data description to generate code to CA9-1998-0001-CAl 7 process message elements of said IMS transaction for use with the program in another language environment.
A system for interfaci:ng a program on an IMS system to a program in another program environment is also provided compirising means for invoking an IMS transaction with the program on the IMS system; and means for converting data between the IMS
transaction and the program in another program environment. The above system is also provided wherein the means for converting further comprises means for translating data types of the program in another program environment to data types used in a message to the IMS system; means for composing the message to the IMS system; means for translating data types used in a message from the IMS
system to data types of the pi-ogram in another program environment; and means for interpreting the message from the IMS system.
BRIEF DESCRIPTION OF THE DRAWINGS
The present invention. is illusti-ated by way of example and not limitation in the figures of the accompanying drawings in which like references indicate similar or corresponding elements and in which:
Figure 1 shows in diagrammatic form the components of a system for automated interface generation according to the present invention;
Figure 2 is a diagram depicting the import utility of Figure 1 in detail;
Figure 3 depicts the structure of an example IMS message used by the invention;
Figure 4A and 4B is a flowchart of the data extraction of IMS messages by the runtime of the present invention;
CA9-1998-0001-CAl 8 Figure 5 is source code of a simple COBOL IMS transaction that is supplied two numbers as input which the COBOL IT/IS program then adds and returns the result; and Figure 6 is the resulting generated C++ classes from the import utility using the simple COBOL IMS transaction in Figure 5 as input.
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
The preferred embodiment of the present invention provides a system, method, computer program product and article of manufacture for generating an interface which defines a mapping from a COBOL program designed for and operating on an IMS system (hereafter COBOL IMS
program) to a computer program written in another computer language such as the C++ and Java languages, for invoking an IMS transaction with the COBOL IMS program (hereafter a COBOL
IMS transaction) and for formatting and converting the COBOL IMS transaction data passing between the COBOL IMS program and the program written in the other computer language. The present invention creates an interface which handles 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, handles conversion between code pages and machine architectures of the systems operating the COBOL IMS program and the program written in the other language, formats the data from the program written in the other language into an IMS
input message to the COBOL IMS program, and converts an IMS output message from the COBOL IMS program into data usable by the program written in the other language.
Particularly, the present invention provides an import utility for interfacing a COBOL
IMS program to a progratn in another program language environment, the import utility comprising a means for scanning the COBOL IMS transaction and generating a program interface, the program interface provicling a means for invoking the COBOL IMS
transaction and for converting data between the COBOL IMS transaction and the program in the other program environment. The generated program interface comprises three parts: (a) a transaction part which provides means for invoking an IMS transaction; (b) a message part which provides means for composing or reading an IMS input or output message respective; and (c) a lpage part which provides the means for dynainic composing or reading of an IMS message. These parts support visual and non-visual prograrnming in the other language.
Further, the present irLvention also provides a program runtime for the generated program interface. The program ruritime provides a generic means for invoking a COBOL
IMS
transaction using the IBM MQSeries messaging interface, for formatting data from the program written in the other language into an IMS input message, and for converting an IMS
output message into data usable by the program written in the other language.
The interfaces generated by the import utility together with the program runtime allow access to COBOL IMS
transactions in, preferably, adistributed environment.
It should be apparent to those skilled in the art that the present invention may be implemented on systems other than IMS systems. The invention may be implemented on systems that provide substantially the same functionality as an IMS system. Similarly, the invention may be implemented on systems that provide just some or all of the key features/functionality that the invention uses and/or addresses. Further, the invention may be implemented in whole or in part as software which software may be stored and/or operated on one or more machines in one or more interconnected systems.
Referring to Figure 1, a schematic of the preferred embodiment of the invention for providing an interface to a COBOL I1vIS transaction 80 with a COBOL IMS
program 90 from a client application 40 writteri in another computer language, for invoking the COBOL IMS
transaction, and for formatting and converting COBOL IMS transaction data passing between the client application and the COBOL IMS program is depicted. Generally, the COBOL
IMS
transaction source file 10 is passed into import utility 20. In the import utility, the COBOL IMS
transaction source file is parsed and the results are used to create the generated code 30 which defines the interface with the COBOL IMS transaction. The generated code is used to form the compiled generated code stub 50 which works with the program runtime 60 of the invention and the client application to invoke the COBOL IMS transaction through MQSeries messaging services 70 and to format and convert the COBOL IMS transaction data passing between the client application and the COBOL IMS program.
In the preferred embodiment, the import utility is integrated into a software application development program, such as the IBM VisualAge C++ software development tool, and the development program provides compilation of the generated code and the inclusion of the runtime and the compiled generated code stub into the client application. It should be apparent to those skilled in the art however that the import utility may operate on a standalone basis and interact with other tool(s) that facilitate compilation and provision of the runtime functionality of the invention. Additionally, the impcirt utility may be designed from 'scratch' or simply be an extension of a code generator= (which are well-known in the art).
Further, in the preferred embodiment, the import utility will create the generated code on a remote workstation 94 (remote relative to the IMS system) for compilation with the client application and the runtime on the remote workstation. And, in the preferred embodiment, the client application (along with the compiled generated code and the runtime) run on the remote workstation which is connec-ted by MQSeries messaging services and hardware connections to the IMS system, typically an OS/390 host computer 96, all more particularly depicted in Figure 1. However, it should be apparent to those skilled in the art that any number of different hardware configurations and system interconnection topologies could be used in accordance with the invention. Without limitation, ariy one or any combination of the components generally described in Figure 1, e.g., the impoirt utility, the client application, the runtime, the compiled generated code, etc. could operate on the same or different workstations or systems. Indeed, all components of the invention could operate on the IMS system host.
More particularly, the import utility facilitates the creation of an interface for a client application 40 written in another computer language to a COBOL IMS transaction with a COBOL IMS application program by reading the IMS transaction source file 10.
In the preferred embodiment, the IMS transaction source file, which is initially located on the file system of the IMS system host, is read from the file system of the computer environment in which the import utility operates. In the prefen-ed embodiment, the user inputs IMS transaction information to the import utility by way of corrunand line arguments passed when invoking the import utility. The user specifies the name of the COBOL IMS transaction to be invoked, the name of the IMS
transaction source file containing relevant message definitions, the name of the main class to be generated by the import utility and the name of the method representing the COBOL IMS
transaction invocation. The user is also required to specify the names of the COBOL data structures representing the input arid output messages. These messages are interpreted as arguments to the aforementioned method. It should be apparent to those skilled in the art that input of arguments could equally be provided by a graphical user interface means, provided to the import utility by a program invoking the import utility, or provided by any other conventional input means, whether manual or autoniatic.
Referring to Figure 2, the inaport utility 20 comprises three components:
scanner 22, parser 24 and code generator 26. The scanner reads the COBOL IMS transaction source file 10 and generates a stream of tok:ens that are input to the parser. The parser interprets the stream of tokens and generates data model code parts corresponding to the contents of the COBOL IMS
transaction messages. These parts are then used by the code generator to generate C++ classes 30, the program interface, representing the IMS input and output messages contained in the COBOL IMS transaction source file. Clearly the classes could be generated in computer languages other than C++, typically the language corresponding to the language of the client application. The generated data types of the input and output messages describe the format of the data stream to be sent to the IMS transaction and the format of the reply sent by the IMS
transaction back to the C++ program.
In the preferred embodiment, the import utility creates the several C++
constructs as described above, namely a transaction part, a message part and a lpage part, which are used to generate the compiled generated code stub used, in combination with the runtime, to invoke the COBOL IMS transaction through the :[BM MQSeries services.
The first construct or part - the main, user specific class, user_class, with a name defined by the user to the import utility - contains the properties and methods needed to communicate with the IMS system. These properties and methods are included in user_class by means of multiple inheritance from generated utility classes, described below, contained in the program runtime classes. These classes include IDAInterfaceBase class, IXDMQIMSConversation class and other member classes of the IBM Open Class library.
The utility classes generated by the import utility include the user classDefinition class, the user class_stub class and. the ims__user class_cstub class. The main purpose of these classes is to provide the abstract definitions properties used by the user_class. The properties provide unique identifiers to identify the class, methods which return Strings containing the signature of user methods, and an abstract implemientation of each user method.
The user_class also defines the implementation of the user defined method, user method, as specified by the user to the import utility. The invocation of this method causes interaction with the IMS transaction as understood by the IMS system including sending an input message to the IMS system and receiving an output message from the IMS system. The method expects two arguments corresponding to the input and output messages of the IMS
transaction. The messages themselves are user_message classes generated by the import utility from the COBOL
data structures representing the input and output messages specified by the user to the import utility.
The second construct or part, a message part - class user_message - provides means for composing or reading an IMS input or output message respectively. Messages exchanged with an IMS system are divided into logical pages or lpages, depicted by way of example in Figure 3 as lpage 1 and lpage 2, and the user_message class reflects this structure by defining the sequence of lpages as its data member.
Since an lpage itself can contain one or more segments and the message can contain two or more logic pages, a third construct or part - a class user lpage - is defined for each logical CA9-1998-0001-CAl 14 page and the generated code 30 conta:ins a class definition for each defined lpage. The segments, depicted by way of example as segl, seg2, and seg3 in Figure 3, contained in a lpage are itself classes, generated from the C'OBOL clata structures by the import utility. The multiple segments within a lpage are grouped ir.ito a segment sequence. The generated code defines all segments of a particular lpage as the data members of that lpage class. Further, the segments are comprised of fields, depicted by way of example as mfldl, mfld2, mfld3, mfld4 and mfld5 in Figure 3, which in turn are the basic COBOL data types. The generated code defines all fields of a particular segment as the data members of that segment class.
In all of the generated code 30, the definition of one class as a data member of, or included in, another class implies the existence of the methods to retrieve and set the value of such data member or includeci class.
In addition to the C++ code described above, the import utility also generates a description of visual and nonvisual parts in a format, in the preferred embodiment, understandable to the Visual Composition Editor included in the IBM VisualAge C++ product.
This description includes graphical representations of the user_class and the user_method as well as other generated classes and their data members. This allows the use of the generated code to visually create user applications using the Visual Composition Editor development functionality such as attribute to attribute connections. It should be apparent to those skilled in the art that formats for other visual or non-visual programming tools may be used.
After creation of the generated code by the import utility, the generated code is compiled (as the compiled generated code stub) with the runtime and client application.
Of course, in other program language environments, the generated code, the application and the runtime may be not be compiled together rather instead interlinked by other means. Once compiled together, the client application and program runtinie interact with the compiled generated code stub to allow access by the client application to a COBOL IMS transaction.
The program runtime 60 of the present invention comprises a set of C++ classes providing access from the application's system to an IMS system. Specifically, the runtime classes provide means to: translate the simple data types of the language used on the application's system to the COBOL data types used in a message to the IMS
system (IDACallHandle class); construct messages in a format understandable by the IMS system (IXDMQIMSCa1lHandlelnternal, IXDMQIMSTransaction and IXDMQIMSConversation classes); exchange the messages with the IMS system using IBM MQSeries services (IXDMQIMSRChnI and IXDMQIMSSChnI classes); read the message returned from the IMS
system (IXDMQIMSCa11Han.dlelnternal, IXDMQIMSTransaction and IXDMQIM S
Conversation classes); and translate the s;Imple COBOL data types contained in a message from the IMS
system to the data types of the language used on the application's system (IDACallHandle class).
The runtime handling of dynamic IMS system messages is described using an example of the reading of an IMS output: message but it is understood that the runtime may also be capable of composing such formatted messages to be sent to an IMS system e.g. as an IMS input message.
As described above, an IMS message can contain multiple lpages, which in turn can contain multiple segments occurring as one or more segment sequences. In any given segment sequence, one or more segrnents can be omitted. Each segment can contain multiple fields corresponding to the simple data types of the COBOL IMS transaction. Some or all data fields can be omitted. The actual structure of each message, said structure defined by the number of lpages in the message, the number of segment sequences in the lpage, and the number and size of CA9-1998-0001-CAl 16 all fields in the segment, is thus really only known at the time of generation of the messages. The ability of the IMS system to reorder lpages and their segment sequences and omit segments and fields prevents direct mappin;i, of the message to a set of generated data structures (classes/types) and thus requires a runtime to read each message and dynamically map the message to the generated data structures (classes/types). The handling of these dynamic messages by the runtime and the compiled generated code of the present invention is described below.
To accommodate all the possible messages, the runtime assumes that a message contains multiple lpages, each with multiple segment sequences, each containing multiple fields. Also, each generated class corresponding to the message, lpage, segment or field, contains the code to unmarshal the corresponding part of the IMS message. This code is combined using the C++
operator overloading mechanism to translate the whole IMS system message.
Initially, the message is copied into a buffer 100 and its length is stored.
Until or unless there is no data in the buffer, the runtime reads a sequence of lpages 110.
After making sure the buffer contains data 120 (using the notAtEndOfBuffer method of the InternalCaliHandle class), the next step is to verify that the data to be read belongs to the current lpage 130. This verification is done using the notAtEndOfBufferOrSeq method. This method uses the page bit and the lpage condition. The page bit is the fourth byte of the message segment. If its value is 0x40. the seginent is the first in the segment sequence of the lpage. The lpage condition consists of a reference value, comparator operator and the offset within the segment. The segment belongs to the lpage when the value at the offset compared, using the comparator operator, to the reference value evaluates to true. This method is used to determine whether the first segment iri the segment sequence belongs to the same lpage or is the first segment in the next lpage. If it is the first segment in the next lpage, the next lpage is processed 110. This comparison operation is necessary since a segment sequence for a lpage does not have to contain the same number of elements and can end after any segment.
If the segment belongs to the current lpage, its contents are unmarshalled.
First, the runtime verifies that the segment is ncit a null segment, that is, a segment containing no data 140.
Method notNullSegment checks whether the segment length specified in its length field is equal to 5, and if it is, whether the fifth byte of the segment is a null character.
The null character is transaction dependent and is defined by the user to the runtime 60. If the segment is empty, no data is read and the buffer pointer is advanced by 5 - the length of the empty segment 150. When the segment is not empty, the runtime strips the first four bytes of the segment containing the length and control information 160. This is done by invoking the method stripLL.
The next step is to unmarshal all the fields of the segment 170. Since fields can be omitted, the runtime checks for a null character before attempting to unmarshal a field 180. If the null character is present, the runtime advances the buffer pointer by the length of the field 190. If the field is truncated, that is the null character is not the first one in the field, the runtime only reads into the buffer up to the null cl.iaracter and advances the buffer pointer appropriately 200.
The fields and segments differ in that a truncated segment is physically shorter, whereas the field always occupies the same space.
After unmarshaling all the fields in the segment, the runtime verifies that it should continue to unmarshal the current lpage. Besides checking whether there is any more data in the buffer 120 (if there is no more data the unmarshalling is terminated), it verifies that the lpage condition is met and therefore whether the next segment belongs to the same lpage 130. If the condition is not met the runtime starts unmarshalling the next lpage 110.
Otherwise, the runtime verifies that the next segment contains data 140. If so, the segment and its fields are processed as described above. If not, the buffer pointer is advanced 150 and unmarshalling continues. In this manner, processing continues until all the data from the message has been retrieved and there is no more data in the buffer 120.
The format of the message sent to the IMS system depends on the state of the conversation between the application and the program on the IMS system. If there is a conversation between the application and the program, the message must not contain the name of the IMS transaction to be invoked, otherwise included in the first segment of the message. The runtime keeps track of the ongoing; conversations and verifies that only valid user data is included in the messages sent to the I1vIS system.
In addition, after every step of the conversation, the runtime writes the conversation identification to a persistent store. This step maintains a state to provide failure recovery. It is necessary because of an IMS, structure that does not terminate conversations that are unfinished and leaves them in an inconsistent state. The utility provided as the part of the program runtime allows automatic termination of all suspended conversations once the user program is restarted.
Referring to Figure 5, the source code of a sample COBOL IMS transaction is provided.
Its parts defining input and output messages format are shown between begin and end comments.
For the transaction to run correctly the data it receives must match exactly these definitions and therefore they determine the format of the generated C++ code.
Figure 6 presents a set of generated files containing C++ classes used to compose an input message sent to a COBOL IM S transaction and read an output message returned by the COBOL IMS transaction. It :includes complete source of the following files:
CA9-1998-0001-CAl 19 = myclass.hpp - contains the definition of the user class with the appropriate runtime initialization and a virtual definition of a method used to invoke the COBOL
IMS transaction (add).
= myclass.imc - defines a ~cstub class providing definition of the method used to invoke the COBOL IMS transaction (add) = myclass.hpd - defines stub and Ciefinition abstract classes, superclasses of the above cstub class = myclass.imd - defines classes representing: the input and output messages -myclass_add_O, myclass_add_I; lpages of'these messages - myclass_add_Lpagel, myclass_add_Lpage2; and fields of these lpages - m)/class_acld_Lpagel_args, myclass_add_Lpagel_result.
= myclass.vbe - contains adescription of visual parts of the generated code that can be used in the Visual Composition Editor (VCE) of IBM's VisualAge C++ development tool.
= myclass.cpp - defines notificatior.i identifiers used by classes to notify about the change of their state when the generated code is used in the VCE.
To use the generated code directly, without using the VCE, the user has to include the header file myclass.hpp, all other files and definitions are included automatically.
The detailed descriptions may have been presented in terms of program procedures executed on a computer ~or network of computers. These procedural descriptions and representations are the mearis used by those skilled in the art to most effectively convey the substance of their work to others skilled in the art. They may be implemented in hardware or software, or a combination of the two.
A procedure is here, and generally, conceived to be a self-consistent sequence of steps leading to a desired result. These steps are those requiring physical manipulations of physical quantities. Usually, though not necessarily, these quantities take the form of electrical or magnetic signals capable of being stored, transferred, combined, compared, and otherwise CA9-1998-0001-CAl 20 manipulated. It proves convenient at times, principally for reasons of common usage, to refer to these signals as bits, values, elements, symbols, characters, terms, numbers, objects, attributes or the like. It should be noted, however, that all of these and similar terms are to be associated with the appropriate physical quantities ancl are merely convenient labels applied to these quantities.
Further, the manipulations performed are often referred to in terms, such as adding or comparing, which are comr.aonly associated with mental operations performed by a human operator. No such capability of a human operator is necessary, or desirable in most cases, in any of the operations described herein which form part of the present invention;
the operations are machine operations. Useful machines for performing the operations of the present invention include general purpose digital computers or similar devices.
Each step of the method may lbe executed on any general computer, such as a mainframe computer, personal computer or the l ike and pursuant to one or more, or a part of one or more, program modules or objects generated from any programming language, such as C++, Java, Fortran or the like. And still further, each step, or a file or object or the like implementing each step, may be executed by special purpose hardware or a circuit module designed for that purpose.
In the case of diagrams depicted herein, they are provided by way of example.
There may be variations to these diagrams or the steps (or operations) described herein without departing from the spirit of the invention. For instance, in certain cases, the steps may be performed in differing order, or steps may be added, deleted or modified. All of these variations are considered to comprise part of the present invention as recited in the appended claims.
While the description herein rnay refer to interactions with the user interface by way of, for example, computer mouse operation, it will be understood that within the present invention the user is provided with the ability to interact with these graphical representations by any known computer interface mechanisms, including without limitation pointing devices such as computer mouses or trackballs, joysticks, touch screen or light pen implementations or by voice recognition interaction with the computer system.
While the preferred embodiment of this invention has been described in relation to the C++ language, this inventior.L need not be solely implemented using the C++
language. It will be apparent to those skilled in the art that the invention may equally be implemented in other computer languages, such as object oriented languages like Java and Smalltalk.
The invention is preferably implemented in a high level procedural or object-oriented programming language to communicate with a computer. However, the invention can be implemented in assembly or machine language, if desired. In any case, the language may be a compiled or interpreted language.
While aspects of the invention relate to certain computer language and other technological specifications (e.g. the Java Language Specification with respect to the Java computer language), it should be apparent that classes, objects, components and other such software and technological items referenced herein need not fully conform to the specification(s) defined therefor but rather may meet only some of the specification requirements. Moreover, the classes, objects, components and other such software and technological items referenced herein may be defined according to equivalent specification(s) other than as indicated herein that provides equivalent or similar functionality, constraints, etc. Accordingly, features, functionality, constraints, etc. may be used other than as defined by the computer language and other technological specification.
The invention may be implemented as an article of manufacture comprising a computer usable medium having computer reaclable program code means therein for executing the method CA9-1998-0001-CAl 22 steps of the invention, a program storage device readable by a machine, tangibly embodying a program of instructions executable by a machine to perform the method steps of the invention, or a computer program product. Such an article of manufacture, program storage device or computer program product may include, but is not limited to, CD-ROMs, diskettes, tapes, hard drives, computer RAM or ROM and/or the electronic, magnetic, optical, biological or other similar embodiment of the program. Indeed, the article of manufacture, program storage device or computer program product may include any solid or fluid transmission medium, magnetic or optical, or the like, for storing or transmitting signals readable by a machine for controlling the operation of a general or special purpose programmable computer according to the method of the invention and/or to structure its components in accordance with a system of the invention.
The invention may also be implemented in a system. A system may comprise a computer that includes a processor and a memory device and optionally, a storage device, an output device such as a video display and/or an input device such as a keyboard or computer mouse. Moreover, a system may comprise an interconnected network of computers. Computers may equally be in stand-alone form (such as the traditional desktop personal computer) or integrated into another apparatus (such a cellular telephone). The system may be specially constructed for the required purposes to perform, for example, the method steps of the invention or it may comprise one or more general purpose computers as selectively activated or reconfigured by a computer program in accordance with the teachings herein stored in the computer(s). The procedures presented herein are not inherently related to ajparticular computer system or other apparatus. The required structure for a variety of these systems will appear from the description given.
While this invention has been described in relation to preferred embodiments, it will be understood by those skilled in the ar1: that changes in the details of construction, arrangement of CA9-1998-0001-CA] 23 parts, compositions, processes, structures and materials selection may be made without departing from the spirit and scope of this invention. Many modifications and variations are possible in light of the above teaching. Thus, it should be understood that the above described embodiments have been provided by way of example rather than as a limitation and that the specification and drawing(s) are, accordingly, to be regarded in an illustrative rather than a restrictive sense.
CA9-1998-0001-CAl 24
DIFFERENT ENVIRONMENTS
FIELD OF THE INVENTION
The invention relates to automated generation of interfaces to programs in different environments. Particularly, the invention relates to automated generation of interfaces to programs designed for and operating; on IBM Corporation's IMSO (Information Management System) transaction and database server system so as to support the dynamic composing and reading of data messages exchanged between an interfacing program and the program operating on the IMS system.
BACKGROUND OF THE '.INVENT ION
An attribute of modern corriputer systems is that they support many programming environments, such as the JavaTM, C, C++, PASCAL, FORTRAN, COBOL and BASIC
computer language environments. Further, many distributed computing systems today provide a client-server model in which a client program can run and interact with a server program, where often the client program and server program run on different systems in a computer network.
Thus, in a distributed environment including possibly many different computer systems supporting any number of different programming environments, sharing of data between different program environments is becoming increasingly important.
Particularly, there is a need in new program environments to access services or data provided by older program environments often through distributed computing systems.
An example of where there is a need for such cross-environment access is with modern object-oriented languages having access to data or services of IMS systems. An IMS system is a complete online transaction processing environment that provides continuous availability and data integrity. An IMS systern comprises a database and a data communication system. The IMS
database system provides for management and storage of data and processes concurrent database calls. The IMS data cornmunication system provides high-volume, high-performance, high-capacity transaction processing for the IMS database system.
In IMS systems, many IMS legacy programs are written in COBOL. In order to perform transactions with these COBOL IMS programs using programs in another computer programming language environment such as a C++ or Java language environment, a programmer must:
= Map between the other computer language data types and the COBOL data types;
= Translate the data and semantics of the other computer language into data corresponding to the COBOL data type(s), wherein the data must be aligned according to COBOL
alignment rules;
= Connect the IMS system and the system containing the programs in the other language in order to allow passage of data between the systems;
= Format the data passing from the programs written in the other language to the IMS system into an IMS message forniat; and = Translate the data returned from ttie IMS system, which is in an IMS message format with its contained COBOL data types, to data corresponding to the other computer language data type(s).
An IMS connection feature called CICON of the IBM@ VisualAge for Smalltalk application development product provides access to transaction applications having MFS
(message formatting services) panels running under an IMS system. Notably however, CICON
only allows access to panel driven applications defining at least one panel using MFS. To provide such access, the VisualAge for Smalltalk product provides a parser for importing the MFS definitions and tools to recreate panel navigation based on user input.
The parser and tools provide the capability to enibody a series of interactions, without any user access, into one navigation and provides a way of mapping this navigation to an object developed in the VisualAge for Smalitalk environment. However, a disadvantage of CICON is that only transactions with defined MFS panels can be accessed. Since it is not required for an IMS
transaction to define such pai:iels, CICON does not optimally allow access to all legacy business applications.
A second tool that allows access to legacy applications is the CICS@/ECI
access tool included with the IBM VisualAge for Java, Enterprise Edition application development product.
This tool allows access to COBOI, transactions running under the IBM CICS
(Customer Information Control System) software system. This tool uses a parser to import a COBOL
program in the CICS system and to generate stubs for communicating and exchanging data with the CICS system. The disadvantage of this tool is its static definition of the data to be exchanged with the CICS system. Once the stubs are generated, the contents of the data buffer to be sent or received from the CICS system cannot be changed. Rather, an IMS system uses input and output messages for interacting with IMS transactions and the content of these messages is dynamic, in that the message defines its size and layout. The COBOL IMS transaction source file input and output message records define data types and also, in part, the layout, but not the actual size of, the messages exchanged. Therefore, it is not possible to use the CICS tool to access COBOL
transactions running in an IMS system.
Thus, it would be advantageous to provide a program runtime capable of reading and composing the IMS message data stream of an IMS system (or any analogous system or environment) as well as providing an import utility with the capability of generating interface stubs capable of handling the dynamic nature of that message data stream.
SUMMARY OF THE INVENTION
The invention provides for automated generation of interfaces to programs in different environments. Particularly, the invention provides for automated generation of interfaces to programs designed for and operating; on IBM Corporation's IMSO (Information Management System) transaction and database server system so as to support the dynamic composing and reading of data messages exchanged between an interfacing program and the program operating on the IMS system.
There is provided a niethod for interfacing a program on an IMS system to a program in another program environment, comprising the steps of scanning an IMS
transaction with the program on the IMS system; and generating a program interface, the program interface providing means for invoking the IMS transaction and converting data between the IMS
transaction and the program in another program environrnent. The above method may also be provided wherein the interface comprises a transaction part which provides for invoking the IMS
transaction; a message part which provides for composing or reading an IMS message; and a ipage part which provides for dynamic composing or reading of an IMS message. The above methods may also further comprise the step of providing a runtime, the runtime comprising means for translating data types of the program in another program environment to data types used in a message to the IMS system; means for composing the message to the IMS system; means for translating data types used in a message from the IMS system to data types of the program in another program environment; and means for reading the message from the IMS system. And the runtime may further comprise means for accessing the IMS transaction via the MQSeries messaging interface.
Further, the above methods tnay comprise the step of compiling the program interface into the program in another program environrnent. And some of the above methods may further comprise the step of compiling the runtime into the program in another program environment. And, the above methods may further comprise the step of providing means for converting code pages between the another program enviromnent and the IMS system.
There is also provided a computer program product for interfacing a program on an IMS
system to a program in another program environment, comprising instruction means for scanning an IMS transaction with the program on the IMS system; and instruction means for generating a program interface, the program interface providing means for invoking the IMS
transaction and converting data between the IMS transaction and the program in another program environment.
The above computer program product may also be provided wherein the interface comprises a transaction part which provicles for invoking the IMS transaction; a message part which provides for composing or reading an IMS message; and a lpage part which provides for dynamic composing or reading of an IMS message. The above computer program products may further comprise instructions means for providing a runtime, the runtime comprising means for translating data types of the prograni in another program environment to data types used in a message to the IMS system; means for composing the message to the IMS system;
means for translating data types used in a message from the IMS system to data types of the program in another program environme at; and naeans for reading the message from the IMS
system. And, the runtime may further comprise means for accessing the IMS transaction via the MQSeries messaging interface. And the above computer program products may further comprise instruction means for compiling the program interface into the program in another program environment.
And some of the above computer program products may further comprise instruction means for compiling the runtime into the program in another program environment. And, the above computer program products may further comprise instruction means for converting code pages between the another program environrnent and the IMS system.
Further, there is provided a computer program product for interfacing a program on an IMS system to a program in anothei- program environment, comprising instruction means for scanning an IMS transaction with the program on the IMS system producing a data description of said IMS transaction; and instruction means for using said data description to generate code for invoking said IMS transaction. The above computer program product may further comprise instruction means for using said data description to generate code to process message elements of said IMS transaction for use with the program in another language environment.
Also provided is a computer program product for interfacing a program on an IMS
system to a program in another program environment, comprising instruction means for invoking an IMS transaction with the program. on the IMS system; and instruction means for converting data between the IMS transaction and the program in another program environment. The above computer program product rnay also be provided wherein the instruction means for converting further comprises instruction. means fbr translating data types of the program in another program environment to data types used in a message to the IMS system; instruction means for composing the message to the IMS sys tem; instruction means for translating data types used in a message from the IMS system to clata types of the program in another program environment; and instruction means for reading the message from the IMS system. The above computer program products may also be provided wherein the instruction means for converting further comprises instruction means for accessing the IMS transaction via the MQSeries messaging interface. And the above computer program products may further comprise instruction means for converting code pages between the another program environment and the IMS system.
There is also provided an article of manufacture comprising a computer usable medium having computer readable program code means therein for executing the method steps of any one of the above methods.
Also provided is a system for interfacing a program on an IMS system to a program in another program environment, comprising means for scanning an IMS transaction with the program on the IMS system; and meains for generating a program interface, the program interface providing means for invok:ing the IMS transaction and converting data between the IMS
transaction and the program in another program environment. The above system may further comprise means for providing a runtime, the runtime comprising means for translating data types of the program in another program environment to data types used in a message to the IMS
system; means for composing the message to the IMS system; means for translating data types used in a message from the IMS system to data types of the program in another program environment; and means for :reading the message from the IMS system.
There is further provided a system for interfacing a program on an IMS system to a program in another prograrei environment, comprising means for scanning an IMS
transaction with the program on the IMS systemi producing a data description of said IMS
transaction; and means for using said data description to generate code for invoking said IMS
transaction. The above system may further comprise means for using said data description to generate code to CA9-1998-0001-CAl 7 process message elements of said IMS transaction for use with the program in another language environment.
A system for interfaci:ng a program on an IMS system to a program in another program environment is also provided compirising means for invoking an IMS transaction with the program on the IMS system; and means for converting data between the IMS
transaction and the program in another program environment. The above system is also provided wherein the means for converting further comprises means for translating data types of the program in another program environment to data types used in a message to the IMS system; means for composing the message to the IMS system; means for translating data types used in a message from the IMS
system to data types of the pi-ogram in another program environment; and means for interpreting the message from the IMS system.
BRIEF DESCRIPTION OF THE DRAWINGS
The present invention. is illusti-ated by way of example and not limitation in the figures of the accompanying drawings in which like references indicate similar or corresponding elements and in which:
Figure 1 shows in diagrammatic form the components of a system for automated interface generation according to the present invention;
Figure 2 is a diagram depicting the import utility of Figure 1 in detail;
Figure 3 depicts the structure of an example IMS message used by the invention;
Figure 4A and 4B is a flowchart of the data extraction of IMS messages by the runtime of the present invention;
CA9-1998-0001-CAl 8 Figure 5 is source code of a simple COBOL IMS transaction that is supplied two numbers as input which the COBOL IT/IS program then adds and returns the result; and Figure 6 is the resulting generated C++ classes from the import utility using the simple COBOL IMS transaction in Figure 5 as input.
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
The preferred embodiment of the present invention provides a system, method, computer program product and article of manufacture for generating an interface which defines a mapping from a COBOL program designed for and operating on an IMS system (hereafter COBOL IMS
program) to a computer program written in another computer language such as the C++ and Java languages, for invoking an IMS transaction with the COBOL IMS program (hereafter a COBOL
IMS transaction) and for formatting and converting the COBOL IMS transaction data passing between the COBOL IMS program and the program written in the other computer language. The present invention creates an interface which handles 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, handles conversion between code pages and machine architectures of the systems operating the COBOL IMS program and the program written in the other language, formats the data from the program written in the other language into an IMS
input message to the COBOL IMS program, and converts an IMS output message from the COBOL IMS program into data usable by the program written in the other language.
Particularly, the present invention provides an import utility for interfacing a COBOL
IMS program to a progratn in another program language environment, the import utility comprising a means for scanning the COBOL IMS transaction and generating a program interface, the program interface provicling a means for invoking the COBOL IMS
transaction and for converting data between the COBOL IMS transaction and the program in the other program environment. The generated program interface comprises three parts: (a) a transaction part which provides means for invoking an IMS transaction; (b) a message part which provides means for composing or reading an IMS input or output message respective; and (c) a lpage part which provides the means for dynainic composing or reading of an IMS message. These parts support visual and non-visual prograrnming in the other language.
Further, the present irLvention also provides a program runtime for the generated program interface. The program ruritime provides a generic means for invoking a COBOL
IMS
transaction using the IBM MQSeries messaging interface, for formatting data from the program written in the other language into an IMS input message, and for converting an IMS
output message into data usable by the program written in the other language.
The interfaces generated by the import utility together with the program runtime allow access to COBOL IMS
transactions in, preferably, adistributed environment.
It should be apparent to those skilled in the art that the present invention may be implemented on systems other than IMS systems. The invention may be implemented on systems that provide substantially the same functionality as an IMS system. Similarly, the invention may be implemented on systems that provide just some or all of the key features/functionality that the invention uses and/or addresses. Further, the invention may be implemented in whole or in part as software which software may be stored and/or operated on one or more machines in one or more interconnected systems.
Referring to Figure 1, a schematic of the preferred embodiment of the invention for providing an interface to a COBOL I1vIS transaction 80 with a COBOL IMS
program 90 from a client application 40 writteri in another computer language, for invoking the COBOL IMS
transaction, and for formatting and converting COBOL IMS transaction data passing between the client application and the COBOL IMS program is depicted. Generally, the COBOL
IMS
transaction source file 10 is passed into import utility 20. In the import utility, the COBOL IMS
transaction source file is parsed and the results are used to create the generated code 30 which defines the interface with the COBOL IMS transaction. The generated code is used to form the compiled generated code stub 50 which works with the program runtime 60 of the invention and the client application to invoke the COBOL IMS transaction through MQSeries messaging services 70 and to format and convert the COBOL IMS transaction data passing between the client application and the COBOL IMS program.
In the preferred embodiment, the import utility is integrated into a software application development program, such as the IBM VisualAge C++ software development tool, and the development program provides compilation of the generated code and the inclusion of the runtime and the compiled generated code stub into the client application. It should be apparent to those skilled in the art however that the import utility may operate on a standalone basis and interact with other tool(s) that facilitate compilation and provision of the runtime functionality of the invention. Additionally, the impcirt utility may be designed from 'scratch' or simply be an extension of a code generator= (which are well-known in the art).
Further, in the preferred embodiment, the import utility will create the generated code on a remote workstation 94 (remote relative to the IMS system) for compilation with the client application and the runtime on the remote workstation. And, in the preferred embodiment, the client application (along with the compiled generated code and the runtime) run on the remote workstation which is connec-ted by MQSeries messaging services and hardware connections to the IMS system, typically an OS/390 host computer 96, all more particularly depicted in Figure 1. However, it should be apparent to those skilled in the art that any number of different hardware configurations and system interconnection topologies could be used in accordance with the invention. Without limitation, ariy one or any combination of the components generally described in Figure 1, e.g., the impoirt utility, the client application, the runtime, the compiled generated code, etc. could operate on the same or different workstations or systems. Indeed, all components of the invention could operate on the IMS system host.
More particularly, the import utility facilitates the creation of an interface for a client application 40 written in another computer language to a COBOL IMS transaction with a COBOL IMS application program by reading the IMS transaction source file 10.
In the preferred embodiment, the IMS transaction source file, which is initially located on the file system of the IMS system host, is read from the file system of the computer environment in which the import utility operates. In the prefen-ed embodiment, the user inputs IMS transaction information to the import utility by way of corrunand line arguments passed when invoking the import utility. The user specifies the name of the COBOL IMS transaction to be invoked, the name of the IMS
transaction source file containing relevant message definitions, the name of the main class to be generated by the import utility and the name of the method representing the COBOL IMS
transaction invocation. The user is also required to specify the names of the COBOL data structures representing the input arid output messages. These messages are interpreted as arguments to the aforementioned method. It should be apparent to those skilled in the art that input of arguments could equally be provided by a graphical user interface means, provided to the import utility by a program invoking the import utility, or provided by any other conventional input means, whether manual or autoniatic.
Referring to Figure 2, the inaport utility 20 comprises three components:
scanner 22, parser 24 and code generator 26. The scanner reads the COBOL IMS transaction source file 10 and generates a stream of tok:ens that are input to the parser. The parser interprets the stream of tokens and generates data model code parts corresponding to the contents of the COBOL IMS
transaction messages. These parts are then used by the code generator to generate C++ classes 30, the program interface, representing the IMS input and output messages contained in the COBOL IMS transaction source file. Clearly the classes could be generated in computer languages other than C++, typically the language corresponding to the language of the client application. The generated data types of the input and output messages describe the format of the data stream to be sent to the IMS transaction and the format of the reply sent by the IMS
transaction back to the C++ program.
In the preferred embodiment, the import utility creates the several C++
constructs as described above, namely a transaction part, a message part and a lpage part, which are used to generate the compiled generated code stub used, in combination with the runtime, to invoke the COBOL IMS transaction through the :[BM MQSeries services.
The first construct or part - the main, user specific class, user_class, with a name defined by the user to the import utility - contains the properties and methods needed to communicate with the IMS system. These properties and methods are included in user_class by means of multiple inheritance from generated utility classes, described below, contained in the program runtime classes. These classes include IDAInterfaceBase class, IXDMQIMSConversation class and other member classes of the IBM Open Class library.
The utility classes generated by the import utility include the user classDefinition class, the user class_stub class and. the ims__user class_cstub class. The main purpose of these classes is to provide the abstract definitions properties used by the user_class. The properties provide unique identifiers to identify the class, methods which return Strings containing the signature of user methods, and an abstract implemientation of each user method.
The user_class also defines the implementation of the user defined method, user method, as specified by the user to the import utility. The invocation of this method causes interaction with the IMS transaction as understood by the IMS system including sending an input message to the IMS system and receiving an output message from the IMS system. The method expects two arguments corresponding to the input and output messages of the IMS
transaction. The messages themselves are user_message classes generated by the import utility from the COBOL
data structures representing the input and output messages specified by the user to the import utility.
The second construct or part, a message part - class user_message - provides means for composing or reading an IMS input or output message respectively. Messages exchanged with an IMS system are divided into logical pages or lpages, depicted by way of example in Figure 3 as lpage 1 and lpage 2, and the user_message class reflects this structure by defining the sequence of lpages as its data member.
Since an lpage itself can contain one or more segments and the message can contain two or more logic pages, a third construct or part - a class user lpage - is defined for each logical CA9-1998-0001-CAl 14 page and the generated code 30 conta:ins a class definition for each defined lpage. The segments, depicted by way of example as segl, seg2, and seg3 in Figure 3, contained in a lpage are itself classes, generated from the C'OBOL clata structures by the import utility. The multiple segments within a lpage are grouped ir.ito a segment sequence. The generated code defines all segments of a particular lpage as the data members of that lpage class. Further, the segments are comprised of fields, depicted by way of example as mfldl, mfld2, mfld3, mfld4 and mfld5 in Figure 3, which in turn are the basic COBOL data types. The generated code defines all fields of a particular segment as the data members of that segment class.
In all of the generated code 30, the definition of one class as a data member of, or included in, another class implies the existence of the methods to retrieve and set the value of such data member or includeci class.
In addition to the C++ code described above, the import utility also generates a description of visual and nonvisual parts in a format, in the preferred embodiment, understandable to the Visual Composition Editor included in the IBM VisualAge C++ product.
This description includes graphical representations of the user_class and the user_method as well as other generated classes and their data members. This allows the use of the generated code to visually create user applications using the Visual Composition Editor development functionality such as attribute to attribute connections. It should be apparent to those skilled in the art that formats for other visual or non-visual programming tools may be used.
After creation of the generated code by the import utility, the generated code is compiled (as the compiled generated code stub) with the runtime and client application.
Of course, in other program language environments, the generated code, the application and the runtime may be not be compiled together rather instead interlinked by other means. Once compiled together, the client application and program runtinie interact with the compiled generated code stub to allow access by the client application to a COBOL IMS transaction.
The program runtime 60 of the present invention comprises a set of C++ classes providing access from the application's system to an IMS system. Specifically, the runtime classes provide means to: translate the simple data types of the language used on the application's system to the COBOL data types used in a message to the IMS
system (IDACallHandle class); construct messages in a format understandable by the IMS system (IXDMQIMSCa1lHandlelnternal, IXDMQIMSTransaction and IXDMQIMSConversation classes); exchange the messages with the IMS system using IBM MQSeries services (IXDMQIMSRChnI and IXDMQIMSSChnI classes); read the message returned from the IMS
system (IXDMQIMSCa11Han.dlelnternal, IXDMQIMSTransaction and IXDMQIM S
Conversation classes); and translate the s;Imple COBOL data types contained in a message from the IMS
system to the data types of the language used on the application's system (IDACallHandle class).
The runtime handling of dynamic IMS system messages is described using an example of the reading of an IMS output: message but it is understood that the runtime may also be capable of composing such formatted messages to be sent to an IMS system e.g. as an IMS input message.
As described above, an IMS message can contain multiple lpages, which in turn can contain multiple segments occurring as one or more segment sequences. In any given segment sequence, one or more segrnents can be omitted. Each segment can contain multiple fields corresponding to the simple data types of the COBOL IMS transaction. Some or all data fields can be omitted. The actual structure of each message, said structure defined by the number of lpages in the message, the number of segment sequences in the lpage, and the number and size of CA9-1998-0001-CAl 16 all fields in the segment, is thus really only known at the time of generation of the messages. The ability of the IMS system to reorder lpages and their segment sequences and omit segments and fields prevents direct mappin;i, of the message to a set of generated data structures (classes/types) and thus requires a runtime to read each message and dynamically map the message to the generated data structures (classes/types). The handling of these dynamic messages by the runtime and the compiled generated code of the present invention is described below.
To accommodate all the possible messages, the runtime assumes that a message contains multiple lpages, each with multiple segment sequences, each containing multiple fields. Also, each generated class corresponding to the message, lpage, segment or field, contains the code to unmarshal the corresponding part of the IMS message. This code is combined using the C++
operator overloading mechanism to translate the whole IMS system message.
Initially, the message is copied into a buffer 100 and its length is stored.
Until or unless there is no data in the buffer, the runtime reads a sequence of lpages 110.
After making sure the buffer contains data 120 (using the notAtEndOfBuffer method of the InternalCaliHandle class), the next step is to verify that the data to be read belongs to the current lpage 130. This verification is done using the notAtEndOfBufferOrSeq method. This method uses the page bit and the lpage condition. The page bit is the fourth byte of the message segment. If its value is 0x40. the seginent is the first in the segment sequence of the lpage. The lpage condition consists of a reference value, comparator operator and the offset within the segment. The segment belongs to the lpage when the value at the offset compared, using the comparator operator, to the reference value evaluates to true. This method is used to determine whether the first segment iri the segment sequence belongs to the same lpage or is the first segment in the next lpage. If it is the first segment in the next lpage, the next lpage is processed 110. This comparison operation is necessary since a segment sequence for a lpage does not have to contain the same number of elements and can end after any segment.
If the segment belongs to the current lpage, its contents are unmarshalled.
First, the runtime verifies that the segment is ncit a null segment, that is, a segment containing no data 140.
Method notNullSegment checks whether the segment length specified in its length field is equal to 5, and if it is, whether the fifth byte of the segment is a null character.
The null character is transaction dependent and is defined by the user to the runtime 60. If the segment is empty, no data is read and the buffer pointer is advanced by 5 - the length of the empty segment 150. When the segment is not empty, the runtime strips the first four bytes of the segment containing the length and control information 160. This is done by invoking the method stripLL.
The next step is to unmarshal all the fields of the segment 170. Since fields can be omitted, the runtime checks for a null character before attempting to unmarshal a field 180. If the null character is present, the runtime advances the buffer pointer by the length of the field 190. If the field is truncated, that is the null character is not the first one in the field, the runtime only reads into the buffer up to the null cl.iaracter and advances the buffer pointer appropriately 200.
The fields and segments differ in that a truncated segment is physically shorter, whereas the field always occupies the same space.
After unmarshaling all the fields in the segment, the runtime verifies that it should continue to unmarshal the current lpage. Besides checking whether there is any more data in the buffer 120 (if there is no more data the unmarshalling is terminated), it verifies that the lpage condition is met and therefore whether the next segment belongs to the same lpage 130. If the condition is not met the runtime starts unmarshalling the next lpage 110.
Otherwise, the runtime verifies that the next segment contains data 140. If so, the segment and its fields are processed as described above. If not, the buffer pointer is advanced 150 and unmarshalling continues. In this manner, processing continues until all the data from the message has been retrieved and there is no more data in the buffer 120.
The format of the message sent to the IMS system depends on the state of the conversation between the application and the program on the IMS system. If there is a conversation between the application and the program, the message must not contain the name of the IMS transaction to be invoked, otherwise included in the first segment of the message. The runtime keeps track of the ongoing; conversations and verifies that only valid user data is included in the messages sent to the I1vIS system.
In addition, after every step of the conversation, the runtime writes the conversation identification to a persistent store. This step maintains a state to provide failure recovery. It is necessary because of an IMS, structure that does not terminate conversations that are unfinished and leaves them in an inconsistent state. The utility provided as the part of the program runtime allows automatic termination of all suspended conversations once the user program is restarted.
Referring to Figure 5, the source code of a sample COBOL IMS transaction is provided.
Its parts defining input and output messages format are shown between begin and end comments.
For the transaction to run correctly the data it receives must match exactly these definitions and therefore they determine the format of the generated C++ code.
Figure 6 presents a set of generated files containing C++ classes used to compose an input message sent to a COBOL IM S transaction and read an output message returned by the COBOL IMS transaction. It :includes complete source of the following files:
CA9-1998-0001-CAl 19 = myclass.hpp - contains the definition of the user class with the appropriate runtime initialization and a virtual definition of a method used to invoke the COBOL
IMS transaction (add).
= myclass.imc - defines a ~cstub class providing definition of the method used to invoke the COBOL IMS transaction (add) = myclass.hpd - defines stub and Ciefinition abstract classes, superclasses of the above cstub class = myclass.imd - defines classes representing: the input and output messages -myclass_add_O, myclass_add_I; lpages of'these messages - myclass_add_Lpagel, myclass_add_Lpage2; and fields of these lpages - m)/class_acld_Lpagel_args, myclass_add_Lpagel_result.
= myclass.vbe - contains adescription of visual parts of the generated code that can be used in the Visual Composition Editor (VCE) of IBM's VisualAge C++ development tool.
= myclass.cpp - defines notificatior.i identifiers used by classes to notify about the change of their state when the generated code is used in the VCE.
To use the generated code directly, without using the VCE, the user has to include the header file myclass.hpp, all other files and definitions are included automatically.
The detailed descriptions may have been presented in terms of program procedures executed on a computer ~or network of computers. These procedural descriptions and representations are the mearis used by those skilled in the art to most effectively convey the substance of their work to others skilled in the art. They may be implemented in hardware or software, or a combination of the two.
A procedure is here, and generally, conceived to be a self-consistent sequence of steps leading to a desired result. These steps are those requiring physical manipulations of physical quantities. Usually, though not necessarily, these quantities take the form of electrical or magnetic signals capable of being stored, transferred, combined, compared, and otherwise CA9-1998-0001-CAl 20 manipulated. It proves convenient at times, principally for reasons of common usage, to refer to these signals as bits, values, elements, symbols, characters, terms, numbers, objects, attributes or the like. It should be noted, however, that all of these and similar terms are to be associated with the appropriate physical quantities ancl are merely convenient labels applied to these quantities.
Further, the manipulations performed are often referred to in terms, such as adding or comparing, which are comr.aonly associated with mental operations performed by a human operator. No such capability of a human operator is necessary, or desirable in most cases, in any of the operations described herein which form part of the present invention;
the operations are machine operations. Useful machines for performing the operations of the present invention include general purpose digital computers or similar devices.
Each step of the method may lbe executed on any general computer, such as a mainframe computer, personal computer or the l ike and pursuant to one or more, or a part of one or more, program modules or objects generated from any programming language, such as C++, Java, Fortran or the like. And still further, each step, or a file or object or the like implementing each step, may be executed by special purpose hardware or a circuit module designed for that purpose.
In the case of diagrams depicted herein, they are provided by way of example.
There may be variations to these diagrams or the steps (or operations) described herein without departing from the spirit of the invention. For instance, in certain cases, the steps may be performed in differing order, or steps may be added, deleted or modified. All of these variations are considered to comprise part of the present invention as recited in the appended claims.
While the description herein rnay refer to interactions with the user interface by way of, for example, computer mouse operation, it will be understood that within the present invention the user is provided with the ability to interact with these graphical representations by any known computer interface mechanisms, including without limitation pointing devices such as computer mouses or trackballs, joysticks, touch screen or light pen implementations or by voice recognition interaction with the computer system.
While the preferred embodiment of this invention has been described in relation to the C++ language, this inventior.L need not be solely implemented using the C++
language. It will be apparent to those skilled in the art that the invention may equally be implemented in other computer languages, such as object oriented languages like Java and Smalltalk.
The invention is preferably implemented in a high level procedural or object-oriented programming language to communicate with a computer. However, the invention can be implemented in assembly or machine language, if desired. In any case, the language may be a compiled or interpreted language.
While aspects of the invention relate to certain computer language and other technological specifications (e.g. the Java Language Specification with respect to the Java computer language), it should be apparent that classes, objects, components and other such software and technological items referenced herein need not fully conform to the specification(s) defined therefor but rather may meet only some of the specification requirements. Moreover, the classes, objects, components and other such software and technological items referenced herein may be defined according to equivalent specification(s) other than as indicated herein that provides equivalent or similar functionality, constraints, etc. Accordingly, features, functionality, constraints, etc. may be used other than as defined by the computer language and other technological specification.
The invention may be implemented as an article of manufacture comprising a computer usable medium having computer reaclable program code means therein for executing the method CA9-1998-0001-CAl 22 steps of the invention, a program storage device readable by a machine, tangibly embodying a program of instructions executable by a machine to perform the method steps of the invention, or a computer program product. Such an article of manufacture, program storage device or computer program product may include, but is not limited to, CD-ROMs, diskettes, tapes, hard drives, computer RAM or ROM and/or the electronic, magnetic, optical, biological or other similar embodiment of the program. Indeed, the article of manufacture, program storage device or computer program product may include any solid or fluid transmission medium, magnetic or optical, or the like, for storing or transmitting signals readable by a machine for controlling the operation of a general or special purpose programmable computer according to the method of the invention and/or to structure its components in accordance with a system of the invention.
The invention may also be implemented in a system. A system may comprise a computer that includes a processor and a memory device and optionally, a storage device, an output device such as a video display and/or an input device such as a keyboard or computer mouse. Moreover, a system may comprise an interconnected network of computers. Computers may equally be in stand-alone form (such as the traditional desktop personal computer) or integrated into another apparatus (such a cellular telephone). The system may be specially constructed for the required purposes to perform, for example, the method steps of the invention or it may comprise one or more general purpose computers as selectively activated or reconfigured by a computer program in accordance with the teachings herein stored in the computer(s). The procedures presented herein are not inherently related to ajparticular computer system or other apparatus. The required structure for a variety of these systems will appear from the description given.
While this invention has been described in relation to preferred embodiments, it will be understood by those skilled in the ar1: that changes in the details of construction, arrangement of CA9-1998-0001-CA] 23 parts, compositions, processes, structures and materials selection may be made without departing from the spirit and scope of this invention. Many modifications and variations are possible in light of the above teaching. Thus, it should be understood that the above described embodiments have been provided by way of example rather than as a limitation and that the specification and drawing(s) are, accordingly, to be regarded in an illustrative rather than a restrictive sense.
CA9-1998-0001-CAl 24
Claims (26)
1. A method for interfacing an information management system (IMS) program on an IMS
system to a program in another program environment, said IMS program receiving and sending input and output messages having variant content, the method comprising the steps of:
scanning an IMS transaction with the IMS program on the IMS system; and using results of said scanning to generate a program interface, the program interface providing means for invoking the IMS transaction, dynamically composing or reading said input or output messages, and dynamically converting data between the IMS transaction and the program in another program environment;
wherein the interface comprises a transaction part which provides for invoking the IMS transaction;
a message part which provides for composing or reading an IMS message; and a logical page (lpage) part which provides for dynamic composing or reading an IMS message.
system to a program in another program environment, said IMS program receiving and sending input and output messages having variant content, the method comprising the steps of:
scanning an IMS transaction with the IMS program on the IMS system; and using results of said scanning to generate a program interface, the program interface providing means for invoking the IMS transaction, dynamically composing or reading said input or output messages, and dynamically converting data between the IMS transaction and the program in another program environment;
wherein the interface comprises a transaction part which provides for invoking the IMS transaction;
a message part which provides for composing or reading an IMS message; and a logical page (lpage) part which provides for dynamic composing or reading an IMS message.
2. The method of claim 1, further comprising the step of providing a runtime, the runtime comprising: means for translating data types of the program in another program environment to data types used in a message to the IMS system;
means for composing the message to the IMS system;
means for translating data types used in a message from the IMS system to data types of the program in another program environment; and means for reading the message from the IMS system.
means for composing the message to the IMS system;
means for translating data types used in a message from the IMS system to data types of the program in another program environment; and means for reading the message from the IMS system.
3. The method of claim 2, wherein the runtime further comprises means for accessing the IMS transaction via the MQSeries messaging interface.
4. The method of claim 2, further comprising the step of compiling the runtime into the program in another program environment.
5. The method of claim 1, further comprising the step of compiling the program interface into the program in another program environment.
6. The method of claim 1, further comprising the step of providing means for converting code pages between the another program environment and the IMS system.
7. A computer program product having computer readable memory tangibly embodying computer readable code for interfacing an information management system (IMS) program on an IMS system to a program in another program environment, said IMS program receiving and sending input and output messages having variant content, the computer readable code comprising:
instruction means for scanning an IMS transaction with the IMS program on the IMS
system; and instruction means for using results of said scanning to generate a program interface, the program interface providing means for invoking the IMS transaction and, dynamically composing or reading said input or output messages, dynamically converting data between the IMS transaction and the program in another program environment;
wherein the interface comprises a transaction part which provides for invoking the IMS transaction;
a message part which provides for composing or reading an IMS message; and a logical page (lpage) part which provides for dynamic composing or reading an IMS message.
instruction means for scanning an IMS transaction with the IMS program on the IMS
system; and instruction means for using results of said scanning to generate a program interface, the program interface providing means for invoking the IMS transaction and, dynamically composing or reading said input or output messages, dynamically converting data between the IMS transaction and the program in another program environment;
wherein the interface comprises a transaction part which provides for invoking the IMS transaction;
a message part which provides for composing or reading an IMS message; and a logical page (lpage) part which provides for dynamic composing or reading an IMS message.
8. The computer program product of claim 7, further comprising instructions means for providing a runtime, the runtime comprising:
means for translating data types of the program in another program environment to data types used in a message to the IMS system;
means for composing the message to the IMS system; means for translating data types used in a message from the IMS system to data types of the program in another program environment; and means for reading the message from the IMS system.
means for translating data types of the program in another program environment to data types used in a message to the IMS system;
means for composing the message to the IMS system; means for translating data types used in a message from the IMS system to data types of the program in another program environment; and means for reading the message from the IMS system.
9. The computer program product of claim 8, wherein the runtime further comprises means for accessing the IMS transaction via the MQSeries messaging interface.
10. The computer program product of claim 8, further comprising instruction means for compiling the runtime into the program in another program environment.
11. The computer program product of claim 7, further comprising instruction means for compiling the program interface into the program in another program environment.
12. The computer program product of claim 7, further comprising instruction means for converting code pages between the another program environment and the IMS
system.
system.
13. A computer program product having computer readable memory tangibly embodying computer readable code for interfacing an information management system (IMS) program on an IMS system to a program in another program environment, said IMS program receiving and sending input and output messages having variant content, the computer readable code comprising:
means for scanning an IMS transaction with the IMS program on the IMS system to dynamically compose or read said input or output messages and to produce dynamically a data description of said IMS transaction; and means for using said data description to generate code for invoking said IMS
transaction;
wherein the means for scanning includes a transaction part which provides for invoking the IMS transaction:
a message part which provides for composing or reading an IMS message; and a logical page (lpage) part of which provides dynamic composing or reading an IMS message.
means for scanning an IMS transaction with the IMS program on the IMS system to dynamically compose or read said input or output messages and to produce dynamically a data description of said IMS transaction; and means for using said data description to generate code for invoking said IMS
transaction;
wherein the means for scanning includes a transaction part which provides for invoking the IMS transaction:
a message part which provides for composing or reading an IMS message; and a logical page (lpage) part of which provides dynamic composing or reading an IMS message.
14. The computer program product of claim 13, further comprising:
instruction means for using said data description to generate code to process message elements of said IMS transaction for use with the program in another language environment.
instruction means for using said data description to generate code to process message elements of said IMS transaction for use with the program in another language environment.
15. A computer program product having computer readable memory tangibly embodying computer readable code for interfacing an information management system (IMS) program on an IMS system to a program in another program environment, said IMS program receiving and sending input and output messages having variant content, the computer readable code comprising:
instruction means for using information obtained from the IMS program on the IMS
system to invoke an IMS transaction with the program on the IMS system; and instruction means for composing or reading said input or output messages and for dynamically converting data between the IMS transaction and the program in another program environment;
wherein the instruction means for composing or reading includes a transaction part which provides for invoking the IMS transaction;
a message part which provides for composing or reading an IMS message; and a logical page (lpage) part which provides for dynamic composing or reading an IMS message.
instruction means for using information obtained from the IMS program on the IMS
system to invoke an IMS transaction with the program on the IMS system; and instruction means for composing or reading said input or output messages and for dynamically converting data between the IMS transaction and the program in another program environment;
wherein the instruction means for composing or reading includes a transaction part which provides for invoking the IMS transaction;
a message part which provides for composing or reading an IMS message; and a logical page (lpage) part which provides for dynamic composing or reading an IMS message.
16. The computer program product of claim 15, wherein the instruction means for converting further comprises:
instruction means for translating data types of the program in another program environment to data types used in a message to the IMS system;
instruction means for composing the message to the IMS system;
instruction means for translating data types used in a message from the IMS
system to data types of the program in another program environment; and instruction means for reading the message from the IMS system.
instruction means for translating data types of the program in another program environment to data types used in a message to the IMS system;
instruction means for composing the message to the IMS system;
instruction means for translating data types used in a message from the IMS
system to data types of the program in another program environment; and instruction means for reading the message from the IMS system.
17. The computer program product of claim 15, wherein the instruction means for converting further comprises instruction means for accessing the IMS transaction via the MQSeries messaging interface.
18. The computer program product of claim 15, further comprising instruction means for converting code pages between the another program environment and the IMS
system.
system.
19. An article of manufacture readable by machine, tangibly embodying a program of instructions executable by the machine to perform method steps for interfacing an information management system (IMS) program on an IMS system to a program in another program environment, said IMS program receiving and sending input and output messages having variant content, said method steps comprising:
scanning an IMS transaction with the IMS program on the IMS system; and using results of said scanning to generate a program interface, the program interface providing means for invoking the IMS transaction dynamically composing or reading said input or output messages, and dynamically converting data between the IMS transaction and the program in another program environment;
wherein the interface comprises a transaction part which provides for invoking the IMS transaction;
a message part which provides for composing or reading an IMS message; and a logical page (lpage) part which provides for dynamic composing or reading an IMS message.
scanning an IMS transaction with the IMS program on the IMS system; and using results of said scanning to generate a program interface, the program interface providing means for invoking the IMS transaction dynamically composing or reading said input or output messages, and dynamically converting data between the IMS transaction and the program in another program environment;
wherein the interface comprises a transaction part which provides for invoking the IMS transaction;
a message part which provides for composing or reading an IMS message; and a logical page (lpage) part which provides for dynamic composing or reading an IMS message.
20. A system for interfacing an information management system (IMS) program on an IMS
system to a program in another program environment, said IMS program receiving and sending input and output messages having variant content, the method comprising:
means for scanning an IMS transaction with the IMS program on the IMS system;
and means for using results of said scanning to generate a program interface, the program interface providing means for invoking the IMS transaction, dynamically composing or reading said input or output messages, and dynamically converting data between the IMS transaction and the program in another program environment;
wherein the interface comprises a transaction part which provides for invoking the IMS transaction;
a message part which provides for composing or reading an IMS message; and a logical page (lpage) part which provides for dynamic composing or reading an IMS message.
system to a program in another program environment, said IMS program receiving and sending input and output messages having variant content, the method comprising:
means for scanning an IMS transaction with the IMS program on the IMS system;
and means for using results of said scanning to generate a program interface, the program interface providing means for invoking the IMS transaction, dynamically composing or reading said input or output messages, and dynamically converting data between the IMS transaction and the program in another program environment;
wherein the interface comprises a transaction part which provides for invoking the IMS transaction;
a message part which provides for composing or reading an IMS message; and a logical page (lpage) part which provides for dynamic composing or reading an IMS message.
21. The system of claim 20, further comprising means for providing a runtime, the runtime comprising:
means for translating data types of the program in another program environment to data types used in a message to the IMS system;
means for composing the message to the IMS system;
means for translating data types used in a message from the IMS system to data types of the program in another program environment; and means for reading the message from the IMS system.
means for translating data types of the program in another program environment to data types used in a message to the IMS system;
means for composing the message to the IMS system;
means for translating data types used in a message from the IMS system to data types of the program in another program environment; and means for reading the message from the IMS system.
22. A system for interfacing an information management system (IMS) program on an IMS
system to a program in another program environment, said IMS program receiving and sending input and output messages having variant content, the method comprising:
means for scanning an IMS transaction with the IMS program on the IMS system to dynamically compose or read said input or output messages and to produce dynamically a data description of said IMS transaction; and means for using said data description to generate code for invoking said IMS
transaction;
wherein the means for scanning includes a transaction part which provides for invoking the IMS transaction;
a message part which provides for composing or reading an IMS message; and a logical page (1page) part which provides for dynamic composing or reading an IMS message.
system to a program in another program environment, said IMS program receiving and sending input and output messages having variant content, the method comprising:
means for scanning an IMS transaction with the IMS program on the IMS system to dynamically compose or read said input or output messages and to produce dynamically a data description of said IMS transaction; and means for using said data description to generate code for invoking said IMS
transaction;
wherein the means for scanning includes a transaction part which provides for invoking the IMS transaction;
a message part which provides for composing or reading an IMS message; and a logical page (1page) part which provides for dynamic composing or reading an IMS message.
23. The system of claim 22, further comprising:
means for using said data description to generate code to process message elements of said IMS transaction for use with the program in another language environment.
means for using said data description to generate code to process message elements of said IMS transaction for use with the program in another language environment.
24. A system for interfacing an information management system (IMS) program on an IMS
system to a program in another program environment, said IMS program receiving and sending input and output messages having variant content, the method comprising:
means for using information obtained from the IMS program on the IMS system to invoke an IMS transaction with the IMS program on the IMS system; and means for composing or reading said input or output messages and for converting dynamically converting data between the IMS transaction and the program in another program environment;
wherein the means for composing or reading includes a transaction part which provides for invoking the IMS transaction;
a message part which provides for composing or reading an IMS message;
and a logical page (1page) part which provides for dynamic composing or reading an IMS message.
system to a program in another program environment, said IMS program receiving and sending input and output messages having variant content, the method comprising:
means for using information obtained from the IMS program on the IMS system to invoke an IMS transaction with the IMS program on the IMS system; and means for composing or reading said input or output messages and for converting dynamically converting data between the IMS transaction and the program in another program environment;
wherein the means for composing or reading includes a transaction part which provides for invoking the IMS transaction;
a message part which provides for composing or reading an IMS message;
and a logical page (1page) part which provides for dynamic composing or reading an IMS message.
25. The system of claim 24, wherein the means for converting further comprises:
means for slating data types of the program in another program environment to data types used in a message to the IMS system;
means for composing the message to the IMS system;
means for translating data types used in a message from the IMS system to data types of the program in another program environment; and means for interpreting the message from the IMS system.
means for slating data types of the program in another program environment to data types used in a message to the IMS system;
means for composing the message to the IMS system;
means for translating data types used in a message from the IMS system to data types of the program in another program environment; and means for interpreting the message from the IMS system.
26. A method for interfacing an information management system (IMS) program on an IMS
system to a program in another program environment, comprising:
scanning an IMS transaction with the IMS program, the IMS program being configured to receive and send input and output messages having variant content;
generating a program interface using results of the scanning;
invoking the IMS transaction;
dynamically composing or reading the input and output messages; and dynamically converting data between the IMS transaction and the program in another program environment;
wherein, the program interface comprises a transaction part configured to perform the invoking, a message part configured to perform the dynamically composing or reading the input and output messages, and a logical page (1page) part configured to perform the dynamically converting data.
system to a program in another program environment, comprising:
scanning an IMS transaction with the IMS program, the IMS program being configured to receive and send input and output messages having variant content;
generating a program interface using results of the scanning;
invoking the IMS transaction;
dynamically composing or reading the input and output messages; and dynamically converting data between the IMS transaction and the program in another program environment;
wherein, the program interface comprises a transaction part configured to perform the invoking, a message part configured to perform the dynamically composing or reading the input and output messages, and a logical page (1page) part configured to perform the dynamically converting data.
Priority Applications (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CA002290167A CA2290167C (en) | 1999-11-22 | 1999-11-22 | Automated interface generation for computer programs in different environments |
| US09/574,409 US6983468B1 (en) | 1999-11-22 | 2000-05-19 | Automated interface generation for computer programs in different environments |
| DE10054001A DE10054001A1 (en) | 1999-11-22 | 2000-11-01 | Automated interface generation method for computer programs, involves generating program interface for converting data between IMS-transfer and program in different program environment after scanning IMS transaction |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CA002290167A CA2290167C (en) | 1999-11-22 | 1999-11-22 | Automated interface generation for computer programs in different environments |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CA2290167A1 CA2290167A1 (en) | 2001-05-22 |
| CA2290167C true CA2290167C (en) | 2008-09-02 |
Family
ID=4164671
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CA002290167A Expired - Fee Related CA2290167C (en) | 1999-11-22 | 1999-11-22 | Automated interface generation for computer programs in different environments |
Country Status (3)
| Country | Link |
|---|---|
| US (1) | US6983468B1 (en) |
| CA (1) | CA2290167C (en) |
| DE (1) | DE10054001A1 (en) |
Families Citing this family (11)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6889191B2 (en) * | 2001-12-03 | 2005-05-03 | Scientific-Atlanta, Inc. | Systems and methods for TV navigation with compressed voice-activated commands |
| US7430732B2 (en) * | 2003-10-23 | 2008-09-30 | Microsoft Corporation | Design of application programming interfaces (APIs) |
| US7694315B2 (en) * | 2004-02-13 | 2010-04-06 | Microsoft Corporation | Schema-based machine generated programming models |
| US7526563B2 (en) * | 2004-02-27 | 2009-04-28 | Nokia Corporation | Interworking gateway and method |
| US7343556B2 (en) * | 2004-12-30 | 2008-03-11 | Sap Ag | Technique for processing and generating messages in multiple languages |
| US7793154B2 (en) | 2006-11-30 | 2010-09-07 | International Business Machines Corporation | Method and implementation for automating processes using data driven pre-recorded transactions |
| FR2944366B1 (en) * | 2009-04-09 | 2012-02-03 | Bull Sas | METHOD AND DEVICE FOR PERFORMING HETEROGENEOUS TRANSACTIONAL COMPONENTS |
| US8375353B2 (en) * | 2009-12-30 | 2013-02-12 | International Business Machines Corporation | Enabling the use of process flow applications within an information management system (IMS) |
| US8533667B2 (en) * | 2009-12-30 | 2013-09-10 | International Business Machines Corporation | Call wizard for information management system (IMS) applications |
| 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 |
| CN113031963B (en) * | 2021-03-24 | 2023-09-12 | 北京字节跳动网络技术有限公司 | Method, device, equipment and storage medium for realizing conditional compiling |
Family Cites Families (12)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5036484A (en) * | 1988-11-23 | 1991-07-30 | International Business Machines Corporation | Personal computer/host emulation system for handling host data with personal computer application programs at personal computers |
| US5329619A (en) * | 1992-10-30 | 1994-07-12 | Software Ag | Cooperative processing interface and communication broker for heterogeneous computing environments |
| GB9314460D0 (en) * | 1993-07-13 | 1993-08-25 | Int Computers Ltd | Computer systems integration |
| US5623657A (en) | 1993-12-30 | 1997-04-22 | International Business Machines Corporation | System for processing application programs including a language independent context management technique |
| US5627979A (en) | 1994-07-18 | 1997-05-06 | International Business Machines Corporation | System and method for providing a graphical user interface for mapping and accessing objects in data stores |
| US5619685A (en) | 1994-11-04 | 1997-04-08 | Ball Corporation | Run-time dynamically adaptive computer process for facilitating communication between computer programs |
| US5673633A (en) | 1995-05-31 | 1997-10-07 | Pfister; Joel W. | Table leg system |
| US5634053A (en) | 1995-08-29 | 1997-05-27 | Hughes Aircraft Company | Federated information management (FIM) system and method for providing data site filtering and translation for heterogeneous databases |
| US6263497B1 (en) * | 1997-07-31 | 2001-07-17 | Matsushita Electric Industrial Co., Ltd. | Remote maintenance method and remote maintenance apparatus |
| US6382846B1 (en) * | 1998-01-09 | 2002-05-07 | Industial Technology Research Institute | Intermediate instruction execution processor which resolves symbolic references without modifying intermediate instruction code |
| US6438744B2 (en) * | 1998-07-15 | 2002-08-20 | Microsoft Corporation | Dynamic mapping of component interfaces |
| US6330711B1 (en) * | 1998-07-30 | 2001-12-11 | International Business Machines Corporation | Method and apparatus for dynamic application and maintenance of programs |
-
1999
- 1999-11-22 CA CA002290167A patent/CA2290167C/en not_active Expired - Fee Related
-
2000
- 2000-05-19 US US09/574,409 patent/US6983468B1/en not_active Expired - Lifetime
- 2000-11-01 DE DE10054001A patent/DE10054001A1/en not_active Ceased
Also Published As
| Publication number | Publication date |
|---|---|
| CA2290167A1 (en) | 2001-05-22 |
| DE10054001A1 (en) | 2001-05-31 |
| US6983468B1 (en) | 2006-01-03 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US6063128A (en) | Object-oriented computerized modeling system | |
| US5815415A (en) | Computer system for portable persistent modeling | |
| US6948174B2 (en) | IMS MFS (message format service) metamodel | |
| US7370275B2 (en) | System and method for providing context to an input method by tagging existing applications | |
| JP3842213B2 (en) | Common application metamodel including C / C ++ metamodel | |
| US6349404B1 (en) | Object-oriented repository, a system and method for reusing existing host-based application assets for the development of business-centric applications | |
| EP1174791B1 (en) | Unified data type system and method | |
| US8332828B2 (en) | System for translating diverse programming languages | |
| US6226692B1 (en) | Method and system for constructing software components and systems as assemblies of independent parts | |
| US6854123B1 (en) | Method, system, and program for mapping standard application program interfaces (APIs) to user interface APIs | |
| EP3350696B1 (en) | Overriding a migrated method of an updated type | |
| US8656372B2 (en) | System for translating diverse programming languages | |
| TWI556170B (en) | Projecting native application programming interfaces of an operating system into other programming languages (2) | |
| Reiss | The Field programming environment: A friendly integrated environment for learning and development | |
| US20140157243A1 (en) | System for Translating Diverse Programming Languages | |
| KR20080017351A (en) | Data centric workflows | |
| CA2290167C (en) | Automated interface generation for computer programs in different environments | |
| US8359568B2 (en) | Method and system for automatically adding generic change log to legacy application | |
| US7752596B2 (en) | Connecting alternative development environment to interpretive runtime engine | |
| US20050102649A1 (en) | Strategy for referencing code resources | |
| Specification | Object management group | |
| US9383972B2 (en) | Methods and arrangements for processing and presentation of information | |
| Jeffery et al. | MCORBA: a CORBA binding for Mercury | |
| Guan et al. | Application of API Functions in the Visualization Platform | |
| Herman | Review and Approval |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| EEER | Examination request | ||
| MKLA | Lapsed | ||
| MKLA | Lapsed |
Effective date: 20101122 |