CNE Training Guide NetWare 4.1 Administration

Previous chapterNext chapterContents


- 6 -

Customizing the NetWare 4.x User Environment


Before users can use the network effectively, the network environment needs to be set up correctly. In this chapter, you'll be shown how to customize a user's network environment, a process that consists of setting up the workstation environment and login scripts, implementing user account restrictions, writing custom login scripts, and simplifying access to NetWare applications using the Novell menus.

In this chapter, you learn about the different types of login scripts used in NetWare 4.x: system, profile, user, and default. You also learn when to use each type of login script. You learn the different components of a NetWare 4.x menu system and learn to how to write a menu script file.

Defining the User Network Environment

The network environment is where the user interacts with the network. Therefore it must be set up with a great amount of planning and attention to detail. This chapter discusses the different types of start-up files for the individual DOS workstation and the network environment. Much of the attention to detail is in organizing the network start-up files, called login scripts.

The login script commands and script variables that make up the network start-up files will be explored, along with recommendations on how to organize the login scripts to keep them simple and understandable.

Preparing the PC as a Workstation

When DOS is used to boot a PC, the PC has no idea that it will be used as a workstation on a NetWare LAN. Most varieties of DOS do not have any inherent capability to work with a network (Novell DOS 7 does). Instead, network capability must be added to DOS, which is accomplished by running a series of TSR (terminate-and-stay-resident) programs that remain running in the background while DOS is being used on the workstation. These TSRs include the ODI drivers, Link Support Layer (LSL.COM), the VLM manager (VLM.EXE), and the driver for the network board. You need at least four files, such as LSL, NE2000, IRTODF, and VLM. Collectively, these files are called the DOS Requester, because they enable DOS programs to request network or local DOS services.

Even though nothing is in the CONFIG.SYS file to suggest that a PC is being used as a NetWare workstation, certain configuration commands in the CONFIG.SYS file can have an important effect on using the PC as a NetWare workstation.

How DOS Is Loaded

It's very helpful to have knowledge of what takes place behind the scenes when DOS first loads. Certain problems that can occur during the processing of network login scripts become clear when you understand the DOS load process.

When a system is first powered up, it automatically jumps to location memory 0FFFF0 hex, and begins executing the program starting at that location. This is a feature of all of the Intel 80x86 family of microprocessors--80286, 80386, 80486, and 80586 (Pentium)--and is independent of any operating system such as DOS, OS/2, or Unix that may be running on the PC. The special location 0FFFF0 hex lies in a location in the ROM of the PC, and performs a Power On Self-Test (POST) process that checks RAM integrity, the keyboard, system clock, and other devices. After a successful POST, control is transferred to the bootstrap program, which is part of the BIOS, as shown in figure 6.1. Most often, the process of starting a PC is called booting, a term derived from this bootstrap program.

Figure 6.1 Memory map when control is transferred to bootstrap program.

The bootstrap program reads the first sector on the boot media (floppy disk in drive A or hard disk drive C), which contains the rest of the bootstrap program and information on the disk. After reading the rest of the bootstrap program in an arbitrary location in memory, the system transfers control to it (see fig. 6.2).

Figure 6.2 Memory map on loading disk bootstrap program.

The bootstrap program then checks for the existence of a copy of the operating system. For MS-DOS, this is done by checking for the two files IO.SYS and MSDOS.SYS, in that order. For IBM PC-DOS, these two files are IBMBIO.SYS and IBMDOS.SYS. If these files are missing, you are prompted with the error message:

Non-System disk or disk error
Replace and strike a key when ready 

This message appears when the NetWare workstation software is copied onto a disk that has not been properly prepared using the FORMAT /S or SYS commands under DOS.

If the two system files are found, they are read into memory and control is transferred to the program in IO.SYS. In some systems the IO.SYS loads first, and this in turn reads MSDOS.SYS in memory. The IO.SYS file actually consists of two parts:

Next, SYSINIT performs the initialization programs--in MS-DOS they carry out tasks such as:

After the system initialization program is run, the MS-DOS copyright message is displayed. The basic MS-DOS system is loaded at this point. SYSINIT makes use of MS-DOS file services to open the CONFIG.SYS file. The details of CONFIG.SYS file processing are discussed in the next section. If it's found, the entire CONFIG.SYS file is loaded in memory and each line in the file is processed. Any device drivers loaded by DEVICE or DEVICEHIGH= commands are processed in the order in which they're found and loaded in memory. For DR DOS, a statement with a ? before it causes the system to prompt the user if that statement should be processed. With MS-DOS 6 and above, pressing the F8 key causes the system to display each line in the CONFIG.SYS file (and AUTOEXEC.BAT file) and prompt you if you want to execute this line.

After all the installable device drivers are loaded, SYSINIT closes all files it has opened and opens the console (CON), printer (PRN), and auxiliary (AUX) devices as standard input, standard output, and standard error devices.

Finally, SYSINIT calls the MS-DOS EXEC function to load the command-line interpreter COMMAND.COM, which is located on the boot media or specified by the SHELL= statement in CONFIG.SYS file. To save on memory, the COMMAND.COM file is actually loaded in two parts:

1. Resident part, loaded in lower memory

2. Transient part, loaded just below the 640 KB limit

The resident part, as the name implies, is always resident in RAM, whereas the transient portion of COMMAND.COM can be written over by applications that are big enough to fill the entire 640 KB. After the application exits, DOS reloads the transient portion from a copy of the COMMAND.COM indicated by the COMSPEC environment variable, whose default value is set by the COMMAND.COM path in the SHELL= statement in the CONFIG.SYS file. This last point is important to remember because it's the cause of the Invalid COMMAND.COM_ System Halted error message that's sometimes encountered with NetWare LANs. This issue will be discussed again later in the chapter when the setting of the login script variable COMSPEC is discussed.


PRACTICAL TIP: To load COMMAND.COM with sufficient environment variable space, use the SHELL statement as follows:

SHELL=COMMAND.COM /P /E:800

The preceding statement specifies an environment variable space of 800 bytes, which should be adequate for most NetWare DOS workstations. Replace 800 with a larger value if you need additional environment variable space.


After SYSINIT performs its job, it's no longer needed and gets discarded. The final memory configuration looks similar to that shown in figure 6.3.

Figure 6.3 Final DOS map showing COMMAND.COM components.

If there is an AUTOEXEC.BAT file in the root directory of the boot media, it is read into memory and processed using the command line interpreter COMMAND.COM. If the AUTOEXEC.BAT file is not found, DOS will prompt you for the date and time, which is a good reason to create an AUTOEXEC.BAT file and have at least a statement such as the PROMPT $P$G in the file. For a NetWare DOS workstation, there may be an additional line such as:

@CALL C:\NWCLIENT\STARTNET.BAT

in the AUTOEXEC.BAT file that calls the STARTNET.BAT file. This file loads the ODI drivers and the NetWare DOS Requester that establishes a connection with the NetWare 4.x network.

NetWare workstation configuration involves four important files (see fig. 6.4) including:

Figure 6.4 Workstation configuration. The processing of these files is discussed in the following sections.


STUDY NOTE: The STARTNET.BAT, NET.CFG, CONFIG.SYS, and AUTOEXEC.BAT files are used to configure a NetWare DOS workstation.

DOS CONFIG.SYS Processing

A number of statements are in the CONFIG.SYS file that are important for a PC being set up as a NetWare workstation:

The SHELL= parameter uses the /P parameter to run AUTOEXEC.BAT and make the command-line interpreter permanent. The /E parameter tells how much space DOS should reserve for the environment variables. In a NetWare environment--where many applications are being run--you might want to increase this value if you receive the message Out of environment space. A good value to use is 800 bytes. Therefore, the SHELL= statement might look like the following:

SHELL=C:\DOS\COMMAND.COM /P /E:800

The C:\DOS\ specifies the pathname where the DOS COMMAND.COM file can be found. If you're using an earlier version of DOS (such as DOS 3.1), the environment space is measured in number of paragraphs, where each paragraph is 16 bytes.

The FILES= statement controls the number of files the workstation can have open locally. For example, if you want to increase the values of these parameters to 40 files, use the following statement in the CONFIG.SYS file:

FILES=40

The BUFFERS= parameter specifies the number of 512-byte blocks set aside for read and write operations. DOS reads and writes data in 512-byte sectors, and if there are a sufficient number of buffers in RAM, this can speed up file operations. In DR DOS, the HIBUFFERS= statement can be used to allocate buffers in high memory instead of conventional memory. A general rule of thumb is to have one buffer for every file you might want to open simultaneously. If you have no more than 20 files open simultaneously, set this to BUFFERS=20.

The LASTDRIVE= parameter specifies the last drive letter recognized by DOS. Its default value is E. In earlier NetWare versions where the NetWare shell was used, this value was used to determine the start of the network drives; this is the reason that the first network drive usually defaulted to the next available drive F. For the NetWare DOS Requester, you should set this value to:

LASTDRIVE=Z

The reason for this is that DOS and the NetWare DOS Requester share the same drive table (see fig. 6.5). When the older NetWare shell was used, the NetWare shell maintained a separate table for itself that was distinct from the DOS drive table.

Figure 6.5 Sharing of DOS drive table.


STUDY NOTE: NetWare 4.x DOS workstations should set the value of LASTDRIVE=Z in CONFIG.SYS.

Both the DEVICEHIGH= and DEVICE parameter load device drivers in memory. While the DEVICE parameter loads device drivers in conventional memory, DEVICEHIGH= loads the drivers in upper memory, leaving more space for applications to run in conventional memory. If you're interested in conserving conventional memory for applications, you should try to load as many device drivers in upper memory using DEVICEHIGH= as possible. In DR DOS, the equivalent command for loading drivers in upper memory is HIDEVICE=.


PRACTICAL TIP: If you're using MS DOS 6 or higher, use the memory optimizer program called MEMMAKER. MEMMAKER analyzes the current memory utilization and makes changes to the CONFIG.SYS file and AUTOEXEC.BAT file to leave more space for running applications in the conventional memory (memory below 640 KB).

If you use MEMMAKER, be patient; it takes quite a while to complete its analysis. You should also run MEMMAKER with the NetWare DOS Requester software loaded.


Setting BREAK=OFF prevents you from breaking out of programs by using Ctrl+C or Ctrl+Break keys until the program performs I/O operation on the screen or printer. Setting BREAK=OFF prevents users from breaking out of batch files.

Only the CONFIG.SYS parameters that have a more direct bearing on the network environment have been presented. For a more complete and comprehensive description of CONFIG.SYS parameters, consult your DOS manual or NRP's extensive DOS reference, Inside MS-DOS 6.2. In general, most other CONFIG.SYS parameters can be specified in the CONFIG.SYS file without adversely affecting the network workstation environment.

Here's an example of a CONFIG.SYS file used on one of the author's network workstations, giving you a sense of what can be placed in the CONFIG.SYS file without any problems:

DEVICE=C:\DOS\HIMEM.SYS
DOS=HIGH,UMB
DEVICEHIGH=C:\DOS5.0\SETVER.EXE
DEVICEHIGH=C:\DOS5.0\EMM386.EXE RAM 
FILES=40
BUFFERS=20
SHELL=C:\COMMAND.COM /P /E:800
LASTDRIVE=Z

AUTOEXEC.BAT Processing

After the CONFIG.SYS file has been processed, DOS uses the command-line interpreter to execute the commands in the AUTOEXEC.BAT file. DOS looks for the AUTOEXEC.BAT file in the root directory of the boot media. A fundamental difference exists between CONFIG.SYS and AUTOEXEC.BAT files in terms of the kinds of statements that can be placed in these files. The statements in the CONFIG.SYS file are special statements dealing with system configuration, whereas the statements in AUTOEXEC.BAT file can be any DOS internal or external commands and any applications that you'd normally load from the DOS command line.

For setting up an automatic start-up script for logging in to a NetWare network, you can place the following commands in AUTOEXEC.BAT file:

@ECHO OFF
PROMPT $P$G
PATH C:\LOCAL\APPS;C:\LOCAL\BIN
CALL C:\NWCLIENT\STARTNET.BAT

This example has a couple of interesting points. The @ in DOS versions 3.3 and higher stops the command on that line from being displayed. The ECHO OFF stops the commands in AUTOEXEC.BAT file from being displayed as they are executed. The PATH command sets up a local path environment.

The call to STARTNET.BAT loads all drivers and the VLMs. This is discussed next.


STUDY NOTE: The call to STARTNET.BAT file is usually placed in the AUTOEXEC.BAT file.

STARTNET.BAT Processing

The AUTOEXEC.BAT file transfers control to the STARTNET.BAT file. Alternatively, the STARTNET.BAT file can be invoked from the DOS command prompt. STARTNET.BAT is the standard file that contains the commands required to start the DOS Requester.

The NET.CFG file contains configuration information for the DOS Requester. Each of the DOS Requester files can have a parameter section in NET.CFG, and you'll need to know how to customize each section to complete configuration of a DOS workstation.

Here's a sample STARTNET.BAT file:

@ECHO OFF
C:
CD \NWCLIENT
SET NWLANGUAGE=ENGLISH
LSL
CEODI
IPXODI
VLM
CD \

The above STARTNET.BAT file starts up a default DOS Requester configuration. This basic STARTNET.BAT file is produced by the NetWare DOS client INSTALL program. First, the batch file changes the directory to C:\NWCLIENT--the standard location where the files that implement the NetWare DOS Requester, ODI drivers, and VLMs are installed. The NWLANGUAGE DOS environment variable is set to the language in which NetWare menu options and Help messages should appear for the user. NetWare 4 language support includes English, Spanish, German, Italian, and French. If the NWLANGUAGE environment variable is not specified, the default language is English.


STUDY NOTE: You can also specify the language environment for a user by setting the language property for the User object.

The next four commands load different components of the ODI drivers. First, the LSL.COM program is run to load the Link Support Layer. When loading, LSL.COM looks for configuration information in the Link Support section of NET.CFG.

Next, the ODI driver (also called the MLID--Multiple Link Interface Driver) is loaded. A specific ODI driver must be loaded for each brand of NIC. ODI drivers for many standard NICs are shipped with the DOS Requester files that accompany NetWare 4.x. Manufacturers also include ODI drivers on disks that accompany most NetWare-compatible NICs. In this example, the ODI driver is CEODI, which is used for Xircom's PCMCIA Credit Card Ethernet adapter driver. For a Novell NE2000 board, you replace CEODI with NE2000. When the ODI driver loads, it reads its configuration information from the Link Driver section of the NET.CFG file, which will be discussed later in this chapter.

After the ODI driver loads, the communication protocol must be loaded. The most common protocol on NetWare 4.x networks will be IPX, and in this example the IPXODI.COM is loaded. This implements the SPX/IPX protocol and the diagnostic responder. The diagnostic responder is used by some network management applications to report on network adapter statistics.

If the diagnostic responder isn't needed, it can be disabled using the /D switch:

IPXODI /D

Disabling the diagnostic responder can save about 3 KB of memory. SPX is used by remote console and remote printer support. NetWare core services bypass SPX and make use of IPX directly. If you're not running an application that needs SPX and you want to use less memory, you can use the following command to disable the diagnostic responder and SPX:

IPXODI /A

The /A switch results in a saving of 9 KB of memory. When the communication protocol loads, it looks for any special configuration settings for itself in the PROTCOL section of the NET.CFG file. For example, if there's more than one logical network board at the workstation, you must specify the logical board number IPX must bind to. This can be specified in the PROTOCOL IPX section of the NET.CFG files:

PROTOCOL IPX
BIND #2

In the preceding example, IPX is bound to board 2. The board 2 will have to be defined in the LINK DRIVER section of the NET.CFG file.


STUDY NOTE: The VLM Manager can be loaded only after the ODI interface support and the communication protocols are loaded.

NET.CFG Processing

After the communication protocol is loaded, the VLM Manager, implemented by VLM.EXE, is loaded. This loads the necessary VLMs (discussed in Chapter 1, "Introduction to NetWare 4.x") that make up the NetWare DOS Requester client software. The VLM Manager looks for its configuration information in the NetWare DOS Requester section of NET.CFG. A sample NET.CFG file is shown here:

Link Driver CEODI
     FRAME Ethernet_802.3
     FRAME Ethernet_802.2
     FRAME Ethernet_II
     INT  5
     PORT  380
     MEM  D0000
     IOWORDSIZE  16
Protocol IPX
     bind #2
NetWare DOS Requester
     FIRST NETWORK DRIVE = F
     NAME CONTEXT = "OU=CORP.O=SCS"
     Preferred Server=NW4KS


STUDY NOTE: For a NetWare 4.x workstation, one can expect to find at least the following statements in a NET.CFG file:
FRAME Ethernet_802.2
NetWare DOS Requester
FIRST NETWORK DRIVE
NAME CONTEXT

Many of the NET.CFG statements also apply to NetWare client configuration for using the older NetWare shell (NETX.COM or NETX.EXE) programs.

ETHERNET_802.2 is the standard Ethernet frame type used with NetWare 4.x. Prior to NetWare 4.x, the default frame type of ETHERNET_802.3 was used for Ethernet. This frame type did not have an explicit protocol identification field to identify whether the Ethernet frame was carrying IPX data. In a multi-protocol network environment, this made it difficult for routing devices to identify IPX packets. The ETHERNET_802.2 frame uses the LLC (Logical Link Control layer, also called the IEEE 802.2 header) header to identify the protocol data that is being carried. It uses a value of E0 (hexadecimal) in the DSAP (Destination Service Access Point) and the SSAP (Source Service Access Point) to identify that the packet data field contains an IPX packet.

Server LAN drivers written for NetWare 4.x and NetWare 3.12 use the ETHERNET_802.2 frame type by default. If all your servers use the ETHERNET_802.2 frame type, only that frame type needs to be configured on your workstations.

If a mix of older NetWare 3.11 (or earlier) networks is being used, you should also define the ETHERNET_802.3 frame so you can communicate with NetWare 3.11 servers.

If you're also using your workstation for TCP/IP client software, you should define the ETHERNET_II frame. Some TCP/IP software can work with ETHERNET_802.2 frame encapsulation, but the majority of TCP/IP software expects an ETHERNET_II frame encapsulation.

For Token Ring boards, the default frame type of TOKEN can still be used.

In the NetWare DOS Requester section, the FIRST NETWORK DRIVE is set to F:. It can be set to any other letter. A popular value is F: to maintain compatibility with the default NetWare 3.11 convention. Also, you might want to use F: if you've migrated from a NetWare 3.11 (or earlier) network to a NetWare 4.x network. Some programs and batch files might have a reference to the F: drive as a network drive. Not defining the F: drive as a network drive can cause these programs and batch files to fail.

The NAME CONTEXT defines the initial context of the workstation in the NDS tree. The context parameter must appear as a quoted string and have the complete name syntax, but should appear without a leading period. The name context value should be set to the container users can expect to have most of their resources defined.

The example of the NET.CFG shows a PREFERRED SERVER statement. This statement makes an initial attachment to the defined server. An initial attachment to a server is needed to access the LOGIN.EXE program in the SYS:LOGIN directory of a NetWare 4.x server. The LOGIN.EXE program is needed to log in to the NDS tree. When the LOGIN.EXE program runs, it prompts the user for a valid User object name and valid password.


PRACTICAL TIP: If the User objects and the server the user is attached to are defined in the same context, the login name of the User object can be typed instead of typing the NDS path for the User object.

To complete the login sequence, the user must change to the network drive and run the LOGIN.EXE program:

F:
LOGIN 

Because the preceding statements aren't added by default to the STARTNET.BAT by the NetWare DOS client INSTALL program, you might want to add them explicitly, as shown in figure 6.6.

Figure 6.6 Placing LOGIN.EXE in STARTNET.BAT.


AUTHOR'S NOTE: If you add the command to log in the STARTNET.BAT, you should place the call to STARTNET.BAT in the AUTOEXEC.BAT file after the PATH statement in the AUTOEXEC.BAT file. If the PATH statement is run after the STARTNET.BAT is run and the login is complete, it can wipe out your network drive mappings.


STUDY NOTE: The NET.CFG file contains configuration parameters for each of the ODI layers. The following list shows which NET.CFG section contains configuration information for each of the layers:
Link Support Layer (LSL.COM) parameters appear in the LINK SUPPORT section

MLID (BOARDNAME.COM) parameters appear in the LINK DRIVER section
Protocol (IPXODI.COM) parameters appear in the PROTOCOL section
DOS Requester (VLM.EXE) parameters appear in the NetWare DOS Requester section


Login Validation and Account Restrictions

Figure 6.7 shows the login validation that takes place when a user logs in. An unusual aspect of the login name validation is that if an incorrect user name is typed, access is denied. In NetWare 3.x (and other systems), the LOGIN program waits for you to type in an incorrect password before displaying the Access denied message. In NetWare 3.x, it's not possible to guess whether you typed in the user name incorrectly or the password incorrectly.

Figure 6.7 Login name and password validation.

In NetWare 4.x, if you type in the user name incorrectly, you're informed about it--even before you type in the complete password. This might seem to be a less secure mechanism, but it alerts the user that the user name is incorrect early in the login process. One reason for this could be the following: In NetWare 4.x, user names might have to be specified using the NDS path. This is considerably more complex than the simpler user names used in NetWare 3.x, and many more typing mistakes can be made. By alerting the user that the user name was typed incorrectly, the user can take corrective action. Otherwise, it can increase the frustration level of users and place an additional burden on the system administrator. For sites that are concerned about sec-urity, enabling intruder detection can reduce the likelihood that an intruder will guess a valid user ID and password combination.

After the user name and password are validated, other account restrictions may apply, including:

Details of these types of restrictions were presented in Chapter 5, "NetWare Directory Services Security." These tasks can be performed using the NetWare Administrator or the NETADMIN utility.

Processing of Network Requests

When the VLM.EXE loads, it sets up the first network drive to map to the SYS:LOGIN directory of a NetWare server. The first network drive is specified in the FIRST NETWORK DRIVE statement in the NET.CFG file. Changing to this drive and invoking the LOGIN program initiates the user-authentication process. The user has to supply the correct login name and password before access to a NetWare server is granted.

After logging in, the commands typed by the user are checked by DOS to see if they're local or network commands. Network commands are sent to the network services using the DOS redirector function defined for DOS 3.1 and above. Local commands are processed by the local workstation operating system. The networking software creates the illusion that the network is an extension of the workstation operating environment. This makes it possible for single-user applications to run on the network if they're set up correctly. Figures 6.8 and 6.9 show the kind of processing that takes place at the workstation and server to keep the network transparent to DOS.

If the DOS system call is for NetWare services such as access to a file on a network drive, DOS directs this request across the network to the server. In other words, DOS plays the role of traffic policeman or a redirector. The request is sent as a NetWare Core Protocol (NCP) packet encapsulated in an IPX datagram and passed on to the LAN drivers for the workstation (see fig. 6.8).

Figure 6.8 NetWare 4.x workstation makes system requests.

The LAN drivers encapsulate the IPX packet with data-link headers and send this packet across the network to the server. The server's LAN drivers strip the data-link header and pass the IPX packet to the IPX process on the server. The IPX process passes the IPX packet to the router process on the server. Remember: every NetWare server is capable of acting as an IPX router. The router process examines the destination address on the IPX packet and checks to see whether the IPX packet is destined to a different network than the one on which the IPX packet was received.

If the IPX packet belongs to a different network, the router process consults its routing table to determine which router the IPX packet should be sent to. The IPX header is then replaced by the address of the next router. This process continues until the IPX packet gets to its final destination.

If the router process discovers that no routing is necessary, it strips the IPX header and sends the original NCP request to the file-server process on the server.

The file server (see fig. 6.9) processes the request, and sends an NCP reply packet to the router and IPX process. The router process determines whether the packet needs to be routed. The NCP packet is encapsulated in an IPX packet and sent to the LAN drivers, which send it back to the workstation that made the request. At the workstation, the LAN drivers strip the data-link header and pass it on to the IPX software running at the workstation (IPXODI.COM). The IPX process at the workstation strips off the IPX header and sends the NCP reply packet to the NetWare Requester, which translates the original DOS request to a DOS system reply. The application that was waiting for the DOS system service then resumes--none the wiser about all the behind-the-scenes network activity it took to satisfy its request.

Figure 6.9 NetWare 4.x server replies to a workstation.

To set up the network environment, a network login script is processed when the user logs in successfully. The login script file is kept on the server and is similar in concept to the role the AUTOEXEC.BAT file plays for a single-user PC.

After the user logs in, a set of login scripts for the user can be executed. These login scripts are described in the following section.

Login Scripts

Many of the NetWare 3.x login script commands can be used with NetWare 4.x. NetWare 4.x includes a few additional login script commands, but the biggest difference is in the area of login script organization. In NetWare 3.x, there were three types of login scripts: system, user, and default login scripts. NetWare 4.x has an additional login script type called the profile login script. The scope of the system login script has changed also. In NetWare 3.x, the system login script applied to all user accounts defined on the file server. In NetWare 4.x, the system login script applies to user accounts for the container on which it is defined.

Login Script Types

NetWare 4.x supports four types of login scripts:

The system login script is a property of the Organization and Organizational Unit container objects. The profile login script is a property of the Profile leaf object. The user login script is a property of the User object. The default login script doesn't exist as an object or a property; it's contained in the LOGIN.EXE utility used for logging in to the network. Because login scripts are properties of objects, NDS tools (such as the NETADMIN or the NetWare Administrator) can be used for creating and modifying login scripts. Each of these different login script types are discussed in the following sections.

System Login Script

The system login script is a property of the Organization and Organizational Unit container objects, and applies to all User objects defined in that container. This means that system login scripts are a convenient way of specifying the commands that should be executed for all users belonging to an organization or department (Organizational Unit) within the organization.


STUDY NOTE: The NDS objects that can contain the system login script are Organization and Organizational Unit objects.

The system login script is executed for only the immediate users in that container. In figure 6.10, the system login script for organization O=SCS applies only to users Admin, KSS, and Dei that are defined in that container. They do not apply to users Lisa, Janice, or Bill in container OU=ENG.O=SCS. The container OU=ENG has its own system login script, and this applies to users Lisa, Janice, and Bill. The container OU=SALES.O=SCS, in figure 6.10, doesn't have a system login script. This means that for users Nina, John, and Dorsh, there's no system login script. If a container doesn't have a system login script, it does not inherit the system login script from a Parent container.


AUTHOR'S NOTE: Inheritance of system login script from a Parent container unnecessarily complicates the network computing environment. For instance, if the system login script is removed from a Parent container, inheritance means that the user may execute the login script of the parent's Parent container. Execution of login script of a Parent container might not make sense because the login script usually makes references to network resources that are available to users in the container. These resources might not be available to User objects several levels down on the directory information tree.

Figure 6.10 Scope of system login script.

The system login script is the first type of login script that is executed and can be used to set up the general environment for all users in that container.

To create a system login script, you must highlight the container object using NETADMIN or NetWare Administration tool, and select its Login Script property for modification.

Profile Login Script

A profile login script is a property of the Profile object. The Profile object is a leaf object whose sole purpose is to contain the profile login script (see fig. 6.11). If a group of users has common needs, that group fits a certain profile. In this case, a Profile object can be assigned to each of the users.

Figure 6.11 Profile login script.

Every User object has a profile login script property (as well as a user login script property). The profile login script property for a user can contain the name of a Profile object. If the profile login property for a User object is set to a Profile object, the profile login script (property of the Profile object) is executed every time that user logs in. If the profile login property for a User object is not set, no profile login script is executed when that User object is logged in.


STUDY NOTE: The profile login script is set by assigning a Profile object to the User object's profile login property.

The profile login script is executed after the system login script, and only one profile login script can be assigned to a user's profile login property.

The profile login script seems to be similar to the system login script. What, then, is its purpose? The system login script applies to only User objects that are in the immediate container. There might be situations in which users belonging to different containers have a common need for setting up their user environment. The profile login script property for users can be set to the same Profile object, even if the User objects are defined in different containers. This makes it possible for users in different Parent containers to have a common login script.


PRACTICAL TIP: Use system login scripts to meet the common needs of users in a Parent container. For most organizational structures, this should be enough. Use the Profile object only if users in different departments or organizations need to have a common login script. Using profile login scripts can complicate future maintenance if the login requirements change. You might have to change the profile login script property of every User object. Use the NLIST command to search for users who have the same Profile object value for their profile login script property.


STUDY NOTE: The profile login script is executed after the system login script, but before the user login script.
A User object can have only one profile login script.

User Login Script

Every User object has a login script property (see fig. 6.12). The value for the login script property can be a sequence of login script commands. The same type of login script commands that are used for the system and profile login script can be used for user login scripts.


STUDY NOTE: The user login script is set by entering login script commands for the User object's user login property.

The user login script is executed after the profile login script (if any).

Figure 6.12 User login script.

The user login script can be used to customize a user's login environment. The other login scripts (system and profile) are used to share common login script commands with other users. A user may have special needs that are not addressed by these "group" login scripts. In that case, use the user login script to further customize the user's environment.

Default Login Script

The default login script is unlike all the other login scripts in the sense that the other login scripts can be modified, but the default login script cannot. The default login script is fixed and can be considered to be "contained" in the login program, LOGIN.EXE. It's meant to provide a minimum user environment in case a user logs in and doesn't have a user login script. This is certainly true the first time the user Admin logs in to a newly installed network. A newly installed network doesn't have any system, profile, or user login script set up. The Admin user can at least perform some basic administration without having to create drive mappings.

After a user login script is created for that user, the default login script won't execute for that user. In some situations, all the login script needs of a user can be met by the system login script or the profile login script. In this case, there is no need to have a user login script. However, since the user login script has not been set, the default login script executes in addition to any system and profile login scripts. One of the default actions the default login script performs is to set up a search drive mapping to SYS:PUBLIC. If the system or profile login script already maps a search drive to SYS:PUBLIC, a second search drive mapping to SYS:PUBLIC is created unless the user login script property is set, or the NO_DEFAULT login directive exists in the system or profile login script.


STUDY NOTE: The default login script is executed if the user login script is not set.

The default login script is contained in the LOGIN.EXE file.


The default login script file looks similar to the following. Comments (lines starting with REM) have been added by the author to illustrate certain points:

REM This sets up a greeting for the user
WRITE "Good %GREETING_TIME, %LOGIN_NAME."
REM This is similar to the DOS ECHO OFF command.
REM It stops the display of commands as they are executed.
MAP DISPLAY OFF
REM Error processing is not shown
MAP ERRORS
REM Map the first network drive (*1:) to the
REM root directory on volume SYS:
MAP *1:=SYS:
REM Map the first search drive to the SYS:PUBLIC directory
REM which contains some public system utilities that can
REM be executed by the user.
MAP S1:=SYS:PUBLIC
REM Turn on display of commands as they are processed
REM so that when the MAP command is executed, a listing
REM of the current drive mappings is displayed.
MAP DISPLAY ON
MAP

As you study this default login script, you'll see that the MAP command, which can be executed from the command line, can also be executed directly in the login script. Certain login script commands such as WRITE, MAP DISPLAY ON, and MAP DISPLAY OFF cannot be executed from the DOS prompt.

The commands in the login script files are interpreted by the LOGIN utility; this includes the MAP command. The MAP command is normally performed by a program named MAP.EXE, which is located in the SYS:PUBLIC directory. However, the first time you execute the MAP command in the login script you don't have a search drive mapping to the SYS:PUBLIC directory. Yet, somehow the MAP commands still work--regardless of an absence of a search path to the SYS:PUBLIC directory. The reason for this is that the MAP command is interpreted and not invoked as an external program.

The NO_DEFAULT Directive

The NO_DEFAULT directive in the system or profile login script can explicitly disable the execution of the default login script (see fig. 6.13). This is useful if you want to override the default mappings created when the user login script property is not set, but you don't want to set the user login property (because the login scripts of the system and/or profile login script are sufficient to set up the required user environment).


STUDY NOTE: The NO_DEFAULT directive is used to prevent the default login script from executing and is set in the system or profile login scripts.

Figure 6.13 The NO_DEFAULT login script command.

Login Script Execution Order

The order of execution for the login script types is illustrated in figure 6.14 and is also listed here. These steps are executed when the user logs in to a NetWare 4.x network:

1. If the container in which the User object resides has the system login script property set, the system login script is executed for that user.

2. If a user's profile login script property is set to a Profile object, the profile login script for that Profile object is executed for that user.

3. If a user's user login script property is set, the user login script for that User object is executed.

4. If a user's user login script property is not set, the default is executed unless the NO_DEFAULT login script command has been included in the system or profile login script.

Figure 6.14 Login script order.

Some examples might help illustrate the above rules. Figure 6.15 shows an example of the NDS tree for organization O=TEC that has a system login script.

Figure 6.15 Example of login script execution.

Under O=TEC there are two Organizational Unit objects. One of the Organizational Unit objects (OU=ENG) has a system login script, while the other (OU=EXP) doesn't. The users Admin, KSS, and Bill have a user login script, but user Charles does not. The user KSS also has a profile login script property set to the Profile object CN=Profile1.OU=ENG.O=TEC. The order of execution of login scripts for the different users is listed as follows: User KSS: User KSS's container has a system login script. Therefore, the system login script for OU=ENG is executed first. User KSS also has a profile login script. This is executed next. Finally, a check is made to see whether user KSS has a user login script. Because user KSS has a user login script, this is executed next. The order of login script executions for user KSS is:

User Bill: User Bill's container has a system login script. Therefore, the system login script for OU=ENG is executed first. User Bill doesn't have a profile login script. A check is made to see whether user Bill has a user login script. Because user Bill does have a user login script, this is executed next. The order of login script executions for user Bill is:

User Admin: User Admin's container has a system login script. Therefore, the system login script for O=TEC is executed first. User Admin does not have a profile login script. A check is made to see whether user Admin has a user login script. Because user Admin has a user login script, this is executed next. The order of login script executions for user Admin is:

User Charles: User Charles's container OU=EXP does not have a system login script. Therefore, no system login script is executed. User Charles does not have a profile login script. A check is made to see if user Charles has a user login script. Because user Charles does not have a user login script, the default login script is executed.


STUDY NOTE: The login script execution order is:

1. System login script

2. Profile login script

3. User login script or default login script if user login script property is not set


Upgrade Considerations for Login Scripts

When upgrading from an earlier NetWare version to NetWare 4.x, the first system login script encountered for a file server that's placed in a container object becomes the system login script property of that container object. Any subsequent system login scripts from file servers that are placed in the same container are ignored. It's important to upgrade the server that contains the most up-to-date version of the system login script first.


STUDY NOTE: The first system login script encountered for a file server that's placed in a container object becomes the system login script property of that container object.

Even though the earlier NetWare login scripts are compatible with NetWare 4.x, you should review the upgraded login scripts to see whether you can take advantage of the new NetWare 4.x features. If the directories you want to map as network drives are on Volume objects that are in a different context than the context where the users are defined, you'll have to modify the login script MAP commands to refer to the NDS name of Volume objects.

Rights to Execute Login Script Property Value

A login script is a property of an NDS object; the system login script is a property of the Organization or Organizational Unit container; the profile login script is a property of the Profile object; and the user login script is a property of the User object. For a User object to execute the login scripts when the User object is logged in, that User object must have certain rights to that login script property.

Containers are granted the Read property right to their login script. The User object in the container must have the Browse right to the container object and the Read property right to the login script to execute the system login script. The Browse right to the container is usually granted by inheritance. For example, it's typical in most NDS trees to make [Public] a trustee of [Root] with the Browse right. Users in a container inherit the Browse right.


STUDY NOTE: The User object in the container must have the Browse right to the container object and the Read property right to the login script to execute the system login script.
Containers are granted the Read property right to their login script (system login script).

Profile login scripts are assigned by setting a user's profile login script property to the name of the Profile object. The user needs to be made a trustee of the Profile object. When a user is made a trustee of the Profile object, the following rights are assigned by default to the user:

1. Browse object right to the Profile object

2. Read and Compare property rights to the All Properties of the Profile object

Because of the All Properties Read and Compare rights, the user also inherits these rights for the profile login script property.


STUDY NOTE: When a user is made a trustee of the Profile object, the user is given the Browse object right to the Profile object, and Read and Compare property rights to the All Properties of the Profile object.

Users are by default assigned Read and Write property rights to their user login script property. The Write property right lets users modify their own login scripts. In some network environments, it may not be desirable for users to modify their login scripts. In this case, the Write property right to the login script must be removed.


STUDY NOTE: By default, users are assigned Read and Write property rights to their user login script property.

NetWare Login Script Commands

As you saw in the example of the default login script earlier in this chapter, one of the most useful commands in login script processing is the MAP command.

Besides MAP, there are a number of useful commands that are discussed next. Consider the following simple login script:

MAP DISPLAY OFF
WRITE "Good %GREETING_TIME, %LOGIN_NAME"
MAP *1:=SYS:USERS/%LOGIN_NAME
MAP S1:=SYS:PUBLIC

The WRITE command displays text strings to the user's console. You might also notice in this example the use of the %GREETING_TIME and %LOGIN_NAME variables. These are called login script identifier variables and are discussed later. As you can probably guess, these variables represent character strings that can be used in commands such as WRITE "Good %GREETING_TIME, %LOGIN_NAME." For example, this statement may produce the following message:

Good Morning, KARANJIT.

The %GREETING_TIME evaluates to "Morning" and %LOGIN_NAME evaluates to the user's login name--in this case, KARANJIT. A word of caution, however: When used in a string, such as "Good %GREETING_TIME, %LOGIN_NAME," the script variables must be in capital letters to evaluate correctly.

In many cases, you'll be unable to accomplish a desired task using only the commands that are built into the login command processor. If you want to invoke external utilities, you must precede them with the # character. An external utility is any command that must be performed by a .COM or .EXE file. Therefore, invoking the utility NETUSER requires the following command in the login script file:

#NETUSER

Login script commands can have a maximum of 150 characters per line, and can be in upper- or lowercase. The case is not sensitive except in the case of login script variables in double quotes ("). Login script variables appearing in quotes must be preceded by % and must be in uppercase. Outside the quoted string, the login script variables can be upper- or lowercase.

Complexity of Login Script Files

One of the more powerful commands that can be used in a login script is the IF_ THEN conditional statement, which has the following general form:

IF <condition> THEN BEGIN
     <statements>
ELSE
     <statements>
     END

or

IF <condition> THEN <statement>

The IF statement in the login script file gives you the power of conditionally executing statements; that is, execute statements only if a certain condition is true. It can be used to customize a login script, but there is also a danger of making the login script too complicated, as shown in the following example of a system login script:

MAP DISPLAY OFF
BREAK OFF
FIRE PHASERS 3 TIMES
WRITE ""
WRITE "Good %GREETING_TIME, %LOGIN_NAME"
WRITE ""
WRITE "You have logged in to file server %FILE_SERVER"
WRITE "from station %NETWORK_ADDRESS:%P_STATION."
WRITE ""
WRITE "Your connection number is %STATION and you are"
WRITE "using shell %SHELL_TYPE on machine %SMACHINE."
WRITE "Your internal userid is %USER_ID"
WRITE ""
WRITE "Today is %DAY_OF_WEEK" %MONTH_NAME, %DAY %YEAR"
IF MEMBER OF "NONCIVILIAN" THEN
      WRITE "System time is %HOUR24:%MINUTE:%SECOND"
ELSE
      WRITE "System time is %HOUR:%MINUTE:%SECOND %AM_PM"
END

IF MONTH = "1" AND DAY = "1" THEN BEGIN

      WRITE "Happy new year %YEAR, %FULL_NAME"
END

IF SHORT_YEAR = "00" THEN WRITE "Have a nice new century!"

IF NDAY_OF_WEEK = "6" THEN
      WRITE "Have a good weekend!"
 IF NDAY_OF_WEEK > "1" AND NDAY_OF_WEEK < "7" THEN
      FDISPLAY SYS:MESSAGES/DAILY.MSG
ELSE
      DISPLAY SYS:MESSAGES/WEEKEND.MSG
END
IF MEMBER OF "ENGINEERING" THEN BEGIN
     IF DAY_OF_WEEK="TUESDAY" THEN
           WRITE "STAFF MEETING AT 3:00 PM"
     IF DAY_OF_WEEK="FRIDAY" THEN BEGIN
           WRITE "STATUS MEETING AT 3:30 PM."
           WRITE "BE THERE OR BE SQUARED!"
     END
END
MAP INS S1:=SYS:PUBLIC
MAP INS S2:=SYS:PUBLIC/%MACHINE/%OS/%OS_VERSION
IF MEMBER OF "PAYROLL" THEN BEGIN
      IF DAY_OF_WEEK="MONDAY" THEN
           WRITE "STAFF MEETING AT 1:00 PM IN CONF.RM. 303"
      IF DAY_OF_WEEK="FRIDAY" THEN
           WRITE "REVIEW MEETING AT 11:00 AM."
      END
      ATTACHB LAKSHMI/%LOGIN_NAME
      MAP L:=LAKSHMI/SYS:USERS/%LOGIN_NAME
END

COMSPEC=S2:COMMAND.COM

IF MEMBER OF "ACCOUNTING" THEN
      MAP INS S16:=SYS:APPS/AMRIT
END
IF MEMBER OF "WPUSERS" THEN
      MAP INS S16:=SYS:APPS/WP
END
IF MEMBER OF "PAYROLL" OR MEMBER OF "ACCOUNTING" THEN BEGIN
      MAP INS S16:=SYS:APPS/ADP
      MAP *2:=SYS:PAYROLL
END
IF LOGIN_NAME = "SUPERVISOR" THEN BEGIN
      MAP *1:=SYS:USERS/SUPER
      MAP *2:=SYS:SYSTEM
      MAP INS S2:=*2:
      MAP INS S3:=SYS:SYSTEM/NMUTILS
END

IF MEMBER OF "ACCOUNTING" THEN   #CAPTURE Q=ACCT_LASERQ NB TO=25

IF MEMBER OF "ENGINEERING" THEN BEGIN
      #CAPTURE Q=ENG_LASERQ NB NT TO=15
      IF ERROR_LEVEL <> "0" THEN BEGIN
           SEND "ERROR IN CAPTURE" TO TOM
           #EMAIL TOM "ERROR IN CAPTURE FOR %LOGIN_NAME"
      END
END
IF <EDITOR>="BRIEF" THEN
      MAP INS S16:=SYS:APPS/BRIEF
END
DOS SET X = "1"
ALOOP:
      SET X = [X] + "1"
      WRITE "VICTORY PARADE!"
IF <X> IS LESS THAN "7" THEN GOTO ALOOP
DRIVE *2:
DOS VERIFY ON
SET PROMPT = "$P$G"
MAP DISPLAY ON
MAP
EXIT "MENU  TOPAPPS"

The preceding system login script resembles a BASIC program more than a simple login script. Its only redeeming feature--besides the fact that it can work for a specific environment--is that it makes use of almost every type of script variable and login statement construct. The complexity makes the system login script difficult to maintain. When making changes for a specific group, it's easy to inadvertently make a mistake that could affect all the users on the system. The above example might seem extreme, but the author has seen more complex (worse) examples than the login script file used here.

Recommendations for Organizing Login Scripts

Over a period of time, the system login script file can become very complex (see previous section) as you try to adapt a common system login script file to a changing network environment.

You should keep the system login script file as simple as possible. The system login script should contain statements that are applicable for all users in that container. Preferably, there should be no IF ... THEN conditionals in the system login script, because these can become complex. Remember that changes you make at the system login script will be "seen" by users in that container. This also includes any mistakes that you make that will prevent users from logging in.

The system login script file can contain statements to display messages that are system-wide, as shown here:

REM **************************************************
REM *                                                *
REM * The system login script should  have           *
REM * simple statements of the type FDISPLAY         *
REM *                                                *
REM **************************************************
REM * Send a global display message
FDISPLAY SYS:MESSAGES/GLOBAL.MSG

When this system login script file is processed, it displays any global system messages that the supervisor may have kept in the message file SYS:MESSAGES/GLOBAL.MSG. Control is then transferred to the profile login script for the user--if one exists.

The profile login script can be used to group login scripts common to a group of users with similar needs (those who have a common network usage "profile" or requirement). An example of this could be users who work on a common project or have a common need for accessing directories and files. Because the users sharing a profile login script have similar needs, you should not have to use too many IF ... THEN ... ELSE statements. If you find yourself using too many IF ... THEN ... ELSE statements to implement exceptions to the rule, you probably need to make separate profile login scripts for users.

If a user has too many special needs and doesn't fit the profile login script, you should place the login script statements for the user in the user login script. The user login script can also be used for any special needs a user may have that cannot be accommodated easily in the system and profile login scripts.

Any of the login scripts can contain a statement of the form:

INCLUDE SYS:PUBLIC/SCRIPTS/COMMON.SCR

The INCLUDE statement means that the contents of the specified file, in this case SYS:PUBLIC/SCRIPTS/COMMON.SCR, are processed as login script commands. This is sometimes called the subroutine mechanism for login script processing by Novell. If all the users have a common script file, the COMMON.SCR can be used for them. The advantage of using the INCLUDE statement is that if the login script is to be changed, the COMMON.SCR file only needs to be changed once.

The individual script file can have the structure shown here:

MAP DISPLAY OFF
REM Greetings (optional)
WRITE "Good %GREETING_TIME, %LOGIN_NAME"
REM General logon messages
FDISPLAY SYS:USERS/MSGS/WEEKLY.TXT
REM Home Directory Mappings
MAP *1:=.CORP_SYS.CORP.SCS:USERS\%LOGIN_NAME
REM Search drive mappings
MAP INS S1:=.CORP_SYS.CORP.SCS:PUBLIC
MAP INS S2:=.CORP_SYS.CORP.SCS:PUBLIC\%MACHINE\%OS\%OS_VERSION
MAP INS S3:=.CORP_SYS.CORP.SCS:PUBLIC\BIN
MAP INS S4:=.ENG_SYS.ENG.SCS:APPS\CAD
REM Set COMSPEC environment variable
COMSPEC=S2:COMMAND.COM
REM Application directory mappings
MAP H:=.ENG_SYS.ENG.SCS:APPS\DATA
REM Any environment variable changes
SET PROMPT="$P$G"
REM Display mappings
MAP DISPLAY ON
MAP

The first few statements can be greeting statements. These are followed by drive mappings, including search drives. The COMSPEC variable must be set next to point to the correct copy of COMMAND.COM.

Individual messages can be printed next. Avoid using too many IF ... THEN conditionals, or else you'll have the same complexity evident in the example in the previous section. If you want to use conditionals such as IF MEMBER OF "GROUP" THEN ..., you can create a separate group.SCR file and specify it in the INCLUDE statement in the login script file for members of the group:

INCLUDE SYS:PUBLIC/SCRIPTS/group.SCR

Replace group with a name indicative of the group for whom special processing needs to be done. The users must have Read and File Scan rights ([ R F ]) in the SYS:PUBLIC/SCRIPTS directory.

The following commands can be used in login scripts:

These commands are discussed in the following sections.

Login Script Command: #

When placed before an external command, the # character provides external program execution. The general syntax of the command is:

# [path]filename parameters

The [path]filename specifies the full path name of the external command. The # must be the first character in the command line. As expected, you can execute any .EXE and .COM file under DOS. To execute a DOS batch file or a DOS internal command, you must invoke the command line processor using the following command:

#COMMAND /C batchOrInternal

where batchOrInternal is replaced by the name of a batch file or an internal command.

For example, to clear the screen from the login script, you can use the following DOS CLS internal command:

#COMMAND /C CLS

This method was the only way to clear a screen in earlier NetWare versions. In NetWare 4.x, you can make use of the explicit login command CLS to clear the screen:

CLS


AUTHOR'S NOTE: When executing an external command, you must make sure that the proper drive mappings and search drives have been set. That's because the external command executes in the context of the NetWare environment set up at the time of execution. You must have sufficient network rights in the directory where the program is located; minimum rights should be [R F].

When the external command is executed, the login program is still resident in RAM and is not released until termination of the login script processing. Therefore, loading TSRs during login processing is not advisable; it leaves a hole (where the login program was) when login script processing terminates.


Login Script Command: ATTACHB

The ATTACHB command can be used to attach to bindery-based servers. You can attach to a maximum of eight file servers. This command allows the attachment to other file servers without interrupting the current execution of the login script. The general syntax of the command is:

ATTACHB [fileserver[/username[;password]]]

If the fileserver, username, and password are not specified, you will be prompted for the variables you have not entered.


AUTHOR'S NOTE: Be careful about including password information in the login script file; anyone with Read access to the login script file can read the password, and this can compromise the security of your network.

Login Script Command: BREAK

The BREAK ON command lets you terminate the execution of your login script. The general syntax of the command is:

BREAK [ON | OFF]

If BREAK is ON, the command allows you to terminate the processing of your login script using Ctrl+C or Ctrl+Break. The default value is OFF.

The BREAK command is different from the DOS BREAK command, explained next.

Login Script Command: DOS BREAK

If DOS BREAK is set to ON, it enables the Ctrl+Break checking for DOS. With the CTRL_BREAK checking enabled, whenever a program sends a request to DOS, the request can be terminated using the Ctrl+Break key. This command is equivalent to the DOS BREAK command.

Login Script Command: COMSPEC

The COMSPEC specifies the directory DOS should use to load the command line processor COMMAND.COM. The general syntax is:

COMSPEC=[path]COMMAND.COM

It's possible to use a command-line processor other than COMMAND.COM, but such implementations are rare. The COMSPEC command directly sets the COMSPEC DOS environment variable.

Earlier in this chapter, the sequence of events for when DOS loads was described. It was explained that a transient portion of COMMAND.COM is loaded in the area of memory just below 640 KB. This is shown in figure 6.16, which also shows a general memory MAP for a DOS NetWare workstation.

Figure 6.16 Use of COMSPEC environment variable.

When a large program loads, it can overwrite the transient portion of DOS, and when this program exits, the transient portion of COMMAND.COM needs to be restored. DOS makes use of the COMSPEC environment variable to obtain a copy of COMMAND.COM. If the COMMAND.COM in memory and the one indicated by COMSPEC are for different versions of DOS, the workstation crashes with a message, Invalid COMMAND.COM. On a network, there's a potential for users using different versions of DOS, and therefore a potential for COMSPEC pointing to an incorrect version of DOS. The COMSPEC variable should be set to the correct directory. This can be done by using the following commands:

MAP S2:=SYS:PUBLIC/%MACHINE/%OS/%OS_VERSION
COMSPEC=S2:COMMAND.COM

For example, the SYS:PUBLIC/%MACHINE/%OS/%OS_VERSION evaluates to SYS:PUBLIC/IBM_PC/MSDOS/V6.00 for MS-DOS 6.00. You can place in this directory the MS-DOS utilities that will be used by the users on the network, and also a copy of MS-DOS 6.0 COMMAND.COM. This allows the sharing of DOS 6.0 utilities on the network, and also a single place where COMMAND.COM is located.

Another technique that can be used for users who always boot from the hard disk is to set COMSPEC as follows:

COMSPEC=C:\COMMAND.COM

This statement takes care of different versions of DOS on the workstation's hard disk.

OS/2 users should not set their COMSPEC variable as indicated here. In case a login script needs to be shared by OS/2 users and users using the VDM (Virtual DOS Machine), the OS/2 users should reset their value of the COMSPEC variable.

Login Script Command: CONTEXT

The CONTEXT statement can be used to change a user's context from the login script. The general syntax is:

CONTEXT  context

To set your context to OU=LAB.OU=INVE.O=ETC, you can use the login command:

CONTEXT OU=LAB.OU=INVE.O=ETC

or

CONTEXT LAB.INVE.ETC

To move one container above current context, you can use:

CONTEXT  .

To move two containers, above current context, you can use:

CONTEXT  ..

Login Script Command: DISPLAY

This command shows the contents of the specified file on the workstation screen. The exact characters are displayed including any control codes for printer and word processing formats. The general syntax is:

DISPLAY [pathname]file

where [pathname]file is the name of the file whose contents are displayed.

Login Script Command: FDISPLAY

This command shows the contents of the specified text file on the workstation screen. The text is formatted and filtered so that only the text itself is displayed. The general syntax is:

FDISPLAY [pathname]file

where [pathname]file is the name of the file whose contents are displayed.

Login Script Command: DOS SET or SET

This command can be used to set a DOS environment variable from within a login script. The general syntax is:

[option] [DOS] SET name = "value"

The [option] can be replaced by an optional keyword such as TEMP, TEMPORARY to signify that the variable is set only during the login script processing and does not affect the DOS environment. Replace name with the name of the environment variable and value with its actual value. The value must always be enclosed in the double quote (") characters.

Examples of the use of the SET command are:

SET PROMPT = "$P$G"         - for setting DOS prompt
SET FNAME =                 - for removing the definition of the  
                            - environment variable
SET Y = "1"
SET Y = <Y> + 1          

SET UDIR = "*1:\\USERS\\%LOGIN_NAME"

Notice that you can refer to a DOS environment variable by using the <> brackets around it. If you want to use an environment variable in a MAP command, you must precede it with a %.

SET NWPATH="Z:\APPS\BIN"
MAP INS S3:=%<NWPATH>

If you want to use the backslash character (\) in a string value, you must specify two backslashes:

SET   FILENAME = "F:\\PUBLIC\\TEMP\\KSSFILE"

The reason for this is that the single backslash character is used to indicate special character codes as shown below:

\r                    carriage return
\n                    new line
\"                    embed quotation marks in string
\7                    generate a beep sound (bell)

Login Script Command: SET TIME [ON | OFF]

Use SET TIME ON (default) to set your workstation's time to the server you first connect to. This is the default behavior. To override this default behavior, use the SET TIME OFF. In this case, the workstation's clock will not synchronize to the server clock.

Login Script Command: DOS VERIFY ON

When set to ON, this is used to verify that the data can be written to a local drive without an error. The default is OFF and the general syntax is:

DOS VERIFY [ON|OFF]

The NCOPY automatically does a read after write verify check and can be used to copy files to floppy disks. If you want to use the DOS COPY command, you should have:

DOS VERIFY ON

in the login script, for added reliability in making copies to floppy disks. The /V option can also be used with the DOS COPY command to produce the same effect.

Login Script Command: DRIVE

The DRIVE command can be used to specify which network drive will be the default drive. The general syntax is:

DRIVE [d: | *n:]

where d: represents a drive letter and *n represents a network drive number such as *1, *2, and so on. By default, the first network drive *1 is the default drive, but you can change this by specifying the new default drive in the DRIVE command.

Login Script Command: EXIT

Normally, execution terminates at the end of processing the individual user login script. The EXIT command can be used to prematurely terminate the login script processing or specify the command to be executed on termination. The general syntax is:

EXIT ["commandstring"]

where commandstring is replaced with the program name plus arguments of any command to be executed after login script termination. The length of commandstring (at the moment of writing this book) is limited to 14 characters. This is the same as the limitation in earlier NetWare versions.

Examples of the use of the EXIT command are:

EXIT                   - Simply terminates login processing
EXIT MENU              - Executes the MENU utility on termination
EXIT "F:USEREXEC.BAT"  - Executes USEREXEC.BAT in the default drive                          on termination

Avoid using the EXIT command in all but the last line in the individual login script, because the EXIT command terminates the processing of the login script and this may not be what you want to do.

If used in the system login script file, it stops the processing of the system login script and returns control to the DOS prompt. The individual login script file will be totally bypassed.

There may be times when using the EXIT command in the individual login script file can serve as a convenient means of escaping to the DOS prompt, but for properly designed script files, this should not be necessary.

Login Script Command: FIRE PHASERS

FIRE PHASERS is a popular command that produces the sound effects of firing phasers. It doesn't work from the DOS command line. The general syntax is:

FIRE PHASERS n TIMES

where n is replaced by a number from one to nine.

Examples are:

FIRE PHASERS 4 TIMES
FIRE PHASERS %NDAY_OF_WEEK TIMES

Login Script Command: GOTO

The GOTO command can be used to set up a "loop" in your login script. The general syntax is:

GOTO label

The label can be an identifier and must be specified in the current login script. The following example should make this clear.

SET Y = "1"
REM The line below shows how labels can be defined
LOOP:                 
     REM The indentation shown below is for purposes
     REM of clarity and readability of the login script.
     REM It is not a requirement.	
     REM Placing <> around Y tells the login processor
     REM that this is an environment variable whose value
     REM needs to be evaluated.
     SET Y = <Y> + "1"
     
     REM Do whatever login script processing
     REM that needs to be repeated, here.
     REM Place a condition for terminating the loop, otherwise
     REM you will repeat this loop indefinitely!
     IF <Y> <= "45" THEN GOTO LOOP

Set BREAK ON in the login script before experimenting with loops, just in case you want to break out of a loop you have created unintentionally.

Login Script Command: IF ... THEN ... ELSE

This is a statement that lets you execute certain commands conditionally. The general syntax is:

IF conditional(s) [AND|OR|NOR] conditional(s) THEN
      command
ELSE
      command
END

If the command is a series of statements, you must include a BEGIN on the previous line. IF statements can be nested to a maximum of 10 nested IF statements.

The conditional(s) can be generated by using the following operators:
Equal Not Equal
= !=
== <>
EQUAL NOT EQUAL
EQUALS DOES NOT EQUAL
NOT EQUAL TO
Greater and Less Than Relational Operators
> IS GREATER THAN
< IS LESS THAN
>= IS GREATER THAN OR EQUAL TO
<= IS LESS THAN OR EQUAL TO

Login Script Command: INCLUDE

The INCLUDE command indicates a level of direction for processing login scripts. It means that the content of the file specified in the INCLUDE statement is to be processed next, after which processing returns to the statement following the INCLUDE command. The general syntax is:

INCLUDE [pathname]filename

or

INCLUDE objectname

where [pathname]filename is the location of the file to be processed, and objectname is the name of the object whose login script you want to use. Container objects, Profile objects, and User objects have login scripts associated with them. For example, to execute the login script for the container OU=CORP.O=SCS, use the following:

INCLUDE OU=CORP.O=SCS


PRACTICAL TIP: INCLUDE commands can be nested up to any level--limited only by the memory available for processing. Don't use more than two levels of nesting or your login script will be difficult to figure out by others. You must have a minimum of [R F] rights to use the INCLUDE file.

Login Script Command: MACHINE

This can be used to set the value of the MACHINE login script variable. The MACHINE value can also be changed from the NET.CFG file. Here's the general syntax of the command:

MACHINE = machinename

where machinename is replaced by a name that can be up to 15 characters long. If a machine name is longer than 15 characters, it is truncated to conform to this limit. For example, to specify that a machine name is NECULTRA, use:

MACHINE = NECULTRA

Login Script Command: MAP

This has the same syntax and meaning as the NetWare MAP command found in the SYS:PUBLIC directory with a few extensions:

MAP DISPLAY [ON|OFF]
MAP ERRORS [ON|OFF]

The MAP DISPLAY ON shows the drive mappings when you log in. This is the default setting. To disable the MAP processing messages use MAP DISPLAY OFF.

MAP ERRORS ON displays serious error messages such as "The path to which you are mapping does not exist (not relocatable)." The default setting is ON. To disable the display of MAP errors, you can use the MAP ERRORS OFF. It's best to leave the MAP ERRORS to its default setting of ON.

When creating a login script that provides access to server volumes in other contexts, you can use the NDS name of the volume you're mapping to. For example, if you want to set a search drive to the ENGFS_SYS volume in container OU=LAB.OU=ENG.O=SCS, you can use the following:

MAP  INS S16: = .CN=ENGFS_SYS.OU=LAB.OU=ENG.O=SCS:PUBLIC/BIN

or

MAP INS S16: = .ENGFS_SYS.LAB.ENG.SCS:PUBLIC/BIN

Login Script Command: NO_DEFAULT

If you don't want to create a user login script and not have the default login script run, you can use the NO_DEFAULT command, which disables the execution of the default login script that would normally run if the user login script was not set.

Login Script Command: NOSWAP and SWAP

The LOGIN.EXE is normally in conventional memory when an external command is executed via the #. If there is insufficient memory available, LOGIN.EXE is swapped out to high memory, if available, or to the local hard disk. If you want to disable this swapping action, use the NOSWAP login command. In this case, if LOGIN.EXE cannot be held in conventional memory and run the external command, execution of the external command will fail.

You can revert to the default behavior by using the SWAP command.

Login Script Command: PAUSE or WAIT

This command creates a PAUSE in the execution of the login script. Its general syntax is:

PAUSE

or

WAIT

It can be used to pause the execution of the login script so that the messages do not scroll by before you have time to read them.

Login Script Command: PCCOMPATIBLE or COMPATIBLE

This is used to indicate that the workstation PC is IBM PC- compatible:

PCCOMPATIBLE

or

COMPATIBLE

If your machine is IBM PC-compatible, but you have changed the long machine or short machine name using the LONG MACHINE TYPE=, SHORT MACHINE TYPE= statements in the NET.CFG (older SHELL.CFG) file, you must use the PCCOMPATIBLE command to indicate to the shell that your machine is IBM PC-compatible. If you neglect to do this, graphical NetWare utilities such as SYSCON and FILER (that make use of the C-Worthy library routines) won't work correctly.

Login Script Command: REMARK or REM

This command is used to place comments in the login script file for enhancing the readability of the login script:

REM[ARK] [text]

or

* text

or

; text

Login Script Command: SHIFT

The LOGIN command can be used to pass variables after the LOGIN servername/username. These variables are referred to as %0, %1, %2, and so on.

Thus, in the login command:

LOGIN  WE_SERVE/LYDIA	PUBS GRAPHIC

the following variable assignments take place: %0 =WE_SERVE

%1 = LYDIA

%2 = PUBS %3 = GRAPHIC The %0 is always assigned to the file server being logged into, even if the file server name is not explicitly specified in the LOGIN command. The %1 is always mapped to the user's login name. The %2 and other parameters are mapped to the additional arguments on the LOGIN command line.

The SHIFT command shifts the variable assignments:

SHIFT [n]

where n can be a positive number for the number of variables you want to shift to the right, or a negative number for shifting to the left. If n is left out, the default value of 1 is assumed.

The main use of the SHIFT command is to sequence through a group of parameters specified in the command line. For instance, the following loop can be used to assign %2 to each of the parameters specified in the LOGIN command after the user name:

LOOP:
     IF "%2" = "VAL1" THEN Command
     IF "%2" = "VAL2" THEN Command
     IF "%2" = "VAL3" THEN Command

     SHIFT 1
IF "%2" <> "" THEN GOTO LOOP

This loop checks each of the parameters against a specific value, and if there's a match, performs the action specified in Command. The SHIFT 1 causes the %2 variable to be assigned to the next parameter, until there are no more parameters left to process; at that time, the conditional expression in the IF statement evaluates to false, and execution proceeds to the statement following the IF statement.

Login Script Command: LASTLOGINTIME

Used to display the last time the user logged in. Used for informational purposes.

Login Script Command: WRITE

This command is used to display a text message on the screen:

WRITE "text"

Text strings separated by a ";" are concatenated. For example, the two WRITE commands that follow will result in the same output.

WRITE "Good"; GREETING_TIME; ", %LOGIN_NAME"
WRITE "Good %GREETING_TIME, %LOGIN_NAME"

New NetWare 4.x-Specific Commands

For users already familiar with earlier versions of NetWare, the NetWare 4.x specific login script commands are summarized in table 6.1.

Table 6.1 NetWare 4.x-Specific Login Script Commands

Login Command Description
ATTACHB Attach to bindery-based servers. Can also attach to NetWare 4.x servers in bindery emulation mode.
CLS Clears screen. This had to be done by the #COMMAND /C CLS in earlier NetWare versions.
CONTEXT newcontext Can be used to change the user's context from login script.
INCLUDE NDS objectName Can be used to invoke login scripts that are properties of other NDS objects. The traditional INCLUDE filename used in earlier NetWare 3.x also works in NetWare 4.x.
LASTLOGINTIME Used to display the last time the user logged in. Used for informational purposes.
MAP CHANGE or MAP C Change drive from ordinary network drive to search drive and vice versa.
MAP NP No Prompt. Override existing map-ping without prompting user to verify the operation.
MAP P Map drive pointer to physical volume rather than the volume object.
NO_DEFAULT When used in system login script or profile login script, it can disable the default login script from running.
NO_SWAP NO_SWAP prevents LOGIN.EXE from being swapped out to high memory.
SWAP SWAP (default) can result in LOGIN.EXE being swapped out if there is insufficient memory to run LOGIN.EXE, especially when executing # commands.
PROFILE profobject Used to override the profile script assigned to a user or specified at the command line, and cause the user to execute a PROFILE script profobject.
SET_TIME [ON|OFF] SET_TIME ON is used to synchronize workstation time to server that is first attached to. This is the default behavior. SET_TIME OFF disables this default behavior.

Login Script Variables

This chapter has made many references to the login variables and there are many examples of their use throughout the chapter. Table 6.2 gives a formal definition of some of these script variables. The script variables are sometimes also referred to as login macros because they evaluate to a specific value. When used as part of a string or a path name, the percent character must be used before the script variable name. Property values for user objects can be accessed from login scripts by using their property names. In addition, certain login script variables are defined that use compound properties (combination of more than one property). An example of this is the HOME_DIRECTORY that evaluates to a concatenation of the volume name and the path of the user's home directory.

Table 6.2 Identifier Variables

Conditional Items Screen Display
ACCESS_SERVER Displays TRUE if access server is functional. Displays FALSE if not functional.
ERROR_LEVEL Displays the number of errors. If 0, no errors are found.
MEMBER OF group Displays TRUE if the user is a member of a specified group. Displays FALSE if the user is not a member of a specified group.
Date Screen Display
DAY Displays the day from 01 to 31.
DAY_OF_WEEK Displays the day of the week.
MONTH Displays the month from 01 to 12.
MONTH_NAME Displays the name of the month.
NDAY_OF_WEEK Displays the number of the weekday.
SHORT_YEAR Displays the year in short format, such as 94, 95, and so on.
YEAR Displays the year in full format, such as 1994, 1995, and so on.

DOS Environment Screen Display
<> Enables you to use any DOS environment variable as a string.
NETWORK_ADDRESS Displays the network number of the cabling system in eight hex digits.
FILE_SERVER Displays the name of the file server.
Time Screen Display
AM_PM Displays the time as day or night, using a.m. or p.m.
GREETING_TIME Displays the time of day as morning, afternoon, or evening.
HOUR Displays the time of day in hours, from 1 to 12.
HOUR24 Displays the hour in 24-hour time, from 00 to 23.
MINUTE Displays the minutes from 00 to 59.
SECOND Displays the seconds from 00 to 59.
User Screen Display
FULL_NAME Displays the full name of the user by using SYSCON information.
LOGIN_NAME Displays the user's login name.
USER_ID Displays the ID number of each user.
Workstation Screen Display
MACHINE Displays the machine from which the shell was written, such as IBMPC.
OS Displays the workstation's operating system, such as MS-DOS.
OS_VERSION Displays the DOS version of the workstation.
P_STATION Displays the station address or node address in 12 hex digits.
SMACHINE Displays the name of the machine in short format, such as IBM.
STATION Displays the connection number.

Novell Menus

Novell menus allow you to create a menu-driven user interface, where you have the choice of selecting the menu titles and the options in a specific menu. You can associate a number of commands with each option or specify that another submenu be invoked when an option is selected.

In NetWare 3.11 this was provided by Novell menus. The NetWare 3.11, Novell menus were adequate in simple situations, but many network administrators preferred the use of more robust third-party tools. An example of such a tool is the Saber menus. In NetWare 4.x, Novell has licensed the Saber menu technology and used it to build the Novell menus that are used with NetWare 4.x. Currently, the NetWare 4.x menus don't have the full functionality of the commercial Saber menu system package, but they're a vast improvement over the NetWare 3.x Novell menus. Starting with NetWare 3.12, the NetWare 3.x product line uses the NMENU utility. The NMENU implements the Novell menus. It is currently a batch file (NMENU.BAT) that invokes other utilities such as MENUEXE.EXE and MENUREST.EXE.

One of the improvements to the NetWare 4.x menu utility is the requirement for less memory, which allows programs that need more memory to be run from the NMENU utility.

A scripting language is used to create the source file for the NMENU utility. The source (.SRC extension) file is then compiled to produce a data file (.DAT extension). The data file is then used with an NMENU.BAT utility that interprets and executes the .DAT file. The steps to perform these operations are depicted in figure 6.17.

Figure 6.17 Novell menu compilation steps.

Older menu script files (.MNU extension) that were used with the scripting language of the NetWare 3.11 Novell menu utility can be converted to the NetWare 4.x menu script language by using a conversion tool called MENUCNVT.EXE. The conversion process is shown in figure 6.18.

Figure 6.18 Novell menu conversion process.


STUDY NOTE: Older menu scripts can be converted to NetWare menu scripts by using MENUCNVT.EXE.

If the older Novell menu script file is named MAIN.MNU, you can convert it by compiling and running the menu using the NetWare 4.x menu system. Perform the following steps:

MENUCNVT MAIN.MNU (Produces a MAIN.SRC file. Examine MAIN.SRC file and edit as necessary.)
MENUMAKE MAIN.SRC (Produces a MAIN.DAT file)
NMENU MAIN.DAT


STUDY NOTE: The MENUMAKE utility is used to compile the menu script (.SRC) file to the menu object file (.DAT).


PRACTICAL TIP: The MENUCNVT.EXE program does not always do a complete translation. You can expect to do some manual edits to the .SRC file to make the menus behave as expected.

Menu Temporary Files

When the Novell menus are executed using the command:

NMENU   compiledfile

where compiledfile contains the compiled menu description, a number of temporary files are created. These default files are created in the current directory, unless special environment variables are set. To create these temporary files, the user needs the following permissions:

The user has these rights in the home directory and the local hard disk, so these commands can be run from the home directory or local hard disk. If the machine is turned off or stops while running the NMENU program, temporary files are left behind. Some administrators may prefer to define a common directory where these temporary files are kept, because it makes it easy for the administrator to clean up old temporary files. To set NMENU to use a specific directory for holding NMENU temporary files, you can set the S_FILEDIR environment variable. For instance, to set the NMENU to use Z:\MENUDAT as a temporary directory, you can use the following:

SET S_FILEDIR=Z:\MENUDAT

in the workstation's AUTOEXEC.BAT file. Alternatively, you can set the following:

SET S_FILEDIR="Z:\MENUDAT"

in a login script file such as the system, profile, or user login script file.

A problem with using a common directory for holding temporary files is that the temporary file names are based on the user names. As long as the user names are unique, the temporary files are unique per user, and the Novell menus will work fine. But what if a user logs in more than one time using the same user name, and uses the Novell menus? This is possible unless the concurrent connections restriction number is kept to 1. In this case, the Novell menus will try to create a separate set of temporary files with names that already exist. The resulting name collisions cause Novell menus to not work properly. The solution is to have Novell menus create temporary files based on station connection number, which is unique, per-user session. If a user logs in using the same user account, each user session will have a different connection number, and a different set of temporary files for Novell menus.

The S_FILE environment variable can be used to determine how temporary files are to be named. This can be used to change temporary files to use the station connection number using the following command in a login script:

SET S_FILE="%STATION"

To set the Novell menus to use the user's home directory for temporary files, use the following command in a login script:

SET S_FILEDIR="SYS:USERS/%LOGIN_NAME"

Example Menu Script

A sample menu script file is shown here, and figure 6.19 shows the Novell menus resulting from it:

menu 01,Network Utilities
      item NetAdmin
           exec NETADMIN
      item NetUser	
           exec NETUSER
      item DOS Prompt
           exec DOS
      item Logout
           exec LOGOUT

Figure 6.19 NMENU display.

The name of the menu is called the menu title and is defined by the MENU command. Each of the options in the menu item are defined by the ITEM statement. The names of the programs to be executed when an option is selected is defined by the EXEC statement.

You will examine the details of the menu script in the following section.

Menu Parts

A NetWare menu can consist of four components (see fig. 6.20). The components are specified in the menu source file and are listed as follows:

1. A main menu that has a title and at least one option.

2. Commands to be executed when an option is selected.

3. Submenus that are displayed when an option is selected.

4. Prompts for user input.

The first two preceding parts are necessary. The remaining parts, such as the submenus and prompted user input, are optional.

Figure 6.20 Parts of a menu.

Menu Commands

As you saw in the earlier section, the principal menu commands are MENU, ITEM, and EXEC. The MENU and ITEM commands are used for organizing the structure and appearance of the menu. The EXEC command is used for controlling the execution of commands when a particular item is selected. In general, menu commands can be divided into two categories:

These two categories of commands are discussed in greater detail in the following section.


STUDY NOTE: Menu commands can be divided into the categories of organizational commands and control commands.

Organizational Commands

Organizational commands are responsible for the overall organization and contents of the menu; they also determine the appearance of the menu on the screen. Currently, only two commands are defined for this category:

Every menu and submenu is defined by a MENU command. The parameters for the MENU command are a menu number and the title of the menu:

MENU menuNumber,menuTitle

The menuNumber is unique per-menu, and it can be any number between 1 and 255. There is no special ordering relationship between the menu numbers and the menus that are displayed. The only requirement is that they be unique. There should not be any spaces between the menuNumber, the comma, and the menuTitle. The menuTitle is a string of characters that should not exceed 40 characters and is displayed at the top of the menu. It is used to identify the title of the menu.


STUDY NOTE: Novell menus have two organizational commands: MENU and ITEM.

If a menu is given a number of 5 and a title of "Available Options," its menu command should appear as the following:

MENU 5,Available Options

This command defines the start of the menu Available Options that's identified by the menu number 5.

The ITEM organizational command is used to define the option that is displayed for a menu. The items are listed in the order in which you want them to appear in the menu. An option consists of a text string parameter to the ITEM command. The general syntax of the ITEM command is:

ITEM  itemText { itemOption itemOption ... }

or

ITEM  ^tagchar itemText { itemOption itemOption ... }

In the first format for the ITEM command, every itemText is preceded by a letter that's automatically assigned by the Menu utility. The letters are from A to Z, with the first ITEM command being assigned A, the next B, and so on. These letters or item tags serve as a shortcut to selecting the option. Pressing the letter key corresponding to an option causes that menu item to be selected. The item tags do not determine the order in which the menu is displayed. The display order is determined by the order in which the items are listed. The itemText is the text string that you want displayed for the menu option. The itemOption is placed within { } braces, and can consist of zero or more item options that further qualify the menu option. The itemOption variable will be discussed in greater detail in the following section. An example of the syntax for the first format is:

ITEM    NetAdmin Tool { }

The itemText is "NetAdmin Tool," and there are no itemOptions specified. Therefore, the { } pair of braces are empty. If the braces { } are empty, they can be omitted.

ITEM Display Context
       EXEC CX

If this was the first ITEM listed under a MENU command, it would have a tag character of A; if this was the second item, its tag character would be B, and so on.

The second format for the command is similar to the first format. The difference is that ^tagchar can precede the itemText. The caret (^) character followed by a single character, the tagchar, allows this character to override the default letter assignment for that item. For example, if you want to use digits 1 to 6 to designate the menu options, you use the following:

ITEM  ^1First Option { }
ITEM  ^2Second Option { }
ITEM  ^3Third Option { }
ITEM  ^4Fourth Option { }
ITEM  ^5Fifth Option { }
ITEM  ^6Sixth Option { }

The item options are displayed in the order in which they're listed. The menu utility makes no attempt to sort them based on any tag characters you've specified. It's possible to mix ITEM statements that have tag characters with the ITEM statements that do not have tag characters:

MENU 01, NLIST and NDIR Menu
ITEM  Show all objects  {PAUSE}
      EXEC NLIST * /D /S /CO "[Root]"
ITEM  LIST Help
      EXEC NLIST /? ALL
ITEM  Change Context  {PAUSE}
      EXEC CX %
ITEM  ^XEXIT
      EXEC EXIT
ITEM  ^LExit and Logout
      EXEC LOGOUT

ITEM Options

The itemOptions that are placed in the { } braces in the ITEM command further qualify how the commands associated with the ITEM are executed. The list that follows shows the ITEM command and the commands that are executed when an item is selected:

ITEM Menu Option Text { }
      command 1
      command 2
              :
      command N

The commands that are executed when the ITEM is selected are listed immediately following the ITEM. These commands are preceded by one of the following key words: EXEC, LOAD, SHOW, GETO, GETR, or GETP. These commands will be discussed in greater detail in the next section.


STUDY NOTE: The commands for an ITEM follow immediately after the ITEM statement.

The commands following an ITEM statement can be EXEC, LOAD, SHOW, GETO, GETR, or GETP.



PRACTICAL TIP: It's not necessary to indent the commands in relationship to the ITEM command. However, indenting is recommended because it makes the menu script more readable.

The itemOption that can be placed in { } can be any of the following:

The BATCH item option is used to free up additional memory when running an application. The Novell NetWare 4.x menu utility by itself takes up 32 KB of RAM. For applications that take up a large amount of memory, it is desirable to use as much RAM as possible for the application. By using the BATCH option, the commands associated with the menu are written in a temporary batch file. The menu utility is removed from memory and the batch file is run. The last command in the batch file re-invokes the menu utility. To run the NETADMIN utility using a batch file, you use the following:

ITEM NetAdmin Utility {BATCH}
     EXEC NETADMIN


STUDY NOTE: Use the BATCH option when running large programs, or when you are unable to run a program from the menu utility because of insufficient memory.

The BATCH item option is used to free up memory taken by the Novell menu utility when running an application.



STUDY NOTE: The Novell NetWare 4.x menu utility takes up about 32 KB of RAM.

The CHDIR item option is used to restore the default directory to the one that existed prior to executing the command. Some programs give you the option of changing the default directory when they are run. After exiting these programs, you may be placed in a default directory that is different from the one that was in use prior to executing the program. It is often desirable to have the same default directory when programs are excepted from the menu utility.

Example:

To keep the same default directory for a progam called TELNET, throughout the execution of the menu utility, you could use the following:

ITEM Remote login via TELNET {CHDIR}
      EXEC TELNET


STUDY NOTE: The CHDIR item option is used to restore the default directory to the one that existed prior to executing the command.

The different item options can be combined. For example, to execute FILER as a batch file and to retain the same default directory, you could use the following:

ITEM Filer Utility {BATCH CHDIR}
     EXEC FILER


STUDY NOTE: To free memory taken up by the menu utility and restore the default directory to the one that existed prior to executing an application, combine the BATCH and CHDIR item options.

The order in which the item options are placed inside { } is not significant. Therefore, the preceding statements are equivalent to those listed here:

ITEM Filer Utility {CHDIR BATCH}
     EXEC FILER


PRACTICAL TIP: Use the CHDIR option consistently to always return to a known default directory.

The SHOW item option is used to display the name of the DOS command executed from the menu utility on the upper-left hand corner of the screen as it executes. This is particularly useful if the DOS command that is executing is passed a parameter, which is also displayed as the command executes. An example of this usage is shown as follows:

ITEM Directory Contents Listing {SHOW}
     EXEC DIR % 


STUDY NOTE: The SHOW item option is used to display the name of the DOS command executed from the menu utility on the upper-left hand corner of the screen as it executes.

The PAUSE option causes the message Press any key to continue at the end of executing the command(s). This gives the user an opportunity to read the screen before proceeding to the next step. The menu utility won't proceed to the next step unless the user presses a key. An example of using the PAUSE option is shown here:

ITEM Search for files that have "SCS (C)opyright"  {PAUSE}
     EXEC GREP  "SCS (C)opyright"  *.*


STUDY NOTE: Use the PAUSE option when running a utility that prints messages to the standard output or standard error stream and terminates. The standard output and standard error streams are set to the display console by default.

The PAUSE option causes the message Press any key to continue at the end of executing the command.

The PAUSE option can be combined with the SHOW option for many DOS commands that terminate after displaying their results.


Table 6.3 summarizes the different ITEM options that are discussed in this section.

Table 6.3 ITEM Options

Item Option Description Example
BATCH Frees up RAM menu utility (32 KB) when a program runs. ITEM Application {BATCH}
CHDIR Restores default directory to that which existed prior to running the commands associated with the menu item. ITEM Application {CHDIR}
SHOW Shows DOS commands on upper-left corner of screen as they execute. ITEM Application {SHOW}
PAUSE Pauses display, and waits for user to press a key, at end of executing a command. ITEM Application {PAUSE}

Menu Control Commands

The MENU and ITEM commands that were discussed in the previous section are used to determine the contents of a menu or submenu and the manner in which options should be displayed or run. The actual commands that are processed occur after the ITEM command. These commands are called control commands, and they are used to execute applications from within the menu utility (NMENU), load menu definitions kept in separate files, show submenus, and obtain user input. There are six control commands:

The first three control commands (EXEC, LOAD, SHOW) deal with executing programs and loading and displaying submenus. The last three (GETO, GETR, GETP) solicit input from the user, which can then be used as parameters for commands and programs that are executed.


STUDY NOTE: The EXEC (or EXECUTE) menu command is used to run an application.

The EXEC Control Command

The EXEC (or EXECUTE) command is used to run an application. The command that is run can be an .EXE, .COM, .BAT, an internal DOS command, or any of the following:

An example of using the EXEC command for a DOS internal command is shown here:

ITEM  ^DShow Directory listing {SHOW}
      EXEC DIR

An example of using the EXEC command for a NetWare .EXE program file is shown here:

ITEM  ^UNetwork User {BATCH}
      EXEC NETUSER

The EXEC DOS command runs a second copy of the command shell. For DOS, this is the COMMAND.COM command processor. When a second copy of the command shell runs, the user is presented with a command prompt and can type in any DOS or application command. The NMENU utility and the previous copy of the command shell are still loaded, so you are limited by the remaining memory available for your DOS application. An example of the use of the EXEC DOS command is shown here:

ITEM  Exit to DOS { }
      EXEC DOS

To return to the Novell menu utility, you must type the EXIT command at the command prompt. This terminates the second shell and returns you to the menu utility.


STUDY NOTE: The EXEC DOS command runs a second copy of the command shell, and allows users to run DOS commands from the second command interpreter.

You should be familiar with the differences among the EXEC DOS, EXEC EXIT, and EXEC LOGOUT commands.


For secure environments, you might want to control the applications a user can run on the network. In this case, you might want to restrict the users' access to the command prompt and not use the EXEC DOS command.


STUDY NOTE: To make the Novell menus secure, you should not use the EXEC DOS command in an item option.

If you want to give users the option of exiting the menu program completely and going to the DOS prompt, you can use the EXEC EXIT command. This command terminates the menu utility program, and causes the system to remove the program from memory. Control is returned to the command shell and the command prompt. If, for security reasons, you want to control a user's access to the command, you should not use the EXEC EXIT command. An example of the use of the EXEC EXIT command is shown here:

ITEM  Exit NMENU { }
      EXEC EXIT

In many environments, it's desirable to control a user's access to the command prompt; neither EXEC DOS nor EXEC EXIT are suitable for this purpose, because these give a user access to the command prompt. Yet, it's necessary for a user to terminate the use of the network and the Novell menus. To accomplish this, a special EXEC LOGOUT command has been defined. When the EXEC LOGOUT option is used, it logs the user out of the network and simultaneously terminates the Novell menu utility.

An example of the use of the EXEC LOGOUT command is shown here:

ITEM  Exit Novell Menus and logout { }
      EXEC LOGOUT


STUDY NOTE: To make a menu secure, you can exit the Novell menus using the EXEC LOGOUT control command.

Table 6.4 summarizes the different EXEC commands that can be used.

Table 6.4 EXEC Command Summary

EXEC Type Description
EXEC command Replaces command with a DOS internal/external command, an .EXE or .COM pro-gram file, or a DOS batch file.
EXEC DOS Starts a secondary shell and gives user access to the command prompt via the secondary shell.
EXEC EXIT Terminates the Novell menu (NMENU) utility and returns control to the command shell and the command prompt.
EXEC LOGOUT Terminates the Novell menu (NMENU) utility and logs user out of the network. Provides a secure option to exit the Novell menus.

The SHOW Control Command

A menu is defined using the MENU command in which you must define the menu number and the menu title. There can be many such menu commands in a single file. The first menu command in a compiled file that is passed as a parameter to the NMENU command becomes the first menu that is displayed. This is the main menu. All other menus in the file are displayed by using the SHOW command. The syntax of the SHOW command is as follows:

SHOW menuNumber

The menuNumber should be replaced with a number that represents the menu number defined in the MENU statement for the submenu that should be displayed. There can be up to 255 submenus or menu commands (menu definitions) in a single menu file.

The submenu that is displayed is cascaded in relationship to the previous menu. Its position on the screen is determined automatically by the Novell menu utility.

Figure 6.21 shows the SHOW commands in a menu script file. The two SHOW commands SHOW 3 and SHOW 8 refer to the indicated submenus in the script file.

Figure 6.21 SHOW commands in a menu script file.


STUDY NOTE: The SHOW control command is used to display a menu by its menu number.

The LOAD Control Command

A menu is defined using the MENU command in which you must define the menu number and the menu title. There is a limit of up to 255 submenus or menu commands (menu definitions) in a single menu file. For large menu systems, you must place the menu definitions in separate files. You may decide to use separate files for menu systems that are not large because doing so can help you organize and manage the menu definitions. To load a menu that's in a separate file, you must use the LOAD command. The syntax of the LOAD command is:

LOAD menuName

The menuName should be replaced by the file name of the compiled menu file. When the LOAD command is executed, the original menu system is left running, but a second menu is added to the screen.

Figure 6.22 shows the use of the LOAD command. It shows how a large menu can be broken into smaller menus. In this figure, three menus, MENU1, MENU2, and MENU3, are shown defined in separate files MENU1.DAT, MENU2.DAT, and MENU3.DAT.

Figure 6.22 Use of menu LOAD command.


STUDY NOTE: The LOAD command is used to load menus compiled in a separate file.

The GETx Commands

There are three forms of the GETx commands: GETO, GETR, and GETP. Like the other control commands, GETx commands are listed after an ITEM command and are executed when the menu item is selected. An example of some of the GETx commands is shown here:

ITEM   ^LDirectory Listing
      GETO  Enter directory name: {} 45,, {}
      EXEC DIR


STUDY NOTE: The Menu GET commands obtain input from the user through the Novell menus.

The GETO Command The GETO command is used for obtaining an optional input from the user. The O in GETO is for the word "optional." When the GETO command is executed, as shown in the previous example, a dialog box is displayed. The message in the dialog box, the width of the user input, the initial value of the user input, and so on, are passed as parameters to the GETO command.


STUDY NOTE: The GETO command is used for obtaining an optional input from the user.

With the GETO, GETR, and GETP commands, the Enter key signals that you've completed the information, and the F10 key signals that you want to continue with the menu execution.

The user has a choice of making an entry or not making an entry (optional GET). In either case, when the user presses the F10 key, execution continues. If the user makes an entry, the entered value is passed as a parameter to the command that follows. In the preceding example, the command that follows is the EXEC DIR command. In this example, if a user had made the entry F:\SYSTEM, the EXEC command that would be executed is:

EXEC DIR F:\SYSTEM

This command displays the contents of the directory F:\SYSTEM. If the user had not made any entry, but just typed in F10, the EXEC command that would be executed would be as follows:

EXEC DIR

This command displays the contents of the current directory.

The % character can be used as a placeholder for a single user input. The preceding example of the use of the GETO command can be alternatively expressed using the % placeholder.

ITEM   ^LDirectory Listing
      GETO  Enter directory name: {} 45,, {}
      EXEC DIR %


STUDY NOTE: The O in GETO stands for Optional input.

The GETR Command The GETR command works in a manner similar to the GETO command described previously. The big difference is that the GETR command requires users to enter information. Just pressing F10 only (or Enter if GETR is in its own dialog box), will not cause the GETR command to continue execution. The menu display will be paused, and not continue until a valid input has been entered.


STUDY NOTE: The GETR command requires an input from the user.

An example of the use of GETR is shown here:

ITEM  User Command
      GETR Enter a user command: {}80,,{}
      EXEC %

This passes the user-typed string as a command to be executed by the EXEC command.


STUDY NOTE: The R in GETR stands for Required input.


AUTHOR'S NOTE: The inputs received by the GETR and GETO commands are placed at the end of the next EXEC command line. Thus, if the next EXEC command is:

EXEC NNC

then input received by the GETR and GETO commands are placed as shown below:

EXEC NNC   InputViaGet

where InputViaGet is replaced by input received through the GETR and GETP commands.


The GETP Command The GETP command works in a manner similar to the other GETx commands. The special feature of GETP is that it assigns a variable to the user input. This variable can then be used in other commands. An example of the use of GETP command is shown here:

ITEM  Network Copy {PAUSE SHOW}
      GETP Source: {} 60,, {}
      GETP Destination: {} 60,,{}
      EXEC NCOPY  %1 %2

The first GETP parameter assigns the user input to the variable %1, and the second GETP command assigns its user input to %2. These parameters are used in the EXEC NCOPY command as the source and destination, respectively.


STUDY NOTE: The GETP command can be used to assign parameters to the user input.

Table 6.5 summarizes the different GETx commands.

Table 6.5 GETx Commands

GETx Command Description
GETO This is used to obtain optional user input from the user.
GETR This is used to obtain required user input from the user.
GETP This is used to obtain user input that is assigned to variables %1, %2, and so on.

GETx Commands--User Input Processing

While the GETR and GETO commands append the input they receive to the next EXEC command, the GETP command parses the input and breaks it down into words that are assigned to parameter variables %1, %2, %3, and so on.

Thus, if the user input is the following: MONTHS 12 YEARS 25 the parameter variables have the following values: %1 = MONTHS

%2 = 12

%3 = YEARS %4 = 25 These parameter variables can be used in the next EXEC command. An example of this is shown as follows:

EXEC CalcInt  %3=%4  TYPE %1=%2

Given the previously discussed parameter values, the preceding EXEC command evaluates to:

EXEC CalcInt YEARS=25 TYPE MONTHS=12

As you can see, the GETP allows you greater control over how you can use the user typed-in values.

GETx Parameter Options

In the examples of the use of the GETx commands in the previous section, you noticed the use of the { } braces and the commas (,) as part of the syntax of the GETx command. This syntax is part of a general syntax that gives you options to control the width of the user input and the initial value that is displayed for the user. You can also modify the user input by prepending and/or appending special text string values to the user input. The syntax of these parameters is shown here:

GETx  promptString, {prependString} length,prefillString,{appendString}

or

GETx  promptString, {prependString} length,prefillString,SECURE {appendString}

The x in GETx is O, R, or P for the different types of GET commands. The promptString is the text that is displayed for the GET command, and is meant as an aid to the user to enter the appropriate value. The prependString placed inside the { } is a string that's attached to the beginning of the data the user enters. If there is no value that you want to prepend to the entered data, you must enter the empty string inside {}. An example of the use of the prepend string is shown here:

ITEM  ZIP code for Montana Residents
      GETR {MT }5,,{}
      EXEC RecZip %

In this example, the prepend string "MT" is prepended to the supplied user input. The RecZip represents a custom application that processes user-supplied data.


PRACTICAL TIP: There's a difference between the {} braces and the { } braces. The former represents a null or empty string, and means that no value will be prepended to the user data. The latter represents a blank character that is prepended to the user data. These comments also apply to the {appendString} in the GETx command syntax.

The length specifies the size of the user input field. It's the number of characters the user can enter for the GET command. The length field is mandatory and can have a maximum value of 80 characters. The example that follows shows a maximum length field of 80 being used:

ITEM  Address Information
      GETR  Enter your street address {}80,,{}
      EXEC RecData %

The RecData in the EXEC command in the preceding example is meant as an example of a custom application (RecData) that can process the user-supplied information.

The prefillString is the initial value that is placed in the user's response field. It is used as the default value that the user can accept, if the user chooses not to enter a different value. The prefillString is optional. The prefillString is separated from the length field by a comma (,) and no spaces. If no prefill string is used, it can be omitted as shown in the following example:

ITEM  Get user information
      GETO Enter your company name:{}50,,{}
      EXEC RecData  %

The next example shows a prefill string being used:

ITEM  Get user information
      GETO Enter your company name:{}50,IBM,{}
      EXEC RecData  %

In this example the "Enter your company name:" field in the dialog box for the GETO command has an initial value of IBM. The user can accept this value or override it with a different value. The user-supplied value is used as a parameter to a custom application called RecData.

The SECURE keyword is optional. If present, it must occur between the prefillString parameter and the {appendString} parameter. If the SECURE keyword exists as part of the GET command syntax, it means that the typed-in user data will not be displayed (hidden). This is useful if the user wishes to enter a password, security code, or some other confidential data. An example of the use of the SECURE keyword is shown next:

ITEM  Security Information
      GETR  Enter Personal Identification Number(PIN): {}4,,SE-       	CURE{}
      EXEC  ValidPIN %

The ValidPIN in the EXEC command is meant to signify a custom application--one that, perhaps, validates the user-supplied PIN data.

The appendString placed inside the {} is a string that is attached to the end (appended) of the data the user enters. If there's no value that you want to append to the entered data, you must enter the empty string inside {}. An example of the use of the append string is shown here:

ITEM  Security Information
      GETR  Enter Personal Identification Number(PIN):        	{}4,,SECURE{KXVZ}
      EXEC 	ProcPIN

In this example, the append string "KXVZ" will be appended to the supplied user input. The ProcPIN represents a custom application that processes the user-supplied data. In this example the append string is used as a special security code that is sent in conjunction with the user-supplied data to the processing program ProcPIN.

If several GET commands are listed under an ITEM command, the GET fields are grouped in the order of occurrence with 10 GETs per dialog box. In other words, there can be a maximum of 10 GET command prompts per dialog box. If you want to override this default behavior and have a GET command appear in its own dialog box, you must use the caret (^) at the beginning of the prompt text for the GET command. The next example shows how each of the GET commands can appear in its own dialog box:

ITEM  Enter User Information
      GETP  ^User Name:{}50,,{}
      GETP  ^Address:{}80,,{}
      GETP  ^Password:{}30,,SECURE{}
      EXEC ProcUser %1 %2 %3

The ProcUser represents a custom application that processes the user-supplied input.

Another example of the use of the GET commands that prompt users for options is listed next: The user is prompted for the source and destination directories. These are used as parameters %1 and %2 in the NCOPY command:

ITEM  Network Copy {PAUSE SHOW}
      GETP  Source: {} 60,, {}
      GETP  Destination: {} 60,,{}
      EXEC  NCOPY  %1 %2

Other uses of the GET commands are shown here:

Example 1:

ITEM  Authenticate User
      GETR  User ID:  {} 10,guest,{}
      GETR  Password: {} 25,,SECURE{}
      EXEC  CHKUSER.EXE

In Example 1, the user is asked for a password. The user's response is not displayed because of the SECURE option. The user's response is used as an argument to CHKUSER.EXE.

Example 2:

ITEM  Directory Listing
      GETO  Directory Path: {  } 40,,{}
      EXEC  dir

In Example 2, the user is asked for the directory path for which a listing should be displayed. If one is not specified, the DIR command is executed without an argument--in which case, a listing for the current directory is displayed.

Example 3:

ITEM  Compute Mortgage {SHOW}
      GETP  Enter loan amount:   {}10,0,{}
      GETP  Interest Rate:       {}5,6.5,{}
      GETP  Enter period (/m=months or+
      /y=years) : {} 8, /y=30,{}
      EXEC  echo  Loan amount  = %1
      EXEC  echo  Interest rate  = %2
      EXEC  echo  Period             = %3
      EXEC  MortCalc   /l=%1  /r=%2  %3

In Example 3, the loan amount and interest are passed as parameters to the program MORTCALC (Mortgage Calculation). The loan amount is passed as a parameter of the form /l=amount. The interest rate is passed as a parameter of the form /r=rate. The period is displayed with a default field value of "/y=30" (30 years). The user can enter the value using the /m=months or /y=years format. This is passed as the %3 argument to the program MORTCALC.

There can be no more than 100 GET commands per ITEM command. Also, the GETO and GETR commands must be entered between the ITEM and the EXEC line that is associated with them.

The general syntax of the GETx command is shown here:

GETx  promptString, {prependString} length,prefillString,[SECURE]{appendString}

The [ ] brackets around SECURE imply that SECURE is optional; it is not part of the syntax for GETx.

Table 6.6 summarizes the different GETx parameters that have been discussed.

Table 6.6 GETx Parameters

GETx Parameter Description
promptString This is the message that must be displayed to the user.
prependString The user-entered data is prepended with the prependString placed in the first set of {}.
length Maximum number of characters for the user field. Its maximum value is 80 characters.
prefillString The prefillString is used as the default response, in case the user does not enter a value.
SECURE The user typed-in information is not displayed. It is used for secure data such as passwords and codes.
appendString The user-entered data is appended with the appendString placed in the first set of {}.


STUDY NOTE: Use table 6.6 to review the GETx parameters. Also study the examples on the user of the GETx parameters in this section.

Menu Limitations

The following is a list of menu limitations:

ITEM Telmail option
EXEC MAP T:=FS1/SYS:INET/BIN
SHOW 06

Customizing Menu Colors

The menu utility COLORPAL can be used to customize color palettes for the menu utilities. The color schemes, and the default color scheme, are defined in a file called:

shortmachine_RUN.OVL

where shortmachine is replaced by the SHORT MACHINE TYPE parameter defined in the NET.CFG file. The default value of SHORT MACHINE TYPE is IBM, and therefore the default name of the color schemes file (C-Worthy overlay file) is:

IBM_RUN.OVL

If you set the SHORT_MACHINE type to a different value, such as NEC, using the following command:

SHORT MACHINE TYPE=NEC

in the NET.CFG file, you must define the overlay file NEC_RUN.OVL. This allows custom color palettes to be defined for user workstations with unusual displays that need to display a different set of color combinations from the default.


PRACTICAL TIP: Do not change the default color combination, because it affects all workstation menu/text based utilities that use the shortmachine_RUN.OVL file. Create a special shortmachine_RUN.OVL file, with the shortmachine replaced by the value of the SHORT MACHINE TYPE parameter in the NET.CFG file. Keep this file in the SYS:PUBLIC directory on the NetWare 4.x server, where most other menu/text-based utilities are kept.

Study Guide for the Chapter

If you are preparing for the NetWare 4.x Administration CNE exams, review this chapter with the following goals:

1. Understand the different workstation files used for configuration. You should be familiar with the structure of the NET.CFG file, and special statements placed in the CONFIG.SYS and AUTOEXEC.BAT file. Use the STUDY NOTEs as a quick review.

2. Understand how login script processing works. You should be able to tell when a particular login script file (system, profile, user, default) will run for a User object in an NDS tree. You also should understand the structure of Novell menus and how to use the different EXEC command options.

3. After studying this chapter, attempt the sample test questions for this chapter. If you miss the answer to a question, review the appropriate topic until you understand the reason for the correct answer.

Chapter Summary

In this chapter, you learned about the different configuration files needed to set up the NetWare workstation configuration.

You were shown how to establish the network environment using login scripts. NetWare 4.x uses four types of login scripts: system, profile, user, and default. You learned when a particular login script type was activated. You also learned the different components of a NetWare 4.x menu system and learned to how to write a menu script file.

Chapter Test Questions

Questions are either single choice or multiple choice. Where a single answer is desired, they are indicated by a l that precedes the possible answers. Some questions require you to select more than one answer; these are indicated by the n preceding each answer. Certain questions will be repeated in different ways, so that you can recognize them even when the wording is different. Taking practice quizzes will not only test your knowledge, but also will give you confidence when you take your exam.

1. Which of these files can be used for NetWare 4.x workstation configuration?

A. NET.CFG

B. CONFIG.SYS

C. CONFIG.DAT

D. AUTOXEC.NCF

E. AUTOXEC.BAT

2. The call to STARTNET.BAT file is usually placed in the ______ file.

A. NET.CFG

B. NETSTART.BAT

C. START.BAT

D. AUTOEXEC.NCF

E. AUTOEXEC.BAT

3. Which file is normally used to load the ODI drivers in a NetWare 4.x workstation?

A. NET.CFG

B. NETSTART.BAT

C. START.BAT

D. AUTOEXEC.NCF

E. STARTNET.BAT

F. AUTOEXEC.BAT

4. The ODI drivers must be loaded ______.

A. after the VLM.EXE

B. before the LSL.COM

C. after the LSL.COM

D. after the IPXODI.COM

5. For a NetWare 4.x workstation, one can expect the following statements in a NET.CFG file:

A. FIRST NETWORK DRIVE

B. FRAME Ethernet_SNAP

C. LASTDRIVE=Z

D. VLM Requester

E. NAME CONTEXT

6. How is the profile login script set for a user?

A. The profile login script is set by assigning a profile login script to the User object's profile login property.

B. The profile login script is set by assigning a profile login script to the user's container profile login property.

C. The profile login script is set by assigning a Profile object to the User object's profile login property.

D. The profile login script is set by assigning a Profile object to the User's container profile login property.

7. Which environment variable is set to specify languages other than English?

A. LANGUAGE

B. NWLANGUAGE

C. NWCLANGUAGE

D. NLS

E. NLSLANGUAGE

F. NLSLANG

8. A user's preference for a language can be specified by ______.

A. setting the language environment variable for the user

B. setting the language property for the user

C. loading the language driver in CONFIG.SYS

D. setting the language property in the user's container object

9. Novell menus have two organizational commands: ______ and ______.

A. MENU

B. EXEC

C. GETR

D. ITEM

E. GETP

10. The option that can be used to free up memory taken by the Novell menu utility when running an application is ______.

A. CHDIR

B. SHOW

C. BATCH

D. PAUSE

E. MEMORY

11. Which ITEM option causes the message Press any key to continue at the end of executing the command?

A. CHDIR

B. SHOW

C. BATCH

D. PAUSE

12. To make the Novell menus secure, you should ______.

A. use the EXEC DOS command in an item option

B. not use the EXEC DOS command in an item option

C. use the EXEC SECURE command in an item option

D. use the EXEC SHELL command in an item option

13. Which menu commands obtain input from the user through the Novell menus?

A. LOAD commands

B. SHOW commands

C. PUT commands

D. GET commands

E. READ commands

F. INPUT commands

14. Which command is used for obtaining an optional input from the user?

A. GET

B. GETR

C. GETO

D. GETP

15. Which command can be used to assign parameters to the user input?

A. GET

B. GETR

C. GETO

D. GETP

16. The NDS objects that can contain the system login script are ______ and ______.

A. Organization

B. Organizational Unit

C. Root

D. User

E. Organization Role

17. Which command is used for obtaining required input from the user?

A. GET

B. GETR

C. GETO

D. GETP

18. The profile login script is executed ______.

A. before the system login script but after the user login script

B. after the system login script but before the user login script

C. after the system login script but before the container's login script

D. before the system login script but after the container's login script

19. A User object can have ______ profile login script(s).

A. 1

B. 2

C. up to 8

D. any number of

20. The default login script is executed if the ______.

A. system login script is not set

B. profile login script is not set

C. system and profile login script are not set

D. user login script is not set

21. Which command is used to prevent the default login script from executing and is set in the system or profile login scripts?

A. EXIT_DEFAULT_LOGIN

B. NO_DEFAULT_LOGIN

C. SKIP_DEFAULT

D. QUIT_DEFAULT

E. ABANDON_DEFAULT

F. NO_DEFAULT

22. The User object in the container must have the ______.

A. Browse right to the container object and the Read property right to the login script in order to execute the system login script

B. Read right to the container object and the Read property right to the login script in order to execute the system login script

C. Create right to the container object and the Read and Write property rights to the login script in order to execute the system login script

D. Write right to the container object and the Read and Compare property rights to the login script in order to execute the system login script

23. Containers are granted the ______.

A. Read and Write property rights to their system login script

B. Read property right to their system login script

C. Read, Compare, and Write property rights to their system login script

D. Write property right to their system login script

24. Users are by default assigned ______.

A. Read and Write property rights to their user login script property

B. Read and Compare property rights to their user login script property

C. Read property rights to their user login script property

D. Supervisor property rights to their user login script property

25. The login script command to clear the screen is ______.

A. CLEAR

B. CLS

C. CLEAR DISPLAY

D. CLEAR SCREEN

26. The login script command to change a user's context is ______.

A. LCX

B. CONTEXT

C. CX

D. CHANGE CONTEXT

27. The login script command to execute other login script commands as if they were a subroutine is ______.

A. CALL

B. SUBROUTINE

C. INCLUDE

D. PROC

E. PROCEDURE

28. The login script command to display the last time a user logged in is ______.

A. LOGINDATE

B. LOGINTIME

C. LAST_LOGINDATE

D. LAST_LOGINTIME

E. LASTLOGINTIME

29. The login script command to change drive from ordinary network drive to search drive and vice versa is ______.

A. MAP CHANGE

B. MAP INS

C. MAP CH

D. MAP TOGGLE

30. In this figure, what is the login script execution order for user Nina, if she does not have a user login script? Assume that Nina's profile login script property is set to the Profile object CN=Profile1.O=SCS.

A. system login script for O=SCS, system login script for OU=CORP, user login script for CN=Nina

B. system login script for O=SCS, system login script for OU=CORP, default login script

C. system login script for O=SCS, system login script for OU=CORP, profile login script in CN=Profile1.O=SCS

D. system login script for O=CORP, profile login script in CN=Profile1.OU=SCS, default login script

31. Older menu scripts can be converted to NetWare menu scripts by using ______.

A. CNVTMENU

B. MENUCNVT

C. OLDMENU

D. OLDMENUC

E. MENUCONV

32. The utility to compile the menu script (SRC) file to the menu object file (DAT) is ______.

A. MAKEMENU

B. MENUMAKE

C. MENUCOMP

D. COMPMENU

E. MNUMAKE

F. MAKEMNU


Previous chapterNext chapterContents


Macmillan Computer Publishing USA

© Copyright, Macmillan Computer Publishing. All rights reserved.