OS/2 Shareware BBS: 8 Other/08-Other.zip/cnfgls13.zip/CNFGLS13.NOT

Text File | 1992-12-08 | 33KB | 607 lines

:hp1.IBMLAN.INI File Parameter Interdependences:ehp1.
.sp
:p.Once you decide you are going to take the plunge and dig into the
IBMLAN.INI file, your first question upon looking at the listing of it
might well be, "Where do I start?"
:p.
Well, there are many choices!  Let's skip down to the maxusers parameter
and begin there.  What goes into this number?  Really, it is fairly easy.
Maxusers is the total number of requesters (DOS and OS/2) that will be
accessing the Server plus, and this is not always clear to everybody,
the number of other Servers it will talk to.  These 'other Servers' may
be just the Domain Controller if you are working with an Additional
Server.  For the Domain Controller itself, it counts all Additional
Servers in the Domain.  It does not count any External Resources Server,
though, since only the Requesters communicate with them.  The Domain
Controller, via its External Resources definitions, tells the Requester
what to send to the External Server to get access to its resources, but
it never talks to the External Server itself.  If you are using DLRINST,
add one (1) to maxusers.
:p.
So, if you want to set up a Domain Controller, and you have 50 users
and 2 Additional Servers, maxusers is 52.  If you are cautious, it is OK
to say 53 or more, but 52 will do the job.
:p.
Now, once you've made that change a whole new world is about to open up
to you.  The world of parameter interdependencies.
:p.A user, by
definition, uses things, and that means you have more work to do.
For instance, before the Server and user can communicate, they must
have a NETBIOS Session established.  Establishing it is automatic, but
defining it isn't!  There are two places you have to define the Session,
the INI file's NET1 line (the x1 parameter) and the Communications
Manager's NETBIOS configuration.  One Session is required in each of
these for each maxuser value.  Easy enough so far, 'eh.
:p.
But, it isn't that simple.  Maxusers counts the number of requesters and
servers, but there are other things that require Sessions.  If a user is
using the Server's keyboard (running applications, doing administrator
functions, whatever), an extra two Sessions are required.  Also, you'll
have to add a Session for the user to access every other Server in the
Domain.  Also, if the Server is running the messenger
service, that will require a Session.  Remember this number.  For our
example, 50 users and two Additional Servers, let's assume the
Administrator will work at the Domain Controller (the machine we are
figuring all this out for.)  So, we'll add 2 Sessions for working
at the Server, and 2 more to access the Additional Servers.  Total
to remember, 52 + 2 + 2 = 56.
There's more, so take a break now if you need to.
:p.
OK, ready?  There are other server services which will
use Sessions, and the number you want to allocate to them is up to you.
Really.  It generally determines how many stations the service can
support at once.  If you are using DLRINST, how many DOS requesters
do you want to install DLR on at a time?  Usually, not many.  The service
is single threaded (see Getting Started, page 3-14.)  It will use some
NETBIOS resources (3 Sessions, 3 Commands, and 2 Names to be exact),
but they don't count on the NET1 statement - only in the NETBIOS
configuration file (a part of the Communications Manager's
configuration.)  If you are using RIPL, there is a (short) time during
the RIPL process when it requires two Sessions.  So, let's pick a
number of stations we will support during this short time, 10.  OK?
Add that to the previously calculated Sessions requirement.
56 + 1 + 10 = 67.  This number (67 in our example) is the
INI file's NET1 statement's x1 parameter.  Whew!  Don't go over 254,
though.  That's the limit.
:p.
OK, on to the NETBIOS Communications Manager (CM) configuration.
'Maximum sessions' is where the sessions that are available for ALL
NETBIOS applications (like the server) are defined.
You can use the same number of sessions here as
you did for x1, but our growing company may have other Domains for the
Administrator to administer later on, so let's allow a couple of extra
Sessions here now so we won't have to remember to come back later.
Also, we need to remember to add in the extra NETBIOS Sessions (3)
required by DLRINST.
Make it 72.  Notice, there are no hard and fast rules except that you
must have enough Sessions - extras are allowed!  They aren't free, though
since they take 52 bytes of NETBIOS work area, so don't go hog wild.
We'll have more to say about the NETBIOS work area later.  Lots more.
:p.
So, now you have some users and the users have Sessions and
Communications Manager knows about the Sessions in it's NETBIOS profile.
Are your users ready to log on?  Not quite.  A Session lets two link
stations talk, right?  Well, we haven't defined the link stations yet,
have we?  Easily done, though.  They have to be defined in two places in
the Communications Manager - NETBIOS and 802.2.  The NETBIOS Link
Stations requirement is the same as the INI maxusers value.  This is 52
in our example.  They, too, are cheap -- 50 bytes of NETBIOS work area
each.  The 802.2 configuration can use the same number, but you
might want to add some for SNA or RDS, or ...  To be safe, let's add 4.
Set it to 56 in the 802.2 configuration.
:p.
Continuing on our line of thought, what will our users need next, now
that they can communicate with the server?  Right!  Resources.  Files,
printers, stuff like that.  Well, that will require some other changes
to the INI file to make sure they have access to those resources.
:p.
First, if the users are to access a server resource, it must be shared.
Make sure that you set the maxshares parameter high enough to allow
sharing everything you want users to access.  Sharing a resource requires
one maxshare, no matter how many users access it.  You might count the
applications you intend to share and multiply by three to get a starting
point for this parameter, but you probably want to add some maxshares for
user home directories and printer queues - especially if you have a lot
of them.  In our example, the users will all have home directories, and
server will support 5 printer spool queues.  That is 55 maxshares, and
we'll add 15 to allow for 5 applications (maybe a spreadsheet, a word
processing application, and some graphics work.)  Maxshares, then = 70.
Each increment of maxshares takes 103 bytes of RAM.
The good news is, there are no other parameters you have to change if you
modify maxshares.
:p.
The bad news is that maxshares isn't the only thing you have to set to
allow users to use server resources.  Another thing is maxconnections.
Connections are the server's end of a requester's NET USE.  Each user who
uses a server resource needs a connection for it.  Five users of a
single resource need 5 connections.  Five users of five different
resources will also require five connections.  If every user can use
every shared resource, the maxconnections value is the product of
users times shares.  For our server, that is the case.  Fifty users
times (15 application shares plus 5 print queue shares) = 1000
maxconnections.  We also have to add the users' connections to their
own home directories, so the total is really 1050 maxconnections.
1024 is the maximum value allowed, though.  Maybe we are a bit high.
Another way to figure these is to allow 6 per user and add some
more for users who are likely to need them.  Windows users might get
3 more, OS/2 users another 4.  That makes 53*6+50*4=518.  Use that.
You're right, it takes a LOT of maxconnections, but they only require 20
bytes of PC RAM each, so don't worry too much about it.
:p.
OK, now, where are we.  We've got maxusers, sessions, stations,
maxshares and
maxconnections, right?  We still have to look at buffers, commands
and maybe some details in heuristics (just for the fun of it, actually).
Maybe we can even find time to look at 802.2 stuff, too.  Oh, boy!
I can hardly wait.
:p.
Buffers first.  To be able to send or receive data, the server has to
have some, and there are several types.  Reqbufs, bigbufs, pipes
and messages come to mind.  Easiest first, messages are something we
have no control over - they are what they are (datagrams), so we won't
even worry about them.  They are sent on at a time, so only one buffer
needs to be counted for the function.  Next, pipes.  These are generally
used between servers, and by requesters during the logon process).
The only documented rule is that if you have a lot of users loging on
at the same time, you may want more than the default, 3, srvpipes.
What is 'a lot'?  When 'may' you want more pipes?  In the
total absence of rules, we'll just allocate one for every 12 users.
That way, the maximum value, 20, will be used when we get over 240
users.  Until somebody proves that wrong, 3 pipes will be fine for up to
36 users, and we will want an extra one for 50 users.
We'll use our rule and monitor the servers'
NET ERROR log for any messages that indicate more pipes are needed.
The message, by the way is NET8234E, so you know what to look for.
No messages, no changes.  OK, so it isn't scientific - it works.
Also, note that we never lower the default.  General rule - don't
change them unless you have to.  If it ain't broke, don't fix it.
If you like rules to live by, add "If you don't know what it does,
leave it alone!"
:p.
That takes care of most of the easy stuff.  On to buffers.  In general,
the server will use 'reqbufs' to send records to/from requesters, and
it will use 'bigbufs' for bulk data transfer (that's what we call
things like program loads, COPY operations, and application I/O in 64KB
chunks of data) which are done with raw data protocols.  Rules of thumb
always say things like 'two or three per concurrent user of the
function.'  Real useful, but it is true, that is what is required.
So, we are back to making reasonable estimates (is there NO science to
this tuning stuff?)  Actually, this isn't all that hard - due to some
limits we run into.  First, 'reqbufs' can only take 512KB.  They default
to 4KB each, and that means you have a maximum of 120 of them.  So, we
can allocate 2 per user (for the first 60 users, anyway), and when we
have used up the 512KB, we just stop.  We have to, as a matter of fact.
Makes it simple, huh?  For our 50 users, then, we will define 100
numreqbufs.  Then, we'll add 4 for access to the Additional Servers,
and two more for DLRINST.  Total, 106.
:p.
This limit of 120 'reqbufs' does not mean the server will support only
60 users.  If you picture the buffers as being used just to send data
to users, they will be in a queue awaiting their turn for transmission
on the LAN.  If there were so few buffers available that one could not be
'refilled' with data and re-queued for transmission before all the
others in the queue had been sent, the performance of the server would
be degraded.  This would happen because the server would have to wait
while a buffer was being prepared for transmission.  Waiting servers are
not performing.  But, it actually takes much longer to send 119 buffers
of data than is required to refill one, so fewer than two buffers per
user (or even one buffer per user) is permissable.
:p.
Did you ever see the NET ERROR message which says the server ran
out of the resource defined by the numreqbufs parameter?
There is also
a message for numbigbufs, and the server statistics screen tells
you just how many times this happens if you wish to look (look at the
last 2 lines of the screen you get when you enter the NET STATS SRV
command line command.)  Getting these messages is not bad - if you don't
get them hundreds of times per hour.  A well tuned server will have just
enough buffers to do its job.  That means it will run out every once
in a while.  That isn't a problem, it just shows the memory which might
have been put into buffers is used someplace else - maybe in cache or
VDISK.
:p.
Now, numbigbufs.  You can define up to 80 of these.
But, if we think about it, these are 64KB buffers, and
if we define a bunch of them, they can force our server into swapping,
and that is one thing we want to avoid!  Swapping destroys performance.
If we have limited memory, we might decide it
would be better to have disk cache for applications which do heavy
use of randomly accessed shared data on the disk.  These would be
things like data base applications - you'll have to decide what
applications your server users will run and how they access data.
Applications like spreadsheets, word processors and graphics tend
to access data sequentially and/or to not share files, so they tend to
not get great benefit from large disk caches.  In fact, if your
applications do not share data, don't have cache!  After all, having it
means data will have to be loaded into it, that it will have to be
searched when other users do reads,
that there will not be any cache hits,
and that the data will finally be overlaid by newly written data which
will never be used from cache before it, in turn, is overlaid by data
which will never, ...  You see how cache can be a waste of server cycles,
so don't just assume you want a lot of it.  Examine your applications.
:p.
Our applications will be office, graphics and decision support type of
stuff.  Generally, no shared files.  No need for cache for data.
But, we'll have to come back to cache later.
:p.
On with bigbufs.  Let's first understand how they work.
Actually, bigbufs are used in the self-tuning features of the server.
You knew it did that, didn't you?
To review just a bit, these buffers are used in several ways,
but most often they are used when downloading code or doing COPY
functions.  For best performance, you should have a couple of
bigbufs available when a user starts a function which can use raw data
transfers like the examples given earlier.  But, how many is that?
How many do you have to set up per user?  1/2? 2?  Answer always seems
to be, "It depends."  So what are you going to do?  Guess?  That is
what a lot of folks do, or they just allocate a lot of buffers and hope.
Well, the good news is it is hard to go wrong!
:P.
Now, don't flinch, but SRVHEURISTICS is where you go to control this.
In the SRVHEURISTICS, digits 17 and 18 control how
memory is allocated to bigbufs and how long it stays allocated.  The
NUMBIGBUFS parameter defines how much memory you wish to allow the
server to use for bigbufs.  At startup, you will get 3 bigbufs, no
matter how many more than that you might ask for.
As more than these three are needed, they are created.
The NUMBIGBUFS parameter sets a maximum number of permanent
bigbufs that will
be created and used for reading from and writing to the server.
If users require all these bigbufs to be created and STILL need more
to use while writing to the server, it will dynamically create more.
This creation of 'extra', temporary
bigbufs as required is controlled by the srvheuristics digits
mentioned.  They are created as needed, and when they
are no longer needed, they are released.  Since allocating/creating the
buffers takes cycles, you can use digit 17 to cause the server to wait
for a varying period of time before releasing a bigbuf - for best
performance, this would be a longish time so the overhead could be
avoided as much as possible.  A value of 1 will release the bigbuf
one second after it is no longer needed.  This is too low, so the
default, 3 (waits one minute) should be used to keep the bigbuf
around longer so it will be available if another user or function
requires it before you spend the cycles to deallocate and then just
end up having to reallocate it all over again.
:p.
When a buffer is needed and no memory is available, SRVHEURISTICS
digit 18 determines how often the server will try to allocate
a buffer - the longer it waits, the less overhead you waste on a failure.
The new buffers are allocated from available server memory, and if a user
application is using it, the server will wait and retry later when
another user wants a new bigbuf.  Trying often can get you a buffer
sooner, but if the memory is not available, trying too often can slow
down the system.  The default, 3, waits one minute between tries.  If,
during one of these waits, an already created bigbuf becomes available,
it will be used and a new one will not be created.  Note that this just
keeps the server from retrying too often - the user will not wait.
Instead, the user function will continue as soon as the server finds
no memory is available for temporary bigbuffs.  The only difference
is that the user function will use the smaller reqbufs to get data
to the server.  This is a bit slower and causes more work for the
server, but better that than having the user wait!
:p.
So, the server 'tunes itself' for the number of numbigbufs it has.  But,
that's not all!
:p.
SRVHEURISTICS digit 13 can be used to allocate some of the available
bigbufs to be used to create more reqbufs, called read-ahead buffers,
if the server runs out of
them and some are needed for prefetching data from the disk before a
user requests it be sent on the LAN.  Yes, the server does this.  There
are two major times this is done.  First, when a program opens a file
the requester assumes it will read data from it and prefetches 4KB of
data before the application actually issues a read.  Second, when a
requester reads multiple consecutive records, the server will detect this
and pre-fetch 4KB of data so if the requester continues sequential
processing of the file it will not have to wait for actual disk I/O to be
done.  This 'read-ahead' data is placed in a read-ahead buffer and is
ready to be quickly sent to a requester when an actual read command is
issued.  This makes the LAN Server perform very well in sequential tests.
:p.
Since the server creates these buffers as they are required, this
is another example of (controlled) automatic tuning.  Note
that if you allocate 9 bigbufs to this function you won't
need 144 more NETBIOS commands before they can be used.  You couldn't
define that many commands, anyway.
Since these buffers are used to hold data which requesters
have not yet asked for (but which the server expects them to ask for
soon), the data is not actually sent to the requesters until they ask
for it.  But, having it waiting in a buffer when they ask for it means
they will get the data they want much sooner than they would if the
server had to read it from the disk - or possibly, even faster than
finding it in cache.
:p.
SRVHEURISTICS digit 13 defaults to 1.  That is
enough memory to create 16 additional reqbufs to hold data as required.
If you have a lot of users (over 40), you might increase this value.
You might want to increase it by one for the next 40 users, too.
Three bigbufs are enough for this function in most cases, though, so
stop with that many and let the server use the rest as real bigbufs.
For our example server, we'll set this heuristic to 2, and the
NUMBIGBUFS parameter itself can be set to its default, 5, plus 1 for
every 5 requesters.  That's ten more, so we'll set it to 15 plus the 2
for read-ahead buffers for a total of 17.
:p.
If we want to use the server for running local applications such as
ADMIN functions, NET RUN jobs or AT command functions, we have the
memory available - not committed to bigbufs.  When no such jobs
are running which require the memory, the server can
grow or expand and use the available memory.  If the server
doesn't need the memory, why should it require the memory to be
allocated to the server.  Allocating memory which will not be used
is wasteful.  So is reserving memory which is only used infrequently
for special purposes.  This is one problem which is solved by this
OS/2 LAN Server self-tuning feature.
:p.
Well, we need to look back at cache, and now is as good a time as any.
Cache is designed to allow many users to share
frequently accessed data.  This implies that the data is used in
applications which share files and do byte range, 'record', locking.
That, in turn, indicates the data is randomly accessed (probably by a
data base).
:p.
For these reasons, the OS/2 caches (DISKCACHE and
CACHE.EXE) are designed to NOT cache sequential file accesses.
If you are using the DISKCACHE, you have the option
of defining the maximum disk read length which will be cached.  By
default, this is 3.5KB.  A second parameter on the CONFIG.SYS DISKCACHE
statement allows you to increase this so disk reads up to 64KB will be
cached.  This is handy for sequentially accessed files if they
can be cached when the first record is read from them.   HPFS cache
does not have this capability, and it will cache no reads over 2KB.
Therefore, HPFS looks like  the best place to put your randomly accessed
data files.  If you use both
caches, you could have up to almost 17 MB of cache!  This means you must
do some planning.  Be careful to check to make sure that your
cache does not force your server into a swapping mode.  If
that happens, all the tuning efforts are for naught.
:p.
Earlier I said HPFS cache 'looks like' the best place for random data,
and the more suspicious of you readers probably wondered at that.  And
with good reason!  We are talking server here, not just OS/2, and that
means the way OS/2 usually works can change!  And here, it does.  Why?
Statistics show that many times random files get processed sequentially
(at least in part).  Index searches, key fields with no indexes which
cause data bases to have to search for records, going to a certain
place in a file and then processing a set of records sequentially, and
other such functions cause this.  In fact, the probability is so high
that the server is willing to bet that is what you are going to do!
Not that it bets a lot, but it will try to read records before you want
them so you will get them quickly when you ask for them.  So, when you
open a file, the server sends the requester 4KB of data with the open
response.  If you read a record in that 4KB, no server action is
required, and you get great response.  If you don't read a record in
that 4KB, the server loses its bet - and has wasted the 7 milliseconds
or so it took to send you the data (I told you it didn't bet a lot,
didn't I?)
:p.
OK, great, you say, and I agree.  BUT, if the server is
reading 4KB at a time and HPFS caches no reads greater than 2KB, how much
of the data is going into HPFS cache?  Right, 0, zip, none, naught.  SO,
why do you want an HPFS cache?  Well, it is still used as the HPFS
directory cache, so you certainly don't want to get rid of it!  But, you
can set it small, 64KB is the minimum.  If
you have a lot of users on the server and a lot of file creation/deletion
going on, you might set it to 128KB so the directory can be cached -
maybe even 256 is extreme cases if you are just SURE you have
fragmentation.  Your choice, but small is OK on a server.  Put the
memory into DISKCACHE.
:p.
"Did he say, 'put the memory into DISKCACHE'", you ask?
:p.
"Yes, he did", I say (ungramattically.)
:p.
With CSD WR05015 (May, 1991), the disk device driver cache, DISKCACHE,
can be used by HPFS disks.  If your server is at that CSD level (or at
Version 1.30.1), you have a 14.4MB cache available to you!
:p.
But, we noted the DISKCACHE would handle reads of up to 3.5KB, and if the
server is issuing reads of 4KB, how much is going to be cached?  Wrong!
As mentioned earlier,
there is a parameter on the DISKCACHE statement which lets YOU tell
it how big a read to cache.  The CONFIG.SYS statement is
DISKCACHE = xxxx,nnn where the 'nnn' is the maximum number of sectors
you want to cache for a single read.  Set 'nnn' to 8 to cache 4KB reads.
But, that data is going to be in one of your buffers anyway, so why not
go for the
big stuff?  Set 'nnn' to 128, and cache reads of 64KB!  That is
the biggest read the operating system can do, so 128 is as much as you
want to specify for the 'nnn' value.
:p.
With 128, programs that are downloaded will be cached, and if you do
a lot of that, it can help your performance.  RIPL, in fact can be twice
as fast as before!
:p.
So, with code on the server, cache 64KB reads in DISKCACHE.  With no
code on the server, don't cache it.  Set 'nnn' to 8, and cache data
instead.  But, don't forget to watch for swapping.  It'll kill you.
:p.
Sick and tired of buffers, and caches, yet?  Well, I am.
Onward and upward!
:p.
Once the data is in a buffer, it will be sent to the requester.  That
takes a NETBIOS Command.  These are defined in the IBMLAN.INI file's
x2 parameter and in the CM NETBIOS Maximum commands parameter.
How many of them should be defined?  Well,
the manual recommends, for best
performance, setting NETBIOS Maximum
commands at twice the number of Sessions defined in the INI x1 parameter.
:p.
The 'two Commands per Session' recommendation was an early tuning tip.
It is essentially valid, but we have discovered that there is a maximum
number of Commands which can be defined. That maximum depends on the
other NETBIOS resources which are defined (Sessions, Stations, Names,
Remote Name Directory Entries)
since the control blocks for them must all fit into a 64KB
area in memory. So, there comes a point when there isn't enough
room for all the Commands this tuning tip would require you to define!
:p.
Upon consideration, it can be seen that Commands are used to do I/O
on the network. If
you are doing I/O, you must be handling data. If you are handling data,
you must keep it somewhere. Where? In NETBIOS messages.
:p.
Unfortunately, no parameter defines the number of NETBIOS messages you
want to have. It is actually the sum of several other parameters
(EG, numreqbufs, numbigbufs, pipes, messaging.)   We've looked
at those, and they tend to have maximum values due to storage which
can be or is allocated to them.  We now know how to allocate these
buffers.  They are no longer a problem, right?
:p.
So, count the NETBIOS message buffers (numreqbuf, numbigbuf, etc)
which are available to the
Server, and allocate one Command per buffer. Usually, this maxes out at
about 150 Commands, but it CAN go higher depending on several other
parameters.  Since there aren't more than 150 buffers, it would do no
good to go higher.
:p.
If you decide you need more numreqbufs in your server, you can make them
smaller than the default of 4KB.
Smaller buffers can help your Server's performance in cases where all the
users are doing random record I/O - as long as the numreqbufs are not
smaller than a single record (if they are smaller, performance
degrades badly.)  One thing to note, though.
Servers' reqbufs send data
to requesters' workbufs.  They should be the same size.  So, changing
the servers' sizreqbufs parameter means changing ALL your requesters,
too.  This may not be a task you want to undertake lightly, but, consider
what different sizes means to performance.  If the requesters buffers
are larger, they will be issuing reads to the server that will take
multiple server buffers of data to satisfy.  The wait for all these
transmissions can get long, and performance will suffer.  How mad at you
do you want your users to be?  If the servers' buffers are bigger than
the requesters', the extra space will never be used.  Wasted memory
isn't a good idea (but we'll be glad to sell you more.)
Making the reqbufs smaller allows extra buffers,
but to use them you'll need extra Commands, also.  The maximum number of
Commands you can have, as mentioned before, depends on the usage of
memory in the NETBIOS work area.  Here is how that memory is
allocated by the CM NETBIOS configuration.
.sp
  8288 Bytes for NETBIOS
    50 Bytes times the number of NETBIOS Maximum Stations defined.
    52 Bytes times the number of NETBIOS Maximum Sessions defined.
    22 Bytes times the number of NETBIOS Maximum Names
           (add one to the number of names you define
            because NETBIOS Name-One must be accounted for)
    66 Bytes times the size of the NETBIOS Remote Name Directory.
   202 Bytes times the number of NETBIOS Maximum Commands defined.
:p.
Ouch!  That last one hurt, didn't it?  Well, that is what you are going
to need to allocate.  Buffers without Commands can't be used.  One note
here, to be perfectly clear --  this is the NETBIOS work area in PC RAM.
It is not the Token-Ring Adapter RAM.  The error message you get when
you fill this work area may lead you to think you have an adapter
memory problem, so be careful to understand what you are doing.
:p.
It seems we get sidetracked at lot, but did you ask something about that
Remote Name Directory?  Well, NETBIOS uses it to remember where Users
are.  If it doesn't know where a user is and has to send a message, it
must search the network to find the Station where the user is signed
on.  That takes time, and
you can save that time by giving NETBIOS a little memory to save the
path to a station once it has found it.  Messages also go faster.
In the Communications Manager NETBIOS configuration, you'll need to
make two changes.  Set "Datagrams use Remote Directory" to 'Yes', and
set the "Number of Remote Names" to however many you want to support.
We'll allocate enough for an entry for each of our users.  That's 50.
OK, no more interruptions.  Back to Commands.
:p.
In general, if you have 60 or fewer users, you'll have 2 NETBIOS Commands
per Session, but if you have more than 60 users, you'll have fewer
Commands than the old tuning tip would ask you to define. So, you
may not have 2 Commands per Session - you don't even use the number
of Sessions supported to calculate the number of Commands to define!
We have 106 numreqbufs, 4 srvpipes, messaging (1), 17 numbigbufs,
and we'll also add 6 for maxchdevjob.  Total 134.
So, 134 NETBIOS Commands are needed.  These are specified on the INI
file's NET1 statement, in the x2 parameter.  The NETBIOS Communications
Manager configuration will also need to have that many Maximum
Commands defined.
:p.
Let's see, we've now added numreqbufs, numbigbufs, srvpipes,
cache, VDISK,
Commands and messaging considerations to this (along with some
srvheuristics - don't say I didn't warn you.)  What's left?  Some
miscellaneous stuff -- NETBIOS Names, maxopens, maxlocks, numfiletasks.
Easy stuff.  Use the Net1 x3 default for NETBIOS Maximum
names, but remember that
the NETBIOS configuration Names value has to be one greater than x3.
DLRINST services will need two extra names in the NETBIOS configuration.
:p.
Maxopens?  You can have up to 8000 and you need 'enough.'  The server
can force closes of users' files if it runs out of these, so if you
see the symptom, you know the cure.  Remember that, while DLRs may not
use a lot of files, WINDOWS users will tend to use more, and OS/2 users
will probably use most of all.  Allocate 10 for DLRs, 45 for WINDOWS
users and 55 for OS/2 users for a good starting point.
:p.
Maxlocks, same story.  Normally, this can be set to .1 times maxopens.
Our example OS/2 users will get 50*55= 2750 or so maxopens and
275 maxlocks to start.  Then, we will monitor NET ERROR for messages.
:p.
Numfiletasks, leave it set to one.  Saved the simplest for last.
:p.
OK, now let's review our sample configuration and all of the parameter
settings we have decided on.
  1 Domain Controller, 2 Additional Servers
  50 OS/2 Requesters
  Will support DOS users with
    DLRINST and RIPL
  Sharpies may note we have no DOS users, but this is only an example,
  after all, so cut me some slack!
:p.
Parameter and other tuning settings --
 maxusers = 53
 Sessions
  NET1 x1 = 67
  NETBIOS = 72
 Stations
  NETBIOS = 56
  802.2   = 56
 maxshares = 70
 maxconnections = 518
 srvpipes = 4
 numreqbufs = 106
 srvheuristics 17, 18 and 13 (3, 3 and 2)
 numbigbufs = 17
 Cache = 0
 VDISK = ???
 Commands
  NET1 x2 = 132
  NETBIOS = 135
.pa
  NETBIOS Work Area Memory Map
    8288 Base
     374 Names (22 * 17)
   27270 Commands (202 * 135)
    2800 Stations (50 * 56)
    3744 Sessions (52 * 72)
    3300 Remote Names (66 * 50)
   -----
   45776 Total
.sp
  Names
   NET1 x3 = 16 (default)
   NETBIOS = 17 (default
  maxopens = 2750
  maxlocks = 275
  Numfiletasks = 1
  NETBIOS
    RND = 50
    Datagrams use Remote Names = Yes
:p.
Well, we covered a lot, and we did it in less than 10 pages!  Not bad.
I hope all this is useful to you, but if you think it is too much
trouble, get the CNFGLS13 package from IBM's MKTTOOLS and use it.
Your SE should be able to get it for you.
It'll do all the figuring for you that is described here, and more.
Use it often!
.smalloff
.*
.*    your foils ...
.*
.* --------------------------------------------- this must be at the end
.END NOSTAT                   ;.* NOSTAT to suppress statistics page