IBM
Contents Index Previous Next



Tool Limitations


SDL Suite and TTCN Suite Limitations

Operating System and Windowing Environment

On-Line Help and Documentation

ASN.1 Utilities

The ASN.1 Utilities handle all constructs of ASN.1 as defined in ITU-T recommendation X.680 with extensibility features, X.681 and X.682. Some of the X.683 construct are also supported. See restrictions below for unsupported constructs. There is no support for features defined in the old ASN.1 version X.208.

Restrictions to X.680

ASN.1 Utilities handle all constructs defined in X.680, the following semantic concepts of X.680 are not supported:

Restrictions to X.681
Restrictions to X.682
Restrictions to X.683
Restrictions to X.690 and X.691
Restrictions to Z.105

The following concepts of Z.105 are not supported by the ASN.1 Utilities:

Print

SDL Suite Tool Limitations

All Editors

MSC Editor

OM Editor

UML2SDL utility

Text Editor

Chinese characters can not be used using an English Windows installation. By using an English Windows installation with Chinese language support it is possible to enter Chinese characters in the Text Editor. However when the textfile is reopened the original text has been modified and are not displayed correctly.

Organizer

SDL Editor

Print

Emacs Integration (UNIX only)

Microsoft Word Integration (Windows only)

SDL Analyzer

Generic functions

The default way of generating code for SDL operators was changed in SDL Suite 4.2. This method replaces generated functions for assignments, equal test, free and predefined operators in generators with generic functions.

This means that parameter passing has changed. Parameters are passed as addresses not as values, and data structures describing the data types are needed.

This method is backward incompatible with SDL systems that uses inline C code. The function calls must be manually changed.

Implementation Restrictions

The present version of the Analyzer is an SDL-92 analyzer. The restrictions and the implementation limits are described in this section. When possible, a work-around is described.

Example 1

alternative a,b;
   abc abc t5;
   abc abc t5-2;
endalternative;
b;

The PR to GR Converter
Restrictions on Syntactic Analysis
Restrictions on Semantic Analysis
Semantic Checks that are not Performed

Analysis of the following semantic SDL rules is not performed:

Cadvanced SDL to C Compiler

Targeting Expert

CPP2SDL

SDL Simulator

SDL Explorer/Autolink

Examples

Real-Time Operating System Support

Light Integration

The same restrictions as for the SDL to C Compiler apply. See Cadvanced SDL to C Compiler.

Threaded Integration

The same restrictions as for the SDL to C Compiler apply. See Cadvanced SDL to C Compiler

TCP/IP Communication Module
Tight Integration

SDL C Compiler Driver (SCCD)

Cmicro SDL to C Compiler

Cextreme SDL to C Compiler

The following are not supported in the Cextreme SDL to C compiler:

SDL Target Tester

Application Generation with Cmicro

Use of ADTs from the SDL Suite in Cmicro

The packages and ADTs delivered with the SDL Suite are mainly to be used in Cbasic/Cadvanced applications. Some of these ADTs may however also be useful for Cmicro applications. Others cannot be used together with Cmicro as they contain references to C code from Cbasic/Cadvanced. A list of restrictions and recommendations can be found in Abstract Data Types.

Combining Cadvanced / Cmicro Code

Mixing C code from different SDL to C compilers is not possible as they use their own runtime model and runtime data structures. Trying to mix up the C code will sooner or later lead to compilation errors. This restriction is true for any kind of combination of C code, including sdth2sdl.

TTCN Suite Tool Limitations

Color Problems on Solaris

Table Editor on Solaris

Analyzer

External ASN.1 Reference

The definition of the ASN.1 type that is referred is limited:

TTCN ASN.1 BER Encoding/Decoding

The TTCN to C Compiler

The language supported by the TTCN to C compiler is a subset of the language covered by the Analyzer. This means that in some cases, constructions that have been analyzed correctly are not supported in the code generation phase. The following list describes the known limitations in the current TTCN to C compiler.

MSC Logging

The MSC generation part of an ETS is limited in scope and applicability to some particular applications. This list of limitations may be circumvented by manually editing the code in the files mscgen.h, mscgen.c, static.c and gci.c. Such edits are not supported by IBM Rational, though suggestions of improvements are welcome.

TTCN Simulator

The entire list of SDL to C Compiler limitations applies also to the Simulator, see TTCN ASN.1 BER Encoding/Decoding.

SDL and TTCN Integrated Simulator

TTCN Exerciser

Timer Duration Limitations
Value Encoding and Decoding Limitations

In general, the value encoding and decoding has been designed to be a general mechanism for reading and writing almost any value, including ones that are not part of the type system of a generated test suite. This is for being able to input totally unexpected or irregular messages. The consequence of this is also that it may be easy to "break" test suites or even the kernel by providing wildly unexpected message contents. In order to get valuable results of the simulation runs, there may be a bit of effort needed to specify the messages. While doing that, the following notes and limitations may be helpful to avoid some pitfalls:

Concurrent TTCN

TTCN Link

Auto Link

Storage Format Compatibility

System Files

The file format for system files (.sdt) changed in SDL Suite 6.3 and TTCN Suite 6.3 as compared to 6.2. SDL Suite 6.3 and TTCN Suite 6.3 can read older system files (3.0X - 5.1), but versions earlier than 4.4 cannot read the new system files.

When saving older system files with the Organizer, a conversion to the new format is performed.

SDL/GR and MSC/GR

The storage format for SDL diagrams did change in 4.1. This means that diagrams created with 4.1 cannot be opened in previous versions. SDL Suite 4.1 can still read all previous formats.

The storage format for SDL diagrams did change in 4.0. This means that diagrams created with 4.0 cannot be opened in previous versions.

The storage format for SDL and MSC diagrams did change in SDT 3.1X as compared to SDT 3.0X (and SDT 2.X). SDT 3.1X and later versions of SDL Suite and TTCN Suite can read older files, but previous versions of SDT cannot read the new format introduced in the 3.1X version.

In addition, the storage format for MSC diagrams was changed in version 3.5. Version 3.5 and 3.6 of the MSC Editor can handle the same formats as version 3.4 of the editor, but version 3.4 and earlier of the MSC Editor cannot read the new MSC format.

SDL and MSC diagrams stored in SDT 2.X and SDT 3.0X format may be opened as is into SDT 3.1X and later versions of the editors (using commands such as the SDL Editor's Open). To preserve the original diagram structure, you must however import them into the Organizer, by using the command Import SDL to build a diagram structure that may be stored on a system file.

When saving the opened SDT 2.X or 3.0X diagrams on file with SDT 3.1X and later versions of the editors, a conversion to the 3.1X format is performed. Conversion to the 3.1X format may also be performed automatically when importing the diagrams into the Organizer. The option Save imported diagrams in SDT 3.X format is used for this purpose.

Caution!

It is not possible to open files in the SDT 3.1X format in previous versions of SDT, e.g. SDT 3.0x or SDT 2.3, or to open MSC diagrams in the new 3.5 format in previous versions of the MSC Editor. Make sure you have backup copies of your diagrams.

Generated SDL Simulators and Explorers

Simulators and Explorers should be generated with the same version of the SDL Suite as they are supposed to be executed in. They might not execute as expected when executed under a SDL Simulator Graphical User Interface of a different version. To re-generate, use the Full Make facility to make sure all C files are re-generated properly.

The SDL/GR trace in the SDL Editor requires the SDL diagrams to be saved in order to function properly. (The reference mechanism in SDT 3.X assumes the existence of information that is not stored in SDT 2.X files.)

Deployment Diagrams

The 4.2 Deployment Diagram file format (*.sdp) was extended. The 4.2 Deployment Editor can read and convert .sdp files created with older versions of the Deployment Editor. However, older Deployment Editor versions can not read diagrams created with this new version.

In the 4.1 release, the Deployment Diagram file format (*.sdp) was extended. The Deployment Editor in the 4.1 release can read and convert .sdp files created with older versions of the Deployment Editor. However, older Deployment Editor versions can not read Deployment Diagrams created with the 4.1 version.

Buildscript generation is no longer supported by the Deployment Editor since the 4.1 release. Buildscripts are replaced by a feature which translates Deployment Diagrams into the Partitioning Diagram Models, which are used by the Targeting Expert. This makes it possible to utilize a partitioning configuration in a Deployment Diagram when building SDL systems using the Targeting Expert.

As buildscript generation is no longer supported, build settings on node and component level are ignored when an old Deployment Diagram is converted into 4.1 format. Qualifier data on object level is automatically translated.

The TTCN Suite Database Compatibility

This section describes the different versions of the TTCN Suite database formats and how they are converted to each other. The following table shows the what formats are used in each TTCN Suite version:

TTCN Suite Database version Description

2.0, 2.1

0

Base version.

2.2

1

This version stores additional analyzer info.

3.0x

2

Corrected order of DefaultsRef and Configuration in TestCase.

3.1x

3

Support for Modular TTCN and encoding/decoding added. Changed to the compound format containing both the structure and the tables.

3.2, 3.3, 3.4, 3.5, 3.6, 4.0

4

Store some additional analyzer info and also restructured the content a little.

4.1, 4.2, 4.3, 4.4

5

Changed parse data structure.

4.5

6

Changed parse data structure.

4.5.4, 4.6

7

Support for groups for constraints.

4.6.1, 5.0, 5.1, 6.0, 6.1, 6.2, 6.3

8

Changed parse data structure.

The Database Upgrade

When the TTCN Suite opens an old database, it checks if it is possible to convert the database to the current version via the TTCN Suite TTCN-MP format. A conversion program for this old database version must be available. The name of this program has a suffix which indicates the version number of the database. For example the program which is used to convert a database of version 4 is called mp-output-old4.

This program is installed in the TTCN Suite 6.3 release. It is used to convert databases of version 4 to MP format. The resulting MP file is then converted to GR format as usual. This mechanism solves the problem of backward compatibility. The TTCN Suite or a newer TTCN Suite version can open an old version of the TTCN Suite database.

Forward Compatibility

A special problem occurs when an old TTCN Suite version needs to open a new version of the TTCN Suite database (forward compatibility). This problem is not relevant between database versions 0, 1 and 2 since the transfer format (MP) is the same. But the MP format which is used in 3.1 and later releases have extensions. Another problem occurs because the 3.1 and later databases are stored in a single file (compound format) with extension .itex instead of the .itex/.itex-tables combo of previous versions.

In the TTCN Suite 6.3, the database contains documents of one of these types:

Conversion of a new database of type Module to an old 3.0x or earlier database is not possible. The only forward compatibility which is supported is for the databases of type Test Suite or Modular Test Suite.

This conversion mechanism is possible to retrofit into an older existing 3.X installation by copying the programs mp-output-old6 and
convert-to-old6 from the 6.3 installation's binary directory for the architecture(s) installed and put these copied files into the corresponding directory in the old 3.X installation tree (these files are present in the current release for primarily this reason).

To make a 3.0x version able to convert from 6.3 databases it also needs the companion file with the extension .itex-tables to exist beside the 3.6 database file. Fortunately this file may be a dummy file containing nothing at all.


http://www.ibm.com/rational
Contents Index Previous Next