This digital version is made because current version available in ditial form doesn't contain details about CDS/ISIS file format and was essential in making Biblio::Isis module.

This extract of manual has been produced in compliance with section (d) of WinIsis LICENCE for receiving institution/person which say:

 The receiving institution/person may:

 (d) Print/reproduce the CDS/ISIS manuals or portions thereof,
     provided that such copies reproduce the copyright notice;

CDS/ISIS Files

  nnnnnn.eee

where:

Files marked with "*" are ASCII files which you may display or print. The other files are binary files.

A. System files

Depending on the release and/or target computer, there may also be one or more overlay files. These, if present, have the extension "OVL". Check the contents of your system diskettes or tape to see whether overlay files are present.

where:

For example the full name of the English version of the menu xXGEN is "AEXGEN.FMT".

The page number is transparent to the CDS/ISIS user. Like the file extension the page number is automatically provided by the system. Therefore when a CDS/ISIS program prompts you to enter a menu or worksheet name you must not include the page number. Furthermore as file names are restricted to 6 characters, menus and worksheets names may not be longer than 5 characters.

System menus and worksheets may only have one page.

The language code is mandatory for system menus and standard system worksheets. For example if you want to link a HELP menu to the system menu EXGEN, its name must begin with the letter E.

The X convention is only enforced for standard system menus. It is a good practice, however, to use the same convention for menus that you create, and to avoid creating worksheets (including data entry worksheets) with X in this position, that is with names like xXxxx.

Furthermore, if a data base name contains X or Y in the second position, then the corresponding data entry worksheets will be created in the system worksheet directory (parameter 2 of "SYSPAR.PAR") rather then the data base directory. Although this will not prevent normal operation of the data base, it is not recommended.

B. Data Base files

Each data base consists of a number of physically distinct files as indicated below. There are three categories of data base files:

In the following description "xxxxxx" is the 1-6 character data base name.

The name of user files is fully under user control. However, in order to avoid possible name conflicts it is advisable to establish some standard conventions to be followed by all CDS/ISIS users at a given site, such as for example to define "yyyyyy" as follows:

  xxxyyy

where:

Master file structure and record format

A. Master file record format

"MFBWB" and "MFBWP" are initially set to 0 when the record is created. They are subsequently updated each time the record itself is updated (see below).

The total directory length in bytes is therefore "6*NVF"; the "BASE" field in the leader is always: "18+6*NVF".

(the last four fields are used for statistics during backup/restore).

C. Master file block format

which are stored in a 31-bit signed integer (4 bytes) as follows:

  pointer = XRFMFB * 2048 + XRFMFP

(giving therefore a maximum Master file size of 500 Megabytes).

Each block of the "XRF" file is 512 bytes and contains 127 pointers. The first field in each block ("XRFPOS") is a 31-bit signed integer whose absolute value is the "XRF" block number. A negative "XRFPOS" indicates the last block.

Deleted records are indicated as follows:

E. Master file updating technique

Inverted file structure and record formats

A. Introduction

"ORDN", "ORDF", "N" and "K" are fixed for a given generated system. Currently these values are set as follows:

"ORDN = 5"; "ORDF = 5"; "N = 15"; "K = 5" for both B*trees

                  +--------------+
                  | Root address |
                  +-------|------+
                          |                          .CNT file
                          |                      -------------
                          |                          .N0x file
              +-----------V--------+
              | Key1 Key2 ... Keyn |                   Root
              +---|-------------|--+
                  |             |
            +-----+             +------+
            |                          |
 +----------V----------+     +---------V----------+ 1st level
 | Key1  Key2 ... Keyn | ... | Key1 Key2 ... Keyn |   index
 +--|------------------+     +-----------------|--+
    |                                          :
    :                                  +-------+
    |                                  |
 +--V------------------+     +---------V----------+ last level
 | Key1  Key2 ... Keyn | ... | Key1 Key2 ... Keyn |   index
 +---------|-----------+     +---------|----------+
           |                           |
           |                           |         -------------
           |                           |             .L0x file
 +---------V-----------+     +---------V----------+
 | Key1  Key2 ... Keyn | ... | Key1 Key2 ... Keyn |
 +--|------------------+     +--------------------+
    |
    |                                            -------------
    |                                                .IPF file
 +--V----------------------------------+
 | P1  P2  P3 ..................... Pn |
 +-------------------------------------+

Figure 67: Inverted file structure

The other values are set as required when the B*trees are generated.

C. Format of ".N0x" files

C. Format of .N0x files

E. Format of ".IFP" file

E. Format of .IFP file

"IFPREC[1]" and "FPREC[2]" of the first block are a pointer to the next available position in the ".IFP" file.

Pointers from ".L0x" to ".IFP" and pointers within ".IFP" consist of two 31-bit signed integers: the first integer is a block number, and the second integer is a word offset in "IFPREC" (e.g. the offset to the first word in "IFPREC" is 0). The list of postings associated with the first search term will therefore start at 1/0.

Each list of postings consists of a header (5 double-words) followed by the actual list of postings (8 bytes for each posting). The header has the following format (each field is a 31-bit signed integer):

Each posting is a 64-bit string partitioned as follows:

Each field is stored in a strict left-to-right sequence with leading zeros added if necessary to adjust the corresponding bit string to the right (this allows comparisons of two postings as character strings).

The list of postings is stored in ascending "PMFN"/"PTAG"/"POCC"/"PCNT" sequence. When the inverted file is loaded sequentially (e.g. after a full inverted file generation with ISISINV), each list consists of one or more adjacent segments. If "IFPTOT <= 32768" then: "IFPNXTB/IFPNXTP = 0/0" and "IFPTOT = IFPSEGP = IFPSEGC".

As updates are performed, additional segments may be created whenever new postings must be added. In this case a new segment with capacity "IFPTOTP" is created and linked to other segments (through the pointer "IFPNXTB"/"IFPNXTP") in such a way that the sequence "PMFN"/"PTAG"/"POCC"/"PCNT" is maintained. Whenever such a split occurs the postings of the segment where the new posting should have been inserted are equally distributed between this segment and the newly created segment. New segments are always written at the end of the file (which is maintained in "IFPREC[1]"/"IFPREC[2]" of the first ".IFP" block.

For example, assume that a new posting "Px" has to be inserted between "P2" and "P3" in the following list:

 +----------------------------+
 | 0 0 5 5 5 | P1 P2 P3 P4 P5 |
 +----------------------------+

after the split (and assuming that the next available position in ".IFP" is 3/4) the list of postings will consist of the following two segments:

 +----------------------------+
 | 3 4 5 3 5 | P2 P2 Px -- -- |
 +--|-------------------------+
    |
 +--V-------------------------+
 | 0 0 5 3 5 | P3 P4 P5 -- -- |
 +----------------------------+

In this situation, no new segment will be created until either segment becomes again full.

As mentioned above, the posting lists are normally stored one after the other. However, in order to facilitate access to the ".IFP" file the segments are stored in such a way that:

LICENCE