In article <[log in to unmask]>, [log in to unmask] (George Stachnik)
wrote:
 
> BRYAN O'HALLORAN ([log in to unmask]) wrote:
>
> : Is there a limit to the number of files in a group under MPE/iX 4.0
> : like there used to be in the classics?  We have just under 4,000
> : files in the particular group.
>
> I'm sure there is a theoretical limit, but files should not
> "disappear", regardless of the limit.  Call the RC.
About the limits:
theoretically:
The MPE/iX directory is organized as (special) files; I'm not
sure whether they are limited to 2 Gigabyte or 4 GB by now.
Your file entries in a group's directory node ($FILESET_NODE)
consume 40 Bytes each, so the THEORETICAL limit would be
some 50 million files in a group. This often leads to the
opinion there are no limits.
 
Practically:
Inserts, updates or deletes (BUILD, RENAME, PURGE) in the
directory have 2 aspects to look upon:
a) the way directory routines were coded
b) the fact that the above actions are transaction manager
(XM) protected.
a) When you build a new file (alphabetically in front of
the rest of files in your group) all other entries are
'shifted' 40 bytes behind; for 'large' groups this will
consume resources.
b) With your current OS release (4.0) directory transactions
are protected against system interrupt corruptions (like your
TurboImage databases or KSAM/XL files) by the transaction
manager in a before image / after image way. XM uses (for
directory transactions) a special logfile (on each volume
set) that contains those images, from which completed
transactions can be rebuilt after a system abort, or wiped
out, if they were incomplete.
The size of the XM logfiles limits directory transactions,
so that groups with more than about 70,000 files endanger
XM's capability to protect them. With 5.0 the way XM
handles directory transactions was changed, so that there
could be more files in a group.
 
Apart from that having more than a few thousand files in a
group starts to lead to some performance penalties (for
XM protection as well as for probably not too intelligent
application design as well). With the above sayed, you can
already imagine that e.g. inserting one file in front of
5000 others in the same group causes an XM transaction of
400,000 bytes, i.e a write of around 1600 sectors.
This sure keeps your volume_set master busy :-).
If you have a fast disc and a fast system, my rule of thumb
would be: limit your number of files to 10,000 per group.
("shot from the hip").
 
Well, as all things in life XM protection seems to have its
price; w/o starting to get cynical, but if you ever had the
fun of bringing any "cy*nix" system througn an fsck and could
actually save valuable data from lost+found, you will probably
appreciciate the protection that XM provides.
 
As George states, files should not disappear from your
directory, but error free operating systems are as real
as Santa Claus is; if you haven't contacted the RC already,
you should do so.
 
It helped, didn'n it ?  :-)
 
Goetz 'posting from home does not make me non_hp_employed' Neumann.