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...")
 
 
(40 intermediate revisions by 8 users not shown)
Line 1: Line 1:
Holds Large Object Data (BLOBs and CLOBs)  
<span class="pageSubtitle">Holds Large Object data (BLOBs and CLOBs)</span>


When FILEORG x'100'is set on a file, this is enabled by reorganizing / [[CREATE command: File|CREATE]]ing a file with [[ESIZE parameter|ESIZE]] greater than 0, and then [[DEFINE FIELD command|defining one or more fields]] with an attribute of CLOB or BLOB (the file must have an ESIZE for the latter to occur).  
Storage and manipulation of Large Objects (LOBs) differs greatly depending on whether <var>FILEORG</var> X'100' is set for the file. This page discusses working with <var>FILEORG</var> X'100' files; for a parallel discussion of working with LOBs in files where FILEORG X'100' is ''not'' set, see [[Table E and non-FILEORG X'100' files (File architecture)]]. For a summary of the differences between working with LOB data in files where <var>FILEORG</var> X'100' is set and files where it is not, see [[Table E (File architecture)]].  


Available as of Model 204 V7.5
When the <var>[[FILEORG parameter|FILEORG]]</var> X'100' bit is set on a file, you enable large object data storage by:
<ol>
<li>Reorganizing or [[CREATE command: File|creating]] a file with <var>[[ESIZE parameter|ESIZE]]</var> greater than 0.


<li>[[DEFINE FIELD command|Defining one or more fields]] with an attribute of [[Field design#BLOB.2C CLOB and MINLOBE attributes|CLOB or BLOB]]. (The file must have an <var>ESIZE</var> for its fields to be defined as <var>CLOB</var> or <var>BLOB</var>.)
</ol>


==Summary==
The <var>FILEORG</var> X'100' bit and its Table E effects are available as of Model&nbsp;204 V7.5.


Storage and manipulation of Large Objects (LOBs):  
==Summary==
In a <var>FILEORG</var> X'100' file, all LOBs are chained.
Storing chained LOBs has the following advantages over storing and accessing LOBs in non X'100' files:  
<ul>
<li>Because the LOBs no longer need to be contiguous, space monitoring is simpler and Table E is less likely to fill up. </li>


<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>
<li>You can define fields so that "small" LOBs can be stored "locally" in the record (and so do not use an entire page in Table E). See [[Field design#Using the MINLOBE attribute|Using the MINLOBE attribute]]. </li>  
<p>:space monitoring is simpler (as new occurrences of LOBs obtain space from the reuse queue when available.</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>
<li>You no longer need to predict (using the [[Data maintenance#ADD_statement|RESERVE clause]]) the size to which a LOB field might grow. </li>
</ul>


==Storing Large Objects==
<p>
Defining a field as a large object (LOB) using the [[Field design#BLOB attribute|BLOB]] or [[Field design#CLOB attribute|CLOB attribute]] stores a pointer in the record in Table B or Table X. Storage of the LOB value depends on the [[Field design#MINLOBE attribute|MINLOBE attribute]] and the length of the value being stored, as described below.</p>


== Storing Large Objects ==
===Pointer in the record===
<p>
When you store a "not null" Large Object value in Table E, a Large Object descriptor is stored in Table B (or Table X depending on where the field is being added). The 27-byte descriptor contains the length of and a pointer to the Large Object data in the Table E page.</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 the LOB is stored in Table E.  
This descriptor is the same as in non X'100' files.


=== Pointer in the record ===
=== Storing a Large Object ===
When the length of the value being stored is 0 (a null string), the action taken depends on the "repeating" type ([[Field design#AT-MOST-ONE, REPEATABLE and EXACTLY-ONE attributes|AT-MOST-ONE, REPEATABLE, and EXACTLY-ONE attributes]]) as discussed in the next section.
<p>
Other than null strings, if the value being stored is less than or equal to the <var>MINLOBE</var> attribute for the field, the value is stored directly in the record (Table B or Table X). Note that this value is in addition to the pointer described above.</p>
<p>
If the length of the value being stored is greater than the <var>MINLOBE</var> attribute for the field, the value is stored in a series of pages in Table E. The first (up to) 6140 bytes (4 bytes being reserved for the chain pointer) go on the first page, the next (up to) 6140 bytes go on the "next" page, and so on. These pages are not necessarily contiguous. Any pages emptied by LOB deletes are first reused before the pages at <var>[[EHIGHPG parameter|EHIGHPG]]</var> are used. </p>


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.
====Null strings and Large Objects====
 
The [[Field design#STORE-DEFAULT (SD) and STORE-NULL (SN) attributes|STORE-DEFAULT (SD) and STORE-NULL (SN) attributes]] cannot be set on LOB fields like they can on other field types. This restriction results in LOB fields having the equivalent of the LITeral option. The following table illustrates the results when null strings are stored in Large Object fields:       
 
=== Table E Space Utilization ===
 
 
 
=== Storing a Large Object ===


<table class="thJustBold" style="width:90%">
<tr class="head">
<th align="center">Attribute</th>
<th align="center">Explicit null <br/> ''fieldname'' = ' '</th>
<th align="center">Implicit null <br/> ''fieldname'' = ''%x'' (where ''%x'' is null) </th>
<th align="center">No reference in code </th></tr>
<tr><th>EXACTLY-ONE</th>
<td>(see Note, below) </td>
<td>(see Note, below) </td>
<td>(see Note, below) </td></tr>
<tr><th>AT-MOST-ONE</th>
<td>field stored with null value </td>
<td>not present </td>
<td>not present </td></tr>
<tr><th>REPEATABLE</th>
<td>field stored with null value </td>
<td>not present </td>
<td>not present </td></tr>
</table>


<p class="note"><b>Note:</b> The field will always act as if it is physically present (and return a null). However, <var>EXACTLY-ONE</var> fields react a bit differently depending on whether they are inside a field group or not. Inside a field group, all three operations will result in a field being present (as displayed in a <var>[[PAI statement|PAI]]</var>). Outside of field groups, (and remembering that only the <var>CHANGE</var> statement can be used on <var>EXACTLY-ONE</var> fields) only the <var>CHANGE <i>fieldname</i> TO <i>%x</i></var> syntax will physically create an occurrence on the record. </p>


==The following Parameters and Commands relate to the Use of Table E==
==Parameters and commands relating 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.
'''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.
Line 47: Line 82:
|-
|-
|[[FILEORG parameter]]
|[[FILEORG parameter]]
|The file organisation
|The file organization
|}
|}


Line 54: Line 89:




[[Category:File Architecture and Management]]
[[Category:File architecture]]
[[Category:File Architecture]]

Latest revision as of 19:34, 22 May 2015

Holds Large Object data (BLOBs and CLOBs)

Storage and manipulation of Large Objects (LOBs) differs greatly depending on whether FILEORG X'100' is set for the file. This page discusses working with FILEORG X'100' files; for a parallel discussion of working with LOBs in files where FILEORG X'100' is not set, see Table E and non-FILEORG X'100' files (File architecture). For a summary of the differences between working with LOB data in files where FILEORG X'100' is set and files where it is not, see Table E (File architecture).

When the FILEORG X'100' bit is set on a file, you enable large object data storage by:

  1. Reorganizing or creating a file with ESIZE greater than 0.
  2. Defining one or more fields with an attribute of CLOB or BLOB. (The file must have an ESIZE for its fields to be defined as CLOB or BLOB.)

The FILEORG X'100' bit and its Table E effects are available as of Model 204 V7.5.

Summary

In a FILEORG X'100' file, all LOBs are chained. Storing chained LOBs has the following advantages over storing and accessing LOBs in non X'100' files:

  • Because the LOBs no longer need to be contiguous, space monitoring is simpler and Table E is less likely to fill up.
  • You can define fields so that "small" LOBs can be stored "locally" in the record (and so do not use an entire page in Table E). See Using the MINLOBE attribute.
  • You no longer need to predict (using the RESERVE clause) the size to which a LOB field might grow.

Storing Large Objects

Defining a field as a large object (LOB) using the BLOB or CLOB attribute stores a pointer in the record in Table B or Table X. Storage of the LOB value depends on the MINLOBE attribute and the length of the value being stored, as described below.

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 Table X depending on where the field is being added). The 27-byte descriptor contains the length of and a pointer to the Large Object data in the Table E page.

This descriptor is the same as in non X'100' files.

Storing a Large Object

When the length of the value being stored is 0 (a null string), the action taken depends on the "repeating" type (AT-MOST-ONE, REPEATABLE, and EXACTLY-ONE attributes) as 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, the value is stored directly in the record (Table B or Table X). Note that this value 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. The first (up to) 6140 bytes (4 bytes being reserved for the chain pointer) go on the first page, the next (up to) 6140 bytes go on the "next" page, and so on. These pages are not necessarily contiguous. Any pages emptied by LOB deletes are first reused before the pages at EHIGHPG are used.

Null strings and Large Objects

The STORE-DEFAULT (SD) and STORE-NULL (SN) attributes cannot be set on LOB fields like they can on other field types. This restriction results in LOB fields having the equivalent of the LITeral option. The following table illustrates the results when null strings are stored in Large Object fields:

Attribute Explicit null
fieldname = ' '
Implicit null
fieldname = %x (where %x is null)
No reference in code
EXACTLY-ONE (see Note, below) (see Note, below) (see Note, below)
AT-MOST-ONE field stored with null value not present not present
REPEATABLE field stored with null value not present not present

Note: The field will always act as if it is physically present (and return a null). However, EXACTLY-ONE fields react a bit differently depending on whether they are inside a field group or not. Inside a field group, all three operations will result in a field being present (as displayed in a PAI). Outside of field groups, (and remembering that only the CHANGE statement can be used on EXACTLY-ONE fields) only the CHANGE fieldname TO %x syntax will physically create an occurrence on the record.

Parameters and commands relating 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 organization