I really enjoy figuring out how things work, how to make things work, and how to make things work better. It's satisfying to find a way to make someone's job a little easier, or to make a research tool a little easier to use.

Life as a systems librarian can be quite unpredictable. There are many days that turn out completely differently than how I thought it would. I often have to deal with malfunctioning equipment or software, or respond to requests for services that other people need from me to advance or complete their projects. I have major long-term projects, like managing the migration from an old to a new library automation system. I have smaller, but still substantial projects, such as setting up and tweaking a GoPrint pay-for-print networked computer printing system. I have many ongoing routine tasks as well. So when I'm deciding how to spend my time at any given moment, I have a wide variety of tasks to choose from, many of them of high priority.

To be a good systems librarian, you need quite a bit of technical aptitude. You really need to be able to analyze systems and understand how a lot of different things work. You need to be able to see how systems interact with each other, and be able to draw connections between seemingly unrelated events and observations. You have to be able to spot patterns, and to notice when something odd happens that doesn't fit a pattern. Good spatial perception helps with everything from routing cables, to assembling and disassembling equipment, to turning a screwdriver while reaching around to the back side of a computer. Most libraries have a mix of computers, so you might have to keep straight the differences between Windows 95, 98, 98 SE, ME, NT, 2000, XP Home, and XP Pro. You have to be observant, creative, obsessively curious, and be able to devise and conduct experiments.

You also need a great deal of patience, because you constantly have to deal with people who don't have as much technical aptitude as you.

You need good communications skills, as you often have to give instructions and explanations, and discuss complex projects and situations. You need to be able to extract information from people who might not fully understand something they've observed or experienced. You also have to be able to express yourself in writing, as you write things like procedures and memos. It's a great challenge to communicate clearly and concisely through signs, labels, and web pages.

As in any other computer-related field, things change frequently, and there is more to know than any one person could be expected to know. You need to be able to teach yourself new things, very quickly. I used to have to do that several times a year, but lately, it's more like several times a month.

Changes, Trends, and Challenges

It was a good system that worked fairly well. I ran the system, and if I had a problem that I couldn't handle myself, I could call on the system vendor or a contracted hardware maintenance provider. Having direct access to everything, with full system administrator powers, I had a great deal of control over the system, and could do what I needed to do, when I needed to do it.

A few years later, we migrated to the UHCARL system (pronounced U H Carl). UHCARL was the university-wide library automation system, using the Carl system. It ran on a powerful mainframe computer at Hamilton Library at the University of Hawaii at Manoa, the university's main campus. Our terminals plugged into the back of a terminal server, which was a specialized network-connected device that facilitated "telnet" virtual connections to the mainframe. I had full control over the terminal server, which had powerful management tools that let me tightly secure our public-access terminals. It also let me expand the capabilities of the staff terminals, by allowing multiple simultaneous connections to different host systems, so staff could log in to UHCARL, check records in the Geac system during the transition, and check their e-mail and do other online activities.

UHCARL took a lot of the day-to-day system administration tasks out of my hand, although I then had to get our needs met by working closely with the Hamilton Systems Office, a busy bunch of people with their own set of tasks and priorities and the needs of many other libraries to consider. The Carl system had a number of problems, and I was kept very busy investigating and reporting strange malfunctions. The university was a developmental partner with the system vendor, which meant we often worked with not-quite-debugged software. I also spent a lot of time dealing with networking problems, by analyzing symptoms and figuring out who to call.

In the mid-1990's, text terminals were widely forecast to be on the verge of obsolescence. There was a trend in large-scale library automation systems, perhaps more theoretical than real, away from using terminals and toward using proprietary microcomputer programs as the end-user catalog interface. As it turned out, that era in the history of library automation lasted about 20 minutes, as the widespread embracement of the Internet and the World Wide Web made the web browser the preferred interface for online database services.

In 1997, I posted the following web page extolling the virtues of the dumb terminal:

Yeah, I know. You read the library literature, and attend the conferences, and everybody tells you not to waste your money on dumb terminals because they're dead technology. Now I realize that terminals are limited in what they can do, and they don't let you see the pretty pictures. But on the other hand, they're pretty hard to screw up. Someday, my domain will consist of microcomputers connected by special cables to complex devices connected to other complex devices, and when something goes wrong, I will have a dozen possibilities to consider. But for now, I have terminals -- simple input/output devices that sip electricity, costs hundreds instead of thousands of dollars, have no moving parts except for the keyboard, never really "hang", and can't be infected by viruses. They're connected by simple serial cables to a terminal server, which is a device that gives me, as a system administrator, great control, flexibility, and security. A simple and robust setup, with different functions distributed to separate, specialized devices, making troubleshooting and management relatively easy. There is a quote that came to me as a fortune cookie message that goes something to the effect of, "Remember that the jellyfish still enjoys its secure ecological niche." And by the way, in case you're wondering, we use Wyse 60 terminals because there is currently no microcomputer-based program that emulates all the functions of the Wyse 60 that are used by our automation system. The program that comes the closest is not secure enough to use in a library environment. Rev. 7/97

For me, that dreaded someday came in 2000. In the late 1990s, the users of the UHCARL system, spurred by Y2K issues, began to consider whether we should pay to upgrade the system we had, or switch to a different system. It was probably not the best time to go shopping for a new system, as the library automation industry was in transition. Had we gone shopping a year or two earlier, we would have been looking at the most mature versions of the previous generation of mainframe-based systems -- old technology, but refined by many years of customer feedback and debugging. Had we waited a year or two, we would have had a wider selection of new client-server systems to choose from. A wait of a few years could have also changed the way we implemented the system. The process took longer than planned, and we ended up buying the Y2K upgrade to the old system anyway. But by then, we were too far into the process to stop. After careful consideration of our complex and diverse needs, and an exhaustive review of the capabilities of the different systems that were available at the time, we chose the system that best suited our needs, and became a Voyager user in 2000. The system server is based at Hamilton Library.

With a client-server system, much of the work is done by computer programs (called "clients") loaded on the computers used by library staff members. The Voyager online catalog uses a web interface, making it necessary to provide web browsers for library patrons. Our terminals were retired, and were replaced by Windows personal computers (commonly referred to as a "PC"). This almost doubled the number of PCs I was responsible for. Computers are more difficult to take care of -- they are more complicated, have more parts that can fail, use more electricity, are susceptible to computer viruses, and especially with the more recent operating systems, have built-in hacker-attracting networking features that necessitate a long list of cumbersome security measures that make the computers harder to set up, use, and administer.

Further security measures are needed to protect the computers used by library patrons, as the features that make PCs so useful -- versatility and easy configurability -- are liabilities for computers placed in loosely-supervised public areas. Even staff computers are a concern, as a staff member could easily enable file sharing, for purely non-malicious reasons, without implementing the other necessary security precautions.

Because of my skyrocketing workload, management of the public-access computers was turned over to the campus "Help Desk" unit in early 2003. This reduced my workload, but cost me control. I now have to submit requests to the Help Desk, and accept whatever they do, whenever they can do it. This arrangement has costs not only in efficiency, but also in effectiveness: I've had to deal with problems that I was only able to solve after getting my hands on information that was being withheld from me.

The library data network infrastructure comes under the campus network manager. This makes sense, of course, but the network is another system that we're heavily dependent on that I have no direct control over. I keep my fingers crossed that something doesn't flake out at times when the library is open but support services are unavailable.

One ongoing aggravation is the tedious Voyager client installation process. The Voyager system is upgraded several times a year, and every upgrade requires the installation of a new set of Voyager clients on staff PCs. There are also occasional maintenance patches, so that overall, I have to perform a round of manual software installations every few months. The PC security measures make the process even more tedious.

Using a web interface for the public catalog makes remote access a lot easier, because these days, just about anyone with a reasonably modern computer and an online connection can easily access a web site. However, it also makes the catalog a little harder to use, because the nature of web browsers is such that the system designer has less control over the user's experience than he or she would have with a proprietary interface.

The library subscribes to several electronic research databases, that we access via the web. In the past, we accessed some of these products on CD-ROM, and I used to spend a great deal of time dealing with CD-ROM networking at a time when doing that required specialized software and hardware.

Like any complex system, Voyager has a different set of capabilities and limitations than the previous system. On the whole, we now have many more options for customizing the look and function of the system. The UH system libraries made a decision to function a lot more like a unified system than we have in the past, and the non-Manoa libraries now have a much greater say in how the system operates than we did with UHCARL.

Back to the top level page.
Rev. Aug. 19, 2005