[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference azur::mcc

Title:DECmcc user notes file. Does not replace IPMT.
Notice:Use IPMT for problems. Newsletter location in note 6187
Moderator:TAEC::BEROUD
Created:Mon Aug 21 1989
Last Modified:Wed Jun 04 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:6497
Total number of notes:27359

3627.0. "What's about Time Data Type within MCC_EA_xxx routines V1.1" by ANNECY::JACQUEMOUX () Wed Aug 26 1992 08:35

	It seems that changes within MCC_EA_xxx routines V1.1 (DECmcc V1.2)
affect TIME DATA TYPE descriptor.

For example, I'm calling from my AM the 
MCC_EA_REQUEST_ENET_PACKET routine with RESPONSE_TIMER parameter initialised
(with MCC_TIME_CREATED) as time descriptor with MCC_K_DT_INTEGER32 time data type.

The MCC_EA_REQUEST_ENET_PACKET returned status (under debugger) is
MCC_S_INVALIDTIME. It seems that the EA routine checks that the Time Data Type
of RESPONSE_TIMER would be MCC_K_DT_ABS_TIM. Is it right ?

Please could you shed me light on ?


P.S.: Piece of AM code (in PASCAL)


VAR
	.
	.
	.

    Time_dt             : mcc_t_unsigned32;
    Time_len            : mcc_t_unsigned16;
    Time_Value          : mcc_t_unsigned32;


BEGIN
     	.
	.
	.
           Time_dt        := mcc_k_dt_integer32;
           Time_Len       := 0;
           Time_Value     := Response_Timer;
           Return_status  := mcc_time_create(Resp_Timer_ptr,
                                             time_dt,
                                             time_len,
                                             time_value);
	.
	.
	.
 
             Return_status := mcc_ea_request_enet_packet(
                               Target_Address        := Bridge_addr_ptr::p_ID80
                               Host_Port_Device      := Host_port_ptr,
                               Retry_Counter         := Retry_ptr,
                               Response_Timer        := Resp_Timer_ptr,
                               Send_Data_Buffer      := Send_buff_ptr,
                               Protocol_Type         := Prot_ptr,
                               Padding               := Pad_ptr,
                               Time_Stamp            := Time_stamp_ptr,
                               Received_Data_Buffer  := Rcv_buff_ptr,
                               Host_Port_Device_Used := Host_port_used_ptr,
                               System_status         := IO_status_ptr);

END;







T.RTitleUserPersonal
Name
DateLines
3627.1One big difference between V1.1 EA and V1.2 EA...LINDAS::SZABIETWed Aug 26 1992 21:2956
>>>>        It seems that changes within MCC_EA_xxx routines V1.1 (DECmcc V1.2)
>>>>affect TIME DATA TYPE descriptor.
 
There is one change in particular between the DECmcc V1.1 Ethernet Access
Routines and DECmcc V1.2 Ethernet Access Routines that might be causing the
problem you described. 

The DECmcc V1.2 Ethernet Access Routines comply with the DECmcc SRM, whereas 
the V1.1 implementation did not.  The excerpt below is from the new DECmcc V1.2
Toolkit Release Notes, and it explains further.

Hope this helps some...maybe this is the reason you're getting the error
message.  I'll also look at some code to check on your hypothesis about the 
data type of RESPONSE TIMER.

Stay tuned... :-)

Linda


********************************************************************************
 From Section 5.1 item 4 of the *updated* V1.2 DECmcc Toolkit Release Notes:
********************************************************************************


        4. While the DECmcc V1.2 Ethernet Access Routines comply with the 
           DECmcc SRM, the V1.1 implementation did not.

           The V1.1 implementation differed in the following way:  ALL
           ARGUMENTS have another "level of indirection" inserted.  For
           example, if an argument was described in the SRM as:

               "MCC usage: LAN_Address,
                mechanism: by reference,"
 
           the V1.1 code actually implemented:

               "MCC usage: pointer to LAN_Address,
                mechanism: by reference."

           Affected routines were:

            o  mcc_ea_request_802_packet()
            o  mcc_ea_request_enet_packet()
            o  mcc_ea_request_xid()
            o  mcc_ea_show_enet_device_id()
            o  mcc_ea_show_enet_devices()
            o  mcc_ea_test_802_loopback()



 
  

    
3627.2MCC_EA response_timer argument did not changeLINDAS::SZABIETTue Sep 01 1992 15:4862
Re .0:


>>        It seems that changes within MCC_EA_xxx routines V1.1 (DECmcc V1.2)
>> affect TIME DATA TYPE descriptor.
 
I can't tell if you're trying to use V1.1 or V1.2 MCC_EA routines.  I'm pretty 
sure that the response_timer descriptor argument *did not* change between V1.1 
and V1.2.  Your error message is most likely related to the V1.1 -> V1.2 
interface change in the MCC_EA routines.  Please verify that this is not the 
case.

Other possibilities...

>> For example, I'm calling from my AM the
>> MCC_EA_REQUEST_ENET_PACKET routine with RESPONSE_TIMER parameter initialised
>> (with MCC_TIME_CREATED) as time descriptor with MCC_K_DT_INTEGER32 time data 
>> type

   Your time data type looks correct.

   Does your call to mcc_time_create return successfully?

   >>>>           Time_Value     := Response_Timer;
   >>>>           Return_status  := mcc_time_create(Resp_Timer_ptr,
   >>>>                                             time_dt,
   >>>>                                             time_len,
   >>>>                                             time_value);
 
  
   If a null pointer is passed for Time_Value, a default algorithm for           
   mcc_ea_request_enet_packet will be used. We usually specify four for our      
   Time_Value. Specifying a time value overrides the default response time       
   algorithm. What value is your Response_Timer variable set to?  

   The SRM states that if you are receiving MCC_S_INVALIDTIME after calling
   mcc_time_create, the user passed a datatype argument which is not supported.

   
>> The MCC_EA_REQUEST_ENET_PACKET returned status (under debugger) is
>> MCC_S_INVALIDTIME. It seems that the EA routine checks that the Time Data 
>> Type of RESPONSE_TIMER would be MCC_K_DT_ABS_TIM. Is it right ?

   There is no DECmcc data type MCC_K_DT_ABS_TIM.  There are datatypes           
   MCC_K_DT_BIN_ABS_TIM and MCC_DT_BIN_REL_TIM.  I don't think that the MCC_EA   
   routines check for specific data types. I do know the MCC_EA routines        
   converts a specified response timer into Binary Relative Time                 
   (MCC_K_DT_BIN_REL_TIM) format.  The engineer who worked on the MCC_EA         
   routines will be back from vacation on 9/3. If necessary, he can answer       
   specific questions as to what the EA code is doing.

   The SRM states that is you receive MCC_S_INVALIDTIME after calling 
   mcc_ea_request_enet_packet, the response timer value specified is invalid. 
   Again, please check the DECmcc SRM to make sure that the call arguments are correct. 


Hope this helps :-)

Linda

    
3627.3also remember to check out the time_stamp argumentTOOK::GUERTINIt fall down, go boomWed Sep 02 1992 13:007
    Looks like the time_stamp argument is also an mcc time descriptor,
    which must be set up correctly.  One would have to assume that if
    this parameter were garbage, that the EA routines would have to
    return INVALIDTIME.  What else could it do?
    
    Just a thought,
    -Matt.
3627.4ANNECY::JACQUEMOUXWed Sep 02 1992 13:55126


	Linda,


Thank you very much for your explanation. I interpreted the DECmcc Developer's
Toollkit V1.2 Release Notes as the opposite of the current implementation
(DECmcc V1.2) of MCC_EA argument call :-(.
The status returned by MCC_TIME_CREATE is ok, and my AM works fine as long as
I work under debugger.

Meanwhile, I've got another quite tricky problem.
My PASCAL module, which calls the MCC_EA_REQUEST_ENET_PACKET routine needs to be
compiled [NOOPTIMIZE] to avoid an ACCESS VIOLATION just after the MCC_EA call
(it seems this is in SHARE$LIBRTL). Thus, I suspect my memory allocation of the
variables that are used as arguments of the MCC_EA_ routine.

What is the required allocation attribute for the MCC_EA argument call variables?
(May be[STATIC] ...)


	Regards, Thierry - EIC T&N-E Annecy


P.S.: You can find some parts of my code below:

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

   [EXTERNAL] Function MCC_EA_Request_Enet_Packet(
                               Target_Address        : Bridge_Addr_Type;
                               Host_Port_Device      : [VOLATILE] MCC_T_Descrip
                               Retry_Counter         : [VOLATILE] MCC_T_UNSLONG
                               Response_Timer        : [VOLATILE] MCC_T_Descrip
                               Send_Data_Buffer      : MCC_T_Descriptor;
                               Protocol_Type         : _uword;
                               Padding               : Boolean;
                           VAR Time_Stamp            : MCC_T_Descriptor;
                           VAR Received_Data_Buffer  : MCC_T_Descriptor;
                           VAR Host_Port_Device_Used : MCC_T_Descriptor;
                           VAR System_Status         : MCC_T_CVR;
                               Receive_address       : [TRUNCATE] MCC_T_ID802
                               )                     : MCC_T_CVR; EXTERNAL;


[GLOBAL, CHECK(NOPOINTERS), NOOPTIMIZE] Function mcc_bridge_am__call_cea(
                                        Bridge_Address      : bridge_Addr_type;
                                    VAR Request_packet      : [VOLATILE] Varying[hi] of char;
                                    VAR Response_Packet_Ptr : XLII_Response_Packet_Ptr;
                                    VAR Time_Stamp          : mcc_t_descriptor;
                                    VAR IO_Status           : Unsigned;
                                        Enet_V2_Flag        : Boolean;
                                    VAR Device_name         : Host_port_type;
                                        Response_Timer      : Unsigned;
                                        Retry_Count         : [VOLATILE] Unsigned)
                                                            : Unsigned;
Const
    Space5 = '     ';

Type                                                 
    R_Time_ptr   = ^mcc_t_descriptor;
    U_Long_ptr   = ^Unsigned;
    U_Byte_ptr   = ^_ubyte;
    p_ID802      = ^mcc_t_id802;

Var


    Return_Status       : Unsigned;
    Zero_device         : Host_port_type;

    Host_port_Desc	: [VOLATILE] mcc_t_descriptor;

    Host_port_used_Desc,
    Send_buff_Desc,
    Rcv_buff_Desc       : mcc_t_descriptor;


    Host_port_ptr       : ^mcc_t_descriptor;
    Padding             : Boolean;
    Protocol            : _uword;
    Retry_ptr           : ^Unsigned;
    Resp_Timer_ptr      : ^mcc_t_descriptor;

    Device_used         : [VOLATILE] Host_port_type;

    Device_used_ptr     : ^Host_port_type;
    tmp_status          : unsigned;
                                 (* 011 changes *)
    Time_dt             : mcc_t_unsigned32;
    Time_len            : mcc_t_unsigned16;
    Time_Value          : mcc_t_unsigned32;
    Space5array         : Host_Port_type;
    Delete_Time_flg     : Boolean;
(* The following vars are used for re-trying on a protocol in use error*)
Re_count     : Integer;
Re_time      : Unsigned;
Request_done : Boolean;
Rcb          : Return_Control_Block;    {used for timer routine}

        (*****************************************)
Begin   (* Function mcc_bridge_am__call_cea-     *)
        (*****************************************)

	.
	.
	.

             Return_status := mcc_ea_request_enet_packet(
                               Target_Address        := Bridge_address,
                               Host_Port_Device      := Host_port_ptr^,
                               Retry_Counter         := Retry_ptr^,
                               Response_Timer        := Resp_Timer_ptr^,
                               Send_Data_Buffer      := Send_buff_desc,
                               Protocol_Type         := Protocol,
                               Padding               := Padding,
                               Time_Stamp            := Time_Stamp,
                               Received_Data_Buffer  := Rcv_buff_desc,
                               Host_Port_Device_Used := Host_port_used_desc,
                               System_status         := IO_status);

	.
	.
	.

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