Conference azur::mcc

1:
	Yes, but they will not be available until you shut down and restart 
the map.

	A:	Copy dictionary to work area
		 (including setting up the logicals to point to it...)
	B:	Update dictionary
	C:	Copy new version of dictionary into MCC_COMMON:
	D:	Restart MCC

Note that this requires 150 Kblocks free space on the disk, but does not
require MCC be shut down while you do the update.  Also, the update may 
take a while, but no longer than normal, unless MCC is really running hard
on your system.

2:
	This (1.) avoids the dictionary locked issue, but those programs
	that open the dictionary must be restarted after the update.

	The simple way to see who has the file open is

		SHO DEV MCC_COMMON:/FILES

3:
	Dont think so, but wait for an authoritative reply from someone else.

>>1:
>>	Yes, but they will not be available until you shut down and restart 
>>the map.
>>
>>	A:	Copy dictionary to work area
>>		 (including setting up the logicals to point to it...)
>>	B:	Update dictionary
>>	C:	Copy new version of dictionary into MCC_COMMON:
>>	D:	Restart MCC

>>Note that this requires 150 Kblocks free space on the disk, but does not
>>require MCC be shut down while you do the update.  Also, the update may 
>>take a while, but no longer than normal, unless MCC is really running hard
>>on your system.

So, does this mean that I could write a simple DCL procedure to do steps
A - C above, and replace step B with the ...TCP_MTU procedure then set this
up as a launched appl from the MAP?

>>2:
>>	This (1.) avoids the dictionary locked issue, but those programs
>>	that open the dictionary must be restarted after the update.
>>
>>	The simple way to see who has the file open is
>>
>>		SHO DEV MCC_COMMON:/FILES

If I copy the data dictionary as discussed in 1., and another mcc appl 
(e.g., IP Poller) has the dictionary open for read only access, what prevents
the dictionary from reflecting the same status after I've copied it to 
another directory?

>>3:
>>	Dont think so, but wait for an authoritative reply from someone else.

It would really be helpful to be able to start the IP pller automatically,
even if it's from a DCL procedure prior to starting up mcc.  The key here
would be to pass the necessary startup info as parameters in the procedure.

Merlin

Well, what you actually would do is keep a master copy of the dictionary
in some other location, and update it whenever you wanted to.  Then, to make
the updates take effect, copy it into the MCC_COMMON: area.  You will get a new
file, with a new version (at least on VMS), and then restarting MCC will cause
the new one to get used.

The reason the dictionary is opened for read only access is that internal 
pointers MUST be maintained in a consistent state, and the update procedure
is not "safe", as it may delete and add entries all over the place,
depending on what you do.  So, to prevent MCC from being corrupted by dictionary
updates, the dictionary is "locked".  You can copy it just fine,
there should be no problem (BACKUP /IGNORE=INTER ....), but you cannot
update the currently active dictionary in any case.

Also, if you copy a new dictionary to MCC_COMMON, you should be able to purge
the old one.  The directory entry will be deleted, but the fill will still
actually exist until all readers close the file, and then the space will be
marked free and the FID will be released.  (side note:  This does NOT confuse
the disk defragger, as it understands whats going on.)

	RE. IP Poller.	Unfortunately, none of the stuff you want to do
	is possible with the IP Poller shipped with V1.3. Just wait for
	the next version which will have what you are looking for.

	/rb

>>Well, what you actually would do is keep a master copy of the dictionary
>>in some other location, and update it whenever you wanted to.  Then, to make
>>the updates take effect, copy it into the MCC_COMMON: area.  You will get a new
>>file, with a new version (at least on VMS), and then restarting MCC will cause
>>the new one to get used.

I don't understand.  I thought that the dictionary was dynamic and being 
updated by MCC during normal operations such as registering devices, defining
alarms,  extracting data, etc.  If this true, then copying the "master" into
the MCC_COMMON area would create synchronization problems if I tried to do 
something else to the "master" whil MCC was in operation.  If this is not true
then enlighten me - remember that I'm a jarhead and need to go to the school
of hard bricks for enlightenment.

What is the description of the following files in the MCC_COMMON area:


	MCC_FDICTIONARY.BPT	4652
	MCC_FDICTIONARY.CTM	742
	MCC_FDICTIONARY.DAT	54528
	MCC_FDICTIONARY.LOG	13
	MCC_META_DICTIONARY.DAT	1

If what you suggested above can be done without causing other problems, then
my intentions are to create a launched appl for compiling MIBs from the map.
I would update the "master" data dictionary in some work area directory, and
instruct the user to shut mcc down and restart it after the successful 
interpretation of the new MIBs.  In the command procedure that starts mcc 
I would copy the current dictionary file(s) from the work area into MCC_COMMON
before issuing the manage/enterprise command.  Do you think this will work 
without creating havoc? If so, should all of the dictionary files above be 
moved back and forth, or just certain ones?

Thanks for the feedback thus far Dave.

				SemperFi!


Mgc

>I don't understand.  I thought that the dictionary was dynamic and being 
>updated by MCC during normal operations such as registering devices, defining
>alarms,  extracting data, etc.  If this true, then copying the "master" into
>the MCC_COMMON area would create synchronization problems if I tried to do 
>something else to the "master" whil MCC was in operation.  If this is not true
>then enlighten me - remember that I'm a jarhead and need to go to the school
>of hard bricks for enlightenment.


You're worthless and weak! Now drop and give me 20, Mister!!
	;^)  

Merlin,  the dictionary portion of the MIR is *relatively* static. Think of it
like a.. well a dictionary -- MMs go to the dictionary to 'look up' information
about object *classes*: things like events supported, attribute codes,
datatypes for attributes, etc.      The *instance* portion of the MIR (either
local MIR or that which is in DNS) is what fluctuates  as *instances* of
objects come and go... Think of it sorta like... oh i don't know ... your
checkbook, maybe.  The balance goes up & down over time.  Maybe not a good
example for some....

>If what you suggested above can be done without causing other problems, then
>my intentions are to create a launched appl for compiling MIBs from the map.
>I would update the "master" data dictionary in some work area directory, and
>instruct the user to shut mcc down and restart it after the successful 
>interpretation of the new MIBs.  In the command procedure that starts mcc 
>I would copy the current dictionary file(s) from the work area into MCC_COMMON
>before issuing the manage/enterprise command.  Do you think this will work 
>without creating havoc? If so, should all of the dictionary files above be 
>moved back and forth, or just certain ones?

Think that should work.  Have a go at it.


./doug (Gig 'em Ags!)

    Yes, the MIR is made up of many repositories. Some are
    	the Class Info (The Dictionary)
    	Command Parsing Info (The Parse Tables)
    	Class Lookinto info (the .CTM file)
    	Alarms instances (the Alarms MIR files)
    	Entity Instances (DNS or the Local repository)
    
    I use a DCL procedure to start the Iconic Map on my system anyway.
    Should be easy to check to see if the IP poller is running or not
    and if not, start it. Also, at exit time, you could check if you
    were the last instance of the Iconic Map to shut down and if so,
    stop the IP Poller.
    
    s/rob
    

RE: .5 & .6 ...


I tried what I was talking about in .5 and .6, but to no avail.

The MCC_TCPIP_MTU.COM procedure looks for the data dictionary in the
MCC_COMMON directory.  So even though I'm trying to run my MIB_COMPILER 
in a work directory that has the "master" copy of the data dictionary, when 
I call MCC_TCPIP_MTU it tries to access the dictionary in MCC_COMMON which
results in the read only access error.

Is there an easy way to get around this without changing the MCC_TCPIP_MTU.COM
procedure?

My whole purpose of doing this is to try to manage the customer's objections
to the way we handle our MIB compiling vs. the competition (HP).  From what
they described, HP is point and click from a pull down menu (launched
application).  It seems like this should be something relatively easy for MCC
to do also.

What do you think Doug?

Mgc

If you're running a DCL procedure to do all this, why not redefine MCC_COMMON
to point to your new dictionary location for the duration of the procedure ? I
would *hope* that would be sufficient to convince MTU to look in the right
place...

/doug

>>If you're running a DCL procedure to do all this, why not redefine MCC_COMMON
>>to point to your new dictionary location for the duration of the procedure ? I
>>would *hope* that would be sufficient to convince MTU to look in the right
>>place...

Yes.  But...

If I redefine the MCC_COMMON logical in the MIB_COMPILER DCL procedure
any other mcc related application (the MAP, FCL, IP Poller, etc) that uses
MCC_COMMON will pick up the wrong value for MCC_COMMON (i.e., the work 
directory that has the "master" dictionary) and these mcc appls probably will
not work.  Is this correct?

Mgc

>If I redefine the MCC_COMMON logical in the MIB_COMPILER DCL procedure
>any other mcc related application (the MAP, FCL, IP Poller, etc) that uses
>MCC_COMMON will pick up the wrong value for MCC_COMMON (i.e., the work 
>directory that has the "master" dictionary) and these mcc appls probably will
>not work.  Is this correct?

Just define it for the duration of that DCL procedure , not as a
system-wide logical.  

E.g.    $ DEFINE/USER MCC_COMMON DKA300:[WORKING_DICT_DIR]

The logical name is only picked up by any images run in the context of that
DCL procedure or process.

/doug