Conference azur::mcc

Orna,

Some answers to your questions : 

>    1. How do I cause a certain REFERENCE field to be a manadatory one;
>       meaning: the user must enter a value?

    The short version is : you cannot.
    The long version :
    When an entity gets added to the map, a box is displayed where the
    creation arguments and the reference attributes can be entered. For
    creation arguments, it is possible to specify that the argument is
    mandatory (REQUIRED=TRUE), but the Iconic Map PM use a set directive to
    set the values of the reference attributes and it is not possible to
    require attributes to be mandatory on a set.

    If you are developing your own AM, there might be another possibility
    which is to make this attribute an orphean attribute stored in the MIR
    or in DNS. In that case, define the attribute in the characteristic
    partition, specify it as mandatory on thecreate directive arguments and
    add in the AM the code to handle it. The AM needs to known that this
    attribute is not returned by the entity and will store/retrieve it from
    either the MIR (using mcc_mir routines) or from DNS (using mcc_dns
    routines).

>    2. One of the REFERENCE fields is of type REAL. Evereything goes well
>       but when we need to display its value, we get not what we want.
>       We see its value onlt when we treat it as a string.

    I am not aware of such a problem, but I am not a Registration FM
    specialist. Sorry.
    
>    3. Another customer of mine is writing an AM to a device which is
>       connected with RS232 to the ULTRIX DECstation. They write to the
>       device some characters and wait for characters as an answer.
>       The write session works ok but during the reading session they
>       get this error message:
>       %MCC-E_RECEIVEERROR error trying to receive a packet.
>       Detached process failure: No such file or directory.

    The RECEIVEERROR message is returned by a client, like a PM or an FM,
    when an AM exits instead of returning the mcc_call response. The second
    line seems to be what is returned by the AM that exits in all the
    cases.
    
    I think it means that the AM has accepted the request, but exits
    (i.e. crashes) before returning the response. I would investigate with the
    AM.

    By the way, if the functionality needed for that AM is to be able to
    handle events and alarms, then the ASCII AM from TeMIP would be a good
    solution. It is a lot easier to customise the ASCII AM for the
    appropriate ASCII strings that to write your own AM.

    Best regards,

    Marc.      

    Thanks very much for your response.
    Concerning the 3rd question, I would like to add more details.
    Tha AM interacts with the equipment through the serial line as follows:
    - Writes n bytes of binary data.
    - Reads n bytes of binary data, one by one until reaching a byte value
      of end-of-data from the equipment.
    
    What happens now is: The application stops accepting the equipment
    response after accepting 4-5 bytes of the equipment response, and
    displays the message I gave in .0.
    The AM activates the port-interface routine from the mcc_call.
    
    The whole AM has been completed and was working perfectly on a
    DS5000/240 with DECmcc Ver. 1.2. Since we moved the application to run
    on DS5000/200 with DECmcc Ver. 1.3, the application could never recover
    and complete any access to the equipment.
    
    I would appreciate any help that I can get,
    Thanks,
    Orna.
    

re: -.3

Orna,

As I said in my previous reply, the message you are receiving is very likely to
indicate that the AM crashes after receving the request and before sending back
the response. 

The most likely scenario seems to be a problem in the AM. Did you regenerate
(relink) it with the V1.3 kernel ? If so, did you use the thread package
provided with MCC V1.3 ?  Did you try to run your AM in debug mode to see the
origin of the problem ? 

Best regards,

Marc.

    Hi Mark,
    
    1. Yes, we recompiled the AM on DECmcc Ver. 1.3.
    2. Yes, we use the THREADs packets which come with Ver. 1.3.
    3. The funny thing is that when we wanted to test the AM in debug mode,
       it works! The only different thing between the debug mode and the
       usual mode is that in debug mode we ignored the SIGVTALRM. Do you
       have any idea why?
    
    Thanks,
    Orna.
    

	Orna,

	From what I have heard, using dbx changes the way memory is used in a 
	program, so you might have a core dump in non debug mode while your 
	program works in debug. 

	I would still check the AM, especially all memory allocation/ 		
	deallocation. 

	If other MM developers have other ideas, they are welcomed.

	Best regards,

	Marc.