LCCN 98-700292 appears to be encoding level blank per OCLC error
listings and a search of LC/MUMS. The encoding level E flag was set
during batchload processing due to an invalid subfield code in field
042. The 040 field appears differently than in LC's file since the
record has an additional 505 field which is not present in LC/MUMS.
That field was most likely present on record #37869003 before the LC/PCC
record came in and overlaid it. Record #37869003 was originally input
back on October 30th while the current record was not created until
January 22nd. Nevertheless, additional data was added and the OCLC
symbols found in the original record were added to the 040 field of the
LC/PCC record you now see online. Changes made to PCC records in OCLC
would not have any impact on the copy of the record in MUMS.

OCLC staff receive listings of all problematic records which are flagged
as encoding level E in batchload processing. The problems are normally
resolved with a couple of weeks and are reported back to LC as
necessary. I have adjusted the 042 field and returned the encoding
level back to blank on this record.

Robert Bremer
Database Specialist
[log in to unmask]


> -----Original Message-----
> From: Ralph Papakhian [SMTP:[log in to unmask]]
> Sent: Monday, March 09, 1998 11:13 AM
> To: Multiple recipients of list PCCLIST
> Subject: Re: ELvl E? -Reply
>
> Hello,
> The LC version of this record is level 7 (not E) and does not
> include the same libraries in the 040 field nor the same error.
> Apparently, an OCLC library has attempted to upgrade this record
> as part of PCC/BIBCO by means of a tape load, and the process has
> failed
> resulting in the error code, Level E.
> It looks like RCE? Rice University? Perhaps someone from RICE
> could correct the record in OCLC.
> But this small problem raises the question of PCC upgrades to
> LC level 7 records. Under regular OCLC guidelines, level 7 records
> can be upgraded to level K or I by any participating library.
> No effort is made to adjust the copy of the record in MUMS.
> Should that same practice apply to PCC/BIBCO records?
> Namely, can we upgrade to full or core level without notifying
> LC?
> --ralph p.
>
>
> Ann Della Porta said
> >
> > Ralph,
> > Since LC has used this record, please report the correction to
> the
> > Music Team. Thanks.
> > Ann
> >
> > >>> Ralph Papakhian <[log in to unmask]> 02/24/98 04:57pm >>>
> > Hi, This seems to be a faulty pcc record. What course of action
> > should be taken? Can I just fix it or is the type of error that
> should be
> > reported to CPSO in order to have the MUMS version redistributed?
> > The delimiter a is missing in line 5, which seems to have cause the
> > ELvl E (E System-identified error in tape-loaded record).
> > Would this kind of record be arriving into OCLC from LC or from
> > RCE?
> > Please advise.
> > --ralph p.
> >
> > .
> >
> > # Type: c ELvl: E Srce: c Audn: Ctrl:
> Lang: lat
> > BLvl: m Form: Comp: mo AccM: hi MRec:
> Ctry: fr
> > Desc: a FMus: a LTxt: n DtSt: s Dates: 1996,
> # # 1
> > 010 98-700292/M # # 2 040 NIC #c COO #d DLC #d RCE # #
> 3
> > 028 22 CMBV 014 #b Editions du Centre de musique baroque de
> > Versailles ## 4 041 1 lat #e latfreeng #h lat #g freeng # # 5
> 042
> > ## pcc; lccopycat # # 6 050 00 M3 #b .D79 1992 ser. 3 #a M2021 #
> >
> >
> > --
> > A. Ralph Papakhian, Indiana University Music Library
> > Bloomington, IN 47405 812/855-2970 [log in to unmask] co-owner:
> > [log in to unmask]
> >
>
>
> --
> A. Ralph Papakhian, Indiana University Music Library
> Bloomington, IN 47405 812/855-2970 [log in to unmask]
> co-owner: [log in to unmask]