EMU User Guide

Each parameter is associated with a protocol and a table. In some cases where there are multiple tables within a protocol, the table names are also in this file and can be modified similarly to parameter names.

3.5.3 Operations

• Parameters. Selecting this item allows you to view, change or delete the characteristics of parameters.
• Tables. Selecting this item allows you to view, change or delete the characteristics of tables. In the case of tables there is only 1 characteristic - it's name. Note that changing the name will prevent the help entry on this table name from working unless the corresponding entry in the help library is also changed.

• List. This will list all that parameters in a particular table. There are 5 columns displayed:
  1. PRM. The parameter number.
  2. Keyword. This is the name that will be used when displaying this parameter.
  3. Ctl/Rtn. This is the formatting indicator used to format the parameter value for display. It is either an FAO directive or a routine number.
  4. Flg. This is a bit pattern that controls whether the parameter should be polled for and included in the database and if so, what the alert mechanism should do when it is created, modified or deleted.
  5. LvL. The level this parameter is displayed at. In the user interface the user may select displays from Brief to Verbose displays. This number corresponds to the level.
• Add. Adds a parameter to the file. This function should only be used by developers. It is included here only for completeness. To add a parameter you need to know:
  • The Table the parameter is in. Tables are either assigned internally by the system or calculated from data received from the network. Tables are found via menus that appear on the left of the screen.
  • The parameter number. Usually this is assigned by the protocol but in cases where the protocol does not assign this, the system does. All parameters have an assigned number and belong to exactly 1 table.
  • Formatting. How this parameter is formatted. It is either by FAO directive or routine. If the parameter cannot be formatted by a simple FAO string (usual case) a routine is supplied. A menu of available routines is presented on the left of the screen.
• Modify. You may change any aspect of a parameter entry. Be careful and sure of what you are doing here - changes here can have very subtle and undesired effects. If Modify is selected a menu of protocols appears. Using this menu will take you down through the table hierarchy to arrive at a particular table. Once a table is arrived at you will be asked for a parameter number. This parameter must already exist. To find parameter numbers use the list function. A brief explanation of each field you can change follows:
  • Security. A menu listing all VMS privileges is displayed. Selecting any item causes the selected parameter to require the user to have that privilege in order to view it's presence. That is to say, if you select CMKRNL, the next time you view the parameter list and you do not have the CMKRNL privilege, the parameter will not be seen. Selecting an enabled privilege, disables it.
  • Keyword. This is the word or phrase this parameter is known by. Any printable string up to 64 characters is allowed. If you change the name of a parameter, the help entry will cease to work until you also change the help entry in the help library. Instructions on how to do this are provided in the Hints section.
  • Formatting. Do not change this. If you do, software support will yell at you when you tell them the system is broken. If you change this, you will break the system.
  • Report Level. All parameters belong to a level in range 1-5. The level is used in displaying lists. In general the most interesting parameters are 1 and the least interesting parameters are 5. The display is controlled by the hidden menu on the query display and correspond as:
    1. Summary. The lowest level. Only those parameters defined as 'most interesting' are displayed. Generally this would include only names and addresses.
    2. Brief. Names, addresses and those considered major parameters are displayed.
    3. Normal. All but the most obscure parameters are displayed.
    4. Full. All parameter that can be formatted are displayed.
    5. Verbose. All parameters are displayed. If there is no formatting available for a parameter, a default translation is applied.
  • Include in database. Whether or not to include this parameter, when received in the database. If not included, it will not be monitored or processed in any manner. Normally, most parameters are included except for those which are very dynamic and are not useful at this level. Examples of these are:
    • TCP connections in MIB-II. The list of addresses and ports currently connected to this host.
    • Bridge FDB tables. The list of MAC addresses and destinations in a bridge.
    
    Both of these examples, are (in most cases) very long lists that change rapidly. The result of putting them in the database is to use a LOT of space up with data that is obsolete in minutes and depending on how other parameters are set, will cause excessive alerts. Be sure you understand the impact and use of any parameter before changing this field.Default is yes.
  • Include in monitors. Essentially the opposite of include in database. Monitors are intended to retrieve and display the rapidly changing parameters. Monitors are not yet implemented. Default is no.
  • Alert on Create. Exactly that. When this parameter is created, send an alert to that effect. Default is no.
  • Alert on Modify. Exactly that. When this parameter is modified, send an alert to that effect. Default is no.
  • Alert on Delete. Exactly that. When this parameter is deleted, send an alert to that effect. Default is no.

MIBS must be compiled before they are usable by the system. EMU provides a compiler in 2 parts for a number of reasons:

• It is never advisable to edit a MIB although it is not unknown for errors to be present in the MIB itself. Using the EMU MIB compiler, you can edit the output of the 1st pass to correct any errors of this kind.
• Simple is a relative term. At the protocol level SNMP is not simple to implement although it is much simpler than many. At parameter (MIB) level it is often too simple. A prime example of this is how a MAC (Ethernet) address is specified; it is always shown as an Octet String - that is a string of bytes. Octet strings are generally printable characters but in the case of a MAC address this formatting does not work. EMU therefore redefines these parameters using private definitions and therefore maintaining correct output. Again, output from the 1st part of the compile can be edited to correct these problems.

Table 3-3 EMU ASN.1 Private DataTypes

EMU Symbol	Tag Value	DataType
SNMP_ASN1E_MACADDR	193	Mac address
SNMP_ASN1E_DISPSTR	194	Printable string
SNMP_ASN1E_TBLTOP	195	Table top ¹
SNMP_ASN1E_TBLENT	196	Table entry¹
SNMP_ASN1E_BRIDID	197	Bridge ID

Note 1: These 2 types are used internally only. They should never be edited into a MIB at any stage.

There are a number of enhancements included in this compiler that are not present in industry standard ones:

• The 1st pass extracts all the description fields and builds a VMS standard help library. After registration this help library is available to the user interface providing the user with access to all parameter definitions in readable format. Because MIB parameters are many and often have cryptic or obscure names, this is seen as an essential service.
• The private definitions allow more precise and clearer display of values than those that simply following the protocol.

1. Ensure the MIB you want to compile is in EMU5_MIB: directory. MIBs can normally be obtained by contacting the manufacturer of the device via either the Web or FTP. EMU supplies many of the more common MIBs precompiled and registered. To find which MIBs are already available run PARAMTBL, Select Internet and the resulting menu will display all registered MIBs. Other MIBs are simply supplied and are located in EMU5_MIB:.
2. Run EMU5_EXE:MIB_COMPILE1.The program will ask for the MIB name. Enter it. This compile phase:
   • Opens the input file and creates the Help and output files with the same name as the MIB and with extensions .HLP and MC1 respectively.
   • IMPORTS all files specified in the IMPORT statements in the MIB. These must exist and have been previously complied by this routine. If any do not exist you are given the choice to continue or exit. It is often a good idea to continue as much of the IMPORTED information is not used. If at a later stage the program is unable to define a parameter, exit the program, compile the offending MIBs and start again.
   • Extracts all definition statements and writes then out the the HLP file.
   • Builds the schema internally. See the hints section for a brief description of the schema.
   • Once the MIB is entirely read in, and if there were no errors detected, the schema is written out to the .MC1 file, The Help library is created and the help file just created is inserted into the help library.
3. Run EMU5_EXE:MIB_COMPILE2.The program will ask for the MIB name. Enter it. This compile phase:
   • Takes the MC1 file previously created and converts it to a form usable by the system. It creates a file with the same name as the MIB and extension .MC2. This is the file that the rest of the system searches for when listing out available MIBs.
   • The program displays it's progress by showing the number of lines read/ written on the screen. If the program exits without error, creation has been successful.
4. Run EMU5_EXE:MIB_REGISTER.The program will ask for the MIB name. Enter it. The program will determine if the MIB is already registered and if so, you may replace it with the new definitions. Otherwise it advises the number assigned to this MIB and includes all definitions in EMU5_DAT:MAPPER.DAT. The MIB is now available for the system to use on any device that supports it.
5. After making any required adjustments to the system' usage of the parameters just registered (see below for a hint), you then tell the system which nodes to use this MIB on by:
   • In the main EMU user interface select a node supporting this MIB.
   • Select IP protocol. If the device does not support IP, it does not support any MIBs.
   • The menu of available MIBs is displayed along with Set MIB Params. Select 'Set MIB Params'
   • A further menu appears. Select 'Set MIB'
   • A menu of available MIBs appears. Each item is a toggle; Selecting an already selected MIB deselects it and selecting an unset MIB sets it. The Selected MIBs are shown in a bit pattern at the top of the screen - each MIB has a corresponding bit in the pattern that when set (to 1) indicates to the system to use this MIB when updating this address.
   You can test this MIB with another utility that is also useful in browsing the network: MIBWALKER.

   Note that by default all IP addresses are assumed to support MIB-II - the basic MIB that most SNMP devices support - at least in part. Internally to the system this is MIB number 1. DO NOT CHANGE THIS DEFINITION. If this is the only MIB a device supports or the only MIB you want to act upon a device then no action is necessary.
   

   3.5.5 MIBWALKER

   A MIBWALKER is a generic program that allows you to retrieve and display the results of data from a node supporting SNMP. A number of conditions must be met before this will work:
   • The device you are targeting must be running, attached to the network and be prepared to respond to SNMP requests.
   • You must use the correct MIB to talk to it.
   • If the Device does not allow public access you must know the community string it supports.
   To run the MIB walker type 'MIBWALKER' at the DCL prompt. This system wide symbol is set up at EMU start time. Note that EMU is not required to be running in order to execute this routine.
   Running the program displays a menu on the screen:
   • Set IP address. Select this item and enter the IP address you wish to talk to. Wildcards or names are not allowed. In future, this routine may be integrated with EMU to allow more friendly searches.
   • Set MIB. Set the MIB you want to use on this device. A menu of available MIBs is presented. Select one.
   • Set Community String. By default the transactions will use the public string. If the device does not accept this, select this item and enter the community string the device uses. Selecting this item and providing no input causes the public string to be used. Note the string is case sensitive.
   • Walk the MIB. This MIB walker is a bit unusual in that it does not actually 'walk' the MIB. Selecting this item (after setting at least the IP address and MIB) presents a menu of tables and items this MIB supports. Selecting any item sends the appropriate request to the device and if an answer is received, displays the results. Pressing the HELP key anywhere in this menu invokes the help system and displays and explanations of the associated parameters available. Exit this menu with CTRL Z.
   • Toggle Log file. Selecting this item turns logging on or off. If logging is off it turns it on, if off, it turns it on. When on all displays to the screen are also written to the file MIBWALKER2.LOG in the default directory.
   All the functions are independent. That is you can set the MIB and switch between addresses or vice versa. It is often a good idea to run this program after compiling and registering a MIB and noting which parameters should be adjusted using PARAMTBL. For many MIBS you may not want all the parameters (by default all will be collected) or you may want to alert when additions, deletions or modifications are detected on some parameters. By default no alerts are generated.
   

   3.6 Errors and Omissions

   This is the beta release of software. Some functions described in the user guide are not implemented and others may not perform exactly as expected. It is the purpose of this release to find these errors, note the usefulness of the system as it stands and to collect feedback for it's further development. This section describes the known errors and some possible workarounds. These are given in no particular order:
   • Monitor Listen Display. The error count increments regularly. No other symptoms found (that is there are no known errors). Probable coding issue. No effect on system.
   • On rare occasions the system does not shutdown fully. Before starting the system it is a good idea to start the user interface by typing EMU and the DCL prompt. If the error 'fatal controller error' is returned, the system is fully shutdown. If not, wait a few minutes and try again. If still not shutdown, locate the EMU processes (all EMU processes have 'EMU_' as the 1st 4 characters of their names) and 'STOP/ID' them. Note if this action is necessary it is imperative that on next startup the databases are cleared.
   • DECnet IV PSR does not display on the MONITOR PSR display. Reason unknown. No other known effect.
   • User interface often hangs upon exit from trace facility. Control Y the process and restart the interface. Will be fixed in full release.
   • Bridge Ids in the FDDI display are not translated correctly. The selector wrongly assumes a specific table this is in. Will be repaired in full release.
   • System is prone to slowdown after running for about 10 days. Cause is fragmentation of the database file which is in turn is caused by excessive read/writes to it. A fix has been engineered and can be expected in the full release. In the meantime, the file can be reorganised using CONVERT on occasion. Note that the system must be shutdown to do this.
   • Not all parameters are translated. The two main reasons for this are:
     1. The parameter is not documented and requires reverse engineering to determine what it is and how to translate it.
     2. The parameter is complex and requires special routines to format it.
     This is an ongoing exercise
   • The hidden menu function that filters parameter display based on 'importance' is not effective largely because the parameters are all set to the default of 0 (with the exception of MIB generated parameters which are set to 3). The mechanism also needs some adjustment to filter out untranslatable parameters. The task of revaluing the individual parameters is left to the user at this point although the system may provide more convenient templates in future.
   • MOP sends too many relater frames. The MOP module acquires both the MAC in use and the burned in MAC address on the card. There is no way for MOP to determine if the hardware address has been passed to other databases therefore always sends this information on each cycle. There is no effect other than uselessly using a small resource. A fix is in progress.

• All data is presented as list with each parameter separated by a vertical slash (|). The number of slashes present is always the number of parameters less 1 - if a parameter does not exist there is nothing between the slashes where it would be if it did. This allows for very easy detection and extraction using the F$ELEMENT lexical function in VMS and easy importing to Excel.
• The first parameter is always a number. The number itself has little meaning but note that all parameters associated with a single box always have the same number. Put more simply: When the number changes, it is a different device. A number of example report formatting procedures are in EMU5_RPT:.