Hi. We have just verified something that I first discovered years ago but had forgotten. On all versions of Novell (3,4,5), all versions of AREV (up to 2.12), all versions of Network Driver (Advanced 2.0, All Networks Driver 1.5.0.0 etc) File Locking doesn't work properly (at least not the way we are using it !!!!)

If you lock a FILE with AREV (using a key of Null), then any further attempted record locks will fail as they should. HOWEVER, if you lock a record first, then attempt the file lock, it will return a "success"

result !!

Is there any KNOWN fix to this problem ? I will be happy to install the NLM tomorrow if it GUARANTEES to fix the problem. Could I please

ask that before you write back to me, you run the following little piece of code as a test to verify that it works on your system ?

OPEN 'LISTS' TO LISTS THEN

  RESP=R'

  LOOP

      CALL MSG('(R)ecord or (F)ile Lock','RC',RESP,'')

  UNTIL RESP='

      IF RESP=R' THEN

          LOCK LISTS,'A' THEN

              PRINT "Record Lock Worked"

          END ELSE

              PRINT "Record Lock Failed"

          END

      END

      IF RESP=F' THEN

          LOCK LISTS,'' THEN

             PRINT "File Lock Worked"

          END ELSE

             PRINT "File Lock Failed"

          END

      END

  REPEAT

  UNLOCK ALL

END

Try it with first selecting a record lock, then a file lock, and please let me know the result (either way it would be interesting to know - am I the only bunny out here with this problem cos I have missed something basic on Network setup (after 10 yrs experience ?)

Thanks.

Warren,

I believe this is a misunderstanding on how locking works in AREV.

First of all, I tried your code in AREV 3.12 and OpenInsight 7.2 (just for the heck of it). We are on NT Server so I was using the All Networks 1.5/NT Service 1.5 driver. My results in both environments were what I expected them to be: I am able to lock the Record once and I am able to lock the File once then all subsequent locks fail. It doesn't matter which type of lock I do first, I am still always able to set the other type of lock in the same session.

Your post suggested that you expected to do a File lock first but then fail in a subsequent Record lock. But that is not how locking works. File locks and Record locks are ignorant of each other. In other words, a successful File lock only prevents other File locks and a successful Record lock only prevents other Record locks against the same key.

I am guessing you are trying to perform a universal lock on a File so all attempted Record locks will fail (including a window presumably.) If this is a requirement then you will need to always put File locks in your code first. An alternative to File locks would be to do a Record lock on an arbitrary key (it doesn't have to exist).

Hope this helps,

dbakke@srpcs.com

SRP Computer Solutions

Hi Don,

Thanks for the input. However this confirms exactly what I suspected, and Yes, thanks I have already set up a convention of locking an arbitrary key before locking each record by means of an MFS to effectively create a "logical" file lock.

HOWEVER, what concerns me is that you suggest that the locking results you achieved are correct functionality. If I have understood your results correctly, you achieved the same as me, that is, that once a FILE lock is successfully in place, subsequent RECORD locks fail, but the FILE Lock is intiially granted, independently of any record locks in place.

So the difficulty I have is this. If the FILE and RECORD locks are "ignorant" of each other, then ecord locks subsequent to File Locks should also succeed. What I suspect here is that the while NOVELL will grant the FILE lock independent of the RECORD lock, when the subsequent call for a record lock is made by RBASIC, AREV by convention checks the locking table and returns the failure because the File is "locked".

Do you see what I am driving at ?

If the following is a lock failure :

1) FILE 2) RECORD

then the sequence

1) RECORD 2) FILE

should also be a failure i would have thought.

(Obviously we both know that 1) record 2) record

                        OR 1) File   2) File

will both be failures)

Glad to hear back from you on this.

Warren Kinny.

Warren,

I don't think you understood my results. I'll try to explain again.

Attempt #1 - FILE lock is successful, RECORD lock is successful

Attempt #2 - RECORD lock is successful, FILE lock is successful

You said that for you, however, this is what happens:

Attempt #1 - FILE lock is successful, RECORD lock is fails

Attempt #2 - RECORD lock is successful, FILE lock is successful

We don't get the same results with Attempt #1. However, your original post suggested that you believe your results for Attempt #1 is what's expected but Attempt #2 is not what you expected. I explained that your expectations are incorrect.

A successful FILE lock should not affect subsequent RECORD locks at all, they should always both be successful because they are different types of locks. A successful RECORD lock should not affect subsequent FILE locks at all either for the same reason (unless I am completely off base on this, but I believe I've gone down this same path many years ago.)

Therefore, my results are what I would have expected. Your results are odd but for reasons different from what you are expecting. It could be a Novell thing, but I doubt it if you are using the All Networks Driver since it won't use Novell specific functions to create the lock.

dbakke@srpcs.com

SRP Computer Solutions

Oooh you forger!

Sprezz

World Leaders in all things RevSoft

Whoops!

dbakke@srpcs.com

SRP Computer Solutions

Sprezz

World Leaders in all things RevSoft

Don/Warren, lol

SPREZZ nice to have you in on this one….but how 'bout one of your famed technically brilliant contributions ? *S*… don't just bust Bakke…tell me if you think he's right !

Don, thanks for the clarification of your results. Yes what you havee is NOT what I understood you to be saying…and YEs, you understood the results I got exactly.

What I am saying is 1) Locking the WHOLE File logically to me makes sense that that you shouldn't be able to make record locks simultaneously with a File lock, and

2) AREV itself checks its internal Lock table and fails you on the record lock if you have a FIle lock - because if you are using a non-bumped version of AREV 1 or 2 (you may rememebr that you had to bump those versions to even get it to look at the Network driver at all)…the lock will fail…and its not even communicating with the server AT ALL in that situation.

So can you see now why I think the results are inconsistent ? And Sprezz i'd value your input on this one mate….

Thanks.

Warren Kinny

Exodus Systems Australia

wjkinny@resmaster.com

Warren,

Well I suppose we'll have to see if Sprezz concurs with either one of us. However, when I had this issue come up before I believe it was Sprezz that set me straight. I will be extremely interested to see if File locks ought to prevent subsequent Record locks as this would have simplified much of the code we've written over the years.

dbakke@srpcs.com

SRP Computer Solutions

Warren,

I hear what you're saying, and it is a sensible expectation, but

it would be a performance nightmare to reconcile record locks

against file locks.

Look at it in terms of non-Revelation locking behaviour:-

the DOS API for locking accepts a request that says

"lock this DOS file handle from this offset for this distance (in bytes)".

We have experienced this via its implementation in the generic

DOS 3.1 AREV byte range network driver.

So say an AREV *.lk file is 2048 bytes long - you lock a record in the middle of the file from offset 246 for a length of 120 and then lock the file from byte 0 for length 2048. Think about a server or even a file with 400 concurrent locks on it. Do you compare every lock against every other lock to spot any intersection of a pair of lock ranges? That's 160,000 comparisons. The OS doesn't have time to do this. Nor does the network driver. So the lock succeeds if the lock request isn't presently in place for *exactly* the byte range in question.

The Novell byte-range driver works similarly - the key and the file are hashed to form an 8 byte token. A record lock adds a token to the server's lock table. A second lock on the entire file produces a different 8-byte token - this doesn't exist already on the server so the file lock succeeds in spite of the record lock.

A totally separate and equally frustrating lock is when you lock your keys in the car. Last week it took me fifty minutes to break in and get my wife out.

Eric Emu

So .. married a blonde huh

DSig

Hi Eric,

Thanks for all of your contribution ! lol

What you are saying makes sense of course, and it's nice to hear someone verify how the locks themselves are implemented, and yes, when I go back and now digout TechBulletin #2, I notice that I have highlighted the section that tells me that file and record locks are independent. However, as I say, I guess my biggest problem is the fact that on all our systems the Record Lock AFTER the FILE lock fails - and if you read my previous mesages, I can almost guarantee that AREV returns the failure, without even asking the op system.

SO 2 points from here : 1) I have just now been able to confirm that this inconsistency is fixed in AREV V#3. IE I ran my same code and the record lock WORKED after the file lock was put in place. SO PLEASE NOTE GUYS< this is different than V#1 and 2.

and 2) I notice also in Tech Bulletin #2, it talks about using "Exclusive Coordinated Locks" as a solution to this record/File locking problem. With this option enabled, AREV will always ask for a shared File lock before placing the exclusive record lock, that way, if someone has an exclusive file lock in place, the exclusive record lock will effectively fail.

It mentions in that Tech Bulletin that this is only supported under Novell (obviously it cannot work under the byte range locking driver).

CAN ANYONE CONFIRM that 1) this still works with the Universal Network Driver ?

2) that it works using the NLM on Novell ?

3) That it works on NT servers ?

The reason I am pursuing this guys, is that while we could simply change the application so that it attempts a File lock before any record locks, this would prohibit two users from working on completely different records simply because we have one process that needs to lock the entire file, and for the sake of correct integrity there we would be creating an unecessary bottleneck for everyone else.

Thanks for any feedback

Warren Kinny

Exodus Systems Australia

wjkinny@resmaster.com

View this thread on the forum...