Lennie, glad you got it figured out (and sorry I didn't see all of these posts 
yesterday!)

To fill in a few questions for which everybody probably has already guessed the 
answers:

Q1. Can XTIOT only be requested by using Dynamic Allocation?
A1. Yes.

Q2.  Is XTIOT only available to authorised callers?
A2. Not anymore.  The really short answer is if you use S99DXACU (which gives 
you XTIOT, DSAB above, and actual UCBs), you don't need to be authorized.
There's a long history here, so if you care: There were (and still are) three 
S99RB flags - one for XTIOTs, one for DSABs above-the-line, and one for actual 
UCBs.  Some of them are authorized, some are not, and there are also some 
interactions between them (so for some of them, even if they were unauthorized 
flags, you had to also ask for other ones that required authorization.)  Also, 
not all of the access methods supported XTIOTs.
There usually isn't a good reason to ask for some of those options and not 
others, so the single S99DXACU flag is simpler than setting a bunch of 
different flags.  We didn't change the older flags to remove the authorization 
requirements, and I'd just recommend to use the new flag unless you have a good 
reason not to.  The access method support has been around for a long time now, 
so that's not an issue anymore.  

Q3. What does it mean for (X)TIOT usage if data sets are allocated and 
de-allocated sequentially?
A3.  If you were in a "allocate, open, I/O, close, unallocate" loop - assuming 
you're really unallocating and not doing the remove-in-use attribute thing that 
leaves the DD allocated - you obtain and free an (X)TIOT entry so you only ever 
have 1 of them at a time.  If you are allocating a bunch of DDs, and then doing 
an "open, I/O, close" loop, and then unallocating them - you have (X)TIOT 
entries for all of the allocated DDs.  (The latter case is what it usually 
looks like for batch JCL DDs - the system allocates all of this stuff at the 
beginning of the job step, then gives control to the program that does whatever 
it does, and then at the end of the job step the system unallocates everything.)

And finally, my thoughts on DVC: I can really only speak to this from an 
Allocation point of view, and not from the access methods or SMS point of view, 
but... In terms of "control blocks in memory" (so we're talking about things 
like TIOT entries and JFCBs), a multi-volume data set that resides on 5 volumes 
requires the same mount of memory for our control blocks as a single-volume 
data set with a DVC of 5.  The difference has to do with how DASD space is 
allocated. If you allocate a new 5-volume data set, you get space on 5 volumes 
up front when the data set is created.  If you allocate a new data set with a 
DVC of 5, you get space on 1 DASD volume and then when you fill up your space 
on that volume, you get space on the second, etc.

-Scott

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN

Reply via email to