On Sunday morning the Aleph hardware will be changed. Besides the downtime for staff and public access their are other things that may be affected ... continue reading:
1) Aleph and all the public catalogs will be down beginning at 6:00 a.m. for up to five hours; Notices are up on all the public catalogs.
2) After the change, some computers may not be able to connect if the old server information was cached (this is a feature of XP and other operating systems). This will most likely be a problem with public computers that are not shutdown at night.
a) The first thing to try is to reboot the computer
b) If that does not work, try this URL:
http://libprd.oit.umn.edu/F
3) If you have any URLs (links to the catalog) that referenced saturn.oit.umn.edu these will no longer work. Change the address to: umnlib.oit.umn.edu
All,
Since the changes on Tuesday to Your Account a couple of problems have been reported that are not yet resolved.
1) Off campus users coming from behind a firewall may not be able to access the public catalogs at all. This is believed to be a port issue that usually means the user has to request that their local IT staff open port 8991 (one off campus user reported that solving the problem). We know this is not an ideal solution, and are working towards something better. (There are similar issues with Primo that we are working on in parallel.)
2) If you have static links on your web pages back into the catalog (as a search or a link to a particular record), you will definitely want to test these. If they don't work, you probably want to rebuild them following the procedures you used to originally create the links. Those searches with either "find-c" or "find-b" in the string can usually be corrected by this procedure. There is a pattern for fixing these two (find-c/find-b), so drop me a line if you would prefer that over rebuilding the queries. So far we have not found a way to get searches using "find-a" to work.
3) I have noticed that sometimes the catalog times out to the blue PDS - Patron Directory Service menu. I'm still trying to determine when and why this happens so I can prevent it. Luckily this one is more a nuisance.
Happy weekend, Janet
Fixit works for any problem in MNCAT (a.k.a. Aleph). We can also fix our records in RLG's Eureka and OCLC's WorldCat. If the problem is in a different database than those three, or if it is with the U Libraries interface, it should go to someone else. If you're not sure who to send something to, we'll be happy to help you get it directed to the right place.
Stephen
-------------------------------------
Yes, fixit is still in operation, and it should be used for reporting errors in data in MNCAT.
These shouldn't come to autosys. On the other hand, if MNCAT is down or there are problems with
searching, etc., those should come to autosys and should be assigned to LEO.
Chris M
All:
We have major problems with keyword indexes and indexing, and are working on diagnosis and resolution of the problems. Here is some information about the current state of affairs, along with some suggestions for coping.
What's Happening and How Can I Cope?
1. Keyword index entries have not been generated for records created since approximately November 6, nor have additional keyword entries been created for records updated since then. Direct (number) index entries and browse index entries were created for those records through yesterday (11/15); however, these records will not be accessible in small bases. Last night, Ex Libris staff stopped all background indexing jobs, which means that neither browse nor keyword index entries will be created until we restart the jobs because we are confident they will work.
To search for recently created records in the GUI clients:
--Do record ID and standard number searches when you have those numbers available. These searches will retrieve all relevant records.
--Do browse searches if you don't have a standard number. These will retrieve records created through 11/15.
To search for recently created records in the Web OPAC:
--Search in the All Campuses catalog.
--Search using browse or standard number indexes.
N.B. All browse and standard number searches should work for older records, and most keyword searches also will work.
But see point two.
2. A few keyword searches are failing; i.e., you get a count of records retrieved, but they are not displayed in the Web OPAC, and you cannot display them in the GUI clients. Unfortunately, one of the searches that is failing is the one that limits results to serials format titles. For that reason:
--We have disabled the All Campus, Twin Cities, and Duluth journals catalogs.
--We have removed the choice to limit to serials from the dropdown search boxes.
N.B.: You can search for serials using any relevant indexes in all of the other catalogs; but you cannot limit results to records for serials format materials.
We have identified a few other keyword searches that fail. In those cases:
--If you've used multiple keywords in your search, try using only one word.
--If a search using a single keyword fails, use a browse search instead.
We will be adding a link to instructions to this effect to the Web OPAC.
More information will follow as we learn more. Those who want more details may read on.
A Brief History and Next Steps
When we went up on version 17, we soon realized that keyword indexing and creation of counters for logical bases for new and updated records were going very slowly. We filed a problem report with Ex Libris, and received a fix which speeded processing significantly. Subsequently, we made a few other changes in keyword indexing parameters based on advice from Ex Libris. We experienced only minor problems until the latest Aleph service pack was installed on November 6, when the background process that creates the keyword indexes began dying frequently. We have been working with Ex Libris on this problem, but have not yet been able to correct it.
Yesterday afternoon, we received a report that searches in the Duluth journals base were failing. We filed a high priority problem report with Ex Libris, and began our own investigation. By early evening, Jerry Specht (Ex Libris' North American indexing guru) and I had concluded independently that our keyword indexes probably are corrupted. This may or may not be related to the more general problems we've been having with keyword indexing.
Jerry's next step was to send an urgent request for assistance to Israel, so that staff there could begin working on the problem as soon as their day began (about midnight our time). We have not yet received a response from Israel. However, it's clear that resolving the ongoing problems with keyword indexing, especially making certain that the process runs without errors, is critical. There is no point in correcting the existing indexes if the ongoing process aren't working.
My next step was to begin thinking possible paths to recovery should we determine for certain that the keyword indexes are corrupted. There are two obvious possibilities:
--Revert to an uncorrupted backup copy of the keyword indexes, then index records created since that date, plus all updated records still sitting the queue awaiting keyword indexing.
--Regenerate the keyword indexes in background, replace the existing indexes with the indexes created in background, then index all records in the queue created between the time background indexing began and the new indexes were put in place.
Either process is very complicated, and we want to make sure we get it right. We'll provide more details as we learn more and as our plans firm up.
Meanwhile, we appreciate your patience.
Chris
We are planning to convert to Aleph version [corrected dates follow:]
The correct dates are: Friday, August 26 through Sunday, August 28. Version 17 will be available for regular use on Monday, August 29.
During the conversion period: (see continuation)...
--No updates of the Aleph database should occur. Any that do will have to be redone in version 17.
--The version 16 Web OPAC will be available for searching, but Your Account will be disabled.
--Items can be charged and discharged using offline circulation.
--Staff clients can be used to search for and view all data in Aelph.
A schedule for training during the month of August, along with instructions for registering for classes, will be available soon.
It is important to note that the transition from version 16 to version 17 will be much simpler than the transition from version 14
to version 16. All staff who use Aleph will be asked to attend only a single one and a half hour session highlighting new features
in version 17.
Here is more background.
Since we went live on version 16 February 1, LEO staff have been working on three major implementation tasks:
--Aleph version 17: Ex Libris completed the first test conversion from version 16 to version 17 on February 15. Since then,
work on this task has proceeded fairly smoothly.
--Aleph ILL: MnLINK is the development partner with Ex Libris for this module, and Minitex and Crookston will be its first users on our server. All testing has been done with version 17 of Aleph. Because of contractual commitments and a very compressed development schedule, this work has consumed an enormous amount of time and energy. We are close to having a working product, but considerable testing and configuration for production remains to be done.
--Aleph Reporting Center (ARC): Work on this product has proceeded more slowly than we had hoped, though only a few institutions have gotten as far as we have. Testing has been done with version 17 of Aleph. LEO staff hope to begin more thorough testing of canned reports within the next few weeks, with the goal of opening testing to other staff shortly after that.
We have decided to implement version 17 sooner, rather than later, for two main reasons:
--Version 17 is the foundation for production work on Aleph ILL and the ARC.
--With the switch to production on version 17 behind us, LEO will have two, rather than three, major implementation tasks
in progress. We will continue to work on all three until version 17 is in production, but work on Aleph ILL and the ARC
should go more quickly once version 17 is in place.
Chris
Stephen's note from 11/28/04 (housecleaning here! -sg). Read below for how to search in Aleph.
The standard for ISBNs is being extended to 13 digits to enlarge the pool of available ISBN numbers and make them more consistent with other 13-digit commercial numbers such as UPC codes and EAN codes.
The standard for ISBNs is being extended to 13 digits to enlarge the pool of available ISBN numbers and make them more consistent with other 13-digit commercial numbers such as UPC codes and EAN codes. The change does not become mandatory until January of 2007, but a number of publishers have begun issuing materials which bear a 13-digit ISBN, usually in addition to a 10-digit ISBN. The 13-digit numbers begin with the prefix "978," which implicitly is the prefix for the range that includes all existing ISBNs. Once that range is used up, the prefix "979" will come into use. After that point, 10-digit ISBNs will no longer be unique in principle. The final check digit (a number calculated from the preceding numbers to provide a check on accurate data entry) for 13-digit ISBNs will be based on the 12 rather than the 9 preceding digits, so the two ISBNs for the same item will usually differ in both the presence of the 3-digit prefix and in their final check digits.
In addition to publishers, vendors, and retailers, Library of Congress, OCLC, library system developers, and others are all working to accommodate this change. OCLC and LC have decided to record 13-digit ISBNs provisionally in the 024 field (Other Standard Number) with first indicator 3. Aleph in version 14 and 16 will let us record a 13-digit ISBN in the 020 field (ISBN), though it is not able to verify a 13-digit ISBN and will pop up an error message. After consulation with LEO, the guidelines for dealing with 13-digit ISBNs in MNCAT are:
Leave 13-digit ISBNs in 024 3_ fields on incoming records.
Locally enter 13-digit ISBNs in the 020 field in MNCAT.
In version 16, both the 024 3_ field and the 020 fields will be indexed in the ISBN search index, so they should be accessible with a single search. In version 14, two searches may be needed to find a 13-digit ISBN:
Searching in the Web OPAC
The 024 ISBN numbers must be searched using the "024=" index in Command search. Do not use the ISMN menu choice in the Advanced search to search for ISBNs in 024. The ISMN search listed in Advanced search menus is tied to the "WMN=" index, which includes only true ISMN numbers (024 first indicator 2) and not the 13-digit ISBN numbers. The ISBN Advanced menu choice can be used for 13-digit ISBNs entered in 020 fields. When using an Advanced or Command search for standard numbers always end the search term with a truncation symbol ("?") to ensure that any additional characters in the field (e.g., "(pbk.)") do not cause problems.
Searching in Staff Mode
13-digit ISBNs in 024 fields can be searched using the "Other St Identifiers (024)" search on the Browse or Find search menus, both of which use the "024=" index. Numbers entered in 020 fields can be searched using the ISBN Browse or Find search. When using the Find search for standard numbers always end the search term with a truncation symbol ("?") to ensure that any additional characters in the field (e.g., "(pbk.)") do not cause problems.
If you have questions about how to apply this guideline, please let me know.
Stephen
Information on how to view and hear them and links to the webinar recordings are at: http://staff.lib.umn.edu/leo/v16/webinars.phtml
For new staff or those who missed them, or for anyone who just wants to hear soothing voices talking about version 16, recordings are available of the 16-02 MNCAT Staff Side for Public Service Staff and 16-03 MNCAT Staff Side for Collection Development Staff webinars that were presented to coordinate campuses. (A big thank you to Karen Docherty and Minitex for generously sharing their webinar software and expertise!)
You may have to scroll down on the start menu to find Aleph16 (the ITS guy tells me this is the same as Aleph1602). He also said when the entries in that start menu aren't alphabetical you can do a right click and choose to alphabetize. It was too busy at the desk this aft. to do this, but I'll look later and see if I can set it, and then let's hope the setting "sticks". -sg
Authority Control Blog
I've started a blog focusing on authority control questions, broadly defined. In most cases the entries are intended to answer questions that I've been asked. The address is:
http://blog.lib.umn.edu/s-hear/control/
Feel free to send me any comments or questions you'd like to see addressed using either the blog's Comment feature or e-mail. Thank you.
-- Stephen
keywords Aleph MNCAT headings catalog catalogue
Subject: Aleph Tip Sheet for public service staff
The long-promised 'Tip Sheet' for Public Services staff using Aleph staff side is now available as a Word document. It has been posted to the Web site that includes course materials for all of the Aleph classes, http://staff.lib.umn.edu/leo/v16/courselist.phtml (Also bookmarked on Wils Ref Bookmarks page). We have posted it in Word so you can modify it to suit your needs, though if you do so, keep in mind that it uses text boxes which can behave strangely.
Also listed under 16-02 is the 35-page Class Manual, which we did not distribute but which you can read or print as you wish. And for those of you interested in exploring Commmand Searching, the Technical Services staff have two useful documents listed under 16-11: 'Find Command Searching' and 'Browse Comd Searching'
If you find any errors or problems please let us know.
Gary and Lisa