The user needs that gave rise to the original conception of the local area network (LAN) were far more modest than the user needs of today. The mainstay of business networking still involves activities such as sharing printers, sharing disks, and accessing common databases, but the scale at which these activities are conducted in the modern office dwarfs the simple needs of the early 1980s. Surprisingly, though, as demands for speed and bandwidth have doubled and redoubled, a single network operating system, Novell NetWare, has been able to fulfill these evolving needs in only three major architectural forms. The course of NetWare's development through its 2.x, 3.x and 4.x releases serves as a benchmark for the development of network computing in our time.
This chapter covers the following topics:
As anachronistic as a NetWare 2.x network might seem now, do not forget that it once was on the cutting edge, providing more capability than the users of its time knew what to do with.
As with standalone PCs, network file servers have advanced steadily and rapidly in their voracious appetites for memory and hard drive space. This is where NetWare 2.x really shows its age. By today's standards, a NOS that can support no more than 12M of RAM and 2G of disk space that must be split into volumes no larger than 256M is suitable for only the smallest and most basic of networks. True client/server functionality was only a gleam in Novell's eye when NetWare 2.x was released, and the server applications that were available as value-added processes (VAPs), were modest little applications that provided a simple, basic functionósuch as a backup interfaceówithout monopolizing the server's limited resources.
Despite the fact that they no longer are sold or supported by Novell, a significant number of NetWare 2.x servers are still running out there, and many administrators are satisfied with these servers' continued performance. Advocates of the "if it ain't broke, don't fix it" school may well save their employers some money in the short run, but they will, of course, run into problems when their storage or processing needs outgrow these systemsóor when they wish to run a service that simply cannot be supported by this archaic architecture.
There nofignger is an upgrade path from NetWare 2.x to the later versions. After a generous upgrade offer, and repeated announcements, NetWare 2.x has been officially withdrawn from the market. If you're a remaining NetWare 2.x user and ever decide to upgrade, you'll have to buy a NetWare 3.x or 4.x package at full price.
***
With the introduction of the 80386 microprocessor by Intel, the potential for the improvement of NOSs grew immeasurably. By definition, a NOS is intended to service the simultaneous requests of many users, and the multitasking capabilities of the new 32-bit processors seemed destined to be used for this purpose. The introduction of NetWare 386 in 1989 seemed to open up vast new horizons for networking. The new NetWare's open-ended architecture allowed for the use of enormous amounts of RAM (up to 4G) and hard disk space (up to 32 terabytes), and the introduction of virtual loadable modules (VLMs) presented third-party software companies with a robust set of development tools that challenged them to exercise their imaginations regarding uses that could be made of the tools.
Although originally dubbed NetWare 386 by its creators, this version of the NOS underwent a period of growing pains typical of any newly developed program, particularly an operating system. The first version, NetWare 3.0, supported only the native NetWare IPX protocol suite. Connectivity with Macintosh machines using AppleTalk and Unix machines through TCP/IP was not possible. Maintenance upgrades, versions 3.10 and 3.11, were soon released, resolving these shortcomings. The 3.10 release was extremely short-lived, with 3.11 soon provided as a free upgrade. With version 3.11, the 386 was dropped and the product was known simply as NetWare 3.11. Some time later, version 3.12 was released, adding additional functionality such as networked CD-ROM access, support for Packet Burst transmissions and Large Internet Packets, NCP Packet Signatures, as well as consolidating a number of patches into the shipping release, but this was a paid upgrade, and there are a great many sites still running 3.11 that have found no persuasive reason to upgrade. 3.12 is the only 3.x release that is currently being sold, however.
The original NetWare 386 release shipped as a large set of disks, but when version 3.12 hit the market, it was one of the first products to be shipped on CD-ROM by default. The product's online documentation was also on the disc, and Novell took a good amount of criticism for their decision to abandon the inclusion of paper manuals with their NetWare product. Manuals were available, but at a prohibitively high price. In truth, Novell's online manualsówhich used a viewer named Electro-Text in the 3.x releasesówere easily used, printed excellent hard copy when needed, and made searching for particular subjects far easier than poring over the numerous red books in the paper manual set.
Unlike the bootable partition created by the NetWare 2.x install program, the core of NetWare 3.x is a single DOS executable named SERVER.EXE. This file, when executed from a small DOS partition or a floppy disk, completely takes over all the resources of the computer. Indeed, even the memory used by DOS to boot the machine and run COMMAND.COM can be returned to the NOS, once SERVER.EXE has been loaded.
Running SERVER.EXE technically turns the PC on which it is executed into a self-contained Novell network. Before any of the attributes have been configured to provide the server with access to the network, or to its own storage devices, the program prompts the user for a name for the server and a hexadecimal value for the server's internal IPX address. Like each of the network segments to which the server will ultimately be attached, this address is the identity by which this "one-node network" is known to the rest of the enterprise.
The SERVER.EXE file also contains the NetWare license information. The restriction in the number of users allowed by the particular license purchased is enforced by the NetWare kernel. The serial number of the product is also embedded in the file and is automatically broadcast over the network once LAN access is enabled. If any other server utilizing the same copy of SERVER.EXE is detected on the same network, repeated beeps and license violation messages are generated at the consoles of both servers every few seconds until one of them is brought down. It is a good idea in a multi-server environment, therefore, to keep track of which copy of SERVER.EXE is being used on each server, so that conflicts can be avoided.
The file server is, at this point, useless for any sort of task traditionally associated with computing or networking, but already, we can observe the basic functionality of the kernel. Having supplied a server name and an IPX address, the console of the PC presents a command prompt in the form of a colon (:). Subsequent versions of NetWare may present the server name prior to the colon, but NetWare 3.11 or 3.12, out of the box, presents only the colon.
As with DOS, the presence of the command prompt indicates that the NetWare command processor has been loaded and is functioning. The similarity with DOS continues in that numerous commands internal to the operating system can be executed from the command prompt. For example, entering MEMORY at the colon displays the amount of RAM that is currently usable to NetWare in this PC.
This demonstrates another basic functionality of the NetWare kernel: memory management. Before running SERVER.EXE, the computer has to have been booted to a DOS prompt from a floppy or a DOS partition on the server's primary hard drive. Unless a DOS-based memory manager, such as HIMEM.SYS, has been loaded by mistake, all the memory on the computer above the 1088K mark is not being addressed in any way until SERVER.EXE loads.
To demonstrate the way in which the NetWare kernel has completely taken over the functionality of the computer, you can execute another internal command from the colon prompt: REMOVE DOS totally unloads the DOS operating system and releases to NetWare the memory DOS had utilized. Enter MEMORY again, and a modest increase in the amount of NetWare-addressable memory should be evident. Once the file server has been completely configured, and is up and running, some administrators always execute the REMOVE DOS command to gain every bit of available memory for use by NetWare.
The disadvantages of this practice, however, are made apparent even by our little demonstration. Having removed DOS from memory, you no longer have access to the DOS hard drive partition or the floppy disk drive. Since no disk or LAN drivers have been loaded into the NOS yet, you suddenly find yourself sitting alone in front of a one-node network, with no resources other than those currently in memory.
Obviously, this is not a real-world situation, but the same theory holds true for a fully configured file server. If, for example, there was a disk problem that caused the server's volumes to dismount, removing DOS would prevent you from loading VREPAIR, the NetWare volume repair utility, from a floppy disk or from the DOS partition of the server's hard drive (where you should have cleverly stored a copy, in case of such an emergency).
In that case, as in our demonstration case now, there is no alternative except to execute DOWN at the colon prompt, shutting down SERVER.EXE. On a fully functional server, this causes all server processes to cease, unloads all modules from memory, and then presents a message stating Type EXIT to return to DOS. You may do so, but you will find that there is no DOS in memory to return to. The system has halted for want of a valid COMMAND.COM file, and there is no choice but to reboot the computer, and start over.
On a single-server network, the loss of disk access for any reason would be likely to bring all network users to a halt anyway, but there are many networking situations in which it is preferable to troubleshoot the server while it is still up and running. For example, on a network with several servers, the one with the problem may be functioning as a router (through the installation of multiple network adapters). Loss of disk access is an inconvenience, but bringing the server down completely could cause the users on one or more network segments to lose access to vital network resources.
There are many other internal NetWare commands that can be executed from the colon prompt, and we will use some of them while walking through the process of configuring the server for productive use. Apart from these, however, the NetWare OS can also execute external commands in the form of executable files called NetWare command files (NCF files). These are the only executables recognized by NetWare (unlike DOS, which recognizes three: EXE, COM, and BAT). In fact, NCFs are little different from DOS batch filesóthey are composed solely of ASCII text, are uncompiled, and consist primarily of commands that could also be executed from the command prompt.
A NetWare server nearly always has STARTUP.NCF and AUTOEXEC.NCF files resembling the CONfig.SYS and AUTOEXEC.BAT files of a PC running DOS. These NCF files are automatically executed by the operating system as it loads, just as their DOS counterparts are.
The primary purpose of the STARTUP.NCF file is to load drivers that provide access to the hard disk drive that will contain the files constituting the majority of the NOS. For this reason, STARTUP.NCF is always located on and loaded from the DOS disk (either hard or floppy) where SERVER.EXE is located. Aside from COMMAND.COM and the DOS boot files, SERVER.EXE, STARTUP.NCF and the appropriate disk drivers are the only files that must be on the DOS disk; however, the disk often is also used for other purposes.
As demonstrated earlier, it can be a very good idea to store copies of emergency utilities like VREPAIR on this disk. Some systems even include enough room on a DOS hard drive partition to store a replica of the server's memory. In the case of a server abend (an abnormal ending to server processing), the NetWare system is halted, but a powerful utility named NetWare Debugger is left in memory. One of the functions of the debugger is the ability to perform a core dump; that is, to export an exact image of the server's memory at the moment of the abend to floppy disks or a hard drive partition, for later examination by technical support personnel. Given the large amounts of memory often found in today's NetWare servers, outputting a core dump to floppy disks can be impractical; hence, you may use the DOS partition for this purpose.
A STARTUP.NCF file often contains no more than the commands necessary to provide basic hard drive access to the NOS. This is done using the internal NetWare command LOAD followed by the filename of the appropriate disk driver, as well as any parameters that are needed for the driver to locate the hard drive interface adapter. Once the operating system is loaded, however, the LOAD command can be used to execute other types of modules, most notably NetWare loadable modules (NLMs), the executable form taken by most programs that run on a NetWare server. VREPAIR, for example, is an NLM.
NetWare disk drivers are always named using a DSK extension. They may be supplied with the NetWare operating system, but more often are provided by the manufacturer of the hard drive interface that they must address. It is a good idea, before you begin the installation process for any particular drive interface, to acquire the latest available version of the disk drivers. Virtually all adapter manufacturers maintain one or more online services from which current drivers can be downloaded.
Several other points should be made concerning hard disk drivers. First, even if you have booted the PC from a particular hard drive via the BIOS on the computer's motherboard or a SCSI host adapter, it is necessary to load a NetWare disk driver to provide access to the drive by the NOS. Any disk space used for a DOS partition cannot be utilized by NetWare, so at times there will be two different drivers in the computer's memory, addressing the same device.
Another thing to be concerned about is that some NetWare disk drivers spawn other drivers during their loading process, meaning that one driver automatically loads another without the need for explicit commands to do so.
The most common instance of such spawning occurs when you load a SCSI driver that supports the advanced SCSI programming interface (ASPI), which allows different types of peripherals to coexist on the same SCSI bus. (See chapter 5, "The Server Platform," for more information on SCSI and SCSI drivers.) Explicitly loading a driver such as AHA1540.DSK (used to support the Adaptec AHA-1540 family of SCSI host adapters) causes another driver, ASPITRAN.DSK, to be loaded, providing the ASPI functionality that allows later access of a CD-ROM drive, tape drive, or other peripheral attached to the same adapter. Of course, ASPITRAN.DSK is not loaded if it cannot be found. Be sure that all the drivers needed to support the interfaces in the server are located in the same directory as the SERVER.EXE file.
The drivers can be located in another directory if fully qualified pathnames are provided in STARTUP.NCF, but the drivers should be located on the same device.
The other drivers that usually are loaded from the STARTUP.NCF file are name space modules. These modules, which have the extension NAM, are supplied with all versions of NetWare. They allow NetWare volumes to support file naming and storage conventions other than the standard DOS 8.3 format that is the NetWare default, including those for Macintosh, HPFS (the native OS/2 file format), the File Transfer, Access, and Management protocol (FTAM), or NFS (used by many UNIX systems). Name space support is provided by these modules once the NetWare ADD NAME SPACE server console command has been used to modify specific volumes so that space for additional naming information is provided by the NetWare file system. ADD NAME SPACE only has to be executed once for each name space on each volume, but the appropriate NAM drivers must be loaded every time disk drivers are loaded. Multiple name spaces can be added to any volume, at the cost of additional memory and disk space required to support them. Name space support can only be removed non-destructively from a volume by using the NetWare VREPAIR utility.
Since it is composed only of ASCII text, a STARTUP.NCF file can be created and revised by any DOS text editor. There is a module named EDIT.NLM included with NetWare that can be loaded from the colon prompt, which allows a text file located on a DOS partition or a NetWare volume to be edited directly from the file server console. This is a very convenient utility which many NetWare users don't know about. It can be very handy when you need to troubleshoot NCF files in a server room without a workstation nearby.
Another, more convenient method to create the STARTUP.NCF file is available. The INSTALL.NLM module, which NetWare uses to create and maintain hard disk volumes as well as to copy its system files from floppy disk or CD-ROM, has a feature by which STARTUP.NCF can be created automatically, based on the disk driver modules that have been loaded from the NetWare command prompt. After bringing up SERVER.EXE as described earlier in this chapter, use LOAD at the colon prompt to load the DSK files necessary to provide disk access. Most drivers then prompt the user for the hardware parameters needed to locate the host adapter. Once the drivers have been successfully loaded and configured, choose Create STARTUP.NCF File from the System Options menu of INSTALL.NLM; this retrieves the commands just entered at the colon prompt, and inserts them into a new STARTUP.NCF file (at the location of your choice), using the proper command-line syntax. Choose Edit STARTUP.NCF File if you want to modify a file that already exists. Since there is not yet any NetWare storage available on this server, INSTALL.NLM must be run from a DOS deviceóoften, the original NetWare installation medium.
One of the most powerfulóand certainly the most versatileóof the internal NetWare system console commands is SET. Issuing this command at the colon prompt brings up a series of submenus providing access to dozens of NetWare configuration parameters that can be used to fine-tune the server. Some of the SET parameters themselves will be examined later in this chapter and elsewhere in this book, but their existence is mentioned here because several of them, mostly concerned with memory or the file system, cannot be issued directly from the colon prompt or from the AUTOEXEC.NCF file. This usually is because they affect the way certain parts of the operating system are initially loaded into memory. SET commands of this type, which are clearly designated as such in the NetWare manuals, must therefore be made available as the operating system loadsóthis is done by placing them in STARTUP.NCF. Any of these commands added to the NCF file while the server is running do not take effect until the server is shut down (using DOWN) and restarted.
On a fully configured NetWare server, the successful loading of the disk drivers from STARTUP.NCF causes the server's SYS: volume to be mounted automatically. The NOS then searches the SYS: volume for a /SYSTEM directory, and within that directory, looks for an AUTOEXEC.NCF file, which is executed if it's found. Like STARTUP.NCF, AUTOEXEC.NCF can be manufactured automatically by the INSTALL.NLM utility. Once the remaining tasks of configuring the file server for disk and LAN access are complete (as detailed in the following sections), and Create AUTOEXEC.NCF File is selected from the System Options menu, the file is created and placed in the SYS:\SYSTEM directory. Before this can be done, however, the INSTALL utility must be used to create the NetWare volume where this file is to be stored on a hard drive (as well as any other volumes you desire).
In NetWare parlance, a volume refers to the top level data storage container on a particular file server. It is similar to the DOS term partition, in that a single hard disk drive can be split into many volumes, up to 64 on a single server. Unlike a DOS partition, however, a NetWare volume can span multiple disk drives (up to 32). While the use of multiple drives increases the number of reads and writes that can be performed simultaneously, this practice usually is not recommended, as the failure of any one of the drives comprising a single volume would render the entire volume inaccessible.
When creating a volume with INSTALL.NLM, the user is presented with a table listing all the hard drive space that has been made available by the disk drivers. Before volumes can be created, the hard drives must be formatted. Many new drives are formatted at the factory and can be used immediately. Otherwise, they can be formatted using a program recommended by the manufacturer, the DOS FORMAT utility, or a function included as part of the INSTALL.NLM program.
Once the drives are formatted, you create each desired volume, one at a time, by specifying the desired size of the volume (in megabytes), a name for the volume, and the size of the blocks that will comprise the volume. The first volume must be named SYS:. This is where the NetWare operating system files will be stored. You may give other volumes any name as you create them; traditionally, subsequent volumes are named VOL1:, VOL2:, and so on. It is important to note that although you can make volumes larger later through the addition of more disk space, you cannot decrease their size unless you destroy and re-create them.
As mentioned in the last section, one of the basic parameters you select when you create a volume is block size. This is a value (in bytes) that defines the smallest possible storage unit that can be allocated on that particular volume. No file stored on the volume will consume less than one block's worth of disk space, with additional blocks allocated as needed, in whole blocks only. The block size of a volume can be 4K, 8K, 16K, 32K, or 64K, with the default set at 4K (4096 bytes). In other words, a 200-byte file, when copied to a NetWare volume configured to use a 4K block size, gets an entire 4K block allocated to it. Only 200 bytes of that block are filled with data, and the rest remains as empty space, sometimes referred to as slack, which is unusable by any other process.
The ability to select a block size allows the administrator the flexibility to organize his data storage to take as much advantage of his available disk space as possible. An organization that deals with vast numbers of very small files, for example, would be better off with a small block size, so that less disk space is wasted by slack. A volume that is used for the storage of large databases or multimedia files, however, would benefit from a larger block size, because the less blocks the operating systems needs to cache in memory, the more efficient it is. Different block sizes can be assigned to each volume on a server, so data can be effectively organized by the administrator and allocated to an appropriate volume, if desired. Once a volume is created, the only way to change the block size is to delete the volume entirely and then re-create it, destroying all data stored there.
NetWare has a number of features, like configurable block sizes, that subtly urge the user towards a more organized network configuration. Inexperienced administrators are often haphazard about the way in which they assign the available storage space on their network file system. Some tend to place too many files into single directories, while others go the opposite route and create too many directories, nesting them many layers deep unnecessarily. Either extreme can cause inconvenience and delays, and can waste system resources.
The NetWare operating system caches both file and directory information into memory. While it is not intended to cache the entire file systemónetworks have grown far too large for this to be practicalóthe NOS has been designed to keep the most frequently used file and directory entries available in areas of cachefigmory, to speed up disk access. Having thousands of files in a single directory or having many sparsely-populated directories can cause the caches to be flooded with unneeded files, leading to the exclusion of more worthy data.
Even if you do not change the volume block size from the default, it is a good idea to have a plan delineating where specific kinds of data are to be stored before creating the volumes on your server. Most of the time, an average volume holds files of greatly varying sizes. A typical Windows application, for example, may consist of dozensóeven hundredsóof tiny files, as well as some very large ones. The concept of block sizes should by no means lead you to split up a cohesive group of files, such as those devoted to a single application, across volumes according to their size. This would cause more problems than it would resolve. For general use, the default 4K block size is a good median figure.
File system organization is a subject that is usually understated in most networking manuals. When told not to put too many files in one directory, some people veer wildly in the opposite direction, creating hundreds of directories than contain only a handful of files in each. There is no need to be compulsive or neurotic about maintenance of the server file system. The idea is to provide a gentle nudge to users, urging them to be aware of what they intend to store on server drives, and allowing them to make common-sense adjustments accordingly.
Sometimes, the addition of name spaces for other file system types determines where particular types of data should be stored. Remember that name spaces require additional memory to cache their file information. It would be wasteful to create a name space on a huge volume based on the slim chance that you might someday store a Macintosh file there. If you plan to store files of different types, requiring the support of several different name spaces, it is a good idea to create the different name spaces on separate volumes, rather than creating all the name spaces on one volume.
Another factor to consider when creating volumes is the use of NetWare's Hot Fix disk capabilities. This is a system that reserves a small percentage of the blocks allocated for a particular volume as an area where data can be placed after an attempt is made to write to a bad block on the hard drive. This is done in conjunction with NetWare's read-after-write verification. Each time a file is written to a volume, the NOS attempts to read the just-written file. If a problem is encountered, that block is flagged as defective, and its contents redirected to the Hot Fix area. A small number of bad blocks on a hard drive is no cause for alarm, and the two percent of the volume that is assigned as the Hot Fix area is usually more than sufficient.
The percentage of a volume that serves as the Hot Fix area can be increased through INSTALL.NLM, but if you actually need more than two percent, you might be better off servicing or replacing your hard drive.
***
There may be circumstances when it is preferable to disable the read-after-write verification and Hot Fix capabilities. Some of the newer hard drive interfaces perform functions equivalent to these at the hardware level, thus rendering NetWare's software implementations redundant. Disabling the features allows a two-percent increase in available volume storage space, and enhances the overall efficiency of the NetWare file system by removing the need to read every file after writing it. SET ENABLE DISK READ AFTER WRITE VERIFY = OFF disables the file verification; although this command can be issued at any time, it is recommended that you do it in STARTUP.NCF, before the disk driver is loaded. The Hot Fix area can be eliminated from the Disk Options menu in INSTALL.
Once the volumes have been created on the server drives, all that remains to make them accessible to the NOS is to mount them. The internal server console command MOUNT is used for this purpose, with either ALL or the name of a particular volume specified on the command line. This command ultimately is included in the AUTOEXEC.NCF file, so that disk access is granted automatically whenever the server is started. The mounting of the drives begins the process by which some of their contents are cached in the server's memory pools. Directory entry tables are created at this time, and files, as they are accessed, are saved in the server's file cache buffers for quick recall by later processes.
Because of this activity, the amount of server memory required to run the NOS properly is highly dependent on the amount of disk space that has been mounted on that server. One of the prime symptoms of a RAM shortage in a NetWare file server is for volumes to spontaneously dismount themselves when other processes utilize too much of the available memory. While this occurrence might also indicate the existence of a problem with a disk driver, a hard drive itself, or the other process that caused the dismount, RAM shortage is the easiest thing to check. Temporarily unload some unnecessary NLMs or other modules to free up additional memory, and then repeat the process that caused the original dismount to see if it occurs again. This kind of basic, common-sense troubleshooting is a fundamental skill of LAN administration.
One of the most advanced fault tolerance mechanisms in the NetWare file system is the transaction tracking system (TTS). This feature, integrated into the operating system, helps to prevent the corruption of data when a server process is interrupted. When a server crashes or abends, it is very common to see messages upon restarting the machine, indicating that a specified number of transactions have been trapped by TTS. The system asks if you want the transactions to be backed out, and processing stops until a response is entered.
TTS is implemented (in NetWare 3.12 and higher) as an integrated feature, closely associated with the file-caching system. The purpose of TTS is to protect database files that are stored on server volumes from corruption when a write to those files is interrupted for any reason. It protects the NetWare Bindery, the file system tables, and queue database files, but can be equally useful for transactional database files used by other applications, such as Btrieve or other database engines.
As transactions (such as file writes) are sent to database files on the server, they are cached in memory and written to a separate NetWare system file for safekeeping until the transaction is fully completed, at which time the record of that transaction is marked as closed. If the transaction is interrupted before completion, by a hardware or power failure, or by any other software or memory problem, the transaction remains marked open in TTS. Whenever the server is restarted, TTS records are examined for open entries. If any are found, then the aforementioned dialog box is displayed. If you choose, the data associated with the open transactions is backed out from the original database file. This means that any partial transactions applied before the interruption are undone, and the database file is restored to the condition it was in before the transactions occurred. In many cases, this process removes any database corruption that the partial transactions caused.
It is possible to suppress the dialog when incomplete transactions are found, and instead have them automatically backed out. Do so by including SET AUTO TTS BACKOUT FLAG = ON in the STARTUP.NCF file.
TTS is initialized when the SYS: volume is mounted as the server boots, as long as there is enough memory and disk space for the process to occur. If TTS does not initialize for some reason, then issuing the ENABLE TTS command at the server console can begin the process, as long as the condition that prevented the initialization in the first place has been addressed. TTS can be disabled by issuing the DISABLE TTS command at the server console, or by dismounting the SYS: volume. TTS can also be toggled on and off using the FCONSOLE utility.
TTS can only protect files that are composed of discrete records that can be individually locked for access by multiple users. This includes most database files and some e-mail applications. In order to be protected by TTS, the files must be flagged with the Transactional attribute, using the workstation FLAG utility. TTS can protect up to 10,000 transactions at the same time on a single server. The number of transactions is controlled by the SET MAXIMUM TRANSACTIONS = MAX command; the default of 10,000 is the highest value allowed. This should be more than you will ever need, but since no resources are allocated unless the transactions are performed, there is no harm in leaving this parameter set to the maximum.
All TTS activities are logged into a file named TTS$LOG.ERR, which is stored at the root of the SYS: volume. No provision is made in the operating system for the purging of this file, so it is possible for it to become quite large eventually. Since it is an ASCII text file, it can be edited to remove older information, or can be deleted entirely. NetWare creates a new one as needed.
The design of TTS makes it completely transparent to the applications controlling the databases. A database file and the temporary file created by TTS utilize one file handle, and therefore are seen as a unified entity by the application. Although many database engines have built-in transaction rollback capabilities, utilizing the protection provided by NetWare's TTS might be preferable for several reasons. First, since the system is located within the server operating system, it is less likely to crash during an operation, and even if it did, the TTS is capable of backing out its own back-outs, should the process be interrupted. Second, network traffic is reduced because the transaction tracking is performed at the same location where the files are stored. Third, the delayed write can be performed as a background process, giving greater priority to new file read requests. Fourth, TTS can provide protection for database systems that have no such capabilities of their own. Overall, TTS is one of the most stable and transparent forms of file protection in the NetWare operating system. It rarely is the source of any type of maintenance problem, and it provides excellent protection of both NetWare and third-party database files.
The discussion of the mounting of NetWare volumes brings us to one of the more hotly contested issues surrounding the configuration of a new file server: How much memory should be installed in the machine for proper performance? While we will examine some of the formulas provided by Novell to help answer this question, the final answer is that you always should err on the side of caution and install more memory than you think you need.
This is because nothing degrades a file server's performance more profoundly than having insufficient RAM. Memory shortage is the most common problem negatively affecting the performance of NetWare file servers, and conversely, the most significant upgrade that can be made to the server is to add RAM. NetWare uses all available memoryóabove the amount needed for core OS requirements and other loaded modulesóas file cache buffers. These are areas of memory in which recently accessed files are cached, using a write-back method so that they can be more quickly accessed if requested again. (A write-back cache is one that caches files on their way both to and from the storage medium.) As memory is needed for other processes, it is taken from the file cache buffer pool. Depending on the process, this memory might or might not be returned to the pool when it is no longer needed.
The default size of a server's file cache buffers is 4K (4096 bytes). This is a deliberate correlation with the default volume block size. File cache buffer size can be changed from the default by including SET CACHE BUFFER SIZE = SIZE in the STARTUP.NCF file. (This can only be specified in STARTUP.NCF.) The acceptable values are 4096, 8192, and 16384. The buffer size specified should always be the same as the smallest block size used on any of that server's storage volumes.
The current amount and percentage of memory allocated to the file cache buffer pool can be viewed in the Resource Utilization window of MONITOR.NLM. (This server utility provides the most comprehensive look at the current state of the NetWare file server, and you learn about some of its capabilities, as well as the configuration of different file server memory pools, later in this chapter.) No memory in a NetWare file server ever goes to waste. The only potential drawback to installing too much memory is the cost incurred.
The NetWare manuals dictate that the file cache buffer pool should not be allowed to drop below 20 percent of the available server memory. This should be considered the "red line," the point at which danger lights start flashing. Many NetWare administrators begin their nervousness, however, when the file cache buffer pool drops below 50 percent. Servers perform best when this number is at 60 percent or higher. Although this statistic is unavailable until the server is actually installed, configured, and running, it's the only sure way to determine whether or not a server has enough memory installed in it.
One of the most important factors to consider when examining the figures shown in MONITOR.NLM is the current operational state of the server in relation to the various modules that you may have loaded onto it. Many of the server-based software products used today involve processes that are either launched by user demand or designed to be performed automatically at scheduled times, usually during non-production hours. Backup and communications software (such as network faxing systems) are particularly prone to this practice. A backup software package, for example, may use only a minimal amount of memory when it is idle, but may spawn numerous additional processes, consuming additional memory, in the middle of the night when the backup is performed. In a case like this, a file cache buffer percentage that looks acceptable during the day could be taken below the minimum requirement during the night, causing all sorts of problems, possibly including a server abend.
The difficulty surrounding the question of estimating the amount of memory needed by NetWare is primarily the result of contradictions emanating from Novell. The original NetWare 3.12 manual set, released in July 1993, provides two different formulas. The Installation and Upgrade manual gives what is intended to be a rough approximationóa simple calculation of 0.008 multiplied by the volume size, with constant values added for various amounts of system overhead. The System Administration manual contains the more familiar, and detailed, formula of 0.023 multiplied by the volume size, divided by the block size. This calculation takes the block size into account, which is quite significant in light of the fact that a volume with 4K blocks needs 16 times the amount of memory of a volume the same size with 64K blocks.
Either formula provides reasonably safe results when a server contains a relatively small amount of storage space, and is not heavily loaded with other modules or applications. The limited number of possible memory configurations for the average motherboard nearly always ensures that RAM calculation is rounded off to the next highest multiple of 4M or 16M. Unfortunately, the large amount of storage now being used in many servers, and the wide array of server-based applications and services now available, were not fully anticipated by Novell, even as recently as 1993. Hard drive arrays with capacities of 5G, 10G, or more have become fairly commonplace, and CD-ROMs are well on their way to ubiquity. In addition, many servers are now being used to run multiple directory name spaces, database servers, multi-protocol routers, host connectivity gateways, modem-pooling and remote-access products, or e-mail routers and gateways. Each of these types of products has additional resource requirements above the basic needs of the NOS.
For a complex server configuration like this, combining all the various memory requirements for disk space and file managementóas well as file and directory cachingóinto a single factor to multiply against the server's disk space is inappropriate. While it is true that every megabyte of disk space requires a certain amount of RAM for storing the FAT and other media management needs, estimations of memory requirements for file caching purposes is more accurate if based on the number of users rather than the total amount of disk space. When the above formulas are used on heavily loaded server configurations, the results can yield great discrepancies, often as much as 20M or more.
For this reason, Novell has officially discredited both formulas, and in December 1994, published a supplement to its Application Notes publication that provides a far more detailed worksheet for server memory calculation. Now, separate calculations are required for many of the factors that were grouped together in the earlier formulas. Consideration is also paid to the factors affecting memory usage by NetWare 4.x serversóthese factors are covered later in this chapter.
The worksheet above does not take into account the addition of name spaces to individual volumes. The addition of the NAM name space modules to the server's memory configuration produces virtually no additional memory overhead. The primary impact of name spaces is in the allocation of memory for the caching of the volumes' directory entry tables (DETs). This memory is allocated from the Permanent Memory pool in the form of directory cache buffers (memory pools are examined in more detail later in this chapter). The DET normally lists one entry for each file on a volume. The addition of each name space causes every file to require one additional entry in the table. Thus, while a single 4K directory cache buffer can manage 32 files with only the default DOS name space loaded, this number is reduced to 16 files with one extra name space, 10 files with two extra name spaces, and 8 files with three extra name spaces.
To compute the additional RAM required to compensate for the additional directory cache buffers needed, Novell provides the following formula:
ï 0.032 x volumesize (in M) / blocksize (in K)
Round the result to the next highest megabyte and add to the total RAM requirement previously calculated.
It is important to understand, though, that memory allocation for additional name spaces is solely a matter of server performance, which can be tuned by the user. No additional memory (beyond the small amount needed to load the NAM module) is actually used by the name spaces, but clients' disk access speed will decrease noticeably as additional name spaces are loaded, if the same amount of memory is allocated to caching directory entries. While NetWare 2.x cached the entire directory entry table into memory, this was found to be impractical on servers with large amounts of storage space, so in NetWare 3.x and 4.x only portions of the table are cached, according to a most-recently-used (MRU) algorithm. When one additional name space is added to a server's volumes, the number of directory cache buffers allocated must be doubled to achieve the same level of efficiency those volumes would have had without the added name space.
The number of directory cache buffers that can be allocated is bounded by two SET commands that typically are included in the server's AUTOEXEC.NCF file when the defaults are to be changed:
| Parameter | Default | Minimum | Maximum |
| SET MINIMUM DIRECTORY CACHE BUFFERS | 20 | 10 | 2000 |
| SET MAXIMUM DIRECTORY CACHE BUFFERS | 500 | 20 | 4000 |
The MINIMUM setting represents the directory cache buffers that are allocated immediately when the operating system is booted. This is done because the addition of each additional buffer (beyond the minimum) incurs a 1.1 second delay. Pre-allocating a specified number of buffers that are sure to be needed helps to minimize these delays. If file access seems slow immediately after booting the server and then increases later, this parameter should be increased. Care should be taken, however, not to set this parameter too high. Memory that is allocated for use as directory cache buffers cannot be returned to the file cache buffer pool. Allocated buffers that are not actually used by the file system are wasting server memory.
The MAXIMUM setting prevents the file system from causing too much memory to be allocated to directory cache buffers. Without this setting, the operating system would eventually attempt to cache the entire directory entry table; in most cases, this would monopolize all the memory in the server.
NetWare dynamically allocates additional directory cache buffers from the Permanent Memory pool as needed. The number of buffers currently in use can be viewed in the Resource Utilization screen of the MONITOR.NLM utility. The best way to determine the optimal settings for these two parameters is to observe the increase in the number of buffers allocated over several days of typical server use. Running the server without additional name spaces loaded on the volumes allows a baseline to be established with which the additional requirements for the name spaces can be computed. For one additional name space, double the number of buffers actually allocated and use this as the MINIMUM. For two name spaces, triple it; for three, quadruple it. For the MAXIMUM, add at least 100 to MINIMUM to allow for growth during peak usage.
If a situation arises in which a production server is low on memory, these two parameters should be among the first to be lowered as a temporary stopgap measure until more memory can be installed. Performance might suffer, but this may allow important processes to continue that otherwise would be halted for want of additional RAM.
The use of name spaces on server volumes might be necessary to the operation of the network, but as we've seen, it can require significant amounts of additional memory. It therefore is recommended that, whenever possible, separate volumes be created for the files that require name space support, to prevent simple DOS files from impacting the performance of the server too greatly. It is preferable also for name space support to be added when the volumes are created, rather than after DOS files have already been written to the disk.
Adding a name space to a newly created volume ensures that the additional entry in the DET for each file is nearly always within the same directory entry block as the original entry. Name spaces added later cause the directory entries to be located in different blocks most of the time, requiring that both blocks be cached by the file system in order to access that file, thus decreasing the system's efficiency. When a file with multiple name spaces is accessed from a client, however, only the directory entry corresponding to that particular client is cached. In other words, a file accessed from a Macintosh workstation caches the original DOS entry in the DET as well as the Macintosh entry, but any other entries, such as HPFS or NFS, if they exist for that file, are not cached.
The previous section exemplified one of the ways in which the NetWare operating system allocates available server memory to its many processes. We also have discussed the way in which file cache buffers comprise the primary memory pool from which all of NetWare's other pools access the memory they need. It is important to understand the interaction between the various memory pools, because while some can utilize memory as needed and then return it to the source from which it came, others allocate memory on a permanent basis, releasing it only when the operating system is shut down. Although NetWare contains some very advanced auto-tuning features that allow it to run quite efficientlyóin most cases, without modification of the default settingsó optimizing the way in which memory is managed by the operating system can provide a noticeable increase in server performance and efficiency.
As can be seen from the operating system's original name, NetWare 386 is based on the Intel 80386 microprocessor. The advanced memory handling capabilities of that processor were utilized by NetWare to a greater degree than any other operating system of its time. This is due primarily to the fact that backward compatibility was not considered to be an issue by the developers. NetWare 3.x was a completely new networking environment and, at the time, there were relatively few third-party products that were actually loaded directly into the server's memory structure. The VAPs of NetWare 2.x were eliminated entirely, allowing a totally new memory allocation scheme to be created.
The 32-bit registers of the 386 processor allow NetWare to address the memory installed in the file server as a single contiguous segment, up to 4G in size (232 bytes = 4,294,967,296 bytes = 4G). Rather than pre-allocate areas of memory for the operating system's various needs, as NetWare 2.x does, NetWare 3.x dynamically allocates memory from this pool, only as needed. This largest, primary pool, from which all other processes derive memory, is known as the File Cache Buffer pool, because all memory that is not needed for other processes is used for caching file reads and writes. The primary function of the NetWare memory management system is to provide memory to any other process that requests it, while maximizing the amount of RAM available for caching. There is a minimum requirement of 20 cache buffers for the server's operation, but the more File Cache Buffer space is available, the better the server will runófor this reason, installing additional RAM in a NetWare server is never a wasted action. There is no simpler or better way to enhance server performance than to add additional memory to this pool.
Figure 8.1 shows the File Cache Buffer pool and the other NetWare memory pools. The following sections describe each of the other pools, their uses, and the ways they interact with the File Cache Buffer pool, NetWare's ultimate memory source.
Figure 8.1 These are the NetWare 3.x file server memory pools.
The Permanent Memory pool, as the name indicates, is used for the maintenance of permanent tables and other long-term memory needs. It is also the area in which directory and communications data is cached, in the form of directory cache buffers and packet receive buffers. It is permanent also in the sense that any memory allocated to this pool from the File Cache Buffer pool cannot be returned to the File Cache Buffer pool, except when you restart the server. On the Resource Utilization screen of MONITOR.NLM, the amount of server RAM allocated to the Permanent Memory pool is displayed, along with the amount that is currently in use. Amounts of memory in this pool that are not being used are going to waste, and steps should be taken to determine what processes are causing this memory to be allocated. One possible cause is the values of either the MINIMUM DIRECTORY CACHE BUFFERS or MINIMUM PACKET RECEIVE BUFFERS parameter being set too high.
The Semi-Permanent Memory pool is utilized primarily for LAN and disk driversósmall amounts of memory that are needed for extended lengths of time. This memory can be thought of as a nested pool or "sub-pool." Memory is allocated to this pool dynamically from the Permanent Memory pool as needed, and it can be returned to the Permanent Memory pool when no longer needed. Such returned memory can be accessed directly from the Permanent Memory pool, or can be allocated to another sub-pool, but cannot be returned to use as file cache buffers.
The Alloc Short-Term Memory pool also uses the Permanent Memory pool as its source, but unlike the Semi-Permanent Memory pool, the Alloc Short-Term Memory pool cannot return its memory to the Permanent Memory pool. When the memory is released from use, it remains in the Alloc Short-Term Memory pool, where it can be used by other processes, but only within that pool. This type of memory is used for many tasks requiring small (below 4K) allocations over short periods of time, including the following:
Because of the one-way nature of its memory allocation, some care must be taken to not allow too much RAM to be allocated to the Alloc Short-Term Memory pool. As with the Permanent Memory pool, the size of the Alloc Short-Term Memory pool and the amount that is actually in use can be viewed in the Resource Utilization screen of MONITOR.NLM.
Practices like opening too many windows in several different menu-driven server modules at the same time (ironically, this includes MONITOR.NLM) can cause too much memory to be allocated to this pool, and this memory goes to waste once the windows are closed. Sometimes, improperly coded NLMs can cause a consistent increase in the Alloc Short-Term Memory pool. This can be checked by examining the resource tags (using MONITOR.NLM) for the various NLMs loaded on the server over a period of time, to see which one is regularly requesting more memory from the Alloc Short-Term Memory pool.
Although "alloc" sounds like a truncated version of "allocated," I have never seen this pool referred to by any name that didn't involve "Alloc Memory."
The total amount of memory available for this pool can be controlled through the use of SET MAXIMUM ALLOC SHORT TERM MEMORY, which establishes a ceiling beyond which no more RAM can be used for the Alloc Short-Term Memory pool. The default setting for this parameter was 2M in NetWare versions 3.11 and earlier, but changes to the operating system's memory architecture in version 3.12 caused a greater amount of memory to be needed, as a rule, in the Alloc Short-Term Memory pool. The default setting for version 3.12 was raised to 8M, and the maximum setting to 32M, from 16M in earlier versions:
| Parameter | Version | Default | Maximum | |
| SET MAXIMUM ALLOC SHORT TERM MEMORY | 3.11 | 2M | 16M | |
| 3.12 | 8M | 32M |
The Cache Movable Memory pool is one of two pools that are derived directly from the File Cache Buffer pool, and that can return their memory back for use as file cache buffers after being released. It is used for the maintenance of NetWare's own file allocation, directory entry, and hashing tables, which require widely fluctuating amounts of memory depending on the degree and type of server use. Because this pool is used solely for NetWare's own native processes, it is movable. That is, the operating system dynamically can adjust the location of the memory used for this pool so that, when it is released, no memory fragmentation occurs in the File Cache Buffer pool.
The Cache Non-Movable Memory pool also draws memory directly from the File Cache Buffer pool, and is able to return the memory when it is no longer needed. This pool is used primarily for the loading of NLMs, and as a result, it often is one of the largest allocations on the server. Memory is allocated to this pool in static amounts; that is, it is non-expandable. A particular NLM needs a certain amount of memory to load, and exactly that amount of memory is drawn from the File Cache Buffer pool and allocated to the Cache Non-Movable Memory pool for use by that NLM. No further memory is drawn from this pool by the NLM as it is functioning, although the NLM may draw memory from other pools for different purposes.
(e)Memory Fragmentation
When an NLM is unloaded, memory taken from the Cache Non-Movable Memory pool is released and returned to the File Cache Buffer pool. However, as the name implies, the memory is not moved. The actual range of memory addresses used to load the NLM is released, creating the possibility for the File Cache Buffer pool to become fragmented. If you were to cite the most noticeable flaw in the NetWare memory management model, this would be it. Fragmented memory in the File Cache Buffer pool can result in a module failing to load, even though there is sufficient memory in the pool for its requirements. The problem is that a module will require that its memory be furnished in a single contiguous segment, which fragmentation prevents. The only way to eliminate memory fragmentation is to shut down and restart the server.
When NetWare 3.x was first released, this was not thought by the developers to be much of an issue for the average network server. Memory fragmentation is caused by the repeated loading and unloading of NLMs, and most third-party server applications at the time consisted of modules that were designed to be loaded once and left running continuouslyóhowever, this no longer is the case. Server applications have experienced the same rapid growth in size and capabilities as desktop software packages, and it now is common for them to consist of many different NLMs that are frequently loaded and unloaded as the program operates. For this reason, the era when NetWare 3.x servers could be left running for months or even years without interruption is all but over. It is highly recommended that servers on which this type of new software is installed be shut down regularly to defragment the File Cache Buffer pool. Once a month might be sufficient, but more frequent reboots might be necessary if file system performance becomes sluggish, or if modules fail to load for want of memory when sufficient memory seems to be available.
Frequent memory fragmentation in NetWare servers can also be caused by hardware limitations. The use of the ISA bus for hard drive and network interface cards that use bus-mastering or direct memory access (DMA) in file servers with more than 16M of installed memory is a practice that has been officially proscribed by Novell for many years, yet it continues unabated, even in servers with 32-bit bus slots available for use. Many 16-bit NICs use DMA to transfer packets to and from memory, and nearly all 16-bit SCSI host adapters use bus-mastering, DMA, or both. The fundamental problem is that these adapters are incapable architecturally of addressing memory above 16M.
The problem arises because the 16-bit ISA expansion bus has only 24 address lines, and therefore can only directly address 16M of memory. The ISA bus was designed for the IBM AT using the Intel 80286 microprocessor, which also had only 24 address lines and could utilize a maximum of 16M of RAM. Because of this limitation, these adapters are unable to properly process a memory address above 16M, or in hexadecimal notation, 0x00FFFFFF. Instead of proceeding from this point to the next address, 0x01000000, such adapters roll over to the bottom of their memory address range, to 0x00000001. The memory address at 17M, for example, appears no differently to these adapters than the memory address at 1M. In fact, such a device may attempt to write to both locations at once, affecting whatever code happens to be resident in the memory area below 16M.
Obviously, this can cause severe problems such as memory conflicts, corruption, and fragmentation. This sort of fragmentation is not a gradual inconvenience, however, like the sort caused by the loading and unloading of NLMs. Symptoms of these problems can include not being able to mount large volumes, server errors saying Cache memory allocator out of available memory, and even server abends citing messages such as Invalid Request Returned NPutIOCTL.
Such problems occur because when the driver for a 16-bit SCSI adapter is loaded from the STARTUP.NCF file, memory is allocated from the top down, as is always the case with NetWare. The top, for this driver, is 16M. Once the driver is loaded, the SYS: volume is automatically mounted, and NetWare loads the volume's FAT and other media management information at the 16M mark, working its way down. Therefore, all the volume information for SYS:, and any other volume mounted afterward, must fit into the first 16M of RAM, along with DOS, the core NetWare OS code, the disk controller driver, and the driver buffers. As a result, NetWare might not be able to mount all the volumes installed in the serveróand even if all the volumes can be mounted, the Cache memory allocator out of available memory message may appear later because of this.
If, however, you must use a 16-bit adapter in a server with more than 16M of RAM, be sure to strictly follow the recommendations of the card's manufacturer. They might call for the inclusion of certain switches when loading the driver for the adapter (such as Adaptec's ABOVE16=Y parameter), but usually they involve preventing NetWare from automatically recognizing memory above the 16M mark with the following commands at the beginning of the server's STARTUP.NCF:
The first command prevents the adapter and its drivers from inadvertently writing to the memory above 16M as it is loading, by forcing the server to ignore the existence of any memory above 16M. After the drivers for the 16-bit adapter have been loaded, the REGISTER MEMORY command is used in the AUTOEXEC.NCF file to provide access to all the other memory installed in the server.
The second command reserves an area of RAM below 16M for the use of the adapter that cannot address higher memory. This prevents processes that can utilize any memory in the server from monopolizing the area below 16M. Access to the reserved memory is provided through the use of a special API call designed for this purpose. Other server modules which address the 16-bit adapter, such as tape backup software, may also make use of the reserved buffers, and their number may have to be increased as high as the maximum allowed, which is 200 for NetWare 3.11 and 300 for NetWare 3.12 or later. Both of these SET commands can only be issued from the STARTUP.NCF file.
This procedure might help to prevent memory corruption in some cases, but it does nothing to address the fragmentation that still can be caused by the initial loading of the driver at the 16M mark. One way to minimize this fragmentation is to load the driver without immediately mounting the SYS: volume. This is done by loading the driver from AUTOEXEC.NCF, rather than STARTUP.NCF. Since there is no disk access yet, however, an AUTOEXEC.NCF file must reside on the DOS device on which SERVER.EXE is loaded, and this AUTOEXEC.NCF must contain the commands naming the server and assigning its internal IPX number. Then, the disk driver can be loaded. When a NetWare disk driver is loaded from the AUTOEXEC.NCF file, the SYS: volume is not automatically mounted. The server's extra memory then can be registered, after which SYS: and any other volumes can be mounted. This procedure makes all the installed memory available to NetWare for storing the volumes' file allocation tables.
When using this technique, you might find it preferable to include only the commands necessary to the procedure in the AUTOEXEC.NCF file on the DOS drive. If the last line in this file is SYS:SYSTEM\AUTOEXEC, then NetWare proceeds to run the regular AUTOEXEC.NCF file on the SYS: volume, which can contain the rest of the commands necessary to make the server fully operational.
Include some commentary in these files to document what's being done. If the technique is successful, it might be a long time before you have reason to look at these files again!
***
Of course, this entire procedure can be circumvented if you simply use hardware that is intended for high-performance servers. Most host adapters that use EISA, MicroChannel, or PCI buses can address the memory above 16M without any of these machinations. It consistently amazes me that some people will spend many thousands of dollars on a server, but then skimp on a SCSI adapter to save $100.
Not all host adapters that use EISA, MicroChannel, or PCI buses can address memory above 16M. For example, the Adaptec AHA-1640 MCA SCSI card, despite using the MicroChannel bus, is a 16-bit adapter.
***
Although they obviously are important, none of the elements of the NetWare operating system discussed so far have the slightest value if there is no communication occurring with the network. For communication to occur, drivers for the LAN adapters installed in the server must be loaded and bound to a network protocol. Loading such drivers enables communication between the hardware and the Datalink layer interface, and binding the driver initiates communication with a suite of protocols, like IPX/SPX, AppleTalk, or TCP/IP. NetWare 3.x ships with LAN drivers for a number of popular NICs, but any card you buy these days is likely to ship with a more current version, which usually is preferable.
You can load the LAN drivers for the adapters installed in the server, and then can create AUTOEXEC.NCF entries to automate the process on subsequent server reboots, using the same process you used for loading disk drivers (refer to the "Creating a STARTUP.NCF File" section earlier in this chapter). The server console command LOAD followed by the driver nameówhich always has a LAN extensionócauses the user to be prompted for the parameters needed for the driver to properly address the card. After the entire LAN configuration process is complete, choose Create AUTOEXEC.NCF File from the System Options menu of INSTALL.NLM to cause all data entered at the console to be recalled and saved to an AUTOEXEC.NCF file in the SYS:SYSTEM directory.
The hardware parameters required when loading the driver (using LOAD) depend on the bus type of the hardware being used. The console prompts list all possible values for each parameter, and obviously the values entered must correspond to the hardware settings of the adapter card itself. Aside from the hardware-related settings, other parameters must be specified to allow proper communications with the network.
When multiple LAN adapters of the same type are installed in a single server, they must utilize different hardware parameters so that they can be distinguished by the operating system. NetWare allows each board to be given an identifying name, so that subsequent references to that board in the AUTOEXEC.NCF need not duplicate all the hardware parameters specified on the original LOAD line. This is done by including the NAME=board_name switch on the LAN driver LOAD line, where board_name is a unique identifying name of no more than 17 characters. This parameter is optional.
A frame type must be specified on the LOAD line for the LAN driver, in order to designate the precise configuration of the packet frames that are to be used when communicating over the network. The same frame type also must be specified at all workstations for proper communications to occur.
NetWare's open datalink interface (ODI), allows a tremendous amount of flexibility in the loading and configuration of network drivers, frame types, and protocols. Multiple frame types and multiple protocols can be configured for use on the same LAN adapter, or multiple adapters can be configured to each utilize a different frame type and protocol. The link support layer (LSL) handles this multiplexing of frames and protocols at the workstation, recognizing the nature of each packet received and directing it to the appropriate protocol stack. To exemplify the different capabilities of this interface, a single workstation can be allowed access to both IPX and TCP/IP services with one network connection; alternatively, two separate network segments, one devoted to TCP/IP and the other to IPX workstations, can access the same server simultaneously, through separate network adapters.
To load multiple frame types on a single LAN card, a second LOAD line is entered at the server console, with the same LAN driver specified. A Do you want to load another frame type for a previously loaded board? prompt appears. Responding Yes causes the user to be prompted for the additional frame type. Responding No causes prompts to appear that allow an additional adapter board of the same model to be configured.
While this parameter on ARCnet or Token Ring networks is easily configured, selecting the frame type (or types) to be used by a LAN adapter often causes a certain amount of confusion for Ethernet administrators, and rightly so. When studying the nature of the OSI model's Datalink layer on an Ethernet network (see chapter 7, "Major Network Types"), the IEEE 802.3 specification document is cited as the source of the frame type used by this layer. An 802.3 packet is shown as including the 802.2 frameóthat is, the Logical Link Control (LLC) frameówithin it when necessary. Then why are you being asked to choose between an 802.3 and an 802.2 frame type when loading a LAN driver? And what are Ethernet II and Ethernet SNAP?
You have every right to be confused, because the names specified as frame types here are not truly indicative of the structures they represent. In most casesóespecially on networks running no other protocol besides IPXóthe frame type selected is unimportant, as long as the same frame type is specified at the workstation and the server. The following sections, however, describe each of the possible Ethernet frame types, the ways in which they differ, and their various possible uses. The section headings display the frame types exactly as they should be entered on the LOAD line for the LAN driver.
The 802.3 frame type is the exact model of the packet defined in the IEEE 802.3 specification. For NetWare 3.x (up to version 3.11), this was the default. This frame type can be used on networks utilizing only NetWare's native IPX protocol suite. This is because the third field in the 802.3 packet, coming just after the source and destination addresses, contains only information defining the overall length of the packet. Other frame types utilize this field to indicate the network protocol for which the frame is intended. When delivered to the LSL at the workstation, there is no way to determine the protocol stack to which it should be delivered. There can, therefore, be only a single protocol used at the workstation when the 802.3 frame is used.
The 802.2 frame type, which is the default for NetWare versions 3.12 and 4.x, is the source of all the confusion described above. The IEEE 802.2 specification defines a frame that is used in the upper half of the Datalink layer of the OSI model. This frame encloses the data generated by the upper layers of the model, and in turn is enclosed by the IEEE 802.3 frame, operating at the lower half of the Datalink layer. The 802.2 frame type specified here, however, refers not to the IEEE 802.2 frame alone, but to the entire 802.3 packet, including the 802.2 frame within it. This frame type, therefore, is identical to the 802.3 frame type above, except for the inclusion of an IEEE 802.2 frame within its data field, which immediately follows the packet length field. The IEEE 802.2 portion of the packet provides LLC information as well as indications of the network protocol for which the packet is intended, thus rendering it usable on multi-protocol networks. This frame type is also required in order to use the NCP Packet Signature feature introduced in NetWare 3.12.
The Ethernet II frame type is defined in the second revision of the original DIX Ethernet specification, which was developed in parallel to the IEEE documents. Most of the time, what is referred to as Ethernet is actually the IEEE 802.3 specification. This frame is identical to the 802.3 frame, except that the third field, which is used to specify the length of the packet in 802.3, contains a frame type specifier in Ethernet II, indicating the protocol for which the packet is intended. This frame type is required for networks that will utilize the TCP/IP protocol suite.
Sub-Network Address Protocol (SNAP) is another means of providing protocol identification data with an IEEE 802.3 frame. Like IEEE 802.2, SNAP takes the form of an additional frame that is carried in the data field of an 802.3 packet. Originally conceived to transport IP datagrams within an 802.2 or 802.3 frame, the first three fields of a SNAP frameóproviding source and destination addresses, as well as control informationóare identical to those of an 802.2 frame, ensuring compatibility. The rest of the frame includes network protocol information, as well as a frame type indicator, like that of an Ethernet II frame. SNAP frames are now used, however, for purposes other than IP over Ethernet. The AppleTalk protocol is supported now, and a variation called TOKEN-RING_SNAP is provided for use on multi-protocol Token Ring networks.
Once the LAN driver for a network adapter has been loaded, the link between the Physical layer and the Datalink layer is in place. What remains is for the Datalink layer to be connected to the Network layer protocol which will be used to communicate with other stations on the network. This is called binding the driver to the protocol, and is done with the BIND internal server command. Each frame type specified for each LAN driver must be individually bound to a protocol for communications to begin.
At its simplest, this process consists of issuing a command at the server console prompt that says: BIND driver_name TO IPX NET=x, where driver_name is the name of the driver that has just been loaded (using LOAD), and x is the network address of the segment to which the adapter is connected. When multiple LAN adapters, frame types, or protocols are being used, however, parameters are included with the BIND command to specify the adapter, frame type, or protocol that is to be addressed. This is where the board name parameter (discussed earlier in the "Board Name" section) can be extremely helpful. Alternatively, the same LAN driver parameters used to identify these variables on the LOAD LAN driver line can be specified with the BIND command.
The default Network layer protocol for NetWare is its own native IPX, and nearly all NetWare servers bind this protocol to at least one driver. NET=x is the only protocol parameter that can be applied to IPX; this parameter indicates the address of the network segment that is being used for IPX communications. An existing segment already has a number assigned to it, and this number must match the number specified on the BIND line. A new segment takes as its network address whatever hexadecimal string is specified here. Each station attached to this segment must then be configured to use that address.
The IPX protocol is internal to the NetWare operating system, and therefore requires no other modules for its implementation. Other protocols such as TCP/IP and AppleTalk, however, are made available by the loading of other support NLMs on the server, after which they also can be bound to a LAN driver. Other protocols require different parameters to be specified for communications to be establishedóthese vary according to the protocol used.
What has been discussed so far as the simple act of binding a LAN driver to the IPX protocol is actually the initialization of access to the services of a suite of protocols operating at several different layers of the OSI model. All are carried within the Datalink layer frame type selected for use when loading the LAN driver, giving rise to some problems with terminology that require clarification at the outset.
As with the frame types outlined above, the structures used by the IPX protocol suite are sometimes referred to as "packets," in the sense that one might refer to an "IPX packet" or an "NCP packet." What is actually being discussed here is a frame of that particular type, carried within a packet. The packet itself, the basic unit of data that is transmitted over the network, is sometimes also called a datagram. The outermost frame of a packet may be based on the IEEE 802.3, 802.5, or Ethernet II specification (among others), and several different types may be used on the same network, but all the frames referred to with terms like 802.2 and SNAPóas well as IPX, SPX, and NetWare Core Protocol (NCP)órefer to additional frames carried within this outer frame.
For example, when a client workstation receives a requested file from a NetWare server over a network using a frame type of Ethernet 802.2, what really is being transmitted is the actual file data within an NCP frame, which is within an IPX frame, which is within an 802.2 frame, which is within an 802.3 frame. Each of these successive layers is needed to ensure that the data file is delivered to its destination process in a timely and error-free manner.
The file being transferred undergoes a series of different packaging and encoding processes for this purpose. First of all, unless it is a very small file, it is split into fragments that fit within the required packet size. These fragments may take different routes to their destination, and may arrive at different times or out of their original order. Information within the various frames provides the destination of the packets involved, not only in the form of a node address, but mentioning the specific process for which the included data is to be used. It provides a means for ensuring that the packet is delivered at the correct rate of speed, to avoid packet loss due to a destination interface that is overwhelmed with too much data. It provides a means by which receipt of the intact packets can be acknowledged to the sender. Finally, it provides the receiving station with information necessary to reassemble the pieces to form a coherent whole, and deliver this whole to the appropriate workstation process.
This description does not even take into account the entire process by which the binary data used by the computers at each end is encoded and decoded into electrical signals, pulses of light, or radio carrier waves for the actual transmission.
As you can see, this is a highly complex procedure, but I hope the entire concept has become more comprehensible thanks to splitting up the various levels of packaging. The form of the outer frame (the datagram), has been covered in chapter 7, "Major Network Types," and the basic conceptual organization of the OSI reference model has been examined in chapter 3, "The OSI Model: Bringing Order to Chaos." This section primarily covers the protocol frames that are used at the Network and Transport layers of the OSI model on a standard Novell network; we examine the structure as well as various uses of these protocols, which are usually referred to as the IPX/SPX protocol suite.
Although this protocol suite is the default in NetWare networks, and as a result is very widely used, by no means is it the only game in town. The TCP/IP protocol suite, the dominant protocol for Unix systems and the Internet, is a correlative to IPX/SPX, and is used more and more widely as an additional protocol over NetWare networks. There is a product named NetWare/IP that allows TCP/IP to be used as the primary NetWare protocol, replacing IPX/SPX entirely. AppleTalk is another protocol, used to provide connectivity for Macintosh machines. These alternative protocols are covered elsewhere in this book. The purpose of this section is to illustrate the functions for which the IPX/SPX protocol suite is used, and the basic manner in which IPX/SPX performs those functions. Once you understood these basics, other protocols are basically variations on a theme. They may have radically different names and definitions, but their functions are the same.
Continued...
