My first question is fairly basic. How do you enable byte range locking in Revelation G? And how is it implemented? I was told once that is was used when you didn't want to use (or couldn't use) Novell's semaphore locking scheme. Is that correct?

My second question is a little more "off the wall." I have read in the forum that RevG runs in Windows NT and 2000 as a client of a Novell server. Does anybody have any experience running _multiple_ copies_ of RevG on these machines? I'm thinking of course of a non-LAN approach to muliple users. Has anybody ever done this?

Thanks!

Alvaro Fernandez

Alvaro,

(1) REV SYSPROG

Then at TCL enter the command:

UPDATE.DRIVERS

Select "Generic DOS 3.1 Network"

(2) The CPU load of one REVG session is so high that further REVG sessions may be denied sufficient processing timeslice. If your processes require no keystrokes then you may be able to work in this way, but you will have to watch the CPU load of each session carefully, and set the Windows shortcut Idle Sensitivity setting to compensate and tune it. We wouldn't recommend running multiple sessions in this way. Multiple workstations with one session each is a better way to proceed.

The Sprezzatura Group

World Leaders in all things RevSoft

Thanks for the quick response…

More specific questions about byte range locking:

1. When would you use it? Just to get away from Novell? Put another way: when do people use it? We are interested in the possibility of getting away from Novell if we have to.

2. How is it implemented?

Alvaro

Byte Range locking is common on peer-to-peer and early Microsoft networks (think Lantastic, Lan Manager, Windows for Workgroups 3.11).

It works by locking a range of bytes inside a physical file.

So if your Revelation record stretches from offset 3045 for a length of 407 bytes, and the physical file handle is opened, then this information is passed during a BASIC LOCK statement the BFS (RTP52/59) to the operating system. An unlock does just the opposite -releases this on the server.

This technique fell out of favour because (a) it was based in DOS int 21h calls (b) Microsoft changed to other API-based techniques for Windows 16/32 bit filing systems - part of the obsoleting of DOS © the later Microsoft Windows systems cached file writes (which messed up the synchronization of locking and file/record re-organization).

It still works in many cases, but is subject to the above technical limitations.

The Sprezzatura Group

World Leaders in all things RevSoft

OK. If you don't mind bearing with me, I just need to ask a few more questions.

The reason for my question is this: we are always worried that our RevG apps will become "unrunnable" if Novell "goes belly up", as they say; or, that the next version of Novell may "break" the RevG locking mechanism. I thought that the byte range locking (BRL for short henceforth) mechanism might work more portably.

In fact, the FAQ on this site mention BRL whenever running RevG on NT or Unix (!) is mentioned. So then - do you mean to say that BRL is just not the preferred method, or is it just that as things currently stand, it can't be used anymore? If it can be used, will it work with a non-Novell server, i.e. NT?

Alvaro

The Byte Range Driver (BRL) will work with Rev G and many non-Novell networks. I've used it for years. The Novell Netware driver is more efficient and provides much better performance since the BRL driver forces all locks through a single subdirectory (where REV.EXE is located) and this frequently causes contention but if Novell were to go kaflooey or a new release doesn't support semaphore locking (which is very unlikely), then you can use the BRL driver.

HTH

Don Miller

C3 Inc.

Alvaro,

REVG locks on Novell are handled through Int 21h calls D0-D4h.

To watch the locks real-time, you can use this TSR utility to watch the REVG locks (simply load it in a batch file ahead of REVG) in real time. You'll see locks on the top line and unlocks on the second line of the screen at top right.

It is possible that if these locks were no longer supported under Netware clients (and knowing Microsoft and Novell anything is possible) that Sprezzatura could provide a TSR to convert the lock calls from Novell's into whatever the OS required. In this regard you are quite safe.

Byte range locking is less of a problem with REVG than with AREV because you have a single data file, and any write caching is less of a problem with a single file.

We can state that if you run byte-range locking on REVG that it does run dramatically slower than Novell's semaphore-based locking scheme on the same Netware server.

So - Novell obsolescence isn't really an issue for Revelation Software's database products, even if at some stage, it *was* to eventuate!

Byte range locking in REVG would be our choice on NT / Win2K and Microsoft networks generally.

Steve

The Sprezzatura Group

World Leaders in all things RevSoft

Thanks to all for your responses. I feel a lot more "safe" now than before.

Here is a more speculative idea I had. It was my own idea for locking, using RevG files only. I was curious whether it might be faster than BRL.

In short, the idea is to create "lock records" in a file and use their existence and/or a flag field value as a "semaphore". I thought of two approaches:

1. Create a file LOCKRECS. Each record has a two part key: file name and record id. The record constains a date stamp, a time stamp, and a flag field with 1 (lock on) and 0 (lock off). To lock, the record is created, if it does not exist, or the flag is set to 1 if the record already exists (due to a previous lock). To unlock, the flag value is set to 0.

2. The second approach is similar, but instead of one LOCKRECS file (contention), have a LOCKREC file for each RevG file. The record id is now only the key to the record to be locked. The rest is the same.

UNLOCK ALL would be handled easily: a COMMON block with a list of all the locks currently held by the station, updated by the lock statement.

I'm unsure about whether LOCK itself could be "overloaded" to handle the new code necessary, or if I would have to create a MyLock() function to do this.

Comments? Too much overhead?

NOTE: I'm new to the posting system on this forum, and I think I posted my last message in such a way that it doesn't show properly in the thread. I'm repeating it here:

*

Thanks to all for your responses. I feel a lot more "safe" now than before.

Here is a more speculative idea I had. It was my own idea for locking, using RevG files only. I was curious whether it might be faster than BRL.

In short, the idea is to create "lock records" in a file and use their existence and/or a flag field value as a "semaphore". I thought of two approaches:

1. Create a file LOCKRECS. Each record has a two part key: file name and record id. The record constains a date stamp, a time stamp, and a flag field with 1 (lock on) and 0 (lock off). To lock, the record is created, if it does not exist, or the flag is set to 1 if the record already exists (due to a previous lock). To unlock, the flag value is set to 0.

2. The second approach is similar, but instead of one LOCKRECS file (contention), have a LOCKREC file for each RevG file. The record id is now only the key to the record to be locked. The rest is the same.

UNLOCK ALL would be handled easily: a COMMON block with a list of all the locks currently held by the station, updated by the lock statement.

I'm unsure about whether LOCK itself could be "overloaded" to handle the new code necessary, or if I would have to create a MyLock() function to do this.

Comments? Too much overhead?

File I/O to disk for locking is slower than byte-range locking. Why re-invent the wheel?

The Sprezzatura Group

World Leaders in all things RevSoft

Well, I was being told that BRL was slower than the semaphore locking. Not knowing how Microsoft implemented BRL, I assumed it was also done through some kind of file with a list of byte ranges. I gather that's not how it's done?

So, the reason for reinventing the wheel was because I thought my wheel might roll as well, I guess. That is, I assumed BRL was file based, just like my idea, and I thought my file-based implementation was better. As for the Disk I/O issue - I expected (perhaps naively) that most server OS's would cache server disk I/O, so even reading "from disk" would often be from server memory anyway.

Sooooo….. how _does_ Microsoft implement BRL? If I could just understand this, I'd feel more comfortable using it. Do they keep a list in server memory somewhere? I'm sorry to keep insisting on this, but it's at the crux of what I want to understand. If they use a file, I don't see why it's any slower than what I propose.

Byte range locking calls:

As a Visual Basic call

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/office97/html/output/F1/D6/S5B263.asp

As a DOS call, use Int 21h function 5Ch in C or Assembler

See a 1991 DDJ article for a brief explanation of some locking issues

http://www.ercb.com/ddj/1991/ddj.9101.html

Or Ralf Brown's Interrupt list (the preferred source for all such

minutiae)

http://www.ctyme.com/rbrown.htm

and specifically (regarding locking)

http://www.ctyme.com/intr/rb-3016.htm

There aren't physical files involved. It is a call from the program via the network shell to the server, which registers the lock as a record in a lock "table" (actually a buffer) on the server. Can you get to this programatically from a client to find out which locks are registered? Yes in Novell you can - for interrogation purposes. Not so in Microsoft.

Your approach of creating a physical lock table is fine in theory - until you find there are locks in your lock table, for which you need a table of locks for monitoring the locks of locks, then the locks of locks of locks…

The Sprezzatura Group

World Leaders in all things RevSoft

OK, now I must admit my ignorance. Why would there be locks in my lock table, as you say, fow which I would need eventually a recursive infinity of lock tables? The only locks there would be the ones I would create, right? But you seem to imply that I would "find other locks there." Why would I find any others? Maybe I misunderstood… My scheme works asynchronously. The only possible contention is if two people try to lock the same record simultaneously. But that would happen in any scheme; somebody almost always gets there first. In a server based model, the server can assign an arbitrary priority to two competing requests for locks. In our case, we could lock the whole file _for just the instant_ that MyLock operates; other potential lockers would block until the "locker" finished executing MyLock(). In any case, I don't see any need for the infinite recursion of lock tables you describe, but I am quite willing to be corrected on that score.

I'm glad to know that BRL also uses server memory, though. In that case - how come it's slower than Novell?

I don't have an inmense investment in my idea, mind you; I'm just exploring our options. After all, my idea would require recoding, while BRL would only require setting some parameters differently in RevG.

Alvaro

The biggest problem would be coordinating the records you keep for locks and the locks REVG maintains by itself.

Say JOE crashes out of his session with an "out of memory" error. Your lock table would still have some records present for Joe.

Further, if REVG had placed any of its own locks on any physical records in your physical LOCKS table, you would never get to clear these, and the locks would persist until server reboot. Here the scheme potentially gets into trouble. Further, an UNLOCK ALL call from REVG behind the scenes for its byte range locking could not be readily trapped by your physical routine. How do you know when this occurs? You don't. Therefore you cannot always synchronize.

We were jokingly saying that "every redundant structure enforces the need for another redundant structure to monitor it". Redundant here is used in the sense of duplication.

We've seen physical locking schemes built into applications before today, and the results were overcomplicated for these reasons. You could go as far as a shared RAMDISK to hold locks. Even this is problematic, but we've seen it done.

Byte range locking is marginally slower than Netware logical locking because REVG builds an 8 byte Netware semaphore by hashing the file variable and the record ID. This is pretty fast.

Byte range locking handles more data (file name, byte offset, range to be locked) and is marginally more data to construct and then handle. Not much more, though. Netware doesn't handle byte rage locking as well as it handles logical locking. This is tied up with code within the Netware kernel.

The Sprezzatura Group

World Leaders in all things RevSoft

*The biggest problem would be coordinating the records you keep for *locks and the locks REVG maintains by itself.

Got it! I wasn't thinking of that. No matter what, RevG must keep its own locks, and if there's no Novell to be had, these will be BRL.

*Say JOE crashes out of his session with an "out of memory" error. *Your lock table would still have some records present for Joe.

I was keeping the date, time and user name in the record for that reason. Whenever a user would reenter the system, his locks would be cleared by our maintenance routine. There would also be a lock maintenance menu in the system. But your point is well taken.

*Further, if REVG had placed any of its own locks on any physical *records in your physical LOCKS table, you would never get to clear *these, and the locks would persist until server reboot. Here the *scheme potentially gets into trouble.

*Further, an UNLOCK ALL call from REVG behind the scenes for its byte *range locking could not be readily trapped by your physical routine. *How do you know when this occurs? You don't. Therefore you cannot *always synchronize.

I didn't realize RevG would issue UNLOCK ALLs all by itself… would that be as the result of R/LIST or somesuch?

*We were jokingly saying that "every redundant structure enforces the *need for another redundant structure to monitor it". Redundant here *is used in the sense of duplication.

True enough.

*We've seen physical locking schemes built into applications before *today, and the results were overcomplicated for these reasons. You *could go as far as a shared RAMDISK to hold locks. Even this is *problematic, but we've seen it done.

*Byte range locking is marginally slower than Netware logical locking *because REVG builds an 8 byte Netware semaphore by hashing the file *variable and the record ID. This is pretty fast.

Hashing the file+record id into 8 bytes? Does this mean there are 2^64 buckets? No… that can't be right, can it?

*Byte range locking handles more data (file name, byte offset, range *to be locked) and is marginally more data to construct and then *handle. Not much more, though. Netware doesn't handle byte rage *locking as well as it handles logical locking. This is tied up with *code within the Netware kernel.

I think you have convinced me at this point not to reinvent the wheel.

So BRL is marginally slower. Let's make it easy… what's the worse percent decrease I should expect if all things were kept equal, but I switched the server from latest Novell to say Windows NT or 2000?

View this thread on the forum...