From ST2975@SIUCVMB.SIU.EDU Fri Mar 26 09:45:46 1993 Received: from calvin.sfasu.edu by umaxc.weeg.uiowa.edu (5.61.jnf/920629) on Fri, 26 Mar 93 09:45:42 -0600 id AA20494 with SMTP Received: from SIUCVMB.SIU.EDU by calvin.sfasu.EDU with SMTP (5.59/25-eef) id AA02401; Fri, 26 Mar 93 09:23:00 CST Return-Path: Message-Id: <9303261523.AA02401@calvin.sfasu.EDU> Received: from SIUCVMB.SIU.EDU by SIUCVMB.SIU.EDU (IBM VM SMTP V2R1) with BSMTP id 0293; Fri, 26 Mar 93 09:24:51 CST Date: Fri, 26 Mar 93 09:23:53 CST From: ST2975@SIUCVMB.SIU.EDU To: hyperc-l@calvin.sfasu.edu Subject: opsys error codes Status: R Operating System Error Handling --------- ------ ----- -------- By default, the operating system intercepts all I/O and system call errors. When it dos so, it aborts the running program and prints an error message on the screen, returning to the command line interface. When the system prints an error message it prefaces the message with the name of the program in which the error occurred, and may suffix the message with additional information. Each type of error is assigned a simple number with an enumeration type in the header file errors.h so that you can refer to them symbolically. The errors and their messages are: Value Name Message ----- ---- ------- 0 NOERR --this is no error value-- This is the normal error value returned from an opssy call. It represents the situation where there is no error. 1 DRVERR "drive error -- RWTS" RWTS detected a drive select error. A disk may be missing, the disk may be unreadable, or an invalid drive/slot may have been specified. 2 WRPROT "write protected -- RWTS" RWTS detected that a disk has its write protect hole covered during a write to disk request. Remove the write protect tape from over the notch on the side of the diskette. 3 FMTERR "formatting error -- RWTS" The disk could not be formatted during a format operation. Replace the disk media. 4 BADFD "bad file descriptor" A file operation was attempted with a file dscriptor outside the range 0..15. Only 16 file descriptors can be used. 5 BADFCB "bad FCB -- invalid drive" A file operation was attempted with an illegitimate file control block. When a file is first opened or created, its drive is stored in its file control block. When a file is closed, the drive code is intentionally zapped. Thus, your program tried to use a file control block which was not open! Have your program open a file first. 6 NAMERR "invalid filename" A valid filename consists of a possible drive prefix of a: or b: followed by no fewer than 1, nore more than 13 characters. The error message is followed by the invalid name. 7 DIRFULL "directory full" You attempted to create a file on a disk which has a full directory. No more files may be stored on disk, unless some existing files are removed first. The error message is followed by the disk volume name. 8 DSKFULL "disk full" You have attempted to write another block to a disk which has no free blocks remaining. No more data may be written to that disk until some files are removed. Another possibility is that your program ran away and gobbled up all the space on the disk. The error message is followed with the disk volume name. 9 NOTFND "file not found" An open was attempted with a filename which does not exist on the specified or default drive. Spell the filename correctly, or put the correct disk in the drive. The error message is followed by the name of the file. 10 NOTPROG "not a program file" A command line was typed in which the first command line argument was not the name of a program file, but rather a raw object, data or text file. Only linked load modules may be executed from the command line. The error message is followed by the name of the file. 11 MEMERR "no memory" A memory allocation request alloc() wqs attempte whn fewer than 1k bytes would have been left between the new top of heap and the top of the C-Stack. Have yourr program free up some unused allocations or alter its algorithm. 12 USRABORT "User Abort!!!" You must have hit the control-@ key on the keyboard. ? ? "unknown error" This message should never appear, but it exists just in case the error handler gets called with a code which is none of the above. Programs may intercept these errors for themselves by placing in the system global vector _errHdlr the address of a routine to call when an error is detected. You should retain the original contents of this vector, and call upon a routine for any errors you choose not to handle. The vector is initial- ized to the default handler in the operating system when the program is started In general your handler should either abort the program or use longjmp to reset the state of the program to a known condition. Direct returns from the error handler are discouraged. When an error is detected, the error handler is called with 2 parameters. The first parameter is the error code, and the second is an optional supplemental error message string pointer. If the second parameter is not present, it should be set to zero. The system variable _ioresult is also set to reflect the error code. If a NIL address is stored into the _errHdlr vector, then all error handling is bypassed and errors are ignored by the operating system. The _ioresult byte contains the error code if any occurred. It is your responsibility in this case to check the _ioresult code.