Table X (File architecture): Difference between revisions

From m204wiki
Jump to navigation Jump to search
mNo edit summary
No edit summary
Line 1: Line 1:


Stores all Record [[File Architecture Extensions|Extensions]] in a separate table from the the base records (so that [[File Architecture Table B|Table B]] contains only these base records.   
Stores all Record [[File Architecture Extensions|Extensions]] in a separate table from the the base records (so that [[File Architecture Table B|Table B]] contains only the base records).   
   
   


Line 13: Line 13:
The [[File Architecture Table B|Table B]] of a Model 204 file has a maximum number of 16.7 million record numbers (IRNs). By default ([[XSIZE parameter|XSIZE]] = 0), these 'slots' are used for both base records and extension records.  
The [[File Architecture Table B|Table B]] of a Model 204 file has a maximum number of 16.7 million record numbers (IRNs). By default ([[XSIZE parameter|XSIZE]] = 0), these 'slots' are used for both base records and extension records.  


By implementing Table X ([[XSIZE parameter|XSIZE]] > 0) all defined IRNs (up to 16.7 million) in Table B are used for base records only, allowing the storage of the maximum number of records in a file regardless of the number of extensions.
By implementing Table X ([[XSIZE parameter|XSIZE]] > 0) all defined IRNs (up to 16.7 million) in Table B are used for base records only, allowing the storage of the maximum possible number of records in a file regardless of the number of extensions.


Table X is significantly larger than the 16.7 million limit of Table B; as the product of [[XSIZE parameter|XSIZE] * [[XRECPPG parameter|XRECPPG] may be up to 512 million extension slots.  
Table X can be significantly larger than the 16.7 million limit of Table B; as the product of [[XSIZE parameter|XSIZE] * [[XRECPPG parameter|XRECPPG] may be up to 512 million extension slots.  


When the defined capacity of Table B or Table X is exceeded the file is marked full or the updating transaction is backed out.
When the defined capacity of Table B or Table X is exceeded the file is marked full or the updating transaction is backed out.
Line 27: Line 27:


[[BRECPPG parameter|BRECPPG]] remains the '''maximum number''' of records which may occur on a page, and so IRNs may still be wasted (never assigned to a record) as data fills up a page.  
[[BRECPPG parameter|BRECPPG]] remains the '''maximum number''' of records which may occur on a page, and so IRNs may still be wasted (never assigned to a record) as data fills up a page.  




Line 44: Line 42:
    
    


When a new record is stored, rather than using any and all space available on a page only up to [[BRLIMSZ parameter|BRLIMSZ]]) bytes will be stored in Table B. This ensures that the full [[BSIZE parameter|BSIZE] * [[BRECPPG parameter|BRECPPG] number of IRNs can actually be stored in the file.   
When a new record is stored, rather than using any and all space available on a page, only up to [[BRLIMSZ parameter|BRLIMSZ]]) bytes will be stored in Table B. This ensures that the full [[BSIZE parameter|BSIZE] * [[BRECPPG parameter|BRECPPG] number of IRNs can actually be stored in the file.   
 
[[BRLIMSZ parameter|BRLIMSZ]] must be large enough to hold all preallocated fields.


(Note that the [[BRESERVE parameter]] is ignored with x'01' [[RECRDOPT parameter|RECRDOPT]] files).
(Note that the [[BRESERVE parameter]] is ignored with x'01' [[RECRDOPT parameter|RECRDOPT]] files).
Line 58: Line 58:
===Indexing Performance===
===Indexing Performance===


Even if a file has significantly fewer records than the limit, you should consider the performance of your indices in deciding whether to utilize Table X.
Even if a file has significantly fewer records than the limit, you should consider the performance of your indices in deciding whether to utilize Table X, notably where you expect to have fields with non unique values.  


When Table X is enabled and [[RECRDOPT parameter|RECRDOPT]] = x'01', the fact there are no wasted slots means that the bit maps containing the bitmap and list pages (and, of course, the [[Existence Bit Map (File Architecture)|Existence Bit Map]]) are as compressed as possible. 
   
   


===Avoidance of 'Sick Record' Snaps===


When large sets of unlocked records (either via the use of [[Find Without Locks statement|Find Without Locks]] (FDWOL) or by referencing records on a Model 204 List) are processed it is very possible that the records will either have their contents changed, or even been deleted by the time the record is read. There are three problems which may be encountered when this happens:


: the record should no longer be selected , its contents no longer matching the selection criteria
: the record has been deleted (and so 'Nonexistent record'messages are produced)
: the record now (due to delete and update processing) contains an extension record.
The last of these causes a 'Sick Record' snap.
While Rocket encourages the use of [[Processing unlocked sets of records|coding techniques]] to prevent all of these issues, File Managers can protect themselves from the snaps (at least) by enabling Table X in files where such processing is expected.   






===Avoidance of 'Sick Record' Snaps===


==The following Parameters relate to the Use of Table X==
==The following Parameters relate to the Use of Table X==

Revision as of 03:01, 14 March 2013

Stores all Record Extensions in a separate table from the the base records (so that Table B contains only the base records).


Enabled by reorganizing / CREATEing a file with XSIZE greater than 0.


Available as of Model 204 V7.1


Summary

The Table B of a Model 204 file has a maximum number of 16.7 million record numbers (IRNs). By default (XSIZE = 0), these 'slots' are used for both base records and extension records.

By implementing Table X (XSIZE > 0) all defined IRNs (up to 16.7 million) in Table B are used for base records only, allowing the storage of the maximum possible number of records in a file regardless of the number of extensions.

Table X can be significantly larger than the 16.7 million limit of Table B; as the product of [[XSIZE parameter|XSIZE] * [[XRECPPG parameter|XRECPPG] may be up to 512 million extension slots.

When the defined capacity of Table B or Table X is exceeded the file is marked full or the updating transaction is backed out.

Table X may be implemented in one of two ways depending on the setting of the RECRDOPT parameter.


The default setting of the RECRDOPT (x'00')

If the default setting of RECRDOPT is used, while all extensions are stored in Table X, the record allocation in Table B is identical to what it is without Table X enabled.

BRECPPG remains the maximum number of records which may occur on a page, and so IRNs may still be wasted (never assigned to a record) as data fills up a page.


Setting RECRDOPT to x'01'

This setting changes the base record allocation to ensure that all defined IRNs are available for use.

For all x'01' RECRDOPT files, a base record size limit (the read only parameter BRLIMSZ) is calculated:

For an entry order file:
BRLIMSZ = (6140 / BRECPPG) - 2
For an unordered file:
BRLIMSZ = (6136 / BRECPPG) – 2


When a new record is stored, rather than using any and all space available on a page, only up to BRLIMSZ) bytes will be stored in Table B. This ensures that the full [[BSIZE parameter|BSIZE] * [[BRECPPG parameter|BRECPPG] number of IRNs can actually be stored in the file.

BRLIMSZ must be large enough to hold all preallocated fields.

(Note that the BRESERVE parameter is ignored with x'01' RECRDOPT files).


Advantages of Using Table X

Scalability

The obvious advantage of implementing Table X relates to the ability to store the full 16.7 million base records in a Model 204 file,

Indexing Performance

Even if a file has significantly fewer records than the limit, you should consider the performance of your indices in deciding whether to utilize Table X, notably where you expect to have fields with non unique values.

When Table X is enabled and RECRDOPT = x'01', the fact there are no wasted slots means that the bit maps containing the bitmap and list pages (and, of course, the Existence Bit Map) are as compressed as possible.


Avoidance of 'Sick Record' Snaps

When large sets of unlocked records (either via the use of Find Without Locks (FDWOL) or by referencing records on a Model 204 List) are processed it is very possible that the records will either have their contents changed, or even been deleted by the time the record is read. There are three problems which may be encountered when this happens:

the record should no longer be selected , its contents no longer matching the selection criteria
the record has been deleted (and so 'Nonexistent record'messages are produced)
the record now (due to delete and update processing) contains an extension record.

The last of these causes a 'Sick Record' snap.

While Rocket encourages the use of coding techniques to prevent all of these issues, File Managers can protect themselves from the snaps (at least) by enabling Table X in files where such processing is expected.



The following Parameters relate to the Use of Table X

BRLIMSZ
RECRDOPT
XQLEN
XRECPPG
XRESERVE
XREUSE
XREUSED
XSIZE