C-Kermit Case Study #22

[ Previous ] [ Next ] [ Index ] [ C-Kermit Home ] [ Kermit Home ]

Article: 12223 of comp.protocols.kermit.misc
From: fdc@watsun.cc.columbia.edu (Frank da Cruz)
Newsgroups: comp.protocols.kermit.misc
Subject: Case Study #23: Modem Scripting Tutorial
Date:Fri Feb 23 20:02:02 EST 2001
Organization: Columbia University

It's been a while since scripting tutorials have been posted here, but with C-Kermit 8.0 nearing release, with all its new scripting features, now seems like a good time to resurrect the practice.

Does your organization have a big modem pool? Of course (like any other big university) ours has has a pool of many hundreds of lines. As you know, phone lines aren't cheap so the annual cost of running a big modem pool is painful. Yet, even in this age of DSL and cable modems, the demand for modems never stops increasing, and therefore so do the complaints about busy signals, and the pressure to increase the capacity, and the counterpressure to contain contain costs. (Eventually some day every room will have an Internet jack and modems will have the same historical status as card punches and Teletypes, but that's another discussion -- for now DSL in the home is often not available, usually has a long wait when it is, and it's expensive).

One consequence of all this is the need to monitor and test the modem pool to make sure it's working at its best -- no broken or poorly-performing lines or servers -- plus the degree to which it is available, i.e. the answer-to-call ratio. There's a script for doing this in the Kermit script library, but it's undergone quite a few refinements in recent months as we reconfigure our modem pool, change telephone service providers, etc, and many of the refinements nicely illustrate new features of C-Kermit 8.0 (and the forthcoming next release of Kermit 95).


The script is given a list of phone numbers and a list of terminal-server names. Each list can have one or more items. Obviously the script also needs to know the details of the calling computer: serial device and/or modem name, speed, etc. The script prompts for password (because it's a bad idea to store passwords in files) and runs in a loop, performing the following actions:

  1. Calls the next phone number from the list (which is circular). If the call is not answered or the line is busy, the appropriate error is logged and this step is repeated.

  2. Gets the terminal server prompt, gives any necessary configuration commands to the terminal server, and then requests a Telnet connection to a host computer. If this fails, an error is logged and the script hangs up and goes back to step 1. If the terminal server announces its name and the line number for the call, these are captured.

  3. Logs in to the host computer.

  4. Starts a Kermit server on the host, uploads a 100K precompressed file and downloads the same file.

  5. Says BYE to the Kermit server, closing the connection.

  6. Gets statistics about the call from the modem, including block-error and r