mhg@MITRE-BEDFORD.ARPA (Mark H. Granoff) (06/15/88)
Recently I posted a message about surpressing the error output from
CLI$DCL_PARSE. I mentioned that if a SET MESS/NOFAC/NO... command is
issued before running the program, the error output does not display.
I did get a response from Mike Marques; he suggested using
LIB$ESTABLISH to set up a condition handler that does nothing. A good
idea in theory, but the manual recommends not using this service in
high level languages (like BASIC) that already have condition handlers
set up. I am using BASIC (stop laughing), and being curious, I tried
it out. My results were something less than successful. A condition
handler is overkill for my application anyway.
I did a little poking around in my "new and improved" Version 4.4
VAX/VMS Internals book ($75 from DEC, order #EY-8264E-DP) and found a
symbol for the process message mask. The symbol, CTL$GB_MSGMASK, is a
byte and definately is affected if a SET MESSAGE command is issued.
So, I have two questions:
1. Which bits in this byte represent which MESSAGE parts (i.e.
facility, severity, ident, text).
2. How can I easily access/modify this mask. Code examples are
always welcome, even MACRO-32. :-) Any other relevant tidbits of
information on this topic are also welcome.
Thanks in advance for any help.
+--------------------------------------------------------------------+
| Mark H. Granoff Member of the Technical Staff |
+--------------------------------------------------------------------+
| USMAIL: The MITRE Corporation | ARPAnet: mhg @ mitre-bedford.ARPA |
| Burlington Rd. | UUCP : linus!mbunix!mhg |
| M/S B015 |-----------------------------------|
| Bedford, MA 01730 | A T & T: (617) 271 - 7506 |
+--------------------------- Disclaimer -----------------------------+
| The views expressed herein are my own and do not necessarily |
| reflect those of my employer. |
+--------------------------------------------------------------------+kvc@nrcvax.UUCP (Kevin Carosso) (06/25/88)
In article <8806151302.AA18495@mitre-bedford.ARPA> mhg@MITRE-BEDFORD.ARPA (Mark H. Granoff) writes: >Recently I posted a message about surpressing the error output from >CLI$DCL_PARSE. I mentioned that if a SET MESS/NOFAC/NO... command is >issued before running the program, the error output does not display. > >I did get a response from Mike Marques; he suggested using >LIB$ESTABLISH to set up a condition handler that does nothing. A good >idea in theory, but the manual recommends not using this service in >high level languages (like BASIC) that already have condition handlers >set up. I am using BASIC (stop laughing), and being curious, I tried >it out. My results were something less than successful. A condition >handler is overkill for my application anyway. > >Thanks in advance for any help. For something like the CLI$ routines which signal their errors rather than returning a status, the conditional handler really is the only way to go. The caveat about using LIB$ESTABLISH from a high level language such as BASIC only applies to *how* you set up the handler, not whether you can have one. In Pascal, BASIC, PL/I, or Ada you want to use the built-in language facilities for establishing the handler and not call LIB$ESTABLISH directly. The handler you actually establish is no different in the high-level language (well, Ada may be a little different). In the case of the CLI$ routines, things are really easy since VMS provides some conditional handlers for your use. One of these, LIB$SIG_TO_RET, "converts any signalled condition value to a value returned as a function. The signaled condition is returned to the caller of the user procedure that established the handler that is calling LIB$SIG_TO_RET. This routine may be established as or called from a condition handler." In Pascal you would need to declare the routine LIB$SIG_TO_RET as [ASYNCHRONOUS, UNBOUND] and then simply use: Establish (LIB$SIG_TO_RET); in any procedures that want to catch CLI$ signals and convert them into return values. BASIC will probably be very similar. /Kevin Carosso kvc@nrc.com Network Research Co. kvc@ymir.bitnet kvc@nrcvax.uucp