David Strom

NetWare 4.0 Shows Enterprising Promise, But Demands New Methods

By David Strom

Novell's NetWare 4.0 has been on the streets for six months now. After the initial hype has

faded, it is time for PC champions to give this product a closer look. Why? Because it is one

of the single products that will change the way corporate networks, and the applications that

run on them, will be built for the remainder of this century, and far into the next.

NetWare 4.0 could serve as the basis of corporate communications and application delivery

backbone for large and medium-sized businesses. Through the improvements that Novell has

made to the product such as an innovative implementation of a single enterprise-wise

directory structure, network security, and integration with Windows and Presentation

Manager, will serve corporate users well. 

Windows NT, Unix, and other LAN operating system wannabes don't measure up to NetWare

4.0: applications aren't as plentiful, enterprise-wide support will be more difficult, and none of

these other products can come close to NetWare 4.0 in terms of supporting a wide mixture of

client operating environments such as Macs, OS/2, and Unix. 

NetWare 4.0 is not for everyone. If your corporation currently owns less than five servers in

less than four locations, then stick with whatever networking gear you've got: NetWare 4.0

will be overkill. If you have strictly Windows clients, and you intend to leave character-mode

DOS applications in the dust, then you might want to consider what Microsoft has to offer

with its various NT and Windows for Workgroups products. If you can't afford to retrain your

network support staff to understand the new features and ways of doing business with

NetWare 4.0, or if you have more than 75 percent Macintosh clients, then stay with NetWare

3.x line. 

However, if you've got more servers in more cities and want to cut the size of your support

staff, then the product is worth a try.  The three biggest benefits of NetWare 4.0 are the

ability to run bigger networks with less resources, better integration with Windows clients,

and improved security if the product is used according to directions. Any one of these

benefits is reason alone to take a careful look at the product.

NetWare 4.0 is also a big departure from previous versions of NetWare. It looks at the

network as a single entity, rather than a collection of disparate servers and devices. It uses a

sophisticated directory services database, closely aligned with X.500 principles. It uses new

software on the client side as well, some of which can take advantage of graphical interfaces

to make network connections and administration much easier. And it builds in more

protection and security than anything Novell has ever done before.  When you add niceties

such as the ability to support 1,000 clients per server (first demonstrated at the spring Interop

show in Washington, DC.) and the ability to support a variety of languages other than English

(first pioneered by Banyan), Novell has made it possible to spread large LANs across the

globe on a scale that few others can match.

All of these changes means that implementing NetWare 4.0 won't be a cakewalk. The view of

the enterprise as a single network is foreign to many of you who have grown up on earlier

versions of NetWare that were focused on single servers. Indeed, the best advice we can give

to a NetWare 4.0 neophyte is to hire someone who has been trained by Banyan: they have the

necessary mindset, skills, and view of enterprise networking that will help you get over your

biases of server-centric Novell.

Upgrading to NetWare 4.0, particularly if you have a wide range of earlier Novell products

stretching back to NetWare 2.0, will be painful, although Novell has done a reasonably decent

job of explaining all the options. (NetWare 2.x level servers cannot be upgraded in a single

step to 4.0, for example.) You will need to spend lots of time before you even install the first

server in understanding the new features and how to implement them within your


Novell, Inc.

122 E 1700 South

Provo, UT 84606

800 453 1267

801 429 7000

801 429 5373 fax

5 users $1395

10 users $3,195

25 users $4695

50 users $6295

100 users $8795

250 users $15,695

500 users $26,395

1000 users $47,995


Dealing with Directories

The biggest difference between NetWare 4.0 and previous versions has to do with the way

servers and network resources are organized, what Novell calls NetWare Directory Service

(NDS). This is a completely new way of looking at NetWare.

In previous versions, you had a separate login identity to each NetWare server. If you wanted

to share files on three separate servers, you had to connect to each one individually. This

could get tiresome, particularly entering three passwords every time you needed to connect to

each server. It was tiresome as well for your network administrator to keep up to date, since

he or she had to connect to each server and maintain each account and file system on each

server separately as well. If you wanted to send your print jobs to another printer, you had to

type in the appropriate commands (keeping in mind the names of the print queues) or else

have your network administrator switch them for you. 

All of this information was kept in what Novell called its Bindery, which was essentially a

flat-file database. Each server had its own Bindery, and they didn't share any information. A

user could have supervisor access (someone who can administer the entire server, create

directories, and create and delete user accounts) in one server, and be just an ordinary user in

another server. Indeed, a user could have two different user names, which made things

confusing. Information such as printer names, print queues, the various sets of file directories

each user had access to, and the allowable login times for each user for that particular server

were all kept in the Bindery.

The only way to really maintain any consistency among the various servers was by human

intervention. All of that has changed. NDS has become the enterprise network police,

enforcing this consistency across all servers and network resources. 

With NDS, you see all network resources as a one-stop shop: you login once to the network,

not to any individual server. At login you connect to all of your network resources. No longer

do you have to seek out which server has what set of files or peripherals. If you want to

switch queues, you do so without having to know their names or with which servers the

queues are connected. NDS is essentially an enterprise-wide distributed directory of all

network resources: users, servers, printers, and other network peripherals. Gone forever is the

notion of a server-centric computing world. 

Novell uses the metaphor of a tree to explain NDS: you start out at the root and grow various

departmental branches from the main trunk of your enterprise, until you get to the leaves or

end-points of the directory, which are objects such as user identities and shared directories

and printers. However, figuring out how to structure your tree will take some time, and you

may not get it right the first time (which is fine -- indeed, NDS is designed to change to

mirror changes in organizational structure). 

How do you start?  First off, make sure your network names and numbers are unique, and

that your organization has a systematic way to assign new ones to ensure this uniqueness.

Without this structure, NDS will be useless. If you plan on mixing 3.x and 4.0 servers, this

means using both the new NDS graphical utilities as well as the trusted RCONSOLE and

SYSCON to check each server.

Second, you should have standard set of application names and means of access across the

enterprise. Again, it doesn't do much good to implement NDS if every server stores a copy of

Word in a different way. You can still implement NDS without these standards, but now is

the time to start this process and it helps tremendously down the road.

Finally, your tree design should make sense and be carefully thought out. We recommend that

you try a test design out for a few months among a small group of users until you gain

experience: you most likely will have to change the initial design. Your design should follow

either geographical divisions (such as having separate organizational units for each physical

office) or departmental divisions, or a combination of both.  Part of this planning process is

picking a structure so that all of the people in the New York sales office, for example can

have the same rights and access the same resources, to make things easier to administer. You

will also have to consider what portion of your users move about the company, and how they

will get access to network resources when they are away from home. NetWare 4.0 can take

care of these wandering users, provided the directory structure is set up properly.

There is more about NDS than we can reasonably go into here. The best treatment from

Novell is the April 1993 edition of NetWare Application Notes (a year's subscription costs

$95 and can be obtained by calling 800 377 4136). This is the most concise yet complete

explanation of NDS short of purchasing the NetWare 4.0 product itself.

Getting NDS right will require a great deal of up-front planning, and it could make NetWare

4.0 too costly for small organizations with only a few servers: the product is really designed

for businesses that have servers in many cities. It will take time to get this right.


Differences with VINES

At first blush, given its tree-structure and enterprise view of network services, NDS appears

to look alot like the features found in Banyan's VINES, or its incarnation for the Novell

world called Enterprise Networking Services (ENS). However, there are several distinguishing

features. In some sense, Novell has taken the original ideas from Banyan and expanded upon


-- Levels in the directory tree. Both ENS and VINES have three:

user@department@organization. NDS has unlimited levels, although beyond say six it will

get cumbersome to administer. Some organizations have been hampered by having only three,


-- Replication. The directory on any network partition can be replicated on any other. This

means some level of redundant operations if your "home" server is not operating, in that you

can still access network resources and do not have a single point of failure. Banyan has

read-only copies of the directory and a single server to login for each user; it is a distributed

directory but not a replicated one. 

While every in theory this means that every server can contain a complete replica of the rest

of the network, in practice you probably don't want to have more than a few copies

replicated. (The more replicas, the lower the performance.) Directory partitions are not to be

confused with disk partitions: the two are independent of each other. Deciding on how to

partition your network will also take some time, to ensure that users who move about the

enterprise can still login locally: the goal here is to reduce traffic across slower WAN links

by designing the partitions appropriately so that users can get authenticated from a local


Let's take an example. Assume your login identity in Vines is strom@edit@newyork. If the

server that handles the group edit@newyork goes down, then you and the rest of your group

can't connect to the network anymore. You have a single point of failure for the network.

This isn't the case with NDS.

-- 15 object types: volume, user, profile, printer, print queue, bindery, alias, computer, group,

etc. For NDS, everything is an object: a fax server, a conference room that gets scheduled,

and so forth. These object types are also extensible, so application developers can create their

own objects and add new items to existing objects. Banyan has only six object types that are

not extensible.

Like any good database, there is a great deal of information that can be entered for each

object type. For example, each user object has login name, password, telephone number, fax

number, office location, and so forth. This means that you can view details about your entire

corporation at a glance. Of course, this also means that you or your network administrator

will have to spend time setting things up, although Novell has made matters somewhat easier

by providing lots of default templates for various user and other common object profiles.

-- limited resource groupings. With Banyan, each group must reside on a single server. In

NDS, groups can be any collection of objects across the network.

Overall, NDS is more flexible and more reliable than the equivalent functions in either

VINES or ENS. But Banyan isn't standing still. Extensions to its Street Talk naming service

will include 

New and Improved Security, Protection and Auditing

One of the biggest reasons to consider NetWare 4.0 is the improvements Novell has made to

the security and memory protection areas of the product. Of course, any security features are

useless unless your network administrator enables them and follows the guidelines to maintain

them: for example, it doesn't help overall security if every user has the option of not using a

password at login time. There are other options, which aren't new to NetWare 4.0 but should

be considered: forcing periodic password changes, enforcing a minimum number of characters

for a password, and preventing users from alternating between several passwords.  We

strongly recommend that any NetWare 4.0 installation use all of these security features. 

The new security features cover several areas: workstation security, file server security, and

multitasking application protection. In combination with the ones that exist for the 3.x line,

they provide for something akin to mainframe quality security for the LAN. 

There are two added features to workstation security beyond what was already available in

NetWare 3.x. They are: 

-- The ability to restrict logins to specific Macintosh network addresses (previously, these

restrictions only applied to DOS and OS/2 network addresses). This is helpful, particularly for

those organizations that want to tie particular users to particular computers: now it can be

done for most of the clients supported by NetWare.

-- RSA crypto keys for login. RSA stands for the three gentlemen that founded one of the

most popular cryptographic systems: Rivest, Shamir, and Adelman. Previous versions of

NetWare sent the password over the wire in clear text, making your login insecure for anyone

with a network analyzer who happened to be listening in at that moment. NetWare 4.0

encrypts this process, making snooping almost impossible. Why almost? If you tell others

your password, or choose something easy to guess (your spouse's name, your birthday), all

the security features are useless.  

There are also several enhancements to both network and file server security:

-- The concept of a network auditor.  New to NetWare 4.0 is the concept of a network

auditor. This is someone that independent of the supervisor or network administrator can keep

track of important events on the network, such as each time a particular user logs into the

network, or requests particular network services. Corporations like having a second person in

charge of auditing: it makes it harder for errant employees to get away with something that

they shouldn't be doing (unless of course the two cooperate). All of the auditing features are

implemented with a DOS-only command line AUDITCON, no graphical utilities are yet


Given that this is the first instance of auditing with NetWare, it is a bit clumsy to use and

will take some training to understand how to make the best use of it. But give Novell an A

for effort here: this is something that LANs have lacked and need to have to be serious

contenders in the mainframe replacement market. 

-- Transaction logs can be filtered, for easy viewing of critical events. Before, a network

manager had to sift through the entire log, which was a cumbersome process that few would

attempt. Now you can focus on particular events. 

-- Remote console session security (password encrypt and callback). Previously, security for

the remote console (in other words, operating the file server from a network workstation or

over a phone line) was minimal: anyone with access to the SYS:SYSTEM directory could

figure the password quickly. New to NetWare 4.0 is the ability to encrypt the remote console

password, and indeed to go a step further and have the server call an administrator back at a

pre-set phone number. 

-- Running NLMs in protected mode.  Microsoft has long made hay about the fact that any

errant NetWare Loadable Module (NLM, the actual server-based applications such as fax

servers, protocol interpreters, and the like) can shut servers down, and we've seen rare

instances where it has happened  --  such as an NLM that we copied from a commercial disk

that was corrupted somehow and brought the entire server down when it was loaded.  With

NetWare 4.0, this is no longer as worrisome, since network administrators can set up a fence

around whatever NLMs you want, what Novell calls a protected domain.  However, not all

NLMs will run in protected mode, and still the best advice we can give is to have a separate

test server for anything new that you want to add. 

The reason why Microsoft has made so much noise about misbehaving NLMs is because NT's

(and for that matter OS/2's) server-based processes can run above the kernel layer of the

operating system. However, this is somewhat misleading, since any kernel-based process that

misbehaves can also bring the entire machine down, as we have experienced with both

products on rare occasion. 

Is this important for users? Not really. Network administrators will figure out which NLMs

will run in which domains. However, we are glad Novell has addressed this issue.

Changes in the NetWare Client

Despite these changes in the directory and security services, the most important and most

noticeable changes for any user are what Novell has done to each NetWare 4.0 client. These

clients, by the way, can be installed separately from the NetWare 4.0 server side: they will

work just fine connecting to earlier 3.x and even 2.x servers, and many corporations have

begun the upgrade process to 4.0 by first installing all new client software throughout their


The client changes are in several areas: configuration, user interface, and network

administration. Let's look at each.

First is configuration. By that we mean the way that CONFIG.SYS and batch files load

various network drivers, and how NetWare interacts with DOS, Windows, and OS/2. On the

DOS and Windows side, NetWare 4.0 clients are very different from previous versions.

Many of you are used to loading just two commands to connect to a NetWare server: IPX

and NETX. They are replaced with several new files:

     -- a series of Open Data Link (ODI) drivers, which Novell used as an option in

previous versions but is now mandatory in NetWare 4.0 if you want full directory services

and secure authentication,

     -- changes to CONFIG.SYS for DOS and Windows

     -- new DLLs and other OS/2 and Windows-software,

     -- a new client software called virtual loadable modules or VLMs that replace NETX. 

ODI. The old IPX drivers will still work with NetWare 4.0 servers, but only under bindery

emulation mode. That means that if you want to access any of the directory services

functions, you'll have to upgrade, and the first step is to switch to the newer ODI-style


Why bother, apart from the fact that the older stuff will eventually become obsolete and you

won't be able to get any benefits from NetWare 4.0? Three reasons: First, ODI allows you to

run multiple protocols and frame types over a single adapter. Want to connect to both

NetWare and Unix workstations? No problem. (Speaking of frame types, Ethernet has four

different ones for example, depending on whether you connect to minicomputers, Unix

workstations, Appleshare servers, or NetWare. New to NetWare 4.0 is to default to the 802.2

frame type, although NetWare 4.0 servers can speak all types to whatever client requires, as

did NetWare 3.x.) 

Second, ODI comes as part of the package. Novell has shipped over 150 different ones right

on the same CD and disks that come with the 4.0 product: previous versions of NetWare had

many fewer, and usually required a trip to Compuserve to download the latest ones anyway.

Since they are readily available with the basic NetWare 4.0 package, it is easier to use and

find them. 

Third, ODI drivers are easier to configure and administer, keeping costs down for distributed

networks. The older IPX drivers required the network administrator to set up each driver

depending on the particulars of the card. These are a thing of the past: network administrators

only need to change a single adapter driver depending on what is installed in the workstation,

rather than recreate a new IPX file for every card configuration. This configuration

information is stored in a file called NET.CFG and includes what frame types you want to

use , what should be the first network drive letter (typically, most people use "F:"), and other

arcana such as your machine's TCP/IP address and interrupts and I/O addresses.

Here how ODI works. Instead of loading IPX, you type three commands: LSL, the adapter

driver, and IPXODI. Each of these three files gets additional information from NET.CFG. 

CONFIG.SYS. You'll need to edit your CONFIG.SYS file, and place a LASTDRIVE=Z

command inside it. This is new to NetWare 4.0, and a minor but necessary condition to use

the new DOS and Windows clients and be able to use any search drive mappings (that's

Novell lingo for setting up a path to various file server directories). 

WINDOWS. Novell has done even more work integrating NetWare into Windows, and you'll

need a series of new DLLs and other files to support the NetWare 4.0 servers. All of this is

handled automatically by the NetWare 4.0 Windows client install software, including updating

the various .INI files and putting the files in the right places inside your Windows

subdirectories. That is, it is handled automatically provided you have a copy of Windows on

your local hard drive. If you run Windows from the network, you will first have to copy the

files that the installer puts into C:\WINDOWS\SYSTEM into wherever your system files are

stored on your network.  Novell is working on fixing this, and may have done so by the time

you already read this. [TK: CHECK]

In addition, the new Windows client gives you an option to either load before Windows or

during Windows: the previous 3.x client had to be loaded before starting Windows. 


VLMS. The final part of the quartet of enhancements is the VLM driver set. Basically, what

once was a "shell" software called NETX, a TSR that ran under DOS, is replaced with a new

series of software modules called the DOS Requestor and most visibly noted with VLMs.

There is an overall manager, called VLM.EXE, which loads a whole series of other files,

depending on what you have specified in NET.CFG.  Different software, although the same

VLM architecture, is available for OS/2.

To give you an example of the modularity of VLMs, consider one called AUTO.VLM. When

this module is loaded, anytime a client connection is lost, then reconnected, NetWare will

rebuild the environment to the state prior to the loss of the connection. And the price of this

feature? An extra kilobyte of RAM required. It will only work with 4.0 servers and the

default is not to install it.

VLMs support up to nine printer attachments, provided you connect to a NetWare 4.0 server. 

The previous versions of NetWare clients supported up to three.   

MEMORY and PERFORMANCE. You would think with all these changes that the NetWare

client takes up much more memory, but not necessarily so. Actual mileage can vary

tremendously, and depend on what memory managers are available and how you have

configured your VLMs. Some guidelines are that the client could take anywhere from 10

kilobytes less RAM to 20 kilobytes more, when compared to NetWare 3.x ODI drivers. 

GRAPHICAL UTILITIES. All of this plumbing is geared at making administering a large,

distributed network easier and more reliable. But this is just the first stage of client

improvement with Novell. The most visible changes to any user of NetWare 4.0 is a set of

new graphical utilities to help make things easier for users to gain access to network

resources. And, for the DOS character-mode diehards, there is even new client software for

them as well. The programs are called NWUSER (Windows), NETUSER (DOS), and

NWTOOLS (for OS/2). Macintosh clients will get their own software by the time you read

this according to Novell but they will be only able to access the NetWare 4.0 server under

bindery emulation and not be fully directory aware.

The graphical utilities augment, rather than replace, the traditional NetWare command line

utilities of CAPTURE, FILER, MAP, FLAG, and their brethern. Using these utilities makes

assigning a drive to a network directory or printer easy: you point and click until you find the

appropriate directory (or printer) then you drag the icon for the directory over to the drive

letter (or device) of your choice. You can change your password, again by filling in boxes on

a simple dialog box. There is one restriction we've uncovered: path names can't be any longer

than 64 characters in total, so if you have some long ones you'll have to use the MAP

command outside of the graphical utilities. 

Indeed, Novell has greatly reduced the number of utilities with 4.0: down from approximately

130 different ones in 3.11 to about 50 in 4.0. It is a welcome consolidation, although for old

Novell hands it will take some getting used to locating where the new commands are now


If you wanted to change options for your printer, for example to print a banner page or do a

form feed or whatever, again, it is a simple series of mouse clicks and you are done. No more

learning the syntax of  MAP, SETPASS, or CAPTURE commands.  You can still use these

and all the other NetWare command line utilities, depending on your own inclinations, but the

new graphical utilities will handle most of the day to day activities. 

The final piece of client improvement deals with network administration. Previously, there

was a set of DOS character-mode utilities that administered NetWare servers: SYSCON,

PCONSOLE, and the like. Now Novell has put together new ones: NETADMIN for DOS or

NWADMIN for Windows and OS/2 machines. You'll need at least 6 Mb and 12 Mb of RAM

for Windows and OS/2, respectively, to run these utilities.

They build on the drop and click metaphor used in the end user utilities, and make moving

about the directory tree and assigning aliases and other administrative chores much easier than

in the days of running SYSCON and operating on each server individually. This will take the

most relearning for those network administrators who have taught themselves all the various

quirks of SYSCON -- but by the time you've built your tree several times (after many fits and

starts), you should be able to get the hang of the new graphical utilities.

Managing Storage

But new client software is not the only significant change to NetWare 4.0. Another important

feature has to do with how NetWare handles file storage. Novell has anticipated the need for

storing more than just spreadsheets and documents on its servers: desktop publishing, video

images, multimedia presentations, and other applications will require a new series of storage

devices for your networks. Why? Data storage for these types of applications can change

quickly and in big increments: a presentation can be created overnight and can occupy tens or

hundreds of megabytes of disk space. Once it is finished, these files may not be touched by

any user for many months -- in the meantime, it makes sense to move that data to a less

expensive parking spot, and free up those megabytes for other active applications.

To make things easier for you, the end user, network administrators will have to get more

involved in managing your storage needs: understanding the ebb and flow of the user data,

balancing between expensive and quick magnetic disks and slower but cheaper alternatives.

The added complexity of the network is offset by the savings realized in storage devices. If

your business is getting more involved in these kinds of applications, you should investigate

the benefits of NetWare 4.0's storage management features. 

There are several aspects to NetWare 4.0's storage management, ranging from disk

compression to data migration. 

First up is compression-on-the-fly. That means that the NetWare server itself takes care of

uncompressing your files at the time you access them on your server, and compressing them

after the file is closed. (Files stored on your own local hard disks of course are not handled

by NetWare's compression algorithms but by your desktop's operating system.) All of this is

done without you having to change anything -- it happens automatically and quickly, too.

This is the first server-based compression algorithms to ship: Neither earlier versions of

NetWare nor NT offers any form of compression built-in to the LAN operating system.

Novell states that compression can save more than 60 percent of space on average. This

means if you have filled up your server's 1 gigabyte disk, you will free up 600 megabytes of

space after you turn on compression. Actual mileage will vary tremendously, given some

preliminary research by ZD Labs. They took a variety of data files from various applications

and found that up to 90% of the space was reclaimed by compression, particularly

multimegabyte database files. A total of nine files that occupied over 17 megabytes were

compressed to less than 2 megabytes. This has powerful consequences for businesses that are

running out of storage space on their servers, and especially for servers that contain lots of

databases and documents that lend themselves towards compression. For example, prices for

external SCSI hard disks range from $1 to $2 per megabyte, so the return on this feature can

add up to several thousands of dollars across an enterprise.

You would think that compressed files would take more time to open up by an application,

given that NetWare has to first uncompress them. However, the reality is that in most cases,

opening compressed data files doesn't take any additional time. Most applications only open a

small part of a large file anyway: for example, database applications only read in the indexes

and the first few records, even for files that are megabytes in size. This means that the time

involved in uncompressing the relatively small amount of data that the application has to

initially access is imperceptible by the user compared to the time involved in accessing an

uncompressed file.

The biggest differences in file open times would be for spreadsheets and graphics

applications. In these situations, often the entire file is loaded into memory. We asked ZD

Labs to open a 1 megabyte Excel spreadsheet both compressed and uncompressed. The

compressed spreadsheet took 18 seconds to open while the uncompressed spreadsheet 14.5


Every NetWare 4.0 server volume has the ability to automatically compress files -- indeed,

this is the default setting when the server is installed. But this doesn't mean that every volume

and every file on the server has to be compressed, or even that every file will be compressed.

You can select which directories and files should be candidates for compression if you are

uncomfortable about maintaining the data integrity for these directories, evidence of the

compression's reliability to the contrary.  

There are two types of compression: one that occurs immediately, when a user designates a

particular file be compressed, and one that occurs in the background, when the server itself

decides. Both have a variety of parameters and options:

Users (or network administrators) can set their own compression routines via several

mechanisms: the FLAG command, through the FILER utility, or through the Windows and

OS/2-based NWADMIN utilities. Here there are two options: immediately compress  (option

IC) or don't compress (option DC). For example, to set all files in the user directory

SYS:DATA\STROM to immediately compress, you would type in the following DOS or OS/2



What happens if the network administrator has enabled compression for the entire volume,

and you want to change that for your files? You can do so, with any of the above commands.

The second option is to have the network server search through its own files at a designated

time and do the compression automatically. (The default parameters are for this searching to

take place from midnight to 6:00 am.) An alternative is to search for files that haven't been

touched for a certain number of days (the default is seven days) and then do the compression.

In either case, the compression happens in the background and is the lowest priority task that

the server tends to. This means that if there are spare CPU cycles left over from everything

else the server is doing, then it will attempt to perform compression. So the time invested in

compression is purely a server function, and shouldn't effect the overall performance that a

network user sees at all, at least from what we can see with our preliminary tests.




NetWare 4.0 is actually very smart about its compression algorithms: it does a test calculation

before compression takes place: if no significant space will be saved by the compression

activity, it doesn't perform the operation. What amount is significant? That's up to your

network administrator, who has to set the parameter for each server (the default is two


There are some other considerations to compression, however: changes in the relative time in

file access, reliability, and how compression interacts with tape backups.

What about reliability? Although we haven't been running NetWare 4.0 for very long in either

our labs or our offices, we can state that we haven't had any problems with compression

corrupting files. What if a server is powered down or a disk drive crashes during the

compression? Novell has thought this through: the original file is not touched until the

compression routine is completed and checked for errors.

A third concern has to do with the interaction of the compression and tape backup routines.

Unfortunately, you can't run both concurrently: the compression should be completed before

any automated backup operations begin. That's a limitation of the way that Novell has

designed NetWare 4.0. Novell recommends that any compression take place two hours before

the backup cycle, which could affect your operations if you use the network at the off-hours

that these operations are taking place.  The reason for the two hours is to give the

compression routines time to complete their activities before beginning the backup.

Even given these concerns, compression is a good idea: you save on disk space with little

impact on overall real-time use, and unlike the compression features in DOS, most of it can

be managed without much intervention by the user. It doesn't cost anything, in terms of time,

extra software options, and indeed it can save a few thousand dollars in the long haul by

deferring disk storage purchases.

But compression is just one of three important tools for managing network storage.  The 

others include migrating data from magnetic to optical devices and dynamic allocation of

block sizes.

Data migration means that files that haven't been accessed for a specific amount of time get

moved to less expensive (per megabyte, that is) storage devices such as an optical disk or

tape drive, keeping a pointer on the hard disk showing the way. When a user wants access,

the data is brought back to the magnetic disk. The migration works in conjunction with a new

file system, called High Capacity Storage System or HCSS. This file system uses the same

commands as NetWare to manage its storage. Files and directories look the same under this

file system as they do under whatever client operating system you are using, provided you are

using DOS. Currently, HCSS does not support migrating either OS/2 HPFS or Macintosh


Current devices that support HCSS include Hewlett Packard's C17xx optical jukebox, and

SCSI devices that are attached to the server via one of Adaptec's host adapters. Novell is

testing at least three others that might be out by the time you read this. 

Migration happens to each individual file according to the last time it was accessed by an

application. You can set various parameters, such as the time of day when files migrate (the

default is 1:00 am) and when to start and stop migrating based on how full your magnetic

disk is (the defaults are migration starts with less than 10 percent free space remaining on a

drive, and stops when there is more than 40 percent free space available). And, you can keep

certain files from migrating, such as your NetWare executables or your three most popular

databases. All that is required is a command choice (via the "DM" option in FLAG or the

equivalent graphical utilities).

This is still the beginning for this feature for Novell. The limited number of devices and file

systems that are supported show that it has a long way to go. Nevertheless, migration gives

network administrators powerful controls over managing their storage. 

But it would be useless if another feature, called block size length, remained the same from

version 3.x. In previous versions of NetWare, files were stored with fixed block lengths, with

the length decided at the time the server's volume was installed. Say you store a file that is 10

kilobytes on a server with 4 kilobyte blocks (the usual choice). Your file took up 3 blocks,

and wasted 2 kilobytes of space. Choosing a fixed block size meant that network

administrators would have to guess as to the type of files that would ultimately be contained

on their servers: guess too high, and they got lots of wasted space and lower overall storage

capacity; guess too low, and their server is spending lots of time storing small chuncks of


NetWare 4.0 has changed this guessing game, making things better for network

administrators. It works more efficiently and works with larger block sizes than previous

versions, carving up any partially unused blocks into 512 byte pieces that share the leftover

parts of files. In our example above, the 10 kilobyte file would take up two 4 kilobyte blocks

and four 512 byte pieces, leaving no wasted space. 

NetWare 4.0 determines the default block size based on the size of disk storage and how

much memory your server has. [MARTY: THAT's JUST THE WAY THEY DO IT. SOME


memory required is directly proportional to the block size, but the larger the block size the

faster your files will move from the disk to your workstation.

Other features

There is much more in this product than we have mentioned: a complete Asymetrix-based

Toolbook courseware to give you a broad overview of the product is available on the same

CD that comes with the product, for example. All of the manuals have been put on-line in a

format called Electro Text, which unlike earlier Folio-based help system is actually quite

usable, and visually is equivalent to the printed documentation. We liked the electronic

version because of how easy it was to search for particular terms in the entire set of manuals,

which we could then browse electronically or go to our paper copies. (Paper is an extra

charge, by the way.) 

The Future

Novell isn't standing still, as you can imagine. They are hard at work on bringing complete

System Fault Tolerance level 3 to NetWare 4.0: this is the feature that two separate servers

work together, so that if one goes down the other continues, users don't see any interruption.

Novell won't have SFT3 ready for NetWare 4.0 (it is currently shipping for 3.x servers) until

later this year. Also expect more improvements in the non-DOS client arena, and continued

work by the hundreds of third-party vendors to incorporate the NDS features into their own

products that previously were Bindery-aware, such as fax and print servers and network

management utilities.

Who Should Buy NetWare 4.0?  (box or sidebar)

Strongly consider purchase now if you have: 

-- more than four servers in more than two locations

-- more than 2 gigabytes of total storage on your file server now

-- have more than 600 users 

Steer clear from NetWare 4.0 if you have:

-- greater than 75 percent of your clients are Macintoshes

-- a single server in a single location 

-- have VINES and are happy with your support and setup

Click here to return to the previous page

David Strom David Strom Port Washington, NY 11050 USA US TEL: 1 (516) 944-3407