Conference azur::mcc

4065.0. "Problems reading DNS attributes in AMs" by MANWRK::WILCOX () Wed Nov 11 1992 09:47

Hello,

I have a problem obtaining dns attributes using the mcc_dns_read_attr
call in an AM. Everything works fine if a local namespace is in use, but
when a DNS namespace in use, it appears that some entities cannot be seen.
The following scenarios show what happens. The first shows what happens
in an AM that has problems reading DNS attributes, the second shows what
heppens in an AM that works as expected.

Scenario 1
----------
We are attempting to obtain dns attributes for an entity whose full name
is a dns attribute of the 'current' entity (the entity specified by
the p_in_entity field in the dt_callargs structure passed to the
function). The following operations are performed:

    1). Get the full name of the entity whose attributes we are interested in
        using mcc_dns_read_attr, specifying the p_in_entity value as the
        entity_spec parameter. This succeeds, and returns the full name of
        the entity we are interested in, in the data_buffer parameter.
    2). Create an entity specification for the entity we are interested in
        using mcc_aes_create. The instance parameter is specified as the
        full name descriptor returned by the previous mcc_dns_read_attr call.
        Both class and type type fields are correct. This succeeds.
    3). Attempt to read an attribute from the entity using mcc_dns_read_attr,
        specifying the newly created entity specification as the entity_spec
        parameter. This fails, returning MCC_S_NOENTITY.

Scenario 2
----------
We are attempting to obtain dns attributes for the 'current' entity. The
following operations are performed:

    1). Get the full name of the entity using mcc_aes_get, specifying the
        p_in_entity value as the entity_spec. This succeeds, and returns
        the full name of the entity, in the data_buffer parameter. This
        full name is exactly the same as that returned in scenario 1.
    2). The same as for scenario 1, except that the instance parameter is
        specified as the full name descriptor returned by the previous
        mcc_aes_get call. This succeeds.
    3). The same as for scenario 1. This succeeds.

Note that in scenario 1, the entity we are interested in is the same
entity as the 'current' entity in scenario 2, so it definitely exists
in the namespace. I can't see why the two scenarios should behave differently
in the mcc_dns_read_attr call, when the only difference is in how the full
name of the entity is obtained.

Any suggestions gratefully received,

Lee.

    Lee,
        
    What is your DNS setup like, ie. are you using a read-only replica
    and do you have the patch for the master replica?  The patch corrects
    a condition where, during skulks, attributes are not propagated
    to read-only replicas.
    
    Regards,
    
    Dave Comfort

    
    RE: .0
    
    The MCC DNS routines need the mcc_l_id field of the instance used in
    the instance MCC descriptor.
    The routines use class, datatype, and identifier code to find out 
    what kind of the identifier type.
    
    For example IP name used in MCC has:
        data type of MCC_K_DT_INTERNET_NAME (= 74 stored in mcc_l_dt)
        identifier code of MCC_K_SNMP_InternetName (= 98 stored in mcc_l_id )
    
    
    In step 2 of your scenario 1, make sure that you set the mcc_l_id field
    of the fullname descriptor before calling mcc_aes_create().
    
    William
    

    Problem solved, thanks a lot.
    
    The id field wasn't being set up correctly before the mcc_aes_create.
    I have now set up the id field, and everything is fine.
    
    Thanks,
    
    Lee.