====== Make.Index ======
^Published By^Date^Version^Knowledge Level^Keywords^
|Sprezzatura Ltd|01 JUL 1989|1.15+|EXPERT|MAKE.INDEX, FILECOPY, BTREE, XREF, RELATIONAL, INDEX, CAPTURE|
When moving files around the system, I'm sure that you could not help but
notice that a FILECOPY removes all indexes on the destination file. There is
some logic in this, but it can make life really difficult when trying to
install new versions of software - how can we reinstall the missing indexes?
I know that when I first had this problem I just developed CAPTURE scripts
to call up the main menu, go to Files, Indexing, Update etc. etc. This was a
mess. More often than not, a "Stickum" on the menu would get in the way and
my system would sit there flashing at me as the wrong characters got fed
into the wrong screen. I thought that there had to be a better way and
started playing around. What I thought must be an easy process turned out to
be more complex, but it all revolves around a system subroutine called
MAKE.INDEX. (A routine that puts all the extra necessary pointers and
records onto the system to tell it that it has an index on a field (or to
remove it)).
The calling syntax is for MAKE.INDEX is
CALL MAKE.INDEX(File,Field.name,Old.record,New.record)
where
* File: name of the file the index is on
* Field.name: dict item in the file
* Old.record: compiled dict item before the index was added
* New.record: compiled dict item after the index was added
As you will be aware from the documentation on the utility diskette,
indexing information is stored in various fields on the indexed dictionary
item. When the dictionary item is filed away, DICT.MFS recompiles it and
adds the new object code back into the item before writing it away.
==== BTREE INDEXES ====
A BTREE index is one of the most easy to set up. A dictionary item with a
BTREE index is distinguished by the presence of a 1 in field 6. Thus to add
a BTREE index to a field we would read in the dictionary item for the field,
add a 1 into field 6, write the item out again to recompile it, then read it
in to a new variable and call MAKE.INDEX. E.g. (assuming no errors
encountered)
DECLARE SUBROUTINE MAKE.INDEX
FILE = "DICT USERS"
ITEM = "SURNAME"
OPEN FILE TO DICT THEN
READ REC FROM DICT,"SURNAME" THEN
REC<6> = 1
WRITE REC ON DICT,"SURNAME"
READ NEW.REC FROM DICT,"SURNAME" THEN
MAKE.INDEX(FILE,ITEM,REC,NEW.REC)
END
END
END
==== XREF INDEXES ====
This is, of necessity, the most complicated index to set up. When you set up
an XREF index, a new symbolic field is added into the dictionary which is
used to do the XREFing. This field has the name field.name.XREF and contains
a call to the system routine XREF with the necessary stop list and delimiter
information. Thus to add an XREF index to a field we must first create this
extra dictionary item AS WELL AS altering the original dictionary item to
tell it that an XREF index exists, by adding the name of the symbolic xref
item into field 22 of the original dictionary item. Thus (assuming setup as
above)
OPEN FILE TO DICT THEN
READ REC FROM DICT,"SURNAME" THEN
GOSUB CREATE.XREF
MAKE.INDEX(FILE,ITEM,"",REC.XREF)
REC<22> = ITEM : ".XREF"
WRITE REC ON DICT, "SURNAME" THEN
READ NEW.REC FROM DICT,"SURNAME" THEN
MAKE.INDEX(FILE,ITEM,REC,NEW.REC)
END
END
END
RETURN
CREATE.XREF:
*
* Generate XREF item here, call it REC.XREF - See listing for logic
*
WRITE REC.XREF ON DICT,ITEM : ".XREF"
READ REC.XREF FROM DICT, ITEM : ".XREF" ELSE
* Error handling
END
RETURN
==== RELATIONAL INDEXES ====
This is nearly as simple as BTREEs, it merely requires that the dict item be
told what it is related to by putting file*field*sort.order into field 23.
Thus using the above example to relate the surname field to NAMES file in
the KEYS field in ascending numerical order, (assuming setup as above)
OPEN FILE TO DICT THEN
READ REC FROM DICT,"SURNAME" THEN
REC<23> = "NAMES*KEYS*AR"
WRITE REC ON DICT,"SURNAME"
READ NEW.REC FROM DICT,"SURNAME" THEN
MAKE.INDEX (FILE,ITEM,REC,NEW.REC)
END
END
END
(Volume 1, Issue 3, Pages 4,9)