9(1), November 1992, pages 63-75

Userhome, Sweet Home:
A Review of Novell's NETWARE

Marcia Curtis and Charles Moran

For reasons of economy and pedagogy, most computer-equipped writing classrooms installed in the 1990s will be networked. And the most popular and widely available networking software in this decade is Novell's NETWARE. Most writing teachers working in networked environments will, therefore, encounter this networking platform. Our experience with this particular networking software has been generally positive. That will be the tenor of this review. Yet, through our review will run a thread of argument: That it is important to know and understand the networking software that we do use. If we don't, then we don't know how to manage and configure our own networks, and we therefore turn over to technicians much of the power that we ought to have ourselves as teachers. If we can't use NETWARE, we will not be able to design the "virtual environment" of the networked classroom in ways that suit our pedagogical goals.

It is important for the reader to know that neither of the authors is a techno-groupie; indeed, when we first were introduced to NETWARE, we did not even know how to function in DOS. We are not, even now, five years into our experience, technicians. We are DOS-whizzes, and we are NETWARE literate, but we are still writing teachers, members of a Writing Program staff committed to a view of the student as a writer, a person actively creating meaning in a social context. We offer this review of NETWARE, therefore, as the "story" of how two English teachers came to grips with this particular brand of networking software. We can't do a comparative review that suggests that NETWARE is better or worse in particular respects than, say, Banyan VINES. What we can do is tell you about our experiences, as English teachers of a particular pedagogical persuasion, with this particular networking platform.

Living with NETWARE

Generally speaking, we are happy with our choice of NETWARE. As teachers in a highly student-centered writing program, one depending heavily upon such interstudent activities as peer review and the compilation or "publication" of student texts, we had found our original computer-equipped classrooms, equipped with nonnetworked computers, a frustrating environment to work in. The stand-alone computers did not encourage the sort of interstudent communication and collaborative processes our particular pedagogy required. So the networked classroom was tremendously liberating for us. It has become the site of cooperative and collaborative interaction.

In imagining a networked classroom, we wanted an open system, one that would let students transmit pieces of writing to one another and otherwise communicate in writing with one another easily Ideally, we imagined our students engaged in peer review and even collaborative writing through the system. We wanted a system that would support a whole learning environment, as opposed to a writing "laboratory" of individualized practice and instruction. What we did not want was a system that would encourage direct teacher intervention in the students' writing processes or centrally initiated, uniform drill sessions (both of which are achievable through a variety of software packages).

Some of our early imaginings--such as simultaneous collaboration on a single document--have remained unrealizable, on NETWARE or any affordable, manageable system. Others--such as full-group, simultaneous, on-line discussion of a single on-line document--remain cumbersome, burdened by the limitations of our chosen configuration and of our teachers' skills at manipulating it. On the other hand, the system has admitted and encouraged the development of interactions--between the teacher and students as well as among students--we had not originally envisioned.

The Novell software easily handles the traffic generated by 44 workstations and four printers divided between our two computerized classrooms; it easily accommodates our eighteen scheduled sections of first-year writing, as well as open-use evening hours available to current enrollees and "alums." In addition, we have connected to the network two workstations and a printer housed in a central office designed for teacher and network monitor use, and we have connected to the network three workstations located in remote faculty offices. So the full system--50 workstations and five printers--serves some 400 new users per semester and a host of alums who have permission to use the facility.

Technical Profile

This network is managed by Novell NETWARE version 2.15, running on a file server. Initially, we used a single 386/20 file server with a 150 MB hard disk. This arrangement was, and still is, more than sufficient for network management, but it was not sufficient for printer support. Because NETWARE 2.15 supports only three printers directly, we had to connect some of our printers to print servers, workstations partially dedicated to handling the print jobs generated by our users. This print server arrangement introduced another level of complexity: Now, we had to manage the print server software as well as NETWARE. Further, if a print server went down, and, as inexpensive work stations, they often did, then the printers in a classroom were disabled.

To simplify the system, we added a second file server, a 386/16 machine, running an earlier version of NETWARE. We connected the servers with a "bridge" so that they are, in effect, one system. The principal server manages the network and serves two printers; the second server carries an emergency system that we can use as a temporary backup, and it serves the remaining three printers. This second server also carries some sizable research-supporting software packages for faculty and staff use.

For normal teaching purposes, we don't ask the network to do anything terribly exotic. On our primary system, we have some software, but not much, and thousands of text files, none of which takes up a great deal of room. The software we do have consists of our word-processing package, Microsoft WORD; the Daedalus chat program INTERCHANGE for on-line class discussion; an e-mail program for communication among teachers; virus-scanning software; and a low-rent desktop publishing program; two programs that translate text from one word-processing format to another (for teachers and students with different DOS-based word-processing programs); and a relatively primitive menuing program from which teachers and students can choose these options. Teachers can choose the additional option of entering the DOS environment directly.

All this the Novell software handles stress without evident strain. If we were doing serious desktop publishing, downloading soft fonts, or if we were accessing and downloading huge files of data, we might feel the stress. But for what we do in our first-year writing classes--calling up WORD or another application from the file server and sending it to a workstation, retrieving document files, or even conducting two simultaneous full-class INTERCHANGE discussions--the network is more than enough. The Novell utility "FConsole" permits us to see how heavily our system is being taxed. When students are logging on, or when they are loading the word-processing program, the system is, just for a split second, utilized at 30% to 40% of its capacity, but after that micro-burst of usage, it settles down to its normal situation, working at 2% to 5% of its capacity. If both classrooms are conducting separate full-class INTERCHANGE sessions, the system may reach 20% to 25% of capacity.

The speed of the Novell software is in part the result of its caching system, which remembers the most often requested files and keeps them in random access memory (RAM). Accessing a file from RAM is faster than accessing it from the hard disk. Our main file server has 4 MB of RAM (nothing, really, these days), about 3 MB of which is used by the Novell system as a cache. The "FConsole" utility tells us that over the semester, 98% of the requests for files have been answered from the cache. This accounts for what seems to us to be the network's blinding speed. The workstations are 286 machines with 640K of memory---not, themselves, particularly fast, by today's standards, but more than sufficient for our purposes. Each workstation has two floppy drives, one for the Novell software required to boot the system at log-on, and another for the students' own disk. So all the software is stored on the file server. Yet the software appears at the workstations almost instantaneously, even when it is called up simultaneously by an entire class.

The direct effect of the network's speed on teaching is that it permits us to work in what often seems a "virtual classroom;" students and teachers can roam through their designated part of the system, calling up and saving files quickly, not seeming to wait for the arrival of the text or the clearing of the screen. Depending largely on the teacher's own inclination and ease with computing, nearly all class work can be done on-line. Consequently, students do much more writing than before. Class discussions can now proceed on-line, using the written word; peer editing can be done any time, as the designated editors can call up the author's file during class or at other times when the classrooms function as open labs for the students enrolled in the course, and we can leave on-screen messages for our classes, so that they can come in and do their work whenever they want to. Increasingly, we and our students store our writing on the system, and there is room for it all on the 150 MB hard disk. At present, we have 18 sections of 20 students working in these classrooms, each for four class hours per week. At the moment we write this review, close to the end of our semester, there are 12,674 files on the system, occupying 129,858,856 bytes of disk space. There is room for another 16,965,632 bytes, and there are 2,430 available "file handles," or directory entries. As we become more used to the system, we are keeping more of the semester's work on-line. Somewhere in our future, therefore, is a larger hard disk.

Growing Our Own Virtual Landscape

Our system is distinguished from other systems we've seen by the fact that it's ours and reflects our program's principles and pedagogy. The network has been made to support a "virtual locus" or, more rightly, a landscape of "virtual loci" of writing activity in all its various forms: composing, peer exchange, revising, and publishing. We chose not to outfit our network with commercially produced instructional software. Instead, we designed our system to be an instructional environment, a background against which student writing and the writing process could be foregrounded, just as they are in our nonelectronic classrooms. And we chose not to purchase a shell program that would itself manage the network software. These programs exist, certainly, yet we felt that by purchasing a program such as Daedalus' NET MANAGER we would lose control, would be forced to incorporate choices in our virtual classrooms that perhaps, as teachers, we would not make. Ease of use would require that we forfeit our ability to configure the system as we and our teachers wanted it. This seemed to us not an acceptable trade. So our system, as it has evolved, is ours---low-tech, and without glitz.

When we purchased the network five years ago, it was our good fortune that the technician who installed it for us was the son of two teachers. We two were English teachers, not computer specialists. Our previous experience with the closed architecture of Digital Decmates left us ignorant of DOS; having worked with floppy disks, not hard drives, the "space" of a subdirectory structure was alien to us. Yet, the Novell technician was able to listen to our imaginings and approximate on the network structure the rudimentary class structures we envisioned. His original configuration provided each class with its own private niche in the system, that is, with its own private directory or, in Novell-speak, userhome. Within each class' userhome, he created three subdirectories, labeled, without mnemonic reference to pedagogical use, Box1, Box2, and Box3.

The subdirectories were all equally open to student and teacher use, and therefore were all nonshareable: That is, documents saved to these various "boxes" were by default given the DOS attribute--in Novell parlance the flag--"nonshareable read write," meaning that students or teachers could edit the documents, but just one user at a time could view a given file. There was no menu system: While logging in, students were "mapped"--assigned paths--to their userhome and respective boxes, and sent directly into Microsoft WORD by a set batch file; teachers were sent into DOS. Nor was there any sort of e-mail system by which teachers could communicate with one another: Through a general, one-screen length "Prof News" we who were to manage the system could transmit brief messages to teachers, but there was nothing comparable by which teachers could communicate with one another or with their students. Our first settlement in the virtual landscape was downright spare. But the foundation was set for the environment that has since developed.

During the five-day training period we had purchased along with the network, the technician also managed to teach us the series of DOS commands--really a pidgin mix of DOS and Novell language--necessary to create and delete documents and to flag them "shareable read only" for peer-review and full-group sharing. And for the first semester, we knew little else. What we did know, we passed on to the eight graduate student instructors who, along with us, would be teaching computer-based courses. And the 10 of us spent that first semester chiefly learning the system.

Some naturally learned more and learned it more quickly than others. Many had difficulty mastering the DOS/Novell command sequences necessary for keeping house in their userhomes, which grew increasingly, at times overwhelmingly, cluttered with old document files; many found the command sequences for reflagging documents and directories for peer sharing too complicated to execute while their classes were running, and, abandoning the computers altogether, returned to traditional hard-copy readings. For these teachers, the network complex had effectively devolved into a simple collection of stand-alone PCs.

The need to modify our original configuration was clear. Having watched the Novell technician install the network and having worked with him to perform some of the more simple, repetitive tasks, we began to tinker with the few files and functions we knew. Through the NETWARE "Syscon" utility, which the technician and we had used to establish the original userhomes, we added individual "Class News" files similar to the teachers' "Prof News," enabling teachers to communicate each day's events or assignments to their classes quickly and easily through the system. And we wrote the more cumbersome command sequences in automatically executed batch files, which teachers could activate by one simple command. So, for instance, by entering News Class1 at any DOS prompt, an instructor might set in motion News.Bat:

By doing so, she would automatically, invisibly, and almost instantly move to the system's N:\News directory; flag her own Class1's N:\News file "nonshareable read write," thus readying it for editing; load the document into WORD; then, upon quitting WORD, save and reflag the document "shareable read only" for multiple-student access.

Over time, we wrote dozens such batch files, some meant to help teachers access specific files such as the N:\News through WORD, but most designed to make the seemingly unconquerable flagging and document deleting processes possible. They ranged from the simple Flagall.Bat for flagging a single subdirectory "shareable read only,"

to those reminiscent of a Rube Goldberg sketch, like Empty.Bat, for afterward, deleting read-only documents from that same subdirectory:

Later, however, as some teachers' discomfort still persisted, we discovered that the same "Syscon" utility permitted us to create additional subdirectories as well as assign teachers and student users the differing "rights" that automatically open some subdirectories for shared reading and close others for individual composing at the system level, without teacher intervention. NETWARE's "Filer" utility permitted us to rename the subdirectories for their pedagogical use, thereby sorting and systematizing the initially unsorted userhome Boxes. An understanding of the originally installed mapping batch file gave us opportunity to modify the given path letters to create mnemonic links. Thus a map of the typical class's userhome terrain now reads something like this:

Finally, as the network's configuration has become more rationalized and therefore more accessible to students and teachers alike, we have added, with advice from our Novell technician, our present menu, a simple shareware menu (really just an anthology of discrete batch files), not (for reasons we'll specify later) the somewhat more elegant Novell menu. The menu presents the students with choices they did not have before: They can call up their class news; check their disks for viruses; move, through WORD, directly into their various subdirectories; be reminded of their userhome topography by a map similar to the one above; join an INTERCHANGE session; or clear their own floppy disks of the unnecessary .bak and .tmp files that the word-processing program leaves behind. The teachers' menu contains these choices and three additional choices: access to a new teachers' e-mail system, an "Exit to DOS," and, most recently, an automatic menu entry for moving student drafts from the closed Revision to the open Share subdirectory for peer-review sessions.

The Benefits of Userhome Ownership

Back in 1986, when our first five-day training period ended and our Novell technician left, he suggested that we read the 12-volume encyclopedia of NETWARE manuals, complete with its full-volume Guide to the Manuals. This was a frightening prospect. When our university-assigned technician refused to learn the software, and network management fell entirely to us, we were both--as we admitted only months later--terrified. Indeed, we did experience, during the first year or two, occasional disasters: printer failures, down servers, etc. But most were remedied within 24 hours with a visit from or call to the Novell technician. For this reason, we continue to purchase an annual and, at $2000, fairly costly service contract for our software. But, as noted in the February 10 issue of PC Week, "U. S. businesses this year will allocate 44% of their networking budgets to support" (Brennan, 1992, p. 15). English teachers need technical support too.

In part because of the start-up problems we encountered, the system now in place is ours. Like homemade clothes, the system may lack style, but it fits. We have modified it to suit our pedagogy and can continue to modify it according to both general program and individual teacher needs. Foregoing a commercially produced shell, we have used a combination of batch files, menu options, and NETWARE utility devices to produce instead permeable layers of network management software, giving both us and our teachers a choice of how much control--and with it responsibility--we'll all individually take. Some teachers, working directly in the terrain and language of DOS, reconstruct userhomes more fitted to their own pedagogies, renaming original subdirectories, opening those directories closed at the system level, creating additions, even tinkering with their students' mapping batch files for ease of entry; others combine their batch file repertoire with a smattering of DOS to achieve similar results; and finally, a substantial group of teachers, relying primarily upon the menu system, accept the network configuration as it is. But whether stylized or generic, every userhome has become a site, not just for private composing, but for full communication, as well, between teachers and their classes and among the writers in them.

There may certainly be things we are not doing with our system that we could be doing, simply because we do not know how. But that would be true were we to turn our network's management over to a technical specialist, too: Even the "experts'" knowledge of these increasingly complex systems is limited. For example, we recently discovered in reading Edward Liebing's (1989) NETWARE User's Guide a fast and easy method of renaming whole subdirectories while leaving their contents and "rights" intact through NETWARE's "Filer" utility. Our Novell technician was unaware of this possibility. Similarly, from Liebing, we learned ways of including batch files within Novell menu systems; unable to do this himself, the technician substituted for us the rudimentary shareware menu we currently use. In fact, when he could not adapt this menu, designed for individual PC use, to a multiple-user network application, it was out of the dogged determination arising from self-interest that we succeeded--and have continued to use it successfully since.

The parameters of our system as presently configured may be defined by the limits of our knowledge, but as teachers as well as network managers we are constantly engaged in just this sort of testing of limits and pushing of boundaries to accommodate pedagogical change--in ways technicians, interested in smooth and steady operations, would not be, and, if we were teachers only, we could not be. Even now, we urge our instructors to suggest to us ways we might fashion their userhomes to suit more closely their individual styles and needs. Many do, but just as many never do, instead adapting their classes to the virtual topography they are given. As difficult as it may be to do what we cannot imagine, it may be equally difficult to imagine what we cannot already do. So in instructional supervision meetings, we listen to teachers' problems, concerns, and frustrations and make small changes in the system accordingly. And we comfort ourselves: After all, it took American educators three generations to unbolt their students' desks from the floor and another generation to reconfigure the rows. Changes in the virtual classroom may be incremental, too.

Were we right to network? We think so. We would not now choose to return to the fragmented world of stand-alones, and although only about 20% of our teachers choose computer-based teaching each year, many fewer have chosen to return to the regular classroom.

Were we right to choose Novell? We think so, and apparently, others concur. There are challenges to the "hegemony" of NETWARE; Microsoft's LAN MANAGER 2.1 recently defeated NETWARE 3.11 in a road test designed by InfoWorld (Kent, 1992). But the Novell system is, today, the de facto industry standard. In a recent column in the New York Times, Peter Lewis (1991) observes that NETWARE-based local area networks "constitute three of four LAN's in operation today" (F:10). NETWARE's popularity is attested to by a casual browse through the computer-book sections of college bookstores, where NETWARE is the only networking software that is the subject of third-party books. Of these, incidentally, we note as the best of the lot Liebing's (1989) NETWARE User's Guide mentioned above, which, as of this moment, covers NETWARE versions 2.1 through 2.15. This guide will almost certainly be updated to include more recent versions.

NETWARE's popularity is further demonstrated, too, in the winter 1991 catalog from The Software Labs, a major distributor of shareware and public domain software. In this catalog's "Networking" section (p. 49 ff), there are utilities programs and e-mail systems that have been written for Novell NETWARE--generally "Novell NETWARE 2.0a and above." One program lists "Banyan Vines 2.x and above," but more typical is the disk of network utilities that "requires Novell NETWARE." NETWARE's installed base is sufficient, apparently, to support the work of those who would write users' guides and add-on utility programs. Clearly, if you install NETWARE, you are not working with an exotic system. There's lots of experience and advice out there.

Indeed, Novell's popularity and availability is such that we see advertised in such publications as PC Week that one can now order from a mail-order house shrink-wrapped Novell LANs--with a "phone help" service staffed by a "dozen certified NETWARE engineers." Our experience, however, tells us that you need on-site expertise, and lots of it, if you are to install and maintain a Novell network or, we feel certain, any network. As an unsigned editorial in the October 14, 1991 InfoWorld notes, "There is no doubt that there is a problem with networking today. . . this stuff is just too complicated to manage, and that gets in the way of developing applications that pay for the investment in the LAN. Companies are spending far too much on managing networks and not getting enough new value out of them" (p. 4). If for-profit firms with extensive in-house computer expertise find that "this stuff is just too complicated," English teachers cannot be expected to go it alone (p. 4).

We need to note that our particular version of NETWARE, Advanced NETWARE 2.15, is no longer available; what is available is an upgrade of this software, NETWARE 2.2, just released this year. This version incorporates a "System Fault Tolerant" (SFT) feature, which classroom networks really don't need: a disk "mirroring" system that creates two virtual systems, so that if one goes down, the other takes its place. Unlike the business environments that are NETWARE's principal target, loss of data is for us an inconvenience, not a bankruptcy-producing disaster. We do back up the system every week, but the system runs so reliably that precautions beyond this seem unnecessary. So with NETWARE 2.2, you'll pay for protection that you don't need. Beyond version 2.2 is version 3.1, still more powerful and more expensive, and still, we think, more than a writing classroom requires.

On the other hand, the current version of NETWARE does offer apparent advantages. It is scalable; ours was not. Version 2.2 can be purchased for 5, 10, 50, or 100 terminals; version 2.15 came in the 100-user dimension only. And, according to the literature, version 2.2 comes with a new utility called "Makeuser," providing a simplified and presumably more efficient way of adding users to the system. Any simplification of this process would certainly be welcome, perhaps to managers of networks in educational settings even more than in business settings in which the ratio of users to workstations is more likely to be, not 1:1, but, as in our case, 8:1. Further, if an upgrade would make it possible to run all our printers from a single file server, we'd be tempted to upgrade.

So should you install networked, computer-equipped classrooms? And should you use NETWARE as your network software? Our answer to both questions is unequivocal: Yes, and Yes. Install NETWARE and become NETWARE literate. The virtual environment may not be the whole world yet, but it's a piece of it---an exciting place to teach, a place where you'll find a lot of friends and colleagues exploring the new terrain. Hire a guide, though. It's worth the price; there are still some rough spots on the frontier.

Marcia Curtis is Assistant Director of the Writing Program at the University of Massachusetts at Amherst.

Charles Moran is Professor of English at the University of Massachusetts at Amherst.

NETWARE is available from the following source:

Novell, Inc.
122 E. 1700 South
Provo, UT 84606

Novell has three levels of authorized dealers each approved to sell various Novell networking products. They are "authorized dealers," "authorized gold resellers," and "authorized platinum resellers." Novell will offer prospective customers a list of three area vendors when customers call Novell's 800 number.


Brennan, L. (1992, February 10). Novell takes on support challenge. PC Week, p. 15.

Kent, L. (1992, March 16). NETWARE meets its match. InfoWorld, p. 62-80.

Lewis, P. H. (1991, November 3). The executive computer, New York Times, p. F:10.

Liebing, E. (1989). NETWARE user's guide. Redwood City, CA: M&T Books.

The Software Labs. (Winter 1991). NETWARE user's guide. Redwood City, CA: M&T Books.

Unsigned editorial. (1991, October 14). Infoworld, p.4.