Open System Services Porting Guide (G06.29+, H06.06+, J06.03+)

and C, is not supported in pTAL. No embedded SQL can be included in a user library, which is
a dynamic-link library (for PIC programs) or a shared run-time library (for non-PIC programs).
A TNS/R native C and C++ migration tool aids the programmer in migrating an application from
a TNS environment to a TNS/R native environment. This tool is discussed in the TNS/R Native
Application Migration Guide. The TNS/E environment does not provide such a tool, but once a
TNS program has been migrated to TNS/R native mode, few or no changes are needed to then
migrate the TNS/R native program to the TNS/E native environment. Usually, the only required
action is to recompile the program using a TNS/E compiler. Migrating a TNS program directly to
TNS/E native mode is very similar to migrating it to TNS/R native mode in terms of the source
code changes required.
In planning the migration of your programs to a native environment, you should focus on programs
that have the following qualities:
• Spend a significant amount of time in user code, not system code
• Are critical to application performance
• Are processor-intensive and not I/O bound
In the G-series OSS and Guardian environments, and in the J-series and H-series Guardian
environments, the decision to migrate to native mode is similar to the decision to use the G-series
Accelerator or J-series and H-series Object Code Accelerator for TNS programs.
On systems running J-series and H-series RVUs, the Guardian environment supports execution of
TNS interpreted or accelerated programs, but the OSS environment does not. Therefore, if you
are migrating a G-series OSS TNS program to a system running J-series or H-series RVUs, you must
migrate the program to TNS/E native mode.
Native Environment Features
The following subsections discuss the native environment features:
• “Stack and Heap Sizes” (page 171)
• “Kernel-Managed Swap Facility (KMSF)” (page 171)
• “Native Shared Run-Time Libraries” (page 172)
• “Dynamic-Link Libraries” (page 172)
“Signal Handling for Guardian Processes ” (page 172)
• “OSS and Guardian API Interoperability” (page 172)
Stack and Heap Sizes
User processes initially can have a stack size of 1 MB (G-series) or 2 MB (J-series and H-series),
which can be specified by processes to be up to 32 MB. You can specify the maximum value for
the size of the stack, but it is given a default size when the process is first created. The stack can
grow in size dynamically. You can also specify a maximum heap size value with the ld, nld, or
eld utility or with the process-creation procedures.
Both selectable and flat segments are supported in the native and TNS environments. Only flat
segments are available for native processes, and all flat segments are available at the same time.
Flat segments in TNS processes are allocated to a 32-MB boundary, and a maximum of 13 segments
may be allocated per process. For native processes, flat segments are allocated to a 128-kilobyte
boundary, with no practical limit to the number of segments for each process.
Kernel-Managed Swap Facility (KMSF)
The Kernel-Managed Swap Facility (KMSF) is a method of managing virtual memory for native
processes. It allows a native process to use kernel-managed swap space rather than a user-specified
swap file. The global data, heap, main stack, and SRL or DLL instance data are swapped to
Native Environment Features 171