SURVIVOR: calllist.cf
About `calllist.cf` Alerts About Alerts Dependencies Alert Stanza Keywords Examples Persons About Persons Dependencies Person Stanza Keywords Examples Call Lists About Call Lists Dependencies Call List Stanza Keywords Examples Call List Aliases About Call List Aliases Dependencies Call List Alias Stanza Keywords Examples
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.
1. ### Examples 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.
1. ### Examples 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. 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. 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. 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.
1. ### Examples 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.
1. ### Examples 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