Conference azur::mcc

2224.0. "user-oriented ntw mgt for SNA (via SNA or ASCII AM" by ROM01::CANCELLIERI (perfezionista pentito) Thu Jan 30 1992 10:22

            SNA/AM or ASCI/AM solutions for user-oriented ntw mgt

One of our customers, Banca Nazionale del Lavoro (the largest Italian Bank),
has some specific network management requirements which, I hope,
could be met by DECmcc. I am giving hereunder a short description of
such requirements, and would appreciate if some of you could give us
useful suggestions or comments about the feasibility of the envisaged solutions.

This bank has a huge SNA network (managed by NetView), which connects all the
bank's branches to the main processing centres located in two cities. In
general, we can say that the whole network is duplicated and consists in fact
of two parallel, independent networks, for resiliency. So, half of the
terminals in each branch are connected to the fisrt network, and the other half
to the second one.

It is then obvious, from the point of view of each branch, that the outage
of one network is not catastrophic as the outage of both networks
together. It is therefore essential to know, when a network problem
occurs, what are the consequences on the various branches, in order to give the
problem the appropriate priority. This kind of information is not available
from NetView, and it is exactly what our customer would like to have, and on a
nice iconic display.

I think there are two possible kinds of solutions based on DECmcc:

A) SNA/AM BASED SOLUTION

   that is: use the SNA AM to probe NetView, maintain a special  configuration
   table with associations between the physical newtork objects and the
   reachability of the various bank's branches, in order to be able to show on
   a topological and/or logical map (structured in domains and subdomains)
   various degrees of "suffering" of the individual branches or branch groups.
   The draw-back of this solution is the presumably difficult updating process
   of the branch configuration; moreover, I ignore how easily we can get all
   the information we need, from the SNA AM.

B) ASCII/AM BASED SOLUTION

   that is: let all the "intelligent" work of associating failures of physical
   objects to changes in the reacheabulity level of the various branches, be
   done in the IBM mainframe (where the necessary tables will be implemented and
   maintained anyway), and let's receive (from a special application running
   in the IBM mainframe) simple notifications of network changes in the form of
   fixed-format ASCII strings saying, for instance:

   - branch no.: ....
   - branch-name: ...
   - general status of branch: all ok|minor_problems|major_problems|isolated
   - % of control units available: ....
   - list of control units unavailable: .....  
   - % of terminals available: ....
   - list of terminals unavailable: ....  
   - id of primary line: ...
   - status of primary line: ...
   - id of secondary line: ...
   - status of secondary line: ...
    
   We could use DECmcc to show the current network situation on iconic
   windows. For instance, we could have various kinds of domains, such as:

   -- branches and branch groups
   -- control units and control units groups
   -- terminals and terminal groups
   -- lines and line groups

   We could set up a general configuration with the maximum possible number of
   configurable items (all entities are strictly hierarchical and have a finite
   maximum quantity); if we never receive any notification for a given entity,
   that means the entity is just a place-holder (and "not existing" will be one
   of the visible status on the relevant icon).

   In case of configuration changes, or after an isolation between DECmcc and
   the IBM application, this could send us a number of fictitious events (one
   per branch), just tto refresh the whole configuration, after a "clear all"
   command.

   If there is a change of name for a given branch number, this would create no
   problem if the name of the branch is an internal paramenter of the
   object (visibile through "show characteristics"); instead, if we want to
   show the name of the branch with the icon, then we should update it on the
   relvant icon and I don't know how difficult it would be.

I believe the second kind of solution would be much simpler and less risky to
implement. And the customer would be happy with it, as he knows that some
branch-oriented configuration management must be done in the IBM mainframe
anyway (they have already started developing a relational databes for this
"value added" configuration).

What I would like to know, in particular, is the following:

-- how easy would it be to define the domains and the iconic displays which
   would fulfill the requirements explained in solution B above?
-- when will the ASCII/AM be available (if ever)?
-- how easy would it be to generate alarms based on text lines received from 
   the ASCII/AM?
-- how difficult is it to automatically modify an icon tag (for instance, the
   name of a bank branch)
-- are there better or easier solutions to achieve the results we are looking
   for?

Thanks in advance

Ciao
bruno

    You need to mail a copy of your note to Kathrin Winkler who is
    the project lead of the MCC SNA integration. She doesn't monitor
    the MCC notes file as often as the MCC internal people.
    
    wally