Hi all

We are having a problem on one arev 3.14(?) site where we can log into the app but when we go into a specific data update window, we get an error

"unable to open DICT_CL_CUSTOM_OUTCOME"

This occured after an error in a different table which has since gone away.

LINK LIST IN THE TALBE "!CL_LOCATION*APP*TIMEDATE" is brok

transactions cannot be properly flushed

to correct this problem please rebuild all the indexes in the CL_LOCATION*app table.

- but this error has stopped and I can list the CL_LOCATION table without any problems.

So I've tried all sorts of variations on trying to delete and recreate the CL_CUSTOM_OUTCOME table.

when I try to copy our history version of the table

COPYTABLE CL_CUSTOM_OUTCOME_H TO:(drive:\path CL_CUSTOM_OUTCOME

I get error

"unable to move CL_CUSTOM_OUTCOME_H TO DRIVE:\PATH"

when I try make table I get error - table already exists

when I try to delete table I get error table not available.

the one that is causeing the error message doesn't show up when I list systables.

I can't restore it by copying the dos files for the data and dictionary portions from elsewhere - I still get all the same errors about it already existing but being unavailable.

Something is corrupt and I can't seem to fix it.

We're using XP workstations, and Novel something with the IPX.

I've asked for a restore of the entire data folder instead of just the broken bits but then I'm not sure which bits are broken.

Any ideas appreciated. Thanks.

Sometimes if there is a problem in a !file it prevents the dict or data portion of the associated file from attaching (usually the dict). SYSFILES/TABLES is a virtual file in memory that is updated with attach/detach so that's why the tables aren't listed there.

Backup the problem directory/volume and make sure no one is in ARev during the following steps:

Do a LISTMEDIA path/volume and get the DOS REVxxxxx names to do the copy in DOS (or restore from tape).

Copy over the dos files, renaming as appropriate

Then in ARev do a:

SETALIAS volume/path SYSPROG,password REVMEDIA REVMEDIA

(note the two spaces between setalias and volume)

Then:

EDIT REVMEDIA filename*appname

Clear out SI.MFS on line 2, save and attach the file. Do a LISTFILES or list the SYSTABLES file to see the dict and dictionary are now listed.

Okay, now provided you have documentation on the indexing settings for the file I would do a CLEAR-FILE !filename, do the SETALIAS again, edit the REVMEDIA record and add SI.MFS, reattach, delete all indexing on the file, then add the indexes back on.

Since there appears to be two files involved, it is possible that there are related indexes. If this is the case, I would CLEAR-FILE !secondfile and the remove and add the indexes. If this file was attaching properly there should be no need to mess around with the REVMEDIA entry for this file.

Clearing the !file is a brute force method to clear out any problems in the !file, logical or otherwise (GFE). Sometimes the pointers in the btree nodes get out of sync and then you can neither rebuild nor remove the index(es). Sometimes you can manually delete the offending node but in a very large !file it usually isn't worth the time and effort since you should rebuild all the indexes anyway.

Remember to back up all the files prior to doing any of this.

If the system is not using the NLM I would recommend that it be purchased and installed.

Hi all

Turns out they had been backing stuff up while people were using the system, so the backups were corrupt.

The tables corruption was hard to figure out since the error messages and tables kept changing. As best I could tell there weren't any indexes in the tables that were reported in the error messages, but that doesn't mean some other table didn't have an index pointing at them. It was really difficult to diagnose without any working copy of the system and "run time arev" that wouldn't let me into the dictionaries, or edit the tables I needed to.

Hopefully, now they will believe us when we say people have to be off the system when it gets backed up. Including their batch processor.

The one that had to rekey the missing data will make them believe it.

It never ceases to amaze me how *users* will let their backups go or not listen about rotation of tapes, compares etc. Sometimes it even takes 2 or 3 big problems to get it sunk in. I know one who still doesn't get it

Oh well about time for their yearly call

My method for this was to run on a multiuser host, which rebooted single-user at 2:30 am, performed a backup, and then rebooted to multiuser. I trained site supervisors to do daily restores to separate workstations, which of course they THOUGHT were backups.

This worked very well until a backup error message appeared on the host at one site, at which point the user performed the restore operation by hand – on the host. NO IDEA IS PERFECT.

And don't forget about retention. I worked on a site that had a backup schedule that was pretty typical.

* Daily incrementals, and weekly full backups.

* Weekly backups were maintained until monthly backups were accumulated.

* Monthly backups were retained until quarterly backups were accumulated.

At one point I needed a restore from a tape where the only backup was on a quarterly tape. Unfortunately, the quarterly backup was not good. Most likely, one of the interim backups was good, but the one that got retained was a bad one.

So there was effectively no backup.

View this thread on the forum...