You may sometimes come across dictionary records with types of A
or S
. They play roles similar to D
and I
type dictionary records, but are supported largely for compatability reasons: some forms of PICK (see About UniVerse above) used these instead of D
and I
. If you come across them, you'll find their layout described in the UniVerse documentation: but they are both less friendly and less efficient than the types I have already described, and have no extra functionality. My advice would be that if you find yourself having to change one, do so by replacing it with a D
or I
.
Like X
type records in the VOC
file, X
type dictionary records are not designed to be used as words in commands. They are there to store data. For instance, many files have records keyed by sequential numbers. In order to add a new record to such a file, you must find the lowest unused number you can use as a key. You could do so by enquiring on the file itself, but this would add enormous overhead. Instead, most programmers add a record to the dictionary of the file, called (by convention) &NEXT.AVAILABLE&
, which is a type X and carries the lowest unused number on its second field. This is locked, read, updated, and unlocked by every process which adds a record to the main file.
One or two X
types are harmless, but as with X
type records in your VOC file, bear in mind that each one increases the size of a file crucial to the performance of your system, as well as 'taking up' a word which might otherwise be available as part of your command language. It is therefore advisable to use them sparingly. If you find yourself setting up ten X
types on a dictionary, consider setting up a separate UniVerse file for the values, as it seems likely you will be dealing with a new form of 'entity' altogether, rather than merely a chance administrative detail of your main data file.