Version 6.3.8 for OpenVMS
 —  Programming Guide  —

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

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 mainframe platforms. This means that Natural GPs which are generated on mainframe computers are not executable on UNIX, OpenVMS and Windows platforms without recompilation of the application and vice versa.

Top of page

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

The UNIX, OpenVMS 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.

Top of page

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

Top of page

Transferring Natural Generated Programs

To make use of the portable GP on different platforms (UNIX, OpenVMS 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.

Start of instruction set 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.

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:

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.

Top of page

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.

Top of page