BTECH Minutes - 12/7/05

[Judith Weeks <jweeks@library.berkeley.edu>]

Berkeley Technical Services Discussion Group Meeting

Wednesday, December 7, 2005
9:00am to 11:00am
303 Doe

Agenda

1.Announcements

*There is now a link to the Innopac Manual from the Manuals for Staff, UCB Library web page in addition to its link on the BPM site.  This will hopefully make it easier to find.

*Carole M. announced that she wants to offer a series of classes called "Rules and Tools".  The classes will be on cataloging and electronic media. Staff may sign up for any of them they may be interested in.  The classes will be designed to give staff a better understanding of electronic media and the catalog.  She will send out more information on this topic when she is closer to putting the classes together some time early next year.

*April Gilbert from Check-in Division will be leaving the Library for a new position at San Jose State University.  She will be here until the holiday closure.  Best of luck April!

*Technical Services Check-In Unit is keeping check-in boxes in the check-in card for a while even after binding to retain check-in history for their titles.  Current binding practice for Main titles is not to collapse check-in boxes as was done in the past.  This is so that they can refer to the most recent history of when issues were received in order to determine patterns and adjust future transaction dates.  Eventually older boxes do get deleted when the card fills up, but by then they have outlived their usefulness.  Some decentralized branches delete all previous check-in boxes once issues are sent to be bound and while this is ultimately their choice, some people may not realize there are reasons to keep them around.  It really is best practice to leave some boxes even after binding so that you may see some check-in history.  Check-in Division is requesting that for at least the titles that are RLOC=S, all units please leave some “to bind” or “bound” boxes so that the check-in staff will have check-in history to refer to if needed.  When the cards get too full or need general clean up maintenance, then you can delete some of the older boxes that have been bound.

*A reminder to all branch libraries, it is your responsibility to close out and delete your old cancelled, dropped or ceased Innopac records.  It has been noticed that there are a lot of old dead bound up records that are still in Innopac that are not getting deleted.  Technical Services will not delete branch Innopac records.  When you have a cancelled, ceased, or dropped a title it is the owning units responsibility to order any missing issues if needed, bind up all remaining issues once complete, delete the check-in record from Innopac, close the summary holdings statement in Gladis, and delete the CI# field from Gladis.  We have limited space in Innopac so it is important that all units work on maintaining their records in Innopac.  Also remember that if any thing was touched in Innopac you need to wait at least one week before deleting the CI# from Gladis or it will just reload back into the Gladis record.

2. Systems Gladis Update / C. Takaro

BTECH update Dec. 7 2005
Report on the Gladis group of the Library Systems Office for Oct/Nov/early Dec. 2005

* Dave Zuckerman started 11/28 to replace Joe Mitola.

* Innopac problem: Records created on Innopac from 11/7 (date of upgrade to Silver) on are not loading to Gladis. [Problem resolved 12/8 and all missed records loaded to Gladis]
        
NOTE: There was some concern about order records loading after the full cataloging from OCLC had already loaded.  As long as the PO# is on an incoming OCLC record, the Innopac record coming later should not be a problem  it should find the correct Gladis record to load to. However, there could be situations where the Innopac record did not load first (as it usually would), and the incoming OCLC record does not include the PO#. In these cases you may get two records in Gladis for the same item: a fully cataloged record and an order record. Unfortunately we don't really have a way to identify these (although two years from now any that aren't cleaned up will come out on the "old on order" log).  The numbers should be small and public service impact small, but it is something to watch for.  These records would have to be manually merged.

* OCLC problem: Many records missing from the 11/30 file, file for 12/2 not available initially.  Missing records from 11/30 have been loaded but some are still in the reviewqs, despite programming we did to minimize the number of records that went there
* Barcode problem: A bad set of Maps barcodes were ordered that duplicated some piggybacks
that are in use right now. We thought all the duplicates had been destroyed, but a few are cropping up.

* Program to delete old cancelled orders with no payments was run in late November. This program also produces lists of all q-level records, other old on-order records, and old in process records. Paper lists and web versions will be available soon

* New web link to Gladis reserves:  The Learning Systems Group has partnered with the UC Berkeley Library to provide a new service that allows instructors with library course reserve lists to display them as web pages inside of bSpace. The lists have traditionally been part of the legacy Gladis catalog, which uses a non-web technology. Now those same lists can be rendered as friendlier, easier to access web pages within the context of a professor’s course site. The reserve pages provide live, up to date circulation information, so they can be used in lieu of the Gladis catalog for looking up reserves items.

* Gladis and related changes to Bancroft note indicating their temporary location is up and running went into place in mid-October.

* New post-doc title codes were added to our program that loads Payroll records into Gladis to create patron records.

* Changes to allow Ethnic Studies to bill on CARS.

* Changes to NRLF packaging code table.

* Implemented Secure (encrypted) FTP to CARS and Payroll, meaning that now all our data streams that transfer sensitive or restricted data are encrypted.


3. Electronic vs. Print Monograph cataloging Clarification (SCP) etc. - C. McEwan

Carole just wanted to go over the differences in the
electronic records for monographs for SCP records in particular. It is UC
policy to use separate records for print and electronic monographs.
Serials are slightly different, these are often on the same record.
Catalog records that are describing electronic resources will have a
subfield $h [electronic resources] in the 245 (title) field. This is the
key that the catalog record is for an electronic resource not print.

The 856 field contains the URL for the electronic location of the online
book, in subfield $u. Because of UC policy an 856 field is not put into
the print record. Please do not put and 856 in a print record, they must
stay separate. Because of the large numbers of SCP electronic book
records it is important that staff know not to touch the 856 in SCP
records.  The 856 field also will have a subfield $x SCP UCSD in it
when it is an SCP record. 

There is an exception to the two record rule. If the electronic book is
purchased by UCB and is for UCB ONLY and UCB is the only one that has
access to it, we MAY use a single record for both the print and
electronic if we own both. SCP records will always have 2 records (one
for print, one for online).  

If your unit gets a print only book (and there is no online full text
access) and there is Gladis record for the book with 245 $h [electronic
resource], then this record cannot be used for the print version. A new
record needs to be added to Gladis for the print version - so refer this
problem to "monmaint" or "sermaint" email as
appropriate. 

Generally, the presence of an 856 in a monograph record means that there
is full text of that monograph online. However, there may be a print
monograph record with an 856 and URL that is for just the online Table of
Contents (TOC) -the 856 should have a subfield $3 table of contents to
make that clear. You may see these in print records sometime because they
come in the PromptCat file records. Just ignore them.

4. Technical Processing questions / Open Discussion

Chikako discovered a little problem with new serial issues getting
sent for binding after they are checked in instead of being routed to the
owning unit. Some issues were showing up bound in the EAL cataloging
unit. A few other libraries noticed the same thing happening recently,
getting new serial issues PAM bound instead of just unbound with the rest
of the serials check-in and having to remove them from the binding.
Somehow issues were being misrouted after check-in and put in the binding
work flow. Please notify Rebecca Green, manager of the Check-In Unit, so
that she can investigate and resolve the problem. Please supply as much
pertinent information as possible about the material and time frame in
which the problem occurred.