H. MISC.

H.1 Booting a server without running STARTUP.NCF/AUTOEXEC.NCF

There may be times when you want to boot a file server without running the startup scripts C:\STARTUP.NCF and SYS:SYSTEM/AUTOEXEC.NCF. With NetWare 3.x, when you issue the SERVER command, include the parameter

	-ns     To not execute the STARTUP.NCF
	-na     To not execute the AUTOEXEC.NCF

Note1: These parameters are case sensitive and MUST BE lowercase.

Note2: NEVER load memory management software before running SERVER.EXE!

Under NetWare 2.x all of the configuration information is incorporated into the NET$OS.EXE file so the question doesn't really apply; you would have to regenerate the operating system with NETGEN to change it.

[Thanks to Jay Sissom for clarifying the 2.x issues]

To start server with another STARTUP.NCF type:

SERVER -S START2.NCF

To start server with another AUTOEXEC.NCF type:

SERVER -A AUTO2.NCF

To start server without Directory Services open use -NDB and to start server in internal debugger use SERVER -D (this is the only documented option: type HELP RESTART SERVER on System Console). Options seems to work with RESTART SERVER command.

[Thanks to Petr Jaklin for this info]

H.2 How to login without running the system/user login script

The DEFAULT login script built into LOGIN.EXE executes after the SYSTEM login script (NET$LOG.DAT) when there are no USER login scripts. The solution is to either use an EXIT command at the end of the SYSTEM login script or create individual USER login scripts. The latter approach is more work but there is security benefit to creating USER login scripts.

Among other things the DEFAULT login script maps S1 and S2 search drives to SYS:PUBLIC and to the DOS subdirectories under PUBLIC. It also attempts to map a user home directory immediately under SYS: For more information see the Installaton and Upgrade red book. By the way you cannot modify the DEFAULT login script because it is built into LOGIN.EXE so the best you can do is prevent it from executing.

[Thanks to Andrew Lampert for this info]

In NetWare 3.12 and above, or earlier versions upgraded to the latest LOGIN.EXE, you can use the NO_DEFAULT login script command to prevent the execution of the default user login script for users who have no personal login script.

[Thx S.M.D.]

Alternatively, you could ensure that every user has a NetWare login script, however small, and that there is a system level NetWare login script as well. By the way, use "PATH string" as opposed to "SET PATH=string". The former goes through command.com for regularization, the latter is taken verbatim.

[Thx Joe D.]

This last point is a good idea from a security standpoint, too. Basically, on a server where users are allowed to have their own personal login scripts, an account without one may be a security hole. For the details, see the Hacking NetWare FAQ at:

http://www.nmrc.org/

A number of Netware hacking files and additional info are at this site.

[Thx S.M.D., Gabor Borsodi and Simple Nomad]

Or, you could ATTACH instead of LOGIN to the NetWare file server(s). You will either need to first login to another file server which has the ATTACH command available or copy ATTACH.EXE to the workstation's disk. Then enter the login command as "LOGIN /S nul *username*" which will attempt to read the script from the DOS nul device, which always returns end of file, effectively avoiding reading a login script.

If you are running NetWare 4.x you can LOGIN /NS (/NS meaning No Script). In a 3.x environment use LOGIN /S... Use /S to point to a text file on a local drive containing login script statements (A simple WRITE "It worked" should do) The easiest way of all is to LOGIN to another server and ATTACH to the problem server. If security is not an issue, copy ATTACH.EXE to your sys:login directory to avoid future problems.

[Thanks to A. Murray for this info]

At least in 3.1x, the Login scripts are in the mail directory. So the supervisor Login script is at sys:mail\1\login. If all login scripts are going to be the same, set the system Login scripts to what you like it to be and have only exit in the user login script. You don't want to leave no login because people have write access to the mail directory and can store a login script that causes problems. If there is something there, they can't change it.

[Thanks to Tom Tuckerman for this info]

H.3 Remotely controlling a PC with a telnet compatible program

To use Telnet to remotely control a PC, get telnetd.zip at:

http://www.futureone.com/~opeth/internetwork.html

[Thx S.R.#2]

It works really well with CUTCP TELNET, and also works fine with MacTCP TELNET and most other TELNETs as well.

H.4 Getting userIDs and other information into programs

There are essentially four ways to import Novell information into programs you have written, each of which is appropriate for some solutions:

H.4.1 Environment variables

Use the login script command:

dos set VARIABLE="Value"

to put the user-id (%LOGIN_NAME), station number, etc. (consult the Novell documentation for the list of available values), into an environment variable. Now you will be able to retrieve the environment variable in both batch files and programs. In Turbo Pascal as well as most varieties of C and C++ use the expression GetEnv("VARIABLE") to retrieve an environment variable.

This technique is good for simple programs which only need a few Novell values, and for batch files.

H.4.2 Piping in information from WHOAMI

Write your program to read its input in the form that WHOAMI types, and then pipe in the output from WHOAMI:

WHOAMI [/a] | YOURPROGRAM

You will have to program to ignore lines that contain only / - \ because these still appear at the head of the file while the program is scanning the bindery information.

This is inefficient, but it is the only way to get arbitrary group memberships if you cannot use the H.4.3 or H.4.4 below.

H.4.3 Novell APIs

Purchase the Novell APIs, available in both C (which work with several versions of C and C++, including all Borland products) and assembly language (which you could also use in any high level language with an interrupt command). With these you can retrieve directly almost any information that the account running the program has access to. The APIs provide not only basic services like user-names and connection number, but advanced ones like print queues and IPX/SPX communications, among others.

This is the best and most efficient solution, but requires investment in the APIs as well as programming knowledge.

You can order the Novell SDK by calling 800-RED-WORD or 801-429-5281. The Novell SDK is made available by subscription. The base price is $345 per year. This includes four releases of the SDK CD, a choice of a Novell product for your development/test environment, and a support incident. For further details please see http://developer.novell.com

Documentation may be viewed at http://doc1.provo.novell.com/  

[Thx J.P.]

An alternative to the SDKs is "Programmer's Guide to Netware" by Charles Rose. This book has extensive details on Netware v2.x system calls and covers many Netware v3.x calls.

There is also a shareware API library available via anonymous FTP at:

ftp://ftp.coast.net/SimTel/msdos/c/netclb35.zip

or any SimTel mirror site.

[Thx A.C.]

A Pascal NetWare API supporting programming language is NWTP06. It stands out because it is very complete (it does not however support Netware 4 as yet) and is available at:

ftp://novftp.rc.rug.nl:/proglibs/nwtp06.zip

It contains over 400KB of sources in more than 250 interface functions, over 500KB documentation and more than 200KB samples. The author is Rene Spronk.

[Thanks to Olger Diekstra for this info]

H.4.4 Third Party Utilities

UPDATE.EXE is by Robert Evans <bob@purdue.edu> is a freeware utility that allows you to detect the existence of specific sub-strings in text files, add, replace, delete specific lines, files, directories etc.

ftp://ftp.soe.purdue.edu/pub/update/

[Thx D.L.]

USERDUMP by Roy Coates will tap the bindery and list user info such as mail address, user id, etc. and is available at:

ftp://ftp.mechnet.liv.ac.uk/novell/freeware/userdump.zip

or

http://www.mechnet.liv.ac.uk/~roy/freeware.html

[Thx R.C.]

DISKHOG by Roy Coates will list the disk space used by user, including subdirectories and is available at:

ftp://ftp.mechnet.liv.ac.uk/novell/freeware/diskhog.zip

or

http://www.mechnet.liv.ac.uk/~roy/freeware.html

[Thx R.C.]

H.5 What do all those columns in STAT.NLM v2.0 mean?

STAT.NLM is a process which records performance information for a Netware v3.11 file server. STAT records a data point once per second and writes to the disk once per minute to minimize the effect on the server.

Use DUMPSTAT to output the STAT data in a readable format. This is a DOS command and its syntax is:

	DUMPSTAT inputpath [outputpath] [-L | -X | -S | -Nnum | -Mnum]

where -L Lotus format (comma delimited) -X Excel format (tab delimited) -S Screen format (column justified) -N Output file size (default is 7200 points or 2 hours). You can increase this if you want to put a day's worth in one file, etc. A file with 8 hours of data would therefore have -N28800. -M Data reduction factor ... or do you really not want that much data. This is the number of records that will be averaged and output to a single record. So putting 60 in here would give you a point per minute instead of a point per second. 300 would give you a point per 5 minutes.

Here is the official word from Novell on what the columns of output mean:

1. CPU utilization 2. Bytes received (bytes read from LAN comm channel) 3. Bytes transmitted (bytes written to the LAN comm channel) 4. Bytes read (bytes read from the disk) 5. Bytes written (bytes written through cache to the disk channel) 6. Packets routed (# packets using the router services of the server) 7. Number of connections

An important warning for anyone using STAT.NLM: the next filename to be used by STAT.NLM is stored in a file called STAT.CFG. You must use the STAT configuration utility to change this -- using a text editor will most likely crash your file server.

[Thx G.F.]

H.6 Changing the number of licenced users on a Netware server

Netware 2.x - requires a full "netgen"

Netware v3.1x - The serial number and maximum connection count are both found in SERVER.EXE. When you get your upgrade package from Novell, copy this file from the SYSTEM-1 diskette over your old SERVER.EXE on your server's boot diskette or boot partition and your server is upgraded. Note that it might be wise to keep the old SERVER.EXE around in case you later discover that the new SYSTEM-1 diskette has a media error or something. Also, if you have applied any static patches to your old SERVER.EXE, they will have to be re-applied to the new one (semi-static and dynamic patches, loaded in your AUTOEXEC.NCF, do not modify SERVER.EXE and will continue to work as usual).

Netware 4.x - the license is separate to the server.exe file. To increase or decrease the number of licenses is a matter of adding or deleting the license.mls file via install.nlm from the server console. With Netware 4.0x you may replace the current license via install.nlm, and with Netware 4.1 you may delete the previous license and/or add additional licenses. If you have two 50 user 4.1 licenses, for example, you can now create a 100 user server. If you have one 100 user license, however, you cannot split it into smaller units (at the moment) unless you can find someone to swap the license with for an equivalent number of smaller blocks of licenses.

[Thx S.M.D. & Richard Phillips]

H.7 Register memory ("Cache memory alloc. out of avail. memory" msg)

This section is based on NOVELL FYI 1.1.39, extended to include information provided by George Whitehead, R.J.L., Joe D. and S.M.D.

ISSUE/PROBLEM

Server error message: Cache memory allocator out of available memory.

This can occur when mounting disk volumes even when there are plenty of cache buffers available in machines with more than 16M of memory. It can also occur I guess when you have run out of memory completely but the solution in this case is obvious.

SOLUTION

EISA machines should be configured to use AUTO REGISTER MEMORY, but in the case of ISA machines or EISA machines that are not configured correctly, the following kludge will solve the problem. Every machine that requires the REGISTER MEMORY command, uses more than 16MB of RAM, and has large disk storage, will exhibit problems such as this. This is not an issue in machines that do not require the REGISTER MEMORY command (such as the COMPAQ SystemPro, PS/2 MODELs 90, 95, HP Vectra etc.) because at boot up you see all of the RAM.

By the time you register memory in the AUTOEXEC.NCF, volume SYS: has already been mounted. At the time the first volume is mounted, NetWare draws a line in the sand, and only memory which it had available at that time can be used for FAT caching for all subsequent volumes, regardless of how much physical memory is available at that time. Therefore, subsequent volumes will be mounted downward in memory until you eventually run out of memory below 16 meg (see figure 1 below).

Figure 1:
	     |======{==}={==}={==}| ==========================|
		 {== VL2  VL1 SYS 16                          64
				 MEG of MEMORY               MEG

The key is to REGISTER MEMORY before loading the disk drivers or mounting volume SYS:, as illustrated in figure 2 below.

Figure 2:
		 |===============|=================={==}{==}{==}|
				 16                 { =  VL2 VL1 SYS 64
				MEG of MEMORY                  MEG

Here is the procedure:

Step 1. Remove ALL DISK DRIVERS out of the startup.ncf file. If this is all that startup.ncf has then delete it.

For example my startup.ncf is: set minimum packet receive buffers = 200

Step 2. Create an Autoexec.ncf file in the same DOS directory as SERVER.EXE, making sure that the register memory command is executed before volume SYS is mounted. Use the format listed below.

file server name HOPE ipx internal net 9088 register memory 1000000 1000000 load isadisk port=1F0 int=E mount SYS autoboot

Step 3. Create an Autoboot.ncf file in the SYSTEM directory. Put into it all other Autoexec.ncf commands.

load NE2000 port=300 int=3 frame=ETHERNET_802.3 bind IPX to NE2000 net=01abfeed etc.

The decision to use the name autoboot is purely personal. The mechanism will work with a single Autoexec.ncf on the DOS drive containing all of the autoexec.ncf commands. The advantage of the 2 file method is that the complex part of the autoexec.ncf file is on the Netware partition and can be edited from a workstation using your favourite editor while the server is up. Others may find it preferable to have a single autoexec.ncf on the DOS partition of the server as this allows access to it when the server is down.

[Thanks to George Whitehead, R.J.L., Joe D. & S.M.D.]

Related bits and pieces.

Joe D. posted a message to the NOVELL LISTSERVER at the start of July (1994 Joe?) which described how to configure EISA memory cards.

Earlier versions of the driver for the ISA/MCA Adaptec host adapters (154x and 164x series) had a command-line parameter which informed them that they were operating in a machine with more than 16 MB of memory. Current versions of the drivers for these cards do not require this parameter and the EISA cards have never required this parameter.

Some drivers may require:

	set reserved buffers below 16 MB = 64

[See H.16 for more info on Adaptec]

It is possible to 'RUN' a sequence of netware console commands from a batch file by typing the name of the file from the console. Put the commands in a file in the SYSTEM directory and give it an NCF extension. For example if the file was called TEST.NCF it could be run by typing TEST, then pressing ENTER, at the console prompt.

[Thanks to Douglas Scott and S.M.D. for the info]

Some EISA don't register memory above 16MB. If this is the case, the NSEPRO describes the solution for servers running NW4 is to put the following lines in STARTUP.NCF:

	SET AUTO REGISTER ABOVE 16 MEGABYTES = OFF
	SET RESERVED BUFFERS BELOW 16 MEG = 200
	...load the disk drivers
	LOAD MEMFRGFX 

[Thanks to ksommers for the info]

Also, make sure there is no interrupt conflict. Drew Morris reported problems when a PCI SCSI card was set to Interrupt 15 and another problem when a PCI adapter was on Interrupt 9.

[Thanks to Drew Phillips for the info]

Additional note: Netware 4.x auto-registers memory in a PCI-bus server but Netware 3.x doesn't...unless you have more than 64 MB of RAM. Above 64 MB you will have to register manually, which can be done in the NetWare 4.x STARTUP.NCF file.

[Thx A.S.]

TID500055 Mounting Volumes and Memory Allocation

Some Early Information About Mounting Volumes May Be Misleading

Documented issues about registering memory on ISA and some EISA machines have been interpreted to say that NetWare mounts volumes from the top of the memory block down. That model seemed to explain the memory limits for mounting volumes and the necessity to avoid mounting the SYS volume before registering all memory. While it is true that all memory should be registered with NetWare before any volumes mount, it is not true that volumes mount from the top of the block down.

How NetWare Uses Memory to Mount Volumes and Grow the Directory Hash Table

Mounting a volume consists largely of reading the FAT from disk into server memory. After the FAT is loaded then the DET, directory entry table, is scanned and a hash table is built in server memory. Two simple rules govern the allocation of memory for mounting volumes. The first rule: when the first volume mounts, NetWare defines a block and all subsequent volumes will mount in that block. The second rule: the memory allocated for the volumes grows from the bottom of the block upward. The DHT, directory hash table, will be in the same block and, like volumes, will grow from low to high. Assuming the block in question to be the only block then any NLMs loaded or other cache buffers required will be allocated from the top of the block down. In summary, volumes and DHTs grow from the bottom of the block up and NLMs and other cache buffer requests use memory from the top down.

[Thanks to Mark Cramer for this info]

H.8 Full Duplex versus Half Duplex ethernet

Q: Should I configure my ethernet equipment to operate in full-duplex or half duplex mode?

A: The list has discussed this topic several times; and there is a great deal of anectdotal evidence to suggest that full duplex ethernet connections often _decrease_ network performance. This seems counter intuitive, what is the explanation?

A "normal" half-duplex ethernet has a very simple flow control mechanism - the collision. If a collision happens, retransmissions are handled at the physical layer, i.e. by the electronics of the ethernet equipment. This happens very quickly, i.e within microseconds.

The ethernet full duplex flow control standard is IEEE 802.3x. In order for this to work, _each_ device on the network must support 802.3x including NICs, switches, etc. The vendors seem to disagree on the interpretation of the spec, however. See http://www.nwfusion.com/netresources/0913flow.html for details and vendor finger-pointing.

If the physical level 802.3x flow control is not working properly, a busy ethernet may drop packets. In this case any retransmissions must be handled at the protocol level, i.e. in software (the OS of the network device). This happens _much more slowly_ then collision handling. TCP/IP is very robust in this case, retrasmissions occur within 1/2 second or more (an eternity at wire speed!). Some protocols are very poor in this regard, i.e. NFS over UDP. Some protocols have no provision at all for retransmissions, for example RIP broadcasts, SAP broadcasts, or any multicast protocols - any dropped packets are lost forever.

[Thx Joe D., Hansang Bae, Arthur B., Mike A. and probably lots of other people.]

Please note that full duplex ethernet _can work_ as advertised - it just requires interoperability testing to make sure that _all_ of the equipment on the wire is playing by the same rules.

>You need anywhere from 4 to over a dozen stations to reproduce
>problems that can be caused by full duplex (if there are any with
>your hardware).  Most of our links are half duplex because they fail
>stress test at full, but I have stress tested full duplex between
>Foundry's BigIron switch, and Intel cards and so I leave those set at
>full duplex. (BTW: I highly recommend FoundryNetworks for anyone who
>needs a 10/100 or especially gigabit layer 3 switch that does IP, IPX,
>and Appletalk).
>
>Also, even though I do have some of our servers on full duplex now,
>about the best we get is a few % in performance as most of the
>traffic is one way...  But when the link is unreliable (Intel card
>to a Bay/Nortel 350/450 for example), performance sometimes suffers by
>several hundred % when under a stress test.

[thx John Lauro]

And some final thoughts...

[SNIP]
>FDX fails just when needed most, under heavy stress. Under lighter 
>loadings one can not tell the difference between FDX and HDX. Very 
>often the large transfers are unidirectional, they are file 
>transfers, and in those cases FDX buys almost no advantage. Backbones 
>are the major beneficiaries of FDX, not workstations, because the 
>traffic tends to be bidirectional.
[SNIP]
>the complete FDX path must be properly dealing with FDX traffic or the 
>flow control messages (PAUSE packets) will not get through to the 
>offending transmitter, if they get through at all with congestion. There 
>is no good reason to think PAUSE packets are economical of network time
>since they say wait multiples of 512 bit times (contrast to a typical
>collision interval of 100 bit times) and the amount of waiting is a 
>vendor's choice rather than dynamic sensing of the network moment by 
>moment.

[thx Joe D.]

H.9 deleted

H.10 Getting a list of usernames on a server to an ASCII file

John Baird of New Zealand has developed a range of tools for Netware which are widely regarded as essential for supervisors. One of these is GRPLIST, which will list all users in a group. To get all usernames into an ASCII file, issue the following command:

GRPLIST * /f

which will create a file called USERS.LIS containing all user names on the server. John's utilities are available from most of the ftp servers listed in the FAQ (section C.2), as well as at:

	ftp://netlab2.usu.edu/apps/jrb400a.zip
For Netscapers:
	ftp://netlab2.usu.edu/sys/anonftp/apps/jrb400a.zip

H.10.1 Creating users from an ASCII file

There are several programs that will create users based on input from an ASCII file.

H.10.1.1 Mass User Management

Mass User Management reads in a tab, comma or space delimited file and creates the users. It uses templates to match different user account restrictions to different users in the ASCII file. A demo is available at:

ftp://ftp.coast.net/SimTel/msdos/novell/MUM13B.ZIP

This version of Mass User only works in bindery emulation on NetWare 4.1 servers so all users must be in the same context. An NDS version is in the works, though. Co-authored by Shawn_Holmstead@novell.com and others. Now works with VLMs.

H.10.1.2 UIMPORT -- reads an ASCII text file and adds users

UIMPORT (bundled with NetWare 4.x or higher) uses 2 ASCII text files: a control file and a data file.

UIMPORT /?

H.10.1.3 ScanUser -- scans/creates unknown/missing Mail directories

ScanUser is a small utility that scans for unknown or missing Mail directories, with the option to create missing ones. It is for sites with many users, and avoid the bother of logging in each user with /b to create the Mail directories. It also searches for Unknown Mail and Home Directories. ScanUser is free but you are asked to register if you are using it at: http://www.petena.se/support/register.htm You can get ScanUser at:

http://www.petena.se/software/

[Thanks to Peter Stromblad and Johan Wahlen for this info]

H.10.1.4 BULKLOAD.NLM -- imports users from an LDIF file

H.11 Remote access to a LAN

There are a variety of ways to get access to your network remotely. These include running a telnet server (e.g. telnetd described elsewhere) on a workstation and accessing it via tcp/ip, running remote control clients and accessing them via modem, running remote network node clients and accessing them via modem and of course iptunneling across a tcpip network.

Conceptually and practically, the simplest solution for many people is to run a remote control client on their own workstation which they dial into and control from remote sites. This requires 2 modems (preferably fast ones using V.34, or V.32bis in a pinch) and also requires that you leave your workstation permanently turned on - in itself arguably a Good Thing provided that the monitor is off. It also requires some software and there are a large number of choices.

Commercial packages include PC-Anywhere, CloseUp, Blast, Carbon Copy and Reachout (Stac Electronics, 1201 19th Place, Vero Beach, Fla 32960 (407)770-4777, FAX: (407)770-4779, TECH: (407)563-2255, www.stac.com). These cost around $100 to $200 per node and often work quite reasonably.

Shareware packages such as Telereplica (check your SimTel mirror)

ftp://ftp.radio-msu.net/.1/.m/Coast/msdos/modem/tr4-26.zip

offer a very cost effective solution. Telereplica has long passwords which are very hard to crack and can even do dialback for added security. The only drawback is that it does not do graphics but at 9600 baud, life's too short anyway! If you really need to run a graphics package (e.g. Harvard Graphics or whatever), do it at home and upload the results to your workstation. It's much faster that way !

There's also PCRemote from PC Magazine.

ftp://ftp.cdrom.com/.5/asme/COMM/PCREMOTE.ZIP

PCRemote has assembler source for a simple remote control package via modem which could be the basis for a more sophisticated effort.

[Thanks to Dr Ross Lazarus & S.R.#2 for this info]

One of the Very Frequent Questions on this list is how can folks dial into their NetWare file server.

At present, they can't, at least not like they think they might. Some device has to act as a client node on the network and then put things into a form suitable for async transmission. Whether SLIP or PPP or another framing method is used normally is a small part of the picture. In any case, the server is not an interactive login machine such as a Unix box and DOS does not work to a classical terminal interface.

This means the node on the net can execute the DOS programs and relay screen and keyboard updates across the phone lines (Carbon Copy, PC Anywhere, et al), or it can try to wrap IPX packets into async frames and unpack them on the other end. Things such as Netblazer/Worldblazer modems (though by now "modem" is the small part) act as such relay nodes. Novell's Access Server, and similar boxes, run a bunch of DOS machines having keyboard/screen relayed across the net. NAS simulates many machines on one via a special version of DESQview.

Since you have LWP/DOS 4.1, have a look at the XPC part of things. The idea is to relay the keyboard/screen of a DOS machine executing the program of choice across a wire using IP packets and the X window system protocol on top. Thus you could execute WordPerfect/DOS sessions from your Sun workstation, with your DOS PC doing the real work. Taking one more step, put a modem on your office DOS PC, run XPC there, and at home fire up a PC running X to a matching modem.

You might want to look at:

ftp://netlab2.usu.edu/..???../brainshr.zip

which is basically the floppy disk passed out at Brainshare/SLC (aka Novell Developer's Conference) this spring by Brian Meek addressing LWP/DOS, dialing, SLIP_PPP, and even Kermit's role in this. The development Kermit was just for developers, is out of date and should not be redistributed.

[Thx Joe D.]

H.12 Short Term Memory -- how much does your server need?

The default Short Term Memory allocation will ALWAYS crash your server if any type of load is put on it. I would suggest that you immediately set this value up to 5000000. We happen to run our servers at 8000000.

The exact syntax, which can be placed in your AUTOEXEC.NCF would be,

   SET MAXIMUM ALLOC SHORT TERM MEMORY=8000000

[Thx G.F.]

Long term readers will recall my personal recommendation is to use the maximum amount of memory in the machine, or NW's limits, whichever is smallest, in this line. I don't have much factual information to go on, but my crystal ball says it makes a pool available contiguously and helps NLMs when their memory needs arise. It does not hinder other memory allocations nor consume cache buffers etc.

[Thx Joe D.]

H.13 BTRIEVE -- what do I need?

Btrieve is a record manager running as an NLM on a Novell server. Certain applications can use a Btrieve client to make requests to the engine on the server. BTRIEVE.NLM is the server component, while BREQUEST.EXE is the DOS client. More complete documentation is included with the Novell manual set.

When performing installs of some programs, make sure the btrieve related programs in sys:system are NOT flagged as read-only.

Btrieve is no longer part of Novell. Btrieve Technologies can be reached at: #300 - 8834 N Capital of Texas Hwy, Austin, TX 78759-9774, Tel: 800-BTRIEVE (US & Can), 512-794-1719, eMail: Info@BtrvTech.COM, http://www.btrieve.com

[Thanks to Mark Fogel, H.K. & R.J.L. for this info]

H.14 deleted.

H.15 Synchronising workstation time with server time

Time synchronization occurs at two times. The first is at the time when the shell or redirector makes a connection to a server (the NOT-LOGGED-IN connection which gives you access to SYS:LOGIN). To disable this connection from setting your workstation's time, use SET STATION TIME = OFF in your NET.CFG.

The second time is during the login process. In the absence of a SET_TIME OFF command in any login script executed by the user, the workstation's time will be set to that of the fileserver. This command is supported in the LOGIN.EXE which ships with NetWare 3.12 and 4.x; it can be downloaded from the usual places for earlier versions.

[Thx S.M.D.]

The synchronization of workstation and server clock is explained in the Novell Application Note "Time in the NetWare Environment", Jan 94.

[Thx M.W.]

[ H(1) | H(2) | H(3) | H(4) | Novell FAQ Home Page ]