Source Code Portability Profiles

The primary objective of porting an application is to reconstruct an application on a target platform with minimal or no source code changes and to have the reconstructed application's behaviour identical to that of the original implementation.

Application portability requires more than source code transfer. It also requires that:

1. The source and target platforms each have an implementation of the language that:

   • is the same as that which the source code is written in

   • supports the same syntax and semantics

   • has the same limits imposed on the language.

2. When applications are written in different languages, the various languages must share common data types and data passing semantics when a program segment written in one language invokes a program segment written in another language.

3. For applications which make use of various platform services, the platform services on the source and target platforms must support the same APIs, both in calling convention and exhibited behaviours.

The remainder of this chapter details how SPIRIT has addressed requirements 1. and 2. above.

SPIRIT Language Profiles

SPIRIT Portability Enhanced Languages

SPIRIT Issue 3.0 contains profiles for the following languages:

• C Language

• COBOL Language

• SQL Language.

These SPIRIT language profiles were created to enhance portability of programs written in them. Portability of the C run-time library is also addressed in Part 6, Languages.

Additionally, SPIRIT specifies the STDL language for transaction processing applications. The description of the STDL environment places additional constraints on the use of the other languages, again for the purpose of application portability. Collectively, these are referred to as the SPIRIT portability-enhanced languages, or simply the SPIRIT languages.

The individual language profiles are complemented by the inter-language calls profile, which deals with cross-language issues. The inter-language calls profile is part of each language profile. See Inter-language Calls Profile .

The SPIRIT languages provide sufficient functionality to support a range of applications and the profiles are of sufficient detail to enable those applications to be ported across different vendor platforms.

For the other general-purpose languages, such as FORTRAN, C++ and Pascal, SPIRIT Issue 3.0 only specifies the base standard. Since these languages do not have profiles in this issue of SPIRIT, the degree of portability of applications coded using them is not assured when compared to those coded exclusively in the SPIRIT languages.

Language Limitations for Portability and Interoperability

Each set of language processors available on a given platform has its own architectural limits, such as maximum length of a character string, or numerical precision. If these specifications for limits differ, an application might not be able to compute correctly, or might even fail to run, when it passes data to or invokes another platform. Therefore, limits need to be considered for portability and interoperability between heterogeneous platforms.

• External name/identifier length must be 8 characters to ensure portability and interoperability.

• The first character of an external name must be alphabetic (A-Z).

• Characters 2 through 8 of an external name can be alphabetic (A-Z) or numeric (0-9).

• Individual language specifications or platform combinations may permit other options. Consult the individual specifications for more detail.

Inter-language Calls Profile

Objectives and Requirements

The main objectives of defining the inter-language calls profile is to enhance application portability when applications are written in different languages. This requires the following capabilities:

• Inter-language calls

  A module written in one SPIRIT language must be able to call a module written in another language.

• Support of data types

  When an inter-language call is needed, the data types used in parameter declarations in each language must be defined.

• Data type mapping

  The transfer of data between programs written in different languages must be achieved and also between programs written in the same languages on different vendor implementations.

Inter-language Calls

Outline

An inter-language call is an invocation of a module written in one SPIRIT language by a module written in another language. SPIRIT, however, does not specify actual call methods, nor does it mandate particular call semantics such as passing data by reference or passing data by value. Additional constraints are defined for transaction processing.

Conditions of Conformity

Implementations shall provide the capability of inter-language calls, and the passed data shall conform to the specifications defined here.

Definition of Inter-language Calls

This section defines the possible combinations for calling program modules written in different languages.

An application program written in C must be able to call a program written in COBOL, and an application program written in COBOL must be able to call an application program written in C.

STDL programs must be able to call programs written in C and COBOL, subject to environmental restrictions. See LANG/TXN-1 for details.

Inter-language calls between SQL and C and between SQL and COBOL are defined in the SPIRIT SQL specifications. See Part 6, Languages.

Support of Data Types

Outline

The kinds of data types relating to data transfer and the interfaces relating to the representation formats are defined. The strict definitions of each data type shall conform to the definitions of respective language specifications.

Conditions of Conformity

When a module written in one language calls a module written in another language, the data types used in parameter declarations in each language must be defined according to the correspondence defined in Data Type Mapping .

Definition of Data Type

Each program must be able to declare and use the following types when transferring data according to the correspondence defined in Data Type Mapping .

In this definition, for "n", "m", "a" and "b", an appropriate decimal digit is designated.

1. Base type

   1. Alphanumeric character string type

      A string of n fixed-length characters which can represent the characters of the alphanumeric character set defined in Character Sets .

   2. Short binary integer type

      The integer value represented by the radix of 2. The accuracy is more than or equal to decimal four digits.

   3. Unsigned short binary integer type

      The positive integer represented by the radix of 2. The accuracy is more than or equal to decimal four digits.

   4. Long binary integer type

      The integer value represented by the radix of 2. The accuracy is more than or equal to decimal nine digits.

   5. Unsigned long binary integer type

      Positive integer represented by the radix of 2. The accuracy is more than or equal to decimal nine digits.

   6. Fixed-point-number type

      The real number represented by fixed scaling, having the accuracy of decimal a digits and scaling of b digits. Accuracy ranging to decimal 15 digits or more and the scale from 0 to the accuracy.

   7. Bit string type

      Bit string represented by 8 bits.

   8. Kanji character string type

      A string of n fixed-length Kanji characters which can represent the Kanji character set defined in Character Sets .

   9. Katakana character string type

      A string of n fixed-length characters which can represent the characters of the alphanumeric character set and the characters of the Katakana character set defined in Character Sets .

   10. ISO Latin-1 character string type

       A string of n fixed characters which can represent the characters of the ISO Latin-1 character set defined in Character Sets .

   11. ISO Latin-2 character string type

       A string of n fixed characters which can represent the characters of the ISO Latin-2 character set defined in Character Sets .

2. Derived type

   1. Array

      Repetition of any same data type <type>, having dimensions in accordance with the number of repetition structures.

   2. Variable repetition array

      Repetition of any same data type <type>. The number of repetitions is variable.

   3. Record

      Combination of any data types.

Data Type Mapping

Outline

This section specifies the mapping between data types defined in different languages so that the transfer of data between modules written in different languages will be the same on different platform implementations. Mapping is based on the data types defined in Support of Data Types .

Conditions of Conformity

For data types defined in Support of Data Types , the mapping is defined across SPIRIT languages. It must be possible to map data types in each specified language to corresponding data types in other specified languages. In other words, data must be mappable and transferable between specified languages.

This part does not specify how data is transferred between languages, nor does it specify call semantics for transferring data between languages.

This part specifies data type mappings across C, COBOL and STDL. Data type mappings between SQL and C and between SQL and COBOL are defined in the SPIRIT SQL specifications. See Part 6, Languages for details.

Definition of Data Type Mapping

The data types to which data is possibly transferred and the data types mapping in respective languages are as follows:

In this definition, "-" indicates that the type cannot be handled in this language. For n, m, a and b, an appropriate decimal digit is designated, and for id, number, rec and rec0, an appropriate name is designated. An M indicates an integer which depends on the implementation for representing its data type.

1. Alphanumeric character string type:

   COBOL:

   PIC X(n)

   C:

   char id[n]

   STDL:

   TEXT CHARACTER SET SIMPLE-LATIN SIZE n

   The data transferred can be used directly as a character string of the alphanumeric character set.

2. Short binary integer type

   COBOL:

   PIC S9(4) USAGE BINARY

   C:

   short
   (or equivalent signed short, short int or signed short int)

   STDL:

   -

   The data transferred can be used directly as an integer of the short binary integer type.

3. Unsigned short binary integer type:

   COBOL:

   PIC 9(4) USAGE BINARY

   C:

   unsigned short
   (or equivalent unsigned short int)

   STDL:

   -

   The data transferred can be used directly as an integer of the unsigned short binary integer type.

4. Long binary integer type:

   COBOL:

   PIC S9(9) USAGE BINARY

   C:

   implementation-defined data type.

   This data type must satisfy the requirement 1. Base type, d. of Definition of Data Type .*

   STDL:

   INTEGER

   The data transferred can be used directly as an integer of the long binary integer type.
   

5. Unsigned long binary integer type:

   COBOL:

   PIC 9(9) USAGE BINARY

   C:

   Implementation-defined data type.

   This data type must satisfy the requirement 1. Base type, e. of Definition of Data Type .*

   STDL:

   -

   The data transferred can be used directly as an integer of the unsigned long binary integer type.

6. Fixed-point-number type:

   COBOL:

   PIC S9(a-b)V9(b) USAGE BINARY
   SIGN IS LEADING SEPARATE CHARACTER

   C:

   char id[a+1]

   STDL:

   DECIMAL STRING SIZE a SCALE b

   Excluding C, the data transferred can be used directly as a real number of the fixed decimal number type.

   In C, the data transferred is a character string in EXFOR-5 signed NR1 format; that is, a row of one sign (or blank character) and digits which does not include characters indicating a decimal point. For that reason, an application program should convert the representation to a decimal-number.

7. Bit string type:

   COBOL:

   PIC X

   C:

   char

   STDL:

   OCTET

8. Kanji character string type:

   COBOL:

   PIC N(n)

   C:

   char id[M]

   STDL:

   TEXT CHARACTER SET KANJI SIZE n

   Representing methods for n characters (including the size of storage area) may differ in accordance with the type of languages. For that reason, an application program should convert the representation.

9. Katakana character string type:

   COBOL:

   PIC X(M)

   C:

   char id[M]

   STDL:

   TEXT CHARACTER SET KATAKANA SIZE n

   Representing methods for n characters (including the size of storage area) may differ in accordance with the type of languages. For that reason, an application program should convert the representation.

10. ISO Latin-1 character string type:

    COBOL:

    PIC X(n)

    C:

    char id[n]

    STDL:

    TEXT CHARACTER SET ISO-LATIN-1 SIZE n

11. ISO Latin-2 character string type:

    COBOL:

    PIC x(n)

    C:

    char id[n]

    STDL:

    TEXT CHARACTER SET ISO-LATIN-2 SIZE n

12. Array:

    <One dimension>

    COBOL:

    OCCURS n <type>

    C:

    <type> id[n]

    STDL

    ARRAY SIZE n OF <type>

    <Two dimensions>

    COBOL:

    OCCURS n. OCCURS m <type>

    C:

    <type> id[n][m]

    STDL:

    ARRAY SIZE n OF ARRAY SIZE m OF <type>

    Also, arrays of three dimensions or more are mapped as above.

13. Variable repetition array:

    COBOL:

    OCCURS n TO m DEPENDING ON number <type>

    C:

    Refer to the following (the number of repetitions is identified by the application program).

    STDL:

    ARRAY SIZE n TO m DEPENDING ON number OF <type>

    The number which indicates the number of repetitions is mapped as follows including the same record as an array:

    COBOL:

    01 rec. 02 number PIC S9(9) USAGE BINARY. 02 id OCCURS n TO m DEPENDING ON number <type>.

    C:

    struct rec { long int number ; <type> id[m] ; } ;

    STDL:

    RECORD rec number INTEGER ; id ARRAY SIZE n TO m DEPENDING ON number OF <type> ; END;

    Data type mapping between C and COBOL shall not be permitted.

14. Record:

    COBOL:

    02-49
    (All structures that have level 02 to 49 are allowed.)

    C:

    struct

    STDL:

    RECORD

    Data type mapping between C and COBOL shall not be permitted.

Character Set Mapping

The following pairs of character sets of STDL and SQL mutually correspond to transfer text data encoded in the character sets:

• Alphanumeric character set

  STDL:

  SIMPLE-LATIN

  SQL:

  SIMPLE_LATIN

• Latin-1 character set

  STDL:

  ISO-LATIN-1

  SQL:

  LATIN1

• Latin-2 character set

  STDL:

  ISO-LATIN-2

  SQL:

  LATIN2

• Katakana character set

  STDL:

  KATAKANA

  SQL:

  JAPANESE_KATAKANA

• Kanji character set

  STDL:

  KANJI

  SQL:

  JAPANESE_KANJI

The following SQL named character sets have no corresponding character set in STDL:

• SQL_CHARACTER

• ASCII_GRAPHIC

• ASCII_FULL

• SQL_TEXT

• JAPANESE.

Character Set of Source Program

Source programs are written using characters supported in SPIRIT-defined character sets. For every source program, at least one of the following three character sets is supported:

• Latin-1 character set (I18N-1)

• Latin-2 character set (I18N-5)

• Union of character sets; Alphanumeric (I18N-2), Kanji (I18N-3) and Katakana (I18N-4).

Restriction for Using Multiple Character Sets

Language COBOL (LANG-2) and Human User Interface (HUI-1) are required to handle any character sets supported by SPIRIT; however, implementations may not allow use of multiple character sets at the same time.

In the case of Japanese, Simple-latin (I18N-2), Katakana (I18N-4) and Kanji (I18N-3) must be usable at the same time.

Footnotes

*

For compatibility with former versions of this specification, implementations which support 32-bit long integer type should allow use of data type long (or equivalent: signed long, long int or signed long int) as long binary integer type.

*

For compatibility with former versions of this specification, implementations which support 32-bit unsigned long integer type should allow use of data type unsigned long (or equivalent: unsigned long int) as unsigned long binary integer type.