For OpenTP1, a UAP can be created in either C or C++ language. If you are using C language, code the UAP according to the ANSI C format or the pre-ANSI K&R format. If you are using C++ language, code the UAP in conformance with the C++ language specifications. Although the availability of some functions in the provided standard library is limited, most functions in the library can be used together with the functions in the OpenTP1 library.

In addition, any system calls and program libraries can also be used. However, it is recommendable to use OS-provided standard functions and system calls when writing UAPs in order to assure high portability of the UAPs.

When creating UAPs which use system calls and arbitrary program libraries, note the following:

1. When using a signal from the UAP, do not register the type of a signal handler (SIGILL or SIGBUS) which creates a core file during operation with the signal default specified. If the signal handler is registered, a core file is not created even when the program terminates abnormally. As a result, troubleshooting is impossible.
2. When using a signal from the UAP, do not use a function in the OpenTP1 library from the signal handler.
3. Do not use the following system call:
   
   • chdir (change of the current working directory)
4. Do not use the following system calls after the function dc_rpc_open():
   
   • fork (new process creation)
   • exec (file execution)
   • system (shell command issuance)
5. Do not use jump functions (setjmp and longjmp) which extend over functions in the C-language library.
6. When using another program library, do not use Xlib and OSF/Motif functions which control event-driven dispatching.

If the OS is HP-UX, always specify immediate as the bind mode at linkage. If an executable file created as a bind mode other than immediate is used as an OpenTP1 UAP, the system operation is undefined. Use the OS chatr command to check whether the bind mode for the created UAP is immediate.

We recommend that you include a certain prefix character string in the names of any variables or definitions coded by the user. If any names duplicate those used by the OS or OpenTP1, system operation is unpredictable.

(a) Service function names

Service functions must be given names which are 20 or less alphanumeric characters in length and begin with an alphabetic character. Do not give service functions the following names:

• Names beginning with dc
• Names beginning with CBLDC
• Names beginning with tx or TX
• Names beginning with tp or TP

(b) External variable names

Do not give external variables the following names except when such names are used according to the instructions in this manual:

• Names beginning with dc
• Names beginning with CBLDC
• Names beginning with tx or TX
• Names beginning with tp or TP

(c) Constant names

Do not give the following names as constant names defined in #define statements except when such names are used according to the instructions in this manual:

• Names beginning with DC
• Names beginning with CBLDC
• Names beginning with TX
• Names beginning with TP

If the COBOL85 program has been executed even only once in a process of a UAP created in C language, use the cblend function to enable exit. If the UAP is terminated without using the cblend function, some information will not be output (such as the COBOL85 count information). See the corresponding COBOL language manual for details on the cblend function.

Conform to the specifications of the C compiler used by Windows for compiling and linking UAPs when the OpenTP1 (TP1/LiNK) is used by Windows.

The source files of C user application programs and user exit routines used in Version 6 can also be used as is in Version 7 in the following cases: (1) when both Versions 6 and 7 are for the 32-bit architecture, and (2) when both Versions 6 and 7 are for the 64-bit architecture.