 |
Description  |
|
|
BACKGROUND OF THE INVENTION
Local computers are able to gain access to large volumes of information by
communicating over telephone lines with remote data bases. The remote data
base has storage capabilities which far exceed that which would be
feasible at most local computers and can serve as a central storehouse of
information.
A data base that was developed by the Walsh, Greenwood Information Systems,
Inc. and which is now maintained by Wang Financial Information Services
Corporation is dedicated to information relating to the stock market and
other financial institutions. It contains real time trade and quote
information including over-the-counter, option, commodity, futures, and
fixed income data, as well as news and institutional holdings. The data
base allows a subscribing computer to have access to three general classes
of service: broadcast, inquiry and monitoring.
The broadcast class is that in which information is simply broadcast
continuously to the user. An example is the New York Stock Exchange ticker
service in which all transactions which occur on the New York Stock
Exchange are transmitted to all subscibers as those transactions occur.
Other broadcast services include a news headlines service which scrolls
through headlines received from the Dow Jones News Service and the Reuters
News Service. Finally, the full news items from the Dow Jones News Service
and the Reuters New Service are transmitted to subscribers to allow for
scrolling through the news items as they are released.
Subcribers to the data base are also able to make specific inquiries. For
example, a subscriber may send a request for a quotation on any stock item
and promptly receive the current information stored at the data base for
that stock item. News items of interest may also be retrieved by making
requests which include specific identifier symbols which identify the
information of interest.
Finally, a subcriber may request that the remote data base monitor all of
the information which enters the data base and transmit only that data
which is of particular interest to the subscriber. Again, the subscriber
transmits a request to the data base which includes identifier symbols.
The Walsh Greenwood Information Systems system was designed for
communication with personal computers; hence for each line address there
has been exactly one user. Each personal computer could subscribe to a
particular set of services and pay the appropriate fee for those services.
Configuration and security were handled by the network host processor
sending a message to each computer on each line to indicate which services
the network would allow that computer to use. This provided adequate
control to permit accurate billing and accounting.
DISCLOSURE OF THE INVENTION
Multiple user systems may have multiple terminals connected through a
central computer and a single communication line to the data base host
computer. Different users in this local system may subscribe to different
services. In that situation, the remote data base must maintain accurate
subscription files for each of the terminals. Further, the remote data
base must transmit data to all subscribing terminals along a single
communications line and rely on the local multiuser system to properly
distribute the data to those terminals which have subscribed and which
have made specific inquiries. It is to such a multiuser system that the
present invention is directed.
To properly distribute incoming data to multiple users, the local multiuser
system must maintain subscription records and records of specific requests
and must multiplex the incoming data to the individual users. This
significant task must be performed without introducing unacceptable delays
in transfer of the information from the remote data base to the individual
users. The avoidance of delays is particularly critical in the case of
stock market information. To provide for this rapid distribution of
information, one feature of the present invention is in the handling of
different classes of information. Tracking of specific monitoring requests
from multiple users can become cumbersome. In accordance with one feature
of the present invention, a first provider task divides the incoming data
stream from the remote data base into plural data streams according to the
data type corresponding to each service. Selected data streams which are
in response to nonmonitoring requests are transferred directly to user
tasks subscribing to the data streams. A data stream which is in response
to a specific monitoring request is, however, transferred to a second
provider task. That second provider task then divides the data stream in
response to the specific monitoring requests into further data streams and
transfers the further data streams to the user tasks. Thus, data which is
simply broadcast to the user or which is the result of a specific inquiry
need not be delayed by a task which must also handle the more
time-consuming distribution of data in response to monitoring requests.
The second provider task may also provide the decoding necessary for a
particular class of data.
Specific inquiries such as news retrievals may be handled by yet another
task. Although that class of data does not require the extensive
processing of data based on monitoring requests, the data may require
sufficient additional processing to warrant a separate task. However, it
is preferred that quotation inquiries be handled by the first provider
task. Users are typically concerned with obtaining very rapid responses to
quotation inquiries and handling of such inquires by the first provider
task is not too burdensome.
Information received from data bases must typically be displayed in a
particular format established by the remote data base or by local software
provided to all subscribers. Access to the received data by programs
developed by the user has typically been limited and, where available,
access has required particular programming expertise and effort. Such
access has not been available on a real time basis. A further feature of
the present invention is that data paths between the provider task and the
user task are established by means of a common code module which is linked
to each user task. Each data path is specific to a type of data
transferred to a single user. The common code module simplifies access to
the different data types to which the user has subscribed and also
insulates the user program from changes in the operating system of the
multitask system. Any programming changes required by changes in the
operating system can be handled for all programs by modifying the common
code module. By establishing a distinct data path for each type of data
transferred to each user, local subscriptions can be readily entered and
terminated for specific services and the user program can at any point
limit its access to a particular service. Thus, the internal message
traffic can be minimized.
The time during which a user program must be active while waiting for data
from the data base can be minimized by establishing a wait list which is
monitored by the operating system. The wait list includes a mailbox
address for each type of data for each user task. Through that mailbox,
the operating system notifies the user task of data being transferred to
the task. The operating system speeds the distribution of data because it
is not necessary for each program to independently cycle through wait
routines. Rather, the operating sytem waits for multiple events
simulataneously and then deals with whichever one occurs first. Such
capabilities are not generally available to programmers writing in higher
level languages and are made available in the present system by the common
code module.
In establishing the data paths between providers and subscribers, a
configuration list may be established for each user task from a
configuration file. Each configuration list includes the name of a
provider task mailbox to which requests for each type of data are to be
transferred and an indication of whether the task has access to a
particular type of data. Each configuration list may also indicate whether
the task is a provider of data to other tasks. Provider specific routines
of the common code module are limited to provider tasks.
The common code module may also be used to establish wait lists for
provider tasks. A provider task need not repeatedly check whether requests
are being made from user tasks but the operating system may simply monitor
the provider task mailbox for each service. A configuration list would
also be generated for each provider task so that the provider task would
be able to identify each mailbox relative to each service. To facilitate
distribution of data to subscribers, each provider may establish a
subcriber list relative to each service to identify those users which have
established data paths with respect to each service.
Preferably, during system start up, the first provider task is responsible
for providing all other tasks in the system with the information included
in the configuration list. Only the first provider task has access to
configuration files which include the customer access information received
from the remote data base.
A provider task such as the above mentioned second provider task should
avoid making identical requests for data from the remote data base due to
independent requests from different users. To that end, the provider task
may receive specific data requests from user tasks and compile information
correlating user tasks with specific data requests. For each data request,
the provider determines whether a like request is pending for another
task. Only if a like request is not pending would a specific data request
be transferred to the remote data base. When the data is subsequently
received from the remote data base, the provider determines from the
compiled information all user tasks which have requested the received
data, and the data is transferred to those user tasks. Preferably, the
information is compiled by generating a user tree and a symbol tree. Each
user node of the user tree points to a list of symbols identifying the
data requested by that user. Each node of the symbol tree points to the
users which have requested the data represented by the symbol.
BRIEF DESCRIPTION OF THE DRAWINGS
The foregoing and other objects, features and advantages of the invention
will be apparent from the following more particular description of a
preferred embodiments of the invention, as illustrated in the accompanying
drawings.
FIG. 1 is a diagram of the software architecture of a system embodying the
present invention.
FIG. 2 is an illustration of the configuration list, wait list and
subscriber lists stored in a provider task memory by means of an
application program interface (API) common code module in the system of
FIG. 1.
FIG. 3 is an illustration of the configuration list and wait list stored in
a user task memory by means of the API.
FIG. 4 illustrates a configuration file retrieved by the primary provider
task through API.
FIGS. 5A and 5B illustrate the message format of messages transferred by
means of API.
FIGS. 6A and 6B illustrates the data structure of a symbol tree in the
monitor provided of FIG. 1.
FIGS. 7A and 7B illustrate the data structure of a user tree in the monitor
provider.
FIG. 8 illustrates an add pending queue in the monitor provider.
DESCRIPTION OF A PREFERRED EMBODIMENT
The present invention relates to a multitask, multiuser data processing
system and may, for example, be implemented on a VS system from Wang
Laboratories, Inc. In FIG. 1, the block 20 represents the overall
operating system of the multitask system. Overlayed on the operating
system are a number of distinct programs which share the operating system
to independently complete their respective tasks. For example, three user
programs 22, 24 and 26 are illustrated. Each user program is associated
with a respective computer terminal 28, 30 or 32. Within each user
program, the multitask, multiuser character of the system is invisible to
the user; however, for intertask communications, specific procedures must
be followed to establish data paths through the operating system.
The present invention relates to the transfer of requests to and the return
of data from a remote data base host computer 34. The host computer
gathers real time trade and quotation information over many data lines
which link the host to all exchanges and several supplemental services
such as Dow Jones and Spectrum Institutional Holdings. This information
includes real time stock exchange, over the counter, option, commodity and
fixed income data, as well as news and institutional holdings.
All communications between the remote data base 34 and the user programs
22, 24 and 26 are processed through a primary provider task 36. This task
provides the data to the subcribing users. The primary provider 36
includes conventional communications software for transferring and
receiving data along telephone lines. The primary provider 36 must also
make an initial determination as to what type of data is being received.
Specifically, the primary provider determines the particular data service
of which the data is a part.
The primary provider makes an initial distribution of the data. Most data
of the broadcast class, all of which is transmitted to all subscribers of
the service, is transferred directly from the primary provider to the
individual subcribing users. This class of services includes the Dow Jones
New Service (dj), the New York Stock Exchange Ticker (tk), News Headlines
(nh) and Reuters New Service (rt). An example of the transfer paths for
data from these broadcast services to user programs 24 and 26 are
illustrated in FIG. 1. These transfer paths are illustrated as being in
only one direction because, once the data path as been established, no
further requests from the user program to the remote data base are
required. Other data services require more complex logic on the part of
the provider. To prevent the primary provider from becoming over-burdened
with distribution of data from those services, additional tasks 38 and 40
are provided.
In the present example, much of the data from the inquiry class of services
is transferred by the primary provider to an inquiry provider 38. For
example, with the Dow Jones New Retrieval Service (nr) the remote data
base responds to specific inquiries for news items relating to particular
identifiers transmitted to the data base by a user. The inquiry provider
38 initially receives those requests from the user programs, determines
whether a similar request is already pending, and if no similar request is
pending transfers the request through the primary provider to the remote
data base 34. All data transferred back from that service is directed by
the primary provider 36 to the inquiry provider 38. The inquiry provider
then examines its own records to identify the user program which made the
request and transfers the responsive data to just that user program. In
the example illustrated in FIG. 1, only user program 22 has subcribed to
the Dow Jones News Retrieval Service, but the utility of the inquiry
provider increases with increased subscriptions from other user programs
and with an increased number of services of the inquiry class.
A final class of service is that in which the host computer monitors data
based on a specific request for information identified by identifier
symbols. The remote data base monitors all data as it is received from its
sources and selects that data for which a request is pending. The data is
then transferred to the requesting user. Thus, the monitor class of
services keeps an inquiry open as data continues to be received. The
monitor provider receives requests from the user programs and, as did the
inquiry provider, only forwards requests to the remote data base which are
not already pending. The remote data base, for the most part, sees the
multiuser system as a single user and only transmits a particular item of
data once to the multiuser system. When that data is received it is
directed to the monitor provider. The monitor provider searches its
records to determine which user program or programs requested the data and
transfers the data to those user programs.
Market monitor data is encoded in a compressed format. The primary provider
determines only that the data being received is of the market monitoring
format and transfers all of that data (MM) in coded format to the monitor
provider 40. The monitor provider then decodes the data and directs it to
the requesting user programs as one or more of three services. The basic
market monitoring service (mm) responds to each price change in that
particular stock. A select ticker service (s1) responds to each trade of
the stock and identifies the volume and price of that trade. The block
trade ticker (bt) identifies all trades which exceed ten thousand shares.
Block trade is actually a broadcast class of service but it is encoded by
the host computer with the market monitor service, so it is most
efficiently decoded by the monitor provider. Further, it is expected that
block trading in the future will be a more selective service. As
illustrated in FIG. 1, although all three services rely on the same data
stream received from the remote data base, user programs may individually
subscribe to select ones of the three.
One service which is of the inquiry class but which is handled entirely by
the primary provider is that of stock price quotations (qt). Users expect
that price quotations will be received very promptly, and the present
system facilitates the prompt return of quotation data by minimizing the
number of transfers of the quotation requests and return data through the
operating system. The two transfers in each direction which result from
use of the inquiry provider is avoided. The primary provider transmits the
stock quote request with a sequence code which identifies the request in
the primary provider. The sequence code is stored with the identity of the
requesting user program in a first-in/first-out storage. The remote data
base returns the data in the same order in which it is requested and
returns the same sequence code with the data. The primary provider then
returns the data to the requesting user task as it is identified from the
first-in/first-out storage so long as the sequence numbers match. If a
sequence number is skipped in the return data, the primary provider is
able to either make the request again or notify the user program that the
request should be made again.
A basic user program might allow the user to make specific requests within
a service to which it subcribes and to suitably display the returned data.
However, it is contemplated that users will want to develop their own
programs which are particularly suited to their particular needs. In fact,
users may wish to develop programs which have as only a small part thereof
the need to obtain stock market information. A pension fund management
program might be an example of such a program. In the past, retrieval of
information from stock market services and other data bases has offered
little flexibility to the programmer and has made linking of custom
programs to the remote data base difficult or even impossible. The present
system facilitates such communications by means of an application program
interface (API) which facilitates the establishment of data transfer paths
between tasks by making full use of the operating system capabilities
while minimizing the programming effort required of the user program.
API is a code module of subroutines which may be linked to any one of the
user and provider tasks. Once the API code module has been linked to a
user program, the program need only make simple calls to the subroutines
to establish the data transfer paths. The user need not be aware of the
capabilities and requirements of the underlying operating system because
those capabilities and requirements have been taken into consideration in
development of the code module. Further, the user program is insulated
from changes in the operating system. The system designer will make
appropriate changes in the API code module with changes in the operating
system. Although the API code module offers its greatest advantages in
interfacing user programs to the operating system, it is also used to
interface the provider background tasks. With this approach, the system
designer, in making changes to the operating system, again need only
modify the API code module and need not modify the background provider
task.
A further advantage of the particular API code module to be described below
is that it makes full use of the intertask message (ITM) capabilities of
the Wang VS systems in creating mailboxes and transporting messages to
those mailboxes. In the Wang VS systems, a task is able to list ports, or
mailboxes, in an operating system plist and then "put itself to sleep". In
the present system, those plists are wait lists created by the API code
module. The operating system monitors the plist and, when a message is
received at a port on the plist, the operating system notifies the task
associated with that plist. As a result, the task program need not
continue to operate as the program waits for an event to occur. This
feature of the operating system is particularly useful to the provider
tasks in monitoring data requests from user programs and to user programs
in monitoring the receipt of data from the host computer. Such events may
occur at any time.
Intertask communications are handled efficiently by means of the API code
module by the establishment of three types of lists. FIGS. 2 and 3
illustrate example lists for the primary provider and user2. Each task
which communicates through the API code module establishes a configuration
list and a wait list. In addition, each provider task may establish a
subscriber list for each service that it provides.
Before establishing any data transfer paths, a provider or user task must
first obtain a configuration list through the primary provider. The
configuration list includes a service code for each available service. The
configuration list also indicates, for each service, whether the
particular task is a provider of that service (indicated by a P in the
list). If the task is not a provider the list indicates whether the task
has access to the service (indicated by Y for yes or an N for no). Each
task is also provided with an ITM port, or mailbox address, to which
messages requesting that service should be transferred.
Before a user can complete a request to a provider, the provider must have
retrieved its configuration list. Based on its access and provider mailbox
information provided in that list, the provider must have established
itself to receive requests for the particular service by listing the
mailbox at which it is to receive requests on its operating system wait
list. In FIG. 2, the active status indicated for each service in the wait
list indicates that the primary provider is ready to receive requests for
each service on the wait list. As already noted, the wait list is an
operating system plist in the Wang VS system architecture. Once the wait
list has been established, the provider program need not continue to
monitor its mailboxes for the respective services. Rather, this chore is
handled by the operating system by means of the wait list.
The provider may establish a subscriber list for each service and include
in its configuration list a pointer to the starting address of each
subscriber list (indicated by an * in FIG. 2).
The user also establishes its wait list in the operating system. The user
may establish its own user port for each service to which it has access.
That user port then serves as the mailbox for any data returned from a
provider. The wait list includes each of its mailboxes on which it expects
to receive data. Each mailbox on the wait list may be set at either an
active or an ignore status; the operating system will only notify a task
of transferred data to those mailboxes which are active.
To subscribe to a service, a user looks to its configuration list to obtain
a provider mailbox address. It then constructs a subscription message as
illustrated in FIG. 5B and transmits that message to the designated
provider mailbox. It may then wait to be notified by the operating system
through its user port that a message has been received. The message is
transferred by the operating system into the provider task mailbox and the
provider task is notified that a message has been received. The provider
then processes the subscription request and may place the user's return
mailbox and other data for that service in the provider's subscriber list
for that service. That other data includes the subscriber's workstation
number, user I.D. and key.
By defining in the configuration list a unique provider mailbox for each
service, the system allows each user program to independently establish
data paths for the several services to which it subscribes. Although the
host processor may include the particular user program as a customer and
thus grant access to data for a particular service, within the local
system any user may fail to subscribe or temporarily cancel any
subscription to any service at any time without affecting subscriptions to
other services. As a result, internal message traffic through the
operating system can be minimized. The host processor is not informed of
the user's status as a subscriber within the local system, so
subscriptions and cancellations within the system do not affect the
customer status of the user.
To provide for prompt access to the configuration information, a distinct
configuration list is generated for each task in the system. Each task is
able to efficiently obtain access to its list without requiring further
transfer of data from a configuration file through the operating system.
However, in a multitask system in which a global memory is readily
available to all tasks, the individual configuration lists may not be
required. Rather, the information may be obtained from a centralized file.
It is important, however, that each task have ready access to the provider
mailbox addresses designated by the system and to its own access
information with respect to each available service.
A more detailed description of the creation of the configuration, wait and
subscriber lists and the API subroutines which allow for the efficient
transfer of data follows.
As the initial receiver of all information from the remote data base, the
primary provider 36 has been selected as the focal program for
initialization of programs with respect to transfers from the remote data
base. As a part of the primary provider's initialization processing, it
makes a call to a configuration initialization API routine called CNFINIT.
CNFINIT reads a configuration file from disc storage. The primary provider
also starts the communication line. When the host computer 34 detects that
the line is active, it responds by sending out a services list for
customers as discussed below. The primary provider consolidates the
information received from the remote data base and from the disc storage
to create the configuration file of FIG. 4.
The first item of the configuration file is a key for each task to be
involved in the data transfer. In effect, the key is a logical name for a
configuration record for each task. The keys PRIPRO, INQPRO and MONPRO are
the names provided for the primary provider, inquiry provider and monitor
provider, respectively. A further key ADMIN allows for the implementation
of an administrative program if it is required for the particular needs of
a system. Such a program may control designation of keys and control
access to services by particular tasks and particular workstations.
The programs associated with the first four keys of the file are provider
programs which typically operate in background. An additional three keys
USER1, USER2 and USER3 are indicated for each of the three user programs
shown in FIG. 1. Of course, the system is not limited to three user
programs. These programs are typically subscribers and may or may not
operate in foreground.
The terminal I.D. field is the identifier by which the remote data base
knows each user on a system. The data base grants rights to particular
services and bills for those services in a per terminal identification.
Only user tasks need terminal I.D.'s since they are the only true
consumers of data. Suppliers may be thought of as merely an extension of
the remote data base and require no terminal I.D. The terminal I.D. also
serves as an alternate key; the remote data base is unaware of the first
key and sends its configuration records tagged by the terminal I.D. The
terminal I.D.s are assigned by the remote data base when a customer
requests new or expanded services.
The task number is forwarded to the primary provider with a key as each
task is initialized. The status field indicates whether a key is in use
and, if so, the work station number at which the associated task is being
used. The status field may indicate that a task is being operated in
background. The workstations fields may be used by an administrator
program to restrict the workstations on which a given key and its
corresponding privileges may be used. The key may be restricted from or to
a list of workstations which is simply illustrated by an asterisk in FIG.
4.
The services field is expanded in the lower portion of FIG. 4. This list of
fields defines, for each key, the associated program's role with respect
to each defined service. The program may have any of three roles in
connection with a given service: it may have full subscription privileges
(Y); it may be the provider of the service (P); or it may have no rights
at all for the service (N). The subscriber rights given by the remote data
base may be overruled by a local administrator program as indicated by y,
for subscription allowed, and n, for subscription denied. The roles of
providers are defined by the system designer.
During CFNINIT, primary provider 36 also obtains a provider mailbox file
from disc storage. The provider mailbox for each service is later included
in each configuration list of each task as illustrated in FIGS. 2 and 3.
Using the information from the provider mailbox file and the configuration
file, the primary provider builds a prototype of the configuration list to
be used by each task employing the API code module. The prototype
configuration list contains one record for each defined service, and each
record includes the mailbox, which is the ITM port name, of the provider
of the service.
With the configuration file and the prototype configuration list on hand,
the primary provider then generates its own personal configuration list by
calling SCLINIT. By providing its key PRIPRO, it obtains its configuration
list, based on the prototype list, with its access code P, Y or N taken
from the configuration file for each service. Where a P is indicated for a
service in the configuration list, the provider establishes as its mailbox
the provider mailbox indicated in the configuration list. The provider
also establishes a subscriber list for each such service and sets the
current list size to zero. Further, each mailbox established by the
provider program is placed by the API subroutine on an operating system
plist for that task which will serve as a wait list. The wait status for
each provider mailbox on the wait list is set to active. Finally, the
primary provider program calls an API routine SCLWAIT by which it signals
the operating system that it will wait for an indication that a message
has been received at any of its active mailboxes on the wait list.
With the initialization of the primary provider, other tasks may be
initialized. To that end, each task calls the API routine SCLINIT, whereby
it establishes an operating system wait list. As illustrated in FIG. 3, a
wait list may initially include three pseudoservices emergency (em),
workstation (ws) and timer (tm). The emergency port allows the task to
receive emergency messages at a high priority on the wait list. The
workstation service allows the user program to utilize the wait list
established by the API code module to wait for events which are to occur
at the workstation terminal. With this pseudoservice, the user program
need not delay receipt of data while waiting for an event such as a key
stroke to occur at the terminal. Finally, the timer pseudoservice allows
the program to set a timer by way of the wait list. Again, it allows the
user program to limit the time that it will wait for other events to
occur.
During the SCLINIT routine, the task also obtains its configuration list
which will provide it with the information required to subscribe to a
service in the system. It obtains that configuration list from the primary
provider task and, to that end, the API subroutine is provided with a
default miniconfiguration list by which every task is configured as a user
of configuration data. A user subscribes to the configuration data through
a mailbox cfcf to the primary provider.
When the configuration subscription message arrives at the mailbox cfcf of
the primary provider, the operating system awakens the primary provider in
the SCLWAIT routine. In response to the subscription message for
configuration data at its mailbox cfcf, the primary provider uses the user
key provided in the message to obtain the appropriate record in the
configuration file and mark a copy of the prototype configuration list
with the appropriate access code for each service for that key. The
primary provider returns the customized configuration list to the
subscribing mailbox, for example 20cf, and updates its master
configuration file to indicate that the particular key is in use.
Through individual use of the SCLINIT routine, each task may have a full
configuration list and a wait list which is empty but for the emergency,
workstation and timer pseudoservices. The data paths illustrated in FIG. 1
have not yet been established. To establish the paths, each provider task
calls a routine PRVOPEN, by which it establishes a subscriber list which
is initially empty. Both provider tasks, automatically during PRVOPEN, and
subscriber tasks call a routine SCLOPEN. By the routine SCLOPEN, a
provider task sets its mailbox for the service being opened to that
indicated in the configuration list, and a subscriber task sets the
mailbox to its task number plus the service code, as for example 20qt in
FIG. 3. Any future messages to be received by the particular task for that
service are received at the designated mailbox.
Some tasks may serve as a subscriber to some services and as a provider of
others. For example, the monitor provider serves as a subscriber to market
monitoring service MM and as a provider of market monitoring service mm,
select ticker service s1 and block trade service bt. Similarly, the
inquiry provid | | |
