KB#00668-Opening a file under Novell may result in an error 18 instead of an error 12 after updating the product, OS, or client kit
Opening a file under Novell may result in an error 18 instead of an error 12 after updating the product, OS, or client kit
After ugrading the BASIS product, Operating System, or Novell Client kit, BBx may return an error 18 instead of an error 12 when creating or opening a file. The error 18 is accompanied by a TCB(10)=-5, which is "Access Denied" under DOS. Therefore, when BBx made the system call to create the file, the OS responded with an Access Denied error. BBx simply mapped this to the most appropriate BBx error, with is an error 18 - "Illegal Control Operation / Permissions Error". This BBx error is reasonable, as the OS error (when the TCB(10) is negative) is the "true error" and the one that should be investigated.
A permissions error may be completely different than what the application expects - an error 12. After doing testing, we've found that the TCB(10) (and therefore error) will vary depending on the BBx used, the Operating System, and even by the client kit.
There are several factors at play here:
1) Our products use different system calls to open a file. Under PRO/5, we use the WIN32 API for our file opens. Under DOS ports, we use INTERRUPT 21 calls. Under P4 for Windows we used the 16-bit Windows API. Therefore, since different mechanisms are being used to open a file, it's very likely that the return code on a failed open will vary according to the call that was used.
2) The Operating System and client kit can cause the return code to vary as well. This is evidenced by Win95b returning a different TCB(10) than Win95a with everything else the same. The order of events is that BBx tries to open the file, and that call is handled by the client kit. The client kit and OS eventually work out all of the details and will either pass BBx a handle to the file or a failed return code. They are ultimately responsible for the return code, so that can cause it to vary as well.
3) The method in which you specify the file can have an impact as well. If you specify the full path of the file, nothing is left to chance so it's the best and most direct method. If you don't specify the full path on the file open, it brings many other things into the equation like the current disk, the current working directory, the DSKSYN commands in the config.bbx file, the current prefix, whether or not the DSKSYNed drives or the prefix include a path to a data server, and whether or not the system has full access to every DSKSYNed drive and every directory in the prefix. Note that STRING command usually verifies that the file does not exist on any of the DSKSYNed drives and every directory in the prefix before creating the file. Therefore, if the full path isn't specified, BBx will do a LOT of other system calls in the background. This means that by the time the STRING command errors out, we can't really tell WHAT OS command error'd out - so many have been done to figure out where to create the file. Therefore, the return code could again be very different.
So, the bottom line is that there really isn't a way to guarantee a specific error or TCB(10) when making a call like this. There are so many factors that influence the error code, including the client kit and OS which are beyond our influence, that there isn't any way to ensure what the error will be.
Last Modified: 11/17/1998 Product: PRO/5 Operating System: Novell Error Number:12,18 OS Error: 5
BASIS structures five components of their technology into the BBx Generations.