The Dynamic Volume Count (DVC) parameter in the Data Class constructs is used to specify to the total number of volumes a data set can span, without actually placing an entry in the catalog used by other methods until needed by EOV to extend the data set. This is where the TIOT, TCTTIOT and JFCB control blocks come into play, and problems occur as noted in the earlier discussions. As someone mentioned, they removed the "expensive" vendor products that prevented space abends and set the value to 20. Using a DVC value of 20 would add an additional 684 bytes of unused storage (19 volumes X 36 bytes) that is obtained during allocation. When the data set needs to extend to a new volume, EOV just places the new volume information in the already obtained z/OS Control Block Storage and adds another volume entry in the catalog. At least one of the so called expensive vendor supplied solutions would only obtain an additional 36 bytes of control block storage and update the catalog entry only when the data set needs to extend to a new volume. Both methods work, but in the simplest case of one additional volume, DVC still leaves 648 bytes of unused storage in the task. Using Dynamic Volume Count can have serious implications on tasks that are allocating a large number of data sets. IBM APAR OA4179 (Hiper) talks more about maintaining data sets using DVC. I've never used the DVC or Volume Count attributes of the Data Class because of the exposure presented.
Michael Spencer BMC Software -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Traylor, Terry Sent: Tuesday, June 23, 2009 4:38 PM To: [email protected] Subject: Re: SMS Dataset Allocation Problem The TIOT concern is related to the DVC value rather than the volume count value. The DVC total is counted whether or not the dataset extends to that count total. Whereas the volume count is recorded in the catalog as candidate volumes. Terry Traylor charlesSCHWAB TIS Mainframe Storage Management Remedy Queue: tis-hs-mstg (602) 977-5154 -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Ted MacNEIL Sent: Tuesday, June 23, 2009 1:00 PM To: [email protected] Subject: Re: SMS Dataset Allocation Problem >It was not DB2 that had a problem. It was CICS and a few batch jobs. Okay. I stand/sit corrected. >I don't have a problem with multi-volume datasets at all, and in fact I >design SMS to allocate large datasets on as many volumes as possible. I didn't think you did have a problem. The issue is not multi-volume; it's number of volumes. >It was simply having so many candidate volumes for every dataset, 1 track or 1 pack, was excessive and we started having TIOT blow outs. Were you using the max TIOT size? I believe it's 64K. >I think we were using 20 for the unit count when the problem happened. While I've said we've used 59, usually I've used 20, but that's for Batch. For online, we left it up to apps/DBA, except for DB2, since it uses a different method. - Too busy driving to stop for gas! ---------------------------------------------------------------------- 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 ---------------------------------------------------------------------- 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 ---------------------------------------------------------------------- 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
