Conference azur::mcc

first, some terminology clarification:

Do you mean to say that the user is double-clicking on an
event notification to bring up a notification detail window,
and that an error message is displayed in a box saying:

	"error in Hex String value"

?

>Because there's a very long string delivered, MCC creates a map window with
>the following message:

It appears from looking at the code that there may indeed be a limit of
about 1024 bytes of hex string data during a decode.  Is your string
that long or longer?



If that's not the problem, then it's possible that the DNA4 AM is
encoding this argument of the event incorrectly (QAR 02599, MCC012_INT).
I'll bring this to the DNA4 maintainer's attention.

Hello Pete,

many thanks for your answer. I try to tell you what happened exactly.

As I understood the customer right, he does the following in Iconic Map:

Applications - DECmcc Notification Services - Notify Requests -
 

- Operations: Create --> Entity List: node4 *
                         Events     : any events
                         Expand Notification to All Dynamic Subdomains
                         Send Notifications to Logfile When Logging is Enabled
                         Send Notifications to Map Windows
    
			 Apply

                         --> Entity List = (node4 *), Events = (any events)

As soon as an event occurs, the customer will be notified. 
He can look at the DECmcc Notification window to see which kind of event
occurred. He makes double-click on the notification line --> 
notification detail-window comes up and also a map window message for 
event 4.0, aged packet loss.

It contains:

	error in Hex String value



I don't think that the event-message is longer than 1024 bytes.
It's the normal event-text plus packet header.

I hope, this description is clearer than my Notes-entry 4300.0.

I believe, that the DNA4 AM is encoding the argument of that event incorrectly.


    
Greetings.

Mathilde Schwemmer, Digital Service Center Munich

                              

It appears that there is an error in the MSL for that
particular DNA4 event.  There are also problems with DNA4's 
handling of hex strings, which also need addressing, but we 
doubt these are causing your customer's problem.

Here is a short DAP script that will patch your customer's
dictionary to set the correct datatype for the argument
in the event report that we believe is causing the problem.
The datatype of the argument is listed in the dictionary as
being a hexstring (code 46), but is in reality an unsigned8
(code 33).

Get into DAP and then do the following commands:

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

use class node4 event agedpacketloss argument ENETVISITCOUNT
show definition value_data_type
!       value_data_type
SET DEFINITION CODE 1 TYPE LU COUNT 1 LENGTH 4 -
  VALUE 33
show definition value_data_type
exit noparsetable

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

You should see the following:
$ manage/toolkit/dictionary		! or mcc_dap on ultrix

 %DAP-S-USE_DICT, Using dictionary file: /usr/mcc/mcc_system/mcc_fdictionary.dat

        POLYCENTER Dictionary Administrator Program   Version X1.3.6

DAP> use class node4 event agedpacketloss argument ENETVISITCOUNT
DAP> show definition value_data_type

   Definition Name = VALUE_DATA_TYPE
   Type = L   Length = 4   Count = 1   Defined = TRUE   Class = S
   value[1] = 46

DAP> !       value_data_type
DAP> SET DEFINITION CODE 1 TYPE LU COUNT 1 LENGTH 4 -
_DAP>   VALUE 33
DAP> show definition value_data_type

   Definition Name = VALUE_DATA_TYPE
   Type = L   Length = 4   Count = 1   Defined = TRUE   Class = S
   value[1] = 33

DAP> exit noparsetable
$ 

it won't address your problem.  you'll need a new dna4 am.
hopefully this will squeeze into v1.3, but maybe not.

    I was able to get a fix for this into the DNA4 AM in time for
    the next fieldtest kit for T1.3.  There were two problems here.
    As Pete mentioned, one of the event arguments was defined
    in the dictionary as of type hexstring when in fact it's an unsigned8.
    The second was a bug in the AM (and EVL) in the processing of
    hexstrings.

    This is what our customers want to hear.
    
    Thanks a lot for your help.
    
    
    
    
    Regards,
    
    Mathilde.