Conference azur::mcc

>    After dumping all this information I have collect on you (the MCC
>    development community), is this something wrong in MCC or is there
>    something I should be doing (other than not building ILV constructions
>    with so many elements)?  Your help would be greatly appricitated.
 
There is a bug in the FCL.  We're not setting the mcc$w_maxstrlen field
in the descriptor when calling you back after receiving the MCC_S_INSUF_BUF 
error.  

This will be fixed in the EFT update kit.

Thanks for the excellent problem report.

regards,

Pete

    Thanks for you quick response.
    
    	I updated my code to set mcc$w_maxstrlen to the appropriate value
    and now I'm able to build the 255 member set and dump OUT_P using
    MCC$ILV_DUMP but I get the error:
    
    	%MCC-E-ILV_BADLISTTUPL, Bad list tuple
    
    from FCL (alias TRM).  My code does the same thing as the SRM
    recommends.  Is this my problem (if so, how can I track this down) or
    is it a problem with MCC (or FCL)?
    
    ~Jon.

I don't have the answer for your BADLISTTUPL question.  FCL doesn't generate
the error itself; it must be coming back from an ILV routine.  That makes me
suspect your building or our decoding of the list.  But I don't know which to
suspect more at this point.

As far as tracking it down further, start by turning on the ILV dump and making
sure that what FCL is seeing is what you're intending to build.  Then check
to make sure that what you're intending to build is valid stuff.

One thing I did want to make sure that we're clear on is that your setting of 
the mcc$w_maxstrlen field is a work-around, not a permanent fix.  That field 
should be read-only for you.

re: .2

>    	%MCC-E-ILV_BADLISTTUPL, Bad list tuple
>    

Do you have the SRM update #1 (see note 166 or thereabouts) and are you
using ILV MODE according to those directions?  Check that you are using
MCC_K_ILV_LIST_VALUE mode correctly, and that your .MS matches your
encoding.  I suspect that you are encoding your constructor datatype
in MCC_K_ILV_NATIVE_VALUE mode and sending it back in a Response whose 
arguments are specifed as datatype ATTRIB_LIST in the dictionary 
(which is built from your .MS).  This could cause FCL (TRM), which is
using the dictionary to decode your buffer, to try to read the contents of 
the buffer in the wrong mode.


I can't guess more without seeing at least the .ms, and a dump of the encoding.
If I missed my guess above, please contact me by mail.


Ruth Kohls
(TOOK::KOHLS)

    
    Hi Ruth,
    
    	I reran my AM with the logging enabled and output going to a file.
    When I look at the file I get the error:
    
    	%MCC-E-ILVSYNTAXERROR,  the ASN.1 value's data type conflicts
    				with supplied type
    
    This leads me to suspect you are correct.  I do have the update and
    programmed my code like the example in the book.  The AM I wrote is
    extremely similar to the SAMPLE AM.  It still uses ILV_PUT_LIST for
    most of the parameters and ILV_PUT for a SET OF LATIN1STRING
    construction.  Everything worked fine until I created the construction. 
    I'm not sure which data type is not liked.  Everything works fine when
    I ask to see any part of the data (ie: a specific attribute within the
    STATUS attribute group).  If I ask to see all of the STATUS attributes,
    I get errors.  I'm not sure what is expected or if mixing ILV_PUT_LIST
    with ILV_PUT is causing problems.  Any help would be grealy
    appreciated.
    
    ~Jon.

re: .-1

>    I get errors.  I'm not sure what is expected or if mixing ILV_PUT_LIST
>    with ILV_PUT is causing problems.  

Mixing ILV_LIST_PUT... encoding with ILV MODE decoding is the root of this 
problem.  In the future, tell me the version (from SHOW MCC  0 all char)
of the kernel you are having problems with.
(The rest of this reply will be appearing in several places.)


Ruth
			**** WARNING *****

in the EFT Update, UT1.0.1, ILV_LIST_... (except for ILV_LIST_GET_DATATYPE)
 ARE GONE.  You WILL see ACCVIOS if you still use these calls.

			***** WARNING 2 *****

in the EFT UPdate, the OLD ILV calls (without MODE) are NOT permitted, and
there IS NO ERROR MESSAGE.  (There is no truly portable way to count the
arguments passed to a C function.)  

USE THE ILV routines with MODE, as documented in the SRM UPdate or ECO #37.

			INTERPRETATION:

for the calls ILV_PUT_CONS_BEGIN( Context, IDcode, datatype, reason, mode)

	     ILV_PUT(Context, Valuedescriptor, reason)

		ILV_GET_CONS_BEGIN( Context, Reason, Mode)

	     ILV_GET(Context, Valuedescriptor, reason)


	 where you are currently in mode = MCC_K_ILV_NATIVE_VALUE, pass
unneeded parameters (datatype, reason) as 0 by value.  Since 0 is
a valid reasoncode (MCC_K_REASN_SUCC_OP) and a valid datatype code (null),
this convention allows ILV to do _some_ error checking.  

 a call to open a construction for encoding in LIST MODE when the current 
mode is NATIVE looks like:

nocode = 0;
	
status = mcc_ilv_put_cons_begin( &Ctx, &Id, nocode,
			nocode, &MCC_K_ILV_LIST_VALUE).

	    where you are currently in mode = MCC_K_ILV_LIST_VALUE, pass
all parameters by reference (this call would open a LIST mode 
construction inside a list mode construction):

status = mcc_ilv_put_cons_begin( &Ctx, &Id, &inputdatatype,
			&inputreasoncode, &MCC_K_ILV_LIST_VALUE).


		HINTS and SUGGESTIONS:

o PUT_PARAM_BEGIN puts you in NATIVE mode.

o Don't forget to Close constructions or use PUT_PARAM_END.

o Reads are non-destructive--you can always back up and start over.
o Get_Id always gets the next id, and may pop out of a construction.
o Fnd_ID always locates the first copy of an idcode at the current nesting 
  level.

o Make sure the descriptors are initialized!  
o ILV uses Static Descriptor conventions with "constructed" entity specs as 
  the only exception.
o the mcc_b_flags field of a Value Descriptor should be 0 except if you
  are encoding an IMPLEMENTATION DEFAULT.  
o The mcc_b_ver field Must be 1 for now (Use the symbol defined in 
  mcc_interface_def for descriptor version)

o Use the symbols for MCC_K_ILV_LIST_VALUE and MCC_K_ILV_NATIVE_VALUE,
  the reason codes and the datatype codes (look in ch9 of the SRM). 
  The value of these symbols, like any symbol, may change.