Modify group command in MilCat

["Ryan, Ann" <ann dot ryan at aucklandcity dot govt dot nz>]

Hi everyone

We're a new III consortium (eLGAR in Auckland, New Zealand) just about to go
live with Millennium Silver (12 days and counting)

We've come across a problem with the Modify Group command in MilCat.

We're planning on using this to update batches of new item records with call
numbers (items will be created as part of the receiving process in
Acquisitions)

We're finding that about 70% of the time the Modify Group command changes
only the first record in the selected group of items (instead of changing
all of them).

We've checked several times that we're following the correct procedure; and
III have also managed to replicate the problem.

We haven't managed to isolate any pattern or combination of conditions that
always causes the problem -- and III are continuing to work on it --
although they've said that it's always harder to identify the cause of an
intermittent problem.

I was wondering if anyone had had a similar problem with Modify Group? Or,
alternatively, any  pointers to move towards finding a solution?

Thanks

Ann

Ann Ryan
Cataloguing Process Champion
eLGAR Smarter Systems Project
Level 3S Bledisloe Building
Ph 357-6790



-----Original Message-----
From: Aline Soules [mailto:aline dot soules at csueastbay dot edu] 
Sent: Friday, 27 May 2005 11:12
To: innopac at innopacusers dot org
Subject: manipulating the order of fields in a MARC record




  
  


Manipulating
the
Order of Fields in a MARC Bibliographic Record for
Display
Purposes
Until recently, our library has been able to
“re-order” the fields
of a MARC bibliographic record to affect the OPAC display, but
recently, we
discovered that this is not something that the Innovative system
supports,
unless the field is 4XX or higher.  There
are two major areas where we have been doing this (described below) and
I’d
like to talk to another Innovative library that either did this in the
past or
who also does this now in order to find out about possible alternatives.

The first is call number. 
We currently have the following call numbers in the following
fields:

050 – LC call number assigned by LC

086 – government document number (SuDoc)

090 – locally-assigned LC call number

098 – non-LC law call number

099 – locally-assigned access numbers for media
materials,
e.g., VHS 1, VHS 2, etc.  We also place
“Internet” in this field.

We like to retain these numbers, even if we do not
assign
them to a particular item; for example, if a record contains a 050 LC
number
and we assign VHS 1 to the 099 field, we have been “switching”
the
order of the
fields so that the VHS 1 number displays. 
Unfortunately, the next time we go into the record to make a
change,
e.g., to a subject heading, we lose the “switch” and our public
catalog
then
reverts to displaying the LC number.

Another example is that in cases where the item is
non-music, we also switch the 240 and the 245, so that the title
displays at
the top and the uniform title displays lower down.  With
music, we retain the 240, 245
order.  The same reversion takes place if
we open the record to make a change to any part of the record, related
or
otherwise.

<>Part of our issue may well be indexing, but I&#8217;d like to set
up a call for me and my bibliographic control coordinator to talk with
someone
in another library about this.  If
there&#8217;s anyone out there who&#8217;s dealt with this problem,
I&#8217;d really
appreciate a
conference call.  
Thanks.  


Aline

-- 
Aline Soules, Associate University Librarian
California State University, East Bay
25800 Carlos Bee Blvd.
Hayward, CA  94526-2455
tel. 510-885-4596
e-mail:  aline dot soules at csueastbay dot edu



--- StripMime Report -- processed MIME parts ---
text/html (html body -- converted)
---
--
This message was distributed through the Innovative Users Group INNOPAC list
Public replies:  INNOPAC at innopacusers dot org
Update your subscription options:
http://innopacusers.org/mailman/listinfo/innopac

This email is confidential.  If it is not intended for you please do not read, distribute or copy it or any attachments.  Please notify the sender by return email and delete the original message and any attachments. 

Any views expressed in this email may be those of the individual sender and may not necessarily reflect the views of Auckland City Libraries - Tamaki Pataka Korero.


--- StripMime Report -- processed MIME parts ---
multipart/alternative
  text/plain (text body -- kept)
  text/html
---