Conference azur::mcc

    Hi,

    I have more information.  What this customer is trying to do is the 
    equivelent of mcc> sho node4 john all attributes.  

    She took the example for mcc> sho mcc 0 all attr from the "Enterprise 
    Management Architecture System Reference Manual," which does work for 
    her, and changed the instance classes to the node4 classes. which is 
    when the exception occurs.  She has added Debugging code, but is not 
    getting any extra information to help her figure out what the problem 
    is.  

    >Has anyone tried the MCC_call_access example in the Developer's Toolkit
    >Reference manual against 1.3?
    
    >I have a customer who is using this example to sho a node4.  She is
    >getting the error: MCC_S_SPECIALIZED_EXCEPTION returned from
    >MCC_CALL_ACCESS.
    
    I do have a copy of her program available if anyone is interested.
    
    Meg Evans
    
    

    I have more information.  What this customer is trying to do is the 
    equivelent of mcc> sho node4 john all attributes.  

kjn> "all attributes" is not a valid partition.  If the user types "all
kjn> attribute", the PM transforms that into several mcc_call_access 
kjn> procedure calls, one for each partition.
kjn> The specialized exception that is being retured is probably due
kjn> to an invalid value in the `partition' parameter of the mcc_call.

kjn> She needs to specify the Identifiers, Characteristics, Counters, 
kjn> or other partition using the symbols for those partitions as 
kjn> specified in mcc_vea_def.h, as the value for the `partition' 
kjn> parameter of the mcc_call.

    She took the example for mcc> sho mcc 0 all attr from the "Enterprise 
    Management Architecture System Reference Manual," which does work for 
    her, and changed the instance classes to the node4 classes. which is 
    when the exception occurs.  She has added Debugging code, but is not 
    getting any extra information to help her figure out what the problem 
    is.  

kjn> The example in the SRM Chapter 11 (page call_114) uses the 
kjn> Characteristics partition (MCC_K_ATTR_PRT_CHAR)

kjn> She should read the MM programming guide.  You can put code in your
kjn> debugging logic to dump the `out_p' parameter using the 
kjn> mcc_ilv_dump routine.  This will give the reply_id.  She can then 
kjn> look this reply_id up in the dictionary to know exactly which exception
kjn> the dna4_am is returning.
    
kjn> Another thought, she may have run into a snag with in_entity when 
kjn> she substituted the node4 for mcc.  Has she made the 
kjn> in_instance.mcc_l_dt the correct datatype for the identifier being 
kjn> provided (either phase4 name or phase4 address).  Has she made the 
kjn> in_instance.mcc_l_id field of the descriptor equal the the correct id 
kjn> code for the identifier being provided (name = 1, address = 2)?    

Good luck,
...kjn

Hi,

This is the information the customer sent back when attemting to 
dump the error information: 

She incorporated a call to mcc_ilv_dump and this is the output:

------------------------------------------------------------------------

$ run node4/nodeb
Call to MCC_AES_CREATE returned STATUS = MCC_S_NORMAL
Call to MCC_CALL_ACCESS returned MCC_S_SPECIALIZED_EXCEPTION
------------------------------------------------------------------------

$ run node4/nodeb
Call to MCC_AES_CREATE returned STATUS = MCC_S_NORMAL
Call to MCC_CALL_ACCESS returned MCC_S_SPECIALIZED_EXCEPTION
Calling MCC_ILV_DUMP.


[  347 ] (
    [  2 ]     03 26 d0 aa
    )
Call to MCC_ILV_GET_PARAM_BEGIN returned MCC_S_NORMAL
Call to MCC_ILV_GET_ID returned status = MCC_S_NORMAL, temp_desc.mcc_l_id = 2
Call to MCC_ILV_GET_CONS_BEGIN returned MCC_S_ILVNOTINCONS
Call to MCC_ILV_GET_ID returned status = MCC_S_ILVEOC, temp_desc.mcc_l_id = 2
Call to MCC_ILV_GET_CONS_END returned MCC_S_ILVNOTINCONS

--------------------------------------------------------------------------

She would like to know why the dump doesn't print out the contents of [2]
in ascii.  Is there an easy way to figure the contents of the buffer out?

Using DAP, she found that 347 corresponds to:

	Exception (9) : DECNETPHASEIVAMINTERNALERROR 347

What does it all mean?

This is her path to track the error:

--------------------------------------------------------------------------

$ manage/tool/dict
%DAP-S-USE_DICT, Using dictionary file: sys$common:[mcc]mcc_fdictionary.dat;1
 
        POLYCENTER Dictionary Administrator Program   Version V1.3.0

DAP> sho class node4 directive show
  
  Class (1) : NODE4
---> Directive (6) : SHOW
       Definition (3) : DIRECTIVE_TYPE
       Definition (3) : DISPLAY
       Definition (3) : CATEGORIES
       Definition (3) : PRESENTATION_NAME
       Request (7) : SHOW 1
       Response (8) : SUCCESS 1
       Response (8) : SUCCESSSOMEDATA 2
       Response (8) : SUCCESSNODATA 3
       Response (8) : SUCCESSSHORTERDURATION 4
       Response (8) : SUCCESSINACCURATEDATA 5
       Exception (9) : ALREADYEXISTS 301
	.
	.
	.
       Exception (9) : DECNETPHASEIVAMINTERNALERROR 347
	.
	.
	.

DAP>

  It would seem that there is something wrong with the AES that she is
  creating to pass to the node4 AM.

  First of all, the question about the ILV dump
   
  [  347 ] ( 
      [  2 ]     03 26 d0 aa 
      )

  She is correct in figuring out that 347 is the exception code.  If she
  had gone one more level down in the dictionary, she would have found
  that exception DECNETPHASEIVAMINTERNALERROR has 2 optional arguments. 
  The argument with code 2 is MCCERROR.  The MCCERROR has a datatype of
  MCC_K_DT_MCC_ERROR.  You can look this datatype up in Chapter 9 of of
  the SRM to find out what this means.  In fact, it means that some mcc
  routine that the node4 AM called on returned an error.  The node 4 AM
  returns the error code to its client. ILV-dump does not print it out
  in ascii because it is not an ascii value, it is a 32 bit integer. 

  You can turn 0326D0AA into a decimal number and search for 52875434
  mcc_msg.h to find out the error is  MCC_S_INSUFBUF_ENTITY.  If the code
  had made it as far as the user interface, the FCL would have printed out
  the text message that goes along with the error.               

  This most probably means that the node4 AM issued an mcc_aes_get and
  could not put the instance string from the AES into the alocated space. 
  This would point out to me that there is something wrong with the AES.
  She can check this out by calling mcc_aes_dump and passing the AES
  structure that she created as a parameter.  This will print out what was
  actually created.                          

  She should also check out the mcc descriptor that was used to create the
  AES.  As I mentioned in .2, the fields in the mcc descriptor that points
  to the instance value (in this case `john' ?) determine what is loaded
  into the abstract datatype.  The descriptor should look like the
  following...

      in_instance.mcc_w_maxstrlen = 4;  /* or some number larger than 4 */
      in_instance.mcc_b_dtype = DSC_K_DTYPE_T;
      in_instance.mcc_b_class = DSC_K_CLASS_S;
      in_instance.mcc_a_pointer = /*  address of string 'john'  */ ;
      in_instance.mcc_w_curlen = 4;
      in_instance.mcc_b_flags = 0;
      in_instance.mcc_b_ver = MCC_K_VER_DESCRIPTOR;
      in_instance.mcc_l_id = 1;
      in_instance.mcc_l_dt = MCC_K_DT_PHASE4NAME;
      in_instance.mcc_a_link = MCC_K_NULL_PTR;

  It is best not to use the sizeof function with a string datatype for the
  mcc_w_curlen field, as this will give you the maximum size that the
  string could possibly ever reach.  As an example, maximum size of a
  latin1string is 65,535 bytes.  The strlen function with a string doesn't
  work unless the string is null terminated.  So whatever you use to
  designate the mcc_w_curlen has to give the exact length of the value
  pointed to by the descriptor.

  good luck

  ...kjn

Hi,

My customer is getting somewhere at this point, however she is still
running into a couple of "gotchas"

She can use her identifiers to do an "MCC>show node4 john all identifiers"
just as long as the node4 is a remote node.  If she tries to show her
own node, however she is back to the special exception.

mcc> show node4 tmcc01 does work, but this doesn't.  Could this be
because of the sizeof function in her mcc_w_maxstrlen and mcc_w_curlen, or
are there other issues with seeing your own node this way?

-------------------------------------------------------------------

  strcpy( in_inst_buf, "tmcc01");
  in_instance.mcc_w_maxstrlen  = sizeof( in_inst_buf );
  in_instance.mcc_b_dtype      = DSC_K_DTYPE_Z;
  in_instance.mcc_b_class      = DSC_K_CLASS_S;
  in_instance.mcc_a_pointer    = &in_inst_buf;
  in_instance.mcc_w_curlen     = strlen( in_inst_buf );
  in_instance.mcc_b_flags      = 0;
  in_instance.mcc_b_ver        = MCC_K_VER_DESCRIPTOR;
  in_instance.mcc_l_id         = 1;                     /* from id above */
  in_instance.mcc_l_dt         = 24;                    /* from dt above */
  in_instance.mcc_a_link       = MCC_K_NULL_PTR;
  in_class                       = 12;                  /* from class above */
  wild_type = MCC_K_AES_NOT_WILD;


  status = mcc_aes_create( &p_in_entity, &in_class, &in_instance, &wild_type
);

 run node4/nodeb
Call to MCC_CALL_ACCESS returned MCC_S_SPECIALIZED_EXCEPTION
Calling MCC_ILV_DUMP.
      

[  347 ] (
    [  2 ]     03 26 d0 aa
    )

-----------------------------------------------------------------------
She is also having a simalar problem trying to show a phase v node:

"MCC> sho node nis131 all id" works, but:

----------------------------------------------------------------------

  strcpy( in_inst_buf, "nis131");
  in_instance.mcc_w_maxstrlen  = sizeof( in_inst_buf );
  in_instance.mcc_b_dtype      = DSC_K_DTYPE_Z;
  in_instance.mcc_b_class      = DSC_K_CLASS_S;
  in_instance.mcc_a_pointer    = &in_inst_buf;
  in_instance.mcc_w_curlen     = strlen( in_inst_buf );
  in_instance.mcc_b_flags      = 0;
  in_instance.mcc_b_ver        = MCC_K_VER_DESCRIPTOR;
  in_instance.mcc_l_id         = 1;                     /* from id above */
  in_instance.mcc_l_dt         = 5;                     /* from dt above */
  in_instance.mcc_a_link       = MCC_K_NULL_PTR
  in_class                       = 1;                   /* from class above */
  wild_type = MCC_K_AES_NOT_WILD;
      
   status = mcc_aes_create( &p_in_entity, &in_class, &in_instance, &wild_type
);

-----------------------------------------------------------------------------

Fails.  could this also be related to the sizeof function?

Also, where in the documenmtation is there a good explaination of 
mcc_aes_dump?

Thanks so much for the help already,

Meg

kjn>>  There are no problems looking at your own node.  We do this all 
kjn>>  the time.

kjn>>  The only thing that jumps right out at me about the node4 example 
kjn>>  below is the fact that strcpy takes a pointer to a string as the 
kjn>>  first parameter and she is passing in_inst_buf.  How is 
kjn>>  in_inst_buf declared?  Then she is passing the address of 
kjn>>  in_inst_buf to mcc_a_pointer.  Is the correct value getting in
kjn>>  to the buffer and then into the mcc_aes_create?

kjn>>  I would have to look at the output from an mcc_aes_dump to be
kjn>>  sure of the problem.

kjn>>  Try this:
kjn>>	$ define mcc_fcl_pm_log 8
		OR
kjn>	% setenv MCC_FCL_PM_LOG 8

kjn>>  Now "mcc> show node4 tmcc01" 
kjn>>  The FCL should print out the input and output args to the 
kjn>>  mcc_call, including an aes_dump of in_entity.  Compare what
kjn>>  the FCL built to an aes_dump of the entity she is building.
kjn>>  Also, it would help to have a debug printout of the runtime 
kjn>>  in_instance descriptor values.

kjn>>  It may indeed be related to some small problem with the
kjn>>  curlen or maxstrlen values.

mcc> show node4 tmcc01 does work, but this doesn't.  Could this be
because of the sizeof function in her mcc_w_maxstrlen and mcc_w_curlen, or
are there other issues with seeing your own node this way?

-------------------------------------------------------------------

  strcpy( in_inst_buf, "tmcc01");
  in_instance.mcc_w_maxstrlen  = sizeof( in_inst_buf );
  in_instance.mcc_b_dtype      = DSC_K_DTYPE_Z;
  in_instance.mcc_b_class      = DSC_K_CLASS_S;
  in_instance.mcc_a_pointer    = &in_inst_buf;
  in_instance.mcc_w_curlen     = strlen( in_inst_buf );
  in_instance.mcc_b_flags      = 0;
  in_instance.mcc_b_ver        = MCC_K_VER_DESCRIPTOR;
  in_instance.mcc_l_id         = 1;                     /* from id above */
  in_instance.mcc_l_dt         = 24;                    /* from dt above */
  in_instance.mcc_a_link       = MCC_K_NULL_PTR;
  in_class                       = 12;                  /* from class above */
  wild_type = MCC_K_AES_NOT_WILD;


  status = mcc_aes_create( &p_in_entity, &in_class, &in_instance, &wild_type
);

 run node4/nodeb
Call to MCC_CALL_ACCESS returned MCC_S_SPECIALIZED_EXCEPTION
Calling MCC_ILV_DUMP.
      

[  347 ] (
    [  2 ]     03 26 d0 aa
    )

-----------------------------------------------------------------------
She is also having a simalar problem trying to show a phase v node:

"MCC> sho node nis131 all id" works, but:

----------------------------------------------------------------------

kjn>> AhHa!  She is having a datatype problem.  Define MCC_FCL_PM_LOG as 
kjn>> above and you will clearly see a difference between what the FCL 
kjn>> builds and what your customer is building.

kjn>> The fullname datatype is NOT a string.  It is an abstract datatype
kjn>> that has an external representation that resembles a string, but 
kjn>> internally is stored in an encoded binary format.  She is supplying 
kjn>> a latin1string and telling the system it is a fullname.  When the 
kjn>> aes routines try to decode the fullname they get confused.

kjn>> She has to feed to string "nis131" to the mcc_dns_opaque_fullname 
kjn>> routine to make the string into the internal representation of a 
kjn>> fullname and then pass the address of the fullname to 
kjn>> mcc_aes_create.

  strcpy( in_inst_buf, "nis131");
  in_instance.mcc_w_maxstrlen  = sizeof( in_inst_buf );
  in_instance.mcc_b_dtype      = DSC_K_DTYPE_Z;
  in_instance.mcc_b_class      = DSC_K_CLASS_S;
  in_instance.mcc_a_pointer    = &in_inst_buf;
  in_instance.mcc_w_curlen     = strlen( in_inst_buf );
  in_instance.mcc_b_flags      = 0;
  in_instance.mcc_b_ver        = MCC_K_VER_DESCRIPTOR;
  in_instance.mcc_l_id         = 1;                     /* from id above */
  in_instance.mcc_l_dt         = 5;                     /* from dt above */
  in_instance.mcc_a_link       = MCC_K_NULL_PTR
  in_class                       = 1;                   /* from class above */
  wild_type = MCC_K_AES_NOT_WILD;
      
   status = mcc_aes_create( &p_in_entity, &in_class, &in_instance, &wild_type
);

-----------------------------------------------------------------------------

Fails.  could this also be related to the sizeof function?

Also, where in the documenmtation is there a good explaination of 
mcc_aes_dump?

kjn>>  Unfortunately, the mcc_aes_dump is not documented in theSRM as it 
kjn>>  should be.  It got overlooked. The interface is as follows:

kjn>>	 void mcc_aes_dump (MCC_A_AES entity_spec);

Thanks so much for the help already,

Meg


kjn>> ...kjn

Just one note about the node example in .6....

I was assuming, since the datatype in mcc_l_dt = 5 (MCC_K_DT_FULL_NAME), 
that your customer intended to use the fullname identifier.  If she 
wants to use the synonym, which on second thought, it looks like she 
does, then the datatype should be phase4name not fullname.  

If she is using the synonym, then she has to use the correct mcc_l_id 
(get it from the dictionary) for the synonym attribute and set the 
mcc_l_dt = MCC_K_DT_PHASE4NAME.

The fullname attribute would be the phase5 name - something like

	<namespace name>:<directory>.<node name>

Since phase 5 happily supplies defaults, if there is no directory 
between the namespace name and the last simplename (the node name), then 
when you specify just <node name> it defaults to the correct format.

Example:   (since my phase4 node runs in a phase5 network...)

	my node has a synonym of KAJUN  (its phase4 name)
		      address of 55.67  (its phase4 address)
		      name	 DEC:.tay.s.kajun (its phase5 name)

The phase5 name is the external format of the fullname datatype.  
However, if I told MCC to encode `kajun' as a fullname using the 
mcc_dns_opaque_fullname routine, it would create an external string 
representation of a fulname with the value DEC:.kajun. 

So, you have to tell your customer to decide which identifier she really 
wants to use, the synonym or the phase5 name.  If she wants to use th 
phase5 name, then she has to find out what the fullname is.  She can do 
that by   mcc> show  node  <synonym> all identifiers    This will return 
the phase5 name, the synonym, and the tower set (phase5 address).

Sorry for any confusion,

...kjn