As of Natural Version 5, Natural generated programs (GPs) are portable across UNIX, OpenVMS and Windows platforms.
This document covers the following topics:
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.
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.
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.
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
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.
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.
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 , and . 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 , and , 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.
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.
