Lizbeth
9th April 2002, 18:21
how can i set lock on a file ascii for prevents any process from write in the file..

I try "SEQ.LOCK" and "SEQ.ISLOCKED" but it is not working.

can anybody give a an example please

Thanks in advance

shah_bs
9th April 2002, 22:07
I am sure you must have tried the seq.lock command as follows:

seq.lock(SEQ_F_W_LCK, 0, 0, filepointer)

where SEQ_F_W_LCK is for File Write Lock


If this does not work, another alternative is to use application locks. This will prevent the session from being able to start by two different users at the same time.

NPRao
9th April 2002, 22:24
Hi Lizbeth,

I made a test program and the seq.lock/seq.islocked didnt work to me too. I will log a call with BaaN Support and seek clarification from them.

I just tried to put an application lock on file, I dont think the application locks work on files but only 4-GL sessions.

I dont know whats your exact requirement is. But if you are doing some file handling/error logging then an alternative approach to deal with the situation is to create a temporary file, by

Syntax

string creat.tmp.file$( [string pathname] )

Description

This creates a temporary file. By default, the file is created in the current directory. To create the file in a different directory, use the optional pathname argument to specify the full path to the required directory.
In UNIX environments, a unique temporary file is created with UNIX-privilege mode 0664.

so that every file you create is a temporary unique one and you can copy/move to any new file name you like.

Syntax

long file.cp( const string source, const string target )

Description

This copies a specified source file to a specified target file. Both files can be either local or remote. They can also be on different hosts (provided that the bshell can access both hosts).

NPRao
10th April 2002, 21:23
Updates from BaaN -

The procedure that you have followed is absolutely correct and it seems like there is something wrong with seq.lock.

Please log a Scopus case regarding this.


I also logged a call with the BaaN support site, I hope they will fix the bug soon.

Thanks for the lead, LizBeth. It is always fun to explore into the BaaN tools.

Lizbeth
12th April 2002, 22:09
NPR

I solved my problem with the temporary file.

Thanks a lot !

NPRao
11th June 2002, 19:54
More updates from BaaN Support -



Please find below the explanation on locking mechanism. I have tested and observed the same behaviour in Baan IVc, Baan Vc etc versions. Hope this helps. Please let me know if you have any questions.

The program is working differently than you expect on this issue:

When you execute the lock function the bshell is calling the OS function lock to lock the file. Then a mark is made on the file to inducate that it is locked.

If you then do a request to the OS to check the lock a new OS function is called. However, when this is from the same process the OS will not return that the file is locked, because the process that locked the file is the same as making the request, and that process knows it is locked. It is locked by that process, so in fact it is not locked for that process, only for other processes. So doing a check if the file is locked from the same process as doing the lock will not indicate that the file is locked.

This is for OS processes, not for Baan processes. Running different sessions in the same bshell is still one process for the OS

fabiog
5th February 2003, 20:06
Hi.
On windows nt system, you mast use only seq.lock command. On Unix you must activete file lock on filesystem before you lock it by baan:

change mode of file right:

shell("chmod g+l " & file.tmp.name, SHELL_NO_OUTPUT)

next you can lock file with:

lock.file.id = 0
lock.file.id = seq.open(file.tmp.name, "w")

if lock.file.id > 0 then
if seq.lock(SEQ_F_W_LCK, 0, 0, lock.file.id) >= 0 then
|# File is locked
else
|# File not locked
seq.close(lock.file.id)
endif
endif

We have used this solution for our application.

Bye.

Renegade
20th February 2003, 20:13
The way I handled is like this. I did not use a seq.lock

REPEAT
f = seq.open("${BSE}/_test.txt", "r+")
in_date_ret = seq.read(o.dat, siz,f )
seq.close(f)
UNTIL f = 1

In this case, if another script has opened the file _text.txt, first time f gets value 2. And till the other script releases the file, REPEAT..UNTIL loop continues with incremental value of f. f gets value 1, once the other script releases the file, and then the loop breaks.

I donno if this way of doin has any possibility of jeopardy. I am using this in my current project

Any suggestions welcome..

Dikkie Dik
20th February 2003, 23:27
Renegade,

Probably our source code is right but if you get a lock your bshell will spin (and thus consume a whole CPU). A suspend (100) or so can help a lot

Kind regards,
Dick

fabiog
21st February 2003, 11:27
Your solution:

REPEAT
f = seq.open("${BSE}/_test.txt", "r+")
in_date_ret = seq.read(o.dat, siz,f )
seq.close(f)
UNTIL f = 1

Don't works.
Suppose to have 2 file you must open at the same time, the file pointer seq.open return are two sequenze number (i.e.
f1 = seq.open("file1.txt", "r+")
f2 = seq.open("file2.txt" , "r+")

the result is f1 = 1, f2 = 2)

Furthermore, if you open same file in different application or same application in different client you may have the same file pointer
i.e.

session 1:
f1 = seq.open("file1.txt", "r+")

session 2
f = seq.open("file1.txt", "r+")

if there aren't any other file opened in the sessions then f1 = 1 and f = 1 and you don't implement lock on file.

Bye.

NPRao
22nd February 2003, 01:56
Points to be aware of these limits before you get into issues -


104 ETOOMANY - Too many files open
--------------------------------------------------------------------------------
Description:
This error indicates too many tables are open.
Solution:
If you use the BAAN Base database increase the MAXOPENF parameter.

24 EMFILE - Too many open files
--------------------------------------------------------------------------------
Description:
This error indicates that too many file descriptors are open. No user is allowed to open any file.

Solution:
No process can have more than 20 file descriptors open at a time. Ask your system administrator to change the following parameters to increase the number of open files that is allowed:
The NOFILES parameter, which defines the maximum number of open files per process and must have minimum value of 256. Preferably more.
The NFILE parameter, which defines the number of open files in Baan and must have minimum value of NOFILES * BAAN User License * 3 + 100. Preferably more

Renegade
22nd February 2003, 14:05
hi fabiog

It works for me.

I tell u the background. This particular file i mentioned - _test.txt contains the last time the netchange is run, based on audit on a particular baan table. The lines of code are present in a BOI DLL. It is possible that different business process may invoke the same BOI, sometikes giving room to both BOIs executing at same time and both contends for the same ascii file.

So, when one BOI has opened the file for a moment, the other BOI will get value 2 in 'f' and it keeps on increasing till the other BOI release the file. When it releases, f gets value 1.

And I open only this file. So no two files. So, it works fine. Though as suggested, it may involve high CPU consumption, but by using suspend() as suggested by Dikkie Dik, it works fine.