As some of you probably know, AREV has a little quirk that occurs when you create two copies of an application (ie: production and development) and try to run them on the same Novell server. Two records of the same name in two files of the same name seem to generate the same lock table entry, regardless of the full path where the file resides. This only seems to happen when the DOS filename (REVxxxxx) is also the same.

Example: You have file BP and record PROGRAM1, living in volume J:\PATH\PROD\, and BP is REV20001. You also have a file BP and a record PROGRAM1 living in volume J:\PATH\TEST\, and the BP file is also REV20001. Even though these are two different records, and READ and WRITE would never confuse them, the LOCK function sees them as the same record!

Though I had never tried it, I always assumed that the only way to get around this bug would be to move one of the volumes to a different physical Novell server. Well, we had to do this for a client recently, and the test file I created on the other server did behave as I wanted (ie: the locks no longer conflicted). However, when we moved the rest of the data over, we were still getting unwanted lock conflicts. The AREV.EXE is different for the two copies of the application, but both .EXEs are on the same server (only the data was moved to the other server).

So, my question is: where and how exactly does AREV on Novell store these locks, and how can we get around unwanted lock conflicts; while still having users that can access both copies of the application, preferably simultaneously using separate windows in Win95 ???

I've forgotten how the locking key was generated, something about a 16 byte (bit?) lock id based on several parameters including the REVxxxxx number. One solution is to RECREATEFILE/REMAKETABLE on the conflicting tables. Indexing could be a PITA.

Not recommended but do-able (backup first):

If you want to live very dangerously you could write a program that reads the REVMEDIA file that renumbers the REVxxxxx in each file entry and then does a pcperform rename of the .lk and .ov files. Indexing again will be a pain.

Or at DOS you could do rename REV20*.* REV42*.* then use a batch file or disk editor to change all occurances of REV20 to REV42 in the REVMEDIA.* files, but again indexing would be a problem because REVxxxx information is sometimes stored in some of the indexing control records.

Novell logical locks (from the Advanced Netware Network driver) are stored as 8-byte tokens on the file server in a lock table pool. They are composed from the DOS file prefix of the *.LK file as well as key information. There is a utility on my website to display locks real-time, and others which while not operable under Win 95, carry source code examples to display the lock generation and testing at work.

The only way around your problem is to generate the second copy of your application files from within the first copy, and copy across the records.

Another trick might be to run the Generic DOS 3.1 Network driver on one copy of the application, thereby employing two discrete locking techniques. You might also be able to copy your test files to a local drive and run the no-network driver, with no locking present on one copy.

Back up your exising copies of the application first before trying these methods.

Hope this helps,

Steve Smith

stsm@ozemail.com.au

http://www.ozemail.com.au/~stsm/

I seem to recall that part of the locking semaphore value was based on the serial number.

Be that as it may, a simple change of rev numbers would eliminate the problem.

I whipped one up a while ago, OK, years ago, so it's long since lost. It's not that hard.

apk@sprezzatura.com

Sprezzatura, Inc.

SERIAL() only affects locks once per session, as I understand it.

Also, consider that spurious lock conflicts may still arise if both systems use logical locking.

Steve

Yeah, not too difficult at all. Peter, refer to the earliar threads entitled 'Prefix Number for New Revmedia (8/3/98)' and 'DOS FILENAME REVMEDIA NUMBERS (8/3/98)' for more information on this topic.

Great, thanks for all your responses. It was very reassuring that you were all saying essentially the same thing! The easiest way to fix this problem is to go into a volume that has lock conflicts with another volume that it was copied from, and change all the REVxxxxx numbers (the DOS filenames) to start with a different two digits. This change must happen both in the media map and also the actual renaming of the DOS files. If anyone needs it, I wrote a fairly slick program to automate the whole procedure. E-mail me at pfisera@synergycc.com and I will send it to you for free.

View this thread on the forum...