('not quite nuff said....)
This looks very-very small (it *could* be enough but I must admit to being doubtful)
The PORT.STATUS command gives you access to the MFILE history - should give you some ideas .....
I don't know if this is anything to do with your problem, but would start by stopping UniVerse, increasing this by around 4 times, run uvregen and restart UniVerse
You may have to change an O/S related parameter for the maximum number of concurrently open files per user - and maybe for the system as well. This in turn can have inpact on the number of inodes etc...... check with your Unix administrator..... If all ele fails (some Unix systems have hard limits...) you can resinstate the original file, run uvregen and revert.
Did you find a size on one of these files? (
(ls -l at Unix)

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Porter
Sent: 28 January 2004 14:41
Subject: RE: Periodic COMO file problem

MFILES is at 52.  Don't know if that was the default setting or was changed by a consultant we work with...

>>> [EMAIL PROTECTED] 01/27/04 05:38PM >>>
what's your MFILES ?

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Porter
Sent: 27 January 2004 23:10
Subject: Re: Periodic COMO file problem

It's a Type 1 file. And editing any record even a new one in the file (really a directory) would result in the problem.  I would think, if it was a bad spot on the disk, predictive support should have shown it by now. Even if it was bad, everything is mirrored with MirrorDisk/UX, LVM w/OnlineJFS. That LE should have gone stale and the mirror should have taken over. But it's a direction I haven't considered and worth looking into. Thanks. 
As for it being large, even the small/new records did this. We left them there for a couple hours, waiting until we could bring the system down and it still never worked.
u2-users mailing list

Reply via email to