Prerequisites and Preparatory Information

#### Search Results

Search

# Prerequisites and Preparatory Information

This document provides an overview of the general prerequisites and a short description of the facilities that are available in Natural for implementing a Natural RPC (Remote Procedure Call) environment.

The following topics are covered:

- Products Involved

- Natural Statements Involved

- Natural Utilities for Use with Natural RPC

- Application Programming Interfaces for Use with Natural RPC

- Software AG IDL to Natural Mapping

## Products Involved

If the RPC environment is to be implemented on different platforms, the corresponding current versions of Natural for z/OS, Windows or Linux will be required. In addition, the following required or optional products, subproducts and facilities are available for use in a Natural RPC environment:

Product | Purpose
--- | ---
EntireX Communicator (EntireX Broker) | The EntireX Broker of the EntireX Communicator usually establishes the middleware layer between the Natural client and a Natural server. It uses the ACI protocol and comprises the appropriate client/server stubs.
Entire Net-Work | This product is required if the transport method used by EntireX Broker is Entire Net-work. This is the preferred transport method.
TCP/IP | Required if the transport method used by EntireX Broker is TCP/IP. See also Using TCP/IP as a Transport Method in Setting Up a Natural RPC Environment.
EntireX Developer's Kit | Included in the EntireX Communicator product, this kit is required for non-Natural programming language support.
Directory Services | A remote directory server (RDS) enables you to define directory definitions in one place so that its services can be used by all clients in an RPC environment.
Natural Security | Optional. This add-on product is required on the server side to protect Natural RPC servers and services when security is active on the client and vice versa.
International Components for Unicode (ICU) | Optional. This add-on product is required on the server side if the Natural RPC server is protected by Natural Security and the RPC clients have to provide user ID and password to access services.
EntireX RPC | Optional. Natural RPC fully supports EntireX RPC for 3GL. EntireX RPC is included in the EntireX Communicator product.
EntireX Security | Optional. Natural RPC fully supports EntireX Security on the client and on the server side. EntireX Security is included in the EntireX Broker product.

For information on the supported operating system platforms and other requirements for the current version of Natural, see System Requirements in the Installation documentation.

For information on other products that may be involved in a Natural RPC-based environment, see the corresponding product documentation.

## Natural Statements Involved

The following Natural statements are used in the creation of a Natural RPC environment:

- `CALLNAT`

- `DEFINE DATA PARAMETER`

- `DEFINE DATA CONTEXT`

- `OPEN CONVERSATION`

- `CLOSE CONVERSATION`

In the section Restrictions and Limitations, the paragraphs Natural Statement Reactions and Notes on Natural Statements on the Server provide information on what you should know about any deviating behavior of these statements when they are used in a Natural RPC environment.

## Natural Utilities for Use with Natural RPC

The following Natural utilities are used in the creation and maintenance of a Natural RPC environment:

- `SYSRPC`
  This utility is used to maintain remote procedure call environments.

- `SYSEXT`

  This utility is used to locate and test Natural Application Programming Interfaces (APIs, see below) contained in the current system library `SYSEXT` either in a local Windows environment or in a remote environment located on a Linux or a z/OS platform.

- `SYSPARM`

  On z/OS, this utility is used for creating and maintaining a set of Natural profile parameters that is stored under a profile name.

- Configuration Utility

  Under Windows and Linux, this utility is used to modify global and local configuration files and to create or modify parameter files.

## Application Programming Interfaces for Use with Natural RPC

The purpose of Natural Application Programming Interfaces (API) is to retrieve or modify information or use services that are not accessible by Natural statements.

The APIs in the Natural library `SYSEXT` which are used with the Natural RPC are listed in APIs for Use with Natural RPC.

For further information about how to use a Natural API, see the Utilities > SYSEXT Utility - Natural Application Programming Interfaces.

For a list of all RPC-relevant APIs, select the keyword `RPC` in the context menu of the root node Select Keywords in the SYSEXT utility.

## Software AG IDL to Natural Mapping

This section describes the specific mapping of Software AG IDL data types, groups, arrays and structures to the Natural programming language. Please note also the remarks and hints on the IDL data types valid for all language bindings found in the Software AG IDL File (in the EntireX documentation).

- Mapping Software AG IDL Data Types to Natural Data Formats

- Mapping Library Name and Alias

- Mapping Program Name and Alias

- Mapping Parameter Names

- Mapping Fixed and Unbounded Arrays

- Mapping Groups and Periodic Groups

- Mapping Structures

- Mapping the Direction Attributes IN, OUT, INOUT

- Mapping the ALIGNED Attribute

- Calling Servers as Procedures or Functions

### Mapping Software AG IDL Data Types to Natural Data Formats

In the table below, the following metasymbols and informal terms are used for the IDL.

- The metasymbols [ and ] surround optional lexical entities.

- The informal term number (or in some cases number.number) is a sequence of numeric characters, for example 123.

Software AG IDL | Description | Natural Data Format | Note
--- | --- | --- | ---
Anumber | Alphanumeric | Anumber |
AV | Alphanumeric variable length | A DYNAMIC |
AVnumber | Alphanumeric variable length with maximum length | A DYNAMIC |
Bnumber | Binary | Bnumber |
BV | Binary variable length | B DYNAMIC |
BVnumber | Binary variable length with maximum length | B DYNAMIC |
D | Date | D | 3,5
F4 | Floating point (small) | F4 | 2
F8 | Floating point (large) | F8 | 2
I1 | Integer (small) | I1 |
I2 | Integer (medium) | I2 |
I4 | Integer (large) | I4 |
Knumber | Kanji | Anumber | 1
KV | Kanji variable length | A DYNAMIC | 1
KVnumber | Kanji variable length with maximum length | A DYNAMIC | 1
L | Logical | L |
Nnumber[.number] | Unpacked decimal | Nnumber[.number] |
NUnumber[.number] | Unpacked decimal unsigned | Nnumber[.number] |
Pnumber[.number] | Packed decimal | Pnumber[.number] |
PUnumber[.number] | Packed decimal unsigned | Pnumber[.number] |
T | Time | T | 3,4
Unumber | Unicode | Unumber |
UV | Unicode variable length | U DYNAMIC |
UVnumber | Unicode variable length with maximum length | U DYNAMIC |

See also the hints and restrictions on the Software AG IDL Data Types (in the EntireX documentation) valid for all language bindings.

#### Notes:

1. Data type K is an RPC-specific data format that is not part of the Natural language.

2. When floating-point data types are used, errors due to rounding can occur, so that the values of senders and receivers might differ slightly. This is especially true if client and server use different representations for floating point data (IEEE, HFP).

3. 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:

   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)

4. 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:

   Time / Range of Times | Value / Range of Values
   --- | ---
   1.1.0000 00:00:00.0 | 0 (special value - no date)
   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)

5. 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

### Mapping Library Name and Alias

The library name as specified in the IDL file is not supported by Natural. By default, a Natural client sends the library name `SYSTEM` to the server. To send a library name other than `SYSTEM` from a client to a server, the following steps are required for the client:

To send a library name other than `SYSTEM` from a client to a server

1. On the client, turn on the logon option.

2. Call application programming interface `USR4008N` to specify the name of the library, otherwise the name of the current library is sent

The length of the library name is limited to 8 characters.

### 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.

The generated Natural interface object has the same name.

In the RPC server, the IDL program name sent is used to locate the Natural subprogram.

The length of the program name is limited to 8 characters.

### Mapping Parameter Names

The parameter names as given in the parameter-data-definition of the IDL file are replaced by artificial names in the generated Natural interface object.

See parameter-data-definition in the section Software AG IDL Grammar in the EntireX documentation.

### Mapping Fixed and Unbounded Arrays

- Fixed arrays within the IDL file are mapped to fixed Natural arrays. The lower bound is set to 1 and the upper bound is set to the upper bound given in the IDL file.

  See the array-definition (in the section Software AG IDL Grammar in the EntireX 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 Natural X-arrays. The lower bound is always fixed and set to 1.

  See the array-definition (in the section Software AG IDL Grammar in the EntireX documentation) for the syntax of unbounded arrays within the IDL file and refer to unbounded-array-index.

  Note
  Natural variable arrays (Natural notation (../1:V)) can be used on the Natural RPC server side instead of Natural fixed arrays or X-arrays. An RPC client can pass either an IDL fixed array or IDL unbounded array to a Natural RPC server with such a Natural variable array. In the RPC server, the variable array cannot be resized; this means the number of array occurrences cannot be changed, and the Natural RPC server will always pass back the same number of occurrences.

### Mapping Groups and Periodic Groups

Groups within the IDL file are mapped to Natural groups. See group-parameter-definition (in the section Software AG IDL Grammar in the EntireX documentation) for the syntax on how to describe groups within the IDL file.

### Mapping Structures

Structures within the IDL file are mapped to Natural groups. See structure-definition (in the section Software AG IDL Grammar in the EntireX documentation) for the syntax on how to describe structures within the IDL file.

### Mapping the Direction Attributes IN, OUT, INOUT

The IDL syntax allows you to define parameters as IN parameters, OUT parameters, or INOUT parameters (which is the default if nothing is specified). This direction specification is reflected by Natural as follows:

- Parameters with the `OUT` attribute are sent from the RPC client to the RPC server. They are always provided with the call by reference method.

- Parameters with the `IN` attribute are sent from the RPC server to the RPC client. They are always provided with the call by reference method.

- Parameters with the `INOUT` attribute are sent from the RPC client to the RPC server and then back to the RPC client.

- 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 attribute-list (in the section Software AG IDL Grammar in the EntireX documentation) for the syntax on how to describe attributes within the IDL file and refer to direction-attribute.

Note
If you define an interface object layout in the Natural application `SYSRPC`, the meaning of the direction attributes IN and OUT are reversed compared to the IDL:

- `IN` in `SYSTRPC` is `OUT` in IDL

- `OUT` in `SYSTRPC` is `IN` in IDL

### Mapping the ALIGNED Attribute

The `ALIGNED` attribute is not relevant for the programming language Natural. However, a Natural client can send the `ALIGNED` attribute to an RPC server where it might be needed. To do this you need a Natural interface object that has been generated from an IDL file.

See attribute-list (in the section Software AG IDL Grammar in the EntireX documentation) 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 server. This means a client using a function can call a server implemented as a procedure, and vice versa.

#### Client and Server Side

The Natural RPC does not support functions.

### On this page

- Products Involved
- Natural Statements Involved
- Natural Utilities for Use with Natural RPC
- Application Programming Interfaces for Use with Natural RPC
- Software AG IDL to Natural Mapping