CA2037995A1 - Dynamic data storage system - Google Patents
Dynamic data storage systemInfo
- Publication number
- CA2037995A1 CA2037995A1 CA002037995A CA2037995A CA2037995A1 CA 2037995 A1 CA2037995 A1 CA 2037995A1 CA 002037995 A CA002037995 A CA 002037995A CA 2037995 A CA2037995 A CA 2037995A CA 2037995 A1 CA2037995 A1 CA 2037995A1
- Authority
- CA
- Canada
- Prior art keywords
- record
- segment
- data
- length
- segments
- 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
- G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
- G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
- G06F3/0601—Interfaces specially adapted for storage systems
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F12/00—Accessing, addressing or allocating within memory systems or architectures
- G06F12/02—Addressing or allocation; Relocation
- G06F12/0223—User address space allocation, e.g. contiguous or non contiguous base addressing
- G06F12/023—Free address space management
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
- G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
- G06F2003/0697—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers device management, e.g. handlers, drivers, I/O schedulers
Abstract
ABSTRACT OF THE DISCLOSURE
DYNAMIC DATA STORAGE SYSTEM
The system of the present invention provides a data storage system program 18 between a user and physical memory device 14 which stores file records 20. The data storage system 18 stores records as linked record segments 40/50 that can be randomly located within the memory storage device 14. The segments 40/50 are linked by a next segment address found in a next segment address field 50/51 of a record segment 40/50. When a record needs to be expanded and the current record segment 1000 is not large enough to accommodate the expansion, another record segment 1082 is allocated and used.
If variable length record segments 40 are used, only a single record extension is required. However, if fixed length record segments 50 are used, the system allocates sufficient fixed length record segments to store the additional data. When records shrink in size or are deleted, the vacant space becomes available for reuse and the system attempts to remove the vacant space by combining record segments and storing a single segment in available vacant space.
DYNAMIC DATA STORAGE SYSTEM
The system of the present invention provides a data storage system program 18 between a user and physical memory device 14 which stores file records 20. The data storage system 18 stores records as linked record segments 40/50 that can be randomly located within the memory storage device 14. The segments 40/50 are linked by a next segment address found in a next segment address field 50/51 of a record segment 40/50. When a record needs to be expanded and the current record segment 1000 is not large enough to accommodate the expansion, another record segment 1082 is allocated and used.
If variable length record segments 40 are used, only a single record extension is required. However, if fixed length record segments 50 are used, the system allocates sufficient fixed length record segments to store the additional data. When records shrink in size or are deleted, the vacant space becomes available for reuse and the system attempts to remove the vacant space by combining record segments and storing a single segment in available vacant space.
Description
- 1 - 21.1635 DYNAMIC DATA STORAGE SYSTEM
BAC~GROUND OF THE INVENTION
Fi~ld of the Invention The present invention.is dirQcted to a data storage system designed to allow th~ size of records available for storing data to freely vary from record to record and over time and, more particularly, to a system that provides linked record seg~ents where th~ segments can be added or subtracted to allow the record slze to change, wher~
the segm~nts can be separately and randomly stored within data storage and where the systam automatically consolidates the segments at a single location as space become~ available.
Description of the Related Ar~
The structl~re of conventional file systems is dictated by the application progra~ designer when th~ application program is being designed. For example, during the design stage, the progra~mer prepare~ a data definition which defines the types and size~ o~ records in t~e file and defines the type~ and sizes o ~ield3 within each record. As the application program is created and debugged, the size, number and types of record~, se~ments and fields can change. How~ver, onc~ ~h~ program is debugged, the sizes of the record~, segments and Pields within a record are fix2d. If a user de~ires to change tha 8ize 0~ a racord, ~he application progra~ m,u3t be rede3ign~d and, unle~s the siz~
de~ini~ions are changed, ~hs user cannot enter data 2' ~ 3 ~
- 2 - 21. lfi35 i~to a record or a field which is larger than the space originally defin~d for that record. Since it i5 common ~or a user ~o want to change th~ amount o~
data being stored in a record or a field during the li~e of a program, the cost: and time required to change the data definitions for the program to customize the application program for the user can b~ large. This proble~ becomes ~uch worse if the application progra~ is part: o~ a package distributed to many different u3ers who want change the sizes of different records or fields. The maintenance problems associated with such changes also increa~e especially if a customized program i~ created and maintained for each user. This problem is increasing further in magnitude because o~ the desire to allow the user~'of software to ~reely chang~ tha siz~ o~ data fields u~ed for entering or outp~tting data on screen displays or terminal simply by entering ~ore or less data ~or that record or field. The trend toward allowing c~stomization of the terminal display by the user is ther~by creating database maintenance problems. That is, the data definition redefinition problem is be~ng further aggravated by the desire to increas~ the 5 flexibility o~ the man machine inter~ace.
one solution to this problem is ta provide each record or ~ield with a size that is su~iciently large so that any possible desired length of data can ~it within the record or the field. Thls is done at the design stage in a discussion between the program designers. This is an impractical solution to th~ problem and is particul,arly ineffici~nt in the utilization of the storage. Another solu~ion is to maintain a ~aster application progra~ in such a way as to taks into account ~each of the changes raquested by all the users, so that the size of the records or fields grow until the worst cas~ for each record is 2~37~
_ 3 - 21.1635 satisfied. This was~es memory space and requirQ~
that all user3 be provided with an updat~d program each time a change to the master program is made.
This also requires that the users submit change requests to the program designer and therefore does not satisfy tha flexibility need associated with the man machine interface. This solution is also an expensive solution.
- What is needed is a system which will allow record or field size to change dynamioally without requiring rede~inition of the sizes of the records or fields and which allows the user to enter a desired amount of data no matter what is the record or field size.
1~ SUMMARY OF THE INVENTION
It is an object of the present invention to provide a system which allows record or field size to change dynamically based on the 5ize or the length o~ the data input by the user.
It is another objec~ o~ the present invention to provide a system that is not seen or is transparent to the users.
It is also an object of the present invention to provide a system that efficiently utilizes available me~ory space.
It is a further o~ect of the present invention to provide a syste~ that reduces maintenance requirement~ for application programs.
The aboYe objects can be attained by a data storage system located between the application prsgram and the physical me~ory device. The data storage syste~ stores records a~ Iinked record se~ments that can be randomly located within the memory s1:orage device. If a record needs to be expanded and the current record or location is not large enough to accommodate the expansion, another record segment i5 allocated and ~tored in another location. If variable length record sQg~ents arQ
~3~
- 4 - 21.1635 used, only a single record extension is requilred.
However, i~ fixed length record seqments are used, the system allocates sufficient fixed length record segments to store the additional data. ~hen records shrink in size, the vacant space beco~es avallable for reuse. Periodically and when records are deleted, ths system perfor~s a process that combines or concatenates record segmlents and removes vacan space.
These together with other objects and advantages which will be subsequently apparent, reside in the details of construction and operation as more fully hereinaftQr described and claimed, reference being had to the accompanying drawings forming a part hereof, wherein lika numerals refer to lika parts throughout.
BRIEF D~SCRIPTION OF THE DRAWINGS
Fig. 1 illustrates components of the present invention:
FigsO 2 and 3 illustrate preferred data structures of the pres~ant invention:
Fig. 4 illustrates a record cross reference table of the present invention;
Fig. 5 illustrate~ a vacant space table of the present invention;
Fig. 6 illustrate3 a operation of the present invention using variable length record segm~ants;
Fig. 7 illustrates operation of the present invention using fixed length racord segments;
Figs. 8A-8E colDprise a flowchart of the processes o~ th~ prssent invention when variable length rçacord segments are used;
3S Figs. 9 - ~4 illustrat~ operation of the process of Figs. 8A-~E; and Figs. 15A-lSD illustrats operation o f h~
present iLnvention when fixed length record segments ' .
-. .
. .
2~3~9~5307_267 are used.
Fig. ll appears on the fourth sheet of drawings and Fig. 13 appears on the last sheet of drawings.
DESCRIPTION OF THE PREFERRED E~BODIMENTS
The present invention, as illustrated in Fig. 1, includes an input/output unit 10 via which a user adds updates and deletes records~ The input/output unit 10 is connected to a computer 12 which is also connected to a memory unit 14, such as a magnetic disk memory unit, and which is capable of randomly storing and retrieving data, typically alpha numeric data.
Within the computer 12 an application program 16 exists which may for example create a display for the input/output unit 10 which, for example, allows a user to access and update records in a personnel system. That is, the application program 16 performs the operations associated with interfacing with the user. The application program 16 communicates ~ith a data storage and retrieval program 18 which actually read~, updates and writes the records into the memory unit 14. The data storage and retrieval program 18 allows the user to access a file 19 and change the size of records 20 used by the application program 16 without regard to the original data definition of the application program 16. The data storage and retrieval program 18 is transparent to the user. The memory unit 14 for each file 19 accessed by the data storage and retrieval program 18 stores the f~le records 20, a record cross reference table 22 which is used to locate the records 20, and a vacant space table 24 which is used to determine vacant space within the file l9 that can be used for record - 5a - 2 0 3 73 9 ~ 25307-267 storage. The record cross re~erence tab:Le 22 and vacant space table 24 are preferably stored in the header port;~on of the f1le 19. As discussed later it is possible to implement the s~stem without the cross reference or vacant space tables.
'' : - ' : -- : .
.
2~79~S
- 6 - 21.lS35 During op~ration when a user reg~ests that the contentg of a record 20 or a fi~ld be obtained, the application program 16 preferably provides a record identifier (ID) t~ the data storage and 5 retrieval program 18. This progra~ 18 uses the cross reference table 22 to deter~ine the physical location of the desired record 20, obtains the record 20 and provides the record 20 to the application program 16. This record 20 can be provided to the application progra~ 16 by the invention in a number of different way~, however, it is preferred that the record 20 be provided to the application program 16 in two parts. The first part is a f ixed size record hea~er which includes the record ID, the size of th~ data field o~ t~e record and a pointer to a buf fer which includes the data of the record and which is tha second part of the record. T~e application program 16 then proyidec the contents or data of the record 20 to the input/output unit 10. During a record update or record writing operation the application program 16 also preferably provides the record header which includes the record ID, the size o~ the data field of the record 20 and the pointer to the buf~er that contains the data of the rQcord 20 to the data storage and retrieval program 18. The data storage and re~rieval program 18 then searches the cross re~erencs table 22 to determine whether th~ record ~0 exists and if no~ adds the record 20 as a new record 20 and if the record 20 does exist, updates the record 20. The operations sf writing, reading and updating file records 20 in the memory unit 14 will ba di cussed in greater detail hereinafter.
~lthough the applicatlon progra~ 16 is shown located within the same computer 12 as the data storage and retrieval progra~ 1~ and in direct associat:Lon wi~h the input/output unit 10 it ic possible for the input/output unit 10 to b~ re~otely ~ ~ 3 f~
- 7 - ~1.1635 located wi~h respect to the application program 16, for exa~pl~ with the application program 16 communicating to the program 18 over a co~munication network, and for the app1ic:ation pro~ram 16 to be executed in a different computer than the computer 12 containing the da~a storage and retri~val program 18. It is also possible to have the memory unit 14 located remotely from the c:omputer 12. It is preferred however that the input/output unit 10, comp~lter 12 and memory unit 14 be locally located.
A computer system such as a conventional personal computer or mini computer with a magnetic disk storage unit is pref~rred. It ls also preferred that the data storage and r~tria~ra1 program 18 be programmed in a language such as "Cp1usp1us"
suitable for processing linked lists. The system illustrated in Fig. 1 and particularly the program 18 of course can interface directly with the user as an independent database utility maintenance program~
Th~ present invention can use two different data structure~ for storing the segmented records which can both be used to accomplish the object~ of the pre~ent invention, and which are illustrated in Figs. 2 and 3. A~ illustrated in Fig. 2 each record segment 40 include~ a record head~r 42 and a data field 44. Th~ record header 42 includes a record ID ~ield 46, a size fiald 48 and a next seg~ent address field 50. The he~der 42 is of a fixed ~ze and it i5 preferablQ that the record ID
field 46 bQ 20 bytes long, the siz~ field 48 be 2 bytes long and the next segment address field 50 be 2 bytes 'Lony. Tha data field 44 is variable in length w:Lth th~ size o~ the d~ta fi~ld 44 being stored in the ~ize field 48. The record ID field 46 3 5 can cont~lin an a1phanumeric r~cord name which could correspolld to the nama of the f ield on ~he user ' s display or could be mere1y a record number. ~ach record 20 consi~ts o one or ~ore segm~nt~ 40 with ~ 67 the qegments being linked through the next segment address. As illustrated in Fig. 2, th~ record starting at location 1000 includes two ~egment~, the first segment i a 20 byte segment which starts at the physical addres~ 1000 and th~ ~econd segment is an 8 ~yte segment which start~ at physical address 1082. If a record 20 includes only a single seqment 40, thPn the next segment address field 50 includes a null indicator which acts as an end of record 20 indicator or instead of a null indicator a special and of record code could be used. A can be seen from Fig. 2, the data ~ields are variable in length, for ~xample, the data field 44 for thQ racord seg~3nt 40 starting at addres3 location 1000 is 20 byte~ long whil~ th~ record segment 40 starting at location 1114 is 64 bytes long.
The alternate data structure illustrated in Fig. 3 i~ a data structure which consist~ of fixed l~ngth record sagments 51 where ~he fixed length is preferably 32 by~es~ Each og th~ record segments 51 in th~ ~ix~d lenqth rQcord data structura preferably includes a h~ader ield 5~ the contents of which indicate ~he number of segments, including ~he current se~m~nt, re~aining in the record. Th~t i~, if th~ record includes 5 s~g~ents, the firs~ recurd segmen~, in the numb~r o~ segments ~ield 52, would includ~ th~ nu~b~r 5 and the second s~gment would includa the nu~ber 4 and 30 on until the ~i~th rQcord seg~nt includ~s an end o~ record indicator which could be a special character ~ch as a "*" or could be the s~gment count "1~. Ik is also possibls ~o put the segment coun~ only in the fir~t record s~!g~nt ~nd put a con~inuation cod~ in the field 52 o~ all succ~3siv~ segm~nts. The number o sQgm~nts field 52 i~ pre~rably 2 byte~ lon~.
Ad~acent the nuDb~r og ~eg~nt8 field i~ a dat~
~ield o~ a fix~d leng~h, such a~ 28 byt~. Thu~, in thi~ e~b~i~ent o~ the data ~tructuXo, th~ data in a ~ ~ 3 t~
_ g _ record is divided into 28 byte ~egment and i~ ~he length o~ da~a is no~ evenly divisible by 28 bytes, then a portion of the data fisld 54 ~or the last seqment will be e~pty. Adjacent the data field 54 is a next segment address field 56 or a link field which functions, in the same manner as the corresponding link ~ield 50 in Fig. 2~ to poin~ to the physical address of the next segmen~ 51 of the record 20 in the physical memory torage device, such as a magnetic disk. Thi~ ~ield, when a next seg~ent does ~ot exist can contain a null indicator or a special end o~ record code.
The record data structure~ illustratad in Fi~s. 2 and 3 ha~ a preferred arrangem~nt. It is possible, however, for a different arrangement o~
the fislds to be usedO For example, th~ next segment address f ield 5S could ba ad~acent to the number o~ segment~ fi~ld 52 in Fig. 3 and the siz~
field 4B could be located subsequent to th~ address field 50 in Fig. 2. One a~vantage of the data - structure~ o~ th~ pr~nt invention, in which the next segment pointer~ are part of ths seqment header is that a separate location table for secondary seqoent~ outsid~ of the record it~el~ is not nece~sary.
Fig. 4 illustrate~ the contents o~ a cros r3~eranc~ t~ble 22. Th~ cross re~erenca table 22 lncludes a record ID fi~ld 60 which i~ examined by the proce~s o~ the pre~ent invention to deten~ine whether th~ record ~xists in thc ~ile 19 and if so, to obtain the address of that record fro~ the addr~s~ ~ield 62. Th~ addre3~ field 62 indicate~
the physical addres~ of the firs~ r~cord s~ment ~0 or 50 on ths storage ~ediu~, such a~ the disk o~ the disk drive. This table 22 is not ab~olutely neces~ary but ~ake~ t~e proqra~ run ~aæter even though additional memory spac~ i~ u~ed.
. .
203~
- 10 - 21.1635 Fig. S illustrate the contents o~ a vacant Bpace table 24. Each entry in this table 24 includes the address of the start of a vacant space in the file 19 and the length 72 of this vaC~nt space. This table is also not absolut~ly necessa~y.
Prior to the first execution of the program 18, the application program lS has been d~bugged and an appropriate data de~inition or the records has been used to originally allocate storage for the fils 19. In this data definition the program designer has specified a size for the records 20 in the file 19, such as 224 byt~, and the file 19 has been creat~d ac~ordingly. BecausQ
o~ this invention, the designer need not be concerned with record size and the de igner need not discuss record siz~ with the other designer~ and can simply concentrate on generating the program l9. In other wordc, the file starts with record segments of an arbitrary size suitable for program testing as specified by the designer and the pr~sent invention adjusts record siz~ to suit the particular user.
Fig. 6 illustrates th~ principla of operation of the present invention when variable length data fields 44 are provided as illus~rated in Fig. 2 and Fi~. 7 illustrate~ the principle of operation of the pr~ent in~ention when ~ixed length - data fialds and records are provid~d a~ illustrated in Fig. 3.
With respect to Fig. 6 assuma that the original field or r~cord on the user's display was originally clesigned during development to show seven - alphanum~ric characters Or two bytes each~ In this situation the record 20 with record ID 500 locat~d at physic:al location 1000 would hav~ seYen alphanu~eric character space~ availabl~. Assum~
that the recorcl includ~ the s~ring "A~CDE" and ~our unus~d bytes, and that the user wi~h~ to updat~ the string to "ABCDEFGHIJ~. In this situation the ~37~
~ 21.1635 present invention would ~xamine record 500 starting at location looo, determine that the record 500 would only hold a portion of the updated string, would store that portion in the record segment, obtain the next availabl~ vacant space in the fil~
19 and use it to store the portion of the updated string which would not fit in the record se~ment at physical location 1000. The sys~em would also add the address of the next segment o~ the record to the first segment address field 50 and enter the appropriate size in the size field 4B of the newly allocated segment which is in this situation located at physical location 1082. The size and location o~
th~ vacant space would also chang~.
For the ~ixed record length data structure, as illustrated in Fig. 7, we will assume that the user wishes to updat~ the string "ABCDEF"
to the string ~ABCDEFGHIJKLMNOPQR~o In this situation, as in the variable length example previously discussed, the system will obtai~ the appropriate record segment using the cross reference table 22, determine that only a portio~ of the updated string will fit in the record segment, will update the data field 54 with the portion of the string which will fit ther~in, update the segment nu~ber field 52 to indicate that two re~ord segments ar~ involved and update th~ address field 56 to include the address of th2 next available record s g~ent in th0 file 19 which can store the remaining portion of the string, in this situation record 0003. The number of segmen~s field 52 of record 0003 is updated and a null indicator is entered in th~ next seg~ent address field 56. ThQ details o~
how the proc~s~es associated with Fig~. 6 and 7 perfor~ these operations will be discuss d in detail with rQspect to Fig~. 8A-8E and l5A-lD, respectively.
21337~
~ 1.1635 The present invention as previously discussed with respec~ to Fig. l, whenever the appllca~ion program 16 procluces a file re~uest, preferably providss a record identifier, a size (number of bytes) of the re!cord, if known, and a pointer to a buffer contair~ing the data of the record if n~cessary and the bu~er. The application program in this situation conventionally counts the bytes of data input and provides the size and the buffer. In addition, it is preferred that the application program 16 provide an operation indicator or command for the add, update, read and delete operations, however, the command is not absolutely necessary as discussed later herein but makes the invention operate faster. It i~ also prsferred, as illustrated in Fig. 8A, that the present invention be interrupt driven and o~ course it is recognized as an alternative that the process 18 of the present invention can be called as a subroutine or subprocedure of the application progra~ 16. Fig. 8A is a first of a series of flowcharts which illustrata the processes performed by the present invention when variabla len~th record segm~nt~ are used.
Fig. 8A illustrates not only a pcrtion of th~ control proces~ of the present invention which det~FmineA the typ~ of file accas~ request but also illustrates tha portion of the process of the present invention which adds new records to the fil~. Fig. 8A will be discussed with respect to Fig. 9 which is an example of the r~cord addin~
operation. Onc~ a file requ~st interrupt 100 or subroutin~ call ha occurred, the process determines 102 from the co~mand which o~ th~ opera~ion~ i~ to b~ perfo:r~ed. ~hen the new record addition oparatio:n i~ the file reque~t co~and, a vacant qpac~ pointer i~ set 104 ~o ~he ~irst entry in the table 24, which would be pointing at th~ entry with ~ 0 3 7 9 9 ~
- 13 - 21.1635 the physical address 846 illustrated in Fig. g.
Next the ~ystem reads 106 th~ record ID and size passed to the program 18 and for this example we will assu~e th2t the new rec:ord ID i5 14 and the size is thirty bytes (six bytes of data and twenty-four bytes for the header). The system th~n reads 108 the entry in the vacant spac~ table 24 and compares 110 the size from t:he vacant table size field 72, which is in this case three bytes, with the size of the record (which is six bytes~. If the size of ths vacant space is not sufficient to allow the new record to be inserted in the vacant space, which is the case for the vacan~ space at location 846, the system chec~s 112 to see i~ the end of the table 24 (and also the end of the file) has b~en reached.
If so the system calls a conventional utility which allocates 114 more ~ile space and then upd~tes 116 thQ vacant space table 24 accordingly.
~0 In the present situation the vacant size of three byte~ is not sufficient ~or storing the record of length thirty bytes and the e~d of tha table 24 has not yet been reached. In this situation the vacant spacs pointer i~ incre~ented 118 and the next entry in the table 24 is obtained.
This cycle of searching the vacant space table 24 for a vacant space of suitabl~ size continu~s until a spacs of sufficient size is encountered and in the example o Fig. 9 this will occur when the vacant space entry with the address of 1102 is encountered. Once a suf~iciently large vacant space is encountered, even if it i obtained by axpancling the size o~ ~he file 19, the system stores-1.!0 the record ID, si2e and data at the vacant addr~s~ a~ illustrated in the ~otto~ half o~
Fig. 9 wl~ere a record with a da~a field of six bytes has been added at physical addr~s~ 1102. Next the system upda~es 122 the vacan~ spac~ table 24 ~o take : . , ' - .
, . , ' .
.
?.J~37~35 - 14 - 21.1635 into ac~ount the reduced size of th~ available vacant space, which in this situation resul ~ in a new vacant space addresg of 1132 and a vacant space size of 10 bytes. Next, the cross re~erenc~ table 22 is updated 124 by adding the record ID ~or the record to the first availab]Le location in the table 22 along with the address o~ the new r~cord, as illustrated by the entry in the table 22 in the low~r half of Fig. 9 which has a record nu~ber identifier o~ 14 and an ad~res3 o~ 1102. Once the table 22 is upda~ed, the system returns 126 to the wait state or returns ~rom the system call as is appropriate.
When the present invention is provided 15 with an update or renewal file request, as illustrated in Fig. 8B, thQ cross reference table 22 is first searched 140 for the record ID of the desired record and the address of that record i~
obtained. The system then reads 142 the record header 42. If the record rontain~ additional segments as indicated by a non-null next seg~ent address field 50, the additional segments are obtained 144, combined and the total siz~ of the . record i~ deter~ined. The step~ o~ the block 144 will be discussed`in ~oxe detail with respect to blo~k~ 182-192 in Fig. 8C. Once the total size i~
determined it is compared 146 to the size of the record be~ng updated. If the size of the record being updated is le~s than or equal to the total size, a determination 148 is made concerning whether the sizes ara equal. I~ equal, the record segmen~
or segments are updated 150 by dividing th~ data in the data ~uffer provided to program 18 into seg~ents in accordance with the segment size ~ound in the header~ of each of the segmen~ and ~he data is written .in~o the appropriate record segments using th~ reco:rd ~egment addresses which arQ used ~o find the record ~egment~ during ths ~egment combination - - . , ': ' . ~ :
- : :
, . - - - ., ' .
9 ~ ~
- 15 - 21.1635 operation.
If the new data size is less than the total ~ize of th~ ori~inally ~tored record, and for the example in Fig. 10 we assum~ that the record h~s s shrunk by sixteen bytes, the 5ize of the vacant space which is created by the record size reduction is computed by subtracting the new data size ~rom the total data size. The starting location of the vacant space is also determined and a new entry is added 152 to the vacant space table 24 as illustrated in the bottom half of Fiq~ 10 where a new entry for the physical address 2086 is found.
Of course i~ tha record size shrinks sufficiently to free up more than one segment, then several new entrie~ to the vacant space table 24 are created.
Once the vacant space table entries aEe created, the system updates 154 the segment si~e in the segments of tha record to reflect the change in the total record size. Once the se~ment size in the appropriat~ segments is updated the data fields o~
the segments are updated which in this situation also involves clearing the new vacant spaceO
If the new data size is lar~er than the total size, and for this example we will as~u~e that the record is increasing in size by six data bytes or a segment of thi~ty bytes, the system stores 158 the updated data in the s~gments of the record until th~ ~inal data segment is encountered a~ indicated by a null next seg~ent address field S0. The remaining da~a length is determined 160 and used ~o obtain 162 vacant space sufficient to store the remaining data plus a header as a new segment. The opexation o~ obtaining the vacant space has been discussed with respect to s~eps 10~ - 118 in Fig. 8A
and need no~ be repeated here. Once an appropriate size vacant space is available, and in this exa~ple the vacant spaca is located at addres~ 1082, ~he system store~ 164 ths record ID, the 5iZ~ equiva}ent " ' ' , .
.
2~s~ 25307~267 to the remaining data leng~h and the data starting at tha vacant address and th~n updatss 166 the vacant space table 24. The operation of seqmenting the record and storing it in a vacant location has s been illustrated in Fig. 6 and Fig. ll illustrates how the contents of th~ vac.lnt space table 24 would be changed for the example of Fig. 6 by the change of the entry having address 1082 to an address of lllS with a siza ~ield 72 containing the value 60.
Because the beginning of the record in this situation is located at the same position as prior to the update, the cross reference table 22 does not change.
When the ~ile request i~ a r~ad or lS extraction r~quest, a~ illu~trat~d in Fig. 8C, the record ID in the requ~t is used to search 180 th~
croes re~erenc~ tabl~ 22 to find th~ addrsss of the rQcord. When th~ r~cord addre~ found, the addres~ i used to read the 5ize and the contents of the next seg~ent address field 50 o~ the head~r 42, and the data in field 44 i~ stored in a temporary buf~er. Then the tot~l ~ize for the x~cord is updatad 186 by th~ ~iz~ valu~ ~ound in th~ segment and a d~ter~in~tion 188 i5 ~ade concerning whether th~ addre~. ~iQld 50 contain~ a null indicator indicating ~hat this is th~ end o~ th~ record. If th~ addre~s ~ield 50 is not null thi~ indicates that ths record include another seg~ent. If the record includes another s~gment th~ buffer pointer is updated l90 and the next record segment header i5 read 182 u~ing the address~ When the last ~egment is found, thQ ~uf~rs ar~ combined 192 and output to the us~r 194 by output~ing th~ r~cor~ ID, ~e size and a point2r ~o a bu~r which contain~ ths da~a o~
th~ reco:rd.
When the fils requast co~mand indicat~s that ~ record should b~ d~let~, a~ illustrated in Fig. 8D, th~ proc~3 s~arch~s 210 th~ ~ro~3 . ' ' ' ~
.
- . ........... .
. ~ .
~ ~ i3 P~
- 17 - 21.1635 reference table 22 for the record. In thi~
situation u~ing Fig. 12 as am example in which record number 2 will b~ del~ted, the system accesses 212 the cross reference table 22 looking for record 2 and finds the address 1194. The system then reads 214 the record segment header 42 and the data 44 thereby obtaining th~ size and the contents o the next address field 50. A determination is then made 216 as to whether this record should be delPted. I~
so the chain of segment addresses in the next segment address field 50 is followed to obtain 218 all o~ the segments and the segment addresses and siz~s are temporarily saved. T~e segments are then deleted 220 by clearing the space in th~ storage medium using the temporarily saved sPg~ent addresses and size indicators. The system then adds 222 vacant spac~ entries to the vacant space table 24, as illustrated in the bottom half of Fig. 12, and then updates 224 ~he cross reference table to remove this record ID fro~ the cross reference table 22, as also illustrated in the bottom half of Fig. 12.
Next, the system increments 226 ths table pointer to point to the next record in the cross reference table 22, whic~ in this situation will be record numbQr 3.
onc2 again the record segment is read and sinc~ thi~ is not a record that needs to be deleted, thQ system proceeds to determine 230 whether th~
addrQss field is empty. In this casa, the field is empty and a d~ter~ination is made 232 as to whether the segment ha~ an im~ediately proceeding vacant space. This i5 determined by s~arching the vacant space table 24 for tha vacant space with th~ next lowest ad,dres~, in this situation addre3~ 11940 Then length of ~he vacant spaca i~ added to the address resulting in an address of 1254 which is compared to th~ record addres . I~ th~ addre~se~
match an i~mediately preceding vacant space exists.
: ..
. ' ' '' ' ' , 2~379~
- 18 - 21.1635 If the segment does not have an immediately proceeding vacant space, the. t~ble pointer i5 incremented 226 leaving the se~ment in its original location. Rowever, in this situation as illustrated in the bottom half of Fiy. 12 record 3 includes an immediately preceding vacant space and the re~ord s2gment for record 3 is stor~d 236 starting at physical addr~ss 1194. Next the vacant spa~e table 24 is updated by changing the entry and the cross reference table 22 is updat~d with the new address of the start of record 3. The table increment pointer is then incremented 226 to point at record number 4 and sa~e process is p~rfor~ed agai~. The re~ult is the co~pression of th2 records to remove vacant space after a record is deleted as is shown in Fig. 13.
If the record number 3 when encountered ~t step 230 in Fiq. 8D does not include a null address field, such as is illustrated in the top half of Fig. 14, the system follows the segment addresses and obtains the segments, combines the s~gments and determines the total size as discusæed in more detail with respect to steps 182-192 in Fig. BC. If the first segment in the record inc~udes vacant space 252 preceding the segment, then an available space variable i5 co~puted 254 as the sum o~ the segment size and the preceding vacant space size.
Next, the system determine~ 256 whether the segment ha~ vacant space imm~diately after the segment.
This is deter~ined by adding the data size and header size o~ the record, record 3, to the address and comparing for a match in tha vacant space table 24, which in ~his situation occur~ for ~h~ table 24 entry wit:h an address of 1288. In ~he exa~ple o~
Fig. 14 t:his is the case sinc~ vacant space exists at addre~3~ 1194 and addra~ 1288 bo~h prec~ing and s~bsequent to the r~cord segm~nt ~t addre ~ 125~.
If such subsequ0nt vacan~ spaca exi ts, then ~he 20~79~
- 19 - 21.1635 available ~pace is increased 258 by the a~oun~ o~
the vacant space. Next, the available space i~
compared to the total size obtained in step 250. If the available space is greater~-than or equal to the total size indicating that the sntire record will fit within the preceding and subsequent vacant spaces and the segment being examined, then all of the segments of the record are deleted 262 by clearing the me~ory locaticns. Next the combined record is saved 264 at thQ start of the available space, in this situation at address 1194, and the cross reference and vacant space tables are then updated 266. This results in the file contents as illustrated in the bottom half of Fig. 14. If the available space is less than the total size the system searches 270 the vacant space table 24 for sufficient space a~ illustrated in Fig. 8A by steps 108-118. The seg~ent i then stored 272 in the vacant space and the r2cord segments for the record are daleted 274, followed by update 276 of the cross reference and vacant space tables. In other words, the record segments are consolidated and stored at a new location making th~ stor~ge spac2 previously occupied by ~he record segments vaCant spac~.
The steps ~70-276 in Fig. 8E, can result in the creation of additional vacant spaces that are not remov~d a~ the syst~m continues examining the r~cord~ in the cross reference table 22. In addition, because the updat~ operation of Fig. 8B
can result in rscords being reduced in size additional vacant space can be created which is not removed by step~ 210-276. This problem can be solved by performing the proces~ of Figs. 8D and 8E
- starting with the first record in the cross reference table 22 and seguentially proceedin~
throuqh all the record~ in the ~ile 19. As a result this process includes ~tarting from a compr~ion interrupt 280 and se~ting 282 t~Q cross reference 20379~3~
- 20 - 21.1635 table poin~er to ~he first entry in the table 22.
In this way, all of the vacant space within the file is consolidated and all of the record which are divided into multiple seq~ents are consolidated into 5 a single record segment. Of cour~e it is possible for this compression routine to be executed when the end of file is reached as detected in step ~12 o~
Fig. 8A or when proc~ssing speed becomes slow as detected by the operating sy~tem.
lo The.steps o~ Figs. 8D and 8E result in an orderly layout of the records 20 of the ~ile 19 which is constantly maintained by the periodic combination of record segments and the removal of vacant sp~ce in the f il@ . This results in effi~ient use of the memory storage and the high speed location o~ a complete record in which access time is reduced. Of course, if de~ired, the r~cords could be sorted into some order which will further raduce access time. The combining o~ r~cord segments also reduces Sp2C2 requirements because multiple headers are not required since all headers of secondary seq~ents are eliminat~d.
Figs. 15A-lSD illustrate the op~ration o~
the presant invention when fixed length record segments ar~ provided as illustrated in Fig. 7. The vacant space table 24 and cross refer~nce table 22 o~ the prior embodiment are also used in thiC
e~b~diment. In addition, the Fig~. 9-14 which illustrate the operation of the previously disc~ssed embodiment are also applicable with respect to this e~bodimen~ except tha~ the records rather ~han being variable in length are fixed length.
A~ illu~trated in Fig. 15A onc~ an interxupt or subroutine call has occurred and the 3S .~ystem ha~ decided 302 that a new record i~ to be written or added, the y~te~ det~rmines 304 the number Or record segments ns~ded ~y dividinq the data size ~y tha data ~ield 54 byte width. In the ~37 ~ 267 case Or the data structure o~ Fig. 3, the data size provided ~o proqram 18 i~ divid~d by twQnty-eight.
Th2 ~y~tem then find~ a suf~ici~nt vacant ~pace to store the new record ~y examining th~ vacant ~pacQ
table 24 as discussed previously with re~pect to the previous embodiment. The record count i then written 308 into the segment header 52 and ~he data is written 310 into the dat;l field S4 of the record.
This step only stores as much o~ the new record data as will fit into the r~cord segment and maintains th~ remaining data in a buf~r. This step also decrements the remaining data count which is th~n compared 312 to determine whether any data remains.
I~ so, the address fi~ld 56 is updated by incrementing the address of the current record by 1 and storing it in the link ~ield 56. Th~ record count i~ decrem~nted and thel new record header ( at the address just stored in fi~ld 56) is upda~ed 316.
This loop contimles until no data remains and the system places 318 an ~nd o~ record indicator into the next segment address f iald 56 .
When tl1Q system requests a data renew~l or update, a~ illustrated in Fig. 15B, he syste~
search~ 330 th~ cross~ referenc~ tabl~ 22 for thQ
record nu~ber and then reads 332 the corrasponding rQc:ord ~eg~aent particularly th~ rQcord header. Th~
~iz~ o~ th~ record (nuD~b~r o~ sa~ents in ~ield 52) i3 compar~ad 334 with the size o~ tha updated record and if ~h~ r~cord size~ are equal th~ record i3 overwritteIl 336 by partitioning the updating r~cord into equal size seglaents and ~ollowing the chain oS
record addres~es found in ths f ield 56 until all the record seg~aents have been overwritterl.
I~ th~ record SiZ8 i~3 sEaller ~hs r~s:ord segm~nt header is~ updat~d 340 to reflect the r~duced numb~ar o:e seg~ent3, the da~a ~pacQ i5 cl{~ared and thQ corrl~sponding portion of tha updated record i 3 written 342 into thQ ~egm~nt. The sy~tQm th~n 2~79~
- 22 - 21. 1635 determirl~s 344 whether any data remains to be written and, i~ so, obtains 346 the next addres~
from the field 56 o~ the current record. The num~er of segment~ is then decre~ellted 348 and the record header at ~he next addr2~s .Ls updat~d 340. This loop continues until all the data has been written.
Since the updating record i'3 smaller than the original record the system ~ust now make the remaining segment record~ any, vacant and update the vacant space ~able. This is performed by first storing 350 the next address found in the ~ield 56 of current record segment and storing a null indicator in ths ~ield 56. The stored nsxt address is then sxamined 354 to determine whether the next lS address is a null indicatcr indicating that ~he end o~ tha record ~as been reached. If the end of the record has not been reach2d, the next addres~ is used to obtain 35S the next segmsnt and ~he next addre~s in that segment is stored 358. ~his new record is then cle~red 360 and th~ ~acan~ space tabl~ is updated by 362 ~y adding an appropriate entry. Thi~ loop continue~ until the stored next addres~ is a null indicator at which tims the update process for records smaller than the original record stops.
~ hen the upd~ted record is larger than the original record size, a~ illustrated in Fig. 15C, th~ sy~tem determines 370 the diference ln siz~ a~
a number o~ record segments. The syste~ then searches for a su~ficient size vacant space to store the dif~erence and then writes 37~ the total number o~ record segment~ ~or the record into ths current record segment, followed by writing the data into the data field 54 o~ the current record se~ment.
Th~ syste~ then decrement~ 378 ~hs record seg~ent count and if thi~ record segment is equal to zero indicating th~t there is no data re~aining, the system places 382 an end o~ datà indicator in the - 23 - 21.163S
addre~g field 5S. ~P the record seg~ent count indicate~ data re~ain~, the ~y~tem examines 386 the address field 56 of the curr~Bnt record segment to determine whether this i the end of the record. If not, the address i~ used to ~ove 388 to the n~xt record segment. Thi9 loop i,~ continued until the end of the original record i~ encounter~d and the system then stores 390 the remaining portion of tha record in a vacant space by performing ~he operations illustrated in steps 308-31B of Fig. 15A.
If a record should ~e deleted, as illustrated in Fig. 15D, the system first searches 400 for the record number in the cro~ reference table 22, obtains the record segment and stores 402 the contents found in the next addr~ss field 56.
The syste~ then updates 404 the vacan~ ~pace table 24 with the addres~ o~ the current record segment and clears 406 that rurrent record egment. Th~
next addrecs stored in step 402 is examinsd 408 to determine whether the end o~ the record has been reache~ and, if not, the next record segment is obtain~d using 410 using the next address. When the end of the record has be~n reached, the system performs the fil~ compression and racord concatenation operations discussed with respect to Fig. 8, thereby storing the data in sequential fixed record segments. The system also performs the read operation for fixed length record segments in substantially the same manner as discussed with respect to Fig. a .
The many featurss and advantages of the invention are apparent from the detailed specification and thu~ it is intended by the appended claims ~o cover all 5uch ~eatures and advantag~s o~ the invention which ~all within the tru~ spirit and sCop~ o~ th~ inven~ion. Further, since numerous ~odifications a~d changes will readily occur to thos~ skilled in the art, it is not ~o3~9a 25307 ~67 - 2~ -desirad to limit the invention to the exact con~tructiOn and operation illu3trated and describsd, and accsrdingly all suitable modifica~ions and equivalent~ may be resor~ed to, falling within tha scop~ o~ the invention. For example, it i~ possibls to implem~nt the syste~
without the cross referenc~ table 22 when looking for record~ by sequentially reading each re~ord segment in the file, deter~ining the next read address from the si2a field o~ th~ record and if a vacant space i~ encountered as indicated by a cleared or null size Sield, acce~sing th~ vacant spaca table to indirectly determine th~ address of the next segment in the ~ile. It i~ also possible to do without t~ vacant cpac~ tabl~ and ~ake requ~sts for vacant ¢pac~ to a ~emory management system that doter~ine~ ~he location o~ a spac~ of sufPiclent siza and add~ vacant spac~ w~Qn a record or portion is d~leted. It is al~o possibla to do ~ithout the file request indicator which indicate~
the type of file re~uest (r~ad, upda~e, add, delete) by exa~ining thQ size field oS th~ regue3t. For exa~pl~ thQ size Sield i~ po~itive th~ request is eith~r an ~dd or an updat~9 and is an add i~ ~he record do3~ not exist in the Sil~. If the record SiZ~ i9 z~ro th~ r~u~ a deleta request and if null i~ a read r~que3t. I~ i5 al~o pos-~ibla ~o re~v~ vacant 5pac~ in th~ by readin~ thQ
r~cord seg~en~ , sorting th3~ ~nd writing them to a new ~ allocated for that purpos~ and updating the table3 accordingly. It i5 ~ur~h~r po~sibl~ to eli~inate the SiZQ provid~d in th~ da~a r~qu~st and allow the progr2m 18 at s~p 102 to dstsr~in~ the size by countinq the us~d bytes in th~ ~uf~r suppliedl thor~toO Finally, Qv~n ~ough the pr~sent invention ha~ bQen d~cribed as b~ing initi~ed by an application progra~, th~ pr3~nt i~ven~ion can functioll a~ a data bas~ utility prcgra~.
BAC~GROUND OF THE INVENTION
Fi~ld of the Invention The present invention.is dirQcted to a data storage system designed to allow th~ size of records available for storing data to freely vary from record to record and over time and, more particularly, to a system that provides linked record seg~ents where th~ segments can be added or subtracted to allow the record slze to change, wher~
the segm~nts can be separately and randomly stored within data storage and where the systam automatically consolidates the segments at a single location as space become~ available.
Description of the Related Ar~
The structl~re of conventional file systems is dictated by the application progra~ designer when th~ application program is being designed. For example, during the design stage, the progra~mer prepare~ a data definition which defines the types and size~ o~ records in t~e file and defines the type~ and sizes o ~ield3 within each record. As the application program is created and debugged, the size, number and types of record~, se~ments and fields can change. How~ver, onc~ ~h~ program is debugged, the sizes of the record~, segments and Pields within a record are fix2d. If a user de~ires to change tha 8ize 0~ a racord, ~he application progra~ m,u3t be rede3ign~d and, unle~s the siz~
de~ini~ions are changed, ~hs user cannot enter data 2' ~ 3 ~
- 2 - 21. lfi35 i~to a record or a field which is larger than the space originally defin~d for that record. Since it i5 common ~or a user ~o want to change th~ amount o~
data being stored in a record or a field during the li~e of a program, the cost: and time required to change the data definitions for the program to customize the application program for the user can b~ large. This proble~ becomes ~uch worse if the application progra~ is part: o~ a package distributed to many different u3ers who want change the sizes of different records or fields. The maintenance problems associated with such changes also increa~e especially if a customized program i~ created and maintained for each user. This problem is increasing further in magnitude because o~ the desire to allow the user~'of software to ~reely chang~ tha siz~ o~ data fields u~ed for entering or outp~tting data on screen displays or terminal simply by entering ~ore or less data ~or that record or field. The trend toward allowing c~stomization of the terminal display by the user is ther~by creating database maintenance problems. That is, the data definition redefinition problem is be~ng further aggravated by the desire to increas~ the 5 flexibility o~ the man machine inter~ace.
one solution to this problem is ta provide each record or ~ield with a size that is su~iciently large so that any possible desired length of data can ~it within the record or the field. Thls is done at the design stage in a discussion between the program designers. This is an impractical solution to th~ problem and is particul,arly ineffici~nt in the utilization of the storage. Another solu~ion is to maintain a ~aster application progra~ in such a way as to taks into account ~each of the changes raquested by all the users, so that the size of the records or fields grow until the worst cas~ for each record is 2~37~
_ 3 - 21.1635 satisfied. This was~es memory space and requirQ~
that all user3 be provided with an updat~d program each time a change to the master program is made.
This also requires that the users submit change requests to the program designer and therefore does not satisfy tha flexibility need associated with the man machine interface. This solution is also an expensive solution.
- What is needed is a system which will allow record or field size to change dynamioally without requiring rede~inition of the sizes of the records or fields and which allows the user to enter a desired amount of data no matter what is the record or field size.
1~ SUMMARY OF THE INVENTION
It is an object of the present invention to provide a system which allows record or field size to change dynamically based on the 5ize or the length o~ the data input by the user.
It is another objec~ o~ the present invention to provide a system that is not seen or is transparent to the users.
It is also an object of the present invention to provide a system that efficiently utilizes available me~ory space.
It is a further o~ect of the present invention to provide a syste~ that reduces maintenance requirement~ for application programs.
The aboYe objects can be attained by a data storage system located between the application prsgram and the physical me~ory device. The data storage syste~ stores records a~ Iinked record se~ments that can be randomly located within the memory s1:orage device. If a record needs to be expanded and the current record or location is not large enough to accommodate the expansion, another record segment i5 allocated and ~tored in another location. If variable length record sQg~ents arQ
~3~
- 4 - 21.1635 used, only a single record extension is requilred.
However, i~ fixed length record seqments are used, the system allocates sufficient fixed length record segments to store the additional data. ~hen records shrink in size, the vacant space beco~es avallable for reuse. Periodically and when records are deleted, ths system perfor~s a process that combines or concatenates record segmlents and removes vacan space.
These together with other objects and advantages which will be subsequently apparent, reside in the details of construction and operation as more fully hereinaftQr described and claimed, reference being had to the accompanying drawings forming a part hereof, wherein lika numerals refer to lika parts throughout.
BRIEF D~SCRIPTION OF THE DRAWINGS
Fig. 1 illustrates components of the present invention:
FigsO 2 and 3 illustrate preferred data structures of the pres~ant invention:
Fig. 4 illustrates a record cross reference table of the present invention;
Fig. 5 illustrate~ a vacant space table of the present invention;
Fig. 6 illustrate3 a operation of the present invention using variable length record segm~ants;
Fig. 7 illustrates operation of the present invention using fixed length racord segments;
Figs. 8A-8E colDprise a flowchart of the processes o~ th~ prssent invention when variable length rçacord segments are used;
3S Figs. 9 - ~4 illustrat~ operation of the process of Figs. 8A-~E; and Figs. 15A-lSD illustrats operation o f h~
present iLnvention when fixed length record segments ' .
-. .
. .
2~3~9~5307_267 are used.
Fig. ll appears on the fourth sheet of drawings and Fig. 13 appears on the last sheet of drawings.
DESCRIPTION OF THE PREFERRED E~BODIMENTS
The present invention, as illustrated in Fig. 1, includes an input/output unit 10 via which a user adds updates and deletes records~ The input/output unit 10 is connected to a computer 12 which is also connected to a memory unit 14, such as a magnetic disk memory unit, and which is capable of randomly storing and retrieving data, typically alpha numeric data.
Within the computer 12 an application program 16 exists which may for example create a display for the input/output unit 10 which, for example, allows a user to access and update records in a personnel system. That is, the application program 16 performs the operations associated with interfacing with the user. The application program 16 communicates ~ith a data storage and retrieval program 18 which actually read~, updates and writes the records into the memory unit 14. The data storage and retrieval program 18 allows the user to access a file 19 and change the size of records 20 used by the application program 16 without regard to the original data definition of the application program 16. The data storage and retrieval program 18 is transparent to the user. The memory unit 14 for each file 19 accessed by the data storage and retrieval program 18 stores the f~le records 20, a record cross reference table 22 which is used to locate the records 20, and a vacant space table 24 which is used to determine vacant space within the file l9 that can be used for record - 5a - 2 0 3 73 9 ~ 25307-267 storage. The record cross re~erence tab:Le 22 and vacant space table 24 are preferably stored in the header port;~on of the f1le 19. As discussed later it is possible to implement the s~stem without the cross reference or vacant space tables.
'' : - ' : -- : .
.
2~79~S
- 6 - 21.lS35 During op~ration when a user reg~ests that the contentg of a record 20 or a fi~ld be obtained, the application program 16 preferably provides a record identifier (ID) t~ the data storage and 5 retrieval program 18. This progra~ 18 uses the cross reference table 22 to deter~ine the physical location of the desired record 20, obtains the record 20 and provides the record 20 to the application program 16. This record 20 can be provided to the application progra~ 16 by the invention in a number of different way~, however, it is preferred that the record 20 be provided to the application program 16 in two parts. The first part is a f ixed size record hea~er which includes the record ID, the size of th~ data field o~ t~e record and a pointer to a buf fer which includes the data of the record and which is tha second part of the record. T~e application program 16 then proyidec the contents or data of the record 20 to the input/output unit 10. During a record update or record writing operation the application program 16 also preferably provides the record header which includes the record ID, the size o~ the data field of the record 20 and the pointer to the buf~er that contains the data of the rQcord 20 to the data storage and retrieval program 18. The data storage and re~rieval program 18 then searches the cross re~erencs table 22 to determine whether th~ record ~0 exists and if no~ adds the record 20 as a new record 20 and if the record 20 does exist, updates the record 20. The operations sf writing, reading and updating file records 20 in the memory unit 14 will ba di cussed in greater detail hereinafter.
~lthough the applicatlon progra~ 16 is shown located within the same computer 12 as the data storage and retrieval progra~ 1~ and in direct associat:Lon wi~h the input/output unit 10 it ic possible for the input/output unit 10 to b~ re~otely ~ ~ 3 f~
- 7 - ~1.1635 located wi~h respect to the application program 16, for exa~pl~ with the application program 16 communicating to the program 18 over a co~munication network, and for the app1ic:ation pro~ram 16 to be executed in a different computer than the computer 12 containing the da~a storage and retri~val program 18. It is also possible to have the memory unit 14 located remotely from the c:omputer 12. It is preferred however that the input/output unit 10, comp~lter 12 and memory unit 14 be locally located.
A computer system such as a conventional personal computer or mini computer with a magnetic disk storage unit is pref~rred. It ls also preferred that the data storage and r~tria~ra1 program 18 be programmed in a language such as "Cp1usp1us"
suitable for processing linked lists. The system illustrated in Fig. 1 and particularly the program 18 of course can interface directly with the user as an independent database utility maintenance program~
Th~ present invention can use two different data structure~ for storing the segmented records which can both be used to accomplish the object~ of the pre~ent invention, and which are illustrated in Figs. 2 and 3. A~ illustrated in Fig. 2 each record segment 40 include~ a record head~r 42 and a data field 44. Th~ record header 42 includes a record ID ~ield 46, a size fiald 48 and a next seg~ent address field 50. The he~der 42 is of a fixed ~ze and it i5 preferablQ that the record ID
field 46 bQ 20 bytes long, the siz~ field 48 be 2 bytes long and the next segment address field 50 be 2 bytes 'Lony. Tha data field 44 is variable in length w:Lth th~ size o~ the d~ta fi~ld 44 being stored in the ~ize field 48. The record ID field 46 3 5 can cont~lin an a1phanumeric r~cord name which could correspolld to the nama of the f ield on ~he user ' s display or could be mere1y a record number. ~ach record 20 consi~ts o one or ~ore segm~nt~ 40 with ~ 67 the qegments being linked through the next segment address. As illustrated in Fig. 2, th~ record starting at location 1000 includes two ~egment~, the first segment i a 20 byte segment which starts at the physical addres~ 1000 and th~ ~econd segment is an 8 ~yte segment which start~ at physical address 1082. If a record 20 includes only a single seqment 40, thPn the next segment address field 50 includes a null indicator which acts as an end of record 20 indicator or instead of a null indicator a special and of record code could be used. A can be seen from Fig. 2, the data ~ields are variable in length, for ~xample, the data field 44 for thQ racord seg~3nt 40 starting at addres3 location 1000 is 20 byte~ long whil~ th~ record segment 40 starting at location 1114 is 64 bytes long.
The alternate data structure illustrated in Fig. 3 i~ a data structure which consist~ of fixed l~ngth record sagments 51 where ~he fixed length is preferably 32 by~es~ Each og th~ record segments 51 in th~ ~ix~d lenqth rQcord data structura preferably includes a h~ader ield 5~ the contents of which indicate ~he number of segments, including ~he current se~m~nt, re~aining in the record. Th~t i~, if th~ record includes 5 s~g~ents, the firs~ recurd segmen~, in the numb~r o~ segments ~ield 52, would includ~ th~ nu~b~r 5 and the second s~gment would includa the nu~ber 4 and 30 on until the ~i~th rQcord seg~nt includ~s an end o~ record indicator which could be a special character ~ch as a "*" or could be the s~gment count "1~. Ik is also possibls ~o put the segment coun~ only in the fir~t record s~!g~nt ~nd put a con~inuation cod~ in the field 52 o~ all succ~3siv~ segm~nts. The number o sQgm~nts field 52 i~ pre~rably 2 byte~ lon~.
Ad~acent the nuDb~r og ~eg~nt8 field i~ a dat~
~ield o~ a fix~d leng~h, such a~ 28 byt~. Thu~, in thi~ e~b~i~ent o~ the data ~tructuXo, th~ data in a ~ ~ 3 t~
_ g _ record is divided into 28 byte ~egment and i~ ~he length o~ da~a is no~ evenly divisible by 28 bytes, then a portion of the data fisld 54 ~or the last seqment will be e~pty. Adjacent the data field 54 is a next segment address field 56 or a link field which functions, in the same manner as the corresponding link ~ield 50 in Fig. 2~ to poin~ to the physical address of the next segmen~ 51 of the record 20 in the physical memory torage device, such as a magnetic disk. Thi~ ~ield, when a next seg~ent does ~ot exist can contain a null indicator or a special end o~ record code.
The record data structure~ illustratad in Fi~s. 2 and 3 ha~ a preferred arrangem~nt. It is possible, however, for a different arrangement o~
the fislds to be usedO For example, th~ next segment address f ield 5S could ba ad~acent to the number o~ segment~ fi~ld 52 in Fig. 3 and the siz~
field 4B could be located subsequent to th~ address field 50 in Fig. 2. One a~vantage of the data - structure~ o~ th~ pr~nt invention, in which the next segment pointer~ are part of ths seqment header is that a separate location table for secondary seqoent~ outsid~ of the record it~el~ is not nece~sary.
Fig. 4 illustrate~ the contents o~ a cros r3~eranc~ t~ble 22. Th~ cross re~erenca table 22 lncludes a record ID fi~ld 60 which i~ examined by the proce~s o~ the pre~ent invention to deten~ine whether th~ record ~xists in thc ~ile 19 and if so, to obtain the address of that record fro~ the addr~s~ ~ield 62. Th~ addre3~ field 62 indicate~
the physical addres~ of the firs~ r~cord s~ment ~0 or 50 on ths storage ~ediu~, such a~ the disk o~ the disk drive. This table 22 is not ab~olutely neces~ary but ~ake~ t~e proqra~ run ~aæter even though additional memory spac~ i~ u~ed.
. .
203~
- 10 - 21.1635 Fig. S illustrate the contents o~ a vacant Bpace table 24. Each entry in this table 24 includes the address of the start of a vacant space in the file 19 and the length 72 of this vaC~nt space. This table is also not absolut~ly necessa~y.
Prior to the first execution of the program 18, the application program lS has been d~bugged and an appropriate data de~inition or the records has been used to originally allocate storage for the fils 19. In this data definition the program designer has specified a size for the records 20 in the file 19, such as 224 byt~, and the file 19 has been creat~d ac~ordingly. BecausQ
o~ this invention, the designer need not be concerned with record size and the de igner need not discuss record siz~ with the other designer~ and can simply concentrate on generating the program l9. In other wordc, the file starts with record segments of an arbitrary size suitable for program testing as specified by the designer and the pr~sent invention adjusts record siz~ to suit the particular user.
Fig. 6 illustrates th~ principla of operation of the present invention when variable length data fields 44 are provided as illus~rated in Fig. 2 and Fi~. 7 illustrate~ the principle of operation of the pr~ent in~ention when ~ixed length - data fialds and records are provid~d a~ illustrated in Fig. 3.
With respect to Fig. 6 assuma that the original field or r~cord on the user's display was originally clesigned during development to show seven - alphanum~ric characters Or two bytes each~ In this situation the record 20 with record ID 500 locat~d at physic:al location 1000 would hav~ seYen alphanu~eric character space~ availabl~. Assum~
that the recorcl includ~ the s~ring "A~CDE" and ~our unus~d bytes, and that the user wi~h~ to updat~ the string to "ABCDEFGHIJ~. In this situation the ~37~
~ 21.1635 present invention would ~xamine record 500 starting at location looo, determine that the record 500 would only hold a portion of the updated string, would store that portion in the record segment, obtain the next availabl~ vacant space in the fil~
19 and use it to store the portion of the updated string which would not fit in the record se~ment at physical location 1000. The sys~em would also add the address of the next segment o~ the record to the first segment address field 50 and enter the appropriate size in the size field 4B of the newly allocated segment which is in this situation located at physical location 1082. The size and location o~
th~ vacant space would also chang~.
For the ~ixed record length data structure, as illustrated in Fig. 7, we will assume that the user wishes to updat~ the string "ABCDEF"
to the string ~ABCDEFGHIJKLMNOPQR~o In this situation, as in the variable length example previously discussed, the system will obtai~ the appropriate record segment using the cross reference table 22, determine that only a portio~ of the updated string will fit in the record segment, will update the data field 54 with the portion of the string which will fit ther~in, update the segment nu~ber field 52 to indicate that two re~ord segments ar~ involved and update th~ address field 56 to include the address of th2 next available record s g~ent in th0 file 19 which can store the remaining portion of the string, in this situation record 0003. The number of segmen~s field 52 of record 0003 is updated and a null indicator is entered in th~ next seg~ent address field 56. ThQ details o~
how the proc~s~es associated with Fig~. 6 and 7 perfor~ these operations will be discuss d in detail with rQspect to Fig~. 8A-8E and l5A-lD, respectively.
21337~
~ 1.1635 The present invention as previously discussed with respec~ to Fig. l, whenever the appllca~ion program 16 procluces a file re~uest, preferably providss a record identifier, a size (number of bytes) of the re!cord, if known, and a pointer to a buffer contair~ing the data of the record if n~cessary and the bu~er. The application program in this situation conventionally counts the bytes of data input and provides the size and the buffer. In addition, it is preferred that the application program 16 provide an operation indicator or command for the add, update, read and delete operations, however, the command is not absolutely necessary as discussed later herein but makes the invention operate faster. It i~ also prsferred, as illustrated in Fig. 8A, that the present invention be interrupt driven and o~ course it is recognized as an alternative that the process 18 of the present invention can be called as a subroutine or subprocedure of the application progra~ 16. Fig. 8A is a first of a series of flowcharts which illustrata the processes performed by the present invention when variabla len~th record segm~nt~ are used.
Fig. 8A illustrates not only a pcrtion of th~ control proces~ of the present invention which det~FmineA the typ~ of file accas~ request but also illustrates tha portion of the process of the present invention which adds new records to the fil~. Fig. 8A will be discussed with respect to Fig. 9 which is an example of the r~cord addin~
operation. Onc~ a file requ~st interrupt 100 or subroutin~ call ha occurred, the process determines 102 from the co~mand which o~ th~ opera~ion~ i~ to b~ perfo:r~ed. ~hen the new record addition oparatio:n i~ the file reque~t co~and, a vacant qpac~ pointer i~ set 104 ~o ~he ~irst entry in the table 24, which would be pointing at th~ entry with ~ 0 3 7 9 9 ~
- 13 - 21.1635 the physical address 846 illustrated in Fig. g.
Next the ~ystem reads 106 th~ record ID and size passed to the program 18 and for this example we will assu~e th2t the new rec:ord ID i5 14 and the size is thirty bytes (six bytes of data and twenty-four bytes for the header). The system th~n reads 108 the entry in the vacant spac~ table 24 and compares 110 the size from t:he vacant table size field 72, which is in this case three bytes, with the size of the record (which is six bytes~. If the size of ths vacant space is not sufficient to allow the new record to be inserted in the vacant space, which is the case for the vacan~ space at location 846, the system chec~s 112 to see i~ the end of the table 24 (and also the end of the file) has b~en reached.
If so the system calls a conventional utility which allocates 114 more ~ile space and then upd~tes 116 thQ vacant space table 24 accordingly.
~0 In the present situation the vacant size of three byte~ is not sufficient ~or storing the record of length thirty bytes and the e~d of tha table 24 has not yet been reached. In this situation the vacant spacs pointer i~ incre~ented 118 and the next entry in the table 24 is obtained.
This cycle of searching the vacant space table 24 for a vacant space of suitabl~ size continu~s until a spacs of sufficient size is encountered and in the example o Fig. 9 this will occur when the vacant space entry with the address of 1102 is encountered. Once a suf~iciently large vacant space is encountered, even if it i obtained by axpancling the size o~ ~he file 19, the system stores-1.!0 the record ID, si2e and data at the vacant addr~s~ a~ illustrated in the ~otto~ half o~
Fig. 9 wl~ere a record with a da~a field of six bytes has been added at physical addr~s~ 1102. Next the system upda~es 122 the vacan~ spac~ table 24 ~o take : . , ' - .
, . , ' .
.
?.J~37~35 - 14 - 21.1635 into ac~ount the reduced size of th~ available vacant space, which in this situation resul ~ in a new vacant space addresg of 1132 and a vacant space size of 10 bytes. Next, the cross re~erenc~ table 22 is updated 124 by adding the record ID ~or the record to the first availab]Le location in the table 22 along with the address o~ the new r~cord, as illustrated by the entry in the table 22 in the low~r half of Fig. 9 which has a record nu~ber identifier o~ 14 and an ad~res3 o~ 1102. Once the table 22 is upda~ed, the system returns 126 to the wait state or returns ~rom the system call as is appropriate.
When the present invention is provided 15 with an update or renewal file request, as illustrated in Fig. 8B, thQ cross reference table 22 is first searched 140 for the record ID of the desired record and the address of that record i~
obtained. The system then reads 142 the record header 42. If the record rontain~ additional segments as indicated by a non-null next seg~ent address field 50, the additional segments are obtained 144, combined and the total siz~ of the . record i~ deter~ined. The step~ o~ the block 144 will be discussed`in ~oxe detail with respect to blo~k~ 182-192 in Fig. 8C. Once the total size i~
determined it is compared 146 to the size of the record be~ng updated. If the size of the record being updated is le~s than or equal to the total size, a determination 148 is made concerning whether the sizes ara equal. I~ equal, the record segmen~
or segments are updated 150 by dividing th~ data in the data ~uffer provided to program 18 into seg~ents in accordance with the segment size ~ound in the header~ of each of the segmen~ and ~he data is written .in~o the appropriate record segments using th~ reco:rd ~egment addresses which arQ used ~o find the record ~egment~ during ths ~egment combination - - . , ': ' . ~ :
- : :
, . - - - ., ' .
9 ~ ~
- 15 - 21.1635 operation.
If the new data size is less than the total ~ize of th~ ori~inally ~tored record, and for the example in Fig. 10 we assum~ that the record h~s s shrunk by sixteen bytes, the 5ize of the vacant space which is created by the record size reduction is computed by subtracting the new data size ~rom the total data size. The starting location of the vacant space is also determined and a new entry is added 152 to the vacant space table 24 as illustrated in the bottom half of Fiq~ 10 where a new entry for the physical address 2086 is found.
Of course i~ tha record size shrinks sufficiently to free up more than one segment, then several new entrie~ to the vacant space table 24 are created.
Once the vacant space table entries aEe created, the system updates 154 the segment si~e in the segments of tha record to reflect the change in the total record size. Once the se~ment size in the appropriat~ segments is updated the data fields o~
the segments are updated which in this situation also involves clearing the new vacant spaceO
If the new data size is lar~er than the total size, and for this example we will as~u~e that the record is increasing in size by six data bytes or a segment of thi~ty bytes, the system stores 158 the updated data in the s~gments of the record until th~ ~inal data segment is encountered a~ indicated by a null next seg~ent address field S0. The remaining da~a length is determined 160 and used ~o obtain 162 vacant space sufficient to store the remaining data plus a header as a new segment. The opexation o~ obtaining the vacant space has been discussed with respect to s~eps 10~ - 118 in Fig. 8A
and need no~ be repeated here. Once an appropriate size vacant space is available, and in this exa~ple the vacant spaca is located at addres~ 1082, ~he system store~ 164 ths record ID, the 5iZ~ equiva}ent " ' ' , .
.
2~s~ 25307~267 to the remaining data leng~h and the data starting at tha vacant address and th~n updatss 166 the vacant space table 24. The operation of seqmenting the record and storing it in a vacant location has s been illustrated in Fig. 6 and Fig. ll illustrates how the contents of th~ vac.lnt space table 24 would be changed for the example of Fig. 6 by the change of the entry having address 1082 to an address of lllS with a siza ~ield 72 containing the value 60.
Because the beginning of the record in this situation is located at the same position as prior to the update, the cross reference table 22 does not change.
When the ~ile request i~ a r~ad or lS extraction r~quest, a~ illu~trat~d in Fig. 8C, the record ID in the requ~t is used to search 180 th~
croes re~erenc~ tabl~ 22 to find th~ addrsss of the rQcord. When th~ r~cord addre~ found, the addres~ i used to read the 5ize and the contents of the next seg~ent address field 50 o~ the head~r 42, and the data in field 44 i~ stored in a temporary buf~er. Then the tot~l ~ize for the x~cord is updatad 186 by th~ ~iz~ valu~ ~ound in th~ segment and a d~ter~in~tion 188 i5 ~ade concerning whether th~ addre~. ~iQld 50 contain~ a null indicator indicating ~hat this is th~ end o~ th~ record. If th~ addre~s ~ield 50 is not null thi~ indicates that ths record include another seg~ent. If the record includes another s~gment th~ buffer pointer is updated l90 and the next record segment header i5 read 182 u~ing the address~ When the last ~egment is found, thQ ~uf~rs ar~ combined 192 and output to the us~r 194 by output~ing th~ r~cor~ ID, ~e size and a point2r ~o a bu~r which contain~ ths da~a o~
th~ reco:rd.
When the fils requast co~mand indicat~s that ~ record should b~ d~let~, a~ illustrated in Fig. 8D, th~ proc~3 s~arch~s 210 th~ ~ro~3 . ' ' ' ~
.
- . ........... .
. ~ .
~ ~ i3 P~
- 17 - 21.1635 reference table 22 for the record. In thi~
situation u~ing Fig. 12 as am example in which record number 2 will b~ del~ted, the system accesses 212 the cross reference table 22 looking for record 2 and finds the address 1194. The system then reads 214 the record segment header 42 and the data 44 thereby obtaining th~ size and the contents o the next address field 50. A determination is then made 216 as to whether this record should be delPted. I~
so the chain of segment addresses in the next segment address field 50 is followed to obtain 218 all o~ the segments and the segment addresses and siz~s are temporarily saved. T~e segments are then deleted 220 by clearing the space in th~ storage medium using the temporarily saved sPg~ent addresses and size indicators. The system then adds 222 vacant spac~ entries to the vacant space table 24, as illustrated in the bottom half of Fig. 12, and then updates 224 ~he cross reference table to remove this record ID fro~ the cross reference table 22, as also illustrated in the bottom half of Fig. 12.
Next, the system increments 226 ths table pointer to point to the next record in the cross reference table 22, whic~ in this situation will be record numbQr 3.
onc2 again the record segment is read and sinc~ thi~ is not a record that needs to be deleted, thQ system proceeds to determine 230 whether th~
addrQss field is empty. In this casa, the field is empty and a d~ter~ination is made 232 as to whether the segment ha~ an im~ediately proceeding vacant space. This i5 determined by s~arching the vacant space table 24 for tha vacant space with th~ next lowest ad,dres~, in this situation addre3~ 11940 Then length of ~he vacant spaca i~ added to the address resulting in an address of 1254 which is compared to th~ record addres . I~ th~ addre~se~
match an i~mediately preceding vacant space exists.
: ..
. ' ' '' ' ' , 2~379~
- 18 - 21.1635 If the segment does not have an immediately proceeding vacant space, the. t~ble pointer i5 incremented 226 leaving the se~ment in its original location. Rowever, in this situation as illustrated in the bottom half of Fiy. 12 record 3 includes an immediately preceding vacant space and the re~ord s2gment for record 3 is stor~d 236 starting at physical addr~ss 1194. Next the vacant spa~e table 24 is updated by changing the entry and the cross reference table 22 is updat~d with the new address of the start of record 3. The table increment pointer is then incremented 226 to point at record number 4 and sa~e process is p~rfor~ed agai~. The re~ult is the co~pression of th2 records to remove vacant space after a record is deleted as is shown in Fig. 13.
If the record number 3 when encountered ~t step 230 in Fiq. 8D does not include a null address field, such as is illustrated in the top half of Fig. 14, the system follows the segment addresses and obtains the segments, combines the s~gments and determines the total size as discusæed in more detail with respect to steps 182-192 in Fig. BC. If the first segment in the record inc~udes vacant space 252 preceding the segment, then an available space variable i5 co~puted 254 as the sum o~ the segment size and the preceding vacant space size.
Next, the system determine~ 256 whether the segment ha~ vacant space imm~diately after the segment.
This is deter~ined by adding the data size and header size o~ the record, record 3, to the address and comparing for a match in tha vacant space table 24, which in ~his situation occur~ for ~h~ table 24 entry wit:h an address of 1288. In ~he exa~ple o~
Fig. 14 t:his is the case sinc~ vacant space exists at addre~3~ 1194 and addra~ 1288 bo~h prec~ing and s~bsequent to the r~cord segm~nt ~t addre ~ 125~.
If such subsequ0nt vacan~ spaca exi ts, then ~he 20~79~
- 19 - 21.1635 available ~pace is increased 258 by the a~oun~ o~
the vacant space. Next, the available space i~
compared to the total size obtained in step 250. If the available space is greater~-than or equal to the total size indicating that the sntire record will fit within the preceding and subsequent vacant spaces and the segment being examined, then all of the segments of the record are deleted 262 by clearing the me~ory locaticns. Next the combined record is saved 264 at thQ start of the available space, in this situation at address 1194, and the cross reference and vacant space tables are then updated 266. This results in the file contents as illustrated in the bottom half of Fig. 14. If the available space is less than the total size the system searches 270 the vacant space table 24 for sufficient space a~ illustrated in Fig. 8A by steps 108-118. The seg~ent i then stored 272 in the vacant space and the r2cord segments for the record are daleted 274, followed by update 276 of the cross reference and vacant space tables. In other words, the record segments are consolidated and stored at a new location making th~ stor~ge spac2 previously occupied by ~he record segments vaCant spac~.
The steps ~70-276 in Fig. 8E, can result in the creation of additional vacant spaces that are not remov~d a~ the syst~m continues examining the r~cord~ in the cross reference table 22. In addition, because the updat~ operation of Fig. 8B
can result in rscords being reduced in size additional vacant space can be created which is not removed by step~ 210-276. This problem can be solved by performing the proces~ of Figs. 8D and 8E
- starting with the first record in the cross reference table 22 and seguentially proceedin~
throuqh all the record~ in the ~ile 19. As a result this process includes ~tarting from a compr~ion interrupt 280 and se~ting 282 t~Q cross reference 20379~3~
- 20 - 21.1635 table poin~er to ~he first entry in the table 22.
In this way, all of the vacant space within the file is consolidated and all of the record which are divided into multiple seq~ents are consolidated into 5 a single record segment. Of cour~e it is possible for this compression routine to be executed when the end of file is reached as detected in step ~12 o~
Fig. 8A or when proc~ssing speed becomes slow as detected by the operating sy~tem.
lo The.steps o~ Figs. 8D and 8E result in an orderly layout of the records 20 of the ~ile 19 which is constantly maintained by the periodic combination of record segments and the removal of vacant sp~ce in the f il@ . This results in effi~ient use of the memory storage and the high speed location o~ a complete record in which access time is reduced. Of course, if de~ired, the r~cords could be sorted into some order which will further raduce access time. The combining o~ r~cord segments also reduces Sp2C2 requirements because multiple headers are not required since all headers of secondary seq~ents are eliminat~d.
Figs. 15A-lSD illustrate the op~ration o~
the presant invention when fixed length record segments ar~ provided as illustrated in Fig. 7. The vacant space table 24 and cross refer~nce table 22 o~ the prior embodiment are also used in thiC
e~b~diment. In addition, the Fig~. 9-14 which illustrate the operation of the previously disc~ssed embodiment are also applicable with respect to this e~bodimen~ except tha~ the records rather ~han being variable in length are fixed length.
A~ illu~trated in Fig. 15A onc~ an interxupt or subroutine call has occurred and the 3S .~ystem ha~ decided 302 that a new record i~ to be written or added, the y~te~ det~rmines 304 the number Or record segments ns~ded ~y dividinq the data size ~y tha data ~ield 54 byte width. In the ~37 ~ 267 case Or the data structure o~ Fig. 3, the data size provided ~o proqram 18 i~ divid~d by twQnty-eight.
Th2 ~y~tem then find~ a suf~ici~nt vacant ~pace to store the new record ~y examining th~ vacant ~pacQ
table 24 as discussed previously with re~pect to the previous embodiment. The record count i then written 308 into the segment header 52 and ~he data is written 310 into the dat;l field S4 of the record.
This step only stores as much o~ the new record data as will fit into the r~cord segment and maintains th~ remaining data in a buf~r. This step also decrements the remaining data count which is th~n compared 312 to determine whether any data remains.
I~ so, the address fi~ld 56 is updated by incrementing the address of the current record by 1 and storing it in the link ~ield 56. Th~ record count i~ decrem~nted and thel new record header ( at the address just stored in fi~ld 56) is upda~ed 316.
This loop contimles until no data remains and the system places 318 an ~nd o~ record indicator into the next segment address f iald 56 .
When tl1Q system requests a data renew~l or update, a~ illustrated in Fig. 15B, he syste~
search~ 330 th~ cross~ referenc~ tabl~ 22 for thQ
record nu~ber and then reads 332 the corrasponding rQc:ord ~eg~aent particularly th~ rQcord header. Th~
~iz~ o~ th~ record (nuD~b~r o~ sa~ents in ~ield 52) i3 compar~ad 334 with the size o~ tha updated record and if ~h~ r~cord size~ are equal th~ record i3 overwritteIl 336 by partitioning the updating r~cord into equal size seglaents and ~ollowing the chain oS
record addres~es found in ths f ield 56 until all the record seg~aents have been overwritterl.
I~ th~ record SiZ8 i~3 sEaller ~hs r~s:ord segm~nt header is~ updat~d 340 to reflect the r~duced numb~ar o:e seg~ent3, the da~a ~pacQ i5 cl{~ared and thQ corrl~sponding portion of tha updated record i 3 written 342 into thQ ~egm~nt. The sy~tQm th~n 2~79~
- 22 - 21. 1635 determirl~s 344 whether any data remains to be written and, i~ so, obtains 346 the next addres~
from the field 56 o~ the current record. The num~er of segment~ is then decre~ellted 348 and the record header at ~he next addr2~s .Ls updat~d 340. This loop continues until all the data has been written.
Since the updating record i'3 smaller than the original record the system ~ust now make the remaining segment record~ any, vacant and update the vacant space ~able. This is performed by first storing 350 the next address found in the ~ield 56 of current record segment and storing a null indicator in ths ~ield 56. The stored nsxt address is then sxamined 354 to determine whether the next lS address is a null indicatcr indicating that ~he end o~ tha record ~as been reached. If the end of the record has not been reach2d, the next addres~ is used to obtain 35S the next segmsnt and ~he next addre~s in that segment is stored 358. ~his new record is then cle~red 360 and th~ ~acan~ space tabl~ is updated by 362 ~y adding an appropriate entry. Thi~ loop continue~ until the stored next addres~ is a null indicator at which tims the update process for records smaller than the original record stops.
~ hen the upd~ted record is larger than the original record size, a~ illustrated in Fig. 15C, th~ sy~tem determines 370 the diference ln siz~ a~
a number o~ record segments. The syste~ then searches for a su~ficient size vacant space to store the dif~erence and then writes 37~ the total number o~ record segment~ ~or the record into ths current record segment, followed by writing the data into the data field 54 o~ the current record se~ment.
Th~ syste~ then decrement~ 378 ~hs record seg~ent count and if thi~ record segment is equal to zero indicating th~t there is no data re~aining, the system places 382 an end o~ datà indicator in the - 23 - 21.163S
addre~g field 5S. ~P the record seg~ent count indicate~ data re~ain~, the ~y~tem examines 386 the address field 56 of the curr~Bnt record segment to determine whether this i the end of the record. If not, the address i~ used to ~ove 388 to the n~xt record segment. Thi9 loop i,~ continued until the end of the original record i~ encounter~d and the system then stores 390 the remaining portion of tha record in a vacant space by performing ~he operations illustrated in steps 308-31B of Fig. 15A.
If a record should ~e deleted, as illustrated in Fig. 15D, the system first searches 400 for the record number in the cro~ reference table 22, obtains the record segment and stores 402 the contents found in the next addr~ss field 56.
The syste~ then updates 404 the vacan~ ~pace table 24 with the addres~ o~ the current record segment and clears 406 that rurrent record egment. Th~
next addrecs stored in step 402 is examinsd 408 to determine whether the end o~ the record has been reache~ and, if not, the next record segment is obtain~d using 410 using the next address. When the end of the record has be~n reached, the system performs the fil~ compression and racord concatenation operations discussed with respect to Fig. 8, thereby storing the data in sequential fixed record segments. The system also performs the read operation for fixed length record segments in substantially the same manner as discussed with respect to Fig. a .
The many featurss and advantages of the invention are apparent from the detailed specification and thu~ it is intended by the appended claims ~o cover all 5uch ~eatures and advantag~s o~ the invention which ~all within the tru~ spirit and sCop~ o~ th~ inven~ion. Further, since numerous ~odifications a~d changes will readily occur to thos~ skilled in the art, it is not ~o3~9a 25307 ~67 - 2~ -desirad to limit the invention to the exact con~tructiOn and operation illu3trated and describsd, and accsrdingly all suitable modifica~ions and equivalent~ may be resor~ed to, falling within tha scop~ o~ the invention. For example, it i~ possibls to implem~nt the syste~
without the cross referenc~ table 22 when looking for record~ by sequentially reading each re~ord segment in the file, deter~ining the next read address from the si2a field o~ th~ record and if a vacant space i~ encountered as indicated by a cleared or null size Sield, acce~sing th~ vacant spaca table to indirectly determine th~ address of the next segment in the ~ile. It i~ also possible to do without t~ vacant cpac~ tabl~ and ~ake requ~sts for vacant ¢pac~ to a ~emory management system that doter~ine~ ~he location o~ a spac~ of sufPiclent siza and add~ vacant spac~ w~Qn a record or portion is d~leted. It is al~o possibla to do ~ithout the file request indicator which indicate~
the type of file re~uest (r~ad, upda~e, add, delete) by exa~ining thQ size field oS th~ regue3t. For exa~pl~ thQ size Sield i~ po~itive th~ request is eith~r an ~dd or an updat~9 and is an add i~ ~he record do3~ not exist in the Sil~. If the record SiZ~ i9 z~ro th~ r~u~ a deleta request and if null i~ a read r~que3t. I~ i5 al~o pos-~ibla ~o re~v~ vacant 5pac~ in th~ by readin~ thQ
r~cord seg~en~ , sorting th3~ ~nd writing them to a new ~ allocated for that purpos~ and updating the table3 accordingly. It i5 ~ur~h~r po~sibl~ to eli~inate the SiZQ provid~d in th~ da~a r~qu~st and allow the progr2m 18 at s~p 102 to dstsr~in~ the size by countinq the us~d bytes in th~ ~uf~r suppliedl thor~toO Finally, Qv~n ~ough the pr~sent invention ha~ bQen d~cribed as b~ing initi~ed by an application progra~, th~ pr3~nt i~ven~ion can functioll a~ a data bas~ utility prcgra~.
Claims (20)
1. A dynamic data storage system, comprising:
memory means for storing; and processing means for determining whether a current first record segment in said memory means will store input data input by a user, and linking a second record segment in said memory means to said first record segment and storing the input data in the first and second record segments when the current first record segment will not store the input data.
memory means for storing; and processing means for determining whether a current first record segment in said memory means will store input data input by a user, and linking a second record segment in said memory means to said first record segment and storing the input data in the first and second record segments when the current first record segment will not store the input data.
2. A system as recited in claim 1, wherein the current first record segment includes a next address field where an address of the second segment is stored.
3. A system as recited in claim 2, wherein the first record segment is variable in length.
4. A system as recited in claim 2, wherein the first record segment is fixed in length.
5. A system as recited in claim 1, wherein said processing means combines the first and second segments into a single segment.
6. A system as recited in claim 1, wherein said processing means stores the first and second segments sequentially in said memory means.
7. A system as recited in claim 1, wherein said memory means stores said segments in a file and said processing means stores the second - 26 - 21.1635 segment in the first vacant space in the f file large enough to store the second segment.
8. A system as recited in claim 7, wherein said processing means periodically combines segments into a single segment and removes vacant space in the file.
9. A system as recited in claim 7, wherein when said processing means deletes one of the segments, and combines segments and removes vacant space subsequent to the deleted one of the segments in the file.
10. A system as recited in claim 1, wherein when a length of the input data is smaller than a length of the first record segment, said processing means reduces the length of the first record segment to the length of the input data and makes a difference available for other record segments.
11. A system as recited in claim 1, further comprising an input unit through which the user inputs the input data.
12. A dynamic data storage system, comprising:
storage storing a file including a first record segment including data having a stored length and a next address field;
a processor connected to said storage and determining whether input data having an input length is less than, equal to or greater than the stored length, storing the input data in the first record segment having a reduced stored length and designating vacant space in the file when the input length is less than the stored length, storing the input data in the first record segment and in a second record segment at a first available vacant location in the file and storing an address of the second record segment in the next address field when the input length is greater than the stored length, - 27 - 21.1635 combining the first and second record segments into a single record segment when a vacant area in the file equal to a size of the first and second record segments combined becomes available.
storage storing a file including a first record segment including data having a stored length and a next address field;
a processor connected to said storage and determining whether input data having an input length is less than, equal to or greater than the stored length, storing the input data in the first record segment having a reduced stored length and designating vacant space in the file when the input length is less than the stored length, storing the input data in the first record segment and in a second record segment at a first available vacant location in the file and storing an address of the second record segment in the next address field when the input length is greater than the stored length, - 27 - 21.1635 combining the first and second record segments into a single record segment when a vacant area in the file equal to a size of the first and second record segments combined becomes available.
13. A method of dynamic data storage, comprising:
(a) allowing a user to input data of any length;
(b) determining a difference in length between the input data and a first record segment;
(c) allocating a second record segment having a length equal to the difference when the difference is positive;
(d) linking the first record segment to the second record segment; and (e) storing the input data in the first and second record segments.
(a) allowing a user to input data of any length;
(b) determining a difference in length between the input data and a first record segment;
(c) allocating a second record segment having a length equal to the difference when the difference is positive;
(d) linking the first record segment to the second record segment; and (e) storing the input data in the first and second record segments.
14. A method as recited in claim 13, further comprising:
(f) reducing a size of the first record segment when the difference is negative; and (g) indicating the difference is available for data storage when the difference is negative.
(f) reducing a size of the first record segment when the difference is negative; and (g) indicating the difference is available for data storage when the difference is negative.
15. A method as recited in claim 13, further comprising:
(f) allowing the user to indicate a record segment is to be deleted; and (g) indicating the deleted record segment is available for data storage.
(f) allowing the user to indicate a record segment is to be deleted; and (g) indicating the deleted record segment is available for data storage.
16. A method as recited in claim 13, further comprising:
(f) searching for file vacant space; and (g) combining record segments and storing a single record segment in the vacant space when the combined record segments have a combined length shorter than or equal to a space length of the vacant space.
- 28 - 21.1635
(f) searching for file vacant space; and (g) combining record segments and storing a single record segment in the vacant space when the combined record segments have a combined length shorter than or equal to a space length of the vacant space.
- 28 - 21.1635
17. A method of dynamic data storage, comprising:
(a) allowing a user to input data having an input length;
(b) comparing the input length to a stored length of a first record segment;
(c) allocating a second record segment having a length equal to a difference between the input and stored lengths when the input data length is greater than the stored data length;
(d) linking the first record segment to the second record segment by storing an address of the second record segment in the first record segment;
(e) storing the input data in the first and second record segments;
(f) reducing a size of the first record segment when the stored length is greater than the input length; and (g) indicating the difference is available for data storage;
(h) allowing the user to indicate a record segment is to be deleted;
(i) indicating the deleted record segment is available for data storage;
(j) searching for file vacant space having a space length; and (k) combining the first and second record segments and storing a single record segment in the vacant space when the combined first and second record segments have a combined length shorter than or equal to the space length of the vacant space.
(a) allowing a user to input data having an input length;
(b) comparing the input length to a stored length of a first record segment;
(c) allocating a second record segment having a length equal to a difference between the input and stored lengths when the input data length is greater than the stored data length;
(d) linking the first record segment to the second record segment by storing an address of the second record segment in the first record segment;
(e) storing the input data in the first and second record segments;
(f) reducing a size of the first record segment when the stored length is greater than the input length; and (g) indicating the difference is available for data storage;
(h) allowing the user to indicate a record segment is to be deleted;
(i) indicating the deleted record segment is available for data storage;
(j) searching for file vacant space having a space length; and (k) combining the first and second record segments and storing a single record segment in the vacant space when the combined first and second record segments have a combined length shorter than or equal to the space length of the vacant space.
18. A data structure, comprising:
a first data record segment stored in a first physical location of a memory media and having a record identification field including record identifier, a first data field and a next address record field including an address of a second - 29 - 21.1635 physical location in the memory media; and a second data record segment stored in the second physical location and having the record identification field including the record identifier, a second data field, and where data of a single record being stored in the first and second data fields of said first and second data record segments.
a first data record segment stored in a first physical location of a memory media and having a record identification field including record identifier, a first data field and a next address record field including an address of a second - 29 - 21.1635 physical location in the memory media; and a second data record segment stored in the second physical location and having the record identification field including the record identifier, a second data field, and where data of a single record being stored in the first and second data fields of said first and second data record segments.
19. A structure as recited in claim 18, wherein the first and second data fields are variable in size and said first and second data record segments include first data size fields indicating a size of the first and second data fields, respectively.
20. A structure as recited in claim 18, wherein the first and second data fields are fixed in size.
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2066152A JPH03266039A (en) | 1990-03-16 | 1990-03-16 | Free format data link processing system |
| JP2-66152 | 1990-03-16 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CA2037995A1 true CA2037995A1 (en) | 1991-09-17 |
Family
ID=13307611
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CA002037995A Abandoned CA2037995A1 (en) | 1990-03-16 | 1991-03-11 | Dynamic data storage system |
Country Status (4)
| Country | Link |
|---|---|
| US (1) | US5548751A (en) |
| EP (1) | EP0446940A3 (en) |
| JP (1) | JPH03266039A (en) |
| CA (1) | CA2037995A1 (en) |
Families Citing this family (56)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH03266039A (en) * | 1990-03-16 | 1991-11-27 | Fujitsu Ltd | Free format data link processing system |
| US5592348A (en) * | 1991-05-17 | 1997-01-07 | Adaptec, Inc. | Method and structure for locating and skipping over servo bursts on a magnetic disk |
| JP2962335B2 (en) * | 1991-06-24 | 1999-10-12 | 日本電気株式会社 | Free space search method |
| US5479656A (en) * | 1992-05-13 | 1995-12-26 | Rawlings, Iii; Joseph H. | Method and system for maximizing data files stored in a random access memory of a computer file system and optimization therefor |
| JP3421378B2 (en) * | 1993-03-23 | 2003-06-30 | 株式会社東芝 | Transmission control method |
| JP3445304B2 (en) * | 1993-03-29 | 2003-09-08 | 株式会社東芝 | File management device |
| DE4334313A1 (en) * | 1993-10-08 | 1995-04-13 | Sel Alcatel Ag | Method for managing a voice memory and device therefor |
| JP3594980B2 (en) * | 1993-12-10 | 2004-12-02 | 株式会社東芝 | File management method |
| US5729742A (en) * | 1995-02-27 | 1998-03-17 | International Business Machines Corporation | System and method for enabling multiple computer systems to share a single sequential log |
| JPH0981582A (en) * | 1995-09-12 | 1997-03-28 | Fujitsu Ltd | Method and device for data management based on value |
| GB2308471B (en) * | 1995-12-22 | 1999-10-20 | Nokia Mobile Phones Ltd | Memory defragmentation |
| KR0176637B1 (en) * | 1995-12-30 | 1999-04-15 | 김광호 | Programmable control sequencer and map distributing method therefor of a disk controller |
| KR0159435B1 (en) * | 1995-12-30 | 1998-12-15 | 김광호 | Programmable control sequencer of disk controller and its map allocating method |
| US5933842A (en) * | 1996-05-23 | 1999-08-03 | Microsoft Corporation | Method and system for compressing publication documents in a computer system by selectively eliminating redundancy from a hierarchy of constituent data structures |
| US5734340A (en) * | 1996-08-27 | 1998-03-31 | Symantech Corporation | Method and apparatus for storing run-intensive information in compact form |
| FR2759795B1 (en) * | 1997-02-14 | 1999-05-07 | Francois Charles Oberthur Fidu | METHOD FOR STORING DATA IN A WRITTEN CARD MEMORY |
| US5987472A (en) * | 1997-03-31 | 1999-11-16 | Combustion Engineering, Inc. | System and method for handling database cross references |
| US6112209A (en) | 1998-06-17 | 2000-08-29 | Gusack; Mark David | Associative database model for electronic-based informational assemblies |
| FR2791444A1 (en) * | 1999-03-26 | 2000-09-29 | Open Software Foundation Resea | Data processing system automated memory allocation in virtual machine applications; uses decomposition graph applied automatically on element to forms at least elementary parts having size lower or equal to base memory |
| US6532476B1 (en) | 1999-11-13 | 2003-03-11 | Precision Solutions, Inc. | Software based methodology for the storage and retrieval of diverse information |
| KR100366760B1 (en) * | 2000-01-12 | 2003-01-08 | 주식회사 위즈맥스 | A method of combining multi media files |
| US6668304B1 (en) * | 2000-01-18 | 2003-12-23 | International Business Machines Corporation | Transaction support on logical disks |
| US6453403B1 (en) * | 2000-05-19 | 2002-09-17 | Sun Microsystems, Inc. | System and method for memory management using contiguous fixed-size blocks |
| US6594749B1 (en) * | 2000-05-19 | 2003-07-15 | Sun Microsystems, Inc. | System and method for memory management using fixed-size blocks |
| US9619742B2 (en) * | 2001-05-18 | 2017-04-11 | Nxp B.V. | Self-descriptive data tag |
| US8332502B1 (en) | 2001-08-15 | 2012-12-11 | Metavante Corporation | Business to business network management event detection and response system and method |
| US6886018B1 (en) | 2001-10-05 | 2005-04-26 | Metavante Corporation | Data processing technique for formatting data files that are subjected to a high volume of changes |
| US7243108B1 (en) * | 2001-10-14 | 2007-07-10 | Frank Jas | Database component packet manager |
| US6813632B2 (en) * | 2002-04-24 | 2004-11-02 | International Business Machines Corporation | Distributed file system using scatter-gather |
| US6831575B2 (en) * | 2002-11-04 | 2004-12-14 | The Regents Of The University Of California | Word aligned bitmap compression method, data structure, and apparatus |
| DE102004038210A1 (en) * | 2004-08-05 | 2006-03-16 | Robert Bosch Gmbh | Method for storing messages in a message memory and message memory |
| US8407239B2 (en) | 2004-08-13 | 2013-03-26 | Google Inc. | Multi-stage query processing system and method for use with tokenspace repository |
| US7068192B1 (en) * | 2004-08-13 | 2006-06-27 | Google Inc. | System and method for encoding and decoding variable-length data |
| US7917480B2 (en) | 2004-08-13 | 2011-03-29 | Google Inc. | Document compression system and method for use with tokenspace repository |
| US7313648B2 (en) * | 2004-09-30 | 2007-12-25 | Rockwell Automation Technologies, Inc. | Corruption tolerant method and system for deploying and modifying data in flash memory |
| US7210033B1 (en) * | 2004-10-15 | 2007-04-24 | American Megatrends, Inc. | Method, system, and computer-readable medium for enabling multi-segmented recovery of basic input output system program code in a computer system |
| AU2005304792B2 (en) | 2004-11-05 | 2010-07-08 | Drobo, Inc. | Storage system condition indicator and method |
| US7873782B2 (en) | 2004-11-05 | 2011-01-18 | Data Robotics, Inc. | Filesystem-aware block storage system, apparatus, and method |
| US7404061B2 (en) * | 2005-02-14 | 2008-07-22 | Jordan David A | Permanent pool memory management method and system |
| FR2883391B1 (en) * | 2005-03-18 | 2007-06-01 | Mediscs Sarl | METHOD FOR DYNAMIC MANAGEMENT OF A DATABASE AND ITS IMPLEMENTING SYSTEM |
| US7822891B2 (en) * | 2006-06-13 | 2010-10-26 | Broadcom Corporation | System and method for transferring a multidimensional array of data to a non-contiguous buffer |
| EP2211271A3 (en) * | 2006-07-31 | 2011-04-27 | Kabushiki Kaisha Toshiba | Nonvolatile memory system, and data read/write method for nonvolatile memory system |
| US8484220B2 (en) * | 2007-03-06 | 2013-07-09 | Mcafee, Inc. | Clustered index with differentiated subfields |
| US7962727B2 (en) * | 2008-12-05 | 2011-06-14 | Globalfoundries Inc. | Method and apparatus for decompression of block compressed data |
| US8171178B2 (en) | 2008-12-15 | 2012-05-01 | Lsi Corporation | Scaling of small computer system interface input output (SCSI I/O) referrals |
| US8205062B2 (en) | 2009-10-14 | 2012-06-19 | Inetco Systems Limited | Tiered data management method and system for high performance data monitoring |
| US9378560B2 (en) | 2011-06-17 | 2016-06-28 | Advanced Micro Devices, Inc. | Real time on-chip texture decompression using shader processors |
| EP2662782A1 (en) * | 2012-05-10 | 2013-11-13 | Siemens Aktiengesellschaft | Method and system for storing data in a database |
| US9342547B2 (en) * | 2012-10-31 | 2016-05-17 | International Business Machines Corporation | Management of memory usage using usage analytics |
| US9298521B1 (en) | 2013-04-29 | 2016-03-29 | Seagate Technology Llc | Command sets and functions |
| US10802853B2 (en) | 2016-10-14 | 2020-10-13 | Seagate Technology Llc | Active drive |
| WO2018081582A1 (en) * | 2016-10-28 | 2018-05-03 | Atavium, Inc. | Systems and methods for random to sequential storage mapping |
| US11151102B2 (en) | 2016-10-28 | 2021-10-19 | Atavium, Inc. | Systems and methods for data management using zero-touch tagging |
| US10304155B2 (en) | 2017-02-24 | 2019-05-28 | Advanced Micro Devices, Inc. | Delta color compression application to video |
| US11153578B2 (en) | 2018-04-27 | 2021-10-19 | Ati Technologies Ulc | Gradient texturing compression codec |
| CN111381771B (en) * | 2018-12-29 | 2023-06-27 | 深圳市海思半导体有限公司 | Method for storing data, storage controller and chip |
Family Cites Families (15)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US3596257A (en) * | 1969-09-17 | 1971-07-27 | Burroughs Corp | Method and apparatus for allocating small memory spaces to a computer program |
| US3829837A (en) * | 1971-06-24 | 1974-08-13 | Honeywell Inf Systems | Controller for rotational storage device having linked information organization |
| US3997876A (en) * | 1972-06-07 | 1976-12-14 | International Business Machines Corporation | Apparatus and method for avoiding defects in the recording medium within a peripheral storage system |
| EP0043391A1 (en) * | 1980-06-30 | 1982-01-13 | International Business Machines Corporation | Virtual memory terminal |
| US4536837A (en) * | 1982-05-25 | 1985-08-20 | Elxsi | Improved disk file allocation and mapping system utilizing cylinder control blocks and file map having unbalanced tree structure |
| JPS59146355A (en) * | 1983-02-09 | 1984-08-22 | Hitachi Ltd | Reorganizing method of data set in direct access storage device |
| US4685057A (en) * | 1983-06-06 | 1987-08-04 | Data General Corporation | Memory mapping system |
| US4603380A (en) * | 1983-07-01 | 1986-07-29 | International Business Machines Corporation | DASD cache block staging |
| US4638424A (en) * | 1984-01-12 | 1987-01-20 | International Business Machines Corporation | Managing data storage devices connected to a digital computer |
| EP0164578B1 (en) * | 1984-05-16 | 1992-04-29 | Siemens Aktiengesellschaft | Storage method for grouped communications switching data |
| US4758944A (en) * | 1984-08-24 | 1988-07-19 | Texas Instruments Incorporated | Method for managing virtual memory to separate active and stable memory blocks |
| US4949240A (en) * | 1987-03-13 | 1990-08-14 | Kabushiki Kaisha Toshiba | Data storage system having circuitry for dividing received data into sequential wards each stored in storage region identified by chain data |
| US5021946A (en) * | 1988-06-17 | 1991-06-04 | Modular Computer Systems, Inc. | Mostly contiguous file allocation technique involving file extension |
| US5089952A (en) * | 1988-10-07 | 1992-02-18 | International Business Machines Corporation | Method for allowing weak searchers to access pointer-connected data structures without locking |
| JPH03266039A (en) * | 1990-03-16 | 1991-11-27 | Fujitsu Ltd | Free format data link processing system |
-
1990
- 1990-03-16 JP JP2066152A patent/JPH03266039A/en active Pending
-
1991
- 1991-03-11 CA CA002037995A patent/CA2037995A1/en not_active Abandoned
- 1991-03-15 EP EP19910104010 patent/EP0446940A3/en not_active Withdrawn
-
1994
- 1994-02-14 US US08/198,396 patent/US5548751A/en not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| US5548751A (en) | 1996-08-20 |
| EP0446940A3 (en) | 1992-05-06 |
| EP0446940A2 (en) | 1991-09-18 |
| JPH03266039A (en) | 1991-11-27 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CA2037995A1 (en) | Dynamic data storage system | |
| EP0662228B1 (en) | Apparatus for data storage and retrieval | |
| US6411957B1 (en) | System and method of organizing nodes within a tree structure | |
| US9342528B2 (en) | Method and apparatus for tiered storage | |
| Bercken et al. | An evaluation of generic bulk loading techniques | |
| US5717919A (en) | Database system with methods for appending data records by partitioning an object into multiple page chains | |
| US7647355B2 (en) | Method and apparatus for increasing efficiency of data storage in a file system | |
| US5261088A (en) | Managing locality in space reuse in a shadow written B-tree via interior node free space list | |
| AU2002249161B2 (en) | Data structure for information systems | |
| US20050015674A1 (en) | Method, apparatus, and program for converting, administering, and maintaining access control lists between differing filesystem types | |
| EP0990995A3 (en) | Scheme for accessing data management directory | |
| JPH0554076A (en) | Data search and data holding method in memory | |
| JP2002501256A (en) | Database device | |
| JPH11272691A (en) | Index management device, index updating method and managing method, computer-readable recording medium with index updating program, and with index managing program | |
| WO1999001817A1 (en) | Defragmentation of stored data without pointer indirection | |
| US7895164B1 (en) | Efficient checkpoint process | |
| JP2007522559A (en) | System and method for large object infrastructure in a database system | |
| US5418965A (en) | Subroutine-type computer program for enhancing the speed of data processing in data management programs systems | |
| March et al. | Frame memory: A storage architecture to support rapid design and implementation of efficient databases | |
| US7606815B1 (en) | Non-recursive processing of hierarchical data | |
| US7133877B2 (en) | Method and apparatus for managing a set of data structures associated with a large file | |
| JPH03116248A (en) | Data maintenance system for data base | |
| JP2000148548A (en) | Unnecessary record deleting device | |
| KR100256678B1 (en) | Method of management directory for the partitioned signature file | |
| Van Weert et al. | Containers |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| EEER | Examination request | ||
| FZDE | Discontinued |