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