A Class on the Net for Librarians with Little or No Net Experience


"Thanks to the interstate highway system, it is now possible to travel across the country from coast to coast without seeing anything."

-- Charles Kuralt, _On the Road_, 1985

Not all of the telnet roadway is smooth and without potholes. When you logon to a remote machine, you are at its mercy; it may use commands and displays that are very different from your own. To make matters worse, telnet hosts are notorious for not providing needed information to unsuspecting visitors, especially those from disparate systems on the Net.


In order for you to telnet at all, your host system must first provide telnet access. Almost all colleges and universities and fee-based systems on the Internet do; however, the command or route you take to access telnet on your system may not be obvious to you. Check with your system administrator or service provider to be sure that you can open telnet connections.

To get to library catalogs, which are the most frequently visited telnet sites, you'll probably need some help. OPACs can be tricky because no two are exactly alike. It is up to you when connecting to the host computer, to pay special attention to instructions on how to use the host system and how to exit when you are through. Some systems are better than others at providing this information.

Even if you don't know how to run telnet from your system, there are gateways to many library OPACs and other research databases through gopher and the World Wide Web. You can access a collection of library catalogs listed by location at the gopher hostname, libgopher.yale.edu. This collection gives you both direct telnet instructions, as well as hot links. Of course, you can also use the LIBCAT gopher and WWW locations listed in Lesson 17.

NOTE: Your web browser will still need telnet running in the background to make these connections work; contact your sysadmin if you need help in configuring your software.

Once you've successfully connected to a library OPAC, remember to look for online search instructions. There are about a dozen different popular software packages supporting OPACs, and the search structure and commands to interact with the system will differ slightly for each. Look for HELP screens for the OPAC online; the Yale library gopher referenced above (libraries by location) also includes an item labeled "Instructions for different catalog types" that will give you basic search instructions for different software packages (NOTIS, Geac, DRA, etc.). It also includes a handy table of escape sequences for various telnet packages!

NOTE: If you have access to telnet, but not to gopher or the World Wide Web, you can also use the telnet function to connect to public gopher and WWW browsers. To access gopher, telnet to a public gopher server (VT100 emulation is required) at:
ux1.cso.uiuc.edu and login as gopher. I'll give you telnet addresses to public Web sites in Lesson 26.


Telnetting into a remote host is like visiting a hotel for the first time. You may have free access to the lobby, but you will have to register at the front desk before being permitted to enter a room. In addition, if the reservations desk is busy, you may have to wait in line to get served or come back later.

When you telnet into a remote host, be prepared to encounter similar situations. Sometimes the host is busy or rebooting ("maximum number of users"; "connection refused"); sometimes the host machine is down or broken, or the site is experiencing network trouble or a power outage ("timed out" or "host unreachable"); and sometimes the host has changed its name or you have misspelled it ( "unknown host").

These are temporary problems, at best, which you should be able to overcome by rechecking the hostname (and optional port number) and attempting to reconnect at a later time. If you are continually shut out of a site, check with your local service provider or system administrator: while he or she cannot fix any problems at a remote location, some assistance may be offered in the way of suggesting an alternate route to the information you need.

If attempts to open a hostname using its alphabetic name fail, always try the numeric or IP address if you know it: many times "name service" may not be available to you locally and by using the IP address you will circumvent this problem.

Remember: in order to initiate a telnet connection, you must either open the telnet program on your system and then specify the hostname in the box provided (if your system provides a graphic interface) or, if you are working in a command-based system, type the telnet command and the address of the host you wish to access. Once you are connected, most systems will ask you to login. This might mean you'll need an established account, or you may be able to login with your own name or a guest I.D. If the telnet site doesn't provide you with instructions or a menu of options to choose from, check system access instructions for appropriate login names (Hytelnet and Libcat discussed in Lesson 17 are two sources for this information as well as the Yale Libraries Listed-by-Location gopher site referenced earlier in this lesson).


When you do successfully connect to the telnet host, you may be asked to set the terminal emulation, meaning that you will be prompted to tell the remote computer how to display information on your screen so that you can read it. For the most part, all computer hosts on the Internet are connected transparently -- this means no special emulation is needed.

In two circumstances, however, emulation becomes critical:

  1. Telnetting FROM IBM mainframe host
    If you are connecting from an IBM mainframe system, and a remote host requires VT100 emulation (don't worry about how this works, just trust my system administrator on this one!), you will need to make the connection using a different telnet program that supports VT100 connections. On my CMS mainframe system and others like it, this other telnet program is called TNVT100. Thus, in place of the telnet command, we use TNVT100 as the command.

  2. Telnetting TO IBM mainframe host
    The second critical situation occurs when you are connecting from anything other than an IBM mainframe host, and need to telnet to an IBM mainframe host; you will need a version of telnet that supports IBM3270 emulation (again, just trust my system guru!). For example, if you are telnetting from a UNIX system and trying to access the University of South Carolina's online library catalog, USCAN, on mvs.sc.edu, you must use a 3270 version of telnet to make the connection work. If one isn't available on your system, talk to your sysadmin -- shareware versions are probably available on the net for your particular situation.

If the two special circumstances mentioned above don't apply, and you are presented with a list of terminal emulation settings to choose from when attempting a telnet connection, choosing VT100 is usually a safe bet.

Even with careful navigation, you will sometimes find yourself stuck in a telnet session with a screen full of computer "gibberish." If this happens, try to back out and reconnect using another emulation option.


Unfortunately, for a few of us, some remote hosts on telnet have the nasty habit of "hanging up" our computers, i.e., grabbing hold of them and not wanting to let go. Some systems give you the escape character(s) when you first connect; be sure to write these down (depending on your system and the type of connection, they may or may not work). If you have trouble backing out, or disconnecting, even after using whatever instructions are provided by the remote host, try sending escape characters from your own keyboard; the escape sequence will differ depending on the telnet program you are using. Check to see if one of your pull-down menus provides you with an "escape" sequence, or check with your system administrator for help.

If you do not know the appropriate exit instructions for a host, and can't escape, simply close the telnet session, or (if all else fails) reboot your computer! No harm done, really! Whatever you do, don't get discouraged if you run into trouble. Remember what Patrick Crispen says:

"The Internet was built to survive a direct nuclear attack ... it can take ANYTHING you do to it ... You cannot break the Internet ..." If everything falls apart on you, EXIT TELNET AND TRY AGAIN!


In addition to library catalogs, some of the most information-packed telnet sites on the Internet are Freenets.
NOTE: The term "Free-Net" is a registered servicemark of the National Public Telecomputing Network, Inc., NPTN. There are also non-NPTN affiliated Community Networks which function in a similar manner. In this lesson, when I speak of freenets, I'm using the term generically.) Freenets, or community networks, provide access to local or regional government services and documents, library collections, business, consumer, medical, and legal information, and even provide public email access. Freenets are typically accessible via both dialup connections and via telnet; so, in addition to providing you with access to public library catalogs and research databases, and public gopher and WWW browsers, telnet can be used to link to Freenets and sample community bulletin boards around the US and the world.

Freenet services are provided for free (as the name implies); however, a small annual fee may be charged to subscribers from from outside the service area. Freenets are supported by foundations, corporations, small businesses, governments, information providers, and individuals. According to Steve Snow, Project Director of "Charlotte's Web," in Charlotte, N.C., the goal of Freenets is to provide "free access to public information, with a broad base of support from many providers."

Now that you know how to telnet, I've compiled a short list of Freenet sites in this country you might like to visit:

For a listing of Free-Net sites worldwide, go to the Free-Net Home Page, maintained by Peter Scott, at the University of Saskatchewan Libraries, at:


(Since we're already travelling ...)

* "BCK2SKOL" is a free electronic library classroom created by Ellen Chamberlain, Head Librarian, University of South Carolina Beaufort, and Miriam Mitchell, Sr. Systems Analyst, USC Columbia. Additional support is provided by the Division of Libraries & Information Systems, University of South Carolina Columbia.

Your feedback and support for BCK2SKOL are appreciated; please email link updates, suggestions and comments to: eechambe@gwm.sc.edu

Return to BCK2SKOL Index

Go to Next Lesson

Links checked 7 January 1999. See the BCK2SKOL homepage for course update details.
Copyright © 2000, the Board of Trustees of the University of South Carolina.
URL: http://www.sc.edu/bck2skol/fall/lesson18.html