DLL Programmer's Guide for TNS/R Systems

Sample Sessions and Usage Notes
DLL Programmer’s Guide for TNS/R Systems—522203-002
6-17
Guardian Fundamentals
For a given version, you can link only to the SRLs listed in the column for that version.
If you attempt to link to SRLs that are listed in another column, unexpected results can
occur.
SQL/MX Restriction For C++
Public SRLs that support SQL/MX have cppdialect = version2. Therefore, SQL/MX
clients cannot yet use C++ version3.
CRTLMAIN and CCPPMAIN Files
The CRTLMAIN file, located in $SYSTEM.SYSTEM, contains non-PIC initialization
code for the C and C++ run-time libraries. This object file must be linked into non-PIC
C and C++ programs built on Guardian. For OSS, a copy of the same linkfile is found
in /usr/lib as crtlmain.o.
The PIC variant of CRTLMAIN is named CCPPMAIN in Guardian, and ccppmain.o.
in OSS. (Again, the Guardian and OSS files have the same content but are stored in
different file systems.) The non-PIC and PIC files have the same function, but are
compiled differently. The OSS names are used on workstations.
Unless you specify the -c option to avoid linking, c89 includes ccppmain.o or crtlmain.o
when building a PIC or non-PIC program, as determined by the -call_shared option.
Similarly, if you specify the RUNNABLE option, NMC or NMCPLUS builds a program
from your compilation unit; it includes CCPPMAIN or CRTLMAIN for a PIC or non-PIC
program, per the CALL_SHARED option.
Guardian Fundamentals
Dynamic Loading of Libraries is Not Compatible With
Passive Backup.
“Passive backup” refers to the paradigm in which the backup process runs inside the
Guardian procedure CHECKMONITOR, applying changes specified by actions in the
primary. Guardian functions CHECKPOINTX and CHECKPOINTMANYX cause
transfer of specific areas of memory, and optionally of stack frames and a program's
global data. Other functions (such as FILE_OPEN_CHKPT_ and
SEGMENT_ALLOCATE_CHKPT_ ) cause CHECKMONITOR to perform actions (such
as open a file or create a segment) equivalent to those already done in the primary by
calling the corresponding function (FILE_OPEN or SEGMENT_ALLOCATE). There are
no analogous facilities to call dlopen() or dlclose() in the primary and have the backup
follow suit.
By contrast, “active backup” has user-written code running in the backup, receiving
updates from the primary and performing appropriate actions. A program could convey
the necessary information to its backup to have the backup perform dynamic loading
and unloading.