Conference noted::hackers_v1

    Try "$ SET WATCH FILE /EVENT=MAJOR".

>      Anyone out there know of sneaky ways to get additional
>    error data out of RMS without modifying the source to this application?
 
    Sneaky hu, no source changes hu, well perhaps!
    How about creating a small shareable image:
    	- Entry points SYS$OPEN and SYS$CREATE.
    	- Calls the real SYS$routines, passing original parameter list.
	- Check results.
    	- If status is failure then somehow output STS, STV, (default)filename.
    Now re-link the application against this library and presto!
    I know for a fact that this  works for a cobol or macro application.
    I doubt whether it would work for an application where the file-io
    is handled through a sharable library (BASIC, COBOL, 3thParty..)
    In the later case you need to re-link the library againt the dummy
    rms library. This may very well be impossible.
    
    Then there are always SET WATCH (as replied previously) and perhaps
    the RMSLOG tool.
    
    		Hein.

    If the program is terminating with a traceback - then assuming you
    can at least re-link, make a small MACRO file with a contribution
    to LIB$INTIALIZE and insert your own handler at Vector 2.  This
    would allow you to get the signal and do something (print all info)
    about it...  Of course, this presumes that the program doesn't
    use the secondary vector.
    
    	good luck,
    
    		\rik
    
    ps.  Even if you can't link it in,  you could always use PATCH ;-)

    re:.1	No help for SET WATCH FILE /EVENT=MAJOR.  Is it documented?
    (I dont have the manuals).  I tried it and got %DCL-W-IVQUAL,
    Unrecognized qualifier... 
    
    Re:.2	My first thought was to intercept the RMS calls like
    you said.  The application is written in FORTRAN.  I will also look
    into the Toolkit for RMSLOG.
    
    Re:.3	Tell me more, sounds interesting.
    
    Larry

>    I have a customer (OEM) who sells a package that includes another
>    package in its configuration.  They are having problems with this
>    third party (fourth party??) application in that it delivers rather
>    terse RMS errors with almost no useful information ("Error Opening
>    File").  Anyone out there know of sneaky ways to get additional
>    error data out of RMS without modifying the source to this application?

     I suggest you edit the image header and toggle the bit that gives
     the debugger (this is how we got the passwords for Moria) then 
     check this out. You can also set the sysgen parameter for non-fatal-
     bugcheck and get a crash to wade in (maybe). 

     The Set watch suggestion should be your first step. Send mail if 
     your unfamiliar with any of the above and would like assistance
     this sounds kind of fun...

SET WATCH FILE /CLASS = [NO]ALL
                        [NO]ATTRIBUTES
                        [NO]CONTROL_FUNCTION
                        [NO]DIRECTORY_OPERATIONS
                        [NO]DUMP
                        [NO]ATTACHED
                        [NO]MAJOR_FUNCTION
                        NONE
                        [NO]QUOTA_OPERATIONS

Re .1

>    Try "$ SET WATCH FILE /EVENT=MAJOR".

Sorry if I appear dense, but what command is this? The only SET WATCH I can find
reference to in my 4.4 documentation set is "DBG> SET WATCH".

    Re .7, it's a 'hidden' DCL command that runs the SETWATCH.EXE program.
    
    --svb

	One I believe we should thank Mr. Gilbert for. 
        It is quite nice, though I believe undocumented because
	such flirtations with the XQP can have side effects. 

	The is a program on METOO called show comma that will
	extract the CLD for a DCL verb. I'd almost say Mr. Gilbert
        wrote this too, it's hard to say as legend and fact become
	blurry :^)

    Peter Gilbert *did* write SHCOMMA as well. 

SET WATCH requires privilege - something like CMKRNL.
							-- Jerry