Note: A fully printable copy of the Talis Version 10.0 edition of this chapter is available in Adobe Acrobat™ (.PDF) format. Click here to view the Version 10.0 edition.
New additions to stock, deletions, or changes to existing works are reflected in OPAC by running "update_daily_access_points" overnight. Changes to collections or indexing criteria may necessitate a complete rebuild of the OPAC indexes, this is done by running "auto_access_points".
The OPAC indexes updated or regenerated by the above scripts include:
Once OPAC indexes have been built, it will usually only be necessary to rebuild them infrequently; for example following certain software upgrades and/or after considerable changes to your indexing strategy (such as amendments to the list of MARC tags that you wish to use to generate keywords).
Note: It is important to ensure that all users are logged off when running "auto_access_points" as failure to do so could result in failure to copy back in the revised OPAC tables, leaving the library without certain indexes. The "kill_talis" and "kill_opac" procedures can be used to make sure all users are logged out. Also make sure that TalisWeb OPAC is taken offline by stopping the Web Server daemon.
A complete rebuild should always be followed by a "full_dbdump", as explained in System Manager Manual, Volume 1: System Maintenance, Chapter 3: Database & Software Backup.
The time taken by the "auto_access_points" process to complete will vary, depending on the size of the database and the processing capacity of your machine, but is usually measured in hours.
Both scripts are usually run from "cron" by the user "ops", but can be started manually as necessary.
It is important to log on as the same operator when attempting to build or update access points. For example, having logged on as "ops" on one occasion you will encounter problems if you subsequently attempt to continue having logged on as someone else (for example using the "talis" logon ID). This problem will be indicated by an error message:
Permission denied. Unable to create report.
Author entries are built for any tags that appear in the AUTHOR_TAG and AUTHOR_TAG_RULE tables.
The AUTHOR_TAG table specifies the weightings to be assigned to each MARC tag and subfield, whereas AUTHOR_TAG_RULE specifies rules for concatenating tags. For example, 100*a*c will be built, with a separate entry for 110*c.
Entries will be built for tags specified in AUTHOR_TAG_RULE, but no filing weightings will be attached to the data, which may lead to a strange filing order. Entries will not be built if the tag does not occur in AUTHOR_TAG_RULE.
A flaw in the parameter interface means that this should not currently be used for amending author tag values. Please contact the Help Desk if you require to amend or add any data to the AUTHOR_TAG or AUTHOR_TAG_RULE tables.
|
MARC Tag |
Subfield |
Line Number |
Rule Number |
|
100 |
a |
0 |
0 |
|
100 |
c |
0 |
0 |
|
100 |
d |
0 |
0 |
|
100 |
e |
0 |
0 |
|
100 |
f |
0 |
0 |
|
100 |
h |
0 |
0 |
|
100 |
k |
0 |
0 |
|
100 |
l |
0 |
0 |
|
110 |
a |
0 |
0 |
|
110 |
c |
0 |
0 |
|
110 |
c |
1 |
1 |
|
111 |
a |
0 |
0 |
|
111 |
c |
0 |
0 |
|
111 |
c |
1 |
1 |
|
400 |
a |
0 |
0 |
|
400 |
c |
0 |
0 |
|
400 |
d |
0 |
0 |
|
400 |
e |
0 |
0 |
|
400 |
f |
0 |
0 |
|
400 |
h |
0 |
0 |
|
400 |
k |
0 |
0 |
|
400 |
l |
0 |
0 |
|
600 |
a |
0 |
0 |
|
600 |
c |
0 |
0 |
|
600 |
d |
0 |
0 |
|
600 |
e |
0 |
0 |
|
600 |
f |
0 |
0 |
|
600 |
h |
0 |
0 |
|
600 |
k |
0 |
0 |
|
600 |
l |
0 |
0 |
|
610 |
a |
0 |
0 |
|
610 |
c |
0 |
0 |
|
610 |
c |
0 |
0 |
|
611 |
a |
0 |
0 |
|
611 |
c |
0 |
0 |
|
611 |
c |
1 |
1 |
|
700 |
a |
0 |
0 |
|
700 |
c |
0 |
0 |
|
700 |
d |
0 |
0 |
|
700 |
e |
0 |
0 |
|
700 |
f |
0 |
0 |
|
700 |
h |
0 |
0 |
|
700 |
k |
0 |
0 |
|
700 |
l |
0 |
0 |
|
710 |
a |
0 |
0 |
|
710 |
c |
0 |
0 |
|
710 |
c |
l |
l |
|
711 |
a |
0 |
0 |
|
711 |
c |
0 |
0 |
|
711 |
c |
1 |
1 |
|
800 |
a |
0 |
0 |
|
800 |
c |
0 |
0 |
|
800 |
d |
0 |
0 |
|
800 |
e |
0 |
0 |
|
800 |
f |
0 |
0 |
|
800 |
h |
0 |
0 |
|
800 |
k |
0 |
0 |
|
800 |
l |
0 |
0 |
|
810 |
a |
0 |
0 |
|
810 |
c |
0 |
0 |
|
810 |
c |
1 |
1 |
|
811 |
a |
0 |
0 |
|
811 |
c |
0 |
0 |
|
811 |
c |
1 |
1 |
Keyword entries are built for any tags that appear in the KEYWORD_TAG table. Entries can be added or amended via the parameter interface detailed in Keyword Tags Maintenance.
|
MARC Tag |
Subfield |
Local Flag |
|
240 |
a |
F |
|
245 |
a |
F |
|
245 |
b |
F |
|
245 |
h |
F |
|
245 |
j |
F |
|
245 |
k |
F |
|
246 |
a |
F |
|
248 |
h |
F |
|
440 |
a |
F |
|
670 |
a |
T |
|
671 |
a |
T |
|
740 |
a |
F |
|
745 |
a |
F |
|
840 |
a |
F |
The Local Flag column is used to indicate whether the local or global version of the tag is to be included. The meaning of the two possible values against this flag are summarised below:
|
Local Flag Value |
Meaning |
|
T |
MARC Tag/Subfield is used locally |
|
F |
MARC Tag/Subfield not used locally |
The Title table is more complicated in that the default list of Tags and Subfields varies, depending upon the type of Work record involved. It operates this way in order to produce the appropriate OPAC outputs for different WorkWork Relationship Types, namely:
The meaning of each WorkWork Relationship Type is summarised below:
|
Relationship Type |
Work-Work Link Relationship |
|
255 |
Single-Volume Monograph (or a parent Multi-Volume record) |
|
0 |
Analytical record |
|
1 |
Multi-Volume child |
|
2 |
Serial |
|
3 |
Series |
Note: A Serial title with no Volumes attached will be treated as a Monograph, as will Analytical parents, Series parents and Multi-Volume Parent Works.
Monographs Tags
|
MARC Tag |
Subfield |
Relationship Type |
Local Flag |
|
240 |
a |
255 |
F |
|
245 |
a |
255 |
F |
|
248 |
h |
255 |
F |
|
640 |
a |
255 |
F |
|
645 |
a |
255 |
F |
|
640 |
a |
255 |
T |
|
645 |
a |
255 |
T |
|
740 |
a |
255 |
F |
|
745 |
a |
255 |
F |
|
740 |
a |
255 |
T |
|
745 |
a |
255 |
T |
|
840 |
a |
255 |
T |
|
840 |
a |
255 |
F |
|
440 |
a |
255 |
T |
Catering for Combined Title / Sub-Title Searching: It is not possible in Talis OPAC Title Search to search for the combined title (245*a) and sub-title (245*b). To get around this limitation there are a number of possible actions that could be taken:
|
MARC Tag |
Subfield |
Relationship Type |
Local Flag |
|
240 |
a |
0 |
F |
|
245 |
a |
0 |
F |
|
248 |
h |
0 |
F |
|
740 |
a |
0 |
F |
|
740 |
a |
0 |
T |
|
745 |
a |
0 |
T |
|
745 |
a |
0 |
F |
|
640 |
a |
0 |
F |
|
640 |
a |
0 |
T |
|
645 |
a |
0 |
F |
|
645 |
a |
0 |
T |
|
840 |
a |
0 |
T |
|
840 |
a |
0 |
F |
|
440 |
a |
0 |
T |
|
MARC Tag |
Subfield |
Relationship Type |
Local Flag |
|
248 |
h |
1 |
F |
|
MARC Tag |
Subfield |
Relationship Type |
Local Flag |
|
240 |
a |
2 |
F |
|
245 |
a |
2 |
F |
|
248 |
h |
2 |
F |
|
640 |
a |
2 |
F |
|
640 |
a |
2 |
T |
|
645 |
a |
2 |
F |
|
645 |
a |
2 |
T |
|
740 |
a |
2 |
F |
|
740 |
a |
2 |
T |
|
745 |
a |
2 |
T |
|
745 |
a |
2 |
F |
|
840 |
a |
2 |
T |
|
840 |
a |
2 |
F |
|
440 |
a |
2 |
T |
|
MARC Tag |
Subfield |
Relationship Type |
Local Flag |
|
240 |
a |
3 |
F |
|
245 |
a |
3 |
F |
|
248 |
h |
3 |
F |
|
640 |
a |
3 |
F |
|
640 |
a |
3 |
T |
|
645 |
a |
3 |
F |
|
645 |
a |
3 |
T |
|
740 |
a |
3 |
F |
|
740 |
a |
3 |
T |
|
745 |
a |
3 |
F |
|
745 |
a |
3 |
T |
|
240 |
a |
3 |
F |
Entries in the Classmark search are built into the CLASS table. These are sourced from the CLASSIFICATION table. Only those classifications that are attached to Work records are used. Entries are built for both Main and Added class numbers.
Entries in the Number index are held in the NUMBER table. These are sourced from the CONTROL_NUMBER table. Entries are built for both Main and Added Control Numbers.
Note: Libraries have no control over what is built into the Class and Number indexes.
"auto_access_points" is the process which builds OPAC indexes, according to rules defined by the Library (in the tag rules tables). It also builds separate collections, according to criteria defined by the Library (see Collection Management for details of setting up collections).
The "auto_access_points" script calls two main processes:
Different processing types can be specified, individual indexes built as necessary and "access_points" re-started if it has failed. These options will be described.
Note: After running "auto_access_points" it is vital to perform a "full_dbdump" in order to re-start transaction logging on the database. This applies whether or not the process completed successfully.
To start "auto_access_points" manually:
auto_access_points <Enter>
(Processing options are listed below)
To run "auto_access_points" from "cron" you will need a "cron" line (all entered as one line) such as:
0 22 * * 6 /bin/su - ops -c "auto_access_points >/var/tmp/auto_access_points.log" 2>/var/tmp/auto_access_points.err
When running "auto_access_points" it is now possible to specify the processing type using a "t" switch. The options available are:
This option builds the OPAC "access_points" tables as normal. If no option is specified, the default will be "STANDARD".
Running "auto_access_points" with this option will add entries from Authority crossreferences to the existing OPAC Author table.
Running "auto_access_points" with this option will build the standard OPAC "access_points" tables, and then add entries from Authority crossreferences to the existing OPAC Author table.
For example; type in:
auto_access_points tALL <Enter>
"auto_access_points" will give a warning if Talis is running but it will continue to run.
Authority cross-references are built into OPAC using the script "authority_ap" found in the /usr/opt/blcmp/talis/access_points directory.
This should always be run after running "auto_access_points" if you want authority cross-references to appear in the Author Index. This can be run as an alternative to specifying the "ALL" switch in "auto_access_points".
The "auto_access_points" script sets the correct environment for running "access_points" and calls a number of processes, these are:
The script first performs a test to make sure "access_points" is not already running. Each time auto_access_points is run, a row is added to the "BUILD_OPAC" table. This enables Talis Information to trace a history of "access_points" runs and derive timings for the process.
If "auto_access_points" fails for any reason, there will be no end time present in this table. It will then be necessary to run the script "reset_build_opac", found in the /usr/opt/blcmp/talis/access_points directory.
This script will reset the "BUILD_OPAC" table by creating an end_time. If this script is not run after "access_points" has failed, then the next time "auto_access_points" is run it will fail giving a message in the access_points.report file that there was no end time from the previous run:
"Unable to run the build OPAC process because the previous run which started on [date] is either still running or failed to complete successfully."
This script will reset the BUILD_OPAC table by creating an end_time. This script needs to be run if "auto_access_points" has failed. There is no harm in running it accidentally.
To run the script:
cd /usr/opt/blcmp/talis/access_points <Enter>
reset_build_opac -ddbname <Enter>
The database name will default to "prod_talis" if not specified.
If successful the script will report:
"The 'build_opac' process table has been reset."
The next process run is the "mcoll_dae" daemon, which assigns Works to collections. If a Work does not satisfy the select requirements for any collections then it will not appear in OPAC. The main collection is usually defined as a catch-all collection.
When "mcoll_dae" has finished, the "auto_access_points" script calls the "build_opac" script with a number of default conditions, normally building all indexes. It is possible to build individual indexes where time or space is at a premium, where it is only necessary to rebuild a single index or to re-start the "access_points" process. This is done by calling the "build_opac" script with the relevant command line options.
To run "build_opac" first move to /usr/opt/blcmp/talis/access_points.
Command line options:
build_opac -ddbname -s/scratch -make_collection -author -title -keyword -class -number -READONLY -LOADONLY -FREESPACE <Enter>
where:
-d allows you to specify the name of the database against which the collections are to be built. For example: -d prod_talis. This defaults to "prod_talis".
-s this is the directory and filename prefix to which all work files and reports will be written. The default to /scratch.
-make_collection specifies that collections should be re-built. This should always be specified if new collections are being added, or existing collections are being changed. You must specify at least one index to build if processing collections. If building "access_points" in stages, this step should be included for the first step, but it can be omitted for subsequent stages. It is not possible to build individual indexes. Omitting this option in later runs speeds up the construction of indexes, assuming this were your objective. For example, typical input to re-build just the Author index might be:
build_opac -dprod_talis -s/scratch/ap -author <Enter>
Note: By default all indexes will be built, but individual indexes - or combinations of indexes - may be specified optionally. This is useful if you ever need to re-build indexes selectively.
For example, to re-build all Title indexes for all collections, type:
build_opac -dprod_talis -s/scratch/ -title <Enter>
-READONLY specifies that the data will be extracted and processed, but the revised data should not be loaded back into the Talis database
-LOADONLY specifies that the processed data files should be loaded into the Talis database. This option can be used to load files where "access_points" has failed due to lack of sort space, provided the space available has been enlarged.
-FREESPACE specifies that any space calculation is ignored. This is sometimes necessary where the space available is reported as an exponent as "access_points" cannot handle this calculation. If using this switch, be very careful about ensuring that sufficient space is available as indexes may be truncated if the process runs out of space.
Note: There are efficiency gains to be made in running Author, Keyword and Title indexes together as each of these indexes require the entire WORK_SUBFIELD table to be processed. Running these processes together means that only one pass through this table is necessary.
The "build_opac" script then starts the access_points daemons. These initially extract the data they will process (from WORK_SUBFIELD, CLASSIFICTION and CONTROL_NUMBER). Data from WORK_SUBFIELD is extracted according to the rules defined in the Tag Tables (listed in Rules for Building Indexes (Tag Rules)).
The "access_points" daemons run concurrently. They are:
This daemon generates the AUTHOR, TITLE and KEYWORD indexes.
This daemon generates the CLASS index.
This daemon generates the NUMBER index.
The data processed by the daemons is held in temporary disk files during processing. The Author and Keyword data needs to be sorted before being loaded back into the database tables. The final stage is to rebuild the Sybase indexes on these tables. This stage of processing must not be interrupted.
"auto_access_points" (or "build_opac") produces many reports in the working directory and reports directory during processing. On successful completion of a run these are amalgamated into a single file: "access_points.report" in the working directory (usually /scratch). Details are appended to this script each time "access_points" is run.
It is important to check this file after running "auto_access_points" as any errors or failures in the process will be reported to this file. Certain errors can be ignored, others must be acted on. If there is insufficient space the run will terminate, in which case the figure produced by the report should be used as a guide when clearing sufficient space in /scratch for a successful run.
Please do not delete this file after running "auto_access_points" as it provides a useful record for predicting how much disk space and time should be allocated for future runs.
It is not possible to reproduce a complete example of the report here as it tends to be very large. It includes a section which reports on the total amount of disk space required in /scratch in order to run "auto_access_points".
Refer to Figure 10.1: Extract From Access Points Report .
used scratch sort
KEYWORD 7295801 14591602 18239502
AUTHOR 6062729 12125458 12156822
TITLE 5682550 12501610 0
CLASS 1580231 3476508 0
NUMBER 1799056 3957923 0
available required
/scratch 55553000 80049425
This job will run out of space in /scratch
Figure 10.1: Extract From Access Points Report
The following are allowable errors, which can safely be ignored:
Unknown command (ignored): LOCK_DBNAME","prod_meta" No primary key for the table or view exists /scratch/access_points.TITLE.acc: No such file or directory
(This error will also refer to CLASS and NUMBER).
DB-LIBRARY error: Attempt to bulk-copy a NULL value into Server column 2, which does not accept NULL values.
The following errors must not be ignored:
build_opac failed Wed Apr 2 11:34:33 BST 1997 This job will run out of space in 'filesystem' DB-Library: Unexpected EOF from SQL Server DATABASE ERROR!!!!!! DBPROCESS = 0X313C8 Source = ERROR_HANDLER severity = 9 error no = 20017 message = "Unexpected EOF from SQL Server."
Reports generated whilst "access_points" is running can be useful in establishing progress of the run. Each daemon creates reports in /usr/opt/blcmp/talis/reports. For example:
There will be corresponding files for access_points_dae, caccess_points_dae and naccess_points_dae.
The daemon log files will indicate how many records have been processed as they report out each thousand records. Once all the records have been processed, the report file will be written, indicating how many records in total were processed and how long this took.
See Figure 10.2: Example Make_Collection Report (mcoll_dae.rep).
mcoll_dae.rep 26 Oct 1997 08:22:10
Make Collection Reports
~~~~~~~~~~~~~~~~~~~~~~~
MAKE COLLECTION processing
Work Ids processed: 214131 (11.083/second)
Valid Work Ids: 0
Last WORK_ID used: 0
Figure 10.2: Example Make_Collection Report (mcoll_dae.rep)
Note: The last two entries here always say 0.
When the daemons have finished extracting the data, the sort stage begins, followed by loading.
"Access_points" creates large temporary disk files whilst processing data. These files are removed automatically by the process once they have been copied successfully into the database, but the process will fail if there is insufficient disk space available.
Two areas of disk space are required. The first is space to hold the working files and reports, which uses /scratch by default (although another directory may be specified). The second is space for sorting the temporary author and keyword files, which uses space available in /var/tmp (which is usually linked to scratch). Therefore the entire space required is usually in the /scratch directory.
The most reliable method of determining space requirements when running "auto_access_points" is to check the report from a previous run. A vague approximation can be determined from the space used by the existing tables in the database, although this is less useful where new collections are being built. Use the "sp_spaceused" command in isql to determine the current sizes of the required tables in the database:
isql -Usa -P sp_spaceused AUTHOR sp_spaceused AUTHOR_WORK_LINK
Take the "data" figure to work out the space requirement. Add the figures for both of these tables to work out the disk space required to build the Author Index.
If the run has failed for lack of sort space, it is possible to work out the space required for Author and Keyword from the "used" space in the "access_points.report" file.
(therefore extra space needed will be 4.5 times used space).
The used space required for Keyword build is marginally greater (by approx 10Mb) than the database space used for the KEYWORD and KEYWORD_WORK_LINK tables in the database.
For the TITLE, CLASS and NUMBER indexes the disk space required roughly the same as the data space taken by the Sybase table.
It may be necessary to stop "auto_access_points" if it has run beyond its allotted time. Always contact the Help Desk for assistance in doing this as you risk losing your OPAC if this is stopped either in the wrong way or at an inopportune time.
It is vital to perform a "full_dbdump" after stopping "auto_access_points" as the database will be left in a state where transaction logging will not function.
To check if "access_points" is still running:
ps -ef |grep build_opac <Enter>
"update_daily_access_points" normally runs every night to update OPAC indexes. This is normally run from the UNIX "cron", but it can be started manually. It is not essential that all users are logged off before running this, although they may experience a slight degradation in performance whilst it is running.
This script calls two daemon processes. Ther first is mcoll_dae, which works out which collections works should be part of, the second is "access_points_dae", which assigns works to OPAC indexes.
Any Works that have been edited, or Works that have attached Items that have been edited are normally processed. The collection daemon looks at the WORK_UPDATE table for edited Works (i.e. those of a status 100, 130 or 140). If these Works are processed successfully by the "make_collection" daemon their statuses are modified to become 102, 132 or 142.
If Works are not processed successfully then their statuses will be modified to become 103, 133 or 143.
The "access_points" daemon then looks at the WORK_UPDATE table for Works which have been processed successfully in the previous stage (i.e. those with statuses 102, 132 or 142). If these Works are processed successfully at this stage, their statuses will become 104, 134 or 144.
If Works are not processed successfully at this stage, their statuses will become 105, 135 or 145.
Changes to Item records will only be processed if the Library is running the "itu_update_wku.pl" script
To start "update_daily_access_points" manually:
update_daily_access_points <Enter>
Update_daily_access_points is normally run automatically every night from the UNIX "cron" facility. You will need a "cron" line (entered as all one line) such as:
0 03 * * 0-6 /bin/su - ops -c "update_daily_access_points >/var/tmp/update_daily_access_points.log" 2>/var/tmp/update_daily_access_points.err
This script will take a variable time to complete, depending on the size of the database, the number of records to update and the processing capacity of your machine.
"update_daily_access_points" can be safely interrupted. If you need to do this:
cd /usr/opt/blcmp/talis/control <Enter> pg mcoll_dae.cfg <Enter> pg access_points_dae.cfg <Enter>
Both files should say "UPDATE" at the bottom.
dae_term mcoll_dae <Enter> dae_term access_points_dae <Enter>
Report, log and error files are generated for both the "mcoll_dae" and "access_points" daemons when running "update_daily_access_points". These files are written to the /usr/opt/blcmp/talis/reports directory.
The error files "mcoll_dae.err" and "access_points_dae.err" are always generated, these normally contains the error message:
Unknown command (ignored): "LOCK_DBNAME","prod_meta"
This can be safely ignored. Any other messages should be reported to the Help Desk.
The log file "mcoll_dae.log" is generated as a result of the "make_collection" aspect of "update_daily_access_points". This is produced every night. Make_collection log files simply give an account of when the process started and will always contain the message:
Fork disabled
Refer to Figure 10.3: Example Make_Collection Log (mcoll_dae.log).
mcoll_dae.log 23 Aug 1994 10:44:17 Make Collection Log ~~~~~~~~~~~~~~~~~~~ Process started : 23 Aug 1994 10:44:17 by Operator : cs_talis Command received from user: cs_talis 23 Aug 1994 10:44:17 Fork disabled
Figure 10.3: Example Make_Collection Log (mcoll_dae.log)
This is produced every night and states the number of Work Ids processed. (The last two lines of the report always show zeros and may be ignored).
Refer to Figure 10.4: Example Make_Collection Report (mcoll_dae.rep).
mcoll_dae.rep 23 Aug 1994 10:48:03 Make Collection Reports ~~~~~~~~~~~~~~~~~~~~~~~~ MAKE COLLECTION processing Work Ids processed: 451 (2.004/second) Valid Work Ids: 0 Last WORK_ID used: 0
Figure 10.4: Example Make_Collection Report (mcoll_dae.rep)
Similarly the report file "mcoll_dae.rep" is generated by the collection daemon. This is produced every night with the previous report file being overwritten. It states the number of Work Ids processed and the speed with which they were processed. The number of works processed per second is shown in the report file, this is a useful indicator of the efficiency of the select criteria for the collections. This should not normally be less than one work per second.
The last two lines of the report always show zeros and may be ignored.
The log file "access_points_dae.log" is generated by the access_points daemon. This is produced every night, with the previous nights file being overwritten. This log gives an account of when the process was started and always contains the message:
Fork disabled
It then goes on to indicate that the "access_points" daemon is running in update mode and shows the number of Works read so far. If there are large numbers of Works then a fresh line will be started for each successive 1,000 Works processed.
Providing this daemon has been terminated legally, the final line of the log will indicate the date and time when it was stopped:
Main execution finished at [date] [time]
Refer to Figure 10.5: Example Access_Points Log (access_points_dae.log).
access_points_dae.log 23 Aug 1994 10:48:0 Access Points Log ~~~~~~~~~~~~~~~~~ Process started : 23 Aug 1994 10:48:04 by Operator : cs_talis Command received from user: cs_talis 23 Aug 1994 10:48:04 Running in UPDATE mode : processing KEYWORD/TITLE/AUTHOR/CLASS/NUMBER by default 0 works read: current WORK_ID 230 at Tue Aug 23 10:48:24 1994 Main execution finished at Tue Aug 23 15:38:04 1994 Fork disabled
Figure 10.5: Example Access_Points Log (access_points_dae.log)
Similarly the report file "access_points_dae.rep" is generated by the access_points daemon. This is produced every night, with the previous nights file being overwritten.
This report indicates the number of records processed, the speed with which they were processed and the number of updates to the various OPAC indexes.
Refer to Figure 10.6: Example Access_Points Report (access_points_dae_rep).
access_points_dae.rep 23 Aug 1994 15:38:04 Access Point Reports ~~~~~~~~~~~~~~~ KEYWORD/TITLE/AUTHOR processing Work Ids processed: 709 (0.041/second) Valid Work Ids: 709 Keywords updated: 3787 Titles updated: 780 Authors updated: 1152 Last WORK_ID used: 0 NUMBER processing Work Ids processed: 709 (0.041/second) Valid Work Ids: 709 Numbers updated: 775 CLASS processing Work Ids processed: 709 (0.041/second) Valid Work Ids: 709 CLasses updated: 296
Figure 10.6: Example Access_Points Report (access_points_dae_rep)
OPAC access points may be either regenerated entirely using the "auto_access_points" script, or updated to reflect the changes to records during the current day using the "update_daily_access_points" script.
All OPAC indexes are updated or regenerated by the above scripts.
The particular MARC Tags and Subfields involved in the regeneration/updating of OPAC access points have been summarised. A detailed account of the "build_opac" process has been given, for reference.
Copyright 2000 © Talis Information Ltd. All Rights Reserved.