The one significant disadvantage is that, since this implementation uses a table to store names and pager numbers, the names entered in this file must be unique.

The Implementation

Our system is a Dell 4066/XE running Interactive UNIX v3.2 and Hayes 9600-baud modems. The uucp implementation is based on AT&T's System V w/HoneyDanBer or BNU uucp. The pager is a standard Motorola Bravo Express numeric pager (Motorola Advisor Alpha pager was also tested for the purpose of receiving a numeric page). The paging service has a standard procedure, whereby the user dials the pager number, waits to hear three beeps, enters the number to be displayed on the pager, and then hangs up.

The implementation requires that you modify two uucp files -- /usr/lib/uucp/Dialers and /usr/lib/uucp/Devices -- and add five new files to your UNIX system. I placed the new files under the /usr/local/bin directory. Figure 1 and Figure 2 are excerpts from the two uucp files, showing standard entries and new additions with detailed explanations for the pager entries.

To understand the overall implementation, it's useful to first take a look at how cu normally operates. By default, cu wants to connect to another system; once the systems are connected, interaction between them can take place. When the interaction is finished, you issue a ~. and a carriage return to terminate the cu session. When you are communicating with a paging service, there is no other computer to connect with, so my implementation only checks for whether the paging service answered the phone or a busy signal was received. I use the modem's result codes and the call cleanup exit status code from the cu session to determine whether the paging service call was successful.

Figure 1, the /usr/lib/uucp/Dialers file, shows the hayespag entry I created for our modem to use with the cu session. The chat script is very similar to the other entries in the file, but there are some significant differences. The modem code S7=10 specifies the number of seconds to wait for a carrier signal from the answering modem. Since the connection is not to a modem, I set this value to 10 seconds; if the rest of the proper responses weren't received within this time, the code exits the chat script. The only other change is at the end of the chat script line where CARRIER is the expected result code. In reality, the only result codes possible here are NO CARRIER or BUSY. If the result code is BUSY, the code tries again. If the result code is NO CARRIER, it sends a BREAK command and exits the cu process, which continues to get the rest of its commands from the numpager script (Listing 1).

A modem result code of BUSY would cause the chat script to exit with a status code of 1. A NO CARRIER result code (which would mean that the paging service had answered the phone) would cause the script to exit with a status code of 0. These codes are what the numpager script looks for to determine the next step in the process. Figure 2, the /usr/lib/uucp/Devices file, shows the hayespag entry I created for our modem to use with the cu session. Specifying a speed setting, as shown on the cu line in the numpager script (Listing 1), causes cu to search /usr/lib/uucp/Devices for an ACU entry with a speed of 2400. This speed must be unique for all ACU references to ensure that the hayespag Dialers entry gets selected. This speed must also be one that the modem will understand.

Listing 1, numpager, is the paging script that actually makes the call. This script verifies that it has two parameters, checks the first one to see if the page is for one of the on-call personnel, and if so, replaces the variable $PAGPERSON with the actual user's name. It then verifies that this person has a valid entry in the PAGER_LIST file. Using the UNIX expr command, the script then does a quick addition of 1 to the error code/call-back number to make sure that the user has entered only numbers. Finally, the script uses cu to place the call and check for a 0 error code return value -- otherwise, the phone number was busy.

Remember that the speed parameter used must be unique to the ACU entries in the /usr/lib/uucp/Devices file, and also must be a speed that the modem can deal with. Using cu in this way eliminates the need for specific entries in the /usr/lib/uucp/Systems file, which is what allows us to use a table-driven solution consisting of names and pager numbers.

Listing 2, syspage, is the front-end script to numpager. syspage asks users who they want to page, allows them to enter the call-back number, and then executes the numpager script.

Listing 3 and Listing 4 are the one-line entries in the files for the on-call personnel handling UNIX problems and PC-related problems. These files have the following permissions:

owner = root, group = adm, mode = -rw-r--r--

Listing 5 is a sample of the pager list table, which consists of names and pager numbers, separated by tabs, with one line per name. The phone number has a "9-" prefix to allow for local access on our phone system, with a two-second delay for dial tone. The "-" is interpreted by the entry in the /usr/lib/uucp/Dialers file. This file has the following permissions:

owner = root, group = adm, mode = -rw-r--r--

Testing

To test the scripts once you've installed them, un-comment the cu line in numpager that includes the -d parameter just before the speed setting. Insert a comment at the next line (the cu line that doesn't have the -d parameter). This will allow you to see the diagnostics as the script runs. When you have completed testing, restore the comment to the first cu line and delete the comment from the second.

There are two other changes that may be necessary:

Conclusion

These scripts have been extremely useful in monitoring system performance and beneficial to our users as a support tool. The performance has been excellent, and I have successfully transmitted 20-40 number sequences through the paging service, primarily for testing purposes. All normal pages of 3 to 10 numbers have gone through without a problem.

Recommended Reading

O'Reilly, Tim, and Grace Todino. Managing UUCP and Usenet. Sebastopol, CA: O'Reilly & Associates, 1992. ISBN 0-937175-93-5.

About the Author

Mark McDonagh is the UNIX Systems Manager with the U.S. District Court, Northern District of New York. Mark has set up, installed, cabled, trained, supported, and written custom software for the UNIX, PC, and network environments for the past 15 years. He can be reached at mark@nynd.uscourts.gov.