- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I have an Excel VBA application that calls a VF DLL. Each subroutine in my DLL calls a particular IMSL routine. The subroutine that calls IMSL routine LINRG is failing with the message, "forrtl: severe (38): error during write, unit 6, file CONOUT$". Following that is a traceback listing through DFORRTD.DLL, PFRheometer.dll (my application), VBE6.DLL, OLEAUT32.dll, and VBE6.DLL. The values for Routine, Line, and Source in all of these lines are "Unknown" except for one of the routines, INVERTALPHADU, in PFRheometer.dll. That line lists the line number that makes the call to LINRG.
I'm guessing that LINRG is issuing some kind of error message to the console. I want to see it, but I'm not sure how to do that. I tried OPENing unit 6 with file='CONOUT$' before the call to LINRG, but that didn't change anything. I know that I've seen postings mentioning a Windows routine to provide a console in this forum or the old Compaq one, but I couldn't find any by searching.
Anybody got any suggestions on how to proceed?
I'm surprised that Visual Numerics would have the IMSL routines spitting out messages to the console. Returning error codes to the caller seems to be the better way to go. I don't remember seeing any mention of this when I looked through the IMSL documentation to find the routines I needed.
Mike
I'm guessing that LINRG is issuing some kind of error message to the console. I want to see it, but I'm not sure how to do that. I tried OPENing unit 6 with file='CONOUT$' before the call to LINRG, but that didn't change anything. I know that I've seen postings mentioning a Windows routine to provide a console in this forum or the old Compaq one, but I couldn't find any by searching.
Anybody got any suggestions on how to proceed?
I'm surprised that Visual Numerics would have the IMSL routines spitting out messages to the console. Returning error codes to the caller seems to be the better way to go. I don't remember seeing any mention of this when I looked through the IMSL documentation to find the routines I needed.
Mike
Link Copied
11 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
You can add a call to AllocConsole() to accept I/O directed to the console before that call. You can also add a PAUSE after the call to the offending routine as a "breakpoint" so you can read the message.
For example:
use kernel32
...
call AllocConsole()
...
call LINRG(...)
pause
...
James
For example:
use kernel32
...
call AllocConsole()
...
call LINRG(...)
pause
...
James
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
James,
Thank you. That worked. I didn't need the PAUSE statement because I'm working with a debug configuration, and the debugger stopped at the next statement and allowed me to see the message in the console window.
When I looked up the definition for AllocConsole in the VF online help, it was defined as BOOL AllocConsole(void). Is it always the case when the VC++ definition for a variable is (void) that you simply use the empty parentheses () in the equivalent VF call?
Mike
Thank you. That worked. I didn't need the PAUSE statement because I'm working with a debug configuration, and the debugger stopped at the next statement and allowed me to see the message in the console window.
When I looked up the definition for AllocConsole in the VF online help, it was defined as BOOL AllocConsole(void). Is it always the case when the VC++ definition for a variable is (void) that you simply use the empty parentheses () in the equivalent VF call?
Mike
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
(void) means no arguments, so just:
call AllocConsole
would work.
Steve
call AllocConsole
would work.
Steve
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Yes, C++ void means "nothing" (and if function result, means "subroutine"). But you shouldn't substitute function for a subroutine; James made a typo. Although you may not see apparent effect, I think that corrupts the stack in Fortran. Maybe I'm wrong, but it's better to be on the safe side.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Mike,
We use the NAG maths libraries and their intrinsic diagnostic output gives us no end of headaches. I've seen the exact error you quote! Because the code is so ancient (F77 and previous!), output defaults to unit 6. NAG has a couple of controlling routines that allow you to specify a) whether you want any output, and b) what LUN to write it to (i.e. to a sepcified file),. If you don't call those routines prior to your routine of interest, you're likely to end up with output being written to unit 6, and thence to crashing and burning.
The origins of all these major maths libraries seem a bit incestuous, so I wouldn't be surprised if IMSL works in a similar manner - look for routines that control the diagnostic output.
We use the NAG maths libraries and their intrinsic diagnostic output gives us no end of headaches. I've seen the exact error you quote! Because the code is so ancient (F77 and previous!), output defaults to unit 6. NAG has a couple of controlling routines that allow you to specify a) whether you want any output, and b) what LUN to write it to (i.e. to a sepcified file),. If you don't call those routines prior to your routine of interest, you're likely to end up with output being written to unit 6, and thence to crashing and burning.
The origins of all these major maths libraries seem a bit incestuous, so I wouldn't be surprised if IMSL works in a similar manner - look for routines that control the diagnostic output.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Look at ERSET for instance :)
Dan
Dan
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
General comment, I like to use empty parenthesis for consistency and readability for calls lacking formal parameters.
Jugoslav, you are incorrect about corrupting the stack. In this case the compiler simply doesn't use the call return register. Is there a reason you think CVF wouldn't handle this?
James
Jugoslav, you are incorrect about corrupting the stack. In this case the compiler simply doesn't use the call return register. Is there a reason you think CVF wouldn't handle this?
James
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
You can corrupt the floating point stack if you call a function that returns a floating result in a way that the caller doesn't see the result, or if you call a function that DOESN'T return a floating result in a way that makes the caller think it does. There's no problem with functions that return integer results.
Steve
Steve
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Dan,
I looked up the ERSET routine, and it will allow me to suppress output from all of the IMSL routines. I'll use that once I solve my problem with using LINRG. Even though I can call FreeConsole to get rid of every console I create with AllocConsole, my application makes the console windows dance across the screen because it calls LINRG many times. Although somewhat entertaining, I doubt that it's what the users want to see, and creating and destroying all those windows has got to be taking extra time.
Mike
I looked up the ERSET routine, and it will allow me to suppress output from all of the IMSL routines. I'll use that once I solve my problem with using LINRG. Even though I can call FreeConsole to get rid of every console I create with AllocConsole, my application makes the console windows dance across the screen because it calls LINRG many times. Although somewhat entertaining, I doubt that it's what the users want to see, and creating and destroying all those windows has got to be taking extra time.
Mike
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Mike,
One strategy we've used in the past is to turn off intrinsic diagnostics, but watch the error conditions from the maths routines, and create your own diagnostics that you can control and send where you want. This is a bit more work, but can be D-Lined so that it can be used to get the code working, but ultimatley has little effect on the speed.
Dan
One strategy we've used in the past is to turn off intrinsic diagnostics, but watch the error conditions from the maths routines, and create your own diagnostics that you can control and send where you want. This is a bit more work, but can be D-Lined so that it can be used to get the code working, but ultimatley has little effect on the speed.
Dan
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
My VB collegue won't allow me to "allocate a console" when my Fortran DLL (using IMSL calls) is fired by his VB app. The method Judd proposed cannot capture all reported errors for all IMSL function calls. Therefore, I use a wrapper for every IMSL function call using a simple mechanism as follows:
Any other idea?
-George
! open a file in case IMSL function may dump error info call file_open(cs_dumppath,cs_subname,io_unit) ! set imsl routine to report all levels of errors ! print error message and do not stop if error ocurrs call erset(0,1,0) ! open a file and re-direct the imsl error output to this file call umach(-3,io_unit) ! call the IMSL call IMSL_Function ! Get the IMSL error code & do proper handling imsl_errcode = iercd() if (imsl_errcode /= 0) then !extract error message from the error dump file !and report to global error log call read_imslerr(io_unit) end if
Any other idea?
-George
Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page