In a message dated 6/8/2005 10:50:41 A.M. Central Daylight Time,
[EMAIL PROTECTED] writes:
I just took a quick look at one of the affected volumes. Of 3800 datasets
on the volume, 1600 of them have 0 tracks allocated, and have 44-character
dsnames. This is a great example of how to fill
I just took a quick look at one of the affected volumes. Of 3800 datasets on
the volume, 1600 of them have 0 tracks allocated, and have 44-character
dsnames. This is a great example of how to fill up a VTOC and VTOCIX before
the volume runs out of space, if the VTOC and VTOCIX were sized based
IEC614I RENAME FAILED - RC 008, DIAGNOSTIC INFORMATION IS (0812041B)
Ur right this does indicate CVAF CVSTAT code 1B, which is VTOCIX full.
It is true that the space used in the VTOCIX is dependant on the length
of dataset names, and also on the variability of the names. Similar
names ge
Matt Simpson said the following on 06/06/2005 10:19 PM:
| Now I think I know why we're weird. I looked at the appendix Bruce
recommended. I haven't actually crunched the numbers, but I see that VTOCIX
size is dependent on average DSNAME length. The same programmer that likes
to create
On Mon, Jun 06, 2005 at 12:00:00AM +, Ted MacNEIL ([EMAIL PROTECTED]) wrote:
> If you have a lot of small datasets on a pack,
> you may also have a lot of small free extents (a usual tendency).
> Remember, the index is also used to find free space, as well.
>
> The format-5 (?) is unusable on
...
we tend to use a lot more DSCBs on a 3390-3 volume than saner installations
would, but I don't know if
that affects the VTOC-to-VTOCIX ratio.
...
If you have a lot of small datasets on a pack,
you may also have a lot of small free extents (a usual tendency).
Remember, the index is also used t
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Matt Simpson said the following on 06/06/2005 10:19 PM:
| Now I think I know why we're weird. I looked at the appendix Bruce
recommended. I haven't actually crunched the numbers, but I see that VTOCIX
size is dependent on average DSNAME length.
On Mon, 6 Jun 2005 15:02:55 -0500, Matt Simpson <[EMAIL PROTECTED]> wrote:
>That doesn't seem to be true here. We have several 3390-3 volumes with
>75-track VTOCs and 14-track VTOCIXes. Running the report you suggested shows
>VTOCs ranging from 85-95% full, and VTOCIXes running from 97-99% full
On Mon, 6 Jun 2005 10:28:22 -0400, Bruce Black <[EMAIL PROTECTED]> wrote:
>Are you certain that the VTOCIX is full?
Pretty sure. Or at least it was. It got a little better after a migration run
over the weekend.
On Friday, an attempt to rename a dataset on the volume got:
IEC603I VTOC ERRORS M
I have some volumes (Shark logical 3390) with VTOC Indexes that are full, or
very close to it.
If possible, I would like to expand the indexes without taking the volumes
offline or making them
unavailable. The problem is that the index, the VTOC, and the VVDS are all
adjacent (in that order
Matt,
We expand IX vtocs using:
//STEP1 EXEC PGM=ICKDSF,REGION=3M
//MYVOL DD UNIT=3390,DISP=OLD,VOL=SER=SYS316
//SYSPRINT DD SYSOUT=*
//SYSIN DD *
BUILDIX DDNAME(MYVOL) OS PURGE
> -Original Message-
> From: IBM Mainframe Discussion List
> [mailto:[EMAIL PROTECTED] On Behalf Of Matt Simpson
> Sent: Friday, June 03, 2005 4:02 PM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Advice on expanding VTOC index
>
>
> I have some volumes (Shark logi
I have some volumes (Shark logical 3390) with VTOC Indexes that are full, or
very close to it.
If possible, I would like to expand the indexes without taking the volumes
offline or making them
unavailable. The problem is that the index, the VTOC, and the VVDS are all
adjacent (in that order, s
13 matches
Mail list logo
