Table of Contents
How to customize error messages in MARC Report
When working on a file of records, it is often desirable to remove or filter out certain cataloging error messages. MARC Report has a number of tools that can help you with this objective.
Here are three different ways that you may use to configure which error messages the program displays:
1. To view only error messages about a certain tag or range of tags, use the Brief Message Filter (under the 'Filters' menu)
2. To cancel any message that appears in the Brief Message panel on the right, right-click on the message and select the option you want: cancel for all sessions, cancel for session, cancel for current record.
3. To disable a cataloging check message start the Cataloging Check editor (Options|Cataloging Checks|Edit) and set the 'Enabled for …' column to 'None'.
The Brief Message filter uses a fairly broad brush. To target an individual message, cancelling may be the quickest method; however, it lacks the precision and permanence of using the Cataloging Check editor.
A more detailed description of each method follows.
1. Brief Message Filter
This filter is also accessible by right-clicking any error message in the 'Brief Messages' list on the top right panel.
The shortcut for setting a brief message filter is <Ctrl><Alt><B>; to clear it, press <Ctrl><Alt><C>
This filter makes it easy to quickly process errors pertaining to a particular tag (or tags). When you set a Brief message filter, you are asked to enter a list of tags. Once this is done, the program will then display only those error messages that begin with the tags in your list. For example, if you enter '260' in the Brief Message filter, only error messages that begin with '260' will be shown in the Brief messages list.
The Brief message filter becomes very powerful because it can be combined with the red arrow in the navigation panel at the bottom of the screen (the red arrow is used to jump ahead to the next record in the file that has an error message). When a Brief message filter is active and you press the red arrow, the program scans through the records in the file and does not stop until it finds one that meets the filter criteria. This makes it possible to very quickly identify and edit all records with a problem in a particular field.
More than one tag can be entered in the Brief message filter; if multiple tags are entered they should be separated by a comma (with no intervening spaces). For instance, we could enter:
to show only those error messages that pertain to a Subject Added Entry. The same objective might be achieved by entering
–as the Brief message filter also understands 'XX' tags.
The sense of a Brief Message Filter can be reversed by entering a '-' (minus sign) in front of the first tag. For example, the filter:
will list all error messages in the record EXCEPT those that pertain to a Subject Added Entry. The minus sign should only be entered once, before the first tag, with no following spaces.
Also, if you are looking for error messages about, for example, dates in the fixed field, instead of entering '008'–which will find all error messages for the 008–you can restrict the filter to just the date elements with:
–as the Brief message filter also understands this notation.
When a Brief message filter is active, an indicator will be displayed in the top status bar. In addition to this indicator, the first error message displayed for each record will be one that says:
Some/All messages (n) removed by filter
where 'n' is the number of messages that have been removed due to the current filter. For this reason, setting a Brief message filter that discards all error messages will not result in a 'Perfection' image.
You can see a list of discarded error messages for a record by right-clicking on any brief message and then selecting the 'Brief message filter' option. A sub-menu containing all filtered messages will display to the right, and if you click on a filtered message the program will select the applicable tag in the MARC record. Notes, however, are not available for these filtered messages.
A Brief message filter can be cleared from the 'Filters' menu at the top of the screen, or by right-clicking on any brief message and then selecting the 'Clear Brief message filter' option. The program will apply the last Brief message filter defined the next time it starts.
2. Cancelling Messages
The Cancelled Messages feature is the easiest way to disable individual cataloging check or validation messages. This feature removes only the specific message(s) that you select.
To cancel a cataloging check message, right-click on the brief message that you want to remove.
The following options pertaining to Cancelled Messages will appear in the right-click menu:
The ‘Current Set’ indicator at the top shows you which Cancelled Message set is currently active; it will be ‘Default’ if you have not used this feature before. The next line tells you what effect the Cancelled Messages are having on the current record: it will display the count of messages cancelled, if any, in the record currently being validated. If any messages were cancelled, you can click on this item to display a list of cancelled messages.
When a message is cancelled using this menu, the program uses the brief message itself to remove all matching error messages from the list. It is a kind of post-processing of the error messages1).
If you select 'Cancel message–for This Session only', the message remains cancelled until you exit Record-by-record or Edit mode; the next time that you open a file (even if it is the same file), the message is automatically re-activated.
If you select 'Cancel message–for All Sessions', the message will be added to the currently active Cancelled Message set. The message will remain cancelled until you manually go into the options and re-activate it.
If you select 'Cancel message–for this Record only', the message will only be cancelled in the current record.
Why would you want to use this last option? Let's say you are working on a file of records, and MARC Report displays one of those 'warning' type of messages (ie. there may be a problem or there may not–you just have to check). If you check it out, and there's no problem, you will not get a Perfection image (and of course, you are using those images to let you know when a record has been completed to your satisfaction). But, on the other hand, you do not want to cancel the message for the rest of the file (or permanently), because the next time it appears there may really be an error. This option addresses this quandary.
Whenever you choose to cancel a message, the current record will be revalidated and the message will be removed from the list.
If you open the Cancelled Message Editor while running MARC Report, any messages that were cancelled 'for This Session only' will be re-activated. (You will be prompted by the program if this situation should arise.)
Cancelled messages are also active–like other options–when running MARC Report in Batch Mode.
Messages referring to Mandatory fields may not be cancelled. The reason for this is that Cancelled Messages do not take into account the Leader Record Type value, which is required when determining when a field or element is Mandatory (which in effect makes the mandatory field concept a crosscheck rather than a validation check). If you want to disable a message about a Mandatory Field, you must use the Mandatory Field Editor in the Program Options.
The Cancelled Message concept was designed to provide a quick and easy way for the average user to turn off a message that they felt they did not want to see anymore. However, there are limitations to using this method, which comes about because of the way in which the Cancelled Messages are implemented.
Say that you have some 500 fields that end in a '>' and the program displays a message like:
500-01: End of field punc. needed
You want to accept the '>' as valid end of field punctuation and so you cancel that message (we don't have any other way for you to specify that at present). But remember what we said above–the program uses the message itself when cancelling, not any cataloging check logic. So cancelling this message will also cancel messages for a 500 field that lacks a period at the end of the field, because the brief message for a 500 that doesn't end in a period is exactly the same as for a 500 that ends in an '>':
500-01: End of field punc. needed
Similarly, if the message changes in a subsequent version, to something like:
500-01: End of field punc. required
then the previously cancelled message becomes obsolete, because the program uses the message itself when cancelling, and the message that was cancelled no longer matches the message being displayed. To get around this limitation, use the next method:
3. Customizing the Cataloging Checks DB
This method is the most precise one available, because it makes it possible to disable/enable specific cataloging checks for different cataloging scenarios (AACR and RDA, AACR Only, RDA Only, and 'None'). It is also the most complex, perhaps.
Click the 'Edit' button on the Cataloging Check page of the program options to open the Cataloging Check editor. This editor opens a table that you can customize (you may first be prompted to creat a new set for customization).
The customization column is labelled 'Enabled for…' and the possible options are:
None: means this message will not be displayed
AACR and RDA: means this 'shared' cataloging check message will appear whether a record follows RDA (040 $e rda) cataloging or AACR cataloging, (040 $e aacr or no 040 $e present); the message will also appear in records that follow neither RDA nor AACR conventions (040 $e is some other code)
AACR Only: means this message will only appear when a record is an AACR record (040 $e aacr or no 040 $e present)
RDA Only: means this message will only appear when a record is an RDA record (040 $e rda)
As always, at any time you may enter the Cataloging Check editor and customize any of the cataloging checks–both new and old–to run in a different manner than in the default set-up, but beware!! If you change RDA Only, AACR Only, or AACR and RDA to anything except 'None', you may get some very strange results. Note down any such changes that you make, so that you can reset the values to their defaults, if necessary, once of you have seen the result of your change.
Complete details on how to use this editor are available by pressing 'Help'.
At TMQ, we use this method, combined with Batch Mode, to test new cataloging checks. Since running MARC Report on a large file (such as the LC Database) is necessary to effectively test a new check, yet will produce an overwhelming number of messages, some method to focus the run on the new code is necessary. Here are the steps we use to do this:
- Go to the cataloging checks options page and click 'Edit'
- Select Default in the dropdown list at the top and click 'Save As'
- Enter a descriptive name, like 'Testing new 260 checks'
- Click the 'Disable All' button
- Sort the brief message column (by clicking the column label twice)
- Scroll through the table, and for each check you want to test, change 'Enabled' to 'Y'
- Click 'Save' when done
- Back on the Cataloging Checks page, uncheck all boxes except the first two: 'Enable Cataloging Checks', and 'Check for Common problems'; the name entered in step #3 will appear in the 'Current Set' box.
- Go to the Validation page in the options and uncheck the 'Enable Validation' box
Now, if you run Batch mode on a large file, only the messages selected above will be listed in the report. Alternately, if you start an Edit Session on a file, the red arrow button should quickly skip through the records, stoppping only at those records selected in step #6 above.
Note: If you have 'Options Profiles' enabled, you can save all of the above as a profile, so that it doesnt replace your default options.
Note: this 'editor' applies only to cataloging check messages; it does not allow you to cancel 'Validation' messages.
If your application requires better performance, prefer this method to cancelling a message. The decisions made in the cataloging check table are applied at a much more lower level than 'cancelled messages', and this should result in better performance on large files. Also, if you are configuring options for others, and/or need your decisions to persist over time, prefer this method to cancelling a message. Even if the message changes in a subsequent version, setting a cataloging check to 'None' here will still remove the message; however, if the cancelled message method is used, the check will need to be cancelled again.