UC Berkeley Library Web UC Berkeley Library Web List of Libraries Using the Libraries How to find About the Libraries Help
Recent Changes - Search:

Steering Ctte Links

Other Links

edit SideBar


This page lists known issues with Millennium that have been reported. Please check here for updates, this list will be updated as new issues are reported.

 [Last updated 08/28/14, smoody]

Please note that the known issues below are functionality issues with Millennium, not data cleanup issues. For the to-do list of data cleanup projects, see: (also listed at the link to the left).

If you identify a problem that has not been listed below or on our cleanup list, please submit a ticket to the OskiCat Help Desk.

Known OskiCat Issues with date reported:

  • RSS feed in patron record: 11/12/13 - Issue: Via the Chrome browser the RSS feed in a patron record doesn't work correctly. If you use the Chrome browser, you need to add the extension at
  • Truncated keyword search terms sometimes return zero results: 3/21/13 - Issue: A keyword search for a term that includes the wildcard (*) truncation sometimes returns zero results. An example of this is film*. This is not a bug in OskiCat. If the truncated term matches too many keywords, it is an error and no results are returned.
  • Error in emailing full records: 7/12/12 - Issue: When you mail a full display journal record part of each holdings statement is truncated.
  • Linking title performs title search: 2/3/12 - Issue: When a user clicks on a linking title (for example, 780/785 or "Continued By"/"Continues") OskiCat performs a title search rather than link to the actual correct record. When the linking title is a very common or generic title such as Annual report, clicking on the link results in a list of thousands of records. For example: view then click on the linking field labeled Continued By. Suggested workaround: if the field contains more than just a title, copy the entire contents of the field and paste it into a keyword search.
  • Web Management Reports Firefox issue: 11/16/11 - Issue: Firefox won't display fund information in Web Management Reports, although data can be saved and viewed in excel. In Firefox html code displays. IE does not have this problem.
  • Staff view in OskiCat shows records it should not via public display: 10/21/11 - Issue: 1) OskiCat Public View--when viewed in Staff Mode--does not give the same display as the OPAC. For example: You're working in Staff Mode. You see a record that is suppressed from the OPAC. Click on the Public View button, and you see the record, whereas in the real OPAC, no such record is retrieved. Example:
  • Keyword search can not contain a hypen 8/4/11 - Issue: Performing a keyword search on a phrase that contains a hyphen will fail, because hyphens are not indexed in the keyword index. The same search as a title will succeed. Example title: Traite's 51-54. Solution: Search as title, or omit hyphen for keyword search.
  • Location dump with Firefox 3x 4/25/11 - Issue: In FireFox 3x selecting and saving a retrieved record results in a location dump at the top of the screen. This is caused by a javascript conflict with MobileCat. This problem only occurs with Firefox 3x, we recommend using Internet Explorer, or some other browser for selecting and saving records.
  • Proxy error when saving lists 2/25/11 - Issue: OskiCat users are experiencing a problem when saving items from a search to MyLists while not logged in. The new problem occurs only when a user who is not logged in does a search, clicks on "save all", then on "save to my lists". At this point, a "Proxy Error" screen appears. To avoid the proxy error:
  1. Do a search.
  2. Select individual records by checking their boxes and clicking on "save selected records", or click on "save all" to get all the records on current page.
  3. Click on "view saved" button near top of screen.
  4. Click on "save to my lists".
  5. You should see the login page, offering CalNet and Patron/PIN options.
  • Changing a hold pickup location on a busy record doesn't give an error 09/10/10 - Issue: If a patron is trying to change a pickup location or freeze a hold on a record which is in use by the system, instead of being given an error message, the screen just reloads with no indication of a problem.
  • Item status lacking spaces 09/08/10 (r2009b) - Issue: All statuses display without a space between them, making the display difficult to read. For example, items that are checked out and then billed display without a space between date due and billed information, e.g. "DUE 11-19-07BILLED".
  • Vernacular keyword search title browse error 09/07/10 (r2009b) - Issue: Doing a keyword search using vernacular characters in Chinese, Greek, or Russian sometimes display numeric codes rather than the appropriate characters in the title browse list.
  • Problems With Viewing Pre-Composed Characters 08/03/10 - Issue: There can be a problem with viewing pre-composed characters (latin with diacritics) in OskiCat. The problem with viewing these records in OskiCat is caused by browser settings. If the browser is not configured correctly you'll see boxes instead of diacritics. When we first went live, we sent around instructions on how to set up one's browser to use Arial Unicode-MS for correct display. Apparently when the browser is upgraded (which has happened since that time), these settings are lost. IE on the public PCs may need to be properly configured. Firefox seems to be more forgiving.
Steps to correct the problem: 1. Configure the browser so that it ignores coded font types in webpages, and 2. Set the browser's default font value to Arial Unicode-MS.
If a browser's settings are not correct, in a romanized record, where there are diacritics, in OskiCat you'll see boxes instead of the latin value and diacritic. See record number b15194631 as an example.
  • Character Limit in Search Boxes 07/07/10 - Issue: Searches are limited to only 75 characters in the search boxes on browse search results lists and item-level pages. The search boxes on browse search results lists and item-level pages are part of an III token that is added automatically to the page. The code in this token can't be edited, and there are no configuration options to change the character limit settings.
  • Request Link Display 05/20/10 - Issue: The "Request" link displays for each title on browse search results lists if any item/volume for that title can be requested. This may be misleading because the full holdings/location information is not displayed for each item at the browse list level. So there may be multiple volumes/copies of an item available at other locations, but a patron won't discover this unless they click on the title link in the browse display to view the detailed item-level record. They may assume based on the browse display that they have to request the item. With our current version of the WebPac, we don't have the option to not display this "Request" link at the browse list level - we can configure its appearance and any associated graphics (like the current yellow arrow) via a wwwoption, but if we choose not to configure that wwwwoption, the system will still supply a text link.
  • OskiCat Spell Checker 01/08/10 - Issue: OskiCat Spell Checker isn't very intelligent. For example, a search for "McKenzie" will not also search for "Mackenzie". It was noted that Google will find both with one search. Answer: The spellchecker is imperfect. It's using a standard third party list of terms that we can't modify. Changing it to manage things like personal names would be a wonderful enhancement, and it would probably take someone like Google to pull it off. At this point we can't expand how it works. However, we can keep our eyes out in case in the future we have some enhancement option that would allow us to add terms or use a broader dictionary. In any case, it would be pretty tricky, because once one branches out into names, it gets darn hard for a machine to guess how something should be spelled or what one might mean. On the other hand, this sort of fuzzy searching gums up search retrievals when doing exact term/phrase searching. One might *not* want to retrieve results for both MacKenzie & McKenzie. Furthermore, this could be seen as an authority issue: authority records coupled with consistent authority control work would sort this problem out with regards to author or subject searching.
  • Searching by Call Number in OskiCat 9/09 - Issue: Why do I retrieve multiple hits when searching for a call number?. Answer: This aspect of OskiCat will not change. OskiCat can only index call numbers from one of two different locations: the item record or the bibliographic (MARC) record. If the call number is indexed from the bibliographic record, the system only reads the first instance of the call number, ignoring any other call numbers in the record. This would retrieve one result for a call number, and works in catalogs where there is only one call number for each item. If the call number is indexed in the item record, the system reads each call number in each item record, and retrieves as many results as there are item records with that call number. Because the UCB Library has multiple copies of items with different call numbers across the collection, and because the system will only read one call number in a bibliographic record, the ILS Implementation Team made the decision to index the call number from the item record. Unfortunately this impacts searching for serial call numbers, or large sets with the same call number. Having the call number in each item record also plays into collection usage statistics by call number, aka SCAT Table statistics found in Web Management Reports, so that we can track the usage of serials by call number. No fix... user education needed.
  • Including colon in keyword searching yields no results - 9/13/09 - Example: a title search on: "groundswell: constructing the" reveals the item immediately ( However, a keyword search on "groundswell: constructing the" reveals no hits. Similarly, an "advanced keyword search" on "title" (which is a keyword search on the title index only) yields no hits. Reported to Innovative on 9/29/09 who responded that colons and other punctuation are not indexed and that this should be forwarded to their Help Desk to determine if punctuation can be normalized out of search strings. 10/09/2009 - Phil Youngholm informs us that the colon cannot be readily normalized out of KW searches as it is used to delineate specific parameters (e.g. title: war of the worlds). Being referred to WAG to determine how best to educate patrons about this issue. Systems may add temporary message to opening OskiCat screen in interim.
  • Searches with and without diacritics - 08/15/14 - There is an asymmetry in how Mill. treats characters with diacritics in searches.
You can search a plain character and get results for a character with diacritic, e.g.:
'koln' retrieves 'Köln'
'tragodien' retrieves 'Tragödien'
...but you can't search a character with diacritic and retrieve the plain equivalent:
'töklas' will not retrieve 'Toklas'
'öakland' will not retrieve 'Oakland'
--and that's with either {u00F6} or ALT-0246 for 'ö'.
Best practice would be to search with plain characters, or if you get negative results with a search including diacritics, search again
without diacritics.

Known Millennium Issues with date reported

  • NRLF item barcode/new patron barcodes overlap (10/3/12) - Issue: Campus Cal1 cards are now being issued that have barcode patterns that match existing NRLF item barcodes that begin with A followed by seven numbers. This means a search on one of these barcodes will yield a list of two records: the item and the patron. It also means that in circ desk mode at checkout, circ staff will be presented with this same list, and will need to select the correct line to continue (ie, when wanding the patron barcode, chose the patron record, when wanding the book barcode, chose the book title). Choosing the incorrect line will do nothing. Moving to two separate indexes for barcodes is not a good solution as it would require circ staff to indicate which index to search every time they wand a barcode for checkout, checkin, etc.
  • Millennium slowness (ongoing) - Issue: Millennium is sometimes very slow or freezes. Sometimes this is due to system load caused by the actions of other users. At other times it is related to the function you are trying to do. When possible, try to do non-time sensitive tasks (create lists) and system intensive tasks (moving items within a big set, any item work on a big set, etc.) outside of the busiest hours (ie, before 11am or after 4pm) both to make your process go faster and to avoid slowing down the system for others.
  • Transferring items from one holdings to another may "flip" set/analytic 09/30/10 (r2009b) - Issue: When you use the Transfer command to move item records from one holdings to another AND some are all of the item records are linked to analytics, the program moves the primary link of the item record to the analytic. This happens regardless of if the transfer is between holdings on the same bib record or different bib records.
  • Transferring holds from one bib to another doesn't always preserve order of holds 09/10/10 (r2009b) - Issue: When holds are transferred from one bib record to another the order of the holds should be preserved. The problem is if the order of holds had been explicitly rearranged by someone with the "Change Priority" authorization, that is not preserved and the holds transfer in date order. Note: This should be of minimal or no impact here as we are not using "Change Priority" except possibly very rarely.
  • Incorrect frequency display 09/09/10 (r2009b) - Issue: The 'n Weekdays' and 'p 10 per year' frequencies don't display on the Summary tab correctly. Both display as 'Monthly'.
  • Problem Retrieving Patron Records 08/03/10 - Issue: In Millennium circ module, when a patron barcode is wanded (or typed), if there is an exact match with the barcode of one patron and a partial match with the barcode of another patron, MillCirc will retrieve both patron records. Staff will need to choose which record to use for the checkout. For example, patron barcode 999000010 brings up a choice between two (test) patron records: one for Visiting Scholar/Postdoc with the intended 999000010 barcode (an exact match), and another for a Stanford Faculty member with barcode 99900001014 (matches first 9 of 11 digits).According to III: "When you search an index, the index is searched for matches to the search criteria. If multiple records match the search string, then Millennium will display all records which match the string. This is not something that is configurable, so you will need to alert your staff to this behavior." We are working on a possible solution.
  • Attaching New Item After Using the Create Multiple Item Option 06/16/10 - Issue: There is a minor bug when creating item records using the "Create Multiple Item" option. When adding an additional item record after creating a series of items, the copy record command should not be used on one of these newly created items. If it is, the program will recreate however many new items one has just created in the multiple item module. In other words, if 100 new items records are created, another 100 new item records will be created when one copies just one of the newly created records. Although these are easily deleted, the best approach is to not use the "Copy Record" edit after creating new item records (using the multiple item creation module.) Only use the "Attach a New Item Record" option, followed with chosing the "Single Item" option.
  • Title Index Indexing Rules 03/25/10 - Issue: Title indexing rules stop indexing when they encounter " / " (space slash space). For Example:
$aProceedings / Symposium on Nonlinear Estimation Theory and its Applications.
The title index will only indexing for the first word in the 245 field, so can only be found as "Proceedings"; "Symposium on Nonlinear Estimation Theory and its Applications" is ignored. Since this behavior is hard-coded into the indexing rule, there are no changes that can be made that would change this behavior. This same coding applies to the keyword indexing rule. These should be cleaned up as encountered, or identified via create lists and turned over to DCU for clean-up. Clean-up will require that the title corrected, or an added entry is created; a current and full OCLC record will ususally do the trick.
  • Searching by non-LC subject in OskiCat 09/09 - Issue: Subject keyword search does not retrieve subjects cataloged as non-LC (ie, 690). Answer: Our subject phrase index only contains LC subject headings. Any non-LC subject heading is keyword indexed only. Unfortunately, if a subject heading is *not* indexed in the subject phrase index, it will not be accessable with a subject keyword search. Instead, the "note" keyword search must be used. To "fix" this problem, one of two things can happen: 1) Index any subject heading, and not just LC subject headings, into the subject string index. This will allow for access not only by the subject index, but also by subject keyword index searching. 2) Change the label in OskiCat from "note" to "other" keyword index, in conjunction with user education. Currently, these options are being reviewed by OskiCat design staff.
  • Title Index Problem: 6/17/09 - Indexing chapter titles (when we have a formatted Table of Contents note in the bibligraphic record) in the title index is desirable, but there is a known issue with how Millennium "nests" entries in the retrieval list in the Millennium client, such that a matching title can be nested under an apparently unrelated chapter title in the same results set. In each case, expanding the line with more than one entry will display the apparently unrelated nested items (in the client, click the "expand all" button above the search results on the right, in the OPAC click on the line whose number shows more than one entry is nested). In addition, in the Millennium client the "title" display in the results list is a raw dump of the table of contents, not the specific piece of the table of contents that was retrieved by the index search.
Example screenshot of this problem from the Millennium client: ClientExample. NOTE that r2009b 1.1 improved results in the OPAC - it no longer displays like this previous example shows: OPACExample
  • Initial articles - searching in Millennium: 6/12/09 - NOTE: This problem is only in the Millennium client. In the OPAC title searches function correctly when the initial article is removed. Millennium is set up to automatically ignore the following English initial articles: "the", "a", and "an". This presents a problem when searching for a title in a foreign language where the first word is the same as one of these three initial articles. In this case, the word must be repeated - so to search for this French title in the client: you have to enter the title search "the the au harem".
It is beyond belief that the client works this way, but you can read about it yourself here: We had to ask III several times to be sure we have no options to alter this unfortunate behavior. Another good reason to always search by at least three access points if it really matters if you find a match if we have the title already!
  • Record In Use Problem: 6/24/09 - If a patron record is up on the screen at one location, that patron record can not be accessed to check out books (etc) in other locations. For this reason patron records and all other record types must be closed immediately after the transaction is complete. III does not consider this an issue - it's a basic element of how their system is designed,but it does cause problems if staff are not careful to always close the record immediately. This problem applies to other record types also - if any record type is open by someone who has the ability to edit that record, it is "busy" and can not be edited by others or accessed by the system. For example, if an item record is open for edit on someone's desktop, that item can not be accessed by the circulation system to check it out to the patron who brought it to the desk.


  • Email subject line from OskiCat unable to handle diacritics 09/08/10 (r2009b)(RESOLVED 11/23/12 by upgrade to r2011) - Issue: When emailing exported information from OskiCat, if you use diacritics in the subject line they display as 'garbage' characters.
  • Subject phrase search for English term limited to Chinese displays titles in vernacular on title browse. 09/07/10 (r2009b)(RESOLVED 11/23/12 by upgrade to r2011) - Issue: Entering an English search term on the opening OskiCat screen for a subject search and limiting results to Chinese produces a title browse list in Chinese characters instead of their romanized versions.
  • Request not working for some NRLF items 10/12/10 (r2009b) (RESOLVED 7/11/11 by III patch) - Issue: Request is denying patrons the ability to page from NRLF in situations where some items have volume fields and some do not. Selecting volumes in NRLF for paging should be allowed, even if volumes on campus are available (and thus, not requestable).
  • NRLF barcodes not displaying in Staff OskiCat summary display 09/17/10 (r2009b) (RESOLVED 5/24/11 by III patch) - Issue: Staff logged into MyOskicat should be able to see NRLF barcodes in the item summary display. Since the upgrade barcodes can only be seen by clicking into each individual item record.
  • Request doesn't work 01/25/11 (RESOLVED 2/8/11 by III patch) - Issue: Single sign on after hitting "Request" does not work. Loi from III reports that the request function is improperly generating a URL with encoded spaces instead of using pluses. Loi placed an urgent call to the III programming team to fix this. The workaround is for a patron to click on a record's permanent link, and place a request from the resulting page.
  • My Lists content disappears 01/30/11 (first reported 01/18/11, resolved 1/20/11 and 2/4/11 by restarting Webpac) - Issue: Some library patrons have lost their My Lists content, and reported that their List content has disappeared.
  • Naming Lists does not always work 01/30/11 (first reported 01/18/11 resolved 1/20/11 and 2/4/11 by restarting Webpac) - Issue: Some library patrons report that when they name a List, OskiCat retorts that the List name already exists, when in fact it doesn't.
  • Keyword searches with search terms in quotes fail if boolean operators included 10/4/10 (r2009b) (RESOLVED 1/6/11 by upgrade to r2009b 1.2) - Issue: Performing a keyword search against search terms surrounded by quotes that include a boolean operator such as "and" are failing in some cases. Compare a search for: "Phase equilibria, phase diagrams" (which works) with a search for "Phase equilibria, phase diagrams and phase transformations" (which does not work).
  • Limit by location not always correct: 8/7/09 (RESOLVED 9/14/09) - The ability to do a pre- or post-search limit by location in the OPAC relies on the location being correct in the bib record, and the bib record only holds location for this purpose (it never displays in the OPAC). The item record is the "true home" of location information (and to a lesser extent, the holdings record), but location in the bib must be correct for a pre- or post-search limit by location to retrieve accurate results. III is in the process of setting up a job that will maintain the location in the bib record automatically, so that it is always kept in synch with the location in the item records on a daily basis. Once this is running changes to an item record's location will allow for accurate limits by location in the OPAC. Until that time new or changed item records may not respond correctly to pre-search limits.
  • KW search defaults to "Other" for failed searches 7/18/09 - example: Title begins with Search: Dwelling Construction under 2008 building code; No results in title browse screen; Change the drop-down from "Title" to "Keyword(s)" and click search; No Results. OskiCat defaults to Advanced Keyword Search page with the search terms in the search box. Run the search again; OskiCat defaults to Title Browse Screen with nothing on it, and the drop-down has changed to the "other" index. This index appears randomly. Phil Youngholm identified possible source of problem 9/17, working with Innovative Help Desk to resolve in OskiCat.
  • Request button in OskiCat when copies are available on campus: 7/29/09 or earlier - RESOLVED Dec. 2009 - The Request button in OskiCat allows a patron to place a hold on checked out items or page items from NRLF. Ideally the Request button in OskiCat should only be displayed when all on-campus copies are checked out. Or if an item is at NRLF, the patron should be able to request whether the copy is available or checked out. Unfortunately the configuration to allow title level requests (so patron can receive the first copy returned) and to allow request of NRLF items regardless of status, also allows patron request when one or more items are available (not checked out) on campus. In addition, the checked out copy is not always recalled nor the available copy paged, so the patron's request doesn't necessarily get fulfilled in a timely way. The patron's hold also prevents renewal of checked-out copies in both client and My OskiCat and the system will attempt to fill the hold with the next holdable copy that is checked in or checked out. We are testing various configurations in the training server to see if we can improve this situation.
  • Advanced Keyword Search results duplicated 09/03/10 (r2009b) - Issue: Advanced Keyword search results screen is duplicating results between the "most relevant" and "highly relevant" categories. A blank record is being displayed at the end. NOTE: III expects to apply the fix for this issue early Monday 9/13 RESOLVED 9/13/10
  • Can't get to last page of results 09/03/10 (r2009b) - Issue: Advanced keyword subject searches with two or more pages of retrievals don't allow viewing of the final page of records on the list, or when the page loads, it says "record not available". NOTE: III expects to apply the fix for this issue early Monday 9/13 RESOLVED 9/13/10
  • Vernacular in title browse list 09/03/10 (r2009b) - Issue: Searching an English language term like "Forestry" in the Advanced Keyword Subject search and limiting results to Chinese gives a title browse list where the titles are only in vernacular (ie Chinese characters). Clicking on the title takes you to the record where you see both the romanized and vernacular forms of the title, but the title browse should show the romanized form and does not. NOTE: III expects to apply the fix for this issue early Monday 9/13 but there is a similar problem listed below that happens from a subject phrase search ("subject begins" from the opening screen) that we don't have a fix estimate for yet. RESOLVED 9/13/10
  • Keyword searching with a semicolon (;) leads to an error when trying to access the full bibliographic record from a browse. 09/07/10 (r2009b) - Issue: Results from a keyword search containing a semicolon are not viewable. The record is reported as being unavailable at that location.
  • Keyword indexing not indexing new records 09/27/10 (r2009b) - Issue: Keyword indexing appears not to be working on any newly cataloged or recataloged bib records. These records can be retrieved via a title or subject search but not by simple or advanced keyword searches. Reported to III as a high priority problem. Resolved 10/1/10
  • Create Lists busying Patron records: 1/26/10 - This problem occurs if you run a Create Lists in the Circulation Module of Millennium. If you open the review file and click on a patron record for editing and then close it, the system will keep the record in use until you exit all the way out of the client. To avoid this problem refrain from opening the record in the Circulation Module but do so in another module such as Cataloging. The solution Innovative gave was to upgrade to Release 2009A.
  • Volumes sort is out of order: 7/1/09 - For unknown reasons, the volume order of item records was rearranged when the item records were loaded to the Millennium production server. This was unexpected, because the items loaded properly in the training server. Currently, the sort of volume number is left to right, so volumes sort like this: v.1, v.10, v.2, etc. The sort for item records with dates sort as straight alphas, like this: Apr 1865, August 1865, Feb 1865, etc. This was reported to Innovative as a severe problem and they are currently working on a fix. Since we don't know what that fix will be, our advice is to not spend a lot of time resorting volumes now. Only resort if there is a public service access problem. This is a high priority fix and should be resolved soon.
  • Refworks/Endnote citation export not functioning 09/21/10 (r2009b) - Issue: OskiCat is no longer able to output a usable record for import into Refworks if you chose to output to screen. These emergency workarounds are suggested: chose to output to local disc or email the record to yourself, then cut and paste into Refworks; or use Zotero as another option.
  • Abililty to access another patron's saved list 09/07/2010 (r2009b) - Issue: There is a way a patron can view the contents of another patron's saved list (without being able to see which patron that list is associated with). Resolved 10/18/10
  • "Forgot your PIN" button missing 10/1910 (r2009b?) - Issue: The MyOskiCat login page requires name, patron id#, and pin. A "forgot your PIN" button used to be present allowing patrons to reset their PIN, but we are no longer able to make this button appear. Workaround: for now patrons have to reset their PIN numbers via the Privileges Desk. Resolved 10/25/10
  • Order record location not blocking request 6/20/11 - Issue: Order records are currently requestable in OskiCat, so that patrons may place holds on them and be alerted when the item is actually received. Currently it is not possible to deny request of order records based on location due to a Millennium bug, so orders created for web resources (location web) are requestable even though a physical item to satisfy the request will never be received. This has been reported to Millennium, but not yet fixed. Links are now being put into uncataloged e-resources, so maybe this solves part of the problem. Resolved Oct. 2011
  • Items for serials and sets incorrectly appearing on opening page of OPAC display - 10/20/09 - Reported to III 10/21/09 - Issue: Some serial and MVM records incorrectly show the full list of items on the opening page of the OPAC display in addition to showing them via the View volumes link. III has identified this as a bug which will be fixed with the new release of Millennium, scheduled to be installed in mid-2010.
Here are some examples: The first shows how the display SHOULD appear, and the second illustrates the problem: No additional item records display Item records display below Holdings records
Update 10/8/10- Upgrading to r2009b improved this problem slightly in that now the suppression has no impact- an item can be suppressed or unsuppressed without affecting this behavior. However, the problem of any item not linked to an existing holdings record causing the bad display behavior is still happening. This is very common for anything with a "WEB" item for online full text content.
UPDATE 10/18/11 - This behavior now only occurs in genuine problem situations: where an *unsuppressed* item is not linked to any holdings record. This means it is now rarely encountered.
UPDATE 4/12/12 - This behavior also occurs when there is an unsuppressed item linked to a suppressed holdings record.
  • Melvyl doesn't always show up to date information for UCB items/holdings (fall 2010 on) - Issue: Two problems (one a Melvyl restriction and one a bug on the Millennium side) mean that records with lots of items and/or holdings do not always have changes in Millennium reflected in classic Melvyl, despite the fact that we are sending records to Melvyl weekly.Resolved by Melvyl going off line June 2011, and the OCLC reclamation July-Sept 2011.
  • Create lists - export not possible if list not owned by user 09/08/10 (r2009b) Issue: Only users with function authorization #186 or the owner of a list are allowed to export content from an owned review file. Expected behavior is that restrictions apply only to modifying or deleting contents of the owned review file. Resolved with r.2009b 1.4
  • Create lists - export subfields not saved 09/08/10 (r2009b) - Issue: A saved export does not retain in memory the specified delimiters, and the default values are not correct when inputting a new export list as a result. Resolved with r.2009b 1.4
Edit - History - Print - Recent Changes - Search
Copyright (C) The Regents of the University of California. All Rights Reserved.
Page last modified on February 18, 2015, at 12:13 PM
Server manager: contact