mhg@mitre-bedford.ARPA (Mark H. Granoff) (06/09/88)
Here's what may amount to be a trivial question, but I don't see the simple answer... I am writing an application in which I would like to do DCL parsing, using CLI$xxx routines, CLI tables, etc. I know how to do this. The problem is in the way CLI$DCL_PARSE works. If the command string it is parsing is erroneous, it spits out an error message (not unlike DCL error messages). My application uses FMS; error messages printed to the screen (without using FMS calls) would mess up the display. I wrote a little test program (complete with test CLD) and discovered that a SET MESSAGE/NOID/NOFAC/NOTEXT/NOSEV before invoking the image successfully suppresses the error output (yeah!). So, how do I operate on the SET MESSAGE bits (to save them and change them) from within a program. I do not want to use LIB$SPAWN or anything slow like that. I know I could use a command procedure, but some code to do the same thing would be much niftier :-). Thanks for any help. I apologize if I'm missing the boat on something obvious. ** Please respond directly to me since I do not subscribe to comp.os.vms. +--------------------------------------------------------------------+ | 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. | +--------------------------------------------------------------------+
rrk@byuvax.bitnet (06/12/88)
I would recommend a macro solution (This is untested, but it has worked
for me in similar situations):
.entry dcl_parse,^m<r2,r3,r4,r5,r6,r7,r8,r9,r10,r11>
movab g^lib$sig_to_ret,(fp)
callg (ap),g^cli$dcl_parse
ret
You can do the same thing in a high level language by using lib$establish
and explicitly passing all the parameters from dcl_parse to cli$dcl_parse.
Now you can call dcl_parse instead of cli$dcl_parse which should return
a status value in R0 instead of signaling the error.mhg@MITRE-BEDFORD.ARPA (Mark H. Granoff) (06/14/88)
[This has already been cross posted to the comp.os.vms newsgroup] Here's what may amount to be a trivial question, but I don't see the simple answer... I am writing an application in which I would like to do DCL parsing, using CLI$xxx routines, CLI tables, etc. I know how to do this. The problem is in the way CLI$DCL_PARSE works. If the command string it is parsing is erroneous, it spits out an error message (not unlike DCL error messages). My application uses FMS; error messages printed to the screen (without using FMS calls) would mess everything up. I wrote a little test program (complete with test CLD) and discovered that a SET MESSAGE/NOID/NOFAC/NOTEXT/NOSEV before invoking the image successfully suppresses the error output (yeah!). So, how do I operate on the SET MESSAGE bits (to save them and change them) from within a program. I do not want to use LIB$SPAWN. Thanks for any help. I apologize if I'm missing the boat on something obvious. Please respond directly to me (to avoid flooding the network with responses). +--------------------------------------------------------------------+ | 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. | +--------------------------------------------------------------------+
nagy%warner.hepnet@LBL.GOV (Frank J. Nagy, VAX Wizard & Guru) (06/16/88)
> I am writing an application in which I would like to do DCL parsing, > using CLI$xxx routines, CLI tables, etc. I know how to do this. The > problem is in the way CLI$DCL_PARSE works. If the command string it > is parsing is erroneous, it spits out an error message (not unlike DCL > error messages). My application uses FMS; error messages printed to > the screen (without using FMS calls) would mess up the display. CLI$DCL_PARSE does not write the message to the screen; it just signals the error and the traceback handler is writing onto the screen. The way to fix this problem is to write your own exception handler (see Section 7 of the VAX/VMS Run-Time Library Routines Reference Manual) to trap these messages. Your exception handler can then either toss them in the junk or be fancier and generate its own display of the messages (in which case you also want to look at the $GETMSG or $PUTMSG system service to translate the signal to text. The $PUTMSG service is the one being used by the traceback handler to display the message you are objecting to; I have used $PUTMSG with user-specified action routines to grab the text in my own exception handlers and send it OPCOM - for instance). The advantage of the exception handler is that it can handle only those errors it understands and pass others (maybe like ACCVIO) on to the traceback handler for some sort of final error message and exit. Also, you can establish your exception handler only for the routine in which you call CLI$DCL_PARSE to better localize its actions. = Frank J. Nagy "VAX Guru & Wizard" = Fermilab Research Division EED/Controls = HEPNET: WARNER::NAGY (43198::NAGY) or FNAL::NAGY (43009::NAGY) = BitNet: NAGY@FNAL = USnail: Fermilab POB 500 MS/220 Batavia, IL 60510
jayz@cullsj.UUCP (Jay Zorzy) (06/28/88)
From article <8806141226.AA03010@mitre-bedford.ARPA>, by mhg@MITRE-BEDFORD.ARPA (Mark H. Granoff): > ...problem is in the way CLI$DCL_PARSE works. If the command string it > is parsing is erroneous, it spits out an error message (not unlike DCL > error messages). My application uses FMS; error messages printed to > the screen (without using FMS calls) would mess everything up. Have you tried establishing a condition handler around your calls to the CLI$... routines? If not, you might try this. For example: (in C:) { LIB$ESTABLISH (cond_handler); stat = CLI$DCL_PARSE (...); LIB$REVERT (); If (stat !== CLI$_NORMAL)... . . . } int cond_handler () { return (SS$_CONTINUE); /* To prevent resignalling */ } In this example, 'cond_handler' will trap any errors generated by the CLI$DCL_PARSE routine and basically ignore them. But you're checking the return status after the call, so you should be covered. For more information on condition handlers, see the System Services and the Run-Time Library manuals. Hope this helps. Jay Zorzy Cullinet Software San Jose, CA