Denied access functions and thread safety
To prevent problems in system integrity and to prevent data damages, certain APIs and commands are either conditionally threadsafe or not threadsafe. These APIs and commands deny all or partial access.
- Multithread capability
In this case, the decision to deny access to a function is made by checking the multithread-capable job attribute. If the job is capable of supporting threads, regardless of the current number of threads in the job, you cannot call the function. When a function denies access based on multithread capability, it sends a CPF1892 (Function &1 not allowed) escape message to the caller. You must call functions that deny access based on multithread capability in separate jobs.
- Initial thread
Some functions deny access based on whether the initial thread of the job calls the function. If you call the function in a secondary thread, the function denies access by sending a CPF180C (Function &1 not allowed) escape message to the caller. You can call a function that denies access from a secondary thread by routing a request to the initial thread and having the function called in the initial thread. Overriding a database file is an example of a function that is only allowed in the initial thread.
- More than one thread
In this case, the number of threads in the job causes the decision to deny access. If more than one thread is in the job, the function sends a CPF180B (Function &1 not allowed) escape message to the caller. Other functions that return error numbers sets errno to ENOTSAFE.
You can call a function that denies access when there are multiple threads by restricting its use to when only one thread is active. An example of such a function is any file system API that is used to access a file in a file system that is not threadsafe.