Restrictions when Using applmain()
Overall, the C programmer using multitasking has the z/VM API, the C language constructs, and the C run-time library available for use. However, for CMS to create and maintain a multitasking environment, and to allow the application to obtain expected results from C library functions, a few restrictions apply.
The functions of the C run-time library can be used by a multitasking
application. Each thread or event trap routine executes in its own
private instance of the C run-time environment. While this allows
each thread to use the run-time library without interference between
threads, this separation has implications on thread cooperation:
- Although the C heap storage is usually tied to an instance of the run-time environment, CMS C multitasking language support intercepts requests for heap storage and allows sharing of the heap. This means, for example, that one thread can allocate a block of storage and a second thread can release it. CMS performs this interception for calls to malloc(), calloc(), realloc(), and free().
- Because applmain() employs the system programmer C facilities, the same restrictions apply as are documented for the system programming environment in z/OS: XL C/C++ Programming Guide. Threads are executed as persistent C environments with access to the C Specific Library. The chief restriction in this environment is that the application cannot use the C-PL/I Common Library. Consult the C documentation for a full list of restrictions.