The pointer to DCOLLECT and reporting on Free VIRs (MXG variable DCVFRVIRS) has
helped me find potential problem volumes.
And rebuilding the VTOCIX (ICFDSF REFORMAT REFVTOC EXTINDEX(current size)) has
seemed to have repaired the few volumes that were giving me trouble. I also
found several volumes where the VTOCIX was still (or back) in OSVTOC format. I
am resetting (BUILDIX IXVTOC) them.
What I still don't know is why, out of 24 volumes (with identical, AFAICT, SMS
attributes on the storage group) most have 300-400 datasets and 3 have
2000-4000+ datasets. Even repaired, the volume that first got my attention,
with 4366 datasets has only 36 free VIR as opposed to the ~250 that most of the
others have.
I am beginning to suspect that the Control-D product has some "feature" where
it "prefers" specific volumes despite SMS, as most of the 2000 to 4000 datasets
are archived reports. But, there are some archived report datasets on the other
volumes.
I am thinking I'll QUINEW the 3 outlier volumes and see what happens.
> -----Original Message-----
> From: Willie Bunter <williebun...@yahoo.com>
> Sent: Monday, July 15, 2019 6:44 AM
> To: Gibney, Dave <gib...@wsu.edu>
> Subject: Re: Determine level of fragmentation in VTOCIX?
>
> Hi Dave,
>
> Just curious. Were you able to fix the problem? Was your question
> answered?
>
> Thanks.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
