Table E and FILEORG X'100' files (File architecture): Difference between revisions

From m204wiki
Jump to navigation Jump to search
(Created page with "Holds Large Object Data (BLOBs and CLOBs) When FILEORG x'100'is set on a file, this is enabled by reorganizing / CREATEing a file with [[ESIZE par...")
 
No edit summary
Line 12: Line 12:


<p>The 'chained LOBs' in Table E under [[FILEORG parameter|FILEORG]] x'100' files has a number of advantages over the way LOBs are stored and accessed in non x'100' files.</p>
<p>The 'chained LOBs' in Table E under [[FILEORG parameter|FILEORG]] x'100' files has a number of advantages over the way LOBs are stored and accessed in non x'100' files.</p>
<p>:space monitoring is simpler (as new occurrences of LOBs obtain space from the reuse queue when available.</p>
<p>*because the LOBs no longer need to be contiguous, space monitoring is simpler and files are less likely to fill up.</p>
<p>:fields may be defined so that 'small' entries may be stored 'locally' in the record (and so do not use an entire page in Table E</p>
<p>*fields may be defined so that 'small' entries may be stored 'locally' in the record (and so do not use an entire page in Table E)</p>
 
<p>*you no longer need to predict the fields may be defined so that 'small' entries may be stored 'locally' in the record (and so do not use an entire page in Table E)</p>


== Storing Large Objects ==
== Storing Large Objects ==


When a field is defined as a large object (LOB) ([[BLOB attribute|BLOB]] or [[CLOB attribute]]s) a pointer is stored in the record (in Tables B or X) and the LOB is stored in Table E.
<p>When a field is defined as a large object (LOB) ([[BLOB attribute|BLOB]] or [[CLOB attribute]]s) a pointer is stored in the record (in Tables B or X), and, depending on the [[MINLOBE attribute]] and length of the value being stored, and the LOB value is stored in its proper place, as follows:</p>


=== Pointer in the record ===
=== Pointer in the record ===


When you store a Large Object value in Table E, a Large Object descriptor is stored in Table B (or X depending on where the field is being ADDed). The descriptor contains the length, reserve, and a pointer to the Large Object data in the Table E page and is 27 bytes long.
<p>When you store a 'not null' Large Object value in Table E, a Large Object descriptor is stored in Table B (or X depending on where the field is being ADDed). The descriptor contains the length, and a pointer to the Large Object data in the Table E page and is 27 bytes long.<p>


This is the same as non x'100' files.


=== Table E Space Utilization ===
 
=== Storing a Large Object ===
 
<p>When the length of the value being stored is 0 (i.e.: a null string) the action taken depends on the 'repeating' type ([[EXACTLY-ONE attribute|EXACTLY-ONE]], [[AT-MOST-ONE attribute|AT-MOST-ONE]] or [[REPEATABLE attribute]]s). This is discussed in the next section.</p>
<p>Other than null strings, if the value being stored is less than or equal to the [[MINLOBE attribute]] for the field, then the value is stored directly in the record (Table B or X). Note that this is in addition to the pointer described above.</p>
<p>If the length of the value being stored is greater than the [[MINLOBE attribute]] for the field, the value is stored in a series of pages in Table E with the first (up to) 6140 bytes (4 bytes being reserved for the chain pointer) on the first page, the next (up to) 6140 bytes on the 'next' page, and so on. These pages are not, necessarily, contiguous. Any pages emptied by field or record deletes are first reused, before the pages at [[EHIGHPG parameter|EHIGHPG]] are used. .</p>
 
==== Null Strings and Large Objects ====
 
Unlike other field types, the [[STORE-NULL attribute|STORE-NULL]] and [[STORE-DEFAULT attribute]]s may not be set on LOB fields. This results in such fields having the equivalent to the LITeral option. The following table illustrates the results when null strings are stored in Large Object fields:       
 
{| class="wikitable";style="width="90%
|-
! align="center" scope="col" | Attribute
! align="center" scope="col" | Explicit Null <br/> ''fieldname'' = (how do I embed two single quotes>)
! align="center" scope="col" | Implicit Null <br/> ''fieldname'' = %X (where %X is null)
! align="center" scope="col" | No reference in code
|-
! scope="row"| EXACTLY-ONE
| (Note 1) 
| (Note 1)
| (Note 1)
|-
! scope="row"| AT-MOST-ONE
| field stored with null value 
| not present
| not present
|-
! scope="row"| REPEATABLE
| field stored with null value 
| not present
| not present
|}
 
Note 1: the field will always act as if it is physically present (and return a null).






=== Storing a Large Object ===





Revision as of 23:12, 2 April 2013

Holds Large Object Data (BLOBs and CLOBs)


When FILEORG x'100'is set on a file, this is enabled by reorganizing / CREATEing a file with ESIZE greater than 0, and then defining one or more fields with an attribute of CLOB or BLOB (the file must have an ESIZE for the latter to occur).

Available as of Model 204 V7.5


Summary

Storage and manipulation of Large Objects (LOBs):

The 'chained LOBs' in Table E under FILEORG x'100' files has a number of advantages over the way LOBs are stored and accessed in non x'100' files.

*because the LOBs no longer need to be contiguous, space monitoring is simpler and files are less likely to fill up.

*fields may be defined so that 'small' entries may be stored 'locally' in the record (and so do not use an entire page in Table E)

*you no longer need to predict the fields may be defined so that 'small' entries may be stored 'locally' in the record (and so do not use an entire page in Table E)

Storing Large Objects

When a field is defined as a large object (LOB) (BLOB or CLOB attributes) a pointer is stored in the record (in Tables B or X), and, depending on the MINLOBE attribute and length of the value being stored, and the LOB value is stored in its proper place, as follows:


Pointer in the record

When you store a 'not null' Large Object value in Table E, a Large Object descriptor is stored in Table B (or X depending on where the field is being ADDed). The descriptor contains the length, and a pointer to the Large Object data in the Table E page and is 27 bytes long.

This is the same as non x'100' files.

Storing a Large Object

When the length of the value being stored is 0 (i.e.: a null string) the action taken depends on the 'repeating' type (EXACTLY-ONE, AT-MOST-ONE or REPEATABLE attributes). This is discussed in the next section.

Other than null strings, if the value being stored is less than or equal to the MINLOBE attribute for the field, then the value is stored directly in the record (Table B or X). Note that this is in addition to the pointer described above.

If the length of the value being stored is greater than the MINLOBE attribute for the field, the value is stored in a series of pages in Table E with the first (up to) 6140 bytes (4 bytes being reserved for the chain pointer) on the first page, the next (up to) 6140 bytes on the 'next' page, and so on. These pages are not, necessarily, contiguous. Any pages emptied by field or record deletes are first reused, before the pages at EHIGHPG are used. .

Null Strings and Large Objects

Unlike other field types, the STORE-NULL and STORE-DEFAULT attributes may not be set on LOB fields. This results in such fields having the equivalent to the LITeral option. The following table illustrates the results when null strings are stored in Large Object fields:

Attribute Explicit Null
fieldname = (how do I embed two single quotes>)
Implicit Null
fieldname = %X (where %X is null)
No reference in code
EXACTLY-ONE (Note 1) (Note 1) (Note 1)
AT-MOST-ONE field stored with null value not present not present
REPEATABLE field stored with null value not present not present

Note 1: the field will always act as if it is physically present (and return a null).




The following Parameters and Commands relate to the Use of Table E

Note: Pages are either used or not in Table E, so there is no formula to determine whether a page is added to the reuse queue (unlike Tables B and X). Because of this, there are no EREUSE, EREUSED, or EQLEN parameters. The size of the reuse queue can always be determined by the difference between EHIGHPG and EPGSUSED.

EHIGHPG parameter The highest active Table E page. (The first page in Table E is page zero.)
EPGSUSED parameter The number of Table E pages currently in use.
ESIZE parameter The number of pages in Table E
FILEORG parameter The file organisation