Newsgroups: bit.listserv.notis-l
Date:         Thu, 13 Aug 1992 10:00:56 CDT
From:         "Anne L. Highsmith (409-845-8111)" <K026AH@TAMVM1.BITNET>
Subject:      Re: GTO 3.0 and new OCLC field 003

On Thu, 13 Aug 1992 10:03:40 ECT Andrew Perry said:
>We have noticed problems with OCLC transfer since the OCLC changes
>in USMARC went into effect recently. Most importantly, the addition
>of fixed field 003 seems to be the culprit.

NOTIS did put out an official communication before the change was imple-
mented, warning sites to adjust lgt300p to delete the 003 field on GTO
transfer.

>Does anyone know
>if this affects the batch loaders as well? (LBC30, etc.) I just
>received a recon tape from OCLC with thousands of records that I
>don't want screwed up during the load.

I don't think the existence of the 003 field will cause problems with
the batch loader, because lbc30 will simply ignore it. You should probably
set up the appropriate table to delete the field, however.

>
>The 003 seems to only contain the header OCoLC which is now
>generated automatically when building the 035 from the input 001
>in both batch and GTO loaders. Any insight as to why OCLC had to
>add the 003? or how quickly NOTIS will deal with it? Is it
>addressed in GTO 3.1?

Actually, I've gotten around to the most important question last.
The addition of field 003 represents a change to the USMARC formats - it
is not OCLC-specific. The MARBI Committee and LC felt that there
needed to be a more standard way to define WHOSE number was in the 001
field when a record was received. Rather than try to stick the NUC
qualifier in the 001 field and thus invalidate millions of existing
records, it was decided that field 003 was added and would contain the
NUC qualifier that corresponded to whose number was in 001. OCLC is
simply complying with the new format requirements.

I think optimal processing for 003 would go like this - when an agency
receives a record, via a batch loader or GTO, it would check to see if
there is a 003 field. If there is, the record receiver should move the
003 field and the 001 field into the 035 field and delete the 003 and
assign their own number in the 001 or its equivalent. Then,
when that receiver sends the record out, they put their own number in
the 001 and generate a 003 based on THEIR NUC code. The 035 which was
created when they received the record will still be there to identify
that it was an OCLC record at one time, and what the number was.

When NOTIS was soliciting suggestions for enhancements to LBC30 last
year, I mentioned that they should build 003 processing into the
program. While they accepted some of my other suggestions, they did not
take that one. They will continue to assign the qualifier in the 035
field based on tables you set up when you run the program. This can be
a problem for record sources like Marcive's GPO, where most of the records
have OCLC numbers, but some are derived in Marcive's own database and
do not have an OCLC number. The LBC30 program will stick all such 001 fields
into an 035 field and call them OCLC numbers, which could cause problems
later for GTO overlay and batch update.

Probably more than you ever wanted to know about 003, but I hope some of
it's useful.

Anne L. Highsmith
NOTIS Coordinator
Texas A&M U.
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU