Bitmaps (File architecture) - Revision history

JAL: link repair

2015-01-15T20:43:59Z

link repair

← Older revision		Revision as of 20:43, 15 January 2015
Line 10:		Line 10:
	<ul>		<ul>

	<li>Bitmaps track records inside both indexing types (hash and B-tree).		<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>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>During procedure execution, all found sets are held as bitmaps. </li>
	</ul>		</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.		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==		==Manipulating bitmaps==
Line 32:		Line 32:
	==Example==		==Example==
	<p>		<p>
	~~In this~~ example ~~(which~~ looks at a bitmap as used by an index~~), this is~~ the beginning of the bitmap representing the ORD CHAR field value pair <code>COLOR = BLUE</code> for the ~~3rd~~ segment of a file (which covers [[#Internal Record Number\|IRNs]] 98304 to 147455):</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>

	:[[File:Bit Map Example (File Architecture).jpg\|border]]		<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.~~

			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 architecture]]

JAL at 00:29, 28 January 2014

2014-01-28T00:29:24Z

← Older revision		Revision as of 00:29, 28 January 2014
Line 17:		Line 17:
	</ul>		</ul>

	And, for [[Table E non x'100' (File architecture)\|Table E non FILEORG x'100']] files, large object available pages are tracked as well.		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==		==Manipulating bitmaps==

JAL at 21:26, 22 January 2014

2014-01-22T21:26:56Z

← Older revision		Revision as of 21:26, 22 January 2014
Line 1:		Line 1:
	<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>		<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>

	== The ~~workings~~ of ~~a bitmap ==~~		==Usages==
			The most common use of bitmaps in Model 204 is to track sets of records:
			<ul>

	<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>~~		<li>Bitmaps track records inside both indexing types (hash and B-tree).

	~~== Usages ==~~		<li>The [[#Table D (File Architecture) existence bitmap\|existence bitmap]] tracks which internal record numbers are in use.

	~~The most common use in Model 204 is to track sets of records:~~		<li>During procedure execution, all found sets are held as bitmaps.
			</ul>
	* Inside both indexing types (hash and B-tree) bitmaps are used
	* The [[#Table D (File Architecture) existence bitmap\|existence bitmap]] which tracks which internal record numbers are in use.
	* During procedure execution, all found sets are held as bitmaps

	And, for [[Table E non x'100' (File architecture)\|Table E non FILEORG x'100']] files, large object available pages are tracked as well.		And, for [[Table E non x'100' (File architecture)\|Table E non FILEORG x'100']] files, large object available pages are tracked as well.

	== Manipulating bitmaps ==		==Manipulating bitmaps==
			Once conditions are represented as bitmaps, the manipulation ("ANDing" and "ORing") of these sets is straightforward and efficient:

	~~Once you have conditions 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:

	~~In code which has a find such as:~~		<p class="code">X: In ''filename'' FD COLOR = 'BLUE'

	<p class="code">
	X: In ''filename'' FD COLOR = 'BLUE'
	STATE = 'NY' ...		STATE = 'NY' ...

	</p>		</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>

	<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 'X'. </p>		==Example==
			<p>
	== Example ==		In this example (which looks at a bitmap as used by an index), this is the beginning of the bitmap representing the ORD CHAR field value pair <code>COLOR = BLUE</code> for the 3rd segment of a file (which covers [[#Internal Record Number\|IRNs]] 98304 to 147455):</p>

	<p>In this example (which looks at a bitmap as used by an index), this is the beginning of the bitmap representing the ORD CHAR field value pair <code>COLOR = BLUE</code> for the 3rd segment of a file (which covers [[#Internal Record Number\|IRNs]] 98304 to 147455):</p>

	:[[File:Bit Map Example (File Architecture).jpg\|border]]		:[[File:Bit Map Example (File Architecture).jpg\|border]]

JAL: /* Example */

2014-01-22T21:06:14Z

Example

← Older revision		Revision as of 21:06, 22 January 2014
Line 32:		Line 32:
	== Example ==		== Example ==

	<p>In this example (which looks at a bitmap as used by an index), this is the beginning of the bitmap representing the ORD CHAR field value pair <code>COLOR = BLUE</code> for the 3rd segment of a file (which covers [[#Internal Record Number\|IRNs]] 98304 to 147455).</p>		<p>In this example (which looks at a bitmap as used by an index), this is the beginning of the bitmap representing the ORD CHAR field value pair <code>COLOR = BLUE</code> for the 3rd segment of a file (which covers [[#Internal Record Number\|IRNs]] 98304 to 147455):</p>

	:[[File:Bit Map Example (File Architecture).jpg]]		:[[File:Bit Map Example (File Architecture).jpg\|border]]

	Based on this, record 98304 does not have an occurrence of <code>COLOR = BLUE</code>, but records 98305 and 98306 do... and so on.		Based on this, record 98304 does not have an occurrence of <code>COLOR = BLUE</code>, but records 98305 and 98306 do... and so on.

JAL: /* Example */

2014-01-22T21:03:17Z

Example

← Older revision		Revision as of 21:03, 22 January 2014
Line 32:		Line 32:
	== Example ==		== Example ==

	<p>In this example (which looks at a bitmap as used by an index), this is the beginning of the bitmap representing the ORD CHAR field value pair ''COLOR = BLUE'' for the 3rd segment of a file (which covers [[#Internal Record Number\|IRNs]] 98304 to 147455).</p>		<p>In this example (which looks at a bitmap as used by an index), this is the beginning of the bitmap representing the ORD CHAR field value pair <code>COLOR = BLUE</code> for the 3rd segment of a file (which covers [[#Internal Record Number\|IRNs]] 98304 to 147455).</p>

	~~:::[[File:Bit Map Example (File Architecture).jpg]]~~

	~~Based in this, record 98304 does not have an occurrence of ''COLOR = BLUE'', but records 98305 and 98306 do... and so on.~~


			:[[File:Bit Map Example (File Architecture).jpg]]

			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 architecture]]

ELowell at 22:40, 18 December 2013

2013-12-18T22:40:03Z

← Older revision		Revision as of 22:40, 18 December 2013
Line 14:		Line 14:
	* During procedure execution, all found sets are held as bitmaps		* During procedure execution, all found sets are held as bitmaps

	And, for [[Table E non x'100' (File ~~Architecture~~)\|Table E non FILEORG x'100']] files, large object available pages are tracked as well.		And, for [[Table E non x'100' (File architecture)\|Table E non FILEORG x'100']] files, large object available pages are tracked as well.

	== Manipulating bitmaps ==		== Manipulating bitmaps ==

Admin at 21:46, 18 December 2013

2013-12-18T21:46:55Z

← Older revision		Revision as of 21:46, 18 December 2013
Line 4:		Line 4:
	== The workings of a bitmap ==		== 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>		<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 ==		== Usages ==

Admin: Admin moved page Bit Maps (File Architecture) to Bitmaps (File architecture) without leaving a redirect

2013-12-18T21:31:51Z

Admin moved page Bit Maps (File Architecture) to Bitmaps (File architecture) without leaving a redirect

← Older revision	Revision as of 21:31, 18 December 2013
(No difference)

ELowell at 21:29, 18 December 2013

2013-12-18T21:29:49Z

← Older revision		Revision as of 21:29, 18 December 2013
Line 1:		Line 1:
	<p>A ~~Bit Map~~, 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>		<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 ~~Bit Map~~ ==		== 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>		<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>
Line 10:		Line 10:
	The most common use in Model 204 is to track sets of records:		The most common use in Model 204 is to track sets of records:

	* Inside both indexing types (hash and B-tree) ~~bit maps~~ are used		* Inside both indexing types (hash and B-tree) bitmaps are used
	* The [[#Table D (File Architecture) ~~Existence Bit Map~~\|~~Existence Bit Map~~]] which tracks which internal record numbers are in use.		* The [[#Table D (File Architecture) existence bitmap\|existence bitmap]] which tracks which internal record numbers are in use.
	* During procedure execution, all found sets are held as ~~bit maps~~		* During procedure execution, all found sets are held as bitmaps

	And, for [[Table E non x'100' (File Architecture)\|Table E non FILEORG x'100']] files, large object available pages are tracked as well.		And, for [[Table E non x'100' (File Architecture)\|Table E non FILEORG x'100']] files, large object available pages are tracked as well.

	== Manipulating ~~Bit Maps~~ ==		== Manipulating bitmaps ==

	Once you have conditions represented as bitmaps, the manipulation ('anding' and 'oring') of these sets is straightforward and efficient:		Once you have conditions represented as bitmaps, the manipulation ('anding' and 'oring') of these sets is straightforward and efficient:
Line 32:		Line 32:
	== Example ==		== Example ==

	<p>In this example (which looks at a ~~bit map~~ as used by an index), this is the beginning of the ~~bit map~~ representing the ORD CHAR field value pair ''COLOR = BLUE'' for the 3rd segment of a file (which covers [[#Internal Record Number\|IRNs]] 98304 to 147455).</p>		<p>In this example (which looks at a bitmap as used by an index), this is the beginning of the bitmap representing the ORD CHAR field value pair ''COLOR = BLUE'' for the 3rd segment of a file (which covers [[#Internal Record Number\|IRNs]] 98304 to 147455).</p>

	:::[[File:Bit Map Example (File Architecture).jpg]]		:::[[File:Bit Map Example (File Architecture).jpg]]

ELowell: /* Manipulating Bit Maps */

2013-05-16T19:11:25Z

Manipulating Bit Maps

← Older revision		Revision as of 19:11, 16 May 2013
Line 28:		Line 28:
	</p>		</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 'X'. </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 'X'. </p>




	== Example ==		== Example ==