
------------------------------------------------------------------
NOVERMSG.DOC -- 19970401 -- Email thread on NetWare Error Messages
------------------------------------------------------------------

	Feel free to add or edit this document and then email
	it back to faq@jelyon.com




Date: Fri, 23 Feb 1996 19:04:48 UT
From: Dave Kearns <DKearns@MSN.COM>
Subject: Re: Severity Number?

>Can someone tell me where to find the information for
>severity number recorded in sys$log.err below.

Here's a copy of a Novell TID outlining these. While this was written for
3.11, it SHOULD still be applicable.

TID:		LOCUS, SEVERITY and CLASS Error Codes - TID13386
DOC REV:	1
DATE:		08SEP93

Several questions have been asked about some of the NetWare 3.11 error
codes, such as LOCUS, SEVERITY, and CLASS.  The following is a list of
the NetWare 3.11 error numbers and the constant they represent:

ERROR LOCUS IDENTIFIERS
-----------------------
 0	LOCUS_UNKNOWN
 1	LOCUS_MEMORY
 2	LOCUS_FILESYSTEM
 3	LOCUS_DISKS
 4	LOCUS_LANBOARDS
 5	LOCUS_COMSTACKS
 7	LOCUS_TTS
 8	LOCUS_BINDERY
 9	LOCUS_STATION
10	LOCUS_ROUTER
11	LOCUS_LOCKS
12	LOCUS_KERNEL
13	LOCUS_UPS
14	LOCUS_SERVICE_PROTOCOL
15	LOCUS_SFT_III
16	LOCUS_RESOURCE_TRACKING
17	LOCUS_NLM

ERROR CLASSES
-------------
 0	CLASS_UNKNOWN
 1	CLASS_OUT_OF_RESOURCE
 2	CLASS_TEMP_SITUATION
 3	CLASS_AUTHORIZATION_FAILURE
 4	CLASS_INTERNAL_ERROR
 5	CLASS_HARDWARE_FAILURE
 6	CLASS_SYSTEM_FAILURE
 7	CLASS_REQUEST_ERROR
 8	CLASS_NOT_FOUND
 9	CLASS_BAD_FORMAT
10	CLASS_LOCKED
11	CLASS_MEDIA_FAILURE
12	CLASS_ITEM_EXISTS
13	CLASS_STATION_FAILURE
14	CLASS_LIMIT_EXCEEDED
15	CLASS_CONFIGURATION_ERROR

ERROR SEVERITY LEVELS
---------------------
0  SEVERITY_INFORMATIONAL:      Counters or Gauges reached thresholds
1  SEVERITY_WARNING:            Configuration errors, etc. No Damage.
2  SEVERITY_RECOVERABLE:        Hot Fix disk, etc. Workaround made.
3  SEVERITY_CRITICAL:           Disk Mirror failure, etc. Fix-up attempted.
4  SEVERITY_FATAL:              Resource fatally affected--shut down.
5  SEVERITY_OPERATION_ABORTED:  The operation can't complete.

------------------------------

Date: Tue, 1 Apr 1997 11:30:18 +0100
From: Richard Letts <R.J.Letts@SALFORD.AC.UK>
Subject: Re: A Schedule "Work To Do" error message.

>Our 150 user network froze for this afternoon for no obvious reason.
>I came check on my server and found this message on the console:
>
>Server-4.10-911
>A scheduled "Work To Do" took over one minute to be run.
>
>After a few minute, the server was back to normal (the console screen
>did not freeze on me anymore and the utilization drop from a steady
>100%), but a whole lot of users had to reboot their systems because
>they lost network drive connections.
>
>Please advise on this error message and how I can prevent it.  I still
>don't know what the error message mean as of this time.  Thanks in
>advance for your help.

I can't help with the symptoms, but here's some education on the internals
of NetWare 4.x

There are three priority levels in 4.x:
 - low priority thread (eg compression, sub-allocation)
 - normal priority threads (eg pserver, monitor, server xx process)
 - worker's

Worker processes are managed by threads rather than the kernel; the
control structures for them are created by the thread that owns them
rather than the kernel. they are designed to carry out tasks of defined,
sort duration, and are scheduled /before/ all of the others. they do
things like transfer data between memory and controllers, etc.
A NLM doesn't need to use worker processes to do this; they look awful
to program and I've never needed them.

If one of these took too long to run you can see none of the other
processes got a chance to run. Since the other processes include the
server xx processes, user's [could/]would lose their connection.

[further aside:
A thread belongs to a thread-group; when a NLM is loaded it is given an
initial thread and thread-group context. It can create additional threads
and thread-groups if it wants. Thread-group contexts are used by some
libraries, for example the inet_ntoa(), etc  functions use static memory
referenced off the thread group context. Forgetting this leads to
unexpected output of different threads in the same context! ]

Back onto the track of your problem.  I'd suspect the disk
controller/drives as being most suspect.  Worker threads are most-often
used here.

------------------------------

