Resident Modules
================
Any application written with the Toolkit works in conjunction with two
TSRs known as the resident modules: RTM.EXE (the resident transport
module), and either RNMNIS.EXE or RNMFILE.EXE (the resident name service
modules.) These resident modules must be loaded on the PC's hard disk in a
directory located within the DOS Path. 

The Resident Transport Module
=============================
The resident transport module (RTM) provides the TCP and UDP transport
services that allow an application to "talk" to the underlying network. 

The RTM is loaded into memory by a Toolkit application the first time
the application needs to access the network. You can also load the resident 
modules from the DOS command line. To load a resident module from the 
command line, enter its file name, as in:
	rtm
A resident module loaded from the command line must be unloaded from the
command line.

The Toolkit supplies two utilities for removing resident modules from
memory:

RTMREM.EXE - to remove the RTM from memory
RNMREM.EXE - to remove the RNM from memory

Note - The resident modules must be unloaded in the order in which they
were loaded. If the RTM was loaded before the RNM and you attempt to run
RTMREM.EXE before RNMREM.EXE, RTMREM.EXE will fail with the message,
"rtmrem: Int2f is in use by another application. RTM is not removed." to
indicate that the RTM is being used by the RNM.

A resident module that is loaded from the command line must be unloaded
from the command line as well.  To unload, for example, a resident
module previously loaded from the command line, enter,

rtmrem
or
rnmrem

Resident Name Service Modules
=============================
The resident name-service modules (RNM) provide the naming services that
enable an application to locate other nodes and services on a network. 
The resident name service modules provide one of the following types of 
name-to-address mapping:

RNMNIS - Implements the network information service (NIS). NIS is a 
distributed database facility for storing network information. The 
information is maintained on NIS servers, and the RNMNIS module will 
query those servers to acquire any name-service information an 
application requests. To use this module, an application must be on a 
network that has NIS and must have PC-NFS configured to use NIS. RNMNIS 
takes approximately 37K of memory.

RNMFILE - Implements the file or local database name service. In this 
scheme, each node on the network has a local copy of the network 
databases. The RNMFILE module will satisfy application name-service 
queries based on the information in the local network databases. RNMFILE 
requires approximately 23K of memory.

Loading the Resident Modules
============================
There are two strategies for loading the resident modules. They can be 
loaded:

o  By the Toolkit Library when they are first required
o  Before running any applications that need them

The strategy you choose will have an impact on the memory available to 
your application. If you choose to load the resident modules before any
applications that will use them, the modules will decrease available 
memory by 58-125K before any other applications are loaded, but will not
interfere with an application's manipulation of far heap space. 

The ideal strategy for providing the maximum amount of memory to your 
application is to load as much network software as possible into the 
memory space above the 640K boundary. MS-DOS version 5.0 or a variety of 
third-party memory managers will enable you to load programs into this 
otherwise inaccessible memory.
 
Unfortunately, there may not be enough room in upper memory for all the 
device drivers and TSRs that you want to load "high." Current wisdom 
suggests that only 96-120K of this memory will typically be available, 
depending upon how the hardware of any particular machine is configured 
(extra hardware may be mapped into this area, for example.) The PC-NFS 
drivers and TSRs can use 70K or more, and the Toolkit RTM can be from 
35-88K, while the two RNM modules are 37K and 23K.

Command Line Switches for the Resident Modules
==============================================
When loaded from the DOS command line, the resident modules accept the 
following command-line switches:

/v -  displays the version number

/heap n - (RTM only) sets the amount of RTM heap space set aside for XTI 
endpoints and sockets, in kilobytes. n can be any value between 4 and 64.
The documentation supplied by an application vendor will tell you if you
need to use the /heap switch.

The netconf Database
====================
Once you have decided which resident name-service module your 
application will use, you may need to edit the netconf database, which 
can be located by searching NFSPATH.

The netconf file used by Toolkit applications contains the following lines:

udp     tpi_clts         v    inet udp \rtm\udp rnmnis.exe,rnmfile.exe
tcp     tpi_cots_ord     v    inet tcp \rtm\tcp rnmnis.exe,rnmfile.exe

For each of the usable network transport protocols-TCP and UDP, 
respectively-you can elect to use either the RNMNIS or the RNMFILE 
module. The RNM files must be listed identically for both specified 
protocols, which means that the following is not allowed:

udp     tpi_clts         v    inet udp \rtm\udp rnmnis.exe,rnmfile.exe
tcp     tpi_cots_ord     v    inet tcp \rtm\tcp rnmfile.exe,rnmnis.exe

The RNM used by the application will be the first one listed in netconf 
and found to be installed on the network. The user of a Toolkit 
application will need to edit netconf only if his network has NIS 
available but he prefers to use local-machine network databases. In this 
case, the user will need to remove references to rnmnis.exe from netconf.

