Trying to work out a problem where a BPX_COND_WAIT is returning with an EINVAL and the Jr-errno indicating JRNotSetup.
The basic flow-of-control is: <lock some data structures> invoke COND_SETUP <unlock the data structures> invoke COND_WAIT so - the only way I can get this EINVAL (which doesn't happen every time mind you) is if there is a signal received between the COND_SETUP and COND_WAIT. The documentation is very clear that the only BPX routine allowed after the COND_SETUP is the QUEUE_INTERRUPT service, saying: If your program uses cond_wait to wait for events that it specified by calling cond_setup, it must not call any other z/OS UNIX services between the calls to cond_setup and cond_wait. If the program invokes other callable services between cond_setup and cond_wait, the cond_wait callable service fails with a return value of -1, a return code of EINVAL, and a reason code of JRNotSetup. The only exception to this is the queue_interrupt service. You can use the queue_interrupt service to "put back" the last signal delivered to the signal interface routine (SIR). A signal can arrive after the program that is running on the thread has called cond_setup, and before it gets a chance to call cond_wait. The program may choose to "put back" the signal to defer handling of it until a later time. That is well-and-good - however how is the signal interface routine (SIR) supposed to know this is the case. We could add a flag that could be set in the user info, but that flag would need to be disabled before the COND_WAIT is invoked, at which point a signal could arrive and we are right back where we started. That is, there is no way to atomically reset the flag and invoke COND_WAIT. I'm getting the implication from the doc that COND_SETUP must set some flag somewhere in the BPX information (or TCB related info?) that indicates we are in this state, and any subsequent invocation of a BPX routine clears this flag. (And, COND_WAIT checks that flag to produce the EINVAL + JRNotSetup error) My signal interface routine could simply test that same flag to see if the arriving signal needs to be "put back". But - I can't find where such a flag is documented? That is, how can I programmatically determine that a signal needs to be "pushed back" within the SIR? The SIR is only passed the BPXYPPSD information, and I didn't see a flag related to COND_SETUP. There is also the THLIDEFERSIGNALS flag that appears interesting? But - there is a caveat in the documentation that says: This mechanism is not intended to be used by an application that is requesting z/OS UNIX system services. If a syscall is requested, any pending signals are delivered. so that doesn't seem correct in this case. And, again, once the flag is set how do we clear it atomically with the call to COND_WAIT (same problem.) I _did_ find the OTCBDEFERSIGS field in the OTCB mapping: OTCBDEFERSIGS EQU X'80' Defer sigs is in effect could that be what I'm looking for? Any info would be *terrific*. - Thanks - - Dave Rivers - -- [email protected] Work: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.com ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
