SURVIVOR: calllist.cf
About calllist.cf
syntax
  • Whitespace is generally ignored, unless otherwise noted.
  • boldface denotes keywords.
  • [brackets] denote optional keywords.
  • Separators (|) denote mutually exclusive keywords.
  • Comments begin with a # symbol, and may appear anywhere. Comments must be terminated with newlines.
     <name> : [a-zA-Z0-9\.+%@_-]+
  

calllist.cf defines Alerts, which define combinations of format and transmit modules to send alert messages, Persons, which define sets of addresses that can be used to notify a given individual (or entity), Call Lists, which are used to notify one or more Persons when an alert is generated, and Call List Aliases, which allow a Call List to be associated with more than one Alert.

Alerts
syntax
     alert via <name> {
         format as <name>
	 transmit with <name>
     }
 

About Alerts

An alert stanza defines the format and transmit modules that are used to format an alert message and then send it out to the intended recipients. The name of the alert stanza is used in the via keyword of a Person or Call List definition.

Dependencies

  • None.

Alert Stanza Keywords

alert via <name> Define a new Alert. The name defined here is used by the via keyword in a Person or Call List definition.
format as <name> Specify the format module to use.
transmit with <name> Specify the transmit module to use.

Examples

  1. An Alert that uses the full format module and mail transmit module.
         alert via mail {
           format as full
           transmit with mail
         }
         

Persons
syntax
     person <name> {
         notify <name> via <name>
	 [...]
	 [notify <name> otherwise]
     }
 

About Persons

Persons define how an individual can be reached. This simplifies Call List definitions by allowing Call Lists to operate over people instead of addresses, meaning addresses don't need to be defined multiple times if a Person is a member of more than one Call List. It also simplifies the definition of two Call Lists for the same group (eg: one for mail and one for mailtopager), since the second list can simply be an alias for the first.

Dependencies

  • The Alert specified by the via keyword must be defined first in an alert stanza.

Person Stanza Keywords

person <name> Define a new Person. The name defined here is used in the notifies keyword of a Call List definition.
notify <name> via <name>

notify <name> otherwise

Define an address for the Person to be reached at. If via is specified, then the address provided is reachable via the Alert named. If otherwise is specified, then the address becomes the default entry, reachable by any Alert invoked by the Call List.

Examples

  1. In this example, the Person janeuser has two addresses, one for the mail Alert, and one for page.
         person janeuser {
           notify janeuser@site.org via mail
           notify 5551212@paging.com via page
         }
         
  2. In this example, the Person joeuser has one specific address, for page, and one default address for any other Alert that might be used to notify him.
         person joeuser {
           notify 5552121@paging.com via page
           notify joeuser@site.org otherwise
         }
         

Call Lists
syntax
     call list <name> {
         notifies {
	     <name>
	     [...]
	 }
	 via <name>
	 [rotates using <name> schedule | broadcasts to all]
     }
 

About Call Lists

A call list stanza specifies who is notified when an alert message is generated and how they are notified (via which Alert). There are three types of Call Lists.

  1. Simple.
    A Simple Call List contains one or more recipients. If more than one recipient is listed, each subsequent alert notification will be passed to the next address on the list. Note this is per alert notification, not per problem. If a problem generates two alert notifications because the problem has not cleared and there is more than one Person defined in the Call List, the two alert notifications will be sent to different Persons.

  2. Broadcast.
    A Broadcast Call List is like a Simple Call List, except that whenever an alert notification is sent via a Broadcast Call List, it is always sent to every member of the list.

  3. Rotating.
    A Rotating Call List is like a Simple Call List with more than one entry, except that the rotation happens at a specified time. Rotation can happen according to any set of daily or weekly intervals specified in the Schedule, beginning when the scheduler is started or HUP'd after the Call List is defined. Subsequently, days or weeks (as appropriate) when no alert notification is transmitted are correctly accounted for.

Regardless of the type of Call List, if notify on clear is in effect (see schedule.cf), the notification of a problem clearing will be sent to whoever received the last alert for that problem, even if the person or persons is no longer a member of the original Call List.

When editing Simple and Rotating Call Lists, it should be noted that Persons are remembered, not positions. If the active Person (the last Person notified for a Simple Call List or the current Person for a Rotating Call List) is moved, he or she will still remain active, and the rotation will continue on from that position. If the active Person is removed entirely, the list will start over from the beginning.

A Person may not be defined twice in the same Call List.

Substitutions may be created to temporarily adjust a Simple or Rotating Call List. See the command line interface documentation for more information.

Dependencies

  • Each member in a Call List must first be defined in a person stanza.
  • Each Person in a Call List must be reachable by the Alert used in the Call List. Thus, if the Call List alerts via mail, then every member of the list must have a notify x via mail or notify x otherwise entry.
  • The Schedule specified for a Rotating Call List must be defined in schedule.cf.

Call List Stanza Keywords

call list <name> Define a new Call List. The name defined here is used in AlertPlan definitions.
notifies Define the list of Persons notified by this Call List. Which Person is notified depends on whether this is a Simple, Broadcast, or Rotating Call List.
via <name> Define the Alert used for notification by this Call List.
rotates using <name> schedule Make this list a Rotating Call List. The Call List will rotate at the times specified by the named schedule, which is defined in schedule.cf. Rotation can happen according to any set of daily or weekly intervals. Rotation begins when the scheduler is started or HUP'd after the Call List is defined. Subsequently, days or weeks (as appropriate) when no alert notification is transmitted are correctly accounted for.
broadcasts to all Make this list a Broadcast Call List. All members specified in the notifies stanza are notified whenever this list is in effect.

Examples

  1. This example of a Simple Call List notifies joeuser via the mail Alert.
         call list example1 {
           notifies {
             joeuser
           }
    
           via mail
         }
         
  2. This example is also a Simple Call List. janeuser will be the recipient of the first alert notification to be generated, joeuser will be the recipient of the second alert notification to be generated, and then janeuser will again be the recipient when a third alert notification is generated. The various alert notifications can be any combination of alert notifications for the same or different problems. Although this Call List rotates, it is still a Simple Call List and should not be confused with a Rotating Call List.
         call list example2 {
           notifies {
             janeuser
             joeuser
           }
    
           via mail
         }
         
  3. In this example, a Broadcast Call List is defined that notifies both joeuser and janeuser simultaneously.
         call list example3 {
           notifies {
             janeuser
    	 joeuser
           }
    
           via mail
           broadcasts to all
         }
         
  4. In the following example of a Rotating Call List, janeuser will receive all alert notifications until the next Monday at 3pm, when joeuser will receive all alert notifications.

    From schedule.cf

         schedule schedex {
           at {
             monday 15:00
           }
         }
         
    From calllist.cf
         call list example4 {
           notifies {
             janeuser
    	 joeuser
           }
    
           via mail
           rotates using schedex schedule
         }
         

Call List Aliases
syntax
     alias <name> via <name> to <name>
 

About Call List Aliases

Call List Aliases allow a Call List to use more than one Alert. This is useful for a Rotating Call List to maintain the same current recipient, or simply to avoid having to maintain the same list in more than one place.

Dependencies

  • A Call List must be defined before it can be aliased.

Call List Alias Stanza Keywords

alias <name> via <name> to <name> Define a new Call List Alias. The name specified by via is the name of the Alert to use in lieu of the Alert defined in the original Call List. The name specified by to is the name of the "new" Call List.

Examples

  1. In this example, the example4 Call List from the previous example is aliased to be notified via the page Alert.
         alias example4 via page to example5
         

Next: schedule.cf


$Date: 2006/11/19 04:22:46 $
$Revision: 0.9 $
keywords
alias
alert via
broadcasts to all
call list
format as
notifies
notify
person
rotates using
transmit with
via