Computers: Universe: The Dictionary DictionaryComputers: Universe: The Dictionary DictionaryI have already mentioned that you can apply most commands to dictionary files as easily as to data files. LIST itself is no exception. Try this:
>LIST DICT CUSTOMER.INVOICES
DICT CUSTOMER.INVOICES 17:51:53 08-13-99 Page 1
Type &
Field......... Field. Field........ Conversion.. Column......... Output Depth &
Name.......... Number Definition... Code........ Heading........ Format Assoc..
@ID D 0 InvNum 6R S
CUSTOMER.NAME D 1 Customer Name 15T S
WIDE.CUSTOMER. D 1 Customer Name 50T S
NAME
PRODUCT D 2 Product 20T S
UNIT.PRICE D 3 MD20P Unit Price 10R S
QUANTITY D 4 Quantity 10R S
VALUE I UNIT.PRICE * MD20P Value 10R S
QUANTITY
7 records listed.
Here you can see, in a single enquiry, all the dictionary records you have defined. An interesting point, though, is that in order to format an enquiry like this, LIST requires a dictionary. After all, how does it know that the title of the first column is 'Field Name'? And indeed, how did it know which columns to display, given that you specified no field names after your LIST command?
The answer to both questions is that every dictionary has a dictionary. But does this mean that that dictionary in turn must have a dictionary, and so on in an infinite series of dictionaries? No. The thing is, while the format of each data file is unique, and so must have a unique dictionary, the dictionary files themselves are all structured exactly the same way: and you've learnt this structure in the last few sections. This means that they can all share the same dictionary. It is called DICT.DICT. Take a look:
>LIST DICT.DICT
DICT.DICT 18:00:34 08-13-99 Page 1
Type &
Field......... Field. Field........ Conversion.. Column......... Output Depth &
Name.......... Number Definition... Code........ Heading........ Format Assoc..
@ID D 0 Field 14L S
Name
FIELD D 0 Field 14L S
Name
ID D 0 15L S
ITEM.ID D 0 10T S
KEYR D 0 15R S
KEY D 0 15L S
CODE D 1 4L S
F1 D 1 35L S
EXP D 2 FIELD # or EXPR 30T S
ESSION
A2 D 2 3R S
DATA.FILE D 2 DATA.FILE.NAME 30T S
LOC. D 2 LOC. 3T S
LOC.L D 2 LOCATION 40T S
LOC D 2 LOCATION 15T S
Press any key to continue...
This listing goes on for a number of pages, and is not as friendly as it might be, largely because UniVerse themselves do not follow the rule I recommended whereby each field is given a single D type entry to define it. Don't ask me why: I've told them often enough, but they've stopped answering my mail.
But doesn't DICT.DICT also require a dictionary? Well, because it is a dictionary, it follows the same structure that any dictionary follows. And the dictionary of a dictionary is... DICT.DICT. In other words, DICT.DICT is its own dictionary. You can prove this curious fact to yourself by sneaking a look at its VOC record:
>ED VOC DICT.DICT
3 lines long.
----: P
0001: F
0002: /work/universe/DICT.DICT
0003: /work/universe/DICT.DICT
Bottom at line 3.
----: Q
>
And there it is: field 2 (which points to the data file) and field 3 (which points to the dictionary file) both point to the same file (see File Pointers for information about file pointers). This neat device precludes the need for an infinite series of dictionaries.
To find out how LIST decides which fields to show when you enter a LIST DICT filename command without specifying field names (as you did above), check out the @ record in DICT.DICT (for information about how the @ phrase determines the default enquiry, see Phrases):
>ED DICT CUSTOMER.INVOICES @
The file "DICT.DICT" is read-only and cannot be updated.
3 lines long.
----: P
0001: PH
0002: BY FIELD.NO BY TYPE ID.SUP FIELD FIELD.TYPE FIELD.DEF FIELD.CONV FIELD.HE
AD FIELD.FMT FIELD.ASSOC_
0003: HEADING "'F' 'T' Page 'PL'"
Bottom at line 3.
----: Q
>
Several things to notice here.
1. The field names, and the BY clauses, determine what you see when you type LIST DICT filename....
2. A trick I haven't mentioned before: the use of a _ character at the end of line 2 to allow the phrase to continue on line 3: which you can use in any phrase which gets rather long.
3. The HEADING clause, which puts a custom written heading at the top of your enquiry. I'll explain this, along with other clever things the query language can do, in the section on RetrieVe.
4. The ...read-only... message: as you can see from the paths on fields 2 and 3, DICT.DICT points to the central UniVerse directory. If you changed it, you'd change the way every dictionary is displayed, not just in this account, but in every account on your system. UniVerse only gives toys like this to the Unix system administrator root. If you don't fully understand what DICT.DICT does, you shouldn't edit it. If you do, you wont anyway.