Thanks for the reply Ray, I guess all this is pointing to the fact that our current setting of MFILES is too low - BUT as far as we can tell everything is flying along (and much faster than normal due to our new box). Will increasing MFILES to a more reasonable level show a noticeable performance gain? Ours is currently at 52, and I'm thinking 300 would be a sensible setting in our situation.
Is there an overhead to increasing MFILES? assuming that the Unix nfile & maxfiles parameters are already set large enough to cope with MFILES being increased. eg. With 250 users & increasing MFILES by a factor of 6, will we see memory usage sky rocket or will it be all gain and no pain? AdrianW -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ray Wurlod Sent: Friday, 29 October 2004 3:03 PM To: [EMAIL PROTECTED] Subject: Re: [U2] [UV] PORT.STATUS MFILE.HIST documentation? It's covered in the IBM course (UV905) UniVerse Theory and Practice, which is the replacement for UniVerse Internals. (See http://www-306.ibm.com/services/learning/ites.wss/us/en?pageType=course_ description&courseCode=UV905) Don't have a copy with me at the moment. From memory you're on the right track. The MF functions are the low-level functions that work with the rotating file pool. MFcheck determines whether an "open" file is currently in or out of the pool, and often returns having determined that the file's "in". MFclose, MFfree and MFopen you can probably guess after that! (Note that MFfree is usually called from MFopen.) The DB... functions are the higher-level, or logical, functions invoked by the UniVerse file manager. For any file that's not guaranteed a file unit, it's always necessary to go via the rotating file pool. Use the FILEMAP option of PORT.STATUS to map file names to FileNo and Chan. ------- u2-users mailing list [EMAIL PROTECTED] To unsubscribe please visit http://listserver.u2ug.org/ ------- u2-users mailing list [EMAIL PROTECTED] To unsubscribe please visit http://listserver.u2ug.org/
