Tom Harper wrote: Allocating a multi-volume file before writing it is a complex business (it can be done, but you must be authorized).
Well, I know that, and the application exists (and is authorized). Tom Harper wrote: My question is, what are you trying to accomplish here? Well, I'm looking for the best way to optimize the allocation for an existing multi-volume application. Thanks for your input anyway. ----- Original Message ----- From: DEBERT Jean-Louis [mailto:jl.deb...@rsd.com] Sent: Tuesday, November 06, 2012 08:42 AM To: IBM-MAIN@LISTSERV.UA.EDU <IBM-MAIN@LISTSERV.UA.EDU> Subject: Re: multi-volume SMS file allocation Well, yes, that works during writing the file. But how do I allocate the file (before writing to it) ? I should have mentioned that the file is dynamically allocated. Well, if I specify several volumes on my dynalloc, SMS will allocate as many PRIMARY space as I specified volumes, one per volume. Maybe it would work that way (using only primary allocation, and specifying no secondary at all at allocation). I still have a problem if some of those primary allocations are not used at all at writing time, and I would like to free the unused space. RLSE will not do it except on the volume active at CLOSE time, this is documented. -----Message d'origine----- De : IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] De la part de Tom Harper Envoyé : mardi 6 novembre 2012 14:22 À : IBM-MAIN@LISTSERV.UA.EDU Objet : Re: multi-volume SMS file allocation Issue FEOV when you want to go to the next volume. ----- Original Message ----- From: DEBERT Jean-Louis [mailto:jl.deb...@rsd.com] Sent: Tuesday, November 06, 2012 08:14 AM To: IBM-MAIN@LISTSERV.UA.EDU <IBM-MAIN@LISTSERV.UA.EDU> Subject: 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
