Notes for Loader – FAQ
Where can I find help to get started?
A document to help you set up tables for using the OCLC Loader is posted on the Cataloging Work group home page: http://www.odin.nodak.edu/staff/ug-cataloging.html
Look for Work Group doc - How to load OCLC
tab_loader: If you do not want items created for a holdings library, do you need to fill in an item status in tab_loader_def z30-ITEM-STATUS? A blank item status turns into 00. Is that okay, or should I put a valid code in there?
It is okay to have 00 in the item status because you are saying "0" in column 4 - Do not create items.
tab_loader: how do I create item records? 949
If you chose an option in tab_loader to create an item it will be created with a dummy barcode. If you want the item to be created with a barcode, you need to use 949.
If you have one barcode you would do:
049 UNDA
949 33100012345678
If you have one book in Collection A and another copy in Collection B you would do:
049 UNDA $a UNDB
949 33100024680135 $c UNDA
949 33100086429753 $c UNDB
If you have multiple volumes you would do
049 UNDB
949 33100078945612 $c UNDA
949 33100003216547 $c UNDA
You would need to add volume numbers to tab2 and tab5 in each item. Or may decide it is easier to duplicate once one item is created - then enter only 1 949 tag.
NOTE 1 : to do either of the last two options, i.e. create more than one item for your whole ADM, you need to chose option 2 or 4 in col. 10. If you have chosen "first" and If you already have an item, the message says: 949 field ignored (line $a 331... $c UNDP) ... Bib already has items. If you chose 5 and have order brief bib and don't want a new item, leave out the 949 - it will create a HOL but you need to link your item to the HOL.
NOTE 2 : 949 is the only tag used for barcodes - no more 969 or 979
Overlay
During overlay of bib record that already has an item - If you chose any option in tab_loader other than 2 or 4 and don't enter a 949 tag, no new item will be created.
Check on uniqueness is performed. The OCLC Loader program looks for CSCR-OCLC-Z30-BARCODE in tab_checksum
tab_mapping: I think tables are read top to bottom. So is it correct to place call number fields 090 and 092 above call number fields 050 and 082, indicating a priority to locally assigned numbers over others?
Yes, generally tables read from top to bottom, but do not put the 09Xs above the 050s. Rather, list the tags in order numerically, e.g. 050, 090, 099. Outside of this table, Aleph will look for local fields first. You will more likely have problems because of how you create your record in OCLC. If you say for the OCLC code, records could use 050, 086, 090, and your record has those three fields, but your specific book should use the 086, delete the 090 on the OCLC record, otherwise Aleph will use the 090. Most of the time it seems to work the same as PALS - whatever call number is closest to the 049 is the one it uses.
Tab_mapping: How do I enter local call number fields?
099 should be entered as 997
098 should be entered as 998
856 really has 3 choices
1) leave it out of the table, no new line is added
2) Y means overlay old with new
3) N means don’t overly with new
This puts the 856 in the HOL
If you chose to enter an 856 in the table, the resulting OPAC display will duplicate the URL on the Holdings screen (not the main bib screen). It is my understanding that with ver. 18 implementation of the Holdings screen, the top where the URL displays would be on the first bib screen. In that case if you are adding URLs to print records, you may use the HOL to add the URL. This would assume 2 HOLdings records - a HOL for a web collection and a HOL for your print collection.
Tab_mapping and tab_loader
# should be entered as =
$ should be entered as _
tab_mapping: where should I list the OWN field?
The OWN field should be a new line. The only thing that can be put together is the call number when you expect $a and $b to be used to make the call number. Everything else should be on a separate line.
Tab_mapping and tab_loader. What if my library OCLC codes have special characters?
If you have symbols in your OCLC code, you will need to send in a Remedy ticket to ask for the column headers to be changed to allow you to enter your OCLC code correctly. These could include & $ % * + _ = If you don't have symbols, all your OCLC codes can be entered correctly.
Example: UND%
Start your Remedy ticket with: Loader - OCLC code symbols:
Overlay: My library doesn’t create acquisitions records yet, but may in the future. Is it okay to have the overlay flag set to Y (column 7), even though there are no acquisitions records to overlay?
Overlay applies to any record, an existing full record, a brief bib from Circ, or a brief bib used for an acquisitions order. So, if you want a better OCLC record to overlay an old, poor record, Y will allow that to happen. If there are no records to overlay, Aleph just continues on with its procedures.
Sound recordings: Do I still have to change record’s format?
You will still have to change Record’s Format for sound recordings to SR because Ex Libris doesn't get it that music scores and sound recordings are different.
Holdings LDR default: What if I have multiple volumes?
You will need to manually change from x to v (multi-part monograph) or y (multi-part serial). There is only one default and it is for single monograph.
035 – now how do we enter it?
1. 035 __ $a ocm###
The default format of the 001 OCLC system number has been ocm##### (and some other slight variations). ODIN's records were migrated by creating the 035 with this default form.
With Technical Bulletin 253 < http://www.oclc.org/support/documentation/worldcat/tb/253/default.htm > OCLC has announced that by the end of the year, exported records will contain an 035 in this format:
035## $a (OCoLC)#####
See also: http://www.loc.gov/marc/bibliographic/ecbdnumb.html#mrcb035
Ver. 17 of Aleph's OCLC Loader software generates the 035 in the format: 035## $a (OCoLC)########
YOU MUST HAVE 8 DIGITS!
You will noticed they are the same. OCLC said it contacted vendors last spring and told them of the change and apparently Ex Libris updated their procedures to match. However, since the old records do not match the new record format, overlay will not occur and Aleph will create a new additional BIB record.
It does not appear that a global change of the records 035 format will be made. If you have a BIB record in ODIN with an "035 ocm" and you want to overlay it to get updated information, you will first need to edit the 035 in the existing record to the new correct format.
Example:
change 035__ $a ocm31313041
to 035__ $a (OCoLC)31313041
2. 035 9 $a 00####
You no longer need to add the 035 9 tag. The OCLC Loader will not add 035 9. You do not need to edit or delete the existing 035 9 tags. Just ignore them and Aleph will too.
Cataloger level: what level is set by the OCLC Loader?
The Loader sets the cataloger level at 00
Diacritics – will they be easier with the OCLC Loader?
The Loader manages diacritics much better than manual overlay. In most cases, the records will be added with correct Unicode values. There will be 880 $6 paired fields in the bib record - that is correct. However, the Web still needs to be set up to display CJK.
Batch – what does that really mean?
There are different scenarios associated with this word. We need to be clear which we are talking about.
Batch - load a file/batch of authority records
Batch - PromptCat records come together once a day in a file
Batch- OCLC has a batch processing option to allow export of a group of records
Batch - EDI processing
At this time we are prepared to handle the OCLC Batch option. MnSCU and Ex Libris have tested and found that records will drop (be lost) if you process over 50. ODIN is asking that we do no more than 20. More will be considered later after more testing.
Overlay controls: is there a way to protect local fields?
We are still working on a table that controls overlay of particular fields. What you need to be testing is does the system add/create BIB, Item and HOL records with appropriate item status and material types for the right collection.
Brief bibs: will the overlaid records be the right format?
For those of you creating a brief bib within ACQ or CIRC, it is critical that you use the right format code for "Format"
Book (printed materials)=BK
Continuing resources (Serials)=SE
Computer files=CF
Maps=MP
Music=MU
Sound recordings=SR
Visual materials=VM
Mixed materials=MX
If you have entered BK but are cataloging a serial and the brief bib has LDR values for BK, when you overlay the record with a full record through the OCLC Loader, the name of the LDR will change but the values will remain book. This will cause the format display in the OPAC to be wrong and other problems as well. The blue title line near the top will say the right format so it won't be obvious that it is wrong. It is better to create it correctly or edit before exporting through the OCLC Loader.
Brief bibs: are there any special overlay issues?
You can use the OCLC loader overlay for brief bibs for orders as long as they have an ISBN or 035 OCLC number. Most new orders will have an ISBN. Even if the OCLC bib record has several, all you need is one match and the brief bib will be overlaid by the record coming through the OCLC Loader. If there is no ISBN, edit the brief bib by adding 035 __ $a (OCoLC)######## That will also overlay just fine.
Two issues to keep in mind.
1. If for some reason ODIN indexing is behind, the added 035 may not have been indexed and then the record won't overlay. Since this situation most often occurs with original cataloging, I tend to save to the local file in OCLC, add the 035 to the brief order once I know what it is, and move on to the next record. Once I have 4 or 5 done, then I go to the OCLC local file, highlight the lines I want to export, click "E"export and they all overlay very nicely.
Note: If some other library has just run a global change process that requires indexing hundreds of records, your record will be at the end of the line to index so it will take a while to index.
2. Serials can be a problem. ISSN's get used on a various formats of a title so if you have microfiche and print or print and online with the same ISSN the wrong records will get overlaid. It depends on what I am doing. If I have an existing print, and want to add an online with the same ISSN, I delete the ISSN from the print, bring in the new record, then go back to the print and add the ISSN. Or, I add both ISSN and 035 __ (OCoLC) to a record I DO want to overlay.
The overlay didn’t work. What went wrong?
In your existing record fix the 035 9 to 035 __ $a (OCoLC)######## and save to server (or make sure you have an 035 in that format). Do not try to overlay with the OCLC record you just exported that failed. You need to look it up again in OCLC, copy over any changes, and export again. The OCLC export flag has already been set, so Aleph won't overlay with that again.
If you have a mixed up record, you will have to manually bring in the record to overlay it. Being proactive by searching for ISBN before cataloging, really saves time in the end. Then add the 035 (OCoLC) to the existing record. Then catalog your new record and it should load just fine.
Every now an then I can't explain what went wrong, but I keep finding little tricks to make it better.
Why do I not find my new record?
It is an indexing issue. The best way to get to your record is to mark/highlight the system number - in this case 6212476 and copy; then paste it into the top left box in the cataloging window. All the records will be accessible from there.
LDR: why are there multiple lines in the Catalog Print screen?
We have seen the leader duplicate in just a few records. You can't get at it to delete. The numbers you see indicate the five-character numeric string that indicates the first character position of the first variable control field in a record. You will notice that what started with is what it ended with so I see no problem. You will also notice that the beginning of the leader has 00000 whereas records processed the old way have ^^^^^. The zeroes are the correct format rather than ^. They should be a number representing the number of characters in the entire record (called record directory). OCLC is generating the number and aleph is changing it to 00000. The point here is that Aleph is manipulating the record and for a reason I can't figure out yet it hiccups and creates the partial field. As long as it creates a correct field I am not worrying about it.
Also: Multiple 049 subfields appear to create 2 001 tags when loaded through the OCLC Loader
001: Why is there no 001?
It is really there. If you see your record and there is a number in the blue letters at the top, and your tree at the left shows a number, you have a system number. If you edit the record and save it to the server, the 001 will display.
Can I process Acquisitions information from vendors?
Yes, provided appropriate data is in 98X fields. See file_90 Help.
2009-9-9