RE: [TRNSYS-users] Run time error - Unit-1 file CONOUT$

[Edward Halawa <Edward.Halawa@unisa.edu.au>]

Michael,

Yes, it was due to the WRITE statement present in my DLL. I included this WRITE
instruction previously for checking my program outside the TRNSYS. Before I
made modification, my program had always run succesfully. I suspect therefore
there is something wrong with my modification which the program reports as
error by attempting to display a message in the screen and causes the run time
error. I'm now rechecking my modification.

While I'm checking this bug, it would be worthwhile if you could tell me how to
transfer the ERROR CHECKING to TRNSYS, so that I can avoid the WRITE statement
in my DLL. In DLL "template" provided, no mention of such ERROR CHECKING. The
main reason why I decided to write my subroutine as DLL (as opposed to ordinary
TYPE in TRNSYS) is because the DLL "template" provided is easier for me to
follow than the ordinary TYPE "template". [FYI: Previously I wrote my program
in VB, then transferred it to Visual C/C++, and finally to FORTRAN, due to the
fact that my previous attempts to create my DLL in VB & C/C++ and made it a
TNRSYS component, failed].

I'm also trying to convert my DLL to ordinary TYPE subroutine, but I always get
the message something like: YOU ATTEMPT TO CALL A SUBROUTINE WHICH HAS NOT BEEN
LINKED ...

I would greatly appreciate your help.

Regards,

Edward Halawa

-----Original Message-----
From: Michaël Kummert [mailto:kummert@engr.wisc.edu] 
Sent: Saturday, 21 August 2004 7:58 AM
To: 'trnsys-users@engr.wisc.edu'
Subject: Re: [TRNSYS-users] Run time error - Unit-1 file CONOUT$

This shows that the error occurs inside your DLL. Error 68 is described 
in the Visual Compaq Fortran help (I pasted the text here below).

severe (68): Variable format expression value error
FOR$IOS_VFEVALERR2. The value of a variable format expression was not 
within the range acceptable for its intended use; for example, a field 
width was less than or equal to zero. A value of 1 was assumed, except 
for a P edit descriptor, for which a value of zero was assumed.

I suggest that you step through your code looking for the WRITE 
instruction that causes the problem. You can debug your DLL by making it 
the "active" project in CVF.

The fact that the error ocurs writing to CONOUT suggests that you have a 
"WRITE(*,...)" or WRITE(LUN,...) where LUN=1 (and I don't think you will 
see the output anywhere by the way because this is supposed to write to 
the screen). Some "write" problems also occur when sharing logical units 
between DLL's if the project is not linked against the DLL version of 
standard libraries.

Kind regards,

Michaël Kummert