AU718928B2 - Method for coupling transaction systems - Google Patents

Description

h -6 -1- PATRON DATABASE ARCHITECTURE Background of the Invention Technical Field This invention relates to the field of data communication and, in particular, to systems and methods providing flexible communications between proprietary computer systems and resources located on open network systems.

Background Art The power and flexibility of network based computer systems are increasingly apparent, particularly to companies and other institutions that are widely distributed geographically. In particular, networks based on open systems architectures like UNIX and Windows allow system integrators to select from among many different vendors the servers, database managers, workstations and various other network components best suited to their needs. In addition, the de facto standard communication protocols, TCP/IP, provides fast, reliable data transmission among the nodes of open system networks.

Many companies that could benefit from open system-based networks, have already invested substantial capital in mainframe computer systems and in the development of application software to run on their computer systems. These "legacy" systems are often based on proprietary main-frame architectures designed specifically for on-line transaction processing (OLTP) with a central database. OLTP applications 20 include, for example, airline reservation systems, electronic banking/ATM systems, and various other systems that implement and track transactions in various business environments. However, even the most powerful main-frame systems lack the transaction processing capability and flexibility of open system networks and are not S" adequate for today's enterprise-wide computer systems. Many companies are looking for efficient ways to leverage the valuable information and applications from their legacy systems into distributed systems better suited to their current needs.

One barrier to this integration is that the software libraries of legacy systems may include applications that do not readily or efficiently communicate with resources located on open network system. For example, many legacy software routines are implemented in high level, report program generator (RPG) languages written for older Sprogramming environments. These are relatively slow by current OLTP systems 21609-00.DOC -2standards and are not supported by the more advanced communication middleware.

Open system transaction management systems, like AT&T's TOP END, can communicate with proprietary transactions managers, such as IBM's Customer Information Control System (CICS). However, this communication is only possible if CICS is implemented in one of the newer IBM SAA-compatible environments, such as MVD, ESA and the like. Unfortunately, many legacy system software libraries were developed before these environments existed, and converting legacy system libraries to these newer operating environments is expensive.

Available solutions for interfacing legacy systems with open system networks often entail hard coding data translation software into both the RPG applications on the proprietary system and service applications on the open system. Consequently, these programs must all be re-coded whenever there is a change to the database schema such as the addition of new attributes (columns) or the modification of existing attributes. In Saddition, the conversion code slows down response time of these applications and limits the utility of the legacy systems for real-time, on-line processing. These problems also apply to the exchange of information between messaging systems and transaction o management systems in which messages are built/parsed using rules written in a data dictionary, such as disclosed in D1.

There is thus a need for a fast, flexible interface for coupling transactions between 20 RPG applications on proprietary systems and resources, such as database servers, on open system platforms.

Summary of the Invention According to one aspect of the present invention there is provided a messaging system for coupling transactions between a report program generator (RPG) application implemented on a proprietary computer system and a transaction management system implemented on an open computer system, the messaging system comprising: a messaging module implemented on the proprietary computer system and coupled to the RPG application and the transaction management system for initializing and terminating a communication link with the transaction management system and for transmitting service requests and responses between the transaction management system Aand the RPG application, each request and response having at least one segment; 21609-00.DOC -3a data dictionary module comprising a plurality of segment definitions for specifying attributes of segments of requests and responses transmitted to and from the transaction management system; a set of defined data structures stored in a memory accessible to the messaging module and the RPG application, for receiving and storing data from both the RPG application and the messaging module, each data structure associated with a segment definition of the data dictionary module; and a message build/parse module coupled to the data dictionary module and the messaging module, the message build/parse module including functions for reading data and control information stored in the data structures by the RPG application, and assembling the read information into a service request in accordance with segment definitions associated with the read data structures, the assembled request to be transmitted to the transaction management system by the messaging module, and for parsing a service response received from the transaction management system in accordance with the segment definitions into data, and storing the parsed data into the S"data structures associated with the segment definitions used to parse the service response, the stored data read from the data structures by the RPG application.

S•. According to a second aspect of the present invention there is provided a method for coupling transactions between an RPG application implemented on a proprietary 20 computer system and a transaction management system implemented on an open computer system, the method comprising the steps of: storing a data dictionary module defining segment definitions for segments of service request messages, and each segment definition associated with a data structure in a a memory accessible to the RPG application; establishing a communication link between the RPG application and the transaction management system; detecting a service request from the RPG application; determining from the data dictionary module at least one service segment definition associated with the service request; 21609-00.DOC 3areading data and control information stored by the RPG application from a memory shared with the RPG application and associated with the determined service segment definition; generating a service request message packet using the read data and control information according to the service segment definition; and transmitting the service request message packet to the transaction management system on the communication link.

According to a third aspect of the present invention there is provided a method for coupling transactions between an RPG application implemented on a proprietary computer system and a transaction management system implemented on an open computer system, the method comprising the steps of: storing a plurality of segment definitions in a data dictionary module, at least one segment definition associated with at least one service request message and further associated with data structures in a memory accessible to the RPG application to read and write data therefrom to specify a service request to the transaction management :system; ::retrieving a specified service request from a data structure; Sodetermining segment definitions of the specified service request from the data dictionary module; 20 reading control and data information in the data structures associated with the determined segment definitions, the control and data information stored in the data structures by the RPG application; generating a request transaction by formatting the read data into a plurality of segments in accordance with the determined segment definitions; and transmitting the request transaction to the transaction manager.

According to a fourth aspect of the present invention there is provided a messaging system for coupling transactions between an RPG application executing on a proprietary computer system and a transaction management system executing on an open computer system, the RPG application storing a plurality of data structures for writing data to be transmitted to the transaction management system, and for reading data received from S the transaction management system, the messaging system comprising: 21609-o00.DOC 3b a messaging module for execution on the proprietary computer system and providing a set of functions invokable by the RPG application and the transaction management system to transmit requests from the RPG application to the transaction management system, and to transmit responses from the transaction management system to the RPG application, each request and response having at least one segment, each segment having defined attributes; a set of defined data structures stored in a memory accessible to both the messaging module and the RPG application, for receiving and storing data and control information from both the RPG application and the messaging module, each data structure associated with a segment; and a message parse/build module having a set of functions invokable by the messaging module, the functions including: a message build function for reading data and control information stored in selected ones of the data structures by the RPG application, and assembling the read information into a request in accordance with the attributes of the segments associated with the read data structures, the assembled request to be transmitted to the transaction management system by the messaging module; and a message parse function for parsing a response received from the transaction management system into data and control information according to the attributes of the 20 segments of the responses, and storing the parsed data and control information into the data structures associated with segments used to parse the response, the stored data and control information read from the data structures by the RPG application.

According to another aspect of the present invention there is provided a method for coupling transactions between an RPG application implemented on a proprietary computer system and a transaction management system implemented on an open computer system, the method comprising the steps of: storing a plurality of segment definitions, each segment definition corresponding to a segment of at least one message and further associated with a data structure stored in a memory accessible to the RPG application for receiving data from the transaction g A management system and being read by the RPG application; Sdetecting a response message from the transaction management system; 21609-00.DOC 3c parsing the response message into data portions using the segment definitions correspondingto segments of the response message; and storing the parsed data portions into the data structures associated with the segment definitions corresponding to the segments of the response message, the parse data accessible to the RPG application by reading the data structures.

Preferably, the present invention is a flexible messaging system for coupling data between an RPG application program on a proprietary platform and a transaction management system on an open system platform. The messaging system handles the message building/parsing, sending/receiving, and exception processing functions for the RPG application, providing RPG programmers with substantially transparent access to resources served by the transaction management system. In particular, the messaging system of the present invention accommodates RPG applications developed for IBM's AS/400 systems, which operate in IBM's System Network Architecture (SNA LU6.2).

The resource, which is typically a database, is implemented on an open system platform, 15 such as UNIX or Windows. The transaction management system is preferably implemented on a gateway server in the SNA network, to route transactions between the RPG application and the open system resource. In the preferred embodiment of the °invention, the open system platform employs TCP/IP network protocols to keep LU6.2 traffic off of the open system network.

20 Preferably, a messaging system in accordance with the present invention comprises a messaging module (MSG module) that serves as an application program interface for a message building and parsing module (Build/Parse module), a data dictionary associated with the Build/Parse module, and a set of defined data structures S* for exchanging data and control information between the RPG application and the MSG module. The MSG module uses the network services on the gateway to initialize conversations with the transaction management system, which establishes a dialogue with the targeted resource on the open system platform. Thereafter, the RPG application can access the resource through the messaging system, using message packets constructed from RPG-provided data and control information. The message packets are assembled by the Build/Parse module in accordance with the associated data dictionary, and transmitted by the MSG module to the transaction monitor with the appropriate 21609-00.DOC -3dcontrol information. A Build/Parse module associated with a service application at the open system resource provides complementary message building and parsing services for the resource.

Preferably also, the flexibility of the messaging system is further enhanced by a human-readable, i.e. ASCII, definition file (ADF) which provides a common definition for the data to be exchanged by the RPG application and the open system resource. The data dictionary for the messaging system and the defined data structures, through which the RPG application and the messaging system exchange data, are generated from the ADF. The defined data structures and data dictionaries are updated only when the ADF is modified, at which times, the updated objects are generated using utilities provided by the present invention.

Unless the context clearly requires otherwise, throughout the description and the claims, the words 'comprise', 'comprising', and the like are to be construed in an inclusive sense as opposed to an exclusive or exhaustive sense; that is to say, in the sense o 15 of"including, but not limited to".

Brief Description of the Drawings 9.

Fig. 1 is a block diagram of a network system incorporating a messaging system in accordance with the present invention.

Fig. 2A is a block diagram of the messaging system for the network system shown in Fig. 1.

°Fil °Fig. 2B is a block diagram showing the relationship between the ASCII Definition SFile and the defined data structures and data dictionaries generated from the ASCII o S"Definition File.

.•Fig. 2C is a representation of an application control data structure (ACDS) defined 25 data structure for communications between an RPG application and the messaging system of the present invention.

Fig. 3A is a block diagram of the components of a service application supported by transaction services of the open system network.

Fig. 3B is a more detailed block diagram of the service application of Fig. 3A.

Fig. 4 is a block diagram of the network system of Fig. 1, including a security service in the gateway server.

-A Figs. 5A-5D are flow charts of methods implemented by the messaging system of the present invention.

21609-00.DOC Detailed Discussion of the Invention Referring first to Fig. 1, there is shown a block diagram of a networked computer system 100 including a platform-independent messaging system 120 in accordance with the present invention. Computer system 100 comprises a first computer 112 based on a proprietary system architecture, a server 192 based on an open system architecture, and a gateway server 152 for connecting the different system architectures. The proprietary system architecture of first computer 112 is represented by network protocol 130, and the open system architecture of server 192 is represented by network protocol 160. For example, the open system architecture may be a UNIX or Windows-based architecture, and network protocol 160 is typically TCP/IP.

First computer 112 includes an RPG application 1 10 coupled to messaging system 120, which generates message packets based on RPG-provided data for transmission on network protocol 130. In the preferred embodiment of the invention, first computer 112 is an IBM AS/400 system, adhering to IBM's System Network Architecture (SNA), and network protocol 130 is IBM's SNA LU6.2. Messaging system 120 acts as an application program interface (API) between RPG application 110 and service applications 310 (Fig. 3A) accessed through transaction management system 150. Specifically, messaging system 120 converts data and control information provided by RPG application 110 into a message packet that is transmitted to gateway server 152 using LU6.2 protocol (130).

Gateway server 152 includes a network services module 140, a transaction management system 150, and an interface module 142. When triggered by messaging system 120, network service module 140 allocates a conversation between messaging system 120 and transaction management system 150 by means of interface module 142. In the preferred embodiment of the invention, this occurs when messaging system 120 is initialized by a call from RPG application 110.

A conversation is a logical connection that allows communications between applications on different nodesro proceed, while hiding the details of the underlying communication protocol from the communicating applications. In the disclosed embodiment, the allocated conversation carries message packets between messaging system 120 and transaction management system 150. The message packets include parameters, i.e. data and control information, necessary to activate the remote process (service application 310), carry on communications with the activated process, and terminate it. For example, transaction management system 150 provides access to service applications 310 (Fig. 3A) on open system network server 192, based on control information specified in these message packets. Gateway server 152 handles conversion between the SNA and open system communication protocols, i.e.

TCP/IP.

.77rrJ;,. The actual format of the message packets is specified in part by interface module 142, which separates the data and control information contained in a message packet, and uses the control information to establish a dialogue with a requested service application 310 through transaction management system 150. The data from the message packet is forwarded to the designated server application 310 along with a control header provided by transaction management system 150. The other determining factor in the format of the message packet is server application 310, which employs a build/parse module 320 (Fig. 3A) comparable to that in messaging system 120 to parse and, if necessary, reformat data from the forwarded message packet in accordance with a data dictionary 328. This process is discussed in greater detail below, in conjunction with Fig. 3B.

Suitable transaction management systems 150 include transaction processing monitors that adhere to X/Open distributed transaction processing (DTP) model. These include AT&T's TOP END, Novell's TUXEDO, and Transarc's ENCINA. AT&T's TOP END transaction management system 150 is employed in the preferred embodiment of system 100.

Modifications of the TOP END transaction monitor are necessary to preserve the security and accountability of transactions by ensuring that identification codes assigned to users of RPG application 110 (userids) are preserved when the users' service requests are forwarded to transaction services-1 7 0. These modifications are discussed below, in conjunction with Fig. 4.

Referring now to Fig. 2A, there is shown a block diagram of messaging system 120.

Messaging system 120 comprises a MSG module 210, a Build/Parse module 220 including a data dictionary 228, and defined data structures (DDS) 250 for coupling data between messaging system 120 and RPG application 110. Also shown are a List_Build module 230 for facilitating data access, a memory management system (MMS) module 240 for allocating and deallocating memory for messaging system 120, and an inbound/outbound message buffer 218 for communicating with transaction management system 150. In order to make messaging system 120 portable between platforms, component modules 210, 220, 230, and 240 are written in the C prograu ffn g language.

MSG module 210 includes a MSG API 212 through which RPG application 110 accesses functions.21 4 for initiating and terminating conversations with transaction management system 150 and for requesting transaction processing services from server applications 31 Cccessed through transaction management system 150. In the disclosed embodiment, MSG module 210 also includes registered functions 216, which manipulate data between DDS 250 and MSG buffer 218 as described below.

Build/Parse module 220 comprises a Build/Parse API 222, a data dictionary (DD) 228, message building/parsing functions 224, and a registered function (RF) API 226. Build/Parse TR 222 provides MSG module 210 with access to platform independent message bilding/parsing functions 224. DD 228 specifies the fields and field attributes of data segments that are recognized by an open system resource being accessed by RPG application 110. As discussed in greater detail below, DD 228 contributes to the flexibility of messaging system 120, by providing a mechanism for altering its message building capabilities without requiring recoding of RPG application 110 or service applications 310.

RF API 226 provides Build/Parse module 220 with access to registered functions 216, which manipulate RPG data in DDS 250. Registered functions 216 are specific to the data types of a platform, and including registered functions 216 in MSG module 210 removes any platform-dependence from Build/Parse module 220. For example, a substantially identical build/parse module 322 (Fig. 3A) is employed in service application 310 on the open system platform. Build/Parse mpdule 320 parses request message packets from RPG application 110 and builds response message packets to RPG application 110.

List build module 230 and MMS module 240 provide linked list building and memory allocation functions, respectively, for MSG module 210 and Build/Parse module 220. For example, when RPG application 110 is initialized, it identifies to MSG module 210 all DDS it employs. MSG module 210 checks that the DDS have the proper number of parameters and calls List build module 230 to generate a linked list of pointers to the DDS. Listbuild module calls on MMS module 240 as needed to allocate memory for the linked list. List_Build module 230 and MMS module 240 are also used by MSG module 210 to eliminate the linked list when RPG application 110 is terminated.

Typical service applications 310 provide RPG application 110 with functions for searching and writing data to database 390 (Fig. 3A). In order for RPG application 110 to communicate with database 390, messaging system 120 must employ in its data packets, data having attributes consistent with the columns of database 390. Since RPG application 110 is the ultimate source of data, messaging system 120 must include some means of ensuring consistency between the attributes of the data segments employed by RPG application 110 and those of databas'90. This is the function of DDS 250 and DDs 228, 328.

Messaging system 120 provides utilities for generating DD 228 and DD 328 (Fig. 3B) and DDS 250 from a single source that includes attribute definitions consistent with those of database 390. This ensures that messaging system 120 and service application 310 support the same vocabulary which in turn ensures that RPG application 110 and database 390 can communicate. The single source from which DDs 228, 328 and DDS 250 are generated is ASCII definition file (ADF) 260.

Referring now to Fig. 2B, there is shown a block diagram indicating the relationship among ADF 260, DDs 228, 328, and DDS 250. ADF 260 is a human-readable file that includes descriptions of the attributes of every field of every data segment in the system. As noted bove, the attributes of a segment field correspond to the columns (attributes) of the database ADF 260 also includes header segments, which are used to indicate which ser/ice l 77+,rz4 application 310 is being requested by RPG application 110 and may also include control information for error codes and messages. Header segments associated with service applications 310 that require input data from RPG application I 10 have appended the data segments corresponding to the required data. ADF 260 also includes a list of restricted segments, which are segments that may only be used by selected service applications 310. ADF 260 is typically generated through a GUI design tool, which in the preferred embodiment of the invention, is Visual Builder Tool (VBT). In essence, ADF 260 specifies the vocabulary understood by database 390.

Also shown in Fig. 2B is a Data_Structure Utility (DSU) 270 which is used to generate DDS 250 from ADF 26Q. DDS 250 are regenerated whenever ADF 260 is modified. DSU 270 reads ADF 260 and uses ListBuild module 230 to generate a linked list of fields and a linked list of segments from the entries in ADF 260. For every segment in the segment linked list, DSU 270 retrieves attributes of the component fields from the field linked list and writes the information to a DDS 250. In a preferred embodiment, DDS 250 are made available to messaging system 120 by writing them to a file, which is linked to RPG application 110 and messaging system 120 as an externally defined data structure.

In the preferred embodiment of messaging system 120, two DDSs 250 are provided for each data segment defined in ADF 260. Application request data structures (ARDS) 252 are loaded with data by RPG application 110 to provide messaging system 120 with the data it needs to a build a message to a service application 310 (service request). Application response data structures (ASDS) 254 are written by messaging system 120 to communicate a response from service application 310 to RPG application 110 (service response), following parsing by Build/Parse module 220. A single applicationcontrol data structure (ACDS) 256 is used by RPG application 110 to communicate service application requests to messaging system 120.

Also shown in Fig. 2B is a utility, DDBIN 280, that reads ADF 260 and generates DD 228 as a binary gsorted by segment names. DDBIN 280 also creates a summary information field for DD 228, including the total number of segments, offsets into DD 228 for alphabetically sorted segment groups, and an offset into the file for a restricted segment file (RSF). This is followed by a flatrepresentation of segment structures and field structures for each segment and field known to the system.

The segment and field structures summarize all segment/field information necessary for messaging system 120 to couple data between RPG application 110 and transaction management system 150. For example, each segment structure includes the name of the segment, the number of fields for the segment and whether or not the fields have been initialized, and an offset into DD 228 to the first field structure of the segment. Each field structure includes the field name, a pointer to the field data, the number of elements for fields i that comprise arrays, the data type of the field, the length in bytes of the field data, the maximum number of array elements allowed for the field, flags indicating restrictions on the data, the number of decimal places, and the names (place-holders) of registered functions that may be applied to the field data. In sum, the field and segment structures provide the templates used by Build/Parse module 220 when manipulating and converting data between DDS 250 and message buffer 218.

DD 228 may be linked into Build/Parse module 220 as an include file. Alternatively, the contents ofDD 228 may be read into a segment cache 354 (Fig. 3B) associated with Build/Parse module 220, as needed, to facilitate access to segment information. This latter alternative is employed in the preferred embodiment of messaging system 304 (Fig, 3A) which is used for message packet building/parsing by service application 310.

Each time ADF 260 is modified, DDS 250 and DDs 228, 328 must be updated to reflect any changes to the underlying segments. Referring to Fig. 5C, there is shown a method for determining the field structure for each segment defined in ADF 260. Entries in ADF 260 are read 576 sequentially. When segment information is read 578, the segment name is added 580 to a linked list and fields associated with the segment are inserted 582 in the linked list entry.

When field information is read 584, the field name is added 586 to a field linked list and associated field attribute information is inserted 588 in the field linked list entry. This is repeated 590 until all segment and field information has been read from ADF 260 and corresponding field and segment linked lists have been generated. At this point, DDSs 250 may be generated from the segment and field linked lists.

Referring now to Fig. 5D, there is shown a method for generating DDS 250 from the segment and field linked lists such as those provided by the method of Fig. 5C. A source file is opened 591 for storing DDSs 250 generated and each segment in the linked list is read 592.

Field information associated with each segment provides access 593 to a corresponding entry in the field linked list. Attribute information stored with each field entry is written 594 to an area of the source file assigned to the segment. This is repeated 595 for each field of the segment and for each segment 596 of the linked list. When the field attributes of the last segment have been written to the source file, the file is closed 597.

The method for generating DD 228 is similar to that described above for DDSs 250 except that a header including summary information is generated for DD 228 and additional information on field data types and registered functions is included in the field structures generated. In the preferred embodiment of messaging system 120, DD 228 is added to Build/Parse module 220 as an include file.

Alternativly, in transaction services 170 (Fig. 3B) DD 328 is stored as a separate file on disc. Build/Parse module 320 checks and records a time stamp in DD 328 prior to accessing d egment information. A time stamp in DD 328 that is more recent than the value recorded by 'uild/Parse module 320 indicates that DD 328 has been modified. When Build/Parse module i ;-771,W44 320 detects a more recent time stamp in DD 328, it drops the segment information derived from the earlier version of DD 328 and reloads the modified segment information from DD 328.

Referring now to Fig. 2C, there is shown a representation of an ACDS 256 that is used by RPG application 110 to request services of messaging system 120. ACDS 256 is also used by messaging system 120 to provide information on the status of requested services to RPG application 110. A single ACDS 256 is used by RPG application 110 to indicate which of transaction services 170 is being requested. Details of the requested service are provided in the following data fields of ACDS 256: Request Service Name, Sending Segments, and (3) Hold Context Flag.

Request Service Name is a data field in which the name of a service application 310 available through transaction management system 150 is specified. A corresponding header segment defined in ADF 260 is used by messaging system 120 to indicate to transaction management system 150 the type of service being requested. As noted above, some service applications 310 require that RPG application 110 provide data along with the service request.

In these cases, the Sending Segments field is used by RPG application 110 to specify which ARDSs 252 contain the required data. Each such ARDS 252 is specified in the Sending Segments field by the Segment Name of the data it contains. In the preferred embodiment of the invention, the name of each data segment to be sent is concatenated and delimited by a pipe For example, where data from three ARDSs 252 corresponding to a name (NAME), business address (BUS), and home address (HOME) will be sent to service application 310 specified by ACDS 256, the Sending Segments field will be NAMEIBUSIHOME. Data provided in response to a service request is sent from service application 310 to messaging system 120 as data segments. Messaging system 120 makes any necessary data conversions and forwards the converted data segments to RPG application 110 using the corresponding ASDSs 254.

Hold Coptxt Flag is set when RPG application 110 will retain an on-going conversation with a service application 310 as, for example, when RPG application 110 will submit sequential service calls to service application 310.

The Results Services fields of ACDS 256 comprises Return Status Code, Initialized Flag, and ContrqFlag fields. Messaging system 120 uses these to indicate to RPG application 110 the status of a service request. Return Status Code is zero, unless an error has occurred in the Service Request. Initialized Flag is set when messaging system 120 is properly initialized and is zero otherwise. Control Flag indicates the status of messaging system 120. It is zero by default, four when a service application 310 is currently holding context, and some non-zero value other than four when a failure occurs in messaging system 120.

The interactions between RPG application 110 and messaging system 120 will now be escribed from initialization through termination of RPG application 10. As noted above, I !,?7(;nX4 messaging system 120 is initialized through a function call from RPG application 10 during its initialization. The initializing function call includes a parameter list specifying the segment name, segment address, and number of occurrences of each ARDS 252 and ASDS 254 used by RPG application 110 to send data to and receive data from MvSG module 210. The parameter list also specifies the name and address of ACDS 256 used by RPG application 110 to communicate control information to MSG module 210. Addresses for ARDS 252. ASDS 254, and ACDS 256 (collectively, DDSs 250) are in shared memory location 114.

On initialization, MSG module 210 first checks that DDSs 250 are specified properly (3 parameters for each ARDS 252 and ASDS 254 and 2 parameters for ACDS 256). MSG module 210 then calls initializing functions in Build/Parse module 220, List_build module 230, and MMS module 240, initializes a conversation with transaction management system 150 via network services 140 and IF 142. and waits for a verification message that the conversation has been established. At this time, transaction management system 150 establishes a dialogue with transaction services 170 on open system server 192. MSG module 210 also calls List_Build module 230 to generate a linked list of pointers to DDSs 250, and ListBuild module 230 calls MMS module 240 as needed to allocate memory for the linked list.

Once conversation/dialogue links have been established between messaging system'1 2 0 and transaction management system 150, RPG application 110 accesses a requested service application 310 of transaction services 160 through transaction management system 150, using messaging system 120 as an application program interface (API). RPG application 110 initiates a request for services by loading the Request Service Name and Sending Segments List fields of ACDS 256 with the segment name of the service being requested and the segment names of any data that is to be provided with the service request. RPG application 110 also loads each ARDS 252 named on the Sending Segments List with the data to be sent.

When ARDSs 252 and ACDS 256 are loaded, RPG application 110 calls the request function in MSmodule 210, including the names of ACDS 256 and ARDS 252 in a parameter list associated with the function call. MSG module 210 use the request function to clear the Results Services fields of ACDS 256 and read the Request Service Names and Sending Segments List fields of ACDS 256. MSG module 210 writes a control/status header (see below) to message buffer 218, specifying Request Service Name, a user identification (userid), and status data far transaction management system 150. MSG module 210 also calls the Build MSG function in Build/Parse module 220 with the parameter list specifying the names of the data segments and the location of message buffer 218.

Build/Parse module 220 handles the conversion and manipulation of data between the DDSs 250 identified in the parameter list and message buffer 218. As noted above, the 4 ild/Parse MSG functions of module 220 use registered functions 216 to accomplish the ial data manipulation between DDSs 250 and message buffer 218. For outbound messages, 1 ,53:41.231 D7170'hX4 ;~,tflKp SHEET the Build MSG function uses the segment and field structures of DD 228 as a template to identify the DDSs 250 having the field data to be transmitted, attributes of the field data, any conversions necessary for the field data, and the registered functions to use for converting the field data and manipulating it to message buffer 218. DD 228 is also used on inbound message packets to convert data to a format appropriate to the operating system of the AS/400 and transfer field data between message buffer 218 and DDSs 250. The addresses of DDSs 250 are determined from the link list generated on initialization.

The message packet generated by messaging system 120 has the following form: error control I function code I userid data.

control/status application data The header, comprising error, control, function code, and userid fields, provides the routing and status information necessary to transfer the service request and associated data of RPG application 110 from messaging system 120 to requested service application 310. In particular, the error field includes error codes for tracking purposes, the control field specifies the status of communications with transaction management system 150, the function code field specifies which service application 310 is being requested, and for security checking purposes, userid.

identifies the person(s) using RPG application 110. The data field comprises the service name and any application data, suitably formatted, that is being transferred between RPG application 110 and service application 310. As discussed above, this data is loaded by messaging system 120 using Parse/Build module 220.

Once the message packet has been completed, MSG module 210 calls a send/receive function to forward the message packet to transaction management system 150 in gateway server 152, using the conversation allocated on initialization. Interface module 142 maps the conversation to the dialogue established between transaction management system 150 and transaction services 170, determines from the function code in the header of message packet (I) which service ap eation 310 is targeted, and uses transaction management system 150 to call targeted service application 310.

Referring row to Fig. 5A, there is shown a flow chart summarizing the method described above for transferring data from RPG application 110 to transaction management system 150. RPQ application loads 510 data into appropriate DDSs 250 and calls 514 messaging system to begin the data transfer. Messaging system 120 identifies 520 to Build/Parse module 220 segments indicating the service requested and any data required, and Build/Parse module 220 accesses 524 the appropriate segment structures through DD 228.

Using the segment structures, Build/Parse module 220 writes 530 the segment and field names message buffer 218. Message buffer also calls 534 registered functions indicated in the field tures to transfer the field data from DDS 250 to message buffer 218 and implement any field data conversions indicated by the field structure. The header is added 540 to message buffer 218 and the message packet transmitted 544, using the conversation previously established between messaging system 120 and transaction management system 150.

Referring now to Fig. 5B, there is shown a flow chart summarizing the method implemented by messaging system 120 for parsing message packets from transaction management system 150. When an incoming message packet is detected 550, build/parse module 220 identifies 554 a segment name in the buffer and uses DD 228 to determine 560 the various properties of the associated fields. Consistency between the field names in message buffer 218 and those specified in the segment structure of DD 228 provides a check on the data in the received message packet. Build/Parse module 220 calls 564 registered functions indicated in the field structures to convert and load data from message buffer 218 to the appropriate DDSs 250. When data conversion/loading is completed, messaging system 120 returns control 570 to RPG application 110, which retrieves the requested data from DDS 250.

Processes similar to those described for Build/Parse module 220 are implemented by build/parse module 320 in service application 310. The main difference is that data is converted and transferred between message buffer 314 and a data structure accessible to application function 314. Application function 314 uses the data for communications with DBMS 380.

Refemrring no'w to Fig. 3A, there is shown a block diagram of components of transaction services 170 for accessing a resource on the open system network. Transaction services 170 comprises an instance of transaction management system 150, including a client-server interface (CSI) 154, a database management system 380, a service application 310, and a message conversion module 304. Message conversion module 304 comprises a message Build/Parse module 320, a list_build module 330, and a memory management system (MMS) module 340, which perform functions for the open system platform of server 192 that build/parse module 220, list_build module 330, and MIMS module 240 perform on the 2 5 proprietary platform of AS/400 112. In the case of server 192, however, transaction management syst. 150 operates in conjunction with CSI 154 to handle routing and control information. In particular, these components ensure that the data portion of message packet (I) is routed to service application 310, and effectively act as the counterpart of MSG module 210 on server 192. Onthe other hand, the data portion of message packet must be converted into a format suitable for the open system platform, and this is the function performed by modules 320, 330, 340.

In the preferred embodiment of system 100, resource manager (DBMS 380) is Informix and transaction management system 150 is AT&T's TOP END, both of which conform to the X/Open distributed transaction processing (DTP) XA interface. Transaction management y_ stem 150 also conforms to the DTP TX interface for communications with service application p i Referring now to Fig. 3B, there is shown a detailed block diagram of service application 310 and its interaction with DBMS 380 and message conversion module 304. As indicated, service application 310 has associated registered functions 316 and an inbound/outbound message buffer 314 through which message packets are received/sent. Registered functions 316 are used by build/parse module 320 to parse data from inbound message packets, convert the parsed data, and load it into data structures associated with application function 3 14. Similarly, parse/build module 320 uses registered functions 316 to build messages in buffer 314 from data provided by application function 314. Application function 314 handles communications with DBMS 380, much as message module 210 handles communications with RPG application 110.

In the preferred embodiment, however, DBMS 380 is written in C, not RPG, and the defined data structures (DDS 250) described above are not necessary. Rather, application function 314 employs data structures defined by C typedefs for manipulating and converting message data.

List build module 330 and MMS 340 provide essentially the same functions as their counterpart modules 230, 240 on AS/400 112.

Message conversion module 304 also differs from messaging system 120 in that it uses a segment cache 354 and segment cache interface structure (SCIS) 352 to facilitate access to the segment and field structures of data dictionary (DD) 328. The need to search DD 326 is eliminated when the necessary segment/field information is available in cache 354. This is an alternative configuration to that employed on AS/400 112.

While the configuration of computer system 100 shown in Fig. 1 provides the necessary communication between an RPG application 110 and transaction services 170, it does not provide adequate security or accounting functions for many purposes. This arises in the preferred embodiment of system 100, where transaction management system 150 is TOP END (TE) and IF 142 is an inbound agent (IA) spawned by network services module 140 when messaging system 120 is initialized. In particular, IF 142 is configured to map all conversations/dialogues having the same transaction program name (TE sign-on name) and transaction cod#-equest Service Name) to a generic userid. This means that all users of a given service application 310 will be assigned the same userid, independent of which user(s) of RPG application 110 actually initiated the transaction. If not addressed, this circumstance effectively eliminates security checking and accountability for transactions to server 192.

In order o ensure both security checking and accountability for transactions to server 192, the preferred embodiment of system 100 incorporates a security service, SIGNON SECURITY SERVICE (SSS) 154, in the TE transaction management system 150 on gateway server 152. Referring now to Fig. 4, there is shown a block diagram of a preferred configuration for gateway server 152, in which transaction management system 150 is coupled to transaction services 160 through SSS 154. SSS 154 comprises a TE client 156' and aTE Sserver 156 coupled back-to-back through a client/server interface (CSI) provided by transaction management system 150.

22 I ii 4 -14- IF 142 incorporates an integral client which accesses SSS 154 through transaction management system 150 on behalf of messaging system 120. On initialization of messaging system 120, network services module 140 spawns IF 142, which forwards a SIGNON message, including a non-generic userid, generated by messaging system 120.

IF 142 establishes a dialogue with SSS 154 by passing a request for SSS services through transaction management system 150, using the generic userid provided in the configuration file of IF 142. Transaction management system 150 forwards the request to SSS 154, establishing a dialogue between TMS server 156 and RPG application 110 (via messaging system 120). TMS server 156 then triggers TMS client 156' to sign onto transaction management system 150 using the non-generic userid embedded in the signon message. SSS 154 confirms to messaging system 120 that the dialogue has been established, and sets a flag holding the dialogue open. Thereafter, transaction services 170 are accessed by TMS client 156' in response to message packets from messaging system 120.

While the present invention has been described with reference to the particular :embodiments disclosed herein, these are included merely to better illustrate its operation.

A messaging system incorporating these same features may be implemented in a number :4.,of different ways that fall within the scope of the present invention.

Embodiments of the invention provide a system and method for coupling messages 20 between an RPG application on a proprietary computer system and a transaction *•°99 °management system on an open network system. The system includes a data dictionary that provides all segment and filed information known to the computer system, a platform-independent message Build/Parse module that builds request message packets to open network services and parses response message packets in accordance with the data dictionary, a set of DDS for coupling data/control information between the RPG application apd the messaging system, and a message module that initializes communication links with the open system network, sends service request messages to and receives service response messages from resources on the open system network, and terminates communication links with the open system network when triggered by the RPG application.

Claims (4)

1. A messaging system for coupling transactions between a report program generator (RPG) application implemented on a proprietary computer system and a transaction management system implemented on an open computer system, the messaging system comprising: a messaging module implemented on the proprietary computer system and coupled to the RPG application and the transaction management system for initializing and terminating a communication link with the transaction management system and for transmitting service requests and responses between the transaction management system and the RPG application, each request and response having at least one segment; a data dictionary module comprising a plurality of segment definitions for specifying attributes of segments of requests and responses transmitted to and from the transaction management system; a set of defined data structures stored in a memory accessible to the messaging module and the RPG application, for receiving and storing data from both the RPG application and the messaging module, each data structure associated with a segment 4 4 definition of the data dictionary module; and a message build/parse module coupled to the data dictionary module and the 20 messaging module, the message build/parse module including functions for reading data and control information stored in the data structures by the RPG application, and S-assembling the read information into a service request in accordance with segment definitions associated with the read data structures, the assembled request to be transmitted to the transaction management system by the messaging module, and for 25 parsing a service response received from the transaction management system in accordance with the segment definitions into data, and storing the parsed data into the data structures associated with the segment definitions used to parse the service response, the stored data read from the data structures by the RPG application.

2. The messaging system of claim 1, wherein the defined data structures are defined in accordance with the segment definitions of the data dictionary module.

21609-00 DOC -16-

3. The messaging system of claim 1, wherein the messaging module includes registered functions accessible by the message build/parse module for manipulating data between the defined data structures and an input/output buffer.

4. The messaging system of claim 3, wherein the registered functions include a conversion function for converting data between proprietary-platform-specific formats and open platform formats. The messaging system of claim 1, further comprising a linked list module coupled to the message build/parse module and including pointers to each defined data structure, for facilitating access to the defined data structures, and pointers associated with respective segment definitions. 6. The messaging system of claim 1, further comprising a memory management module coupled to the message build/parse module for allocating and deallocating memory for segments and data structures. 7. The messaging system of claim 1, further comprising: a definition file including human readable definitions of data segments and service types; and e a utility module for reading the definition file and generating the defined data structures from the human readable definitions. 8. The messaging system of claim 7, further comprising a second utility 20 module for reading the definition file and generating the data dictionary module ,1 I including binary definitions of data segments and service types. 9. The messaging system of claim 1, wherein the data dictionary module is incorporated into the message build/parse module. The messaging system of claim 1, further comprising a segment cache coupled to the message build/parse module for storing pointers to data and server segments in the memory to allow rapid access to recently used segment definitions. 11. The messaging system of claim 1, wherein the open system is a UNIX- based system. 12. The messaging system of claim 1, wherein the open system is a Windows-based system. 21609-00.DOG -17- 13. The messaging system of claim 1, wherein the proprietary system is an IBM AS400-based system. 14. A method for coupling transactions between an RPG application implemented on a proprietary computer system and a transaction management system implemented on an open computer system, the method comprising the steps of: storing a data dictionary module defining segment definitions for segments of service request messages, and each segment definition associated with a data structure in a memory accessible to the RPG application; establishing a communication link between the RPG application and the transaction management system; detecting a service request from the RPG application; determining from the data dictionary module at least one service segment definition associated with the service request; reading data and control information stored by the RPG application from a memory shared with the RPG application and associated with the determined service segment definition; generating a service request message packet using the read data and control information according to the service segment definition; and transmitting the service request message packet to the transaction management 20 system on the communication link. The method of claim 14, wherein the step of establishing a communication link comprises the substeps of: identifying data and control segments associated with the RPG application; and S: generating a linked list of data structures associated with the identified data and control segments. 16. The method of claim 15, wherein the step of establishing a communication link further comprises the substeps of: transmitting an initialization signal to the transaction management system; detecting an acknowledgment signal from the transaction management system; and signalling establishment of the communication link. 21609-00.DOC -18- 17. The method of claim 15, wherein the step of detecting a service request comprises reading a service name from a designated data structure. 18. A method for coupling transactions between an RPG application implemented on a proprietary computer system and a transaction management system implemented on an open computer system, the method comprising the steps of: storing a plurality of segment definitions in a data dictionary module, at least one segment definition associated with at least one service request message and further associated with data structures in a memory accessible to the RPG application to read and write data therefrom to specify a service request to the transaction management system; retrieving a specified service request from a data structure; determining segment definitions of the specified service request from the data dictionary module; reading control and data information in the data structures associated with the determined segment definitions, the control and data information stored in the data structures by the RPG application; generating a request transaction by formatting the read data into a plurality of 4 segments in accordance with the determined segment definitions; and transmitting the request transaction to the transaction manager. a 20 19. The method of claim 18, wherein the step of storing a plurality of segment definitions comprises: -providing a file of human readable segment definitions; and generating a file of machine readable segment definitions from the human readable segment definitions. 25 20. The method of claim 19, further comprising generating data structures o o from the human readable segment definitions. S21. The method of claim 18, wherein the step of determining a segment definition comprises the substeps of: comparing a service name in the specified request with the segment definitions of the data dictionary module to identify a segment definition associated with the service S name; and 21609-00.DOC -19- identifying fields associated with the identified segment definition. 22. The method of claim 21, wherein the step of generating a request transaction in accordance with the segment definitions comprises the substeps of: writing the service name to a message buffer; determining from the identified fields properties of data stored in the fields; converting data stored in the identified fields as indicated by the determined properties; and transferring the converted data to the message buffer. 23. The method of claim 22, comprising the additional step of prepending routing information to data in the message buffer. 24. The method of claim 18, wherein at least one segment definition is associated with a response message, further comprising the steps of: detecting a response message; parsing the response message into segment and field data in accordance with segment definitions associated with the response message; and loading the segment and field data into data structures associated with the segment definitions, the data structures in the memory space of the RPG application and readable by the RPG application. o :25. A messaging system for coupling transactions between an RPG S 20 application executing on a proprietary computer system and a transaction management system executing on an open computer system, the RPG application storing a plurality of data structures for writing data to be transmitted to the transaction management system, and for reading data received from the transaction management system, the messaging system comprising: a messaging module for execution on the proprietary computer system and S. providing a set of functions invokable by the RPG application and the transaction management system to transmit requests from the RPG application to the transaction management system, and to transmit responses from the transaction management system to the RPG application, each request and response having at least one segment, each segment having defined attributes; 21609-00.DOG 20 a set of defined data structures stored in a memory accessible to both the messaging module and the RPG application, for receiving and storing data and control information from both the RPG application and the messaging module, each data structure associated with a segment; and a message parse/build module having a set of functions invokable by the messaging module, the functions including: a message build function for reading data and control information stored in selected ones of the data structures by the RPG application, and assembling the read information into a request in accordance with the attributes of the segments associated with the read data structures, the assembled request to be transmitted to the transaction management system by the messaging module; and a message parse function for parsing a response received from the transaction management system into data and control information according to the attributes of the segments of the responses, and storing the parsed data and control information into the data structures associated with segments used to parse the response, the stored data and control information read from the data structures by the RPG application. 26. The system of claim 25, further comprising: *a data dictionary module communicatively coupled to the messaging module and Sstoring attributes defining each segment. S 20 27. The system of claim 25, further comprising: a message buffer coupled to the messaging module and the message build/parse module, for storing a request assembled by the message build/parse module, the messaging module reading the request from the message buffer and transmitting it to the too transaction management system, and for storing a response from the transaction management system, the message build/parse module reading the stored response and •parsing it into data for storing into the data structures in the memory. 28. The system of claim 25, wherein each segment includes at least one field, the system further comprising: a linked list module for generating a linked list of pointers, each pointer pointing to a data structure in the shared memory, and associated with a segment or field of a request _or a response, the message build/parse module using the pointers associated with a 21609-00.DOC -21- request or response to respectively read or write data in the data structures accessible to the RPG application. 29. A method for coupling transactions between an RPG application implemented on a proprietary computer system and a transaction management system implemented on an open computer system, the method comprising the steps of: storing a plurality of segment definitions, each segment definition corresponding to a segment of at least one message and further associated with a data structure stored in a memory accessible to the RPG application for receiving data from the transaction management system and being read by the RPG application; detecting a response message from the transaction management system; parsing the response message into data portions using the segment definitions corresponding to segments of the response message; and storing the parsed data portions into the data structures associated with the segment definitions corresponding to the segments of the response message, the parse data accessible to the RPG application by reading the data structures. A messaging system substantially as herein described with reference to any one embodiment and its associated drawings. 31. A method for coupling transactions substantially as herein described with o reference to any one embodiment and its associated drawings. *o S DATED this 13th Day of August 1999 S: HARRAH'S OPERATING COMPANY, INC. Attorney: PETER R. HEATHCOTE Fellow Institute of Patent Attorneys of Australia of BALDWIN SHELSTON WATERS *i 21609-00.DOC