Hi,

I was just wondering if someone could help me in the understanding of
the TCI standard.

My first question is on the operation tciGetModuleParameters which is
called by the TM and implemented by TE. The text states"The TE provides
to the management a list of module parameters of the identified module.
If no module parameters exist, an empty module parameter list is
returned. If the TE cannot provide a list, the distinct null value shall
be returned."
So my question here is how does the TE return (value) information about
module parameters which have no default value specified?
A null value is not enough since then the TM has no way to figure out
the type of the module parameter - only its name.
It would be nice if the text could also be more elaborate on this issue.

My second question is about verdict values. Currently a verdict value is
a (Tci)Value which stores an integer value which returned as part of the
tciTestCaseTerminated
operation. At least in the c-mapping only a reference to the object is
returned. Here I wonder if anybody has ever considered that the TE may
delete that object before the TM has any change to access the verdict?
Or is there anything else in the standard that garuantees that this will
not happen?
So my question is why this has not been simply mapped to an integer
(alias) parameter in the operation definition .. and instead to an
object?

Thanks,
stephan

Hello!

> I was just wondering if someone could help me in the understanding of
> the TCI standard.
>
> My first question is on the operation tciGetModuleParameters which is
> called by the TM and implemented by TE. The text states"The TE provides
> to the management a list of module parameters of the identified module.
> If no module parameters exist, an empty module parameter list is
> returned. If the TE cannot provide a list, the distinct null value shall
> be returned."
> So my question here is how does the TE return (value) information about
> module parameters which have no default value specified?
> A null value is not enough since then the TM has no way to figure out
> the type of the module parameter - only its name.
> It would be nice if the text could also be more elaborate on this issue.

I guess there is an omission even in the TTCN-3 edition 3 standard here,
you cannot get that information through the TCI-TM API. I guess this
requires yuo to know the types a priori during the compile time.

We have solved this problem by giving our users a function to get
that information. This funcion is:

TciType tciGetModuleParType
(TciModuleParameterIdType parameterId);

> My second question is about verdict values. Currently a verdict value is
> a (Tci)Value which stores an integer value which returned as part of the
> tciTestCaseTerminated
> operation. At least in the c-mapping only a reference to the object is
> returned. Here I wonder if anybody has ever considered that the TE may
> delete that object before the TM has any change to access the verdict?
> Or is there anything else in the standard that garuantees that this will
> not happen?

If the specification indeed has forgotten to mention about the lifetime
of the objects, I would think that vendors need to provide this detail.
A resonable implementation would give the user the duration of the
function call time to copy any necessary information to be used
after the function call such as tciTestCaseTerminated returns.

> So my question is why this has not been simply mapped to an integer
> (alias) parameter in the operation definition .. and instead to an
> object?

I guess in European specs very simple solutions are not possible. :)

Best regards,
Vesa-Matti

--
Vesa-Matti Puro
OpenTTCN Oy
E-mail: This email address is being protected from spambots. You need JavaScript enabled to view it. * Tel.: +358 440396461 * Web: www.openttcn.com

Hi vesi-matti,

> > My first question is on the operation
> tciGetModuleParameters which is
> > called by the TM and implemented by TE.
> > So my question here is how does the TE return (value)
> information about
> > module parameters which have no default value specified?
> > A null value is not enough since then the TM has no way to
> figure out
> > the type of the module parameter - only its name.
> > It would be nice if the text could also be more elaborate
> on this issue.
>
> I guess there is an omission even in the TTCN-3 edition 3
> standard here,
> you cannot get that information through the TCI-TM API. I guess this
> requires yuo to know the types a priori during the compile time.
>
> We have solved this problem by giving our users a function to get
> that information. This funcion is:
>
> TciType tciGetModuleParType
> (TciModuleParameterIdType parameterId);

I guess another alternative would be to add a reference to the type to TciModuleParameterIdType.
That would however require to change an operation.

What is the status of CRs on this? Have you submitted one? Has ETSI already processed this?

> > My second question is about verdict values. Currently a
> verdict value is
> > a (Tci)Value which stores an integer value which returned
> as part of the
> > tciTestCaseTerminated
> > operation. Here I wonder if anybody has ever considered that
> the TE may
> > delete that object before the TM has any change to access
> the verdict?
> > Or is there anything else in the standard that garuantees
> that this will
> > not happen?
>
> If the specification indeed has forgotten to mention about
> the lifetime
> of the objects, I would think that vendors need to provide
> this detail.
> A resonable implementation would give the user the duration of the
> function call time to copy any necessary information to be used
> after the function call such as tciTestCaseTerminated returns.

Ok - I guess I did not read this closely enough. Somehow I thought this operation is called by TM. But of called it is called by TE. That resoves my concerns.

Thanks,
stephan

Hi Stephan,

>>>My first question is on the operation
>>tciGetModuleParameters which is
>>>called by the TM and implemented by TE.
>>>So my question here is how does the TE return (value)
>>information about
>>>module parameters which have no default value specified?
>>>A null value is not enough since then the TM has no way to
>>figure out
>>>the type of the module parameter - only its name.
>>>It would be nice if the text could also be more elaborate
>>on this issue.
>>
>>I guess there is an omission even in the TTCN-3 edition 3
>>standard here,
>>you cannot get that information through the TCI-TM API. I guess this
>>requires yuo to know the types a priori during the compile time.
>>
>>We have solved this problem by giving our users a function to get
>>that information. This funcion is:
>>
>>TciType tciGetModuleParType
>>(TciModuleParameterIdType parameterId);
>
> I guess another alternative would be to add a reference to the type to
TciModuleParameterIdType.
> That would however require to change an operation.
>
> What is the status of CRs on this? Have you submitted one? Has ETSI already
processed this?

We have not yet submitted a CR about this yet but we are
evaluating this solution in practise and it seems to be quite
ok. The only question is if that need is specific to
to module parameters or if it would be as well needed
to find out type of any id or reference i.e. having
TciType tciGetType(...)?

Best regards,
Vesa-Matti