| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 443.1 | Try this for messages. | FROST::HARRIMAN | Dialogue...Duologue | Tue Apr 14 1987 10:17 | 11 |
| > Is there a way to get the functionality of $PUTMSG without actually
> printing the message. I know I could parse the signal stack myself,
> but PUTMSG does a nice job. Right now I print the message but I would
> eventually like to send all the signal info to a mailbox for another
> (the main) process to deal with.
The system service $GETMSG is the actual call - $PUTMSG will output
to SYS$OUTPUT but $GETMSG will simply store the message text in
a buffer. Does more than that but only if you tell it to. See the
System Services manual.
|
| 443.2 | | CHAMBR::GUINEAU | | Tue Apr 14 1987 11:22 | 14 |
|
But $GETMSG dosen't fill in FAO directives.
In the Condition Handler I get a SIG[n] signal stack which has messages
and FAO arguments.
Guess I have to either live without the FAOs or do them myself.
John
|
| 443.3 | VMS has it NOW! | FROST::HARRIMAN | Dialogue...Duologue | Tue Apr 14 1987 11:49 | 15 |
|
Yes, but $GETMSG *does* tell you how many FAO arguments it thinks
you should have. Since the message text will be in a buffer you
can the do the FAO yourself, using the count that $GETMSG returns
to you ("outadr", byte 1). You said you didn't want to output them,
right? All you have to do to output them is to $FAO the message
with the FAO count supplied by $GETMSG, and yank 'em off your stack.
You could even get around that by doing a $FAOL into another buffer,
once you got the message... You already appear to have your arguments
on the stack, it's not that difficult to make $FAOL take arguments.
You cartainly don't HAVE to do them yourself!
/pjh
|
| 443.4 | Try an ACTRTN | KATYA::FISHER | Bill Fisher | Tue Apr 14 1987 12:01 | 5 |
| I thought that executing an action routine which returned with LBC would
keep $PUTMSG from writing to SYS$OUTPUT and SYS$ERROR. The description of
$PUTMSG doesn't seem to state this, but the FORTRAN example indicates that
it works that way.
|
| 443.5 | use $PUTMSG with action routine | SQM::RICO | | Tue Apr 14 1987 13:19 | 7 |
| .4 is correct. I have an application that uses $PUTMSG to format
messages and ship them through a mailbox. Exiting your action
routine with a "failure" status (LBC) with prevent $PUTMSG
from writing to SYS$OUTPUT or SYS$ERROR. This is not documented
that I can see so I don't know if it could change in the future.
Rico
|
| 443.6 | Solved | CHAMBR::GUINEAU | | Tue Apr 14 1987 13:33 | 11 |
|
Thats it! I think PUTMSG with an ACTRTN is the way to go.
Thanks !
John
|
| 443.7 | CHF questions | CASEE::COWAN | Ken Cowan | Fri May 01 1987 13:30 | 12 |
|
As for the other question, yes you can unwind through AST routines,
but you have to be careful. Some parts of VMS don't like asynchronous
unwinds.
I suspect you want to unwind the AST, and no further. This is
the normal case. To do that, have your AST routine enable
a handler, and from the handler call SYS$UNWIND with no arguments.
If you want your AST routine to return a value, modify the
saved R0 and saved R1 in the mechanism vector.
KC
|
| 443.8 | | WJG::GUINEAU | | Fri Sep 18 1987 15:06 | 10 |
|
> I suspect you want to unwind the AST, and no further. This is
> the normal case. To do that, have your AST routine enable
> a handler, and from the handler call SYS$UNWIND with no arguments.
>> If you want your AST routine to return a value, modify the
>> saved R0 and saved R1 in the mechanism vector.
Who would get the AST's value?
|
| 443.9 | fyi | SQM::RICO | | Tue Sep 22 1987 10:19 | 6 |
| Re .7
I believe that using LIB$SIG_TO_RET is the equivalent of doing
a $UNWIND with no arguments and placing a value in the saved R0.
Rico
|