Method and system for dynamically controlling the content of a local receiver data base from a transmitted data base in an information retrieval communication network4745559Abstract A method and system (28) are provided for dynamically controlling the content of a local receiver data base (24, 26) from a transmitter data base (20) in an information retrieval communication network (28) in which a message transmitter transmitting the transmitter data base (20) dynamically provides data base messages over a message distribution network (22) to local receivers receiving the local receiver data bases (24, 26). The transmitter data base (20) messages are used to incrementally increase and decrease the content of the local receiver data base (24, 26) on a record-by-record basis. In addition, non-data base messages may also be provided. The data base messages consist of displayable data as well as file maintenance messages. Storage templates (42) are retrievably stored at the local receiver data base (24, 26). These storage templates (42) are locally retrieved based on receipt of a unique identifier. Each stored record (40) has a unique associated storage template (42) although a storage template (42) may be corresponding to several different records (40 ). Set identifiers defining multiple field identifiers of information fields and ripple chains, which chains require a change in only one field in the ripple chain to be transmitted, are used by the local receiver data base (24, 26) in conjunction with transmitted update record data base messages (54) to reduce the communications capacity that is required. Claims What is claimed is: Description TECHNICAL FIELD
__________________________________________________________________________
FIELD NAMES
LAST
DM NET
DM DVOL
DM TIME
DM
__________________________________________________________________________
SET DEFINITION
4 0 30 0 31 0 32 0
__________________________________________________________________________
Preferably, where the data mark or DM indicated that different data was expected for each of the associated fields, the field set definition message would contain an SID code which associated the four fields in the above order. In the situation where two or more fields were updated with the same value, for example where a "trade produced a condition where the new LAST PRICE was also the new HIGH PRICE, the fields involved, using the above example, would be as follows: LAST (4), and HIGH (26), and a field set definition message would be issued containing the following data:
______________________________________
FIELD NAMES LAST HIGH DM
______________________________________
SET DEFINITION
4 26 0
______________________________________
In the above example the data mark DM indicates that only one piece of data is expected for those fields associated by that SID or field set identifier. Although it does not apply to the above example, with respect to the previous example, it should be noted that for a correct update, all updates containing multiple data items to be applied via the field set identifier or SID must preferably be constructed and applied in the same order as in the field set definitions. As was previously mentioned, multiple and combined cases of the above examples could also be employed in accordance with the presently preferred system and method of the present invention. As shown by way of example in FIG. 7, a typical storage template 42 preferably includes FID or field identifier information. In addition, as illustrated by way of example in FIG. 7, the storage template 42 preferably includes a field class which indicates for a given set of templates which class of information those templates and associated records relate to. In this regard, it should be noted that a given storage template 42 may preferably be associated with a plurality of records, with each record being uniquely associated with a given storage template 42. The aforementioned field class is a set of information fields defined via the storage template 42 where the FID or field identifier of a particular information field in the class is always the same. Although there may be several storage templates 42 defined for a given class, each field identifier or FID defined in the storage template 42 is always associated with a given field. Hence, some storage templates 42 may be defined to include all the fields in the class and some for a given subset of those fields in a class, although the field identifier or FID definitions are always preferably consistent. In addition, there may also be transient fields in accordance with the presently preferred system 28 and method of the present invention which are defined in order to allow for cases where fields are not stored for retrieval in the usual way, that is, are not normally contained in data base messages, but are transient to the network 28. However, preferably these fields are still identified via a field identifier or FID but since these are transient or non-data base messages, any updates received which would contain a reference to these transient fields would not be applied to the local receiver data base 24 and would only be transmitted in order to allow downstream devices to process or display this type of data immediately. Therefore, no storage need be allocated to these transient fields in the record even though there has been an allocation of a field identifier. Referring once again to FIG. 7, the storage template 42 concept employed in the presently preferred method and system 28 of the present invention shall be described in greater detail before the presently preferred method of controlling the content of the local receiver data base 24 based on date base messages which affect the entire record as an entity, such as the messages referred to in FIG. 1, is described in greater detail. Thus, the presently preferred storage template 42 is a mechanism by which field identifiers are mapped to positions within the associated local receiver data base 24 storage structure and are themselves stored in the local receiver data base 24 as records, such as the typical storage template 42 illustrated in FIG. 7. The storage templates 42 employed in the presently preferred method and system of the present invention, allow the storage of format information on a field by field basis, thus reducing the amount of information necessary in each update message. By way of example, the presently preferred system 28 of the present invention may employ 255 different storage templates 42, or less, with various storage templates 42 supporting multiple records so that, by way of example, fifty different storage templates 42 could support 100,000 records. Preferably, in the presently preferred system 28 and method of the present invention, the storage templates 42 would be available on the local receiver data base 24 for retrieval, and would preferably be stored locally by every device that needed to do field interpretation since the storage templates 42 are used to decipher the data base messages transmitted to the local receiver data base 24. Although a separate storage template request message may preferably be defined in order that a downstream device from the transmitter data base 20 may obtain storage templates 42 on a as needed basis, once a storage template 42 is initially retrieved from the transmitter data base 20, it is preferably retained by the local receiver data base 24 for future use unless a DROP TEMPLATE message 58 is received from the transmitter data base 20. In addition, storage templates 42 can be built into the software as opposed to being requested. As previously mentioned, each record on the data base, either the transmitter data base 20 or the local receiver data base 24, preferably has a field associated with the template number or identifier which indicates which storage template 42 the data contained in that record is associated with. A transmitted or arriving field update message would preferably contain a record name, a field identification code and some data or update information. The record name or RIC in the update message preferably identifies the associated storage template 42 to be employed to decipher the update message via the template number field of the record. Each data or information field in the record, which is a self contained integral record, preferably has associated with it in its associated storage template 42, a field identifier or FID, a ripple chain field identifier or RIPFID, some data format information, the field length, and an offset, with the offset held in the storage template 42 showing the position relative to the start of the record at which the particular field starts. The aforementioned format information specifies which transmission encoding format or TEF and data interpretation format or DIF applies when processing the data in that particular information field. Thus, the storage template 42 controls both the deciphering of the data base message and the processing thereof. Once the appropriate associated storage template 42 has been identified, the field identifier or FID extracted from the update message points to the appropriate storage template 42 entry for that field and the data or information can then be applied to the designated record by locating the field within the record via the offset, as will be described in greater detail hereinafter. If the data requires interpretation, the data interpretation format is obtained from the storage template 42 along with the offset allowing the data to be translated prior to its display or processing at the local receiver 24. As was previously mentioned and as will be described in greater detail hereinafter, the ripple chain or RIPFID in the extracted storage template 42 allows individual ripple fields in the record to be chained together by keeping the field identifier number or FID of the next ripple field in the ripple chain. In the above example, if there is a 0 offset in the storage template 42, this would preferably indicate that there was no field in the record corresponding to that particular field identifier. As was previously mentioned, and as shall be described in greater detail hereinafter with reference to FIGS. 9 and 10, the presence of a ripple chain or RIPFID in the storage template 42, chains or associates ripple fields within a given record so that an update to the first information field in a ripple field chain will affect the other ripple fields within the ripple chain. Preferably, a ripple chain is established in circumstances when an update to a given field in a record would cause data to be overwritten in that field which is still useful data, such as, for example, the last three trade prices of a stock when the information retrieval network is used for transmission of financial information. For example, such a ripple chain would look like the following, assuming hypothetical field identifiers or FID being given in parentheses: LAST (4), LAST-ONE (5), LAST-TWO (6), LAST-THREE (7). In the above example, an update to the field LAST(4), which in the above example is the most current last price of a stock, or other trading instrument, would require that the values of each of the ripple fields in the ripple chain ripple down the record, or be changed such that the old value of LAST-THREE (7), would eventually be lost, with this ripple field representing the third last price of the trading instrument in terms of time. In this regard, it is clear that if the ripple fields in the ripple chain are chronologically related, when the most current information is updated by subsequent information it, of course, becomes the next most current information and so on throughout the ripple chain. This, will be more readily understood by reference to FIG. 10 which shows the processing of a ripple chain and will be explained in greater detail hereinafter with reference thereto. At this point, suffice to say that in the above example a resulting ripple effect will result in the following changes in the information content of the fields in the ripple chain: the field LAST (4) would be changed to contain the new update information from the update message which has been received; the next field LAST-ONE (5) would have its information content changed so as to now contain the information which was previously in the LAST (4) field when the update message was received; the next field LAST-TWO (6) would have its information content changed to the information which was in the LAST-ONE (5) field prior to receiving the update message; and the LAST-THREE (7) field would have its information content changed to contain the information content of the LAST-TWO (6) field immediately prior to receipt of the update message; with the prior information content of the LAST-THREE (7) field immediately prior to receipt of the update message being lost. Thus, it can be seen that a single update message containing information for only a single ripple field in the ripple chain will, in affect, cause the updating of all of the ripple fields in the ripple chain without having to transmit information for each of those fields, thereby resulting in a bandwidth efficiency. It should be noted that preferably, in order for the chaining function in the ripple chain to operate, the ripple chain or RIPFID defined in the storage template 42 should contain, for each ripple field in the ripple chain, an offset to the field identifier or FID of the next ripple field in the ripple chain with, by way of example, a 0 entry being used to indicate either no ripple chain or the end of a given ripple chain. Preferably, ripple occurs only in a forward direction down the record in ascending field identifier order and occurs preferably only as the result of an update message being received by the local receiver data base 24. In addition, as was also previously mentioned, ADD RECORD, DROP RECORD, ADD TEMPLATE, and DROP TEMPLATE messages are received by the local receiver data base 24 from the transmitter data base 20 and are used for file maintenance of the local receiver data base 24. For example, when an ADD RECORD message is received by the local receiver data base 24, an index entry is created and the data is copied from the data base message into the new record formed in the local receiver data base 24, with the reverse being true for a DROP RECORD message. Similarly, if an ADD TEMPLATE message is received by the local receiver data base 24 and the storage template 42 is not contained in the local receiver data base 24, then an index entry is created and the storage template 42 is copied from the data portion of the message as a new storage template 42 in the local receiver data base 24. Again, the opposite procedure is followed in response to a DROP TEMPLATE data base message. In this manner, dynamic record-by-record control or management of the local receiver data base 24 on an integral record by record basis may be maintained. "SETTING UP THE LOCAL RECEIVER DATA BASE" Referring now to FIG. 2, we shall now initially discuss the procedure for setting up the local receiver data base 24 to receive the desired record structures from the transmitter data base 20 in the form of data base messages which are transmitted through the message distribution network 22 and interpreted at the local receiver data base 24. However, before these transmitter data base messages can be interpreted or deciphered, there must be an associated storage template 42 present in the local receiver data base 24 for deciphering the transmitter data base message and processing this message in accordance therewith. The ADD TEMPLATE message 50, as illustrated in FIGS. 1 and 2, is preferably transmitted to the local receiver data base 24 from the transmitter data base 20 via the message distribution network 22 in order to set up the local receiver data base 24 to receive data base messages which affect the record content of the local receiver data base 24. At the local receiver data base 24, the ADD TEMPLATE message 50 is examined for valid signs and template number fields. A check is made to determine if the template number is already present in the template index 70, which check is represented by block 72 in FIG. 2. If the template number is already in the template index and an ADD TEMPLATE message 50 has been received, preferably the previously stored storage template 42 having that template number must be dropped so that it can be replaced by the new storage template 42 being transmitted along with the ADD TEMPLATE message so that the local receiver data base 24 will not have two storage templates 42 with the same template number of identifier. This drop template function, in this instance, along with an indication of such dropped is represented by blocks 74 and 76 in FIG. 2. On the other hand, if the template number is not already present in the template index 70, it is an indication that the storage template 42 is not present in the local receiver data base 24 and a check is then made to determine if there is space in the local receiver data base 24 for storage of the transmitted storage template 42. This function is represented by block 78 in FIG. 2. In the event there is insufficient storage space, then an error message would be generated which is represented by block 80 in FIG. 2. In the more normal instance, where there is sufficient storage space, then the storage template data is extracted from the ADD TEMPLATE message 50 and copied into the indicated storage template, with the added storage template 42 being added to the local receiver data base 24, and with the associated template number or unique identifier for that storage template 42 being added to the template index 70. These functions are represented by blocks 82 and 84 in FIG. 2. After this is accomplished, the processing of the ADD TEMPLATE message 50 has been completed and the procedure ends, as represented by block 86. A typical ADD TEMPLATE message is represented below
______________________________________
[TPLNO] [TEMPLEN] [RECLEN] [CLASS]
[DATA]
(8) (16) (16) (8) (V)
TPLNO = Template number
TEMPLEN = Number of entries in template
RECLEN = Length in bytes of associated record (excluding
header)
CLASS = Template Class
DATA =
0 {FID, RIPFID, TEF, DIF, FLDLEN, OFFSET} 32,767
(16)(8)(4)(4)(8)(16)
FID = Field Identifier Number
RIPFID = Ripple Field Identifier
TEF = Transmission Encoding Format
DIF = Data Interpretation Format
FLDLEN = Length of Field in Bytes
OFFSET = Offset of Field in Record
[DATA] field portions of the above message are
preferably transmitted in ascending FID order,
omitting any entries for FIDs which do not exist in
the template 42.
______________________________________
In order to further understand the processing of the ADD TEMPLATE message 50 in the local receiver data base 24 microcomputer, the following programming explanation is provided below in Table A, with this programming information being translated into Pascal, by way of example, for running on the Digital Equipment Corporation MICROVAX:
TABLE A
__________________________________________________________________________
PROCESS --ADD --TEMPLATE --MSG
begin
GET --SIZE (MSG --SIZE)
GET --TPLNO (TPLNO)
GET --TEMPLEN (TEMPLEN)
GET --RECLEN (RECLEN)
GET --CLASS (CLASS)
if STATUS = NO --ERROR
then
if (TEMPLATES [TPLNO].TEMPLEN #0)
then
DROP --TEMPLATE (TPLNO)
REPORT --ERROR ("TEMPLATE --DROPPED")
else
end if
TEMPLATES [TPLNO].TEMPLEN: = TEMPLEN
TEMPLATES [TPLNO].RECLEN: = RECLEN
TEMPLATES [TPLNO].CLASS: = CLASS
i: = 0
repeat
GET --FIC(CURR- --FID)
TEMPLATES [TPLNO].DATA [CURR --FID].FID: = CURR- --FID
GET --BYTE (RIPFID)
TEMPLATES [TPLNO].DATA [CURR --FID].RIPFID: = RIPFID
GET --BYTE (TEFDIF)
TEMPLATES [TPLNO].DATA [CURR --FID].TEF: = TEFDIF MOD 16
TEMPLATES [TPLNO].DATA [CURR --FID].DIF: = TEFDIF DIV 16
GET --BYTE (FLDLEN)
TEMPLATES [TPLNO].DATA [CURR --FID] FLDLEN: = FLDLEN
GET --WORD (OFFSET)
TEMPLATES [TPLNO].DATA [CURR --FID].OFFSET: = OFFSET
i = i + 1
until (i = TEMPLEN)
UPDATE --STATS
else
endif
end.
__________________________________________________________________________
"ADDING A NEW RECORD TO THE LOCAL RECEIVER DATA BASE" The above situtation referred to in FIG. 2 refers to the data base maintenance procedure for adding a storage template 42 to the local receiver data base 24. However, the more normal procedure encountered is the incremental addition of new records to the local receiver data base 24 after the appropriate storage templates 42 have been stored in the local receiver data base 24. Such a situation is illustratively represented in FIG. 3. The ADD RECORD message 52 is a procedure for checking to see if the record to be added to the local receiver data base 24 is already stored in the local receiver data base 24 and if there is enough space in the local receiver data base 24 to store the record to be added. As shown and preferred in FIG. 3, in processing the ADD RECORD message 52, the local receiver data base 24 checks to see if there is a template number in the message and generates an error message if no template number is present. These functions are represented by blocks 88 and 90 in FIG. 3. Assuming a template number is present in the ADD RECORD message 52, which is preferably a requirement of all data base messages so that they can be deciphered at the local receiver data base 24 and processed there, a check is then made to determine if the record to be added is already present in the record index 92 resident in the local receiver data base 24. This function is represented by block 94 in FIG. 3. If the record is already resident in the record index 92 then, preferably, the record is dropped and an indication of record drop is provided so that storage space is not wasted by storing the same record twice. These functions are represented by blocks 96 and 98 in FIG. 3. If, however, the record is not already resident in the record index 92, then the template number associated with the transmitted data base message is then looked up in the template index 70. This function is represented by block 100 in FIG. 3. If a template number is not resident in the template index 70, which indicates that no storage template 42 has been previously stored in the local receiver data base 24 so that the record cannot then be deciphered and processed, an error message is provided. These functions are represented by blocks 102 and 90 in FIG. 3. Assuming, however, that the template number associated with the transmitted record is contained in the template index 70, a check is then made to determine if there is space in the local receiver data base 24 for the record to be stored. This function is represented by block 104 in FIG. 3. If there is not sufficient space to store the record, then an error message is generated and the process ends. This function is represented by blocks 90 and 106 in FIG. 3. If, however, there is sufficient space in the local receiver data base 24 to store the transmitted record, then the record is added to the local receiver data base 24, with a typical such record being represented by reference numeral 40 in FIG. 7, with the space required to store the record being allocated in the local receiver data base 24, and with all defined fields being set to a default value. This function is represented by block 108 in FIG. 3. The record identification code or RIC is also added to the record index 92 and the procedure is then complete. This is represented by the blocks 110 and 106 in FIG. 3. As in the above example of the ADD TEMPLATE message 50, this ADD RECORD function can be further described in a programming information format which can readily be converted into PASCAL, by way of example, to run on the Digital Equipment Corporation MICROVAX. This ADD RECORD function can be broken into two aspects, one dealing with the checking to see if the record 40 is already in the local receiver data base 24, which programming function is represented below in Table B, and into an ADD RECORD primitive of function that checks to see if there is sufficient space in the local receiver data base 24 for the record to be stored, which is represented in Table C:
TABLE B
__________________________________________________________________________
PROCESS --ADD --RECORD --MSG
begin
GET-SIZE (MSG --SIZE)
GET --NAME (CURR --NAME)
GET --TPLNO (CURR --TPLNO)
IF STATUS: = ERROR THEN
REPORT --ERROR ("NO TEMPLATE NO. --IN --ADD --MSG")
EXIT
END
GET --RTL (CURR --RTL)
STATUS: = LOCATE --RECORD
if STATUS = RECORD --LOCATED
then
REPORT --WARNING (DROP DUE TO DUPLICATE ADD)
STATUS: = DELETE --RECORD
else
end if
ADD --RECORD (NAME, RTL, TPLNO)
end.
__________________________________________________________________________
"DROPPING A RECORD FROM THE LOCAL RECEIVER DATA BASE" Similarly, a record may also be incrementally deleted from the local receiver data base 24, with FIG. 4 relating to the DROP RECORD data base message 56. As illustrated in FIG. 4, the dropping of a stored record from the local receiver data base 24 can occur as a result of a DROP TEMPLATE message 58 to be described in greater detail with reference to FIG. 5, or as a direct result of receipt of DROP RECORD message 56. At this point, the dropping of a record from the local receiver data base 24 shall be described solely in response to receipt of a DROP RECORD message 56 with the other alternative being dealt with when FIG. 5 is described. Again, as was true with respect to the ADD RECORD data base message 52, the DROP RECORD data base message 56 involves two aspects, one of which is in an attempt to first check if the record to be dropped is stored in the local receiver data base 24 and, thereafter, the actual dropping or removal, incrementally, of the stored record from the local receiver data base 24, assuming it is found. These functions are broadly illustrated in FIG. 4 with the determination of whether or not the record is stored in the local receiver data base 24 being accomplished by checking the record indicator code or RIC index 92 to see if the RIC contained in the DROP RECORD message 56 is located in the record index 92. This function is represented by block 112 in FIG. 4. If the RIC contained in the DROP RECORD message 56 is not in the record index 92, then an error message is generated and the procedure is ended. This is represented by blocks 114 and 116 in FIG. 4. The absence of the RIC from the record index 92 is an indication that the record to be dropped was not stored in the local receiver data base 24. If however, the RIC in the DROP RECORD message 56 is contained in the record index 92, then this is an indication that the record is present in the local receiver data base 24 and the DROP RECORD message 56 is then processed to remove the record from the local receiver data base 24. This is represented by block 118 in FIG. 4. In addition, the RIC associated with the removed record is then dropped from the record index 92 since the record is no longer stored in the local receiver data base 24. This is indicated by block 120 in FIG. 4x. The procedure is then ended as represented by block 116. Again, as was true with respect to the above functions, the programming information for carrying out the function illustrated in FIG. 4, and which may readily be converted into PASCAL for running on the Digital Equipment Corporation MICROVAX, is given below in Tables D and E, where Table D represents the portion of the DROP RECORD function which relates to checking to see if the record is present in the local receiver data base 24, and Table E represents the function of actually removing the record 40 from the local receiver data base 24, assuming it is present therein.
TABLE D
__________________________________________________________________________
PROCESS --DROP --RECORD --MSG
begin
GET --SIZE (MSG --SIZE)
GET --NAME (CURR --NAME)
STATUS : = DROP --RECORD (NAME)
if STATUS : = RECORD --DELETED
then
UPDATE --STATS
else
REPORT --ERROR ("ATTEMPTED --DELETE, RECORD NOT PRESENT")
end
end
__________________________________________________________________________
"DROPPING A TEMPLATE FROM THE LOCAL RECEIVER DATA BASE" As was mentioned above with respect to FIG. 4, a record 40 can also be dropped as a result of the processing of a DROP TEMPLATE data base message 58 transmitter from the transmitted data base 20 to the local receiver data base 24. The processing of such a DROP TEMPLATE message 58 in accordance with the presently preferred method and system of the present invention is illustrated in FIG. 5. As shown and preferred in FIG. 5, upon receipt of the DROP TEMPLATE data base message 58, the local receiver data base 24 determines if the template number associated with the DROP TEMPLATE data base message 58 is in the template index 70 of the local receiver data base 24 since, if the template number is not present in the template index 70, then the DROP TEMPLATE message 58 is erroneous with respect to that local receiver data base 24 and an error message is provided. This function is represented by the blocks given reference numerals 122 and 124 in FIG. 5. Assuming the template number associated with the DROP TEMPLATE message 58 is present in the template index 70, a determination must then preferably be made as to whether there are any records stored in the local receiver data base 24 associated with this storage template number. In this regard, as previously mentioned, each stored record in the local receiver data base 24 has an associated storage template 42 which has a corresponding unique identifier or storage template number although a given storage template 42 may be associated with a plurality of different records 40 in the local receiver data base 24. This determination is represented by the block given reference numeral 126 in FIG. 5. If there are records 40 which have been stored in the local receiver data base 24 which are associated with the storage template number contained in the DROP TEMPLATE data base message 58, then each record 40 in the local receiver data base 24 having this associated storage template number is preferably dropped or deleted from the local receiver data base 24. This function is represented by reference numeral 128 in FIG. 5. In this instance, assuming that the record 40 is to be dropped, the process illustrated in FIG. 5 branches to the process illustrated and previously described with reference to FIG. 4 so that a determination is then made as previously explained, if the RIC is present in the record index 92 and, assuming it is, the record is removed from the local receiver data base 24 and the RIC is removed from the record index 92 as illustrated in FIG. 4. This procedure is preferably repeated for each record 40 associated with the template number contained in the DROP TEMPLATE data base message 58. In addition to dropping the records associated with this template number, as further shown and preferred in FIG. 5, the associated storage template 42 is also removed from the local receiver data base 24. This function is represented by the block given reference numeral 130 in FIG. 5. In addition, the template number or identifier is also removed from the template index 70 in the local receiver data base 24 which function is illustrated by the block given reference numeral 132 in FIG. 5. The processing of the DROP TEMPLATE message 58 is then completed, as represented by the block given reference numeral 134. In the instance where there are no records 40 stored in the local receiver data base 24 which are associated with the template number contained in the DROP TEMPLATE message 58, then what preferably occurs in response to DROP TEMPLATE message 58 is the removal of the storage template from the local receiver data base 24 and the removal of the template number form the template index 70, as also illustrated in FIG. 5. The above processing of a DROP TEMPLATE data base message 58 can also be described in terms of the following programming information format given below in Table F, which may readily be converted to PASCAL for use with the Digital Equipment Corporation MICROVAX:
TABLE F
__________________________________________________________________________
PROCESS --DROP --TEMPLATE --MSG
begin
GET-TPLNO (TPLNO)
if TEMPLATES [TPLNO] = 0 then
REPORT --ERROR ("ATTEMPTED DISCARD, TEMPLATE NOT DB")
else
I = 1
while I = TOTAL --NO --OF --RECS do record : = LOCATE --NEXT --
RECORD (I)
if RECORD.TPLATE = TPLNO THEN
DROP --RECORD (RECORD)
else
end
I = I + 1
end if
TEMPLATES [TPLNO] = 0
end
__________________________________________________________________________
"UPDATING A RECORD IN THE LOCAL RECEIVER DATA BASE" Up to this point we have described various data base messages which primarily relate to the construction of the local receiver data base 24, such as by incrementally increasing or decreasing the record content of the local receiver data base 24 as well as the associated storage template content used to decipher these records and for processing thereof. However, the bandwidth efficiencies of the presently preferred method and system of the present invention are most apparent in connection with the updating of a typical record 40 stored in the local receiver data base 24, particularly since each of the stored records 40 preferably contains multiple information fields, several or all of which may have to be updated at any given time. As generally explained above, through the use of a ripple chain of ripple fields and set identifiers along with the associated storage templates 42, updates can be provided in several information fields of a record without having to transmit a data base message having separate specified information for each information field to be updated. FIGS. 6A, 6B, 8, 9, 10, 11 and 12 all relate to this important updating function and shall be described in greater detail hereinafter at this time. The UPDATE RECORD data base message 54 is illustrated in block 54 in FIG. 6A. This update record data base message preferably contains a record identification code or RIC, a field identification code or FIC and a data content of update information for the information fields corresponding to the field identification code of the associated record 40 which corresponds to the record identification code. As was previously mentioned, this field identification code or FIC could consist of one or more field identifiers or FIDs, or one or more set identifiers or SIDs, or a combination of field identifiers and set identifiers. As was previously mentioned, a set identifier is really a bandwidth efficient way of transmitting information for a plurality of fields or field identifiers and, accordingly, the associated field identifiers or FIDs must be extracted from the transmitted set identifiers or SIDs at the local receiver data base 24. This extraction process shall be described in greater detail hereinafter with reference to FIG. 8. However, before doing that, we shall describe the updating of a record in the local receiver data base 24 for any given field identifier, with the understanding that the process is repeated for each field identifier defined in the UPDATE RECORD data base message 54, whether it is individually defined or whether it is defined as a result of a transmitted set identifier from which it must be extracted in accordance with the process illustrated in FIG. 8. Referring once again to FIG. 6A, the record identification code or RIC is extracted from the UPDATE RECORD data base message 54 at the local receiver data base 24, which is represented by the block given reference numeral 140 in FIG. 6A. A determination is then made as to whether the record identification code or RIC extracted from the UPDATE RECORD data base message 54 is present in the record index 92, which function is represented by the block given reference numeral 142 in FIG. 6A. If the RIC is not stored in the record index 92, then an error message is provided, which function is represented by the block given reference numeral 144, and the processing of the UPDATE RECORD data base message 54 at this particular local receiver data base 24 is terminated, as represented by the block given reference numeral 146 in FIG. 6B. If however, the RIC is present in the record index 92, then the template number is extracted from the record 40 already stored in the local receiver data base 24 as represented by the block given reference numeral 148 in FIG. 6A. UPDATE RECORD data base message 54 is then examined and the field identification code or FIC is then extracted from the UPDATE RECORD data base message 54, as represented by the block given reference numeral 150 in FIG. 6A. A determination is then made as to whether the field identification code which has been extracted represents a set identifier or SID, which is represented by the block given reference numeral 152 in FIG. 6A. If the field identification code does represent an SID then, as previously mentioned, the individual field identifiers or FIDs must be extracted from the set identifier or SID, which is preferably accomplished in the manner to be described with reference to FIG. 8, and then the processing continues for each extracted field identifier. Alternatively, if the extracted FIC does not represent an SID, then the processing continues of the UPDATE RECORD data base message 54 for that field identifier or FID. In either instance, the extracted field identifier or FID entry is located in the extracted storage template 42 which defines the field offset, the field length and the transmission encoding format or TEF. This is represented by the block given reference numeral 156 in FIG. 6A. It should be noted that the field offset is defined as the position of that field defined by the FID relative to the start of the affected record, with such an offset being illustrated in FIG. 12. The processing of the UPDATE RECORD data base message 54 continues with an examination of the ripple chain identifier or RIPFID for that extracted field identifier or FID in the associated storage template 42 contained in the local receiver data base 24, as represented by the block given reference numeral 158 in FIG. 6B. A determination is then made as to whether the RIPFID of the storage template 42 is 0 or not, which is represented by the block given reference numeral 160 in FIG. 6B, since, as previously described, the presence of a 0 would indicate either the end of a ripple chain or that no ripple chain at all were present. If the ripple chain identifier or RIPFID was not a 0, this would indicate the presence of a ripple chain to be processed in response to the UPDATE RECORD data base message 54 and the ripple would preferably be processed, as generally represented by the block given reference numeral 162 in FIG. 16, in a manner to be described in greater detail hereinafter with reference to FIGS. 9, 10 and 12. If, however, the ripple chain identifier is 0, or, alternatively after the ripple has been processed, if this identifier is 0, the next step in the processing of the UPDATE RECORD data base message 54 is to locate the position of the given field identifier or FID in the record 40 to be updated as indicated by the RIC content of the UPDATE RECORD data base message 54, with the FID position being located based on the field offset contained in the storage template 42. This function is illustrated by the block given reference numeral 164 in FIG. 6B. The transmission encoding format or TEF associated with that field identifier or FID is also determined from the storage template 42, as represented by the block given reference numeral 166 in FIG. 6B. Once the position of the field to be updated and the record is known, and the transmission encoding format is known so that the message can be deciphered, update information or data is transferred from the UPDATE RECORD data base message 54 to the stored record 40 appropriate information field corresponding to the FID using the associated transmission encoding format or TEF data transfer routine and field length, as illustration in FIG. 11. This function is represented by the block given reference numeral 168 in FIG. 6B and will be described in greater detail hereinafter with reference to FIGS. 11 and 12. In this regard it should be noted that the transmission encoding format or TEF defines the way the particular field is encoded in the UPDATE RECORD data base message 54. A determination is then made as to whether there is any other field identifier or FID to process in the UPDATE RECORD data base message 54 received by the local receiver data base 24. This is represented by the block given reference numeral 170 in FIG. 6B. If there is another field identifier to process, then the aforementioned process is preferably repeated at the point where the UPDATE RECORD data base message 54 is again examined and the next FIC or field identification code extracted, as represented by the block given reference numeral 150 in FIGS. 6A, with this process preferably being continually repeated until all field identifiers or FIDs present in the UPDATE RECORD data base message 54 are processed. When there are no more FIDs to process in the UPDATE RECORD data base message, the record transaction level number or RTL in the stored record 40 is preferably incremented to indicate that the record 40 has been updated. Thus, the RTL is a convenient way of being able rapidly examine the number of change messages applied to any given record 40 although it may be omitted, if desired, without departing from the spirit and scope of the present invention. This RTL number incrementing function is represented by the block given reference numeral 172 in FIG. 6B. A determination is then made as to whether any additional processing for the record 40 is required, as represented by the block given reference numeral 174 in FIG. 6B and, if such additional processing is required, it then preferably proceeds, as represented by reference the block given numeral 176 in FIG. 6B. In either instance, the processing of the UPDATE RECORD data base message 54 is thereafter terminated, as represented by the block given reference numeral 146. "EXTRACTION OF FIELD IDENTIFIERS FROM SET IDENTIFIERS" Referring now to FIG. 8, the extraction of the field identifiers or FIDs associated with a given set identifier or SID contained in an UPDATE RECORD data base message 54, and generally represented by the block given reference numeral 154 in FIG. 6A, shall now be described in greater detail. In this regard, the set identifier has to preferably be translated into the format of field identifier or FID followed by its associated data so that the processing of the UPDATE RECORD data base message 54 for each of the information fields to which the set identifier refers can take place. It should be noted that if the field identifiers or FIDs are of different value, then the set identifier definition will preferably consist of each field identifier separated by a data mark, which is a logical place keeper, whereas, if the field identifiers are of the same value, then the SID definition would preferably consist of all of the field identifiers adjacent to each other, with a data mark following the last field identifier. As was previously mentioned, the set identifier or SID can be used to define a one-to-one relationship in which for every field changed, a new value is in the message and is generally different, or can be used to define a one-to-many situation in which only one common piece of data in the message having a single value is put into several fields. In either instance, it should be noted that the order of data in the message is important since it preferably matches the order of fields as defined in the set identifier. In extracting the associated FIDs from the set identifier, the SID number must first preferably be extracted from the UPDATE RECORD data base message 54, as represented by the block given reference numeral 180 in FIG. 8. A determination is then made whether the SID number which has been extracted from the UPDATE RECORD data base message 54 is in the SID index stored at the local receiver data base 24. This function is represented by the block given reference numeral 182 in FIG. 8. If the extracted SID number is not in the SID index, then an error message is generated, as represented by the block given reference numeral 184 in FIG. 8. If, however, the SID number is contained in the SID index at the local receiver data base 24, then the SID definition associated with that SID number is extracted from the local receiver data base 24, as represented by the block given reference numeral 186 in FIG. 8. After the definition has been extracted, a determination is then made if the next item in the SID definition is a field identifier or FID or a data mark which function is represented by the block given reference numerals 188, 190, and 192 in FIG. 8. If it is not a field identifier, and is not a data mark, then the extraction process of FIG. 8 is terminated, as represented by the block given reference numeral 194. If, however, the item is a field identifier, then the next field identifier is preferably copied from the SID definition and the associated data is copied from the message, as represented by the block given reference numeral 196 in FIG. 8, and a determination is then made as to whether or not this is the end of the SID definition, as represented by the block given reference numeral 198. If it is the end of the SID definition, then the extraction process is terminated, as represented by the block given reference numeral 194. If, however, it is not the end of the SID definition, then the process preferably repeats, with a determination being made if the next item is a field identifier or a data mark, and with this process preferably continuing to loop until the end of the SID definition, as illustrated in FIG. 8. Similarly, if the item is not an FID, but is a data mark, then, as indicated in FIG. 8, the processing preferably moves to the next adjacent item in the message to determine if the next item is an FID or a data mark. This function is represented by the block given reference numeral 200 in FIG. 8. The processing is then preferably repeated until the end of the SID definition. It should be noted that if the same value is to be copied from the UPDATE RECORD data base message 54 into multiple information fields which correspond to the FIDs defined in the SID, then there is no data mark until the end, i.e., until all of the field identifiers have been defined. This causes the loop represented by the arrow 202 in FIG. 8 to repeat continually until the data mark is reached. Similarly, as described above, if there are different values for each of the FIDs then there will be a data mark after each FID and the processing will preferably continue in the manner of FIG. 8 until the last data mark is reached. The aforementioned processing of the UPDATE RECORD data base message 54 can also be defined in terms of a programming information format, which may readily be converted into PASCAL for running on the Digital Equipment Corporation MICROVAX computer with, this programming information format being given below in Table G:
TABLE G
__________________________________________________________________________
PROCESS --UPDATE --MSG
begin
GET --SIZE (MSG --SIZE)
GET --NAME (NAME)
STATUS - LOCATE --RECORD
IF STATUS = RECORD --LOCATED
then
UPDATE --LOCATED
else
REPORT --EPROM ("UPDATE FOR NONEXISTANT RECORD")
end
end
UPDATE --RECORD (MSG --INDEX)
begin
UPDATE --RECORD : = NO --ERROR
while (MSG --INDEX.LT.MSG --SIZE) and (UPDATE --RECORD = NO --ERROR)
STATUS : = GET --FIC (MSG --INDEX, CURR --FIC)
if STATUS = ERROR
then
REPORT --ERROR (FIC EXTENDS BEYOND END OF MESSAGE)
UPDATE --STATS
UPDATE --RECORD : = FIC --OVERRUN
else
if STATUS = FID --FOUND
then
CURR --FID : = CURR --FIC
UPDATING --BY --SID : = FALSE
FDAT --INDEX : = MSG -- INDEX + 2
else
CURR --SID : = CURR --FIC
UPDATING --BY --SID : = TRUE
FDAT --INDEX : = MSG --INDEX + 1
endif
if UPDATING --BY --SID
then
if CURR --SID = 0
then
CREATE --SID --0 ()
else
endif
STATUS : - LOCATE --FSD (CURR --SID)
if STATUS = ERROR
then
REPORT --ERROR (UNDEFINED SID IN MESSAGE)
UPDATE --STATS
UPDATE --RECORD : = UNDEFINED --SID
else
FSI : = 1 (Field Set Index)
GET --LOW --NIB TRUE
while (FSI.LT. FSDS [CURR --SID].FSETLEN
repeat
CURR --FID : = FSDS [CURR --SID].DATA [FSI]
PROCESS --MSG --FDAT (CURR --FID,
FDAT --INDEX,
FDAT --SIZE)
FSI : = FSI + 1
until FSDS [ CURR --SID].DATA[FISI] = DM
FDAT --INDEX : = FDAT --INDEX + FDAT --SIZE
endwhile
MSG --INDEX : = FDAT --INDEX FDAT --SIZE
PROCESS --MSG --FDAT (CURR --FID),
FDAT --INDEX,
FDAT --SIZE)
endif
endif
endwhile
end.
__________________________________________________________________________
"PROCESSING THE RIPPLE CHAIN" Referring now to FIGS. 9 and 10, the processing of the ripple chain, which is generally given reference numeral 162 in FIG. 6B, shall now be described in greater detail. As was previously mentioned, a ripple chain identifier or RIPFID refers to a ripple chain of related ripple fields which are all changed as a result of the change of a single information field or FID which has been updated based on the update data content for that field in the UPDATE RECORD data base message 54 without requiring the transmission of update information for each of the other ripple fields in the ripple chain, thereby resulting in considerable bandwidth efficiency. FIG. 9 generally illustrates the processing of the ripple function based on the determination that the ripple chain identifier or RIPFID of the storage template 42 associated with the UPDATE RECORD data base message 54 is not 0. In such an instance, the old data information content associated with the first FID in the ripple chain is extracted and the transmitted new or update information for that FID, which is contained in the UPDATE RECORD data base message 54, is then inserted in that first FID in the ripple chain. These functions are represented by the block given reference numerals 210 and 212 in FIG. 9. The next ripple field in the ripple chain is extracted from the ripple chain identifier or RIPFID in the storage template 42 for that UPDATE RECORD data base message 54, as represented by the block given reference numeral 214 in FIG. 9, and the old data is extracted from that next ripple field in the ripple chain, with the data extracted from the previous FID or ripple field in the ripple chain then being inserted in this ripple field. These functions are represented by the blocks given reference numerals 216 and 218 in FIG. 9. A determination is then made as to whether or not the RIPFID is now 0, which would indicate the end of the ripple chain. This is reprented by the block given reference numeral 220 in FIG. 9. If it is not 0, then the ripple processing preferably moves to the next FID in the ripple chain, as represented by the block given reference numeral 222, and the processing preferably continues in the manner previously described. If, however, the RIPFID is 0, then this is an indication that the ripple chain processing has been completed. It should be noted that the ripple fields in a ripple chain do not have to be in field sequence, but merely need be a different field so that the ripple chain could be field 1, field 2, field 6, and then field 4, for example, or field 1, 2, 3 and 4. Although the ripple chain effect has been generally discussed above, we shall discuss it further with respect to the illustration of FIG. 10, assuming that the ripple chain consists of four fields, FID 1, FID 2, FID 3 and FID 4, with the data information content of these fields being represented by the letters A, B, C, D and E and, for purpose of illustration, with the RIPFID identifiers in the ripple chain being represented by the numbers 2, 3, and 4, referring to FID 2, FID 3, and FID 4, respectively, and by the identifier 0 which, as previously described, indicates the end of the ripple chain. In the example of FIG. 10, the new data for FID 1, which is the FID indicated in the UPDATE RECORD data base message 54 in this example, is designated by the letter E. The old data information content of FID 1, which is designated by the letter A, is first extracted from FID 1 and, then, information E is inserted in its place. The RIPFID associated with FID 1 is then extracted from the RIPFID field, with this RIPFID pointing to FID 2. The old information content of FID 2, represented by the letter B, is then extracted from FID 2 and the information content A previously extracted from FID 1 is inserted in its place. The RIPFID associated with FID 2 is then extracted and, in the above example, points to FID 3. The old data content of FID 3, represented by letter C, is extracted from FID 3 and the previous information content of FID 2 represented by letter B, is inserted in its place. The RIPFID associated with FID 3 is then extracted and it points to FID 4. The old data content of FID 4, represented by the letter D, is extracted and the previous information content of FID 3, represented by letter C, is inserted in its place. The RIPFID associated with FID 4 is then extracted. Since in the above example it is a 0, this indicates the end of the ripple chain and the ripple processing is terminated. Since the old information D extracted from FID 4 is no longer to be used, in the above example, it is dropped. Thus, in order to process a ripple chain, all that the local receiver data base 24 need be sent, in the above example, is the new data for FID 1, such as the last trade price, and the associated storage template 42 for that RIC, contains the information which causes the processing of the ripple chain to occur, resulting in the updating of data in each of the other ripple fields of the ripple chain which are FID 2, FID 3, and FID 4 in the above example of FIG. 10. "TRANSFER OF DATA FROM AN UPDATE MESSAGE" Referring now to FIG. 11, the actual transfer of the data information content of an UPDATE RECORD data base message 54 shall be described. As was previously mentioned with reference to FIG. 6B, the transmission encoding format or TEF associated with a given field identifier or FID can be different, with five such possibilities from TEF=0 to TEF=4, being illustrated in FIG. 11. With respect to the condition when TEF=0, in the example of FIG. 11, this is assumed to be a transient field and you must therefore locate the next field in the message by using the length defined in the data portion of the message with the data associated with this transmission encoding format not being applied to the data base since it is a non-data base type of message. The presently preferred steps to be employed under this condition are illustrated in FIG. 11 by the blocks given reference numerals 300, 302, and 304, with reference numeral 300 referring to the determination of the TEF as being 0, and with reference numeral 302 referring to the subsequent determination of the length "L" of the data portion of the UPDATE RECORD data base message from the length field of the data portion of the update message, and with reference numeral 304 referring to the location of the next field in the message at a location of the determined length "L" plus one byte from the current position. As shown in FIG. 6B, after this position has been determined, the data is transferred from the UPDATE RECORD data base message to modify the old data in that field of the record at the determined position, as indicated by the block given reference numeral 168. If the TEF is not equal to 0, then a determination is made as to if the TEF is equal to 1 as represented by the block given reference numeral 306 in FIG. 11. Assuming that the TEF is equal to 1, then the length "L" of the data is determined from the length defined in the associated storage template 42 for that record 40 or RIC, as represented by the block given reference numeral 308 in FIG. 11. Based on this determination, "L" bytes are copied from the data portion of the UPDATE RECORD data base message 54 into the field or FID defined by the UPDATE RECORD data base message 54, as represented by the block given reference numeral 310. The next field in the message is then located at a position which is L+1 byte from the current position, as represented by the block given reference numeral 312 in FIG. 11 and the data is then transferred from the UPDATE RECORD data base message to modify the old data in that field of the record at the determined position. If the TEF is not equal 1, however, then a determination is made as to whether the TEF is equal to 2, as represented by the block given reference numeral 314 in FIG. 11. If the TEF is equal to 2, then the length "L" of the data portion of the message is determined from the length field of the data portion of the UPDATE RECORD data base message, as represented by the block given reference numeral 316. An offset X is then determined from the data portion of the UPDATE RECORD data base message, as represented by the block given reference numeral 318, with the offset X being illustrated in FIG. 12. The length "M" of the field is then determined from the length defined in the storage template 42 associated with the RIC of the UPDATE RECORD data base message, as represented by the block given reference numeral 320. A determination is then made as to whether this length "M" of the field is greater than or equal to length "L" of the data portion of the message plus the offset, as represented by the block given reference numeral 322. If it is not, an error message is generated, as represented by the block given reference numeral 324, and the processing is terminated, as represented by the block given reference numeral 326. If, however, this relationship is satified, then "L" bytes are copied from the data portion of the UPDATE RECORD data base message 54 into the field or FID defined by the UPDATE RECORD data base message 54 starting at offset position "X". Again, this relationship is illustrated in FIG. 12, with this function being represented by the block given reference numeral 328 in FIG. 11. After this has been accomplished, the next field in the message is located at location L+1 byte from the current position and the transfer of data from the UPDATE RECORD data base message to modify the old data in that field of the record occurs. If, however, the TEF is not equal to 2, then a determination is made as to whether the TEF is equal to 3, as represented by reference numeral 330 in FIG. 11. Assuming the TEF is equal to 3, the length "L" of the data portion of the message is determined from the size field of the data portion of the UPDATE RECORD data base message 54, as represented by the block given reference numeral 332 in FIG. 11. Thereafter, "L" bytes are copied from the data portion of the UPDATE RECORD data base message into the field or FID defined by the data base message 54, as represented by the block given reference numeral 334, and the next field in the message is located at location L+1 byte from the current position. The data is then transferred from the UPDATE RECORD data base message to modify the old data in that field of the record. Lastly, in the above example, if the TEF is not equal to 3, then a determination is made as to whether the TEF is equal to 4, as represented by the block given reference numeral 336. If it is not equal to 4, in the above example, then an error message is generated, as represented by the block given reference numeral 338, and the processing is terminated, as represented by the block given reference numeral 340. If, however, the TEF is equal to 4, this is indicative of the transmission of nibbles which are 4 bit data portions equal to half of a byte, with two nibbles being equal to a full byte. In such an instance, the four bit data portion or nibble of the UPDATE RECORD data base message 54 is copied into the field defined by the FID associated with this nibble, as represented by the block given reference numeral 342. A determination is then made as to whether the copied 4 bits are the first of a pair of 4 bit fields, as represented by the block given reference numeral 344. If it is the first four bits of a pair of four bit fields, then the next four bit data portion of the UPDATE RECORD data base message 54 is copied into the field defined by its FID as represented by the block given reference numeral 346, and the next field in the message is located at the current position plus one byte, as represented by the block given reference numeral 348, and data is transferred from the UPDATE RECORD data base message to modify old data in that field of the record at that position. Similarly, if the copied four bits are not the first of a pair of four bit fields, then a next step is to locate then the next field of the message at the current position plus one byte, as represented by the block given reference numeral 348, and to transfer data from the UPDATE RECORD data base message to modify old data in that field of the record at that position. The above processing described with reference to FIG. 11 can further be described in terms of a programming format information which can readily be converted into PASCAL for running on the Digital Equipment Corporation MICROVAX computer by way of example. Table H below illustrates this programming information format:
TABLE H
__________________________________________________________________________
PROCESS --MSG --FDAT (FID, FDAT --index, FDAT --SIZE)
begin
TEF : = TEMPLATES [M --C --B.TPLNO].DATA [FID].TEF
DIF : = TEMPLATES [M --C --B.TPLNO].DATA [FID].DIF
FLDLEN : = TEMPLATES [M --C --B.TPLNO].DATA [FID].FLDLEN
OFFSET : = TEMPLATES [M --C --B.TPLNO].DATA [FID].OFFSET
RIPFID : = TEMPLATES [M --C --B.TPLNO].DATA [FID].RIPFID
if (OFFSET = 0)
then
REPORT --WARNING (FID IN MESSAGE NOT DEFINED IN TEMPLATE)
UPDATE --STATS
ABORT --MSG : = TRUE
else
if (FLDLEN = 0)
then
REPORT --ERROR (FID NOT DEFINED IN TEMPLATE)
UPDATE --STATS
ABORT --MSG : = TRUE
else
case TEF of
TEF = 0 :
STATUS : = PROCESS --TEF0 --FDAT
TEF = 1 :
STATUS : = PROCESS --TEF1 --FDAT
TEF = 2 :
STATUS : = PROCESS --TEF2 --FDAT
TEF = 3 :
STATUS : = PROCESS --TEF3 --FDAT
TEF = 4 :
STATUS : = PROCESS --TEF4 --FDAT
endcase
endif
endif
end.PROCESS --TEF0 --FDAT
begin
FDAT --SIZE : = MS --MSG [FDAT --INDEX]
if (FDAT --INDEX + FDAT --SIZE.GT.(MSG --SIZE + 1)
then
PROCESS --TEF0 --FDAT : = MSG --FDAT --OVERRUN
ERROR --CODE : = FDAT --OVERRUN
REPORT --ERROR (FDAT EXCEEDS LENGTH OF MESSAGE)
else
endif
end.
PROCESS --TEF1 --FDAT
begin
FDAT --SIZE : = FLDLEN
if (FDAT --SIZE + FDAT --INDEX).GT.(MSG --SIZE + 1)
then
REPORT --ERROR (FIELD DATA EXTENDS BEYOND END OF MESSAG | ||||||