C and C++ code is restricted to only use EXEC CICS® HANDLE ABEND PROGRAM from all the APIs in the EXEC CICS HANDLE 'family'. This restriction continues with XPLink support and is policed by the C and C++ translators.
EXEC CICS RETURN, EXEC CICS XCTL and EXEC CICS SEND PAGE RELEASE cause a direct transfer of control from user code to CICS. In C++ these APIs should be used with great care so that the destructors of C++ objects will still get driven appropriately. Failure to drive object destructors can cause storage to leak, open files to be left open, locks to stay locked, and other problems. It is standard practice in C++ to obtain resources during object construction and to release the resource during object destruction. The destructors of stack allocated objects are automatically invoked when they go out of scope. Some C++ objects may also be statically constructed that is they are constructed before the 'main' function is entered and destroyed when the 'main' function ends or the 'exit' call is invoked.
Because C and C++ CICS application programs which are compiled with the XPLink flag, and meet the other criteria described here, run on their own TCBs, application developers might assume that the full set of C, C++ and POSIX APIs are also available to them. That is not so.
CICS application programs which are written in C or C++ should not make use of multithreading techniques in their application code. You are advised not to use these techniques.
By multithreading techniques, we mean those forms of coding that create multiple execution paths within the application, for example the use of fork() statements or of pthreads. They are untested in the CICS environment and are considered by CICS to be unsupported. IBM® will not accept any problem reports that might be associated with the use of such techniques.
Even if your program would normally run using an OPEN TCB (L8, L9, X8, or X9) CEDF forces use of the QR TCB, because CEDF itself is not threadsafe.