About the Rule Files
The rule files contain logical rules that govern the ability to perform certain actions with database records. They are:
All rule files are edited as free text files. If the first character of a line is '#', the line is ignored. The # is used to enter comments into the file or to turn off a rule or condition.
Rule lines must conform to the structure described in the documentation for each rule file. Each line consists of nine data elements that, by default, are delimited by the vertical bar character ('|'). The delimiter can be changed to any other character by including the trigger @delimiter=c as the first line of the file, where c is the new delimiter character. This is useful when the vertical bar itself is part of a rule target (e.g., a subfield delimiter).
The rule files all have nine identically named elements, but the effect that each element has on the rules governed by a particular file is specific to each rule file.
Two special values for data elements are:
NULL | This term is used when the element contains no value at all. In such a case, there will be no character between the delimiters (i.e., ||). |
BLANK | This term is used when the element contains the <SPACE> character (i.e., | |). |
The rules are read from the beginning of the file, continuing to the end. Rules may appear on one line or span multiple lines. The last line of a rule begins with the letter 'q' in the Logic Operator element. Each line of a rule specifies a condition that the particular record being tested must meet for the rule to "test true," although what this means in terms of the action the system takes depends on the type of rule file. If none of the specified conditions in a rule is met, the rule "tests false," and the next rule in the file is tested.
Innovative recommends that users follow the examples given in the documentation for each rule file and adhere to recommended practices for each type of rule file. The programming underlying the system interpretation of the rule files is complex and not necessarily the same for all files. The elements provide the groundwork for functionality that may be developed in the future but may not be present currently. The examples illustrate recommended strategies for the rule files.
Special Field Codes
Records may contain special fields that are uniquely structured to perform a defined function. Data is added to special fields in the required format by the system because of user activity, but users cannot enter data directly into these fields. Many of these fields are used internally only and are never seen by users. Rule files may refer to these fields and, for this reason, are listed below.
The following table lists the tag, name, a short description of each special field, and the record(s) in which they appear. Values for the Record Type are:
b | bibliographic |
i | item |
c | checkin |
o | order |
r | course |
a | authority |
p | patron |
e | resource |
g | program |
Record Type |
Tag | Name | Purpose |
---|---|---|---|
All | ^ | Link Rec | Contains record numbers of all records of a particular type that are linked to this one. This field occurs once for each type of linked record. |
o | 0 (zero) | Paid | Contains information about a previous payment on an order. |
p | 1 (one) | Family ID | This tag appears in patron records at libraries that have acquired the Linked Patrons product. It contains a unique identifier for a group of linked patron records. |
b, o, c | 1 (one) | "multi" locations | Contains a list of locations when there is more than one location per record (i.e., fixed-length field LOCATION = "multi"). |
o | 2 | "multi" funds | Contains a list of funds when there is more than one fund per order (i.e., fixed-length field FUND = "multi"). |
c | 2 | Ckin Info | Stores serial holdings information in a checkin record. A checkin record can have multiple '2' fields. When a Serials server sends a checkin record to a client, it creates MARC-tagged fields in the record on the client. When the client returns the checkin record to the server, the Innovative system saves each MARC-tagged field as a separate '2' field. The first three characters of a '2' field contain the corresponding MARC tag of that field. |
c | 3 | Check-In | Tracks individual issues of a serial (character-based serial records only). |
c | 4 | Routing | Contains a list of people to whom serial issues are routed. |
i | 4 | Virtual Patron | INN-Reach only. Holds the "virtual patron record" for an INN-Reach patron who requests an item from another institution using INN-Reach. This field is attached to the item record of the requested item at the owning location. |
p | 4 | Virtual Item | INN-Reach and ILL only. Holds the "virtual item record" of an INN-Reach (or ILL) item requested by a patron from another institution using INN-Reach (or ILL). This field is attached to the patron record of the requesting patron at the patron location. |
i, p | 5 | Booking | Inserted in the patron record of the patron making the booking and the item record of the item being booked. |
i | 6 | Course ID | Stores the record number of a course record to which the item belongs. |
i | 7 | Save Item | Stores the original item type, location, and number of times checked out when the item is placed on reserve and this data is temporarily changed. |
b, i, p | 8 | Hold | Stores information about a hold for an item or bibliographic record. This is stored in both the patron record and the corresponding item or bibliographic record. |
p | 9 | Fine | Records information about an outstanding fine assessed against a patron. |
r | 9 | Item ID | Stores item record information for an item placed on Course Reserve. A maximum of 350 item records can be attached to a reserve record via 9 fields. |
Internationalized Rule File Messages
The Message element in the Rules for Requesting and Rules for Deletion of Records files can be internationalized. Internationalization allows you to enter similar messages in more than one language. The system will then display the appropriate message, depending on the current language.
To enter internationalized text in a Message element:
- Place the cursor at the end of the Message element.
- Choose Edit | Insert Translation. If the library has multiple supported languages, choose the language from the displayed list.
- The system will insert a 'dot' (·) followed by a language code and '='. Enter the message immediately following the '='.
The "dot" (·) is a delimiter that separates each translated prompt. It must not be removed from the comment field.
- Repeat these steps for multiple languages.
Tips for Editing Rule Files
- Do not enter blank lines or spaces at the end of lines. To determine if you have entered blank lines or spaces following the last line in the file, place the cursor at the end of the last line in the rule file. Use the "right arrow" key and try to move beyond this position. If the cursor moves right or down, you have inadvertently entered a space or blank line into the file. Use the backspace key to delete the lines or spaces. When you can no longer move the cursor beyond the last character in the comment of the last line in the rule file with the right arrow key, you have resolved the problem. Save the changes.
Be sure to check carefully for blank lines before you save changes to a rule file. Blank lines in rule files can cause system errors in the applications that use them.
- Do not enter extraneous spaces between rule elements.
- Do not use "wildcards" for target elements; wildcards are not supported.
- Ensure that you have entered every rule element, even those that you are not using. Unused elements must be treated as described in the documentation, usually with a BLANK or NULL value.
- The system cannot "nest" logic statements. A line is ANDed or ORed with the following line only.
- Use caution when applying the OR logic operator. For example, the statement "Order status is not equal to 'o' OR order status is not equal to 'a'" will match all orders in the database. In this case, use AND as the logic operator to reject requests on bibliographic records whose orders are not status 'o' or 'a'.