------------------------------------------------------------------ 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 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 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. ------------------------------