Re:

> We use Netbase which communicates between its various processes via a series of message files.  Occasionally,  and not just after a system abort, our main production system was getting major impede problems, traceable to the main Export process from Netbase.  Using glance we traced the impede to a "DISK FILL" wait on the first message file - and when we rebuilt the file this problem disappeared - so the problem was not Netbase, but MPE.
>
> The moral - there are clearly ways in which message files can get corrupt - I don't know if MPE engineers have low-level diagnostic tools to look at these files.  We take the safe approach of rebuilding our message files as frequently as possible.

The second moral: hit <return> in your mailer, or configure it to
fold lines at 72 columns or so :)   (Your first paragraph was one long
line of about 420 characters)


Anyway...the problem isn't merely MPE.  Yes, there's a performance
problem with FCONTROL 6 on message files.  But, you have to ask:
why is Netbase *doing* FCONTROL 6 on them, and why is the message
file so large?  (the problem scales with the size of the message file)

It turns out there's a lot of discussion right there, but the bottom line is:

  1) purge/rebuild your netbase message file (sorry, forgot it's
     name) at system startup;

  2) monitor its size.  If it gets large, then netbase isn't keeping
     up with your transactions for some reason ... contact Quest and
     investigate & fix this.

  3) use the current version of netbase, which automatically purges/rebuilds
     the message file at startup (sorry, forgot the version)

  4) look into testing the new version of netbase, which doesn't use
     message files (ditto).


--
Stan Sieler                                          [log in to unmask]
                                         http://www.allegro.com/sieler/