Electrical computers and digital processing systems: multicomput – Computer-to-computer data routing – Least weight routing
Reexamination Certificate
1998-12-03
2002-10-29
Metjahic, Safet (Department: 2171)
Electrical computers and digital processing systems: multicomput
Computer-to-computer data routing
Least weight routing
C709S241000, C707S793000
Reexamination Certificate
active
06473807
ABSTRACT:
FIELD OF THE INVENTION
The present invention relates to systems and processes that support data communication between distributed computer systems. More specifically, the present invention is directed to a system and data processing method that enables the invocation of programs in a CICS transaction processing system on a remote computer as if they were stored procedures on a database management system.
BACKGROUND OF THE INVENTION
A principal benefit of computers today is the storage of large quantities of data organized in a fashion that allows select portions of the data to be located quickly and presented either to the user or other programs. This is largely accomplished today by use of sophisticated software systems known as databases. A database provides facilities not only to store data, but also to provide enhanced searches to select entries and retrieve data items pursuant to the search protocols. In addition to direct access of the identified entries in the database, advanced features provide for data entries to be related to other entries so that relevant information is accessible in a profoundly manageable mechanism. The use of these facilities is generally referred to as querying a database.
Historically, various database system vendors developed their own languages to query database systems, and also their own application programming interfaces (APIs) by which programs communicated to these database systems. In the early 1980s, an effort by the computer industry to standardize the language by which databases are queried led to the adoption in 1986 of the Structured Query Language (SQL) by the American National Standards Institute. Somewhat later, an effort to standardize database APIs led to the issuance in 1992 of the Open DataBase Connectivity (ODBC) specification. This latter standardization effort was spearheaded by Microsoft Corporation, but quickly became widely adopted by all database system vendors.
The ODBC specification incorporates the SQL specification, by stipulating that all of the query commands to be sent to a database system through an ODBC-compliant API conform to the SQL specification. Both specifications are used almost universally for database access. Both have continued to evolve. The SQL specification was most recently revised in 1992. The ODBC specification is now at version 3.52, and was most recently revised in 1997.
As a result of the development of these two related standards, it is relatively easy for programmers to develop software to access data stored in database systems using programming techniques that are essentially independent of the vendor of the database system being accessed and, therefore, portable to other competing vendor products without substantial rewriting.
With reference to
FIG. 1
, a common feature of a database management system
102
is the ability to store a query in the database system itself, rather than in stored client database programs
103
or stored ODBC invocation programs
101
which access the database management system
102
. Such queries are called stored procedures
106
. Rather than a client data processing system
107
delivering a query to database management system
102
, a stored ODBC invocation program
101
indicates to the database management system
102
the stored procedure
106
it wishes to have executed. A processing mechanism
104
at the database management system
102
executes the procedure, and delivers the result to a remote computer
100
of client data processing system
107
in the same manner as if the query were embedded in the stored client database program
103
. Typical database management systems
102
also include one or more stored database management programs
110
and a database
108
.
With reference to
FIG. 2
, transaction processing for businesses is another critically important function of modem computers. At first glance, there appear to be many similarities between the hardware configurations of
FIGS. 1 and 2
. For example, a typical transactional processing system
202
includes a processing mechanism
204
, a database that stores transactional information
208
, and one or more transactional programs
210
. The foregoing environment relating to databases, as described in
FIG. 1
, was not, however, replicated in the field of transaction support software, and this field has developed without a common pool of standard protocols. In this context, a transaction is defined as a relatively brief interaction between a human being and a computer, where a human using an online terminal types some data and presses a key to request the computer to process that data.
Historically, transactional processing system vendors have developed their products without regard to one another. This has created an environment similar to that which originally existed with database management systems (FIG.
1
), where a user or programmer had to learn the details of each vendor's transactional processing system
202
in order to use it. A programmer working with a particular transactional processing system
202
was required to custom design-transactional programs
210
consistent with the vendor specific protocols for that transactional processing system
202
. As a general matter, transactional programs
210
are executed by a processing mechanism
204
, but software protocols may differ from vendor to vendor. If the same transactional program
210
was later to be used in conjunction with another transaction support product, the program would have to be modified to comply with the next vendor's protocols. No standardization efforts have arisen to address these dissimilarities.
As in the case of a database management system
102
(FIG.
1
), a transactional processing system
202
is intended for use with a client data processing system
207
that includes a remote computer
100
and a stored ODBC invocation program
201
. Transactional processing system
202
also includes one or more stored client transactional programs
203
. However, note that client data processing system
207
includes a display device
105
. This is intended to illustrate the point that transactional processing systems are designed with the assumption that the consumer of is a human working at an online terminal, not another computer program. Some transactional processing systems, however, also offer interfaces which present their data in a manner suitable for further processing by another computer program. It is frequently the case that transaction processing systems access database systems (such as the system of
FIG. 1
) in order to store and retrieve data keyed in by human users. However, although a program in a transactional processing system will usually access databases through interfaces conformant to the ODBC and SQL standards, the manner in which the data is presented to the client data processing system
207
by the transactional processing system
202
generally does not conform to any vendor-neutral standard (as already stated above). Additionally, if a transactional processing system is accessing data not stored in a database system (FIG.
1
), there are no standards that apply to such access.
The most widely used transaction processing system in the world today is a product of IBM, called CICS. CICS was introduced in the late 1960s, and has grown steadily in usage around the world. IBM can claim that nearly a billion transactions per day are processed through CICS systems. CICS is a registered trademark of IBM.
A number of existing systems are now offered to help support the communication with legacy programs by applying industry standard protocols. For example, Neon Systems, Inc., based in Sugarland, Texas has offered a product line of sophisticated middleware programs designed to facilitate communication to legacy programs. These products are discussed in the product brochure titled “ShadowDirect®” and the product description titled “An Introduction to Shadow Direct”, both incorporated by reference as if restated in full.
The Neon System products fill an important need in the Industr
Hills Theodore S.
Saxton Gregory M.
Le Uyen
Merrill Lynch & Co. Inc.
Metjahic Safet
Morgan Lewis & Bockius
LandOfFree
System for invocation of CICS programs as database stored... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with System for invocation of CICS programs as database stored..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and System for invocation of CICS programs as database stored... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2995419