Biblio-Isis

 view release on metacpan or  search on metacpan

lib/Biblio/Isis/Manual.pod  view on Meta::CPAN

=item C<xxxxxx.XRF>

Crossreference file (Master file index)

=item C<xxxxxx.CNT>

B*tree (search term dictionary) control file

=item C<xxxxxx.N01>

B*tree Nodes (for terms up to 10 characters long)

=item C<xxxxxx.L01>

B*tree Leafs (for terms up to 10 characters long)

=item C<xxxxxx.N02>

B*tree Nodes (for terms longer than 10 characters)

=item C<xxxxxx.L02>

B*tree Leafs (for terms longer than 10 characters)

=item C<xxxxxx.IFP>

Inverted file postings

=item C<xxxxxx.ANY>*

ANY file

=back

=head3 Auxiliary files

=over

=item C<xxxxx.STW>*

Stopword file used during inverted file generation

=item C<xxxxxx.LN1>*

Unsorted Link file (short terms)

=item C<xxxxxx.LN2>*

Unsorted Link file (long terms)

=item C<xxxxxx.LKl>*

Sorted Link file (short terms)

=item C<xxxxxx.LK2>*

Sorted Link file (long terms)

=item C<xxxxxx.BKP>

Master file backup

=item C<xxxxxx.XHF>

Hit file index

=item C<xxxxxx.HIT>

Hit file

=item C<xxxxxx.SRT>*

Sort convertion table (see "Uppercase conversion table (1SISUC.TAB)" on
page 227)

=back

=head3 User files

=over

=item C<yyyyyy.FST>*

Field Select tables used for sorting

=item C<yyyyyy.PFT>*

Additional display formats

=item C<yyyyyy.FMT>*

Additional data entry worksheets

=item C<yyyyyy.STW>*

Additional stopword files

=item C<yyyyyy.SAV>

Save files created during retrieval

=back

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 C<yyyyyy> as follows:

  xxxyyy

where:

=over

=item C<xxx>

is a data base identifier (which could be the first three letters of
the data base name if no two data bases names are allowed to begin with
the same three letters)

=item C<yyy>

lib/Biblio/Isis/Manual.pod  view on Meta::CPAN

directory has exactly NVF entries). Each directory entry consists of 3
integers:

=over

=item C<TAG>

Field Tag

=item C<POS>

Offset to first character position of field in the variable field
section (the first field has C<POS=0>)

=item C<LEN>

Field length in bytes

=back

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

=head3 Variable fields

This section contains the data fields (in the order indicated by the
directory). Data fields are placed one after the other, with no
separating characters.

=head2 B. Control record

The first record in the Master file is a control record which the
system maintains automatically. This is never accessible to the ISIS
user. Its contents are as follows (fields marked with C<*> are 31-bit
signed integers):

=over

=item C<CTLMFN>*

always 0

=item C<NXTMFN>*

MFN to be assigned to the next record created in the data base

=item C<NXTMFB>*

Last block number allocated to the Master file (first block is 1)

=item C<NXTMFP>

Offset to next available position in last block

=item C<MFTYPE>

always 0 for user data base file (1 for system message files)

=back

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

=head2 C. Master file block format

The Master file records are stored consecutively, one after the other,
each record occupying exactly C<MFRL> bytes. The file is stored as
physical blocks of 512 bytes. A record may begin at any word boundary
between 0-498 (no record begins between 500-510) and may span over two
or more blocks.

As the Master file is created and/or updated, the system maintains an
index indicating the position of each record. The index is stored in
the Crossreference file (C<.XRF>)

=head2 D. Crossreference file

The C<XRF> file is organized as a table of pointers to the Master file.
The first pointer corresponds to MFN 1, the second to MFN 2, etc.

Each pointer consists of two fields:

=over

=item C<RECCNT>*

=item C<MFCXX1>*

=item C<MFCXX2>*

=item C<MFCXX3>*

=item C<XRFMFB>

(21 bits) Block number of Master file block containing the record

=item C<XRFMFP>

(11 bits) Offset in block of first character position of Master record
(first block position is 0)

=back

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 C<XRF> file is 512 bytes and contains 127 pointers. The
first field in each block (C<XRFPOS>) is a 31-bit signed integer whose
absolute value is the C<XRF> block number. A negative C<XRFPOS> indicates
the last block.

I<Deleted> records are indicated as follows:

=over

=item C<XRFMFB E<lt> 0> and C<XRFMFP E<gt> 0>

logically deleted record (in this case C<ABS(XRFMFB)> is the correct block
pointer and C<XRFMFP> is the offset of the record, which can therefore

lib/Biblio/Isis/Manual.pod  view on Meta::CPAN

to the record is increased by 1024 to indicate that this is a new
record to be inverted (after the inversion of the record 1024 is
subtracted from C<XRFMFP>).

=head3 Update of existing records

Whenever you update a record (i.e., you call it in data entry and exit
with option X from the editor) the system writes the record back to the
Master file. Where it is written depends on the status of the record
when it was initially read.

=head4 There was no inverted file update pending for the record

This condition is indicated by the following:

On C<XRF> C<XRFMFP E<lt> 512> and

On C<MST> C<MFBWB = 0> and C<MFBWP = 0>

In this case, the record is always rewritten at the end of the Master
file (as if it were a new record) as indicated by C<NXTMFB>/C<NXTMFP> in the
control record. In the new version of the record C<MFBWB>/C<MFBWP> are set to
point to the old version of the record, while in the C<XRF> file the
pointer points to the new version. In addition 512 is added to C<XRFMFP>
to indicate that an inverted file update is pending. When the inverted
file is updated, the old version of the record is used to determine the
postings to be deleted and the new version is used to add the new
postings. After the update of the Inverted file, 512 is subtracted from
C<XRFMFP>, and C<MFBWB>/C<MFBWP> are reset to 0.

=head4 An inverted file update was pending

This condition is indicated by the following:

On C<XRF> C<XRFMFP E<gt> 512> and

On C<MST> C<MFBWB E<gt> 0>

In this case C<MFBWB>/C<MFBWP> point to the version of the record which is
currently reflected in the Inverted file. If possible, i.e. if the
record length was not increased, the record is written back at its
original location, otherwise it is written at the end of the file. In
both cases, C<MFBWB>/C<MFBWP> are not changed.

=head3 Deletion of records

Record deletion is treated as an update, with the following additional
markings:

On C<XRF> C<XRFMFB> is negative

On C<MST> C<STATUS> is set to 1

=head2 F. Master file reorganization

As indicated above, as Master file records are updated the C<MST> file
grows in size and there will be lost space in the file which cannot be
used. The reorganization facilities allow this space to be reclaimed by
recompacting the file.

During the backup phase a Master file backup file is created (C<.BKP>).
The structure and format of this file is the same as the Master file
(C<.MST>), except that a Crossreference file is not required as all the
records are adjacent. Records marked for deletion are not backed up.
Because only the latest copy of each record is backed up, the system
does not allow you to perform a backup whenever an Inverted file update
is pending for one or more records.

During the restore phase the backup file is read sequentially and the
program recreates the C<MST> and C<XRF> file. At this point alt records which
were marked for logical deletion (before the backup) are now marked as
physically deleted (by setting C<XRFMFB = -1> and C<XRFMFP = 0>.
Deleted records are detected by checking holes in the C<MFN> numbering.

=head1 Inverted file structure and record formats

=head2 A. Introduction

The CDS/ISIS Inverted file consists of six physical files, five of
which contain the dictionary of searchable terms (organized as a
B*tree) and the sixth contains the list of postings associated with
each term. In order to optimize disk storage, two separate B*trees are
maintained, one for terms of up to 10 characters (stored in files
C<.N01>/C<.L01>) and one for terms longer than 10 characters, up to a maximum
of 30 characters (stored in files C<.N02>/C<.L02>). The file C<CNT> contains
control fields for both B*trees. In each B*tree the file C<.N0x> contains
the nodes of the tree and the C<.L0x> file contains the leafs. The leaf
records point to the postings file C<.IFP>.

The relationship between the various files is schematically represented
in Figure 67.

The physical relationship between these six files is a
pointer, which represents the relative address of the record being
pointed to. A relative address is the ordinal record number of a record
in a given file (i.e. the first record is record number 1, the second
is record number 2, etc.). The file C<.CNT> points to the file C<.N0x>,
C<.N0x> points to C<.L0x>, and C<.L0x> points to C<.IFP>. Because the
C<.IFP> is a packed file, the pointer from C<.L0x> to C<.IFP> has two
components: the block number and the offset within the block, each expressed
as an integer.

=head2 B. Format of C<.CNT> file

This file contain two 26-byte fixed length records (one for each
B*tree) each containing 10 integers as follows (fields marked with *
are 31-bit signed integers):

=over

=item C<IDTYPE>

B*tree type (1 for C<.N01>/C<.L01>, 2 for C<.N02>/C<.L02>)

=item C<ORDN>

Nodes order (each C<.N0x> record contains at most C<2*ORDN> keys)

=item C<ORDF>

Leafs order (each C<.L0x> record contains at most C<2*ORDF> keys)

=item C<N>

Number of memory buffers allocated for nodes

=item C<K>

Number of buffers allocated to lst level index (C<K E<lt> N>)

=item C<LIV>