File Load utility: FLOD and FILELOAD commands: Difference between revisions
(51 intermediate revisions by 5 users not shown) | |||
Line 1: | Line 1: | ||
<p> | <div class="toclimit-3"> | ||
<p>These commands place the file in deferred update mode, in which updates to Tables C and D are deferred to deferred update data sets and are applied later to Tables C and D.</p> | <p> | ||
A <var>FLOD</var> or a <var>FILELOAD</var> command is followed by a series of file load statements that comprise the file load program. The program is terminated by an <var>END</var> statement, beginning in column 1.</p> | |||
<ul> | |||
<li>If you are doing a multistep File Load procedure, the <var>FLOD</var> command | |||
marks the beginning of a file load program.</li> | |||
<li>If you are doing a one-step procedure, use the <var>FILELOAD</var> command.</li> | |||
</ul> | |||
<p> | |||
These commands place the file in deferred update mode, in which updates to Tables C and D are deferred to deferred update data sets and are applied later to Tables C and D.</p> | |||
<blockquote class="note"> | |||
<b>Notes:</b> | |||
<ul> | |||
<li>For a site that is authorized for <var class="product">[[Fast/Reload]]</var>, the <var>FLOD</var> and <var>FILELOAD</var> commands are syntactically unchanged but invoke <var class="product">Fast/Reload</var>, which compiles and executes the <var>FLOD</var> and <var>FILELOAD</var> programs. </li> | |||
<li><var>[[FILEORG parameter|FILEORG]]</var> X'100' files cannot be loaded by <var>FLOD</var> or | |||
<var>FILELOAD</var> except with a <var class="product">Fast/Reload</var> Load All Information (<var>[[Fast/Reload statements#The LAI statement|LAI]]</var>) <var>FLOD/FILELOAD</var> program.</li> | |||
</ul> | |||
</blockquote> | |||
<br> | |||
===Including the FLOD or FILELOAD command in your run=== | ===Including the FLOD or FILELOAD command in your run=== | ||
<p>Include the FLOD or FILELOAD command and its associated file load program in the CCAIN data set, along with any other <var class="product">Model 204</var> commands needed to prepare the file for loading or to manipulate or check the data after loading.</p> | <p> | ||
<b>Note</b> | Include the <var>FLOD</var> or <var>FILELOAD</var> command and its associated file load program in the CCAIN data set, along with any other <var class="product">Model 204</var> commands needed to prepare the file for loading or to manipulate or check the data after loading.</p> | ||
<p class="note"><b>Note:</b> | |||
There can be only one <var>FLOD</var>, <var>FILELOAD</var>, or <var>Z</var> command specified in any given File Load job step. </p> | |||
===Getting information about a FLOD or FILELOAD run=== | ===Getting information about a FLOD or FILELOAD run=== | ||
<p>Some of the characteristics of the File Load run such as the number of records deleted or the number of fields added during the run are kept as counters that are printed at the end of the run. These counters are listed in [[#FLOD and FILELOAD command output|FLOD and FILELOAD command output]]. A histogram listing the distribution of deferred update record lengths along with the number of records for each range of lengths is also displayed for variable-length deferred update data sets. It can be used as an aid to setting the variable-length sort parameter, and is illustrated in | <p> | ||
Some of the characteristics of the File Load run such as the number of records deleted or the number of fields added during the run are kept as counters that are printed at the end of the run. These counters are listed in [[#FLOD and FILELOAD command output|FLOD and FILELOAD command output]]. A histogram listing the distribution of deferred update record lengths along with the number of records for each range of lengths is also displayed for variable-length deferred update data sets. It can be used as an aid to setting the variable-length sort parameter, and is illustrated in [[Deferred update feature#Setting the variable-length sort parameter (vl)|Setting the variable-length sort parameter (vl)]]. </p> | |||
==Double-checking your file load run== | ==Double-checking your file load run== | ||
<p>If you know how many records you are loading, you can use the | <p> | ||
If you know how many records you are loading, you can use the SOUL <var>FPC</var> (Find and Print Count) construct to ensure that all records have been loaded.</p> | |||
===Loading nondeferrable fields=== | ===Loading nondeferrable fields=== | ||
<p>If you are loading fields whose updates should not be deferred, it is not sufficient to specify the NON-DEFERRABLE attribute in order to override the deferral of updates for these fields. (In single-user File Load runs, the NON-DEFERRABLE attribute is ignored by <var class="product">Model 204</var>.) See | <p> | ||
If you are loading fields whose updates should not be deferred, it is not sufficient to specify the <var>NON-DEFERRABLE</var> attribute in order to override the deferral of updates for these fields. (In single-user File Load runs, the <var>NON-DEFERRABLE</var> attribute is ignored by <var class="product">Model 204</var>.) See [[Deferred update feature#Overriding deferred updates|Overriding deferred updates]] for a description of the techniques available to override deferred updates.</p> | |||
===Do not use RRN files in deferred update mode=== | ===Do not use RRN files in deferred update mode=== | ||
<p>Rocket Software suggests that you do not use deferred update mode with Reuse Record Number files except where you are performing simple record adds (such as reorganizing files). Doing so could cause you to lose updates without warning. See [[File design | <p> | ||
Rocket Software suggests that you do not use deferred update mode with <var>Reuse Record Number</var> files except where you are performing simple record adds (such as reorganizing files). Doing so could cause you to lose updates without warning. See [[File design#RRN files and deferred update_mode|RRN files and deferred update mode]] for more information.</p> | |||
==FLOD command== | ==FLOD command== | ||
<p>The FLOD command marks the beginning of a file load program. This command is followed by the file load statements described starting on [[#File Load statements: overview|File Load statements: overview]]. The procedure ends with the word END, beginning in column 1.</p> | <p> | ||
The <var>FLOD</var> command marks the beginning of a file load program. This command is followed by the file load statements described starting on [[#File Load statements: overview|File Load statements: overview]]. The procedure ends with the word <var>END</var>, beginning in column 1.</p> | |||
===Syntax=== | ===Syntax=== | ||
<p class=" | <p> | ||
</ | The format of the <var>FLOD</var> command is:</p> | ||
<p class="syntax">FLOD <span class="term">k,n,m</span> | |||
. | |||
. | . | ||
. | . | ||
END | END | ||
</p> | </p> | ||
< | <p> | ||
Where: </p> | |||
<ul> | <ul> | ||
<li>If k is -1, FLOD loads all records into the <var class="product">Model 204</var> file.</li> | <li><var class="term">k</var> specifies the maximum number of records to be loaded into the <var class="product">Model 204</var> file: | ||
<li>If k is any negative number except -1, the number is converted into a 32-bit unsigned number, <var>N,</var> and <var>N</var> records are processed. </li> | <ul> | ||
</ul> | <li>If <var class="term">k</var> is -1, <var>FLOD</var> loads all records into the <var class="product">Model 204</var> file.</li> | ||
< | |||
<li>If <var class="term">k</var> is any negative number except -1, the number is converted into a 32-bit unsigned number, <var>N,</var> and <var>N</var> records are processed. </li> | |||
</ul></li> | |||
<li><var class="term">n</var> specifies the maximum number of times the statements in the file load program are to be executed: | |||
<ul> | <ul> | ||
<li>If n is 0, the FLOD or FILELOAD code is compiled, but is <var class="term">not</var> executed. </li> | <li>If <var class="term">n</var> is 0, the <var>FLOD</var> or <var>FILELOAD</var> code is compiled, but is <var class="term">not</var> executed. </li> | ||
<li>If n is -1, FLOD keeps making passes through the code until the process is stopped by another condition (such as EOF)</li> | |||
</ul> | <li>If <var class="term">n</var> is -1, <var>FLOD</var> keeps making passes through the code until the process is stopped by another condition (such as EOF)</li> | ||
< | </ul></li> | ||
<li><var class="term">m</var> specifies the number of input records to skip before starting the File Load process, which is helpful for breaking up the load process so that dumps (backups) can be taken during large loads: | |||
<ul> | <ul> | ||
<li>If m is -1, all records are skipped.</li> | <li>If <var class="term">m</var> is -1, all records are skipped.</li> | ||
<li>If m is any negative number except -1, the number is converted into a 32-bit unsigned number, < | |||
<li>If <var class="term">m</var> is any negative number except -1, the number is converted into a 32-bit unsigned number, <code>N</code>, and <var>FLOD</var> skips <code>N</code> records before processing begins.</li> | |||
</ul></li> | |||
</ul> | </ul> | ||
===Usage=== | ===Usage=== | ||
<p>Each time the END statement is encountered during execution, <var class="product">Model 204</var> begins again with the first statement following the FLOD command. The procedure continues to execute until one of the following occurs:</p> | <p> | ||
Each time the <var>END</var> statement is encountered during execution, <var class="product">Model 204</var> begins again with the first statement following the <var>FLOD</var> command. The procedure continues to execute until one of the following occurs:</p> | |||
<ul> | <ul> | ||
<li>All the records in the input data set have been processed.</li> | <li>All the records in the input data set have been processed.</li> | ||
Line 51: | Line 89: | ||
<li><var class="term">n</var> passes have been made through the file load program. </li> | <li><var class="term">n</var> passes have been made through the file load program. </li> | ||
</ul> | </ul> | ||
<p>Thus, either <var class="term">k</var> or <var class="term">n</var> can be used to limit File Load processing and to load only a sample of the data. </p> | <p> | ||
<p>To process all the input records, set both <var class="term">k</var> and <var class="term">n</var> to -1. </p> | Thus, either <var class="term">k</var> or <var class="term">n</var> can be used to limit File Load processing and to load only a sample of the data. </p> | ||
===Example=== | <p> | ||
<p>The following | To process all the input records, set both <var class="term">k</var> and <var class="term">n</var> to -1. </p> | ||
<p class="code">FLOD -1,-1,0 | |||
====Example==== | |||
<p> | |||
The following command specifies that all input records be processed starting with the first record (that is, skip 0 records):</p> | |||
<p class="code">FLOD -1,-1, 0 | |||
</p> | </p> | ||
==FILELOAD command== | ==FILELOAD command== | ||
<p>To perform a one-step file load, use the FILELOAD command to mark the beginning of a file load program. This command is followed by the file load statements described starting on [[#File Load statements: overview|File Load statements: overview]]. The procedure ends with the word END, beginning in column 1.</p> | <p> | ||
To perform a one-step file load, use the <var>FILELOAD</var> command to mark the beginning of a file load program. This command is followed by the file load statements described starting on [[#File Load statements: overview|File Load statements: overview]]. The procedure ends with the word <var>END</var>, beginning in column 1.</p> | |||
===FILELOAD command processing=== | ===FILELOAD command processing=== | ||
<p>The FILELOAD command attaches one or two sort subtasks to do the sorting required to load index and FRV entries efficiently. These subtasks run asynchronously with <var class="product">Model 204</var> (except under z/VM, which does not support true subtasking). Two buffers are used for the sorts. <var class="product">Model 204</var> fills the second buffer while the sort is emptying the first. After the records are sorted, the same double-buffering mechanism is used to pass the records back to <var class="product">Model 204</var>. | <p> | ||
The <var>FILELOAD</var> command attaches one or two sort subtasks to do the sorting required to load index and <var>FRV</var> entries efficiently. These subtasks run asynchronously with <var class="product">Model 204</var> (except under z/VM, which does not support true subtasking). Two buffers are used for the sorts. <var class="product">Model 204</var> fills the second buffer while the sort is emptying the first. After the records are sorted, the same double-buffering mechanism is used to pass the records back to <var class="product">Model 204</var>.</p> | |||
====Syntax==== | ====Syntax==== | ||
<p class=" | <p> | ||
The complete format of the <var>FILELOAD</var> command is:</p> | |||
<p class="syntax">FILELOAD <span class="term">k,n,m</span> [,[<span class="term">s1</span>] [,[<span class="term">s2</span>] [,[<span class="term">s3</span>] [,[<span class="term">s4</span>] [,<span class="term">vl</span>]]]]] | |||
. | . | ||
. | . | ||
Line 72: | Line 118: | ||
END | END | ||
</p> | </p> | ||
<p> | <p> | ||
< | Where:</p> | ||
<ul> | |||
<li><var class="term">k</var>, <var class="term">n</var>, and <var class="term">m</var> have the meanings described for the <var>FLOD</var> command in [[#FLOD command|FLOD command]], above.</li> | |||
< | <li><var class="term">s1</var> represents the amount of memory that the sort package uses for sorting the deferred update index records produced by the file load program. If <var class="term">s1</var> is omitted or is not a positive integer, a default value of 50,000 bytes (64K for z/VM) is used for the sort work space. | ||
<p>s2 represents the amount of memory used for sorting the deferred update FRV index records. If <var class="term">s2</var> is omitted or is not a positive integer, a default value of 50,000 bytes (64K for z/VM) is used. For 3380 disk drives the minimum values for <var class="term">s1</var> and <var class="term">s2</var> are 64,000 bytes.</ | <p class="note"><b>Note:</b> Make the <var class="term">s1</var> parameter as large as possible, especially for sorts involving many records. It is important to increase <var class="term">s1</var> for large sorts. </p></li> | ||
< | |||
< | <li><var class="term">s2</var> represents the amount of memory used for sorting the deferred update <var>FRV</var> index records. If <var class="term">s2</var> is omitted or is not a positive integer, a default value of 50,000 bytes (64K for z/VM) is used. For 3380 disk drives the minimum values for <var class="term">s1</var> and <var class="term">s2</var> are 64,000 bytes.</li> | ||
< | |||
<li><var class="term">s3</var> represents the amount of memory allocated for the two buffers used to pass data from <var class="product">Model 204</var> to the sorts. This parameter specifies the combined size of the two buffers. The core specified in <var class="term">s3</var> is evenly divided between the two buffers, and the default value of <var class="term">s3</var> is 8000 bytes. The minimum value accepted is 48 bytes, but such a small size is not recommended. A larger value of <var class="term">s3</var> can produce a noticeable performance improvement. However, increasing <var class="term">s1</var> normally has a greater effect on performance than a corresponding increase in <var class="term">s3</var>.</li> | |||
<li><var class="term">s4</var> represents the amount of memory allocated for the two buffers used to pass data from the sorts to <var class="product">Model 204</var>. <var class="term">s4</var> is ordinarily equal in size to <var class="term">s3</var> and is set equal to <var class="term">s3</var> by default.</li> | |||
<li><var class="term">vl</var> specifies the maximum sort record length in variable-length record sorts. (<var class="term">vl</var> corresponds to the <var>L2</var> of the <var>RECORD</var> sort statement.) | |||
<p> | |||
The <var class="term">vl</var> parameter is required when <var>ORDERED</var> fields are updated by the file load program. For efficiency, do not use the <var class="term">vl</var> parameter if <var>ORDERED</var> fields are not updated. For more information about the <var class="term">vl</var> parameter and how to select a value for it, see [[Deferred update feature#Setting the variable-length sort parameter (vl)|Setting the variable-length sort parameter (vl)]]. </p></li> | |||
</ul> | |||
====Examples==== | ====Examples==== | ||
<p>To specify a value for <var class="term">s2</var>, but not <var class="term">s1</var>, supply two consecutive commas before <var class="term">s2</var>, as follows:</p> | <p> | ||
To specify a value for <var class="term">s2</var>, but not <var class="term">s1</var>, supply two consecutive commas before <var class="term">s2</var>, as follows:</p> | |||
<p class="code">FILELOAD <var class="term">k,n,m,,s2,s3,s4</var> | <p class="code">FILELOAD <var class="term">k,n,m,,s2,s3,s4</var> | ||
</p> | </p> | ||
<p>The same technique can be used to specify values for <var class="term">s3</var>, <var class="term">s4</var>, and <var class="term">vl</var>. For example:</p> | <p> | ||
The same technique can be used to specify values for <var class="term">s3</var>, <var class="term">s4</var>, and <var class="term">vl</var>. For example:</p> | |||
<p class="code">FILELOAD <var class="term">k,n,m,,,,,vl</var> | <p class="code">FILELOAD <var class="term">k,n,m,,,,,vl</var> | ||
</p> | </p> | ||
<p>Alternatively, specify a zero or negative value for <var class="term">s1</var> and allow the system to supply the default. The same technique can be used to specify values for <var class="term">s2</var>, <var class="term">s3</var>, and <var class="term">s4</var>. For example:</p> | <p> | ||
Alternatively, specify a zero or negative value for <var class="term">s1</var> and allow the system to supply the default. The same technique can be used to specify values for <var class="term">s2</var>, <var class="term">s3</var>, and <var class="term">s4</var>. For example:</p> | |||
<p class="code">FILELOAD <var class="term">k,n,m,</var>0,-1,-2,-3,<var class="term">vl</var> | <p class="code">FILELOAD <var class="term">k,n,m,</var>0,-1,-2,-3,<var class="term">vl</var> | ||
</p> | </p> | ||
===FILELOAD error reporting=== | ===FILELOAD error reporting=== | ||
<p>If a serious problem arises while the FILELOAD command is running, the user is restarted. A message is issued reporting the completion codes issued by the sorts. The message is:</p> | <p> | ||
<p class="code"><b></b>*** M204.0760: SORT RETURN CODES - SORT 1: <var class="term">xxxxxx</var>, | If a serious problem arises while the <var>FILELOAD</var> command is running, the user is restarted. A message is issued reporting the completion codes issued by the sorts. The message is:</p> | ||
<p class="code"><b></b>*** M204.0760: SORT RETURN CODES - SORT 1: <var class="term">xxxxxx</var>, SORT 2: <var class="term">xxxxxx</var> | |||
</p> | </p> | ||
<p>The completion codes issued by the sorts (<var class="term">xxxxxx</var>) are reported as | <p> | ||
The completion codes issued by the sorts (<var class="term">xxxxxx</var>) are reported as six hexadecimal digits. The first three digits are the subtask system completion code, such as <code>0C4</code>. The last three digits are the user completion code, such as <code>010</code> (which is a decimal 16). These completion codes can be useful in determining whether a problem is in <var class="product">Model 204</var> or is in the sort package itself.</p> | |||
==FLOD and FILELOAD command output== | ==FLOD and FILELOAD command output== | ||
<p>After the file load program has completed, the following counters are displayed: </p> | <p> | ||
After the file load program has completed, the following counters are displayed: </p> | |||
<table> | <table> | ||
<tr class="head"> | <tr class="head"> | ||
Line 109: | Line 168: | ||
<th>Displays the number of... </th> | <th>Displays the number of... </th> | ||
</tr> | </tr> | ||
<tr> | <tr> | ||
<td>RECORDS | <td nowrap>RECORDS READ </td> | ||
<td>Records read from the TAPEI (input) data set, including those skipped by the FLOD or FILELOAD command</td> | <td>Records read from the TAPEI (input) data set, including those skipped by the <var>FLOD</var> or <var>FILELOAD</var> command</td> | ||
</tr> | </tr> | ||
<tr> | <tr> | ||
<td>ADDS </td> | <td>ADDS </td> | ||
<td>New <var class="product">Model 204</var> records begun</td> | <td>New <var class="product">Model 204</var> records begun</td> | ||
</tr> | </tr> | ||
<tr> | <tr> | ||
<td>DELETES </td> | <td>DELETES </td> | ||
<td><var class="product">Model 204</var> records deleted</td> | <td><var class="product">Model 204</var> records deleted</td> | ||
</tr> | </tr> | ||
<tr> | <tr> | ||
<td>AF </td> | <td>AF </td> | ||
<td>Fields added</td> | <td>Fields added</td> | ||
</tr> | </tr> | ||
<tr> | <tr> | ||
<td>DF </td> | <td>DF </td> | ||
<td>Fields deleted (not including those deleted through a DELETE command) | <td>Fields deleted (not including those deleted through a <var>DELETE</var> command) </td> | ||
</tr> | </tr> | ||
</table> | </table> | ||
<p>These counters can help you ensure that you have added, deleted, or changed all the records that you intended to. </p> | <p> | ||
These counters can help you ensure that you have added, deleted, or changed all the records that you intended to. </p> | |||
==File Load statements: overview== | ==<b id="stmts"></b>File Load statements: overview== | ||
<p><var class="product">Model 204</var> provides several File Load statements that are elements of a separate File Load language.</p> | <p> | ||
<p>The file load language provides limited programming capability. If complicated edits or large amounts of data manipulation are required, consider using FLOD | <var class="product">Model 204</var> provides several File Load statements that are elements of a separate File Load language.</p> | ||
<p>All File Load statements follow the FILELOAD command.</p> | <p> | ||
<p>See the following sections for details:</p> | The file load language provides limited programming capability. If complicated edits or large amounts of data manipulation are required, consider using <var>FLOD</var> exits, a preprocessing program, or a host language or SOUL program to load the file. </p> | ||
<p> | |||
All File Load statements follow the <var>FILELOAD</var> command.</p> | |||
<p> | |||
See the following sections for details:</p> | |||
<ul> | <ul> | ||
<li>[[#File Load statements: mode bits|File Load statements: mode bits]]</li> | <li>[[#File Load statements: mode bits|File Load statements: mode bits]]</li> | ||
Line 142: | Line 211: | ||
<li>[[#File Load statements: manipulating data areas with string buffers|File Load statements: manipulating data areas with string buffers]]</li> | <li>[[#File Load statements: manipulating data areas with string buffers|File Load statements: manipulating data areas with string buffers]]</li> | ||
<li>[[#File Load statements: working with index registers|File Load statements: working with index registers]]</li> | <li>[[#File Load statements: working with index registers|File Load statements: working with index registers]]</li> | ||
<li>[[#File Load statements: | <li>[[#File Load statements: updating existing Model 204 records|File Load statements: updating existing Model 204 records]]</li> | ||
<li>[[#File Load statements: | <li>[[#File Load statements: deleting records and fields|File Load statements: deleting records and fields]]</li> | ||
</ul> | </ul> | ||
===File Load statement summary=== | ===File Load statement summary=== | ||
<p>See [[#Syntax of File Load statements|Syntax of File Load statements]] for a complete summary of all statements in the File Load language.</p> | <p> | ||
See [[#Syntax of File Load statements|Syntax of File Load statements]] for a complete summary of all statements in the File Load language.</p> | |||
==File Load statements: mode bits== | ==File Load statements: mode bits== | ||
<p>Many of the statements described in the next sections use mode bits. These mode bits allow you to specify various options that are discussed here. Most options can be summed.</p> | <p> | ||
<b>Note</b> | Many of the statements described in the next sections use mode bits. These mode bits allow you to specify various options that are discussed here. Most options can be summed.</p> | ||
<p class="note"><b>Note:</b> | |||
If numeric sequence numbers are present, you must specify mode bits.</p> | |||
===Mode bits summary=== | ===Mode bits summary=== | ||
Line 160: | Line 231: | ||
<th>Meaning</th> | <th>Meaning</th> | ||
</tr> | </tr> | ||
<tr> | <tr> | ||
<td align="right">X'8000'</td> | <td align="right">X'8000'</td> | ||
<td>Begin a new <var class="product">Model 204</var> record.</td> | <td>Begin a new <var class="product">Model 204</var> record.</td> | ||
</tr> | </tr> | ||
<tr> | <tr> | ||
<td align="right">X'4000'</td> | <td align="right">X'4000'</td> | ||
<td>Delete a field</td> | <td>Delete a field</td> | ||
</tr> | </tr> | ||
<tr> | <tr> | ||
<td align="right">X'2000'</td> | <td align="right">X'2000'</td> | ||
<td>Sort or hash key omitted (specified with X'8000')</td> | <td>Sort or hash key omitted (specified with X'8000')</td> | ||
</tr> | </tr> | ||
<tr> | <tr> | ||
<td align="right">X'1000'</td> | <td align="right">X'1000'</td> | ||
<td>Delete first occurrence of field</td> | <td>Delete first occurrence of field</td> | ||
</tr> | </tr> | ||
<tr> | <tr> | ||
<td align="right">X'0800'</td> | <td align="right">X'0800'</td> | ||
<td>Suppress deletion of blanks</td> | <td>Suppress deletion of blanks</td> | ||
</tr> | </tr> | ||
<tr> | <tr> | ||
<td align="right">X'0400'</td> | <td align="right">X'0400'</td> | ||
<td>Translate numeric codes</td> | <td>Translate numeric codes</td> | ||
</tr> | </tr> | ||
<tr> | <tr> | ||
<td align="right">X'0200'</td> | <td align="right">X'0200'</td> | ||
<td>Load all-zero fields as '0'</td> | <td>Load all-zero fields as '0'</td> | ||
</tr> | </tr> | ||
<tr> | <tr> | ||
<td align="right">X'0100'</td> | <td align="right">X'0100'</td> | ||
<td>Strip leading zeroes</td> | <td>Strip leading zeroes</td> | ||
</tr> | </tr> | ||
<tr> | <tr> | ||
<td align="right">X'0080'</td> | <td align="right">X'0080'</td> | ||
Line 199: | Line 279: | ||
===Begin a new Model 204 record (X'8000')=== | ===Begin a new Model 204 record (X'8000')=== | ||
<p>Mode bit X'8000' causes a new <var class="product">Model 204</var> record to be started. More than one <var class="product">Model 204</var> record can begin on each pass through a file load program. </p> | <p> | ||
<p>For example, suppose that the input statements for the following example each contained data for two people, with one person's data starting in column 1 and the other's in column 41. The file load program might look like this:</p> | Mode bit X'8000' causes a new <var class="product">Model 204</var> record to be started. More than one <var class="product">Model 204</var> record can begin on each pass through a file load program. </p> | ||
<p> | |||
For example, suppose that the input statements for the following example each contained data for two people, with one person's data starting in column 1 and the other's in column 41. The file load program might look like this:</p> | |||
<p class="code">FLOD 5000,5000,0 | <p class="code">FLOD 5000,5000,0 | ||
G | G | ||
Line 213: | Line 295: | ||
END | END | ||
</p> | </p> | ||
<p>The X'8000' mode bit begins a new record even if the field turns out to be all blank, and is not actually stored in the new record (that is, it is possible to have a <var class="product">Model 204</var> record that has no fields).</p> | <p> | ||
The X'8000' mode bit begins a new record even if the field turns out to be all blank, and is not actually stored in the new record (that is, it is possible to have a <var class="product">Model 204</var> record that has no fields).</p> | |||
===Delete a field (X'4000')=== | ===Delete a field (X'4000')=== | ||
<p>The X'4000' mode bit deletes one field. It is used in conjunction with the read-and-load-a-field statement, as follows:</p> | <p> | ||
The X'4000' mode bit deletes one field. It is used in conjunction with the read-and-load-a-field statement, as follows:</p> | |||
<p class="code"><var class="term">fieldname</var><b></b>=<var class="term">position</var>,<var class="term">length</var>,X'4000' | <p class="code"><var class="term">fieldname</var><b></b>=<var class="term">position</var>,<var class="term">length</var>,X'4000' | ||
</p> | </p> | ||
<p>For more information see [[#File Load statements: | <p> | ||
For more information see [[#File Load statements: deleting records and fields|File Load statements: deleting records and fields]].</p> | |||
===Sort or hash key omitted (X'2000')=== | ===Sort or hash key omitted (X'2000')=== | ||
<p>The X'2000' mode bit allows you to specify that a record in a sort or hash key file does not have a sort or hash key. This mode bit can be used in conjunction with the X'8000' mode bit when reorganizing sort or hash key files. For more information, see | <p> | ||
The X'2000' mode bit allows you to specify that a record in a sort or hash key file does not have a sort or hash key. This mode bit can be used in conjunction with the X'8000' mode bit when reorganizing sort or hash key files. For more information, see [[File reorganization and table compaction#Reorganizing sorted and hash key files|Reorganizing sorted and hash key files]].</p> | |||
===Delete first occurrence of field (X'1000')=== | ===Delete first occurrence of field (X'1000')=== | ||
<p>The X'1000' mode bit, when combined with the X'4000' and X'0800' mode bits, allows you to delete a specific value from a record. Use the X'4000' mode bit to delete INVISIBLE or VISIBLE fields; the value of the INVISIBLE field must be specified. Use the combined mode bit X'5800' to delete specific values in multiply occurring visible fields. See [[#Deleting a VISIBLE field|Deleting a VISIBLE field]] and [[#Deleting specific values|Deleting specific values]] for more information.</p> | <p> | ||
The X'1000' mode bit, when combined with the X'4000' and X'0800' mode bits, allows you to delete a specific value from a record. Use the X'4000' mode bit to delete <var>INVISIBLE</var> or <var>VISIBLE</var> fields; the value of the <var>INVISIBLE</var> field must be specified. Use the combined mode bit X'5800' to delete specific values in multiply occurring visible fields. See [[#Deleting a VISIBLE field|Deleting a VISIBLE field]] and [[#Deleting specific values|Deleting specific values]] for more information.</p> | |||
===Suppress blank deletion (X'0800')=== | ===Suppress blank deletion (X'0800')=== | ||
<p>Unless suppressed with mode bit X'0800', the File Load utility automatically deletes leading and trailing blanks from the value string. </p> | <p> | ||
Unless suppressed with mode bit X'0800', the File Load utility automatically deletes leading and trailing blanks from the value string. </p> | |||
===Translate numeric codes (X'0400')=== | ===Translate numeric codes (X'0400')=== | ||
<p>Input data sometimes contains information in a coded format. For instance, in the example at the beginning of the section, the department field is expressed as a two-digit code to save space on the input line. The File Load utility can store this code as is. However, if the code is a simple numeric code ranging upwards from 0, you can provide a translation table, using mode bit X'0400', following the read-and-load-a-field statement to convert these codes into full departmental names. | <p> | ||
<p>The following sample statement translates and stores a department code:</p> | Input data sometimes contains information in a coded format. For instance, in the example at the beginning of the section, the department field is expressed as a two-digit code to save space on the input line. The File Load utility can store this code as is. However, if the code is a simple numeric code ranging upwards from 0, you can provide a translation table, using mode bit X'0400', following the read-and-load-a-field statement to convert these codes into full departmental names. </p> | ||
<p> | |||
The following sample statement translates and stores a department code:</p> | |||
<p class="code">DEPT=24,2,X'0400' | <p class="code">DEPT=24,2,X'0400' | ||
= * Code 0 | = * Code 0 | ||
Line 240: | Line 330: | ||
DATA PROCESSING= * Code 4 | DATA PROCESSING= * Code 4 | ||
= * Code 5 | = * Code 5 | ||
MEN'S CLOTHING= | MEN'S CLOTHING= * Code 6 | ||
WOMEN'S CLOTHING= | WOMEN'S CLOTHING= * Code 7 | ||
NOTIONS= | NOTIONS= | ||
SPORTSWEAR= | SPORTSWEAR= | ||
Line 248: | Line 338: | ||
. | . | ||
</p> | </p> | ||
<p>An input line having '06' in columns 24 and 25 causes the field DEPT=MEN'S CLOTHING to be stored in the new record.</p> | <p> | ||
An input line having '06' in columns 24 and 25 causes the field <code>DEPT=MEN'S CLOTHING</code> to be stored in the new record.</p> | |||
====Creating translation tables==== | ====Creating translation tables==== | ||
<p>To create a translation table:</p> | <p> | ||
To create a translation table:</p> | |||
<ol> | <ol> | ||
<li>Specify mode bit X'0400' on the read-and-load-a-field statement.</li> | <li>Specify mode bit X'0400' on the read-and-load-a-field statement.</li> | ||
<li>Enter the value strings for codes 0 through <var class="term">n</var> on the next <var class="term">n</var>+1 lines, each starting in column 2 and immediately followed by an equal sign (=). If a particular code is not used, represent it with a line having only an equal sign in column 2 (like codes 00 and 05 in the above example).</li> | |||
<li>Enter the value strings for codes 0 through <var class="term">n</var> on the next <var class="term">n</var>+1 lines, each starting in column 2 and immediately followed by an equal sign (<tt>=</tt>). If a particular code is not used, represent it with a line having only an equal sign in column 2 (like codes 00 and 05 in the above example).</li> | |||
<li>Signal the end of the translation table with a line that contains a period in column 1. </li> | <li>Signal the end of the translation table with a line that contains a period in column 1. </li> | ||
</ol> | </ol> | ||
====Rules for translation tables==== | ====Rules for translation tables==== | ||
<p>The code in the data area of the input record must be an EBCDIC character representation of a decimal number. A plus sign (+) is permitted; blanks are not.</p> | <p> | ||
<p>Translation does not occur and the code itself is stored as the field value in the current <var class="product">Model 204</var> record under the following circumstances: </p> | The code in the data area of the input record must be an EBCDIC character representation of a decimal number. A plus sign (<tt>+</tt>) is permitted; blanks are not.</p> | ||
<p> | |||
Translation does not occur and the code itself is stored as the field value in the current <var class="product">Model 204</var> record under the following circumstances: </p> | |||
<ul> | <ul> | ||
<li>Data area does not contain a correct positive numeric code.</li> | <li>Data area does not contain a correct positive numeric code.</li> | ||
Line 266: | Line 362: | ||
<li>Code corresponds to a line for which no value is specified.</li> | <li>Code corresponds to a line for which no value is specified.</li> | ||
</ul> | </ul> | ||
<b>Note</b> | <p class="note"><b>Note:</b> | ||
Do not confuse numeric codes in the input data with the <var>CODED</var> field type option of <var class="product">Model 204</var> files. <var>CODED</var> fields affect only the internal storage of the field value and are virtually transparent to the end-user.</p> | |||
====Using multiple translation table entries on a single line==== | ====Using multiple translation table entries on a single line==== | ||
<p> | <p>Yo | ||
u can place more than one translation table entry on a single line using the following rules:</p> | |||
<ul> | <ul> | ||
<li>Value for one entry must immediately follow the equal sign for the preceding entry. </li> | <li>Value for one entry must immediately follow the equal sign for the preceding entry. </li> | ||
Line 277: | Line 374: | ||
<li>Period ending the table must always appear on a line by itself.</li> | <li>Period ending the table must always appear on a line by itself.</li> | ||
</ul> | </ul> | ||
<p>The previous example can be written:</p> | <p> | ||
The previous example can be written:</p> | |||
<p class="code">DEPT=24,2,X'0400' | <p class="code">DEPT=24,2,X'0400' | ||
<b></b>=ACCOUNTING=PERSONNEL=PURCHASING= | <b></b>=ACCOUNTING=PERSONNEL=PURCHASING= | ||
Line 287: | Line 385: | ||
====Loading a constant field using a translation table==== | ====Loading a constant field using a translation table==== | ||
<p>At times, you might want to specify a field to add to a <var class="product">Model 204</var> record rather than taking a value from the input record. To do this, write a read-and-load-a-field statement that specifies a position and length of zero and a translation table that has one entry:</p> | <p> | ||
At times, you might want to specify a field to add to a <var class="product">Model 204</var> record rather than taking a value from the input record. To do this, write a read-and-load-a-field statement that specifies a position and length of zero and a translation table that has one entry:</p> | |||
<p class="code"><var class="term">fieldname</var><b></b>=0,0,X'0400' | <p class="code"><var class="term">fieldname</var><b></b>=0,0,X'0400' | ||
<var class="term">value</var><b></b>= | <var class="term">value</var><b></b>= | ||
. | . | ||
</p> | </p> | ||
<p>Position zero is a special case that makes no reference to the current input record. For example, if the personnel records for more than one company are kept in the PEOPLE file, the records for each company can be loaded in separate File Load runs.</p> | <p> | ||
<p>For a particular run, the following example adds the field COMPANY = Rocket to every record loaded during that run:</p> | Position zero is a special case that makes no reference to the current input record. For example, if the personnel records for more than one company are kept in the <code>PEOPLE</code> file, the records for each company can be loaded in separate File Load runs.</p> | ||
<p> | |||
For a particular run, the following example adds the field <code>COMPANY=Rocket</code> to every record loaded during that run:</p> | |||
<p class="code">COMPANY=0,0,X'0400' | <p class="code">COMPANY=0,0,X'0400' | ||
Rocket= | Rocket= | ||
Line 300: | Line 401: | ||
===Load zero fields as '0' (X'0200')=== | ===Load zero fields as '0' (X'0200')=== | ||
<p>Mode bit X'0200' loads all-zero fields as '0'. This option is valid only if used in conjunction with mode bit X'0100' (strip leading zeroes). Use mode bits X'0100' and X'0200' together to strip leading zeroes, but to ensure that a field containing all zeros is stored as '0'. This is useful when a zero field and a missing field have different meanings in the database. </p> | <p> | ||
Mode bit X'0200' loads all-zero fields as '0'. This option is valid only if used in conjunction with mode bit X'0100' (strip leading zeroes). Use mode bits X'0100' and X'0200' together to strip leading zeroes, but to ensure that a field containing all zeros is stored as '0'. This is useful when a zero field and a missing field have different meanings in the database. </p> | |||
===Strip leading zeros (X'0100')=== | ===Strip leading zeros (X'0100')=== | ||
<p>To compress values, you can strip all leading zeroes from certain field values before they are loaded into the <var class="product">Model 204</var> file using mode bit X'0100'. If a field contains all zeroes, it is stripped completely and is not stored. Unless blank deletion is suppressed, blanks are stripped before zeroes. </p> | <p> | ||
To compress values, you can strip all leading zeroes from certain field values before they are loaded into the <var class="product">Model 204</var> file using mode bit X'0100'. If a field contains all zeroes, it is stripped completely and is not stored. Unless blank deletion is suppressed, blanks are stripped before zeroes. </p> | |||
===Read and load floating-point data (X'0080')=== | ===Read and load floating-point data (X'0080')=== | ||
<p>Mode bit X'0080' indicates that the incoming data contains floating- point input. If the field to be loaded is not FLOAT, the field value is converted to a character string for storage. If the field is FLOAT, the value is stored with no conversion. </p> | <p> | ||
<p>With the mode bit turned off, character string input to a FLOAT field is converted to a floating-point value, if possible. Exponent format input is converted to numeric form for storage in FLOAT fields, and is left unconverted for non-FLOAT fields.</p> | Mode bit X'0080' indicates that the incoming data contains floating- point input. If the field to be loaded is not <var>FLOAT</var>, the field value is converted to a character string for storage. If the field is <var>FLOAT</var>, the value is stored with no conversion. </p> | ||
<p>Floating-point format input to a FLOAT field is stored without conversion, but might be truncated or rounded, depending on its length. For more information about storing values in floating-point fields | <p> | ||
With the mode bit turned off, character string input to a <var>FLOAT</var> field is converted to a floating-point value, if possible. Exponent format input is converted to numeric form for storage in <var>FLOAT</var> fields, and is left unconverted for non-<var>FLOAT</var> fields.</p> | |||
<p> | |||
Floating-point format input to a <var>FLOAT</var> field is stored without conversion, but might be truncated or rounded, depending on its length. For more information about storing values in floating-point fields, see [[Floating point conversion, rounding, and precision rules]]. </p> | |||
==File Load statements: loading a new Model 204 file== | ==File Load statements: loading a new Model 204 file== | ||
<p>The statements that can be used in a file load program are summarized here. Most file load statements are sensitive to the column in which they begin; note the specifications carefully. | <p> | ||
<b>Note</b> | The statements that can be used in a file load program are summarized here, with the exceptions of the <var>[[Fast/Reload statements#The OPTIONS statement|OPTIONS]]</var> and <var>[[Fast/Reload statements#The LAI statement|LAI]]</var> statements, which are valid only if [[Fast/Reload]] is authorized at your site. In addition, those of the statements summarized here that are not valid for Fast/Reload are so noted.</p> | ||
<p> | |||
Most file load statements are sensitive to the column in which they begin; note the specifications carefully. </p> | |||
<p class="note"><b>Note:</b> | |||
The file load statements use the vertical bar (<tt>|</tt>) character (that is, the character that has the hexadecimal value X'4F'). If the vertical bar is not available on the terminal being used for the File Load run, use the up-arrow (<tt>↑</tt>) or caret (<tt>^</tt>) instead. The broken vertical bar symbol available on some ASCII terminals is not equivalent to the vertical bar. Use the up-arrow or caret for these terminals.</p> | |||
===G (go to the next logical record) statement=== | ===G (go to the next logical record) statement=== | ||
<p>The G statement consists simply of the letter G in column 1. This statement causes the next logical record of the input data set to be positioned for processing. </p> | <p> | ||
The <var>G</var> statement consists simply of the letter <code>G</code> in column 1. This statement causes the next logical record of the input data set to be positioned for processing. </p> | |||
====Syntax==== | |||
<p class="syntax">G | <p class="syntax">G | ||
</p> | </p> | ||
<p>Various other file load statements can then refer to the data in the input record by specifying a relative position within the record. If the input records are of fixed or undefined length (RECFM = F, FB, or U), the data starts in position 1. If the records are of variable length (RECFM = V or VB), the data starts in position 5, and the binary length of the data is in positions 1 and 2.</p> | <p> | ||
<p>If no more input records remain, the file load program terminates and <var class="product">Model 204</var> goes on to the command that follows the END statement.</p> | Various other file load statements can then refer to the data in the input record by specifying a relative position within the record. If the input records are of fixed or undefined length (RECFM = F, FB, or U), the data starts in position 1. If the records are of variable length (RECFM = V or VB), the data starts in position 5, and the binary length of the data is in positions 1 and 2.</p> | ||
<p> | |||
If no more input records remain, the file load program terminates and <var class="product">Model 204</var> goes on to the command that follows the <var>END</var> statement.</p> | |||
===* statement (comment line)=== | ===* statement (comment line)=== | ||
<p>Comment lines can be inserted anywhere in the file load program. Comment lines must have an asterisk in column 1.</p> | <p>Comment lines can be inserted anywhere in the file load program. Comment lines must have an asterisk in column 1.</p> | ||
====Syntax==== | |||
<p class="syntax"><b></b>* This is a comment | <p class="syntax"><b></b>* This is a comment | ||
</p> | </p> | ||
===Read-and-load-a-field statement=== | ===<b id="rdLoadStmt"></b>Read-and-load-a-field statement=== | ||
<p>The read-and-load-a-field statement stores a field (in a <var class="product">Model 204</var> record) that contains the specified field name and a value extracted from the specified positions of the current input record. </p> | <p> | ||
The read-and-load-a-field statement stores a field (in a <var class="product">Model 204</var> record) that contains the specified field name and a value extracted from the specified positions of the current input record. </p> | |||
====Read-and-load-a-field statement processing==== | ====Read-and-load-a-field statement processing==== | ||
<p>Before the value is stored, leading and trailing blanks are deleted from it for the sake of space saving and uniformity. (In retrieval specifications, <var class="product">Model 204</var> considers 'MALE' and 'MALE ' to be separate and distinct values.) Internal blanks are not changed in any way; for example: 'A B' | <p> | ||
<p>If the specified data area is entirely blank, then deleting the blanks reduces the length of the value to zero and the field is not stored. To load null values, use the LOADNULLS ON statement as described on [[#LOADNULLS statement|LOADNULLS statement]]. Deleting leading and trailing blanks can be suppressed by using mode bits after the length specification.</p> | Before the value is stored, leading and trailing blanks are deleted from it for the sake of space saving and uniformity. (In retrieval specifications, <var class="product">Model 204</var> considers <code>'MALE'</code> and <code>'MALE '</code> to be separate and distinct values.) Internal blanks are not changed in any way; for example: <code>'A B'</code> is stored as <code>'A B'</code> and not as <code>'AB'</code> or <code>'A B'</code>.</p> | ||
<p> | |||
If the specified data area is entirely blank, then deleting the blanks reduces the length of the value to zero and the field is not stored. To load null values, use the <var>LOADNULLS ON</var> statement as described on [[#LOADNULLS statement|LOADNULLS statement]]. Deleting leading and trailing blanks can be suppressed by using mode bits after the length specification.</p> | |||
====Syntax==== | |||
<p class="syntax"><span class="term">fieldname</span><b></b>=<span class="term">position</span>,<span class="term">length</span>,<span class="term">mode_bits</span></p> | <p class="syntax"><span class="term">fieldname</span><b></b>=<span class="term">position</span>,<span class="term">length</span>,<span class="term">mode_bits</span></p> | ||
<p> | <p> | ||
< | Where: </p> | ||
< | <ul> | ||
< | <li><var class="term">fieldname</var> must start in column 2 and must be defined before running the file load program. <var class="term">fieldname</var> must be followed immediately by the equal sign with no intervening blanks. </li> | ||
< | |||
<li><var class="term">position</var> denotes the starting position of the field's value within the input record currently being processed and is always a positive number. (Position zero has a special significance that is explained in [[#Loading a constant field using a translation table|Loading a constant field using a translation table]].)</li> | |||
<li><var class="term">length</var> specifies the number of characters allotted to the value in the input record.</li> | |||
<li><var class="term">mode_bits</var> are optional and are described beginning on [[#File Load statements: mode bits|File Load statements: mode bits]].</li> | |||
</ul> | |||
===Load-constant (LDC) statement=== | ===Load-constant (LDC) statement=== | ||
<p>The LDC statement loads a constant value into a field. </p> | <p> | ||
The LDC statement loads a constant value into a field. | |||
It is more efficient for loading a constant field than the translation table method described in [[#File Load statements: mode bits|File Load statements: mode bits]].</p> | |||
====Syntax==== | |||
<p class="syntax">LDC <span class="term">fieldname</span | <p class="syntax">LDC <span class="term">fieldname</span>=<span class="term">value</span>=<span class="term">mode_bits</span> | ||
</p> | </p> | ||
<p> | <p> | ||
< | Where: </p> | ||
< | <ul> | ||
< | <li><var>LDC</var> begins in column 1.</li> | ||
< | |||
<li><var class="term">fieldname</var> is the Model 204 field into which the constant value is to be loaded.</li> | |||
<li><var class="term">mode_bits</var> are optional and are the same as those described beginning on [[#File Load statements: mode bits|File Load statements: mode bits]]. </li> | |||
<li>Equal signs (<tt>=</tt>) are value delimiters. </li> | |||
</ul> | |||
====Examples==== | |||
<p>The following examples use the LDC statement:</p> | <p>The following examples use the LDC statement:</p> | ||
<ul> | <ul> | ||
<li>Load the value 1176 B into field DEPT NO: | <li>Load the value <code>1176 B</code> into field <code>DEPT NO</code>: | ||
<p class="code">LDC DEPT NO=1176 B= | <p class="code">LDC DEPT NO=1176 B= | ||
</p></li> | </p></li> | ||
<li>Load the value BOSTON into the field CITY and begin a new <var class="product">Model 204</var> record: | |||
<li>Load the value <code>BOSTON</code> into the field <code>CITY</code> and begin a new <var class="product">Model 204</var> record: | |||
<p class="code">LDC CITY=BOSTON=X'8000' | <p class="code">LDC CITY=BOSTON=X'8000' | ||
</p></li> | </p></li> | ||
</ul> | </ul> | ||
===LOADNULLS statement=== | ===LOADNULLS statement=== | ||
<p>The LOADNULLS statement allows you to determine how to treat null values. Null values (values with a string length of zero) occur when you delete a data area that is blank.</p> | <p> | ||
The <var>LOADNULLS</var> statement allows you to determine how to treat null values. Null values (values with a string length of zero) occur when you delete a data area that is blank.</p> | |||
====Syntax==== | |||
<p class="syntax">LOADNULLS [ON | OFF] | <p class="syntax">LOADNULLS [ON | OFF] | ||
</p> | </p> | ||
<p> | <p> | ||
< | Where:</p> | ||
< | <ul> | ||
< | <li><var>ON</var> means that null values are loaded, the default.</li> | ||
<li><var>OFF</var> means that null values are not loaded.</li> | |||
</ul> | |||
<p> | |||
If <var>LOADNULLS</var> is not specified, the initial <var>FLOD</var> state is set to <var>LOADNULLS OFF</var>. </p> | |||
===Load-repeating-field (LDRF) statement=== | ===Load-repeating-field (LDRF) statement=== | ||
<p>The LDRF statement loads a variable number of occurrences of a fixed length field of an input record into a multiply occurring field of a <var class="product">Model 204</var> record. If the number of occurrences of the fixed length field varies between input records, each input record must contain a field that specifies the number of occurrences. If the number of occurrences of the fixed length field is the same in all input records, the constant value can be loaded into a string buffer, and the LDRF statement can refer to the string buffer. The fixed length fields must be adjacent in the input record. </p> | <p> | ||
The <var>LDRF</var> statement loads a variable number of occurrences of a fixed length field of an input record into a multiply occurring field of a <var class="product">Model 204</var> record. If the number of occurrences of the fixed length field varies between input records, each input record must contain a field that specifies the number of occurrences. If the number of occurrences of the fixed length field is the same in all input records, the constant value can be loaded into a string buffer, and the <var>LDRF</var> statement can refer to the string buffer. The fixed length fields must be adjacent in the input record. </p> | |||
====Syntax==== | |||
<p class="syntax">LDRF <span class="term">fieldname</span><b></b>=<span class="term">pos1</span>,<span class="term">len1</span>,<span class="term">pos2</span>,<span class="term">len2</span>[,<span class="term">index</span>][,<span class="term">mode_bits</span>] | <p class="syntax">LDRF <span class="term">fieldname</span><b></b>=<span class="term">pos1</span>,<span class="term">len1</span>,<span class="term">pos2</span>,<span class="term">len2</span>[,<span class="term">index</span>][,<span class="term">mode_bits</span>] | ||
</p> | </p> | ||
<p>< | <p> | ||
<p>For example, consider a file load program input file for a personnel database. The records might contain skill data that is likely to be multiply occurring. If the skill fields begin at position 45 of the input record, the length of each field is 15 bytes, a two-character EBCDIC occurrence count exists at record position 10, and the data is to be loaded into fields named SKILL, the following statement loads the fields:</p> | Where:</p> | ||
<ul> | |||
<li><var>LDRF</var> must begin in column 1.</li> | |||
<li><var class="term">pos1</var> is the starting position within the input record of the first occurrence of the fixed length field.</li> | |||
<li><var class="term">len1</var> is the length of each occurrence of the field.</li> | |||
<li><var class="term">pos2</var> is an EBCDIC number representing the number of occurrences of the fixed length field.</li> | |||
<li><var class="term">len2</var>, in bytes, is the length of the number in <var class="term">pos2</var>.</li> | |||
<li><var class="term">index</var> is optional and specifies an index register that points, after execution of the statement, to the record position just past the last occurrence loaded.</li> | |||
<li><var class="term">mode_bits</var> are optional and described starting on [[#File Load statements: mode bits|File Load statements: mode bits]]. </li> | |||
<li>The <var class="term">pos2</var> parameter is expected to be in EBCDIC. If this field is in the input record in some form, use the appropriate conversion statement (<var>CFB</var>, <var>CFF</var>, <var>CFP</var>, <var>CFZ</var>), with a string buffer. The string buffer can then be specified in the <var>LDRF</var> statement as the <var class="term">pos2</var> parameter. See [[#File Load statements: manipulating data areas with string buffers|File Load statements: manipulating data areas with string buffers]] for more information about converting values. </li> | |||
</ul> | |||
====Example==== | |||
<p> | |||
For example, consider a file load program input file for a personnel database. The records might contain skill data that is likely to be multiply occurring. If the skill fields begin at position 45 of the input record, the length of each field is 15 bytes, a two-character EBCDIC occurrence count exists at record position 10, and the data is to be loaded into fields named <code>SKILL</code>, the following statement loads the fields:</p> | |||
<p class="code">LDRF SKILL=45,15,10,2 | <p class="code">LDRF SKILL=45,15,10,2 | ||
</p> | </p> | ||
===Label definition (#) statement=== | ===Label definition (#) statement=== | ||
<p>Labels can be defined within a file load program by a statement in the form:</p> | <p> | ||
Labels can be defined within a file load program by a statement in the form:</p> | |||
<p class="syntax"><b></b>#<span class="term">n</span> | <p class="syntax"><b></b>#<span class="term">n</span> | ||
</p> | </p> | ||
<p> | <p> | ||
< | Where: </p> | ||
< | <ul> | ||
<li><var>#</var> (pound sign) is in column 1, and it is the label delimiter.</li> | |||
<li><var class="term">n</var> is a positive number. The minimum value for <var class="term">n</var> is 1 (see [[#File load program execution|File load program execution]]). The maximum is either 4095 or the value of the parameter <var>[[LNTBL parameter|LNTBL]]</var>, whichever is smaller. </li> | |||
</ul> | |||
====Usage==== | ====Usage==== | ||
<p>Labels are used by these other file load statements:</p> | <p> | ||
Labels are used by these other file load statements:</p> | |||
<ul> | <ul> | ||
<li>Unconditional branch</li> | <li>Unconditional branch</li> | ||
<li>Branch-on-character-equal</li> | <li>Branch-on-character-equal</li> | ||
<li>CASE statements that transfer execution from one part of the procedure to another.</li> | <li><var>CASE</var> statements that transfer execution from one part of the procedure to another.</li> | ||
</ul> | </ul> | ||
<p>These related statements are discussed in the following sections.</p> | <p> | ||
These related statements are discussed in the following sections.</p> | |||
===Unconditional branches=== | ===Unconditional branches=== | ||
<p>To force the execution of a file load program to transfer unconditionally to a statement other than the next one in line, specify a statement in the following form in column 1:</p> | <p> | ||
To force the execution of a file load program to transfer unconditionally to a statement other than the next one in line, specify a statement in the following form in column 1:</p> | |||
<p class="syntax">=<span class="term">label</span> | |||
<p class=" | |||
</p> | </p> | ||
<p> | <p> | ||
<p>label is the "<var class="term">n</var>" portion of the label as described in the previous section. </p> | Where: </p> | ||
<p> | |||
<var class="term">label</var> is the "<var class="term">n</var>" portion of the label as described in the previous section. </p> | |||
===Branch-on-character-equal (=) statement=== | ===Branch-on-character-equal (=) statement=== | ||
<p>The branch-on-character-equal statement allows the execution of a file load program to transfer to a different part of the procedure if the character at a specified position of the input record is equal to a specified character. | <p> | ||
The branch-on-character-equal statement allows the execution of a file load program to transfer to a different part of the procedure if the character at a specified position of the input record is equal to a specified character. </p> | |||
====Syntax==== | ====Syntax==== | ||
<p class=" | <p class="syntax"><b></b>=<span class="term">label</span>,<span class="term">position</span>,<span class="term">character</span> | ||
</p> | </p> | ||
<p> | <p> | ||
< | Where:</p> | ||
< | <ul> | ||
< | <li><var>=</var> (equal sign) is in column 1.</li> | ||
< | |||
<li><var class="term">label</var> is the "<var class="term">n</var>" portion of the label defined elsewhere in the procedure.</li> | |||
<li><var class="term">position</var> denotes the position of the character in the input record to be compared.</li> | |||
<li><var class="term">character</var> is the EBCDIC character to which the input character is compared. If the characters are equal, execution is transferred to the file load statements following the specified label. </li> | |||
</ul> | |||
====Usage==== | ====Usage==== | ||
<p>This statement can compare only one character at a time. The EBCDIC character must immediately follow the second comma in the statement. Be careful about what EBCDIC character you choose; you can only specify an unprintable character if the editor has special input capabilities. </p> | <p> | ||
This statement can compare only one character at a time. The EBCDIC character must immediately follow the second comma in the statement. Be careful about what EBCDIC character you choose; you can only specify an unprintable character if the editor has special input capabilities. </p> | |||
====Example==== | ====Example==== | ||
<p>In the following example, certain personnel input records contain the employee's sex (F or M) in | <p> | ||
In the following example, certain personnel input records contain the employee's sex (<code>F</code> or <code>M</code>) in column 8, and the employee's spouse's name in columns 20 through 35: </p> | |||
<p class="code">FLOD -1,-1,0 | <p class="code">FLOD -1,-1,0 | ||
G *Get a record from TAPEI | G *Get a record from TAPEI | ||
Line 461: | Line 623: | ||
===CASE statement=== | ===CASE statement=== | ||
<p>The CASE statement provides a character string compare and branch facility that allows the execution of a file load program to transfer to one of a number of other parts of the procedure based upon the contents of a data field at a specified position of the input record. | <p> | ||
The <var>CASE</var> statement provides a character string compare and branch facility that allows the execution of a file load program to transfer to one of a number of other parts of the procedure based upon the contents of a data field at a specified position of the input record. </p> | |||
====Syntax==== | ====Syntax==== | ||
<p class=" | <p class="syntax">CASE <span class="term">position</span>,<span class="term">length | ||
</ | </span> <span class="term">string1=label1 | ||
string2=label2 | string2=label2 | ||
string3=label3 | string3=label3</span> | ||
</ | |||
. | . | ||
. | . | ||
Line 475: | Line 636: | ||
ENDCASE | ENDCASE | ||
</p> | </p> | ||
<p> | <p> | ||
< | Where:</p> | ||
< | <ul> | ||
< | <li><var>CASE</var> begins in column 1.</li> | ||
< | |||
< | <li><var class="term">position</var> denotes the starting position of the character string in the input record to be tested.</li> | ||
<li><var class="term">length</var> denotes the length of the character string. </li> | |||
<li><var class="term">stringN=labelN</var> specifications form a branch table to indicate where to transfer control when the argument string is matched. Branch table entries must begin in column 2. <var>CASE</var> is limited to 25 or fewer entries.</li> | |||
<li><var>ENDCASE</var>, starting in column 1, must be used to terminate the branch table. </li> | |||
</ul> | |||
====Usage==== | ====Usage==== | ||
<p>The CASE statement recognizes a match only if the content and length of the input record string argument are identical to the string value and length of one of the branch table entries. If no branch table entry matches the input record string argument, control passes to the statement following ENDCASE.</p> | <p> | ||
The <var>CASE</var> statement recognizes a match only if the content and length of the input record string argument are identical to the string value and length of one of the branch table entries. If no branch table entry matches the input record string argument, control passes to the statement following <var>ENDCASE</var>.</p> | |||
====Example==== | ====Example==== | ||
<p>Consider the following example:</p> | <p> | ||
Consider the following example:</p> | |||
<p class="code">CASE 37,4 | <p class="code">CASE 37,4 | ||
JUNE=6 | JUNE=6 | ||
Line 493: | Line 663: | ||
ENDCASE | ENDCASE | ||
</p> | </p> | ||
<p>When the CASE statement is executed, the four-character string that starts at position 37 of the input record is compared to each table entry. A match on content and length results in a branch to the procedure label following the =. Thus, if an input record contained JUNE in positions 37-40, control is transferred to procedure label 6. If the record contained JULY or MAY, control is passed to label 7 or 2, respectively.</p> | <p> | ||
<p>The table entry for MAY in the previous example was expanded to four bytes. If the table entry is as follows, a match does not occur because its implies string length is 3:</p> | When the <var>CASE</var> statement is executed, the four-character string that starts at position 37 of the input record is compared to each table entry. A match on content and length results in a branch to the procedure label following the <code>=</code>. Thus, if an input record contained <code>JUNE</code> in positions 37-40, control is transferred to procedure label 6. If the record contained <code>JULY</code> or <code>MAY</code>, control is passed to label 7 or 2, respectively.</p> | ||
<p> | |||
The table entry for <code>MAY</code> in the previous example was expanded to four bytes. If the table entry is as follows, a match does not occur because its implies string length is 3:</p> | |||
<p class="code">MAY=2 | <p class="code">MAY=2 | ||
</p> | </p> | ||
<p>The comparison is of data content and length. Applications of the CASE statement, in which the length of the strings in the branch table vary, can be handled by using a file load program index register for the CASE length specification. Index registers are discussed in [[#File Load statements: working with index registers|File Load statements: working with index registers]].</p> | <p> | ||
The comparison is of data content and length. Applications of the <var>CASE</var> statement, in which the length of the strings in the branch table vary, can be handled by using a file load program index register for the <var>CASE</var> length specification. Index registers are discussed in [[#File Load statements: working with index registers|File Load statements: working with index registers]].</p> | |||
===Transfer-on-condition (T) statement=== | ===Transfer-on-condition (T) statement=== | ||
<p>Use the transfer-on-condition statement to compare two data areas of the input record and to transfer to a specified label if the comparison indicates a specified condition. | <p> | ||
Use the transfer-on-condition statement to compare two data areas of the input record and to transfer to a specified label if the comparison indicates a specified condition. </p> | |||
====Syntax==== | ====Syntax==== | ||
<p class=" | <p class="syntax">T <span class="term">label</span>,<span class="term">position1</span>,<span class="term">length</span>,<span class="term">position2</span>,<span class="term">condition</span> | ||
</p> | </p> | ||
<p> | <p> | ||
< | Where:</p> | ||
< | <ul> | ||
< | <li><var>T</var> is in column 1. </li> | ||
< | |||
< | <li><var class="term">label</var> is the "<var class="term">n</var>" portion of the specified label (see previous statements about labels).</li> | ||
< | |||
<li><var class="term">position1</var> is the position of the first data area.</li> | |||
<li><var class="term">length</var> specifies the number of characters.</li> | |||
<li><var class="term">position2</var> is the position of the second data area. Each data area is taken to be and is treated as a simple EBCDIC character string.</li> | |||
<li><var class="term">condition</var> is represented by a decimal number, as follows: | |||
<table> | <table> | ||
<tr class="head"> | <tr class="head"> | ||
Line 518: | Line 698: | ||
<th>Meaning</th> | <th>Meaning</th> | ||
</tr> | </tr> | ||
<tr> | <tr> | ||
<td align="right"> 2</td> | <td align="right"> 2</td> | ||
<td>Greater than</td> | <td>Greater than</td> | ||
</tr> | </tr> | ||
<tr> | <tr> | ||
<td align="right"> 4</td> | <td align="right"> 4</td> | ||
<td>Less than</td> | <td>Less than</td> | ||
</tr> | </tr> | ||
<tr> | <tr> | ||
<td align="right"> 7</td> | <td align="right"> 7</td> | ||
<td>Not equal to</td> | <td>Not equal to</td> | ||
</tr> | </tr> | ||
<tr> | <tr> | ||
<td align="right"> 8</td> | <td align="right"> 8</td> | ||
<td>Equal to</td> | <td>Equal to</td> | ||
</tr> | </tr> | ||
<tr> | <tr> | ||
<td align="right"> 11</td> | <td align="right"> 11</td> | ||
<td>Greater than or equal to</td> | <td>Greater than or equal to</td> | ||
</tr> | </tr> | ||
<tr> | <tr> | ||
<td align="right"> 13</td> | <td align="right"> 13</td> | ||
<td>Less than or equal to</td> | <td>Less than or equal to</td> | ||
</tr> | </tr> | ||
</table> | </table></li> | ||
</ul> | |||
====Example==== | ====Example==== | ||
<p>The following example transfers to label 40, if the character string in columns 3 through 12 is greater than that in columns 31 through 40:</p> | <p> | ||
The following example transfers to label 40, if the character string in columns 3 through 12 is greater than that in columns 31 through 40:</p> | |||
<p class="code">T 40,3,10,31,2 | <p class="code">T 40,3,10,31,2 | ||
</p> | </p> | ||
===Read a field name from input data (D) statement=== | ===Read a field name from input data (D) statement=== | ||
<p>In some circumstances, the input data contains the names of the fields to be loaded as well as the values. The D statement is similar to the read-and-load-a-field statement except that it also specifies the position and length of the field name within the current input. | <p> | ||
In some circumstances, the input data contains the names of the fields to be loaded as well as the values. The <var>D</var> statement is similar to the read-and-load-a-field statement except that it also specifies the position and length of the field name within the current input. </p> | |||
====Syntax==== | ====Syntax==== | ||
<p class=" | <p class="syntax">D <span class="term">position1</span>,<span class="term">length1</span><b></b>=<span class="term">position2</span>,<span class="term">length2</span>[,<span class="term">mode_bits</span>] | ||
</p> | </p> | ||
<p> | <p> | ||
< | Where: </p> | ||
< | <ul> | ||
< | <li><var>D</var> is in column 1.</li> | ||
< | |||
<li><var class="term">position1</var> and <var class="term">length1</var> specify the position and length of the data area that contains the field name. Leading and trailing blanks are deleted.</li> | |||
<li><var class="term">position2</var> and <var class="term">length2</var> specify the position and length of the data area that contains the field value.</li> | |||
<li><var class="term">mode_bits</var> are optional and identical to the optional mode bits in [[#File Load statements: mode bits|File Load statements: mode bits]]. </li> | |||
</ul> | |||
====Example==== | ====Example==== | ||
<p>Suppose that input statements are arranged so that each statement contains a field name in columns 2 through 31 and a field value in columns 32 through 80. Furthermore, column 1 contains a 1 if the field is the first field of a new record and a 2 otherwise. The input records are:</p> | <p> | ||
Suppose that input statements are arranged so that each statement contains a field name in columns 2 through 31 and a field value in columns 32 through 80. Furthermore, column 1 contains a 1 if the field is the first field of a new record and a 2 otherwise. The input records are:</p> | |||
<p class="code">1SOC.SEC.NO 540237398 | <p class="code">1SOC.SEC.NO 540237398 | ||
2NAME THORNHILL | 2NAME THORNHILL | ||
Line 573: | Line 768: | ||
. | . | ||
</p> | </p> | ||
<p>The following file load program loads the records:</p> | <p> | ||
The following file load program loads the records:</p> | |||
<p class="code">FLOD -1,-1,0 | <p class="code">FLOD -1,-1,0 | ||
G *Read new input record | G *Read new input record | ||
<b></b>=10,1,2 | <b></b>=10,1,2 *Branch to 10 if rec starts with 2 | ||
D 2,30=32,49,X'8000' *Load first fld of Model 204 rec | D 2,30=32,49,X'8000' *Load first fld of Model 204 rec | ||
<b></b>=20 | <b></b>=20 *Branch to label 20 | ||
<b></b>#10 | <b></b>#10 | ||
D 2,30=32,49 | D 2,30=32,49 *Add a field to Model 204 record | ||
<b></b>#20 | <b></b>#20 | ||
END | END | ||
Line 586: | Line 782: | ||
===Print a character string (P) statement=== | ===Print a character string (P) statement=== | ||
<p>Use the P statement to print selected portions of the current input record or of a string buffer. | <p> | ||
Use the <var>P</var> statement to print selected portions of the current input record or of a string buffer. </p> | |||
====Syntax==== | ====Syntax==== | ||
<p class=" | <p class="syntax">P <span class="term">position</span>,<span class="term">length</span> | ||
</p> | </p> | ||
<p> | <p> | ||
< | Where:</p> | ||
< | <ul> | ||
< | <li><var>P</var> is in column 1.</li> | ||
<li><var class="term">position</var> indicates the starting position on the input record or string buffer.</li> | |||
<li><var class="term">length</var> indicates the number of bytes of data to be printed from the input record or string buffer. </li> | |||
</ul> | |||
====Example==== | ====Example==== | ||
<p>The following statement can be used to print out sample input data:</p> | <p> | ||
The following statement can be used to print out sample input data:</p> | |||
<p class="code">FLOD -1,50,0 | <p class="code">FLOD -1,50,0 | ||
G | G | ||
Line 604: | Line 804: | ||
END | END | ||
</p> | </p> | ||
<p>This statement prints 50 input records of 80 bytes each.</p> | <p> | ||
<p>The P statement also is useful for printing out input records that are not in an expected format. The following procedure prints out input records that contain something other than an X or a Y in column 1:</p> | This statement prints 50 input records of 80 bytes each.</p> | ||
<p> | |||
The <var>P</var> statement also is useful for printing out input records that are not in an expected format. The following procedure prints out input records that contain something other than an <code>X</code> or a <code>Y</code> in column 1:</p> | |||
<p class="code">FLOD -1,-1,0 | <p class="code">FLOD -1,-1,0 | ||
G | G | ||
Line 626: | Line 828: | ||
===STOP statement=== | ===STOP statement=== | ||
<p>The STOP statement allows a file load program to exit before the number of records in the data set or specified in the file load program have been processed. | <p> | ||
The <var>STOP</var> statement allows a file load program to exit before the number of records in the data set or specified in the file load program have been processed. </p> | |||
====Syntax==== | ====Syntax==== | ||
<p class=" | <p class="syntax">STOP <span class="term">return_code</span> | ||
</p> | </p> | ||
<p> | <p> | ||
< | Where <var class="term">return_code</var> is an optional, nonzero number. This number sets the job step return code for the file load program step. </p> | ||
====Usage==== | ====Usage==== | ||
<p>When the STOP statement is executed, the file load program ends evaluation of the statements in the procedure and displays the following message:</p> | <p> | ||
When the <var>STOP</var> statement is executed, the file load program ends evaluation of the statements in the procedure and displays the following message:</p> | |||
<p class="code"><b></b>*** M204.0697: FLOD FINISHED -- STOP STATEMENT | <p class="code"><b></b>*** M204.0697: FLOD FINISHED -- STOP STATEMENT | ||
</p> | </p> | ||
<p>When the file load program STOP statement executes, it ends the program, but not any of the other commands contained in the job stream.</p> | <p> | ||
When the file load program <var>STOP</var> statement executes, it ends the program, but not any of the other commands contained in the job stream.</p> | |||
==File Load statements: manipulating data areas with string buffers== | ==File Load statements: manipulating data areas with string buffers== | ||
<p>Two 256-byte areas, called string buffers, are provided to allow you to manipulate and reformat data areas before they are loaded. Use string buffers when: </p> | <p> | ||
Two 256-byte areas, called string buffers, are provided to allow you to manipulate and reformat data areas before they are loaded. Use string buffers when: </p> | |||
<ul> | <ul> | ||
<li>Input contains a long data area that is continued over two or more input records</li> | <li>Input contains a long data area that is continued over two or more input records</li> | ||
<li>Number of data areas are to be combined, reordered, or reformatted before loading</li> | <li>Number of data areas are to be combined, reordered, or reformatted before loading</li> | ||
<li>Using a numeric conversion statement (CFB, CFP, CFF, or CFZ)</li> | <li>Using a numeric conversion statement (<var>CFB</var>, <var>CFP</var>, <var>CFF</var>, or <var>CFZ</var>)</li> | ||
<li>Using an L/ENDL loop (see [[#L...ENDL statement (locate existing records)|L...ENDL statement (locate existing records)]]) </li> | <li>Using an <var>L/ENDL</var> loop (see [[#L...ENDL statement (locate existing records)|L...ENDL statement (locate existing records)]]) </li> | ||
</ul> | </ul> | ||
<p>Use the following statements to manipulate the contents of the string buffers.</p> | <p> | ||
Use the following statements to manipulate the contents of the string buffers (the statement name in the first column is a link to the section that explains it).</p> | |||
<table> | <table> | ||
<tr class="head"> | <tr class="head"> | ||
Line 655: | Line 861: | ||
<th>Meaning</th> | <th>Meaning</th> | ||
</tr> | </tr> | ||
<tr> | <tr> | ||
<td>S </td> | <td>[[#sStmt|S]] </td> | ||
<td>Clears the string buffer; moves a character string into the buffer</td> | <td>Clears the string buffer; moves a character string into the buffer</td> | ||
</tr> | </tr> | ||
<tr> | <tr> | ||
<td>SC</td> | <td>[[#scStmt|SC]]</td> | ||
<td>Clears the string buffer; moves a constant into the buffer</td> | <td>Clears the string buffer; moves a constant into the buffer</td> | ||
</tr> | </tr> | ||
<tr> | <tr> | ||
<td>M</td> | <td>[[#mStmt|M]]</td> | ||
<td>Appends (moves) a character string into the buffer without clearing</td> | <td>Appends (moves) a character string into the buffer without clearing</td> | ||
</tr> | </tr> | ||
<tr> | <tr> | ||
<td>MC</td> | <td>[[#mcStmt|MC]]</td> | ||
<td>Appends (moves) a constant into the buffer without clearing</td> | <td>Appends (moves) a constant into the buffer without clearing</td> | ||
</tr> | </tr> | ||
<tr> | <tr> | ||
<td>CFB</td> | <td>[[#cfbStmt|CFB]]</td> | ||
<td>Converts from binary</td> | <td>Converts from binary</td> | ||
</tr> | </tr> | ||
<tr> | <tr> | ||
<td>CFF</td> | <td>[[#cffStmt|CFF]]</td> | ||
<td>Converts from floating-point</td> | <td>Converts from floating-point</td> | ||
</tr> | </tr> | ||
<tr> | <tr> | ||
<td>CFP</td> | <td>[[#cfpStmt|CFP]]</td> | ||
<td>Converts from packed decimal</td> | <td>Converts from packed decimal</td> | ||
</tr> | </tr> | ||
<tr> | <tr> | ||
<td>CFZ</td> | <td>[[#cfzStmt|CFZ]]</td> | ||
<td>Converts from zoned decimal</td> | <td>Converts from zoned decimal</td> | ||
</tr> | </tr> | ||
Line 690: | Line 904: | ||
===Referring to string buffers=== | ===Referring to string buffers=== | ||
<p>Any statement that refers to the normal input record can also refer to a string buffer. A position field in any statement can be modified to refer to the string buffer instead of the input record using the following format:</p> | <p> | ||
Any statement that refers to the normal input record can also refer to a string buffer. A position field in any statement can be modified to refer to the string buffer instead of the input record using the following format:</p> | |||
<p class="syntax"><b></b>=<span class="term">position,</span> {|0S | |1S} | |||
<p class=" | |||
</p> | </p> | ||
====Examples==== | ====Examples==== | ||
<p>The following example branches to label 12 if column 37 of string buffer 0 contains an A:</p> | <p> | ||
The following example branches to label 12 if column 37 of string buffer 0 contains an <code>A</code>:</p> | |||
<p class="code"><b></b>=12,37|0S,A | <p class="code"><b></b>=12,37|0S,A | ||
</p> | </p> | ||
<p>The following example loads a field called DATE with a value taken from the first six columns of string buffer 1:</p> | <p> | ||
<p class="code"> | The following example loads a field called <code>DATE</code> with a value taken from the first six columns of string buffer 1:</p> | ||
<p class="code">DATE=1|1S,6 | |||
DATE=1|1S,6 | |||
</p> | </p> | ||
<p>The length of the current contents of a string buffer is remembered by <var class="product">Model 204</var> and can be used in any statement that contains a length field. This is done by immediately following the length with a vertical bar, the string buffer number, and the letter S. This causes the current length of the specified string buffer to be added to the length field.</p> | <p> | ||
<p>Therefore, the length field normally is specified as zero.</p> | The length of the current contents of a string buffer is remembered by <var class="product">Model 204</var> and can be used in any statement that contains a length field. This is done by immediately following the length with a vertical bar, the string buffer number, and the letter <code>S</code>. This causes the current length of the specified string buffer to be added to the length field.</p> | ||
<p>The following example loads a field called DATE with a value equal to the current contents of string buffer 1:</p> | <p> | ||
Therefore, the length field normally is specified as zero.</p> | |||
<p> | |||
The following example loads a field called <code>DATE</code> with a value equal to the current contents of string buffer 1:</p> | |||
<p class="code">DATE=1|1S,0|1S | <p class="code">DATE=1|1S,0|1S | ||
</p> | </p> | ||
<p>The following example transfers to label 20, if the current contents of string buffer 0 are less than or equal to (condition 13) the contents of the date area beginning at column 73 of the current record:</p> | <p> | ||
The following example transfers to label 20, if the current contents of string buffer 0 are less than or equal to (condition 13) the contents of the date area beginning at column 73 of the current record:</p> | |||
<p class="code">T 20,1|0S,0|0S,73,13 | <p class="code">T 20,1|0S,0|0S,73,13 | ||
</p> | </p> | ||
<p>For example, certain input records contain Social Security numbers in the form 123-45-6789 in columns 21 through 31. The following code removes the hyphens before the numbers are loaded into the <var class="product">Model 204</var> file:</p> | <p> | ||
For example, certain input records contain Social Security numbers in the form 123-45-6789 in columns 21 through 31. The following code removes the hyphens before the numbers are loaded into the <var class="product">Model 204</var> file:</p> | |||
<p class="code">S 0,21,3 * Blank buffer; load 3 digits. | <p class="code">S 0,21,3 * Blank buffer; load 3 digits. | ||
M 0,25,2 * Add middle 2 digits. | M 0,25,2 * Add middle 2 digits. | ||
M 0,28,4 * Add last 4 digits. | M 0,28,4 * Add last 4 digits. | ||
SOC.SEC.NO=1|0S,9 | SOC.SEC.NO=1|0S,9 * Load number from buffer. | ||
</p> | </p> | ||
===S statement=== | ===<b id="sStmt"></b>S statement=== | ||
<p>The S statement clears the contents of the specified string buffer to blanks and then moves in a character string from the current input record. The string is left-justified in the string buffer. | <p> | ||
The <var>S</var> statement clears the contents of the specified string buffer to blanks and then moves in a character string from the current input record. The string is left-justified in the string buffer. </p> | |||
====Syntax==== | ====Syntax==== | ||
<p class=" | <p> | ||
The format of the <var>S</var> statement is: </p> | |||
<p class="syntax">S {0 | 1},<span class="term">position</span>,<span class="term">length</span> | |||
</p> | </p> | ||
<p> | <p> | ||
< | Where: </p> | ||
< | <ul> | ||
< | <li><var>S</var> begins in column 1.</li> | ||
< | <li>0 and 1 are string buffers.</li> | ||
<li><var class="term">position</var> is the starting column number from which to read characters from the current input record.</li> | |||
<li><var class="term">length</var> is the number of characters to read.</li> | |||
</ul> | |||
====Examples==== | ====Examples==== | ||
<p>The following example clears buffer 0 and moves 11 characters from columns 29 through 39 of the current input record into the beginning of the buffer:</p> | <p> | ||
The following example clears buffer 0 and moves 11 characters from columns 29 through 39 of the current input record into the beginning of the buffer:</p> | |||
<p class="code">S 0,29,11 | <p class="code">S 0,29,11 | ||
</p> | </p> | ||
<p>The following example clears string buffer 1 and inserts the character from column 3 of the input:</p> | <p> | ||
The following example clears string buffer 1 and inserts the character from column 3 of the input:</p> | |||
<p class="code">S 1,3,1 | <p class="code">S 1,3,1 | ||
</p> | </p> | ||
<p>The following example simply clears string buffer 0:</p> | <p> | ||
The following example simply clears string buffer 0:</p> | |||
<p class="code">S 0,1,0 | <p class="code">S 0,1,0 | ||
</p> | </p> | ||
===M statement=== | ===<b id="mStmt"></b>M statement=== | ||
<p>The M statement is almost identical to the S statement except that the string buffer is not cleared first. Characters from the input record are simply appended to the existing contents of the buffer. | <p> | ||
The <var>M</var> statement is almost identical to the <var>S</var> statement except that the string buffer is not cleared first. Characters from the input record are simply appended to the existing contents of the buffer. </p> | |||
====Syntax==== | ====Syntax==== | ||
<p class=" | <p> | ||
The format of the <var>M</var> statement is: </p> | |||
<p class="syntax">M {0 | 1},<span class="term">position</span>,<span class="term">length</span> | |||
</p> | </p> | ||
===SC statement=== | ===<b id="scStmt"></b>SC statement=== | ||
<p>The SC statement clears the contents of the specified string buffer to blanks and then moves in a constant | <p> | ||
The <var>SC</var> statement clears the contents of the specified string buffer to blanks and then moves in a constant. </p> | |||
====Syntax==== | ====Syntax==== | ||
<p class=" | <p> | ||
The format of the <var>SC</var> statement is: </p> | |||
<p class="syntax">SC {0 | 1},<span class="term">value</span>= | |||
</p> | </p> | ||
<p> | <p> | ||
< | Where: </p> | ||
< | <ul> | ||
< | <li><var>SC</var> begins in column 1.</li> | ||
<li>0 and 1 are string buffers.</li> | |||
<li><var class="term">value</var><var>=</var> is any constant string. You <var class="term">must</var> specify the final equal sign. The constant can be up to 256 characters long.</li> | |||
</ul> | |||
====Example==== | ====Example==== | ||
<p>The following example clears buffer 0 and moves the constant value, 7, into the beginning of the buffer:</p> | <p> | ||
The following example clears buffer 0 and moves the constant value, 7, into the beginning of the buffer:</p> | |||
<p class="code">SC 0,7= | <p class="code">SC 0,7= | ||
</p> | </p> | ||
===MC statement=== | ===<b id="mcStmt"></b>MC statement=== | ||
<p>The MC statement is almost identical to the SC statement except that the string buffer is not cleared first. A constant value is simply appended to the existing contents of the buffer. | <p> | ||
The <var>MC</var> statement is almost identical to the <var>SC</var> statement except that the string buffer is not cleared first. A constant value is simply appended to the existing contents of the buffer. </p> | |||
====Syntax==== | ====Syntax==== | ||
<p class=" | <p> | ||
The format of the <var>MC</var> statement is:</p> | |||
<p class="syntax">MC {0 | 1},<span class="term">value</span>= | |||
</p> | </p> | ||
===Data conversion statements=== | ===Data conversion statements=== | ||
<p>You can use string buffers as an intermediate storage area while converting input data from binary, packed decimal, zoned decimal, or floating-point to EBCDIC for storage in the <var class="product">Model 204</var> file. Numeric data must be translated to character form if the data is to be accessible to a | <p> | ||
<p>These statements are described in detail in the following sections.</p> | You can use string buffers as an intermediate storage area while converting input data from binary, packed decimal, zoned decimal, or floating-point to EBCDIC for storage in the <var class="product">Model 204</var> file. Numeric data must be translated to character form if the data is to be accessible to a SOUL user.</p> | ||
<p> | |||
These statements are described in detail in the following sections.</p> | |||
===CFB (convert from binary) statement=== | ===<b id="cfbStmt"></b>CFB (convert from binary) statement=== | ||
<p>To allow you to translate from binary input data to a character string format for use in <var class="product">Model 204</var>, the convert-from-binary instruction is provided. | <p> | ||
To allow you to translate from binary input data to a character string format for use in <var class="product">Model 204</var>, the convert-from-binary instruction is provided. </p> | |||
====Syntax==== | ====Syntax==== | ||
<p class=" | <p> | ||
The statement format is:</p> | |||
<p class="syntax">CFB {0 | 1},<span class="term">position</span>,<span class="term">length</span> | |||
</p> | </p> | ||
<p> | <p> | ||
< | Where:</p> | ||
< | <ul> | ||
< | <li><var>CFB</var> starts in column 1.</li> | ||
< | <li>0 and 1 are string buffers.</li> | ||
<li><var class="term">position</var> indicates where the binary data in the input record begins.</li> | |||
<li><var class="term">length</var> can be from 1-4 bytes. </li> | |||
</ul> | |||
====Usage==== | ====Usage==== | ||
<p>The data in the specified position must be a 1- to 4-byte signed binary number. The CFB instruction converts it to EBCDIC and stores it in the designated string buffer where it can be edited and/or loaded into the <var class="product">Model 204</var> file. Leading integer zeroes are stripped during conversion. </p> | <p> | ||
<p>The first character of the result is either a significant digit or a minus sign (-). If the input value is a zero, the result is a single zero. </p> | The data in the specified position must be a 1- to 4-byte signed binary number. The <var>CFB</var> instruction converts it to EBCDIC and stores it in the designated string buffer where it can be edited and/or loaded into the <var class="product">Model 204</var> file. Leading integer zeroes are stripped during conversion. </p> | ||
<p> | |||
The first character of the result is either a significant digit or a minus sign (<tt>-</tt>). If the input value is a zero, the result is a single zero. </p> | |||
====Example==== | ====Example==== | ||
<p>For example, the following sequence converts a 2-byte binary field beginning in Position 4 of the input record to EBCDIC, leaving the result in string buffer 1:</p> | <p> | ||
For example, the following sequence converts a 2-byte binary field beginning in Position 4 of the input record to EBCDIC, leaving the result in string buffer 1:</p> | |||
<p class="code">CFB 1,4,2 | <p class="code">CFB 1,4,2 | ||
QUANTITY=1|1S,0|1S | QUANTITY=1|1S,0|1S | ||
</p> | </p> | ||
<p>The EBCDIC string is loaded from string buffer 1 into the QUANTITY field of the current record.</p> | <p> | ||
The EBCDIC string is loaded from string buffer 1 into the <code>QUANTITY</code> field of the current record.</p> | |||
===CFF (convert from floating-point) statement=== | ===<b id="cffStmt"></b>CFF (convert from floating-point) statement=== | ||
<p>The convert-from-floating-point instruction converts short- or long-floating-point input data to a character string format for use in <var class="product">Model 204</var>. | <p> | ||
The convert-from-floating-point instruction converts short- or long-floating-point input data to a character string format for use in <var class="product">Model 204</var>.</p> | |||
====Syntax==== | ====Syntax==== | ||
<p class=" | <p> | ||
The statement format is:</p> | |||
<p class="syntax">CFF {0 | 1},<span class="term">position</span>,<span class="term">length</span> | |||
</p> | </p> | ||
<p> | <p> | ||
< | Where: </p> | ||
< | <ul> | ||
< | <li><var>CFF</var> starts in column 1.</li> | ||
< | <li>0 and 1 are string buffers.</li> | ||
<li><var class="term">position</var> indicates where the binary data in the input record begins.</li> | |||
<li><var class="term">length</var> depends on the form of the input data. The input data can be either a short- or long-precision floating-point number. Length must be: | |||
<ul> | <ul> | ||
<li>4 for a short-precision number</li> | <li>4 for a short-precision number</li> | ||
<li>8 for a long-precision number</li> | <li>8 for a long-precision number</li> | ||
</ul> | </ul> | ||
<b>Note</b> | <p class="note"><b>Note:</b> | ||
If <var class="term">length</var> is specified incorrectly (neither 4 nor 8), a zero length results and no error indication is given. </p></li> | |||
</ul> | |||
====Usage==== | ====Usage==== | ||
<p>Leading integer zeros and trailing fractional zeros are stripped during conversion. A decimal point is not included for an integer value. If the input value is a zero, the result is a single zero. If the input value is a negative number, the first character of the result is a minus sign. The result of the conversion has at least 15 digits of precision. The result of a CFF instruction can be loaded into a <var class="product">Model 204</var> record using a read-and-load-a-field statement, as shown in the following example.</p> | <p> | ||
Leading integer zeros and trailing fractional zeros are stripped during conversion. A decimal point is not included for an integer value. If the input value is a zero, the result is a single zero. If the input value is a negative number, the first character of the result is a minus sign. The result of the conversion has at least 15 digits of precision. The result of a CFF instruction can be loaded into a <var class="product">Model 204</var> record using a read-and-load-a-field statement, as shown in the following example.</p> | |||
====Example==== | ====Example==== | ||
Line 831: | Line 1,090: | ||
AMOUNT=1|1S,0|1S | AMOUNT=1|1S,0|1S | ||
</p> | </p> | ||
<p>For information about loading floating-point input directly into a field, see [[#Read and load floating-point data (X'0080')|Read and load floating-point data (X'0080')]].</p> | <p> | ||
For information about loading floating-point input directly into a field, see [[#Read and load floating-point data (X'0080')|Read and load floating-point data (X'0080')]].</p> | |||
===CFP (convert from packed decimal) statement=== | ===<b id="cfpStmt"></b>CFP (convert from packed decimal) statement=== | ||
<p>To allow you to translate from packed decimal input data to a character string format for use in <var class="product">Model 204</var>, the convert-from-packed instruction is provided. | <p> | ||
To allow you to translate from packed decimal input data to a character string format for use in <var class="product">Model 204</var>, the convert-from-packed instruction is provided. </p> | |||
====Syntax==== | ====Syntax==== | ||
<p class=" | <p> | ||
The statement format is:</p> | |||
<p class="syntax">CFP {0 | 1},<span class="term">position</span>,<span class="term">length</span>[,<span class="term">decimal_position</span>] | |||
</p> | </p> | ||
<p> | <p> | ||
< | Where: </p> | ||
< | <ul> | ||
< | <li><var>CFP</var> starts in column 1.</li> | ||
< | |||
<b>Note</b> | <li>0 and 1 are string buffers.</li> | ||
< | <li><var class="term">position</var> indicates where the packed data in the input record begins.</li> | ||
<li><var class="term">length</var>, specified in bytes rather than packed decimal digits, must be between 1 and 8. | |||
<p class="note"><b>Note:</b> | |||
If the length is specified incorrectly (less than 1 or greater than 8) a zero length results and no error indication is given.</p></li> | |||
<li><var class="term">decimal_position</var> indicates where a decimal point can be inserted into the string, expressed as a number of digits to the right of the desired decimal point. </li> | |||
</ul> | |||
====Usage==== | ====Usage==== | ||
<p>The data in the specified position must be a 1- to 8-byte packed decimal number, which starts on a byte boundary and, therefore, consists of an odd number of digits. This data is not checked for conformity to a packed decimal format. A number is assumed to be positive unless its sign position contains a valid minus sign.</p> | <p> | ||
<p>The CFP instruction converts the data to EBCDIC and stores the result in the designated string buffer, where it can be edited and/or loaded into the <var class="product">Model 204</var> file. The first character of the result is either a blank or a minus sign, and leading and trailing zeros are not stripped. If a decimal position is specified, a decimal point is inserted in the string. If the decimal position is invalid (less than zero or greater than the number of digits in the input), a message is issued and the decimal point is not inserted. </p> | The data in the specified position must be a 1- to 8-byte packed decimal number, which starts on a byte boundary and, therefore, consists of an odd number of digits. This data is not checked for conformity to a packed decimal format. A number is assumed to be positive unless its sign position contains a valid minus sign.</p> | ||
<p> | |||
The <var>CFP</var> instruction converts the data to EBCDIC and stores the result in the designated string buffer, where it can be edited and/or loaded into the <var class="product">Model 204</var> file. The first character of the result is either a blank or a minus sign, and leading and trailing zeros are not stripped. If a decimal position is specified, a decimal point is inserted in the string. If the decimal position is invalid (less than zero or greater than the number of digits in the input), a message is issued and the decimal point is not inserted. </p> | |||
====Example==== | ====Example==== | ||
<p>The following sequence converts a 6-byte packed decimal field beginning in Position 8 of the input record to EBCDIC, leaving the result in string buffer 1 with a decimal point inserted, giving the number two decimal places:</p> | <p> | ||
The following sequence converts a 6-byte packed decimal field beginning in Position 8 of the input record to EBCDIC, leaving the result in string buffer 1 with a decimal point inserted, giving the number two decimal places:</p> | |||
<p class="code">CFP 1,8,6,2 | <p class="code">CFP 1,8,6,2 | ||
AMOUNT=1|1S,0|1S | AMOUNT=1|1S,0|1S | ||
</p> | </p> | ||
<p>The result has the form:</p> | <p> | ||
<p class=" | The result has the form:</p> | ||
<p class="syntax"><span class="term">sddddddddd.dd</span> | |||
</p> | </p> | ||
<p> | <p> | ||
< | Where: </p> | ||
< | <ul> | ||
<p>This result is then loaded into the AMOUNT field of the current record from string buffer 1.</p> | <li><var class="term">s</var> represents a blank or minus sign. </li> | ||
<li><var class="term">d</var> represents a digit between 0 and 9. </li> | |||
</ul> | |||
<p> | |||
This result is then loaded into the <code>AMOUNT</code> field of the current record from string buffer 1.</p> | |||
===CFZ (convert from zoned decimal) statement=== | ===<b id="cfzStmt"></b>CFZ (convert from zoned decimal) statement=== | ||
<p>To allow translation from zoned decimal input data to a character string format for use in <var class="product">Model 204</var>, the convert-from-zoned instruction is provided. | <p> | ||
To allow translation from zoned decimal input data to a character string format for use in <var class="product">Model 204</var>, the convert-from-zoned instruction is provided. </p> | |||
====Syntax==== | ====Syntax==== | ||
<p class=" | <p> | ||
The statement format is:</p> | |||
<p class="syntax">CFZ {0 | 1},<span class="term">position</span>,<span class="term">length</span>[,<span class="term">decimal_position</span>] | |||
</p> | </p> | ||
<p> | <p> | ||
< | Where: </p> | ||
< | <ul> | ||
< | <li><var>CFZ</var> starts in column 1.</li> | ||
< | <li>0 and 1 are string buffers.</li> | ||
< | <li><var class="term">position</var> indicates where the zoned data in the input record begins.</li> | ||
<li><var class="term">length</var>, specified in bytes, must be between 1 and 16. If the length is specified incorrectly (less than 1 or greater than 16), a zero length results and no error indication is given.</li> | |||
<li><var class="term">decimal_position</var> indicates where a decimal point can be inserted into the string, expressed as the number of digits to the right of the desired decimal point. </li> | |||
</ul> | |||
====Usage==== | ====Usage==== | ||
<p>The data in the specified position must be a 1- to 16-byte zoned decimal number. The data is not checked for conformity to a zoned decimal format. If the zone of the low-order byte is not a valid minus sign, the number is assumed to be positive.</p> | <p> | ||
<p>The CFZ instruction converts the data to EBCDIC and stores the result in the designated string buffer where it can be edited and/or loaded into the <var class="product">Model 204</var> file. The first character of the result is either a blank or a minus sign, and leading and trailing zeroes are not stripped. If the decimal position is invalid (less than 0 or greater than the number of digits in the input), a message is issued and the decimal point is not inserted. </p> | The data in the specified position must be a 1- to 16-byte zoned decimal number. The data is not checked for conformity to a zoned decimal format. If the zone of the low-order byte is not a valid minus sign, the number is assumed to be positive.</p> | ||
<p> | |||
The <var>CFZ</var> instruction converts the data to EBCDIC and stores the result in the designated string buffer where it can be edited and/or loaded into the <var class="product">Model 204</var> file. The first character of the result is either a blank or a minus sign, and leading and trailing zeroes are not stripped. If the decimal position is invalid (less than 0 or greater than the number of digits in the input), a message is issued and the decimal point is not inserted. </p> | |||
====Example==== | ====Example==== | ||
<p>The following sequence converts a 6-byte zoned decimal field beginning in position 20 of the input record to EBCDIC, leaving the result in string buffer 1 with a decimal point inserted, giving the number two decimal places:</p> | <p> | ||
The following sequence converts a 6-byte zoned decimal field beginning in position 20 of the input record to EBCDIC, leaving the result in string buffer 1 with a decimal point inserted, giving the number two decimal places:</p> | |||
<p class="code">CFZ 1,20,6,2 | <p class="code">CFZ 1,20,6,2 | ||
PAYMENT=1|1S,0|1S | PAYMENT=1|1S,0|1S | ||
</p> | </p> | ||
<p>The result has the form:</p> | <p> | ||
<p class=" | The result has the form:</p> | ||
<p class="syntax"><span class="term">sdddd.dd</span> | |||
</p> | </p> | ||
<p> | <p> | ||
< | Where:</p> | ||
< | <ul> | ||
<p>This result is then loaded into the PAYMENT field of the current record from string buffer 1. </p> | <li><var class="term">s</var> represents a blank or minus sign.</li> | ||
<li><var class="term">d</var> represents a digit between 0 and 9. </li> | |||
</ul> | |||
<p> | |||
This result is then loaded into the <code>PAYMENT</code> field of the current record from string buffer 1. </p> | |||
==File Load statements: working with index registers== | ==File Load statements: working with index registers== | ||
<p>A number of work areas called index registers, which are used primarily to manipulate numbers, are available for use within file load programs. The numbers in these index registers are most often used to modify the position or length fields of other file load statements.</p> | <p> | ||
A number of work areas called index registers, which are used primarily to manipulate numbers, are available for use within file load programs. The numbers in these index registers are most often used to modify the position or length fields of other file load statements.</p> | |||
====Number of allowable registers==== | ====Number of allowable registers==== | ||
<p>Index registers are denoted by index register numbers that can range from 1 to the value of the parameter LNTBL, which defaults to 50 (see [[#File load program execution|File load program execution]]). The maximum number of index registers is 255, no matter how large LNTBL is. </p> | <p> | ||
Index registers are denoted by index register numbers that can range from 1 to the value of the parameter <var>LNTBL</var>, which defaults to 50 (see [[#File load program execution|File load program execution]]). The maximum number of index registers is 255, no matter how large <var>LNTBL</var> is. </p> | |||
====Index register size==== | ====Index register size==== | ||
<p>Each index register is four bytes long (a fullword) and can contain number values between -2,147,483,648 and +2,147,483,647, inclusive. </p> | <p> | ||
Each index register is four bytes long (a fullword) and can contain number values between -2,147,483,648 and +2,147,483,647, inclusive. </p> | |||
===Setting an index register=== | ===Setting an index register=== | ||
<p>The I statement has a fairly complicated format. A number of simple forms are discussed first. | <p> | ||
The <var>I</var> statement has a fairly complicated format. A number of simple forms are discussed first. </p> | |||
====Syntax==== | ====Syntax==== | ||
<p class=" | <p> | ||
The basic statement format is:</p> | |||
<p class="syntax">I <span class="term">index</span>,[<span class="term">operands</span>] | |||
</p> | </p> | ||
<p> | <p> | ||
< | Where:</p> | ||
< | <ul> | ||
< | <li><var>I</var> is in column 1. </li> | ||
<li><var class="term">index</var> is the number of the index register to be set.</li> | |||
<li><var class="term">operands</var> are optional operations that modify the indicated index register and can involve input records or other index registers. </li> | |||
</ul> | |||
===Clearing an index register=== | ===Clearing an index register=== | ||
<p>If no optional operands are specified, the I statement sets the specified index register to zero. The following example sets index register 15 to zero:</p> | <p> | ||
If no optional operands are specified, the <var>I</var> statement sets the specified index register to zero. The following example sets index register 15 to zero:</p> | |||
<p class="code">I 15 | <p class="code">I 15 | ||
</p> | </p> | ||
===Setting an index register from the input record=== | ===Setting an index register from the input record=== | ||
<p>As many as four bytes of data from the current input record can be loaded into an index register, | <p> | ||
As many as four bytes of data from the current input record can be loaded into an index register, using the following format:</p> | |||
<p class="syntax">I <span class="term">index</span>,<span class="term">position</span>,<span class="term">length</span> | |||
<p class=" | |||
</p> | </p> | ||
< | <p> | ||
Where <var class="term">length</var> is the number of bytes of data starting at the specified position that are placed into the specified index register right-aligned and padded with binary zeros on the left if length is less than 4. </p> | |||
====Example==== | ====Example==== | ||
<p>The following example loads the first two bytes of the input record into index register 9:</p> | <p> | ||
<p class="code">I 9,1,2 | The following example loads the first two bytes of the input record into index register 9:</p> | ||
<p class="code">I 9,1,2 </p> | |||
<p> | |||
If the input records are variable-length (RECFM=V or VB), index register 9 contains the number of characters of data in the record. | If the input records are variable-length (RECFM=V or VB), index register 9 contains the number of characters of data in the record. | ||
</p> | </p> | ||
===Setting an index register to a constant=== | ===Setting an index register to a constant=== | ||
<p>To set an index register to a specified number:</p> | <p> | ||
To set an index register to a specified number:</p> | |||
====Syntax==== | ====Syntax==== | ||
<p class="code">I <var class="term">index</var>,,,<var class="term">number</var> | <p class="code">I <var class="term">index</var>,,,<var class="term">number</var> | ||
</p> | </p> | ||
<p> | <p> | ||
< | Where <var class="term">number</var>, which can be specified in decimal, hexadecimal (X'<i>xx</i>'), or character (C'<i>c</i>') form, must be between -32,768 and +32,767, inclusive (two bytes). If a larger value is specified, only the low-order two bytes are used.</p> | ||
====Example==== | ====Example==== | ||
<p>The following example sets index register 35 to | <p> | ||
The following example sets index register 35 to minus one:</p> | |||
<p class="code">I 35,,,-1 | <p class="code">I 35,,,-1 | ||
</p> | </p> | ||
===Adding to an index register=== | ===Adding to an index register=== | ||
<p>A number can be added to the contents of an index register and stored back into that register or some other register | <p> | ||
A number can be added to the contents of an index register and stored back into that register or some other register.</p> | |||
====Syntax==== | ====Syntax==== | ||
<p class=" | Use the following format: | ||
<p class="syntax">I <span class="term">index1</span>,,,<span class="term">number</span>|<span class="term">index2</span> | |||
</p> | </p> | ||
<p>The number must conform to the previous rule for a constant.</p> | <p> | ||
The number must conform to the previous rule for a constant.</p> | |||
====Examples==== | ====Examples==== | ||
<p>For example, suppose that index register 23 contains the number 119. The following example sets index register 7 to 124. Register 23 still contains 119:</p> | <p> | ||
For example, suppose that index register 23 contains the number 119. The following example sets index register 7 to 124. Register 23 still contains 119:</p> | |||
<p class="code">I 7,,,5|23 | <p class="code">I 7,,,5|23 | ||
</p> | </p> | ||
<p>The following example changes the contents of register 23 from 119 to 99:</p> | <p> | ||
The following example changes the contents of register 23 from 119 to 99:</p> | |||
<p class="code">I 23,,,-20|23 | <p class="code">I 23,,,-20|23 | ||
</p> | </p> | ||
===Multiplying the contents of an index register=== | ===Multiplying the contents of an index register=== | ||
<p>The contents of an index register can be multiplied by a specified number and the result stored into that register or some other register | <p> | ||
The contents of an index register can be multiplied by a specified number and the result stored into that register or some other register.</p> | |||
====Syntax==== | ====Syntax==== | ||
<p class=" | Use the following format: | ||
<p class="syntax">I <span class="term">index1</span>,,,,<span class="term">number</span>|<span class="term">index2</span> | |||
</p> | </p> | ||
<p>The number must conform to the rule given above for a constant.</p> | <p> | ||
The number must conform to the rule given above for a constant.</p> | |||
====Examples==== | ====Examples==== | ||
<p>For example, suppose that index register 4 contains the number 10. The following example sets index register 5 to -10. Register 4 still contains 10:</p> | <p> | ||
For example, suppose that index register 4 contains the number 10. The following example sets index register 5 to -10. Register 4 still contains 10:</p> | |||
<p class="code">I 5,,,,-1|4 | <p class="code">I 5,,,,-1|4 | ||
</p> | </p> | ||
<p>The following example changes the contents of register 4 from 10 to 70:</p> | <p> | ||
The following example changes the contents of register 4 from 10 to 70:</p> | |||
<p class="code">I 4,,,,7|4 | <p class="code">I 4,,,,7|4 | ||
</p> | </p> | ||
===Full format of I statement=== | ===Full format of I statement=== | ||
<p>The full format of the I statement is:</p> | <p> | ||
The full format of the <var>I</var> statement is:</p> | |||
<p class="syntax">I <span class="term">index1</span>,<span class="term">position</span>,<span class="term">length</span>,<span class="term">number2</span><span class="squareb">|</span><span class="term">index2</span>,<span class="term">number3</span><span class="squareb">|</span><span class="term">index3</span> | |||
<p class=" | |||
</ | |||
</ | |||
</p> | </p> | ||
<p>In this full format the I statement computes the sum of these four quantities: </p> | <p> | ||
In this full format the I statement computes the sum of these four quantities: </p> | |||
<ul> | <ul> | ||
<li>Data field of "length | <li>Data field of <var class="term">length</var> bytes at the specified position of the current input record</li> | ||
<li> | <li><var class="term">number2</var></li> | ||
<li>Contents of index2</li> | <li>Contents of <var class="term">index2</var></li> | ||
<li>Product of number3 and the contents of index3 </li> | <li>Product of <var class="term">number3</var> and the contents of <var class="term">index3</var> </li> | ||
</ul> | </ul> | ||
<p>The sum is then stored in <var class="term">index1</var>.</p> | <p> | ||
<p>length cannot exceed 4. </p> | The sum is then stored in <var class="term">index1</var>.</p> | ||
<p>number2 and number3 should follow the rule given above for a constant.</p> | <p> | ||
<var class="term">length</var> cannot exceed 4. </p> | |||
<p> | |||
<var class="term">number2</var> and <var class="term">number3</var> should follow the rule given above for a constant.</p> | |||
====Example==== | ====Example==== | ||
<p>The following example adds the two bytes at the beginning of the input record, the contents of index register 15, and the contents of register 16, and stores the result in register 14:</p> | <p> | ||
The following example adds the two bytes at the beginning of the input record, the contents of index register 15, and the contents of register 16, and stores the result in register 14:</p> | |||
<p class="code">I 14,1,2,0|15,1|16 | <p class="code">I 14,1,2,0|15,1|16 | ||
</p> | </p> | ||
===Modifying position and length fields=== | ===Modifying position and length fields=== | ||
<p>The position or length fields of most file load statements can be modified by the contents of any index register by immediately following the field with a vertical bar and the number of the index register. That is:</p> | <p> | ||
The position or length fields of most file load statements can be modified by the contents of any index register by immediately following the field with a vertical bar and the number of the index register. That is:</p> | |||
= | <p class="syntax"><span class="squareb">|</span><span class="term">index</span> | ||
< | |||
</p> | </p> | ||
<p>The contents of the index register are added to the position or length number preceding the vertical bar. </p> | <p> | ||
The contents of the index register are added to the position or length number preceding the vertical bar. </p> | |||
====Examples==== | ====Examples==== | ||
<p>For example, if index register 18 contains 5, the following example branches to label 40 if column 8 of the current input record contains a semicolon | <p> | ||
< | For example, if index register 18 contains 5, the following example branches to label 40 if column 8 of the current input record contains a semicolon (<tt>;</tt>): </p> | ||
<p class="code"><b></b>=40,3|18,; | <p class="code"><b></b>=40,3|18,; | ||
</p> | </p> | ||
<p>Suppose that an input record contains a data area in columns 20 through 39 that has a person's name in the format:</p> | <p> | ||
Suppose that an input record contains a data area in columns 20 through 39 that has a person's name in the format:</p> | |||
<p class="code"><var class="term">last_name,first_name</var> | <p class="code"><var class="term">last_name,first_name</var> | ||
</p> | </p> | ||
<p>The following code loads a LAST NAME field composed of everything up to the comma:</p> | <p> | ||
<p class="code">I 4 | The following code loads a <code>LAST NAME</code> field composed of everything up to the comma:</p> | ||
<b></b>#31 | <p class="code">I 4 *Clear index register 4 | ||
<b></b>=32,20|4,, | <b></b>#31 *Top of comma loop check | ||
I 4,,,1|4 | <b></b>=32,20|4,, *Branch to label 32 if comma found | ||
<b></b>=31 | I 4,,,1|4 *Add one to register 4 | ||
<b></b>=31 *Branch back to label 31 | |||
<b></b>#32 | <b></b>#32 | ||
LAST NAME=20,0|4 *Load last name (length in reg 4 | LAST NAME=20,0|4 *Load last name (length in reg 4) | ||
</p> | </p> | ||
===Referring to the contents of index registers=== | ===Referring to the contents of index registers=== | ||
<p>In some cases, an index register can be treated as a data area itself. As such, the index register can be viewed as being four characters long (containing positions 1 through 4).</p> | <p> | ||
<p>Any file load statement that has a position field can refer to a position in a specified index register by replacing:</p> | In some cases, an index register can be treated as a data area itself. As such, the index register can be viewed as being four characters long (containing positions 1 through 4).</p> | ||
<p> | |||
Any file load statement that has a position field can refer to a position in a specified index register by replacing:</p> | |||
<p class="code"><var class="term">position</var> | <p class="code"><var class="term">position</var> | ||
</p> | </p> | ||
<p>with:</p> | <p> | ||
<p class="code"><var class="term">indexposition</var>|<var class="term">index</var | with:</p> | ||
<p class="code"><var class="term">indexposition</var><span class="squareb">|</span><var class="term">index</var>* | |||
</p> | </p> | ||
<p> | <p> | ||
< | Where:</p> | ||
< | <ul> | ||
<p>The following example branches to label 40 if position 4 of index register 11 contains the EBCDIC character 3:</p> | <li><var class="term">indexposition</var> is 1, 2, 3, or 4 (position 1 is the high-order position).</li> | ||
<li><var class="term">index</var> specifies the desired index register. The asterisk replaces the comma that normally follows the position specification. </li> | |||
</ul> | |||
<p> | |||
The following example branches to label 40 if position 4 of index register 11 contains the EBCDIC character 3:</p> | |||
<p class="code"><b></b>=40,4|11*3 | <p class="code"><b></b>=40,4|11*3 | ||
</p> | </p> | ||
<p>The EBCDIC representation for 3 is equal to the number X'F3', or decimal 243. </p> | <p> | ||
The EBCDIC representation for 3 is equal to the number <code>X'F3'</code>, or decimal 243. </p> | |||
====Example==== | ====Example==== | ||
<p>The following example branches to label 35 if the contents of positions 1 through 4 of index register 11 are equal to (condition 8) positions 1 through 4 of register 12. In other words, the following instruction simply compares two index registers: </p> | <p> | ||
The following example branches to label 35 if the contents of positions 1 through 4 of index register 11 are equal to (condition 8) positions 1 through 4 of register 12. In other words, the following instruction simply compares two index registers: </p> | |||
<p class="code">T 35,1|11*4,1|12*8 | <p class="code">T 35,1|11*4,1|12*8 | ||
</p> | </p> | ||
===Printing an index register value=== | ===Printing an index register value=== | ||
<p>The Q statement prints the current numeric value of a specified index register as a decimal number. </p> | <p> | ||
<p>The format is:</p> | The <var>Q</var> statement prints the current numeric value of a specified index register as a decimal number. </p> | ||
<p> | |||
The format is:</p> | |||
<p class=" | <p class="syntax">Q <span class="term">index</span> | ||
</p> | </p> | ||
===File Load statements: | ===File Load statements: updating existing Model 204 records=== | ||
<p>You can use file load programs to update or retrieve data from existing records in the <var class="product">Model 204</var> file as well as to load new records. The FLOD command and JCL are identical to those used for loading new records. The following special purpose file load statements can be used within file load programs to locate existing records, add fields, or determine the current value of an existing field.</p> | <p> | ||
You can use file load programs to update or retrieve data from existing records in the <var class="product">Model 204</var> file as well as to load new records. The <var>FLOD</var> command and JCL are identical to those used for loading new records. The following special purpose file load statements can be used within file load programs to locate existing records, add fields, or determine the current value of an existing field.</p> | |||
===L...ENDL statement (locate existing records)=== | ===L...ENDL statement (locate existing records)=== | ||
<p>The L statement provides a means of locating all the existing records in the <var class="product">Model 204</var> file with a specified field name = value pair. The field must be a KEY or ORDERED field. One pass is then made through a locate loop of file load statements for each record located in this way.</p> | <p class="note"><b>Note:</b> The <var>L</var> and <var>ENDL</var> statements are not supported by [[Fast/Reload statements#Overview|Fast/Reload]]. </p> | ||
< | <p> | ||
The <var>L</var> statement provides a means of locating all the existing records in the <var class="product">Model 204</var> file with a specified field name = value pair. The field must be a <var>KEY</var> or <var>ORDERED</var> field. One pass is then made through a locate loop of file load statements for each record located in this way.</p> | |||
<p>A locate loop that follows an L statement consists of a sequence of file load statements followed by an ENDL statement. You can use any file load statement except one that transfers control to a label outside the loop (that is, a label that is not between the L and ENDL statements). | <p> | ||
During a particular pass, the located record becomes the current record (that is, the record updated by [[#rdLoadStmt|read-and-load-a-field]] statements, <var>[[#delStmt|DELETE]]</var> statements, and so on). Whatever <var class="product">Model 204</var> record was current before the L statement is remembered and becomes the current record again when all the located records have been processed by the locate loop.</p> | |||
<p> | |||
Within an <var>L</var> loop, <var>[[#upStmt|UP]]</var> statements can be used to process records which were current outside the loop.</p> | |||
<p> | |||
If no records contain the specified field name = value pair, no passes are made through the locate loop. </p> | |||
<p> | |||
A locate loop that follows an L statement consists of a sequence of file load statements followed by an <var>ENDL</var> statement. You can use any file load statement except one that transfers control to a label outside the loop (that is, a label that is not between the <var>L</var> and <var>ENDL</var> statements). </p> | |||
====Syntax==== | ====Syntax==== | ||
<p class=" | <p>The format of the <var>L</var> statement is:</p> | ||
<p class="syntax">L {0 | 1},<span class="term">fieldname</span>=<span class="term">index</span>,<span class="term">label</span>[,<span class="term">mode_bits</span>] | |||
. | . | ||
. | . | ||
Line 1,083: | Line 1,421: | ||
ENDL | ENDL | ||
</p> | </p> | ||
<p> | <p> | ||
Where:</p> | |||
<ul> | <ul> | ||
<li>mode_bits are optional and described in [[#File Load statements: mode bits|File Load statements: mode bits]]. If default editing produces the wrong value, you must specify mode bits.</li> | <li><var>L</var> is in column 1.</li> | ||
<li>ENDL ends the locate loop and must start in column 1.</li> | |||
<li>0 or 1 specifies the number of a string buffer that contains the value portion of the field name = value pair.</li> | |||
<li><var class="term">fieldname</var> must specify a field that has the <var>KEY</var> or <var>ORDERED</var> attribute.</li> | |||
<li><var class="term">index</var> specifies the number of any unused index register. The index register is used as a work area by the locate loop.</li> | |||
<li><var class="term">label</var> specifies a label to which control is to be transferred after passes have been made through the locate loop for all the located records. If no records are found by the <var>L</var> statement, control passes immediately to the label. For this reason, the statement after the <var>ENDL</var> always needs a label or it is not executed. </li> | |||
<li><var class="term">mode_bits</var> are optional and described in [[#File Load statements: mode bits|File Load statements: mode bits]]. If default editing produces the wrong value, you must specify mode bits.</li> | |||
<li><var>ENDL</var> ends the locate loop and must start in column 1.</li> | |||
</ul> | </ul> | ||
====Usage==== | ====Usage==== | ||
<p>Locate loops can be nested up to three levels. Each time an L statement is encountered, the current record is remembered and record processing is said to go down one level. When the lower locate loop has processed its records, the record processing goes up one level and the remembered record once again becomes the current record. Each nested locate loop operates a FIND against the whole file of records, not just on the found set of the previous loop. </p> | <p> | ||
<p>Nesting is shown in | Locate loops can be nested up to three levels. Each time an L statement is encountered, the current record is remembered and record processing is said to go down one level. When the lower locate loop has processed its records, the record processing goes up one level and the remembered record once again becomes the current record. Each nested locate loop operates a <var>FIND</var> against the whole file of records, not just on the found set of the previous loop. </p> | ||
<p> | |||
Nesting is shown in the following figure:</p> | |||
== | <p class="caption" style="width:346px">Locate loop nesting</p> | ||
[[File:Locate loop nesting.gif]] | <p class="figure">[[File:Locate loop nesting.gif|346px]]</p> | ||
====Example==== | ====Example==== | ||
<p>Suppose that a <var class="product">Model 204</var> file contains personnel information that includes a last name field. The input data contains last names in columns 1 through 20 followed by as many as three homonyms in columns 21-40, 41-60, and 61-80:</p> | <p> | ||
Suppose that a <var class="product">Model 204</var> file contains personnel information that includes a last name field. The input data contains last names in columns 1 through 20 followed by as many as three homonyms in columns 21-40, 41-60, and 61-80:</p> | |||
<p class="code">FLOD -1,-1,0 | <p class="code">FLOD -1,-1,0 | ||
G | G * Get new input record | ||
S 0,1,20 | S 0,1,20 * Move last name into buffer 0 | ||
L 0,LAST NAME=30,45 *FR WHERE LAST NAME = last name | L 0,LAST NAME=30,45 * FR WHERE LAST NAME = last name | ||
HOMONYM=21,20 | HOMONYM=21,20 * Add Homonym Value | ||
HOMONYM=41,20 * Add Homonym Value | HOMONYM=41,20 * Add Homonym Value | ||
HOMONYM=61,20 | HOMONYM=61,20 * Add Homonym Value | ||
ENDL | ENDL * END FOR | ||
<b></b>#45 | <b></b>#45 | ||
END | END | ||
</p> | </p> | ||
<p>For each input record, the previous procedure locates records that contain a LAST NAME equal to the value in columns 1 through 20. For each such record, as many as three HOMONYM fields are added.</p> | <p> | ||
<p>A locate loop is quite similar to the following | For each input record, the previous procedure locates records that contain a <code>LAST NAME</code> equal to the value in columns 1 through 20. For each such record, as many as three <code>HOMONYM</code> fields are added.</p> | ||
<p> | |||
A locate loop is quite similar to the following SOUL construction:</p> | |||
<p class="code">LOOP: FOR EACH RECORD WHERE fieldname = value | <p class="code">LOOP: FOR EACH RECORD WHERE fieldname = value | ||
. | . | ||
Line 1,123: | Line 1,473: | ||
</p> | </p> | ||
===UP and DOWN statements (change record processing level)=== | ===<b id="upStmt"></b>UP and DOWN statements (change record processing level)=== | ||
<p>The current record processing position can be changed through use of the UP and DOWN statements. The UP and DOWN statements consist of words starting in column 1. They can be used only within locate loops: </p> | <p class="note"><b>Note:</b> The <var>UP</var> and <var>DOWN</var> statements are not supported by [[Fast/Reload statements#Overview|Fast/Reload]]. </p> | ||
<p> | |||
The current record processing position can be changed through use of the <var>UP</var> and <var>DOWN</var> statements. The <var>UP</var> and <var>DOWN</var> statements consist of words starting in column 1. They can be used only within locate loops: </p> | |||
<ul> | <ul> | ||
<li>UP statement causes record processing to go up one level. That is, the record that was remembered by the L statement once again becomes the current record and can be updated.</li> | <li><var>UP</var> statement causes record processing to go up one level. That is, the record that was remembered by the <var>L</var> statement once again becomes the current record and can be updated.</li> | ||
<li>DOWN statement reverses the process, and the record that the locate loop was processing at the time of the UP statement becomes the current record. </li> | |||
<li><var>DOWN</var> statement reverses the process, and the record that the locate loop was processing at the time of the <var>UP</var> statement becomes the current record. </li> | |||
</ul> | </ul> | ||
<p>UP and DOWN statements must always occur in pairs.</p> | <p> | ||
<p>An L statement performs the DOWN function automatically; an ENDL statement performs an automatic UP. </p> | <var>UP</var> and <var>DOWN</var> statements must always occur in pairs.</p> | ||
<p> | |||
An <var>L</var> statement performs the <var>DOWN</var> function automatically; an <var>ENDL</var> statement performs an automatic <var>UP</var>. </p> | |||
====Example==== | ====Example==== | ||
<p>Suppose that a file contains two types of records: "people" records and "child" records. A number of child records are being loaded into the file. Each contains the name of the child's parent. It is assumed that the parent's record already is in the file. Moreover, the input data for the child records does not include addresses. As each child's record is loaded, this file load program locates the child's parent's record, reads its ADDRESS field, and copies it into the new child record:</p> | <p> | ||
Suppose that a file contains two types of records: "people" records and "child" records. A number of child records are being loaded into the file. Each contains the name of the child's parent. It is assumed that the parent's record already is in the file. Moreover, the input data for the child records does not include addresses. As each child's record is loaded, this file load program locates the child's parent's record, reads its <code>ADDRESS</code> field, and copies it into the new child record:</p> | |||
<p class="code">FLOD -1,-1,0 | <p class="code">FLOD -1,-1,0 | ||
G | G | ||
Line 1,154: | Line 1,510: | ||
===F statement (read field values)=== | ===F statement (read field values)=== | ||
<p>The F statement provides a means of reading the current value(s) of a specified field within the current record. One pass is made through an F loop of file load statements for each occurrence of the field within the record. | <p class="note"><b>Note:</b> The <var>F</var> and <var>ENDF</var> statements are not supported by [[Fast/Reload statements#Overview|Fast/Reload]]. </p> | ||
<p> | |||
The <var>F</var> statement provides a means of reading the current value(s) of a specified field within the current record. One pass is made through an <var>F</var> loop of file load statements for each occurrence of the field within the record. </p> | |||
====Syntax==== | ====Syntax==== | ||
<p class=" | <p> | ||
The format of the <var>F</var> statement is:</p> | |||
<p class="syntax">F <span class="term">label</span>,<span class="term">fieldname</span>=<span class="term">index1</span>,<span class="term">index2</span> | |||
</p> | </p> | ||
< | <p> | ||
Where:</p> | |||
<ul> | <ul> | ||
<li>One that transfers control to a label outside the F loop</li> | <li><var>F</var> is in column 1.</li> | ||
<li>L statement </li> | |||
<li>Another F statement</li> | <li><var class="term">label</var> specifies a label to which control is to be transferred after passes have been made through the <var>F</var> loop for all occurrences of the field.</li> | ||
<li>DELETE statement </li> | |||
<li>Delete-field statement that deletes a VISIBLE field </li> | <li><var class="term">fieldname</var> must specify a field that has the <var>VISIBLE</var> attribute.</li> | ||
<li><var class="term">index1</var> and <var class="term">index2</var> specify numbers of index registers not currently in use. | |||
<p> | |||
At the beginning of each pass through the <var>F</var> loop, the value of the field occurrence to be processed in that pass is placed in a special work area, and <var class="term">index1</var> is pointed at that work area. <var class="term">index2</var> contains the length of the current value. Thus, the statements within the <var>F</var> loop can refer to the current value by specifying a position of <code>1|<var class="term">index1</var></code> and a length of <code>0|<var class="term">index2</var></code>. </p> | |||
<p> | |||
After the last pass through the <var>F</var> loop, <var class="term">index1</var> and <var class="term">index2</var> still can be used to refer to the last value processed until another <var>F</var> statement is encountered. </p> | |||
<p> | |||
An <var>F</var> loop following an <var>F</var> statement consists simply of a sequence of file load statements followed by an <var>ENDF</var> statement. Any file load statement can be used except:</p> | |||
<ul> | |||
<li>One that transfers control to a label outside the <var>F</var> loop</li> | |||
<li><var>L</var> statement </li> | |||
<li>Another <var>F</var> statement</li> | |||
<li><var>DELETE</var> statement </li> | |||
<li>Delete-field statement that deletes a <var>VISIBLE</var> field </li> | |||
</ul></li> | |||
</ul> | </ul> | ||
====Example==== | ====Example==== | ||
<p> | <p> | ||
The following statements delete the last occurrence of the <code>CHILD</code> field in the current record:</p> | |||
<p class="code">F 27,CHILD=35,36 | <p class="code">F 27,CHILD=35,36 | ||
ENDF | ENDF | ||
Line 1,183: | Line 1,554: | ||
</p> | </p> | ||
==File Load statements: | ==File Load statements: deleting records and fields== | ||
===Deleting a record=== | ===<b id="delStmt"></b>Deleting a record=== | ||
<p>The DELETE statement deletes the current <var class="product">Model 204</var> record from the file. This statement consists of the word DELETE in column 1. | <p class="note"><b>Note:</b> The <var>DELETE</var> statement is not supported by [[Fast/Reload statements#Overview|Fast/Reload]]. </p> | ||
<p>The following procedure deletes <var class="product">Model 204</var> records whose Social Security numbers correspond to those read from the input file:</p> | <p> | ||
The <var>DELETE</var> statement deletes the current <var class="product">Model 204</var> record from the file. This statement consists of the word <var>DELETE</var> in column 1. </p> | |||
<p> | |||
The following procedure deletes <var class="product">Model 204</var> records whose Social Security numbers correspond to those read from the input file:</p> | |||
<p class="code">FLOD -1,-1,0 | <p class="code">FLOD -1,-1,0 | ||
G | G * Get an input record | ||
S 1,1,9 | S 1,1,9 * Move SSN to string buffer 1 | ||
L 1,SOC.SEC.NO=47,15 * FOR EACH matching M204 record | L 1,SOC.SEC.NO=47,15 * FOR EACH matching M204 record | ||
DELETE | DELETE * Delete the record | ||
ENDL | ENDL * END FOR | ||
<b></b>#15 | <b></b>#15 | ||
END | END | ||
</p> | </p> | ||
<p>The FLOD run must be a multiuser run in order for the NON-DEFFERABLE attribute to take effect at all. How to set up a multiuser run so that the NON-DEFERRABLE attribute takes effect is described in | <p> | ||
<p>Two variations of the read-and-load-a-field statement allow you to delete fields from the current record. One form is limited to deleting VISIBLE fields only. The other form can be used to delete VISIBLE, INVISIBLE, and multiply occurring fields. Descriptions of both variations follow.</p> | The <var>FLOD</var> run must be a multiuser run in order for the <var>NON-DEFFERABLE</var> attribute to take effect at all. How to set up a multiuser run so that the <var>NON-DEFERRABLE</var> attribute takes effect is described in [[Deferred update feature#Overriding deferred updates|Overriding deferred updates]]. </p> | ||
<p> | |||
Two variations of the read-and-load-a-field statement allow you to delete fields from the current record. One form is limited to deleting <var>VISIBLE</var> fields only. The other form can be used to delete <var>VISIBLE</var>, <var>INVISIBLE</var>, and multiply occurring fields. Descriptions of both variations follow.</p> | |||
===Deleting a VISIBLE field=== | ===Deleting a VISIBLE field=== | ||
<p>The format of the statement used to delete a VISIBLE field is:</p> | <p> | ||
The format of the statement used to delete a <var>VISIBLE</var> field is:</p> | |||
<p class="syntax"><span class="term">fieldname</span>=1,1,X'5800' | |||
<p class=" | |||
</p> | </p> | ||
<p> | <p> | ||
< | Where:</p> | ||
< | <ul> | ||
< | <li><var class="term">fieldname</var> must start in column 2 and must specify a field that has the <var>VISIBLE</var> attribute. If the field occurs in the current record more than once (for example, a <code>CHILD</code> field), only the first occurrence is deleted.</li> | ||
<li>1's are position and length indicators (as in the following subsection).</li> | |||
<li>X'5800' is a combination of mode bit options (see [[#File Load statements: mode bits|File Load statements: mode bits]]). </li> | |||
</ul> | |||
====Example==== | ====Example==== | ||
<p>The following procedure changes the ADDRESS fields of <var class="product">Model 204</var> records whose Social Security numbers are provided in columns 1 through 9 of the input records. The new addresses are in columns 10 through 59:</p> | <p> | ||
The following procedure changes the <code>ADDRESS</code> fields of <var class="product">Model 204</var> records whose Social Security numbers are provided in columns 1 through 9 of the input records. The new addresses are in columns 10 through 59:</p> | |||
<p class="code">FLOD -1,-1,0 | <p class="code">FLOD -1,-1,0 | ||
G | G | ||
S 0,1,9 | S 0,1,9 * Move SSN into string buffer 0 | ||
L 0,SOC.SEC.NO=15,20 | L 0,SOC.SEC.NO=15,20 * FR WHERE SOC.SEC.NO=value | ||
ADDRESS=1,1,X'5800' * Delete old address | ADDRESS=1,1,X'5800' * Delete old address | ||
ADDRESS=10,50 | ADDRESS=10,50 * Add new address | ||
ENDL | ENDL * END FOR | ||
<b></b>#20 | <b></b>#20 | ||
END | END | ||
Line 1,226: | Line 1,608: | ||
===Deleting specific values=== | ===Deleting specific values=== | ||
<p>Use this form of the read-and-load-a-field statement to delete any field value, even if it is INVISIBLE or a value in a multiply occurring field. | <p> | ||
Use this form of the read-and-load-a-field statement to delete any field value, even if it is <var>INVISIBLE</var> or a value in a multiply occurring field.</p> | |||
====Syntax==== | ====Syntax==== | ||
<p class=" | <p> | ||
The format of the statement used to delete a specific occurrence of a field is:</p> | |||
<p class="syntax"><span class="term">fieldname</span>=<span class="term">position</span>,<span class="term">length</span>,X'4000' | |||
</p> | </p> | ||
<p> | <p> | ||
< | Where:</p> | ||
< | <ul> | ||
< | <li><var class="term">fieldname</var> must start in column 2 and is followed immediately by an equal sign.</li> | ||
< | |||
<li><var class="term">position</var> specifies the starting position within the current input record (or string buffer) of the specific value to be deleted.</li> | |||
<li><var class="term">length</var> specifies the length of the value.</li> | |||
<li>X'4000' is the mode bit option for deleting a field (see [[#File Load statements: mode bits|File Load statements: mode bits]]). </li> | |||
</ul> | |||
<p>This delete-field statement differs from the first delete-field statement in the following ways:</p> | <p>This delete-field statement differs from the first delete-field statement in the following ways:</p> | ||
<ul> | <ul> | ||
<li>Value must be specified as well as the field name.</li> | <li>Value must be specified as well as the field name.</li> | ||
<li>Form can be used to delete INVISIBLE fields as well as VISIBLE fields.</li> | <li>Form can be used to delete <var>INVISIBLE</var> fields as well as <var>VISIBLE</var> fields.</li> | ||
<li>It can be used to delete the second, third, and subsequent occurrences of a multiply occurring field, as well as the first occurrence. | <li>It can be used to delete the second, third, and subsequent occurrences of a multiply occurring field, as well as the first occurrence. </li> | ||
</ul> | </ul> | ||
===Deleting records=== | ===Deleting records=== | ||
<p>The date-time stamp feature does not include support for DELETE RECORD or DELETE RECORDS processing. DELETE RECORD or DELETE RECORDS processing must be handled by your application software.</p> | <p> | ||
<p>As well, you can use logical delete techniques. However, in all forms of deleting records, it is your responsibility to maintain a log of record deletions, if you want one.</p> | The date-time stamp feature does not include support for <var>DELETE RECORD</var> or <var>DELETE RECORDS</var> processing. <var>DELETE RECORD</var> or <var>DELETE RECORDS</var> processing must be handled by your application software.</p> | ||
<p> | |||
As well, you can use logical delete techniques. However, in all forms of deleting records, it is your responsibility to maintain a log of record deletions, if you want one.</p> | |||
====Handling the date-time stamp field in a file==== | ====Handling the date-time stamp field in a file==== | ||
<p>The DELETE FIELD command is prohibited for the DTSFN field in a file when the FOPT | <p> | ||
<p class="code">M204.2727: | The <var>DELETE FIELD</var> command is prohibited for the <var>DTSFN</var> field in a file when the <var>FOPT</var> X'10' bit is set. Attempting to do so results in the following message:</p> | ||
<p class="code">M204.2727: Can't delete DTS field when FOPT=X'10' is on | |||
</p> | </p> | ||
Line 1,256: | Line 1,651: | ||
===File load program phases=== | ===File load program phases=== | ||
<p>The file load program is processed in two phases. First, all of the statements between the FLOD command and the END statement are compiled. If any errors are detected, such as invalid field names or field-level security violations, the file load program is not executed.</p> | <p> | ||
<p>If the compilation is successful, the procedure is executed.</p> | The file load program is processed in two phases. First, all of the statements between the <var>FLOD</var> command and the <var>END</var> statement are compiled. If any errors are detected, such as invalid field names or field-level security violations, the file load program is not executed.</p> | ||
<p> | |||
If the compilation is successful, the procedure is executed.</p> | |||
===Internal file load optimization feature=== | ===Internal file load optimization feature=== | ||
<p>Most file load programs add records to a new or partially loaded entry order file (where new records are always added at the end of the file). The internal file load optimization feature greatly optimizes file load program performance in such situations. </p> | <p> | ||
<p>The internal file load optimization feature also enhances performance when loading records into new or reinitialized Reuse Record Number (RRN) files. </p> | Most file load programs add records to a new or partially loaded entry order file (where new records are always added at the end of the file). The internal file load optimization feature greatly optimizes file load program performance in such situations. </p> | ||
<p>In other environments, such as sorted, hash key, and unordered files, or for file load programs containing statements that examine or modify data already in the file (DELETE, F, L, or a statement having the X'4000' (delete) mode bit), the internal file load optimization feature is automatically turned off. </p> | <p> | ||
The internal file load optimization feature also enhances performance when loading records into new or reinitialized Reuse Record Number (<var>RRN</var>) files. </p> | |||
<p> | |||
In other environments, such as sorted, hash key, and unordered files, or for file load programs containing statements that examine or modify data already in the file (<var>DELETE</var>, <var>F</var>, <var>L</var>, or a statement having the X'4000' (delete) mode bit), the internal file load optimization feature is automatically turned off. </p> | |||
===Storage tables=== | ===Storage tables=== | ||
<p>File load programs are compiled into various storage and work areas. These areas consist of the following tables: </p> | <p> | ||
File load programs are compiled into various storage and work areas. These areas consist of the following tables: </p> | |||
<table> | <table> | ||
<tr class="head"> | <tr class="head"> | ||
Line 1,271: | Line 1,672: | ||
<th>Contains...</th> | <th>Contains...</th> | ||
</tr> | </tr> | ||
<tr> | <tr> | ||
<td>NTBL</td> | <td>NTBL</td> | ||
<td>Label definitions and index registers. Each NTBL entry is shared by the label and index register having the same number. The size of NTBL determines the highest number that can be used. </td> | <td>Label definitions and index registers. Each NTBL entry is shared by the label and index register having the same number. The size of NTBL determines the highest number that can be used. </td> | ||
</tr> | </tr> | ||
<tr> | <tr> | ||
<td>QTBL </td> | <td>QTBL </td> | ||
<td>Statements in internal form. Each file load statement generates one QTBL entry. Entry sizes vary, but most entries are between 12 and 20 bytes long. Important exceptions are the read-and-load-a-field entry, which expands by 4 bytes for each entry in a translation table, and the CASE entry, which starts at 12 bytes and adds 8 bytes for every branch table entry. </td> | <td>Statements in internal form. Each file load statement generates one QTBL entry. Entry sizes vary, but most entries are between 12 and 20 bytes long. Important exceptions are the read-and-load-a-field entry, which expands by 4 bytes for each entry in a translation table, and the <var>CASE</var> entry, which starts at 12 bytes and adds 8 bytes for every branch table entry. </td> | ||
</tr> | </tr> | ||
<tr> | <tr> | ||
<td>STBL </td> | <td>STBL </td> | ||
<td>All character strings specified for translation tables, CASE statements, and LDC statements. Each string is preceded by a 1-byte length. </td> | <td>All character strings specified for translation tables, <var>CASE</var> statements, and <var>LDC</var> statements. Each string is preceded by a 1-byte length. </td> | ||
</tr> | </tr> | ||
<tr> | <tr> | ||
<td>VTBL </td> | <td>VTBL </td> | ||
Line 1,288: | Line 1,693: | ||
</tr> | </tr> | ||
</table> | </table> | ||
<p>The size of each table is determined by a parameter that can be set in the File Load job. These parameters are LNTBL, LQTBL, LSTBL, and LVTBL. For more information about these tables see | <p> | ||
The size of each table is determined by a parameter that can be set in the File Load job. These parameters are <var>LNTBL</var>, <var>LQTBL</var>, <var>LSTBL</var>, and <var>LVTBL</var>. For more information about these tables, see [[Large request considerations#Description of tables|Description of tables]]. </p> | |||
===FLOD and FILELOAD exits=== | ===FLOD and FILELOAD exits=== | ||
<p>FLOD or FILELOAD | <p> | ||
<var>FLOD</var> or <var>FILELOAD</var> exits pass control from <var>FLOD</var> to an Assembler or COBOL program, which allows you more sophisticated data manipulation capabilities. For complete information about these exits, see [[FLOD exits]].</p> | |||
==Error conditions== | ==Error conditions== | ||
<p>This section describes the file load program error conditions that <var class="product">Model 204</var> can encounter because of preallocated field and field-level security violations. </p> | <p> | ||
< | This section describes the file load program error conditions that <var class="product">Model 204</var> can encounter because of preallocated field and field-level security violations. </p> | ||
<p> | |||
Errors generated during file load program evaluation are <b>counting errors</b>, which are described in [[Terminal session#Counting errors|Counting errors]]. If the number of errors encountered during evaluation reaches the limit specified in the <var>ERMX</var> parameter, the file load program is terminated and the user is restarted. </p> | |||
====File load performance==== | ====File load performance==== | ||
<p>The order in which fields are loaded affects the speed with which the file load program executes. This is particularly true when the go-faster feature is in effect. Execution speed can be optimized by loading preallocated fields before all other fields.</p> | <p> | ||
The order in which fields are loaded affects the speed with which the file load program executes. This is particularly true when the go-faster feature is in effect. Execution speed can be optimized by loading preallocated fields before all other fields.</p> | |||
===Preallocated field violations=== | ===Preallocated field violations=== | ||
<p>If you try to load values in a preallocated field that are longer than the length specified in the field's LENGTH option or you try to add more occurrences to a preallocated field than are specified in the field's OCCURS option, an error is generated during the file load program evaluation. The value lengths specified in file load statements are not checked during compilation. Instead, actual value lengths are checked during evaluation, after blanks have been deleted and leading zeroes have been stripped. | <p> | ||
<p><var class="product">Model 204</var> handles length and occurrence errors by issuing time error messages that specify the relevant field name and the internal record number of the record that <var class="product">Model 204</var> was processing when the error was encountered.</p> | If you try to load values in a preallocated field that are longer than the length specified in the field's <var>LENGTH</var> option or you try to add more occurrences to a preallocated field than are specified in the field's <var>OCCURS</var> option, an error is generated during the file load program evaluation. The value lengths specified in file load statements are not checked during compilation. Instead, actual value lengths are checked during evaluation, after blanks have been deleted and leading zeroes have been stripped. </p> | ||
<p>Except in the case of the LDRF (load-repeating-field) statement, nothing is stored for the statement that causes the error, and evaluation continues with the next file load statement. For LDRF, the occurrence causing the error is not stored, but <var class="product">Model 204</var> attempts to load subsequent values.</p> | <p> | ||
<var class="product">Model 204</var> handles length and occurrence errors by issuing time error messages that specify the relevant field name and the internal record number of the record that <var class="product">Model 204</var> was processing when the error was encountered.</p> | |||
<p> | |||
Except in the case of the LDRF (load-repeating-field) statement, nothing is stored for the statement that causes the error, and evaluation continues with the next file load statement. For LDRF, the occurrence causing the error is not stored, but <var class="product">Model 204</var> attempts to load subsequent values.</p> | |||
===Field-level security violations=== | ===Field-level security violations=== | ||
<p>All field-level security (FLS) violations, except those occurring in a D statement used to load field = value pairs from the input data, can be detected during compilation of a file load program. FLS violations detected during compilation result in counting error messages that prevent evaluation of the file load program. An FLS violation that results from the compilation of a D statement produces error messages that identify the input record number, the relevant field name, and the internal record number of the record that was being built when the error was encountered. The field is not stored in the file. </p> | <p> | ||
All field-level security (FLS) violations, except those occurring in a <var>D</var> statement used to load field = value pairs from the input data, can be detected during compilation of a file load program. FLS violations detected during compilation result in counting error messages that prevent evaluation of the file load program. An FLS violation that results from the compilation of a <var>D</var> statement produces error messages that identify the input record number, the relevant field name, and the internal record number of the record that was being built when the error was encountered. The field is not stored in the file. </p> | |||
===AT-MOST-ONE field violations=== | ===AT-MOST-ONE field violations=== | ||
<p>When you use FLOD or FILELOAD to load or modify records that have AT-MOST-ONE fields, <var class="product">Model 204</var> ensures that the new or modified records do not violate AT-MOST-ONE constraints. <var class="product">Model 204</var> detects and reports all violations of AT-MOST-ONE in one pass of the input data. If <var class="product">Model 204</var> finds any fields that violate the constraints, the following occurs:</p> | <p> | ||
When you use <var>FLOD</var> or <var>FILELOAD</var> to load or modify records that have <var>AT-MOST-ONE</var> fields, <var class="product">Model 204</var> ensures that the new or modified records do not violate <var>AT-MOST-ONE</var> constraints. <var class="product">Model 204</var> detects and reports all violations of <var>AT-MOST-ONE</var> in one pass of the input data. If <var class="product">Model 204</var> finds any fields that violate the constraints, the following occurs:</p> | |||
<ol> | <ol> | ||
<li>Error is reported and the new or duplicate field is rejected.</li> | <li>Error is reported and the new or duplicate field is rejected.</li> | ||
<li>FLOD continues processing the input data.</li> | |||
<li><var>FLOD</var> continues processing the input data.</li> | |||
<li>At the end of the run, the file is marked "logically inconsistent."</li> | <li>At the end of the run, the file is marked "logically inconsistent."</li> | ||
<li> | |||
<p class="code">M204.2119: AT-MOST-ONE CONSTRAINT VIOLATION IN RECORD < | <li>The following error message is issued for each violation: | ||
<p class="code">M204.2119: AT-MOST-ONE CONSTRAINT VIOLATION IN RECORD <i>recno</i>, FIELD IGNORED: <i>field</i>=<var class="term">value</var> | |||
</p></li> | </p></li> | ||
</ol> | </ol> | ||
===NUMERIC VALIDATION file violations=== | ===NUMERIC VALIDATION file violations=== | ||
<p>When loading or modifying records in NUMERIC VALIDATION files using FLOD or FILELOAD, <var class="product">Model 204</var> ensures that the new or modified FLOAT and BINARY fields do not violate NUMERIC VALIDATION constraints. <var class="product">Model 204</var> detects and reports all FLOAT and BINARY violations. If <var class="product">Model 204</var> finds any numeric data type violations, the following occurs:</p> | <p> | ||
When loading or modifying records in <var>NUMERIC VALIDATION</var> files using <var>FLOD</var> or <var>FILELOAD</var>, <var class="product">Model 204</var> ensures that the new or modified <var>FLOAT</var> and <var>BINARY</var> fields do not violate <var>NUMERIC VALIDATION</var> constraints. <var class="product">Model 204</var> detects and reports all <var>FLOAT</var> and <var>BINARY</var> violations. If <var class="product">Model 204</var> finds any numeric data type violations, the following occurs:</p> | |||
<ol> | <ol> | ||
<li>Error is reported with one of the following messages and the field is rejected.</li> | <li>Error is reported with one of the following messages and the field is rejected.</li> | ||
<li>FLOD (or FILELOAD) continues processing the input data.</li> | |||
<li>At the end of the run, the file is marked "logically inconsistent;" that is, the FISTAT parameter is set to X'40'.</li> | <li><var>FLOD</var> (or <var>FILELOAD</var>) continues processing the input data.</li> | ||
<li>At the end of the run, the file is marked "logically inconsistent;" that is, the <var>[[FISTAT parameter|FISTAT]]</var> parameter is set to X'40'.</li> | |||
<li>One of the following error messages is issued for each violation: | <li>One of the following error messages is issued for each violation: | ||
<p class="code">M204.2123: VALUE SPECIFIED VIOLATES BINARY DATA TYPE VALIDATION IN RECORD < | <p class="code">M204.2123: VALUE SPECIFIED VIOLATES BINARY DATA TYPE VALIDATION IN RECORD <i>recno</i>, | ||
< | FIELD IGNORED: <i>field</i> = <i>value</i> | ||
M204.2124: VALUE SPECIFIED VIOLATES FLOAT DATA TYPE VALIDATION IN RECORD < | M204.2124: VALUE SPECIFIED VIOLATES FLOAT DATA TYPE VALIDATION IN RECORD <i>recno</i>, | ||
< | FIELD IGNORED: <i>field</i> = <i>value</i> | ||
</p></li> | </p></li> | ||
</ol> | </ol> | ||
==Syntax of File Load statements== | ==Syntax of File Load statements== | ||
<p>This section provides the complete syntax of the FILELOAD and FLOD commands and all the file load statements. </p> | <p> | ||
This section provides the complete syntax of the <var>FILELOAD</var> and <var>FLOD</var> commands and all the file load statements. </p> | |||
===FILELOAD command=== | ===FILELOAD command=== | ||
<p>The FILELOAD command has the following format:</p> | <p> | ||
The <var>FILELOAD</var> command has the following format:</p> | |||
====Syntax==== | ====Syntax==== | ||
<p class=" | <p class="syntax">FILELOAD <span class="term">k,n,m</span> [,[<span class="term">s1</span>] [,[<span class="term">s2</span>] [,[<span class="term">s3</span>] [,[<span class="term">s4</span>] [,<span class="term">vl</span>]]]]] | ||
</p> | </p> | ||
<p> | <p> | ||
< | Where:</p> | ||
< | <ul> | ||
< | <li><var class="term">k</var> is the maximum number of records loaded.</li> | ||
< | |||
< | <li><var class="term">n</var> is the maximum number of passes through the file load procedure.</li> | ||
< | |||
< | <li><var class="term">m</var> is the number of input records to skip before starting the load process.</li> | ||
< | |||
<li><var class="term">s1</var> is the amount of memory used for sorting the deferred update index records.</li> | |||
<li><var class="term">s2</var> is the amount of memory used for sorting the deferred update <var>FRV</var> index records.</li> | |||
<li><var class="term">s3</var> is the amount of memory allocated for the two buffers used to pass data from <var class="product">Model 204</var> to the sorts.</li> | |||
<li><var class="term">s4</var> is the amount of memory allocated for the two buffers used to pass data from the sorts to <var class="product">Model 204</var>.</li> | |||
<li><var class="term">vl</var> is the maximum sort record length in variable-length record sorts. (<var class="term">vl</var> corresponds to the <var class="term">L2</var> of the <var>RECORD</var> sort statement.) | |||
<p> | |||
The <var class="term">vl</var> parameter must be present for one-step File Load runs that update <var>ORDERED</var> fields. </p></li> | |||
</ul> | |||
===FLOD command=== | ===FLOD command=== | ||
====Syntax==== | ====Syntax==== | ||
<p class=" | <p class="syntax">FLOD <span class="term">k,n,m </span> | ||
</p> | </p> | ||
<p> | <p> | ||
Where: </p> | |||
<ul> | <ul> | ||
<li>k, n, and m have the same meanings as in FILELOAD. </li> | <li><var class="term">k</var>, <var class="term">n</var>, and <var class="term">m</var> have the same meanings as in <var>FILELOAD</var>. </li> | ||
</ul> | </ul> | ||
===Abbreviations=== | ===Abbreviations=== | ||
<p>The following abbreviations and terms are used: </p> | <p> | ||
The following abbreviations and terms are used: </p> | |||
<table> | <table> | ||
<tr class="head"> | <tr class="head"> | ||
Line 1,371: | Line 1,808: | ||
<th>Definition</th> | <th>Definition</th> | ||
</tr> | </tr> | ||
<tr> | <tr> | ||
<td>i</td> | <td>i</td> | ||
<td>Index register number</td> | <td>Index register number</td> | ||
</tr> | </tr> | ||
<tr> | <tr> | ||
<td | <td> | ||
<p>len</p> | <p>len</p> | ||
<p>n</p> | <p>n</p> | ||
Line 1,382: | Line 1,821: | ||
<p>n|i</p> | <p>n|i</p> | ||
</td> | </td> | ||
<td | <td> | ||
<p>Length, specified as one of:</p> | <p>Length, specified as one of:</p> | ||
<p>Number</p> | <p>Number</p> | ||
Line 1,389: | Line 1,828: | ||
</td> | </td> | ||
</tr> | </tr> | ||
<tr> | <tr> | ||
<td> | |||
<p>mode</p> | |||
<td | |||
<p>mode | |||
</p> | |||
<p>X'8000'</p> | <p>X'8000'</p> | ||
<p>X'4000'</p> | <p>X'4000'</p> | ||
Line 1,411: | Line 1,844: | ||
<p>X'4000'</p> | <p>X'4000'</p> | ||
</td> | </td> | ||
<td | <td> | ||
<p>Four-digit hexadecimal number indicating field-loading options:</p> | <p>Four-digit hexadecimal number indicating field-loading options:</p> | ||
<p>Begin a new record</p> | <p>Begin a new record</p> | ||
Line 1,426: | Line 1,859: | ||
</td> | </td> | ||
</tr> | </tr> | ||
<tr> | <tr> | ||
<td>n,m</td> | <td>n,m</td> | ||
<td>Decimal integers</td> | <td>Decimal integers</td> | ||
</tr> | </tr> | ||
<tr> | <tr> | ||
<td | <td> | ||
<p>p</p> | <p>p</p> | ||
<p | <p>n</p> | ||
<p> | <p>n|sS</p> | ||
<p> | <p>n|i</p> | ||
</td> | </td> | ||
<td | <td> | ||
<p>Position, specified as one of:</p> | <p>Position, specified as one of:</p> | ||
<p>Position in current input record</p> | <p>Position in current input record</p> | ||
<p>Position in string buffer s</p> | <p>Position in string buffer s</p> | ||
<p>Followed by | <p>Followed by <code>,</code>: n + contents of index register i is position in current input record </p> | ||
<p>Followed by | <p>Followed by <code>*</code>: n is position in index register <var class="term">i</var></p> | ||
</td> | </td> | ||
</tr> | </tr> | ||
<tr> | <tr> | ||
<td>s</td> | <td>s</td> | ||
Line 1,480: | Line 1,886: | ||
</tr> | </tr> | ||
</table> | </table> | ||
<p>The statements are listed in alphabetical order. Replace elements in | |||
<p> | |||
The statements are listed in alphabetical order. Replace elements in lowercase. Uppercase elements appear as shown.</p> | |||
<table> | <table> | ||
<tr class="head"> | <tr class="head"> | ||
Line 1,486: | Line 1,894: | ||
<th>Action </th> | <th>Action </th> | ||
</tr> | </tr> | ||
<tr> | <tr> | ||
<td> | <td> | ||
<p class=" | <p class="codeInTable">field=p,len,mode | ||
</p></td> | </p></td> | ||
<td>Read-and-load-a-field</td> | <td><p>Read-and-load-a-field</p></td> | ||
</tr> | </tr> | ||
<tr> | <tr> | ||
<td | <td> | ||
<p class=" | <p class="codeInTable">CASE p,len | ||
string1=label1 | string1=label1 | ||
Line 1,503: | Line 1,913: | ||
ENDCASE | ENDCASE | ||
</p></td> | </p></td> | ||
<td | <td><p>Branch based on string value </p></td> | ||
</ | |||
</tr> | </tr> | ||
<tr> | <tr> | ||
<td> | <td> | ||
<p class=" | <p class="codeInTable">CFB s,p,len | ||
</p></td> | </p></td> | ||
<td>Convert from binary</td> | <td><p>Convert from binary</p></td> | ||
</tr> | </tr> | ||
<tr> | <tr> | ||
<td> | <td> | ||
<p class=" | <p class="codeInTable">CFF s,p,len | ||
</p></td> | </p></td> | ||
<td>Convert from floating point</td> | <td><p>Convert from floating point</p></td> | ||
</tr> | </tr> | ||
<tr> | <tr> | ||
<td> | <td> | ||
<p class=" | <p class="codeInTable">CFP s,p,len,decimal-places | ||
decimal places | |||
</p></td> | </p></td> | ||
<td>Convert from packed decimal</td> | <td><p>Convert from packed decimal</p></td> | ||
</tr> | </tr> | ||
<tr> | <tr> | ||
<td> | <td> | ||
<p class=" | <p class="codeInTable">CFZ s,p,len,decimal-places | ||
decimal places | |||
</p></td> | </p></td> | ||
<td>Convert from zoned decimal</td> | <td><p>Convert from zoned decimal</p></td> | ||
</tr> | </tr> | ||
<tr> | <tr> | ||
<td> | <td> | ||
<p class=" | <p class="codeInTable">D p1,len1=p2,len2,mode | ||
</p></td> | </p></td> | ||
<td>Read and load field name and value</td> | <td><p>Read and load field name and value</p></td> | ||
</tr> | </tr> | ||
<tr> | <tr> | ||
<td> | <td> | ||
<p class=" | <p class="codeInTable">DELETE | ||
</p></td> | </p></td> | ||
<td>Delete current record</td> | <td><p>Delete current record</p></td> | ||
</tr> | </tr> | ||
<tr> | <tr> | ||
<td> | <td> | ||
<p class=" | <p class="codeInTable">DOWN | ||
</p></td> | </p></td> | ||
<td>Go down one locate level</td> | <td><p>Go down one locate level</p></td> | ||
</tr> | </tr> | ||
<tr> | <tr> | ||
<td> | <td> | ||
<p class=" | <p class="codeInTable">END | ||
</p></td> | </p></td> | ||
<td>End of file load program</td> | <td><p>End of file load program</p></td> | ||
</tr> | </tr> | ||
<tr> | <tr> | ||
<td> | <td> | ||
<p class=" | <p class="codeInTable">ENDF | ||
</p></td> | </p></td> | ||
<td>End of F loop</td> | <td><p>End of F loop</p></td> | ||
</tr> | </tr> | ||
<tr> | <tr> | ||
<td> | <td> | ||
<p class=" | <p class="codeInTable">ENDL | ||
</p></td> | </p></td> | ||
<td>End of L (locate) loop</td> | <td><p>End of L (locate) loop</p></td> | ||
</tr> | </tr> | ||
<tr> | <tr> | ||
<td | <td> | ||
<p class=" | <p class="codeInTable">F label,field=i1,i2 | ||
</p></td> | </p></td> | ||
<td | <td><p>Read field value from current record</p></td> | ||
</ | |||
</tr> | </tr> | ||
<tr> | <tr> | ||
<td> | <td> | ||
<p class=" | <p class="codeInTable">G | ||
</p></td> | </p></td> | ||
<td>Get new input record</td> | <td><p>Get new input record</p></td> | ||
</tr> | </tr> | ||
<tr> | <tr> | ||
<td | <td> | ||
<p class=" | <p class="codeInTable">I i1,p,len,n|i2,m|i3 | ||
</p></td> | </p></td> | ||
<td | <td><p>Set i1 to (value of data in position p for len bytes) + n + i2 + (m * i3)</p></td> | ||
</ | |||
</tr> | </tr> | ||
<tr> | <tr> | ||
<td> | <td> | ||
<p class=" | <p class="codeInTable">L s,field=i,label | ||
</p></td> | </p></td> | ||
<td>Locate field = string buffer value</td> | <td><p>Locate field = string buffer value</p></td> | ||
</tr> | </tr> | ||
<tr> | <tr> | ||
<td> | <td> | ||
<p class=" | <p class="codeInTable">LDC field=value=mode | ||
mode | |||
</p></td> | </p></td> | ||
<td>Load constant field</td> | <td><p>Load constant field</p></td> | ||
</tr> | </tr> | ||
<tr> | <tr> | ||
<td> | <td> | ||
<p class=" | <p class="codeInTable">LOADNULLS ON|OFF | ||
</p></td> | </p></td> | ||
<td>Load null values</td> | <td><p>Load null values</p></td> | ||
</tr> | </tr> | ||
<tr> | <tr> | ||
<td | <td nowrap> | ||
<p class=" | <p class="codeInTable">LDRF field=p1,len1,p2,len2,i,mode | ||
</p></td> | </p></td> | ||
<td | <td><p>Load repeating field</p></td> | ||
</ | |||
</tr> | </tr> | ||
<tr> | <tr> | ||
<td> | <td> | ||
<p class=" | <p class="codeInTable">M s,p,len | ||
</p></td> | </p></td> | ||
<td>Append value to string buffer</td> | <td><p>Append value to string buffer</p></td> | ||
</tr> | </tr> | ||
<tr> | <tr> | ||
<td> | <td> | ||
<p class=" | <p class="codeInTable">MC s,value | ||
</p></td> | </p></td> | ||
<td>Append constant to string buffer</td> | <td><p>Append constant to string buffer</p></td> | ||
</tr> | </tr> | ||
<tr> | <tr> | ||
<td> | <td> | ||
<p class=" | <p class="codeInTable">P p,len | ||
</p></td> | </p></td> | ||
<td>Print value</td> | <td><p>Print value</p></td> | ||
</tr> | </tr> | ||
<tr> | <tr> | ||
<td> | <td> | ||
<p class=" | <p class="codeInTable">Q i | ||
</p></td> | </p></td> | ||
<td>Print value in index register</td> | <td><p>Print value in index register</p></td> | ||
</tr> | </tr> | ||
<tr> | <tr> | ||
<td> | <td> | ||
<p class=" | <p class="codeInTable">S s,p,len | ||
</p></td> | </p></td> | ||
<td>Clear string buffer and load value | <td><p>Clear string buffer and load value</p></td> | ||
</p></td | |||
</tr> | </tr> | ||
<tr> | <tr> | ||
<td> | <td> | ||
<p class=" | <p class="codeInTable">SC s,value | ||
</p></td> | </p></td> | ||
<td> | <td><p>Clear string buffer and load constant</p></td> | ||
</tr> | </tr> | ||
<tr> | <tr> | ||
<td> | <td> | ||
<p class=" | <p class="codeInTable">STOP | ||
</p></td> | </p></td> | ||
<td> | <td><p>Stop file load program </p></td> | ||
</tr> | </tr> | ||
<tr> | <tr> | ||
<td nowrap> | |||
<p class="codeInTable">T label,p1,len,p2,condition </p> | |||
where condition can be: | |||
<table> | |||
<tr><td>2</td><td>Greater than</td></tr> | |||
<tr><td>4</td><td>Less than</td></tr> | |||
<tr><td>7</td><td>Not equal to</td></tr> | |||
<tr><td>8</td><td>Equal to</td></tr> | |||
<tr><td>11</td><td>Greater than or equal to</td></tr> | |||
<tr><td>13</td><td>Less than or equal to</td></tr> | |||
</table> | |||
</td> | |||
<td><p>Compare strings and branch conditionally</p></td> | |||
</tr> | </tr> | ||
<tr> | <tr> | ||
<td> | <td> | ||
<p class=" | <p class="codeInTable">UP | ||
</p></td> | </p></td> | ||
<td>Go up one locate level </td> | <td><p>Go up one locate level </p></td> | ||
</tr> | </tr> | ||
<tr> | <tr> | ||
<td | <td> | ||
<p class=" | <p class="codeInTable">XG FLODXTn, c, r, s | ||
</p></td> | </p></td> | ||
<td | <td><p>Pass fields to <var>FLOD</var> exit program control</p></td> | ||
</ | |||
</tr> | </tr> | ||
<tr> | <tr> | ||
<td> | <td> | ||
<p class=" | <p class="codeInTable"><b></b>#n | ||
</p></td> | </p></td> | ||
<td>Define label n</td> | <td><p>Define label n</p></td> | ||
</tr> | </tr> | ||
<tr> | <tr> | ||
<td | <td> | ||
<p class=" | <p class="codeInTable"><b></b>=label,p,char | ||
</p></td> | </p></td> | ||
<td | <td><p>Branch to label, optional comparison of char to input</p></td> | ||
</ | |||
</tr> | </tr> | ||
<tr> | <tr> | ||
<td> | <td> | ||
<p class=" | <p class="codeInTable"><b></b>* | ||
</p></td> | </p></td> | ||
<td>Comment</td> | <td><p>Comment</p></td> | ||
</tr> | </tr> | ||
</table> | </table> | ||
[[Category:File | </div> <!-- end of div for "toclimit-3" --> | ||
[[Category:File loading and reorganization]] |
Latest revision as of 21:33, 11 June 2022
A FLOD or a FILELOAD command is followed by a series of file load statements that comprise the file load program. The program is terminated by an END statement, beginning in column 1.
- If you are doing a multistep File Load procedure, the FLOD command marks the beginning of a file load program.
- If you are doing a one-step procedure, use the FILELOAD command.
These commands place the file in deferred update mode, in which updates to Tables C and D are deferred to deferred update data sets and are applied later to Tables C and D.
Notes:
- For a site that is authorized for Fast/Reload, the FLOD and FILELOAD commands are syntactically unchanged but invoke Fast/Reload, which compiles and executes the FLOD and FILELOAD programs.
- FILEORG X'100' files cannot be loaded by FLOD or FILELOAD except with a Fast/Reload Load All Information (LAI) FLOD/FILELOAD program.
Including the FLOD or FILELOAD command in your run
Include the FLOD or FILELOAD command and its associated file load program in the CCAIN data set, along with any other Model 204 commands needed to prepare the file for loading or to manipulate or check the data after loading.
Note: There can be only one FLOD, FILELOAD, or Z command specified in any given File Load job step.
Getting information about a FLOD or FILELOAD run
Some of the characteristics of the File Load run such as the number of records deleted or the number of fields added during the run are kept as counters that are printed at the end of the run. These counters are listed in FLOD and FILELOAD command output. A histogram listing the distribution of deferred update record lengths along with the number of records for each range of lengths is also displayed for variable-length deferred update data sets. It can be used as an aid to setting the variable-length sort parameter, and is illustrated in Setting the variable-length sort parameter (vl).
Double-checking your file load run
If you know how many records you are loading, you can use the SOUL FPC (Find and Print Count) construct to ensure that all records have been loaded.
Loading nondeferrable fields
If you are loading fields whose updates should not be deferred, it is not sufficient to specify the NON-DEFERRABLE attribute in order to override the deferral of updates for these fields. (In single-user File Load runs, the NON-DEFERRABLE attribute is ignored by Model 204.) See Overriding deferred updates for a description of the techniques available to override deferred updates.
Do not use RRN files in deferred update mode
Rocket Software suggests that you do not use deferred update mode with Reuse Record Number files except where you are performing simple record adds (such as reorganizing files). Doing so could cause you to lose updates without warning. See RRN files and deferred update mode for more information.
FLOD command
The FLOD command marks the beginning of a file load program. This command is followed by the file load statements described starting on File Load statements: overview. The procedure ends with the word END, beginning in column 1.
Syntax
The format of the FLOD command is:
FLOD k,n,m . . . END
Where:
- k specifies the maximum number of records to be loaded into the Model 204 file:
- If k is -1, FLOD loads all records into the Model 204 file.
- If k is any negative number except -1, the number is converted into a 32-bit unsigned number, N, and N records are processed.
- n specifies the maximum number of times the statements in the file load program are to be executed:
- If n is 0, the FLOD or FILELOAD code is compiled, but is not executed.
- If n is -1, FLOD keeps making passes through the code until the process is stopped by another condition (such as EOF)
- m specifies the number of input records to skip before starting the File Load process, which is helpful for breaking up the load process so that dumps (backups) can be taken during large loads:
- If m is -1, all records are skipped.
- If m is any negative number except -1, the number is converted into a 32-bit unsigned number,
N
, and FLOD skipsN
records before processing begins.
Usage
Each time the END statement is encountered during execution, Model 204 begins again with the first statement following the FLOD command. The procedure continues to execute until one of the following occurs:
- All the records in the input data set have been processed.
- k records have been added to the Model 204 file.
- n passes have been made through the file load program.
Thus, either k or n can be used to limit File Load processing and to load only a sample of the data.
To process all the input records, set both k and n to -1.
Example
The following command specifies that all input records be processed starting with the first record (that is, skip 0 records):
FLOD -1,-1, 0
FILELOAD command
To perform a one-step file load, use the FILELOAD command to mark the beginning of a file load program. This command is followed by the file load statements described starting on File Load statements: overview. The procedure ends with the word END, beginning in column 1.
FILELOAD command processing
The FILELOAD command attaches one or two sort subtasks to do the sorting required to load index and FRV entries efficiently. These subtasks run asynchronously with Model 204 (except under z/VM, which does not support true subtasking). Two buffers are used for the sorts. Model 204 fills the second buffer while the sort is emptying the first. After the records are sorted, the same double-buffering mechanism is used to pass the records back to Model 204.
Syntax
The complete format of the FILELOAD command is:
FILELOAD k,n,m [,[s1] [,[s2] [,[s3] [,[s4] [,vl]]]]] . . . END
Where:
- k, n, and m have the meanings described for the FLOD command in FLOD command, above.
- s1 represents the amount of memory that the sort package uses for sorting the deferred update index records produced by the file load program. If s1 is omitted or is not a positive integer, a default value of 50,000 bytes (64K for z/VM) is used for the sort work space.
Note: Make the s1 parameter as large as possible, especially for sorts involving many records. It is important to increase s1 for large sorts.
- s2 represents the amount of memory used for sorting the deferred update FRV index records. If s2 is omitted or is not a positive integer, a default value of 50,000 bytes (64K for z/VM) is used. For 3380 disk drives the minimum values for s1 and s2 are 64,000 bytes.
- s3 represents the amount of memory allocated for the two buffers used to pass data from Model 204 to the sorts. This parameter specifies the combined size of the two buffers. The core specified in s3 is evenly divided between the two buffers, and the default value of s3 is 8000 bytes. The minimum value accepted is 48 bytes, but such a small size is not recommended. A larger value of s3 can produce a noticeable performance improvement. However, increasing s1 normally has a greater effect on performance than a corresponding increase in s3.
- s4 represents the amount of memory allocated for the two buffers used to pass data from the sorts to Model 204. s4 is ordinarily equal in size to s3 and is set equal to s3 by default.
- vl specifies the maximum sort record length in variable-length record sorts. (vl corresponds to the L2 of the RECORD sort statement.)
The vl parameter is required when ORDERED fields are updated by the file load program. For efficiency, do not use the vl parameter if ORDERED fields are not updated. For more information about the vl parameter and how to select a value for it, see Setting the variable-length sort parameter (vl).
Examples
To specify a value for s2, but not s1, supply two consecutive commas before s2, as follows:
FILELOAD k,n,m,,s2,s3,s4
The same technique can be used to specify values for s3, s4, and vl. For example:
FILELOAD k,n,m,,,,,vl
Alternatively, specify a zero or negative value for s1 and allow the system to supply the default. The same technique can be used to specify values for s2, s3, and s4. For example:
FILELOAD k,n,m,0,-1,-2,-3,vl
FILELOAD error reporting
If a serious problem arises while the FILELOAD command is running, the user is restarted. A message is issued reporting the completion codes issued by the sorts. The message is:
*** M204.0760: SORT RETURN CODES - SORT 1: xxxxxx, SORT 2: xxxxxx
The completion codes issued by the sorts (xxxxxx) are reported as six hexadecimal digits. The first three digits are the subtask system completion code, such as 0C4
. The last three digits are the user completion code, such as 010
(which is a decimal 16). These completion codes can be useful in determining whether a problem is in Model 204 or is in the sort package itself.
FLOD and FILELOAD command output
After the file load program has completed, the following counters are displayed:
This counter | Displays the number of... |
---|---|
RECORDS READ | Records read from the TAPEI (input) data set, including those skipped by the FLOD or FILELOAD command |
ADDS | New Model 204 records begun |
DELETES | Model 204 records deleted |
AF | Fields added |
DF | Fields deleted (not including those deleted through a DELETE command) |
These counters can help you ensure that you have added, deleted, or changed all the records that you intended to.
File Load statements: overview
Model 204 provides several File Load statements that are elements of a separate File Load language.
The file load language provides limited programming capability. If complicated edits or large amounts of data manipulation are required, consider using FLOD exits, a preprocessing program, or a host language or SOUL program to load the file.
All File Load statements follow the FILELOAD command.
See the following sections for details:
- File Load statements: mode bits
- File Load statements: loading a new Model 204 file
- File Load statements: manipulating data areas with string buffers
- File Load statements: working with index registers
- File Load statements: updating existing Model 204 records
- File Load statements: deleting records and fields
File Load statement summary
See Syntax of File Load statements for a complete summary of all statements in the File Load language.
File Load statements: mode bits
Many of the statements described in the next sections use mode bits. These mode bits allow you to specify various options that are discussed here. Most options can be summed.
Note: If numeric sequence numbers are present, you must specify mode bits.
Mode bits summary
Mode bit | Meaning |
---|---|
X'8000' | Begin a new Model 204 record. |
X'4000' | Delete a field |
X'2000' | Sort or hash key omitted (specified with X'8000') |
X'1000' | Delete first occurrence of field |
X'0800' | Suppress deletion of blanks |
X'0400' | Translate numeric codes |
X'0200' | Load all-zero fields as '0' |
X'0100' | Strip leading zeroes |
X'0080' | Read and load floating point data |
Begin a new Model 204 record (X'8000')
Mode bit X'8000' causes a new Model 204 record to be started. More than one Model 204 record can begin on each pass through a file load program.
For example, suppose that the input statements for the following example each contained data for two people, with one person's data starting in column 1 and the other's in column 41. The file load program might look like this:
FLOD 5000,5000,0 G SOC.SEC.NO=1,9,X'8000' * begin a new record NAME=10,14 DEPT=24,2 SCALE=26,6 SOC.SEC.NO=41,9,X'8000' * begin a new record NAME=50,14 DEPT=64,2 SCALE=66,6 END
The X'8000' mode bit begins a new record even if the field turns out to be all blank, and is not actually stored in the new record (that is, it is possible to have a Model 204 record that has no fields).
Delete a field (X'4000')
The X'4000' mode bit deletes one field. It is used in conjunction with the read-and-load-a-field statement, as follows:
fieldname=position,length,X'4000'
For more information see File Load statements: deleting records and fields.
Sort or hash key omitted (X'2000')
The X'2000' mode bit allows you to specify that a record in a sort or hash key file does not have a sort or hash key. This mode bit can be used in conjunction with the X'8000' mode bit when reorganizing sort or hash key files. For more information, see Reorganizing sorted and hash key files.
Delete first occurrence of field (X'1000')
The X'1000' mode bit, when combined with the X'4000' and X'0800' mode bits, allows you to delete a specific value from a record. Use the X'4000' mode bit to delete INVISIBLE or VISIBLE fields; the value of the INVISIBLE field must be specified. Use the combined mode bit X'5800' to delete specific values in multiply occurring visible fields. See Deleting a VISIBLE field and Deleting specific values for more information.
Suppress blank deletion (X'0800')
Unless suppressed with mode bit X'0800', the File Load utility automatically deletes leading and trailing blanks from the value string.
Translate numeric codes (X'0400')
Input data sometimes contains information in a coded format. For instance, in the example at the beginning of the section, the department field is expressed as a two-digit code to save space on the input line. The File Load utility can store this code as is. However, if the code is a simple numeric code ranging upwards from 0, you can provide a translation table, using mode bit X'0400', following the read-and-load-a-field statement to convert these codes into full departmental names.
The following sample statement translates and stores a department code:
DEPT=24,2,X'0400' = * Code 0 ACCOUNTING= * Code 1 PERSONNEL= * Code 2 PURCHASING= * Code 3 DATA PROCESSING= * Code 4 = * Code 5 MEN'S CLOTHING= * Code 6 WOMEN'S CLOTHING= * Code 7 NOTIONS= SPORTSWEAR= MILLINERY= ADMINISTRATIVE= .
An input line having '06' in columns 24 and 25 causes the field DEPT=MEN'S CLOTHING
to be stored in the new record.
Creating translation tables
To create a translation table:
- Specify mode bit X'0400' on the read-and-load-a-field statement.
- Enter the value strings for codes 0 through n on the next n+1 lines, each starting in column 2 and immediately followed by an equal sign (=). If a particular code is not used, represent it with a line having only an equal sign in column 2 (like codes 00 and 05 in the above example).
- Signal the end of the translation table with a line that contains a period in column 1.
Rules for translation tables
The code in the data area of the input record must be an EBCDIC character representation of a decimal number. A plus sign (+) is permitted; blanks are not.
Translation does not occur and the code itself is stored as the field value in the current Model 204 record under the following circumstances:
- Data area does not contain a correct positive numeric code.
- Code is larger than the translation table.
- Code corresponds to a line for which no value is specified.
Note: Do not confuse numeric codes in the input data with the CODED field type option of Model 204 files. CODED fields affect only the internal storage of the field value and are virtually transparent to the end-user.
Using multiple translation table entries on a single line
Yo u can place more than one translation table entry on a single line using the following rules:
- Value for one entry must immediately follow the equal sign for the preceding entry.
- Last entry on each line must end with an equal sign.
- Entries are numbered just as if each entry appeared on a line by itself.
- Period ending the table must always appear on a line by itself.
The previous example can be written:
DEPT=24,2,X'0400' =ACCOUNTING=PERSONNEL=PURCHASING= DATA PROCESSING==MEN'S CLOTHING= WOMEN'S CLOTHING=NOTIONS=SPORTSWEAR= MILLINERY=ADMINISTRATIVE= .
Loading a constant field using a translation table
At times, you might want to specify a field to add to a Model 204 record rather than taking a value from the input record. To do this, write a read-and-load-a-field statement that specifies a position and length of zero and a translation table that has one entry:
fieldname=0,0,X'0400' value= .
Position zero is a special case that makes no reference to the current input record. For example, if the personnel records for more than one company are kept in the PEOPLE
file, the records for each company can be loaded in separate File Load runs.
For a particular run, the following example adds the field COMPANY=Rocket
to every record loaded during that run:
COMPANY=0,0,X'0400' Rocket= .
Load zero fields as '0' (X'0200')
Mode bit X'0200' loads all-zero fields as '0'. This option is valid only if used in conjunction with mode bit X'0100' (strip leading zeroes). Use mode bits X'0100' and X'0200' together to strip leading zeroes, but to ensure that a field containing all zeros is stored as '0'. This is useful when a zero field and a missing field have different meanings in the database.
Strip leading zeros (X'0100')
To compress values, you can strip all leading zeroes from certain field values before they are loaded into the Model 204 file using mode bit X'0100'. If a field contains all zeroes, it is stripped completely and is not stored. Unless blank deletion is suppressed, blanks are stripped before zeroes.
Read and load floating-point data (X'0080')
Mode bit X'0080' indicates that the incoming data contains floating- point input. If the field to be loaded is not FLOAT, the field value is converted to a character string for storage. If the field is FLOAT, the value is stored with no conversion.
With the mode bit turned off, character string input to a FLOAT field is converted to a floating-point value, if possible. Exponent format input is converted to numeric form for storage in FLOAT fields, and is left unconverted for non-FLOAT fields.
Floating-point format input to a FLOAT field is stored without conversion, but might be truncated or rounded, depending on its length. For more information about storing values in floating-point fields, see Floating point conversion, rounding, and precision rules.
File Load statements: loading a new Model 204 file
The statements that can be used in a file load program are summarized here, with the exceptions of the OPTIONS and LAI statements, which are valid only if Fast/Reload is authorized at your site. In addition, those of the statements summarized here that are not valid for Fast/Reload are so noted.
Most file load statements are sensitive to the column in which they begin; note the specifications carefully.
Note: The file load statements use the vertical bar (|) character (that is, the character that has the hexadecimal value X'4F'). If the vertical bar is not available on the terminal being used for the File Load run, use the up-arrow (↑) or caret (^) instead. The broken vertical bar symbol available on some ASCII terminals is not equivalent to the vertical bar. Use the up-arrow or caret for these terminals.
G (go to the next logical record) statement
The G statement consists simply of the letter G
in column 1. This statement causes the next logical record of the input data set to be positioned for processing.
Syntax
G
Various other file load statements can then refer to the data in the input record by specifying a relative position within the record. If the input records are of fixed or undefined length (RECFM = F, FB, or U), the data starts in position 1. If the records are of variable length (RECFM = V or VB), the data starts in position 5, and the binary length of the data is in positions 1 and 2.
If no more input records remain, the file load program terminates and Model 204 goes on to the command that follows the END statement.
* statement (comment line)
Comment lines can be inserted anywhere in the file load program. Comment lines must have an asterisk in column 1.
Syntax
* This is a comment
Read-and-load-a-field statement
The read-and-load-a-field statement stores a field (in a Model 204 record) that contains the specified field name and a value extracted from the specified positions of the current input record.
Read-and-load-a-field statement processing
Before the value is stored, leading and trailing blanks are deleted from it for the sake of space saving and uniformity. (In retrieval specifications, Model 204 considers 'MALE'
and 'MALE '
to be separate and distinct values.) Internal blanks are not changed in any way; for example: 'A B'
is stored as 'A B'
and not as 'AB'
or 'A B'
.
If the specified data area is entirely blank, then deleting the blanks reduces the length of the value to zero and the field is not stored. To load null values, use the LOADNULLS ON statement as described on LOADNULLS statement. Deleting leading and trailing blanks can be suppressed by using mode bits after the length specification.
Syntax
fieldname=position,length,mode_bits
Where:
- fieldname must start in column 2 and must be defined before running the file load program. fieldname must be followed immediately by the equal sign with no intervening blanks.
- position denotes the starting position of the field's value within the input record currently being processed and is always a positive number. (Position zero has a special significance that is explained in Loading a constant field using a translation table.)
- length specifies the number of characters allotted to the value in the input record.
- mode_bits are optional and are described beginning on File Load statements: mode bits.
Load-constant (LDC) statement
The LDC statement loads a constant value into a field. It is more efficient for loading a constant field than the translation table method described in File Load statements: mode bits.
Syntax
LDC fieldname=value=mode_bits
Where:
- LDC begins in column 1.
- fieldname is the Model 204 field into which the constant value is to be loaded.
- mode_bits are optional and are the same as those described beginning on File Load statements: mode bits.
- Equal signs (=) are value delimiters.
Examples
The following examples use the LDC statement:
- Load the value
1176 B
into fieldDEPT NO
:LDC DEPT NO=1176 B=
- Load the value
BOSTON
into the fieldCITY
and begin a new Model 204 record:LDC CITY=BOSTON=X'8000'
LOADNULLS statement
The LOADNULLS statement allows you to determine how to treat null values. Null values (values with a string length of zero) occur when you delete a data area that is blank.
Syntax
LOADNULLS [ON | OFF]
Where:
- ON means that null values are loaded, the default.
- OFF means that null values are not loaded.
If LOADNULLS is not specified, the initial FLOD state is set to LOADNULLS OFF.
Load-repeating-field (LDRF) statement
The LDRF statement loads a variable number of occurrences of a fixed length field of an input record into a multiply occurring field of a Model 204 record. If the number of occurrences of the fixed length field varies between input records, each input record must contain a field that specifies the number of occurrences. If the number of occurrences of the fixed length field is the same in all input records, the constant value can be loaded into a string buffer, and the LDRF statement can refer to the string buffer. The fixed length fields must be adjacent in the input record.
Syntax
LDRF fieldname=pos1,len1,pos2,len2[,index][,mode_bits]
Where:
- LDRF must begin in column 1.
- pos1 is the starting position within the input record of the first occurrence of the fixed length field.
- len1 is the length of each occurrence of the field.
- pos2 is an EBCDIC number representing the number of occurrences of the fixed length field.
- len2, in bytes, is the length of the number in pos2.
- index is optional and specifies an index register that points, after execution of the statement, to the record position just past the last occurrence loaded.
- mode_bits are optional and described starting on File Load statements: mode bits.
- The pos2 parameter is expected to be in EBCDIC. If this field is in the input record in some form, use the appropriate conversion statement (CFB, CFF, CFP, CFZ), with a string buffer. The string buffer can then be specified in the LDRF statement as the pos2 parameter. See File Load statements: manipulating data areas with string buffers for more information about converting values.
Example
For example, consider a file load program input file for a personnel database. The records might contain skill data that is likely to be multiply occurring. If the skill fields begin at position 45 of the input record, the length of each field is 15 bytes, a two-character EBCDIC occurrence count exists at record position 10, and the data is to be loaded into fields named SKILL
, the following statement loads the fields:
LDRF SKILL=45,15,10,2
Label definition (#) statement
Labels can be defined within a file load program by a statement in the form:
#n
Where:
- # (pound sign) is in column 1, and it is the label delimiter.
- n is a positive number. The minimum value for n is 1 (see File load program execution). The maximum is either 4095 or the value of the parameter LNTBL, whichever is smaller.
Usage
Labels are used by these other file load statements:
- Unconditional branch
- Branch-on-character-equal
- CASE statements that transfer execution from one part of the procedure to another.
These related statements are discussed in the following sections.
Unconditional branches
To force the execution of a file load program to transfer unconditionally to a statement other than the next one in line, specify a statement in the following form in column 1:
=label
Where:
label is the "n" portion of the label as described in the previous section.
Branch-on-character-equal (=) statement
The branch-on-character-equal statement allows the execution of a file load program to transfer to a different part of the procedure if the character at a specified position of the input record is equal to a specified character.
Syntax
=label,position,character
Where:
- = (equal sign) is in column 1.
- label is the "n" portion of the label defined elsewhere in the procedure.
- position denotes the position of the character in the input record to be compared.
- character is the EBCDIC character to which the input character is compared. If the characters are equal, execution is transferred to the file load statements following the specified label.
Usage
This statement can compare only one character at a time. The EBCDIC character must immediately follow the second comma in the statement. Be careful about what EBCDIC character you choose; you can only specify an unprintable character if the editor has special input capabilities.
Example
In the following example, certain personnel input records contain the employee's sex (F
or M
) in column 8, and the employee's spouse's name in columns 20 through 35:
FLOD -1,-1,0 G *Get a record from TAPEI SEX=8,1,X'8000' *Start new rec, load SEX field =10,8,M *Branch to label 10 if SEX is M NAME OF HUSBAND=20,16 *Load husband's name =11 *Branch to 11,skip wife's name #10 *Branch here when SEX is M NAME OF WIFE=20,16 *Load wife's name #11 *Fall through to END statement END
CASE statement
The CASE statement provides a character string compare and branch facility that allows the execution of a file load program to transfer to one of a number of other parts of the procedure based upon the contents of a data field at a specified position of the input record.
Syntax
CASE position,length string1=label1 string2=label2 string3=label3 . . . ENDCASE
Where:
- CASE begins in column 1.
- position denotes the starting position of the character string in the input record to be tested.
- length denotes the length of the character string.
- stringN=labelN specifications form a branch table to indicate where to transfer control when the argument string is matched. Branch table entries must begin in column 2. CASE is limited to 25 or fewer entries.
- ENDCASE, starting in column 1, must be used to terminate the branch table.
Usage
The CASE statement recognizes a match only if the content and length of the input record string argument are identical to the string value and length of one of the branch table entries. If no branch table entry matches the input record string argument, control passes to the statement following ENDCASE.
Example
Consider the following example:
CASE 37,4 JUNE=6 JULY=7 MAY =2 ENDCASE
When the CASE statement is executed, the four-character string that starts at position 37 of the input record is compared to each table entry. A match on content and length results in a branch to the procedure label following the =
. Thus, if an input record contained JUNE
in positions 37-40, control is transferred to procedure label 6. If the record contained JULY
or MAY
, control is passed to label 7 or 2, respectively.
The table entry for MAY
in the previous example was expanded to four bytes. If the table entry is as follows, a match does not occur because its implies string length is 3:
MAY=2
The comparison is of data content and length. Applications of the CASE statement, in which the length of the strings in the branch table vary, can be handled by using a file load program index register for the CASE length specification. Index registers are discussed in File Load statements: working with index registers.
Transfer-on-condition (T) statement
Use the transfer-on-condition statement to compare two data areas of the input record and to transfer to a specified label if the comparison indicates a specified condition.
Syntax
T label,position1,length,position2,condition
Where:
- T is in column 1.
- label is the "n" portion of the specified label (see previous statements about labels).
- position1 is the position of the first data area.
- length specifies the number of characters.
- position2 is the position of the second data area. Each data area is taken to be and is treated as a simple EBCDIC character string.
- condition is represented by a decimal number, as follows:
Code Meaning 2 Greater than 4 Less than 7 Not equal to 8 Equal to 11 Greater than or equal to 13 Less than or equal to
Example
The following example transfers to label 40, if the character string in columns 3 through 12 is greater than that in columns 31 through 40:
T 40,3,10,31,2
Read a field name from input data (D) statement
In some circumstances, the input data contains the names of the fields to be loaded as well as the values. The D statement is similar to the read-and-load-a-field statement except that it also specifies the position and length of the field name within the current input.
Syntax
D position1,length1=position2,length2[,mode_bits]
Where:
- D is in column 1.
- position1 and length1 specify the position and length of the data area that contains the field name. Leading and trailing blanks are deleted.
- position2 and length2 specify the position and length of the data area that contains the field value.
- mode_bits are optional and identical to the optional mode bits in File Load statements: mode bits.
Example
Suppose that input statements are arranged so that each statement contains a field name in columns 2 through 31 and a field value in columns 32 through 80. Furthermore, column 1 contains a 1 if the field is the first field of a new record and a 2 otherwise. The input records are:
1SOC.SEC.NO 540237398 2NAME THORNHILL 2DEPT ACCOUNTING 1SOC.SEC.NO 239876433 2NAME DARCY . . .
The following file load program loads the records:
FLOD -1,-1,0 G *Read new input record =10,1,2 *Branch to 10 if rec starts with 2 D 2,30=32,49,X'8000' *Load first fld of Model 204 rec =20 *Branch to label 20 #10 D 2,30=32,49 *Add a field to Model 204 record #20 END
Print a character string (P) statement
Use the P statement to print selected portions of the current input record or of a string buffer.
Syntax
P position,length
Where:
- P is in column 1.
- position indicates the starting position on the input record or string buffer.
- length indicates the number of bytes of data to be printed from the input record or string buffer.
Example
The following statement can be used to print out sample input data:
FLOD -1,50,0 G P 1,80 END
This statement prints 50 input records of 80 bytes each.
The P statement also is useful for printing out input records that are not in an expected format. The following procedure prints out input records that contain something other than an X
or a Y
in column 1:
FLOD -1,-1,0 G =10,1,X * Branch to 10 if first column is X. =20,1,Y * Branch to 20 if first column is Y. P 1,80 * Print bad input record. =30 * Don't process bad record. #10 . . * Process X records. . =30 #20 . . * Process Y records. . #30 END
STOP statement
The STOP statement allows a file load program to exit before the number of records in the data set or specified in the file load program have been processed.
Syntax
STOP return_code
Where return_code is an optional, nonzero number. This number sets the job step return code for the file load program step.
Usage
When the STOP statement is executed, the file load program ends evaluation of the statements in the procedure and displays the following message:
*** M204.0697: FLOD FINISHED -- STOP STATEMENT
When the file load program STOP statement executes, it ends the program, but not any of the other commands contained in the job stream.
File Load statements: manipulating data areas with string buffers
Two 256-byte areas, called string buffers, are provided to allow you to manipulate and reformat data areas before they are loaded. Use string buffers when:
- Input contains a long data area that is continued over two or more input records
- Number of data areas are to be combined, reordered, or reformatted before loading
- Using a numeric conversion statement (CFB, CFP, CFF, or CFZ)
- Using an L/ENDL loop (see L...ENDL statement (locate existing records))
Use the following statements to manipulate the contents of the string buffers (the statement name in the first column is a link to the section that explains it).
Statement | Meaning |
---|---|
S | Clears the string buffer; moves a character string into the buffer |
SC | Clears the string buffer; moves a constant into the buffer |
M | Appends (moves) a character string into the buffer without clearing |
MC | Appends (moves) a constant into the buffer without clearing |
CFB | Converts from binary |
CFF | Converts from floating-point |
CFP | Converts from packed decimal |
CFZ | Converts from zoned decimal |
Referring to string buffers
Any statement that refers to the normal input record can also refer to a string buffer. A position field in any statement can be modified to refer to the string buffer instead of the input record using the following format:
=position, {|0S | |1S}
Examples
The following example branches to label 12 if column 37 of string buffer 0 contains an A
:
=12,37|0S,A
The following example loads a field called DATE
with a value taken from the first six columns of string buffer 1:
DATE=1|1S,6
The length of the current contents of a string buffer is remembered by Model 204 and can be used in any statement that contains a length field. This is done by immediately following the length with a vertical bar, the string buffer number, and the letter S
. This causes the current length of the specified string buffer to be added to the length field.
Therefore, the length field normally is specified as zero.
The following example loads a field called DATE
with a value equal to the current contents of string buffer 1:
DATE=1|1S,0|1S
The following example transfers to label 20, if the current contents of string buffer 0 are less than or equal to (condition 13) the contents of the date area beginning at column 73 of the current record:
T 20,1|0S,0|0S,73,13
For example, certain input records contain Social Security numbers in the form 123-45-6789 in columns 21 through 31. The following code removes the hyphens before the numbers are loaded into the Model 204 file:
S 0,21,3 * Blank buffer; load 3 digits. M 0,25,2 * Add middle 2 digits. M 0,28,4 * Add last 4 digits. SOC.SEC.NO=1|0S,9 * Load number from buffer.
S statement
The S statement clears the contents of the specified string buffer to blanks and then moves in a character string from the current input record. The string is left-justified in the string buffer.
Syntax
The format of the S statement is:
S {0 | 1},position,length
Where:
- S begins in column 1.
- 0 and 1 are string buffers.
- position is the starting column number from which to read characters from the current input record.
- length is the number of characters to read.
Examples
The following example clears buffer 0 and moves 11 characters from columns 29 through 39 of the current input record into the beginning of the buffer:
S 0,29,11
The following example clears string buffer 1 and inserts the character from column 3 of the input:
S 1,3,1
The following example simply clears string buffer 0:
S 0,1,0
M statement
The M statement is almost identical to the S statement except that the string buffer is not cleared first. Characters from the input record are simply appended to the existing contents of the buffer.
Syntax
The format of the M statement is:
M {0 | 1},position,length
SC statement
The SC statement clears the contents of the specified string buffer to blanks and then moves in a constant.
Syntax
The format of the SC statement is:
SC {0 | 1},value=
Where:
- SC begins in column 1.
- 0 and 1 are string buffers.
- value= is any constant string. You must specify the final equal sign. The constant can be up to 256 characters long.
Example
The following example clears buffer 0 and moves the constant value, 7, into the beginning of the buffer:
SC 0,7=
MC statement
The MC statement is almost identical to the SC statement except that the string buffer is not cleared first. A constant value is simply appended to the existing contents of the buffer.
Syntax
The format of the MC statement is:
MC {0 | 1},value=
Data conversion statements
You can use string buffers as an intermediate storage area while converting input data from binary, packed decimal, zoned decimal, or floating-point to EBCDIC for storage in the Model 204 file. Numeric data must be translated to character form if the data is to be accessible to a SOUL user.
These statements are described in detail in the following sections.
CFB (convert from binary) statement
To allow you to translate from binary input data to a character string format for use in Model 204, the convert-from-binary instruction is provided.
Syntax
The statement format is:
CFB {0 | 1},position,length
Where:
- CFB starts in column 1.
- 0 and 1 are string buffers.
- position indicates where the binary data in the input record begins.
- length can be from 1-4 bytes.
Usage
The data in the specified position must be a 1- to 4-byte signed binary number. The CFB instruction converts it to EBCDIC and stores it in the designated string buffer where it can be edited and/or loaded into the Model 204 file. Leading integer zeroes are stripped during conversion.
The first character of the result is either a significant digit or a minus sign (-). If the input value is a zero, the result is a single zero.
Example
For example, the following sequence converts a 2-byte binary field beginning in Position 4 of the input record to EBCDIC, leaving the result in string buffer 1:
CFB 1,4,2 QUANTITY=1|1S,0|1S
The EBCDIC string is loaded from string buffer 1 into the QUANTITY
field of the current record.
CFF (convert from floating-point) statement
The convert-from-floating-point instruction converts short- or long-floating-point input data to a character string format for use in Model 204.
Syntax
The statement format is:
CFF {0 | 1},position,length
Where:
- CFF starts in column 1.
- 0 and 1 are string buffers.
- position indicates where the binary data in the input record begins.
- length depends on the form of the input data. The input data can be either a short- or long-precision floating-point number. Length must be:
- 4 for a short-precision number
- 8 for a long-precision number
Note: If length is specified incorrectly (neither 4 nor 8), a zero length results and no error indication is given.
Usage
Leading integer zeros and trailing fractional zeros are stripped during conversion. A decimal point is not included for an integer value. If the input value is a zero, the result is a single zero. If the input value is a negative number, the first character of the result is a minus sign. The result of the conversion has at least 15 digits of precision. The result of a CFF instruction can be loaded into a Model 204 record using a read-and-load-a-field statement, as shown in the following example.
Example
CFF 1,20,8 AMOUNT=1|1S,0|1S
For information about loading floating-point input directly into a field, see Read and load floating-point data (X'0080').
CFP (convert from packed decimal) statement
To allow you to translate from packed decimal input data to a character string format for use in Model 204, the convert-from-packed instruction is provided.
Syntax
The statement format is:
CFP {0 | 1},position,length[,decimal_position]
Where:
- CFP starts in column 1.
- 0 and 1 are string buffers.
- position indicates where the packed data in the input record begins.
- length, specified in bytes rather than packed decimal digits, must be between 1 and 8.
Note: If the length is specified incorrectly (less than 1 or greater than 8) a zero length results and no error indication is given.
- decimal_position indicates where a decimal point can be inserted into the string, expressed as a number of digits to the right of the desired decimal point.
Usage
The data in the specified position must be a 1- to 8-byte packed decimal number, which starts on a byte boundary and, therefore, consists of an odd number of digits. This data is not checked for conformity to a packed decimal format. A number is assumed to be positive unless its sign position contains a valid minus sign.
The CFP instruction converts the data to EBCDIC and stores the result in the designated string buffer, where it can be edited and/or loaded into the Model 204 file. The first character of the result is either a blank or a minus sign, and leading and trailing zeros are not stripped. If a decimal position is specified, a decimal point is inserted in the string. If the decimal position is invalid (less than zero or greater than the number of digits in the input), a message is issued and the decimal point is not inserted.
Example
The following sequence converts a 6-byte packed decimal field beginning in Position 8 of the input record to EBCDIC, leaving the result in string buffer 1 with a decimal point inserted, giving the number two decimal places:
CFP 1,8,6,2 AMOUNT=1|1S,0|1S
The result has the form:
sddddddddd.dd
Where:
- s represents a blank or minus sign.
- d represents a digit between 0 and 9.
This result is then loaded into the AMOUNT
field of the current record from string buffer 1.
CFZ (convert from zoned decimal) statement
To allow translation from zoned decimal input data to a character string format for use in Model 204, the convert-from-zoned instruction is provided.
Syntax
The statement format is:
CFZ {0 | 1},position,length[,decimal_position]
Where:
- CFZ starts in column 1.
- 0 and 1 are string buffers.
- position indicates where the zoned data in the input record begins.
- length, specified in bytes, must be between 1 and 16. If the length is specified incorrectly (less than 1 or greater than 16), a zero length results and no error indication is given.
- decimal_position indicates where a decimal point can be inserted into the string, expressed as the number of digits to the right of the desired decimal point.
Usage
The data in the specified position must be a 1- to 16-byte zoned decimal number. The data is not checked for conformity to a zoned decimal format. If the zone of the low-order byte is not a valid minus sign, the number is assumed to be positive.
The CFZ instruction converts the data to EBCDIC and stores the result in the designated string buffer where it can be edited and/or loaded into the Model 204 file. The first character of the result is either a blank or a minus sign, and leading and trailing zeroes are not stripped. If the decimal position is invalid (less than 0 or greater than the number of digits in the input), a message is issued and the decimal point is not inserted.
Example
The following sequence converts a 6-byte zoned decimal field beginning in position 20 of the input record to EBCDIC, leaving the result in string buffer 1 with a decimal point inserted, giving the number two decimal places:
CFZ 1,20,6,2 PAYMENT=1|1S,0|1S
The result has the form:
sdddd.dd
Where:
- s represents a blank or minus sign.
- d represents a digit between 0 and 9.
This result is then loaded into the PAYMENT
field of the current record from string buffer 1.
File Load statements: working with index registers
A number of work areas called index registers, which are used primarily to manipulate numbers, are available for use within file load programs. The numbers in these index registers are most often used to modify the position or length fields of other file load statements.
Number of allowable registers
Index registers are denoted by index register numbers that can range from 1 to the value of the parameter LNTBL, which defaults to 50 (see File load program execution). The maximum number of index registers is 255, no matter how large LNTBL is.
Index register size
Each index register is four bytes long (a fullword) and can contain number values between -2,147,483,648 and +2,147,483,647, inclusive.
Setting an index register
The I statement has a fairly complicated format. A number of simple forms are discussed first.
Syntax
The basic statement format is:
I index,[operands]
Where:
- I is in column 1.
- index is the number of the index register to be set.
- operands are optional operations that modify the indicated index register and can involve input records or other index registers.
Clearing an index register
If no optional operands are specified, the I statement sets the specified index register to zero. The following example sets index register 15 to zero:
I 15
Setting an index register from the input record
As many as four bytes of data from the current input record can be loaded into an index register, using the following format:
I index,position,length
Where length is the number of bytes of data starting at the specified position that are placed into the specified index register right-aligned and padded with binary zeros on the left if length is less than 4.
Example
The following example loads the first two bytes of the input record into index register 9:
I 9,1,2
If the input records are variable-length (RECFM=V or VB), index register 9 contains the number of characters of data in the record.
Setting an index register to a constant
To set an index register to a specified number:
Syntax
I index,,,number
Where number, which can be specified in decimal, hexadecimal (X'xx'), or character (C'c') form, must be between -32,768 and +32,767, inclusive (two bytes). If a larger value is specified, only the low-order two bytes are used.
Example
The following example sets index register 35 to minus one:
I 35,,,-1
Adding to an index register
A number can be added to the contents of an index register and stored back into that register or some other register.
Syntax
Use the following format:
I index1,,,number|index2
The number must conform to the previous rule for a constant.
Examples
For example, suppose that index register 23 contains the number 119. The following example sets index register 7 to 124. Register 23 still contains 119:
I 7,,,5|23
The following example changes the contents of register 23 from 119 to 99:
I 23,,,-20|23
Multiplying the contents of an index register
The contents of an index register can be multiplied by a specified number and the result stored into that register or some other register.
Syntax
Use the following format:
I index1,,,,number|index2
The number must conform to the rule given above for a constant.
Examples
For example, suppose that index register 4 contains the number 10. The following example sets index register 5 to -10. Register 4 still contains 10:
I 5,,,,-1|4
The following example changes the contents of register 4 from 10 to 70:
I 4,,,,7|4
Full format of I statement
The full format of the I statement is:
I index1,position,length,number2|index2,number3|index3
In this full format the I statement computes the sum of these four quantities:
- Data field of length bytes at the specified position of the current input record
- number2
- Contents of index2
- Product of number3 and the contents of index3
The sum is then stored in index1.
length cannot exceed 4.
number2 and number3 should follow the rule given above for a constant.
Example
The following example adds the two bytes at the beginning of the input record, the contents of index register 15, and the contents of register 16, and stores the result in register 14:
I 14,1,2,0|15,1|16
Modifying position and length fields
The position or length fields of most file load statements can be modified by the contents of any index register by immediately following the field with a vertical bar and the number of the index register. That is:
|index
The contents of the index register are added to the position or length number preceding the vertical bar.
Examples
For example, if index register 18 contains 5, the following example branches to label 40 if column 8 of the current input record contains a semicolon (;):
=40,3|18,;
Suppose that an input record contains a data area in columns 20 through 39 that has a person's name in the format:
last_name,first_name
The following code loads a LAST NAME
field composed of everything up to the comma:
I 4 *Clear index register 4 #31 *Top of comma loop check =32,20|4,, *Branch to label 32 if comma found I 4,,,1|4 *Add one to register 4 =31 *Branch back to label 31 #32 LAST NAME=20,0|4 *Load last name (length in reg 4)
Referring to the contents of index registers
In some cases, an index register can be treated as a data area itself. As such, the index register can be viewed as being four characters long (containing positions 1 through 4).
Any file load statement that has a position field can refer to a position in a specified index register by replacing:
position
with:
indexposition|index*
Where:
- indexposition is 1, 2, 3, or 4 (position 1 is the high-order position).
- index specifies the desired index register. The asterisk replaces the comma that normally follows the position specification.
The following example branches to label 40 if position 4 of index register 11 contains the EBCDIC character 3:
=40,4|11*3
The EBCDIC representation for 3 is equal to the number X'F3'
, or decimal 243.
Example
The following example branches to label 35 if the contents of positions 1 through 4 of index register 11 are equal to (condition 8) positions 1 through 4 of register 12. In other words, the following instruction simply compares two index registers:
T 35,1|11*4,1|12*8
Printing an index register value
The Q statement prints the current numeric value of a specified index register as a decimal number.
The format is:
Q index
File Load statements: updating existing Model 204 records
You can use file load programs to update or retrieve data from existing records in the Model 204 file as well as to load new records. The FLOD command and JCL are identical to those used for loading new records. The following special purpose file load statements can be used within file load programs to locate existing records, add fields, or determine the current value of an existing field.
L...ENDL statement (locate existing records)
Note: The L and ENDL statements are not supported by Fast/Reload.
The L statement provides a means of locating all the existing records in the Model 204 file with a specified field name = value pair. The field must be a KEY or ORDERED field. One pass is then made through a locate loop of file load statements for each record located in this way.
During a particular pass, the located record becomes the current record (that is, the record updated by read-and-load-a-field statements, DELETE statements, and so on). Whatever Model 204 record was current before the L statement is remembered and becomes the current record again when all the located records have been processed by the locate loop.
Within an L loop, UP statements can be used to process records which were current outside the loop.
If no records contain the specified field name = value pair, no passes are made through the locate loop.
A locate loop that follows an L statement consists of a sequence of file load statements followed by an ENDL statement. You can use any file load statement except one that transfers control to a label outside the loop (that is, a label that is not between the L and ENDL statements).
Syntax
The format of the L statement is:
L {0 | 1},fieldname=index,label[,mode_bits] . . . ENDL
Where:
- L is in column 1.
- 0 or 1 specifies the number of a string buffer that contains the value portion of the field name = value pair.
- fieldname must specify a field that has the KEY or ORDERED attribute.
- index specifies the number of any unused index register. The index register is used as a work area by the locate loop.
- label specifies a label to which control is to be transferred after passes have been made through the locate loop for all the located records. If no records are found by the L statement, control passes immediately to the label. For this reason, the statement after the ENDL always needs a label or it is not executed.
- mode_bits are optional and described in File Load statements: mode bits. If default editing produces the wrong value, you must specify mode bits.
- ENDL ends the locate loop and must start in column 1.
Usage
Locate loops can be nested up to three levels. Each time an L statement is encountered, the current record is remembered and record processing is said to go down one level. When the lower locate loop has processed its records, the record processing goes up one level and the remembered record once again becomes the current record. Each nested locate loop operates a FIND against the whole file of records, not just on the found set of the previous loop.
Nesting is shown in the following figure:
Example
Suppose that a Model 204 file contains personnel information that includes a last name field. The input data contains last names in columns 1 through 20 followed by as many as three homonyms in columns 21-40, 41-60, and 61-80:
FLOD -1,-1,0 G * Get new input record S 0,1,20 * Move last name into buffer 0 L 0,LAST NAME=30,45 * FR WHERE LAST NAME = last name HOMONYM=21,20 * Add Homonym Value HOMONYM=41,20 * Add Homonym Value HOMONYM=61,20 * Add Homonym Value ENDL * END FOR #45 END
For each input record, the previous procedure locates records that contain a LAST NAME
equal to the value in columns 1 through 20. For each such record, as many as three HOMONYM
fields are added.
A locate loop is quite similar to the following SOUL construction:
LOOP: FOR EACH RECORD WHERE fieldname = value . . . END FOR
UP and DOWN statements (change record processing level)
Note: The UP and DOWN statements are not supported by Fast/Reload.
The current record processing position can be changed through use of the UP and DOWN statements. The UP and DOWN statements consist of words starting in column 1. They can be used only within locate loops:
- UP statement causes record processing to go up one level. That is, the record that was remembered by the L statement once again becomes the current record and can be updated.
- DOWN statement reverses the process, and the record that the locate loop was processing at the time of the UP statement becomes the current record.
UP and DOWN statements must always occur in pairs.
An L statement performs the DOWN function automatically; an ENDL statement performs an automatic UP.
Example
Suppose that a file contains two types of records: "people" records and "child" records. A number of child records are being loaded into the file. Each contains the name of the child's parent. It is assumed that the parent's record already is in the file. Moreover, the input data for the child records does not include addresses. As each child's record is loaded, this file load program locates the child's parent's record, reads its ADDRESS
field, and copies it into the new child record:
FLOD -1,-1,0 G . . . PARENT.NAME=65,15 *Add PARENT.NAME to child's record S 1,65,15 *Move parent's name into buffer 1 L 1,NAME=43,20 *FR WHERE NAME = parent's name F 19,ADDRESS=30,33 * FEO address UP * Make child's record current ADDRESS=1|30,0|33 * Add address to child's record DOWN * Make parent's record current ENDF * END FOR #19 * Transfer here at end of F loop. ENDL *END FOR #20 *Transfer here at end of L loop. END
F statement (read field values)
Note: The F and ENDF statements are not supported by Fast/Reload.
The F statement provides a means of reading the current value(s) of a specified field within the current record. One pass is made through an F loop of file load statements for each occurrence of the field within the record.
Syntax
The format of the F statement is:
F label,fieldname=index1,index2
Where:
- F is in column 1.
- label specifies a label to which control is to be transferred after passes have been made through the F loop for all occurrences of the field.
- fieldname must specify a field that has the VISIBLE attribute.
- index1 and index2 specify numbers of index registers not currently in use.
At the beginning of each pass through the F loop, the value of the field occurrence to be processed in that pass is placed in a special work area, and index1 is pointed at that work area. index2 contains the length of the current value. Thus, the statements within the F loop can refer to the current value by specifying a position of
1|index1
and a length of0|index2
.After the last pass through the F loop, index1 and index2 still can be used to refer to the last value processed until another F statement is encountered.
An F loop following an F statement consists simply of a sequence of file load statements followed by an ENDF statement. Any file load statement can be used except:
- One that transfers control to a label outside the F loop
- L statement
- Another F statement
- DELETE statement
- Delete-field statement that deletes a VISIBLE field
Example
The following statements delete the last occurrence of the CHILD
field in the current record:
F 27,CHILD=35,36 ENDF #27 CHILD=1|35,0|36,X'4000'
File Load statements: deleting records and fields
Deleting a record
Note: The DELETE statement is not supported by Fast/Reload.
The DELETE statement deletes the current Model 204 record from the file. This statement consists of the word DELETE in column 1.
The following procedure deletes Model 204 records whose Social Security numbers correspond to those read from the input file:
FLOD -1,-1,0 G * Get an input record S 1,1,9 * Move SSN to string buffer 1 L 1,SOC.SEC.NO=47,15 * FOR EACH matching M204 record DELETE * Delete the record ENDL * END FOR #15 END
The FLOD run must be a multiuser run in order for the NON-DEFFERABLE attribute to take effect at all. How to set up a multiuser run so that the NON-DEFERRABLE attribute takes effect is described in Overriding deferred updates.
Two variations of the read-and-load-a-field statement allow you to delete fields from the current record. One form is limited to deleting VISIBLE fields only. The other form can be used to delete VISIBLE, INVISIBLE, and multiply occurring fields. Descriptions of both variations follow.
Deleting a VISIBLE field
The format of the statement used to delete a VISIBLE field is:
fieldname=1,1,X'5800'
Where:
- fieldname must start in column 2 and must specify a field that has the VISIBLE attribute. If the field occurs in the current record more than once (for example, a
CHILD
field), only the first occurrence is deleted. - 1's are position and length indicators (as in the following subsection).
- X'5800' is a combination of mode bit options (see File Load statements: mode bits).
Example
The following procedure changes the ADDRESS
fields of Model 204 records whose Social Security numbers are provided in columns 1 through 9 of the input records. The new addresses are in columns 10 through 59:
FLOD -1,-1,0 G S 0,1,9 * Move SSN into string buffer 0 L 0,SOC.SEC.NO=15,20 * FR WHERE SOC.SEC.NO=value ADDRESS=1,1,X'5800' * Delete old address ADDRESS=10,50 * Add new address ENDL * END FOR #20 END
Deleting specific values
Use this form of the read-and-load-a-field statement to delete any field value, even if it is INVISIBLE or a value in a multiply occurring field.
Syntax
The format of the statement used to delete a specific occurrence of a field is:
fieldname=position,length,X'4000'
Where:
- fieldname must start in column 2 and is followed immediately by an equal sign.
- position specifies the starting position within the current input record (or string buffer) of the specific value to be deleted.
- length specifies the length of the value.
- X'4000' is the mode bit option for deleting a field (see File Load statements: mode bits).
This delete-field statement differs from the first delete-field statement in the following ways:
- Value must be specified as well as the field name.
- Form can be used to delete INVISIBLE fields as well as VISIBLE fields.
- It can be used to delete the second, third, and subsequent occurrences of a multiply occurring field, as well as the first occurrence.
Deleting records
The date-time stamp feature does not include support for DELETE RECORD or DELETE RECORDS processing. DELETE RECORD or DELETE RECORDS processing must be handled by your application software.
As well, you can use logical delete techniques. However, in all forms of deleting records, it is your responsibility to maintain a log of record deletions, if you want one.
Handling the date-time stamp field in a file
The DELETE FIELD command is prohibited for the DTSFN field in a file when the FOPT X'10' bit is set. Attempting to do so results in the following message:
M204.2727: Can't delete DTS field when FOPT=X'10' is on
File load program execution
File load program phases
The file load program is processed in two phases. First, all of the statements between the FLOD command and the END statement are compiled. If any errors are detected, such as invalid field names or field-level security violations, the file load program is not executed.
If the compilation is successful, the procedure is executed.
Internal file load optimization feature
Most file load programs add records to a new or partially loaded entry order file (where new records are always added at the end of the file). The internal file load optimization feature greatly optimizes file load program performance in such situations.
The internal file load optimization feature also enhances performance when loading records into new or reinitialized Reuse Record Number (RRN) files.
In other environments, such as sorted, hash key, and unordered files, or for file load programs containing statements that examine or modify data already in the file (DELETE, F, L, or a statement having the X'4000' (delete) mode bit), the internal file load optimization feature is automatically turned off.
Storage tables
File load programs are compiled into various storage and work areas. These areas consist of the following tables:
This table | Contains... |
---|---|
NTBL | Label definitions and index registers. Each NTBL entry is shared by the label and index register having the same number. The size of NTBL determines the highest number that can be used. |
QTBL | Statements in internal form. Each file load statement generates one QTBL entry. Entry sizes vary, but most entries are between 12 and 20 bytes long. Important exceptions are the read-and-load-a-field entry, which expands by 4 bytes for each entry in a translation table, and the CASE entry, which starts at 12 bytes and adds 8 bytes for every branch table entry. |
STBL | All character strings specified for translation tables, CASE statements, and LDC statements. Each string is preceded by a 1-byte length. |
VTBL | Compiler variables. A minimal amount of VTBL space is used if the file load program contains an L statement (locate loop). Entries are variable in length, but most range from 8 to 20 bytes. |
The size of each table is determined by a parameter that can be set in the File Load job. These parameters are LNTBL, LQTBL, LSTBL, and LVTBL. For more information about these tables, see Description of tables.
FLOD and FILELOAD exits
FLOD or FILELOAD exits pass control from FLOD to an Assembler or COBOL program, which allows you more sophisticated data manipulation capabilities. For complete information about these exits, see FLOD exits.
Error conditions
This section describes the file load program error conditions that Model 204 can encounter because of preallocated field and field-level security violations.
Errors generated during file load program evaluation are counting errors, which are described in Counting errors. If the number of errors encountered during evaluation reaches the limit specified in the ERMX parameter, the file load program is terminated and the user is restarted.
File load performance
The order in which fields are loaded affects the speed with which the file load program executes. This is particularly true when the go-faster feature is in effect. Execution speed can be optimized by loading preallocated fields before all other fields.
Preallocated field violations
If you try to load values in a preallocated field that are longer than the length specified in the field's LENGTH option or you try to add more occurrences to a preallocated field than are specified in the field's OCCURS option, an error is generated during the file load program evaluation. The value lengths specified in file load statements are not checked during compilation. Instead, actual value lengths are checked during evaluation, after blanks have been deleted and leading zeroes have been stripped.
Model 204 handles length and occurrence errors by issuing time error messages that specify the relevant field name and the internal record number of the record that Model 204 was processing when the error was encountered.
Except in the case of the LDRF (load-repeating-field) statement, nothing is stored for the statement that causes the error, and evaluation continues with the next file load statement. For LDRF, the occurrence causing the error is not stored, but Model 204 attempts to load subsequent values.
Field-level security violations
All field-level security (FLS) violations, except those occurring in a D statement used to load field = value pairs from the input data, can be detected during compilation of a file load program. FLS violations detected during compilation result in counting error messages that prevent evaluation of the file load program. An FLS violation that results from the compilation of a D statement produces error messages that identify the input record number, the relevant field name, and the internal record number of the record that was being built when the error was encountered. The field is not stored in the file.
AT-MOST-ONE field violations
When you use FLOD or FILELOAD to load or modify records that have AT-MOST-ONE fields, Model 204 ensures that the new or modified records do not violate AT-MOST-ONE constraints. Model 204 detects and reports all violations of AT-MOST-ONE in one pass of the input data. If Model 204 finds any fields that violate the constraints, the following occurs:
- Error is reported and the new or duplicate field is rejected.
- FLOD continues processing the input data.
- At the end of the run, the file is marked "logically inconsistent."
- The following error message is issued for each violation:
M204.2119: AT-MOST-ONE CONSTRAINT VIOLATION IN RECORD recno, FIELD IGNORED: field=value
NUMERIC VALIDATION file violations
When loading or modifying records in NUMERIC VALIDATION files using FLOD or FILELOAD, Model 204 ensures that the new or modified FLOAT and BINARY fields do not violate NUMERIC VALIDATION constraints. Model 204 detects and reports all FLOAT and BINARY violations. If Model 204 finds any numeric data type violations, the following occurs:
- Error is reported with one of the following messages and the field is rejected.
- FLOD (or FILELOAD) continues processing the input data.
- At the end of the run, the file is marked "logically inconsistent;" that is, the FISTAT parameter is set to X'40'.
- One of the following error messages is issued for each violation:
M204.2123: VALUE SPECIFIED VIOLATES BINARY DATA TYPE VALIDATION IN RECORD recno, FIELD IGNORED: field = value M204.2124: VALUE SPECIFIED VIOLATES FLOAT DATA TYPE VALIDATION IN RECORD recno, FIELD IGNORED: field = value
Syntax of File Load statements
This section provides the complete syntax of the FILELOAD and FLOD commands and all the file load statements.
FILELOAD command
The FILELOAD command has the following format:
Syntax
FILELOAD k,n,m [,[s1] [,[s2] [,[s3] [,[s4] [,vl]]]]]
Where:
- k is the maximum number of records loaded.
- n is the maximum number of passes through the file load procedure.
- m is the number of input records to skip before starting the load process.
- s1 is the amount of memory used for sorting the deferred update index records.
- s2 is the amount of memory used for sorting the deferred update FRV index records.
- s3 is the amount of memory allocated for the two buffers used to pass data from Model 204 to the sorts.
- s4 is the amount of memory allocated for the two buffers used to pass data from the sorts to Model 204.
- vl is the maximum sort record length in variable-length record sorts. (vl corresponds to the L2 of the RECORD sort statement.)
The vl parameter must be present for one-step File Load runs that update ORDERED fields.
FLOD command
Syntax
FLOD k,n,m
Where:
- k, n, and m have the same meanings as in FILELOAD.
Abbreviations
The following abbreviations and terms are used:
Term or abbreviation | Definition |
---|---|
i | Index register number |
len n n|sS n|i |
Length, specified as one of: Number Number + length of current contents of string buffers Number + contents of index register i |
mode X'8000' X'4000' X'2000' X'1000' X'0800' X'0400' X'0200' X'0100' X'0080' X'8000' X'4000' |
Four-digit hexadecimal number indicating field-loading options: Begin a new record Delete the field Sort or hash key omitted (specified with X'8000') Delete first occurrence of field Do not strip leading or trailing blanks Translation table provided Load all-zero field as '0' Strip leading zeroes Floating-point input Begin a new record Delete the field |
n,m | Decimal integers |
p n n|sS n|i |
Position, specified as one of: Position in current input record Position in string buffer s Followed by Followed by |
s | String buffer number (0 or 1) |
The statements are listed in alphabetical order. Replace elements in lowercase. Uppercase elements appear as shown.
File Load statement | Action | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
field=p,len,mode |
Read-and-load-a-field |
||||||||||||
CASE p,len string1=label1 string2=label2 . . . ENDCASE |
Branch based on string value |
||||||||||||
CFB s,p,len |
Convert from binary |
||||||||||||
CFF s,p,len |
Convert from floating point |
||||||||||||
CFP s,p,len,decimal-places |
Convert from packed decimal |
||||||||||||
CFZ s,p,len,decimal-places |
Convert from zoned decimal |
||||||||||||
D p1,len1=p2,len2,mode |
Read and load field name and value |
||||||||||||
DELETE |
Delete current record |
||||||||||||
DOWN |
Go down one locate level |
||||||||||||
END |
End of file load program |
||||||||||||
ENDF |
End of F loop |
||||||||||||
ENDL |
End of L (locate) loop |
||||||||||||
F label,field=i1,i2 |
Read field value from current record |
||||||||||||
G |
Get new input record |
||||||||||||
I i1,p,len,n|i2,m|i3 |
Set i1 to (value of data in position p for len bytes) + n + i2 + (m * i3) |
||||||||||||
L s,field=i,label |
Locate field = string buffer value |
||||||||||||
LDC field=value=mode |
Load constant field |
||||||||||||
LOADNULLS ON|OFF |
Load null values |
||||||||||||
LDRF field=p1,len1,p2,len2,i,mode |
Load repeating field |
||||||||||||
M s,p,len |
Append value to string buffer |
||||||||||||
MC s,value |
Append constant to string buffer |
||||||||||||
P p,len |
Print value |
||||||||||||
Q i |
Print value in index register |
||||||||||||
S s,p,len |
Clear string buffer and load value |
||||||||||||
SC s,value |
Clear string buffer and load constant |
||||||||||||
STOP |
Stop file load program |
||||||||||||
T label,p1,len,p2,condition where condition can be:
|
Compare strings and branch conditionally |
||||||||||||
UP |
Go up one locate level |
||||||||||||
XG FLODXTn, c, r, s |
Pass fields to FLOD exit program control |
||||||||||||
#n |
Define label n |
||||||||||||
=label,p,char |
Branch to label, optional comparison of char to input |
||||||||||||
* |
Comment |