FERGUSON@TMASL.EXXON.COM (05/04/89)
I tried to open a mailbox file that doesn't exist today, and received
the status code = 0x800e0007
When I do an error_$print on this status code, I get the error
name not found from (OS/naming server). Therefore, I tried to
put in a conditional like this:
if (status.all == name_$not found) {
etc.
However, the name_$not_found status code in /sys/ins/name.ins.c
is different by one bit. Instead of being 0x800e0007, it's
0x000e0007, and I don't know why. Obviously, I can kludge my
way around this, but has anyone else noticed it?
I did an fpat (grep) on all of the /sys/ins/?*.c files as well as
the .pas files, and the status code is not defined anywhere.
Anyone know anything about this? Does the error handler ignore
that first bit or something?
Thanks,
Scott Ferguson
ferguson@erevax.bitnet
[cosc5zu@uhnix1.uh.edu (Larry W. Stone) (05/05/89)
> However, the name_$not_found status code in /sys/ins/name.ins.c > is different by one bit. Instead of being 0x800e0007, it's > 0x000e0007, and I don't know why. Obviously, I can kludge my > way around this, but has anyone else noticed it? > Thanks, > Scott Ferguson I don't have manuals here, but I believe the first bit in the status_$t structure indicates the severity of the error, rather than the type of error. This could be the reason for the discrepancy. I would have replied directly on this, but the mailer here couldn't find your address. Hope this hasn't wasted too much space for anyone.
oj@apollo.COM (Ellis Oliver Jones) (05/07/89)
In article <8905041340.AA03449@umix.cc.umich.edu> FERGUSON@TMASL.EXXON.COM writes: > > ... The name_$not_found status code in /sys/ins/name.ins.c >is different by one bit. Instead of being 0x800e0007, it's >0x000e0007.... Fun facts to know and tell: Here's the typedef "status_$t" as defined, on SR10+, in /usr/apollo/include/base.h : /* Common status datatype returned by most Apollo-supplied procedures: */ typedef union { struct { unsigned fail : 1, /* true if module couldn't handle error */ subsys : 7, /* subsystem code */ modc : 8; /* module code */ short code; /* module specific error */ } s; long all; /* used for testing for specific value */ } status_$t; As several others have pointed out, the high bit should be ignored when trying to determine equality of error codes. /oj
scoville_w@apollo.COM (William Scoville) (05/08/89)
Scott, >the status code = 0x800e0007 What happens it that the "fail" bit of status is set. Simply do "status.fail = false" and then do the compare to the constant. Status is defined in apollo/base.h as : typedef union { struct { unsigned fail : 1, /* true if module couldn't handle error */ subsys : 7, /* subsystem code */ modc : 8; /* module code */ short code; /* module specific error */ } s; long all; /* used for testing for specific value */ } status_$t; -BS-
gaz@apollo.COM (Gary Zaidenweber) (05/09/89)
From article <8905041340.AA03449@umix.cc.umich.edu>, by FERGUSON@TMASL.EXXON.COM: > > I tried to open a mailbox file that doesn't exist today, and received > the status code = 0x800e0007 > When I do an error_$print on this status code, I get the error > name not found from (OS/naming server). Therefore, I tried to > put in a conditional like this: > > if (status.all == name_$not found) { > etc. > > However, the name_$not_found status code in /sys/ins/name.ins.c > is different by one bit. Instead of being 0x800e0007, it's > 0x000e0007, and I don't know why. Obviously, I can kludge my > way around this, but has anyone else noticed it? > > I did an fpat (grep) on all of the /sys/ins/?*.c files as well as > the .pas files, and the status code is not defined anywhere. > Anyone know anything about this? Does the error handler ignore > that first bit or something? > > Thanks, > Scott Ferguson > ferguson@erevax.bitnet > [ status_$t is a variant record (union). The top bit is a boolean called "fail". See base.ins.pas for more info. I can't give you much information on how/why/who causes the "fail" bit to be set, but checking it like this: if ((status.all & 0x7FFFFFFF) == name_$not_found) { etc. would be perfectly valid and would even yield the correct results :-) Please note the bitwise AND (&) rather than a logical and (&&). Also please forgive the pedantic explanation if you didn't need it. -- Gary Zaidenweber | Its 1989: UUCP: umix!apollo!gaz | Do you know where your lawyer is? ARPA: gaz@apollo.COM |