IOSTAT on OPEN

[DavidWhite]

Can you tell me what is wrong with this file open?

[cpp]WRITE(99,*) 'Reading Local License "'//TRIM(INSTPATH)//''//TRIM(ModName)//'.lc"'
Open (2,FILE='"'//TRIM(INSTPATH)//''//TRIM(ModName)//'.lc"',STATUS="OLD", &
    ACTION="READ",SHARE="DENYWR",IOSTAT=I)
WRITE(99,*) "Local IOSTAT", I  
The output to unit 99 is ...

 Reading Local License "C:Program FilesAHEAPropsAHEAPROPS.lc"
 Local IOSTAT          43


Thanks
[/cpp]

[rase]

Quoting - David White

[cpp]WRITE(99,*) 'Reading Local License "'//TRIM(INSTPATH)//''//TRIM(ModName)//'.lc"'
Open (2,FILE='"'//TRIM(INSTPATH)//''//TRIM(ModName)//'.lc"',STATUS="OLD", &
    ACTION="READ",SHARE="DENYWR",IOSTAT=I)
[/cpp]

Maybe (UNIT=2.....) ?

[tropfen]

Hello,
you are using a lot of " and ' .

have a try with:
file=TRIM(INSTPATH)//''//TRIM(ModName)//'.lc'

Frank

[DavidWhite]

Quoting - tropfen

Hello,
you are using a lot of " and ' .

have a try with:
file=TRIM(INSTPATH)//''//TRIM(ModName)//'.lc'

Frank

I added the extra quotaions as I previoulsy got another error - code 29, I think it was. I wondered whether the space in "Program Files" was causing the issue, so added the quotes around the filename to avoid that.

D

[Steven_L_Intel1]

You don't need (and I think cannot use) the quotes in this context - that's only when entering filespecs on the command line.

How about assigning the string to a character variable then referencing the variable in the OPEN and also writing it to the console? Or take out the IOSTAT so that the error message is displayed.

[tropfen]

Quoting - David White

I added the extra quotaions as I previoulsy got another error - code 29, I think it was. I wondered whether the space in "Program Files" was causing the issue, so added the quotes around the filename to avoid that.

D

I never had any problem with having spaces insides filenames, as long as i was working inside windows.

Frank

[tropfen]

Quoting - Steve Lionel (Intel)

You don't need (and I think cannot use) the quotes in this context - that's only when entering filespecs on the command line.

How about assigning the string to a character variable then referencing the variable in the OPEN and also writing it to the console? Or take out the IOSTAT so that the error message is displayed.

Two questions about your reply:

1) is there a difference if i use a constructed filename (like trim(path)//trim(filename) ) or i use a single character?
2) If i have no iostat i will get a nice error message during debug. But is this message different to the iostat number?

Frank

[DavidWhite]

Quoting - David White

I added the extra quotaions as I previoulsy got another error - code 29, I think it was. I wondered whether the space in "Program Files" was causing the issue, so added the quotes around the filename to avoid that.

D

Steve,

Done as suggested

Log file contents are
Reading Local License from C:Program FilesAHEAPropsAHEAPROPS.lc

I created a shortcut to the file in Windows, which has the contents
"C:Program FilesAHEAPropsAHEAPROPS.lc" (just to prove file is actually there)

Error message when running is
forrtl: severe (30): open failure, unit 2, file C:Program FilesAHEAPropsAHEAPROPS.lc
on line 68 of Checklic.f90, which is

[cpp]        Open (2,FILE=TRIM(COMMAND),STATUS="OLD", &
            ACTION="READ",SHARE="DENYWR") !,IOSTAT=I)
[/cpp]

where COMMAND has the contents as printed above in the Log file.

I should explain the context - the code is in a DLL which is called from Excel via a VBA call - hence it can't be debugged in VS.

thanks,

David

[DavidWhite]

Quoting - David White

Steve,

Done as suggested

Log file contents are
Reading Local License from C:Program FilesAHEAPropsAHEAPROPS.lc

I created a shortcut to the file in Windows, which has the contents
"C:Program FilesAHEAPropsAHEAPROPS.lc" (just to prove file is actually there)

Error message when running is
forrtl: severe (30): open failure, unit 2, file C:Program FilesAHEAPropsAHEAPROPS.lc
on line 68 of Checklic.f90, which is

[cpp]        Open (2,FILE=TRIM(COMMAND),STATUS="OLD", &
            ACTION="READ",SHARE="DENYWR") !,IOSTAT=I)
[/cpp]

where COMMAND has the contents as printed above in the Log file.

I should explain the context - the code is in a DLL which is called from Excel via a VBA call - hence it can't be debugged in VS.

thanks,

David

I have a work around, but can't explain ... removed the SHARE="DENYWR" option, and now works perfectly. I am running on thelocal machine, no other users have access to the file, and no other processes should be accessing it.

Anyideas?

While this app uses a local license file, other apps I work with use a server copy, which I do need to protect from being accessed in write mode asthe licensefileis managed and can be updated remotely.

I am using IVF 11.0.061

thanks,

david

[DavidWhite]

Mea Culpa

I attempted opening the same file (to a different unit no.) in the parent program to check that it was available, and never closed it. This earlier OPEN did not have the READ attribute, so was readwrite an so the second OPEN failed.

Sorry for wasting your time.

David

[IanH]

Quoting - David White

... the code is in a DLL which is called from Excel via a VBA call - hence it can't be debugged in VS.

Totally irrelevant point to the OPEN issue - but debugging in Visual Studio a Fortran "DLL which is called from Excel via a VBA call" is very possible. Briefly: Compile the DLL in debug mode, make sure the VBA code references that debug version of the DLL, attach the VS debugger to the Excel process, set your breakpoints in your DLL code, cross your fingers while you get Excel to execute the relevant VBA wrapper code and bingo!

Or are you doing something trickier?

[DavidWhite]

Quoting - IanH

Totally irrelevant point to the OPEN issue - but debugging in Visual Studio a Fortran "DLL which is called from Excel via a VBA call" is very possible. Briefly: Compile the DLL in debug mode, make sure the VBA code references that debug version of the DLL, attach the VS debugger to the Excel process, set your breakpoints in your DLL code, cross your fingers while you get Excel to execute the relevant VBA wrapper code and bingo!

Or are you doing something trickier?

Ian,

How do I attach the VS debugger to the Excel process?

The functions in the DLL are called from from the spreadsheet via a user function in the VBA wrapper.

Thanks,

David

[IanH]

Under VS2005 it is Debug > Attach to Process. Don't be surprised if VS "freezes" up for a minute or so while it attaches.

[Steven_L_Intel1]

There's an easier way. In your DLL project, set the project property Debugging > Command to the path of the executable (VB, Excel, etc.). Set a breakpoint in your DLL routine. Start debugging - VB/Excel/whatever will start and when it calls your DLL the breakpoint will be hit. I do this all the time.