Computers: Universe: Q Pointers

In our discussion of file pointers (see File Pointers above), we discussed the danger of creating multiple file pointers simply in order to provide synonyms by which a file could be accessed. As the file pointer is the only thing which defines a file name under UniVerse, having more than one file pointer effectively gives the same file two names: and provides no clue to users that the two files are in fact the same, unless they take the trouble to edit the pointer records themselves.

To illustrate the risks, try the following:

>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".
>

The next stage in our illustration involves creating a 'synonym' file pointer to this file. In the last section, we did this by creating a new VOC record with the editor: and this is commonly the way it is done. UniVerse does, however, provide a command which achieves the same thing: so for the sake of learning this command, we shall use it instead:

>SETFILE

Enter DATA file pathname = DIRECTORY000

What do you want to call it in your VOC file = DIRECTORY.FILE.POINTER

Establishing file pointer:
Pathname "DIRECTORY000"
VOC Name "DIRECTORY.FILE.POINTER"
OK to establish pointer (Y/N) ? Y

Pointer "DIRECTORY.FILE.POINTER" established in VOC file.
>

This creates a VOC record in exactly the same way as you could with the editor, as you can check:

>ED VOC DIRECTORY.FILE.POINTER
3 lines long.

----: P
0001: F
0002: DIRECTORY000
0003: D_DIRECTORY000
Bottom at line 3.
----: Q
>

Now enter the command:

>DELETE.FILE DIRECTORY.FILE.POINTER
DELETEd "DIRECTORY000", Type 19.
DELETEd file "D_DIRECTORY000", Type 3, Modulo 1.
DELETEd file definition record "DIRECTORY.FILE.POINTER" in the VOC file.
>

You have been allowed to delete the file using the file pointer you only created as a synonym. While the VOC record DIRECTORY.FILE.POINTER has been deleted, DIRECTORY.FILE is still there, and now points to a non-existant path. You can demonstrate this to yourself by entering a command to count the number of records in DIRECTORY.FILE:

>COUNT DIRECTORY.FILE
Unable to open "DIRECTORY.FILE" file.
>

A good principle to maintain, therefore, is that you should only have one file pointer to each file: which uniquely defines the file's 'real' name.

There are legitimate reasons, though, why you might wish to create a synonym to a file name. You might, for instance, be working at a site where two or more languages are in common use: say English and Afrikaans in South Africa, or English and Spanish in the United States. Having created your files using names consistently selected from one language, you might wish to create synonyms for each filename in the second language.

But perhaps the most common reason to create file synonyms is to allow a file which was created within one UniVerse account to be accessed from another. It was explained earlier in the course (see The UniVerse Paradigm above) that UniVerse observed a strict and simple hierarchy: accounts contained files, files contained records, and so on. It was also explained that each account was an entirely independent entity, with it's own VOC file defining its own command environment. However, by using file synonyms, it is possible to access a file in one account from another.

Both of these aims can best be achieved using a Q pointer. For the sake of our examples, we will create another new file:

>CREATE.FILE CUSTOMER.FILE DYNAMIC
WARNING: An operating system file will be created with a truncated name.
Creating file "CUSTOMER.000" as Type 30.
Creating file "D_CUSTOMER.000" as Type 3, Modulo 1, Separation 2.
Added "@ID", the default record for RetrieVe, to "D_CUSTOMER.000". >

To create a synonym in a second language is extremely simple. The example here is in Afrikaans:

>ED VOC KLANT.FILE
New record.

----: I
0001= Q
0002= (Put in a space)
0003= CUSTOMERS.FILE
0004= (Press RETURN)
Bottom at line 3.
----: FI
"KLANT.FILE" filed in file "VOC".
>

The first line of this VOC record, like the first line of all VOC records, indicates the type of the record. Q pointers carry, unsurprisingly (and for no particular reason) a Q. The second line contains the name of the UniVerse account in which the file lives. If it is left blank (as here), then the file is assumed to be in the same account as the Q pointer itself. The third line contains the name of the file: note that this is the UniVerse name, not the UNIX name. You can now use the name KLANT.FILE to refer to the file CUSTOMER.FILE. Try it:

>COUNT KLANT.FILE

0 records counted.
>

You can set up a Q pointer to a file in another account just as easily, though any example of this would depend on the names of the accounts as installed on your system. Suffice to say that an account name entered on line 2 of the Q pointer will refer the pointer to that account when seeking the file on line 3.

Note that Q pointers contain no UNIX paths. The account name on line 2 is a UniVerse account name, and the file name on line 3 is a UniVerse file name. When you use the pointer, UniVerse consults it's internal list of account names to resolve the location of the account, and then looks in the VOC file of the account it finds to resolve the location of the file. This is a great strength. If a UniVerse account is moved, provided the UniVerse administrator updates the list of accounts within the UniVerse system administration menu, and external Q pointers pointing to a file in the moved account will continue to work: foreign file pointers, though, dependent on a particular UNIX path to access the file, will be broken. Equally, consider the situation if someone were to delete and then recreate the CUSTOMER.FILE file. The UNIX name of the file might well change (you'll remember that the three digits at the end of this name are essentially arbitary), but as long as the UniVerse file name is the same, any Q pointer will still work. A F type synonym, which relies on an absolute UNIX path, though, will break.

But the real pay-off is that UniVerse 'knows' that a Q pointer is just a synonym, and not the real file name. Try the command:

>DELETE.FILE KLANT.FILE
"KLANT.FILE" is already in your VOC file as a type "Q" record.
File name =(just press RETURN)
>

The word 'already' in the error message is ridiculously misleading: the reason the file cannot be deleted is not because the VOC pointer is 'already' there, but because it is a Q pointer. However, the point is that the file cannot be deleted. By and large, you can access your file via a Q pointer exactly as you could via an F, but certain important functions are reserved for the 'real' F pointer.

One final absurdity: in the same way that there is a SETFILE command to create F type pointers, there is a command to create Q pointers: it is called SET.FILE. That's right, the only difference between the two is the dot between SET and FILE. The reasons are historical: the SETFILE command came first, and preceded the invention of Q pointers. When Q pointers came along, it was realised that these provided a better way of creating synonyms, but to change the SETFILE command to create Q pointers might break existing applications. Therefore, a new command was commissioned, called SET.FILE. Go figure. I tend to avoid them both, as it's just as easy (and less prone to error) to set up such pointers by hand. For the sake of completeness, though, here is an example of SET.FILE being used to set up another Q pointer to the CUSTOMER.FILE:

SET.FILE
Q name: CLIENT.FILE
Account: (press RETURN)
File: CUSTOMER.FILE
Q-pointer written to VOC file.
>

Today's main message is, though: leave your default F type pointers as they are on file creation, and use only Q pointers to refer provide synonyms and access from other Universe accounts.