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.
- 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
- 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.
- 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).
- 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!
- Now, to get to the topic listed above, improving performance, the steps
here are basically the same as NetWare. They are:
- Create a local directory; I usually call it (cleverly) C:\AREVLOC
- Change their user profile in AREV so that their sort path and
rollout names all point there.
- 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)
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
- 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
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.)
- 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.)
- 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.