WO1998002811A1

WO1998002811A1 - Method for coupling transaction systems

Info

Publication number: WO1998002811A1
Application number: PCT/US1997/011884
Authority: WO
Inventors: Richard L. Thomas; Richard P. O'beirne; Eugene D. Kays; Carl Osborne, Iii
Original assignee: Harrah's Operating Company, Inc.
Priority date: 1996-07-11
Filing date: 1997-07-10
Publication date: 1998-01-22
Also published as: NZ333320A; AU3881097A; EP0912938A1; AU718928B2

Abstract

The MSG module uses the network services on the gateway to initialize conversations with the transaction monitor, 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 the RPG 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 control information. A Build/parse module associated with a service application at the open system resource provides comparable message building and parsing services for the resource.

Description

METHOD FOR COUPLING TRANSACTION SYSTEMS

Related Patent Applications

This patent application is related to U.S. patent application no. , entitled

"National Customer Recognition System and Method", assigned to the same assignee and filed on even date herewith.

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 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 systems networks and are not 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 programming environments. These are relatively slow by current OLTP systems standards 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 attiibutes. In addition, the conversion code slows down response time of these applications and limits the utility of the legacy systems for real-time, on-line processing.

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

Summary of the Invention

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, 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.

A messaging system in accordance with the present invention comprises a messaging module (MSG module) that serves as an application program interface (API) 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 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 appiopπate control 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.

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 dictionanes are updated only when the ADF is modified, at which times, the updated objects are generated using utilities provided by the present invention

Brief Description of the Drawings

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 tor the netwoik system shown in

Fig 2B is a block diagram showing the relationship between the ASCII Definition File and the defined data structures and data dictionaries geneiated from the ASCII Definition File

Fig. 2C is a representation of an ACDS defined data structure foi communications between an RPG application and the messaging system ot the piesent 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 ot Fig 3A.

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

Figs. 5A-5D are flow charts of methods implementedy by the messaging system of the present invenUon 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 1 12 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 1 12 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. 3 A) accessed through transaction management system 150. Specifically, messaging system 120 converts data and control information provided by RPG application 1 10 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 1 10.

A conversation is a logical connection that allows communications between applications on different nodes to 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. 3 A) 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. 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 packets, and uses the control information to establish a dialogue with a requested server 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. 3 A) 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 160. 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 1 10. 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 programming language.

MSG module 210 includes a MSG API 212 through which RPG application 110 accesses functions 214 for initiating and terminating conversations with transaction management system 150 and for requesting transaction processing services from server applications 310 accessed 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 API 222 provides MSG module 210 with access to platform independent message building/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 1 10. 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 1 10 or server applications 310.

RF API 226 provides Parse/build 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 server application 310 on the open system platform. Build/Parse module 320 parses request message packets from RPG application 110 and builds response message packets to RPG application 1 10.

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. List_build 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 1 10 with functions for searching and writing data to database 390 (Fig. 3 A). In order for RPG application 1 10 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 1 10 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 1 10 and those of database 390. 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 1 10 and database 390 can communicate. The single source from which DDs 238, 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 above, the attributes of a segment field correspond to the columns (attributes) of the database 390. ADF 260 also includes a header segments, which are used to indicate which service 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 1 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 260. DDS 250 are regenerated whenever ADF 260 is modified. DSU 270 reads ADF 260 and uses List_Build 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 application control data structure (ACDS) 256 is used by RPG application 1 10 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 file sorted 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 flat representation 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 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 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 of DD 228 may be read into a segment cache 325 (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 Unked 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 130 as an include file. Alternativly, in transaction services 170 (Fig. 3B) DD 328 is stored as a separate file on disc. Build/parse module 330 checks and records a time stamp in DD 328 prior to accessing segment information. A time stamp in DD 328 that is more recent than the value recorded by build/parse module 330 indicates that DD 328 has been modified. When build/parse module 330 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 1 10 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

160 is being requested. Details of the requested service are provided in the following data fields of ACDS 256: (1) Request Service Name, (2) 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 conesponding 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 1 10 provide data along with the service request. In these cases, the Sending Segments field is used by RPG application 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 ("I"). 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 Context Flag is set when RPG application 1 10 will retain an on-going conversation with a service application 310 as, for example, when RPG application 1 10 will submit sequential service calls to service application 310.

The Results Services fields of ACDS 256 comprises Return Status Code, Initialized Flag, and Control Flag fields. Messaging system 120 uses these to indicate to RPG application 1 10 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 1 10 and messaging system 120 will now be described from initialization through termination of RPG application 110. As noted above, messaging system 120 is initialized through a function call from RPG application 1 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 1 10 to send data to and receive data from MSG 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 1 14.

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_bιιild 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 160 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 List_Build 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 120 and transaction management system 150, RPG application 1 10 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 1 10 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 1 10 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 1 10 calls the request function in MSG module 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 118, specifying Request Service Name, a user identification (userid), and status data for 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 Build/Parse MSG functions of module 220 use registered functions 216 to accomplish the actual data manipulation between DDSs 250 and message buffer 218. For outbound messages, 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:

(I) I error I control I function code I userid I data I. i control status > I < — 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 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 160, determines from the function code in the header of message packet (I) which service application 310 is targeted, and uses transaction management system 150 to call targeted service application 310.

Referring now to Fig. 5A, there is shown a flow chart summarizing the method described above for transferring data from RPG application 1 10 to transaction management system 150. RPG 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 to message buffer 218.

Message buffer also calls 534 registered functions indicated in the field structures 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 1 10, 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.

Referring now to Fig. 3A, there is shown a block diagram of components of transaction services 160 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_bιιild module 230, and MMS module 240 perform on the proprietary platform of AS/400 1 12. In the case of server 192, however, transaction management system 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. On the other hand, the data portion of message packet (I) 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 7.0, 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 system 150 also conforms to the DTP TX interface for communications with service application 310.

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 314. 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 1 10. In the preferred embodiment, however, DMBS 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) 326. 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 1 12.

While the configuration of computer system 100 shown in Fig. 1 provides the necessary communication between an RPG application 1 10 and transaction services 160, 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 (LA) spawned by network services module 140 when messaging system 120 is initialized. In particular. I A 142 is configured to map all conversations/dialogues having the same transaction program name (TE sign-on name) and transaction code (Request 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 to 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 a TE server 156' coupled back-to-back through a client/server interface (CSI) provided by transaction management system 150.

IA 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 IA 142, which forwards a SIGNON message. including a non-generic userid, generated by messaging system 120. I A 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 I A 142. Transaction management system 150 forwards the request to SSS 154, establishing a dialogue between TE server 156 and RPG application 110 (via messaging system 120). TE server 156 then triggers TE 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 160 are accessed by TE client 156' in response to message packets (I) from messaging system 120.

While the present invention has been described with reference to the particular embodiments disclosed hererin, these are included merely to better illustrate its operation. A messaging system incorporating these same features may be implemented in a number of different ways that fall within the scope of the present invention.

There has thus been provided a system and method for coupling messages between an RPG application on a proprietary computer system and a transaction management system on an open network system. The system includes a data dictionary that provides all segment and field information known to the computer system, a platform-indpendent 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 and 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.

What is claimed is:

Claims

1. A messaging system 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 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; a data dictionary module comprising a plurality of segment definitions for specifying properties of data and services accessed through the transaction management system; a set of defined data structures accessible to the messaging module and the RPG application, for exchanging data and control information between the RPG application and the messaging module; and a message parse/build module coupled to the data dictionary and the messaging module, the message parse/build module including functions for assembling data and control information into a service request and parsing service responses into data in accordance with the segment definitions.

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

3. The messaging system of claim 1, wherein the messaging module includes registered functions accessible by the 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.

5. The messaging system of claim 1, further comprising a linked list module coupled to the build/parse module and including pointers to each defined data structure, for facilitating access to the defined data structures.

6. The messaging system of claim 1 , further comprising a memory management module coupled to the 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 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 module for reading the definition file and generating the data dictionary including binary definitions of data segments and service types.

9. The messaging system of claim 1, wherein the data dictionary is incorporated into the message build/parse module.

10. The messaging system ot claim 1, further comprising a segment cache coupled to the message build/parse module tor storing pointers to data and serve- segments to facilitate message building and parsing.

1 1 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.

13 The messaging system of claim 1, wherein the piopπetary 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 using data structures defined in accordance with data and lequest segments, the method comprising the steps of: 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 a service segment definition associated with the service request; generating a service request message packet according to service segment definition; and transmitting the service request message packet to the transaction management system on the communication link.

15. The method of claim 14, wherein the step of establishing a communication link compπses the substeps of: identifying data and control segments associated with the RPG application; and 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 manager: and signaling establishment of the communication link.

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: providing platform-independent segment definitions in a data dictionary; generating data structures for use by the RPG application to specify service requests; retrieving a specified service request from a data structure; determining a definition of the specified service request from the data dictionary; generating a request transaction in accordance with the determined definition; and transmitting the request transaction to the transaction manager;

19. The method of claim 18, wherein the step of providing platform independent 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.

20. The method of claim 19, wherein the step of generating data structures comprises generating data structures from the human readable segment definitions.

21. The method of claim 18, wherein the step of determining a definition comprises the substeps of: comparing a service name in the specified request with the segment definitions of the data dictionary to identify a segment definition that corresponds to the service name; and 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, comprising the additional steps of: detecting a response message; parsing the response message into segment and field data; and loading the segment and field data into designated data structures.