CA2078396A1 - Method of retrieving literal strings in a data processing system - Google Patents
Method of retrieving literal strings in a data processing systemInfo
- Publication number
- CA2078396A1 CA2078396A1 CA002078396A CA2078396A CA2078396A1 CA 2078396 A1 CA2078396 A1 CA 2078396A1 CA 002078396 A CA002078396 A CA 002078396A CA 2078396 A CA2078396 A CA 2078396A CA 2078396 A1 CA2078396 A1 CA 2078396A1
- Authority
- CA
- Canada
- Prior art keywords
- string
- stored
- tables
- entry
- data
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/90—Details of database functions independent of the retrieved data types
- G06F16/901—Indexing; Data structures therefor; Storage structures
- G06F16/9017—Indexing; Data structures therefor; Storage structures using directory or table look-up
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
- Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10S707/00—Data processing: database and file management or data structures
- Y10S707/99951—File or database maintenance
- Y10S707/99952—Coherency, e.g. same view to multiple users
- Y10S707/99954—Version management
Abstract
METHOD OF RETRIEVING LITERAL STRINGS
IN A DATA PROCESSING SYSTEM
ABSTRACT OF THE DISCLOSURE
A method is provided for retrieving and outputting literal strings in a data processing device. The strings are stored in the device's memory in the form of two or more tables.
A directory of the tables is generated. When a literal string is needed, the directory is searched for an appropriate table; when an appropriate table is found, the table is searched for the needed string.
When a string or table is to be corrected or superseded, a later table is stored in the memory. An updated directory is assembled. The updated directory is arranged so that the later table is searched before the corrected or superseded table.
IN A DATA PROCESSING SYSTEM
ABSTRACT OF THE DISCLOSURE
A method is provided for retrieving and outputting literal strings in a data processing device. The strings are stored in the device's memory in the form of two or more tables.
A directory of the tables is generated. When a literal string is needed, the directory is searched for an appropriate table; when an appropriate table is found, the table is searched for the needed string.
When a string or table is to be corrected or superseded, a later table is stored in the memory. An updated directory is assembled. The updated directory is arranged so that the later table is searched before the corrected or superseded table.
Description
2 ~
~-796 M~THOD OF RETRIEVING LITERAL STRINGS
IN A DATA PROCESSING SYSTEM
Related Ap~lication Reference is made to application Serial Number ~Attorney docket no. C-795), entitled "Method of Retrieving Variable Values in a Data Processing System", filed contemporaneously with this application.
Field of the Invention This invention relates to data processing devices and more particularly to such devices that output strings of alphanumeric characters.
Backaround of_the Invention It is well known for a data processing device to communicate with a user of the device by outputting a string of alphanumeric characters. An example of such a device is a parcel processing system of the type disclosed in U.S. Patent Nos. 5,024,282 and 5,009,276. A parcel processing system commonly includes a display by which alphanumeric prompt messages are output to guide the user in operation of the system. Such a system also frequently includes a printer through which the system outputs reports, parcel manifests and so forth. The reports usually comprise headings, subheadings, and/or page footers that are made up of strings of alphanumeric characters. The character strings making up the prompts, headings and other texts just described are typically stored in the system's memory and accPssed as needed by the system's application program. Various methods of storing the strings have been used. For example, the strings may simply be embedded at appropriate places in the program code. It is also known to store the strings separately from the code and to generate a table that identifies the address at which each string is stored. The . : : ~ , .;: ,, -:
-,,, ,~
, . .
2~8~'`3~
program then refers to the table when a particular string is required to be output.
It is also known to use strings of characters to control certain operations of a data processing device. For instance, a ch~racter string may comprise a "script" that provides format and other informatlon required for generation of a report. A character string may also constitute a series of commands that controls an operating sequence or set up o the device.
Although prior art methods have been useful for their intended purposes, it is desirable to provide more flexible methods of storing and retrieving character strings, particularly in view of the need to ~ake changes to output te~ts or control strings after the devi~e has been placed at a user's location. Such changes may include correcting of errors, adding of new functions, changing report formats or adding new reports, or increasing the number of natural languages in which the device is able to communicate with the user.
Summary of the Invention According to the invention, a method of retrieving a literal string is provided in a data processing device. The device has a memory and an output mechanism. The memory incl~ldes a plurality of locations. The method includes the steps of:
(a) storing a plurality of literal strings in the memory, each of the strings being stored in one of the locations, each of the locations having an address;
(b) storing in the memory a plurality of tables, each of the tables having data identifying some of the stored strings and addresses of the respective locations in which the strings are stored;
(c) assembling a directory of the stored tables, the directory having a pl~rality o~ entries, each of which corresponds to one of the stored tables;
(d) receiving a request to locate one of the literal strings, the request having at least one request parameter;
2 ~ ~ ~ 3 ~ ~
(e) searching the directory for an entry that matches the at least one request parameter;
(f) upon finding such an entry, searching the stored table corresponding to the matching entry for the identifying data corresponding to the requested string; and (g) upon finding the corresponding data, accessing the re~uested string.
According to one aspect of the invention, the entries include one or more entry parameters, the entry parameters include a version number for the corresponding tables, and the step of assembling the directory includes sorting the entries by version number.
According to a further aspect of the invention the sorting of entries is performed so that entries for more recent tables are listed earlier in the directory than less recent tables, and the searching of the directory proceeds in order through the directory, so that more recent tables are searched before less recent tables. Accordingly, a literal string may be updated or changed by storing a more recent table in the memory.
Brief DescriPtion of the Drawinqs Fig. 1 is a block diagram of a device using the method of the subject invention.
Fig. l-A is a semi-schematic front view of a system comprising the device of Fig. 1.
Fig. 2 is a flow chart of an initialization routine for assembling a literal table directory in accordance with the invention.
Figs. 3-A, 3-B and 3-C are a flow chart of a routine for handling a literal string retrieval request in accordance with the invention.
Detailed Description of the Invention Referring to Fig. l, data processing device 10 is illustrated by means of a block diagram and preferably takes the form of a control module for a parcel processing system.
Device 10 includes CPU 12, which may be an Intel model 80188 - microprocessor. CPU 12 is operatively connected, via an . ~ , .': ' ,,;, '',' ' .. , . ~
': ~ . . ,: ;~ '' ' .,.' ' ;' h ~ 7 8 ~ ~ ~
appropriate interface, to display 14, which i5 preferably a conventional bit-mapped liquid crystal display. other types of displays may also be used.
CPU 12 is also operatively connected, by means of an appropriate interface, to Xeyboard 16, which may be used, in a preferred embodiment, to enter carrier selection commands, parcel data, menu selections, and other functions associated with operation o~ a parcel processing system. Also operatively connected to CPU 12 i5 a clock/calendar module 18 which provides to CPU 12 signals indicative of the current date and time.
Memory elements addressable by CPU 12 include PROMS 20, which preferably include fourteen PROMS, each having a capacity of 64X bytes and mounted two each on seven PROM
paddles that are detachably connected to device 10 by conventional means.
PROMS 20 store the object code for the device's operating system and also for the application program that causes the device to perform its desired functions. Also typically stored in PROMS 20 are rate tables for one or more parcel carriers, zip to zone conversion data, and a directory of the system functions available to the user.
Alternatively, some of the data, such as the directory and the zip to zone data, may be downloaded to RAM 22 from a PROM 20 that is subsequently detached from device 10.
RAM 22 is also addressable by CPU 12 and preferably comprises two 128K battery-backed-up CMOS RAM devices. Of these, 128K RAM device 22-2 is connected to CPU 12 through switching logic device 24. Switching logic 24 also connects CPU 12 to two PROMS 20-7 mounted on the seventh PROM paddle.
Switching logic 24 allows RAM 22-2 and PROMS 20-7 to share the same 128K of CPU 12's address space, thereby making accommodation to the limited address space available to CPU
12.
EEPROM 26 is also operatively connected to, and addressable by, CPU 12. EEPROM 26 mav be used to store such data as a device serial number, or user passwords and, if device 10 is used as a parcel register, accounting data such as an ascending or descending register.
_ ~ _ - : . . . . . , - : .
~7~3~
It will be appreciated that device 10 may alternatively be designed with larger or smaller quantities of memory elements and that the memory elements may be configured in a variety of ways, and that the proportions of RAM, PROMS and EEP~OMS may be varied and that some of the memory elements may be dispensed with entirely. It will also be appreciated that switching logic 24 may also be dispensed with if 1024K
or less of memory is to be addressed or if CPU 12 is capable of addressing a larger memory space.
Communication ports 2~ are also operatively connected to CPU 12. Ports 28 may be used for communication between data processing device 10 and peripheral devices. Ports 28 preferably include an Echoplex port for communication with a postage meter ~see U.S. Pat. No. 4,301,507 for a description of Echoplex communication), a parallel port for communication with a line printer, a serial port for communication with a label printer, and a second serial port for communication with a scale. Ports 28 may also be used for communication with other peripheral devices or with other data processing systems.
Referring now to Fig. l-A, a parcel processing system 30 is shown in schematic form. System 30 includes data processing device 10, which includes display 14 and keyboard 16 and which is connected via appropriate cabling 32 to platform scale 34 and line printer 36. Scale 34 weighs a parcel that is to be shipped and transmits weight data to device 10. Device 10 uses the weight data to calculate a shipping charge for the parcel.
Printer 36 may be used to print, for example, manifests that are submitted to a parcel carrier along with a group of parcels that are to be shipped via the carrier. As another example, printer 36 may print reports summarizing shipping activities performed by system 30. Also, as is known to those skilled in the art, printer 36 may be of the type that is adaptable to printing labels as well as reports.
System 30 may also include other peripherals, which are not shown, such as a postage meter, a bar code scanner, and one or more additional printers.
, .
. . :
2~73~
Although device 10 is shown as a separately housed control module for system 30, it is of course possible to physically integrate some or all of the components of a parcel processing system. For example, it is well known to combine a scale and control module in a single housing. It is within the contemplation of the invention to use the method disclosed herein in such integrated hardware.
Turning now from an overview of system 30 and device 10 to particulars of information stored in PROMS 20, it will be understood that PROMS 20 store the object code for the device~s operating system and also for the application program that causes the device to perform its desired functions. Also typically stored in PROMS 20 are rate tables for one or more parcel carriers, zip to zone conversion data, and a directory of the system functions available to the user. It has also been known to store, in various forms, literal character strings to be used in generating (a) prompt messages, error messages and other texts to be displayed on display 14 and (b) headings and other texts that make up part of reports to be printed by printer 36.
According to the invention, the literal strings needed by system 30 are stored in the form of tables in PROMS 20.
These tables will sometimes be referred to as "literal tables". As illustrated in the following chart, each table consists of three parts: a header, a sequence of string locating data pairs, and then the literal strings themselves.
, :
: . ~ - , : :: . : . . ~ . :
.
~ ~ 7 ~
HEADER
*****~**
TAG I.D.
OFFSET
TAG I.D.
OFFSET
TAG I.D.
OFFSET
*******
[string 13 [string 2.]
[string N]
*******
The table header is at the beginnin~ of the table and serves to identify the table. Typically the header includes the following parameters: TABLE I.D.; CARRIER; LANGUAGE;
REVISION NO. It will be understood that each of these parameters may simply be a code number, such as a two-digit hexadecimal integer, that represents a certain value of the parameter. Typically values of the 'TABLE I.~.' could be 'error messages', 'report headers', '~ystem promptst, etc., each represented hy a different code number.
Similarly, ~or the 'CA~RIER' parameter, '01' may represent the U.S. Postal Service, '02' may represent United Parcel Service, 'G3' may represent Airborne Express, and so forth. Preferably the last code; 'FF' is reserved for 'carrier independent' as will be explained in more detail below.
- . ~ , ,, ~J~
For the 'LANGUAGE' parame~er, '01' may represent 'English', '02' may represent 'French', '03 may represent 'Spanish' and so forth. ~s before 'FF' is reserved for 'language independent' as will be explained below.
The 'REVISION NO.' parameter is simply a number that indicates the version or revision number of the table. As will be discussed below, the revision number will be assigned in the order of issuance, e.g., '00', '01' and so forth, or date stamped, such as '910515','911010', etc., or time stamped.
As will be appreciated by those skilled in the art, all headers may contain or start with a particular character or sequence of characters that identifies the header as a literal table header.
Following the header are data pairs. There is one data pair for each string stored in the third part of the table.
Each data pair consists of a 'TA~ I.D.' that identifies the corresponding string and an offset, which is a number from which may be calculated the address or location of the ; 20 corresponding string's location. As will be understood by those skilled in the art, there are a number of possible offset conventions. In a preferred approach to the invention, the offset is a number which, when added to the - address of the first memory location af~er the header ~i.e.
the location of the first 'TAG I.D.'), yields the address of the memory location in which is stored the first character of ; the corresponding string.
As may be inferred ~rom the foregoing, the literal strings corresponding to the data pairs are stored one after the other immediately following the last data pair.
Preferably the end of each string is marked by a delimiting character~ As will be well understood by those skilled in the art, each string is stored in a memory location, or, more precisely, in a series of memory locations equal in number to the number of characters in the string (including the delimiting character~. As i5 also well understood, each memory location has associated with it an address, and each string may be accessed by means of th~ address of the memory location in which the first character of the string is , ,: -:::: :
~ ~ P~
stored. It may therefore be said that each string is stored in a memory location and that each memory location has an address, which is in effect the address of the first character's location.
While the literal table structure as just described is preferred since it preserves flexibility in the use of PROM
~emory space, it will be appreciated that a variety of other structures are possible. For instance, the second item of each data pair could be the absolute address of the corresponding string rather than an offset from which the address is to be calculated. As another alternative, the string section of the table could be detached from the rest of the table and the strings stored at another location or locations in the PROM or PROMS. In this case, of course, another offset convention may be used instead of the preferred convention described above, or as just mentioned, the absolute address could be included in the data pair instead of an offset.
There will now be described with reference to Fig. 2 a program initialization routine in which device 10 builds and stores a directory o~ all literal tables stored in PROMs 20.
The routine of Fig. 2 is preferably part of an initialization process that is performed each time system 30 is "powered up", i.e. turned on. Alternatively, the routine may also be performed whenever a PROM 20 is attached to or detached from device 10, if the process of detaching or attaching a PROM
does not include turning the system off and on.
The routine begins with step 100, at which all of PROMS
20 are searched for literal tables and a list Gf the tables and their locations is returned. Next follows step 102, at hich the number of tables in the list is counted. The number of tables needs to be determined in order to request the appropriate quantity of memory space for the literal table directory.
Next follows step 104, at which the required quantity of memory is requested for the literal table directory.
Step 106 follows step 104. At step 106 the directory is built while eliminating duplicate entries. It will be ~ understood that duplicates can be eliminated by comparing , '3) ~
each entry against every entry that has previously been added to the directory and not adding the current entry if it duplicates a preceding entry.
It should be noted that each entry includes the parameters of the heading of the corresponding table (e.g.
TABLE I.D.; CARRIER; LANGUAGE; REVISION NO.) plus the location of the corresponding table.
Step 108 follows step 106. At step 108 the directory is sorted. Preferably the entries are sorted according to three criteria. The first criterion is the value of the 'CARRIER' parameter. The second criterion is the value of the 'LANG~IAGE' parameter and the third criterion is the value of the 'REVISION NO.' parameter. It will be appreciated that both the entries parameters may be sorted in accordance with the hexadecimal number value of the parameter for each entry, which will cause in each case the 'FF' entries to be sorted to the end. Thus the 'carrier independent' or 'language independent' table entries will follow the entries that are specific to a carrier or a language. As to the sortation of revision numbers, the sortation scheme is such that the most recently revised and issued tables will appear in the ; directory ahead of less recent tables. This may be done by issuing ascending revision numbers and then sorting in reverse order of revision number or by issuing 'FF' as the ;25 first number and then issuing subsequent revision numbers in descending order.
According to a preferred method of performing the invention, no sortation by 'TABLE' is reguired.
Upon completion of step 108 a properly sorted literal table directory has been stored in the memory, preferably in battery-backed-up RAM 22, of device 10. The routine of Fig.
2 then ends with a return to the balance of the initialization procedure.
Referring now to Figs. 3-A, 3-B and 3-C, there will be - 35 described a program routine for using the literal table directory to respond to a literal re~uest and output the required character string.
This routine begins at step 200 with the receipt of a literal request from one or another of the functions making : - : ., .,, : : .
~ ;: , i . . . ~
S~
up the applications program. For example, if a report is being generated, the request may be for a report heading that is needed for the report. Alternatively, if the system needs to respond to ~eyboard entry of data with a prompt message or an error message to be displayed on display 14, the request is for the s~ring making up the text of the prompt message or error message.
The request as received preferably contains the following request parameters: TAG; LANGUAGE; CARRIER; TABLE;
RETURN ADDRESS. It should be appreciated that, in an alternative embodiment of the invention not all of these parameters will need to be specified in every request. For instance, some reports that are printed have nothing to do with any carrier, in which case the carrier parameter may well be omitted. The TAG parameter is to identify the particular string that is ~equired. The LANGUAGE parameter either specifies a language or, by an appropriate code, indicates that the language is to be whatever language has been selected by the operator for operation of the system.
The CARRIER parameter will of course be used to identify prompts that are specific to a gi~en carrier and the TABLE
parameter will, together with the TAG parameter, identify the desired tag. The RETURN ADDRESS parameter will indicate the memory location to which the pointer to the appropriate string's address is to be sent.
Following step 200 is step 202 at which it is determined whether the value of the LANGUAGE request parameter is equal to 'currently selected language'. If not, the specified value of the 'LANGUAGE' request parameter is used in searching the directory (step 204). Otherwise, the currently selected language is used as the value of the parameter for the purpose of searching the directory (step 206)o Following step 206 or 204, as the case may be, is step 208, at which it is determined whether there are any more entries in the directory. If so (as would usually be the case at the first time the routine reaches step 208), step 210 follows, at which the current entry is set ~o be the next entry in the directory (which the first time through would be the first entry). Following step 210 is step 212, at which it is .
:
..
s~ ~ r) ~ 3 determined whether the 'CARRIER' parameter of the entry matches the requested value of the 'CARRIER' parameter. If not, the routine cycles back to step 208.
If at step 208 no more entries are found in the directory, an error message is sent (step 214) and the routine ends). If there are more entries, the routine will continue to cycle through steps 208, 210 and 212 until a match in the 'CARRIER' parameter is found. Once this occurs, step 212 is ~ollowed by step 216, at which it is determined whether the 'L~NGUAGE' parameter of the entry matches the requested value of the 'LANGUAGE' parameter. If there is no match at step 216 again the routine returns to step 208. If there is a match at step 216, the routine proceeds to step 218, at which is determined whether the 'TABLE' parameter of the directory entry matches the requested ~alue of the ~ 'TABI.E' parameter. Again, if not the routine returns to step `~ 208. It will be recognized that the routine will accordingly continually cycle through step 208 until a directory entry matches the requested values all three of the 'CARRIER', 'LANGUAGE' and 'TABLE' parameters or until there are no more entries in the directory. Assuming an entry matching all ~` three parameters is found, then step 220 will follow step 218. At step 220, the table corresponding to the matching entry will be searched for the requested tag I.D.. It is then determined, at step 222, whether the requested tag I.D.
is found in that table. If not, an error message is sent (step 214) and the routine ends. Otherwise, the offset that constitutes the second part of the data pair of which the requested tag I~D~ is the first part is used to calculate a pointer to the desired string and that pointer is then returned to the return address specified in the request (step 224). The routine then ends.
It will be seen, then, that upon completion of step 224 the function that sent the literal request has access to the requested literal and may, as appropriate, output the literal string or use the string for control or processing purposes.
Although the implications of th~ routines discussed in connection with Figs. 2, 3-A, 3-B and 3-C will generally be .
;
. ~
; ~
r ~g3 understood by those skilled in the art, it is worthwhile to note some of the implications in detail.
As is well known to those skilled in the art, it is frequently necessary to update the carrier rate data stored in PROMs 20 of system 30. The well known method by which this is accomplished is mailing an updated rate PROM board to the user of system 30. The user or a service representative then detaches a PROM board from device 10 and replaces it with the updated rate PROM board.
Suppose now that a typographical error is discovered in a character string stored in a literal table stored on any of PROMs 20. For purposes of illustration we will refer to that literal table as TABLE A, Rev. 1 t where "TABLE A" will be understood to include all the parameters required to identify the table other than 'REVISION NO.' If it is desired to correct the erroneous string all that is required is to include on the next rate update PROM a literal table in the following form:
TABLE A, REV. 2 ******
` TAG I.D.
OFFSET
*******
(corrected string) ******
(It will be assumed that no revisions to Table A have been previously issued since Rev. l. It will also be understood that the TAG I.D. immediately following the header of TABLE
A, Rev. 2 corresponds to the string that is to be corrected.) Upon reinitialization of system 30 after installation of the update PROM, a literal table directory will be generated and stored in accordance with the routine of Fig. 2. As a result of that routine, and particularly step 108, the literal table directory will include an entry for TABLE A, REV. 2 immediately before the entry for TABLE A, REV. 1.
Subsequently when the string in question is to be output, an appropriate literal request w:ill be received (Fig. 3-A, step 200), the entry for TABLE A, REV. 2 will be matched (Fig.
, ~
' ' ' . ':: . . , ~g~
~-796 M~THOD OF RETRIEVING LITERAL STRINGS
IN A DATA PROCESSING SYSTEM
Related Ap~lication Reference is made to application Serial Number ~Attorney docket no. C-795), entitled "Method of Retrieving Variable Values in a Data Processing System", filed contemporaneously with this application.
Field of the Invention This invention relates to data processing devices and more particularly to such devices that output strings of alphanumeric characters.
Backaround of_the Invention It is well known for a data processing device to communicate with a user of the device by outputting a string of alphanumeric characters. An example of such a device is a parcel processing system of the type disclosed in U.S. Patent Nos. 5,024,282 and 5,009,276. A parcel processing system commonly includes a display by which alphanumeric prompt messages are output to guide the user in operation of the system. Such a system also frequently includes a printer through which the system outputs reports, parcel manifests and so forth. The reports usually comprise headings, subheadings, and/or page footers that are made up of strings of alphanumeric characters. The character strings making up the prompts, headings and other texts just described are typically stored in the system's memory and accPssed as needed by the system's application program. Various methods of storing the strings have been used. For example, the strings may simply be embedded at appropriate places in the program code. It is also known to store the strings separately from the code and to generate a table that identifies the address at which each string is stored. The . : : ~ , .;: ,, -:
-,,, ,~
, . .
2~8~'`3~
program then refers to the table when a particular string is required to be output.
It is also known to use strings of characters to control certain operations of a data processing device. For instance, a ch~racter string may comprise a "script" that provides format and other informatlon required for generation of a report. A character string may also constitute a series of commands that controls an operating sequence or set up o the device.
Although prior art methods have been useful for their intended purposes, it is desirable to provide more flexible methods of storing and retrieving character strings, particularly in view of the need to ~ake changes to output te~ts or control strings after the devi~e has been placed at a user's location. Such changes may include correcting of errors, adding of new functions, changing report formats or adding new reports, or increasing the number of natural languages in which the device is able to communicate with the user.
Summary of the Invention According to the invention, a method of retrieving a literal string is provided in a data processing device. The device has a memory and an output mechanism. The memory incl~ldes a plurality of locations. The method includes the steps of:
(a) storing a plurality of literal strings in the memory, each of the strings being stored in one of the locations, each of the locations having an address;
(b) storing in the memory a plurality of tables, each of the tables having data identifying some of the stored strings and addresses of the respective locations in which the strings are stored;
(c) assembling a directory of the stored tables, the directory having a pl~rality o~ entries, each of which corresponds to one of the stored tables;
(d) receiving a request to locate one of the literal strings, the request having at least one request parameter;
2 ~ ~ ~ 3 ~ ~
(e) searching the directory for an entry that matches the at least one request parameter;
(f) upon finding such an entry, searching the stored table corresponding to the matching entry for the identifying data corresponding to the requested string; and (g) upon finding the corresponding data, accessing the re~uested string.
According to one aspect of the invention, the entries include one or more entry parameters, the entry parameters include a version number for the corresponding tables, and the step of assembling the directory includes sorting the entries by version number.
According to a further aspect of the invention the sorting of entries is performed so that entries for more recent tables are listed earlier in the directory than less recent tables, and the searching of the directory proceeds in order through the directory, so that more recent tables are searched before less recent tables. Accordingly, a literal string may be updated or changed by storing a more recent table in the memory.
Brief DescriPtion of the Drawinqs Fig. 1 is a block diagram of a device using the method of the subject invention.
Fig. l-A is a semi-schematic front view of a system comprising the device of Fig. 1.
Fig. 2 is a flow chart of an initialization routine for assembling a literal table directory in accordance with the invention.
Figs. 3-A, 3-B and 3-C are a flow chart of a routine for handling a literal string retrieval request in accordance with the invention.
Detailed Description of the Invention Referring to Fig. l, data processing device 10 is illustrated by means of a block diagram and preferably takes the form of a control module for a parcel processing system.
Device 10 includes CPU 12, which may be an Intel model 80188 - microprocessor. CPU 12 is operatively connected, via an . ~ , .': ' ,,;, '',' ' .. , . ~
': ~ . . ,: ;~ '' ' .,.' ' ;' h ~ 7 8 ~ ~ ~
appropriate interface, to display 14, which i5 preferably a conventional bit-mapped liquid crystal display. other types of displays may also be used.
CPU 12 is also operatively connected, by means of an appropriate interface, to Xeyboard 16, which may be used, in a preferred embodiment, to enter carrier selection commands, parcel data, menu selections, and other functions associated with operation o~ a parcel processing system. Also operatively connected to CPU 12 i5 a clock/calendar module 18 which provides to CPU 12 signals indicative of the current date and time.
Memory elements addressable by CPU 12 include PROMS 20, which preferably include fourteen PROMS, each having a capacity of 64X bytes and mounted two each on seven PROM
paddles that are detachably connected to device 10 by conventional means.
PROMS 20 store the object code for the device's operating system and also for the application program that causes the device to perform its desired functions. Also typically stored in PROMS 20 are rate tables for one or more parcel carriers, zip to zone conversion data, and a directory of the system functions available to the user.
Alternatively, some of the data, such as the directory and the zip to zone data, may be downloaded to RAM 22 from a PROM 20 that is subsequently detached from device 10.
RAM 22 is also addressable by CPU 12 and preferably comprises two 128K battery-backed-up CMOS RAM devices. Of these, 128K RAM device 22-2 is connected to CPU 12 through switching logic device 24. Switching logic 24 also connects CPU 12 to two PROMS 20-7 mounted on the seventh PROM paddle.
Switching logic 24 allows RAM 22-2 and PROMS 20-7 to share the same 128K of CPU 12's address space, thereby making accommodation to the limited address space available to CPU
12.
EEPROM 26 is also operatively connected to, and addressable by, CPU 12. EEPROM 26 mav be used to store such data as a device serial number, or user passwords and, if device 10 is used as a parcel register, accounting data such as an ascending or descending register.
_ ~ _ - : . . . . . , - : .
~7~3~
It will be appreciated that device 10 may alternatively be designed with larger or smaller quantities of memory elements and that the memory elements may be configured in a variety of ways, and that the proportions of RAM, PROMS and EEP~OMS may be varied and that some of the memory elements may be dispensed with entirely. It will also be appreciated that switching logic 24 may also be dispensed with if 1024K
or less of memory is to be addressed or if CPU 12 is capable of addressing a larger memory space.
Communication ports 2~ are also operatively connected to CPU 12. Ports 28 may be used for communication between data processing device 10 and peripheral devices. Ports 28 preferably include an Echoplex port for communication with a postage meter ~see U.S. Pat. No. 4,301,507 for a description of Echoplex communication), a parallel port for communication with a line printer, a serial port for communication with a label printer, and a second serial port for communication with a scale. Ports 28 may also be used for communication with other peripheral devices or with other data processing systems.
Referring now to Fig. l-A, a parcel processing system 30 is shown in schematic form. System 30 includes data processing device 10, which includes display 14 and keyboard 16 and which is connected via appropriate cabling 32 to platform scale 34 and line printer 36. Scale 34 weighs a parcel that is to be shipped and transmits weight data to device 10. Device 10 uses the weight data to calculate a shipping charge for the parcel.
Printer 36 may be used to print, for example, manifests that are submitted to a parcel carrier along with a group of parcels that are to be shipped via the carrier. As another example, printer 36 may print reports summarizing shipping activities performed by system 30. Also, as is known to those skilled in the art, printer 36 may be of the type that is adaptable to printing labels as well as reports.
System 30 may also include other peripherals, which are not shown, such as a postage meter, a bar code scanner, and one or more additional printers.
, .
. . :
2~73~
Although device 10 is shown as a separately housed control module for system 30, it is of course possible to physically integrate some or all of the components of a parcel processing system. For example, it is well known to combine a scale and control module in a single housing. It is within the contemplation of the invention to use the method disclosed herein in such integrated hardware.
Turning now from an overview of system 30 and device 10 to particulars of information stored in PROMS 20, it will be understood that PROMS 20 store the object code for the device~s operating system and also for the application program that causes the device to perform its desired functions. Also typically stored in PROMS 20 are rate tables for one or more parcel carriers, zip to zone conversion data, and a directory of the system functions available to the user. It has also been known to store, in various forms, literal character strings to be used in generating (a) prompt messages, error messages and other texts to be displayed on display 14 and (b) headings and other texts that make up part of reports to be printed by printer 36.
According to the invention, the literal strings needed by system 30 are stored in the form of tables in PROMS 20.
These tables will sometimes be referred to as "literal tables". As illustrated in the following chart, each table consists of three parts: a header, a sequence of string locating data pairs, and then the literal strings themselves.
, :
: . ~ - , : :: . : . . ~ . :
.
~ ~ 7 ~
HEADER
*****~**
TAG I.D.
OFFSET
TAG I.D.
OFFSET
TAG I.D.
OFFSET
*******
[string 13 [string 2.]
[string N]
*******
The table header is at the beginnin~ of the table and serves to identify the table. Typically the header includes the following parameters: TABLE I.D.; CARRIER; LANGUAGE;
REVISION NO. It will be understood that each of these parameters may simply be a code number, such as a two-digit hexadecimal integer, that represents a certain value of the parameter. Typically values of the 'TABLE I.~.' could be 'error messages', 'report headers', '~ystem promptst, etc., each represented hy a different code number.
Similarly, ~or the 'CA~RIER' parameter, '01' may represent the U.S. Postal Service, '02' may represent United Parcel Service, 'G3' may represent Airborne Express, and so forth. Preferably the last code; 'FF' is reserved for 'carrier independent' as will be explained in more detail below.
- . ~ , ,, ~J~
For the 'LANGUAGE' parame~er, '01' may represent 'English', '02' may represent 'French', '03 may represent 'Spanish' and so forth. ~s before 'FF' is reserved for 'language independent' as will be explained below.
The 'REVISION NO.' parameter is simply a number that indicates the version or revision number of the table. As will be discussed below, the revision number will be assigned in the order of issuance, e.g., '00', '01' and so forth, or date stamped, such as '910515','911010', etc., or time stamped.
As will be appreciated by those skilled in the art, all headers may contain or start with a particular character or sequence of characters that identifies the header as a literal table header.
Following the header are data pairs. There is one data pair for each string stored in the third part of the table.
Each data pair consists of a 'TA~ I.D.' that identifies the corresponding string and an offset, which is a number from which may be calculated the address or location of the ; 20 corresponding string's location. As will be understood by those skilled in the art, there are a number of possible offset conventions. In a preferred approach to the invention, the offset is a number which, when added to the - address of the first memory location af~er the header ~i.e.
the location of the first 'TAG I.D.'), yields the address of the memory location in which is stored the first character of ; the corresponding string.
As may be inferred ~rom the foregoing, the literal strings corresponding to the data pairs are stored one after the other immediately following the last data pair.
Preferably the end of each string is marked by a delimiting character~ As will be well understood by those skilled in the art, each string is stored in a memory location, or, more precisely, in a series of memory locations equal in number to the number of characters in the string (including the delimiting character~. As i5 also well understood, each memory location has associated with it an address, and each string may be accessed by means of th~ address of the memory location in which the first character of the string is , ,: -:::: :
~ ~ P~
stored. It may therefore be said that each string is stored in a memory location and that each memory location has an address, which is in effect the address of the first character's location.
While the literal table structure as just described is preferred since it preserves flexibility in the use of PROM
~emory space, it will be appreciated that a variety of other structures are possible. For instance, the second item of each data pair could be the absolute address of the corresponding string rather than an offset from which the address is to be calculated. As another alternative, the string section of the table could be detached from the rest of the table and the strings stored at another location or locations in the PROM or PROMS. In this case, of course, another offset convention may be used instead of the preferred convention described above, or as just mentioned, the absolute address could be included in the data pair instead of an offset.
There will now be described with reference to Fig. 2 a program initialization routine in which device 10 builds and stores a directory o~ all literal tables stored in PROMs 20.
The routine of Fig. 2 is preferably part of an initialization process that is performed each time system 30 is "powered up", i.e. turned on. Alternatively, the routine may also be performed whenever a PROM 20 is attached to or detached from device 10, if the process of detaching or attaching a PROM
does not include turning the system off and on.
The routine begins with step 100, at which all of PROMS
20 are searched for literal tables and a list Gf the tables and their locations is returned. Next follows step 102, at hich the number of tables in the list is counted. The number of tables needs to be determined in order to request the appropriate quantity of memory space for the literal table directory.
Next follows step 104, at which the required quantity of memory is requested for the literal table directory.
Step 106 follows step 104. At step 106 the directory is built while eliminating duplicate entries. It will be ~ understood that duplicates can be eliminated by comparing , '3) ~
each entry against every entry that has previously been added to the directory and not adding the current entry if it duplicates a preceding entry.
It should be noted that each entry includes the parameters of the heading of the corresponding table (e.g.
TABLE I.D.; CARRIER; LANGUAGE; REVISION NO.) plus the location of the corresponding table.
Step 108 follows step 106. At step 108 the directory is sorted. Preferably the entries are sorted according to three criteria. The first criterion is the value of the 'CARRIER' parameter. The second criterion is the value of the 'LANG~IAGE' parameter and the third criterion is the value of the 'REVISION NO.' parameter. It will be appreciated that both the entries parameters may be sorted in accordance with the hexadecimal number value of the parameter for each entry, which will cause in each case the 'FF' entries to be sorted to the end. Thus the 'carrier independent' or 'language independent' table entries will follow the entries that are specific to a carrier or a language. As to the sortation of revision numbers, the sortation scheme is such that the most recently revised and issued tables will appear in the ; directory ahead of less recent tables. This may be done by issuing ascending revision numbers and then sorting in reverse order of revision number or by issuing 'FF' as the ;25 first number and then issuing subsequent revision numbers in descending order.
According to a preferred method of performing the invention, no sortation by 'TABLE' is reguired.
Upon completion of step 108 a properly sorted literal table directory has been stored in the memory, preferably in battery-backed-up RAM 22, of device 10. The routine of Fig.
2 then ends with a return to the balance of the initialization procedure.
Referring now to Figs. 3-A, 3-B and 3-C, there will be - 35 described a program routine for using the literal table directory to respond to a literal re~uest and output the required character string.
This routine begins at step 200 with the receipt of a literal request from one or another of the functions making : - : ., .,, : : .
~ ;: , i . . . ~
S~
up the applications program. For example, if a report is being generated, the request may be for a report heading that is needed for the report. Alternatively, if the system needs to respond to ~eyboard entry of data with a prompt message or an error message to be displayed on display 14, the request is for the s~ring making up the text of the prompt message or error message.
The request as received preferably contains the following request parameters: TAG; LANGUAGE; CARRIER; TABLE;
RETURN ADDRESS. It should be appreciated that, in an alternative embodiment of the invention not all of these parameters will need to be specified in every request. For instance, some reports that are printed have nothing to do with any carrier, in which case the carrier parameter may well be omitted. The TAG parameter is to identify the particular string that is ~equired. The LANGUAGE parameter either specifies a language or, by an appropriate code, indicates that the language is to be whatever language has been selected by the operator for operation of the system.
The CARRIER parameter will of course be used to identify prompts that are specific to a gi~en carrier and the TABLE
parameter will, together with the TAG parameter, identify the desired tag. The RETURN ADDRESS parameter will indicate the memory location to which the pointer to the appropriate string's address is to be sent.
Following step 200 is step 202 at which it is determined whether the value of the LANGUAGE request parameter is equal to 'currently selected language'. If not, the specified value of the 'LANGUAGE' request parameter is used in searching the directory (step 204). Otherwise, the currently selected language is used as the value of the parameter for the purpose of searching the directory (step 206)o Following step 206 or 204, as the case may be, is step 208, at which it is determined whether there are any more entries in the directory. If so (as would usually be the case at the first time the routine reaches step 208), step 210 follows, at which the current entry is set ~o be the next entry in the directory (which the first time through would be the first entry). Following step 210 is step 212, at which it is .
:
..
s~ ~ r) ~ 3 determined whether the 'CARRIER' parameter of the entry matches the requested value of the 'CARRIER' parameter. If not, the routine cycles back to step 208.
If at step 208 no more entries are found in the directory, an error message is sent (step 214) and the routine ends). If there are more entries, the routine will continue to cycle through steps 208, 210 and 212 until a match in the 'CARRIER' parameter is found. Once this occurs, step 212 is ~ollowed by step 216, at which it is determined whether the 'L~NGUAGE' parameter of the entry matches the requested value of the 'LANGUAGE' parameter. If there is no match at step 216 again the routine returns to step 208. If there is a match at step 216, the routine proceeds to step 218, at which is determined whether the 'TABLE' parameter of the directory entry matches the requested ~alue of the ~ 'TABI.E' parameter. Again, if not the routine returns to step `~ 208. It will be recognized that the routine will accordingly continually cycle through step 208 until a directory entry matches the requested values all three of the 'CARRIER', 'LANGUAGE' and 'TABLE' parameters or until there are no more entries in the directory. Assuming an entry matching all ~` three parameters is found, then step 220 will follow step 218. At step 220, the table corresponding to the matching entry will be searched for the requested tag I.D.. It is then determined, at step 222, whether the requested tag I.D.
is found in that table. If not, an error message is sent (step 214) and the routine ends. Otherwise, the offset that constitutes the second part of the data pair of which the requested tag I~D~ is the first part is used to calculate a pointer to the desired string and that pointer is then returned to the return address specified in the request (step 224). The routine then ends.
It will be seen, then, that upon completion of step 224 the function that sent the literal request has access to the requested literal and may, as appropriate, output the literal string or use the string for control or processing purposes.
Although the implications of th~ routines discussed in connection with Figs. 2, 3-A, 3-B and 3-C will generally be .
;
. ~
; ~
r ~g3 understood by those skilled in the art, it is worthwhile to note some of the implications in detail.
As is well known to those skilled in the art, it is frequently necessary to update the carrier rate data stored in PROMs 20 of system 30. The well known method by which this is accomplished is mailing an updated rate PROM board to the user of system 30. The user or a service representative then detaches a PROM board from device 10 and replaces it with the updated rate PROM board.
Suppose now that a typographical error is discovered in a character string stored in a literal table stored on any of PROMs 20. For purposes of illustration we will refer to that literal table as TABLE A, Rev. 1 t where "TABLE A" will be understood to include all the parameters required to identify the table other than 'REVISION NO.' If it is desired to correct the erroneous string all that is required is to include on the next rate update PROM a literal table in the following form:
TABLE A, REV. 2 ******
` TAG I.D.
OFFSET
*******
(corrected string) ******
(It will be assumed that no revisions to Table A have been previously issued since Rev. l. It will also be understood that the TAG I.D. immediately following the header of TABLE
A, Rev. 2 corresponds to the string that is to be corrected.) Upon reinitialization of system 30 after installation of the update PROM, a literal table directory will be generated and stored in accordance with the routine of Fig. 2. As a result of that routine, and particularly step 108, the literal table directory will include an entry for TABLE A, REV. 2 immediately before the entry for TABLE A, REV. 1.
Subsequently when the string in question is to be output, an appropriate literal request w:ill be received (Fig. 3-A, step 200), the entry for TABLE A, REV. 2 will be matched (Fig.
, ~
' ' ' . ':: . . , ~g~
3-B, steps 212, 216 and 218) and TABLE A, REV. 2 searched for the TAG I.D. corresponding to the desired string (Fig. 3-C, step 220). The TAG I.D. is then found, a pointer to the corrected string is returned, and the corrected string is then accessed and either output or interpreted for control purposes, as the case may be.
It will therefore be seen that TABLE A, REV. 2 represents a simple, effective and conveniently installed .~ "patch" on TABLE A, REV. 1. When a request is made for a string stored in TABLE A, REV. 1 other than the corrected string, the corresponding TAG I.D. will not be found in TABLE
A, REV. 2 and the retrieval routine will cycle through steps 208, 210 212, 216 and 218. TABLE A, REV. 1 will then be found to match the request and the requested string will be retrieved and accessed, etc.
While a rather modest example has just been given, it will be appreciated that much more complex and extensive changes to literal strings can readily be made via new ~-; literal tables on update PROMs with little or no need to ` 20 change the system's application program. For example, if a parcel carrier changes the required format of manifests, many or all of the changes can be implemented via a new literal table containing updated character and/or format command strings. As another example, the natural languages in which output literals are expressed can readily be changed or augmented with little or no change to the application - program. As still another example, strings required by new functions can easily be added via new literal tables.
Although the inventive method as described herein has included references to memory space realized in detachable PROM boards, it is also within the contemplation of this invention to use the inventive method in devices without PROMs and in devices in which data storage and/or updating is accomplished via floppy disk, data communication, keyboard input, optical character or data code reading and by other means. Accordingly, as used in the claims, "addrass" shall be construed to refer to a conventional RAM or ROM address and also to a code or number that denotes a specific location in a fixed or floppy disk or other storage device. It will ,;
2~3~
also be apparent that variations and modifications may be made in the subject invention and it is therefore intended in the following claims to cover each such variation and modification as falls within the true spirit and scope of the invention.
, ' ~ , , : . ~ .
It will therefore be seen that TABLE A, REV. 2 represents a simple, effective and conveniently installed .~ "patch" on TABLE A, REV. 1. When a request is made for a string stored in TABLE A, REV. 1 other than the corrected string, the corresponding TAG I.D. will not be found in TABLE
A, REV. 2 and the retrieval routine will cycle through steps 208, 210 212, 216 and 218. TABLE A, REV. 1 will then be found to match the request and the requested string will be retrieved and accessed, etc.
While a rather modest example has just been given, it will be appreciated that much more complex and extensive changes to literal strings can readily be made via new ~-; literal tables on update PROMs with little or no need to ` 20 change the system's application program. For example, if a parcel carrier changes the required format of manifests, many or all of the changes can be implemented via a new literal table containing updated character and/or format command strings. As another example, the natural languages in which output literals are expressed can readily be changed or augmented with little or no change to the application - program. As still another example, strings required by new functions can easily be added via new literal tables.
Although the inventive method as described herein has included references to memory space realized in detachable PROM boards, it is also within the contemplation of this invention to use the inventive method in devices without PROMs and in devices in which data storage and/or updating is accomplished via floppy disk, data communication, keyboard input, optical character or data code reading and by other means. Accordingly, as used in the claims, "addrass" shall be construed to refer to a conventional RAM or ROM address and also to a code or number that denotes a specific location in a fixed or floppy disk or other storage device. It will ,;
2~3~
also be apparent that variations and modifications may be made in the subject invention and it is therefore intended in the following claims to cover each such variation and modification as falls within the true spirit and scope of the invention.
, ' ~ , , : . ~ .
Claims (20)
1. In a data processing device having a memory and output means, said memory comprising a plurality of locations, a method of retrieving a literal string, comprising the steps of:
(a) storing a plurality of literal strings in said memory, each of said strings being stored in a separate one of said locations, each of said locations having an address;
(b) storing in said memory a plurality of tables, each of said tables comprising data identifying at least some of said stored strings and addresses of the respective locations in which said some strings are stored;
(c) assembling a directory of said stored tables, said directory comprising a plurality of entries, each of said entries corresponding to one of said stored tables;
(d) receiving a request to locate one of said literal strings, said request having at least one request parameter;
(e) searching said directory for an entry that matches said at least one request parameter;
(f) upon finding such an entry, searching a first stored table corresponding to said matching entry for said identifying data corresponding to said requested string, and (g) upon finding said corresponding data, accessing said requested string.
(a) storing a plurality of literal strings in said memory, each of said strings being stored in a separate one of said locations, each of said locations having an address;
(b) storing in said memory a plurality of tables, each of said tables comprising data identifying at least some of said stored strings and addresses of the respective locations in which said some strings are stored;
(c) assembling a directory of said stored tables, said directory comprising a plurality of entries, each of said entries corresponding to one of said stored tables;
(d) receiving a request to locate one of said literal strings, said request having at least one request parameter;
(e) searching said directory for an entry that matches said at least one request parameter;
(f) upon finding such an entry, searching a first stored table corresponding to said matching entry for said identifying data corresponding to said requested string, and (g) upon finding said corresponding data, accessing said requested string.
2. The method of claim 1, wherein said tables comprise said stored strings.
3. The method of claim 1, wherein said entries comprise entry parameters and wherein said assembling step comprises sorting said entries in accordance with at least some of said entry parameters.
4. The method of claim 3, wherein said entry parameters include a revision number of the table corresponding to each respective entry.
5. The method of claim 4, wherein a second stored table corresponding to a second matching entry is searched for said identifying data if said identifying data is not found in said first stored table.
6. The method of claim 5, wherein said first stored table is stored in said memory after said second stored table.
7. The method of claim 6, wherein said first stored table is issued after said second stored table.
8. The method of claim 1, wherein said method of storing said tables in said memory comprises programming said tables into at least one PROM and detachably connecting said at least one PROM to said device.
9. The method of claim 1, further comprising the step of outputting said accessed string.
10. The method of claim 9, wherein said outputting step comprises displaying said accessed string on a display.
11. The method of claim 9, wherein said outputting step comprises printing said accessed string as part of a report generated by a printer.
12. In a data processing device having a memory, a method of retrieving a literal string, comprising the steps of:
(a) storing in said memory a plurality of tables, each of said tables comprising a header, one or more literal strings, and one or more data pairs, said data pairs corresponding one-to-one to said literal strings, each said data pair consisting of first data identifying said pair's corresponding string and second data related to a storage address of said corresponding string;
(b) assembling a directory of said stored tables, said directory comprising a plurality of entries, each of said entries corresponding to one of said stored tables, each of said entries having one or more entry parameters, each of said entry parameters corresponding to a respective parameter of the header of said entry's corresponding table;
(c) sorting said directory in accordance with said entry parameters;
(d) receiving a request to locate a literal string, said request having one or more request parameters;
(e) searching said directory for an entry that matches said request parameters;
(f) upon finding such an entry, searching a first stored table corresponding to said matching entry for said identifying data corresponding to said requested string;
(g) if said corresponding data is found in said first table, using said second data to calculate a storage address of said requested string and then returning a pointer to said storage address; and (h) if said corresponding data is not found in said first table, searching a second stored table corresponding to a second matching entry.
(a) storing in said memory a plurality of tables, each of said tables comprising a header, one or more literal strings, and one or more data pairs, said data pairs corresponding one-to-one to said literal strings, each said data pair consisting of first data identifying said pair's corresponding string and second data related to a storage address of said corresponding string;
(b) assembling a directory of said stored tables, said directory comprising a plurality of entries, each of said entries corresponding to one of said stored tables, each of said entries having one or more entry parameters, each of said entry parameters corresponding to a respective parameter of the header of said entry's corresponding table;
(c) sorting said directory in accordance with said entry parameters;
(d) receiving a request to locate a literal string, said request having one or more request parameters;
(e) searching said directory for an entry that matches said request parameters;
(f) upon finding such an entry, searching a first stored table corresponding to said matching entry for said identifying data corresponding to said requested string;
(g) if said corresponding data is found in said first table, using said second data to calculate a storage address of said requested string and then returning a pointer to said storage address; and (h) if said corresponding data is not found in said first table, searching a second stored table corresponding to a second matching entry.
13. The method of claim 12, wherein said method of storing said tables in said memory comprises programming said tables into at least one PROM and detachably connecting said at least one PROM to said device.
14. The method of claim 13, wherein in each said table said one or more strings immediately follow said corresponding one or more data pairs.
15. A method of updating a literal string stored in the memory of a data processing device, the method comprising the steps of:
(a) storing a first table in said memory, said first table comprising a first string, said first table having a first revision number;
(b) storing a second table in said memory, said second table comprising a second string, said second table having a second revision number;
(c) assembling a table directory, said directory comprising a first entry corresponding to said first table and a second entry corresponding to said second table; and (d) sorting said entries in accordance with the revision numbers of said tables.
(a) storing a first table in said memory, said first table comprising a first string, said first table having a first revision number;
(b) storing a second table in said memory, said second table comprising a second string, said second table having a second revision number;
(c) assembling a table directory, said directory comprising a first entry corresponding to said first table and a second entry corresponding to said second table; and (d) sorting said entries in accordance with the revision numbers of said tables.
16. The method of claim 15, wherein said storing steps comprise programming said tables into one or more PROMs and detachably connecting said PROMs to said data processing device.
17. The method of claim 15, wherein said second string is an update of said first string.
18. The method of claim 15, wherein said second string is a correction of said first string.
19. The method of claim 15, wherein said first string represents a statement in a first natural language and said second string represents a translation of said statement into a second natural language.
20. The method of claim 15, wherein said assembling and sorting steps are a part of an initialization routine of said device.
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US07/760,638 US5357629A (en) | 1991-09-16 | 1991-09-16 | System for recording structured read only data table revisions and forming a directory to the latest revisions of table elements |
| US760,638 | 1991-09-16 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CA2078396A1 true CA2078396A1 (en) | 1993-03-17 |
Family
ID=25059721
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CA002078396A Abandoned CA2078396A1 (en) | 1991-09-16 | 1992-09-16 | Method of retrieving literal strings in a data processing system |
Country Status (2)
| Country | Link |
|---|---|
| US (1) | US5357629A (en) |
| CA (1) | CA2078396A1 (en) |
Families Citing this family (11)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| DE4213278C2 (en) * | 1992-04-16 | 1998-02-19 | Francotyp Postalia Gmbh | Arrangement for franking mail |
| US5499329A (en) * | 1992-04-30 | 1996-03-12 | Ricoh Company, Ltd. | Method and system to handle context of interpretation in a document processing language |
| US5819306A (en) * | 1995-02-14 | 1998-10-06 | General Magic | Shadow mechanism for a modifiable object oriented system |
| US5692187A (en) * | 1995-02-14 | 1997-11-25 | General Magic | Shadow mechanism having masterblocks for a modifiable object oriented system |
| US5995980A (en) * | 1996-07-23 | 1999-11-30 | Olson; Jack E. | System and method for database update replication |
| US5842213A (en) * | 1997-01-28 | 1998-11-24 | Odom; Paul S. | Method for modeling, storing, and transferring data in neutral form |
| US7003494B2 (en) * | 1999-02-03 | 2006-02-21 | International Business Machines Corporation | Preprocessor system and method for rejection of duplicate invoices |
| US6477703B1 (en) * | 1999-06-29 | 2002-11-05 | Hewlett-Packard Company | Software patch selection tool |
| US6963885B2 (en) * | 2001-04-11 | 2005-11-08 | International Business Machines Corporation | System and method for identifying invoices that may be duplicate prior to payment |
| US7149962B1 (en) * | 2002-03-01 | 2006-12-12 | General Electric Railcar Services Corporation | System and method for providing a gauge table |
| US8438558B1 (en) | 2009-03-27 | 2013-05-07 | Google Inc. | System and method of updating programs and data |
Family Cites Families (13)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US4271481A (en) * | 1976-06-10 | 1981-06-02 | Pitney Bowes Inc. | Micro computerized electronic postage meter system |
| US4481587A (en) * | 1981-12-24 | 1984-11-06 | Pitney Bowes Inc. | Apparatus for providing interchangeable keyboard functions |
| US4623987A (en) * | 1982-12-08 | 1986-11-18 | Pitney Bowes Inc. | Postage meter with keyboard keys for commanding and requesting performance of meter operations |
| US4996662A (en) * | 1983-10-03 | 1991-02-26 | Wang Laboratories, Inc. | Method for generating document using tables storing pointers and indexes |
| US4674040A (en) * | 1984-12-26 | 1987-06-16 | International Business Machines Corporation | Merging of documents |
| US4730252A (en) * | 1985-09-24 | 1988-03-08 | International Business Machines Corp. | Document composition from parts inventory |
| JPS6320622A (en) * | 1986-07-15 | 1988-01-28 | Brother Ind Ltd | Document editing device |
| US4953122A (en) * | 1986-10-31 | 1990-08-28 | Laserdrive Ltd. | Pseudo-erasable and rewritable write-once optical disk memory system |
| US4800506A (en) * | 1987-03-13 | 1989-01-24 | Pitney Bowes Inc. | Apparatus for preparing mail pieces |
| US5179703A (en) * | 1987-11-17 | 1993-01-12 | International Business Machines Corporation | Dynamically adaptive environment for computer programs |
| US5107423A (en) * | 1988-03-26 | 1992-04-21 | Brother Kogyo Kabushiki Kaisha | Document processing device with merge function |
| US5276616A (en) * | 1989-10-16 | 1994-01-04 | Sharp Kabushiki Kaisha | Apparatus for automatically generating index |
| US5247658A (en) * | 1989-10-31 | 1993-09-21 | Microsoft Corporation | Method and system for traversing linked list record based upon write-once predetermined bit value of secondary pointers |
-
1991
- 1991-09-16 US US07/760,638 patent/US5357629A/en not_active Expired - Fee Related
-
1992
- 1992-09-16 CA CA002078396A patent/CA2078396A1/en not_active Abandoned
Also Published As
| Publication number | Publication date |
|---|---|
| US5357629A (en) | 1994-10-18 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US5009276A (en) | Electronic postal scale with multilingual operator prompts and report headings | |
| US5040132A (en) | System for preparing shipping documents | |
| EP0585932B1 (en) | A container packing verification and labeling system | |
| GB2202660A (en) | Mail preparation system | |
| US5357629A (en) | System for recording structured read only data table revisions and forming a directory to the latest revisions of table elements | |
| AU609192B2 (en) | Inserter based mail manifesting system | |
| CA1196723A (en) | Apparatus for providing interchangeable keyboard functions | |
| EP0910048B1 (en) | Electronic postage scales system and method | |
| US5387783A (en) | Method and apparatus for inserting and printing barcoded zip codes | |
| US5668990A (en) | Apparatus and method for generating 100% United States Postal Service bar coded lists | |
| US5661653A (en) | Custom class selection in automated mail processing | |
| EP0981110B1 (en) | A method and system of printing postage indicia from an envelope design application | |
| US6337743B1 (en) | Method and system of print stream address extraction | |
| US6615298B2 (en) | Method and system for establishing a standard peripheral interface server between a client and a plurality of peripherals | |
| EP0927964B1 (en) | A method for utilizing the postal service address as an object in an object oriented environment | |
| US6384931B1 (en) | Method and system for capturing destination addresses from label data | |
| EP0927581B1 (en) | A method for address determination | |
| US6393135B1 (en) | OLE automation server for manipulation of mail piece data | |
| EP0492439A2 (en) | User interface for a mail processing system | |
| AU608422B2 (en) | System for making pieces to be dispatched ready for shipping | |
| US5079712A (en) | Register setting arrangement for carrier management system | |
| CA2078397A1 (en) | Method of retrieving variable values in a data processing system | |
| WO1995011495A2 (en) | Postage imprinting apparatus and methods for use with a computer printer | |
| US20050125365A1 (en) | Apparatus for automatic determination of a product description for display by means of a mail-processing device | |
| JP2000001005A (en) | Printing apparatus |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| FZDE | Discontinued |