[This note has been sent to the following InterNet address(es):
HP3000-L @ UTCVM.UTC.EDU
it has also been sent to the following JP Morgan address(es) :
      To : SSWPROD.OAS @ TRSSW
]
 
 
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.
 
Goetz Neumann wrote:
 
>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.
{snip}
>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).
{snip}
>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").
{snip}
 
There is an outstanding problem with the directory on MPE/iX 4.0 which
I have knowledge of. It is SR4701257899 a corrupt file label problem caused
 by too many files within one group with similar names. There is no patch
 available at present. HP says that it can occur any time if you have more than
3,000 files with similar names. However, there are groups with nearly 15,000
without any problems. Also, groups with less files have shown problems.
 
The indication of corruption is shown by a LISTF (with no parameters) which
shows
two files with the same name in the same group while a LISTF,2 on this filename
shows NO files by that name in the group ! The files cannot be purged.
 
The only way (so far) to get round this is to purge ALL the files in the group
and
the group itself and recreate it. Also, as it is on a Private Volume, the sytem
and
volume entry for the group must be deleted/recreated.
 
John Dunlop ([log in to unmask]) "All opinions expressed are mine, as far as
I know"