EntireX IDL to C mapping
Learn the specific mapping of EntireX IDL data types, groups, arrays and structures to the C programming language.
See also hints and restrictions on the EntireX IDL data types valid for all programming language bindings under IDL data types in the IDL Editor documentation.
Mapping IDL data types to C data types
- The metasymbols
[and]enclose optional lexical entities. - The informal term number (or in some cases number1.number2) is a sequence of numeric characters, for example 123.
| EntireX IDL | Description | C Data Type | Note |
|---|---|---|---|
| Anumber | Alphanumeric | unsigned char [number] | 1,3 |
| char [number + 1] | 1,3 | ||
| AV | Alphanumeric variable length | ERX_HVDATA | 4 |
| AVnumber | Alphanumeric variable length with maximum length | ERX_HVDATA | 3,4 |
| Bnumber | Binary | unsigned char [number] | 3 |
| BV | Binary variable length | ERX_HVDATA | 4 |
| BVnumber | Binary variable length with maximum length | ERX_HVDATA | 4 |
| D | Date | unsigned char [ERX_GET_PACKED_LEN(7)] | 3,5,8,12,14,15 |
| F4 | Floating point (small) | float | 11 |
| F8 | Floating point (large) | double | 11 |
| I1 | Integer (small) | signed char | |
| I2 | Integer (medium) | signed short | |
| I4 | Integer (large) | signed long | |
| Knumber | Kanji | unsigned char [number] | 3 |
| KV | Kanji variable length | ERX_HVDATA | 4 |
| KVnumber | Kanji variable length with maximum length | ERX_HVDATA | 3,4 |
| L | Logical | unsigned char | 6 |
| Nnumber1[.number2] | Unpacked decimal | double | 9 |
| unsigned char[number1 + number2] | 7,9 | ||
| NUnumber1[.number2] | Unpacked decimal unsigned | double | 9 |
| unsigned char[number1 + number2] | 7,9 | ||
| Pnumber1[.number2] | Packed decimal | double | 10 |
| unsigned char[ERX_GET_PACKED_LEN(number1 + number2)] | 8,10 | ||
| PUnumber1[.number2] | Packed decimal unsigned | double | 10 |
| unsigned char[ERX_GET_PACKED_LEN(number1 + number2)] | 8,10 | ||
| T | Time | unsigned char[ERX_GET_PACKED_LEN(13)] | 5,8,13,14,16 |
| Unumber | Unicode | wchar_t[number] | 2,17,18 |
| wchar [number + 1] | 2,17,18 | ||
| UV | Unicode variable length | ERX_HVDATA | 4,17 |
| UVnumber | Unicode variable length with maximum length | ERX_HVDATA | 4,17,19 |
See also hints and restrictions on the EntireX IDL data types valid for all programming language bindings under IDL data types in the IDL Editor documentation.
- It is possible to map the data type to the C data type
unsigned char[..]without null termination (mainframe Natural, COBOL, PL/I style) or C style string (C data typechar[.. + 1]with null termination). The mapping is controlled with the Mapping options when you generate source files from IDL. See Generate C source files from EntireX IDL files . - It is possible to map the data type to the C data type
wchar_t[..]without null termination (mainframe Natural, COBOL, PL/I style) or to a C style wide character string ( C data typewchar_t[.. + 1]with null termination). The mapping is controlled with the Mapping options when you generate source files from IDL. See Generate C source files from EntireX IDL files . - The field length is given in bytes.
- The data type ERX_HVDATA is an RPC-specific data type in the header file erxVData.h for handling variable-length data types. See API Function Descriptions for Variable-length Data Types AV, BV, KV and UV.
- Date and Time values are mapped in mainframe-style packed format.
- The binary value zero is treated as
FALSE. Contents other than a binary zero are treated asTRUE. - Unpacked format is an internal representation of numbers with a specified number of digits used in mainframe environments (Natural, COBOL, PL/I).
- Packed format is an internal representation of numbers with a specified number of digits used in
mainframe environments (Natural, COBOL, PL/I).
ERX_GET_PACKED_LENGTHis a macro within the header fileerx.hused to evaluate the length of a field in bytes with packed contents. - It is possible to map the data type to double or unpacked. The mapping is controlled with the
Mapping
options when you generate source files from IDL. See Generate C source files from EntireX
IDL files.
- For unpacked, the total number of digits (number1+number2) is 99.
- For double, it depends on your target environment how many significant digits are supported. In most environments 15 - 16 digits, which means for exact results the total number of digits (number1+number2) should be less than 16.
- It is possible to map the data type to double or packed. The mapping is controlled with the
Mapping
options when you generate source files from IDL. See Generate C source files from EntireX
IDL files.
- For unpacked the total number of digits (number1+number2) is 99.
- For double, it depends on your target environment how many significant digits are supported. In most environments 15 - 16 digits, which means for exact results the total number of digits (number1+number2) should be less than 16.
- For
floatanddouble, rounding errors can occur, so that the values of senders and receivers might differ. - Count of days AD (anno domini, after the birth of Christ). The valid range is from 1.1.0001 up
to 28.11.2737. Mapping of the number to the date in the complete range from 1.1.0001 on, follows the
Julian and Gregorian calendar, taking into consideration the following rules:
- 1
- Years that are evenly divisible by 4 are leap years.
- 2
- Years that are evenly divisible by 100 are not leap years unless rule 3, below, is true.
- 3
- Years that are evenly divisible by 400 are leap years.
- 4
- Before the year 1582 AD, rule 1 from the Julian calendar is used. After the year 1582 AD, rules 1, 2 and 3 of the Gregorian calendar are used.
See the following table for the relation of the packed number to a real date:Table 2. Relation of the packed number to a real date Date / Range of Dates Value / Range of Values 1.1.0000 0 (special value - no date) undefined dates 1 - 364 (do not use) 1.1.0001 365 1.1.1970 719527 (start of C-time functions) 28.11.2737 999999 (maximum date) - Count of tenth of seconds AD (anno domini, after the birth of Christ). The valid range is from
1.1.0001 00:00:00.0 up to 16.11.3168 9:46:39 plus 0.9 seconds. See the following table for the relation of the packed number to a real time:
Table 3. Relation of the packed number to a real time Time / Range of Times Value / Range of Values 1.1.0000 00:00:00.0 0 (special value - no time) undefined times 1 - 315359999 1.1.0001 00:00:00.0 315360000 1.1.1970 00:00:00.0 621671328000 (start of C-time functions) - The relation between the packed number of a Date and Time data type is as follows:
tenths of a second per day =24*60*60*10 = 864000 number of time = number of date * 864000 315360000 = 365 * 864000 1.1.0001 00:00:00.0 621671328000 = 719527 * 864000 1.1.1970 00:00:00.0 number of date = number of time / 864000 365 = 315360000 / 864000 1.1.0001 719527 = 621671328000 / 864000 1.1.1970 - The
no datevalue is the internal state of a#DATE(Natural type D) variable after aRESET #DATEis executed within Natural programs. This internal state is not a valid date. Theno datevalue can be transferred as the invalid date 1.1.0 from RPC clients to servers and vice versa. C Wrapper supports Naturalno datevalue. C Wrapper passes 0 to the C application whenno dateis received. With the same value of 0, the C application can sendno dateto its partner (client or server). - The
no timevalue is the internal state of a#TIME(Natural type T) variable after aRESET #TIMEis executed within Natural programs. This internal state is not a valid time. Theno timevalue can be transferred as the invalid time 1.1.0 0:00:00.0 from RPC clients to servers and vice versa. C Wrapper supports Naturalno timevalue. C Wrapper passes 0 to the C application whenno timeis received. With the same value of 0, the C application can sendno timeto its partner (client or server). - The Unicode encoding provided (on receive) or expected (on send) on the API depends on the width
of the
wchar_tdata type in your environment:The endianness (big endian or little endian) of the Unicode encoding that is used (UTF-16-LE, UTF-16-BE, UTF32-LE or UTF32-BE) is the same as the hardware architecture of the machine.Table 4. Unicode encoding Size of wchar_t UTF Version Used 2 bytes (Windows) UTF-16 4 bytes (Linux) UTF-32 - In environments where
sizeof(wchar_t)is 4 bytes, only Unicode characters from the Basic Multilingual Plane are supported (code points U+0000 to U+FFFF except U+D800 to U+DFFF reserved for leading and trailing surrogates). Unicode characters from Supplementary Planes (code points U+10000 to U+10FFFF) are not supported. - In environments where
sizeof(wchar_t)is 4 bytes, the number of UTF-16 Unicode code points (after character conversion from UTF-32 to UTF-16) must be less than or equal to number. Note the following:- Unicode characters from the Basic Multilingual Plane (code points U+0000 to U+FFFF except U+D800 to U+DFFF, reserved for leading and trailing surrogates) require one code point in UTF-16
- Unicode characters from Supplementary Planes (code points U+10000 to U+10FFFF) require two code points in UTF-16
Mapping library name and alias
The library name as specified in the IDL file is sent from a client to the server. Special characters are not replaced. The library alias is not sent to the server.
In the RPC server, the IDL library name sent may be used to locate the target server. See Locating and Calling the Target Server under z/OS (CICS, Batch, IMS) | C | .NET.
The library name as given in the IDL file is used to compose the names of the generated output files. See library-definition under EntireX IDL Grammar in the IDL Editor documentation. Therefore the allowed characters are restricted by the underlying file system.
For the server interface object, the name is composed with a prefix D as
Dlibrary-name.c and for the server as
library-name.c. For the client interface object the name is
composed with a prefix C as Clibrary name.c. For both interface
objects the same header file Clibrary-name.h is also used. When
the name of the generated sources is built, lower and uppercase characters are considered and the
special characters '#', '$', '&', '+', '-', '.', '/' and '@' used in the name for libraries are
replaced by the character underscore '_'. Other special characters used in the library name are not
changed and may lead to problems with your underlying file system.
Aliases for the library name in the IDL file are not supported in C Wrapper language binding. See library-definition.
Examples:
- A library name of
#HU$GO. results inC_HU_GO_.candC_HU_GO_.has the client interface object file name for the generated source. - A library name of
#HU$GO. results inD_HU_GO_.candC_HU_GO_.has the server interface object file name for the generated source.
Mapping program name and alias
The program name is sent from a client to the server. Special characters are not replaced. The program alias is not sent to the server.
In the RPC server, the IDL program name sent is used to locate the target server. See Locating and Calling the Target Server under z/OS (CICS, Batch, IMS) | C | .NET.
The program names as given in the IDL file are mapped to functions within the generated C sources. See program-definition under EntireX IDL Grammar in the IDL Editor documentation. When building function names, lower and uppercase characters are considered and the special characters '#', '$', '&', '+', '-', '.', '/' and '@' are replaced by the character underscore '_' valid for C names. Other special characters used in the program name are not changed and may lead to compilation errors when compiling the generated sources.
Aliases for the program name in the program-definition are not supported in C Wrapper language binding.
Example: A parameter name of #HU$GO. results in
_HU_GO_ as the function name for the C programming language.
Mapping parameter names
The parameter names as given in the IDL file are mapped to parameters of the generated C functions. See parameter-data-definition under EntireX IDL Grammar in the IDL Editor documentation. When building parameters, lower and uppercase characters are considered and the special characters '#', '$', '&', '+', '-', '.', '/' and '@' are replaced by the character underscore '_' valid for C names.
Example: A parameter name of #HU$GO. results in _HU_GO_ as the
parameter name for the C programming language.
Mapping fixed and unbounded arrays
- Fixed arrays within the IDL file are mapped to fixed C arrays. The upper bound given in the IDL
file is decremented by 1 because C arrays always start with the lower bound 0. For example the
number (I2/5) in the IDL file will be mapped to
signed short number [4].See the array-definition under EntireX IDL Grammar in the IDL Editor documentation for the syntax on how to describe fixed arrays within the IDL file and refer to fixed-bound-array-index.
- Unbounded arrays within the IDL file are mapped to the
ERX_HARRAYdata type found in the header fileerxArray.h. See using ubounded arrays.See the array-definition for the syntax of unbounded arrays within the IDL file and refer to unbounded-array-index.
Mapping groups and periodic groups
Groups within the IDL file are mapped to the C data type struct. See the group-parameter-definition under EntireX IDL Grammar in the IDL Editor documentation for the syntax on how to describe groups within the IDL file.
Mapping structures
Structures within the IDL file are mapped to the C data type struct like groups. See structure-definition for the syntax on how to describe structures within the IDL file.
Mapping the direction attributes In, Out, InOut
IN parameters,
OUT parameters, or IN OUT parameters (which is the default if
nothing is specified). This direction specification is reflected in the generated C interface object
as follows:- Parameters with the IN attribute are sent from the RPC client to the RPC server. When the parameter is a simple parameter (that is, no fixed or unbounded array, no group and no structure) the parameter is provided with the method call by value. Complex parameters such as fixed and unbounded arrays, groups and structures are provided with the call by reference method.
- Parameters with the OUT attribute are sent from the RPC server to the RPC client. They are always provided with the call by reference method.
- Parameters with the IN and OUT attribute are sent from the RPC client to the RPC server and then back to the RPC client. They are always provided with the call by reference method.
Note that only the direction information of the top-level fields (level 1) is relevant. Group fields always inherit the specification from their parent. A different specification is ignored.
See the attribute-list for the syntax on how to describe attributes within the IDL file and refer to direction attribute.
Mapping the ALIGNED attribute
The ALIGNED Attribute is not relevant for the programming language C. However, a C client can
send the ALIGNED attribute to an RPC server where it might be needed.
See the attribute-list for the syntax of attributes in the IDL file and refer to the
aligned attribute.
Calling servers as procedures or functions
The IDL syntax allows definitions of procedures only. It does not have the concept of a function. A function is a procedure which, in addition to the parameters, returns a value. Procedures and functions are transparent between clients and servers. This means a client using a function can call a server implemented as a procedure and vice versa.
It is possible to call the remote procedure as a function and not as a procedure, if you prefer it and if it suits your interface.
Example:
Library ... is
Program 'sin' is
Define Data Parameter
1 x (F4) In
1 Function_Result (F4) Out
End-Definey = sin(x);- The last parameter's name is function_result. The name function_result is case-insensitive.
- The last parameter's direction is Out. See attribute-list.
- The last parameter is a scalar variable, that is, not an array.
- The last parameter is of type and length:
Table 5. interface description in the IDL file EntireX IDL Description Note I1 Integer (small) 2 I2 Integer (medium) 2 I4 Integer (large) 2 A1 Alphanumeric with length 1 2 B1 Binary with length 1 2 L Logical 2 Nnumber [.number] Unpacked decimal 1, 2 Pnumber [.number] Packed decimal 1, 2 NUnumber [.number] Unpacked decimal unsigned 1, 2 PUnumber [.number] Packed decimal unsigned 1, 2 Notes:- The data types must be mapped to double. See Mapping options when you generate C source files from EntireX IDL files.
- The type of the function returned is defined by Mapping IDL data types to C data types .