Conference azur::mcc

    I would be interested in information on this as well. One of my
    customers described a product which collects ASCII data from multiple
    "management systems",parses the data and feeds alarms to NETVIEW. I
    didn't know if we had any plans to implement something similar.
    
    Thanks,
    
    Liz
     

I think that an ASCII AM is badly needed if you need to use DECmcc to 
control devices from the "real" (read: non DECnet, non TCPIP  8-)) world.
Otherwise we soon end up in writing  thousends of similar AMs.

I appreciate if some pointer can be posted here for the ASCII AM info.

Peretz

	RE: .2,

>I think that an ASCII AM is badly needed if you need to use DECmcc to 
>control devices from the "real" (read: non DECnet, non TCPIP  8-)) world.
>Otherwise we soon end up in writing  thousends of similar AMs.
>
>I appreciate if some pointer can be posted here for the ASCII AM info.

	Yes, I would like to see a discussion of this opened up as well.

	I would think that a lot of interfaces would boil down to an ASCII-like
interface once you got past the coms protocol used to interface to the network
element.  Maybe a generic API or ASCII parsing tool is needed.

	Carl

    Somewhat tangential, but we might learn a lot from the VCS folks.  
    After all, they've been in that base technology (parsing ascii strings)
    for some years now.   They probably have at least a few ideas about
    some good (or bad) ways to implement this as either some MMs or kernel
    services...

    Is anyone in the VCS group lurking out there? Any ideas|suggestions? 

/doug

	RE: .4,

>    Somewhat tangential, but we might learn a lot from the VCS folks.  
>    After all, they've been in that base technology (parsing ascii strings)
>    for some years now.   They probably have at least a few ideas about
>    some good (or bad) ways to implement this as either some MMs or kernel
>    services...
>
>    Is anyone in the VCS group lurking out there? Any ideas|suggestions? 

	Doug, can you give some more background on what VCS is?

	Carl

          Software
          Product
          Description

          ________________________________________________________________

          PRODUCT NAME:   VAXcluster Console System, Version 1.3       SPD
          27.46.04
          DESCRIPTION

          The VAXcluster Console System (VCS) is a VMS V5.3 DECwindows
          layered software product which provides a central point for
          system console services and for logging console data received
          from the serviced nodes. From a single terminal or VAXstation
          display connected to the VCS host system, a system manager can
          perform all console functions for all serviced nodes. These
          functions include, but are not limited to:

          o  Shutting down or rebooting the serviced nodes

          o  Running standalone diagnostics

          o  Performing standalone backup operations

          o  Installing layered products

          o  Viewing console output

          o  Reviewing historical console data

          o  Retrieving historical console data for analysis or printing

          o  Searching for console data

          VCS also performs the following functions:

          o  Logs all data and activities between VCS and the serviced
             nodes

          o  Scans incoming messages from the serviced nodes for specific
             text strings that may contain status or error information

          o  Notifies system managers of critical system messages via
             DECtalk, VAXmail, or by changing icon colors

                                       DIGITAL                    May 1990

                                                               AE-HV29E-TE

 


          VAXcluster Console System, Version 1.3              SPD 27.46.04



          o  Enables users to assemble icons (not drawn to scale) into
             graphics displays on a VAXstation screen representing the
             aerial view of your data center and the logical grouping of
             your VAXcluster configurations

          o  Provides an optional security facility to control access to
             the serviced nodes

          VCS can be accessed from locally connected terminals or remotely
          over the Ethernet.

          The VAXcluster Console System allows a system manager or an
          operator to manage up to 32 devices which can be:

          o  VAXcluster systems

          o  Standalone VAX systems

          o  Any other device that

             Sends ASCII data over an RS232C line,
             Has an EIA console port,
             Supports XON/XOFF and I/O buffering

          Hence, PDP-11s, line printer servers or controllers, LAN
          bridges, and other third-party devices that meet the above
          requirements can be monitored from one central location.

          The VAXcluster Console System software can be installed on any
          VAX, MicroVAX or VAXstation platform identified in the System
          Software Addendum (SSA 27.46.04-x) The devices managed by VCS
          are connected to the VCS platform by:

          o  Direct connection, i.e. connecting to a port of a serial line
             interface device (DHV11, DHQ11, DZQ11, or CXY08) within the
             VCS host system cabinet

          o  Host-initiated connection, i.e., connecting to a port of a
             terminal server which is accessible by the VCS host system
             over the Ethernet. The DECserver port must be mapped to an
             LTA terminal device defined in the VCS host system.

                                          2

 


          VAXcluster Console System, Version 1.3              SPD 27.46.04



          Software Components

          The VCS V1.3 software includes the following components:

          I/O Data Logger - Manages the console lines and logs all data
          received on these lines. In addition, it makes the received data
          available to other VCS components and transmits the data on the
          console lines to nodes designated by those components.

          Data Scanner - Scans the console log data for predefined events.
          The information about detected events is relayed to other VCS
          components for logging and additional processing.

          Event Logger - Records events detected by the Data Scanner. It
          logs all events from all currently configured systems to a disk
          log file.

          Central Control Coordinator Interface - A DECwindows interface
          that provides an aerial view of a data center. From this in-
          terface, system managers can monitor all console activities and
          respond to events detected on the console connections. Console
          events are reflected by the node icons in the display and direct
          the system manager to systems needing attention. Other interac-
          tive interfaces can also be activated from the Central Control
          Coordinator Interface.

          Monitor Interface - Enables system managers to monitor the
          serviced nodes. It monitors these systems by displaying multiple
          windows of information. System managers can connect the primary
          window to a single system or display log data in this window
          while monitoring other nodes.

          Connect Interface - Enables system managers to connect to a
          serviced node, making their terminal the dedicated console (more
          than one system manager can connect to the same node). Once
          connected, all keystrokes, except for the defined "break" and
          "escape" characters, are transmitted directly to the console
          line of the node to which VCS is connected. While connected to
          that node, the system manager has normal console behavior. The
          only exception to normal behavior is that one control character

                                          3

 


          VAXcluster Console System, Version 1.3              SPD 27.46.04



          is reserved to enable the operator to escape back to the VCS
          system from which the connection was made.

          Record Interface - Enables operators to capture console line
          activity on a hardcopy device.

          Review Interface - Enables system managers to retrieve console
          data and event information from the console and event log files.
          The retrieved information and data can be specified in terms of
          source node and time interval.

          Access Interface - A programming interface that provides an
          alternate method for capturing events for additional processing.
          User-written applications can be used with the Access Interface.
          In addition, VCS provides a default application, complete with
          source codes, which sends scan and console events to a specified
          output device.

          Even Notification System - A suite of Access Interface applica-
          tions for interfacing with a wide-range of communication media
          for VCS event notification.

          Configuration Editor - Helps operators create and maintain the
          configuration information that VCS requires.

          Configuration File - Contains information about the nodes being
          serviced by VCS and the VCS environment itself. The Configura-
          tion Editor is provided to aid in the creation and modification
          of this data.

          Log Files - VCS maintains the console and event log files as the
          permanent historical records of console data from the serviced
          nodes. VCS creates a new set of console and event log files
          every 24 hours, beginning at midnight.

          When additional space is needed on the disk device, VCS displays
          a warning message before disk space shortage is critical. Then,
          as additional space is required, VCS deletes the oldest log
          files to make room for the new ones. The system manager can back
          up the log files before VCS deletes them.

                                          4

 


          VAXcluster Console System, Version 1.3              SPD 27.46.04



          The operational nature of the VAXcluster Console System makes it
          a requirement that the VAXcluster Console System host processor
          be a non-clustered VAXsystem. Thus, it is recommended that the
          VAXcluster Console System not be a member of a CI VAXcluster
          system or a satellite member of a Local Area or Mixed Intercon-
          nect VAXcluster system. However, the VAXcluster Console System
          can serve as the boot member of a Local Area VAXcluster System.

          Features

          o  Support of up to 32 devices; either VAXcluster system nodes,
             stand-alone VAXsystems or any device that sends ASCII data
             over an RS232 line, has an EIA console port and supports
             XON/XOFF and I/O buffering. The maximum supported console
             terminal speed is 19.2K baud.

          o  All data received from connected devices are logged by VCS
             and identified by source node name and the time received by
             VCS.

          o  Operators can connect to the console port of any node ser-
             viced by VCS from any terminal connected to the VCS host.

          o  VCS can control remote devices via host-initiated connections
             over Ethernet using terminal servers.

          o  Operators can remotely access the VCS host system via DECnet,
             LAT or dial-up ports to perform VCS functions.

          o  A security facility is provided to allow the system manager
             to restrict access to VCS-controlled devices.

          o  VCS detects console events by scanning console text messages
             and comparing them with predefined text strings contained in
             the configuration file.

          o  With VAXstation host systems, VCS provides the ability to
             build an icon-based view of all devices connected to it. This
             graphics layout uses color to indicate the severity of an
             event. It also allows the user to easily access a device's
             console by clicking with a mouse to activate a VCS interface.

                                          5

 


          VAXcluster Console System, Version 1.3              SPD 27.46.04



          o  Users are alerted of critical system messages by changing
             icon colors via a DECtalk device or through VAXmail.

          HARDWARE REQUIREMENTS

          VAX, MicroVAX or VAXstation configuration as specified in the
          System Support Addendum (SSA 27.46.04-x).

          Cables and adapters as specified in the System Support Addendum.

          SOFTWARE REQUIREMENTS *

          For VAX hosts:

          VMS Operating System

          For VAXstation hosts:

          VMS Operating System

          VMS DECwindows (included with VMS Operating System)

          *  Refer to the System Support Addendum (SSA 27.46.04-x) for
             availability and required versions of Prerequisite/Optional
             Software.

          ORDERING INFORMATION

          Software Licenses: QL-V01A*-**
          Software Media: QA-V01A*-**
          Software Documentation: QA-V01AA-GZ
          Software Product Services: QT-V01A*-**

          *  Denotes variant fields. For additional information on avail-
             able licenses, services and media, refer to the appropriate
             price book.

............................................................................
       <<<<deleted the rest of SPD in interest of disk space... dwm>>>>

    Re .4,.5

    > Somewhat tangential, but we might learn a lot from the VCS folks.  
    > After all, they've been in that base technology (parsing ascii strings)
    > for some years now.

    Here in VCS development, we have been giving some thought to the idea
    of using VCS technology to allow a DECmcc to manage a system that only
    allows management via a console line.  It seems very doable using
    existing VCS code or new code. There are some hard problems with this 
    concept in the general case though.

    Using existing code, you could write some glue to connect the common
    agent to the VCS pipes that are used to share access to managed
    console lines and scan event data.  This would be done by extending
    the VCS$IFEX image in VCS to support the common agent.  This would
    require that a VCS system be set up and configured to manage the
    console lines you wish to access from DECmcc.  Most likely, it
    would only be useful at sites that already have a need for the
    VCS product.  A lot of code would be needed on the common agent
    side to map commands (SET,SHOW) attributes and events into scan
    strings and console commands.

    You could also lift parts of VCS to do just the job you need.
    Take the scanner code, the parts of the I/O data logger that
    know how to manage the console connection and parts of the
    C3 that maintain event history.

    One of the problems that VCS has always had is the inherent limitation
    of managing a system via it's console line.  With most systems, there
    are far too many possible states the system can get into for any
    reasonable AM to keep track of.  There are many cases where the
    state of the system can be ambiguous or where the system can change
    state without any hit of the change on the console line.  In the
    case of VCS, we have always wanted to filter out duplicate reports
    of a node dropping out of a VAXcluster.  This has not been possible
    because VCS has no way to confirm that two messages from different
    machines are reporting the same event.

    The lack of ambiguity of the state of the system means that the
    set of attributes that you might wish to track could not be
    maintained with any certainty.  This would make the SHOW command
    useless.  The SET command could only be used if the system is
    in a known state.  If it gets into an unknown state, the affect
    of the SET command could be unpredictable.

    The ASCII AM could only be used on systems that have a small set
    of states that the AM can always track.  This might require that
    the system always run a special application that would maintain
    a protocol over the console line that allows the state of the
    managed system to be known.  

    The bottom line is that, in most cases, trying to manage a system
    using only an ASCII AM to a console line breaks the EMA model.
    SET may not set anything and SHOW may not show anything. Is it
    worth risking the model to manage systems this way with DECmcc?
    It may be better to integrate DECmcc another management application
    written to handle these systems so that the seam between the applications 
    will remind the manager to change models.

    					Mike Carleton
    					VCS Project Leader

    An idea.
    
    Perhaps an AM to talk to VCS or a subset?
    
    I have seen several customer cases recently that don't really want
    to "manage" the device that they can only get an ascii connect to, but
    are VERY interested in getting alarms/alerts from them.
    
    A product (some combo of MMs and VCS parts) that could connect to
    any console that a reasonable description of the console messages
    can be obtained would have a high re-use in closing sales.
    
    my $.02
    s/rob

>    A product (some combo of MMs and VCS parts) that could connect to
>    any console that a reasonable description of the console messages
>    can be obtained would have a high re-use in closing sales.

Yes, yes, yes!!! We need it!

And it should be customizable by the user. The user should be able to
specify for each event the corresponding ASCII string + variable attributes.
for example:

         EVENT           ASCII MESSAGE COMING FROM CONSOLE

Link X is down           ***LINK DOWN*** <link number><timestamp>

The events may be fixed in advance (i.e you may need to recompile to add
more events). But it is the user who will be able to change the ASCII strings
as required without the need to recompile.

Peretz Gur-El

    Hi,
    
    	I believe that if you have VCS and DECmcc today you can get some
    sort of ASCII alarms working by getting VCS to track the ASCII console
    stuff and to feed the event into DECmcc (although this may involve some
    daggy stuff like having VCS set a reference attribute (or is it
    characteristic?) and then having DECmcc alarm on the change in the
    reference information. My idea was that with V1.2 (I believe) we would
    be able to use VCS in this way to monitor modems, etc and to set the
    alarm on the line if the modem failed...
    
    	ANy comments?
    
    regards,
    ANdrew

Or more simply, you could use the VCS callable interface to grab VCS events and
then write a bit of code to send them to the Data Collector AM (In the 1.2
kit).  Then you could disply VCS events as DECmcc _events_ on a DECmcc console.
/doug

> Or more simply, you could use the VCS callable interface to grab VCS events 
> and then write a bit of code to send them to the Data Collector AM (In the 1.2
> kit).  Then you could disply VCS events as DECmcc _events_ on a DECmcc 
> console.
> /doug
    
	That would work.  You could write a VCS access interface
    application to stuff the events into the Data Collector.  You could
    also use the Event Notification System (ENS) access interface
    application fire up a DCL command procedure when an event occurs and
    write DCL to tickle DECmcc.

        VCS 1.4 (now in external field test) includes an interface for
    pseudo console applications.  You can write a program to feed text
    into VCS from any source you like.  We use this to feed the output of
    the printserver management program into VCS so that it can be scanned
    for 'Out of paper' events and the like.  The kit includes sample
    pseudo-console applications in source form.

					Mike Carleton
					VCS Project Leader