 |
Claims  |
|
|
We claim:
1. In a multitask electronic data processing shstem having means for
receiving from a remote data base of different types in response to
nonmonitoring requests for data and specific monitoring requests for data,
the specific monitoring requests requiring the remote data base to monitor
data base sources with respect to specific identifiers, a method performed
by the electronic data processing system for distributing the data to
plural user tasks subscribing to the data comprising:
in a first provider task dividing a data stream of plural data types from
the remote data base into plural data streams according to the data types;
transferring from the first provider task at least one selected data stream
in response to nonmonitoring requests directly to user tasks subscribing
to the data streams and transferring at least one selected data stream in
response to specific monitoring requests to at least a second provider
task; and
in a second provider task, dividing the data stream in response to specific
monitoring requests into further data streams and transferring the further
data streams to user tasks requesting the data streams.
2. A method as claimed in claim 1 further comprising the step of decoding
the data a stream in the second provider task.
3. A method as claimed in claim 1 further comprising, before transferring
data to user tasks and by means of a common code module linked to each
user task, the step of establishing data transfer paths between the
provider tasks and the user tasks, each data transfer path being specific
to a type of data transferred to a single user task.
4. A method as claimed in claim 3 further comprising, by means of a wait
list established in an operating system, the step of monitoring provider
task mailboxes with respect to each type of data to identify request from
user tasks and of monitoring user task mailboxes with respect to each type
of data to identify data being transferred to the user tasks.
5. A method as claimed in claim 4 further comprising, in establishing data
paths, the step of generating a configuration list for each of the
provider tasks and the user tasks from a configuration file, each
configuration list including the name of a provider task mailbox to which
requests for data of each type are to be transferred and an indication of
whether the task has access to a particular type of data.
6. A method as claimed in claim 3 further comprising the step of generating
in at least the first provider task, a subscribers list for identifying,
relative to each type of data, the tasks which are to receive that type of
data.
7. A method as claimed in claim 1 further comprising, by means of a wait
list established in an operating system, the step of monitoring provider
task mailboxes with respect to each type of data to identify requests from
user tasks and of monitoring user task mailboxes with respect to each type
of data to identify data being transferred to the user tasks.
8. A method as claimed in claim 1 further comprising establishing data
transfer paths between the provider tasks and the user tasks, each data
transfer path being specific to a type of data transferred to a single
user task.
9. A method as claimed in claim 8 further comprising, in establishing data
paths, the step of generating a configuration list for each of the
provider tasks and the user tasks from a configuration file, each
configuration list including the name of a provider task mailbox to which
requests for data of each type are to be transferred and an indication of
whether the task has access to a particular type of data.
10. A method as claimed in claim 1 wherein the second provider task
receives specific data requests from the user tasks and compiles
information correlating user tasks with specific data requests, the data
being compiled by generating a user tree and a data-type tree, each user
node of the user tree pointing to a list of data types requested by that
user and each node of the data-type tree pointing to the users which have
requested that type of data.
11. A method as claimed in claim 1 wherein the data comprises stock market
information.
12. A method as claimed in claim 11 further comprising transferring stock
quotation requests from the user tasks to the first provider task,
providing each such request with a sequence number in the first provider
task and transferring the request to the remote data base, the first
provider task maintaining a record of users requesting the data with
respect to sequence numbers and, by means of sequence numbers returned
with the data, confirming receipt of data responses to the requests and
forwarding the received data to the users which made the quotation
requests.
13. In a multitask electronic data processing system having means for
receiving from a remote data base data of different types, a method of
distributing the data from a provider task to plural user tasks
subscribing t the data, the method performed by the electronic data
processing system comprising:
by means of a common code module linked to each user task, establishing
data paths between the provider task and the user tasks, each data path
being specific to a type of data transferred to a single user; and
by means of the provider task, dividing a data stream from the remote data
base into plural data streams according to the data type and transferring
the plural data steams to the user tasks through the established data
paths.
14. A method as claimed in claim 13 further comprising the step of
monitoring, by means of a wait list established through the common code
module in an operating system, a user task mailbox with respect to each
type of data to notify the user task of data being transferred to the user
task.
15. A method as claimed in claim 14 further comprising, in establishing
data paths, the step of generating a configuration list for each user task
from a configuration file, each configuration list including the name of a
provider task mailbox to which requests for data of each type are to be
transferred and an indication of whether the task has access to a
particular type of data.
16. A method as claimed in claim 15 wherein each configuration list
indicates whether the task is a provider of data to other tasks, the
method further comprising the step of limiting provider specific routines
of the common code module to provider tasks.
17. A method as claimed in claim 15 further comprising the step of
monitoring, by means of a wait list established through the common code
module in an operating system, a mailbox to a provider task with respect
to each type of data to notify the provider task of data being transferred
to the provider task.
18. A method as claimed in claim 17 further comprising the step of
generating a configuration list for each provider task from a
configuration file, each configuration list including the name of a
provider task mailbox to which requests for data of each type are to be
transferred.
19. A method as claimed in claim 17 further comprising the step of
generating in at least the provider task, a subscribers list for
identifying, relative to each type of data, the tasks which are to receive
that type of data.
20. A method as claimed in Claim 14 further comprising the step of
monitoring, by means of a wait list established through the common code
module in an operating system, a mailbox to a provider task with respect
to each type of data to notify the provider task of data being transferred
to the provider task.
21. A method as claimed in claim 13 further comprising the step of
generating in the provider task, a subscribers list for identifying,
relative to each type of data, the tasks which are to receive that type of
data.
22. A method as claimed in claim 13, further comprising, in establishing
data paths, the step of generating a configuration list for each user task
from a configuration file, each configuration list including the name of a
provider task mailbox to which requests for data of each type are to be
transferred and an indication of whether the task has access to a
particular type of data.
23. A method as claimed in claim 13 wherein the data comprises stock market
information.
24. In a multitask electronic data processing system having means or
receiving from a remote data base data of different types, a method of
distributing the data from a provider task to plural user tasks
subscribing to the data, the method performed by the electronic data
processing system comprising:
in response to calls from the user tasks, establishing data paths between
the provider task and the user tasks, each data path being specific to a
type of data transferred to a single user; and
by means of the provider task, dividing a data stream from the remote data
base into plural data streams according to the data type and transferring
the plural data streams to the user tasks through the established data
paths.
25. A method as claimed in claim 24 further comprising in establishing data
paths, the step of generating a configuration list for each of the
provider tasks and the user tasks from a configuration file, each
configuration list including the name of a provider task mailbox to which
requests for data of each type are to be transferred and an indication of
whether the task has access to a particular type of data.
26. A method as claimed in claim 25 further comprising the step of
monitoring, by means of a wait list established in an operating system,
mailboxes with respect to each type of data to the provider tasks to
identify requests from user tasks and to user tasks to identify data being
transferred to the user tasks.
27. A method as claimed in claim 24 further comprising, by means of a wait
list established in an operating system, the step of monitoring provider
task mailboxes with respect to each type of data to identify requests from
user tasks and of monitoring user task mailboxes with respect to each type
of data of identify data being transferred to the user tasks.
28. A method as claimed in claim 24 wherein the data comprises stock market
information.
29. In a multitask electronic data processing system having means for
receiving from a remote data base data, a method performed by the
electronic data processing system of distributing the data to plural user
tasks comprising in a provider task:
receiving specific data requests from the user task and compiling
information correlating user tasks with specific data requests;
for each data request, determining whether a like request is pending for
another task;
only if a like request is not pending, transferring to the remote data base
the specific data request;
receiving specific data from the remote data base;
determining from the compiled information all user tasks which have
requested the received specific data; and
transferring the specific data to user tasks which have requested the data.
30. A method as claimed in claim 29 wherein the information is compiled by
generating a user tree and a symbol tree, each user node of the user tree
pointing to a list of symbols identifying data requested by that user and
each node of the symbol tree pointing to the users which have requested
the data represented by the symbol.
31. A method as claimed in claim 30 wherein each node of the user tree
includes a listing of services to which that user has subscribed.
32. A method as claimed in claim 30 wherein each node of the symbol tree
includes a listing of services through which users have made requests for
the data identified by the symbol.
33. A method as claimed in claim 29 wherein the data comprises stock market
information.
34. In a multitask electronic processing system having means for receiving
data of different types, a method of distributing the data from provider
tasks to plural user tasks subscribing to the data, the method performed
by the electronic data processing system comprising:
by means of a common code module linked to each user task, establishing
data paths between the provider tasks and the user tasks, each data path
being specific to a type of data being transferred to a single user, the
data paths being established by each user task using a configuration list
for each user task, each configuration list including the name of a
provider task mailbox to which requests for data of each type are to be
transferred and an indication of whether the task has access to a
particular type of data;
by means of a wait list established in an operating system, monitoring
provider task mailboxes with respect to each type of data to identify
requests from user tast and monitoring user tasks mailboxes with respect
to each type of data to identify data being transferred to the user tasks;
receiving in a monitor provider task specific data requests from the user
tasks and compiling information corelating user tasks with specific data
requests, determining whether a like request is pending for another task,
and only if a like request is not pending transferring through a primary
provider task to the remote data base the specific data request;
in the primary provider task, dividing a data stream of plural data types
from the remote data base into plural data streams according to the data
types;
transferring selected data streams in response to nonmonitoring requests
directly to user tasks subscribing to the data streams and transferring at
least one selected data stream in response to specific monitoring requests
to the monitor provider task; and
in the monitor provider task, dividing the data stream in response to
specific monitoring requests into further data streams and transferring
the further data streams to user tasks requesting the data streams.
35. A method as claimed in claim 34 wherein the data comprises stock market
information.
36. A method as claimed in claim 13 wherein the data paths are established
by routines of the common code module based on system configuration
information available to the common code module routine, the routine being
called by a user task without regard for the provider task architecture.
37. A method as claimed in claim 36 wherein the configuration information
is available through a configuration list which includes the name of a
provider task mailbox to which requests for data of each type are to be
transferred and an indication of whether the task has access to a
particular type of data.
38. A method as claimed in claim 14 further comprising the step of
including in the wait list events specified by the user other than data
transfers from a provider task.
39. A method as claimed in claim 13 wherein data streams of a first type
are transferred to specific user tasks depending on the content of the
data streams, and data streams of a second type are transferred to all
user tasks from a list of user tasks. |
|
 |
|
 |
Claims |
|
|
|
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 subscribers 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. Also, 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.
Subscribers 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 subscriber 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 communications 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
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
provider 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 system waits for multiple events
simultaneously 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 subscriber 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 for
providing monitoring services 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 embodiment of the invention, as illustrated in the accompanying
drawings.
FIG. 1 is a block 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 the message format of messages transferred by means of API.
FIGS. 6A and the data structure of a symbol tree in the monitor provider 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 is
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. 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 (sl) 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 o 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
tasks.
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 user 2. Each task
which communicates through the API code module establishes a configuration
list and a wait through API routines. In addition, each provider task may
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 through the API code module, the provider
program need not continue to 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 through API
routines. 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 serive, a user looks to its configuration list in an API
routine to obtain a provider mailbox address. Through the routine, 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 subscription 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
| | |
