Conference azur::mcc

    Lynn,
    
    When you get the MCC-E-INV_DESC error status, what DECmcc common
    routine are you calling.  Can you post the problem section of code?
    
    /keith

hi - 
This is the section of code in the do_pseudo_directive
of the show_char.c file from the design framework where the mcc_ilv_put
call returns a status of 52874802 - %MCC-E-INV_DESC-
invalid string descriptor encountered.

/*
 *  List-Put into the Reply-Output if set
 *
 *  Note that reason_code equals 0 (success) here always--
 *  due to using pseudo entity--this is normally conditional
 */

      reason_code = 0;

      if (status == MCC_S_NORMAL)
        status = mcc_ilv_put(&ctx, demochar[i], &reason_code);
       
        i++;

    } /* end while walking through the attribute array */

  } /*end if put_cons_begin was Normal */


----------------------------------------
demochar[0] has the following values:

maxstrlen	2  /* i define 2 bytes in trans.c, 1 for each LuValue used*/
		   /* in the record definition. */
mcc_b_dtype     0  /* i define as DSC_K_DTYPE_Z in trans.c */
                   /* which is defined as 0 */
mcc_b_class     1
mcc_a_pointer  address holding value of 2
curlen		2
flags		0
ver		1
id		2
dt		13
link		0

I guess I'm surprised about the invalid "string" descriptor when
I am defining LuValue as Integer8.  In my pseudo entity I define
the attribute as a short int. Are all record definitions considered
strings?

Let me know if you need more info.   thanks   lynn

                       <<< Note 3349.0 by MSBCS::DOLAN >>>
                              -< RECORD DATATYPE >-


>My objective is to have a characteristic attribute that represents
>data in the following format (22-23,10-12,8-18,27-32) so if the end user
>were setting this attribute they would type in
>"set service test pu * my_attribute (30-33,3-12)"
>
>Here's what I decided was the way I could do this:
>
>In my .ms file
>
>TYPE LuValue = 1011 Integer8[1..255];
>
>TYPE LuRange = 1012 RECORD Minimum = 1 : LuValue; Maximum = 2 : LuValue;
>		    END RECORD;
>
>TYPE LuList = 1013 SET OF LuRange; /* NOTE: I have not defined this because
>I was trying to understand RECORD datatype. Thus my current implementation
>would just have 1 LuRange as a value for my_attribute.*/
>

In the future, you will want to use the Range or the Subrange data type, but 
neither is working quite right, so your general approach to the MSL will do.

If your LuValue is to be always positive and always one byte, why not
eliminate one level of definition in your MS file as follows:

TYPE LuRange = 1012 RECORD 
			Minimum = 1 : Unsigned8; (* minimum LU in range *)
			Maximum = 2 : Unsigned8; (* maximum LU in range *)
		    END RECORD;

Another method, if your LU Values ranges are small and sparse, is to define
Enumerations for each small subrange.  Assuming you are talking SNA LUs, and
given what little I know of LUs, this probably isn't practical.

If you are talking SNA LUs, perhaps you should get in touch with a member of the
AEtius team and see what they've done.  Try Sally Martin at SMAUG::SMARTIN.

Ruth k.

  Lynn,

  Your descriptor datatype is set to MCC_K_DT_RECORD (the value 13).  You
  can not ILV encode the Record datatype directly!  I am not quite sure how
  you do this either 8(

  But, I'll give it a try - and maybe someone else can correct me.

  MCC_K_DT_RECORD is a constructed datatype; that is, made of other things.
  You have to build a construction using the ILV routines .. something like
  (in pseudo code):

  mcc_ilv_put_cons_begin( id = attribute code with the record datatype)
  mcc_ilv_put( id = record field id code, descriptor = data )
    :
    :
  mcc_ilv_put_cons_end()

  Is this helping ?

  /keith

Ruth - thanks for the suggestions!! I will try and get in touch with Sally.

The only reason I had the extra level is because 0 is not a valid value.
Do you think this is overkill?  Should I just do the data validation myself
for zero.		lynn

Lets phrase it differently--neither the mcc_ilv_xxx routines nor the
Design Framework will let you encode a Record data type in that way.
They most certainly CAN be encoded!

	Keith is correct about the method:  A record is an ordered
sequence of fields, so you need to open an ILV construction:

	for each attribute of type record:

  mcc_ilv_put_cons_begin( id = attribute code with the record datatype)	
			MODE argument will be "native".
	mcc_ilv_put( id in descriptor = id of first field, )
	mcc_ilv_put( id in descriptor = id of next field )
	etc.
	(you can put constructions inside constructions, to a total of 12
	deep, including the outermost.  I've heard that the design framework
	hides some of this from users, but if you go too deep you will get 
	an error message, "MCC_S_ILVPASTLIMIT" or something similar.)

	when you have all the record fields encoded,
  mcc_ilv_put_cons_end(...) will close the record construction.
	
	Chapter 11 of the SRM has the routine details.
	
About the MSL, there is a trade-off.  The dictionary data is also ilv-encoded, 
and with the descriptive (meta) data it needs to interpret private (MSL TYPE) 
data types, the limit on nesting private data types inside private data types
comes to 5.  
	So, 1) you save 2 nesting levels for complex TYPE definitions by
checking for the invalid 0 in your code.  But,
	    2) If the LU value range definition could be used a lot 
of places, having the LUvalue validated on the way in by the UI is very useful.

Ruth K.

The datatype  you  need  seems  to be exactly the same as the set of channel
ranges   used  for  X.25  DTEs.   The  syntax  there  is  SET  OF  RANGE  OF
INTEGER[0..1024].  The user visible representation is {[1..10],[40..50]}.

That is exactly what the RANGE OF type was designed for!

.3> In the future, you will want to use the Range or the Subrange data type, but 
.3> neither is working quite right, so your general approach to the MSL will do.

If they  aren't working right I hope they are very high up the priority list
to  fix  because they are key for Phase V X.25 management!  I would expect a
CLD from a European DECmcc user fairly soon after they go to Phase V if this
doesn't work.

Graham

Yes, Range is high on my list, in second place at the moment.

In the interests of a quicker resolution, have you ever tried to display 
your Set of Ranges with MCC?  If so, what was the result? 

Regards,

Ruth K.