I had problems with the error message

'RTP36' Line 1. B703 Variable exceeds maximum length.

May the error be caused by locking?

RTP36 is the lock processor. See:-

http://www.sprezzatura.com/revmedia/v1i4a12.htm

The Sprezzatura Group

World Leaders in all things RevSoft

Thanks for answer,

my suspections were correct.

I must run the program in a single mode batch closing.

Thanks once again.

Perhaps your program in not UNLOCK ing rows.

If there was no typo:), I was unlocking everything I locked.

But the number of locks and unlocks performed during the run was probably more than 64K.

I usually write daily batch programs, therefore I have no much experiences with locking.:(

Arev/OI can return a lock failure flag via STATUS() that says your workstation has the lock or that some other workstation has placed the lock. It does this by keeping a list of lock tokens (identifiers) in a variable at your instance of Arev/OI. So, this variable cannot exceed 64k in Arev/OI16.

So, if your batch process now has too many rows locked at one time perhaps you need to redesign. You may need to keep everyone off the system or off these particular tables until the batch procedure has finished. Just use a lock on a row that every process checks.

A lock is just a token. It doesn't even have to refer to a rows that actually exists or will ever exist.

Dave

Dave .. excellent point. This is how I'm able to implement a generalized file lock when the number of locks or the length of the lock table is likely to exceed 64K. Any process that needs to use a table has to check a record in the table GLOBAL_FILE_LOCKS. The structure of the data element is:

NAME OF TABLE (KEY)

TYPE OF LOCK Table Lock or Key Lock (Record Lock) coded as 1 or 2

HOLDER OF LOCK .. The @STATION value

DATE_TIME of lock.

Part of the login procedure for a workstation is to examine this table and to clear it's own locks. There's also an administrator routine to reset the GLOBAL_FILE_LOCKS to empty in case of a real mess.

I've exceeded the number of allowable locks in some environments (particularly Banyan Vines) or the length of the Lock Token Table when a customer uses extremely long keys.

Anyway .. glad you posted

Don M.

Thank you both Dave and Don,

I am always happy to learn something from those who know….

In may case (insurance company), the process should do small update in the most used table (policy) in the environment. The records in the table are locked by standard windows allowing editting for the users.

In the RBasic program I have loop through the client table, locked all policies of a client, and if succesful, I updated and unlock them all. The number of policies of a client is rather small, and the problem was not caused by a particular client. (I have checked, that when I call the process just for the client for which the overflow occurs during loop, there is no problem.)

The solution to move the program to batch process solves the problem.

My question is to Dave: how can I access the "token list" variable.

Is it possible that unlocking does not free the space?

(I didn't test the status after UNLOCK, may the UNLOCK be unsuccessful? When?)

I don't think you can directly access the lock token table, although Sprezz may have found a way to do it. I'm sure there's a memory variable that's being used to hold it. The real key is to make sure that you do an unlock of every key locked in a batch process. Sometimes, to be sure, I do an UNLOCK ALL just before the return or stop statement. This guarantees that no trash is hanging around.

Don M.

well….

Hippo - are you running on Novell or NT? You may be able to use coordinated locking to reduce the amount of locks needed if you're on Novell.

The Sprezzatura Group

World Leaders in all things RevSoft

I hesitate to say this, but with the right driver, it works. It's sort of like implementing coordinated locking without having to implement coordinated locking. All you do is lock the null key on the relevant file to prevent any other locks to be set on that file. If this works on your setup, then the following code should display the message:

LOCK HANDLE, "" THEN

LOCK HANDLE, "ANYTHINGELSE" ELSE

CALL MSG('RECORD LOCKED')

END

END

I am on Novell (with NLM), but don't ask me the version numbers.

If I understand it well, I can lock the whole table (POLICY).

That means nobody can edit records in the table during the process.

But as this is the most needed table in the system, this is almost the same solution as to lock the whole system and run it in the single user mode without other locking (as I did).

I repeat the question: Is it possible, that unlocking does not free the space allocated by locking … causing variabe overflow?

View this thread on the forum...