Portable Natural Generated Programs

#### Search Results

Search

# Portable Natural Generated Programs

As of Natural Version 5, Natural generated programs (GPs) are portable across UNIX, OpenVMS and Windows platforms.

This document covers the following topics:

- Compatibility

- Endian Mode Considerations

- ENDIAN Parameter

- Transferring Natural Generated Programs

- Portable FILEDIR.SAG and Error Message Files

## Compatibility

As of Natural Version 5, a source which was cataloged on any Natural-supported UNIX, OpenVMS and Windows platform is executable with all of these Open Systems platforms without recompilation. This feature simplifies the deployment of applications across Open Systems platforms.

Natural applications generated with Natural Version 4 or Natural Version 3 can be executed with Natural Version 5 or above without cataloging the applications again (upward compatibility). In this case, the portable GP functionality is not available. To make use of the portable GP and other improvements, cataloging with Natural Version 5 or above is required.

Command processor GPs are not portable. The portable GP feature is not available for z/OS platforms. This means that Natural GPs which are generated on z/OS computers are not executable on UNIX, OpenVMS and Windows platforms without recompilation of the application and vice versa.

## Endian Mode Considerations

As of Natural Version 5, Natural acts as follows: Depending on which UNIX, OpenVMS or Windows platform it is running, Natural will consider the byte order in which multi-byte numbers are stored in the GP. The two byte order modes are called "Little Endian" and "Big Endian".

- "Little Endian" means that the low-order byte of the number is stored in memory at the lowest address, and the high-order byte at the highest address (the little end comes first).

- "Big Endian" means that the high-order byte of the number is stored in memory at the lowest address, and the low-order byte at the highest address (the big end comes first).

The Linux and Windows platforms use both endian modes: Intel processors and AXP computers have "Little Endian" byte order, other processors such as HP-UX, Sun Solaris, or RS6000 use "Big Endian" mode.

Natural converts a portable GP automatically into the endian mode of the execution platform, if necessary. This endian conversion is not performed if the GP has been generated in the endian mode of the platform.

## ENDIAN Parameter

In order to increase execution performance of portable GPs, the profile parameter `ENDIAN` has been introduced. `ENDIAN` determines the endian mode in which a GP is generated during compilation:

`DEFAULT` | The endian mode of the machine on which the GP is generated.
`BIG` | Big endian mode (high order byte first).
`LITTLE` | Little endian mode (low order byte first).

The values `DEFAULT`, `BIG` and `LITTLE` are alternatives whereby the default value is `DEFAULT`.

The `ENDIAN` mode parameter may be set

- as a profile parameter with the Natural Configuration Utility,

- as a start-up parameter,

- as a session parameter or with the `GLOBALS` command.

## Transferring Natural Generated Programs

To make use of the portable GP on different platforms (Linux and Windows), the generated Natural objects must be transferred to the target platform or must be accessible from the target platform, for example, via NFS.

Using the Natural Object Handler is the recommended way to distribute Natural generated objects or even entire Natural applications. This is done by unloading the objects in the source environment into a work file, transferring the work file to the target environment and loading the objects from the work file.

To deploy your Natural generated objects across Open Systems platforms

1. Start the Natural Object Handler. Unload all necessary cataloged objects into a work file of type `PORTABLE`.

   Error messages, if needed, can also be unloaded to the work file.

   Important
   The specified work file type must be of type `PORTABLE`. `PORTABLE` performs an automatic endian conversion of a work file when it is transferred to a different machine. See also the information on the work file type in the description of the `DEFINE WORK FILE` statement in the Statements documentation.

2. Transfer the work file to the target environment. Depending on the transfer mechanism (network, CD, diskette, tape, email, download, etc.), the use of a compressed archive such as a ZIP file or encoding with UUENCODE/UUDECODE or similar may make sense. Copying via FTP requires binary transfer type.

   Note
   According to the transfer method used, it may be necessary to adjust the record format and attributes or block size of the transferred work file depending on the specific target platform, before continuing with the load function. The work file should have the same format and attributes on the target platform as a work file of the same type that was generated on the target platform itself. Use operating system tools if an adaptation is necessary.

3. Start the Natural Object Handler in the target environment. Select `PORTABLE` as work file type. Load the Natural objects and error messages from the work file.

For more details on how to use the Natural Object Handler, refer to Object Handler in the Utilities documentation.

You can find more information about how to port an application from a Natural development workstation to a Natural Runtime workstation in the section Porting Procedure Overview in the Operations documentation.

Beside the aforementioned preferred method, there are various other ways of "moving" or copying single Natural generated objects or even entire libraries or parts thereof, using operating system tools and different transfer methods. In all of these cases, to make the objects executable by Natural, they have to be imported into the Natural system file `FUSER` so that the FILEDIR.SAG structure is adapted. For information on the `FNAT` or `FUSER` directory, see System Files FNAT and FUSER in the Operations documentation.

This can be done with either of the following methods:

- Using the Import function of the `SYSMAIN` utility.

- Using the `FTOUCH` utility. This utility can be used without entering Natural.

- It is also possible to import files from the Windows Explorer to the Natural environment, using drag-and-drop or the menu commands Cut, Copy and Paste. This means, if you have access to the Natural objects you want to import via the Windows Explorer, you can use drag-and-drop or Cut, Copy and Paste, and the FILEDIR.SAG file will be updated automatically. For more details on copying, moving and importing objects, see Managing Natural Objects in the Using Natural Studio documentation.

The same applies when direct access is possible from a target platform to the generated objects in the source environment, for example, via NSF, network file server, etc. In this case, the objects have to be imported, too.

## Portable FILEDIR.SAG and Error Message Files

As of Natural Version 6.2, the file FILEDIR.SAG and the error message files are platform independent. Hence, it is possible to share common `FUSER` system files among different Open Systems platforms. For example, it is possible to copy sets of Natural libraries from one Open Systems platform to another with operating system copy procedures. However, it is not recommended to share `FNAT` system files. For more information about the portable FILEDIR.SAG, refer to Portable Natural System Files in the Operations documentation.

### On this page

- Compatibility
- Endian Mode Considerations
- ENDIAN Parameter
- Transferring Natural Generated Programs
- Portable FILEDIR.SAG and Error Message Files