Ron Hawkins wrote: <snip> I may have misunderstood what you wanted, as you did not mention the RLSE requirement. If that is the case, then use UNIT COUNT in the DATACLAS, do not specify secondary extents, and do not use a guaranteed space storage class. As you write to the file sequentially a new primary extent will be allocated on a 2nd, 3rd, 4th volume as you fill the primary extent on the previous volume. When you close the extent on the last used volume, the 4th in your example, the unused space can be released. The 5th volume will never have space allocated, but it will be in the catalog as a candidate volume, that can be used in the event you grow the extent on the 4th volume. You can leave it like that, or you can specify secondary extents for the subsequent opens so the 4th volume will have secondary extents before moving on to the candidate volume. Ron <end snip>
Well, after some tests, it does not appear to work like you say: where you say that the 5th volume (unused) will never have space allocated, here on my system it DOES allocate the space on the 5th volume, that I have to free manually afterwards. It might be due, of course, to my misunderstanding your advice. For that matter, where do you see any "unit count" parameter in the DATACLAS ??? I don't see that either in my prod system (Z/OS 1.11) or the test system LPAR (Z/OS 1.13) ... For a "unit count" to be recognized, I have to put it in JCL (UNIT keyword) or in the dynamic allocation (DALUNCNT text unit), otherwise only the first volume extent is allocated and I get X37 abend when it fills up. I tried with "dynamic volume count" which is in the DATACLAS, but it doesn't change the behavior above. Now I guess that I'll try to use the secondary allocation, which doesn't have this problem of the release of unused space (since for secondary, it will not be allocated at all until really used). No harm done, I just wanted you to know that it doesn't work as you suggested. Jean-Louis. > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of DEBERT Jean-Louis > Sent: Wednesday, November 07, 2012 1:16 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: [IBM-MAIN] multi-volume SMS file allocation > > Ron Hawkins wrote: > Use a guaranteed space storage class, and specify a unit count in the > JCL - > e.g. UNIT=(,5). Specify a VOLSER list if you want the chunks in a particular > volume order. > This will allocate the primary extent requested on each of five volumes. > When you write to it sequentially the five primary extents will fill before > taking secondary extents on the fifth volume. > > > In short, you are advising me to use only primary allocation. > That would work, all right, for the purpose of using max size > allocation on > each volume, when needed. > I still have the problem of releasing unused space if any not on the last-used > volume (I don't know in advance what space the file will need, this is > a pre- > defined parameter in the application). > (in the above example, say I use 3 primary extents and a half, RLSE > will free > unused space on the 4th, but the 5th will stay allocated). > > Thank you for your input anyway, and thanks to all who took the time > to answer (and fast, at that ...) > > > > -----Original Message----- > > From: IBM Mainframe Discussion List [mailto:IBM- > m...@listserv.ua.edu] > > On Behalf Of DEBERT Jean-Louis > > Sent: Tuesday, November 06, 2012 5:15 AM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: [IBM-MAIN] multi-volume SMS file allocation > > > > Hello list, > > > > Does anybody know if/how it is possible to force SMS to allocate > > extents > (the > > primary allocation then each secondary allocation) on different > > volumes (even if there is space enough on the first volume to put > > several extents > > there) ? > > > > This would be for an application that writes the file sequentially > > (for > > performance) but then will read it direct access, using FEOV and > > POINT > (with > > as many DCB's as there are different volumes). > > You guessed it, the application uses BSAM READ/WRITE with > > (respectively) POINT/NOTE with TTR. > > > > The multi-volume data set is one way to somewhat allow more space > > than TTR addressing allows (65,535 tracks on any volume) and for > > this purpose, > it is > > best to have (ideally) the largest possible allocation, but no more, > > on > each > > volume. > > The same would be true if using TTTR (although with a bigger > > addressable space per volume) > > > > Any hints are welcome. > > > > Thanks in advance. > > > > -------------------------------------------------------------------- > > -- For IBM-MAIN subscribe / signoff / archive access instructions, > > send email > to > > lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, send > email to > lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, send > email to > lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
