Need access to EXE$EXCEPTABLE

[Roger tucker_1]

As usual, I'll try to explain myself as clearly as I can, but please read very carefully and assume I have done my homework. (Or I wouldn't be waisting your time asking something I could have figured out.)

As background, We have an exception handler in our software that grabs all exceptions and ships them off the box for alarming, filtering, and storage. This exception handler needs to know if the status code is a hardware exception or a software exception so it can correctly handle the number of signal arguments. (This exception routine, use to just decrement the number of exception arguments by 2 assuming it was a software error, but I noticed that this fails on hardware exceptions because the PC and the PSL are the last two arguments during a hardware exceptions.) If you don't know what I'm talking about; you haven't used exception handling routines that much...

Additional research. In looking at the VMS source listings in routine SYS$PUTMSG (SYSPUTMSG.LIS) I noticed that the code uses the table EXE$EXCEPTABLE. This is a table of system exceptions and the number of arguments for each exception. If the status code is not found in this table, PUTMSG subtracts 2 from the ARGCNT. See the area around “Special system message setup”. This code is also interesting, because PUTMSG also retrieves the number of arguments for this condition from this table and handle RMS status codes as well (STV value). I always wondered why you didn’t pass the number of arguments for hardware exceptions or for RMS status values and now I know how all of this works.

Now, my problem. I need to do the same thing! The problem is, I can’t get to EXE$EXCEPTABLE without linking with SYS$BASE_IMAGE; and I don’t really want to do that.
I also took a look at traceback and it uses an internal routine (TBK$IS_HARDWARE_EXCEPTION) which uses it’s own list. I didn’t really want to maintain my own list either.
So, I’m stuck at the moment.

My question, is there another way to determine if a VMS status code is a hardware exception or not; so that I can handle the number of arguments in a signal handler correctly without keeping my own list. I sure wish there was a routine to check EXE$EXCEPTABLE table that was a public symbol. This is very kludgy (new word?) the way this works that hardware exceptions and software exceptions were not done exactly the same way (no argument count) -– but I’m sure that is lost in history as to why it was done this way many years ago on the VAX.

Roger Tucker

[Volker Halle]

Roger,

the fact that traceback ([TRACE]TKBIO) maintains it's own list and it's internal routine TBK$IS_HARDWARE_EXCEPTION seems to indicate, that there may be no better way to get this information via a public interface. This module has not changed since 1992 ...

Volker.

[Volker Halle]

Roger,

SYS$GETMSG returns the count of FAO arguments in byte 1 of the outadr argument. Could this information help ?

Volker.

[Roger tucker_1]

This gets even more interesting.

LIB$SIGNAL and LIB$STOP tack on the PC and PS/PSL and increment the number of arguments in the signal array by 2. Even the Fortran and MACRO examples in the 8.2 RTL library documentation for LIB$SIGNAL are wrong. The C example is correct.

The example condition handler there shows what is going on. Notice that for system exceptions you DO NOT pass the number of arguments in the signal, but for your own error messages you MUST. For example, if you wanted to signal your own error message you would do something like this:

lib$signal(MY_OWN_CONDITION,2,P1,P2,SS$_ACCVIO,2,0xFACE);

The ACCVIO takes 4 arguments, 2 are passed, the PC and PS/PSL are tacked on by lib$signal. This is NOT documented correctly in section 9.8.1 of the programming concepts manual; where it shows lib$signal() different than lib$stop with reguard to the number of arguments and don't mention the difference between system error conditions and user-defined error conditions. The example MTH$ signal in section 9.8.2 does show this, but doesn't explain why. Now I know...

[Roger tucker_1]

I decided to compare the status codes in EXE$EXCEPTABLE of my V7.3-2 system and those in my source listing of TBK$ (V7.1) just to see if they were the same and how often they might have changed. EXE$EXCEPTABLE had everything TBK$ had with the following additions:

Status 1300, Condition 162, args 3 %SYSTEM-F-UNALIGN_SP_LOAD, unaligned load of SP, virtual address=!XH, PC=!XH, PS=!XL

Status 1308, Condition 163, args 3 %SYSTEM-F-GENTRAP, software trap, code=!XL, PC=!XH, PS=!XL

Status 1316, Condition 164, args 2 %SYSTEM-F-FLTINV, floating invalid operation, PC=!XH, PS=!XL

Status 1324, Condition 165, args 2 %SYSTEM-F-FLTINE, floating inexact result, PC=!XH, PS=!XL

Status 1332, Condition 166, args 2 %SYSTEM-F-DECDIV, decimal divide by zero, PC=!XH, PS=!XL

Status 1340, Condition 167, args 2 %SYSTEM-F-DECINV, decimal invalid operand, PC=!XH, PS=!XL

Status 1348, Condition 168, args 2 %SYSTEM-F-ASSERTERR, assertion error, PC=!XH, PS=!XL

Status 1356, Condition 169, args 2 %SYSTEM-F-NULPTRERR, null pointer error, PC=!XH, PS=!XL

Status 1364, Condition 170, args 2 %SYSTEM-F-STKOVF, stack overflow, PC=!XH, PS=!XL

Status 1372, Condition 171, args 2 %SYSTEM-F-STRLENERR, string length error, PC=!XH, PS=!XL

Status 1380, Condition 172, args 2 %SYSTEM-F-SUBSTRERR, substring error, PC=!XH, PS=!XL

Status 1388, Condition 173, args 2 %SYSTEM-F-RANGEERR, range error, PC=!XH, PS=!XL

Status 1396, Condition 174, args 2 %SYSTEM-F-SUBRNG1, subscript 1 range error, PC=!XH, PS=!XL

Status 1404, Condition 175, args 2 %SYSTEM-F-SUBRNG2, subscript 2 range error, PC=!XH, PS=!XL

Status 1412, Condition 176, args 2 %SYSTEM-F-SUBRNG3, subscript 3 range error, PC=!XH, PS=!XL

Status 1420, Condition 177, args 2 %SYSTEM-F-SUBRNG4, subscript 4 range error, PC=!XH, PS=!XL

Status 1428, Condition 178, args 2 %SYSTEM-F-SUBRNG5, subscript 5 range error, PC=!XH, PS=!XL

Status 1436, Condition 179, args 2 %SYSTEM-F-SUBRNG6, subscript 6 range error, PC=!XH, PS=!XL

Status 1444, Condition 180, args 2 %SYSTEM-F-SUBRNG7, subscript 7 range error, PC=!XH, PS=!XL

Status 1452, Condition 181, args 4 %SYSTEM-F-PAGRDERRXM, page read error across access modes, I/O status=!XL, virtual address=!XH, PC=!XH, PSL=!XL

Status 3172, Condition 396, args 2 %SYSTEM-F-EMULATED, an instruction not implemented on this processor was emulated at PC=!XH, PS=!XL

Status 9604, Condition 1200, args 3 %SYSTEM-F-TRANSCALLER, routine at !XL cannot be called by translated code

Status 9660, Condition 1207, args 3 %SYSTEM-F-SIG_INVARGTYPE, signature block specifies an invalid argument type; PC/PDA: !XL

Status 9668, Condition 1208, args 3 %SYSTEM-F-SIG_INVFLTARG, signature block specifies an invalid floating argument type; PC/PDA: !XL

Status 9676, Condition 1209, args 3 %SYSTEM-F-SIG_INVARGLIST, signature block will generate more than 255 OpenVMS arguments; PC/PDA: !XL

Status 9684, Condition 1210, args 3 %SYSTEM-F-SIG_INVFUNCTYPE, signature block specifies an invalid function value type; PC/PDA: !XL

Status 9692, Condition 1211, args 3 %SYSTEM-F-SIG_ARGMISMATCH, signature block & OpenVMS arglist have mismatched argument datatypes; PDA: !XL

Notice that 9604, 9660, 9668, 9676, 9684 and 9692 have an argument count that doesn't agree with the message.

PUTMSG uses the argument count from EXE$EXCEPTABLE if found; but you must pass the argument count for your own user-defined error messages. Also !XL maybe should be !XH in theses messages.

I've decided that I'm going to extract the status codes and argument counts from EXE$EXCEPTABLE and use that, but in the future it sure would be nice if there was an easier way to do this.

I just don't like the whole way SYS$SIGNAL and SYS$STOP append the PC and PSL without you knowing about it; then you having to correct the argument count in a signal handler and knowing when you need to do this to make everything work correctly.

Also, having to know the number of arguments for system conditions but the number of arguments for user-defined conditions being in the signal array.

Now that I understand it all - I think I can deal with it. Good luck if your new to VMS and your writing a complex condition handler!

[Roger tucker_1]

After much research and after looking at the code to PUTMSG and all the special stuff it does; I've decided to try to move our code to call that routine since I think it does almost everthing that we need. Most of the stuff I talked about is fairly well documented in the system services reference manual under sys$putmsg. Trying to do everything putmsg does yourself is not recommended. I'm closing this thread, but there might be some information gleamed from the above.

[Roger tucker_1]

trying to use sys$putmsg.

[Roger tucker_1]

I think this should be documented.
sys$putmsg() reads past the message vector in some cases.

for example, the following code works:

#include
int main()
{
unsigned long msgvec[6] =
{ 3, 12, 1, 2, 3, 4 };
/* ^number of arguments = 3 */
return sys$putmsg(msgvec);
}

The number of arguments in the msgvec is 3, but an accvio (12) needs 4 arguments and reads off the end of the message vector for them! This has to work this way because of the way lib$signal(), last_chance handler, and putmsg() has to work. If you write your own signal handler to call putmsg(), you must subtract two from the number of signal arguments and call putmsg and hope it reads off the end. There is no other way to make this work.