ACP Index File errors

[robert70]

I am running VMS 7.3-2 on a DS20E
we had a problem through the night when we were unable to create new files?

%RMS-E-CRE, ACP file create failed

after we deleted and purged we were able to.

we were also seeing some ACP index file error.

Is there some limit on the number of files that a disk can hold? and is this setup in the INDEXF.SYS file? How can you check what this is set to and can you modify easily?

Thanks

[Heinz W Genhart]

Hi robertedinburgh

With

$ SHOW DEVICE/FULL 'disk'

you will see 'Maximum files allowed'

Could it be that the disk is very fragmented ?

regards

Geni

[Uwe Zessin]

There is a file header bitmap (to maintain free/used header blocks) within INDEXF.SYS. The file cannot grow larger than the bitmap describes - even with dynamic expansion. As the bitmap is at the beginning of INDEXF.SYS the only way to grow is a backup, initialize with a larger bitmap and data-restore.

[Uwe Zessin]

Good point, a very fragmented disk can eat up headers as well, because they include the retrieval pointers. If the first header is full, additional pointers go into extent headers. A simple backup/restore can 'fix' this.

[robert70]

Thanks

is there any way to find out the total number of files on a device (without doing a dir/size=total, which takes ages)?

[robert70]

i mean dir/total

[Uwe Zessin]

You would have to go through INDEXF.SYS directly - I think there is freeware that can do this. Watch out for aliases or hard links as DIRECTORY can be fooled by them and count files/directories multiple times.

And don't get confused by 'Maximum Files' as it shows the size of the header bitmap, but a single file can use multiple headers.

[Jan van den Ende]

Robert,

was there no second line in the error message, with some more explanation?

This can happen:
- when trying to create CONTIGUOUS files with no big enough contiguous space ("DEVICE FULL")
- when many files are very fragmented, such that the index file can no longer hold the headers (it needs to be contigous) (cannot now reproduce the secondary message exactly, but it is rather descriotive)
- when you are exceeding the max number of files on a drive (VERY unlikely, unless you have BIG drives with SMALL clustersizes and MANY ( > 16 M !! ) files on one drive.

The temporary cure is to delete some files (as you found).
If the cause is fragmentation, defragging (or deleting a VERY fragmented file; BIG .LOG files are a likely target) is a somewhat longer lasting cure.

A more permanent solution is to INIT the drive with bigger-than-default /HEADERS (and maybe /MAXFILES and/or /DIRECTORIES)
see HELP INIT for details.

It may be interesting, if you (temporarily) have an extra drive available, to INIT that one, and do a BACKUP/IMAGE/NOINIT from the current drive to the newly-INITed one.

Success.

Proost.

Have one on me.

jpe

[robert70]

our max here is 517,000 files and I purged a lot this morning - we now have 413,000 files

[Willem Grooters]

It may be worthwhile to check the fragmentation of a file on the disk.

DFU will show, probably. a Q&D template: see attachement...