Scripting Has Never Been More Powerful

The days of writing NLMs are all but gone. Those beasts had a cryptic API, confusing documentation and scarce support from Novell. But starting with NetWare 4, Novell has opened its API to developers through the NetWare Developer Kit. Using the NDK, developers can code in ActiveX, C/C++, Java and various scripting languages. NetWare 5 has full support for JavaScript, NetBasic 6.0, Novell Script, PERL 5, REXX and ScriptEase.



Universal Component System

Novell’s UCS (Universal Component System) exposes NetWare services to the scripting engines regardless of the underlying scripting language. UCS is a scripting-language interpreter that lets programmers develop scripting applications using various components implemented as JavaBeans, Java classes, CORBA (Common Object Request Broker Architecture) objects, UCX (Universal Component Extension) objects (which are C or C++ objects for NetWare/UCS), or even ActiveX and OLE Automation objects running on a remote Win32 machine. All access is achieved through a single homogenous interface.

The system acts as a conversion layer between the programming languages and the reusable components.

An example of a UCS-supported script is the snippet of PERL code at right. This code logs a user into an NDS tree under a particular context and lists the available objects. Many similar scripts are available on Novell’s NDK Web site.

Novell Script for NetWare

Your first stop for NetWare scripting is Novell’s own Novell Script for NetWare. The most noticeable feature is its complete compatibility with Microsoft’s VBScript. It supports true software component semantics, allowing the use of functions, properties and events much as you would use ActiveX components on Win32. Novell Script replaces the NMX architecture of NetBasic 6.0 with UCS.

Because Novell Script is both BASIC- and VBScript-compatible, you can leverage your BASIC, VBScript and Visual Basic programming skills while using the power of NetWare services. Unlike its Microsoft Windows counterpart, the Novell Script seamlessly integrates with Java classes and nonvisual JavaBean software components.


PERL has its roots in Unix. However, Novell has ported PERL to NetWare, which is interesting since the PERL community had ported it to almost all other platforms with minimal help from vendors. PERL’s process-, file- and text-manipulation facilities make it ideal for tasks involving prototyping, software tools, database access, graphical programming, networking and system management.

NetWare 5 supports extended PERL syntax. Extensions may be developed in C and linked into your PERL scripts, making any component appear as merely another PERL function. You also can code your main functionality in C and then invoke PERL code on the fly. Novell has a special version of PERL that is UCS-enabled, so you can use any UCS object from PERL just as you would through the native NetBasic as shown in the UCS-supported script at lower left.


Ease of use was a primary goal in the design of REXX, making it usable by both the professional programmer and the casual user in need of a quick fix. Everything in REXX is handled as a text string, obviating data typing and conversions. REXX is used to execute and monitor programs, and it can take specified actions based on the output of the programs it’s monitoring. REXXware, developed by Simware, is an implementation of REXX for NetWare. On NetWare, REXXware’s features include clib calls for specific NetWare functions, a compiler, a scheduler, NDS library support and events support. REXXware also ships with a complete NDS administration application for helpdesk environments.

Rapid Application Development

As mentioned, UCS lets programmers use scripting languages to invoke external components to perform various OS functions. Novell takes this concept one step further with ready-to-use components that expose the majority-if not all-of the services available to NetWare programmers. These components come in two flavors: ActiveX components to be used from within COM (Component Object Module)-capable calling environments such as ASP (Active Server Page), Visual Studio and WSH (Windows Scripting Host), and Beans for Novell Services. As the name implies, the last are JavaBeans that can be used on the server to abstract significant NetWare networking services and data sources.

Win32 and Scripting

Almost any scripting language available for Unix is available for Win32 in a native format: no OS middleware, no fuss-just install and use. Some of the more common languages available for Win32 are PERL, Python, Tcl/Tk and most Unix shells. If you are serious about scripting on Win32, you should become intimately familiar with WSH. Until recently, the only native scripting language available for Microsoft OSes was the Command prompt and its associated scripting environment, which is limited at best. However, Microsoft recently changed that with WSH, a native environment that supports an assortment of scripting languages-much as UCS does on NetWare. WSH on its own is not a scripting language but a platform that enables the use of various scripting engines. The two engines available are VBScript and JavaScript. Microsoft expects other software companies to provide ActiveX scripting engines for other languages, such as PERL, Python, REXX and Tcl.

WSH controls ActiveX scripting engines, much as Microsoft Internet Explorer (IE) does on the client side and Internet Information Server (IIS) does on the server side for ASP pages. However, WSH has a much smaller footprint than either IE or IIS, making it ideal to run systems-administration scripts. Version 1.0 of WSH makes use of the script file’s extension, looked up the appropriate scripting engine in the registry and feeds the script to that engine (see “WSH 1.0 at Work,” below).

For example, a script file called rotate_logs.vbs would be run with the VBScript engine, and delete_logs.js would be executed using JavaScript. Running scripts under WSH 1.0 is limited in use without the availability of an object model. For security reasons, neither the scripts nor the script engines could connect to the operating system resources. Pressure from the WSH newsgroup opened Microsoft’s eyes to the weaknesses of WSH 1.0, and WSH 2.0 was introduced to rectify these shortcomings.

Administering Windows

ADSI (Active Directory Service Interface) extracts the capabilities of various directory services from different network vendors to present a single set of directory-service interfaces for managing network resources. Administrators and developers can use ADSI to manage the resources in a directory service, no matter which network environment contains the resources. ADSI lets administrators automate common tasks such as adding users and groups, managing printers and setting permissions on network resources. Using ADSI, an administrator can develop easy-to-understand scripts to manage user accounts without relying on custom C++ or VB objects (see “Sample Add-User Script” below).

PERL, Python and Tcl for NT

PERL 5 for Win32 offers all the features available to the Unix programmer, plus it has specific functions to manipulate the Windows NT event log and to query the system registry. Additionally, modules allow for manipulation of user accounts and groups. Recent builds of PERL 5 require no registry entry, and their DLLs don’t have to be installed under the Windows folder. Thus, they easily can be shared off a network drive. The latest stable version of PERL is 5.6, which can be downloaded from Larry Wall, the creator of PERL, recently announced intentions to develop PERL 6 from scratch.

Another possibility for writing your administration scripts is to use Tcl/Tk. The Tcl script was created by John Ousterhout and counts more than half a million programmers among its users. Tk is a popular GUI toolkit that lets programmers create graphical programs very quickly. Tcl/Tk 8.3 is the latest stable release of the product and is available for a plethora of platforms-its installation on Win32 is a breeze. Visit for the latest downloads and useful Tcl extensions developed by fellow programmers.

I found Python easier to learn than PERL. Available for many platforms, Python is seeing its following grow rapidly. Installation on Win32 is a snap, and the documentation is abundant. You can easily run it from the command line just as you could PERL and Tcl. I do wait for the day, however, when all three languages can be plugged into WSH, simplifying the work of Win32 administrators. You can check out for more information-like the fact that Python is not named after the snake but the British comedy troupe Monty Python.

Leave a Reply