NetWare 2.x Notes

Novell NetWare has quite a long history, but the older parts of it are now almost completely lost. In the mid-1980s, Novell offered Advanced NetWare, NetWare ELS, NetWare SFT, and other members of the NetWare 286 family.

With the partial exception of so-called non-dedicated NetWare 2.x servers, version 2.x and later of NetWare always had dedicated server machines with clients (called “shell” in the old days, later “workstation”) for DOS, OS/2, Macintosh, and more.

There was not much to see on a NetWare 2.x server console

Until the mid-1990s NetWare typically used its own networking protocol called IPX. NetWare networks could use Ethernet, Token-Ring, Arcnet, IBM PC Network, and other physical network layers. In later days, NetWare networks were almost exclusively Ethernet based (as the other technologies died out), and over time increasingly switched to TCP/IP transport.

In 1989, NetWare 386 was released, to be followed by 3.1, 3.11, 3.12, and 3.2. NetWare 386 was one of the first 386 operating systems for the PC; while it lacked some features of other contemporary advanced operating systems (such as pre-emptive multi-tasking), it had others, like dynamically loadable and un-loadable modules. NetWare 3.x had a long life and survived into the Internet era, including its PDF documentation.

In 1993, NetWare 4.0 was an update to the 3.x line with directory services and other add-ons. Technically NetWare 4.x wasn’t very different from 3.x, and together NetWare 3.x and 4.x were the mainstay of many networks small and large for many years.

NetWare 3.x and 4.x had the curious property that the core of the 32-bit OS (SERVER.EXE) was loaded from DOS, with the ability to exit back to DOS once the NetWare server was “downed” (using the DOWN command, then EXIT).

NetWare 286

NetWare 2.x was… different. A dedicated NetWare 2.x server was installed in its own partition and did not require DOS to boot at all (in that regard it was like NetWare 6.0). It also did not use loadable modules, which made maintenance somewhat challenging (there were VAPs, or Value-Added Processes, mysterious and rare add-ons).

The way NetWare 286 was configured was not unlike many commercial UNIX variants of the era. That is to say, the OS kernel and drivers were provided as object files (regular OMF objects with .OBJ extension), and reconfiguring NetWare meant re-linking the OS. The client side software was managed in the same manner, with the appropriate network driver linked into IPX.COM, to be used by the shell.

Installation and configuration required DOS. It was also designed to not require a hard disk–that is to say, it could be started using a bootable DOS floppy and copied from floppies onto the dedicated server. Especially for NetWare versions prior to 2.2, this was a rather painful process requiring several dozens of 360K floppies. Due to the non-requirement of hard disk, some of the floppies were modified during installation and it was advisable to use working copies, not the original disks. Once a NetWare server was on a LAN, it was possible to install using a directory on the file server, massively reducing the floppy juggling.

While the installation process is more annoying than difficult, there are parts of it that are not in the least obvious, even to people familiar with later NetWare 3.x and 4.x versions. NetWare 2.x was meant to be installed by trained consultants and resellers, which explains why it remained somewhat esoteric.

Matters are further complicated because although NetWare 2.x in fact comes with extensive on-line help, which includes documentation for administrators, the help files are designed to be only available on a shared network drive after installing NetWare. Then again, NetWare used to be delivered with many pounds of printed documentation detailing the install process… with almost all of it completely lost to the sands of time.

Installing NetWare 2.2

NetWare 2.2, released in 1991, was a consolidation of previous NetWare 286 offerings: NetWare ELS (Entry Level Solution), with only 4 or 8 users; Advanced NetWare; and NetWare SFT (System Fault Tolerance) with technologies such as disk mirroring. NetWare 386 at the time was relatively expensive, starting at about $3,500 (20 users), while a basic NetWare 2.2 license (5 users) was about $900. NetWare 2.2 installation was somewhat different and easier compared to the older versions, and therefore is worth discussing separately.

Given the multitude of disks and the workings of the installer, disk naming is crucial. Working floppies or floppy images must be named SYSTEM-1, LAN_DRV_001, or OSEXE; simple numbering just won’t do.

The installation and maintenance tool in NW 2.2 is called INSTALL.EXE and therefore not difficult to find (in NetWare 2.15 it’s not that simple). It can be used for installing a new NW 2.2 server, reconfiguring an existing one, or upgrading an older NetWare 2.x server.

When installing a new machine, there are two options: Basic and Advanced. The Basic variant assumes NE2000 networking hardware in its default configuration and is therefore probably not applicable. The Advanced option allows the system administrator to choose the network and disk configuration.

Disk Drivers

Hard disk support is where trouble may start. Out of the box, NetWare 2.2 effectively only supports classic AT disk controllers or early IDE drives. No geometry translation, no LBA (then again it’s fine with a 120MB disk, so who cares).

Worse yet, NetWare 2.x has an interesting restriction in that the FDPT (Fixed Disk Parameter Table) must be placed at segment C800h in memory or higher. In practice that means NW 2.x refuses to work with user-defined disk parameters with BIOSes that store the geometry either in low memory (0:300 is common) or in the EBDA. A fix to remove this requirement was available.

Vendor-provided HBA drivers for NetWare 2.x were not common but did exist.

Network Drivers

NetWare 2.x came with a decent selection of drivers for networking hardware available in the late 1980s. That is to say, a handful of drivers. About the only one that isn’t totally obsolete is NE2000–the drivers shipped with NetWare 2.x may work on later NE2000 compatibles.

Some vendors did provide drivers for NetWare 2.x servers in the 1990s. Those were provided in the form of a .LAN file and usually four or more .OBJ files.

Even after finding a functioning NetWare 2.x server driver, the fun is not over. The default Ethernet frame type changed from 802.3 (raw IEEE 802.3 Ethernet) in NW 2.x to 802.2 (IEEE 802.2 LLC) in NW 3.12 and later. What that means in practice is that servers and clients using different frame types won’t see each other on the network.

Note that as for NetWare 2.x clients, NetWare 2.2 already provided ODI as an alternative, and using newer ODI-based clients is generally not a problem with NetWare 2.x servers. The “native” way of setting up NetWare 2.x clients was using SHGEN (Shell Generator) or later WSGEN (Workstation Generator) to link IPX.COM with a specific driver in a more or less fixed configuration.

For NetWare 3.x and later, it’s relatively easy to support both Ethernet frame types (or even more). NetWare 2.x Ethernet drivers cannot be reconfigured to use an Ethernet frame type other than 802.3. However, there is a virtual 802.2 driver (A8022.LAN) which provides 802.2 frame support in addition to the default 802.3 frames.

It is also necessary to understand that while NetWare 3.x and later servers can easily handle multiple Ethernet frame types, NetWare clients can not. Newer clients can be configured to use Ethernet 802.3, 802.2 LLC, or plain Ethernet II frames, but only one type can be used at a time

Every NetWare server and client can work with 802.3 frames, but it is not the default on newer NetWare versions. Caveat emptor.

Installing NetWare 2.15

Here it gets a lot more complicated. The first question is, which NetWare 2.15? There’s ELS II, there’s Advanced NetWare, and there’s SFT.

Note that this is not meant to be a tutorial but rather a collection of notes explaining some NetWare features and pointing out certain tricky parts of the installation process.

First of all, there are two conceptually separate steps in installing NetWare 2.15. One is generating the NetWare system, and the other is preparing the server’s disk.

The name of the system generator depends on the NetWare flavor. For ELS II (probably the most widespread flavor of NetWare 2.15), it is ELSGEN.EXE, and it is found on the ELSGEN disk. For Advanced NetWare, the installer is NETGEN.EXE on the NETGEN disk.

NetWare ELS II ELSGEN

The installation uses a full-screen menu-oriented user interface, which is not difficult to use as such, and provides decent guidance. It does have certain idiosyncrasies, such as the following:

Yes, press Escape to continue. No, it does not make any sense, and for the most part NetWare menu-based utilities use the Escape key in the usual fashion.

When setting up a new server, the IPX network address has to be chosen. For all servers on the same LAN (and using the same Ethernet frame type), the address must be the same, or the servers will complain. The actual address matters little; in newer NetWare versions, the number is randomly generated, in old versions it has to be manually entered.

Once the server OS is generated, it must be installed on a server. That includes choosing a disk…

…and running the dreaded COMPSURF utility (COMPrehensive SURFace test). COMPSURF was a tool designed for 1980s dumb drives that had no media defect management. NetWare did it all on its own, identified bad sectors, replaced them with spare sectors, and so on. On a file server, data integrity was obviously quite important.

At one time it was even possible to buy COMPSURF-ed drives that would avoid the need to run COMPSURF, which on a larger drive was a process that took a number of hours.

How much do you want to torture your drive?

COMPSURF is not very nice. It completely destroys all data on a disk.

If you have any data, COMPSURF will eat it

Once COMPSURF is done and the disk is prepared, NetWare volumes can be defined:

NetWare ELS II volume creation

After that, the “cold boot loader” can be installed. That way, NetWare can boot off a hard disk (which is actually optional, it is possible to boot from floppies as well).

Once the server is prepared, it’s off to the races. The server can boot, and clients can connect to it.

Booting a NetWare 2.15 ELS II server in a VM takes about one second (yes, really). Booting a DOS 3.3 VM that connects to the server takes even less. It’s blazingly fast, and a huge change for anyone used to the IBM/Microsoft protocols based on various implementations of NetBIOS.

From a running DOS client, it’s possible to run e.g. FILECON and check the server version:

Note that after the server is installed, there are a few things that need to be done from a client, such as installing on-line help (see HELPLOAD.EXE). That part is entirely optional an can’t be done together with copying all those PUBLIC floppies.

Non-Dedicated NetWare

A curious feature of NetWare 2.x which has no equivalent in NetWare 3.x and later is non-dedicated servers. As mentioned above, there are two ways to generate the server executable, dedicated or non-dedicated.

Which NetWare flavor would you like?

A dedicated server boots directly off the hard disk like a normal OS and takes over the machine. A non-dedicated NetWare server is not bootable. The machine must first boot to DOS, then run NET$OS.EXE. That starts the NetWare server and goes immediately back to DOS (with NetWare still running in the background). At that point, DOS manages the first megabyte of memory in real mode, while NetWare controls everything above that.

Note that the hard disk is not bootable because it is not a DOS disk. That is a huge caveat of non-dedicated NetWare–the hard disk is formatted using the NetWare file system which DOS does not understand.

Once a non-dedicated server dropped out to DOS, it is possible to get back to the server console by running CONSOLE.COM, and it is possible to return back to DOS again by running the appropriately named DOS console command.

A disadvantage of a non-dedicated server is that because it runs DOS in real mode, it is quite easy to hang the system, or in a less extreme case, significantly interfere with the file server’s performance. So why would anyone want to use a non-dedicated server? One possible reason is that on a non-dedicated server, it is possible to run all DOS-based NetWare management tools directly on the server machine, without requiring a workstation attached over the network–something that only came back in NetWare 5.x.

Virtual Non-Dedicated Network Adapter

Note that when in DOS, a non-dedicated NetWare 2.x server has the equivalent of IPX.COM already running. It is still necessary to run a NetWare shell (NETx.COM, NETX.EXE, etc.) but there is no network driver to load. Logically the DOS workstation running locally on a non-dedicated server exists on a separate virtual network between the server and the DOS process, and the server’s virtual adapter is called “Non-Dedicated Server DOS Process”.

Yes, there is a lot to absorb, and these notes aren’t even all that comprehensive.

This entry was posted in NetWare, Networking, PC history. Bookmark the permalink.

13 Responses to NetWare 2.x Notes

  1. Yuhong Bao says:

    I think before IPX.COM there was ANETx.OBJ too which was even more monolithic.

  2. Michal Necasek says:

    Yes. I’ve not had an opportunity to examine the even older shell.

  3. Rich Shealer says:

    I guess I did about 20 Netware systems starting in August of 1986 up until I saw the last one die about 3 years ago. I’m surprised at how much I don’t remember. For example, with Advanced NetWare 286 I know I used to copy the disks to a DOS based drive to generate/link but I don’t remember having to do special naming of folders, I think there were all copied into one big folder.
    In 1986 my task was to get training so we could install it for a customer.
    I remember that there were two main flavors at the time, one was NetWare 68 that ran on a proprietary Novell 68000 server. The one we were using was Advanced Netware/86. I think Advanced NetWare/286 was just about to be released, but we had already sold this system.
    We were an HP dealer and we were going to install it on the new HP Vectra, their first IBM AT somewhat compatible. It was somewhat compatible because it had a hard disk controller that I believe had some sort of caching. Even though the Vectra was on the Novell supported list I couldn’t install it.
    Talking with Novell they eventually said that the computer was compatible, but not the hard disk card that came with it. A business friend offered us a clone AT controller, and it worked fine.
    I’m pretty sure that this was Advanced NetWare/86 and not Advanced NetWare/286 because of a couple of features.
    * You could edit and see the user passwords in SYSCON. That was changed in Advanced NetWare/286.
    * It came with a local email system
    * There was a hardware serial number dongle that plugged into a slot. Advanced NetWare/286 used a serialized installation disk to link the serial number to the installation. The G-Net network card had this built in, but if you used SMC ARCnet cards like we did you had to have a separate dongle.

    Being inexperienced with networking at the time we believed the hype that you could use the server as a DOS workstation and sold it that way. The main application they were going to run was MS Word (for DOS). Problem was there wasn’t enough left-over RAM to run both Netware and Word.
    My friend loaned us an 8-bit memory card that allowed me to boast this monochrome machine by 64K to 704K. Problem was that the BIOS didn’t recognize it. I wrote a program that checked for the extra RAM, if it saw it would rewrite the total RAM that BIOS had seen in the 0:413 BIOS area of RAM. It would then do a soft reboot. MS-DOS would load using the additional 64K and Word worked fine.
    We had rare occasional issues with that station, but in general it worked well. Even though the memory card was only 8-bits rather than 16.

  4. Yuhong Bao says:

    This period in 1986 was around the time Netware 286 was released in the first place. Note that early versions use ISA keycards I think.

  5. Michal Necasek says:

    The NW 2.15/2.2 installs I did had one directory per floppy, and the directories definitely needed to have the right names. The install program normally takes care of that; it’s only a possible issue when adding stuff manually.

    Both NetWare/68 and NetWare/86 are things I only read about. I have been completely unable to find any NetWare version from before 1990, the oldest was 2.12 ELS Level I but still with some files from 1990. I’ve been also unable to find any NetWare/386 older than 3.11.

    Yes, I read that in the mid-1980, NetWare had something called MUSCLS which was an ISA key card. 3rd party software could be bolted to it as well, and the server could keep track of how many copies were in use at a time. The later releases had serialized disks, it’s pretty obvious (looking at the Kryoflux dumps) that the disks were mass duplicated and then one .OBJ file was rewritten to include the serial number.

    I like the “AT somewhat compatible” description of the HP Vectra, I think that’s pretty accurate 🙂

    My non-dedicated NetWare 2.15 ELS Level II VM running with PC DOS 3.3 has about 520K free, that seems pretty good. But you are probably talking about NetWare/86 which I’m sure was quite different in that respect.

  6. Yuhong Bao says:

    Actually, thinking about it, I wonder if Netware 286 ever supported the HP Vectra at all and how.

  7. MiaM says:

    Did thins Netware/86 use it’s own code to talk to the hard disk controller hardware, or did it use BIOS?

    If it had it’s own code, then the “blame” is at least as much on Novell as it’s on HP. After all, you’d have the same issue with any SCSI card or similar where there weren’t drivers for the operating system you wanted to run.

  8. Michal Necasek says:

    Never having seen NetWare/86, I can only guess… but I can improve the accuracy of the guessing by looking at the 1986 NetWare/86 Installation manual (this appears to be for Advanced and SFT NetWare/86 2.0a). I could not find an explicit statement for the support of standard XT or AT disks; there is talk about requiring drivers for any non-IBM-standard hard disks (NETDISK.SYS is what the drivers were called). I would guess that NetWare/86 had its own drivers for the standard disks as well. That’s certainly how NetWare/286 did it.

    Given how slow disks were back then, NetWare probably needed its own drivers capable of simultaneous disk and network I/O to get any kind of useful performance.

    Interesting note — NetWare/86 came with its own network drivers but was also able to run on top of NETBIOS.

  9. Rich Shealer says:

    The training class I took at the time for ANW/86 talked about “Elevator Seeking” and caching. They cached the FAT table and would sort the writes so that if they need to write something to track 480 and while it was on its way would get a request to write to track 302 it would take care of 302 first similar to how an elevator stops at each needed floor along the way.

    I don’t think this precludes using the BIOS, but I don’t think it did.

  10. Michal Necasek says:

    Yes, that’s what made NetWare fast. They also had lots of technologies like RAID before it was even called that. And yes, elevator seeking could in theory be doable with BIOS as well, but almost certainly NetWare/86 had its own drivers for the custom drives.

  11. MiaM says:

    Re disk speed: In theory it could had been possible to use BIOS for disk access and let interrupt code from the NIC do a whole bunch of the processing. Kind of wasteful and rather tricky but at least in theory doable.

  12. Yuhong Bao says:

    You can still see the remains in VREPAIR.EXE which is linked with the NetWare 286 disk drivers but runs in real mode.

  13. Yuhong Bao says:

    (The original HP Vectra didn’t use a standard AT keyboard. I think it used the BIOS to emulate one)

Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.