SYSTEM FOR BATCH SCHEDULING OF
TRAVEL-RELATED TRANSACTIONS AND
BATCH TASKS DISTRIBUTION BY
PARTITIONING BATCH TASKS AMONG
This application is a continuation of application Ser. No. 08/172.046 filed Dec. 22, 1983 (now abandoned).
The present invention relates generally to a data management method and architecture. In particular the present invention relates to a data management method and architecture allowing user-absent execution of scheduled batch tasks and administration of accounting information in environments that typically involve multiple users requiring access to centrally stored data such as the travel industry.
BACKGROUD OF THE INVENTION
The growth of the airline business from the early 1980's to the 1990's has resulted in the proliferation of travel agencies and other travel information groups that require access to large volumes of data in a "real time" environment. This growth has spurred many technological advancements in central reservation systems (CRS) for the transportation industry and in particular the airline industry. Examples of such systems are the American Airlines Lie's SABRE system. System One, Covia and Worldspan.
As the number of travel agencies and other travel providers has grown, the importance of automating their business practices such as accounting and report generation has also increased. Innovations for the back-office business side of travel providers have grown from calculators, adding machines and manual file systems to very sophisticated accounting software packages which are commonly available in the market place today.
Until the present invention, however, there has not been a successful integration of the a "real time" central reservation system with the modern travel provider back-office accounting and reporting packages taking full advantage of distributed personal computer processing capabilities. For example, the central reservation systems have gone from a relatively small number of mainframe computers to vast multiplexed systems not specifically designed for a given backoffice environment. Furthermore, in the past the mainframe computers were almost always connected to "dumb" terminals, i.e. terminals having no independent processing power and incapable of handling any of the accounting and reporting processing.
Beginning in the mid-1980's, the Personal Computer (PC) began replacing the "dumb" terminals, thus making the processing power of the PC available to the travel provider. Until the present invention, however, a method and architecture that could take advantage of the newly available processing power was not available. Most previously developed methods and architectures depended on "dumb" terminals where all the processing takes place in a single computer such as mainframe or minicomputer. The few previous methods and architectures that allowed users to install PC's utilized "dumb" terminal emulation packages to force the PC's to function as "dumb" terminals, again failing to use the available processing power of the PC. Thus, prior methods and architectures did not allow the user to fully utilize the available PC processing power.
Past and present methods and architectures also did not allow the user to realize the full benefits of using PC based
applications that access a database, such as a CRS, directly. Instead, prior art products provided some ability to execute a PC "hand-off" function where the user switches between using the "dumb" terminal emulation package to commu5 nicate with the CRS and the PC to perform accounting and reporting functions. Should the user require an integration of the CRS communication with the accounting and reporting functions, however, then an intermediate step is required. Personal productivity and efficiency are much less because intermediate steps must be performed.
While back-office systems for the travel provider have existed for several years, including Agency Data Systems' ADS product; Systems One's Max; World Span's World Ledger 4000 and Travel Data Systems' TDS; each of these systems was implemented on an IBM proprietary AS/400 architecture. Therefore, none of the prior art back-office accounting and reporting systems are easily ported to other architectures or used in connection with other vendor's hardware products. In addition, the travel providers have to depend on the developer of each architecture to do the necessary programming to port existing back-office accounting and reporting systems to new architectures as they are developed.
The present invention, however, provides an integrated
2J "real-time" CRS to back-office system that works on any industry supported architecture and is independent of the particular hardware system used. Thus, the present invention allows travel providers to install various hardware devices not offered by the original architectural vendor. Examples of
30 these hardware devices include printers, workstations. DOS based platforms. DOS based network file servers, and similar devices. The openness and flexibility of the present invention permits travel providers to largely solve their own day-to-day operational and information management needs
35 with minimal dependence for additional programming from the original architectural vendor.
Unlike the prior art methods and architectures, the present invention provides a method and architecture that can distribute reporting functions among available processing
40 resources in a network environment though a batch scheduling system. This provides maximum flexibility to the end user, as each user can now allocate computing power to a given reporting task. Furthermore, the user can designate the most appropriate platform to accomplish a specific reporting
45 task. This feature allows a user who works in a mixed platform environment to maximize the efficiency of each individual platform by allocating it to a suitable task.
Moreover, the batch scheduling system of the present invention enables a high on-line throughput of transactions
50 achieved through a client server system architecture. The client server architecture can operate when application functions are separated logically, and indeed, sometimes physically from the database management functions. Thus, a user can work with a client (the frontend) on his workstation and
55 use resources of the server (the back-end) only when data needs to be accessed. Thus, regardless of the platform on which the database is run, e.g.. UNIX, OS/2. Novell Netware, the same client applications can be accessed without any changes.
60 Furthermore, in the present invention either the client or server can be changed independently of the other. For example, one database can be moved from a vendor's UNIX system to another, or to an emerging environment like Microsoft Windows NT, with no additional programming
65 required for the client applications.
The present invention also provides the ability to process multiple tasks simultaneously not only on the database