On Tue, 16 Jan 2007 20:18:22 +1000, Shane <[EMAIL PROTECTED]> wrote: . . . > >I wonder if this was a common way of operating in a past age. A few >years back I found a customer doing likewise with a WTOR in UTL - >apparently expecting the task(s) in the address space in question to be >non-dispatchable whilst the exit was in play and had a WTO(R) >outstanding.
How many years back was the exit written? Way back that is exactly what did happen - SMF made all other tasks in the address space non- dispatchable (TCBNDSMF) before calling UTL. I encountered this when it caused a deadlock with UTL waiting for something that one of the other tasks in the address space was holding. From memory I think UTL issued a WTO (not WTOR) and JES2 needed another track-group to copy the message to the joblog, and ended issuing an ENQ, which by bad luck was held by one of the ND tasks. IBM support would not accept this as being a problem, citing some fine print in the UTL documentation of the day, which said something like "do not use any SVCs that may issue a WAIT". That was despite me pointing out that one of the documented uses of UTL was to "inform the operator" and I could not think of a reasonable way to do that without issuing a WTO. Then at some point, I have forgotten when, all that was changed, with SMF no longer making other tasks non-dispatchable when UTL is called. I note that the current UTL documentation has a warning that issuing an ENQ for something held by another task in the address space will abend the initiator. Who knows what that really means. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
