third_party_content:community:commentary:forums_nonworks:959b6856c66b8deb85256ec500627a1e

Sign up on the Revelation Software website to have access to the most current content, and to be able to ask questions and get answers from the Revelation community

Fatal Error Readnexting (AREV Specific)

At 02 JUL 2004 01:55:37PM douglas e smith wrote:

AREV Specific

I am getting this error in an application that has run without trouble for several years (since we started using the lhipxtsr client/server stuff on our Netware 4.1 server). The user was updating indexes, which failed. Now we get a:

"Fatal Error Readnexting in file LOCTAPE.ALPHABETIC" with the GFE description - "Record length incorrect or frame linkage error."

whenever we try to run a report.

lh_verify loctape.alphbetic results in an error box:

"The "LH_GROUP_DATA" file has not been created or attached."

The guy who does the support for our app (the original author) is going to be unavailable for several days, so he suggested trying this forum.

This is running on AREV 2.12 on a Netware 4.1 server. The workstation uses Windows 2000.

I have some fairly recent backups. Note, I know little about AREV but am reasonably skilled at networking, admining Unix, Netware, Windows, etc. So you can tune the level of detail in any reply.

What other information can I collect that might be useful?

Thanks for any suggestions.

Doug Smith.

At 02 JUL 2004 05:52PM Steve Smith wrote:

Doug,

I'd be reaching for the last known full integrity backup.

It's a file corruption. Data files in AREV exist in pairs - same filename prefix, different suffic (OV or LK)

If there's been several days' data entry since your last backup, the GFE (Group format error) may be reparable by editing the linked list pointers in the file itself. These are situated between individual records to point to the next physical key/record pair throughout the file.

Until someone views the data in situ it would be difficult to tell the best recovery method.

The cause?

It could be a virus scanner has hit an OV file (these should be excluded from scan. It could be a flaky network card. It could be someone has copied a file from within Explorer to an AREV volume (verboten). It could be a dodgy disk sector. It could be a virus has attached to an OV file. Could be a brownout. Many possible scenarios could be to blame. If you don't usually get these errors, I favour the "human touch" - someone has tried to edit the data file in notepad, or deleted the OV portion (check the DELETED.SAV path for any REV*.OV files).

Steve

steve@state-of-the-art.com.au

At 05 JUL 2004 08:51PM Warren wrote:

LHVerify requires two files: LH_GROUP_DATA and LH_VERIFY_DATA

These should be global files in the REVBOOT directory. If they are not there, create them, but I think you need some symbolics in the dictionary for the reports to work properly.

Revelation should be able to send you the dictionaries if the files are nowhere to be found.

At 07 JUL 2004 05:17AM Hippo wrote:

Backup the "broken" table both .LK and .OV files.

(LISTVOLUMES, LISTVOLUME volume will help you to find the REVuvwxy.LK REVuvwxy.OV names).

This may be either problem of index or of a datatable.

Try "LO tablename" from a TCL. … It does not use indexes (as I hope).

If OK, reindexing will probably cure the problem.

(Problem may be with RIGHTDEX … "indexes" replace them with BTREE ones)

If LO fails, the problem is much serious.

Data portion may contain all data, but they are inaccessible as long as total key length of one group is greater then 64KKB.

Look at the file sizes (LK size is very small compared to OV size).

… Problem with wrongly computed ALPHA in very special case of table fill:( … Backup solves problem only partially, as the table tends to resize into this bad shape.

In this case standard AREV loop through the table fails, and one is forced to access the records on low level.

I hope this is not the case so I stop for now:)

But there are solutions … even for this case.

Of course the table may be corrupted even in other ways (by foreign soft) in that cases nothing except backup will help you.

At 07 JUL 2004 01:07PM douglas e smith wrote:

Thanks everyone for the assistance.

Warren, we makefile'd the LH_ files that you mentioned. When I run

LH_VERIFY filename now it runs for a while and fails with:

"GROUP is an unrecognised word."

Suggestions?

Thanks very much,

Doug

At 07 JUL 2004 01:39PM dsig@sigafoos.org wrote:

It sounds like it is trying to reference a dictionary item. Just creating the files will let the routine process but then the final listing requires the dictionary itmes.

Here is a dict listing of syslhverify .. hope this works

FULL_TABLE_NAME F 0

DATE F 1

GROUP F 2

FRAMESIZE F 3

LK_SIZE F 4

OV_SIZE F 5

MODULO F 6

SIZELOCK F 7

FRAME_FOR_FREE F 8

UNUSED_FREES F 9

ROWS F 10

ROWCNT F 11

ROWS_PER_GROUP F 12

ROW_LENGTH F 13

LOAD_PRIMARY F 14

LOAD_ALL F 15

AVE_DISK_IO F 16

STD_DISK F 17

AVE_OV_GROUP F 18

STD_OV_GROUP F 19

LOAD_FACTOR F 21

VERBOSE S

  DD=XLATE('SYSTEXT', 'DICT.SYSLHVERIFY*PARMS*2', 1, 'X')

  @ANS='

  TP='

  KK={GROUP}

  EE={CODEL}

  IF EE NE '' THEN

  FOR I=1 TO COUNT(EE, @VM) + 1

  DAT=KK

':DAT

  REC=XLATE('SYSLHGROUP', NAME, '', 'X')

  COD=EE

  SCPT=DD

  GOSUB STUFFING

  TP := @VM:SCPT

  NEXT I

  IF KK1,1 EQ 0 THEN

  TMP=TP

  TMP=Initial setup failed!!  ':TMP

  TP=TMP

END

  @ANS=TP2,9999

END

  GOTO BOTTOM

  STUFFING:

  SWAP '%1%' WITH REC IN SCPT

  SWAP '%2%' WITH REC IN SCPT

  SWAP '%3%' WITH REC IN SCPT

  SWAP '%4%' WITH REC IN SCPT

  RETURN

  BOTTOM:

TESTING_STATUS S

  DD=XLATE('SYSTEXT', 'DICT.SYSLHVERIFY*PARMS*4', 1, 'X')

  IF {GROUP} EQ '' THEN

  @ANS=DD

  END ELSE @ANS=DD

CODE

 DD={GROUP}

 @ANS='

 IF DD NE '' THEN

 FOR I=1 TO COUNT(DD, @VM)+1

':DD

 VAL=XLATE('SYSLHGROUP', NAME, '','X')

 @ANS := @VM:VAL

 NEXT I

 @ANS1,1='

END

CODEL S

 DD={GROUP}

 @ANS='

 TMP='

 IF DD NE '' THEN

 FOR I=1 TO COUNT(DD, @VM)+1

':DD

 VAL=XLATE('SYSLHGROUP', NAME, 2, 'X')

 TMP := @VM:VAL

 NEXT I

 @ANS=TMP2,9999

END

TABLENAME S

 DD={FULL_TABLE_NAME}

 E=INDEX(DD, '*', 1)

 @ANS=DDE+1, 999    /* DONT PRINT VOLUME NAME */

TERSE S

 DD=XLATE('SYSTEXT', 'DICT.SYSLHVERIFY*PARMS*1', 1, 'X')

 FF=XLATE('SYSTEXT', 'DICT.SYSLHVERIFY*PARMS*5', 1, 'X')

 @ANS='

 KK={GROUP}

 GG={CODE}

 IF KK NE '' THEN

 FOR I=1 TO COUNT(KK, @VM) + 1

 @ANS=DD]

 NEXT I

 IF KK EQ 0 THEN

 EE=@ANS

 EE=Initial setup failed!! ':EE

 @ANS=EE

END

 END ELSE

 FOR I=1 TO 14

 IF I EQ 2 THEN

 @ANS= ---- ':FF:' ---- '

 END ELSE @ANS='

 NEXT I

END

RECMD S

 EQU DISK.IO.BOUND$    TO 2.5

 EQU FREE.FRAME.BOUND$ TO 1

 EQU SIZE.LOCK$        TO 1

 EQU REC.DIFF$         TO 20

 EQU TRUE$             TO 1

 EQU FALSE$            TO 0

 SCRIPT=XLATE('SYSTEXT', 'DICT.SYSLHVERIFY*PARMS*3', 1, 'X')

 TMP='

 @ANS='

 GFE=FALSE$

 IF {GROUP} NE '' THEN

 GFE=TRUE$

 TMP := @TM:SCRIPT

END

 IF {SIZELOCK} ] SIZE.LOCK$ THEN TMP := @TM:SCRIPT

 IF GFE AND {ROWCNT} AND ABS({ROWS}-{ROWCNT}) ] REC.DIFF$ THEN

 TMP := @TM:SCRIPT

END

 IF {UNUSED_FREES} ] FREE.FRAME.BOUND$ THEN TMP := @TM:SCRIPT

 IF {AVE_DISK_IO} ] DISK.IO.BOUND$ THEN

 BEGIN CASE

 CASE {ROW_LENGTH} ] 3072; VAL=4096

 CASE {ROW_LENGTH} ] 2048; VAL=3072

 CASE {ROW_LENGTH} ] 1024; VAL=2048

 CASE 1;                   VAL=1024

 END CASE

 IF {FRAMESIZE} EQ 4096 ELSE    ;* we discourage user to have over

 4K size

 BUF=SCRIPT

 SWAP '%1%' WITH VAL IN BUF

 TMP := @TM:BUF

END

END

 TMP1,1='

 IF TMP THEN

 NM=COUNT( TMP, @TM) + 1

 FOR I=NM+1 TO 5

 TMP[i]='

 NEXT I

END

 @ANS=TMP

dsig@sigafoos.org.com onmouseover=window.status=the new revelation technology .. a refreshing change;return(true)"

DSig's Radio Free Oregon

David Tod Sigafoos ~ SigSolutions

At 08 JUL 2004 08:32AM douglas e smith wrote:

Thanks for your response and the dict information.

However, we are using AREV 2.11 runtime and that the file syslhverify doesn't exist. How can we apply this information.

Thanks to all who have responded.

Doug Smith

At 08 JUL 2004 12:08PM dsig@sigafoos.org wrote:

Run the process again. Then when you get the error look at the tcl stack and see if there is a 'list' statement there. look at the name of the file that it is using and put the dicts in there.

dsig@sigafoos.org.com onmouseover=window.status=the new revelation technology .. a refreshing change;return(true)"

DSig's Radio Free Oregon

David Tod Sigafoos ~ SigSolutions

At 09 JUL 2004 11:30AM douglas e smith wrote:

Thanks, everyone for the assitance. We finally had to restore a backup.

Thanks!

Doug Smith

At 10 JUL 2004 01:48PM Warren wrote:

If it's a run-time the dictionaries can't be edited because there is no compiler.

View this thread on the forum...