OS/390 Multitasking and Other Low-Level System Interfaces

Multitasking SAS/C Applications

Note that when you run multiple SAS/C tasks in an address space, each task must have its own C framework. That is, each subtask load module must include a main function, or must use the indep compiler option to create a new C framework. Each SAS/C framework in an address space operates completely independently of the others. This means that you can use objects created by the library only under the task by which they were created. Specifically:

You cannot allocate storage with malloc or palloc in one framework and free it with free or pfree in another.
You cannot dynamically load a SAS/C load module in one framework and call it or unload it in another.
You cannot open a C file (using either UNIX-style or standard I/O) in one framework and use it in another.
Depending on the application, it may be necessary to redirect standard files for SAS/C subtasks. If the standard files are allocated to the terminal or to OS/390 SYSOUT, generally no problems will result from using them from all subtasks; but if stdout or stderr is a disk file, lost output and or I/O errors may occur.
Each framework has its own defined run-time options. Run-time options are not automatically inherited, and must be set explicitly (either by the caller or by use of _options in the subtask) if the defaults are not suitable.
It is possible, in most situations, to run the SAS/C Debugger in several tasks at the same time. However, this is not recommended. A separate invocation of the debugger is needed for each task, which significantly increases total memory requirements. In addition, it is often difficult to control which debugger will receive input commands. (For this reason, running the debugger in line mode in this situation is recommended.)
Only external and permanent scope environment variables are shared between frameworks.
UNIX System Services (USS) resources such as file descriptors and signal handlers are shared between all tasks in an address space. For this reason, it is recommended that no more than one task in an address space use USS functionality.

Note: Many of these restrictions can be bypassed by using operating system facilities directly. For instance, memory allocated by GETMAIN and DCBs processed using BSAM I/O can be shared freely among subtasks so long as all OS/390 restrictions are honored. [cautionend]

Chapter Contents
Previous
Next
Top of Page