Sorry, I am new in the discussion group.

I use AREV for 8 years. Now I had a problem.

I do "SELECT CLIENT" in the TCL level.

Following reads from the table causes collaps of the table

(LK file is reduced to one frame length and everything

goes to OV file, readnexting corrupts)

The table has 89439 records.

I have analyze the problem.

The problem is in changing ALPHA during the select.

(I uninstal the SI.MFS and install my own "ALPHAGUARD.MFS".

This informs me, that the ALPHA is changed wrongly by BFS(RTP57) clearselect. (From 16744648 to 287475) I cannot go deeper (As I don't have source codes of RTP57:) ))

Do you know about the problem?

Are there specific conditions in which it arises?

(Table was GFE free, without a MFS on it, in the single user environment.)

Checkout these two links which might be of use:-

http://www.revelation.com/8525652b0066bfaf/d739a1010f28f6798525656b00612ab1/2a1a068d4d16001285256683000b474c?OpenDocument

http://www.revelation.com/8525652b0066bfaf/d739a1010f28f6798525656b00612ab1/C3ECEB81A228F0608525647E00188244?OpenDocument

The Sprezzatura Group

World Leaders in all things RevSoft

I understand what hapens after the change of alpha (it is obvious).

I understand that there is a bug in SELECT, READNEXT, CLEARSELECT loop in RTP57.

(There may be corrupted pointer given to CLEARSELECT? And this is why

clearselect updates ALPHA to wrong value. Where is the computed ALPHA maintained? Is this internal variable of RTP57/some RBASIC public variable/partial information of Pointer used in "BFS protocol"?)

I have read the topic dealing with Alpha here.

It seems that more programmers are interested in it.

The Sizelock=1 is only a partial solution.

(My ALPHAGUARD.MFS is not suited for network environment and therefore isn't the solution, too).

Unfortunately VerifyLH does not check the ALPHA value.

FixLH fixes it well.

Another partial solution is probably to use

TCL "SELECT CLIENT BY something"

WHERE something is a BTREE indexed field.

This is slower (as it must read from both !CLIENT and CLIENT), but the SELECT READNEXT CLEARSELECT loop is performed by SI.MFS.

RTP57 isn't called at all for these 3 primitives. (It expects that there are not pending insert/delete index transactions/the programmer should know the difference.)

This is probably solution recomended to everyone who is avare of this bug until the bug will be corrected. Am I right?

This is probably not helpful .. just an observation. I note that your value of 16744648 is very close to hex FFFFFF or 16777215. I think the filing system is limited to FFFFFFFF (one additional byte of resolution), but perhaps there is a routine that is truncating to only three bytes. With the high byte stripped off, what you would end up with is a number close to zero.

This would require some experimenting to see if this is what is really going on, but it is possible that you could write an MFS to monitor this and if a result is returned close to zero, add 1000000 (hex) to it.

Well it is such a long standing bug that it may never be resolved BUT with Pat McNerthney hard at work on the newer versions of the filing systems there may yet be hope. If it is fixed it would more likely appear in a chargeable upgrade to a network driver or the NPP though this is just supposition on our part.

The Sprezzatura Group

World Leaders in all things RevSoft

No, I don't thing so. 16744648(FF80C8)-]287475(462F3)

I cannot see a similarity (of course last frame may be was striped, but the rounding errors should be in one frame range=1024(400))

Thank you for a comment

I guess the coffee hadn't kicked in yet. I saw the number and immediately thought of hex FFFFFF.

Rereading your message, it looks like you are able to reproduce this problem. Does it happen regularly? Does a select on the file not fix the problem?

Grr, I failed in sending the answer.

I hope I dont forgot anything now.

FF may be important. (Yes, I have a copy of LK,OV files before the alpha change.)

I've continued in the research (Source codes not needed).

I've analysed the huge MFS trace log file especialy concerning the FMC

Here is The FMC used in the READNEXT loop:

0 1 2 3

4 5 6 7

8 9

frame#

alpha

fl

Each time the readnext is called, it reads one frame and returns

keys in the RECORD (limited to 64K), it updates FMC accumulators and returns STATUS=1. If eof is encountered, FMC is changed just in the fl field and STATUS is changed to 0.

… last FMC was

36500000E181FF0004005F5D0100 (ASCII values)

… correct as MODULO=5036h ALPHA=FF81E1h and RECCNT=15D5Fh.

But the clearselect expects the same on input and was called with

            0004005F5D0100

(FF=@RM..?bug here?)

CLEARSELECT (RTP57) only updates ALPHA,RECCNT according to the computed values (I expect) but ALPHA was not presented. It was replaced at random!!!

Result: It is danger to have FF in the FRAME0 header (If my suspection is right.)

Solution: I cannot change AREV.EXE therefore I can only create

CLEARSELECTGUARD.MFS which will trap the CLEARSELECT call and if LEN(FMC)<14 it will not call the RTP57!!!. (Mount the MFS as the lowest layer not to trap SI.MFS clearselect!! See the MFS topic)

This I recomended to install on each file for everybody, since FF apears in Frame0 header "almost randomly".

Is this right?

See also both topics opened by me 12/20/2001.

I am a bit tired by a monologue kind of the discussion so

I am going to the off-line mode now.

I suppose, upgrading to Universal driver will solve the problem …

the FMC's logic seems to be dependent on the "network driver" … so this will be correct time for ALPHAGUARD.MFS removal:)

Can someone confirm this?

View this thread on the forum...