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.