Question using Open Statement on Server

[Michael8]

Hello:

I have created the following simple test program:

program Test  open(10, name='temp1', status='old', err=1)  stop1 open(10, name='temp1', status='replace')
end

It works fine (i.e. it doesn't crash) when I run it from my local machine. But when I copy the solution and project to a server directory (to which I havefull write permission), and run it from the server, it crashes at line 1 saying that it can't open the file. I noticed, though, that if I change the file names to "D: emp1" (so that it's trying to open the file on my local machine), then it runs, even from the server.

This seems strange to me. What am I missing? Is it perhaps a compiler bug?

Thanks.
Michael

[Steven_L_Intel1]

Please provide the complete and exact text of the error message. When you say you "run it from the server", what exactly do you mean?

[Michael8]

I have attached a screen shot of the error message showing that it crashed when trying to open the file.

By running from the server I mean that I copied the entire solution folder (and contents) to a server on our network and rebuilt the solution. (The rebuilding was probably unnecessary.) I then ran it from that solution on the server using "Start without debugging". Practically, I think the only difference between running it on the server and runnning it on my machine is the working directory of the program when it executes.

I can attach a zip file of my solution if that would help.

Thanks.
Michael

[Steven_L_Intel1]

I tried an example and I saw this:

'servernameF$SharedConsole55'
CMD.EXE was started with the above path as the current directory.
UNC paths are not supported. Defaulting to Windows directory.

I expect you're seeing much the same. When you run a program from within Visual Studio, it sets the default directory to the project directory. Windows does not support UNC paths for this. Instead, mount the share as a device letter and use it that way.

[Michael8]

No, I do not see that message. The screenshot that I posted is exactly what I get.

I tried mapping a drive and running it from the command line using the mapped drive, but got the exact same results. I've attached another screen shot of the error usingthe mapped drive.

Thanks
Michael

[Steven_L_Intel1]

I just tried your code in a test case and it worked for me. I note that the name of the file you're opening is the same as the name of the executable - I wonder if that's an issue.

[Michael8]

Sorry about picking the same name for the file as for the executable. That was just due to my lack of imagination. But I just tried changing the name of the file and it made no difference: it still runs fine on my local D: drive, but crashes when I run it on a server across the network.

I'm running IVF 10.1.021. Is that the version you tried it with? (If not, can you try it with that version?)

Note that if you ran it on a local drive and it worked (as it should have), and then copied the entire solution folder to a server, it still would likely work. This is because it you copied the entire folder, you probably also copied the file "temp" that was created when you ran it on your local drive. So when you ran it on the server, it saw that "temp" existed and completed running sucessfully. Perhaps you could try deleting "temp" from you the server folder and thenrunning it again.

Thanks.
Michael

[Steven_L_Intel1]

I tried it with 10.1.024, which is the current version. I don't have 021 installed but don't expect that to make a difference. I tested it again making sure that the data file was not present, and it worked fine with a mapped drive instead of a UNC path.

[Michael8]

I'm probably just grasping at straws, but would you mind trying to use the attached zip file to see if you can reproduce it?

Thanks.
Michael

[Steven_L_Intel1]

Works fine for me. I unpacked the ZIP to a folder on a shared drive (mapped to a letter), opened the solution in the share, built with 10.1.024 and ran it.

[Michael8]

Thanks for tryng this.

I just upgraded to 10.1.024. As you guessed, it made no difference: the program still crashed when I ran it over the network.

I dofind it curious though, that when I run it over the network, it makes no difference for me if I use a mapped drive or not. I don't get that message you refferred to earlier about Windows not being able to start with a UNC path. (I've seenthat messagea bunch of times relating to other things whenI've tried to start a command prompt over the network, but not with this little test program.)

If you have any other suggestions about what could be causing this -- I'd love to hear them!

As always, thanks.
Michael

[Steven_L_Intel1]

Can you try a program that opens a new (or 'unknown') file first and then does an INQUIRE to get its filename? What type of system is the remote server? (Mine is XP)

[Michael8]

I was able to open a file and "inquire" to get its file name. I've attached the program I used -- hopefully I did what you were asking.

Our workstations here are running XP, but the servers are running Windows 2003 Server.

Thanks.
Michael

[Steven_L_Intel1]

I guess the next step is to try each step in your original program independently. Do the first open with the err= removed and see what happens. Try the second open by itself. What are your permissions on the server? Try opening an "administrative share" (eg, C$) on your own system and try it that way.

[Michael8]

Everything seems to work "normally" when I do the steps independently.

Leaving off the "err =" in the first open statement causes the program to crash immediately (as would be expected) since the file "temp" does not exist. Just using the second open statement by itself works fine (i.e., no crash), also as would be expected. My permission on that drive of the directory on the server is set to "Full Control".

When I mapped a drive to the "adminstrative share" version of that directory on the server, I got the same crashwhen the program reachedthe second open statement.

Thanks.
Michael

[Steven_L_Intel1]

Try this version:

program Test
use ifport
open(10, name='temp1', status='old', err=1)
stop
1 call sleepqq(1000)
open(10, name='temp1', status='replace')
end

[Michael8]

Same result (i.e., it crashed), but after a delay of 1 second. I tried bumping it up to 5000 to have it delay for 5 seconds, but this did not help either.

Thanks.
Michael

[Steven_L_Intel1]

I'm out of ideas, then. You say that the second OPEN works by itself - just not if preceded by the first. Is that right?

It would be interesting to see if other readers can replicate this.

[Michael8]

Well, thanks for taking your time to share your ideas up till now. I've also run out of ideas, so I was hoping to get some brainstorming ideas from here!

Yes, the second open statement by itself works fine. It's only when the first one fails that the second one also fails. A co-worker in my office reproduces the exact same results as me when using the zip file attached to my earlier post. It runs on his local machine but not on the server.

If any other forum users could give this a try and report their results, that would be great...

Thanks.
Michael

[Michael8]

Still grasping at straws here...

Steve, your earlier post mentoined that you had done your tests on an XP server. Even though our regular servers here run Windows Server 2003, I tried a test where I shared out a drive on my XP machine and had a co-worker use run the program over that shared drive. Sure enough, it worked for him, even though it didn't work when he ran it on a Windows 2003 server.

So it looks like the server type may make a difference. Is there any way you could try and run the program over the network on a Windows 2003 Server machine to see if you can get it to crash?

Thanks.
Michael

[Steven_L_Intel1]

I tried on a Windows Server 2003 system and got the identical behavior I did on XP. If I used the UNC path to open the project, I got the error about not being able to use UNC paths for a default. If I used a mapped drive, it worked fine.

What happens if you open a command prompt window, set default to the mapped drive and run the program?

You may have a permissions problem on the share.