Conference azur::mcc

>>  How can I read/get in my AM information which was
>>  stored in the REFERENCE screen?

  From the FCL Interface:

    show <entity> all reference

  From the AM itself:

    you'll have to code up the Show directive and issue the mcc_call_function
    call to the Registration FM to get the list of Reference Attributes.

    You can check in the Example FM code, which calls the Sample AM to see
    what you have to do to get this to work.

  /keith

Hi MCC gurus.

Another question about reference partition stored in DNS.

My customer wants to write a separate application (neither an FM nor an AM)
to retrieve informations created by DECmcc in the reference partition of a
global entity.

If I Have well understood, MCC, via the registration FM, stores reference
attributes in the DECdns name space as MCC defined attributes associated with
a DECdns object entry.

How this reference partition is stored in DECdns ?

Are these informations stored in a binary format (ILV) in DECdns ?

If yes, can the customer link its program with a DECmcc library and use the
standard routines MCC_ILV_GET_CONS_BEGIN, MCC_ILV_GET, etc...to convert
informations stored in ILV to informations directly usable by the customer
program (string, interger, etc...) ?

If somebody has already done that (I do not like to re-invent the wheel :-),
I would appreciate to have a pointer to a program which:

	- pick up MCC defined informations in DNS using the DNS API (if possible
	  under Ultrix but if it exists an example with VMS it is OK also..)

I thank you in advance,
best regards,
Damien.

 

re .1

>  From the AM itself:
>
>    you'll have to code up the Show directive and issue the mcc_call_function
>    call to the Registration FM to get the list of Reference Attributes.


According to the DECmcc SRM page 2-10 it is not allowed to do a mcc_call from
an AM to a FM !?

Is it not better to use mcc_dns routines ?  I have once tried to search the
reference attributes in the namespace with the DNS utility DNS$CONTROL, but
I did not find them. I would be interested where they are stored.

Edgar

RE: .3

> According to the DECmcc SRM page 2-10 it is not allowed to do a mcc_call from
> an AM to a FM !?

  Now doesn't that seem silly .. an AM can't call an FM .. the FM is just
  providing a service which in your case the AM needs.  I suggest that you
  code it up and call the Registration FM and get your data.  There is no
  *real* reason this can't work.

> Is it not better to use mcc_dns routines ?

  I'd stay away from call DNS directly.  You don't know how the Registration
  FM has stored the data, and frankly, you don't care.  All you *need* to 
  know is that the Registration FM is the keeper of the Reference data, and
  provides you with an abstracted mechanism (API) of managing that data.

  If you *did* call DNS to get the data, and in the next release the way
  the data was stored was changed (and the Registration FM internals changed
  accordingly) .. you'd be up-the-creek by going to DNS directly .. and 
  happy if you coded against the published API's ..  Ok?

  /keith  

>>If you *did* call DNS to get the data, and in the next release the way
>>the data was stored was changed (and the Registration FM internals changed
>>accordingly) .. you'd be up-the-creek by going to DNS directly .. and 
>>happy if you coded against the published API's ..  Ok?

Keith,
	I do agree with you.
	The only problem I see is that my customer is stingy :-)
	(by the way, does it exist a non-stingy customer ?)

	If he needs to call mcc routines (such as mcc_dns_xxx, mcc_ilv_xxx,
	etc...), DECmcc becomes therefore a prerequisite for its software...and
	he has to pay an MCC license...

	His idea was to access directly the DNS database to read informations
	created by another node which has, I hope :-), an MCC license loaded.
	I think that's why he asked if the informations stored in DNS are
	ilv-encoded.

	Now the question he asks me is the following:

	"Can I use MCC routines (such as mcc_dns_xxx, mcc_ilv_xxx) in my
	 program, use this program on a system which has not a DECmcc license
	 loaded ?"

	 Note that his application do not communicate at all with the MCC
	 modules (he does not call any mcc_call_xxx routines) and is just
	 interested in retrieving the reference attribute of global entities
	 stored by MCC in DECdns...

	 When I said stingy... :-)

	Could someone give me the response to this !@#$%^ question...

I thank you in advance,
Regards,

Damien.

>        His idea was to access directly the DNS database to read informations
>        created by another node which has, I hope :-), an MCC license loaded.

The object oriented approach of MCC does not allow access to the MIR (which DNS
is a part of) other than by using MCC routines. Accessing internal data
structures clearly is a hack and would never be supported. This is the main
reason why we built the EXPORT FM. (I'm not sure if it allows exporting of
reference data, though). 

In other words: to get data directly from MCC's MIR you need MCC routines (and
a licenese) - period. 

*Robert

P.S.: A hint from a support person: Never help a customer developing hacks. If
it breaks in the future he will get back to you (or someone else) stating: "But
I got this information from Digital, therefore it must be supported"...

re .4

>> According to the DECmcc SRM page 2-10 it is not allowed to do a mcc_call from
>> an AM to a FM !?

>  Now doesn't that seem silly .. an AM can't call an FM .. the FM is just
>  providing a service which in your case the AM needs.  I suggest that you
>  code it up and call the Registration FM and get your data.  There is no
>  *real* reason this can't work.

Keith, is this an official statement ?  Shall I go to a partner company and
tell them that the SRM is silly ? Why do we have an SRM if we can not rely
on it ?

>> Is it not better to use mcc_dns routines ?

>  I'd stay away from call DNS directly.  You don't know how the Registration
>  FM has stored the data, and frankly, you don't care.  All you *need* to 
>  know is that the Registration FM is the keeper of the Reference data, and
>  provides you with an abstracted mechanism (API) of managing that data.

>  If you *did* call DNS to get the data, and in the next release the way
>  the data was stored was changed (and the Registration FM internals changed
>  accordingly) .. you'd be up-the-creek by going to DNS directly .. and 
>  happy if you coded against the published API's ..  Ok?

Sorry, I did not mean that we should access DNS directly in an application.
I have mentioned the *mcc_dns* routines, especially the mcc_dns_read_attr_data
and mcc_dns_write_attr_data for reading and writing orphaned attributes.
Perhaps, it may be the wrong way or once again it may be silly.

Remark: I such cases we need precise answers. Partner companies or customers 
invest a lot of money in MCC development. They deserve a good support.

Edgar

    RE .5 and .7
    
    If the application is neither an FM or an AM, but simply an application
    which uses Callable MCC.  Then you can call FMs, AMs (and even PMs). 
    The Management Module rules do not apply to these applications.  They
    are like "special-purpose" PMs.
    
    An FM or AM must Enroll Dispatch Entries into either the FM or AM table
    in order to be Management Module.  In this case, rules should be
    followed.  AMs which call FMs _might_ cause problems with future releases
    of MCC.  FMs and AMs actually become a part of MCC once they enroll,
    they add functionality and accessibility to network/system
    objects/information for the rest of MCC (alarms, historical data, etc.)
    to use.  Applications, on the other hand, do not "plug-in" to MCC, and
    hence do not need to follow the same strict set of good-neighbor rules.
    
    
    Can you give an example of what Reference data you need to access and
    why?

    If you have an Access Module which needs to access FM data:
    Your Management Module can be both an FM and an AM.  There is nothing
    in the SRM which prevents this.  Technically, you can view it as two
    separate management modules if you wish.  It is purely an architectural
    delineation.  There is nothing which states that FMs and AMs must be
    be in separate source modules.  The AM may enroll dispatch entries in
    the AM table and the FM table.  Likewise, an FM may enroll dispatch
    entries in both the AM table and the FM table.

    When you need to get Reference Information, you can have the Function
    Table dispatch entry called.  Then you (the developer/architect) can
    be comfortable in the knowledge that a PM is calling an FM (or that
    an FM is calling a FM) and that an FM is calling an AM.

    Note that if you want to simply have reference information returned
    directly to the caller, then NO WORK is required.  This is because
    the Registration FM (or perhaps we should call the Reference-FM which
    so happens to live in the same source module as the Registration FM)
    already supports ALL REFERENCE on behalf of all Management Modules
    which declare the Reference Partition (and attibutes)in their MS files.

    By the way, calling the DNS routines directly is in many ways worse
    than calling the Registration FM because it violates the data
    encapulation and data sharing rules of good "O-O" programming. 
    (Although, I would assume that the information is encoded in the
    exact same format as what you would get back in Out_P from an MCC
    call.)
    
    -Matt.
    
    

Hallo Matt

Thanks for your explanations.

In my case it was a question during a DECMCC AM Development course, where
I talked about the storage of orphaned attributes on behalf of not so 
intelligent entities. The access of these attributes from inside our outside
DECmcc may be a task for the development. I hooked into this discussion
because I had problems to give a satisfying answer.

From the replies so far I conclude that the access to the services of FM's is
more flexible than my first impression from the SRM. About the function and
access dispatch table I am now more confused than before. Who is responsible
for the correct enrollment (FM or AM) of the dispatch table entries?

Studying some details I realized that the Control FM disappeared in V1.2 !?
Is this correct? What happens with the primitive services like SHOW, SET ...?

You have mentioned the callable MCC and the option to call FM's, AM's and
even PM's. The documentation for the callable MCC is so far poor. Is there
any additional doc? Any examples which could be used for educational purposes
would be very appreciated.

Edgar   

>>    Can you give an example of what Reference data you need to access and
>>    why?

The Customer uses the reference partition of a network element global entity
to store the addressing informations required to access this network element.

In this case, the Network element is accessed either via LAT ports through a DEC
server (async. lines) or via X25 router (sync. lines)

In the following drawing I assume that he uses X25. The addressing information
concerning this network element is the X25 network name and the DTE address.

In the reference partition of the "Network Element", he has therefore defined
two attributes X25_network and DTE_address. This reference partition is stored
by the MCC registration FM in the customer network-wide database maintained by
DNS.

Eth
================================================================
     |                  |                     |              |
+-----------+      +------------+      +------------+   +-----------+
| Node A    |      | DNS server |      |  Node B    |   | X25 router|
| MCC       |      +------------+      +------------+   +-----------+
+-----------+                                               ///
                                                         +-----------+
                                                         | Network   |
                                                         | Element to|
                                                         | ne managed|
                                                         +-----------+



Now, another group in this company needs also to access this network element
for a completly different purpose. And this group does NOT want to use any
MCC related software (application to be run on node B) while MCC and the
"Network Element" AM runs on node A.

This new application needs of course the addressing info to access the Network
Element. They know that this information is "somewhere" in DNS and they don't
want to duplicate it.

That's why they asked where this information is located in DNS, how it is
encoded...just to be able to retrieve it from the node B...

And the other question, can their application on node B be linked with the MCC
library which contains the routines mcc_dns_read_attr_data, mcc_ilv_get, etc...
JUST TO RETRIVE THE VALUES STRORED BY MCC IN DNS (the addressing information
to access the network element).

I understand the point of vue of the person who has written 4912.6.
For the moment we are just trying to find out if it is TECHNICALLY possible
to do that. If they need an MCC license on node B because they use the
mcc_dns_xxx, mcc_ilv_xxx routines, they WILL have to pay an MCC license.

The TECHNICAL question is just for the moment:
	Without installing any MCC kit on node B, can an application (using
	JUST mcc_dns_read_attr_data, mcc_ilv_get_xxx) run on node B ?
	I'm not sure if it's important or not (?) but for the moment, node A and
	B are Ultrix nodes and will migrate to OSF/1 as soon as they can
	(depends on the availability of the layered products they use)

I'm sorry if my previous reply was not clear enough :-(
Any advice would be VERY appreciated,
Regards,

Damien.

The TECHNICAL question is just for the moment:
>	Without installing any MCC kit on node B, can an application (using
>	JUST mcc_dns_read_attr_data, mcc_ilv_get_xxx) run on node B ?

    No.  Not without copying the necessary mcc library routines to system B
    from a system that already has MCC installed.  I don't know if 'callable
    MCC' invokes LMF checks, so it may or may not work without having a PAK
    installed on system B.  However, even if this solution *does* work, I am
    pretty certain that it constitutes theft of services [I am not a lawyer,
    nor do I play one on TV.]
 

    Also, to respond to a previous complaint that 'callable MCC' was poorly
    documented -- See section 3.7 of the "Management Module Programming"
    Guide.  There is a section of 'starter code' for a 'callable MCC'
    application there.  I have also posted (either in here or in MCC-TOOLS) a
    small,simple  'callable MCC' program to check if an entity is registered or
    not. You could use that as a starter point.

    /doug

    re: .10
>> The Customer uses the reference partition of a network element global entity
>> to store the addressing informations required to access this network element.
    
    It would appear that Reference attributes (as manipulated by the
    Registration FM) are inappropriate to use for real addressing
    information. It would be more appropriate to use the scheme employed by
    other DECmcc AMs, where addressing information is stored, and
    retrieved, by the AM itself (albeit using mcc_dns routines) as a
    so-called "orphan" attribute.
    
    The Register directive would be used by the AM to create the attribute
    entry, and any other directive would retrieve the orphaned attribute
    value in order to communicate with the entity's agent.
    
    Using a Reference attribute, via the Registration FM, leads to you wish
    to break the natural DECmcc hierarchy, which is unecessary. (Also, as
    Matt pointed out, in reality an Acess Module can have functional
    services - the real restriction is that access services should not call
    function services, and indeed there should be no reason for them to do
    so).
    
    Colin

    RE:.9
    
    	Orphaned attributes are not the same as reference attributes (as
    described in Colin's reply).  One of the things I was trying to
    describe is a "philosophy" of data sharing and encapulation.  In
    general, the component which "stashes" the data should be the same
    component which "fetches" the data.  If a different component tries to
    fetch the data directly from storage because it has partial knowledge
    that the information is "in there somewhere", then things break when
    the original component determines that it needs to change how and where
    the data is stored.  If an AM stores orphaned attribute information,
    then the AM can certainly retrieve the orphaned attribute information. 
    What we discourage is the "back-door" approach of directly reading the
    "raw" data from storage by third-party applications.  If the
    Registration FM stores data, then why can't you ask the Registration FM
    to Show you the data that it stored?  Sorry, but breaking a fundamental
    rule of good programming is NOT encouraged.  And if you ask for help in
    doing so, then you should expect push-back.  If there is a legitimate
    reason for this "back-door" approach, then I have no problems saying,
    "get a hex dump of the namespace and knock yourself out."
    
    As for who is responsible for enrollment of dispatch table entries,
    the Management Module has it's _INIT entry point called when the
    user enrolls the Management Module.  In this _INIT routine, the
    Management Module can call mcc_enr_enroll() to enroll the Access Table
    entries and/or the Function Table entries (obviously, if has both
    Access Table entries and Function Table entries would make two calls,
    one for each Dispatch Table).
    
    The Control-FM functionality was subsumed by the Information Manager
    in V1.2.  The functionality is still there, its just not in an FM.
    
    -Matt.

Thanks to all !

It was an interesting discussion and I have learned a lot. I found two
examples for callable MCC in notes 1015 and 1173. I know chapter 3.7 in
MM Programming, but I still think that one page of doc is not adequate for
such an important integration tool.

Edgar