Multitask subscription data retrieval system

Description: TECHNICAL FIELD [Detailed description of the invention]

【0001】

[Technical field to which the invention belongs]

The present invention relates to a method of distributing data from a provider task to a plurality of user tasks requesting the data in a multitasking data processing system having means for receiving various types of data.

【0002】

[Conventional technology]

A local computer can access a large amount of information by communicating with a remote database via a telephone line. A remote database has much more storage capacity than is possible on most local computers and can act as a central storage house for information.

【0003】

Developed by Walsh Greenwood Information Systems, Inc. and taken over by Wang Financial Information Services Corporation, the database is a stock market and other financial services. It is dedicated to information about the institution. This database contains real-time trading, over-the-counter quotes, options, commodities, quotes including future quotes, fixed income data as well as news and group holdings. This database allows reserved computers generally access to three types of services: broadcasting, querying and monitoring.

【0004】

In the case of broadcasting, the information is simply continuously broadcast to the user. One example is the New York Stock Exchange quote service, where all transactions made on the New York Stock Exchange are communicated to all bookers as they take place. Other broadcast services include news headline services that scroll through headlines received from Dow Jones News Service and Reuters News Service. It will also communicate all news items from Dow Jones News Services and Reuters News Services to subscribers, allowing them to scroll through the news items as the news is released.

【0005】

Also, database subscribers can make specific queries. For example, a subscriber can request a quote for one of the stocks and quickly receive the current information stored in the database for that stock. In addition, news items of interest can be searched by issuing a request containing a specific identifier symbol that identifies the information of interest.

【0006】

Finally, the subscriber can request that the remote database monitor all the information that goes into the database and send only the data that is of particular interest to the subscriber. Again, the subscriber propagates the request to the database containing the identification code.

【0007】

The Walsh Greenwood Information Systems system was configured for communication with personal computers. Therefore, there was exactly one user for each communication line address. Each computer may reserve a specific set of services and pay an appropriate fee for these services. Configuration and confidentiality were handled by the network's host processor, which sends a message to each computer on each line indicating which services the network allows for the computer to use. This provided sufficient control to allow accurate accounting and calculations.

【0008】

[Summary of Invention]

A multi-user system can have a large number of terminals connected via a central computer and a single line of communication to and from the host computer of the database. Various users in this local system can reserve various services. In that state, the remote database needs to keep accurate files for each terminal. In addition, a remote database is a local multi-user to transmit, reserve, and properly distribute data to all subscriber terminals along a single communication line. -It needs to depend on the system. It is such a multi-user system that the present invention is oriented towards.

【0009】

In order to properly distribute incoming data to a large number of users, the local multi-user system keeps reservation records and records of specific requests and multiplexes incoming data to individual users. There is a need. This important task needs to be accomplished without unacceptably delaying information from remote databases to individual users. Eliminating the delay is especially important in the case of stock market information. One feature of the present invention is to embed various kinds of information so that the information can be distributed quickly in this way. Tracking specific monitoring of requests from a large number of users can be tricky. According to one feature of the present invention, the task of the first provider divides the incoming data flow from the remote database into multiple data flows according to the data type corresponding to each service. The data stream selected in response to not monitoring the request is transmitted directly to the task of the user who reserves the data stream. However, certain monitoring requests are forwarded to a second provider task. The provider task then divides the data stream into another data stream in response to a particular monitoring request and transfers the other data stream to the user task. Thus, data that is simply broadcast to the user or that is the result of a particular query needs to be delayed by tasks that need to handle more time-consuming distribution of data in response to monitoring requests. Absent. The second provider task can also perform the necessary decryption for a particular class of data.

【0010】

Certain queries, such as news searches, can be processed by yet another provider task. The classes of data do not require extensive data embedding based on monitoring requests, but the data may require sufficient additional embedding to guarantee individual tasks. However, quote queries are preferably handled by the first provider task. Users are typically interested in responding to market inquiries with a very rapid response, and handling the inquiries by the first provider task is less cumbersome.

【0011】

The information received from the database needs to be typically displayed in a particular format created by a remote database or by local software provided to all subscribers. Access to data received by user-developed programs is typically limited, and access, where available, has required specific programming techniques and efforts. No such access was available on a real-time basis. Another feature of the present invention is that the data path between the provider task and the user task is set by a common code module connected to each user task. Each data path is specific to the type of data that is transferred to a single user. A common code module simplifies access to various user-reserved data types and shields user programs from fluctuations in the operating system of multitasking systems. Any programming variation that requires variation in the operating system can be handled for all programs by modifying a common code module. By setting a clear data path for each type of data transferred to each user, local reservations can be easily entered and stopped for a particular service, and the user program can either Access to specific services can be restricted in terms of points. In this way, the amount of internal message communication can be minimized.

【0012】

The amount of time a user program needs to be used while waiting for data from the database can be minimized by setting a wait list monitored by the operating system. The wait list contains mailbox addresses for each type of data for each user's task. Through the mailbox, the operating system notifies the user task of the data being transferred to the task. The operating system speeds up data distribution because each program does not have to cycle independently through wait routines. Rather, the operating system waits for many events at the same time, then fills in whatever happens first. The above features are generally not available to programmers writing in higher level languages and are made available by common code modules in the systems of the invention.

【0013】

When setting up a data path between a provider and a subscriber, you can set up a configuration list for each user task from the configuration file. Each configuration list contains the name of the provider task mailbox to which requests for each type of data are forwarded and instructions as to whether the task has access to a particular type of data. Each configuration list also indicates whether the task is a provider of data to other tasks. Certain routines of providers in the common code module are restricted to provider tasks.

【0014】

You can also use a common code module to set up a wait list for provider tasks. The provider task does not have to repeatedly check to see if the request is being made from the user task, but the operating system simply monitors the provider's task mailbox for each service. It also creates a configuration list for each provider task so that the provider task can identify each mailbox for each service. To facilitate the distribution of data to subscribers, each provider can set up a subscriber list for each service and identify the user who generated the data path for each service.

【0015】

It is preferred that during system startup, the task of the first provider also provides the information contained in the configuration list to all other tasks of the system. Only the task of the first provider accesses the configuration file that contains the customer's access information received from the remote database.

【0016】

For example, a provider task, such as the second provider task mentioned above, which provides a monitoring service, prevents the same request for data from a remote database due to independent requests from different users. Should be. To this end, the provider task receives a specific data request from the user task, and for each data request that compiles information that correlates the user task with the specific data request, the provider has a separate task. Detects whether a similar request is pending for. Certain data requests are forwarded to the remote database only if similar requests are not pending. Then, when the data is received from the remote database, the provider detects from the compiled information all the user tasks that requested the received data and the data is transferred to these user tasks. The information is preferably compiled by generating a user tree and a symbol tree. Each user node in the user tree is directed to a list of symbols that identify the data requested by that user. Each node in the symbol tree points to the user who requested the data displayed by the symbol.

【0017】

The aforementioned and other objects, features and advantages of the present invention will become apparent from the following detailed description of preferred embodiments of the invention shown in the accompanying drawings.

【0018】

BEST MODE FOR CARRYING OUT THE INVENTION

The present invention relates to a multitasking, multiuser data embedding system and can be implemented, for example, on a VS system manufactured by Wang Laboratories, Inc. In Figure 1, block 20 shows the entire operating system of a multitasking system. The operating system is provided with a number of well-defined programs that share the operating system to complete each task independently. For example, three user programs 22, 24, 26 are shown. Each user program is associated with its own computer terminal 28, 50 or 52. Inside each user program, the multitasking, multiuser characteristic of this system is invisible to the user. However, for communication between tasks, certain steps need to be followed to set the data path through the operating system.

【0019】

The present invention relates to the transfer of a request to a remote database host computer 54 and the recovery of data from that computer. The host computer is real-time on a number of data lines that connect the host to all stock trading and several ancillary services, such as Dow Jones and Spectrum Institutional Holdings. Collect trading and market information. This information includes real-time stock trading, over-the-counter, options, commodity trading and fixed income data as well as news and group holdings.

【0020】

All communication between the remote database 34 and the user programs 22, 24 and 26 is buried via the primary provider task 36. This task provides the data to the reserved user. The primary provider 56 includes conventional communication software that sends and receives data along the telephone line. The primary provider 56 also needs to make the first detection of what type of data is being received. Specifically, the primary provider detects a particular data service to which the data is part.

【0021】

The primary provider makes the initial distribution of the data. Most of the broadcast class data, all of which is transmitted to all subscribers of the service, is transmitted directly from the primary provider to individual subscriber users. Services in this class include Dow Jones New Services (dj), New York Stock Exchange Quotes (tk), News Headlines (nh) and Reuters New Services (rt). FIG. 1 shows an example of a data transfer path from these broadcast services to the user programs 24 and 26. These forwarding paths are shown as one-way only, as no further requests from the user program to the remote database are required once the data path is set. Other data services require more complex logic on the provider side. Additional tasks 38 and 40 are provided to prevent the primary provider from being overloaded by the distribution of data from said services.

【0022】

In this example, a copy of the data from the query class service is transferred by the primary provider to the query provider 38. For example, in Dow Jones' new search service (m), the remote database responds to specific queries for news items about specific identifiers transmitted to the database by users. The query provider 58 first receives these requests from the user program, detects if similar requests are already pending, and if no similar requests are pending, makes the requests through the primary provider. Transfer to a remote database. All transferred data from the service is directed by the primary provider 56 to the query provider 58. The query provider then examines its own record to identify the user program that made the request and transfers the response data to just that user program. In the example shown in Figure 1, only user program 22 reserves Dow Jones' new search service, but the utility of the query provider is to increase bookings from other user programs and the number of services in the query class. It increases with the increase.

【0023】

The last class of services monitors data based on specific requests for information identified by host computers by identification symbols. The remote database monitors all data as it is received from its source and selects the data for which the request is pending. The data is then transferred to the requesting user. In this way, the service monitor class keeps the query open. The monitor provider receives the request from the user program and simply advances the request to a remote database that is no longer pending, just as the query provider did. Most remote databases mimic a multi-user system as a single user and transmit specific items of data to the multi-user system. When the data is received, it is directed to the monitor provider. The monitor provider searches the record, detects which user program requested the data, and transfers the data to those user programs.

【0024】

Market monitor data is encoded in a compressed format. The primary provider only determines that the data being received is in market monitoring format and transfers all of the data (mm) to monitor provider 40 in encoded format. The monitor provider then decrypts the data and directs it to the requesting user program as one or more of the three types of services. The basic market monitoring service (mm) responds to the stock price fluctuations of each particular stock. The selected quote service (sl) responds to each transaction of the stock and identifies the volume and amount of that transaction. The block trade quote (bt) identifies all trades above 10,000 shares. Block trade is actually a broadcast-class service, but it is most efficiently decrypted by the monitor provider because it is encoded by a host computer with a market monitoring service. In addition, future block trades are expected to be a larger selective service. As shown in Figure 1, all three types of services rely on the same flow of data received from a remote database, but user programs can individually reserve a selection of the three types of services. ..

【0025】

Although it is a query class, the service that the primary provider fully handles is the stock price (qt) service. Users expect to seek and receive stock price quotes quickly, and current systems make it easier to speed up the return of quote data by minimizing the number of transfers of quote requests and the number of return data via the arithmetic system. To do. Two types of transfers in each direction due to the use of the query provider are eliminated. The primary provider transmits the stock quote request with a sequence code that identifies the request in the primary provider. The sequence code is stored with the identifier of the requesting user program in the first-in / first-out storage device. The remote database returns the data in the same order it was 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, as long as the sequence number matches. If the sequence number is skipped in the return data, the primary provider can either make the request again or notify the user program that the request should be made again.

【0026】

The basic user program allows users to make specific requests and properly view the returned data within the scope of the service they have reserved. However, it is possible that users will want to develop their own programs that are particularly suitable for their particular needs. In fact, as a very small part of it, users may want to develop programs that have the need to obtain stock market information. The pension management program would be an example of such a program. In the past, retrieving information from stock market services and other databases has given little flexibility to programmers, making it difficult or impossible to combine custom programs into remote databases. The present invention facilitates such communication using application program interfaces (APIs). This API makes it easy to set data transfer paths between tasks by maximizing the functionality of the operating system and at the same time minimizing the programming work required of the user program.

【0027】

An API is a code module of a subroutine that can be attached to any of the user and provider tasks. When the API code module is attached to the user program, the program simply calls the subroutine to set the data transfer path. The user does not need to know the capabilities or requirements of the underlying operating system. These are already taken into account when developing the code module. In addition, user programs are shielded from operating system fluctuations. The system designer uses the variation of the operating system to modify the API code module appropriately. API code modules offer the greatest advantage in interfaced user programs to the operating system, but are also used to interface provider background tasks. With this method, system designers only need to modify the API code modules to make changes to the operating system, not the provider tasks behind them.

【0028】

Another advantage of certain API code modules described below is the full functionality of the Wang VS System's Intertask Message (ITM) feature when creating mailboxes and forwarding messages to those mailboxes. May be used. In the Wong VS system, a task can list a port or mailbox in the operating system's P-list and "sleep itself". In the system according to the invention, these P-lists are standby lists created by the API code module. The operating system monitors the P-list, and when a message is received on the port of the P-list, it notifies the task related to the P-list. As a result, the task program does not have to keep running as the program waits for an event to occur. This feature of the operating system is especially useful for provider tasks in monitoring data requests from user programs and for user programs in monitoring the receipt of data from host computers. Is. Such an event can occur at any time.

【0029】

Inter-task communication is handled efficiently by the API code module by setting up three types of lists. 2 and 3 show an exemplary list for the primary provider and user 2. Each task communicating via the API code module sets a configuration list and a wait list via an API routine. In addition, each provider task may set up a subscriber list for each service it provides.

【0030】

Before setting any data transfer path, the provider or user task must first acquire the configuration list through the primary provider. The configuration list contains a service code for each available service. In addition, the configuration list tells each service whether a particular task is the provider of the service (indicated by P in the list). If the task is not a provider, the list indicates whether the task has access to the service (yes for Y, no for N). In addition, each class is provided with an ITM port or mailbox address, to which messages requesting the service are forwarded.

【0031】

The provider must search its configuration list before the user can complete the request to the provider. Based on its access and provider mailbox information provided in the list, the provider will receive requests for a particular service by listing the mailboxes that should receive the request in the operating system's wait list. Should be set. In FIG. 2, the available state indicated for each service on the wait list indicates that the primary provider is in a state of receiving a request for each service on the wait list. As mentioned earlier, the standby list is the p-list of operating systems in Wong's VS system architecture. Once the wait list is set via the API code module, the provider program does not have to keep monitoring the mailbox for each service. Rather, this tedious task is handled by the operating system with a wait list.

【0032】

The provider can set a subscriber list for each service and include a pointer to the starting address of each subscriber list in the configuration list (indicated by * in Figure 2).

【0033】

The user also sets the operating system wait list via API routines. The user can include its own user port for each service it has access to. The user then acts as a mailbox for the data returned by the provider. The wait list contains each mailbox that is expected to receive data. Each mailbox on the wait list can be set to either the enabled or canceled state, and the operating system only notifies the task of the data transferred to the available mailbox.

【0034】

To reserve a service, the user searches the configuration list in the API routine to get the provider mailbox address. Throughout the routine, as shown in Figure 5B, a reserved message is then constructed and delivered to the designated provider mailbox. The user then waits for notification by the operating system via the user port on which the message was received. The reservation message is forwarded by the operating system to the provider task mailbox, and the provider task is notified that the message has been received. The provider may then process the booking list and place it in the user's return mailbox and other data for the service in the provider's subscriber list for the service. The other data mentioned above include the subscriber's workstation number, the user's ID and key.

【0035】

By defining a unique provider mailbox for each service in the configuration list, the system allows each user program to independently route data for several services reserved by the user. To. The host processor contains a particular user program as a cutomer, which can allow access to the data for a particular service, but within the local system either user fails to book or or It is possible to cancel a reservation for any service at any time without affecting the local service. As a result, internal message traffic through the operating system can be minimized. The host processor does not inform the user's status as a subscriber in the local system, so reservations and cancellations in the system do not affect the user's customer status.

【0036】

Generate a clear configuration list for each task in the system to expedite access to configuration information. Each class can efficiently gain access to its list without the need to transfer any further data from the configuration file through the operating system. However, in a multitasking system where global memory is easily available for all tasks, no individual configuration list is needed. Rather, the information can be obtained from the central file. However, it is important that each task has immediate access to the provider mailbox address specified by the system and its own access information for each available service.

【0037】

Below is a more detailed description of how to configure / wait and create API subroutines that enable efficient transfer of subscriber lists and data. As the first to receive all information from the remote database, the primary provider 56 has not been selected as the central program for initiating programs related to transfers from the remote data base. Call a configuration-initiated APT routine called CNFINIT as part of the primary provider's invocation process. CNFINIT reads the configuration file from the optical device. The primary provider also initiates a communication line. When the host computer 34 detects that the line is in use, it responds by sending a service list for the customer as described below. The primary provider integrates the information received from the remote database and the disk storage to create the configuration file shown in Figure 4.

【0038】

The first item in the configuration file is the key for each task that should be included in the data transfer. In fact, the key is a logical name for recording the configuration of each task. The keys PRIPRO, INQPRO and MONPRO are the names given to the primary provider, query provider and monitor provider respectively. Another key, ADMIN, allows the execution of business administration programs when required for the specific needs of the system. Such programs can control keying and access to services by specific tasks and workstations.

【0039】

The program associated with the first four keys of the file is typically a provider program that runs in the background. In addition, three additional keys, USER1, USER2, and USER3, are directed to each of the three user programs shown in FIG. Of course, this system is not limited to these three user programs. These programs are typically subscribers and may or may not compute in the foreground.

【0040】

The terminal ID field is an identifier for the remote database to know each user in the system. The database grants rights to specific services, identifies each terminal and charges for those services. Only the user task requires the device's ID because it is the only genuine consumer of the data. The supplier can think of it as just an extension of the remote database and does not require a terminal ID. The terminal ID also acts as an alternative key. The remote data base does not know the first key and sends its configuration record tagged by the terminal ID. The terminal ID is assigned from the remote database when the customer requests a new or expanded service.

【0041】

When each task is initialized, the task number is sent to the primary provider along with the key. The status field tells if the key is being used, and if so, the workstation number where the associated task is being used. The status field can indicate that the task is running in the background. The workstation field is used by the administration program to limit the workstations that can use a given key and the corresponding privileges. Keys can be from or limited to the list of workstations indicated by the asterisks in Figure 4.

【0042】

At the bottom of Figure 4, the service field is expanded. This list of fields defines the role of the associated program for each of the defined services for each key. A program can have one of three roles with respect to a given service. It can have full reservation privilege (Y). It may be a service (P) provider or have no rights to the service (N). Subscriber rights granted by the remote database are indicated by y for accepted reservations and n for denied reservations and can be overruled by the local administration program. The role of the provider is defined by the system designer.

【0043】

During CFNINIT, the primary provider 36 also acquires the provider mailbox file from disk storage. The provider mailbox for each service will later be included in each configuration list for each task, as shown in Figures 2 and 3. Using the information from the provider mailbox file and the configuration list, the primary provider builds a prototype of the configuration list to be used by each task using the API code module. The prototype configuration list contains one record for each defined service, and each record contains the service provider's mailbox. This mailbox is the ITM port name.

【0044】

With the configuration file and the prototype configuration list at hand, the primary provider generates its own personal configuration list by calling SCLINIT. By providing the key PRIPRO, the primary provider retrieves the access code P, Y or N from the configuration file for each service based on the prototype list and obtains the configuration list. When P is instructed for the service in the configuration list, the provider sets the provider mailbox indicated in the configuration list as the mailbox. The provider also sets a subscriber list for each service and sets the current list size to zero. In addition, each mailbox set by the provider program is placed in the operating system's p-list by API subroutines for tasks that act as wait lists. The wait state for each provider's mailbox in the wait list is set to the available state. Finally, the primary provider program calls the API routine SCLWAIT, informing the operating system to wait for instructions that a message has been received in one of the available mailboxes in the wait list. ..

【0045】

When the primary provider is initialized, so are the other tasks. To do this, each task sets up an operating system wait list by calling the API routine SCLINIT. As shown in Figure 3, the wait list can initially include three imitation services: emergency (em), workstation (WS) and timer (tm). The emergency port allows tasks to receive urgent messages at high priority on the wait list. The workstation service allows a user program to wait for an upcoming event at a workstation terminal using a wait list set by an API code module. With this imitation service, the user program does not have to delay receiving data while waiting for an event, such as a keystroke, to occur in the terminal. Finally, the timer imitation service allows the program to set the timer via the wait list. Therefore, it is possible to limit the time that the user program waits for the occurrence of other events.

【0046】

During the SCLINIT routine, the task also acquires a configuration list that provides the information needed to reserve services for the system. The task gets its configuration list from the primary provider task, so the API subroutine has a default mini-configuration list in which all tasks are configured accordingly as users of the configuration data. The user reserves configuration data with the primary provider via mailbox "cfcf".

【0047】

When the configuration reservation message reaches the primary provider's mailbox "cfcf", the operating system evokes the primary provider in the SCLWAIT routine. In response to the configuration data reservation message in mailbox "cfcf", the primary provider uses the user key provided in the reservation message to obtain an appropriate record of the configuration file and, in a copy of the prototype configuration list, Attach the appropriate access code to each service for that key. The primary provider returns the customized configuration list to the reserved mailbox, eg 20cf, and updates the master configuration file to indicate that a particular key is being used.

【0048】

By using the SCLINIT routines individually, each task can have a complete configuration list and an empty but wait list for imitation services for emergencies, workstations and timers. The data path shown in Fig. 1 has not been set yet. To set the route, each provider calls the routine PRVOPEN, which sets up an initially empty subscriber list. Both provider and booker tasks automatically call routine SCLOPEN during PRVOPEN. Call routine SCLOPEN. The routine SCLOPEN sets the provider task to open its mailbox to what the service is indicated in the configuration list, and the booker task sets the mailbox to a task, for example 20gt in Figure 3. Set to the number plus the service code. Any future message received by a particular task for the service will be received in the designated mailbox.

【0049】

A task can act as a subscriber to one service and a provider of another service. For example, the monitor provider acts as a subscriber to the market monitoring service MM and as a provider of the market monitoring service mm, the selective trading service and the block trading service bt. Similarly, inquiry providers are subscribers to the news search service NR and providers of the distributed news search service nt. Individual SCLOPEN routines need to be called for each service.

【0050】

In the SCLOPEN routine, the mailbox is placed on the wait list for the task, but is set to "deny". The provider task then retrieves SCLLISTEN to set a particular mailbox on the wait list to the enabled state. The subscriber task typically calls the routine SCLSUBSCRIBE first. According to the routine, the reservation person constructs a reservation message as shown in FIG. 5B, and transmits the reservation message to the provider mailbox obtained from the configuration list. The subscriber message includes a return mailbox for the service at the subscriber and a flag indicating whether the message is a subscriber or for cancellation. The message also includes a task number, a user ID and a user's key, and the provider responds to the message by adding the subscriber to the subscriber list for the service. The subscriber then typically enters SCLLISTEN to set the associated mailbox on the wait list to the enabled state.

【0051】

The data returned by the provider to the subscriber mailbox can then be read by entering the API routine SCLREAD, which allows the user to acquire any information intervening in the mailbox. However, the user typically enters the routine SCLWAIT to signal the operating system when an event occurs in any of the mailboxes in use.

【0052】

Once the user has reserved the service, the SCLSEIND routine in the API code module can make a specific request for a remote database through the provider. By using this routine, the user program will generate a message as shown in Figure 5A. Figure 5A contains services and flags and messages suitable for a particular service and request. Under SCLSHND, the provider's mailbox is retrieved from the subscriber's configuration list and messages are sent. The message is buried by the provider, and in the case of a query provider or monitor provider, the provider generates its own message that should be transmitted to the primary provider as well as to the remote database. Messages to the primary browser are sent via the SCLOPEN and SCLSUBS CRIBE routines along the previously configured route.

【0053】

Finally, when the data is received by the provider from the host processor 34, the provider needs to send the data to the reserved user. By calling the PRVSEND routine, the provider visits the reservation list for a particular service and sends the submitted data to the subscriber. Alternatively, providers like monitors can detect mailboxes that need to carry data via their own internal list.

【0054】

In addition to the routines described so far, there are reverse routines such as SCLTRM, which is the reverse of Sclinit, SCLCACEL, which is the reverse of SCLSUBSCRIBE, SCLIGNORE, which is the reverse of SCLLISTEN, and SCLCLOSE, which is the reverse of SCLCPEN.

【0055】

Additional Features SCLLIST allows users to add events specified by a large number of users to the wait list used by SCLWAIT. This imitation service (US), such as the workstation imitation service, allows the user program to eliminate the waiting process for encouragement, which can delay the receipt of incoming data.

【0056】

A detailed description of the monitor provider task is provided below for Figures 6-8. The monitor provider not only needs to keep a subscriber list for each of the market monitor, selective quote and block trading services, but also forwards and receives from the host a specific request that the host should monitor a specific market code. The booker list needs to be correlated with the requested code so that the data can be distributed properly. For that purpose, the monitor provider relies on the symbol tree shown in Figure 6A and the user tree shown in Figure 7A. Each tree is a binary threaded tree that additionally contains a pointer to the combined list.

【0057】

In the case of a symbol tree, each node in the three identifies a symbol that acts as an identifier for a particular security (confidential, security) being monitored. Each node in the tree points to a combined list of users who have requested information for the symbol. In the user tree, each node in the tree identifies a subscriber to one of the services from the monitoring provider, and each node points to a combined list of symbols being monitored for that user. .. For each symbol in the list joined to each user node, there is a corresponding symbol node in the symbol tree.

【0058】

The user tree grows as additional user tasks reserve the monitor provider service. The signal tree grows as the number of specific requests within each service increases. In each case, the first user to reserve or the first signal to be requested acts as the root of the tree. After that, additional nodes are added to the left or right of the predecessor node, depending on whether the new node has a low or high alphabetic value. Thus, all symbols that precede the symbol MMM.N at the base of the symbol tree alphabetically are found on the left side of the tree. Using a binary tree significantly reduces the time it takes to search a list for a particular item. This search time is especially important when 20 users or 50 symbols per user are listed in the tree.

【0059】

Each node in the symbol tree contains the information listed in Figure 6B. Each node contains a security symbol, the conditions under which that security is traded, and the most recent price for said security received from the host. It also contains pointers to end users on the user list associated with the node. Pointers to each of the combined lists and in such lists are indicated by dotted arrows in FIG. 6A. The combined list is doubly combined to facilitate adding and removing nodes from the list. Pointers for the left and right children of each node are provided along with pointers to the parent of that node. These pointers are indicated by solid arrows in FIG. 6A. Threading the tree to its parent with a pointer simplifies the reorganization of the tree when adding or removing symbols. Each user node in the combined list contains a service for which a particular user has thereby requested a symbol. The service minding table contained in each symbol node identifies all of the services contained in its combined user list.

【0060】

Each user node in the user list has the information shown in Figure 7b. Each node contains the return mailbox identified in the subscriber's reservation message in routine SCLSUBSCRIBE, the user's terminal ID, and the user's key. In addition, each node contains a pointer to a list of symbols associated with that node and a pointer to the node's children and parents. In addition, the user node contains its own service minding table. This minding table lists all the services reserved by a particular user. As illustrated by user 7 in FIG. 7A, a particular user does not need to have a particular symbolic request pending having a user node.

【0061】

When a user reserves a service through SCLSUBSCRIBE, the monitor provider scans the user tree to determine if the user node is already configured for that task. If set, the new service reserved by the task is added to the service minding table. If not set, a new node will be added as a leaf to the tree.

【0062】

The SCLSEND routine can then allow the task to request that the service be monitored for a particular symbol. Before adding a symbol to the tree, a request must be sent to the host processor and an acknowledgment must be received from the host in the form of a price. If the same symbol in the same service was not previously requested, the request will only be sent to the host processor. To make this decision, the monitor provider first scans the symbol tree for the symbol to be requested. If the provider locates the symbol, it checks the service minding table to determine if the symbol was requested for the desired service. If a symbol and service are found in the symbol tree, the user is added to the combined user list for the symbol node and the symbol is added to the combined symbol list for the user node. However, if the symbols and services are not located in the symbol tree, a request is made to the host.

【0063】

When a request is made to the host, the request is given a sequence number, which is transmitted with the request. The host acknowledges the request in a first-in / first-out manner and returns the sequence number. To determine if an acknowledgment has been received, the requested symbol is placed in the additional pending queue shown in Figure 8. Each node in this queue points to the next symbol that should be requested. The sequence number is included with the requested symbol. In addition, each node in the queue points to a user node that may be included in the list.

【0064】

When an acknowledgment is received, the symbol node is removed from the queue and the pointer to the user node is forwarded to that symbol node in the symbol tree. If the symbol does not already have a node in the tree, it will be set as a node. In addition, nodes in the combined symbol list in the user tree are added to a particular user.

【0065】

If the acknowledgment sequence number is received in disorder, the system assumes that the skipped request was unsuccessful and sends a new request for the same symbol. The symbol, along with the new sequence number, is placed at the end of the additional pending queue. Also, the counter is ticked. This counter allows the request to be retransmitted only three times to avoid making an endless loop request for a symbol that has not been acknowledged.

【0066】

When a user requests to remove a symbol from the service, the user tree is scanned to locate the user and the symbol is removed from the combined list. The symbol tree is then scanned for the symbol and the user is excluded from the combined list. In addition, the combined list is scanned to locate the user and determine if the user is the last to include the signal for a particular service. If so, the service is removed from the symbol node minding table. Then, when scanning the symbol tree to determine if a particular service is pending for a signal, it is not necessary to scan the joined user list because the minding table has been updated. If the deleted user is the last node in the combined user list, the node is permanently removed from the symbol tree. Also, a delete request is sent to the host processor.

【0067】

If the delete request is not properly received and processed by the host, the system may receive updates in the future that the host expects to be distributed in the future. When scanning the symbol tree to locate the user of the data, the location of the corresponding signal node is not identified. In such a case, the deletion request is sent to the host processor again.

【0068】

If the symbol is found in the symbol tree when information is received from the host, the combined user list is scanned to identify the user who should receive the particular data. Data is sent to these users in the appropriate mailboxes determined by traversing the user tree.

【0069】

When a user program calls the SCLCANCEL routine and sends a cancellation message to the monitor provider, the user tree is required to clear the symbol tree of the symbols associated with that user. Upon receiving a message from the routine, the user tree is scanned for that user, and the symbols are identified by scanning the combined symbol list. The symbol tree is then scanned for these symbols and the user is removed from the combined user list. Again, if the user is the last user to be joined to the symbol, the symbol is removed from the symbol tree and a delete request is sent to the host.

【0070】

It should be noted that the block trade symbol bt is not included in any of the sample trees. The reason for this is that the block trading service is a broadcasting service. The block trading service is processed only by the monitor provider because it is encoded using the market monitor data. However, as a broadcast service, block trades are easily buried by the API routine PRVSUBSCRIBE, which adds users to the subscriber list, and PRVSEND, which distributes data to the listed users.

【0071】

In the above, the present invention has been shown and described using preferred embodiments, but if you are an expert in this technical field, the form and details will not deviate from the spirit and scope of the present invention defined in the claims. You will understand that various changes are possible in. For example, the present invention relates to a multitasking system in which multiple tasks are performed in one buried unit, but these tasks are still included in certain features of the present invention. , Can be distributed to other processing units. Furthermore, the present invention also has applications to non-market data.

[Simple explanation of drawings]

[Figure 1]

It is a block diagram of the software architecture of the system which carried out this invention.

[Figure 2]

FIG. 5 is a diagram showing a configuration list, a standby list, and a subscriber list stored in the provider task memory by the common code module of the system application program interface (API) shown in FIG.

[Fig. 3]

It is a figure which shows the configuration list and the waiting list stored in the user task memory by API.

[Fig. 4]

It is a figure which shows the configuration file which is searched through API by the task of a primary provider.

[Fig. 5]

FIG. 5B is composed of FIGS. 5A and 5B and shows a message format of a message transferred by an API.

[Fig. 6]

FIG. 6B is a diagram showing the data structure of the symbol tree in the monitor provider shown in FIG. 1, which is composed of FIGS. 6A and 6B.

[Fig. 7]

FIG. 7B is a diagram showing the data structure of the user tree in the monitor provider, which is composed of FIGS. 7A and 7B.

[Fig. 8]

FIG. 5 shows an additional pending queue at a monitor provider.