Dear TTCN-3'ler,

among the proposals for new features, which the TTCN-3 maintenance team
discussed last week, there was a proposal, which deals with the return
values for functions called in the START operation.

Currently, it is allowed use a function, which has a return value,
in a START component operation. However, the return value is lost,
when the component terminates.

The proposal is now that the return value is saved by the test system
and to give access to the return value by extending the DONE operation.
For this, the DONE operation is extended to a complete receiving
operation. The syntax of DONE becomes similar to a RECEIVE operation,
i.e., matching with the return value and value assignment to variables
will be allowed. It will look like:

MyPTC.DONE (MyTemplate) -> value MyVar

where MyTemplate and MyVar are of the type of the return value
of the function with which MyPTC has been started.

I don't want to repeat the complete proposal here, but only present
the idea.

The TTCN-3 maintenance team would now like to know what your opinion
about this kind of extension is. Do you have any use for such an
extension? Please comment!

Kind regards
Jens Grabowski


--

======================================================================
Prof. Dr. Jens Grabowski
Institut für Informatik
Universität Göttingen E-mail:
Lotzestrasse 16-18 This email address is being protected from spambots. You need JavaScript enabled to view it.
D-37083 Göttingen, Deutschland
www.ifi.informatik.uni-goettingen.de/

until July I am mainly reachable at

Institute for Telematics phone: +49 451 500 3723
University of Luebeck fax: +49 451 500 3722
Ratzeburger Allee 160 eMail: This email address is being protected from spambots. You need JavaScript enabled to view it.
D-23538 Luebeck or This email address is being protected from spambots. You need JavaScript enabled to view it.
(Germany) WWW: www.itm.mu-luebeck.de
======================================================================

Hi,

The extended done operation is needed (at least) when you have to retain values from a PTC. Just some conventional telecom use cases:
1) In SCCP the standard specifies that SCCP local references shall remain frosen for some time after the SCCP connection is released. Therefore implementations normally swivel round local reference values used. So, it is quite essential to know in a test case, which source and destination local references have been used in previous test cases (to avoid re-using and check if the IUT do not re-use previous values). When the SCCP connection is handled by a PTC (as in most cases), today the only way to preserve any value from the PTC is by using co-ordination messages (sent to the MTC and then returning to the control part as an inout parameter). But this is a rather nasty thing in the code (extra ports, extra messages, extra defaults to catch extra messages etc.).
2) The test case shall check if the layer 3 call reference allocated by the IUT in the previous test case is really freed up when the call has been released (at the end of the previous test case). Here we need to return a value to re-use it and not to avoid; but otherwise the problem is similar to the previous one.

PS: Obviously both specifying the template to be matched and saving of the received value are optional (but no saving without matching), just like the receive operation. So, all 3 "forms"
MyPTC.done; // and
MyPTC.done (MyTemplate); //and
MyPTC.done (MyTemplate) -> value MyVar;
should be allowed that assures backward compatibility.

BR, Gyorgy

>

---

Original Message

---

> From: Jens Grabowski [This email address is being protected from spambots. You need JavaScript enabled to view it.]
> Sent: Monday, September 22, 2003 11:10 AM
> To: This email address is being protected from spambots. You need JavaScript enabled to view it.
> Subject: Extension of DONE operation
>
>
> Dear TTCN-3'ler,
>
> among the proposals for new features, which the TTCN-3
> maintenance team
> discussed last week, there was a proposal, which deals with the return
> values for functions called in the START operation.
>
> Currently, it is allowed use a function, which has a return value,
> in a START component operation. However, the return value is lost,
> when the component terminates.
>
> The proposal is now that the return value is saved by the test system
> and to give access to the return value by extending the DONE
> operation.
> For this, the DONE operation is extended to a complete receiving
> operation. The syntax of DONE becomes similar to a RECEIVE operation,
> i.e., matching with the return value and value assignment to variables
> will be allowed. It will look like:
>
> MyPTC.DONE (MyTemplate) -> value MyVar
>
> where MyTemplate and MyVar are of the type of the return value
> of the function with which MyPTC has been started.
>
> I don't want to repeat the complete proposal here, but only present
> the idea.
>
> The TTCN-3 maintenance team would now like to know what your opinion
> about this kind of extension is. Do you have any use for such an
> extension? Please comment!
>
> Kind regards
> Jens Grabowski
>
>
> --
>
> ======================================================================
> Prof. Dr. Jens Grabowski
> Institut für Informatik
> Universität Göttingen E-mail:
> Lotzestrasse 16-18 This email address is being protected from spambots. You need JavaScript enabled to view it.
> D-37083 Göttingen, Deutschland
> www.ifi.informatik.uni-goettingen.de/
>
> until July I am mainly reachable at
>
> Institute for Telematics phone: +49 451 500 3723
> University of Luebeck fax: +49 451 500 3722
> Ratzeburger Allee 160 eMail: This email address is being protected from spambots. You need JavaScript enabled to view it.
> D-23538 Luebeck or This email address is being protected from spambots. You need JavaScript enabled to view it.
> (Germany) WWW: www.itm.mu-luebeck.de
> ======================================================================
>

Hello all,

let me share my thoughts about this with you:

a) Regarding György's examples: example 2) is related to passing information from test case to test case and has nothing to do with return values of functions started on behaviour. Also the first part of example 1) has to do with passing information from test case to test case. Therefore in the example we are looking at a way to avoid sending the SCCP local reference from the component handling the connection to some other component. In this case returning this local reference can make sense, although one could imagine other schemes with extra components keeping track of which references are already used in a test case.

Let's see what happens if we open this box:

b) return values have actually to be returned
There are at least four ways how the behaviour on a test component could stop. I ignore that the whole test case terminates. 1) A stop statement is executed on the component itself, 2) a return statement is executed in the function used in the start statement, 3) the last statement in the function used in the start statement is executed, 4) Another component executes <ptc>.stop

I think only case 2) allows to actually return properly a value. One could also extend the stop statement to stop <value>, but only in the case that it is executed on the component itself. Still this might be problematic when using a stop statement e.g. in an altstep used as default. This might be problematic because some altsteps might be used in different behaviours and what should be returned then?

Case 4) above implies that when stopping a component externally, one has to be prepared to have done statements catching return values and to have done statements catching absence of return values. When stopped externally, the stopped component has no chance to create and return a value.

Case 3) above implies also that one has to be prepared for components terminating without passing a return value, but this might be considered as badly written TTCN-3.

c) What happens if a function is started that should return a value, but actually terminates without returning one? Is this a runtime error? This can be handled similarly to usual function calls, but is still complicated by stop statements.

d) The return value has to be received: In an actual done statement with value redirection there is absolutely no relation between the component instance and the type of the return value. Functions with various return value types can be started on the same component type, therefore there are few things that can be checked at compile time, which in turn can lead to various runtime errors.
If there is a done statement with a template and no return value is returned from the component, then I think this should block. Matching a template against an absent return value simply fails. Alternatively this could be a runtime error.

e) component references can be exchanged among test components
Several test components can have a <ptc>.done statement for the same ptc. Hence a possible return value should be available to each of them.

This are my thoughts, although not really not the examples Jens asked for.

Best regards

Thomas

>

---

Original Message

---

> From: ext György Réthy (IJ/ETH) [This email address is being protected from spambots. You need JavaScript enabled to view it.]
> Sent: Monday, September 22, 2003 4:42 PM
> To: This email address is being protected from spambots. You need JavaScript enabled to view it.
> Subject: Re: Extension of DONE operation
>
>
> Hi,
>
> The extended done operation is needed (at least) when you
> have to retain values from a PTC. Just some conventional
> telecom use cases:
> 1) In SCCP the standard specifies that SCCP local references
> shall remain frosen for some time after the SCCP connection
> is released. Therefore implementations normally swivel round
> local reference values used. So, it is quite essential to
> know in a test case, which source and destination local
> references have been used in previous test cases (to avoid
> re-using and check if the IUT do not re-use previous values).
> When the SCCP connection is handled by a PTC (as in most
> cases), today the only way to preserve any value from the PTC
> is by using co-ordination messages (sent to the MTC and then
> returning to the control part as an inout parameter). But
> this is a rather nasty thing in the code (extra ports, extra
> messages, extra defaults to catch extra messages etc.).
> 2) The test case shall check if the layer 3 call reference
> allocated by the IUT in the previous test case is really
> freed up when the call has been released (at the end of the
> previous test case). Here we need to return a value to re-use
> it and not to avoid; but otherwise the problem is similar to
> the previous one.
>
> PS: Obviously both specifying the template to be matched and
> saving of the received value are optional (but no saving
> without matching), just like the receive operation. So, all 3 "forms"
> MyPTC.done; // and
> MyPTC.done (MyTemplate); //and
> MyPTC.done (MyTemplate) -> value MyVar;
> should be allowed that assures backward compatibility.
>
> BR, Gyorgy
>
> >

---

Original Message

---

> > From: Jens Grabowski [This email address is being protected from spambots. You need JavaScript enabled to view it.]
> > Sent: Monday, September 22, 2003 11:10 AM
> > To: This email address is being protected from spambots. You need JavaScript enabled to view it.
> > Subject: Extension of DONE operation
> >
> >
> > Dear TTCN-3'ler,
> >
> > among the proposals for new features, which the TTCN-3
> > maintenance team
> > discussed last week, there was a proposal, which deals with
> the return
> > values for functions called in the START operation.
> >
> > Currently, it is allowed use a function, which has a return value,
> > in a START component operation. However, the return value is lost,
> > when the component terminates.
> >
> > The proposal is now that the return value is saved by the
> test system
> > and to give access to the return value by extending the DONE
> > operation.
> > For this, the DONE operation is extended to a complete receiving
> > operation. The syntax of DONE becomes similar to a RECEIVE
> operation,
> > i.e., matching with the return value and value assignment
> to variables
> > will be allowed. It will look like:
> >
> > MyPTC.DONE (MyTemplate) -> value MyVar
> >
> > where MyTemplate and MyVar are of the type of the return value
> > of the function with which MyPTC has been started.
> >
> > I don't want to repeat the complete proposal here, but only present
> > the idea.
> >
> > The TTCN-3 maintenance team would now like to know what your opinion
> > about this kind of extension is. Do you have any use for such an
> > extension? Please comment!
> >
> > Kind regards
> > Jens Grabowski
> >
> >
> > --
> >
> >
> ======================================================================
> > Prof. Dr. Jens Grabowski
> > Institut für Informatik
> > Universität Göttingen E-mail:
> > Lotzestrasse 16-18
> This email address is being protected from spambots. You need JavaScript enabled to view it.
> > D-37083 Göttingen, Deutschland
> > www.ifi.informatik.uni-goettingen.de/
> >
> > until July I am mainly reachable at
> >
> > Institute for Telematics phone: +49 451 500 3723
> > University of Luebeck fax: +49 451 500 3722
> > Ratzeburger Allee 160 eMail: This email address is being protected from spambots. You need JavaScript enabled to view it.
> > D-23538 Luebeck or This email address is being protected from spambots. You need JavaScript enabled to view it.
> > (Germany) WWW:
www.itm.mu-luebeck.de
> ======================================================================
>

Hi All,

This discussion touches on something that I've always regarded as a bit of
an impediment in TTCN-3. That is the disallowance of global data, which, if
I understand correctly, is due to consideration for TTCN-3 vendors
implementing on a process-based, as opposed to a thread-based,
environment/operating system.

It seems an unfortunate side effect is that issues like those identified by
György (and other issues that I can think of) require unnatural solutions,
such as using extra PTCs to keep track data. For me, I'm using external
functions to do the job because a lot of times, I only require an MTC and
don't want the complication of PTCs and passing forwards and backwards of
unnecessary messages and cluttering up my code.

So the question is, why not allow global data and let the process-based
TTCN-3 vendors (are there that many of them anyway?) tackle the issue of
global data (writing to files, or passing messages to an auxiliary process
that maintains global data, etc). I know that, for at least 2
implementations (Telelogic Tau G2 Tester and Testing Technologies), this
should not be a problem because they are or can be thread-based. I think the
natural solution of allowing global data would benefit everyone using TTCN-3
in the long run.

Your feedback would be most welcome.


Best Regards

Ray Cheung

---

Motorola
Global Telecom Solutions Sector
Thamesdown Drive
Groundwell
Swindon
Wiltshire
SN25 4XY
Phone: +44 (0)1793 565529
Fax: +44 (0)1793 541228

---

---

Original Message

---

From: Thomas Deiss [This email address is being protected from spambots. You need JavaScript enabled to view it.]
Sent: 23 September 2003 08:12
To: This email address is being protected from spambots. You need JavaScript enabled to view it.
Subject: Re: Extension of DONE operation


Hello all,

let me share my thoughts about this with you:

a) Regarding György's examples: example 2) is related to passing information
from test case to test case and has nothing to do with return values of
functions started on behaviour. Also the first part of example 1) has to do
with passing information from test case to test case. Therefore in the
example we are looking at a way to avoid sending the SCCP local reference
from the component handling the connection to some other component. In this
case returning this local reference can make sense, although one could
imagine other schemes with extra components keeping track of which
references are already used in a test case.

Let's see what happens if we open this box:

b) return values have actually to be returned
There are at least four ways how the behaviour on a test component could
stop. I ignore that the whole test case terminates. 1) A stop statement is
executed on the component itself, 2) a return statement is executed in the
function used in the start statement, 3) the last statement in the function
used in the start statement is executed, 4) Another component executes
<ptc>.stop

I think only case 2) allows to actually return properly a value. One could
also extend the stop statement to stop <value>, but only in the case that it
is executed on the component itself. Still this might be problematic when
using a stop statement e.g. in an altstep used as default. This might be
problematic because some altsteps might be used in different behaviours and
what should be returned then?

Case 4) above implies that when stopping a component externally, one has to
be prepared to have done statements catching return values and to have done
statements catching absence of return values. When stopped externally, the
stopped component has no chance to create and return a value.

Case 3) above implies also that one has to be prepared for components
terminating without passing a return value, but this might be considered as
badly written TTCN-3.

c) What happens if a function is started that should return a value, but
actually terminates without returning one? Is this a runtime error? This can
be handled similarly to usual function calls, but is still complicated by
stop statements.

d) The return value has to be received: In an actual done statement with
value redirection there is absolutely no relation between the component
instance and the type of the return value. Functions with various return
value types can be started on the same component type, therefore there are
few things that can be checked at compile time, which in turn can lead to
various runtime errors.
If there is a done statement with a template and no return value is returned
from the component, then I think this should block. Matching a template
against an absent return value simply fails. Alternatively this could be a
runtime error.

e) component references can be exchanged among test components
Several test components can have a <ptc>.done statement for the same ptc.
Hence a possible return value should be available to each of them.

This are my thoughts, although not really not the examples Jens asked for.

Best regards

Thomas

>

---

Original Message

---

> From: ext György Réthy (IJ/ETH) [This email address is being protected from spambots. You need JavaScript enabled to view it.]
> Sent: Monday, September 22, 2003 4:42 PM
> To: This email address is being protected from spambots. You need JavaScript enabled to view it.
> Subject: Re: Extension of DONE operation
>
>
> Hi,
>
> The extended done operation is needed (at least) when you
> have to retain values from a PTC. Just some conventional
> telecom use cases:
> 1) In SCCP the standard specifies that SCCP local references
> shall remain frosen for some time after the SCCP connection
> is released. Therefore implementations normally swivel round
> local reference values used. So, it is quite essential to
> know in a test case, which source and destination local
> references have been used in previous test cases (to avoid
> re-using and check if the IUT do not re-use previous values).
> When the SCCP connection is handled by a PTC (as in most
> cases), today the only way to preserve any value from the PTC
> is by using co-ordination messages (sent to the MTC and then
> returning to the control part as an inout parameter). But
> this is a rather nasty thing in the code (extra ports, extra
> messages, extra defaults to catch extra messages etc.).
> 2) The test case shall check if the layer 3 call reference
> allocated by the IUT in the previous test case is really
> freed up when the call has been released (at the end of the
> previous test case). Here we need to return a value to re-use
> it and not to avoid; but otherwise the problem is similar to
> the previous one.
>
> PS: Obviously both specifying the template to be matched and
> saving of the received value are optional (but no saving
> without matching), just like the receive operation. So, all 3 "forms"
> MyPTC.done; // and
> MyPTC.done (MyTemplate); //and
> MyPTC.done (MyTemplate) -> value MyVar;
> should be allowed that assures backward compatibility.
>
> BR, Gyorgy
>
> >

---

Original Message

---

> > From: Jens Grabowski [This email address is being protected from spambots. You need JavaScript enabled to view it.]
> > Sent: Monday, September 22, 2003 11:10 AM
> > To: This email address is being protected from spambots. You need JavaScript enabled to view it.
> > Subject: Extension of DONE operation
> >
> >
> > Dear TTCN-3'ler,
> >
> > among the proposals for new features, which the TTCN-3
> > maintenance team
> > discussed last week, there was a proposal, which deals with
> the return
> > values for functions called in the START operation.
> >
> > Currently, it is allowed use a function, which has a return value,
> > in a START component operation. However, the return value is lost,
> > when the component terminates.
> >
> > The proposal is now that the return value is saved by the
> test system
> > and to give access to the return value by extending the DONE
> > operation.
> > For this, the DONE operation is extended to a complete receiving
> > operation. The syntax of DONE becomes similar to a RECEIVE
> operation,
> > i.e., matching with the return value and value assignment
> to variables
> > will be allowed. It will look like:
> >
> > MyPTC.DONE (MyTemplate) -> value MyVar
> >
> > where MyTemplate and MyVar are of the type of the return value
> > of the function with which MyPTC has been started.
> >
> > I don't want to repeat the complete proposal here, but only present
> > the idea.
> >
> > The TTCN-3 maintenance team would now like to know what your opinion
> > about this kind of extension is. Do you have any use for such an
> > extension? Please comment!
> >
> > Kind regards
> > Jens Grabowski
> >
> >
> > --
> >
> >
> ======================================================================
> > Prof. Dr. Jens Grabowski
> > Institut für Informatik
> > Universität Göttingen E-mail:
> > Lotzestrasse 16-18
> This email address is being protected from spambots. You need JavaScript enabled to view it.
> > D-37083 Göttingen, Deutschland
> > www.ifi.informatik.uni-goettingen.de/
> >
> > until July I am mainly reachable at
> >
> > Institute for Telematics phone: +49 451 500 3723
> > University of Luebeck fax: +49 451 500 3722
> > Ratzeburger Allee 160 eMail: This email address is being protected from spambots. You need JavaScript enabled to view it.
> > D-23538 Luebeck or This email address is being protected from spambots. You need JavaScript enabled to view it.
> > (Germany) WWW:
www.itm.mu-luebeck.de
> ======================================================================
>

Hi,

I try to keep it short:

1) "Existing concept of test components and the exchange of information between test components via connected ports"
Again, they are fine, no one touches them and in many cases the only way to reach the wanted test behaviour. But has no direct relation to value returning done we are discussing at the moment.

2) "...user's test case logic communicates through ports."

create, start, running, stop, done etc. are part of the test case logic too.

3) "...there are some complexities there, for example, what happens if no value is returned."

I consider to be a very bad writing style to stop a component by an another component when one is expecting a return value from it. Nevertheless one always has to be prepared for unexpected events but this is a style guide/user guide issue:
alt{ [] MyPTC.done (integer:?) -> var_savehere {}
[] MyPTC.done {log "We are in a trouble, something unexpected happened")
}
This is not the only case when the TS writer has to think about unexpected events (defaults are introduced for this reason) or is able to write a code that is blocking during execution. So, I can not see any essential obstacle here.

Once again, using matching in done is not mandatory. Who needs it, lets use it; who do not needs it, let use "simple" done.

4) "If value returning done is though as some kind return value concept, I think that it could be restricted to be available in the component that originally started the component returning values."

Yes, it could be done. But you are not restricted to check the status of a component only from that component which created it. Once information on a component status is reachable from other components, I can not see any reason for artificial restrictions in the case of return values.

5) "I think that the communication though ports is the price to pay from the fact that the TTCN-3 standard does not specify how components are implemented... "

I can not see, how returning a value together with done would restrict implementations of components. If you think about some additional run-time checks, than this is almost nothing related to run-time checks a TTCN-3 system has to do on port communications...
and checking of returned value type has to be done very rarely, only when a component status is asked, the component is finished already and it has returned a value;

6) "But this could be still solved somehow, here are some ideas: ..."

Would be an overcomplicated solution of a simple problem. Except that, it would break existing TTCN-3 semantics. Again, value returning done is not about any global variable or anything like that; it is just to make it easier to get out a value from a PTC. If you would like to use "global variables", still a control part variable and inout parameterization of test cases has to be used for it.

BR, Gyorgy

>

---

Original Message

---

> From: Vesa-Matti Puro [This email address is being protected from spambots. You need JavaScript enabled to view it.]
> Sent: Wednesday, December 24, 2003 11:18 AM
> To: This email address is being protected from spambots. You need JavaScript enabled to view it.
> Subject: Re: Extension of DONE operation / global variables
>
>
> Hi all,
>
>
> György Réthy (IJ/ETH) wrote:
> > Ina's statement "TTCN-3 has currently a clear concept of test
> > components and the exchange of information between test components
> > via connected ports" sounds well but unfortunately has not much to
> > do with the given topic (except that today this is the only option
> > for the user).
>
> I think that it is good that there is a clear concepts of
> components in
> TTCN-3. Usually components are associated with encapsulatation, i.e.
> internals of the components are hidden. The behavior of the component
> can be manipulated and monitored with create, start, running, stop,
> done, ... operations. Secondly, the user's test case logic
> communicates
> through ports.
>
>
> > 2. When you write
> > AnotherPTC.done;
> > the status information regarding the another PTC's status is not
> > communicated via a port. Also: create, start(component), running,
> > stop(component) are all a form of inter-component communication
> > handled by the test system (and we could list here mtc and system
> > used in a PTC) and not via communication ports. Value returning
> > done is about to add one more information (not even an operation)
> > to the EXISTING inter-component communication model. It has nothing
> > to do with global variables or with a different model than specified
> > today.
>
> What comes to value returning done, we think that's fine for us, if
> that is needed. You are right that it does not break the existing
> "TTCN-3 component model". But as Thomas in his 23.9. email anlysed,
> there are some complexities there, for example, what happens if
> no value is returned. These needs to be just taken into account.
>
> If value returning done is though as some kind return value concept,
> I think that it could be restricted to be available in the
> component that originally started the component returning values.
>
>
> > I would like also to draw the attention to another aspect that
> > I think much more important. The use of co-ordination messages
> > between components is rather inconvenient & peevish for the USER.
> > However, no other mean when TIMING is important (so when really
> > used for co-ordination betwee ncomponents). But do not force the
> > USER to nasty solutions (like external functions as Cheung Ray
> > mentioned) when timing is unimportant. That's annoying and do not
> > increase the popularity of TTCN-3.
>
> I think that the communication though ports is the price to pay
> from the fact that the TTCN-3 standard does not specify how
> components are implemented... which is a good because it keeps
> different implementation strategies open.
>
>
> But this could be still solved somehow, here are some ideas:
>
> 1) let's allow to specify a component "local" (like ports can be
> specified "message" or "procedure"), this could open access
> to global variables that would have TTCN-2 test suite variables
> semantics (i.e. preserve value from one testcase to another).
>
> 2) let's define "threads" in TTCN-3, user could start a
> parallelly executing function that could access the
> variables of a componentn where it was started.
> This would preserve components as encapsulated
> (and possibly distributed) objects, and the user could
> use threads if she/he merely needs local parallel
> processing. These threads could have start, stop,
> running, done, ... i.e. the same methods as components
> have but they would be guaranteed to be able to access
> component variables.
>
> 3) let's define "attributes" (like in IDL) for the MTC,
> the attributes would be like global variables and
> visible for all components,
> the user would have some reminder that read/write
> operations of these attributes are not guaranteed
> to happen in the same address space.
>
>
> > I often cannot get rid of the feeling (as with this discussion)
> > that tool providers care about nice & simple tool implementation
> > ONLY and do forget about USERs' convenience and usability of the
> > language. This discussion should be about what users wish to see
> > in the language and not about what tool implementers wish to
> > implement. Only those features should be criticized by tool
> > implementers which are technically really non-implementable (that
> > I believe is NOT the case for value returning done even - as Thomas
> > pointed out - the type of the returned value can be
> checked run-time).
>
> At the moment, TTCN-3 is already one of the most complex computer
> languages designed. It includes features like "import w/ language"
> that allows combining all other languages with it, and "attributes"
> that also provides an open ended extensions.
>
> I think the value of this list is increased by the users who
> give feedback what is needed, and by the tool implementors who
> give feedback about implementability and consequences of the
> proposals.
>
> It has also some value to keep the TTCN-3 stable for some time.
> This would allow the users to adopt the language, before it is
> changed next time.
>
>
> > PS: In my examples I have written "When the SCCP connection
> is handled by a PTC...";
> > so it should be clear that when giving example for the use
> of value returning done,
> > I'm talking about how to get the value out of the PTC (by
> the MTC) and not how to
> > save it between test cases (for the example to work both is
> needed, of course)
>
> Maybe TTCN-2 style test suite variable semantics could be
> introduced. I would sound more natural to keep the state inside
> a component that move values back and forth between the "control
> part" and test cases.
>
>
> Best regards,
> Vesa-Matti
>
>
> --
> Vesa-Matti Puro
> E-mail: This email address is being protected from spambots. You need JavaScript enabled to view it.
> Tel.: +358 440396461
> OpenTTCN Oy
> Web: www.openttcn.com
>