How many times are you willing to type the same thing over and over again? If the last time was once too many, it may be time to write a macro!

The Problem

When bringing books from a series into your catalog, there are a number of decisions to make in advance to ensure consistency:

• Do you want a separate record for each volume (“analyzed”) or just one record for the whole series? In some series, volumes may not even have individual titles, so separate records would look strange. If the volumes are sufficiently different though, you may find it useful to provide subject access to each individual volume.
• Should each book get its own call number, or should they be classed together? Some series are most useful grouped together, but to allow for broader discovery on the shelf, you may want to shelve each volume with other books on its specific subject.
• Is the series aspect important enough to be marked as such (“traced”) on each record, or is it just branding by the publisher, like “A Penguin Book”?
• Should the whole series be treated the same way? Or should parts of it (say, the first 100 volumes) be treated differently?

These decisions are recorded in a series authority record. When copy cataloging, you can usually find an authority record for your series with reasonable decisions made and bring that into your catalog. Those fields look something like this:

644 __ f ǂ5 DLC      (fully analyzed)
645 __ t ǂ5 DLC      (traced)
646 __ c ǂ5 DLC      (class together)

The decision was made by Library of Congress, so each line has their symbol DLC.

My library has multiple branches (including YOUNG and LITTLE) and sometimes we make different decisions for a series. When we bring in a new series, we add our symbol to the line that reflects our decision, like:

644 __ f ǂ5 DLC ǂ5 YOUNG ǂ5 LITTLE      (both branches fully analyzed)
645 __ t ǂ5 DLC ǂ5 YOUNG ǂ5 LITTLE      (both branches traced)
646 __ c ǂ5 DLC ǂ5 LITTLE               (LITTLE chose to class together)
646 __ s ǂ5 YOUNG                       (YOUNG chose to class separately)

When a new book from that series comes into the catalog, we check our local copy of the authority record and follow the practice stated there.

It may not seem like a lot of work to type ǂ5 YOUNG three times (or type it once and paste it twice), but one day I finally got tired of it. Also, it seemed like a simple enough problem for my first OCLC Connexion Macro!

Don’t judge; there was an access issue.

Macros with OCLC Connexion

I had written macros to drive Connexion before using AutoHotKey. Most of them just did silly things to normalize the hotkeys in OCLC and Voyager. One beast of a macro (I called him Hugo) was actually generated by another script. His goal was to replace now-broken URLs in records for some of our local e-resources with their new (dissimilar) URLs, based on a list. He did something like this, in a loop:

• Skip to the end of the record
• Scoot up two fields (this is the field to be replaced)
• Skip to the end of the line
• Press backspace 100 times
• Type in the new field value (different per record, but hard-coded into the script)
• Go to the next record (saving current record to local file when prompted)

Hugo was terrifying to watch for a number of reasons:

• He did no error checking, or really any checking of any kind. He just counted on having the records to be edited in a particular order, and the field to be replaced in a particular position. They always were; I had ordered Hugo’s tasks based on that exact file, and the records had been created by my library’s template in the first place (though the master record in OCLC could have been changed since then).
• He required the computer’s focus. Since the macro was a long series of “press this key” commands, changing the focus to another program (or having it stolen by one that wanted my attention) resulted in furious beeping until I managed to interrupt him and put him back on track.
• He didn’t respond to events, like records being fully loaded. He just kept typing his keystrokes with experimentally determined “sleep” commands in between. Had there been a timeout (unlikely but possible on the local file) or other error message, there would have been more furious beeping.

Overall, it wasn’t a bad thing. The work got done quickly and I checked the accuracy before committing. It also gave me context for the power of Connexion Macros when I saw them in OCLC webinars (Basic, Advanced).

The Program (using OML)

This macro adds my branch’s symbol ǂ5 YOUNG to the first instance of each series treatment field (644, 645 and 646). If there is more than one instance of a field, or I just want to change a decision for my branch, some hand-editing may be necessary.

TL;DR: The OML (OCLC Macro Language) source code and a packaged mbk file are available from my Connexion GitHub repository. To customize for your own library, edit the macro text to replace YOUNG with your symbol.

Since arbitrary series authority records do not have a rigid format, more finesse is needed than keystrokes in batch easily allow. Series treatment fields are repeatable and don’t appear in a consistent position. Using OCLC’s macro commands, I was able to extract and modify fields by tag number, and do plenty of error-checking along the way.

This is the first code I’ve written in any flavor of BASIC in over 15 years (OML seems to be OCLC-aware Visual Basic), so I did some head-scratching to remember its syntax (for-next!) and googling to discover its eccentricities. Though the program is brief, I am pleased with it, and I can refer back to it if I forget how to do the following in OCLC macros:

• for-next loops
• case statements
• integer to string conversion
• error handling (the source of my only GOTO)

I did not appreciate the vagueness of the OML compiler’s error reporting. It repeatedly scolded me about a non-specific error on the last line (end sub? looks fine to me!) when the real trouble was a much earlier label statement that was not left-aligned.

Version Control

I caution writers of OCLC macros to be diligent about version control, or at least backups. Connexion’s macro editor is reasonably friendly with its buttons to compile, debug and save, so it is tempting to do all development in that editor and treat the mbk file as the permanent home for the code. That is a dangerous game: not only can the file be wiped out by a hardware failure or a system upgrade, but also by spurious system bugs.

I am still hunting down an as-yet unreproducible bug that truncates the macro code and gives a compile error when running the macro from a User Tool on the Tool Bar. If this happens to you, just edit the macro (Tools -> Macros -> Manage, select the macro and click Edit), paste in the contents of AuthOK.txt, and save the file using the diskette button. Also, let me know, so I can sort out whether this is a problem with how I created an earlier mbk, a local Connexion install glitch (I have seen it when installing other people’s macros locally), a bug to be reported, or a problem I have actually fixed!

If you’re looking for a free online version control system, why not try GitHub? It has the bonus of letting your share your code!

Resources

I found these sites very helpful while composing this macro:

• Better Living Through Macros (Joel Hahn, Niles Public Library District)
• Basics: Use Macros (OCLC Connexion Client Guide)