|
>>>> 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()
|
|
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
|
| 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.
|
|
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);
.
.
.
---------------------------------------------------------------------------------
|