CA2072169A1 - In-band/out-of-band alert delivery system - Google Patents
In-band/out-of-band alert delivery systemInfo
- Publication number
- CA2072169A1 CA2072169A1 CA002072169A CA2072169A CA2072169A1 CA 2072169 A1 CA2072169 A1 CA 2072169A1 CA 002072169 A CA002072169 A CA 002072169A CA 2072169 A CA2072169 A CA 2072169A CA 2072169 A1 CA2072169 A1 CA 2072169A1
- Authority
- CA
- Canada
- Prior art keywords
- alert
- alerts
- manager
- band
- delivered
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/06—Management of faults, events, alarms or notifications
- H04L41/0681—Configuration of triggering conditions
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/30—Monitoring
- G06F11/32—Monitoring with visual or acoustical indication of the functioning of the machine
- G06F11/324—Display of status information
- G06F11/327—Alarm or error message display
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/14—Error detection or correction of the data by redundancy in operation
- G06F11/1402—Saving, restoring, recovering or retrying
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/30—Monitoring
- G06F11/32—Monitoring with visual or acoustical indication of the functioning of the machine
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/34—Signalling channels for network management communication
- H04L41/344—Out-of-band transfers
Abstract
IN-BAND/OUT-OF-BAND ALERT DELIVERY SYSTEM
ABSTRACT OF THE DISCLOSURE
An in-band/out-of-band alert delivery system far a computer system manager includes an alert log which maintains a record of alerts to be delivered and the status of those alerts, an alert manager for making a first attempt to deliver each alert, and a retry manager for making subsequent attempts to deliver alerts as becomes necessary and appropriate. The alert delivery system may also include a bus master interface manager for making in-band alert deliveries and a communications manager for making out-of-band alert deliveries. Telephone numbers are provided to the communications manager by an alert destination list. Out-of-band alert deliveries may be made via a modem, a universal asynchronous receiver transmitter, or the like.
ABSTRACT OF THE DISCLOSURE
An in-band/out-of-band alert delivery system far a computer system manager includes an alert log which maintains a record of alerts to be delivered and the status of those alerts, an alert manager for making a first attempt to deliver each alert, and a retry manager for making subsequent attempts to deliver alerts as becomes necessary and appropriate. The alert delivery system may also include a bus master interface manager for making in-band alert deliveries and a communications manager for making out-of-band alert deliveries. Telephone numbers are provided to the communications manager by an alert destination list. Out-of-band alert deliveries may be made via a modem, a universal asynchronous receiver transmitter, or the like.
Description
0721 ~
IN-B~MD/OUT'OF-BAND ALERr DELIVERY SYSTEM
:
., .
~ .
. ~. , , The present invention r~lates to hardware ~anageability support systems Ln network environments. More particularly, the present invention relates to syst~ms ~hat deliver alerts in ~ local area network, wide area netwark, enterprise network :~ 20 environments, and the like.
~ In its sLmplest form, data ccmmunication takes place ., .
: , ' : .' ~'' ' , . -: . ~ , :. .
., . , : :, ,, . :-~, :i -. , 2072~9 between two devices that are directly cor~cted by some form of point-to-point transmission medium. H~ever, in certain instanKes it is impractical Por two devioes or compor~lts to be directly, point-to-point cor~ected. An example of such an instance is when there are a set of devi~c, each of which may require a link to nEuly of the others at various timfs. This problem has been heretofore addressed by attaching multiple devices to a commum cation network. Each devi oe, or station, is attached to a network node. The set of nodes to which stations attach is the boundary of a oommunication network that is capable of transferring data betweer. pairs of stations.
Ccmmunication networks may be categorized based on the architecture an~ the techniques used to transfer data. Iwo major different types of communication networks are switched networks and broadcast networks. Switched networks involve transfer of data from a souroe to a destination through a series of intermediate nodes that prcvide a switching facility to move the data from node to node. Examples of switched communication networks include circuit switched netw~rks, message s~itched networks, and packet switched networks. Broadcast networks `~ involve no intermediate switching nodes; each statio~ has a transmitter/receiver that allows communication over a common medium, so that a transmlssion fro~ any one station i5 broadcast to and received by all other stations in ~h~ ne~wDrk. Exanples of broadcast communication networks Lnclude packet radio netw~rks, satellite network~, and local ~ .
The present invention is especially designed to cperate in packet-broad~asting net~Drks such as local ar~a networks ; ("L~NS"), wide area networks ('~NS"), enterprise network environments ("en~erprise environm2nts") and the like. As thQse skilled in ~he art should appreciate, the ~erms L~Ns, ~Ns and enterprise environments have c~nstantly ev~lvin~ ~ s. In general, hc~7ever, a L~N is a general-purpose local netw~rk supportLng personal ccmFuters ("PCs"), a W~N i5 a ~eneral-:
., .. . , .. ~ , .. .
20721~9 purpose netw~rk supporting a wide area relative to a LAN
(usually because it passes throu3h a public switch3d telephone network at least in part), and an enterpri~e environment is a general-purpose network supporting mini ccmputers and mainframes. LANs, W~Ns, and enterprise environments can also s ~port any number of other peripherals (e.g., printers), and qulte often carry v~ioe, video, a~d graphics as ~ell as data.
To assist th~se presently familiar with and skilled in the art in understanding what is meant by the various network terms used herein, the term LAN as used herein enocnpasses Novell NetWare, SOO UNIX, Banyan VINES, Microsoft LAN Manager, and the like.
Further, the term enterprise environment as used herein en~cmpasses I~M SN~ Management Services, DEC Enterprise Management Architecture, A~T Uhified Netwoxk ~nagement Architecture, SNMP-Based Management Stations, Hewlett-Pac ~ 's OPENVIEW, and the like.
As will beoome appar~lt from the detailed description of the invention section below, the present inv2ntion may be viewed as an alert delivary system servici~3 a numk~r of system components that supplement oon~entional network components to enhance management functions. m ese oonven~ional network componen~s inclu~e network managemen~ agents and n~tw~r~ manager ~ consoles. Uhderlying both of these compon2nts is a network ; operating system ~"OS"). Ihe 06 is sDfkware, firmware, or -~ 25 hardware that controls the execution of proYes:es in a system.
Servioes provided by an 06 can include rescuroe allocation scheduling, input/output oontYol, and data management. Ihe theory behind an OS is to prcvid~ support in a sin~le spot so that each pro3ram does not need to be concsrne~ with controllLng har~ware. A network m~nagement agent is a part of the OS. ~he network management a~ent is ~he cçntral collection point for a particular server's networ~ management info~mation. Typically, the information is stared in an obj~ct orient2d format for use by "netw~rk manager" sDftwar~ that ru~s on ~he netw~rk such as a - .~
- : , : : :~: : :.: . : ~ -:
2~7216~
~4--remote console or IEM's Netview. A netw~rk manager console, the second component mentioned above, is generally provided as an optional component piece of an OS network management package.
Typically, the network manager console allows one central po mt of monitoring and control for a network admdnistrator's dcmain of interest. From the console the administrator can view and control the objects registered with the netw~rk management agent. Ihe networX manager console represents one type of manager software connected over the internet (i.e., ;` 10 interconnected networks) with the network management agent.
Other network manager software can also make use of the information in the management agent.
` q~o other concepts that should be fully understood to appreciate the present invention are 'lin-~andl' and "out-of-band". The term in-band is used herein to refer to signals sent via network management software residing locally on the server.
In simple terms, in-band refers to use of the wire that cGmes with a networX. The term out-of-band refers to communications ~` that leave the computer system manager (discussed at length in the related ca~e so titled) via an asynchr~ncus port. Although the out-of-~and concept will be discussed in much grea~er detail below, it should be appreciated that asynchroncus transmission is involved, that is, transmi æ ion in which each information character is individually synchronized, usually by the use of start elements ~nd stqp el~ments.
~` Although netw~rk managers have heretofore been able to provide an acceptable level of netwark mana~ement, the c3nstant improve~ents ke mg made in networks betray the fact that many improve~ents can still yet be made. FQr ~ le, it is important that the system software ~r thQ network ~anager be notified about significant or potentially significant events occurring or abcut to ooour in the netw~rk. Alerts pexform such a function. Hcwever, prior art al~rt delivery systems have a number of shortcomings and defects. For exa~ple, prior art :. , ~ - , :
: , ~721~9 ; -5-alert delivery systems are limited as to the number and types of alert receivers, the alert transmission media that can be used, capability for retrying, and effectiveness of the underly mg algorithm, to name just a few.
The present i~vention cwerccmes the shcrtctmin~s and deficiencies of the prior art by prcviding an i~-kand/out-of-band alert delivery sys~em for a co~puter system manager : including an alert log which maintaLns a record of alerts to be delivered and the status of those alerts, an alert manager for making a first attempt to deliver each alert, and a retry manager for naking subsequent attempts to deliver alerts as beccmes nmc.ss~ry and appropriate.
`~ In embodiments of the alert delivery system of the present invention there may be a bus master interfaoe manager for making in-kand alert deliveries and a communications manager for ~ g out-of-band alert deliveries. Telephone numkers may be provid~d : to the communications manager by an alert destination list.
Out-of-ba~d alert deliveries may be made via a mcde~, a : 20 unlversal asynchroncus receiver transmitter, or the like.
: According to the teachings of the present invention, out of-band deliveries may be made to pagers, telepbones and remote console~ via asynchronoas lLnes. The underlying algorithm in em}odiments of the present inNention is designed for success rate, via ~xhaustive retrying, in delivering alerts.
Accordingly, it is an object of ~he pr~sEnt inNention to provide an imprcved alert delivery system for Lncorporation into data ~ cation net~ork environmen~s.
Another object of the present i~vention is to prcvide an ; 30 m-band/out-of-band ale~t delivery system with a p#rsis~ent retrying capability.
Yet another ~bj~ct of ~he present inv2ntion is to provide an in-band/cut-of-band alert delivery ~ystem for a computer system manager that is able to deliver aler~s to many different .. .
V72~9 types of ale~t re~eivers including pagers, telephones and remote consoles.
Still yet another object of the present invention is to provide an in-band/out-of-band alert delivery system for a computer syst~ nanager which operates based upon a very effective "underlying" algorithm.
` Othe~ objects, advantages, and ncvel features of the present invention will kec~me a~parent from the following ~ 10 detailed description of the invention when considered in ; conjunction with ~he aoccmpanying drawi~gs wherein:
FIG. 1 is a block diagram of a compu~er network having an EISA based computer system and a computer system manager koard installed therein;
; 15 FIG. 2 is a block diagram of portions of the EISA system board of FIG. 1 which illustrates information flow to and frcm, as well as withLn, the board;
FIG. 3 is a flow diagram illustrating decisional prooesses in an emt~dlmint of the alert delivery system according to the teachings of the present Lnvention; and FIG. 4 is a flow chart depicting the logic empl3yed in an embodiment of the present inYention.
As discussed in dekail in ~ther of the related cases referenced above, the management system L~ which the alert delivery sys~em discussed hereLn may ke incorparated is in one embodlment a system of ~ re and software c=mponerts that provide enhanoed hardware nanagement capabilities for EIS~-based systems. In this embodiment, the management system is designed to be Lncorporated into LANS, ~NS, enterprise e~vironmen~s, and the like.
In yreater detail, and as also dLYcussed in greater detail :
2~721~9 r ~7~
in other of the related cases referenced abcve, in various embodiments the ~ystem of hardware and sDftware components can include a 32-Bit intelligent Bus Master EISA board and firmware, an OS device driver, a remote asynchronous driver, a rem~ote asynchronous console program, and configuration support. These components are coupled with a network manage~en~ agent and a network manager console, bcth of which are discusscd in the ` description of related art section above, so as ~o provide enhanced h~rdware management capabilities. Because these various components are discuss~i in detail in cther of the related cases referenced abave, they will nok be discussed in detail herein. However, it may ~e noked that the 32-Bit intelli~ent Bus Mas~er EISA board and ~irmware provides the ~ are and f.Lnmware support for alerting conL~olling and monitorLng functions, which functions are discl~sed further below as well as in the related cases. The OS devioe driver, a ccmponent which is n~oes Rry for each supSo t~d operating system, is a mechanism for providing tworway communication between a netw~rk management agent running on the cperating system and the system manager haxdware. The remoke asynchronous driver is a mechanism for en~bl mg access t3 the 32-Bit intelligent Bus M~ster EI5A board m~ntioned abcve through an a ~ onGus connection. Further, the ~ asynchronous driver enables remote console software operation as ciscusse~ in other of the related cases ref ~ abo~e. Ihe rem~te asynchroncus con601e program is a *oftware ~ nt that executes on any PC connected to a ~dem ar asynchronous interfa oe of the ~ystem m~nager. This software inte~ac*s with the 32-Bit intelligent Bus M~ster EISA ~oard by callLng a re~;ident asynchron~Ls driver API that has a pro~oool link with an asynchronous or ~d~m port of the sys~n manager. Ihe API
allows rem~te control (e.g., rebo~tLng), a~ess to stored dat~, and a r~te console f~tionO Ihe xem~e oansole er~lation (te~t mode only) is in~ep~dent o the syst~n and OS allc;wing " , ~ "
: . .: ,: ~ :
2~72~ ~9 significant functionality without the support of the network or operating system. Remote console em~lation is the express subject matter of related U.S. Patent Application Serial No. _ (Att~. Docket No. 09447/0070) incorporated here m.
All out-of-band accesses to the modem or asynchronous interfa oe of the system manager can be made to require s4curity chec~s ~efore aocess is allowed. 'Lhe final co~ponFnt of the management system listed above, configuration support, involves configuring the 32-Bit intelligent Bus Master EISA board into an EISA system using an F~SA configuration utility with corresponding and appropriate files. Default settings for the cards' configurable options can be stored in the host EI5~ nonNolatile memory. The management system may also require runtime configuration, possibly remokely, to set thresholds for alerting temperatures and other specific configuration options discussed further kelow. These coniguration commands can be made available at various points throughout the management systEm.
The system manager d~scriked in the immediately preceding paragraph can perform a n~mber of functi~ns. Fcur of the man~
functions it can perf3rm are alerting, monitoring, remote man2gement, and histories. Altho~gh alerting will be discussed in great detail below, it may be noted at this point that the managemen~ system discussed in general in the various related applications is able to dial a preconfi ~ telephone ~ r and repart important e~ents, that is, to alert. Alerting can be accompli~hed by any of the follow ~ methods: by sending a protocol message cver a swi~ch telephone CQnneCticn or ~hrcugh a direct serial connection, by dialing a phone number associated with a pager, and/or by dialLng a Fhone number associated with a person and leaY m ~ a synthe~i~ed voioe m@ssage. The foregoing list is not exhaustive as will ke disoussel fur~her below.
The second function ~n~ioned above, mLnitorLng, is the ability of the system t~ m~nitor system ocmponents and parameters. SLmply, this means that if a ccmpcnent experiences .
:: . .. .
~, ' ' ''- '~. ;,: ` . ', , ' ' :
2~721~9 g a failure, or exhibits ~haracteristics that indicate that it might have a failure, portions of the management system can detect this and report it to a system software entity that can, in turn, report. the information to a netw~rk adm1nistrator so that corrective action can be taken. Three examples of a multitude of system co~ponents and parameters that can be mo m tored by the n~r~gement system include system power, internal temFerature, and memory refresh and parity. In all three of these examples alerts or portions of the alerting svstem may be involved. For example, if the system detects a drop in system power ~i.e., below some predefined threshold), it may report the event as an alert. Likewise, if the temperature rises above a predetermined threshold, the system may issue an alert. Still further, if the system dQtcts the aksence of memory refresh signals or a memory parity error, it may issue an alert. In general, associated with the various system objects within ~he system may be a capability t~ provide generic thresholding and alerting. That is, if some counter or value within a system o~ject exceeds a threshold, the system can automatically send an alert either locally or throu~h one or koth of its serial ports.
e remote manage~ent function refers to the ~bility to provide remoke m~nagement of a ~ r. As previcusly discuss2d, alertin~ is a function that ~ay be provided remotely.
~tior~lly, ~e manag~me3it sys~n can, in sc~ne ~i~s, re~ze a small list of tones over its modem connection.
These tones may be used to issue c~s. ~c~ nple, ~en the mar~gement system i~;sues an alert over a model using v~ioe synthesis, a tal~htone a~ may l:~e used to "a~wle~ge" the alert.
Based upon the foregoir~, it shalld be readily a ~ arent to those skilled Ln the art that the m~lagement system discussed in this an~ the various related cases h3s an alert delivery system, ; which alert d~livery system is nck only i~pQrtant in~epen~ently, 2~721~9 but which system is also importallt because its capabilities and operations managem~nt permeate and influence various other components throughout the system. With that in mind, the alert system may ~ow be disc~E~3d in detail.
Referring initially to FIG. 1, an extended industry standard ~ itecture ("EISA") basei computer network 10 is shown therein. The computer netw~rk 10 includes an EISA server 12 and an EISA board/~us 13. Installed on the EI5~ system board 13 are a plurality of cards including a system manager 22, an EISA netw~rk interfa oe adapker 24, and an intellige~t disk array c~ntroller device 26. Also running on the EI~ server 12 is a network o~eratLng system 14, preferably one whic~ mcludes a network managemen~ agent 15. Two-way communication between the system manager 22 and the network management agent 15 is provided by a syst~m m~nager device driver 16. In a similar manner, a network interfa oe devioe driver 18 interconnec~s the network ~anagement agent 14 and the EI5A network interfa oe adapter 24, and an intelligent disk array controller devioe driver 20 interoonnec~s the netwark operatLng s~stem 14 and the intelligent disk array controller device 26. Also shown in FIG.
1 are three terminals con~ected to the overall netwcrk 10.
Terminal 30 is connected to the EI5A network interfa oe adapker 24 via EIS~ bus 28. Terminal or ~etwark m~nager oonsol~ 34 is connected to the ~ manager 22 via an asynoh mnous (cut-of-band) line 40. FLnally, terminal o~ netw~rk manager console 36 is ccnnectei to the network operating system 14 via inter-network communicatiQn (inrband) lLne 42. The ~e~wark manager oonsole 34 m~y cparate in either a remote or an cut-of-band local mode. m e netw~rk manager c~nsole 36 ~perates only ~ a local mode~
Ale~ts are used t~ n~tify system sDf~ware c~ a network administrator abcut important events. Fc~ example, if ~he host experiences a pcwer failure, ~he enhanoemen~ or EISA system board 13 detects the loss o~ power and sends an ale~t. As . :.
;
":
heretofore mentioned, there are two types of alerting: in-band or out-of-band. In-band alerts are sent to software residing locally on the server 12 with the enhanoement board 13. If an alert is to be delivered in and cut-of-band, one or the other (typically the in-band alert) may be delivered first. Out-of-band alerts are sent thrcugh the EISA system board's asynchronous p~rt (designated by reference numeral 44 in FIG. 1) to a remote application. These alerts include alerts sent to a r~mvte console, a phone, or a pager.
Referring ncw to FIG. 2, further details regarding the alert system are set forth therein. In that FIG. it may be seen that asynchronous lines 46, 48, 50 may exist between the EISA
system board 13 and a pager 52, a telephone 54 and a console 56, respectively. Althou~h fur~her details will be pr~vided below, it may be noted in FIG. 2 that from a functional poin~ of view, the EISA system board 13 m cludes an alert management controller or alert manager 58 which can trigger opera~ion of a m~dem 60 with voioe capability 62 as appropriate based upon oo~parison of values obtained fram a bus m~nitor 62 and threshold values in an object data file 64.
Referring ncw to FIG. 3, ~here is shown a flow diagram illustrat mg decisional processes in embodimert~ of the alert delivery system according to the teachin~s of the present invention. operation of the alert delivery ~ according to the teachings of the present inventiRn begins with generation of an alert and deliv~ry of that alert to the alert mana~er (discussed above with r ~ t~ FIG. 2). Pro~pkly upon receiving a new alert, the alert n~n~gæ 58 has th~ fact that the alert was received entered inbo an alert log 66. m e alert IrE~nag~r 58 then makes a first ~fart to deliv~r ~e alert, either in-band via a bus ~ interfa oe master 68 (a card between software l~yers and h2rdware in the management system) or cut-of-~and via a commLnicaticns manager 70. The commum cations manager 70 may, and likely -~culd be, a piece of .. ; :- : .: .
~ :,: ., : . :: :, 20~21~9 code in board 13. Telephone numkers c~re required to deliver out-of-bc~nd alerts; thus, an alert destination list 72, OCmpriSLng such numbers, is associated with the alert manager 58 and the oommunications n~nager 70 to transmit as and when apprGpriate, telephone numbers for out-of-band alerts. m e c3mmunications manager 70 n~y direct the operation of other c~mponents to deliver out-of-band alerts. Such cowponents n~y be a n~dem 72 and/or a uniYersal asynLhr~nc~s receiver transmitter ~ gr") 74 as shown in FIG. 3.
A very in~ortant asp~ct of the present inNention is also shown in FIG. 3. m is aspect is a retry capability. Quite often alerts ~re not satisfactorily delivered the ~irst time they are sent. For example, no one may be sittin~ at a particular terminal where an alert is delivered or n,o one nay answer a telephone call via which an out-of-band alert delivery is being attempted. The present invention cvlrccme~ this problem by including a retry manager 76. The retry manager 76, like the alert manager 58, has a~CC to the alert log 66 so ~hat it can bokh note that an alert needs to be delivered and update the alert log status when an alert is pr~perly deliv~red.
Assuming that the alert nanager 58 fails in its ~ttempt to deliver an alert, the re~ry nanayer 76 can detect that fact via the alert log 66 and itself a ~ to deliver the alext, whether in-band or out-of-band. Re~ry manager timung is provided by a ~ kernel 78. In theory the retry m2nager can continue attempting to deliver an alext at pr~determined intervals until the alert is delivered. Cnce th~ alert is delivered, entry of that fact Ln the ar~ log 6~ can terminate the delivery processes.
Before discussing the al~rt delivery system of the present invention ~n detailed functional terms, a few oomments a ~
alert generation ~ay be helpful and, thus, follow. Ihe various system components keing monitored ~y a system manag~r ~ay be grcuped in~o classes. Each sys~m ccmponent within a given . . : . : ;
: .. . : , .
::
2~721~9 class may be referred to as an object. All objects consist of attri~utes that describe the status of the object. In such a case there may be three types of attributes that can cause al~rts: a counter, a state, and a threshold.
Alerts may be caused when rent values exceed bcundaries that have been se~. me current values change when the attrikutes are, e.g., mcrem~nted, decremented, updated, reset, or modified. When a current value oomes kack Lnto boundaries set for it and then travels cutside those bcun~aries again, another alert may be generated. In addition to the above operations, an alert may be caused if the atL~ibute is created with alert conditions already present. m e follohnu~g table is an example of a threshold aL-Libute.
q~ EL~le --24 (byte - Attribute ID) l l , _ _ l(Enable) ¦O(In) l(Out)¦ l(res) l(internal) O(Res)¦O(Res) O(hQst notify) I l l .
l(mean mg)¦l(meaning) l(mea m ng) l(sev)¦l(sev)¦O(type) l(type~ O(type) l , .
6 (~yte - voioe error message) _ _ _ "System Voltage" (1~ byte label) _ _ O (2 by~es next offset) :~ _ _ 4750 (4 byts low threshold) 5250 (4 byte high thr~shold) . _ . _ 5000 (4 ~yke default value) ~ _ 5500 (4 byte current value) 052091 (3 kyte date: ~o~th/Day/Year) _ :
~ 123033 (3 byte tLme) .
:, , ~: - : :: . : ~ . - ..
: ~ . . , , : ., :- ~ , . .:
:~: , , : :, : ~' , ~
..
2~72~9 The meaning bits specify if an alert will nn~ ~ when the current value is equal to, or within the thresholds. In the example, the valtage thresholds are 4750 mv and 5250 mv. The meaning bits (111) specify that an alert should be signaled when the voltage is outside of the threshold val~es. The example is set for an out-of-band alert, with, as will be discussed further below, attrikute logging and host natification on.
An example of an alert s*ructure oommand is as follows:
Ccmmand (40h) (byte) Object ID (4 bytes) ~ (~) _ _ Attribute ID (byte) Attribute type ~2 bytes) Voice Error message # (byte) Object label (16 ~ytes) Attribute lakel (16 ~ytes) Class (4 ~ytes) Date (3 bytes) . _ .
Time (3 ~ytes) Current Value (4 ~ytes~
Li~nit Value (4 ~:es) Cpkional Value (4 byt~) To a~cict those ~killed in the art in fully ~a~
the present invention, an~ ~o provi~e an e~?le e~di~t of 4 0 the present mve~tion with a 3nm~er of ~Lig~e aE~cts and advantages, affects of c~ther c~s in an s~i ent of the ., ~. ~ ;, .
: ~ :. , . :
: :~, : :, - ,, : : :., :~"
: ~ , . , :, ", 20721~9 present invention will now be discussed.
In one embodiment of the present Lnvention, alerts are stored in the alert log 66 along with their status. m e status of these alerts is affected by three ccmmands: Get Alert Log, Load Configuration, and Feature Control.
When Get Alert Log is issued from the host, it affects the status of in band alerts. The alert log 66 affects out-of~band status ~hen the commanæ is issued frcm a remote application.
When the Get Alert Lcg is issued all the alerts for that band are considered delivered since all the information given in response to Get Alert Log is the same information delivered for a sLn~le alert delivery.
The intent of the Get Alert Log oommand is to provide the user a way to termlnate alert delivery while retaining an alert history that is provided in the alert log 66; by marking the alerts Done after viewing alerts in t~e log, this goal is achieved.
If the Load Configuration oommand oontains a new alert destination list, all rent destinaticn nYmker references in the alert log 66 become mvalid. Out-of-ban~ members are referenced by index only and because the indexed destination member in the new list has no c~rrelation to the member in the old list, the kcard 13 nLst invalidate the alert entry. Note:
The alert itself is still re~ained, but its delivery status becomes invalid.
Al~rt ~ can ke ~ led by the Feature Control command.
If disabled, all current alert log entries will be marked Invalid for kckh bands. New alerts will ~e discarded until alertLng is re-enabl æ.
Continuing t~ discuss a particular e~bodim-nt of an alert delivery system accarding to the teachings of ~he present invention, the alert lo~ S6 i~self has tw~ main sections for each alert; an al~rt deliv~ry status section an~ a destination member status section.
2 ~
qhe followLn~ table illustrates the Farts of each alert log entry.
. _ . .
Alert I~g . _ Alert #1 Alert Delivery Status Byte In-band I Out-of-b~nd . _ ~c~ O ~ ~5 : (Bits 7 3) Number statNS2 (Bit 2) statusl (Bi~ 1) stat~sO (Bit o) :~ of retries left for 15 member (0) ____ _ (Bits 7 - 3) Number status2 (Bit 2) statusl (Bit 1) stat~sO (Bit 0) of retries left for member (15) _ The alert delivery status secticn describes the alert status for the entire alert, i.e. whether the alert has ccmpleted the process thrcugh the en~ire destination memker list. The alert ~ay ke:
o Pendiny (i.e.,queued, but not sent. Status = 2 0 ) o Done (suooessfully deli ~ inrkand; retry ccunt has been met or suc~essful delivery for all cut-of-kan~ ~emkers. Status e 5.) o Failed (cculd nok ~e delivered. status = 4.) o Invalid (will not be d~livered eNer. Status =
OAh.) o Not one (ei~her retry is processing, or not all alert destLnatio~ m~mbers have received this alert. Statl~s = 4 or 7) : . . , ',,, .: ; ,. ;' ~ ,:
2~72~9 With respect to the destination member status section, at configuration, an alert destination list is defined which contains the phone num~e~s and all pertinent inormation needed to send an alert. Each member that should receive the alert has a status in the alert log destinakion member status. If a remote calls in that is not in the destination list, no alerts will be delivered to that rem~te.
Describing the embodiment of the present invention being discussed functionally, when the Get Alart Log comman~ is issued from the host (i.e., via terminal 36 in FIG. 1), the alert log will appear as it is at that time. Ri~ht after viewing, several changes occur within the log, and th2 status of alerts change.
These changes occur only on those alert entries that are viewed.
The changes will show when the Get Alert Log ccmmand is issued again.
1. Once the alert type Failed, (Stabus = 4) has be~n viewed it will be marked Success (Status = 5) because that entry in the alert log has been viewed, it is considered delivared. This holds true for in-band alerts only.
2. When the Get Alert Log is issued, the following in-band alerts will not c~nge:
o pending (~o attempt h3s been made to deliver yet. Status = 2.) o processing (in the process of be ; delivered. Status = 3.) ~r o invalid (will nck be d~livered. Stabus =
OAh. ) The followin~ effects are valid at the ~ th~ Get Alert Log command i~ issued.
1. m e alert log will n~t contain entries for alerts that were in the process of bei~g added to ~he alert log.
For instanoe, if the alert log had previously stabilized at 32 entries, an~ the cc~mand is issued ... .... .. . .. ..
~7~69 while a new alert entry is bein~ built, only 31 will be returned. One will be displaced (note that only 32 entries are allowed in this cmbodi~ent of the present inventian) and the new one is not yet valid.
2. If the buffer size is nok big enough to contain all the alerts, only the number of entries that fit will be returned. An error code (13h) "not encu3h buffer size" will be returned.
IN-B~MD/OUT'OF-BAND ALERr DELIVERY SYSTEM
:
., .
~ .
. ~. , , The present invention r~lates to hardware ~anageability support systems Ln network environments. More particularly, the present invention relates to syst~ms ~hat deliver alerts in ~ local area network, wide area netwark, enterprise network :~ 20 environments, and the like.
~ In its sLmplest form, data ccmmunication takes place ., .
: , ' : .' ~'' ' , . -: . ~ , :. .
., . , : :, ,, . :-~, :i -. , 2072~9 between two devices that are directly cor~cted by some form of point-to-point transmission medium. H~ever, in certain instanKes it is impractical Por two devioes or compor~lts to be directly, point-to-point cor~ected. An example of such an instance is when there are a set of devi~c, each of which may require a link to nEuly of the others at various timfs. This problem has been heretofore addressed by attaching multiple devices to a commum cation network. Each devi oe, or station, is attached to a network node. The set of nodes to which stations attach is the boundary of a oommunication network that is capable of transferring data betweer. pairs of stations.
Ccmmunication networks may be categorized based on the architecture an~ the techniques used to transfer data. Iwo major different types of communication networks are switched networks and broadcast networks. Switched networks involve transfer of data from a souroe to a destination through a series of intermediate nodes that prcvide a switching facility to move the data from node to node. Examples of switched communication networks include circuit switched netw~rks, message s~itched networks, and packet switched networks. Broadcast networks `~ involve no intermediate switching nodes; each statio~ has a transmitter/receiver that allows communication over a common medium, so that a transmlssion fro~ any one station i5 broadcast to and received by all other stations in ~h~ ne~wDrk. Exanples of broadcast communication networks Lnclude packet radio netw~rks, satellite network~, and local ~ .
The present invention is especially designed to cperate in packet-broad~asting net~Drks such as local ar~a networks ; ("L~NS"), wide area networks ('~NS"), enterprise network environments ("en~erprise environm2nts") and the like. As thQse skilled in ~he art should appreciate, the ~erms L~Ns, ~Ns and enterprise environments have c~nstantly ev~lvin~ ~ s. In general, hc~7ever, a L~N is a general-purpose local netw~rk supportLng personal ccmFuters ("PCs"), a W~N i5 a ~eneral-:
., .. . , .. ~ , .. .
20721~9 purpose netw~rk supporting a wide area relative to a LAN
(usually because it passes throu3h a public switch3d telephone network at least in part), and an enterpri~e environment is a general-purpose network supporting mini ccmputers and mainframes. LANs, W~Ns, and enterprise environments can also s ~port any number of other peripherals (e.g., printers), and qulte often carry v~ioe, video, a~d graphics as ~ell as data.
To assist th~se presently familiar with and skilled in the art in understanding what is meant by the various network terms used herein, the term LAN as used herein enocnpasses Novell NetWare, SOO UNIX, Banyan VINES, Microsoft LAN Manager, and the like.
Further, the term enterprise environment as used herein en~cmpasses I~M SN~ Management Services, DEC Enterprise Management Architecture, A~T Uhified Netwoxk ~nagement Architecture, SNMP-Based Management Stations, Hewlett-Pac ~ 's OPENVIEW, and the like.
As will beoome appar~lt from the detailed description of the invention section below, the present inv2ntion may be viewed as an alert delivary system servici~3 a numk~r of system components that supplement oon~entional network components to enhance management functions. m ese oonven~ional network componen~s inclu~e network managemen~ agents and n~tw~r~ manager ~ consoles. Uhderlying both of these compon2nts is a network ; operating system ~"OS"). Ihe 06 is sDfkware, firmware, or -~ 25 hardware that controls the execution of proYes:es in a system.
Servioes provided by an 06 can include rescuroe allocation scheduling, input/output oontYol, and data management. Ihe theory behind an OS is to prcvid~ support in a sin~le spot so that each pro3ram does not need to be concsrne~ with controllLng har~ware. A network m~nagement agent is a part of the OS. ~he network management a~ent is ~he cçntral collection point for a particular server's networ~ management info~mation. Typically, the information is stared in an obj~ct orient2d format for use by "netw~rk manager" sDftwar~ that ru~s on ~he netw~rk such as a - .~
- : , : : :~: : :.: . : ~ -:
2~7216~
~4--remote console or IEM's Netview. A netw~rk manager console, the second component mentioned above, is generally provided as an optional component piece of an OS network management package.
Typically, the network manager console allows one central po mt of monitoring and control for a network admdnistrator's dcmain of interest. From the console the administrator can view and control the objects registered with the netw~rk management agent. Ihe networX manager console represents one type of manager software connected over the internet (i.e., ;` 10 interconnected networks) with the network management agent.
Other network manager software can also make use of the information in the management agent.
` q~o other concepts that should be fully understood to appreciate the present invention are 'lin-~andl' and "out-of-band". The term in-band is used herein to refer to signals sent via network management software residing locally on the server.
In simple terms, in-band refers to use of the wire that cGmes with a networX. The term out-of-band refers to communications ~` that leave the computer system manager (discussed at length in the related ca~e so titled) via an asynchr~ncus port. Although the out-of-~and concept will be discussed in much grea~er detail below, it should be appreciated that asynchroncus transmission is involved, that is, transmi æ ion in which each information character is individually synchronized, usually by the use of start elements ~nd stqp el~ments.
~` Although netw~rk managers have heretofore been able to provide an acceptable level of netwark mana~ement, the c3nstant improve~ents ke mg made in networks betray the fact that many improve~ents can still yet be made. FQr ~ le, it is important that the system software ~r thQ network ~anager be notified about significant or potentially significant events occurring or abcut to ooour in the netw~rk. Alerts pexform such a function. Hcwever, prior art al~rt delivery systems have a number of shortcomings and defects. For exa~ple, prior art :. , ~ - , :
: , ~721~9 ; -5-alert delivery systems are limited as to the number and types of alert receivers, the alert transmission media that can be used, capability for retrying, and effectiveness of the underly mg algorithm, to name just a few.
The present i~vention cwerccmes the shcrtctmin~s and deficiencies of the prior art by prcviding an i~-kand/out-of-band alert delivery sys~em for a co~puter system manager : including an alert log which maintaLns a record of alerts to be delivered and the status of those alerts, an alert manager for making a first attempt to deliver each alert, and a retry manager for naking subsequent attempts to deliver alerts as beccmes nmc.ss~ry and appropriate.
`~ In embodiments of the alert delivery system of the present invention there may be a bus master interfaoe manager for making in-kand alert deliveries and a communications manager for ~ g out-of-band alert deliveries. Telephone numkers may be provid~d : to the communications manager by an alert destination list.
Out-of-ba~d alert deliveries may be made via a mcde~, a : 20 unlversal asynchroncus receiver transmitter, or the like.
: According to the teachings of the present invention, out of-band deliveries may be made to pagers, telepbones and remote console~ via asynchronoas lLnes. The underlying algorithm in em}odiments of the present inNention is designed for success rate, via ~xhaustive retrying, in delivering alerts.
Accordingly, it is an object of ~he pr~sEnt inNention to provide an imprcved alert delivery system for Lncorporation into data ~ cation net~ork environmen~s.
Another object of the present i~vention is to prcvide an ; 30 m-band/out-of-band ale~t delivery system with a p#rsis~ent retrying capability.
Yet another ~bj~ct of ~he present inv2ntion is to provide an in-band/cut-of-band alert delivery ~ystem for a computer system manager that is able to deliver aler~s to many different .. .
V72~9 types of ale~t re~eivers including pagers, telephones and remote consoles.
Still yet another object of the present invention is to provide an in-band/out-of-band alert delivery system for a computer syst~ nanager which operates based upon a very effective "underlying" algorithm.
` Othe~ objects, advantages, and ncvel features of the present invention will kec~me a~parent from the following ~ 10 detailed description of the invention when considered in ; conjunction with ~he aoccmpanying drawi~gs wherein:
FIG. 1 is a block diagram of a compu~er network having an EISA based computer system and a computer system manager koard installed therein;
; 15 FIG. 2 is a block diagram of portions of the EISA system board of FIG. 1 which illustrates information flow to and frcm, as well as withLn, the board;
FIG. 3 is a flow diagram illustrating decisional prooesses in an emt~dlmint of the alert delivery system according to the teachings of the present Lnvention; and FIG. 4 is a flow chart depicting the logic empl3yed in an embodiment of the present inYention.
As discussed in dekail in ~ther of the related cases referenced above, the management system L~ which the alert delivery sys~em discussed hereLn may ke incorparated is in one embodlment a system of ~ re and software c=mponerts that provide enhanoed hardware nanagement capabilities for EIS~-based systems. In this embodiment, the management system is designed to be Lncorporated into LANS, ~NS, enterprise e~vironmen~s, and the like.
In yreater detail, and as also dLYcussed in greater detail :
2~721~9 r ~7~
in other of the related cases referenced abcve, in various embodiments the ~ystem of hardware and sDftware components can include a 32-Bit intelligent Bus Master EISA board and firmware, an OS device driver, a remote asynchronous driver, a rem~ote asynchronous console program, and configuration support. These components are coupled with a network manage~en~ agent and a network manager console, bcth of which are discusscd in the ` description of related art section above, so as ~o provide enhanced h~rdware management capabilities. Because these various components are discuss~i in detail in cther of the related cases referenced abave, they will nok be discussed in detail herein. However, it may ~e noked that the 32-Bit intelli~ent Bus Mas~er EISA board and ~irmware provides the ~ are and f.Lnmware support for alerting conL~olling and monitorLng functions, which functions are discl~sed further below as well as in the related cases. The OS devioe driver, a ccmponent which is n~oes Rry for each supSo t~d operating system, is a mechanism for providing tworway communication between a netw~rk management agent running on the cperating system and the system manager haxdware. The remoke asynchronous driver is a mechanism for en~bl mg access t3 the 32-Bit intelligent Bus M~ster EI5A board m~ntioned abcve through an a ~ onGus connection. Further, the ~ asynchronous driver enables remote console software operation as ciscusse~ in other of the related cases ref ~ abo~e. Ihe rem~te asynchroncus con601e program is a *oftware ~ nt that executes on any PC connected to a ~dem ar asynchronous interfa oe of the ~ystem m~nager. This software inte~ac*s with the 32-Bit intelligent Bus M~ster EISA ~oard by callLng a re~;ident asynchron~Ls driver API that has a pro~oool link with an asynchronous or ~d~m port of the sys~n manager. Ihe API
allows rem~te control (e.g., rebo~tLng), a~ess to stored dat~, and a r~te console f~tionO Ihe xem~e oansole er~lation (te~t mode only) is in~ep~dent o the syst~n and OS allc;wing " , ~ "
: . .: ,: ~ :
2~72~ ~9 significant functionality without the support of the network or operating system. Remote console em~lation is the express subject matter of related U.S. Patent Application Serial No. _ (Att~. Docket No. 09447/0070) incorporated here m.
All out-of-band accesses to the modem or asynchronous interfa oe of the system manager can be made to require s4curity chec~s ~efore aocess is allowed. 'Lhe final co~ponFnt of the management system listed above, configuration support, involves configuring the 32-Bit intelligent Bus Master EISA board into an EISA system using an F~SA configuration utility with corresponding and appropriate files. Default settings for the cards' configurable options can be stored in the host EI5~ nonNolatile memory. The management system may also require runtime configuration, possibly remokely, to set thresholds for alerting temperatures and other specific configuration options discussed further kelow. These coniguration commands can be made available at various points throughout the management systEm.
The system manager d~scriked in the immediately preceding paragraph can perform a n~mber of functi~ns. Fcur of the man~
functions it can perf3rm are alerting, monitoring, remote man2gement, and histories. Altho~gh alerting will be discussed in great detail below, it may be noted at this point that the managemen~ system discussed in general in the various related applications is able to dial a preconfi ~ telephone ~ r and repart important e~ents, that is, to alert. Alerting can be accompli~hed by any of the follow ~ methods: by sending a protocol message cver a swi~ch telephone CQnneCticn or ~hrcugh a direct serial connection, by dialing a phone number associated with a pager, and/or by dialLng a Fhone number associated with a person and leaY m ~ a synthe~i~ed voioe m@ssage. The foregoing list is not exhaustive as will ke disoussel fur~her below.
The second function ~n~ioned above, mLnitorLng, is the ability of the system t~ m~nitor system ocmponents and parameters. SLmply, this means that if a ccmpcnent experiences .
:: . .. .
~, ' ' ''- '~. ;,: ` . ', , ' ' :
2~721~9 g a failure, or exhibits ~haracteristics that indicate that it might have a failure, portions of the management system can detect this and report it to a system software entity that can, in turn, report. the information to a netw~rk adm1nistrator so that corrective action can be taken. Three examples of a multitude of system co~ponents and parameters that can be mo m tored by the n~r~gement system include system power, internal temFerature, and memory refresh and parity. In all three of these examples alerts or portions of the alerting svstem may be involved. For example, if the system detects a drop in system power ~i.e., below some predefined threshold), it may report the event as an alert. Likewise, if the temperature rises above a predetermined threshold, the system may issue an alert. Still further, if the system dQtcts the aksence of memory refresh signals or a memory parity error, it may issue an alert. In general, associated with the various system objects within ~he system may be a capability t~ provide generic thresholding and alerting. That is, if some counter or value within a system o~ject exceeds a threshold, the system can automatically send an alert either locally or throu~h one or koth of its serial ports.
e remote manage~ent function refers to the ~bility to provide remoke m~nagement of a ~ r. As previcusly discuss2d, alertin~ is a function that ~ay be provided remotely.
~tior~lly, ~e manag~me3it sys~n can, in sc~ne ~i~s, re~ze a small list of tones over its modem connection.
These tones may be used to issue c~s. ~c~ nple, ~en the mar~gement system i~;sues an alert over a model using v~ioe synthesis, a tal~htone a~ may l:~e used to "a~wle~ge" the alert.
Based upon the foregoir~, it shalld be readily a ~ arent to those skilled Ln the art that the m~lagement system discussed in this an~ the various related cases h3s an alert delivery system, ; which alert d~livery system is nck only i~pQrtant in~epen~ently, 2~721~9 but which system is also importallt because its capabilities and operations managem~nt permeate and influence various other components throughout the system. With that in mind, the alert system may ~ow be disc~E~3d in detail.
Referring initially to FIG. 1, an extended industry standard ~ itecture ("EISA") basei computer network 10 is shown therein. The computer netw~rk 10 includes an EISA server 12 and an EISA board/~us 13. Installed on the EI5~ system board 13 are a plurality of cards including a system manager 22, an EISA netw~rk interfa oe adapker 24, and an intellige~t disk array c~ntroller device 26. Also running on the EI~ server 12 is a network o~eratLng system 14, preferably one whic~ mcludes a network managemen~ agent 15. Two-way communication between the system manager 22 and the network management agent 15 is provided by a syst~m m~nager device driver 16. In a similar manner, a network interfa oe devioe driver 18 interconnec~s the network ~anagement agent 14 and the EI5A network interfa oe adapter 24, and an intelligent disk array controller devioe driver 20 interoonnec~s the netwark operatLng s~stem 14 and the intelligent disk array controller device 26. Also shown in FIG.
1 are three terminals con~ected to the overall netwcrk 10.
Terminal 30 is connected to the EI5A network interfa oe adapker 24 via EIS~ bus 28. Terminal or ~etwark m~nager oonsol~ 34 is connected to the ~ manager 22 via an asynoh mnous (cut-of-band) line 40. FLnally, terminal o~ netw~rk manager console 36 is ccnnectei to the network operating system 14 via inter-network communicatiQn (inrband) lLne 42. The ~e~wark manager oonsole 34 m~y cparate in either a remote or an cut-of-band local mode. m e netw~rk manager c~nsole 36 ~perates only ~ a local mode~
Ale~ts are used t~ n~tify system sDf~ware c~ a network administrator abcut important events. Fc~ example, if ~he host experiences a pcwer failure, ~he enhanoemen~ or EISA system board 13 detects the loss o~ power and sends an ale~t. As . :.
;
":
heretofore mentioned, there are two types of alerting: in-band or out-of-band. In-band alerts are sent to software residing locally on the server 12 with the enhanoement board 13. If an alert is to be delivered in and cut-of-band, one or the other (typically the in-band alert) may be delivered first. Out-of-band alerts are sent thrcugh the EISA system board's asynchronous p~rt (designated by reference numeral 44 in FIG. 1) to a remote application. These alerts include alerts sent to a r~mvte console, a phone, or a pager.
Referring ncw to FIG. 2, further details regarding the alert system are set forth therein. In that FIG. it may be seen that asynchronous lines 46, 48, 50 may exist between the EISA
system board 13 and a pager 52, a telephone 54 and a console 56, respectively. Althou~h fur~her details will be pr~vided below, it may be noted in FIG. 2 that from a functional poin~ of view, the EISA system board 13 m cludes an alert management controller or alert manager 58 which can trigger opera~ion of a m~dem 60 with voioe capability 62 as appropriate based upon oo~parison of values obtained fram a bus m~nitor 62 and threshold values in an object data file 64.
Referring ncw to FIG. 3, ~here is shown a flow diagram illustrat mg decisional processes in embodimert~ of the alert delivery system according to the teachin~s of the present invention. operation of the alert delivery ~ according to the teachings of the present inventiRn begins with generation of an alert and deliv~ry of that alert to the alert mana~er (discussed above with r ~ t~ FIG. 2). Pro~pkly upon receiving a new alert, the alert n~n~gæ 58 has th~ fact that the alert was received entered inbo an alert log 66. m e alert IrE~nag~r 58 then makes a first ~fart to deliv~r ~e alert, either in-band via a bus ~ interfa oe master 68 (a card between software l~yers and h2rdware in the management system) or cut-of-~and via a commLnicaticns manager 70. The commum cations manager 70 may, and likely -~culd be, a piece of .. ; :- : .: .
~ :,: ., : . :: :, 20~21~9 code in board 13. Telephone numkers c~re required to deliver out-of-bc~nd alerts; thus, an alert destination list 72, OCmpriSLng such numbers, is associated with the alert manager 58 and the oommunications n~nager 70 to transmit as and when apprGpriate, telephone numbers for out-of-band alerts. m e c3mmunications manager 70 n~y direct the operation of other c~mponents to deliver out-of-band alerts. Such cowponents n~y be a n~dem 72 and/or a uniYersal asynLhr~nc~s receiver transmitter ~ gr") 74 as shown in FIG. 3.
A very in~ortant asp~ct of the present inNention is also shown in FIG. 3. m is aspect is a retry capability. Quite often alerts ~re not satisfactorily delivered the ~irst time they are sent. For example, no one may be sittin~ at a particular terminal where an alert is delivered or n,o one nay answer a telephone call via which an out-of-band alert delivery is being attempted. The present invention cvlrccme~ this problem by including a retry manager 76. The retry manager 76, like the alert manager 58, has a~CC to the alert log 66 so ~hat it can bokh note that an alert needs to be delivered and update the alert log status when an alert is pr~perly deliv~red.
Assuming that the alert nanager 58 fails in its ~ttempt to deliver an alert, the re~ry nanayer 76 can detect that fact via the alert log 66 and itself a ~ to deliver the alext, whether in-band or out-of-band. Re~ry manager timung is provided by a ~ kernel 78. In theory the retry m2nager can continue attempting to deliver an alext at pr~determined intervals until the alert is delivered. Cnce th~ alert is delivered, entry of that fact Ln the ar~ log 6~ can terminate the delivery processes.
Before discussing the al~rt delivery system of the present invention ~n detailed functional terms, a few oomments a ~
alert generation ~ay be helpful and, thus, follow. Ihe various system components keing monitored ~y a system manag~r ~ay be grcuped in~o classes. Each sys~m ccmponent within a given . . : . : ;
: .. . : , .
::
2~721~9 class may be referred to as an object. All objects consist of attri~utes that describe the status of the object. In such a case there may be three types of attributes that can cause al~rts: a counter, a state, and a threshold.
Alerts may be caused when rent values exceed bcundaries that have been se~. me current values change when the attrikutes are, e.g., mcrem~nted, decremented, updated, reset, or modified. When a current value oomes kack Lnto boundaries set for it and then travels cutside those bcun~aries again, another alert may be generated. In addition to the above operations, an alert may be caused if the atL~ibute is created with alert conditions already present. m e follohnu~g table is an example of a threshold aL-Libute.
q~ EL~le --24 (byte - Attribute ID) l l , _ _ l(Enable) ¦O(In) l(Out)¦ l(res) l(internal) O(Res)¦O(Res) O(hQst notify) I l l .
l(mean mg)¦l(meaning) l(mea m ng) l(sev)¦l(sev)¦O(type) l(type~ O(type) l , .
6 (~yte - voioe error message) _ _ _ "System Voltage" (1~ byte label) _ _ O (2 by~es next offset) :~ _ _ 4750 (4 byts low threshold) 5250 (4 byte high thr~shold) . _ . _ 5000 (4 ~yke default value) ~ _ 5500 (4 byte current value) 052091 (3 kyte date: ~o~th/Day/Year) _ :
~ 123033 (3 byte tLme) .
:, , ~: - : :: . : ~ . - ..
: ~ . . , , : ., :- ~ , . .:
:~: , , : :, : ~' , ~
..
2~72~9 The meaning bits specify if an alert will nn~ ~ when the current value is equal to, or within the thresholds. In the example, the valtage thresholds are 4750 mv and 5250 mv. The meaning bits (111) specify that an alert should be signaled when the voltage is outside of the threshold val~es. The example is set for an out-of-band alert, with, as will be discussed further below, attrikute logging and host natification on.
An example of an alert s*ructure oommand is as follows:
Ccmmand (40h) (byte) Object ID (4 bytes) ~ (~) _ _ Attribute ID (byte) Attribute type ~2 bytes) Voice Error message # (byte) Object label (16 ~ytes) Attribute lakel (16 ~ytes) Class (4 ~ytes) Date (3 bytes) . _ .
Time (3 ~ytes) Current Value (4 ~ytes~
Li~nit Value (4 ~:es) Cpkional Value (4 byt~) To a~cict those ~killed in the art in fully ~a~
the present invention, an~ ~o provi~e an e~?le e~di~t of 4 0 the present mve~tion with a 3nm~er of ~Lig~e aE~cts and advantages, affects of c~ther c~s in an s~i ent of the ., ~. ~ ;, .
: ~ :. , . :
: :~, : :, - ,, : : :., :~"
: ~ , . , :, ", 20721~9 present invention will now be discussed.
In one embodiment of the present Lnvention, alerts are stored in the alert log 66 along with their status. m e status of these alerts is affected by three ccmmands: Get Alert Log, Load Configuration, and Feature Control.
When Get Alert Log is issued from the host, it affects the status of in band alerts. The alert log 66 affects out-of~band status ~hen the commanæ is issued frcm a remote application.
When the Get Alert Lcg is issued all the alerts for that band are considered delivered since all the information given in response to Get Alert Log is the same information delivered for a sLn~le alert delivery.
The intent of the Get Alert Log oommand is to provide the user a way to termlnate alert delivery while retaining an alert history that is provided in the alert log 66; by marking the alerts Done after viewing alerts in t~e log, this goal is achieved.
If the Load Configuration oommand oontains a new alert destination list, all rent destinaticn nYmker references in the alert log 66 become mvalid. Out-of-ban~ members are referenced by index only and because the indexed destination member in the new list has no c~rrelation to the member in the old list, the kcard 13 nLst invalidate the alert entry. Note:
The alert itself is still re~ained, but its delivery status becomes invalid.
Al~rt ~ can ke ~ led by the Feature Control command.
If disabled, all current alert log entries will be marked Invalid for kckh bands. New alerts will ~e discarded until alertLng is re-enabl æ.
Continuing t~ discuss a particular e~bodim-nt of an alert delivery system accarding to the teachings of ~he present invention, the alert lo~ S6 i~self has tw~ main sections for each alert; an al~rt deliv~ry status section an~ a destination member status section.
2 ~
qhe followLn~ table illustrates the Farts of each alert log entry.
. _ . .
Alert I~g . _ Alert #1 Alert Delivery Status Byte In-band I Out-of-b~nd . _ ~c~ O ~ ~5 : (Bits 7 3) Number statNS2 (Bit 2) statusl (Bi~ 1) stat~sO (Bit o) :~ of retries left for 15 member (0) ____ _ (Bits 7 - 3) Number status2 (Bit 2) statusl (Bit 1) stat~sO (Bit 0) of retries left for member (15) _ The alert delivery status secticn describes the alert status for the entire alert, i.e. whether the alert has ccmpleted the process thrcugh the en~ire destination memker list. The alert ~ay ke:
o Pendiny (i.e.,queued, but not sent. Status = 2 0 ) o Done (suooessfully deli ~ inrkand; retry ccunt has been met or suc~essful delivery for all cut-of-kan~ ~emkers. Status e 5.) o Failed (cculd nok ~e delivered. status = 4.) o Invalid (will not be d~livered eNer. Status =
OAh.) o Not one (ei~her retry is processing, or not all alert destLnatio~ m~mbers have received this alert. Statl~s = 4 or 7) : . . , ',,, .: ; ,. ;' ~ ,:
2~72~9 With respect to the destination member status section, at configuration, an alert destination list is defined which contains the phone num~e~s and all pertinent inormation needed to send an alert. Each member that should receive the alert has a status in the alert log destinakion member status. If a remote calls in that is not in the destination list, no alerts will be delivered to that rem~te.
Describing the embodiment of the present invention being discussed functionally, when the Get Alart Log comman~ is issued from the host (i.e., via terminal 36 in FIG. 1), the alert log will appear as it is at that time. Ri~ht after viewing, several changes occur within the log, and th2 status of alerts change.
These changes occur only on those alert entries that are viewed.
The changes will show when the Get Alert Log ccmmand is issued again.
1. Once the alert type Failed, (Stabus = 4) has be~n viewed it will be marked Success (Status = 5) because that entry in the alert log has been viewed, it is considered delivared. This holds true for in-band alerts only.
2. When the Get Alert Log is issued, the following in-band alerts will not c~nge:
o pending (~o attempt h3s been made to deliver yet. Status = 2.) o processing (in the process of be ; delivered. Status = 3.) ~r o invalid (will nck be d~livered. Stabus =
OAh. ) The followin~ effects are valid at the ~ th~ Get Alert Log command i~ issued.
1. m e alert log will n~t contain entries for alerts that were in the process of bei~g added to ~he alert log.
For instanoe, if the alert log had previously stabilized at 32 entries, an~ the cc~mand is issued ... .... .. . .. ..
~7~69 while a new alert entry is bein~ built, only 31 will be returned. One will be displaced (note that only 32 entries are allowed in this cmbodi~ent of the present inventian) and the new one is not yet valid.
2. If the buffer size is nok big enough to contain all the alerts, only the number of entries that fit will be returned. An error code (13h) "not encu3h buffer size" will be returned.
3. If the user requests more log entries than rently exist in the alert log, only those in the log will be returned. If the user reguests more than 32 entries, an "invalid log number" (18h) error code will be returned.
If the user requests more than 32 entries and ~he buffer size is not big ~ h to contain all alerts, the kuffer size error overrides thc " m valid log number error". Only the '~ost buffer size not large enoughl' error 13h will be returned.
If the user requests more than 32 entries and ~he buffer size is not big ~ h to contain all alerts, the kuffer size error overrides thc " m valid log number error". Only the '~ost buffer size not large enoughl' error 13h will be returned.
4. If re alerts have been generated than the alert buffer can hold, new alerts wi11 be discarded and a log çverrun (OIh) will shaw cn the Extended Error code when the Get Alert Log oommand is issuedO The log overrun wlll be cleared after each Get Alert I~.
m e alert log is a circular buff~r. A ~ of 32 entries, as previously m~n~ioned, are allowed in the buffer. New alerts will ovarwritR any old alerts that are:
o Not Dane (Status = 4) o Dare, or Success (Status = 5) o Invalid (Stat~s = QA) An ~v ~ error will occur if the old alerts are:
o reserved (S~atus = 1) pendin~ (status - 2) o process m g (Skakus = 3) :
"
` ~072~9 Continuing to describe the embodiment of the present invention being discussed functionally, when the Get Alert Log command is issued frcm the remote (i.e., via terminal 34 in FIG.
1), the alert log will appear as it is at that time. Right after viewing, æveral changes occur within the log, and the status of out-of-band al~rts change. These changes occur only on those alert entries that are view2d. Ihe changes will show when the Get Alert Log command is issued aga m.
1. m e alert type Nok D~ne (Status = 4, and 7) will be marked Done (Status = 5~ because those Alerts in the Log that have been viewed, are c~nsidered delivered.
; 2. When the Get Alert Log is lss~ed, the following alert status will not change:
o pending (no attempt has been made to deliver yet, Status = 2) o processing (in the prooess of being delivered, Status = 3), or o invalid (will not be delivered, Status = OA) 3. If the Get Alert c~mmand is issued with the nNmber of entries equal to zero, alert entries status = 4 and 7 will be marked Done on all th2 entries in the lo~ even th~gh none were actually viewed.
The follow ~ effects are valid at the time the Get Alert ~ is ~ssued.
1. The alert log will not contain entries for alerts that ~ were in the process of bein~ ~ to the alert log.
;~ For i ~ , if the alert log ha~ previously stabilized at 32 entries, an~ ~he command is issued while a new one is being built, only 31 will be returnad. One will be displaced (~nly 32 entries are : allowed) and the new one is nok yet valid.
2. If the user requests ~Dre log entri~s than currently exist in the alert log, only those Ln the log will be ~ returned. If the user requests more than 32 entries, ; .
, .. , , ~ , ,~ ; ; . - , .
: - , : : . ' . ::
2072~6~
an invalid log number (18h) error code will be returned.
3. If more alerts have been generated than the alert buffer can hold, new al~rts will be d1scarde~ and a log overrun ~OIh) will show on the Extended Error code when the Get Alert Log comman~ is issued. The log cv~rx~m will be cleared after each Get Alert Log.
Fegarling load configuration, if the board 13 has not been configured, alerts cannct be sent or rrceived. If Lcad Configuration (for reo~nfiguration) is issued while the alert log has any valid entries and a new alert destinati~n list is assigned:
1. All out-of-band alerts that have been delivered to at least one alert destination in ~he old list will be marked Invalid in the Alert Delivery Status. These alerts will not be delivered to any other destinations.
2. If none o~ the alert destinatic~s memkers have received the alert ar an alert s~atus is prooess ~ :
A. The Dest mation Mbmker Status will be zerced out, and the retry ~ filed will ~e updated according to the new ocnfigu~aticn.
B. The Alert ~ livery Sta ~ wqll ~e ~arked NGt Done ~No~ Dvne; Status = 4).
C. Ihe ~ prccess will attempk delivery to the ~; memkers of the n~w Alert Destination list.
e user may receive an alert twice if an alert was in process and reached a d~stination. The retry task will send this alert again aoco ~ to the new Alert Destin~tion list.
Duplicate alert dest ~ tion ~ will be treated separately; the ~ser will reoeiv~ one alert for each time ~hat ~- menber ~ppears in ~he list.
e ccmm~nd Feature Control ~llows the user to disable ,:
~ alert mg by settL~g bit 2 of the Feature Co~trol Flag to 1.
,,.
2072~ ~9 The alert log will change in the ~oll ~ manner:
1. All new alerts will be discarded.
2. All out-of-band Alert Delivery Status will ke marked Invalid (Status = O~h) and will not be delivered. The Destination Mbmber Status will still show which members have received the alert.
3. In-~and alerts will be mark~d Invalid (Stabus = OAh).
If the asynchroncus in~erfa oe has been disabled (bit 2 of Feature Control Flag set to 1):
1. All new alerts will be entered into the alert log.
2. The aut-of-band ~lert Delivery Status (p#nding-Status = 2, and prooessing - Status = 3) will be marked Not Done (Status = 4). These alerts will be delivered later.
3. The retry count will not dbcrement until the asynchronous inter~a oe is rerenabled and alerting resumes.
Discussing now the retry portions of the embod1men~ of the present invention keing descri~ed in detail, the retry caunt, plus one, is the number of tLmes the board 13 wlll try to deliver the alert. If the retry ~ is zerv, the board will still try to delivery the alert at least on~e.
Whenever the bcard fails to deliver the alert m~ss~ye th~
retry count will decrement, t~e board will di#xnnmct the -~ 25 session and txy ~nokher destination member. For a failed alert, the retry interval will ke 6 ~ . A failed alert ~ay cccur because a conn~ction could not b~ established (~ill try ~he next destination member on list) or because ~he r~moke returned a value ~ther than success (will try the first destin2tion memker in the list).
Once there is a valid ConneCtiRn with any destination memker, whether initia~ed ~y ~he board or ~y a remoke, those alerts that have b~en ma~-k0d as Failed will be delivered. mOSe marked as Not to be Delivered (nct the righ~ time an~ date) will -.:: ,. ;
.
~0721g~
also be delivered because the date and time mask only restrict the board from attempting ~ call, not from delivering alerts.
If either of these cases fails to successfully oomplete the delivery of an alert (pxopex respon~e is not reoeived by the board), the board will disconnect.
If a remote calls in that is not in the Destination M~mber list, no alert will be sent to that remote~
Set forth immediately ~el~ are a number of examples of structNre and operation of the e~bcdl=ent of the present invention being discussed in detail herein.
Example 1:
If the user oonfigures the system to have 5 alert destination m~mbers, the bcard will try to establish the connection in order (s~artLng fro~ n~mber 0). Assume the retry count is set to zero (only one try will be made per destination) and there is no date and time mask specified. If the board fails to establish a connection with destination nYmkers O - 2 and suoceeds to establish the connection with an~ sen~ the alert to member 3, the alert log will ~e marked as follows:
Deli~ery S*atu~ = ~ot D~ns; status 4 .
, A~ ~ ~ ~ 5~
_ - -I
mRmber O - ~ ~ailed ., _ . _ ~ member 3 Success ~ _.
member 4 To be delivered, (has ~at been tri0d yet ~ retry count - 0) , ~ m e board could not deliver the alert to members 0 2 and mo~ed on to 3. meSe alerts will nct be tried again becau~e ~he ~ retry coun~ was zero, kut will be delivered if a connection is :~ 35made to these memkers at a la~er tIme. Ihe ~oard has n~t tried ~72~
:
.~
to establish a connection with member 4, 50 the retry count is zero, and the alert will be tried once.
~; The Alert Delivery Status is Not Done (Stabus = 4) b~cause not all the members have been tried.
! 5 Ex3mpl~ 2:
Using the same example, but a retry count of 5 for each destination member and no time and date ~ask:
':
Alert Deli~er status - ~k Dcne; S*atus = 4 . 10 _ _ _ member O - 2 To be delivered--retry ccunt = 4 member 3 oonnecti~n-_disoonn ct.
_ _ member 4 To be delivered retry count - 5 For m ~ 0 - 2, the alert has nat keen delivered, but one try has been made to each. Five more tries wlll be m de to these members. (It should be recalled that a try will be made when the retry count eguals zero.) Member 3 reoeived some other value besides sucoess and was disconnected. The next alert ~o be tried will be mYmber 0.
Member 4 has nok been tried yet.
~xample 3:
Us ~ the same example, with a retry count of 5 for each destination m ~ and nD time and date mask ~his example shows the status before any attempks have been made:
. .
~, : ', ' ' ' " ',, `
~`~ 2~721~9 Aaer~ ~ ~ery status - Not Done; Status = 2 __ ~ Des~ ~ ME~ber S~
member O - 4 Retry = 5; no attempt has been made on any destination.
Example 4:
Using the same example, with a retry count of 5 for each destination memker an~ no time and date mask, thi~ example shows the status as the flrst attempt is in progress:
Alert Deli~ery S*atus - NCt DoRe; StatUs = 3; ~lcessin 1~i _ _ ~
A~ ~ ~ ~ S~
- -m~mber O To be delivered (sta ~ 100); Retry = 5;
EXample 5:
In this example, the retry cou~t is 5 ~or each dstination m ~ , and the date ~nd tLme mask has keen set t~ deliver alerts on Manday 8:00 a.m. - 5:00 p~m. only. Ihe current tLme is MGnday 8:00 a.m.
2~ _ Alert D~livery S$atus - N~t D~e; Stabus - 7 _ _ ~ ~ ~i~ ~ SS~ T~ ~c _ 30 member O Will nok be delivered in current ti~ Friday 8:00 a.m.-frame. (status 011) 5:00 p.m.
- . -member 1 Success (status 001) ~day 8:00 a.m.-5:00 p.m.
_ mÆmber 2 T~ be delivered ~s~a~us 100); ~bn~ay 8:00 a.m.-Retry - 5; 5:00 p.m.
_ , ,',~ . ' :, 2~7~1~9 Member 2 is ~ ntly being prccY~ed, thus the overall Alert Delivery Status is Not Done (Status = 7).
E~ample 6:
In this example, the re.try count is 5, and the date and time mask has been set to deliver alerts on MQn~aY 8:00 a.m. to 5:00 p.m. only. The current time is Monday 8:00 a.m. The entire list has been tried at least once.
A session has keen established by remote destination nember o, thus the alerts marked as Will Not ~e Delivered In Current Time Frame will be delivered. If this same alert had been marked Failed, (retry count was met, no m~re tries will ke made) the alert w~uld ba delivered (Failed ~>Success).
_ _ Alert ~Pli~ery status Nbt Dcne; status - 4 _ _ _ Al~c ~ ~i~ ~r S~us $i~ ~c _ _ me~aer 0 Will ncrt be deliver~ ~n currer~ time Friday 8:00 a.m.-frame.~> Success. 5:00 p.m.
_ m~er 1 Success (status 001) Mic~ay 8:00 a.m.-5:00 p.m.
_ _ In the eml~i~t of the pr~ i~rtiaa beir~ discussed in detail hereîn, cor~ct flags det~mi~e ~ic~h alert destination ~ ~h~uld reoeive an al~rt.
q~e retry ca~nt is in~icated in the ~ flag bits 0-4. I~us for each destinatic~ me ~er it is po6sibl~ to have a differen~ retry count. For example, if me~ber O has ths connect flag set to four, that mmker will have a retry ooun~ of f~ur (5 tries will be made). M~ker 1 cculd have the connect flag set to 5, meaning the re~xy coun~ is five. Zer~ m~2ns d~ nok retry the alert, but the alert will ke tried once.
- 2~72~
Bit 5 and 6 of the connect flags have the following q s when there is an alert to be delivered:
Bit 6,5 ~aning 00 Blank Entry. None of the ale*ts will be delivered to this destination.
01 Alert. Ihe board will establish the ccnnectiQn and deliver the alert to this destination member. Call back feature is di-c~hled.
_ _ _ Call Back. The board will not initiate th2 c ~ ion. If a connection exists the board will deliver the alert. Call back is enabled for this dest mation member.
_ 11 Alert and call back. Ihe board will establish the connection and deliver the alert to this destination memker. Call back feature and alert feature æ e enabled.
With respect to voioe alert prc ce dure m the embodin ent of the present invantiQn being ciscussrd in detail herein, ~ ca~ion between the erhancament board v~ioe cLrcuit ~nd the user is through a touch tone telephone. Upon receiving a voice message from the Enharoen.ent board, thQ us~r needs to ccmmunicate with the b~ard by pressing the apprcpriate touch t~ne butt4n.
;~ Listed below are the step6 for communic~ting with the board Ln ~he embodim.nt of the present invention being disoussed:
1. As soon as dialing has been oompleted by the board, the voice messag~ will state one or re identifica~ion ~ . The koard ~annGt d~tct when the phone has been answered dNe to hardware limltations. Thus ~he messag~ will beqIn as the phone is r m gLng~ In ord#r to allow the user to he~r a complete messag~, the mLssage will rqpeat three times.
Wh~n the user first answers the phone, the nEssage may 2~72~
ke Ln progress~
2. Next, the board will request a password. After the password is entered the user may press ~ to indicate he has ccmpleted the pass~A~nd.
Pleæse enter pass~ord ~ben p~e~s pcund ~n ~.
If the user does nct enter the password within 5 s~conds, the mEssage will be repeated 3 more tLmes ~ before the board~ hangs up the pbcne. If the user :~ 10 ; enters the wrong password and realizes his error before pressing the pound ~ign (#), he may simply type ; an asterisk (*), and then retype the oorrect password ; follcwed by the pound sign (#).
m e user has 3 tries to enter a correct p~sword.
After 3 failures, the board will hang up.
m e k~ard wlll wait up to 5 seoonds for each password digit. If the user fai.ls to enter the ~ext password digit within the limited time, the board will terminate the session an~ hang up ~he phone.
3. After enter ~ a correct ~ , the voice gives the alert message. Fcr example the v~ice may state:
~lert Eessage n~hPr 255. 1~:30 a.~. Jan~ary 5.
4. Next the voiæ will give instructions for repeati~g, continuiny or ending the session:
Press ~ bD ~ , p~ss 2 bD ccn~i~o2, p~ass 3 m e user has 5 seconds to respord befcre the message repeats up ~o a maxImum of 3 times. If the user does not respond, ~e ~ard w~ll t~mina~e the sesslon and hang ~ e ~one. ~re5sing ~ cr 3 marks ~e al~t as success Ln the DestLnation Mbmker Status for that cor¢~t me~.
5. If the user presses 1, the mess~ge will repeat.
m e alert log is a circular buff~r. A ~ of 32 entries, as previously m~n~ioned, are allowed in the buffer. New alerts will ovarwritR any old alerts that are:
o Not Dane (Status = 4) o Dare, or Success (Status = 5) o Invalid (Stat~s = QA) An ~v ~ error will occur if the old alerts are:
o reserved (S~atus = 1) pendin~ (status - 2) o process m g (Skakus = 3) :
"
` ~072~9 Continuing to describe the embodiment of the present invention being discussed functionally, when the Get Alert Log command is issued frcm the remote (i.e., via terminal 34 in FIG.
1), the alert log will appear as it is at that time. Right after viewing, æveral changes occur within the log, and the status of out-of-band al~rts change. These changes occur only on those alert entries that are view2d. Ihe changes will show when the Get Alert Log command is issued aga m.
1. m e alert type Nok D~ne (Status = 4, and 7) will be marked Done (Status = 5~ because those Alerts in the Log that have been viewed, are c~nsidered delivered.
; 2. When the Get Alert Log is lss~ed, the following alert status will not change:
o pending (no attempt has been made to deliver yet, Status = 2) o processing (in the prooess of being delivered, Status = 3), or o invalid (will not be delivered, Status = OA) 3. If the Get Alert c~mmand is issued with the nNmber of entries equal to zero, alert entries status = 4 and 7 will be marked Done on all th2 entries in the lo~ even th~gh none were actually viewed.
The follow ~ effects are valid at the time the Get Alert ~ is ~ssued.
1. The alert log will not contain entries for alerts that ~ were in the process of bein~ ~ to the alert log.
;~ For i ~ , if the alert log ha~ previously stabilized at 32 entries, an~ ~he command is issued while a new one is being built, only 31 will be returnad. One will be displaced (~nly 32 entries are : allowed) and the new one is nok yet valid.
2. If the user requests ~Dre log entri~s than currently exist in the alert log, only those Ln the log will be ~ returned. If the user requests more than 32 entries, ; .
, .. , , ~ , ,~ ; ; . - , .
: - , : : . ' . ::
2072~6~
an invalid log number (18h) error code will be returned.
3. If more alerts have been generated than the alert buffer can hold, new al~rts will be d1scarde~ and a log overrun ~OIh) will show on the Extended Error code when the Get Alert Log comman~ is issued. The log cv~rx~m will be cleared after each Get Alert Log.
Fegarling load configuration, if the board 13 has not been configured, alerts cannct be sent or rrceived. If Lcad Configuration (for reo~nfiguration) is issued while the alert log has any valid entries and a new alert destinati~n list is assigned:
1. All out-of-band alerts that have been delivered to at least one alert destination in ~he old list will be marked Invalid in the Alert Delivery Status. These alerts will not be delivered to any other destinations.
2. If none o~ the alert destinatic~s memkers have received the alert ar an alert s~atus is prooess ~ :
A. The Dest mation Mbmker Status will be zerced out, and the retry ~ filed will ~e updated according to the new ocnfigu~aticn.
B. The Alert ~ livery Sta ~ wqll ~e ~arked NGt Done ~No~ Dvne; Status = 4).
C. Ihe ~ prccess will attempk delivery to the ~; memkers of the n~w Alert Destination list.
e user may receive an alert twice if an alert was in process and reached a d~stination. The retry task will send this alert again aoco ~ to the new Alert Destin~tion list.
Duplicate alert dest ~ tion ~ will be treated separately; the ~ser will reoeiv~ one alert for each time ~hat ~- menber ~ppears in ~he list.
e ccmm~nd Feature Control ~llows the user to disable ,:
~ alert mg by settL~g bit 2 of the Feature Co~trol Flag to 1.
,,.
2072~ ~9 The alert log will change in the ~oll ~ manner:
1. All new alerts will be discarded.
2. All out-of-band Alert Delivery Status will ke marked Invalid (Status = O~h) and will not be delivered. The Destination Mbmber Status will still show which members have received the alert.
3. In-~and alerts will be mark~d Invalid (Stabus = OAh).
If the asynchroncus in~erfa oe has been disabled (bit 2 of Feature Control Flag set to 1):
1. All new alerts will be entered into the alert log.
2. The aut-of-band ~lert Delivery Status (p#nding-Status = 2, and prooessing - Status = 3) will be marked Not Done (Status = 4). These alerts will be delivered later.
3. The retry count will not dbcrement until the asynchronous inter~a oe is rerenabled and alerting resumes.
Discussing now the retry portions of the embod1men~ of the present invention keing descri~ed in detail, the retry caunt, plus one, is the number of tLmes the board 13 wlll try to deliver the alert. If the retry ~ is zerv, the board will still try to delivery the alert at least on~e.
Whenever the bcard fails to deliver the alert m~ss~ye th~
retry count will decrement, t~e board will di#xnnmct the -~ 25 session and txy ~nokher destination member. For a failed alert, the retry interval will ke 6 ~ . A failed alert ~ay cccur because a conn~ction could not b~ established (~ill try ~he next destination member on list) or because ~he r~moke returned a value ~ther than success (will try the first destin2tion memker in the list).
Once there is a valid ConneCtiRn with any destination memker, whether initia~ed ~y ~he board or ~y a remoke, those alerts that have b~en ma~-k0d as Failed will be delivered. mOSe marked as Not to be Delivered (nct the righ~ time an~ date) will -.:: ,. ;
.
~0721g~
also be delivered because the date and time mask only restrict the board from attempting ~ call, not from delivering alerts.
If either of these cases fails to successfully oomplete the delivery of an alert (pxopex respon~e is not reoeived by the board), the board will disconnect.
If a remote calls in that is not in the Destination M~mber list, no alert will be sent to that remote~
Set forth immediately ~el~ are a number of examples of structNre and operation of the e~bcdl=ent of the present invention being discussed in detail herein.
Example 1:
If the user oonfigures the system to have 5 alert destination m~mbers, the bcard will try to establish the connection in order (s~artLng fro~ n~mber 0). Assume the retry count is set to zero (only one try will be made per destination) and there is no date and time mask specified. If the board fails to establish a connection with destination nYmkers O - 2 and suoceeds to establish the connection with an~ sen~ the alert to member 3, the alert log will ~e marked as follows:
Deli~ery S*atu~ = ~ot D~ns; status 4 .
, A~ ~ ~ ~ 5~
_ - -I
mRmber O - ~ ~ailed ., _ . _ ~ member 3 Success ~ _.
member 4 To be delivered, (has ~at been tri0d yet ~ retry count - 0) , ~ m e board could not deliver the alert to members 0 2 and mo~ed on to 3. meSe alerts will nct be tried again becau~e ~he ~ retry coun~ was zero, kut will be delivered if a connection is :~ 35made to these memkers at a la~er tIme. Ihe ~oard has n~t tried ~72~
:
.~
to establish a connection with member 4, 50 the retry count is zero, and the alert will be tried once.
~; The Alert Delivery Status is Not Done (Stabus = 4) b~cause not all the members have been tried.
! 5 Ex3mpl~ 2:
Using the same example, but a retry count of 5 for each destination member and no time and date ~ask:
':
Alert Deli~er status - ~k Dcne; S*atus = 4 . 10 _ _ _ member O - 2 To be delivered--retry ccunt = 4 member 3 oonnecti~n-_disoonn ct.
_ _ member 4 To be delivered retry count - 5 For m ~ 0 - 2, the alert has nat keen delivered, but one try has been made to each. Five more tries wlll be m de to these members. (It should be recalled that a try will be made when the retry count eguals zero.) Member 3 reoeived some other value besides sucoess and was disconnected. The next alert ~o be tried will be mYmber 0.
Member 4 has nok been tried yet.
~xample 3:
Us ~ the same example, with a retry count of 5 for each destination m ~ and nD time and date mask ~his example shows the status before any attempks have been made:
. .
~, : ', ' ' ' " ',, `
~`~ 2~721~9 Aaer~ ~ ~ery status - Not Done; Status = 2 __ ~ Des~ ~ ME~ber S~
member O - 4 Retry = 5; no attempt has been made on any destination.
Example 4:
Using the same example, with a retry count of 5 for each destination memker an~ no time and date mask, thi~ example shows the status as the flrst attempt is in progress:
Alert Deli~ery S*atus - NCt DoRe; StatUs = 3; ~lcessin 1~i _ _ ~
A~ ~ ~ ~ S~
- -m~mber O To be delivered (sta ~ 100); Retry = 5;
EXample 5:
In this example, the retry cou~t is 5 ~or each dstination m ~ , and the date ~nd tLme mask has keen set t~ deliver alerts on Manday 8:00 a.m. - 5:00 p~m. only. Ihe current tLme is MGnday 8:00 a.m.
2~ _ Alert D~livery S$atus - N~t D~e; Stabus - 7 _ _ ~ ~ ~i~ ~ SS~ T~ ~c _ 30 member O Will nok be delivered in current ti~ Friday 8:00 a.m.-frame. (status 011) 5:00 p.m.
- . -member 1 Success (status 001) ~day 8:00 a.m.-5:00 p.m.
_ mÆmber 2 T~ be delivered ~s~a~us 100); ~bn~ay 8:00 a.m.-Retry - 5; 5:00 p.m.
_ , ,',~ . ' :, 2~7~1~9 Member 2 is ~ ntly being prccY~ed, thus the overall Alert Delivery Status is Not Done (Status = 7).
E~ample 6:
In this example, the re.try count is 5, and the date and time mask has been set to deliver alerts on MQn~aY 8:00 a.m. to 5:00 p.m. only. The current time is Monday 8:00 a.m. The entire list has been tried at least once.
A session has keen established by remote destination nember o, thus the alerts marked as Will Not ~e Delivered In Current Time Frame will be delivered. If this same alert had been marked Failed, (retry count was met, no m~re tries will ke made) the alert w~uld ba delivered (Failed ~>Success).
_ _ Alert ~Pli~ery status Nbt Dcne; status - 4 _ _ _ Al~c ~ ~i~ ~r S~us $i~ ~c _ _ me~aer 0 Will ncrt be deliver~ ~n currer~ time Friday 8:00 a.m.-frame.~> Success. 5:00 p.m.
_ m~er 1 Success (status 001) Mic~ay 8:00 a.m.-5:00 p.m.
_ _ In the eml~i~t of the pr~ i~rtiaa beir~ discussed in detail hereîn, cor~ct flags det~mi~e ~ic~h alert destination ~ ~h~uld reoeive an al~rt.
q~e retry ca~nt is in~icated in the ~ flag bits 0-4. I~us for each destinatic~ me ~er it is po6sibl~ to have a differen~ retry count. For example, if me~ber O has ths connect flag set to four, that mmker will have a retry ooun~ of f~ur (5 tries will be made). M~ker 1 cculd have the connect flag set to 5, meaning the re~xy coun~ is five. Zer~ m~2ns d~ nok retry the alert, but the alert will ke tried once.
- 2~72~
Bit 5 and 6 of the connect flags have the following q s when there is an alert to be delivered:
Bit 6,5 ~aning 00 Blank Entry. None of the ale*ts will be delivered to this destination.
01 Alert. Ihe board will establish the ccnnectiQn and deliver the alert to this destination member. Call back feature is di-c~hled.
_ _ _ Call Back. The board will not initiate th2 c ~ ion. If a connection exists the board will deliver the alert. Call back is enabled for this dest mation member.
_ 11 Alert and call back. Ihe board will establish the connection and deliver the alert to this destination memker. Call back feature and alert feature æ e enabled.
With respect to voioe alert prc ce dure m the embodin ent of the present invantiQn being ciscussrd in detail herein, ~ ca~ion between the erhancament board v~ioe cLrcuit ~nd the user is through a touch tone telephone. Upon receiving a voice message from the Enharoen.ent board, thQ us~r needs to ccmmunicate with the b~ard by pressing the apprcpriate touch t~ne butt4n.
;~ Listed below are the step6 for communic~ting with the board Ln ~he embodim.nt of the present invention being disoussed:
1. As soon as dialing has been oompleted by the board, the voice messag~ will state one or re identifica~ion ~ . The koard ~annGt d~tct when the phone has been answered dNe to hardware limltations. Thus ~he messag~ will beqIn as the phone is r m gLng~ In ord#r to allow the user to he~r a complete messag~, the mLssage will rqpeat three times.
Wh~n the user first answers the phone, the nEssage may 2~72~
ke Ln progress~
2. Next, the board will request a password. After the password is entered the user may press ~ to indicate he has ccmpleted the pass~A~nd.
Pleæse enter pass~ord ~ben p~e~s pcund ~n ~.
If the user does nct enter the password within 5 s~conds, the mEssage will be repeated 3 more tLmes ~ before the board~ hangs up the pbcne. If the user :~ 10 ; enters the wrong password and realizes his error before pressing the pound ~ign (#), he may simply type ; an asterisk (*), and then retype the oorrect password ; follcwed by the pound sign (#).
m e user has 3 tries to enter a correct p~sword.
After 3 failures, the board will hang up.
m e k~ard wlll wait up to 5 seoonds for each password digit. If the user fai.ls to enter the ~ext password digit within the limited time, the board will terminate the session an~ hang up ~he phone.
3. After enter ~ a correct ~ , the voice gives the alert message. Fcr example the v~ice may state:
~lert Eessage n~hPr 255. 1~:30 a.~. Jan~ary 5.
4. Next the voiæ will give instructions for repeati~g, continuiny or ending the session:
Press ~ bD ~ , p~ss 2 bD ccn~i~o2, p~ass 3 m e user has 5 seconds to respord befcre the message repeats up ~o a maxImum of 3 times. If the user does not respond, ~e ~ard w~ll t~mina~e the sesslon and hang ~ e ~one. ~re5sing ~ cr 3 marks ~e al~t as success Ln the DestLnation Mbmker Status for that cor¢~t me~.
5. If the user presses 1, the mess~ge will repeat.
6. If the user pre~ses 2, the next alert messzge will be ,~
.
~:~ 2~721~9 heard, or if there are no further alert messages, the erd of session message will oocNr and the board will hang up the phone.
.
~:~ 2~721~9 heard, or if there are no further alert messages, the erd of session message will oocNr and the board will hang up the phone.
7. If the user presses 3, the end of sessiQn message will occur.
~7d af a~ ~.
If the user enters a number other than 1, 2, or 3 when prcmpted, the curre~t alert message will be termlnated and ~he whole alert message will be repeated within 5 seconds. The digit entered will be ignored. Ihe oorrect digit shculd be ; reentered. The user mLst enter a 2 or 3 to acknowledge the message, or the bcard will mHrk the attempt as Failed and disconnect.
If the user enters the pro~pt digit or passwcrd digits before the board has finished the previcus message, the message will be chopped imm~diately and a new message corresponding to the action chosen will occur.
As previously mentioned, alerts can be delivered to a pager. Each pager can only receive one alert per call. The sequence is listed belGw.
1. When an alert is sent t~ a p*ger, the pag~r will display:
~ the five digit server ID followed by - and ~hree :~ digi~cs For ~ leo ~`~ 12345 oo~L
This inlicates ~hat server 12345, has error nLmber 1.
2. The error should be look2d up in a spec prcvided to the user.
~hen a remcte cansole receives an alert a windGws ~`~ application ~r the l~ke can cxeate a wind~w that describes the alert. EffeckLng at least si~ple versions of thiS cperation are well within the ability of those skilled in the art.
;~ Listed belc~ are examples of haw ~he board 13 can announce .
2 ~
the timel date and system ID.
T~
. 5 0:0 Twelve A.M.
_ 0: 30 Twelve thirty A.M.
5:00 Five A.M.
6:06 SLX O six A.M.
9:10 Nine ten A.M.
_ ~ 15 10~15 Ten fifteen A.M.
::~ 11:45 Eleven forty five A.M.
_ 12:00 Twelve P.M.
12:22 Twelve twenty tw~ P.M.
13:35 One thirty five P.M.
22: 30 Ten Thirty P.M.
_ . _ 23:59 Eleven fifty nine P.M.
_ _ _ .
Date: U. S .A~ European _ 1/1 January one anuary : 7/29 July twenty nine Twenty nine July _ _ _ _ 8/17 ALgust sVen~een Seven~ en ALgust - - -9/21 .Sepbember twenty one I~enty one SeQbember _ _ _ 10/5 OctDber five Five Octcber 10/ 6 Octo~ SLX S1X OC~
_ _ 11/20 Ncvember twenty Twenty Novemker __ 12/24 Dece~ber ~wenty four Twenty fGur ~ecember -,: ;: : , ~ : , -~ 2~721~
i ~ ID
_ 12045 one tw~ zero fo~ five _ .
V ~ P~e 125 ar~ e;~ five 200 tw~ hun~ed ~ _ _.
53 fifty three _ ..
105 or~e ~ five 100 c~ne h~ed : , , , - .
~ 2~7~ ~9 .
Embodiments of the present .invention may generate alert messages on bcard 13. The followLng table depic~s six example ~card-generated alerts and their m~anings.
_ _ ~ ~ ~ Ou~-of-S~ect Attrikute N~aning ~and ~and . . .
System S/W Watchdog Sys. no longer communicatLng X
with sys. software.
System S/W Interface Fail Sys. software failed to X
ccmplete a oommand to board or Ln-ban~ alert failed.
15 System H/W Power Fail s. pcwer is bad. _ X
System H/W Reset Sys. reset detecto~. ~
System Mgr H/W Interfaoe Fail EMIC devioe no longer X
; 20 ~unctioning.
~: - - - -: Syste~ ~gr H/W CQmm Fail Ex~ernal mcdem failure. X _ System Mgr H~W Battery Fail board's battery is n~ longer X X
_ function~l. _ , ~ :
,:
; 2~721~9 : -3~-Referri~ now to FIG. 4, there is shown a flow chart illustrating steps in the operatiQn of an embodiment of the present invention. At the top o~ the chart it may be seen that information may come to the board 13 from either host software or bus monitoring. This information can be used to update a portion of randcm access memory if the .Lnformation is, e.g., greater than a thre~hold valu~. This portion of the process of the present invention is indicated by blocks 80, 82 and 84 in the flow chart of FIG. 4. If m -band alert delivery is appropriate, an in-band alert may be issued ~s previously discussed (blocks 86, 88). If out-of-band alert delivery is appropriate, out-of-band alerts ~ay be issued as also previously discussed (blocks 90, 92). ~etrying as discussed herein above is depicted by blo~ks 94, 96 with respect to out-of-band delivery. 5imilar retry mg could be effected in in-band delivery in embodiments of the present invention, as previously discusse1. Once delivery is completed, the prooess is done (block 93).
Those skilled Ln the art should now appreciate that the present invention provides an in-band out-of-band alert delivery system that is much improved over prior art alert delivery ; systems. m e alert deliv2ry system according to th2 teachings of the present invention l R basad upon a very effective underlyiny algorithm which effec~s Fersistent retry ~ and alert delivery to a number of different ~ of al~rt reoeivers. The alert delivery sys~em aocording t~ the tea ~ s of the present invention is well suib0d to delivery alerts with respect to EISA-based components in data commMmication network env~rorm~ts.
m ose skilled in the art will r ~ ze that ma~y modifications an~ vari~tions kesides ~ho~e qpecifically mentioned may be made in the techniques dbscribed hexein without departing sukstan~ially frcm the concept o~ the present mYention. Ascordingly, it shculd be clearly umderstcod that ~7216~
; -33-.; .
the forms of the invention as descri~ed herein are exemplary only and are not intended as a limitation on the sccpe of the invention.
'
~7d af a~ ~.
If the user enters a number other than 1, 2, or 3 when prcmpted, the curre~t alert message will be termlnated and ~he whole alert message will be repeated within 5 seconds. The digit entered will be ignored. Ihe oorrect digit shculd be ; reentered. The user mLst enter a 2 or 3 to acknowledge the message, or the bcard will mHrk the attempt as Failed and disconnect.
If the user enters the pro~pt digit or passwcrd digits before the board has finished the previcus message, the message will be chopped imm~diately and a new message corresponding to the action chosen will occur.
As previously mentioned, alerts can be delivered to a pager. Each pager can only receive one alert per call. The sequence is listed belGw.
1. When an alert is sent t~ a p*ger, the pag~r will display:
~ the five digit server ID followed by - and ~hree :~ digi~cs For ~ leo ~`~ 12345 oo~L
This inlicates ~hat server 12345, has error nLmber 1.
2. The error should be look2d up in a spec prcvided to the user.
~hen a remcte cansole receives an alert a windGws ~`~ application ~r the l~ke can cxeate a wind~w that describes the alert. EffeckLng at least si~ple versions of thiS cperation are well within the ability of those skilled in the art.
;~ Listed belc~ are examples of haw ~he board 13 can announce .
2 ~
the timel date and system ID.
T~
. 5 0:0 Twelve A.M.
_ 0: 30 Twelve thirty A.M.
5:00 Five A.M.
6:06 SLX O six A.M.
9:10 Nine ten A.M.
_ ~ 15 10~15 Ten fifteen A.M.
::~ 11:45 Eleven forty five A.M.
_ 12:00 Twelve P.M.
12:22 Twelve twenty tw~ P.M.
13:35 One thirty five P.M.
22: 30 Ten Thirty P.M.
_ . _ 23:59 Eleven fifty nine P.M.
_ _ _ .
Date: U. S .A~ European _ 1/1 January one anuary : 7/29 July twenty nine Twenty nine July _ _ _ _ 8/17 ALgust sVen~een Seven~ en ALgust - - -9/21 .Sepbember twenty one I~enty one SeQbember _ _ _ 10/5 OctDber five Five Octcber 10/ 6 Octo~ SLX S1X OC~
_ _ 11/20 Ncvember twenty Twenty Novemker __ 12/24 Dece~ber ~wenty four Twenty fGur ~ecember -,: ;: : , ~ : , -~ 2~721~
i ~ ID
_ 12045 one tw~ zero fo~ five _ .
V ~ P~e 125 ar~ e;~ five 200 tw~ hun~ed ~ _ _.
53 fifty three _ ..
105 or~e ~ five 100 c~ne h~ed : , , , - .
~ 2~7~ ~9 .
Embodiments of the present .invention may generate alert messages on bcard 13. The followLng table depic~s six example ~card-generated alerts and their m~anings.
_ _ ~ ~ ~ Ou~-of-S~ect Attrikute N~aning ~and ~and . . .
System S/W Watchdog Sys. no longer communicatLng X
with sys. software.
System S/W Interface Fail Sys. software failed to X
ccmplete a oommand to board or Ln-ban~ alert failed.
15 System H/W Power Fail s. pcwer is bad. _ X
System H/W Reset Sys. reset detecto~. ~
System Mgr H/W Interfaoe Fail EMIC devioe no longer X
; 20 ~unctioning.
~: - - - -: Syste~ ~gr H/W CQmm Fail Ex~ernal mcdem failure. X _ System Mgr H~W Battery Fail board's battery is n~ longer X X
_ function~l. _ , ~ :
,:
; 2~721~9 : -3~-Referri~ now to FIG. 4, there is shown a flow chart illustrating steps in the operatiQn of an embodiment of the present invention. At the top o~ the chart it may be seen that information may come to the board 13 from either host software or bus monitoring. This information can be used to update a portion of randcm access memory if the .Lnformation is, e.g., greater than a thre~hold valu~. This portion of the process of the present invention is indicated by blocks 80, 82 and 84 in the flow chart of FIG. 4. If m -band alert delivery is appropriate, an in-band alert may be issued ~s previously discussed (blocks 86, 88). If out-of-band alert delivery is appropriate, out-of-band alerts ~ay be issued as also previously discussed (blocks 90, 92). ~etrying as discussed herein above is depicted by blo~ks 94, 96 with respect to out-of-band delivery. 5imilar retry mg could be effected in in-band delivery in embodiments of the present invention, as previously discusse1. Once delivery is completed, the prooess is done (block 93).
Those skilled Ln the art should now appreciate that the present invention provides an in-band out-of-band alert delivery system that is much improved over prior art alert delivery ; systems. m e alert deliv2ry system according to th2 teachings of the present invention l R basad upon a very effective underlyiny algorithm which effec~s Fersistent retry ~ and alert delivery to a number of different ~ of al~rt reoeivers. The alert delivery sys~em aocording t~ the tea ~ s of the present invention is well suib0d to delivery alerts with respect to EISA-based components in data commMmication network env~rorm~ts.
m ose skilled in the art will r ~ ze that ma~y modifications an~ vari~tions kesides ~ho~e qpecifically mentioned may be made in the techniques dbscribed hexein without departing sukstan~ially frcm the concept o~ the present mYention. Ascordingly, it shculd be clearly umderstcod that ~7216~
; -33-.; .
the forms of the invention as descri~ed herein are exemplary only and are not intended as a limitation on the sccpe of the invention.
'
Claims (5)
PROPERTY OR PRIVILEGE IS CLAIMED ARE DEFINED AS FOLLOWS:
1. For a computer network having at least one computer system operatable therein, said computer system having a plurality of components interconnected by a system bus for transferring information between said components, a manager for said computer system, comprising:
means for monitoring information transfers along said system bus;
a processor connected to said monitoring means, said processor determining alert conditions based upon said monitored information transfers and generating alerts upon determining said alert conditions;
a console for receiving alerts from said processor; and means for transferring said alerts generated by said processor to said console, said means for transferring alerts comprising:
a preconfigured log specifying how a detected alert should be delivered;
means for delivering alerts out-of-band;
means for transmitted alerts to be delivered to the appropriate delivery means based upon information in said preconfigured log;
means for determining whether an alert is successfully delivered; and means for retrying delivery of an unsuccessfully delivered alert until that alert is successfully delivered.
means for monitoring information transfers along said system bus;
a processor connected to said monitoring means, said processor determining alert conditions based upon said monitored information transfers and generating alerts upon determining said alert conditions;
a console for receiving alerts from said processor; and means for transferring said alerts generated by said processor to said console, said means for transferring alerts comprising:
a preconfigured log specifying how a detected alert should be delivered;
means for delivering alerts out-of-band;
means for transmitted alerts to be delivered to the appropriate delivery means based upon information in said preconfigured log;
means for determining whether an alert is successfully delivered; and means for retrying delivery of an unsuccessfully delivered alert until that alert is successfully delivered.
2. A system manger according to claim 1 wherein said console is remotely located and whereby said means for transferring said alerts generated by said processor to said console further comprises interface means for asynchronously transferring said alerts to said remote console.
3. A system manager according to claim 2 wherein said computer network further comprises a network manager and a local console accessible to said network manager via said network, and wherein said system manager further comprises:
means for interfacing with said network manager, said interfacing means providing far the transfer of alerts from said processor to said network manager;
wherein said alerts generated by said processor may be selectively delivered to said remote console via said asynchronous transfer means or to said local console via said network manager.
means for interfacing with said network manager, said interfacing means providing far the transfer of alerts from said processor to said network manager;
wherein said alerts generated by said processor may be selectively delivered to said remote console via said asynchronous transfer means or to said local console via said network manager.
4. A system manager according to claim 2 wherein said system manager further comprises a telephone and said means for transferring alerts further comprises a modem connected to said processor, wherein said alerts generated by said processor may be selectively delivered to said remote console via said asynchronous transfer interface means or to said telephone via said modem.
5. A system manager according to claim 2 wherein said system manager further comprises a pager and said means for transferring alerts further comprises a modem connected to said processor, wherein said alerts generated by said processor may be selectively delivered to said remote console via said asynchronous transfer interface means or to said pager via said modem.
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US72025891A | 1991-06-24 | 1991-06-24 | |
| US720,258 | 1991-06-24 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CA2072169A1 true CA2072169A1 (en) | 1992-12-25 |
Family
ID=24893311
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CA002072169A Abandoned CA2072169A1 (en) | 1991-06-24 | 1992-06-23 | In-band/out-of-band alert delivery system |
Country Status (5)
| Country | Link |
|---|---|
| US (2) | US5764886A (en) |
| EP (1) | EP0520770B1 (en) |
| AT (1) | ATE159363T1 (en) |
| CA (1) | CA2072169A1 (en) |
| DE (1) | DE69222697T2 (en) |
Families Citing this family (57)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CA2072169A1 (en) * | 1991-06-24 | 1992-12-25 | Lih-Juan L. Danielson | In-band/out-of-band alert delivery system |
| GB9301286D0 (en) * | 1993-01-22 | 1993-03-17 | Int Computers Ltd | Data processing system |
| EP0765560A1 (en) * | 1994-06-08 | 1997-04-02 | Hughes Aircraft Company | Apparatus and method for hybrid network access |
| US6701370B1 (en) | 1994-06-08 | 2004-03-02 | Hughes Electronics Corporation | Network system with TCP/IP protocol spoofing |
| US6182157B1 (en) * | 1996-09-19 | 2001-01-30 | Compaq Computer Corporation | Flexible SNMP trap mechanism |
| US7444394B2 (en) * | 1997-02-03 | 2008-10-28 | Canon Kabushiki Kaisha | Network data base control device and method thereof |
| US5864850A (en) * | 1997-02-27 | 1999-01-26 | Apple Computer, Inc. | Asynchronous-event opening component of a network component system |
| US6425006B1 (en) * | 1997-05-13 | 2002-07-23 | Micron Technology, Inc. | Alert configurator and manager |
| US6553416B1 (en) | 1997-05-13 | 2003-04-22 | Micron Technology, Inc. | Managing computer system alerts |
| US6134615A (en) | 1997-05-13 | 2000-10-17 | Micron Electronics, Inc. | System for facilitating the replacement or insertion of devices in a computer system through the use of a graphical user interface |
| US6389464B1 (en) * | 1997-06-27 | 2002-05-14 | Cornet Technology, Inc. | Device management system for managing standards-compliant and non-compliant network elements using standard management protocols and a universal site server which is configurable from remote locations via internet browser technology |
| JPH1155447A (en) * | 1997-08-07 | 1999-02-26 | Toshiba Corp | Device for inputting image information and its method |
| US6308206B1 (en) * | 1997-09-17 | 2001-10-23 | Hewlett-Packard Company | Internet enabled computer system management |
| US5937329A (en) * | 1997-10-29 | 1999-08-10 | Northern Telecom Limited | System and method for displaying local messages over a satellite television picture |
| WO1999053627A1 (en) | 1998-04-10 | 1999-10-21 | Chrimar Systems, Inc. Doing Business As Cms Technologies | System for communicating with electronic equipment on a network |
| US6532497B1 (en) * | 1998-04-14 | 2003-03-11 | International Business Machines Corporation | Separately powered network interface for reporting the activity states of a network connected client |
| US6230198B1 (en) * | 1998-09-10 | 2001-05-08 | International Business Machines Corporation | Server-to-server event logging |
| US6167383A (en) * | 1998-09-22 | 2000-12-26 | Dell Usa, Lp | Method and apparatus for providing customer configured machines at an internet site |
| US6934255B1 (en) | 1999-02-02 | 2005-08-23 | Packeteer, Inc. | Internet over satellite apparatus |
| US6674553B1 (en) * | 1999-04-09 | 2004-01-06 | Canon Denshi Kabushiki Kaisha | Image reading apparatus and image processing system |
| EP1045549A1 (en) * | 1999-04-15 | 2000-10-18 | International Business Machines Corporation | System and method for non intrusive monitoring and management of distributed data networks |
| US20020099886A1 (en) * | 1999-05-17 | 2002-07-25 | Emerson Theodore F. | System and method for controlling remote console functionality assist logic |
| SE518104C2 (en) * | 2000-06-13 | 2002-08-27 | Saab Ab | Software maintenance system and method |
| US7213077B2 (en) * | 2000-07-21 | 2007-05-01 | Hughes Network Systems, Inc. | Method and system for providing buffer management in a performance enhancing proxy architecture |
| US6980790B1 (en) * | 2000-11-27 | 2005-12-27 | Lucent Technologies Inc. | Intermittent, low bandwidth, wireless data network and method of operation thereof |
| US7127722B2 (en) * | 2001-06-18 | 2006-10-24 | Intel Corporation | Method and apparatus for avoiding multiple processing of the same IPMI system event |
| DE10130309A1 (en) * | 2001-06-22 | 2003-01-02 | Mes Gmbh | System for monitoring and operating automatic systems |
| US7546354B1 (en) * | 2001-07-06 | 2009-06-09 | Emc Corporation | Dynamic network based storage with high availability |
| JP2003150359A (en) * | 2001-11-15 | 2003-05-23 | Minolta Co Ltd | System, device and method for informing abnormality |
| US20030208361A1 (en) * | 2002-05-02 | 2003-11-06 | Belinne Daryl Jarvis | Configuration of systems with services |
| US7325140B2 (en) * | 2003-06-13 | 2008-01-29 | Engedi Technologies, Inc. | Secure management access control for computers, embedded and card embodiment |
| US7171467B2 (en) * | 2002-06-13 | 2007-01-30 | Engedi Technologies, Inc. | Out-of-band remote management station |
| US7102767B2 (en) | 2002-07-19 | 2006-09-05 | Kabushiki Kaisha Toshiba | Print module for direct multiple image formatting and printing |
| US7343398B1 (en) | 2002-09-04 | 2008-03-11 | Packeteer, Inc. | Methods, apparatuses and systems for transparently intermediating network traffic over connection-based authentication protocols |
| US7132953B2 (en) * | 2003-06-26 | 2006-11-07 | Lear Corporation | Spring sensor assembly for a vehicle seat cushion |
| US20050049932A1 (en) * | 2003-09-03 | 2005-03-03 | Howell James A. | Process for managing subscription service purchases |
| FR2859556B1 (en) * | 2003-09-05 | 2005-11-11 | Airbus France | METHOD AND DEVICE FOR MAINTENANCE OF A RADIONAVIGATION EQUIPMENT OF AN AIRCRAFT |
| US20050071270A1 (en) * | 2003-09-26 | 2005-03-31 | Ramirez Christopher W. | Process for remote recovery and creation of machine specific authentication keys for systems |
| US7519826B2 (en) * | 2003-10-01 | 2009-04-14 | Engedi Technologies, Inc. | Near real-time multi-party task authorization access control |
| US8509097B1 (en) * | 2004-08-05 | 2013-08-13 | Cisco Technology, Inc. | Network accessibility to any network attached device during reboot and power loss |
| US7817157B2 (en) | 2004-08-23 | 2010-10-19 | Hewlett-Packard Company, L.P. | Method and apparatus for capturing slices of video data |
| US20060122894A1 (en) * | 2004-12-03 | 2006-06-08 | Mcgary Jon | User configured order status updates |
| US20060193462A1 (en) * | 2005-02-28 | 2006-08-31 | Gregg Hansen | System for optimizing configurable information handling systems |
| US20060291645A1 (en) * | 2005-06-08 | 2006-12-28 | Vasu Mekala | Needs based offer |
| JP4831599B2 (en) | 2005-06-28 | 2011-12-07 | ルネサスエレクトロニクス株式会社 | Processing equipment |
| US7623684B2 (en) * | 2005-07-19 | 2009-11-24 | Dell Products, L.P. | System and method for information handling system software registration code management |
| US8036127B2 (en) * | 2006-07-20 | 2011-10-11 | Oracle America, Inc. | Notifying network applications of receive overflow conditions |
| US8108289B2 (en) * | 2007-07-09 | 2012-01-31 | Chicago Mercantile Exchange, Inc. | Market data recovery |
| US7660539B2 (en) * | 2007-07-11 | 2010-02-09 | Dell Products, L.P. | Printer consumable ordering direct from printer |
| US8792341B2 (en) * | 2010-10-27 | 2014-07-29 | Futurewei Technologies, Inc. | System and method for machine-to-machine application based congestion control |
| CN102571465A (en) * | 2010-12-21 | 2012-07-11 | 鸿富锦精密工业（深圳）有限公司 | Abnormality warning system and method for server |
| US10514713B2 (en) | 2012-09-15 | 2019-12-24 | Ademco Inc. | Mailbox data storage system |
| US10992494B2 (en) | 2012-09-15 | 2021-04-27 | Ademco Inc. | Gateway round-robin system |
| US9705962B2 (en) | 2012-09-15 | 2017-07-11 | Honeywell International Inc. | Asynchronous reporting system |
| US9122255B2 (en) * | 2012-09-15 | 2015-09-01 | Honeywell International Inc. | Remote access gateway configurable control system |
| US11226756B2 (en) * | 2018-07-26 | 2022-01-18 | EMC IP Holding Company LLC | Indirect storage data transfer |
| CN113312241A (en) * | 2021-06-29 | 2021-08-27 | 中国农业银行股份有限公司 | Abnormal alarm method, access log generation method and operation and maintenance system |
Family Cites Families (25)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US3996423A (en) * | 1975-11-18 | 1976-12-07 | Bell Telephone Laboratories, Incorporated | Common control failure alarm apparatus |
| US4298860A (en) * | 1980-03-10 | 1981-11-03 | Control Data Corporation | Monitor and control apparatus |
| WO1983001851A1 (en) * | 1981-11-23 | 1983-05-26 | Burroughs Corp | Peripheral unit adapted to monitor input/output interface |
| US4633246A (en) * | 1984-01-09 | 1986-12-30 | Fiberlan, Inc. | Time divison multiplex ring |
| US4703325A (en) * | 1984-10-22 | 1987-10-27 | Carrier Corp. | Remote subsystem |
| US4748654A (en) * | 1986-04-21 | 1988-05-31 | William Gray | Remote supervisory monitoring and control system |
| US4996703A (en) * | 1986-04-21 | 1991-02-26 | Gray William F | Remote supervisory monitoring and control apparatus connected to monitored equipment |
| US4791658A (en) * | 1986-07-09 | 1988-12-13 | Theodore Simon | Integrated alarm and touch tone telephone system |
| US4817080A (en) * | 1987-02-24 | 1989-03-28 | Digital Equipment Corporation | Distributed local-area-network monitoring system |
| US4964065A (en) * | 1987-03-12 | 1990-10-16 | Decibel Products, Inc. | Computer-controlled electronic system monitor |
| US4856047A (en) * | 1987-04-29 | 1989-08-08 | Bd Systems, Inc. | Automated remote telemetry paging system |
| US4965772A (en) * | 1987-06-15 | 1990-10-23 | International Business Machines Corporation | Method and apparatus for communication network alert message construction |
| US4823345A (en) * | 1987-06-15 | 1989-04-18 | International Business Machines Corp. | Method and apparatus for communication network alert record identification |
| US5049873A (en) * | 1988-01-29 | 1991-09-17 | Network Equipment Technologies, Inc. | Communications network state and topology monitor |
| US4951029A (en) * | 1988-02-16 | 1990-08-21 | Interactive Technologies, Inc. | Micro-programmable security system |
| US4893307A (en) * | 1988-02-29 | 1990-01-09 | International Business Machines Corporation | Method and apparatus for linking SNA terminals to an SNA host over a packet switched communications network |
| US5251302A (en) * | 1988-04-11 | 1993-10-05 | Square D Company | Network interface board having memory mapped mailbox registers including alarm registers for storing prioritized alarm messages from programmable logic controllers |
| US5119377A (en) * | 1989-06-16 | 1992-06-02 | International Business Machines Corporation | System and method for software error early detection and data capture |
| US5155842A (en) * | 1989-08-14 | 1992-10-13 | Microsoft Corporation | Logical event notification method and apparatus |
| US5063523A (en) * | 1989-11-16 | 1991-11-05 | Racal Data Communications Inc. | Network management system with event rule handling |
| US5163151A (en) * | 1990-03-22 | 1992-11-10 | Square D Company | System for processing and prioritizing alarms from devices on data communications network |
| US5136594A (en) * | 1990-06-14 | 1992-08-04 | Acer Incorporated | Method and apparatus for providing bus parity |
| US5210866A (en) * | 1990-09-12 | 1993-05-11 | Storage Technology Corporation | Incremental disk backup system for a dynamically mapped data storage subsystem |
| CA2072169A1 (en) * | 1991-06-24 | 1992-12-25 | Lih-Juan L. Danielson | In-band/out-of-band alert delivery system |
| US5603523A (en) * | 1995-08-24 | 1997-02-18 | General Motors Corporation | Bias flap for air bag module |
-
1992
- 1992-06-23 CA CA002072169A patent/CA2072169A1/en not_active Abandoned
- 1992-06-24 EP EP92305802A patent/EP0520770B1/en not_active Expired - Lifetime
- 1992-06-24 DE DE69222697T patent/DE69222697T2/en not_active Expired - Lifetime
- 1992-06-24 AT AT92305802T patent/ATE159363T1/en not_active IP Right Cessation
-
1995
- 1995-11-27 US US08/562,780 patent/US5764886A/en not_active Expired - Lifetime
-
1998
- 1998-06-02 US US09/089,040 patent/US6473795B1/en not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| EP0520770B1 (en) | 1997-10-15 |
| EP0520770A2 (en) | 1992-12-30 |
| EP0520770A3 (en) | 1993-11-18 |
| US6473795B1 (en) | 2002-10-29 |
| DE69222697D1 (en) | 1997-11-20 |
| DE69222697T2 (en) | 1998-04-09 |
| US5764886A (en) | 1998-06-09 |
| ATE159363T1 (en) | 1997-11-15 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CA2072169A1 (en) | In-band/out-of-band alert delivery system | |
| JP3805951B2 (en) | Image forming apparatus management system and management method | |
| EP0475080A2 (en) | Distributed messaging system and method | |
| JPH10116254A (en) | Decentralized computer system | |
| CN101160818A (en) | Equipment port monitoring system and method | |
| JP2000165433A5 (en) | ||
| EP1145201A1 (en) | Event notification within a local system | |
| US5892432A (en) | Personal computer control and activation device utilizing a paging message | |
| US6154129A (en) | Operation system for transmission devices and alarm monitoring method | |
| CN111262731A (en) | Alarm method, alarm device, server equipment and storage medium | |
| CN109194738A (en) | Remote reboot method, routing development board and hardware bottom plate | |
| KR100580103B1 (en) | The method for Server Process Remote Monitoring of the Telecommunication Network Management System | |
| JP2001202307A (en) | Network system, terminal equipment and information transmitting method | |
| JP4026606B2 (en) | Uninterruptible power supply management system | |
| KR100299030B1 (en) | Method for remotely monitering maintenance of pabx system using internet | |
| JPH04242396A (en) | Remote supervisory system | |
| JPH05191494A (en) | Monitor | |
| KR930004919B1 (en) | Maintenance method | |
| JPH08237249A (en) | Network management system | |
| KR19990054464A (en) | Network Management Method in Network Management System | |
| JPH09284392A (en) | Exchange system | |
| JPH05204862A (en) | Operation stopping state display system | |
| JPH1070617A (en) | Building management system | |
| JPH06141095A (en) | Monitoring device | |
| CN113806166A (en) | Object monitoring method and device, storage medium and electronic equipment |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| FZDE | Discontinued |