On Mon, 28 Sep 2015 16:04:55 -0500, John McKown wrote: >> >> >I seem to recall a recent enhancement to z/FTP dynamic allocation that >> reports contention and retries some number of times at user-defined >> intervals. TSO ALLOC and IDCAMS might take that as an example for future >> development. >> > >> So instead of deadlocks you can have livelocks? You can code that loop >> yourself. > >Perhaps what is needed is a new option on the ENQ. Normally, when you do >an ALLOCATE and the DSN is unavailable, you get an immediate failure. OTOH, >there is a parameter in the SVC 99 control block which allows an APF >authorized program to WAIT "forever". Which basically leads to the thought > Yes. I believe that's TU S99WTDSN.
>that it would be nice to have an ENQ option with a "timeout" value. I.e. >give me this and, if not available, wait for at most ???? <time intervals> > With an installation defined max? >in the hopes it will soon will be available. This could be emulated by >having the ENQ logic in a subtask. The main task invokes this subtask, the >subtask does the ENQ followed by a POST of an ECB. The main task then sets >up a STIMER for the "max wait" interval. It then waits on one of two ECBs >to be posted. The ENQ subtask ECB or the STIMER expiration ECB. If the >STIMER expires, just force DETACH the subtask to terminate it. > "subtask" or parent task? SMP/E appears to do something of this sort. After ? interval wait it gives up and terminates. I'd imagine a more sophisticated approach: For an unauthorized caller specifying S99WTDSN, Allocation should traverse the GRS graph and if the caller is creating a deadlock, return failure immediately. -- gil ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
