[293] in ad-lib

home help back first fref pref prev next nref lref last post

Re: MIT OCLC TABLE SPEC

daemon@ATHENA.MIT.EDU (Eric Celeste)
Wed Apr 5 14:13:13 1995

To: Sarah Mitchell <smitchel@MIT.EDU>
Cc: ad-cat@MIT.EDU
In-Reply-To: Your message of "Wed, 05 Apr 1995 13:52:40 EDT."
             <9504051752.AA11420@lauren.MIT.EDU> 
Date: Wed, 05 Apr 1995 14:12:54 EDT
From: Eric Celeste <efc@MIT.EDU>


Devising separate codes for serials would force us to duplicate virtually
EVERY code just to get a version that moves data to the 866 instead of the
852. In fact, given what we've heard from MR so far, I don't think it will
work. The draft specs he sent us do not give us any opportunity to define,
for a given code, which tag the data should end up in. What value would we
give a serial code to make it's data go into an 866?

I do not gather from MR's response that he really understood the
problem... in other words: We have to be able to put data into 866's, not
just into 852's. We are paying for the custom programming on this table
and it seems like an indicator on the 949 is the cleanest way to go, Geac
should make it do the right thing. 

I propose that 949 with blank indicators be expanded into 852 and 949 with
first indicator 6 be expanded into 866. I also think we have to review the
spec for this job and make sure it says what we need it to say. MR may be
trying to make our needs fit into some other library's previous spec for
something similar instead of just giving us the program _we_ need to get
our work done.

Having said all that, I'm pretty worried about the impact of 866's for
serial holdings altogether. I had a bad night dreaming about them
(yuck!). I'll try to sift these worries into e-mail for you.

 ...Eric


home help back first fref pref prev next nref lref last post