PC TCP/IP v3.0 for Windows 08 serial key or number

The first command immediately changes the running system. The second causes the services to be enabled the next time UCX starts up. Before transferring data, a client and a server initialize several communication operations. Initialization is determined by the socket type and activation flags set in the services database. Table describes the communication initialization process.

The auxiliary server does not transfer data. Therefore, the auxiliary server can set socket options for a requested service either before or during data communications. Some available options are:

• KEEPALIVE and LINGER for TCP communications
• BROADCAST for UDP communications

You can also specify socket options for a requested service in the services database. These socket options are set before the new socket is passed to the requested server.

Setting Up Event Logging

Event logging can help you manage the UCX software. By default, UCX services do not log events but you can enable event logging for all or selected configured services. You can configure UCX to log events to the operator's console, a log file, or both. To set up event logging, issue the following commands:

• To specify event logging for one service:
  SET SERVICE service /LOG_OPTIONS=(FILE=file,options)
  This configuration is overridden by the values set with the /FORCE_LOG_OPTIONS qualifier of the SET COMMUNICATION and SET CONFIGURATION COMMUNICATION commands.
• To interactively set event logging affecting all the services:
  • SET COMMUNICATION /ALLOW_LOG_OPTIONS=options
    Provides an alternate way to capture logging that you did not set up with the SET SERVICE service /LOG command. Specifies options that, when set, apply to all the services.
  • SET COMMUNICATION /FORCE_LOG_OPTIONS=options
    /FORCE_LOG_OPTIONS overrides the settings of the SET SERVICE /LOG_OPTIONS command.
• To permanently set event logging affecting all the services:
  • SET CONFIGURATION COMMUNICATION /ALLOW_LOG_OPTIONS=options
    Same options as SET COMMUNICATION /ALLOW_LOG_OPTIONS
  • SET CONFIGURATION COMMUNICATION /FORCE_LOG_OPTIONS=options
    Same options as SET COMMUNICATION /FORCE_LOG_OPTIONS

For a list of all the logging options, see the SET SERVICE command description in the DIGITAL TCP/IP Services for OpenVMS Management Command Reference manual.

Some UCX components provide additional event logging capabilities. Refer to individual component chapters for more information.

UCX stores user data in the OpenVMS system space (nonpaged pool). The amount of nonpaged pool space required depends on your network configuration. UCX allocates the following buffer space from the OpenVMS nonpaged pool:

• Buffers specific to OpenVMS (internet I/O request packets [IRPs] and large request packets [LRPs])
• Buffers for the internet memory buffers (MBUFs) and device sockets (see Table )

UCX preallocates MBUFs in blocks as follows:

• Control clusters that store information related to:
  • Device sockets
  • Internal control structures
  • IP addresses
  • IP routes
  • IP packet headers
• Data clusters that store the data in the system space as follows:
  • Before actual transmission, a transmit data operation moves data from the user process space to the large buffer.
  • Until a user process is ready to read data, a receive data operation stores received data in the large buffers.

Table provides the initial (default) values UCX allocates to control cluster (small MBUFs) and data clusters (large MBUFs).

If the default values are not appropriate for your network, you can modify them. See Appendix A for further instructions.

UCX sets buffers for the following data:

• Receive buffer
• Send buffer
• Socket buffer

Each buffer is assigned a quota. When the UCX receive buffer quota is reached, UCX discards any messages received for a particular device socket. When the send buffer quota is reached, UCX puts the process in a resource WAIT. If a process is configured with a NOWAIT option, it receives an I/O error on the write request that filled the buffer quota.

UCX uses counters indicating real-time statistics of usage, performance, and errors. Counters show the amount of specific network activities. To display them, issue SHOW commands. For example, the following command displays, for the UCX communication buffers, the amounts of memory used and free.

For more information about using counters to monitor usage and network activity, see Appendix A.

OpenVMS systems running DIGITAL TCP/IP Services for OpenVMS (UCX) communicate with other internet hosts over a variety of physical media&#;. Because TCP/IP is independent of the underlying physical network, IP addresses are implemented in the network software, not the network hardware.

This chapter reviews key concepts and explains how to configure the network interface and assign IP addresses, subnet masks, and broadcast addresses.

Note

&#; See the DIGITAL TCP/IP Services for OpenVMS Software Product Description for a complete list of supported media.

A network controller is the hardware connection between a computer system and a physical network. Controllers perform the packet channeling to and from the physical medium of your network, usually a cable.

The network interface is a logical network controller a software component that communicates with your UCX software and the network controller. UCX supports multiple logical interfaces for each physical network controller. This means a single physical connection can have more than one IP address. The network controller must be configured to make it visible to the network software. Then the logical network interface can be configured using the device_name, logical_unit_number format.

For each interface, you can enable or disable the interface; set the subnet mask; set protocols for the interface; and assign IP, Ethernet and broadcast addresses.

If you used UCX$CONFIG to configure your software, UCX automatically recognizes network controllers upon startup. If you need to add new network controllers to your system after installing and configuring UCX, follow the installation and configuration instructions that come with your hardware, then simply rerun UCX$CONFIG. UCX will recognize the new controller the next time the software starts up.

Important

Hardware installation and configuration instructions are specific for the various network controllers be sure to read the instructions provided with your new hardware before installing.

To display current controller definitions, issue the LIST COMMUNICATION_CONTROLLER command. It lists the names and other information about the communication controllers known to UCX. For example,

To manually add a new controller, issue the DEFINE COMMUNICATION_CONTROLLER command. To remove a controller definition, issue the DELETE COMMUNICATION_CONTROLLER command.

UCX supports one local interface for loopbacks and one or more network interfaces for each network controller.

The configuration procedure initially configures your network interfaces. Use the following commands if you need to redefine an interface or configure serial lines. See Chapter 3 for more information on configuring serial lines.

• SET INTERFACE
• SET NOINTERFACE
• SET CONFIGURATION INTERFACE
• SET CONFIGURATION NOINTERFACE

To display information, use the SHOW INTERFACE command, and to disable an interface, issue the SET NOINTERFACE command.

Note

If you are redefining an existing interface, issue the SET NOINTERFACE command before you issue the SET INTERFACE command.

Specifying the Interface

On the SET INTERFACE command line, the interface parameter is the interface name for the communication controller you are configuring. Some examples are: FZ0, FZ1, FR1, IR1, EZ0, EX0, SL0, SL1, SL2.

The name of a network interface has two characters followed by the unit number of the communication controller, conforming to this pattern:

Specifying the Network Mask

An IP address consists of a network number and a host number. The network mask is the part of the host field of the IP address identified as the subnetwork. Every host on the same network must have the same subnetwork mask. To specify the network mask, use the /NETWORK_MASK qualifier. This is required if you use subnetworks.

UCX calculates the default by setting:

• The bits representing the network fieldsto 1
• The bits representing the host fieldto 0

You can also divide the host field into a site-specific subnetwork and host field. For more information about defining network interfaces for subnet routing, see Section

Network hosts require manual configuration of a hardware address for a remote IP address under the following conditions:

• The remote host does not support the Address Resolution Protocol (ARP). You need static mapping of IP addresses to hardware addresses.
• The remote host is running ARP, but a change was made to the internet interface on that host.
  To allow the change to be made known to your system, flush the address mapping tables. Use the SET NOARP command.

For example, to map the Ethernet address AA of host ROOK, follow these steps:

1. Add the hardware address to the ARP table. Issue: UCX> SET ARP AA ROOK
2. Specify the time interval for ARP to hold the information in its cache, for example, 30 minutes. Enter this information into dynamic memory and into the permanent configuration database. Issue: UCX> SET PROTOCOL ARP /COMPLETE_TIMER=30 UCX> SET CONFIGURATION PROTOCOL ARP /COMPLETE_TIMER=30
   To set the maximum time that an unresolved query is kept in the ARP dynamic database, use the /INCOMPLETE_TIMER qualifier.

A serial connection is made between two systems using modems and telephone lines or other serial lines. DIGITAL TCP/IP Services for OpenVMS supports serial connections using the PPP and SLIP (including CSLIP) protocols&#;. You can use any standard OpenVMS terminal device as a PPP or SLIP line.

After establishing a Point-to-Point Protocol or Serial Line IP connection between hosts, you can run TCP/IP commands over the line. If the remote system is configured as a gateway to a network, local users can also reach other systems on that network through the serial connection.

This chapter reviews key concepts and describes how to configure your network interface to use a telephone circuit or other serial line.

Note

&#; PPP is available for OpenVMS V Alpha systems only.

If your OpenVMS system is part of a large network, you will probably use both PPP and SLIP for your serial connections. An internet standard, PPP is often preferred because it ensures interoperability between systems from a wide variety of vendors. PPP provides a way for your OpenVMS Alpha system to establish a dynamic IP network connection over a serial line without the extensive use of additional router or server hardware.

However, SLIP has been in use for a longer period of time and thus is available for more kinds of hardware. SLIP is available for most terminal servers and in most PC implementations of TCP/IP. Because SLIP and PPP do not interoperate, hosts wishing to communicate must use the same protocol. For example, if your terminal server supports only SLIP, remote hosts that connect through this server must also use SLIP.

Uses for PPP and SLIP

One of the largest applications for IP over serial lines is dialup access. With this type of configuration, your OpenVMS host answers calls and establishes a connection initiated by a user on a remote host or PC. Or, users on your host can originate the dialup connection to a remote host or terminal server running the same protocol.

Dedicated serial lines running PPP or SLIP can also be used to connect separate LANs into a single WAN. In such a configuration, the host at each end of the serial connection is always the same; no other hosts are allowed to connect to either serial device.

Assigning an IP Address to Your PPP or SLIP Interface

Every network interface requires a unique IP address. If you configure PPP interfaces for multiple remote hosts, the remote hosts can obtain their IP addresses from your host when they connect. Similarly, you can configure a PPP interface on your system without knowing your own IP address and obtain it when you connect to a remote system.

Before establishing SLIP communcation with a remote host, however, you must obtain the IP address for the host's serial interface and assign IP addresses for each interface you configure on the local host.

When using SLIP, consider placing each serial line in a separate subnetwork. You accomplish this by assigning the same subnet mask for the interfaces at either end of the link.

If you need to use an address in the same subnetwork as your site LAN, use the proxy Address Resolution Protocol (ARP) feature (see Section ).

Serial Line Internet Protocol

SLIP sends a datagram across the serial line as a series of bytes. It uses the special characters described below to mark when a series of bytes should be grouped together.

SLIP starts by sending an END character. If END is encountered within the datagram as data, SLIP inserts an escape character, sending the two-character sequence DB DC instead. If the ESC character appears within the datagram as data, it is replaced with the two-character sequence DB DD. The datagram ends with the END character after the last byte in the packet has been transmitted.

There is no standard SLIP specification, nor a defined maximum packet size for SLIP. DIGITAL's implementation of SLIP accepts byte datagrams and does not send more than bytes in a datagram.

Compressed SLIP provides header compression which is beneficial for small packets and low-speed serial links. Header compression improves packet throughput. You can enable CSLIP by means of the /COMPRESS qualifier when you issue a SET INTERFACE command. See Table for more information.

NetWare is a discontinued computer network operating system developed by Novell, Inc. It initially used cooperative multitasking to run various services on a personal computer, using the IPX network protocol.

The original NetWare product in supported clients running both CP/M and MS-DOS, ran over a proprietary star network topology and was based on a Novell-built file server using the Motorola processor, but the company soon moved away from building its own hardware, and NetWare became hardware-independent, running on any suitable Intel-based IBM PC compatible system, and a wide range of network cards. From the beginning NetWare implemented a number of features inspired by mainframe and minicomputer systems that were not available in its competitors.

In , Novell introduced cheaper peer-to-peer networking products for DOS and Windows, unrelated to their server-centric NetWare. These were NetWare&#;Lite&#; (NWL), and later Personal&#;NetWare&#; (PNW) in

In , the main NetWare product line took a dramatic turn when version 4 introduced NetWare Directory Services (NDS), a global directory service similar to the Active Directory that Microsoft would release seven years later. This, along with a new e-mail system (GroupWise), application configuration suite (ZENworks), and security product (BorderManager) were all targeted at the needs of large enterprises.

By , however, Microsoft was taking more of Novell's customer base and Novell increasingly looked to a future based on a Linux kernel. The successor to NetWare, Open Enterprise Server (OES), released in March , offered all the services previously hosted by NetWare , but on a SUSE Linux Enterprise Server; the NetWare kernel remained an option until OES 11 in late

The final update release was version SP8 of May ; NetWare is no longer on Novell's product list.^[2] NetWare SP8 General Support ended in , with Extended Support until the end of , and Self Support until the end of The replacement is Open Enterprise Server.^[3]

History[edit]

A networking card with a sticker indicating certification with NetWare

NetWare evolved from a very simple concept: file sharing instead of disk sharing. In when the first versions of NetWare originated, all other competing products were based on the concept of providing shared direct disk access. Novell's alternative approach was validated by IBM in , which helped promote the NetWare product.

Novell NetWare shared disk space in the form of NetWare volumes, comparable to DOS volumes. Clients running DOS would run a special terminate and stay resident (TSR) program that allowed them to map a local drive letter to a NetWare volume. Clients had to log into a server in order to be allowed to map volumes, and access could be restricted according to the login name. Similarly, they could connect to shared printers on the dedicated server, and print as if the printer was connected locally.

At the end of the s, with Internet connectivity booming, the Internet's TCP/IP protocol became dominant on LANs. Novell had introduced limited TCP/IP support in NetWare 3.x (circa ) and 4.x (circa ), consisting mainly of FTP services and UNIX-style LPR/LPD printing (available in NetWare 3.x), and a Novell-developed webserver (in NetWare 4.x). Native TCP/IP support for the client file and print services normally associated with NetWare was introduced in NetWare (released in ).

During the early to mids Microsoft introduced their own LAN system in LAN Manager, based on the competing NBF protocol. Early attempts to muscle in on NetWare failed, but this changed with the inclusion of improved networking support in Windows for Workgroups, and then the hugely successful Windows NT and Windows NT, in particular, offered services similar to those offered by NetWare, but on a system that could also be used on a desktop, and connected directly to other Windows desktops where NBF was now almost universal.

Early years[edit]

NetWare originated from consulting work by SuperSet Software, a group founded by the friends Drew Major, Dale Neibaur, Kyle Powell and later Mark Hurst. This work stemmed from their classwork at Brigham Young University in Provo, Utah, starting in October

In , Raymond Noorda engaged^{[clarification needed]} the work by the SuperSet team. The team was originally assigned to create a CP/Mdisk sharing system to help network the CP/M Motorola hardware that Novell sold at the time. The first S-Net was CP/MK-based and shared a hard disk. In , the team was privately convinced that CP/M was a doomed platform and instead came up with a successful file-sharing system for the newly introduced IBM-compatible PC. They also wrote an application called Snipes – a text-mode game – and used it to test the new network and demonstrate its capabilities. Snipes [aka 'NSnipes' for 'Network Snipes'] was the first network application ever written for a commercial personal computer, and it is recognized as one of the precursors of many popular multiplayer games such as Doom and Quake.^[4]

First called ShareNet or S-Net, this network operating system (NOS) was later called Novell NetWare. NetWare was based on the NetWare Core Protocol (NCP), which is a packet-based protocol that enables a client to send requests to and receive replies from a NetWare server. Initially NCP was directly tied to the IPX/SPX protocol, and NetWare communicated natively using only IPX/SPX.

The first product to bear the NetWare name was released in There were two distinct versions of NetWare at that time. One version was designed to run on the Intel processor and another on the Motorola processor which was called NetWare&#;68 (aka S-Net); it ran on the Motorola processor on a proprietary Novell-built file server (Novell could not write an original network operating system from scratch so they licensed a Unix kernel and based NetWare on that^{[5][citation needed]}) and used a star network topology. This was soon joined by NetWare&#;86&#;4.x, which was written for the Intel This was replaced in with Advanced NetWare&#;86 version a which allowed more than one server on the same network. In , after the Intel processor became available, Novell released Advanced NetWare&#;&#;a. Two versions were offered for sale; the basic version was sold as ELS&#;I and the more enhanced version was sold as ELS&#;II. The acronym ELS was used to identify this new product line as NetWare's Entry Level System.

NetWare 2.x[edit]

Advanced NetWare version 2.x, launched in , was written for the then-new CPU. The CPU featured a new bit protected mode that provided access to up to 16&#;MB RAM as well as new mechanisms to aid multi-tasking. (Prior to the , PC CPU servers used the Intel / 8-/bit processors, which were limited to an address space of 1&#;MB with not more than &#;KB of directly addressable RAM.) The combination of a higher 16&#;MB RAM limit, processor feature utilization, and &#;MB NetWare volume size limit (compared to the 32&#;MB that DOS allowed at that time) allowed the building of reliable, cost-effective server-based local area networks for the first time. The 16&#;MB RAM limit was especially important, since it made enough RAM available for disk caching to significantly improve performance. This became the key to Novell's performance while also allowing larger networks to be built.

In a significant innovation, NetWare was also hardware-independent, unlike competing network server systems. Novell servers could be assembled using any brand system with an Intel CPU, any MFM, RLL, ESDI, or SCSI hard drive and any 8- or bit network adapter for which NetWare drivers were available – and 18 different manufacturer's network cards were supported at launch.^[6]

A server could support up to four network cards,^[6] and these could be a mixture of technologies such as ARCNET, Token Ring and Ethernet. The operating system was provided as a set of compiled object modules that required configuration and linking. Any change to the operating system required a re-linking of the kernel. Installation also required the use of a proprietary low-level format program for MFM hard drives called COMPSURF.

The file system used by NetWare&#;2.x was NetWare File System , or NWFS&#;, supporting volumes of up to &#;MB. NetWare&#; recognized protected mode, extending NetWare's support of RAM from 1&#;MB to the full 16&#;MB addressable by the A minimum of 2&#;MB was required to start up the operating system; any additional RAM was used for FAT, DET and file caching. Since bit protected mode was implemented in the and every subsequent Intel x86 processor, NetWare&#; version 2.x would run on any or later compatible processor.

NetWare 2.x implemented a number of features inspired by mainframe and minicomputer systems that were not available in other operating systems of the day. The System Fault Tolerance (SFT) features included standard read-after-write verification (SFT-I) with on-the-fly bad block re-mapping (at the time, disks did not have that feature built in) and software RAID1 (disk mirroring, SFT-II). The Transaction Tracking System (TTS) optionally protected files against incomplete updates. For single files, this required only a file attribute to be set. Transactions over multiple files and controlled roll-backs were possible by programming to the TTS API.

NetWare&#;&#;2.x normally required a dedicated PC to act as the server, where the server used DOS only as a boot loader to execute the operating system file . All memory was allocated to NetWare; no DOS ran on the server. However, a "non-dedicated" version was also available for price-conscious customers. In this, DOS&#; or higher would remain in memory, and the processor would time-slice between the DOS and NetWare programs, allowing the server computer to be used simultaneously as a network file server and as a user workstation. Because all extended memory (RAM above 1&#;MB) was allocated to NetWare, DOS was limited to only &#;KB; expanded memory managers that used the MMU of and higher processors, such as EMM, would not work; style expanded memory on dedicated plug-in cards was possible however. Time slicing was accomplished using the keyboard interrupt, which required strict compliance with the IBM PC design model, otherwise performance was affected.

Server licensing on early versions of NetWare&#; was accomplished by using a key card. The key card was designed for an 8-bit ISA bus, and had a serial number encoded on a ROM chip. The serial number had to match the serial number of the NetWare software running on the server. To broaden the hardware base, particularly to machines using the IBM MCA bus, later versions of NetWare&#;2.x did not require the key card; serialised license floppy disks were used in place of the key cards.

Licensing was normally for users, but two ELS versions were also available. First a 5-user ELS in , and followed by the 8-user ELS&#;&#;II in ^[7]

NetWare 3.x[edit]

A book on NetWare published in Thai

NetWare's 3.x range was a major step forward. It began with version in , followed quickly by version and in

A key feature was support for bitprotected mode, eliminating the 16&#;MB memory limit of NetWare&#; and therefore allowing larger hard drives to be supported (since NetWare&#;3.x cached the entire file allocation table and directory entry table into memory for improved performance).

NetWare version 3.x was also much simpler to install, with disk and network support provided by software modules called a NetWare Loadable Module (NLM) loaded either at start-up or when it was needed. NLMs could also add functionality such as anti-virus software, backup software, database and web servers. Support for long filenames was also provided by an NLM.

A new file system was introduced by NetWare&#;3.x&#;– "NetWare File System ", or NWFS&#;, which significantly extended volume capacity (1&#;TB, 4&#;GB files), and could handle up to 16 volume segments spanning multiple physical disk drives. Volume segments could be added while the server was in use and the volume was mounted, allowing a server to be expanded without interruption.

In NetWare&#;&#;3.x all NLMs ran on the server at the same level of processor memory protection, known as "ring 0". This provided the best possible performance, it sacrificed reliability because there was no memory protection, and furthermore NetWare 3.x used a co-operative multitasking model, meaning that an NLM was required to yield to the kernel regularly. For either of these reasons a badly behaved NLM could result in a fatal (ABEND) error.

NetWare continued to be administered using console-based utilities.

For a while, Novell also marketed an OEM version of NetWare&#;3, called Portable NetWare, together with OEMs such as Hewlett-Packard, DEC and Data General, who ported Novell source code to run on top of their Unix operating systems. Portable NetWare did not sell well.

While NetWare&#;3.x was current, Novell introduced its first high-availability clustering system, named NetWare SFT-III, which allowed a logical server to be completely mirrored to a separate physical machine. Implemented as a shared-nothing cluster, under SFT-III the OS was logically split into an interrupt-driven I/O engine and the event-driven OS core. The I/O engines serialized their interrupts (disk, network etc.) into a combined event stream that was fed to two identical copies of the system engine through a fast (typically &#;Mbit/s) inter-server link. Because of its non-preemptive nature, the OS core, stripped of non-deterministic I/O, behaves deterministically, like a large finite state machine. The outputs of the two system engines were compared to ensure proper operation, and two copies fed back to the I/O engines. Using the existing SFT-II software RAID functionality present in the core, disks could be mirrored between the two machines without special hardware. The two machines could be separated as far as the server-to-server link would permit. In case of a server or disk failure, the surviving server could take over client sessions transparently after a short pause since it had full state information. SFT-III was the first NetWare version able to make use of SMP hardware&#;– the I/O engine could optionally be run on its own CPU. NetWare SFT-III, ahead of its time in several ways, was a mixed success.

With NetWare&#;3 an improved routing protocol, NetWare Link Services Protocol, has been introduced which scales better than Routing Information Protocol and allows building large networks.

NetWare 4.x[edit]

NetWare&#;4 and NDS were the subjects of many technical sessions at the Novell BrainShare conference, here seen during a break in

Version&#;4 in introduced NetWare Directory Services, later re-branded as Novell Directory Services (NDS), based on X, which replaced the Bindery with a global directory service, in which the infrastructure was described and managed in a single place. Additionally, NDS provided an extensible schema, allowing the introduction of new object types. This allowed a single user authentication to NDS to govern access to any server in the directory tree structure. Users could therefore access network resources no matter on which server they resided, although user license counts were still tied to individual servers. (Large enterprises could opt for a license model giving them essentially unlimited per-server users if they let Novell audit their total user count.)

Version&#;4 also introduced a number of useful tools and features, such as transparent compression at file system level and RSA public/private encryption.

Another new feature was the NetWare Asynchronous Services Interface (NASI). It allowed network sharing of multiple serial devices, such as modems. Client port redirection occurred via a DOS or Windows driver allowing companies to consolidate modems and analog phone lines.^[8]

The upgrade was not without its flaws – initially NetWare&#;4 could not coexist with earlier versions on the same network because of incompatibilities.^[9]

NetWare for OS/2[edit]

Promised as early as , when the Microsoft-IBM collaboration was still ongoing and OS/2&#;1.x was still a bit product,^[10] the product didn't become commercially available until after IBM and Microsoft had parted ways and OS/2&#; had become a bit, pre-emptive multitasking and multithreading OS.

By August ,^[11] Novell released its first version of "NetWare for OS/2". This first release supported OS/2&#; () as the base OS, and required that users first buy and install IBM OS/2, then purchase NetWare&#;, and then install the NetWare for OS/2 product. It retailed for $^[11]

By around , and coincidental with IBM's renewed marketing push for its bit OS/2 Warp OS, both as a desktop client and as a LAN server (OS/2 Warp Server), NetWare for OS/2 began receiving some good press coverage. "NetWare for OS/2" allowed to run Novell's network stack and server modules on top of IBM's bit kernel and network stack. It was basically NetWare 4.x running as a service on top of OS/2. It was compatible with third party client and server utilities and NetWare Loadable Modules.^[12]

Since IBM's bit OS/2 included Netbios, IPX/SPX and TCP/IP support, this means that sysadmins could run all three most popular network stacks on a single box, and use the OS/2 box as a workstation too. NetWare for OS/2 shared memory on the system with OS/2 seamlessly. The book "Client Server survival Guide with OS/2" described it as "glue code that lets the unmodified NetWare&#;4.x server program think it owns all resources on a OS/2 system". It also claimed that a NetWare server running on top of OS/2 only suffered a 5% to 10% overhead over NetWare running over the bare metal hardware, while gaining OS/2's pre-emptive multitasking and object oriented GUI.^[13]

Novell continued releasing bugfixes and updates to NetWare for OS/2 up to ^[14]

Strategic mistakes[edit]

Novell's strategy with NetWare&#;&#;2.x and 3.x proved very successful; before the arrival of Windows&#;NT Server, Novell claimed 90% of the market for PC based servers.

While the design of NetWare&#;3.x and later involved a DOS partition to load NetWare server files, this feature became a liability as new users preferred the Windows graphical interface to learning DOS commands necessary to build and control a NetWare server. Novell could have eliminated this technical liability by retaining the design of NetWare&#;, which installed the server file into a Novell partition and allowed the server to boot from the Novell partition without creating a bootable DOS partition. Novell finally added support for this in a Support Pack for NetWare&#;

As Novell used IPX/SPX instead of TCP/IP, they were poorly positioned to take advantage of the Internet in This resulted in Novell servers being bypassed for routing and Internet access in favor of hardware routers, Unix-based operating systems such as FreeBSD, and SOCKS and HTTP Proxy Servers on Windows and other operating systems.^{[citation needed]}

A decision by the management of Novell also took away the ability of independent resellers and engineers to recommend and sell the product. The reduction of their effective sales force created this downward spiral in sales.

NetWare x and NetWare for Small Business[edit]

Novell priced NetWare&#; similarly to NetWare&#;, allowing customers who resisted NDS (typically small businesses) to try it at no cost.

Later Novell released NetWare version in which included many enhancements that made the operating system easier to install, easier to operate, faster, and more stable. It also included the first full bit client for Microsoft Windows-based workstations, SMP support and the NetWare Administrator (NWADMIN or NWADMN32), a GUI-based administration tool for NetWare. Previous administration tools used the Cworthy interface, the character-based GUI tools such as SYSCON and PCONSOLE with blue text-based background. Some of these tools survive to this day, for instance manicapital.com

Novell packaged NetWare&#; with its Web server, TCP/IP support and the Netscape browser into a bundle dubbed IntranetWare (also written as intraNetWare). A version designed for networks of 25 or fewer users was named IntranetWare for Small Business and contained a limited version of NDS and tried to simplify NDS administration. The intranetWare name was dropped in NetWare&#;5.

During this time Novell also began to leverage its directory service, NDS, by tying their other products into the directory. Their e-mail system, GroupWise, was integrated with NDS, and Novell released many other directory-enabled products such as ZENworks and BorderManager.

NetWare still required IPX/SPX as NCP used it, but Novell started to acknowledge the demand for TCP/IP with NetWare&#; by including tools and utilities that made it easier to create intranets and link networks to the Internet. Novell bundled tools, such as the IPX/IP gateway, to ease the connection between IPX workstations and IP networks. It also began integrating Internet technologies and support through features such as a natively hosted web server.

NetWare 5.x[edit]

With the release of NetWare&#;5 in October Novell switched its primary NCP interface from the IPX/SPX network protocol to TCP/IP to meet market demand.^[15] Products continued to support IPX/SPX, but the emphasis shifted to TCP/IP. New features included:

The Cluster Services improved on SFT-III, as NCS did not require specialized hardware or identical server configurations.

Novell released NetWare&#;5 during a time when NetWare's market share had started dropping precipitously; many companies and organizations replaced their NetWare servers with servers running Microsoft's Windows NT operating system.

Around this time Novell also released their last upgrade to the NetWare&#;4 operating system, NetWare&#;

NetWare&#;5 and above supported Novell NetStorage for Internet-based access to files stored within NetWare.^[17][18] Novell released NetWare&#; in January It introduced a number of tools, such as:

NetWare [edit]

NetWare&#;6 was released in October , shortly after its predecessor. This version has a simplified licensing scheme based on users, not server connections. This allows unlimited connections per user to any number of NetWare servers in the network.^[19] Novell Cluster Services was also improved to support node clusters;^[20] the base NetWare&#; product included a two-node clustering license.

NetWare [edit]

NetWare&#; was released in August Some of the new features in this version included:

• more open-source products such as PHP, MySQL and OpenSSH
• a port of the Bash shell and a lot of traditional Unix utilities such as wget, grep, awk and sed to provide additional capabilities for scripting
• iSCSI support (both target and initiator)
• Virtual Office – an "out of the box" web portal for end users providing access to e-mail, personal file storage, company address book, etc.
• Domain controller functionality
• Universal password
• DirXML Starter Pack – synchronization of user accounts with another eDirectory tree, a Windows NT domain or Active Directory.
• exteNd Application Server – a Java EE compatible application server
• support for customized printer driver profiles and printer usage auditing
• NX bit support
• support for USB storage devices
• support for encrypted volumes

The latest – and apparently last – Service Pack for NetWare&#; is SP8, released May

Open Enterprise Server[edit]

[edit]

In , Novell announced the successor product to NetWare: Open Enterprise Server (OES). First released in March , OES completes the separation of the services traditionally associated with NetWare (such as Directory Services, and file-and-print) from the platform underlying the delivery of those services. OES is essentially a set of applications (eDirectory, NetWare Core Protocol services, iPrint, etc.) that can run atop either a Linux or a NetWare kernel platform. Clustered OES implementations can even migrate services from Linux to NetWare and back again, making Novell one of the very few vendors to offer a multi-platform clustering solution.

Consequent to Novell's acquisitions of Ximian and the German Linux distributor SuSE, Novell moved away from NetWare and shifted its focus towards Linux. Marketing was focused on getting faithful NetWare users to move to the Linux platform for future releases.^[21] The clearest indication of this direction was Novell's controversial decision to release Open Enterprise Server on Linux only, not NetWare. Novell later watered down this decision and stated that NetWare's 90 million users would be supported until at least ^[22] Meanwhile, many former NetWare customers rejected the confusing mix of licensed software running on an open-source Linux operating system in favor of moving to complete Open Source solutions such as those offered by Red Hat.^[23]

[edit]

OES 2 was released on 8 October It includes NetWare&#; SP7, which supports running as a paravirtualized guest inside the Xen hypervisor and new Linux based version using SLES

New features include

• bit support
• Virtualization
• Dynamic Storage Technology, which provide Shadow Volumes
• Domain services for Windows (provided in OES&#;2 service pack 1)

From the s[edit]

As of ^[update] some organizations still used Novell NetWare, but it had started to lose popularity from the mids, when NetWare was the de facto standard for file- and printer-sharing software for the Intel x86 server platform.^[24]

Microsoft successfully took market share from NetWare products from the lates.^[25][26] Microsoft's more aggressive marketing was aimed directly at non-technical management through major magazines, while Novell NetWare's was through more technical magazines read by IT personnel.^{[citation needed]}

Novell did not adapt their pricing structure to current market conditions, and NetWare sales suffered,^[27]

NetWare Lite / Personal NetWare[edit]

NetWare Lite and Personal NetWare were a series of peer-to-peer networks developed by Novell for DOS- and Windows-based computers aimed at personal users and small businesses between and

Performance[edit]

The success of NetWare as a product is what allowed Novell to have sales-related offices around the world, as the back side of this mids Novell presentation folder shows

NetWare dominated the network operating system (NOS) market from the mids through the mid- to lates due to its extremely high performance relative to other NOS technologies. Most benchmarks during this period demonstrated a to performance advantage over products from Microsoft, Banyan, and others. One noteworthy benchmark pitted NetWare 3.x running NFS services over TCP/IP (not NetWare's native IPX protocol) against a dedicated Auspex NFS server and an SCO Unix server running NFS service. NetWare NFS outperformed both 'native' NFS systems and claimed a performance advantage over SCO Unix NFS on the same hardware.^{[citation needed]}

The reasons for NetWare's performance advantage are given below.

File service instead of disk service[edit]

When first developed, nearly all LAN storage was based on the disk server model. This meant that if a client computer wanted to read a particular block from a particular file it would have to issue the following requests across the relatively slow LAN:

1. Read first block of directory
2. Continue reading subsequent directory blocks until the directory block containing the information on the desired file was found, could be many directory blocks
3. Read through multiple file entry blocks until the block containing the location of the desired file block was found, could be many directory blocks
4. Read the desired data block

NetWare, since it was based on a file service model, interacted with the client at the file API level:

1. Send file open request (if this hadn't already been done)
2. Send a request for the desired data from the file

All of the work of searching the directory to figure out where the desired data was physically located on the disk was performed at high speed locally on the server. By the mids, most NOS products had shifted from the disk service to the file service model. Today, the disk service model is making a comeback, see SAN.

Aggressive caching[edit]

From the start, the NetWare design focused on servers with copious amounts of RAM. The entire file allocation table (FAT) was read into RAM when a volume was mounted, thereby requiring a minimum amount of RAM proportional to online disk space; adding a disk to a server would often require a RAM upgrade as well. Unlike most competing network operating systems prior to Windows NT, NetWare automatically used all otherwise unused RAM for caching active files, employing delayed write-backs to facilitate re-ordering of disk requests (elevator seeks). An unexpected shutdown could therefore corrupt data, making an uninterruptible power supply practically a mandatory part of a server installation.

The default dirty cache delay time was fixed at seconds in NetWare&#; versions 2.x. Starting with NetWare&#;&#;3.x, the dirty disk cache delay time and dirty directory cache delay time settings controlled the amount of time the server would cache changed ("dirty") data before saving (flushing) the data to a hard drive. The default setting of &#;seconds could be decreased to &#;seconds but not reduced to zero, while the maximum delay was 10&#;seconds. The option to increase the cache delay to 10&#;seconds provided a significant performance boost. Windows&#; and server do not allow adjustment to the cache delay time. Instead, they use an algorithm that adjusts cache delay.

Efficiency of NetWare Core Protocol (NCP)[edit]

Most network protocols in use at the time NetWare was developed didn't trust the network to deliver messages. A typical client file read would work something like this:

1. Client sends read request to server
2. Server acknowledges request
3. Client acknowledges acknowledgement
4. Server sends requested data to client
5. Client acknowledges data
6. Server acknowledges acknowledgement

In contrast, NCP was based on the idea that networks worked perfectly most of the time, so the reply to a request served as the acknowledgement. Here is an example of a client read request using this model:

1. Client sends read request to server
2. Server sends requested data to client

All requests contained a sequence number, so if the client didn't receive a response within an appropriate amount of time it would re-send the request with the same sequence number. If the server had already processed the request it would resend the cached response, if it had not yet had time to process the request it would only send a "positive acknowledgement". The bottom line to this 'trust the network' approach was a 2/3 reduction in network transactions and the associated latency.

Non-preemptive OS designed for network services[edit]

One of the raging debates of the s was whether it was more appropriate for network file service to be performed by a software layer running on top of a general purpose operating system, or by a special purpose operating system. NetWare was a special purpose operating system, not a timesharing OS. It was written from the ground up as a platform for client-server processing services. Initially it focused on file and print services, but later demonstrated its flexibility by running database, email, web and other services as well. It also performed efficiently as a router, supporting IPX, TCP/IP, and Appletalk, though it never offered the flexibility of a 'hardware' router.

In 4.x and earlier versions, NetWare did not support preemption, virtual memory,^[28]graphical user interfaces, etc. Processes and services running under the NetWare OS were expected to be cooperative, that is to process a request and return control to the OS in a timely fashion. On the down side, this trust of application processes to manage themselves could lead to a misbehaving application bringing down the server.

See also[edit]

References[edit]