I recall it was 1/3 of the way in, and the idea was nuked by cache (3880-13/23).
No point clustering your busiest datasets together 1/3 or 1/2 of the way into the volume when they are usually cache resident. You create a nice quiet area on the platter for seeking between those less busy datasets. Ron > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Ted MacNEIL > Sent: Saturday, February 08, 2014 1:48 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: [IBM-MAIN] Implicit VVDS creation > > As for location, in a distant galaxy long ago, SLED DASD liked VTOC and VVDS > (did that exist then?) located in the middle of the volume to minimize head > movement. (Nod if you agree.) That pra > > It stopped nattering long before RAID came out. > 3380-K was when IBM stopped recommending it. > Sent from my BlackBerry 10 smartphone on the Bell network. > Original Message > From: Skip Robinson > Sent: Saturday, February 8, 2014 14:12 > To: IBM-MAIN@LISTSERV.UA.EDU > Reply To: IBM Mainframe Discussion List > Subject: Re: Implicit VVDS creation > > Aside from the how of creating your own VVDS, I'm concerned about the > why. > OK, if an existing VVDS fills up, that's a why. Otherwise, you might consider > creating your own VVDS at the outset if the default size or location is likely > not appropriate for the volume. For example, a huge volume like a Mod-54 > or any that will likely hold a myriad of small data sets might well need a > larger > VVDS. OTOH a volume for JES, page, or XCF data sets will likely never need > more than a minuscule VVDS. > > As for location, in a distant galaxy long ago, SLED DASD liked VTOC and VVDS > (did that exist then?) located in the middle of the volume to minimize head > movement. (Nod if you agree.) That practice no longer makes sense in the > era of RAID, so generally aim for the lowest address possible. Especially for > JES and page volumes, location or size of VTOC and VVDS can reduce the > usable space for very large single-extent data sets. In these cases, very > small > VTOC and VVDS (if needed) should be scrunched into the first few tracks. > > . > . > J.O.Skip Robinson > Southern California Edison Company > Electric Dragon Team Paddler > SHARE MVS Program Co-Manager > 626-302-7535 Office > 323-715-0595 Mobile > jo.skip.robin...@sce.com > > > > From: "Cosby, Bob - OCFO" <bob.co...@nfc.usda.gov> > To: IBM-MAIN@LISTSERV.UA.EDU, > Date: 02/07/2014 11:04 AM > Subject: Re: Implicit VVDS creation > Sent by: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> > > > > Just ran into a situation where the VVDS was filling up; 10,10 was not > working. Our DBMB group was installing DB2 V10 which has to be SMS > managed and were placing hundred of DSNs on one mod-3. > So I INIT'ed them as > INIT UNIT(560D) VOLID(DBJ555) VTOC(1,0,60) VFY(TS560D) - > INDEX(0,1,14) STGR > > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On > Behalf Of John McKown > Sent: Thursday, February 06, 2014 12:01 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re:group Implicit VVDS creation > > Yes. step1 is ICKDSF. Step2 creates VVDS. > > > On Thu, Feb 6, 2014 at 11:22 AM, David G. Schlecht > <dschle...@admin.nv.gov>wrote: > > > Does anyone still build VVDS datasets explicitly when initializing > volumes? > > > > I understand that the default allocation for a new VVDS is CYLS(10 10) > > which saves me from having to rebuild the VVDS if it fills up. > > > > What is everyone else doing with VVDS datasets? Is there still a valid > > argument for building them explicitly? > > > > > > David G. Schlecht | Information Technology Professional State of > > Nevada | Department of Administration | Enterprise IT Services > > T:(775)684-4328 | F: (775) 684‐4324 | E:dschle...@admin.nv.gov > > > > ---------------------------------------------------------------------- > 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
