Conference azur::mcc

    On the subject of the TOOLBOX, I believe it might be good if a
    different name was chosen for this window. In the several sessions I
    have had with customers and sales and sales support people, the TOOLBOX
    gets confused with the TOOLKIT. Which one are the "TOOLS" in anyway?
    We allways have to explain several times about which things you buy and
    what comes with what.
    
    s/rob
    

    I have found that sometimes I use upper case when I register entities
    and sometimes lower case. This makes for a less than pretty set of
    lables on the icons in the map window.
    
    For 1.2 perhaps a way to specify the presentation format could be
    provided?
    
    I would think that for starters you could offer the choices of all
    upper case, all lower case, lower case with leading letter in caps,
    display as stored.
    
    Another thing that would make the display look neater would be the
    option of only displaying the rightmost simple name.
    
    s/rob

    I was thinking about the times when I was doing network management and
    the phone would ring (or better a network event would notify me) about
    a problem with something on the network. One of the things that seemed
    to always need to be done was look up some info about the system or
    bridge or whatever. For systems it was usually the name and phone
    number of the system manager.
    
    Well, with alarms, it is real neat that I can get an icon to change
    and I can select it and I can go get info about it. How abot one
    better? Have the ability to choose selected reference info fields to
    be displayed along with the icon when an alarm goes off?
    
    I think it would be handy to see a domain icon change color, double
    click down to check it out, and not only see the icon that has the
    problem lit up, but the info I would need to dig up anyway already
    displayed for me.
    
    I am sure that others will have more on this.
    
    s/rob

    How about a way to list all the current alarms in the mir to a text
    file that could then be easily converted to the appropriate command
    files for enableing and disableing alarms?
    
    s/rob
    

The MCC_ALARMS_EXTRACT_RULES utility creates a file containing all the
commands necessary to rebuild your Alarms MIR.

You'd also like files which contain Enable & Disable commands too, Right?

That would be pretty easy to encorporate into Extract Rules ... Perhaps
in v1.2 if there is time.

/Keith

    This may really need to be in V1.1 but...
    
    When I open up the first domain after starting DECmcc there is NO
    indication to let me know when it is done and I can be successful
    in pulling down something from the menue bar. Even after the map is
    apparently painted, DECmcc is still processing and not ready for more
    instructions. Perhaps the cursor should be a watch during this time?
    
    s/rob

    How about a way to de-select an icon on the screen that does not
    require use of the keyboard? If you have a phone in one hand or a
    manual, it is real awkward to de-select an icon so you could look up
    info about the domain. How about an MB1 click on whitespace like it
    does in the toolbox?
    
    s/rob

    I would like to see something like a logical name that specifies what
    the default username and directory specifications will be when creating
    domains. This would help prevent creating domains that accedentally are
    owned by the wrong person or had the wrong directory thereby removing
    some hassle when doing data recording.
    
    Perhaps better would be to take that info out of the domain entitiy
    completly and have it specified either in a RECORD directive or just
    use the logical name translation when RECORDing.
    
    I am concerned about the situation where a customer may register lots
    of stuff, then several people may create domains and maps and then only
    after a great deal of effort has been put in to the maps, they attempt
    recording data and find out that the username/directory specs on the
    domains are all wrong.
    
    Perhaps it would help to have some useful suggestions on how best to
    proceed with setting up for recording?
    
    Maybe it would help if users created domains FOR recording and placed
    all the members that they want to record data in these domains? This
    could be done completely independant of the domains that are used for
    management of the network.
    
    s/rob

    We really need a way to find out what domains exist to be opened. I no
    longer can remember the names of the domains in my own system. It is
    easy to forget them and have them get out of date (or at least any maps
    associated with them sure get old).
    
    s/rob

    I see that LOTS of unique files are created by alarm rule firings.
    
    This means that even periodic PURGEs of my directory won't keep me from
    filling it up.
    
    How about some maintainance and housekeeping proceedures?
    
    s/rob

    The management windows that are created for operations have far too
    much white space in them. Please make it possible to get more info in a
    window and to get more windows on the screen at the same time.
    
    Real network management involves lots of things happening at once.
    
    s/rob

    We need icons with multiple attachement points on them for things like
    routers and terminal servers so they can be represented more correctly
    on the map.
    
    s/rob

Since some one (Rob) mentioned logicals I want to add my 2 cents. Support of
logicals that are stored as logicals and not immediately expanded. So that
I can define a logical directory when creating a domain. This way if I get
a new manager, or a new account I can simply reset the logical value and
not have to delete and recreate the domain.

Also how about the ability to modify the domain owner id and directory 
information without having to delete and recreate (I know copy works but 
that seems a bit much).

    It would be useful to permit the user (or system manager) to assign
    the severity level (the numbers from 1-6) so that "Indeterminate"
    could be set to be more severe than some other levels.
    
    A note;
    The manual says that the severity number is displayed along the names
    in the customize map - alarms window but the sample in the manual does
    not show any numbers and my test on a monochrome monitor doesn't show
    them either.
    
    s/rob
    

Rob,

We are using the standards definition for the severity levels. So let's try this,
I believe it will handle the function you are looking for..

What you would like is for the Iconic Map PM to allow the user, not the code,
to determine the "severity ordering" for colorization on the map. A type of
customize function which would allow the user to specify which ones the
map should consider the most important, when attempting to arbitrate between
severities/colors of multiple occurrences for a single entity.

    Jill, I don't know how you got a log line in the previous but I
    couldn't read you second sentance.
    
    Anyway, what is really needed is to permit the indication of a failure
    to be able to test an alarm to override some other severity
    particularly when it bubbles up.
    
    I think we all agree (and my discussions with customers confirm) that
    the currrent severity levels for alarms testing true is good.
    
    However, I don't think we all agree as to the importance of a failure
    to be able to test the alarm. For some it may not be a big deal. For
    others, it could be very important.
    
    Is that more clear?
    
    s/rob

some times we all muddle stuff by supplying potential solutions instead
of stating the requirements (my new kick).

While the subject is on severity level is it possible to have the
option of *not* maintaining the most severe color? While I find
that having the most severe color shown useful (my name is probably
still on a requirements doc somewhere asking for this!), I do see
a number of applications where it would be more useful to simply
indicate the last alarm's color regardless of severity. This would
be used to more accurately indicate the present status graphically
rather than an operator having to look at the error and then query
the entity each time to find the status because the present methods
don't allow us to write alarms to indicate the state is back to normal.
It appears from discussions that the "circuit" module is potentially
looking at this but what about a generic solution?

brad...

The problem with using the latest severity is that there can be more than
one "condition" associated with a single icon and taking the latest severity
will mask more severe conditions.  This is especially true when you think about
entities with multiple child entities and domain entities that contain many
member entities: these are both represented by a single icon.

The correct solution requires that some central authority maintain a severity
for each condition, and be able to correlate a later arriving "condition report"
(we call them "occurrences") with a previous occurrence, and override the
previous occurrence's severity.  With this capability, and assuming that the 
Iconic Map is this central authority, the present severity 
maximization/propagation behavior can then work "correctly" and "automatically" 
from the users point of view.

So what we really need to provide are the tools to correlate two (or more) 
occurrences with different severities so that the later severity can override
the earlier ones, while maintaining the capability to distinguish between
unrelated occurrences so that more than one condition can be tracked for a given
icon.

We are presently working on solving this problem for V1.2.

    Since severity levels seem to be a "hot topic" for the moment, I'd
    like to toss in one more twist for consideration:
    
    We're in the process of designing an interface to MCC for a customer
    application.  It would be nice if we could define additional severity
    levels as well that we KNOW are not used by any currently existing
    applications.  That is, we would like to create application specific
    severity levels.  Since we can adjust the color, we could then make
    network problems shades of RED and YELLOW and application problems
    shades of BLUE and GREEN (as an example).  In this way, the customer
    is really managing the ENTERPRISE, not just the network.  I suspect
    this would also require the severity prioritization capabilities
    mentioned in earlier replies.
    
    If this is a stupid idea, just let me know.  We're just now beginning
    to get the hang of all this MCC stuff and it's quite a bite to swallow!
    
    Thanks,
    
    timf

     Have you guys considered doing a QFD (i.e., sticking MCC customers
(internal and external MM writers and UI end users) in a room with MCC
engineers and product and marketing people and a QFD facilitator and
discussing what's needed and why and what's most important and why and
what engineering can deliver most effectively and why)?
									RP

P.S.: more info on QFDs in the notesfile METOO::QFD

    re  .19,.20
    
    One thing we all seem to be assuming is that the only way to
    "alarm" an icon is by changing its color.  This is certainly
    true for 1.1, but I'd hate to retire knowing that that is all
    we ever did!  It is possible to do things like puttting multiple
    indicators within icons and around icons.  This is not a new idea;
    our competitors do it.
    
    I'm not suggesting that this is even in the works for v1.2, that's
    for other to decide.  But I am suggesting that we should not let
    the current model constrict our growth.  Let's grow the model.
    
    Fred  
     

    With the use of the Exporter (and maybe Historian but I haven't got
    there yet) a new need for access to local files is introduced.
    Now the USER must have at least RW access to the MCC_COMMON directory.
    
    I suggest that any files that the USER must have write access to be
    moved out of the MCC_COMMON directories and placed in a potentially
    separately specified directory to make it easier to set up access
    control on the system.
    
    As it is, the system manager must grant write access long enough for
    the files to be created which leaves a hole open for that time.
    Of course, after the exporter files are created, the actual files
    could have ACLs placed on them and the rest of the directory could
    be resecured. A seperate directory would be much cleaner.
    
    s/rob

    re: .9
    
    The Open Domain dialog box in v1.2 will allow the user to get a list of
    domains.  The user can filter which domains to list by DNS directories.
    
    /Jim

    I have had many requests for the following from customers and field
    support people.
    
    Some way to set up some templates of reference information so that
    either when an entity is registered via the IMPM or when reference
    data is to be set via the IMPM, a choice of templates could be provided
    and the info from the selected template copied into the entity
    reference attributes thus saving lots of repetitive typing (have you
    typed in the same reference info to 10's of entities?) and also
    reducing the potential for typing errors.
    
    s/rob

Implement a PRINT push button in each Icon map or display window to snapshot the contents 
of that window to a file.  This function will aid environments where computer operators
are unlikely to learn or use the FCL interface.

/Claudia   

Claudia,

Print as in "create a DDIF file"?

Fred

Reply to .27 -- Yes, Fred, or postscript, something that dumps 'this window' to a 
file that the operator can print without going through FCL to get the information.
/CP

    Please add the DNS Events to the list of supported events.
    
    Since DNS may be used with DECmcc, when it is, it needs to be more
    manageble from DECmcc.
    
    s/rob

    Isn't this covered under Phase V mgmt?  DNS logs events to Phase V
    in DECnet/OSI for ULTRIX.
    

    DECmcc doesn't support the DNS Event Class for DECnet Phase IV in
    the current release. Many (I hope) DECmcc system will be installed
    in DECnet Phase IV networks before DECnet Phase V becomes wide spread.
    We could use support for more DECnet events soon rather than later.
    
    s/rob

    re:.1
    	The first thing I do when using the TOOLBOX is to slide the window
    	up above my domain window. I always kept losing that sucker behind
    	my domain window.  It would be nice to be able to save its
    	position.
    
    re:.11
    	One of the things my customer (and I) don't like much is the fact
    	that there is no way to put more info in a window.  When you are
    	navigating the various child entities, you'll have a stack of 
    	windows to sort through.  When trying to compare counter info on
    	two nodes, I once had so many windows on the screen that I could
    	not compare anything.  One of the other network managerment 
    	products my customer has been evaluating allows you to display the
    	entire private MIB tree in one scrollable window with indented
    	object names and their associated values.  NICE!  Especially good
    	when troubleshooting a problem and you need to see everything.
    
    	I'd also like to be able to select and "cut" info from one of the
    	characteristic/status/identifiers... windows to paste in other
    	windows, but I can't.
    
    re:.12
    	I have used DECpaint very effectively to make many icons.  I use 
    	domains as a catch-all for network connection devices for which 
    	there is no AM.  (Example:  ODS Fiber Optic Concentrators).  It
    	would be very nice to have the ability to connect multiple lines
    	off of specific points on an icon (e.g., the port on a DELNI or
    	terminal server).
    
    	Also, what about arcs and circles for drawing FDDI rings?
    
    re:.13
    	I don't know how I did it, but I created many domains without any
    	problems.  I populated them in great detail with elaborate maps,
    	many different access modules used.  It was looking great.  I was
    	almost ready for the big demo to the "decision-maker" from my 
    	customer group when I discovered today, to my extreme
    	disappointment, that 90% of my domain director specifications
    	were incorrect. (I had recently changed out my VAXstation 3100/48
    	for a 3100/76 which had different disk names.)  Since there was no
    	logical name specifying "directory" - MCC_COMMON was translated to 
    	DISK$DKA300:[MCC] - , I find I'm up the creek.
    
    	I WOULD APPRECIATE SOME ADVICE ON COPYING DOMAINS & MAPS.  My last
    	attempt at copying got only a few of the domain members.  The
    	domains within the domain are apparently not coming over.
    
    	P L E A S E:  Get this fixed in V1.2
    
    
    re:.25
    	A data entry utility would be very welcome.  There are many times
    	I must reassign responsible person, phone number, ... on many
    	nodes.  It would be nice to  have a window to input reference or
    	characteristic info and then update that info for all entities of
    	a specific class in a given domain.  This would save hours of time
    	every month for me.
    
    
    Re: Print capabilities
    	I'm for MAP output in "scalable" postscript format so I could fit 
    	it on A-size (8.5 X 11) or B-size (11X17).  IGES format would be
    	even better, but I know I'm dreaming for V1.2.  Still, it would
    	really be nice to import this into a CAD application.
    
    -Thanks,
     Dan

as have the many others with similar statements. Some of these are
already in the works for v1.2 (I will leave it to Fred or some one from
the Iconic Map team to comment). As to copying of the domain John
Egolf put in a lengty discussion on how to do it a while back. Did
you try using the maps keyword to find it. It was entered by took::egolf.

jill

    Jill,
    
    I've done a ' SEARCH/NOTE=*.ALL "copy domain" ' command in the notes
    file and found only one note.  I've read the documentation and followed
    it.
    
    This is what I did:
    
    MCC> CREATE DOMAIN my_ns:.maint, DIRECTORY = "MCC_SYSTEM:[MCC]", -
    MCC>_ OWNER ID = "NETMANAGER"
          Create successful
    MCC> COPY DOMAIN my_ns:.m.seg20.maint NEW DOMAIN my_ns:.maint, -
    MCC>_ SELECT LIST = (NODE4 *, BRIDGE *, SNMP *, ICMP *, STATION *)
          Copy successful
    
    
    Here's the strange part:
    
    Of 35 NODE4  entities, only the first 2 are copied.
    Of 14 BRIDGE entities, only the first 7 are copied.
    No SNMP, ICMP, or STATION entities are copied.
    
    
    -----------
    Any ideas?
    
    -Dan                 
    

	Dan,
	
	Looks like  you've  found a bug.  Next time you're in LKG, stop
	by for your  prize.    I'd rather internal people find problems
	before our customers.

	While we look into  solving  the problem, would you like a work
	around?

	JCE

   The domain member datatype was changed from FULLENTITY to FULLNAME
late in the game.   All management modules are supposed to support a
fullname identifier.  V1.0 SNMP AM shipped without doing this.  Because of
this there were many changes made throughout the DECmcc to special case around
this.   We missed the SELECT LIST processing for the COPY and POPULATE 
directives.

   The version of SNMP AM that will ship when V1.2 DECmcc ships will support
the fullname identifier, hence fixing this bug.  

/Jim

Reply to 35, 36, 33

Dan,

The Domain Copy command will not copy all the domain members if one or more  
members are deregistered and not removed from the domain.  In most cases, 
Registration will remove the domain members it deregisters. Setting protection
can prevent Registration from cleaning up domain members.  

From FCL do a show domain foo member * all to identify the deregistered members.
Delete the deregistered members or register the members again.  When the 
deregistered members are cleaned up copy will work just fine. It is documented 
restriction in the release notes.  The restriction(known bug)is fixed now, in 
field  test V1.2 

Re 13  Jill, Logicals can be used for domain directory names.  Include the colon. 
Changing where the logical points to will LOSE your historical data. Better stop
all polling too. 

The ability to modify domain owner Id and directory were proposed, but did not 
make the cut for V1.2.  It (rightly) did not have a high enough priority. Feel 
free to lobby for the next version.  It is a simple change for the Domain FM but
a difficult problem for the Historian/Export. I imagine when trying to untangle 
a problem its priority may seem very high.

The next most asked for domain enhancement is syntax checking for directory.  A
wrong directory name or typo causes a hard to understand problem for recording 
historical data.  I suspect that if implemented there would notes requesting it
to be removed.  On multiple distributed platforms the correct syntax gets 
fuzzier. No checking always works on any system. Still, probably the majority 
of users want syntax checking.  

Al

re.35: (copying domains)

I also tried this same approach , but only with domains:
    
    MCC> CREATE DOMAIN my_ns:.maint, DIRECTORY = "MCC_SYSTEM:[MCC]", -
    MCC>_ OWNER ID = "NETMANAGER"
          Create successful
    MCC> COPY DOMAIN my_ns:.m.seg20.maint NEW DOMAIN my_ns:.maint, -
    MCC>_ SELECT LIST = (DOMAIN *)
          Copy successful
    
Only ONE domain icon is effectively copied to the new domain. Even after 
repeating the above, it stays and remains just ONE icon (which happens to
be the first one in the original MAP file. Does this give a clue?)

re 33:    

            <<< NOTED::DISK$NOTES4:[NOTES$LIBRARY_4OF5]MCC.NOTE;1 >>>
            -< DECmcc Family; Introductions 6; Kits 3 BMS & 40 EMS >-
================================================================================
Note 578.33                    Suggestion for V1.2                      33 of 38
CUJO::HILL                                           68 lines   8-AUG-1991 23:29
           -< V1.2 wishes; DOMAIN problem; PRINT; OUTPUT window... >-
--------------------------------------------------------------------------------
    
>    re:.12
>    	I have used DECpaint very effectively to make many icons.  I use 
>    	domains as a catch-all for network connection devices for which 
>    	there is no AM.  (Example:  ODS Fiber Optic Concentrators).  It
>    	would be very nice to have the ability to connect multiple lines
>    	off of specific points on an icon (e.g., the port on a DELNI or
    	terminal server).
>    
>    	Also, what about arcs and circles for drawing FDDI rings?

Fully agree with this one. I also haven't figured out yet what the line
drawing algorithm is doing. When I draw a line which is close to vertical,
the drawing algorithm automatically makes it a nice straight vertical line.
Now sometimes this is indeed usefull (drawing ethernets for example), but
not ALWAYS. Is there a way to prevent this ? If so, than I have missed it
in the documentation, sorry. If not, please make it more flexible in V1.2.
    
    
>    	I WOULD APPRECIATE SOME ADVICE ON COPYING DOMAINS & MAPS.  My last
>    	attempt at copying got only a few of the domain members.  The
>    	domains within the domain are apparently not coming over.
>    
>    	P L E A S E:  Get this fixed in V1.2
    
Yep, agree with this one too. Very often people create domains that look
a lot similar. Instead of redrawing the the complete domain again, it is often
much faster, to copy an existing one with all its members and modify it,
by adding/deleting a couple of lines/nodes.
    
>    re:.25
>    	A data entry utility would be very welcome.  There are many times
>    	I must reassign responsible person, phone number, ... on many
>    	nodes.  It would be nice to  have a window to input reference or
>    	characteristic info and then update that info for all entities of
>    	a specific class in a given domain.  This would save hours of time
>    	every month for me.

We are actually considering to write such a tool that would allow more 
flexible ways to search through MCC data. How to find a node when you only
have its ethernet address or Decnet address? How to find all systems that
are managed by the same person etc. 
    
>    Re: Print capabilities
>    	I'm for MAP output in "scalable" postscript format so I could fit 
>    	it on A-size (8.5 X 11) or B-size (11X17).  IGES format would be
>    	even better, but I know I'm dreaming for V1.2.  Still, it would
>    	really be nice to import this into a CAD application.

Try MCC_GRAPH. Gives you "scalable" postscript format on ANY size.    


Timo

    John,
    
    I would very much like a work around for COPY DOMAIN.
    
    Also, I would like to save my maps as well.  I believe I have a kludgy
    way to do this:
    
    	1. Copy bad_domain to temp_good_domain.
    	2. Rename map file to save it.
    	3. Delete bad_domain.
    	4. Create new_good_domain.
    	5. Copy temp_good_domain to new_good_domain.
    	6. Open new_good_domain and save map.
    	7. Edit new_good_domain's map and include bad_domain's original map
    	   in that file, making sure that entities are placed properly.
    	8. Open new_good_domain to see the finished product.
    
    Do you agree???  Is there an easier/better way???
    
    
    Re: .39
    	Timo,  Thanks for the MCC_GRAPH info.  I'll try it.
    
    -Dan
    

	See note 1351 for a COPY DOMAIN workaround.

	re .-1, yes, the map manipulation seems to be right on.

	JCE

    re; .38
    
    Al, the relationships of the Domain Directory are one of the most
    troublesome parts of DECmcc. The extream flexibility that is built
    in to the product for this is overkill for all instalations I have
    seen to date and when the problem (of having directories wrong for
    some things) is discovered (usually when lots of effort has been
    put into creating domains and maps etc and then finally the user wants
    to start data recording), there is no way out other than to tell them
    to start over. This does not make for happy customers.
    
    My suggestion would be a logical name (or some internal DECmcc
    definable variable) that sets the directory to be used by default
    for all domain creations for this process. A logical would let the
    user define the directory for themselves, a group, or the whoe system,
    as appropriate.
    
    I have yet to see a site that needed more than a very few different
    directories and most only need one. Storing an untranslated logical
    name would help with recoveries after hardware failures (disks or
    posibly whole systems).
    
    s/rob

    I have tried copying domains which have no deregistered entities at all
    and still do not get a complete copy of all members.  I can select one
    entity and "contiguously registered" members will be copied.  That is
    to say: BRIDGE1,BRIDGE2,BRIDGE3,SNMP1,SNMP2,NODE4_1,BRIDGE4,SNMP3 is
    the order of registration for these entities.  If you copy the domain
    without a select list, only BRIDGES1-BRIDGE3 will be copied.  If I
    select SNMP * in the select list, only SNMP1 & SNMP2 will copy.
    
    John Egolf's workaround (mentioned in Note 1351) works well & can be
    modified to suit your needs.  

    How about a creating a "Dummy Icon" option, to be used only as map
    objects, to represent non-DECmcc entities. Like the current lines...
    
    One thing, I have seen in almost all of the DECmcc implementations
    I have looked at. Is the extensive use of user defined Icons, to make
    the maps more representative.
    
    Now if those user icons, are merelly alternative ones for existing
    global entities, there is no problem. 
    
    But in many cases, they are used  to represent entities that  don't 
    exists as far as DECmcc knows. Here the workaround used is to create 
    ALTERNATE domain icons. But this causes performance problems, when
    you have large numbers of them, wich is almost always.
    
    Gil

	Gil,

as far as I know such "dummy entities" are already scheduled for v1.2 

In the mean-time I strongly suggest when using domain entities to represent
such dummy entities to create them as STATIC MEMBER of the parent domain.
This is what we have done in VBO for the DECmcc implementation to enter
all the Repeaters/Delnis...and this improved the time needed to startup
the IMPM when notifications are enabled.

	Manuel.

    I would like to suggest that all optional MMs ask about any
    augmentation (or other stuff) in the kitinstal proceedure and not
    require external proceedures to be run after the install is done.
    This also implies that all optional MMs should provide the Augmentation
    proceedures in their kit.
    
    s/rob

    Recently at a customer site I was dismayed to discover that the
    conversion tool we provide for porting an Ethernim database ONLY ports
    BRIDGE data. The customer wanted to port the DECnet nodes from
    Ethernim because he had already included all the referance data
    and didn't want to type it again.
    
    As a workaround we used a datatrieve proceedure to extract all the
    info from Ethernim and then editted it into a series of registration
    and SET directives to get the Station and NODE4 stuff loaded.
    
    I think it will help if the Ethernim Conversion utility was enhanced to
    do other than just the Bridges.
    
    s/rob

The ETHERnim Conversion Utility currently does BRIDGEs and STATIONs.

At the time the utility was written, the REGISTER NODE4 syntax wasn't
stable enough to include.

We're talking maybe a day's worth of work to add it.

1. Is there any interest in this?
2. Is the DECmcc V1.2 syntax still:

	REGISTER NODE4 fullname SYNONYM Phase4Name ?

3. Any suggested algorithm for the FullName?

    Thanks for the reply.
    
    You could possibly ask for a pathname for existing phase IV nodes
    and then prepend it to the phase iv name to construct the fullname
    or, use a logical name...
    
    Another idea; how about an option to just extract out all the reference
    data and construct SET directives against the phase iv name assuming
    that they are already registered via the tool that reads the ncp data?
    
    The syntax is still valid as you stated. Also, I believe that you can
    also specify a ADDRESS = 1.15 type of thing though it didn't work
    real well in a previous release.
    
    s/rob

    
    
    I seen a question something like this:
    
    2. The DNA4 register syntax wasn't too solid, is it still?
    
    In DECmcc V1.2, the Register syntax will look like this:
    
    	REGISTER NODE4 .fullname SYNONYM nodename ADDRESS address
    
    The address is optional.  When the management station is a Phase 4
    node, if the address is present, we will attempt to add the node into
    the local remote node database before the registration, so that it can
    succeed directly.  On Phase 5 nodes, it will be cached away so that the
    register can succeed based on input information, and we won't get in
    trouble because the node has not dna4 database.
    
    Finally, if the MCC station is a phase 4 node, and the node4 is already
    in the database with a *different* address, we won't allow the register
    to proceed.
    
    -Jim
    

    The following command is quite useful to me:
    
    MCC> SHOW NODE4 * ALL REFERENCE, WITH RESPONSIBLE PERSON = "SMITH,JOHN"
    
    It would be even nicer to have extended functionality such as
    
    MCC> SHOW NODE4 *NOD* ALL REFERENCE, WITH RESPONSIBLE PERSON ="SMI" -
    _MCC> AND LOCATION = "BUILDING 5", IN DOMAIN = .mydomain
    
    *****>>> Will wildcarding and subset strings like this be possible in
             V1.2 ?
    
    Another nice feature would be similar to the following:
    
    MCC> SET NODE4 *NOD* REFERENCE ATTRIB RESPONSIBLE PERSON = "JONES, BOB", -
    _MCC> PHONE = "EXT. 1234", IN DOMAIN = .mydomain
    
    
    Comments?

    I would  V E R Y   M U C H  like the ability to customize the "floating
    window" that appears with the click of MB2.  I use this all the time,
    but I sometimes get stuck with repetitive tasks such as ALARM ENABLEs
    and DISABLEs.
    
    On a different note, I would like some way to show ALL ALARMS, ALARMS
    ENABLED, and ALARMS DISABLED for a specific entity in a domain via the
    Iconic Map PM instead of the current list of hundreds like I have now.
    
    What about the possibility of producing "quick & dirty" column-oriented
    flat files from the MIR without having to export to Rdb & invoke DTR?
    
    One of the nice things I like about DECelms is its static screen
    display with updates of values only.  This allows me to easily spot
    real-time changes of counters at a glance, thus helping me to determine
    which counter parameters are related to a particular anomaly.  The
    current Iconic Map PM implementation requires that a screen be
    "repainted" each time counters are updated following a poll.  Until we
    have processors fast enough to repaint screens faster than the eye can
    see, I'll miss seeing the counter parameter relationships and trends.
    
    -Dan

In V1.1 the lower limit of the repeat interval of the scheduled operation time
is 10 seconds. Although I understand that this can be a drag on system 
resources and that it might be enough for Network management, it is too high
in some cases when your are trying to monitor local, memory-resident resources.

I would like to have this restriction dropped. If you want to put a limit, then
3 seconds seems reasonable although I really perefer 1 second.

For the future, I support the suggestion in .52 for the IMPM to do value 
updates without repainting the whole screen.

Thanks,
Phil