You may also want to check whether a SMS dataclass with 'space constraint relief' is being assigned, whereby you could be getting your allocation spread over a number of volumes if there are no eligible volumes with enough space to allocate the requested primary. This could result in unexpectedly-multivolume files, even if you are not writing much to them (and then resulting the lack of space release from all but the last volume, as has already been alluded to by others) You should get messages out in your joblog if that were the case though.
On 7 November 2011 15:00, Pommier, Rex R. <rex.pomm...@cnasurety.com> wrote: > Willie, > > Based on your JCL, this isn't your problem. What Bob is alluding to is > multi-volume datasets. According to the JCL reference manual, when a > dataset is opened for output on a multi-volume allocation basis, > > <quote> > > For a multi-volume sequential data set, only unused space on the current > volume is released when the data set is closed; allocated space on any > subsequent volume is not affected. This is also valid if the data set is > GUARANTEED SPACE. > > </quote> > > Since your JCL sample didn't have a VOL= parameter, it defaults to a > single volume. I would be amazed if your problem isn't that the datasets > are never opened. That said, the workaround would be to set a very small > primary extent size and increase the size of the secondary extents, as > others have already mentioned. > > > > > Something else you might want to check on in this case, what is the block > size of the output datasets that actually are populated? I noticed you > don't have a BLKZISE parameter in the snippet you showed. Depending on > whether this is an SMS managed dataset or if the MODELDCB has BLKSIZE in it > or a few other variables, the datasets that are created may be unblocked. > > > Rex > > > > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On > Behalf Of willie bunter > Sent: Monday, November 07, 2011 7:13 AM > To: IBM-MAIN@bama.ua.edu > Subject: Re: DSN NOT RELEASING OVER ALLOCATED SPACE > > Bob, > > I learned something new when you say that only the space for the SECONDARY > allocation is released. This could explain why this may be happening. > > > > ________________________________ > From: "Cosby, Bob - OCFO" <bob.co...@nfc.usda.gov> > To: IBM-MAIN@bama.ua.edu > Sent: Friday, November 4, 2011 3:29:20 PM > Subject: Re: DSN NOT RELEASING OVER ALLOCATED SPACE > > If you are allocating as below the release parameter only release the > secondary allocation NOT the primary allocation. > Volume Count on DASD up to 59 to span multiple volumes > DSNAME=NFCDRESC.DASD.MAIL.BK, > UNIT=3390,DISP=(,CATLG,KEEP), > SPACE=(TRK,(1000,3000),RLSE),VOL=(,,,59) > > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On > Behalf Of Rick Fochtman > Sent: Friday, November 04, 2011 12:58 PM > To: IBM-MAIN@bama.ua.edu > Subject: Re: DSN NOT RELEASING OVER ALLOCATED SPACE > > > -------------------------------------<snip>---------------------------------------- > Good Day To All, > > We are trying to figure out this problem. Job A executes, it creates > several dsns and many of these dsns are empty. We have the RLSE parm > coded however it doesn't seem release the unused space for the empty > dsns. Is there a way of fixing this problem or a work around? We are > running RELEASE z/OS 01.11.00 > > Thanks for your help in advance. > > --------------------------------------<unsnip>---------------------------------------- > IIRC, the datasets must be OPEN'ed and CLOSE'd before the RELEASE > function will work. > > Rick > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html > > The information contained in this e-mail may contain confidential and/or > privileged information and is intended for the sole use of the intended > recipient. If you are not the intended recipient, you are hereby notified > that any unauthorized use, disclosure, distribution or copying of this > communication is strictly prohibited and that you will be held responsible > for any such unauthorized activity, including liability for any resulting > damages. As appropriate, such incident(s) may also be reported to law > enforcement. If you received this e-mail in error, please reply to sender > and destroy or delete the message and any attachments. Thank you. > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
