As with most software development cycles, the Novell NetWare network operating system has been subject to a number of major and minor version releases over time. This has resulted in the widespread use of a number of different versions of NetWare. Backup applications and tape drivers are always caught in the middle of these transitions. They are tasked with being able to use old and new tape hardware technology to backup data using previous and current versions of NetWare.

Earlier versions of NetWare made use of a monolithic driver architecture known as DDFS (Device Driver Functional Specification), in which adapters and peripherals such as disks and tapes used drivers having the file extension ".DSK".

Adding new devices to the monolithic architecture was problematic, so Novell introduced a new driver architecture called NWPA (NetWare Peripheral Architecture). With NWPA, a driver having the file extension ".CDM" (custom device module) is used to control the peripheral, and a separate driver having the file extension ".HAM" (host adapter module) is used for the adapter or controller.

Although NWPA was adopted as the system of preference, the "old" DDFS architecture continued to be supported until NetWare Version 5.0. In addition, new minor releases in the NetWare 3 and NetWare 4 series were subsequently issued with support for both DDFS and NWPA. Downloadable "patches" were also made available to allow users with NetWare 3 and NetWare 4 to use the new NWPA architecture.

This can be summarized as follows:

It is clear that, irrespective of the operating system version or tape drive vendor, problems are sometimes experienced by users attempting to set up NetWare systems with backup applications (particularly using NWPA architecture) to perform tape backups.

As of Jan. 1st 1998, Novell’s policy is to only certify new systems if they are compliant with the NWPA driver architecture (that is, adapter drivers with the ".HAM" file extension, and tape and other device drivers with the ".CDM" file extension).

The NWPA driver architecture can be used with NetWare 3 / 4, (providing the appropriate patches have been loaded - see http://support.novell.com/misc/patlst.htm) and with NetWare 5.

The NWPA driver architecture replaces the DDFS monolithic ".DSK" driver architecture used with NetWare 3 and NetWare 4. The DDFS driver architecture is not supported by NetWare 5. Backup applications that depended on ". dsk" drivers for NetWare 3 and NetWare 4 must be changed to depend on ".CDM" drivers for those versions plus NetWare 5.

Novell introduced NWPA with NetWare 4, as an alternative to the DDFS driver architecture (which originated as a way of controlling disk drives - hence the driver extension ".DSK"). NWPA enabled NetWare to easily and dynamically support a wide range of peripheral devices - something not so easily achieved with the "monolithic" DDFS architecture. The NWPA architecture has lead to the ability to support flexible server management. For new server systems "Hot Swap/Hot Add" of storage adapters is achieved via instance loading and unloading of the drivers.

NWPA has been designed from the ground-up to dynamically support many different devices. It uses a layered driver structure, as used in many other operating systems. This allows different abstractions of devices to be used at various layers in the driver architecture.

For example, for SCSI tape drives, at the lowest level would be (one or more) SCSI Host Bus Adapter (HBA) driver(s). These drivers have the extension ".HAM" (host adapter module). On top of these would be layered (one or more) Tape Drive driver(s). These drivers have the extension ".CDM" (custom device module - in this case, a tape class driver).

Tape Class drivers are mainly used by Novell’s built-in backup applications - SBackup for NetWare 3 / 4) and SBCON for NetWare 5. Further services can be layered on top of the class driver modules, such as NetWare 5’s SMS (Storage Management Services). SBCON and by many other backup applications use SMS to provide media management abstraction.

As with the DDFS architecture, Independent Software Vendor (ISV) backup applications tend to use the ASPI (Advanced SCSI Programming Interface)™ layer to communicate with tape drives. Therefore, when using backup applications such as BackupExec™ and ArcServeIT™, the ASPI layer driver must be loaded in place of the normal tape driver. The server should either have the normal tape driver loaded or the ASPI layer driver, but never both at the same time.

Typical DDFS drivers Used for Tape Drives

The following tables list typical DDFS drivers used for tape drives on NetWare 3 / 4 systems.

NWPA Drivers Used for Tape Drives

NWPA supports dynamic loading/unloading of drivers, and will auto-load certain drivers if it recognizes supported devices. For example, once an HBA ".HAM" driver is loaded, if an operational tape drive is found on the SCSI bus that is supported by the SCSI2TP.CDM (NetWare 3 / NetWare 4) or NWTAPE.CDM (NetWare 4.2 and 5) tape device drivers, NWPA should auto-load the tape device driver. The NWAPSI.CDM driver is not auto-loaded by NWPA. It must be included in the STARTUP.NCF file to be loaded at server boot time.

Novell ships a built-in backup application with its NetWare operating systems.

For NetWare versions prior to NetWare 5.0, the backup application is called SBackup. It supports scheduling, full / differential / incremental backup strategies and monitoring of "jobs." It does not support Autoloaders.

The NetWare 5 backup application is SBCON. It supports scheduling, full / differential / incremental backup strategies and mid-flow monitoring of "jobs." It also allows backups and restores to be administered from a remote client using the application NWBACK32.EXE. SBCON has Autoloader support built-in.

The NWPA architecture resides below an application interface layer called the Media Manager. The Media Manager layer provides a set of APIs that applications can use to access and control the storage devices. With Media Manager, NWPA, and correct drivers, there is no need for the application to address the device specifics. Many applications have been designed to use Media Manager. Novell's backup applications SBCON and SBackup also use the Media Manager APIs.

There are three ways for applications to communicate to devices.

1. Write a ".CDM" driver

2. Call NPA_CDM_Passthru API

3. Call NPA_HACB_Passthru API

Create a ".CDM" driver

Perhaps the most ideal tape device solution currently available in NetWare is to use a ".CDM" driver that is architected strictly for tape devices. The tape class driver contains code that can take optimal advantage of the features available in a tape device. The requests processed by the driver are not inhibited by the slow performance that is inherent in a pass-through solution. Applications that communicate with the tape device also have access to the device's features without the need to understand the explicit language and particulars of the device.

Passthru command support

The two other methods to ISV backup applications are available but not recommended for various reasons as discussed below.

The NWPA architecture provides ISV backup software the ability to communicate directly with tape drives. The API named NPA_HACB_Passthru is used to send requests to a device in order to receive status or diagnostic information about the device. The application must have an understanding of the device and handle any errors that occur as a result of the requests. The request types can be for either SCSI (type 1) or IDE (type 2) devices. This API bypasses the ".CDM" driver and communicates directly to any ".HAM" drivers and works for tape devices attached to any adapter. The architecture can handle custom requests to other vendor-specific tape types; however, in that case a custom ".HAM" driver is used. Using the NPA_HACB_Passthru is slow and should just be used for I/O control and should not be used for I/O read or write functions of the backup software.

The NPA_CDM_Passthru is slow also and is used to send vendor-specific requests to the managing ".CDM" of a tape device. This API sends I/O request functions (3E) or control functions (1E). The ".CDM" must understand the parameters being sent, and take the necessary action including specific requests to the device if needed.

Before NWPA existed, most ISV backup applications either built-in their own tape driver support via the DDFS interface or relied upon ASPI (Advanced SCSI Protocol Interface)™ from Adaptec. When NWPA was introduced, the backup applications that used DDFS support did not have ".CDM" drivers yet to cover their list of supported tape drives. The backup applications that used ASPITRAN.DSK from the DDFS interface did not have a NWPA solution either. Therefore, Novell was requested to do two things by tape vendors and ISV's of backup applications. The first request was to add support for specific tape devices to the NWTAPE.CDM module. Support for new devices is regularly being added to this module. The second request was to create an ASPI interface module for the NWPA architecture. This module is called NWASPI.CDM but Novell no longer owns the source code to it. NWASPI.CDM does not use Novell's Media Manager interface and may not keep pace with advances needed for operation on NetWare.

The NWASPI.CDM driver uses the services provided by the SCSI HBA ".HAM" driver. So, as long as the ".HAM" driver and NWASPI.CDM are loaded, ISV backup software can be used with NWPA. The NWASPI.CDM module is limited in handling messages from multiple applications. Its design causes security problems on NetWare because devices are not registered exclusively, this allows multiple applications access to the same device, which can lead to data corruption. The ASPI protocol does not support certain features from the SCSI-2 protocol specification, which may be of concern to developers on NetWare. It does not support tagged command queuing, linking, message phase control, disconnect/reconnect control, narrow/wide negotiation, and synchronous negotiation. ASPI does support synchronous, wide, and disconnected transfers, but not the setup control of them.