In this subdirectory sample files are provided which illustrate the use of
the "Action on Events" feature of HP Hub Manager and HP Interconnect Manager.
The sample files are divided into four groups of files:

DOS batch file example - This is an example of how a DOS batch (.BAT) file 
		can be used to examine some of the information which is 
		available when an event occurs, and to use this information 
		to determine what action (if any) to take. 

Beeper paging example - This example demonstrates one method of causing the 
		manager to page an alphanumeric beeper, and to display an 
  	        informative message on that beeper when an event occurs
	        on the network.  

Windows Recorder example - This example demonstrates the use of the Windows
		Recorder application to cause the manager itself to perform
		some of its functions automatically when an event occurs.

Windows/C program example - This is an advanced example for those who may
		have a programmer available.  It gives an example of how a 
		Windows program written in the C language can be used to 
		examine some of the information available when an event 
		occurs, and to use this information to determine what action 
		(if any) to take.  

After listing the sample files for each example, instructions are given on
how to test the example provided with the manager.  (Note that for some
examples, notably beeper paging, you may need additional hardware and/or 
software.)

Of course, for each example, after you have set up the appropriate files and
parameters, you will need to generate an "event" with Hub or Interconnect
Manager.  An easy way to do this is to arm the "Soft reset" event on a hub or
bridge, and then request a "Soft reset" of that device with the manager.

After instructions on testing the examples as they are provided, there is
information provided on how to customize each of the examples.  

For more information on "Action on Events", see the "User Guide" and the 
"Technical Reference Guide" for HP Hub Manager and HP Interconnect Manager.


DOS Batch file example
----------------------

BAT\AOETEST.BAT - This is an example of how a DOS batch (.BAT) file can be
 	     used to examine some of the information which is available when 
	     an event occurs, and to use this information to determine what
             action (if any) to take.  This example examines the name of
	     the event, the label of the device on which the event occurred,
	     and the time of day at which the event occurred, to decide
	     whether or not to display a message on the screen, and to
	     decide which message to display.

BAT\COMPARE.C  - Since comparisons in DOS .BAT files are limited to equality,
	     we wrote a short program which is used in AOETEST.BAT to compare
	     the time of day against time strings representing 5:00 PM and
             7:00 AM.  This tells the .BAT file whether the event occurred
	     during normal working hours or not.

BAT\COMPARE.EXE- The executable of the above program.

You can test this example by setting the Action on Events parameters as 
follows:

    EventActionFile = <path>\AOETEST.BAT
    EventActionParms = TRUE
    EventActionShow = 1 (Normal)
    EventActionInterval >= 20 (so PC not overwhelmed with new DOS sessions)

BAT\AOETEST.PIF - This is a sample .PIF file which can be used to cause a .BAT
	     file (e.g. AOETEST.BAT) to run in a window.  (You must be running
	     Windows in "Enhanced" mode.)  To do this, you specify the .PIF
	     file (e.g. AOETEST.PIF) as the ActionFile to be executed when 
	     an event occurs.  Then within the .PIF file (using the Windows
	     "PIF Editor" program) you set "Program Filename" to the .BAT
	     file you want executed (e.g. AOETEST.BAT), "Start-up Directory" 
	     to the subdirectory which contains that .BAT file, and "Display
	     Usage" to "Windowed".

You can test this example by setting the Action on Events parameters as 
follows:

	EventActionFile = <path>\AOETEST.PIF
	EventActionParms = TRUE
	EventActionShow = 1 (Normal)
	EventActionInterval >= 20

You will also need to edit the file AOETEST.PIF so that "Start-up Directory"
points to the subdirectory which contains the file AOETEST.BAT.

You can customize this example by editing the file AOETEST.BAT, following the
examples there, to select for the events, devices, etc. on which you want
action taken, and choose a different message to be echoed (or any other action 
which can be implemented from a DOS program) for each case.


Beeper Paging Example
---------------------

PAGE\PAGER.BAT  - These two .BAT files demonstrate one method of causing the 
PAGE\PAGER2.BAT manager to page an alphanumeric beeper, and to display an 
  	        informative message on that beeper when an event occurs
	        on the network.  The copy of PAGER.BAT which is supplied 
		does minimal filtering of the event which comes in.  It does 
		the paging only for two events: "Warm_reset" and 
		"Bytes_received".  But you can easily add additional
		filtering following the example of the file AOETEST.BAT listed
		above.  The message displayed is "<Event> on device <Label>", 
		but it could be any combination you want of pre-defined text 
		and the eight pieces of variable information which are 
		provided when an event occurs.

For this particular example, you will need a modem in your manager PC which 
is connected to an outside phone line, an alpha-numeric pager, the paging
software PcPAGE 2 (available from Metriplex Inc. of Cambridge, MA), access
to an alphanumeric paging dispatch service supported by PcPAGE2 (e.g.,
SkyPager from SkyTel), and the Norton Utilities (available from Symantec 
Corporation of Cupertino, CA).  Other combinations of software will give
you the same results.  This is just one example which we have used to
demonstrate paging.

The steps needed to prepare for a demo of the sample files are these
(assuming you already have a modem installed and connected to a phone
line, and that you have an alphanumeric pager, and access to an alphanumeric 
paging dispatch service):

1. Install Norton Utilitites (e.g., in C:\NORTON).
2. Modify config.sys to load a certain Norton Utilities TSR on bootup:
	DEVICE=c:\norton\keystack.sys
3. Install PcPAGE 2 (e.g., in C:\PCPAGE).
4. Run the PcPAGE 2 configuration utility. CONFIG.COM, to define the
   pager type, modem port, paging dispatch service type, name and phone 
   number, baud rate, etc., and to define all of the user names and pager 
   numbers you want to use.  The sample files provided are set up to
   page the beeper of the second user in the list of users.

You can test this example by setting the Action on Events parameters as
follows:

	EventActionFile = <path>\pager.bat
	EventActionParms = TRUE
	EventActionShow = 1 (Normal)
	EventActionInterval >= 90

Notice that the EventActionInterval is set fairly high (90 seconds) to
allow the PCPAGE software plenty of time to make the connection to the
dispatch service and pass along the pager id number and the message
before another event causes it to try again.  In fact, you may want to
set this even higher; e.g., to 7200 (2 hours) so that the person being
paged has sufficient time time to respond to the page before being paged
again.

PAGE\PAGER.PIF - This is a sample .PIF file which can be used to make a .BAT
	     file (e.g. PAGER.BAT) run in a window.  (You must be running
	     Windows in "Enhanced" mode.)  To do this, you specify the .PIF
	     file (e.g. PAGER.PIF) as the ActionFile to be executed when 
	     an event occurs.  Then within the .PIF file (using the Windows
	     "PIF Editor" program) you set "Program Filename" to the .BAT
	     file you want executed (e.g. PAGER.BAT), "Start-up Directory" 
	     to the subdirectory which contains that .BAT file, and "Display
	     Usage" to "Windowed".

You can test this example by setting the Action on Events parameters as
follows:

	EventActionFile = <path>\pager.pif
	EventActionParms = TRUE
	EventActionShow = 1 (Normal)
	EventActionInterval >= 90


You will also need to edit the file PAGER.PIF so that "Start-up Directory"
points to the subdirectory which contains the file PAGER.BAT.

You can customize this example by modifying the file PAGER.BAT.  The copy
of PAGER.BAT which is supplied does minimal filtering of the event which
comes in.  It does the paging only for two events: "Warm_reset" and 
"Bytes_received"; it always pages the second paging user in the list
maintained by PcPAGE 2; and it always sends the message: "<Event> on
device <Label>".  You can add more sophisticated decision-making about
when to page by following the example in AOETEST.BAT listed above.  You
can also change which user is paged, and what message is sent.  To do so,
you will have to understand a little about what is going on in the ninth
line of the file PAGER.BAT.  This is the line that begins "echo KEYSTACK ...".
The program PcPAGE 2 will not take command line or file input, but requires
a user at the keyboard.  The Norton Utilities TSR "keystack.sys" and the
Norton command interpreter, NDOS, are used to get around this.  The ninth line 
loads keystrokes into a buffer which will later be played back to the program 
PcPAGE 2, as if someone were typing them at the keyboard.  The PAGER.BAT file 
provided shows these keystrokes being stored away:

	0 13	Enter   - This moves PcPAGE 2 from the title screen to the
			  main screen of the program.
	0  9	Tab     - This moves the highlight down one in the list of
                          users maintained by PcPAGE 2.
        0 13    Enter   - This selects the currently highlighted user (the
			  second one) as the one to receive the paging message.
        @60     F2      - This moves the cursor down into the area where the
                          pagin message is to be typed.
	"%3" " on device " "%5" - This is the paging message; when in it typed
			  by this scheme into the message buffer of PcPAGE 2,
			  the "%3" is replaced by the name of the event, and
			  the "%5" is replaced by the label of the device on
			  which the event occurred.
	@61	F3	- This causes PcPAGE 2 to actually do the paging; i.e.,
			  dial up the paging dispatch service, pass it the 
			  pager id number of the second user, and pass it the
			  message provided.  The dispatch service in turn, 
			  sends out a radio signal to the selected pager 
			  causing the pager to beep, and the message to appear 
			  on its screen.
	27	Esc	- These three escape keys make sure that the PcPAGE 2
			  program is exited from.

Therefore, to change which user is paged, simply stack more or less keystrokes
of the form "0 9".  If each user's name begins with a different letter of the
alphabet, you can also stack the letter of the alphabet which begins the
desired user's name (in quotes) in place of any "0 9" keystrokes.  To change
the message, simply replace "%3" " on device " "%5" with the message of your
choice which may involve any combination of literals and the eight parameters
of event information which are supplied to the .BAT file.


Windows Recorder example
------------------------

RECORD\AOETEST.REC - This macro file for the Windows "Recorder" program 
	    contains a macro which operates on the manager, starting a graph 
	    of certain objects for the device which is currently highlighted 
	    on the map.  With the proper Action on Events settings, this 
	    device will be the one on which an event has just occurred.  
	    The idea of this example is that the manager itself can perform 
	    some of its functions automatically when triggered by an event.  
            Another example might be starting a log file of certain
            counters for the device on which the event occurred.  Remember
            though that the current Windows Recorder has a lot of 
	    limitations (many are covered below) which (for now) limit the 
	    usefulness of this approach.

You can test this example by setting the Action on Events parameters as
follows:

	EventActionFile = <drive>:\windows\recorder.exe -h F2 <path>\aoetest.rec
	EventActionParms = FALSE
	EventActionShow = 6 (Minimize)
	EventActionHighlightSwitch = TRUE
	EventActionInterval >= 60

Note the use of the -h option which causes the Windows Recorder to not only
open the file <path>\aoetest.rec, but also to begin immediately to play back 
the macro represented by the short-cut key F2.  Also the passing of parameters
has been turned off, since unfortunately there is no way to pass parameters to
a Windows Recorder macro; and worse, if additional parameters are tacked on to
the end of the command line, the Windows Recorder objects, and does not play
back the requested macro.  Note also the use of the EventActionHighlightSwitch
parameter.  This causes the selection in the OpenView map to move to the device
on which the event occurred before the action is taken.  In this way, a macro
which is written to act on the currently highlighted device will automatically
act on the device which caused the event.

You can customize this example by recording your own Recorder macros and 
having them played back with Action on Events.  Just keep in mind a few 
limitations of this approach:

1) Use the mouse as little as possible; mouse clicks are not as reliable in 
   macros as keystrokes.  Most actions in the manager can be done with 
   keystrokes.

2) Since you can't edit Recorder macros, you will find it less frustrating
   to record a long macro in smaller pieces, and then put them together in a
   super macro.  

3) It is not possible to pass a parameter to a Recorder macro.  Therefore
   the simplistic approach shown so far requires a single macro which must
   apply to all events and all devices.

   A more sophisticated approach would combine a Windows/C program, like that
   in the fourth example below, plus multiple recorder macros.  The program
   would examine the information about the event which had occurred, and then
   decide which macro (if any) to play back based on that information.  The
   program would then call the WinExec procedure of Windows to start the
   Windows Recorder, and pass it the name of the macro file and the keystroke
   shortcut for the macro to be executed.  The command line passed to WinExec
   would look just like the EventActionFile setting shown above (for a typical
   file and macro).  This makes possible the use of this feature for many more
   practical applications: e.g. disabling a hub port which is taking up too
   much of the LAN bandwidth at times when that bandwidth is needed for other
   things; changing the state of a bridge from LEARNING to SECURE; adding
   addresses to a bridge's address table; etc.

4) There is no facility to automatically close the Recorder after it has
   played back a macro, and only one instance of the Recorder may be active
   at any one time.  Thus this use of the Recorder for Action on Events is
   normally limited to one incident without some manual intervention (to 
   close the Recorder) between incidents.

   A way to get around this is to write a Windows program which will close
   another Windows program (specified by name), and then record yourself
   using this program to close the Recorder itself.  Although this sounds
   paradoxical, it actually does work (whereas recording yourself simply 
   closing the Recorder by selecting the "File Close" command does not).  The 
   source for a sample program is provided.

RECORD\KILL.C   - sources for a sample Windows program which will close
RECORD\KILL.DEF   another Windows program given by name.
RECORD\KILL.EXE
RECORD\MAKEFILE


Windows/C program example
-------------------------

C\TTS.C   -  This is an example of how a Windows program written in the C
	     language can be used to examine some of the information 
	     available when an event occurs, and to use this information 
	     to determine what action (if any) to take.  This example 
	     parses the command line to set up string variables for each 
	     of the eight pieces of information which are made available.  
	     It then constructs a message using Time, Event Name, Label,
	     Device Type, and (if available) Port Number.  In this example,
	     the string is then displayed in a Message Box, as well as
	     passed to a DLL routine, "Say".  The DLL we used is from the 
	     "Monologue for Windows" product, available from Davidson & 
	     Associates; El Monte, CA.  Its "Say" procedure causes the 
	     string to be spoken through the speaker of the PC or (if 
	     available) a better quality speaker attached to an audio card.  
	     The program could however do anything, including launching 
	     other Windows (or DOS) programs, or even the Windows "Recorder" 
	     program to play back a macro, based on the information it has 
	     receieved about the event which occurred.

C\TTS.RC   - Additional files which are used to build the programs TTS1.EXE
C\TTS2.LNK - and TTS2.EXE.  The Microsoft C compiler and the Microsoft 
C\TTS2.DEF - Windows SDK (or their equivalents) will be required to modify
C\MAKEFILE - and rebuild these examples.
C\TTS1.LNK -
C\TTS1.DEF -

C\TTS2.EXE - The program itself including synthetic speech output to a 
	     speaker.
C\TTS1.EXE - A simpler version of the program which only pops up a message
	     box.

You can test this example (without the synthetic speech) by setting the
Action on Events parameters as follows:

	EventActionFile = <path>\TTS1.EXE
	EventActionParms = TRUE
	EventActionShow = 1 (Normal)

If you have Monologue for Windows, set EventActionFile = <path>\TTS2.EXE.
Don't forget that you will need to have the library SPEECH.DLL in the path.

You can customize this example by editing the file TTS.C and recompiling 
and linking it.  For this you will need the Microsoft C compiler and the
Microsoft Windows SDK (or their equivalents).  The program TTS.C currently
does no filtering of events, but pops up (and speaks) a message for every
event.  You can add filtering by event and/or device simply by testing the
various informational parameters supplied to the program command line.  You
can rearrange the message which is popped up (or cause the program to take 
any other action which can be implemented by either a Windows or a DOS
program) for each specific case.


