Does bpxwdyn use internal locks to ensure that there is only a single caller of dynamic allocation at one time?
(Sad experience has taught me that dynalloc can deadlock if called simultaneously from multiple TCBs.)
Reason I ask: I have a web application that looks at OS datasets. I need to know if I should code a lock-wrapper around the bpxwdyn call in the request handler (or *shudder* create a bpxwdyn server thread).
Is bpxwdyn thread-safe?
Well,
personally I would recommend that your redirect all calls to a “synchronized” method which accesses the bpxwdyn call.
However, considering rather or not if files are being created/written, I’ll also recommend you look into using the “com.ibm.jzos.Enqueue” Class which provides a Java interface to the z/OS ISGENQ service. This class can be used to control and serialize z/OS system QNAME/RNAME resources.
personally I would recommend that your redirect all calls to a “synchronized” method which accesses the bpxwdyn call.
However, considering rather or not if files are being created/written, I’ll also recommend you look into using the “com.ibm.jzos.Enqueue” Class which provides a Java interface to the z/OS ISGENQ service. This class can be used to control and serialize z/OS system QNAME/RNAME resources.
JZOS is simply a wrapper for BPXWDYN and doesn't add any synchronization, so if there is a multi-threaded issue there would still be one. I would be surprised if this were still the case, but I recommend that you open an ETR with IBM to get an official answer (and please post what you find here).
You certainly could route all of your calls to ZFile.bpxwdyn() through your own synchronized method, as mwilliam suggests, but that would in effect serialize all dynamic allocation (which might be fine).
You certainly could route all of your calls to ZFile.bpxwdyn() through your own synchronized method, as mwilliam suggests, but that would in effect serialize all dynamic allocation (which might be fine).