Its been a while since I actually programmed with an Amos system. I'm trying to port a system with old code and get "File In Use" when it tries to open a Random file.

Would this be because I'm testing on a single system and the file is on the same system i.e. no networking involved? Or does it mean the file actually appears to be opened exclusively?

I would expect this shouldn't happen.

Ed

Hi Ed, are you running some old code an a AMOS system, if not then what system are you trying to run some old AMOS code on? Linux, AIX, Windows.

If Linux or AIX you could try:
lslk /vm/miame/location/filename
To see what other process might have it locked, (maybe yourself?)

Windows I think there is something in system tools to check who has files locked.

I also vaguely remember some problem with file in use when we first ported, but cannot get a finger on it.

Lets see what anybody else has after you amplify the situation/enviroment a somemore.

Have a nice day.

Hi Ed,

It will help if you write here the code you're using for open the file.
In advance:
open #chanel,filename,RANDOM'FORCED,recsize,recno

where RANDOM'FORCED will guarantee that you can open it in concurrent sessions.

As Ken mentioned, more details about the environment will help.

regards

Ed,

If you're working in a single-user environment, you probably want to make sure LOKSER is turned off. Use SET NOLOKSER from the dot prompt, or look in the MIAME.INI for LOKSER=ON and change it to LOKSER=OFF (or add it if there is no LOKSER statement.)

With LOKSER ON, opening a file for RANDOM means exclusive; you need RANDOM'FORCED for sharing. With LOKSER OFF, A-Shell does not use the operating system's file locking system, which generally leaves it up to you to work out multi-user access issues with some other locking mechanism, like XLOCK.SBR or FLOCK.SBR.

On the other hand, if it is really a single user environment, it wouldn't matter if you opened the files exclusive or not. So that does suggest that there may be something else going on that doesn't meet the eye.

Jack

Hello All!
Thanks for the responses. The speed of response is truly inspiring.

Ok, as to environment, I'm helping port an old system that has been running on a Alpha Micro machine until now. Its not code I wrote and I'm trying just to get the port done before changing anything. The new environment will be a Windows server with PC (windows) workstations, but I'm just trying to get it up and running on my PC running Windows 2000.

I couldn't remember precisely what the "File In Use" meant. Its not file channel in use, so I figured the system thought the system was opening things exclusively. It turns out that LOKSER=ON was on in the miame.ini so I'll have another go.

However, the code looks pretty nuts to me.

Here it is in all is glory:

________________
00940 OPEN #2, DEVICES(2)+":CUSIDX.DAT", RANDOM, RECSIZ2, FILE2
00950 OPEN #4, DEVICES(4)+":SALES.DAT", RANDOM, RECSIZ4, FILE4
00960 OPEN #10,DEVICES(10)+":ARCTL.DAT",RANDOM,RECSIZ10,FILE10
00970 IF (SWITCH <> 9) THEN GOTO OPEN13
00980 CALL CLOSE1
00990 GOTO END1
01000 OPEN13:
01010 OPEN #13, DEVICES(4)+":SALES.DAT", RANDOM, RECSIZ13, FILE13
01020 OPEN #1, DEVICES(1)+":CUSMAS.DAT", RANDOM, RECSIZ1, FILE1
01030 FILE1=1
01040 READ #1,CUSMAS
01050 BSEND = ORGREC
01060 FILE13=1
01070 READ #13,DUMSLS
01080 MAXCNT = MAXREC
-------------------------------
It seems to me Sales.Dat is getting opened twice for no good reason (unless the program exits). I'm pretty rusty here, but that looks clear.

My big problem is that I don't know which version of the source is the current one.

Just to get this straight in my head, it appears to me that when we deploy for production use that all files must be on the server. The queue files must also be on the server I'd guess.

Is there a way to keep the run files on the workstations, or is it simpler just to keep it all on the server? It looks that way.

Thanks for your help.

Ed

Hi

It seems turning LOKSER OFF does the trick.

It also seems that the source isn't a good copy. In fact, they don't seem to have a good copy. Lets hope I never have to change it.

Ed

Interesting code, looks like the programer(??) was trying to open the same file on 2 different channels. Maybe to read then update or something.

If you shut of locking it should run on a single server, but won't do you much good in a production enviroment. Maybe Jack has a way around this without reprograming.

When we run on windows we have all the files on the server, then map a drive on each PC (use the same drive letter) to a shared VM on the server. Then you can use that drive letter in the miame.ini or use the //ntserver// nomenclature in the server. We found it was faster to also have the user on the server to run through a mapped drive also.

The problem with putting the runs on each PC is one updating the runs on each PC. Next having to have seperate mapped devices in seperate named ini's for each PC. We did not find any real speed decrease in always loading the runs from the server.

We do mostly Linux, so I am going to let the real windows users guide you.

Good Luck Ed.

Hi Ed,

Looking to the code, there's no doubt where the problem is, opening the same file twice with different channels and RANDOM instead of RANDOM'FORCED the "file in use" will be inevitable.

About how to configure A-Shell to run in Windows servers and Windows workstations it's the simplest software I know to setup.
Just move the installation you've done in your workstation to the server.
On the server, change all the statements in MIAME.INI with c:\ to \\servername\c\
In your workstation, change the path to ASHW32.EXE and to MIAME.INI to \\servername\c.
After this, you'll be able to run A-Shell on the server.

This is the easy part.
When running on Windows, most of the problems arise from the Windows server environment and networking conditions rather than A-Shell, that is, what you're running on the server, what OS you have on the workstations.

The best will be to have an W2000 server only as file server without any other heavy software like Exchange.
On workstations, all and I mean all, with W2000 or XP Pro.
But these are the rules for a good Windows network environment considering or not A-Shell.

I still don't have a definite opinion if using MAP drives instead of UNC paths in MIAME is better, what I know is, using UNC I don't have the problem of frequently have to re-map the drive because the user deactivate it but, I think, the true difference is in the global status of the server and network.

Probably most if not all the things described you already know but, keep asking.

Regards