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/>
