UUCP + Pager = Automated Warning System
Carlos Francisco Gomez
One year ago, while trying to implement UUCP for the
first time in
my new position as system administrator for a secure
network, I toyed
with the idea of using the modem to call my pager. I
had already begun
writing scripts to monitor my system's overall state,
and liked the
idea of the computer telling me when it had a problem.
Newsgroups at my job did not provide me a solution for
I have found that the implementation is quite simple.
presents a list of benefits, a few caveats, my implementation,
performance data, and conclusions.
1. An automated paging system could be linked to any
script to inform the administrator when there may be
a problem, allowing
him or her the potential to resolve an issue before
users notice it.
2. Existing automated paging system products, expensive
requiring additional hardware, would no longer be necessary.
3. The pager could be used in reverse, to inform the
that everything is okay. In this approach, not receiving
page around a certain time would signal that there might
be a problem.
This would be especially useful for troublesome modems,
be periodically "tested" using this method.
4. The pager could be used to inform the administrator
of the progress
of automated test suites, placing a call when different
the test have been completed. I have already done this
in the case
of a five-hour automated test suite -- I was able to
go home and
have the pager update me as to the progress, telling
me when the suite
5. The pager could be part of a built-in request service,
users requested an action, service, or problem resolution
administrator without ever knowing the administrator's
or needing a phone.
1. UUCP, as implemented, wants to connect to another
A pager service "looks" like a dead machine,
since it does
not begin a UUCP session. Therefore, there is no real
way to guarantee
that the page has been successfully placed.
2. A fully integrated implementation would involve a
binary executable that interacts with the modem to place
This, however, becomes an issue to be solved by OS vendors
XX. Currently, this tool is available only from third-party
3. If not carefully implemented, the pager could break
4. In this implementation, information can be transmitted
in the form of a unique numeric code that stands for
a specific problem.
Requirements for alphanumeric paging services also become
to solutions from third-party sources.
For my implementation, a Sparc 2 (Sun OS 4.1.2) is attached
AT&T 7400B Data Module via /dev/ttyb, which supports
Modem Protocol. According to the Sun Microsystems manual,
implementation "is based on the version distributed
System V Release 3, which in turn is based on Honey-DanBer
also has some elements based from BSD 4.3, as well as
some Sun modifications."
The target pager is a standard Motorola Bravo Express
The paging service has a standard interaction in which
a person telephones
the pager number, waits to hear three beeps, and dials
own number, followed by a "#" sign.
Three UUCP configuration files have to be modified.
Figure 1, Figure 2,
and Figure 3 are excerpts from these files, showing standard
configurations and their "pager equivalents."
Listing 1, uupager,
is the paging script that actually executes a call.
A copy of this
script was placed in the /usr/bin directory.
Observed Performance Data
In order to test the reliability of the system I made
five test entries
in the /etc/uucp/Systems file, as shown in Figure 4.
I wrote a simple loop script that would call these "machines"
in succession, once every two minutes, for a total of
30 calls in
one hour. This script is shown in Listing 2. Table 1 shows the observed
While the performance was far from perfect, I was very
the results. Overall, I was successfull in placing a
page over 50
percent of the time, as shown in the Totals in Table 1.
are many variables beyond my control, the uupager script
this into account and tries multiple times to place
the call. I leave
it to more experienced system administrators to create
and possibly binary solution.
About the Author
Carlos Francisco Gomez is a Sun-based UNIX Systems
in pursuit of a Master's degree in Architecture (Technology,
at UCLA. He can be reached at email@example.com.