Lessons From a Batchload Reclamation Project: Part 2

Uploading our catalog’s export to the tech folks at Serials Solutions was uneventful. Their alert that they could see the data in the records was welcome. Their notation that there were no location holdings in them was easy to rectify: I just had to make sure that the “Export 999 field” check box in the Export Records menu of the Utility Module in Symp0hony Workflows was checked on the next go-around.

At some point however, I checked the boxes above and below it as well. The former exported the junk tags; harmless for most purposes, useful for a few. I didn’t think they were really necessary for either project, but figured better too much information than too little and I checked it.

At some point, I checked a box that was marked “Export Symphony catalog key to MARC tag 001″. Now, if you use Workflows and have checked that box yourself while exporting records, you can probably see where this is going. For everyone else, here’s the situation.

We uploaded the exported files to OCLC. They processed the data as we’d arranged in our paperwork and posted the files to their web page. You click the link, download the file, and read it back to your ILS.

Except our files didn’t reload.

I decided that I needed to take a look at the records themselves and wanted to do so within OCLC Connexion Client. I’d been trained to use Client as a primary cataloging tool by my former boss at NYAM and had trained the cataloging staff here how to use it as well. It felt familiar. In there, I felt that I could troubleshoot matters more effectively than I might otherwise.  But I didn’t want to import a ginormous file into it.

So I explained the situation to the staff at OCLC’s batchload desk and they were happy to break the files up into smaller chunks, each one with a maximum size of 9,000 files (Connexion Client has a maximum of 9,999 records per file and I wanted a buffer.)

I downloaded the new files. I saw everything that we’d sent, and everything that OCLC had done. The OCLC control numbers were indeed in their 035 fields. Our local control number tags were in their own 035 fields.  What I didn’t see anywhere were the Sirsi control tags in 035 fields.

Unfortunately, I didn’t know how important that was at the time. I have since learned that in a properly created export file, Workflows adds its own control number to a new 035 field in each record specifically so that you can match on that number when you re-import the records.

What I did know was that the records refused to load. I tried using the 020 to match on the ISBN number . . . that worked, but it also created a load of duplicated records that did no one any good at all and which were later deleted.

I tried matching on the vendor 001. No go.

I tried matching on the OCLC 035. No joy.

I tried matching on the (non-existent) Sirsi 035 a few times. Nada.

I tried matching on the 245 but that created a similar problem to the attempt to match on the 020: titles matched but duplicated records rather than replacing and updating them. So that didn’t work.

In between all these attempts to use the data I’d exported, OCLC was insisting that I was doing something wrong and Sirsi was telling me that OCLC had wrecked our data.

Finally, I arranged a phone conference with Sirsi’s senior analyst and had him log in remotely to my PC to see what he could see. The punchline was this: you remember that check box that exported the catalog key to the 001? That should not have been checked. Catalog keys cannot be used as matching points on a Bibload report in Workflows.

In other words, I had 129,000 records of garbage.


Sometimes the best thing to hear is that you’ve screwed up. It frees you to trash what you’ve done and start again from the beginning. So I did.

This time, I made sure that the catalog keys were not exported to the 001. I made sure the export files were no more than 9,000 records long. I made sure that each file was checked in Connexion Client before I uploaded it to OCLC’s server. I made sure the file names had the correct syntax.

On top of this, OCLC very graciously re-processed our data for free, owing to the fact that the project was still current and that the result had been a case of garbage-in-garbage-out.

This time when the files came back, they uploaded perfectly and updated our original records without problems. That done, I re-exported another set of records for Serials Solutions and their metadata people will work on that shortly.

So. The takeaway:

1. I don’t care what The Cult of Done Manifesto says, pretending you know what you’re doing is not almost as good as knowing. There is no substitute for hands-on experience. Do as much research as you want, but getting your arm stuck in the machinery and pulling a bloody stump out is an effective lesson all its own.

2. Cataloging and Systems Librarianship are like hiking and swimming: both are useful skills, but hardly interchangeable.  Catalogers don’t do systems work and the systems folks can’t catalog. Luckily there enough of us accidental systems librarians out there that we can get the requisite work completed, if not always as quickly as we’d planned for.

3. Experts are experts in their systems, not each others. Which means that . . .

4. Experts will blame each others systems for what goes wrong.

5. Ask for a favor. You might be surprised, as I was when OCLC told me they would re-run the project at no additional cost. And finally . . .

6. Fixing it makes everything that came before before seem better.

These are things to remember for future projects.

5 Differences Between Technical Services and Systems Librarians

It's the year 2010, classes begin in 3 days, and the school administration apparently still thinks I am a systems librarian. This is, it seems, why our budget request for a real systems librarian has been turned down (again).

I meet this news with equal parts of disgust and apprehension; while I'm well versed in the mundane tasks of managing crises involving students (and, occasionally, faculty) and Office 2007 and even to diagnosing some basic network problems involving printer queues and such, there's no time when I have claimed to be a Systems Librarian and until I'm qualified to do so, I won't. Systems Librarians are a world apart from Tech Services librarians. Literally, a different world of work despite the shared knowledge.

This seems to be beyond the grasp of my library director's bosses. Hell, there are times when even the head of IT here doesn't seem to understand the difference. One of the things about me people notice when I talk about setting up computers is that I have the vocabulary and grasp of concepts that accompany someone who's been using them for over 25 years. The reason is that I have been using these damned metal and plastic boxes for that long. I have IT nerds for friends, I read half a dozen tech publications a week on the side, not to mention knowing and talking to real systems librarians to bounce ideas off of now and then. I don't know . . . maybe it's the word "technical" that confuses people. Maybe they just can't tell the difference between one nerd and another, or maybe they just don't care. I'll bet they can figure out the difference between Reference or Circulation and IT, though.

So I decided to start the new year's posting off with a few major (to my mind) differences between Technical Services and Systems Librarians. One caveat: as you read, please keep in mind that I'm trying to discern real and significant differences between the two branches of work; this list is in no way meant to be definitive or exhaustive.

1. A Systems Librarian deals with databases and PC networking; Tech Services deals with the stuff on the shelves. If there is a single essence that all this boils down to, this one is it. I can think of no better way to put it than this. I deal with stuff–books, journals, and their electronic equivalents. Yes, I deal with electronic databases, too, but my role has more to do with ensuring that they are properly paid for each year and correctly implemented within our catalog rather than tweaking OpenURL scripts, parsing rogue XML schemas or spot-checking programming code.

2. Technical Services and Systems Librarians have different specialized skill sets. A Tech Services Librarian can probably spot a problem within the library network, the ILS, with the electronic catalog, or with a link resolver. We might not be able to tell exactly what's wrong or why, but we surely know that something isn't coming out right. A Systems Librarian has the skills required to crack open any of those items, sift through the guts and diagnose it for you. Then, she can fix it. 

3. Systems Librarians and Technical Services positions require different graduate degrees. All I needed to call myself a Tech Services librarian was an MLS. Well, that and about 8 years of actually working in the field: checking in and binding journals, handling acquisition orders and budgets, cataloging new books, maintaining the catalog, and keeping the electronic resources straight and up to date. To be a Systems Librarian, I'd need another degree, probably in Systems Administration or Computer Engineering, and demonstrated competence in programming and troubleshooting networks and intranets, at least one programming language, a knack for writing scripts, and building databases from the ground up–or at least an ability to work those who do. Then there's installing, maintaining, upgrading and replacing networks and intranets, one hard drive at a time.

4. Systems and Technical Services jobs have different professional languages. Any Tech Services librarian can talk about access points, surrogate records, closed stacks, authority files, MARC records, or depth indexing. Systems librarians can discuss all those bits and also discuss the finer points of Java Scripts, XML source code, ASPs and firewall installation. Not to mention the differences between VRML, SGML, and WebGL, as well as the reasons none of them are actually being used these days.

5. Systems Librarians and Technical Services librarians are not interchangeable. There are many important and useful people who share this limitation: heart surgeons and back surgeons, for example; they're both surgeons, both highly qualified medical doctors, but each has a specialized knowledge and experience that would mystify the other. You also wouldn't want to use a copyright lawyer when you need a criminal defense attorney, or an air conditioning mechanic to fix your car. I could extend the analogy to inanimate objects with superficial similarities (i.e., rectal thermometers and spark plugs) but I think the point stands.

I'll repeat it once more for those who were late to class: the fact that I have a working knowledge about computers and how they work, and how to get them to do what I want does not make me a systems librarian.

Related Posts Plugin for WordPress, Blogger...