A program receives error-status 1211, 0811, 0711 or abend code IX11 indicating the error-set is a system-owned index and error-area is an area that contains only a system-owned index. The PRINT SPACE utility indicates that there is plenty of space in the area. What could cause IDMS to think the area is full?
This condition can happen when storing a record that is an automatic member of an index, when connecting a new member to the index, or when modifying the sortkey field of a current member of the index.
Any of these operations could require the DBMS to store a new system index record (SR8). The minor status "11" indicates that the DBMS was unable to find space to store the SR8.
There are three possible reasons to encounter this condition:
- The index is restricted to a page range that is not the entire area. This "sub-area" page range could have little or no space available, so a PRINT SPACE FULL report on the entire area could give misleading information on space available.
- The area is defined with a PAGE RESERVE that is preventing the store of the SR8. PAGE RESERVE is a number of bytes on each page of the area that cannot be used to store records. It is reserved for the growth of existing variable-length records.
- The index is poorly sized. Standard recommendations are to select SR8 size and page size so that at least 4 full-sized SR8s will fit on a page. If the SR8 size chosen is too large or not a good fit for the chosen page size, you could have space available on a page but not enough to fit the SR8 the DBMS needs to store.
Also, consider that there are two types of SR8 record. The SR8s on the bottom level of the index structure, the ones that contain the down pointers to the member records, are eligible to be adjusted in length depending on their contents. These can be less than maximum length for a variety of reasons. SR8s on all of the higher levels of the index structure are not eligible for length adjustment and must always be stored at maximum size. It is most frequently the need to split and/or store one of these SR8s that causes the nn11 error-status if the index is not sized properly.
EXAMPLE: Page size is 13680. Minus header and footer this leaves 13648 bytes for storing records. If you defined the index so that maximum SR8 size was 7000 bytes you would never get more than one upper-level SR8 per page, leaving a great deal of "available space" on a page that could never be used to store another upper-level SR8.
Depending on the nature of the sortkey, duplicates option and the number of entries in bottom-level SR8s it would be possible to get multiple bottom-level SR8s per page but an index sized in this manner could have many pages in the area with space that could never be used to store an upper-level SR8.