Method and apparatus for providing an object-oriented file structuring system on a computer5568639Abstract The present invention provides an object-oriented file structuring system. The invention provides a method of defining DATA objects and CONTAINER objects and SYSTEM objects that facilitates navigation through a file structuring system. Notation and nomenclature are defined for building files composed of CONTAINERs and DATA and SYSTEM objects and for defining relationships between and among files, CONTAINERs and DATA. A FOCUS LIST tracks objects of interest and aids in NAVIGATION. CONTAINER objects contain other objects. DATA objects enclose DATA in either machine-dependent or machine-independent value representations. Developers work with logical files and can freely create and modify the logical relationships of file objects. A RECONSTITUTION algorithm periodically updates the physical file to correspond to the logical file. Claims We claim: Description BACKGROUND OF THE PRESENT INVENTION 1. FIELD OF THE INVENTION
______________________________________
absent DATA for all TYPEs
positive infinity
for numeric TYPEs
negative infinity
for numeric TYPEs except UINT
not a number for numeric TYPEs
null for STRING, BITSTREAM, FILE
______________________________________
The "absent DATA" case is especially useful where data is stored in a defined structure holding defined fields and where data is collected from an input stream. Many data storage implementations make no distinction between a numeric value of zero and an uninitiated numeric field, or between an empty string field and a string field that has not been initiated. This condition makes it difficult to identify incomplete or missing objects. The present invention, by contrast, can denote any typed object as ABSENT, thereby denoting that it was not initialized with a value when an object of that TYPE bearing a value was expected. ABSENT is indicated without limiting or overloading the representable DATA value range, and it preserves the DATA TYPE of the missing data. The "infinity" special cases represent instances in which a numeric type is needed, but no numeric value would properly represent "infinity." The "not a number" case (which mathematicians denote as NaN) exists when a numeric value is expected but the submitted value does not make sense: examples are infinity divided by infinity or zero divided by zero. The "null" special case represents an empty string. In a "C" or "C++" language binding, a zero CHAR could represent an empty string, and this is in fact allowable in the invention. Other languages, however, manage string definition differently (PASCAL, for example, prefaces a string with a length indicator). The "null" special case provides a common standard that allows consistent storage of strings, regardless of the computer language in use. NULL is indicated without limiting or overloading the representable DATA value range. H. System Objects SYSTEM objects provide the means by which the present invention stores the information that is essential to allow correct reconstruction of an MFILE in the event of unexpected interruption of a computer program which employs the invention. The SYSTEM object stores much the same information that is retained in a FOCUS ENTRY, described later. The FOCUS ENTRY resides in computer memory and is used as the information source for periodic reorganization of the MFILE so that the physical object structure of the MFILE embodies its logical object structure. In the event of program interruption, however, the FOCUS ENTRY is lost; in this case the SYSTEM objects in the TAIL are used to rebuild needed FOCUS ENTRIES so that the MFILE can be appropriately reconstructed. The SYSTEM object appears in the TAIL of an MFILE, where it precedes each object added to the MFILE. The SYSTEM object stands alone in the instance where it is used to indicate the removal of an object from the MFILE, and it stands in conjunction with one or more added objects where it is used to indicate the presence of an additive alteration to the MFILE. The SYSTEM object is eliminated by the process, known as RECONSTITUTION, which restructures the MFILE so that the physical structure embodies the logical structure. The SYSTEM object holds somewhat different information from that held in its matching FOCUS ENTRY, for two reasons: first, the FOCUS ENTRY serves additional purposes relating to object management by HANDLES; second, the FOCUS ENTRY stores an updatable logical position marker, whereas the logical position information held in the SYSTEM object on the TAIL of the file cannot be updated in any efficient way. This second difference requires further explanation. The SYSTEM object retains information about the physical position that should be occupied by the object which it accompanies. This information is also often out-of-date, but the shortfall in information is made up by the sequencing of the SYSTEM objects on the TAIL of the file and the placement of the physical object location information into the recreated FOCUS ENTRY, where it can be updated as further changes occur. The structure of the SYSTEM object is shown in FIG. 15A. The SYSTEM object consists of prefix 301 and suffix 302 bracketing a command 1502, virtual file position 1503, and reference object Magic String 1504. The command 1502 contains one of the choices listed in FIG. 15B. The Virtual File Position 1503 provides the necessary physical object location. The Reference Object Magic String 1504 provides the necessary logical object location. FIG. 15A shows the structure of a SYSTEM object. The Command field indicates the kind of file alteration. The available alterations are here set forth in conjunction with the numerical values and purposes assigned to them in the preferred embodiment: 1. Insert--place following object(s) before reference object. 2. Append--place following object(s) after reference object. 3. Replace--replace reference object with following object(s). 4. Remove--remove the reference object from the file. 5. BeginT--note the beginning of a transaction. 6. EndT--note the end of a transaction. 7. AppendPrefirst--place following object(s) first in container. 8. InsertPostlast--place following object(s) last in container. The `Virtual File Position` 1503 in FIG. 15A stores an unsigned long integer that indicates the physical file position at which the following object should begin if none of the preceding alterations in the TAIL of the file had taken place. This information is obtained from the FOCUS LIST when the alteration is COMMITTED, as described below in the section on the Object Control Scheme. The `Reference Object Magic String` 1504 in FIG. 15A is a variable-length numeric sequence formatted like a numeric Dewey Decimal number, which represents the logical position of the reference object in the file. The section above on Symbolic Notation uses a printable representation of this value to indicate the logical positions of objects in the diagrams shown. The actual encoding of the `Magic String` is explained below in the section on the Object Control Scheme. The `Magic String` for the Reference Object is obtained from the FOCUS ENTRY for the current FOCUS when a HANDLE COMMITs an alteration. The sequentially-appended SYSTEM objects preserve a copy of the MAGIC STRING of the reference object that was held in FOCUS by a HANDLE when the HANDLE made the change. Thus, if the SYSTEM objects are needed to reconstruct the FOCUS LIST that contains the FOCUS ENTRIES, each SYSTEM OBJECT can refer to an already-recreated FOCUS ENTRY that can be located by its unique MAGIC STRING in the FOCUS LIST, and the subsequent updating of the FOCUS ENTRY logical position by other file alterations can thereafter occur in memory. I. Brackets and Token The defining characteristics of objects in the invention are that they are self-descriptive with respect to object size and type and that this self-descriptive quality is present in PREFIX and SUFFIX BRACKETs that comprise the beginning and end of each object in a byte stream. This level of generality allows object types to be defined for objects which can enclose virtually any kind and size of information, including other objects, and it provides a robust foundation for assuring object integrity. An example of the format of an object is illustrated in FIG. 3A. An object is comprised of a PREFIX 301, BODY 302, and a SUFFIX 303. The PREFIX and SUFFIX are referred to individually as BRACKET and jointly as BRACKETS. The BRACKETS have closely similar structures and incorporate identical information. The information necessarily incorporated by a BRACKET falls into the following categories: (1) BRACKET size, (2) object length, and (3) object type. The invention also provides (4) a parity bit, which is useful in checking object integrity, (5) a flag that indicates whether Extended Information is present within the object, and (6) a flag that indicates whether the object is operational or is a test object. The invention comprehends the encoding within each bracket of either the actual object length or the offset to the opposing BRACKET. The opposing BRACKET can be located by various offsets, the most obvious ones being to the first or last bytes of that BRACKET, but the preferred offset to locate the opposing BRACKET is to the position of its KEYBYTE. The difference between the KEYBYTE offset and the length of the object is 1 byte, so that the adjustment is easily made to jump to the next adjacent object rather than to the opposing BRACKET. The description of the present invention expressed in this document is given in terms of encoding the full length of the object, which is the preferred embodiment. The PREFIX 301 and SUFFIX 303 contain the same information and identify the length of the object encapsulated by the BRACKETS. That is, identical absolute object length values are encoded in the PREFIX 301 and SUFFIX 303. This makes it possible to jump forward to immediately past the end of an object by reading the PREFIX, or to jump backward immediately before the beginning of an object by reading the SUFFIX. Each object ends with a SUFFIX KEYBYTE so that the SUFFIX KEYBYTE can be adjacent to the PREFIX KEYBYTE of any succeeding adjacent object. Similarly, each object begins with a PREFIX KEYBYTE so that the PREFIX KEYBYTE can be adjacent to the SUFFIX KEYBYTE of any preceding adjacent object. The rule that KEYBYTEs of physically adjacent objects are themselves adjacent is subject to exception in the cases of a CONTAINER object and the first and last contained objects. As shown in FIG. 4D, the PREFIX KEYBYTE of the first contained object 405 lies immediately after the PREFIX 404 of the CONTAINER 403, and the SUFFIX KEYBYTE of the last contained object 407 lies immediately before the SUFFIX 405 of the CONTAINER. In the preferred embodiment, each BRACKET of an object holds four categories of information: BRACKET size, object length, object type, and BRACKET parity. In other embodiments, different numbers and kinds of categories of information may be held by a Bracket. In addition, extended information falling into several categories mentioned above is present in the BRACKETS if so indicated in each BRACKET. The order of information differs between PREFIX and SUFFIX, but the substance of the information is identical. The preferred embodiment is given below. The first and last bytes of an object are the KEYBYTEs of the object's BRACKETS. Each KEYBYTE provides information that is essential to the self-description of the object. In an extreme case in which a DATA object is ABSENT, the first and last bytes are merged into a single-byte TOKEN. A BRACKET can vary in size from one byte to six bytes in the preferred embodiment. As a general principle, the larger BRACKET sizes are required in order to include sufficient bits to encode larger object lengths, as illustrated in the preferred embodiments shown for PREFIX and SUFFIX, below. Note that there is no inherent limit to the size of the PREFIX or SUFFIX. Each BRACKET contains TYPE information, which generally identifies an object as CONTAINER, DATA or SYSTEM, but also provides further detail for sub-categories of object TYPE. A TOKEN, which is a combined SUFFIX/PREFIX of one byte in length, is by definition a DATA object, so it contains only the 5 bits necessary to identify the TYPE subcategories of DATA. All other BRACKETs include a separate TYPE byte, so the smallest non-TOKEN BRACKET is two bytes in length. Each BRACKET indicates whether Extended Information is present. FIGS. 3A and 3B illustrate the placement of the optional Extended Information structure. The BODY 302 of an object is decomposed in FIG. 3B, wherein the optional Extended Information structure 304 is shown to precede the CONTENT 305. The Extended Information structure holds information that characterizes the object. Although the KEYBYTE is part of a BRACKET, its structure is described in advance of that of the overall BRACKET as an aid to understanding. The reason for this is that a BRACKET is not defined as having a fixed size and the KEYBYTE holds the essential BRACKET size information. FIGS. 3A and 4A illustrate the composition of a PREFIX 301, in which the KEYBYTE 401P is followed by the PREFIX REMAINDER 402P and then by the object BODY 302. FIGS. 3A and 4B illustrate the composition of a SUFFIX 303, in which the object BODY is succeeded by the SUFFIX REMAINDER 402S and then by the KEYBYTE 401S. The KEYBYTE describes the size of the BRACKET of which it is a part (the only part in the case of a TOKEN). From the length of the BRACKET it is possible to ascertain the size and the location of the rest of the BRACKET: for PREFIX BRACKETs the KEYBYTE is the first byte, and for SUFFIX BRACKETs the KEYBYTE is the last byte. Computer systems and platforms that use the file system of the present invention are capable of reading a single byte at one time. Jumps between adjacent objects within a CONTAINER thus become one-byte jumps forward from the SUFFIX key byte of one object to the PREFIX key byte of the next object, or one-byte jumps backward from the PREFIX key byte of an object to the SUFFIX key-byte of the preceding object. This illustrates why the internal byte-orderings of PREFIX and SUFFIX order are not identical, although the PREFIX and SUFFIX contents are identical. Each KEYBYTE also includes a parity bit, which is set to match the parity of the other bits in the BRACKET. The presence of this parity bit facilitates the detection of corruption in the BRACKET itself and in the entire object. In the preferred embodiment, the size encoding of a KEYBYTE is represented by a bitstream of `1` value bits, terminated by a `0` value bit. The bitstream could proceed from Most Significant Bit downward or from Least Significant Bit upward; in the preferred embodiment the latter method is used. The position in which a `0` bit value is first encountered (counting from 1 upwards) represents the number of bytes in the BRACKET, including the KEYBYTE. This scheme may be represented by `0` and `1` values for bits that are meaningful and `x` values for bits that are not considered. Thus, in a TOKEN the Least Significant Bit (which is in position 0) holds a `0` value in the sequence `xxxxxxx0`, indicating that the BRACKET is 1 byte in length. In a two-byte BRACKET the Least Significant Bit holds a `1` value and the next most significant bit holds a `0` value which terminates a two-bit sequence of `xxxxxx01`, where `x` represents bits that are not considered. Likewise, in a three-byte BRACKET the three-bit sequence is `xxxxx011`. Note that in this representation the bit positions are represented as 76543210, with 0 as the Least Significant Bit position. In concept, the KEYBYTE need not contain any information other than BRACKET size, because the balance of the BRACKET can be encoded to contain all other essential information, such as object length and object TYPE. In the preferred embodiment, however, it has proven convenient to employ for other purposes the bits that are unused for size encoding. The preferred embodiments of BRACKETS are set forth below for PREFIX and SUFFIX. Note that the TOKEN representation appears identically as the 1-byte size BRACKET for PREFIX and SUFFIX. For the purpose of representing bit-level encoding of BRACKETS, the following symbols are used: `P` is a parity bit `E` is an extended information presence bit `X` is a test object indicator bit `T` is an object type encoding bit `L` is a object length encoding bit `S` is a BRACKET size encoding bit Bit positions are represented in the order of 76543210, with position 0 being the Least Significant Bit. The KEYBYTE of a BRACKET has already been described. The structures of the remaining components are now described under the categories of prefix, suffix, token and extensions, which differ from one another. A detailed view of the PREFIX is illustrated in FIG. 4A. The PREFIX 301 consists of a KEYBYTE 401P followed by the PREFIX remainder 402P. The PREFIX KEYBYTE 401P identifies the length of the PREFIX 301 and correspondingly, the length of the PREFIX remainder 402P. A representation of PREFIX structures from one byte to six bytes in length is illustrated in Table 1 below:
TABLE 1
__________________________________________________________________________
Layout of a PREFIX (KEYBYTE is the leftmost byte):
__________________________________________________________________________
1-byte
PTTTTTXS
2-byte
PLLLLLSS TTTTTTXE
3-byte
PLLLLSSS LLLLLLLL TTTTTTXE
4-byte
PLLLSSSS LLLLLLLL LLLLLLLL TTTTTTXE
5-byte
PLLSSSSS LLLLLLLL LLLLLLLL LLLLLLLL TTTTTTXE
6-byte
PLSSSSSS LLLLLLLL LLLLLLLL LLLLLLLL LLLLLLLL TTTTTTXE
__________________________________________________________________________
As shown above, in a two byte PREFIX, the `L` bits in bit positions 6, 5, 4, 3, and 2 of the KEYBYTE indicate the length of the object (i.e. the offset to the next object). A two byte PREFIX is used to represent an object up to 31 bytes in length. A three byte PREFIX uses bit positions 6, 5, 4, and 3 of the KEYBYTE, and one length byte, to indicate object length. A three byte PREFIX is used to represent an object up to 4095 bytes in length. A four byte PREFIX has three length bits in the KEYBYTE and two length bytes, and is used to represent an object up to 524,287 bytes in length. A five byte PREFIX has two length bits in the KEYBYTE and three length bytes, and is used to represent an object up to 67,108,863 bytes in length. A six byte PREFIX has one length bit in the KEYBYTE and four length bytes, and is used to represent an object up to 8,589,934,589 bytes (approximately 8 gigabytes) in length. These BRACKETS are the preferred embodiment, but the invention comprehends the possibility of representing even larger objects with yet largest BRACKETS. A detailed view of the SUFFIX is illustrated in FIG. 4B. The SUFFIX 303 consists of a KEYBYTE 401S preceded by the SUFFIX remainder 402S. The SUFFIX KEYBYTE 401S identifies the length of the SUFFIX 303 and correspondingly, the length of the SUFFIX remainder 402S. A representation of SUFFIX structures from one byte to six bytes in length is illustrated in Table 1 below:
TABLE 2
__________________________________________________________________________
Layout of a SUFFIX (KEYBYTE is the rightmost byte):
__________________________________________________________________________
1-byte
PTTTTTXS
2-byte
TTTTTTXE PLLLLLSS
3-byte
TTTTTTXE LLLLLLLL PLLLLSSS
4-byte
TTTTTTXE LLLLLLLL LLLLLLLL PLLLSSSS
5-byte
TTTTTTXE LLLLLLLL LLLLLLLL LLLLLLLL PLLSSSSS
6-byte
TTTTTTXE LLLLLLLL LLLLLLLL LLLLLLLL LLLLLLLL PLSSSSSS
__________________________________________________________________________
The object lengths which can be encoded in a SUFFIX are the same as those for the PREFIX of the same size. A one byte combined PREFIX-SUFFIX is referred to as a TOKEN, which is used to represent a non-value DATA object of the given type. The preferred embodiment of a TOKEN is shown identically as the 1-byte versions of PREFIX and SUFFIX. The TOKEN is used to indicate the absence of an expected value of the indicated DATA type: by definition, a TOKEN is a DATA object. The TOKEN, like other BRACKETs, contains one bit denoted above as the `X` bit: this is used to indicate that the TOKEN is a test object, which may be specially handled by a program that employs the invention. Non-value instances other than `absent` are not denoted by a TOKEN, but rather by an object of the same TYPE with full BRACKETS, as described below in the section on object TYPEs. The two BRACKETs of each object hold identical TYPE information that characterizes the object. For a PREFIX or SUFFIX of two bytes or larger, there is a separate TYPE byte, which covers all object types. The TYPE byte is at the end of each PREFIX and at the beginning of each SUFFIX. The TYPE byte provides information about the object depending on the values of specific bits in the byte. The preferred embodiment of the TYPE byte is illustrated in detail in FIG. 2. A TOKEN, which is by definition a DATA object, contains the subset of 5 bits from a TYPE byte which is used to represent DATA object types. The TYPE system required by the invention requires that each BRACKET be able to represent a range of at least 10 unique object types, each of which is mentioned in this section (there are eight sub-types of DATA, plus CONTAINER and SYSTEM objects). In the preferred embodiment, these values are represented in 6 of the 8 bits of one byte in each BRACKET, and as a consequence that byte is referred to as the `TYPE BYTE`. An exception is made for the one-byte TOKEN, which is by definition a DATA type of object, so it need contain only the 8 subtypes that are defined for DATA objects. Note that the numerical type identifications that can be stored in the TYPE BYTE exceed the 10 TYPES defined for the present invention, so there is ample room for extension of the typing system within the preferred embodiment. The structure of BRACKETS and of the TOKEN are discussed below. Every object except a TOKEN can store further sub-typing in an optional Extended Information Structure that lies within the BRACKET of an object. All typing serves the same purposes: to associate objects with unique behaviors defined for the object contents by the invention, and to separate different data value representation schemes from one another. In the present invention, objects written to file as one type can only be recovered from the file as that type: for example, an integer written to file can be identified later as an integer and can only be read as an integer; a CONTAINER object written to file can only be managed as a CONTAINER and cannot be mistaken for an integer or any other DATA object. SYSTEM objects are not exposed to programmers through the API, but the same rule applies that the object is distinguished by TYPE and cannot be manipulated by functions appropriate to a different object TYPE. The reason for defining multiple sub-types is to allow the differentiation of object behaviors which facilitate data storage and manipulation. The behaviors described below for each particular TYPE are specific to that TYPE in the invention and must be enforced by any implementation of the invention. J. Extended Information The present invention provides for the optional inclusion of an Extended Information structure within any object. The preferred embodiment is shown in FIGS. 14A through 14G. Extended Structure Block A 1401 is present if the `E` bit in the BRACKET is set. The structure of Blocks A 1401, B 1402 and C 1403 are shown in FIGS. 14B, 14C, and 14D. In each Block, the Size component 1404, 1407 and 1410 is a byte that holds a flag in the high bit; if the high bit is 0, the size encoded in the lower 7 bits is the offset to the enclosed content 305; if the high bit is 1, the size encoded in the lower 7 bits is the offset to the next Block, which itself begins with a Size byte. For example, if Block B 1402 is present, the high bit of the Size byte 1407 is 0 if the lower 7 bits hold the offset to the object content and 1 if the lower 7 bits hold the offset to the next Block. FIGS. 3A and 3B show the relative placement of object CONTENT 305 immediately following the optional Extended Information structure 304, which together make up the object BODY 302. As shown in FIG. 14E, the Flags component 1405 of Block A is a byte in which the bits are used as follows:
______________________________________
bit number
significance if set to 1
______________________________________
7 1-byte Type Map is present
6 8-byte (64 bit) ID is present
5 2-byte Class Number is present
4 1-byte decryption method index is present
3 1-byte decompression method index is present
2 component of 3-bit checksum method index
1 component of 3-bit checksum method index
0 component of 3-bit checksum method index
______________________________________
As shown in FIG. 14F, the Flags component 1408 of Block B is a byte in which the bits are used as follows:
______________________________________
bit number significance if set to 1
______________________________________
7 1-byte Platform Type is present
6 2-byte modification time stamp is present
5 2-byte Access Id is present
4 1-byte access rights value is present
3 1-byte access grade value is present
2 Id Access flag: Access Id required
1 1 to 40 byte name string is present
0 1 to 80 byte comment string is present
______________________________________
As shown in FIG. 14G, the Flags component 1411 of Block C is a byte in which the bits are used as follows:
______________________________________
bit number significance if set to 1
______________________________________
7 2-byte Class Number is present
6 2-byte modification time stamp is present
5 2-byte access id is present
4 1-byte access rights value is present
3 1-byte access grade value is present
2 Id Access flag: Access Id required
1 1 to 40 byte name string is present
0 1 to 80 byte comment string is present
______________________________________
Block C is used when the object is encrypted. In that case, the information listed above for inclusion in BLOCK C is copied from the identical values in BLOCK A (Class Number) and BLOCK B (all other elements) and then deleted from the origin. The entirety of BLOCK C is then encrypted separately from the object CONTENT 305 but with the same password; thus, an authorized user can attempt to decrypt the object with the correct password, but the required access rights and HANDLE ID can be checked by decryption of BLOCK C and comparison of the values with the current HANDLE ID and rights before the object decryption will proceed. The present invention comprehends the possibility that the information shown structured as above in the preferred embodiment might also be represented by a structure based on larger size and flag components, such as 16 bits rather than 8 bits; in such as case there might be no need to "daisy chain" blocks, so all of the Extended Information might be kept in one block. The defining capability of the Extended Information structure is that the presence of every element other than the size and flag information is optional, so that no space is used unless the information element is present (which will be indicated by the appropriate flag bit). Furthermore, even the size and flag components are not present when no Extended Information element is present (in which case the BRACKETS will indicate that no Extended Information is present). Type. When the `Type` flag is set, the matching `Type` field contains an 8-bit number which identifies the value mapping system which applies to the contents of the object. This value is by definition type-specific. The mappings presently used in the preferred embodiment are as follows:
______________________________________
Affected TYPE
Bit Pattern
Meaning
______________________________________
CHAR and STRING
00000000 null
00000001 ASCII symbols: 7-bit
00000010 UNICODE-2 symbols: 16-bit
00000100 ASCII symbols: 8-bit
00001000 UNICODE-4 symbols: 32-bit
SIGNED INTEGER
00000000 positive infinity
00000001 Not a Number
11111111 negative infinity
UNSIGNED 00000000 positive infinity
INTEGER 00000001 Not a Number
______________________________________
In the case of CHAR and STRING objects, the HANDLE facility, provided by the invention for the manipulation of objects, exists at all times in a symbol-specific state, which can be modified at any time. This state determines the storage space allocated for each CHAR object (or CHAR in a STRING) and the acceptable value ranges which may be appropriately assigned for that symbol set. The Type map for CHAR/STRING is maintained as a HANDLE state, but the map is not placed into an Extended Information Structure when an object is created unless an appropriate API call is made through the HANDLE. The 16-bit and 32-bit UNICODE representations use symbol mappings for many languages (including alphabetic and ideogram systems) promulgated by the UNICODE CONSORTIUM and now being adopted as an ISO (International Standards Organization) standard. The invention allows assignment of these symbol sets to CHAR and STRING objects, as mentioned above, which permits the invention to manage text with mixed languages. Identifier. When the `Identifier` flag is set, the `Identifier` field contains a 64-bit number that is unique to the object. Each computer on which the invention is used is set up with a unique node identifier in a configuration file to assure universal uniqueness of the identifier, because the node identifier number provides part of the 64 bits of value. The invention maintains its own unique object sequence numbering that is applied to the other bits. This numbering system facilitates the association of objects with one another by programs which use the invention. Class Number Because the objects of the present invention may be used for persistent file storage in support of object-oriented programming under circumstances where the structure and behaviour of objects are defined beyond the scope of the invention, provision is made by the invention to allow programmers to assign numbers to objects as a means of identifying them as instances of classes. For example, a programmer might choose to assign the number `87` to a particular data structure that serves as a node in a linked list in computer memory. The data elements of that structure could be represented in the invention as DATA values of the sub-types chosen by the programmer, and the whole structure would consist of a CONTAINER object holding those contents; in this example, every instance of such a CONTAINER in an MFILE would have the value `87` in the `Type` element of the Extended Information structure of the CONTAINER. Encryption. When the `Encrypted` flag is set, the value present in the `Decryption Method` field is a number that indicates which encryption method was used. A user-definable configuration file is used by the invention to associate the user-assigned number with a decryption algorithm or program. Decryption Method `0` is reserved as unspecified, leaving to the programmer the responsibility for choosing the correct algorithm. The actual content of this element is implementation specific. Compression. When the `Compressed` flag is set, the value present in the `Compression Method` field is a number that indicates which compression method was used. A user-definable configuration file is used by the invention to associate the user-assigned number with a decompression algorithm or program. The actual content of this element is implementation specific. Checksum. Three bits are used for the `Checksum` flag, which allows it to serve directly as an information element. If the three bit element holds a non-zero value, there is a `Checksum Amount` element in the Extended Information structure that holds the checksum calculated on the object BODY 302, which is shown in FIG. 3A. The `Checksum Method` element contains a number that indicates which checksum method was used (which also implies the storage size for the calculated checksum), and the `Checksum Amount` field contains the calculated checksum. If the object content is intact, a re-calculation of the checksum at the time of a READ action will confirm the result that was stored in the `Checksum Amount` element. Referencing FIGS. 3A and 3B, the checksum is applied to the object BODY 302, which includes the optional Extended Information structure 304. The checksum is not applied to the object BRACKETS. In the case of a CONTAINER object, all parts of all contained objects are included in the checksum; in the case of a DATA object, only the enclosed data value or values are included. Platform. This information categorizes computer platforms, which consist of computer processors combined with operating systems and in some cases with compilers, so that the characteristics of the platform on which the object data value was created can be stored with the object. This permits implementation of the invention to make any platform-specific adjustments that may be necessary. The actual content of this element is implementation specific and not a part of this invention, but the inclusion and placement of storage for this category of information within the object is part of the invention. Date and Time. This item stores the most recent data modification date of an object (the creation date, at first). The actual content of this element is implementation specific and not a part of this invention, but the inclusion and placement of storage for this category of information within the object is part of the invention. Access Identifier. This item stores a programmer-supplied identifier which was used at creation of the object and which, if the `Id Access Flag` discussed below is set, must be submitted by any HANDLE in order to access the content of the object. The actual content of this element is implementation specific and not a part of this invention, but the inclusion and placement of storage for this category of information within the object is part of the invention. Access Rights. This item stores the rights which must be possessed by a HANDLE in order to access the content of the object. The actual content of this element is implementation specific and not a part of this invention, but the inclusion and placement of storage for this category of information within the object is part of the invention. Access Grade. This item stores the supervisory level which must be possessed by the HANDLE in order to access the content of the object. The actual content of this element is implementation specific and not a part of this invention, but the inclusion and placement of storage for this category of information within the object is part of the invention. Id Access Flag. In the event that an Access Identifier was used to create an object, the requirement that the same identifier must be present in any HANDLE accessing the object is subject to an ON/OFF toggle controlled by this flag. The actual content of this element is implementation specific and not a part of this invention, but the inclusion and placement of storage for this category of information within the object is part of the invention. Name. Any object may be assigned a null-terminated string name, using any binary single-byte values in the string (except that a null will terminate the string). In the preferred embodiment this string may be up to 32 characters in length. Symbol mapping for this element is controlled by the Type Map in the Extended Information structure. The actual content of this element is implementation specific and not a part of this invention, but the inclusion and placement of storage for this category of information within the object is part of the invention. Comment. Any object may be assigned a null-terminated string comment, using any binary single-byte values in the string (except that a null will terminate the string). In the preferred embodiment this string may be up to 80 characters in length. Symbol mapping for this element is controlled by the Type Map in the Extended Information structure. The actual content of this element is implementation specific and not a part of this invention, but the inclusion and placement of storage for this category of information within the object is part of the invention. K. Magic String The MAGIC STRING is a component of the invention that is employed to represent the logical position of an object within the MFILE. The MAGIC STRING is a null-terminated value of variable length which has a binary representation that may be envisioned as a Dewey Decimal number in which containment levels are separated by periods and cardinal positions within a contained level are represented by positive integer numbers. The MAGIC STRING is present in each FOCUS ENTRY on the FOCUS LIST which has a logical position in the MFILE (NOTE: a REMOVED object has no logical position in the file). The values of the MAGIC STRINGs are the basis for sorting the FOCUS LIST entries in logical order of object PREFIX positions. For example, the FOCUS ENTRIES for contained objects will be placed in the FOCUS LIST after the FOCUS ENTRY of their CONTAINER and before the FOCUS ENTRY for any object represented in the FOCUS LIST that is logically located after that CONTAINER at the same level as the container. The rules for sorting are discussed later in the FOCUS LIST topic. Object logical positions are encoded in the bytes of a MAGIC STRING as follows in the preferred embodiment: 1. beginning at the start of the byte sequence, cardinal object position at each level is encoded in a series of bytes in which the value is stored in the 7 low-order bits and the single high-order bit is used as a flag to indicate the end of the series (the end may be thought of as a `period` in a Dewey Decimal number); 2. the value bits of the bytes in the series are packed together, in the preferred embodiment, in a 32-bit variable, padded with `0` bits in the high order range; and 3. in the preferred embodiment, the 32-bit variable is interpreted as an unsigned long integer to obtain the cardinal position of the CONTAINER at any nesting level and to obtain the cardinal position of the object at the deepest nested object represented in the MAGIC STRING. Thus, for each level represented there is a byte with a high-order bit set to `1`, the last of which is succeeded by a null terminating byte. The encoding described in the preceding paragraph is illustrated in FIGS. 16A, 16B and 16C. FIG. 16A shows a MAGIC STRING that represents an object nested inside a CONTAINER, in which the MAGIC STRING has 3 components: a byte series for level 1, a byte series for level 2, and a null terminating byte. A byte series consists of 1 or more bytes. FIG. 16B illustrates a byte series consisting of 3 bytes, of which the value bits are represented by letters A, B and C, and the terminating flag bit is represented by the number `1`. FIG. 16C shows the result of packing the value bits together into a 32-bit variable, left-padded with `0` bits, which yields an integer number that gives the cardinal position of the object at the represented level. L. Handle and Focus The present invention includes a programming facility, known as a "HANDLE", which both allows and controls access to objects within an MFILE. The HANDLE ensures that access to an MFILE is performed in a manner consistent with the file structure which is dictated by the invention. Each file of the present invention is itself an "object" which can contain any number of objects within it. A HANDLE references one object at a time--that is, the file as a whole or some object within the file. The reference to an object by a HANDLE is called FOCUS. The FOCUS of the HANDLE is unaffected by the logical expansion of the file in areas closer to the beginning of the file, even though that expansion apparently alters the offset of the objects that are farther out in the file. A HANDLE is in one of four positional states at a given time. The most common state, which it assumes at inception, is to have FOCUS on an object (the initial object is the HEAD of the MFILE). The other three states pertain to positions within a CONTAINER object whenever no specific object is in FOCUS: the HANDLE may assume a `pre-first` or `post-last` position, or it may be placed in a `null` position. The `pre-first` position is used to append objects in reverse order into the FIRST position in a CONTAINER. The `post-last` position is used to insert objects in order into the LAST position in a CONTAINER. The `null` position results when the HANDLE moves into an empty CONTAINER or when the HANDLE removes the last object from a CONTAINER, thereby causing the CONTAINER to become empty. When an object is in FOCUS, its TYPE and size and Extended Information are accessible by QUERY action, and if the object is a DATA object then its stored data values are accessible by READ action. When a HANDLE changes FOCUS from one object to another, the process is called NAVIGATION. M. Navigation NAVIGATION is defined as the activity of moving the focus of a HANDLE from one object to another object or into a non-FOCUS positional state. Adjacent objects are reached by "next" and "prior" commands. Contained objects are reached by a "move in" command, and CONTAINER objects are reached by a "move out" command. (The exact names associated with the foregoing navigation moves are not essential to the invention). When a HANDLE NAVIGATEs into a CONTAINER, it must take one of two positions: if the CONTAINER contains any objects, the HANDLE will gain FOCUS on the first contained object; otherwise the HANDLE will obtain a `null` FOCUS. From any FOCUS, including from a `null` FOCUS, the HANDLE may NAVIGATE to the `pre-first` or `post-last` positions, which are discussed below. A HANDLE may not obtain a `null` FOCUS by any means other than by causing a REMOVE of the last contained object in a CONTAINER or by NAVIGATING into an empty CONTAINER. A HANDLE may move out of a CONTAINER from any FOCUS inside the CONTAINER and from any non-FOCUS position. The HANDLE may not perform alterations from a `null` FOCUS: this may be done only from an object FOCUS or from the `pre-first` or `post-last` positions, because every MFILE alteration must take place in reference to an object position. An object in FOCUS provides a point of reference for any additive alteration. The `pre-first` position provides a point of reference for APPEND actions only; and the `post-last` position provides a point of reference for INSERT actions only. Navigation of a HANDLE into and out of a CONTAINER object is managed by retaining in the HANDLE a stack of references to FOCUS LIST ENTRIES which represent the current hierarchy of nested CONTAINERs into which the HANDLE has navigated in order to obtain its current FOCUS. FIGS. 17A and 17B illustrate the stack of CONTAINER FOCUS ENTRY references maintained in two separate HANDLEs and the referenced FOCUS ENTRIES on the FOCUS LIST. N. Oueries Any object that is in FOCUS may be subjected to a QUERY for TYPE, object size, buffer size required for variable-length data values, such as BINARY TYPE, and any item that may be contained in its Extended Information structure. The storage size query is defined only for DATA objects, and it returns the size of memory variable that is required to receive the value READ from the DATA object. The object size QUERY returns the inclusive size of the object. The available QUERIES for Extended Information may be deduced from the listing of items contained in Extended Information; however, only the existence--not the value--of Checksum, Encryption, Compression, Access Rights and Access Grade will be revealed by implementations of the invention. O. Reads The value content of any DATA object can be READ when the object is in FOCUS. The invention requires that the READ action be accompanied by a variable supplied by the programmer to receive data of that DATA TYPE. If the wrong type of variable is supplied, an error will be returned. If the DATA value is of a TYPE that has a non-fixed length, the required storage length for a receiving memory variable is available through a QUERY action. The value content of a DATA object is accessed by reading the KEYBYTE of the PREFIX and jumping forward the length of the PREFIX (or by reading the KEYBYTE of the SUFFIX and jumping backwards the length of the SUFFIX). Accessing the first contained object consists of jumping forward from the KEYBYTE the length of the PREFIX of the CONTAINER, and accessing the last contained object consists of jumping backward from the KEYBYTE the length of the SUFFIX. As a practical matter, enclosed DATA is usually read `forward`, so access from a SUFFIX would usually include the extra step of jumping backward over the length of the DATA to its beginning. This means of access to an object is used in the invention automatically to build memory structures called FOCUS ENTRIES, which are later described. DATA objects are always given specific sub-TYPEs. In the preferred embodiment, the minimal DATA TYPEs are SIGNED INTEGER, UNSIGNED INTEGER, FLOAT, CHAR, STRING, BOOLEAN, BINARY, and ENUMERATION, each of which has been mentioned above. P. Alterations Whenever a file alteration occurs, the logical position of various file objects may be changed. The only logical object positions that matter are the ones represented on the FOCUS LIST, and for those the invention automatically updates the `Magic String` values in the FOCUS ENTRIES as needed, so the value is up-to-date at all times, even if multiple HANDLES are operating on separate threads of execution. When alterations are to be made to an object, the present invention permits the alteration to be made before the current FOCUS, after the current FOCUS, replacing the object at the current FOCUS, or removing the object in current FOCUS. An alteration made immediately before the FOCUS is referred to as an `insert`. An alteration made immediately after the FOCUS is referred to as an `append`. The FOCUS itself may be unchanged, or it can move automatically to the new object. In `remove` operations the object in FOCUS becomes unaccessible, so the FOCUS moves automatically to an adjacent object, in the preferred order of `next`, `prior`, and `null`. Every additive alteration (insert, replace, append) creates a new object. When an additive alteration action is invoked, the system (1) creates a receiving buffer; (2) marks the buffer to indicate the alteration type; (3) receives the DATA written into the buffer; and (4) removes or posts the buffer to a serialized UPDATES QUEUE, where the contents of the buffer appear as a SYSTEM object followed by the added object. In case of `remove` the invention posts to the UPDATES QUEUE only the information required to build a SYSTEM object. In the preferred embodiment the intended alteration must be declared through the HANDLE before any content is written to the receiving buffer, and the successful completion of the update must be accomplished by a COMMIT action. The COMMIT action causes the receiving buffer to be posted to the UPDATES QUEUE. An alteration pending in this sequence may also be ABANDONED, in which case the receiving buffer is erased and nothing is posted to the UPDATES QUEUE. An ABANDON or COMMIT action terminates the alteration. The process of alterations may be illustrated by creating an example file. Such an example is illustrated in FIGS. 5A-5C. Consider the situation of creating a file to store address information for the following: Acme Corporation, New York, N.Y. 10022 212-123-4546. Referring to FIG. 5A, a CONTAINER 501 is created. Referring now to FIG. 5B, a second CONTAINER 502 is created within CONTAINER 501. CONTAINER 502 includes four DATA objects 503, 504, 505, and 506. DATA object 503 stores the "name" value (e.g. Acme Corporation). DATA object 504 stores the "city" value (e.g. New York). DATA object 505 stores the "state" value (New York), DATA object 506 stores the "zip" information (10022). There is no need to restrict the size of the DATA objects to a predetermined size, nor is there a need for external indexing information to locate individual values, because the BRACKETS provide information needed to navigate easily through the file. Consider now the situation where a programmer desires to modify the logical file to provide a second name DATA object (e.g., a contact person) and a phone number as part of the file, and desires that the new information be located at the beginning of the file. Referring to FIG. 5C, a new CONTAINER 507 is created and added to the file in front of and at the same level as CONTAINER 502. The new CONTAINER 507 includes DATA objects 508 "name2", and 509 "phone". FIGS. 10A-10C illustrate the state of the physical file stored in memory during the creation and manipulation of the logical file of FIGS. 5A-5C. Referring first to FIG. 10A, there is stored in memory a CONTAINER 1001 that is a representation of the logical CONTAINER 501. Referring now to FIG. 10B, when a change is made to a logical file, a "SYSTEM object" 1020 is created that contains information about how the information added in FIG. 5B to the logical file is added, the logical relationship between the additional information and the existing information, when the change is made, etc. The SYSTEM object is written at the end of the existing file, (in this case, at the end of CONTAINER 1001) along with the additional file information, new CONTAINER 1002 and DATA objects 1003-1006. The SYSTEM object contains all the information necessary to place its associated DATA logically in the file. Referring now to FIG. 10C, another SYSTEM object 1021 is written for the second name and phone number DATA objects to be added to the file in a new CONTAINER. The second command object 1021 is appended at the physical end of the stored file even though logically, the information is added at the beginning of the file. Following the command object 1021 is the new CONTAINER 1007, and new DATA objects 1008 "name2" and 1009 "phone". Q. Updates Queue. The UPDATES QUEUE receives alterations to the MFILE and serializes their effect on the MFILE. The updating procedure is a follows: (1) the write object is obtained from the UPDATES QUEUE; (2) a SYSTEM object is written to the TAIL of the MFILE; (3) the alteration is implemented: a new object is added to the TAIL of the MFILE, the FOCUS is modified or a new FOCUS ENTRY is created; and necessary DATA length changes and logical position changes are made to FOCUS ENTRIES for all enclosing CONTAINERS that have their object lengths changed by the alteration. The use of a separate thread of execution for updates processing is an option, not a requirement, of the invention. When a HANDLE makes a change to a file, a description of that change is placed in an UPDATES QUEUE, which is a linked-list of buffers or pointers to buffers in memory. The UPDATES QUEUE is a FIFO list. The UPDATES QUEUE is used to serialize the updates to a file. This facilitates DATA integrity when multiple handles are attempting to make changes to a file. When changes are made to the file, changes are made from the UPDATES QUEUE in serial order and written onto the TAIL of the file. Some alterations are time intensive. Use of the UPDATES QUEUE allows a HANDLE to put the update into the queue and then proceed with other activity. R. Focus Entry The FOCUS ENTRY holds a unique logical position marker called a MAGIC STRING that is updated in memory whenever a file alteration occurs that changes the logical position of the object referred to by the FOCUS ENTRY. By contrast, a SYSTEM object, which holds the information needed to rebuild the FOCUS ENTRY in case of computer process interruption, is designed to be written to file, where access for the purpose of updating logical position information is most awkward. For this reason, the SYSTEM object contains the MAGIC STRING of the reference object which was current at the time the ALTERATION represented by the SYSTEM object was processed. The format of the FOCUS ENTRIES in the FOCUS LIST is illustrated in FIG. 13. The entry 1300 begins with a user count 1301 that tracks the number of HANDLEs focusing on the object or using the FOCUS ENTRY. The needed count 1302 indicates how many unprocessed alterations have the FOCUS as a reference and how many HANDLES have the object in FOCUS or have a contained object in FOCUS. Object information 1303 stores object variables, including the PREFIX KEYBYTE location, the object CONTENT location, the BRACKET size, and the object length. Only the location of the PREFIX KEYBYTE is required, but it is useful to maintain additional information in the FOCUS ENTRY to improve efficiency by reducing file access. Flags 1304 identify an object as pending removal or pending replacement. The MAGIC STRING 1305 stores information about the logical position of the PREFIX KEYBYTE of an object in the MFILE. The logical position of the PREFIX KEYBYTE is the basis of sorting of the FOCUS LIST. The logical ordering of the PREFIX KEYBYTEs is defined as the order of the locations at which the PREFIX KEYBYTEs of objects will appear in the HEAD of an MFILE after RECONSTITUTION, which is an order that by definition excludes duplication since only one KEYBYTE can appear at a physical location in a file. The comparison of MAGIC STRINGs of FOCUS ENTRIES yields this order. REMOVEd objects present a complication, because they will have no physical position in the RECONSTITUTED file. This complication is solved by marking the FOCUS ENTRY for a REMOVEd object and keeping that FOCUS ENTRY in the FOCUS LIST position that it held immediately before removal, relative to other FOCUS ENTRIES on the FOCUS LIST. An additive ALTERATION (INSERT, REPLACE and APPEND) yields a FOCUS ENTRY that is placed on the FOCUS LIST in position relative to the FOCUS ENTRY of the object which served as a reference for the ALTERATION. As a result, the FOCUS ENTRY for an APPENDed object always follows the FOCUS ENTRY for its reference object, and the FOCUS ENTRY for an INSERTed object always precedes the FOCUS ENTRY for its reference object. Initially, these FOCUS ENTRIES are adjacent; later ALTERATIONs may separate those FOCUS ENTRIES with new FOCUS ENTRIES, but the relative positions on the FOCUS LIST of the FOCUS ENTRY for the added object and the FOCUS ENTRY for the reference object are never switched. The result of these sorting rules is that the FOCUS LIST represents the logical ordering and prospective physical placement of all objects that must be copied to a new MFILE when RECONSTITUTION takes place. The FOCUS LIST also serves as the central reference point for logical NAVIGATION of the MFILE, which is accomplished by walking the FOCUS LIST (adding FOCUS ENTRIES along the way for unrepresented MFILE objects that are encountered). S. Focus List Information about the logical position of old and new objects in a file must be available in order for HANDLES to navigate on the file and in order to reconstruct the file in logical order. This information is stored in a combination of memory structures called "FOCUS ENTRIES", logical position values known as "MAGIC STRINGS", and a compilation of the focus entries called a "FOCUS LIST". Information needed to re-create these memory structures after an unexpected computer shutdown is kept in SYSTEM objects which are written to the TAIL of a file as part of the updating procedure. The fact that an object exists in an MFILE does not itself create a need for that object to be represented by a FOCUS ENTRY on the FOCUS LIST. A FOCUS ENTRY needs to exist for an object only when one or more of the following conditions is met: 1. The object is held in FOCUS by a HANDLE. 2. The object is a CONTAINER and some HANDLE has FOCUS on an object inside the CONTAINER. 3. The object has been REMOVED logically from the MFILE but it is still in the physical MFILE because RECONSTITUTION has not yet taken place. 4. The object was used as reference for an ALTERATION which has not yet been processed. When an object in FOCUS is nested within one or more levels of CONTAINER objects, the HANDLE keeps track of every focus entry which represents one of the enclosing CONTAINER objects, even though it might be the case that none of the CONTAINER objects is directly referenced by a HANDLE. The FOCUS ENTRY is retained in memory as part of the FOCUS LIST as long as there is a HANDLE which has focus on a contained object at a lower level. Thus, each HANDLE retains a stack of references that point at the FOCUS ENTRIES which represent containing objects. That reference provides information to prevent NAVIGATION beyond the boundaries of the retaining objects. Any object that has been added to the TAIL of the MFILE also has an entry in the FOCUS LIST until the file has been reconstituted or the object has been removed. Any object that has been removed from the HEAD of the file has an entry in the FOCUS LIST until it has been physically removed from the file by RECONSTITUTION. This makes it possible to track the logical positions of objects added to the file, without having to read the file and its associated SYSTEM objects, and it makes the RECONSTITUTION algorithm simpler. FOCUS LIST entries that are not needed to support the current FOCUS of a HANDLE are eliminated by the RECONSTITUTION procedure. Any object that has been added to the TAIL of the MFILE and then REMOVED prior to RECONSTITUTION need only have its FOCUS ENTRY removed from the FOCUS LIST: because it lacks a FOCUS ENTRY, it will not be copied to the HEAD of the MFILE during a subsequent RECONSTITUTION. A more detailed discussion of RECONSTITUTION is presented in a later section. FIG. 11 illustrates the FOCUS LIST of the present invention. A FOCUS LIST 1100 includes a number of entries 1101, 1102, 1103, etc. Each entry in the FOCUS LIST 1100 is referred to as a FOCUS ENTRY. Each FOCUS ENTRY represents an object in the file. Consider the file consisting of CONTAINER 1120 containing DATA objects 1121, 1122, and 1123. There is a HANDLE with FOCUS on object 1123; therefore, there is an entry 1101 in the FOCUS LIST for the CONTAINER 1120 of object 1123 and there is an entry 1102 in the FOCUS LIST for object 1123. The FOCUS LIST is a dynamic list and changes as HANDLES move their FOCUS around the file and make changes in the file. The FOCUS LIST is a data structure in computer memory. Each open file in the present invention has an associated FOCUS LIST. In the example shown, the "parent" of each DATA object 1121, 1122, and 1123, is the CONTAINER 1120. Therefore, for example, whenever a HANDLE has FOCUS on DATA object 1123, represented by FOCUS ENTRY 1102 as shown in FIG. 11, there is an entry in the FOCUS LIST for CONTAINER 1120. This is illustrated in FIG. 11 by FOCUS ENTRY 1102 for the PREFIX of object 1123, and entry 1101 for CONTAINER 1120. The FOCUS LIST is sorted in logical order from least to greatest as defined above in this section and in the previous section. The entry for the parent CONTAINER 1120 is thus higher than the entry for the contained object 1123 in the FOCUS LIST of FIG. 11. When a HANDLE is navigating, it uses the FOCUS LIST to move among objects in their logical order. For example, consider the case illustrated in FIG. 12 when HANDLE h1 is to ascend from FOCUS on the object 1123, represented by FOCUS ENTRY 1102, as shown in FIG. 11. HANDLE h1 first examines the FOCUS LIST to access the parent to determine if the ascension is within the boundaries of the file. In this case, the ascent from object 1123 to CONTAINER 1120, is within the boundaries of the file, so HANDLE h1 moves its reference to FOCUS ENTRY 1101, representing object 1120. If it is desired to continue to ascend, the HANDLE again examines the FOCUS LIST to determine if the ascent is within the file boundaries. In this case, continued ascent is in fact outside the boundaries of the file so the navigation move does not proceed. When NAVIGATING to a logical position, the HANDLE first scans the FOCUS LIST to determine if a FOCUS ENTRY already exists for the destination. If so, the HANDLE obtains a reference to that FOCUS ENTRY and the NAVIGATION is accomplished. This requires no file I/O for NAVIGATION purposes. If, however, the logical position is occupied by an object in the file which is not currently represented by a FOCUS ENTRY, then a FOCUS ENTRY is created from the object in the file so that the HANDLE can obtain a reference to it. The FOCUS ENTRIES track the number of HANDLES that are focusing on an object at one time, in order to prevent contention problems. When two or more HANDLES have FOCUS on an object, no ALTERATIONs to that object are permitted (but `append` and `insert` in reference to that object are allowed). The system of the present invention thus prevents simultaneous object ALTERATION by separate HANDLEs without requiring a specific object locking or range locking action. The FOCUS ENTRIES on the FOCUS LIST provide the mechanism for HANDLE NAVIGATION and object manipulation, but they largely depend for their information content upon the structure and information content of the MFILE objects which they reference. The integration of these object structures with the memory-based object control mechanism is an essential part of the present invention. The algorithms for NAVIGATION are described as follows:
______________________________________
DESCEND (allowed only into CONTAINER objects) -
If desired FOCUS is in FOCUS LIST
Return it
Else
Find object after current FOCUS PREFIX and before
current object SUFFIX, skipping removed objects
If there is no object contained within the current focus,
go to a `null` FOCUS
Return the FOCUS
ASCEND (to a higher-level CONTAINER object)
Dispose of current FOCUS if no longer needed
Return enclosing FOCUS (retained in HANDLE stack)
NEXT
If desired FOCUS is in FOCUS LIST
Return the new FOCUS
Else
Find the object after the current FOCUS SUFFIX and
within the enclosing CONTAINER, skipping
removed objects
If the object is not represented yet on the FOCUS
LIST, look into the physical file for the object
and build a FOCUS ENTRY for it
If the desired object does not exist, return an error
and retain the original FOCUS
If the old FOCUS is no longer needed, dispose of it
PRIOR
If desired FOCUS is in FOCUS LIST
Return the new FOCUS
Else
Find the object before the current FOCUS PREFIX and
within the enclosing CONTAINER, skipping
removed objects
If the object is not represented yet on the FOCUS
LIST, look into the physical file for the object and
build a FOCUS ENTRY for it
If the desired object does not exist, return an error
and retain the original FOCUS
If the old FOCUS is no longer needed, dispose of it
______________________________________
T. Reconstitution The RECONSTITUTION procedure realigns the physical file with the logical file. When changes are made to an MFILE, representation of the changes in the form of SYSTEM objects and associated new DATA and/or CONTAINER objects are added to the end of the file. All objects added to the end of the file constitute the TAIL of the MFILE. RECONSTITUTION is invoked when the last HANDLE opened on an MFILE is closed. It is also invoked when certain conditions are met: these are conditions chosen to optimize performance of implementations of the present invention. These conditions generally fall into the following categories: 1. The TAIL gets too long. 2. The TAIL has too many objects in it. 3. Too much time has passed since the last RECONSTITUTION. 4. The ratio of TAIL size to HEAD size becomes too great. 5. The FOCUS LIST occupies too much memory. 6. NAVIGATION using the FOCUS LIST takes too long. RECONSTITUTION uses information in the FOCUS LIST to identify changes in the MFILE and to copy the changes in logical order to a new reconstituted MFILE, thereby aligning the physical condition of the MFILE to its logical condition. Although change information is also found in the SYSTEM objects, SYSTEM objects are not read during normal operation of the invention. This is because changes represented in the SYSTEM objects are also found in the FOCUS LIST. The result of RECONSTITUTION is a new file HEAD object with no file TAIL, unless a separate thread was available for ongoing ALTERATIONS. The RECONSTITUTED MFILE is substituted for the old MFILE and the new file is given old file name. By the end of the RECONSTITUTION, each FOCUS ENTRY either has been updated to reflect the new physical object positions in the RECONSTITUTED file or it has been removed from the FOCUS LIST | ||||||