Brian Peterson wrote on 01/17/2006 10:48:40 AM: > In this context, I believe that the "in-use" and "not-in-use" references > are referring to allocations which have been marked "not-in-use" using the > DAIR interface. This interface is documented in TSO/E Programming Services > topic 17.2.2.11 Marking Data Sets as Not in Use (Entry Code X'2C').
You're correct about when the bit came into existence, and retaining allocations after the command that initially requested them was motivated to a significant degree by DAIR's sluggish performance. However, the bit has enduring significance. It tells the system that a command has asked for use of the ddname and may or may not have a DCB/ACB open to use it. At the completion of the command's processing, it works together with the permanent allocation bit and other factors to determine whether it makes sense to mark the ddname as not in use or to free the allocation. > > Basically, my understanding is that the DAIR interface is as old as the > hills, and the concept of optimizing TSO performance by marking > allocations "not in use" probably dates to OS/360 - but of course the TSO > historians will correct me with the details. > > The two concepts - 1) marking an allocation "not in use" and reusing a "not > in use" allocation, and 2) using the REUSE keyword on the ALLOC command, > are two totally separate and distinct concepts. Total separation is a slight overstatement. The in-use bit may interact with an attempt to free a ddname so a replacement can be established. It would be reasonable for DYNALLOC to reject a request to free an in-use ddname unless the requester explicitly said it was OK. > > Another way to think about this is DAIR predates DYNALLOC. And, it used to > be that Allocation was REALLY SLOW. So the DAIR service to mark > allocations "not in use" was an attempt to optimize TSO, back in the olden > days. > > Brian > > On Tue, 17 Jan 2006 08:04:49 -0700, Paul Gilmartin wrote: > > >The description of DYNALLOC is frightening with in-use and not-in-use > >allocations, and the possibility of reusing an existing allocation > >rather than creating a new one. It states there is a performance gain > >for reusing an existing allocation. Where? Can it bypass catalog > >lookup or VTOC lookup? Does the SYSDSN ENQ remain in effect while an > >allocation is not-in-use? If not, what happens if another job > >deletes (and perhaps even recreates and catalogues) a data set > >associated with a not-in-use allocation? Does the TSO FREE command > >actually remove the allocation, or merely set the not-in-use flag? Yes, it can by-pass catalog lookup if the requestor uses a combination of DYNALLOC keys implying acceptance of ddname reuse. You'll find a list of keys that prevent such ddname reuse as part of DYNALLOC documentation. The performance gain can result from less ENQs ranging from ones that are sysplex-wide (e.g. system catalog requests) to ones for the TIOT. The SYSDSN ENQ is in effect as long as the dsname is allocated and reflects the highest level of serialization ever needed while one or more ddnames were associated with the dsname. The FREE command does what you ask. If you asked that the dsname be freed, multiple ddnames may be freed or discussed via diagnostic messages that talk about concatenated ddnames that could not be freed. If you asked about a specific ddname, that instance of an allocation to dsname(s) will be affected. Bob Wright - Never a DYNALLOC developer but a long time user ---------------------------------------------------------------------- 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
