Hello, I have a couple of theoretical questions. I don’t need to know the answer for my work; they’re just simple questions that came up as I was trying to understand the operational scheme of Adabas. Please correct me if I’m wrong.
Once the RABN has been obtained from the ISN in the Address Converter, that RABN represents a memory block on the storage devices. In the next step, is there simply a communication with the storage controller to request that block? Once the block is retrieved, how is the specific record recovered? Does the block contain some kind of directory that points to the specific address within the block for the desired record?
How does the storage system work in relation to record size expansion? I understand that each block reserves a percentage of its space to allow for potential increases in the size of records contained in that block without needing to relocate them. But how is this expansion managed? Are the records that follow the expanded record shifted, or is the record fragmented so that the original data is kept as is and the new added values are placed in the reserved space at the end of the block? And if it’s the latter case, how is this tracked?
I know these are questions I don’t need answers to because I work with Natural and not Adabas, but I like to understand the overall operational scheme. Thank you.
AFAIK (and remenber) the Data RABN begins with a length counter telling the number of bytes used in the block. Then comes the data records, also starting with the record length counter and the ISN. Then Adabas jumps thru the records, until the desired ISN is reached.
The Data RABN will normally have some unused space left in the end. For new RABNs this is determined by the padding factor. If the RABN overflows, the block is split into two blocks - the old one, and a new one either obtained from the chain of reusable blocks or from the unused blocks in Data RABNs allocated to the file.
For ASSO RABN’s it does an INDEX block split 50/50 (or as close as possible).
For DATA it moves the offending record that is causing the overflow to a new block and rewrites the old block without that record. ADABAS uses the DSST to find a block that the new record will fit in. It will only use the current DSST block it is pointing at to locate a new block with sufficient space. If it doesn’t find space, the record will be added to a new block and it will read in the next DSST block for next time. This avoids scanning entire DSST. So it is possible that records are moved to the end (or to a later RABN) after an update. This is why you should not do mass updates using a READ PHYSICAL, rather use a READ BY ISN.
Eugene (Gene) Miklovich
ADABAS/NATURAL Systems Support and DBA
Cell: 916-202-7047
Normal Hours: 8am-4pm E.T.
Please call or text if assistance needed outside these hours.
Once the RABN is obtained, the buffer pool (area in memory sized by LBP parameter) is checked for the RABN. If it is not found there, it is read from the storage device into the buffer pool. The RABN is then scanned in memory as Steen indicated.
The data block will have some number of records stored in it as Steen mentions, each with a block length followed by the record length and ISN for each record, which are stored in the block in ISN order. All data for the record is kept together (aside from spanned records or BLOBs), so expanded data for one record causes the other records in the block to “shift right”. If the expansion would overflow the block, then the current record being updated is removed from the block and inserted in a different block as Eugene describes. So, no “record fragmentation” takes place.
