00483: Notes on using the _FIX utility

Title:

Notes on using the _FIX utility

Description:

Please Note: Restoring from a backup is always the best solution to maintain integrity of your entire database. 

Documentation: 

The only documentation available, other than this document, is the “_fixmkey” BBx program itself (for MKEYED files); and the “_fixkey” BBx program (for DIRECT files). “_fix” simply RUNs either of the above routines, after determining from the file FID format whether it is MKEYED or DIRECT. General information regarding file structure can be referenced from the FID and FIN information in the BBx Users Reference Manual, as well as from the MKEYED and DIRECT file definitions. 

Running The Fix Utility 

When RUNning “_fix”, the following warning message will be displayed: 

Use this utility at your own risk. It is intended for use by those people with intimate knowledge of both keyed files and how this program works. This program may be unable to repair your keyed files. 

Hit <RETURN> to continue or <ESC> to exit. 

After pressing <RETURN> to continue, then the standard file selection utility screen will appear. The programmer should press Option “A” to add the name of a damaged file. The cursor moves to the top of the screen where a blank line is displayed. Type the path and name of the damaged file here. Then press Option “X” for execute. 

Scan only for flagged files? (Y/N) 

In multi-user environments, BBx maintains a user count in files. When a user opens a file and makes a significant modification to a file (such as adding, modifying or removing a key), the user count in the file is incremented. When the file is closed, this user count is decremented accordingly. So, under normal conditions the count should be zero if no-one has the file open. However, if a user turns off the machine (or any other action that would cause BBx to be terminated abnormally) without closing the file, the user count is not decremented and the file is at risk of being corrupted. In this case, the user count will be non-zero even if no-one has the file open. When _FIX asks the question about flagged files, it is asking if you want to scan only the files that have a non-zero user count. 

Now the utility will scan the file and its key chains. The utility may decide that “all keys were found in all chains”, or something else to the effect that they were not. At any rate, it will ask:

Proceed with reconstruct anyway? (Y/N) 

If you respond with “Y”, then it will display: 

scanning file: filename 
R Recover data into keyed file 
S Save data into file 
E Examine available disk on system 

Enter option (R/S/E) 

Generally, you would want to select “R”, to recover the data to a new keyed file. At this point, a temporary file is created, and the records are copied to it. 

The next option, after “all records are moved”, is: 

Save the recovered data? (Y/N) 

Select “Y”, and the temporary file will be renamed as the old file, with the old damaged file erased. 

Some Possible Caveats: 

The success of “_fix” will depend upon the extent of the file’s damage. Broken key pointers are more easily fixed with “_fix” than broken records, which may require programmer intervention. 

Occasionally, an ERROR=46 will be encountered during the process of moving records to the new temporary file. The program will ESCAPE, and a simple list of the program lines in the general vicinity of the error will probably show that the error occurred during a WRITERECORD of “REC$”. This indicates that the record has control characters in it, or is just basically mangled, sometimes beyond recognition or expected length. The programmer may want to >PRINT REC$ to determine data ‘fixability’, and whether or not to attempt to GOTO the WRITERECORD statement to try to re-write it to the new temporary file again, or simply make a note of the lost record (if possible) for manual entry later. If the record is irretrievable, then the programmer should GOTO the WRITE_RETURN routine and RUN in order to continue retrieval of records from the old damaged file to WRITERECORD to the new temporary file, thereby skipping the bad record(s). 

Core dumps halfway or so through the file will force the programmer to write their own routine to READRECORD/WRITERECORD sequentially from the first logical record (KEYF()) (or index 0 (IND=) for DIRECT files) until the core dump occurs, then enter BBx again and start from the last logical record (KEYL()) and work backwards through the file using the DIR=-1 option until the bad spot is hit again. It may be wise to check the disk for bad spots at this point, and even the possibility of bad memory, in addition to verifying database integrity. 

ERROR=47’s encountered immediately when RUNning “_fix” indicate that the file size information in the file’s header has been damaged, usually giving a large and incorrect value for the file’s actual size. In this case, the programmer may be required to OPEN the file as a STRING file >OPEN(1,ISZ=-1)”filename”, and sort out records from key data blocks manually. This procedure is generally not recommended, unless you have working knowledge of BBx files. 

If “_fix” does not display any of the options or generate any errors, then the file may already be a STRING file type, which may be the case if the file’s header information has been completely corrupted. Again, an experienced BBx programmer may be needed to sort out the data records if a good backup is not available. 

Note: During the scanning, _FIX prints “…” as a status indicator. Because screen I/O can slow down a program, you can REM out the 2 corresponding PRINT stmts on lines 2230 and 2260 to help speed it up. 

Last Modified: 02/23/2004 Product: PRO/5 Operating System: All platforms

BASIS structures five components of their technology into the BBx Generations.