GROUP THINK

by Wayne M. Krakau - Chicago Computer Guide, August 1992

Number one on my list of the characteristics of a poorly managed and difficult to maintain networks is the lack of attention paid to the importance of organizing by groups.

In my constant encounters with disorganized Netware LANs, this is the single most time-consuming (translation: expensive) problem to overcome.

Sometimes the issue comes up during the mending of a completely disabled LAN. Sometimes it's during the installation of a new application. Often its something as simple as the need to add new users or just slightly alter the responsibilities and capabilities of existing users.

It doesn't matter how the problem is discovered, the results are the same. The system administrator (often a "civilian" doing double-duty as "The Computer Person") spends valuable time at company expense trying to make just one more quick fix to a complicated series of rights assignments (rights being Novell terminology for designating who has access to what files and to what degree). Additional time is lost painstakingly examining personal login scripts (login scripts are a sort of autoexec file used to control and enhance the act of logging in to the LAN), looking for common patterns. After reaching a point of diminishing returns, the system administrator having better things to do, a call for help is issued.

Usually the first thing I'll notice is that the system login script has no EXIT commands. To understand the implications of this, you need to know that (excluding the optional Netware Name Service software) there are three types of login scripts, system, default, and personal.

The system login scripts are manually created by the system administrator using the SYSCON utility. When it exists, it is run by everyone who accesses the network with the LOGIN command. It resides on volume SYS (the mandatory name for the first disk portion that Netware controls) in the PUBLIC directory under the name NET$LOG.DAT.

If the system login script doesn't exist, as in a newly installed network, the default login script is run. Also, if the system login script exists but no EXIT command is encountered, a search is automatically made for a user login script. If that's not found, then the default is run after the system. The default login script is embedded ("hardcoded" in programming terms) inside the LOGIN command itself (LOGIN.EXE). Copies of that command are in both the LOGIN and PUBLIC directories on the SYS volume. One bit of warning - the actual contents (the programming code) of the default login script are inappropriate for anything past the first few logins on a newly installed network, and, from an experienced programmer's point of view, are written in a terrible style. So, don't even think of using the listing of the default script as documented in Netware's manuals as an example.

When the default (and sometimes even a personal login script) login script is run subsequent to the system login script, the result is often a login script gumbo - lots of ingredients mixed so that it's difficult to identify one aspect of the flavor as belonging to one particular ingredient. Perhaps a forensic pathologist (that's like "Quincy" for afficionados of late night reruns) would enjoy reverse engineering this gumbo, but I sure wouldn't.

The third kind of login script, personal, runs after either the system (if it exists) or the default (if there's no system). It’s created manually by either the system administrator or the individual to whom it belongs. It's in a file called LOGIN in the subdirectory of the MAIL directory that is named for the internal hexadecimal (base 16) number that Netware uses to identify that user. Each person potentially has a personal login script with that same name, LOGIN, the identifying factor being the location.

The hexadecimal number is found by selecting Other Information from within User Information in the Syscon utility. The personal login script is created and can be copied within the Login Script section of User Information of Syscon. It can also be manually copied by simply copying the appropriate LOGIN file from subdirectory to subdirectory.

This logic (or algorithm, for my fellow computer geeks out there) for deciding which of these scripts run can be short circuited by the use of the EXIT command. If an EXIT command is encountered depending on the use of IF statements, no further login script statements of any kind are run. If the EXIT command stands alone, then the current script stops and no further scripts are started. If the EXIT command has a parameter (up the 18 characters surrounded by regular quotes) the command described within the quotes is immediately executed. Hence, the following line:

IF MEMBER OF PRIMATES THEN EXIT "BANANA"

would cause all members of the group called PRIMATES to execute a program called BANANA, skipping all other lines in the script being run and bypassing any further login script processing. (Plantains, anyone?)

Finally we're back to the original question regarding the implications of having no EXIT commands in the system login script. No EXIT (or bypassing EXITs with IF statements) means get out the ladle, we're into the login script gumbo, again.

Think about this. You have a three-user network. Each person has a personal login script. How long would it take you to modify the scripts to add a new application that needed access to several different directories and maybe a couple of environment variables, all varying by department (or with three people the theoretical department). I could already make a valid argument that it would take longer than if you had used a system login script with IF statements and EXITs.

Now, calculate how long it would take if your network grew to nine users. No, don't simply multiply by three - try cubing. Hence, nine divided by three is three. Three (the original number of users) to the third power (the result of the previous calculation) is twenty-seven. Multiply that twenty times the time you estimated for the original addition to the three-user network. For example, if ten minutes was your original estimate, two hundred and seventy minutes, or four and one-half hours is the estimate for changing the nine-user network. If the person who originally designed the personal login scripts is not available, you may have to double or even triple that estimate.

If you haven't figured it out yet, the preceding calculations were complete gibberish designed to impress upon the reader the overhead of indiscriminate use of login scripts. I will continue with this subject in next month's column.

CORRECTION

Due to an error in the editorial process (something to do with a coffee achiever trying to hold a mouse steady at three in the morning) portions of last month's column "Get Plugged In" were omitted. While the random chunks removed from the middle of the article were annoying (doing wonders for the logical continuity and grammatical structure of the sentences) the two paragraphs lopped off the end did contain at least one vital tidbit of information - how to contact Compuserve! Their (voice) phone number is 800-848-8199. My apologies to anyone inconvenienced by the omission of that number.

As always, questions, comments, and topic suggestions are always welcome.