Conference azur::mcc

I am not certain as to your question, but my interpretation of your request
is: how do I encode an exception within the out_p ilv buffer.

If this is what you are asking, you do it in the same manner used to 
encode a response. If your exception is defined as having NO arguments
then simply do a put_param_begin using the exception code, followed by
a put_param_end, this will return ONLY the exception code to the
service requestor (FM). If you do have arguments then encode each one
after the param begin, using the put or put_cons based upon the data type
of the arguments.

jill

    It doesn't appear to be so easy to me. I succeeded in coding the ILV in
    the out_p arg, by comparison with what DECnet does.
    
    But I've not yet understood:
    
    for the NOENTITY exception, I have to code this ILV:
    
    [3](   			<=> MCC_K_NO_SUCH_ENTITY
    	[6](                    <=> MCC_K_ARG_UNK_ENTITY
            [0](
    		[1]	01	<=> ???
    		[2]	30	<=> Class Code of my entity
    		[3]	01	<=> ???
    		[4]	05	<=> Datatype FullName
    		[5]	code for in_entity
    		)
    	    )
    	)
    
    For Another error such as DNS_E_NOCOMMUNICATION (Exception
    MCC_K_CANNOT_COMPLETE), the following works fine (without giving the
    exception code):
    
    [2](		<=> MCC_K_ARG_MCC_ERR
    	[1]	01	<=> ???
    	[2]	01de8022<=> error code
    	)
    
    Could you give me some explanations about that ?
                   

    This encoding looks fine, you an compare it to another one in the system.
    Define the MCC_FCL_PM_LOG to 8 and then enter MCC, type the command
    "SHOW BRIDGE .GARBAGE ALL CHAR", you will receive the same exception,
    no such entity.
    
    [3](   			<=> MCC_K_NO_SUCH_ENTITY
    	[6](                    <=> MCC_K_ARG_UNK_ENTITY
            [0](                    Full entity (AES)
    		[1]	01	<=> (used by AES)
    		[2]	30	<=> Class Code of my entity
    		[3]	01	<=> (used by AES)
    		[4]	05	<=> Datatype FullName
    		[5]	data        fullname value 
    		)
    	    )
    	)
    
    If your entity spec (AES) in the previous case had had more than one
    level to the spec, then you would have seen the 1..5 arguments
    repeated.
    
    The second encoding looks different because it is encoding a different
    type of data. It is also be interpretted different then you stated.
    If you are returning a CVR of common_exception then it means:
    
    [2](		<=> UNABLE TO COMPLETE OPERATION EXCECPTION CODE
        [1]     01	<=> PROBLEM PERSISTENCE ARGUMENT
    	[2]	01de8022<=> MCC ROUTINE ERROR ARGUMENT
    	)
    
    To check these out get into dap and look up the codes:
    
    $manage/tool/dictionary
    DAP> SHOW CLASS COMMON EXCEPTION CODE 2
    DAP> SHOW ARGUMENT CODE 1
    DAP> PREV
    DAP> SHOW ARGUMENT CODE 2
    
    jill
    
    

    re .2
    
    The [1] ... [5] level of encoding is done for you by ILV.  Don't worry
    about what it means.  When you're encoding the [0] part (which is
    the AES), just make sure your descriptor is pointing at the correct
    AES.  The ILV encoding will handle FullEntity datatypes for you.
    
    Christine