Web Magazine for Information Professionals

From the Trenches: Networking (Notworking?) CD-ROMS

Jon Knight on the perils and problems of networking CD ROMs.

Many libraries now make heavy use of CD-ROM titles. Today databases held on CD-ROMs cover practically all subjects and provide a way for a library to acquire a large quantity of regularly updated information. Coupled with the relatively cheap network equipment that is now available, these CD-ROMs should also be able to provide a very useful network resource for an entire library or even campus. However the current crop of CD-ROMs vary enormously in their ease of use in a networked environment. Some CD-ROMs will just "plug and play" whilst others almost seem designed to cause library systems unit staff to tear their hair out.

This article hopes to outline some of the major problems to look out for in networking CD-ROMs, based on experiences in the Pilkington Library at Loughborough University and discussions with fellow systems support staff at other libraries. It will concentrate on DOS based CD-ROM database search engines delivered over Novell NetWare. Rather than name specific examples of bad CD-ROMs, the aim is to outline general problems to watch out for. However, to be a little positive, examples of good products and vendors in specific problem areas will be included. If nothing else they will prove that it is possible for vendors to make good CD-ROM database products that work well in networked library environments and may encourage some of the more errant publishers to fix some of the deficiencies in their products.

It is very difficult to give detailed recipes that will solve all the problems with CD-ROMs that are in use in the networked library community, mainly due to the wide variety of network environments in use and the effect that even small differences in software and hardware can have. This article is intended more to be a guide to what to look out for in CD-ROMs intended to be networked rather than a cookbook of ready made solutions for the CD-ROMs available today. Who knows, maybe even the CD-ROM vendors might read this and then fix some of the more broken pieces of software that are currently on the market!

Our network environment

Before describing some of the common problems that we've come up against in networking our CD-ROMs, its probably worth just describing the network environment in which this experience has been gained. The Pilkington Library has a large number of CD-ROMs in use, of which a large proportion are available over the network (the rest are installed on a single stand alone CD-ROM workstation in the library and patrons have to have a CD-ROM issued to them by the library staff before they can use it). There are three mechanisms in use for mounting networked CD-ROMS:

The SCSI Express and OptiNet devices and software share a single 486 based Novell server running NetWare 3.12. This server also has the hard disc which contains the installed CD-ROM software. The LanCD drives have their own 486 machine running the LanCD server. The majority of the Library's CD-ROM products are on the SCSI Express/OptiNet server; the LanCD server only holds two multi-disc Civil Engineering databases.

The clients for the CD-ROMs vary greatly. In the library, most machines that access them are discless 486 PCs. These machines mount another Novell server to give them some user file store and access to the standard set of non CD-ROM applications. Doing this makes managing the installation of software packages much easier than if every machine had its own hard disc and cuts down on the chances of virus infection as the mounted drives containing software are write protected from the user accounts and the user file store is wiped clean between users.

Many of the networked CD-ROMs are also available for use by any PC on campus, which includes both machines in staff offices with hard discs and discless workstations in Computing Services run PC labs configured in a similar way to the machines in the Library itself. All access to the CD-ROMs from any PC on campus is made via a set of home grown batch scripts and executables that check user authentication against the central UNIX computing resources on campus. These scripts are usually accessed from an option in a Doug Menu list, which means that users are not exposed to the DOS command line.

Software Installation

The first thing that one comes up against with a CD-ROM when it arrives in the Systems Unit of the Library is the need to install the database search software. This usually involves running an installation program supplied either on the CD-ROM or on accompanying floppy discs that makes a copy of the CD-ROM search software on your hard disc and configures it to look in the right place for your CD-ROM database.

The ease with which this is accomplished varies greatly; some packages take a few minutes to install whereas others take several days and a couple of phone calls/email messages to the supplier to sort things out. It is interesting to note that the complexity of software installation appears to have no direct relationship to the functionality of the software once it is installed. A good example of this is the current Guardian Online CD-ROM. This is a very popular CD-ROM with a good user interface and search facilities. However it requires absolutely no installation. The search software is run straight from the CD-ROM itself. This is a godsend in a networked environment and has rapidly become the favourite CD-ROM of the Systems staff!

Other CD-ROMs are not so straight forward. Some installation processes are a nightmare made worse by the fact that the software seems to have no understanding of the network environment (despite the fact that the Library has most likely paid a large sum of money for a network site license). In some cases one can only get so far using the supplied installation program and then its up to the Systems staff to "hack" the CD-ROM into working. The manuals that accompany the software often have a whole A5 page devoted to the installation process. This page usually makes two incorrect assumptions: firstly that the product is being installed on a stand alone machine with a local hard disc and CD-ROM drive and secondly that the installation process always works flawlessly. The first can probably be explained away by the fact that fewer networked licenses are sold than stand alone ones but the second assumption is just a pain, especially when things go wrong in subtle (and often hidden) ways.

Some search engine installation programs require that installation passwords are entered in order to start the installation process. Quite why this is necessary is unclear; if the supplier sends you the CD-ROM that you've subscribed to, one would assume that you will also get the password at the same time. Of course, this isn't always the case as suppliers sometimes forget to include the password which results in much scratching of heads as you unsuccessfully try last month's password and try to get their technical support hotline to tell you what the password is.

One thing to be ready for in a networked CD-ROM environment is when a new search engine is installed and works well on a machine in the library but refuses to run at all on a machine in another department. These problems often turn out to be a result of a lack of free memory. Its worth ensuring that you load any network and other device drivers that you can into the high memory above 640K so that the CD-ROM software has as much memory as possible available to it. This needs pointing out as some CD-ROM products fail to tell you why they refuse to run (or produce the obligatory cryptic error code). It must be said that there have been occasions when even this has not helped us and the CD-ROM has to be consigned to the standalone workstation. With the slow migration of CD-ROM software to Windows this 640K barrier will slowly be removed and hopefully this problem will occur less and less.

Even once the software is installed and working, the installation "fun" may not yet be over. Next month or next quarter a new CD-ROM will arrive with "new and upgraded" search software. Occasionally this new software does fix things that desperately need fixing but more often it seems to either provide nothing new or adds obscure features that most users will never use. Some CD-ROMs will allow you to use the new CD-ROM database with the old software (all of our current Bowker-Saur CD-ROMs do this for example) which is great for both the Systems staff and the librarians. Its good for the Systems staff because it means that the installation of the new CD-ROM is as simple as dismounting the old issue and then remounting the new one, which is just a five minute job. Its good for the librarians because they are the people who produce the user guides and handouts and so they will be the people who have to rewrite them if new features appear or (worse) existing features are changed.

This in turn is good for the CD-ROM vendor as the two groups of people who decide which CD-ROMs to use in the library are happy. In the now competitive CD-ROM market, where there is often more than one product trying to fill a niche in the market, this is something that vendors should be aware of. At least one CD-ROM vendor has lost custom to a competitor partly because the search engine was too difficult to install in our environment.

Writing Files

Some CD-ROM products generate temporary files during the user's search to hold intermediate or cached results. This is often done to speed up access to the relatively slow CD-ROM, which is a reasonable idea if the temporary files are being stored on a fast local hard disc on the client machine. However in an environment such as ours where many of the machines being used to access the CD-ROMs are discless, much of the performance improvement is lost. The better CD-ROMs from a networking perspective either do not generate these files, or allow the systems administrator to specify where these files should be stored during the installation process or by using environment variables at run time.

Other products try to write the temporary files, and sometimes other files such as access logs, to the directory in which the search software is installed. Whilst this may be acceptable on a stand alone machine that does have a local hard disc, this causes lots of problems in our environment where the clients are discless and the CD-ROM software is stored on write protected Novell volumes. To make these products work, the systems administrator is often forced to revert back to "hacking" the product. Either undocumented configuration files generated by the installation process can be tweaked to persuade the software to write any temporary files to a volume that the end user on the discless client machine does have write permission to, or a sneaky trick has to be employed.

One such trick is to map the same drive letter that the user sees as their writable disc space to the software installation volume prior to running the installation program. Then, at runtime, a small script is run to copy the whole of the installation directory across from the software volume (which now appears mapped to its normal drive letter) to the user's writable disc space, execute the CD-ROM search software, and then, when the user exits the search software, delete the copy of the search software from the user's file store. This allows the software to think that it is writing its temporary and internal files to the installation directory.

Whilst this works, it is not an ideal solution for a several reasons. Firstly, copying an entire installation between two volumes on a Novell server (or in our case two different Novell servers as the user file store is on a separate machine for security and reliability reasons) can be very slow. Some CD-ROM products can take up several megabytes of disc storage and all of this has to be copied from the server holding the master copy of the software, to the client and then back to the server holding the user's file store. Secondly, it means that the machine with the user's file store on it can fill up rapidly during peak hours when many people are accessing CD-ROMs. Thirdly, it can cause problems when the CD-ROMs are used outside of the library on machines run by other departments as they may not always provide enough disc space to some of their users to hold all of one of the large CD-ROM installations.

Lastly, it can be tricky to get right unless you know the CD-ROM product well. Some products are "dirty" and drop hidden files all over the volume in which they are installed (even outside of the supposed installation directory). All of these files have to be located and copied as well. Sometimes the names even change between releases (which is a pain in itself as one can find lots of old, dead files hidden on the server taking up disc space). "Dirty" products are something that systems staff should be wary of and its something to definitely watch out for when new CD-ROMs are being evaluated, especially if there is a choice of product for a particular area.

Poor Technical Support

Of course the ideal solution would be for all the CD-ROM vendors to either do away with temporary files (it can be done!) or provide a well documented, easy method of specifying where they are to be placed. As has already been said, the installation documentation for networked CD-ROMs is often quite poor, and sometimes the systems staff need to fall back to the technical support from the vendors. A few vendors have excellent technical support lines (H.W.Wilson springs to mind here) but unfortunately its often the case that the technical support staff seem to know less about the files that their products create than the library systems staff that have to put up with the CD-ROMs do.

This may be attributed in part to some database publishers relying on third party CD-ROM search and retrieval software. Whilst the publisher's support line may know about the contents of the database in some detail and can even help with minor technical problems, in depth technical questions involving networked installations can leave them flumoxed. When faced with a highly uninformative error message (which seems the norm for CD-ROM software) that isn't mentioned at all in the manual, this is not a nice situation for the library systems staff to be stuck in.

Luckily, there is a fairly large, helpful community of library systems staff on the Internet and they are often able to help out fellow sufferers of CD-ROM networking with technical hints and tips, and warnings of CD-ROM software and hardware to beware of. The best technical support we've found is the CDROMLAN mailing list. Some of the more clued up vendors even have real technical support people lurking on the list that jump in with solutions to technical problems involving their software. You can subscribe to this list by sending an email to LISTSERV@IDBSU.IDBSU.EDU with the body of the message reading:

subscribe CDROMLAN Your Name

Conclusions

This article has attempted to highlight some of the common problems that are encountered when trying to install and use networked CD-ROMs. The technical points to consider when evaluating a potential networked CD-ROM are:

Note that this list doesn't even include considerations of how easy the CD-ROM is to use for the end user, how consistant the user interface is with similar products already in use in the library and what the data quality of the contents of the CD-ROM is like. As these are the issues which the end user and librarians are probably most concerned about they are obviously going to be very important in the evaluation of new products. In choosing CD-ROM products for a library it is obvious that technical issues are only one part of a larger equation.

It has to be said that dealing with networked CD-ROMs is something of a black art still in some cases. The potential benefits of allowing access the wide variety valuable databases available from public workstations, often spread across the campus, often means that the networked CD-ROMs are worth the hassle. How much longer this will remain the case is difficult to say; those libraries with good Internet connectivity may well start to be tempted by some of the online versions of the same databases that vendors such as SilverPlatter are now pushing. However, it is probably fairly safe to say that we are not going to see the disappearance of the networked CD-ROM overnight, so hopefully this article will of some help to systems staff contemplating networking existing stand alone CD-ROMs and also to vendors looking to improve their products. See you all on the CDROMLAN mailing list.

Acknowledgements

Many thanks to Simon Tanner and Gary Brewerton, my colleagues in the Pilkington Library for reading and commenting upon a draft of this article.