Computers: Universe: File PointersComputers: Universe: File PointersEarlier in this course (see Universe and UNIX) we explored the relationship between what unix calls 'files' and what universe calls 'files'. to briefly recap: the terms are related, but not synonymous. depending on the type of the universe file (see Universe Files), what UniVerse calls a file may be implemented using any of a number of different combinations of UNIX directories and files.
Each file has a file pointer in the VOC of its parent environment: created by the CREATE.FILE command along with the UNIX portions of the file itself. The name of the VOC record defines the name of the file as it is known to UniVerse. The contents of the record tells UniVerse where to find the file within the UNIX filing structure.
To examine these file pointers, and the things they point to, we shall create three files: one directory file, one static file, and one dynamic file. Begin by creating the directory file with the command:
>CREATE.FILE DIRECTORY.FILE 19
WARNING: An operating system file will be created with a truncated name.
Creating file "DIRECTORY000" as Type 19.
Creating file "D_DIRECTORY000" as Type 3, Modulo 1, Separation 2.
Added "@ID", the default record for RetrieVe, to "D_DIRECTORY000".
This rather unfriendly and misleading series of messages is trying to tell us a number of things:
1. A UNIX directory called DIRECTORY000 has been created as the physical form of the UniVerse DIRECTORY.FILE file.
2. A UNIX file called D_DIRECTORY000 has been created as the physical form of the UniVerse DIRECTORY.FILE file. The purpose of dictionaries is covered later in the course. For now, it is worth noting simply that a file dictionary is, itself, an independent file, and that every 'data' file has a companion 'dictionary' file which describes its contents to utilities such as the RetrieVe query language. Whatever type you select for your file, UniVerse creates your dictionary files as type 3 (ie. static), modulo 1, separation 2.
A record with the key @ID has been added to this dictionary.
The UNIX file names chosen are interesting. CREATE.FILE creates two files, a main or 'data' file with the name 'X', and a 'dictionary' file with the name 'D_X'. UniVerse attempts to keep the names of the UNIX files it creates to 14 characters or less, and so applies the following naming scheme:
1. If the requested UniVerse file name is 12 characters or less in length, like TWELVE.CHARS, the name of the directory file created is the same, ie. TWELVE.CHARS, and the name of the UniVerse dictionary file is preceded by a D_ thus: D_TWELVE.CHARS.
2. If the requested UniVerse file name is more than twelve.characters in length, like OVER.TWELVE.CHARS, the name of the directory file created consists of the first nine characters of this name followed by a three digit suffix, in this case OVER.TWEL000. The dictionary file is prefixed in the usual way, giving D_OVER.TWEL000. The three digits are chosen so as to ensure the UNIX file name is unique. If UNIX file OVER.TWEL000 already exists, the file is called OVER.TWEL001, and so on.
Returning to the file DIRECTORY.FILE we created earlier, its file pointer looks like this:
ED VOC DIRECTORY.FILE
3 lines long.
----: P
0001: F
0002: DIRECTORY000
0003: D_DIRECTORY000
----:
As do all VOC records, file points store their type and an optional description in field 1.
Field 2 contains the name of the UNIX directory used to physically implement the main DIRECTORY.FILE file.
Field 3 contains the name of the UNIX file used to physically implement DIRECTORY.FILE's dictionary.
To create our example static file, enter the command:
>CREATE.FILE STATIC.FILE 2 1 4
Creating file "STATIC.FILE" as Type 2, Modulo 1, Separation 4.
Creating file "D_STATIC.FILE" as Type 3, Modulo 1, Separation 2.
Added "@ID", the default record for RetrieVe, to "D_STATIC.FILE".
The message which follows is very similar to the one we saw when creating DIRECTORY.FILE above. In this case, the UniVerse file name is less than 13 characters long, and so the corresponding UNIX file names are not abbreviated: but exactly the same naming conventions apply to the creation of static files as do to the creation of directory files.
In fact, the only difference here is that the 'data' file is implemented as a UNIX file (rather than a UNIX directory) because it is a UniVerse static file rather than a UniVerse directory file.
The file pointer to STATIC.FILE is much as you would expect.
ED VOC STATIC.FILE
3 lines long.
----: P
0001: F
0002: STATIC.FILE
0003: D_STATIC.FILE
----:
Finally, to create a dynamic file, enter the command:
>CREATE.FILE DYNAMIC.FILE DYNAMIC
Creating file "DYNAMIC.FILE" as Type 30.
Creating file "D_DYNAMIC.FILE" as Type 3, Modulo 1, Separation 2.
Added "@ID", the default record for RetrieVe, to "D_DYNAMIC.FILE".
As do directory and static files, dynamic files are created with static dictionaries, type 3, modulo 1, separation 2. Also, the same UNIX file naming conventions apply: as the UniVerse file name DYNAMIC.FILE is exactly 12 characters long, it is not truncated: but if it had been longer, it would have been.
The UNIX entity DYNAMIC.FILE is actually a directory. This is because the 'data' part of a dynamic file is implemented using exactly two UNIX files, alwats called DATA.30 and OVER.30, and these are stored in this directory: the former stores the 'ordinary' data, and the latter any data which has overflowed its groups. The names of these files therefore do not appear in the file's pointer, as they never vary: only the name of the directory containing them varies, and this appears in the pointer, which looks like this:
ED VOC DYNAMIC.FILE
3 lines long.
----: P
0001: F
0002: DYNAMIC.FILE
0003: D_DYNAMIC.FILE
----:
As all the files and directories named on fields 2 and 3 of file pointers are UNIX objects, UNIX can be used to move them from place to place. Furthermore, while we have only seen simple UNIX names in these file pointers, they are in fact relative paths which simply happen to point to the current directory: ie. the directory housing the current UniVerse account. It follows from this that it is possible to play lots of games with UniVerse file pointers and the UNIX objects they point to. For instance:
1. By editing a file pointer and saving it under a different name, you have now created a synonym by which the same file can be referred to: neither of which has any claim to being the 'real' name, and thus either of which might be used by different developers in their work, creating confusion and ambiguity.
2. By editing a file pointer, saving it under a different name, and deleting the original, you have effectively changed the name of the UniVerse file: and in the process broken any programs which refer to the file under the original name.
3. By moving the UNIX entities making up the file, and editing the file pointer to reflect the new paths on fields 2 and 3, you have effectively created a file with is nominally part of the account, but is not actually stored within the account directory. Therefore, if at some point someone backs up the directory (on the assumption that they are backing up the account), they will unknowingly omit this file and thus undermine the validity of the backup.
From my description of these activities, you will have gathered that I don't generally encourage them. There are few good reasons for imposing an artificial structure in place of UniVerse's own, and it is a common cause of error and corruption. The sole legitimate aim recorded above, that of creating synonyms, is better achieved using Q pointers: see the next topic Q Pointers.