In order for this site to work correctly, and for us to improve the site, we need to store a small file (called a cookie) on your computer.
By continuing to use this website, you agree to our cookies and privacy policy.
Home page Home page Home page Home page
Pixel Header R1 C1 Pixel
Pixel Header R2 C1 Pixel
Pixel Header R3 C1 Pixel


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,,Old.record,New.record)


         File          name of the file the index is on    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.


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)

0002      FILE = "DICT USERS"
0003      ITEM = "SURNAME"
0006             REC<6> = 1
0007             WRITE REC ON DICT,"SURNAME"
0009                MAKE.INDEX(FILE,ITEM,REC,NEW.REC)
0010             END
0011         END
0012      END


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 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)

0003           GOSUB CREATE.XREF
0004           MAKE.INDEX(FILE,ITEM,"",REC.XREF)
0005           REC<22> = ITEM : ".XREF"
0009           END
0010         END
0011      END
0012      RETURN
0014      CREATE.XREF:
0015      *
0016      * Generate XREF item here, call it REC.XREF - See listing for logic
0017      *
0020         * Error handling
0021      END
0022      RETURN


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)

0003              REC<23> = "NAMES*KEYS*AR"
0004              WRITE REC ON DICT,"SURNAME"
0006                 MAKE.INDEX (FILE,ITEM,REC,NEW.REC)
0007              END
0008           END
0009        END

(Volume 1, Issue 3, Pages 4,9)
Pixel Footer R1 C1 Pixel