D3Help - D3 and Advanced Pick Technical Support for  D3/AIX - D3/NT - D3/HP - D3/DG - D3/LINUX - D3/SCO - PROPLUS - AP/PRO - AP/NATIVE.

 

 

 

"Do it right the first time with a certified D3Help Expert"

 

 

 

Home General Support Data Corruption Down System Data Recovery Support Forum Live Chat About Us

24/7 Emergency Response (ER) Hotline 949-200-7052

 

 
 

 

Out of Disk Space


Here is a table of the most common aborts that we have dealt with. 

We hope that this will help you get a better understanding of what each abort means. 

(See also Data Recovery)


 

 

 

 

 

 

 

 

 

 

 

 

File Inconsistency Error

The system will generate this error message if a bad count field is found in an item. The way it works is each item within a file starts with an item header. The item header consists of 8 bytes of different flags that represent the type of item. Types of items could be a DIRECT item, a POINTER item that points to a group of frames that contains a large item, a POINTER item that points to a File Control Block or a file D-pointer or a BINARY item.

One of the item header flags contains the item size. The system scans the item looking for an end of item mark. If the end of item mark does not match the item size in the item header we get the error message File Inconsistency Error, Bad Count field.

The message could be caused by an item that has control characters imbedded in the item. This could cause the system to misinterpret this character has a end of item mark.

Another reason for this message could be due to a bad link. The correct item size may be in the item header, but the frame links off to another frame and never finds the end of item mark. If the problem is a true bad count field and the item is intact, it is possible that the count field can be changed to the correct value with no data loss.

top

Forward Link Zero

This message indicates that the system was following normal links in a group of frames. The last frame in the group does not have and end of group mark and the system thinks it needs to follow the links to next forward link. Since we are at the end of the group the are no more forward links except zero. There are other reasons for this error, but this is the most common example.  

The best way to correct this type of problem is to add an end of group mark to the last frame. This will allow the item to be edited. Since the data in the item may not be all there, the item can be deleted and sel-restored from a back-up tape.

top

Frame Out Of Range

This means that the system has accessed a frame larger than the highest frame on the system (MaxFid) or has accessed a frame equal to zero. The message is also know as Referencing Illegal Frame.

top

Group Format Error

The system will generate this error message if a bad count field is found in an item. The way it works is each item within a file starts with an item header. The item header consists of 8 bytes of different flags that represent the type of item. Types of items could be a DIRECT item, a POINTER item that points to a group of frames that contains a large item, a POINTER item that points to a File Control Block or a file D-pointer or a BINARY item.

One of the item header flags contains the item size. The system scans the item looking for an end of item mark. If the end of item mark does not match the item size in the item header we get the error message File Inconsistency Error, Bad Count field.

The message could be caused by an item that has control characters imbedded in the item. This could cause the system to misinterpret this character has a end of item mark.

Another reason for this message could be due to a bad link. The correct item size may be in the item header, but the frame links off to another frame and never finds the end of item mark. If the problem is a true bad count field and the item is intact, it possible that the count field can be changed to the correct value with no data loss.

top

Backward Link Zero

Frame links are known to be correct when a frame has a forward link and the backward link that links back to the link that referenced it.

Example: Frame A fwd links to frame B. Frame B should have a backward link back to frame A. If frame B does not link back to frame A and links to a frame equal to zero then we will get this Backward Link Zero message.

top

Illegal Op code Abort

This is normally caused by bad object code or an ABS inconsistency.

At a low level, the system has received an instruction to execute an op code and has discovered that the pointer to the op code is not correct or that the op code is garbage.

top

Referencing Illegal Frame

This means that the system has accessed a frame larger than the highest frame on the system (MaxFid) or has accessed a frame equal to zero. The message is also known as Frame out of Range.

top

Debugger Abort Code

Many different scenarios can cause the system to generate this message. The abort means that the process as fallen into the virtual debugger and the GFE handler was not invoked. At this point all fixes must be performed with the virtual debugger. We have seen this abort be caused by bad count fields, item body corruption, overflow table corruption just to name a few. 

top

Inconsistent File Control Block (FCB)

This message is usually accompanied with a frame number. What is happening here is that the system has encountered a pointer-item that points to a File Control Block or a frame with file d-pointer information, like the filename, base, modulo, privileges and index information. 

If the pointer should be pointing to the FCB frame but points to a different frame, then the system will generate this message and the file will not be accessible until the pointer is found and changed. 

If the pointer-item points to the correct FCB frame and the FCB frame has been overwritten with garbage characters or a stray process then you will see this abort.

If the pointer-item points to the correct FCB frame and the FCB frame appears to be correct, but system information within the frame at key offsets are missing or have been modified then this abort will be triggered.

top

Overflow Table Corruption

Unused disk space on a Pick file system is known as "overflow". The overflow table keeps track of the available space, removing frames when they are in use and returning them when they become available again. It is maintained as a linked list of contiguous blocks of frames.

If the system is shutdown or rebooted incorrectly, then the overflow table may become corrupted. Alternatively, there may be a situation where the system has run out of disk space, and you would like to allocate enough space in order to do a file-save.

To rebuild the overflow table you can either use the system debugger or the Monitor Debugger. If you cannot break into the system debugger then you will have to use the Monitor Debugger.

In short, we will have to modify Frame 1 or 12, which contains the values of some variables which we will need, and Frame 6, which contains the beginning addresses to the list of frames in the overflow table.

top

Privileged Op Code Abort

This is normally caused by bad object code or an ABS inconsistency.

At a low level the system has received an instruction to execute an op code and has discovered that the pointer to the op code is not correct or that the op code is garbage.

top

Workspace Inconsistency

This message will manifest when the users workspace as been corrupted for some reason or another. Could be due to a faulty program, third party ABS or many other low level problems. Workspace Inconsistency or Corrupted Workspace will show up on a port after typing 'where' from tcl.

Typing 'reset-user port#' from tcl will normally clear this problem. If this a reoccurring error that reset-user does not clean-up then we may be able to get more information from the debugger while the port is in the corrupted state.

top

Abs do not verify

"ABS FRAME MISMATCHES - EXPECTED FFFF FOUND FFFF."

This message occurs when ABS in memory does not match the DATA ABS, due to ABS corruption. This corruption could be in the DATA ABS, or in memory.

To correct this problem, clear the DATA ABS and SEL-RESTORE the DATA ABS from the Pick DATA diskettes or from a pseudo floppy. Reload the VIRTUAL ABS (ABS Diskettes #1 & #2 or Pseudo Floppy) from the 'A' option.

WARNING: This process will require reloading any ABS Patches and custom ABS.

PROCEDURE:

1. From the DM account at TCL type: clear-file data abs

2. SET-FLOPPY (AH or SET-DEVICE device#  

(depending on the drive you will be loading your Pick Data files from).

3. If Pick was loaded from diskette then, insert the original Pick data #1 diskette.

4. Type SEL-RESTORE ABS (I , choose F)ull, Account name on tape = DM Filename = ABS

5. Insert the DATA #2 disk when prompted.

6. From TCL in the DM account type VERIFY-SYSTEM

7. If the system still does not verify, Shutdown and reboot the system (with the System #1 disk or Monitor patch if you have a NATIVE or PRO system), at the option menu choose A)BS and reload ABS using ABS #1 & #2 diskettes or the ABS file listed in the display.

8. The system should verify now.

9. Reload any ABS patches and custom ABS that were previously loaded.

top