Guardian Procedure Calls Reference Manual

If the stack-origin parameter is omitted, the stack is not checkpointed. You can, however,
include the stack-origin parameter without checkpointing the stack by setting
stack-origin to -1.
• Checkpointing data areas
Checkpointing specific variables involves using the descriptors parameter to specify the
addresses of data areas and the number of bytes to be checkpointed. Differences in data
layout between a TNS stack and a native main stack cause some restrictions in the way native
processes address these buffers. These rules apply to native processes. Code that follows these
rules can be compiled to run as either a TNS process or as a native process:
◦ To checkpoint global variables, refer to the variables themselves. Do not use constant
addresses.
◦ If your program depends on two global variables being adjacent, you must ensure that
they are in a data block together. In pTAL, this is done automatically if blocks are not
explicit and if the BLOCKGLOBALS compiler directive is not used.
◦ Do not assume adjacency or order of local variables; use structures or arrays
◦ Use $LEN or an equivalent language function to determine the length of data items. The
lengths of some data items differ between a TNS process and a native process.
When checkpointing a set of global variables, if the set is small enough, you can obtain their
address and size using the PROCESS_GETINFOLIST_ procedure, items 108 and 109.
Code that will only be run as a TNS process can use constants for addressing global variables
and assume adjacency of variables.
• Do not checkpoint heap or pool storage
Native processes can use a standard heap area for dynamic memory allocation; programs
using the Common Run-Time Environment (CRE) make this heap available, for example, by
using the C malloc() function. A TNS process can achieve a similar effect with a flat segment
that has space structured as a standard memory pool.
Process pairs must not checkpoint data residing in the heap or memory pool. Control
information is needed to maintain structure, and this control information can be neither obtained
nor checkpointed. If the backup process were to take over using checkpointed heap or pool
data, its heap or pool would be corrupt and allocations and deallocations would not work.
Not only would the space control information be corrupt, but the backup typically would not
even have underlying memory allocated at the needed address to receive the data at the time
of the checkpoint.
• Checkpoint message size limit
The largest stack area or data item that can be checkpointed is 32,500 bytes. Additionally,
the sum total of the sizes of the stack area and each checkpoint item, plus an allowance of
20 bytes for each item, can not exceed 32,500 bytes. An item in this context means either a
data item (user-declared size) or a file synchronization block with varying sizes.
For native processes, the size of the checkpoint message sent to the backup process is limited
to 50,000 bytes. This additional message capacity is necessary because of increased data
memory requirements.
The extra space in a checkpoint message for a native process enables TNS process pairs to
be converted to native processes and allows a program to be compiled for either environment.
• If the address is in an extended data segment, the backup must also have that extended data
segment allocated. The backup must have the same segment ID, and the segment must be the
same size. If the backup has a smaller size, any data in the primary that is outside of the
addressable area of the segment in the backup is not checkpointed. If the backup does not
152 Guardian Procedure Calls (C)