First, I want to say that I've never used the NLM or the NPP, and I've never noticed any problems, except I don't get to join the the RTI forum as much, since I don't have as much to complain about.  I was one of the first regional distributors of NetWare way back when (actually, 1983 or 4) when 4.61 came on 6 - 360K floppies.  They've sure spent one hell of a time getting back into the 4.0 range, eh? <G>  Anyway, I've sold and installed every version of NetWare ever made, and have cussed them just as much as I have COSMOS/RTI.

    I have been a Microsoft developer since the mid-80's, with an MSDN subscription and getting every **** piece of garbage that Bill wanted us to debug.   (This latest idea, of having consumers PAY for the beta copies is a real winner - and the joke is they're DOING it!  Sheesh!)  I've still got my Windows diskettes (the ones BEFORE Windows 286, then 386, then on and on), and I've gotten just about every tool they've ever put out.

    The amazing thing is - the 'adventures' with NetWare and Windows have been very similar, and many of the things that work to make AREV run better with one, works just as well, and for the same reasons, as the other. So, with that said, here's what I've found that works for NT.

1. REQUIREMENTS

1. You MUST have EVERY workstation mapped to the same drive on a given server, and preferably (read that: if you don't, the results are unpredictable and usually BAD.) with the same root path.  i.e. You're mapping to a shared drive on the server.  For some reason, you've created a directory called APPS and have put AREV in that directory (\\ServerName\APPS\AREV).  Now, if one user maps their F: to \\ServerName and their shortcut reads: F:\APPS\AREV\AREV.EXE username /x, and then another user maps their F: to \\ServerName\Apps and their shortcut reads: F:\AREV\AREV.EXE username /x, well, don't call me about it.  I'm not sure that this would cause any problem, but I'm SURE that using the same virtual path WON'T induce any problems.
   
2. You SHOULD have every user using the same permissions for the AREV directory and all subdirectories.  If someone is wanting to go in as Administrator, I like to see all other users get out first.  No, there's no reason I've ever seen for this, but I have seen NT really screw VB and Access up when permissions cross when using the same files.
   
3. You MUST have every user except the one doing an update; i.e. adding, deleting or modifying dictionaries, indexes, system subroutines, windows, etc.  Just try and create an index in a file that someone has a window open to, but is not using their terminal (using it is even worse).
   
4. When users quit AREV for any reason, they need to LOGOUT and not just end the window (this is the biggest reason for all of those 'too many users' messages).  If you make AREV a batch file that is called by a window that doesn't close until AREV is closed, then it can follow with a program in VB or VC that checks to see if they've really logged out of AREV (it's out of memory) or whether they just closed the window.  Then, if they haven't logged out, you can just lock them out of the system for a year or two.   That'll learn 'em!
   
5. Now, to get to the topic listed above, improving performance, the steps here are basically the same as NetWare.  They are:
   1. Create a local directory; I usually call it (cleverly) C:\AREVLOC
   2. Change their user profile in AREV so that their sort path and rollout names all point there.
   3. Create several files on that directory and put an attach to C:\AREVLOC (or whatever) as the last command before whatever you do to bring up the main menu (logon program, RUNMENU, whatever).  The files I create are: (all data only)
      LISTS
      SYSTEMP
      LOCAL_TEMP (I use this as my local trash file)
      Any other file that doesn't need sharing.  Moving LISTS to a local, and putting the SORT path as local make a *real* difference.  You can also keep a local copy of DICT.VOC and VOC, but most people are not versed enough to feel comfortable with that; however, that, also, really speeds the system up
      
   4. REMAKETABLE your files.  Do a DUMPLH and check the number of records, the modulo and how full the LK is.  I had one file that was REALLY slow; it turns out that the DICT had the same modulo (33000+) as the datafile, so I remade it and Whammo!  Speed!   When I do a REMAKETABLE, I *always* do it like this:
      REMAKETABLE DATA Filename
      REMAKETABLE DICT Filename.
      I've done REMAKETABLE DATA !Filename, but I'm not sure how risky that is.  If you do just a REMAKETABLE Filename, it'll create your DICT almost as large as your datafile (that's what happened to me.)
      
   5. Have a program run on the backend of indexing that makes sure (changes) the SIZELOCK on DICTs to 2 (no resize), on !files to 1 (no shrink) and on data files to 1 (unless they are transaction files that grow and shrink a lot.)  The SIZELOCK of 2 on the DICT really helps; the SIZELOCK of 1 on the !file helps some.  Also, SIZELOCK all of your SYS files that don't have data flow (i.e. NOT the SYSTEMP file) to 2; when does SYSOBJ or VOC or DICT.VOC or WINDOWS or POPUPS change during the day?  If you don't SIZELOCK them, every access checks for resizing.  (of course, DO NOT SIZELOCK the LISTS file <g>, it seems to change every now and then.)
      
   6. Check the framesize on your files; in the back of the AREV Reference guide, they actually give parameters for setting the framesize!  Make sure to check the framesize on your DICTs as well as files like Windows and SYSOBJ.  You'd be surprised.
      

Well, I've got to get some work done; hope this helps.