Hi,



The clauses 7.3.4.1.9, 7.3.4.1.10 and 7.3.4.1.11 from “Part6: TTCN-3 Control
Interface” describe the operations provided by the TL to log send
operations.

According to the “Constraint” description field, these logging operations
shall be called by the SA after the send operation is performed.



But looking at the input parameters defined in the prototype description of
these functions, weÂ’ve found that some of them may be hard to be passed by
the System Adaptor.

ThatÂ’s the case for the source file of the test specification (and the
number of line) under execution and, mainly, the msgValue parameter (defined
as the value to be encoded and sent).



Because SA send operations are called by the TE passing a TriMessageType as
parameter, the System Adaptor doesnÂ’t have information about the original
value (before it was encoded by the TE->CD call), so we donÂ’t understand how
will be able the SA to pass this value to the tliMSend_m operations.



We also think it could be a difficult task for the SA to get information
about which test specification file (and number of line!) is being under
execution. And this information, according to the TE->SA interface is never
provided by the TE.



In the other hand, we know that all this information is available in the TE
environment, so we wonder if these tliMSend_m operations are really called
by the SA after sending a message, because the TE seems to be a best
candidate to invoke tliMSend_m operations after calling any of the triSend
functions provided by the SA.



I have also a question regarding the “msg” parameter (TriMessageType). How
is supposed the TL has to manage this parameter? Should the TL logs the
TriMessageType as is in the log file (or a binary representation of it)?? Or
maybe it has to call the CD in order to decode this value before write it
into the log file? We can not assume the second case because TL-CD
interaction is not allowed (?).



To summarize:



Are the tliMSend_m operations really called by the SA? In that case, a
redefinition of input parameters should be done (new CR?)

Should the tliMSend_m operations be invoked by the TE? (New CR?). Parameters
defined in the functions prototype doesnÂ’t need to be reviewed.

In any case, we think a clarification should be done for how the
TriMessageType value has to be logged.



Best regards,

---

David Díaz Rodríguez

Computer Engineer

Senior SW Development Consultant



Tel.: (+34) 91 353 15 64 (Ext. 120)

Fax: (+34) 91 359 61 79

Métodos y Tecnología (MTP)

Paseo de la Castellana, 182 10º

28046 - Madrid, Spain

www.mtp.es <www.mtp.es/>

Dear David,



the tliMSend_m log event should be called by the TE as within the SA (as you already mentioned correctly) you don't have parameters like e.g. the file and line info as well as the TCI value. This should be corrected. Could you please submit a CR.



The TriMessage is the encoded TCI Value, i.e. the binary representation has to be logged here.



Cheers, Ina.





________________________________

From: active_ttcn3 : mts stf133 ttcn version 3 - active members only [This email address is being protected from spambots. You need JavaScript enabled to view it.] On Behalf Of David Diaz
Sent: Wednesday, July 11, 2007 1:32 PM
To: This email address is being protected from spambots. You need JavaScript enabled to view it.
Subject: TCI-TL interface



Hi,



The clauses 7.3.4.1.9, 7.3.4.1.10 and 7.3.4.1.11 from "Part6: TTCN-3 Control Interface" describe the operations provided by the TL to log send operations.

According to the "Constraint" description field, these logging operations shall be called by the SA after the send operation is performed.



But looking at the input parameters defined in the prototype description of these functions, we've found that some of them may be hard to be passed by the System Adaptor.

That's the case for the source file of the test specification (and the number of line) under execution and, mainly, the msgValue parameter (defined as the value to be encoded and sent).



Because SA send operations are called by the TE passing a TriMessageType as parameter, the System Adaptor doesn't have information about the original value (before it was encoded by the TE->CD call), so we don't understand how will be able the SA to pass this value to the tliMSend_m operations.



We also think it could be a difficult task for the SA to get information about which test specification file (and number of line!) is being under execution. And this information, according to the TE->SA interface is never provided by the TE.



In the other hand, we know that all this information is available in the TE environment, so we wonder if these tliMSend_m operations are really called by the SA after sending a message, because the TE seems to be a best candidate to invoke tliMSend_m operations after calling any of the triSend functions provided by the SA.



I have also a question regarding the "msg" parameter (TriMessageType). How is supposed the TL has to manage this parameter? Should the TL logs the TriMessageType as is in the log file (or a binary representation of it)?? Or maybe it has to call the CD in order to decode this value before write it into the log file? We can not assume the second case because TL-CD interaction is not allowed (?).



To summarize:



Are the tliMSend_m operations really called by the SA? In that case, a redefinition of input parameters should be done (new CR?)

Should the tliMSend_m operations be invoked by the TE? (New CR?). Parameters defined in the functions prototype doesn't need to be reviewed.

In any case, we think a clarification should be done for how the TriMessageType value has to be logged.



Best regards,

---

David Díaz Rodríguez

Computer Engineer

Senior SW Development Consultant



Tel.: (+34) 91 353 15 64 (Ext. 120)

Fax: (+34) 91 359 61 79

Métodos y Tecnología (MTP)

Paseo de la Castellana, 182 10º

28046 - Madrid, Spain

www.mtp.es <www.mtp.es/>

Thank you, Ina.

Now it is clear!



I will submit a CR.



Regards,

---

David Díaz Rodríguez

Computer Engineer

Senior SW Development Consultant



Tel.: (+34) 91 353 15 64 (Ext. 120)

Fax: (+34) 91 359 61 79

Métodos y Tecnología (MTP)

Paseo de la Castellana, 182 10º

28046 - Madrid, Spain

www.mtp.es <www.mtp.es/>



_____

De: active_ttcn3 : mts stf133 ttcn version 3 - active members only
[This email address is being protected from spambots. You need JavaScript enabled to view it.] En nombre de Schieferdecker, Ina
Enviado el: miércoles, 11 de julio de 2007 18:34
Para: This email address is being protected from spambots. You need JavaScript enabled to view it.
Asunto: Re: TCI-TL interface



Dear David,



the tliMSend_m log event should be called by the TE as within the SA (as you
already mentioned correctly) you don't have parameters like e.g. the file
and line info as well as the TCI value. This should be corrected. Could you
please submit a CR.



The TriMessage is the encoded TCI Value, i.e. the binary representation has
to be logged here.



Cheers, Ina.





_____

From: active_ttcn3 : mts stf133 ttcn version 3 - active members only
[This email address is being protected from spambots. You need JavaScript enabled to view it.] On Behalf Of David Diaz
Sent: Wednesday, July 11, 2007 1:32 PM
To: This email address is being protected from spambots. You need JavaScript enabled to view it.
Subject: TCI-TL interface



Hi,



The clauses 7.3.4.1.9, 7.3.4.1.10 and 7.3.4.1.11 from “Part6: TTCN-3 Control
Interface” describe the operations provided by the TL to log send
operations.

According to the “Constraint” description field, these logging operations
shall be called by the SA after the send operation is performed.



But looking at the input parameters defined in the prototype description of
these functions, weÂ’ve found that some of them may be hard to be passed by
the System Adaptor.

ThatÂ’s the case for the source file of the test specification (and the
number of line) under execution and, mainly, the msgValue parameter (defined
as the value to be encoded and sent).



Because SA send operations are called by the TE passing a TriMessageType as
parameter, the System Adaptor doesnÂ’t have information about the original
value (before it was encoded by the TE->CD call), so we donÂ’t understand how
will be able the SA to pass this value to the tliMSend_m operations.



We also think it could be a difficult task for the SA to get information
about which test specification file (and number of line!) is being under
execution. And this information, according to the TE->SA interface is never
provided by the TE.



In the other hand, we know that all this information is available in the TE
environment, so we wonder if these tliMSend_m operations are really called
by the SA after sending a message, because the TE seems to be a best
candidate to invoke tliMSend_m operations after calling any of the triSend
functions provided by the SA.



I have also a question regarding the “msg” parameter (TriMessageType). How
is supposed the TL has to manage this parameter? Should the TL logs the
TriMessageType as is in the log file (or a binary representation of it)?? Or
maybe it has to call the CD in order to decode this value before write it
into the log file? We can not assume the second case because TL-CD
interaction is not allowed (?).



To summarize:



Are the tliMSend_m operations really called by the SA? In that case, a
redefinition of input parameters should be done (new CR?)

Should the tliMSend_m operations be invoked by the TE? (New CR?). Parameters
defined in the functions prototype doesnÂ’t need to be reviewed.

In any case, we think a clarification should be done for how the
TriMessageType value has to be logged.



Best regards,

---

David Díaz Rodríguez

Computer Engineer

Senior SW Development Consultant



Tel.: (+34) 91 353 15 64 (Ext. 120)

Fax: (+34) 91 359 61 79

Métodos y Tecnología (MTP)

Paseo de la Castellana, 182 10º

28046 - Madrid, Spain

www.mtp.es <www.mtp.es/>