Bitmaps (File architecture): Difference between revisions
m (→Example) |
m (link repair) |
||
| (15 intermediate revisions by 6 users not shown) | |||
| Line 1: | Line 1: | ||
<p> | <p> | ||
A bitmap, as the name implies, is a series of "on" and "off" bits which are used to track a condition. These maps are used extensively throughout Model 204 to track sets of records or pages.</p> | |||
==The workings of a bitmap== | |||
<p> | |||
The [[Page (File architecture)|page]] size in Model 204 of 6184 bytes contains 6144 "usable" bytes (along with its 40 byte trailer). As such, conditions of up to 49152 "things" (usually records but also pages) can be tracked on a single page.</p> | |||
==Usages== | |||
The most common use of bitmaps in Model 204 is to track sets of records: | |||
<ul> | |||
<li>Bitmaps track records inside both indexing types (hash and B-tree). </li> | |||
<li>The [[Table D (File architecture)#Existence bitmap|existence bitmap]] tracks which internal record numbers are in use. </li> | |||
< | <li>During procedure execution, all found sets are held as bitmaps. </li> | ||
</ul> | |||
And, for [[Table E and non-FILEORG X'100' files (File architecture)|Table E non-FILEORG X'100']] files, large object available pages are tracked as well. | |||
==Manipulating bitmaps== | |||
Once conditions are represented as bitmaps, the manipulation ("ANDing" and "ORing") of these sets is straightforward and efficient: | |||
In code that has a <var>Find</var> such as: | |||
<p class="code">X: In ''filename'' FD COLOR = 'BLUE' | |||
STATE = 'NY' ... | |||
</p> | |||
<p> | |||
What is happening (given the implied "AND") is that the sets of records for each criteria are retrieved, and then "ANDed" (any bits "on" on both, are "on" on the resultant bitmap associated with the label <code>X</code>. </p> | |||
== Example == | ==Example== | ||
<p> | |||
This example looks at a bitmap as used by an index. It shows the beginning of the bitmap representing the <var>ORD CHAR</var> field value pair <code>COLOR=BLUE</code> for the third segment of a file (which covers [[#Internal Record Number|IRNs]] 98304 to 147455):</p> | |||
<p> | <p class="figure">[[File:Bit Map Example (File Architecture).jpg|border]] </p> | ||
Based on this, record 98304 does not have an occurrence of <code>COLOR=BLUE</code>, but records 98305 and 98306 do. And so on. | |||
[[Category:File architecture]] | |||
[[Category:File | |||
Latest revision as of 20:43, 15 January 2015
A bitmap, as the name implies, is a series of "on" and "off" bits which are used to track a condition. These maps are used extensively throughout Model 204 to track sets of records or pages.
The workings of a bitmap
The page size in Model 204 of 6184 bytes contains 6144 "usable" bytes (along with its 40 byte trailer). As such, conditions of up to 49152 "things" (usually records but also pages) can be tracked on a single page.
Usages
The most common use of bitmaps in Model 204 is to track sets of records:
- Bitmaps track records inside both indexing types (hash and B-tree).
- The existence bitmap tracks which internal record numbers are in use.
- During procedure execution, all found sets are held as bitmaps.
And, for Table E non-FILEORG X'100' files, large object available pages are tracked as well.
Manipulating bitmaps
Once conditions are represented as bitmaps, the manipulation ("ANDing" and "ORing") of these sets is straightforward and efficient:
In code that has a Find such as:
X: In filename FD COLOR = 'BLUE' STATE = 'NY' ...
What is happening (given the implied "AND") is that the sets of records for each criteria are retrieved, and then "ANDed" (any bits "on" on both, are "on" on the resultant bitmap associated with the label X.
Example
This example looks at a bitmap as used by an index. It shows the beginning of the bitmap representing the ORD CHAR field value pair COLOR=BLUE for the third segment of a file (which covers IRNs 98304 to 147455):
.jpg)
Based on this, record 98304 does not have an occurrence of COLOR=BLUE, but records 98305 and 98306 do. And so on.