Use separate jobs to run functions that are not threadsafe

There are several threadsafe mechanisms to submit a new job to complete the processing you need.

If your application uses CL commands that are not threadsafe, you can use the system API Qp0zSystem(). This API is similar to the C system() function; however, it starts a new process before running the CL command. It also returns some information about the results of the CL command that you ran. For more details about Qp0zSystem(), see the System API Programming Reference.
If your application calls APIs or programs that are not thread safe, you might use the spawn() API to start a new job. If you use the spawn() API, your application must decide which part of the application environment gets duplicated into the child. The spawn() API allows the child process to inherit open IFS files, sockets, or other resources from the parent. For details about spawn(), see the System API Programming Reference.
Your application might frequently use multiple functions that are not thread safe. In this case, you should use one of the previously mentioned mechanisms to start a new job. That new job can function as a server, running the code that is not threadsafe when requested by your application. Your application can use message queues, data queues, or perhaps semaphores to communicate with your server.

When using any of these separate job mechanisms, you need to be aware of the following problems involved with using a different job to complete some of your application processing:

Input/output considerations:
The server job cannot perform normal I/O without conflicting with the application I/O processing. The application I/O processing can affect file offsets or locks that are maintained on system objects. Attempts at I/O can conflict between the jobs.
Parameter passing:
Passing pointers or other types of complex parameters to the functions that are not threadsafe might not be easy to accomplish. That function runs in a separate job. You need to solve the problems involved with passing complex data to that function.
Returning function calls:
The results from the function that is not threadsafe might be more complex than the simple pass/fail type of information that is provided by some of the mechanisms described above. This is similar to the parameter passing issue described above.
Job attributes:
You might have additional complexity to manage when trying to duplicate your application's environment in the server job. For example, if you started your application as user ALICE, and you started the server job as user BOB, the application behavior is not correct.