| I don't know how big a RA72 is, but here is what my RA92 looks like:
Disk $3$DUS20: (ODIN), device type RA92, is online, mounted, file-oriented
device, shareable, available to cluster, shadow set virtual unit, error
logging is enabled.
Error count 0 Operations completed 121843
Owner process "" Owner UIC [1,1]
Owner process ID 00000000 Dev Prot S:RWED,O:RWED,G:RWED,W:RWED
Reference count 52 Default buffer size 512
Total blocks 2940951 Sectors per track 73
Total cylinders 3099 Tracks per cylinder 13
Host name "ODIN" Host type, avail HS70, yes
Allocation class 3
Volume label "D20" Relative volume number 0
Cluster size 3 Transaction count 52
Free blocks 257529 Maximum files allowed 600000
Extend quantity 5 Mount count 4
Mount status System Cache name "_$3$DUS0:XQPCACHE"
Extent cache size 64 Maximum blocks in extent cache 25752
File ID cache size 64 Blocks currently in extent cache 11316
Quota cache size 600 Maximum buffers in FCP cache 4593
Volume status: subject to mount verification, file high-water marking, write-
through caching enabled.
Hope this helps,
Darryl
|
| You should set MAXIMUM_FILES to an appropriate value for your planned
use of the disk. I cannot imagine how setting the value to any
reasonable value would affect the support of the system.
Given that ALL-IN-1 shared files tend to be rather small it is normal
to make the MAXIMUM_FILES setting larger than the default. The effect
of increasing the MAXIMUM_FILES is to increase the size of the bitmap
of the index file (roughly). The effect of increasing this is not all
that great in terms of storage made available. Clearly, if you cannot
store all of the files you require on the volume than the effect is to
have a lot of unusable space.
In unrelated news to that I would suggest that Darryl might wish to
consider having high water marking turned off on the disk shown in .1.
High water marking is the default setting which adds increased security
and time on the creation and extension of files. This can add up to
15% to the time it takes to extend files. The security is to be sure
that shifty users cannot artificially extend a file beyond the 'true'
end of file and scavenge other data left from the previous file which
occupied the blocks allocated. In a typical ALL-IN-1 environment this
is not an issue given that most users don't know how to write RMS and
lower code or have access to the proper DCL commands. (Or even have a
clue that it COULD be done).
Have fun,
don
|
| Sorry this is belated ... I encountered a similar problem a few years
back at a customer site.
The message "file header is full" is somewhat obscure, and is not
necessarily related to the number of files on the disk.
What's happening is that INDEXF.SYS needs to be extended and cannot be.
It has only 16 extension headers allocated by default - if you have
lots of files or lots of file activity, this isn't nearly large enough.
If you do a DUMP/HEAD/BLOCK=COUNT=0 on INDEXF, you'll probably see that
it's been extended several times and can't be extended any more.
The problem usually shows itself on large disks (>= 1G).
The quick fix is to compress the disk (BACKUP/RESTORE). The longer
term fix is to use INIT/HEAD=somelargevalue (e.g. INIT/HEAD=100), since
INDEXF extension headers are "fixed" rather than dynamic.
+b
|