nteventlog(3erl) [linux man page]

nteventlog(3erl)					     Erlang Module Definition						  nteventlog(3erl)

NAME

       nteventlog - Interface to Windows Event Log

DESCRIPTION

       nteventlog  provides a generic interface to the Windows event log. It is part of the OS_Mon application, see os_mon(7) . Available for Win-
       dows versions where the event log is available. That is, not for Windows 98 and some other older Windows  versions,  but  for  most  (all?)
       newer Windows versions.

       This module is used as the Windows backend for os_sup , see os_sup(3erl) .

       To  retain  backwards  compatibility, this module can also be used to start a standalone nteventlog process which is not part of the OS_Mon
       supervision tree. When starting such a process, the user has to supply an identifier as well as a callback function to handle the messages.

       The identifier, an arbitrary string, should be reused whenever the same application (or node) wants to start  the  process.  nteventlog	is
       informed about all events that have arrived to the eventlog since the last accepted message for the current identifier. As long as the same
       identifier is used, the same eventlog record will not be sent to nteventlog more than once (with the exception of when graved system  fail-
       ures arise, in which case the last records written before the failure may be sent to Erlang again after reboot).

       If  the event log is configured to wrap around automatically, records that have arrived to the log and been overwritten when nteventlog was
       not running are lost. It however detects this state and loses no records that are not overwritten.

       The callback function works as described in os_sup(3erl) .

EXPORTS

       start(Identifier, MFA) -> Result
       start_link(Identifier, MFA) -> Result

	      Types  Identifier = string() | atom()
		     MFA = {Mod, Func, Args}
		     Mod = Func = atom()
		     Args = [term()]
		     Result = {ok, Pid} | {error, {already_started, Pid}}
		     Pid = pid()

	      This function starts the standalone nteventlog process and, if start_link/2 is used, links to it.

	      Identifier is an identifier as described above.

	      MFA is the supplied callback function. When nteventlog receives information about a new event,  this  function  will  be	called	as
	      apply(Mod, Func, [Event|Args]) where Event is a tuple

       stop() -> stopped

	      Types  Result = stopped

	      Stops nteventlog . Usually only used during development. The server does not have to be shut down gracefully to maintain its state.

SEE ALSO

       os_mon(7) , os_sup(3erl)

       Windows NT documentation

Ericsson AB							   os_mon 2.2.5 						  nteventlog(3erl)

snmpa_network_interface(3erl)				     Erlang Module Definition				     snmpa_network_interface(3erl)

NAME

       snmpa_network_interface - Behaviour module for the SNMP agent network interface.

DESCRIPTION

       This  module  defines  the  behaviour  of the agent network interface. A snmpa_network_interface compliant module must export the following
       functions:

	 * start_link/4

	 * info/1

	 * get_log_type/1

	 * set_log_type/2

	 * verbosity/2

       The semantics of them and their exact signatures are explained below.

       But this is not enough. There is also a set of mandatory messages which the network interface entity must be able to receive and be able to
       send. This is described in chapter snmp_agent_netif .

EXPORTS

       start_link(Prio, NoteStore, MasterAgent, Opts) -> {ok, Pid} | {error, Reason}

	      Types  Prio = priority()
		     NoteStore = pid()
		     MasterAgent = pid()
		     Opts = [opt()]
		     opt() = {verbosity, verbosity()} | {versions, versions()} | term()
		     versions() = [version()]
		     version() = v1 | v2 | v3

	      Start-link the network interface process.

	      NoteStore is the pid of the note-store process and MasterAgent is the pid of the master-agent process.

	      Opts  is	an  (basically)  implementation  dependent list of options to the network interface process. There are however a number of
	      options which must be handled: versions and verbosity .

       info(Pid) -> [{Key, Value}]

	      Types  Pid = pid()

	      The info returned is basically up to the implementer to decide. This implementation provided by the application provides info  about
	      memory allocation and various socket information.

	      The  info  returned  by  this  function is returned together with other info collected by the agent when the info function is called
	      (tagged with with the key net_if ).

       verbosity(Pid, Verbosity) -> void()

	      Types  Pid = pid()
		     Verbosity = verbosity()

	      Change the verbosity of a running network interface process.

       get_log_type(Pid) -> {ok, LogType} | {error, Reason}

	      Types  Pid = pid()
		     LogType = atl_type()
		     Reason = term()

	      The Audit Trail Log is managed by the network interface process. So, it is this process that has to retrieve the actual log-type.

       set_log_type(Pid, NewType) -> {ok, OldType} | {error, Reason}

	      Types  Pid = pid()
		     NewType = OldType = atl_type()
		     Reason = term()

	      The Audit Trail Log is managed by the network interface process. So, it is this process that has to do the actual  changing  of  the
	      type.

	      See set_log_type for more info.

Ericsson AB							     snmp 4.19					     snmpa_network_interface(3erl)