Difference between revisions of "Defining the runtime environment (CCAIN)"

From m204wiki
Jump to navigation Jump to search
<
 
 
(102 intermediate revisions by 8 users not shown)
Line 19: Line 19:
 
==Structure of CCAIN==
 
==Structure of CCAIN==
 
<p>
 
<p>
The CCAIN file is divided into three sections:</p>
+
The CCAIN file is divided into three sections, as described here:</p>
 
   
 
   
<ul>
+
===Runtime environment===
<li>Runtime environment specifications line, which is known as the '''User 0 parameter line''', sets system characteristics and default user parameters during <var class="product">Model&nbsp;204</var>  initialization.   
+
The runtime environment specifications line, which is known as the '''User 0 parameter line''', sets system characteristics and default user parameters during <var class="product">Model&nbsp;204</var>  initialization.   
 
   
 
   
<p>User 0, which acts as the system operator, is the name given to the input stream used by <var class="product">Model&nbsp;204</var> initialization routines. The input stream is read from the CCAIN file and echoed on the CCAPRINT file (for more information on CCAPRINT, see [[Obtaining User 0 output (CCAPRINT)]]). </p>
+
<p>
 +
User 0, which acts as the system operator, is the name given to the input stream used by <var class="product">Model&nbsp;204</var> initialization routines. The input stream is read from the CCAIN file and echoed on the CCAPRINT file. (For more information on CCAPRINT, see [[Obtaining User 0 output (CCAPRINT)]].) </p>
 
   
 
   
<p>The User 0 parameter line, which is described in this page, includes:</p>
+
<p>
 +
The User 0 parameter line, which is described in this page, includes:</p>
 
   
 
   
 
<ul>
 
<ul>
<li> System table sizes</li>
+
<li>System table sizes</li>
  
<li> I/O buffer sizes</li>
+
<li>I/O buffer sizes</li>
  
<li> Scheduler and performance options</li>
+
<li>Scheduler and performance options</li>
  
<li> Recovery options  
+
<li>Recovery options</li>
</li>
 
 
</ul>
 
</ul>
 
   
 
   
<p>Parameters on the User 0 line are specified on the first line of the CCAIN input stream unless certain DEFINE commands are used. Commands such as DEFINE DATASET and DEFINE STREAM are the only User 0  statements that can precede the User 0 parameter line.</p></li>
+
<div id="preUser0Cmds">
 +
====Pre-user 0 commands====
 +
<!--Caution: <div> above-->
 +
 
 +
<p>Parameters on the User 0 line are specified on the first line of the CCAIN input stream unless certain commands are used. The following commands are the only ones that can <i>precede</i> the User 0 parameter line:</p>
 +
<ul>
 +
<!-- The following are only allowed for SIRIUS or ROCKET:
 +
<li>[[*LOOK command|*LOOK]]</li>
 +
<li>[[*ZAP command|*ZAP]]</li>
 
   
 
   
<li> User environment definitions and specifications are set for each user on a separate line for:
+
This is allowed for anyone as far as SIRHC is concerned, I haven't check
 +
but it seems to not be found in the wiki:
 +
<li>[[CPTRACE command|CPTRACE]]</li>
 +
-->
 +
 
 +
<li>[[*LOWER command|*LOWER]]</li>
 +
<li>[[*UPPER command|*UPPER]]</li>
 +
<li>[[APPDATE command|APPDATE]]</li>
 +
<li>[[DEFINE DATASET command|DEFINE DATASET]]</li>
 +
<li>[[DEFINE STREAM command|DEFINE STREAM]]</li>
 +
<li>[[MSGCTL command|MSGCTL]]</li>
 +
<li>[[UNICODE command|UNICODE]]</li>
 +
</ul>
 +
<ul>
 +
<li><b>*</b> (a comment) is also allowed, however, a blank <b>must follow</b> the <code>*</code>.</li>
 +
<li>An all-blank line is also allowed.</li>
 +
</ul>
 +
 
 +
In addition, starting with version 7.5, you can [[PRECCAIN|provide a common configuration]] for all <var class="product">Model 204</var> jobs by linking <code>PRECCAIN</code> into your ONLINE, IFAM1, and/or IFAM4 load modules. <code>PRECCAIN</code>, an assembler module which you modify and link into the load modules, contains <var class="product">Model 204</var> commands and parameters set and executed, respectively, during <var class="product">Model 204</var> initialization.
 +
 
 +
===User environments and definitions===
 +
User environment definitions and specifications are set for each user on a separate line for:
 
<ul>  
 
<ul>  
 
<li> Device type and terminal communication network</li>
 
<li> Device type and terminal communication network</li>
Line 50: Line 80:
 
   
 
   
 
<li> Default output options</li>
 
<li> Default output options</li>
</ul></li>
+
</ul>
  
<li> System control commands are entered on successive lines. System commands include:
+
===System control commands===
 +
System control commands are entered on successive lines. System commands include:
 
<ul>
 
<ul>
 
<li> Recovery procedures</li>
 
<li> Recovery procedures</li>
Line 66: Line 97:
 
<li> End-of-data and end-of-job statements</li>
 
<li> End-of-data and end-of-job statements</li>
 
   
 
   
<li> User Language requests</li>
+
<li> [[SOUL]] requests</li>
 
   
 
   
 
<li> FLOD programs </li>
 
<li> FLOD programs </li>
</ul></li>
+
</ul>
</ul>
+
 
 
 
==ONLINE data streams with CCAIN==
 
==ONLINE data streams with CCAIN==
 
   
 
   
Line 79: Line 109:
 
   
 
   
 
===Parameter lines===
 
===Parameter lines===
+
<p>
<p>A CCAIN parameter line consists of one or more 80-column card images with parameter keywords and values in columns 1 through 71. </p>
+
A CCAIN parameter line consists of one or more 80-column card images with parameter keywords and values in columns 1 through 71. </p>  
+
<p>
<p>If the line exceeds 71 characters, any non-blank character in column 72 indicates continuation to the next card image. </p>
+
If the line exceeds 71 characters, any non-blank character in column 72 indicates continuation to the next card image. </p>
+
<p>
<p>The maximum length of the parameter area is controlled by the LIBUFF parameter, which is listed in Tables 2-4 and 2-6.       </p>
+
The maximum length of the parameter area is controlled by the <var>LIBUFF</var> parameter, which is listed in the [[#Runtime environment specifications|Common runtime parameters]] and [[#Calculating fixed table size|Fixed server table values]] tables. </p>
+
<p>
<p><var class="product">Model&nbsp;204</var> accepts comment lines or blank lines after the User 0 parameters in the CCAIN input stream. IODEV lines can have comments and blank lines before, between and after them.</p>
+
<var class="product">Model&nbsp;204</var> accepts comment lines or blank lines after the User 0 parameters in the CCAIN input stream. <var>IODEV</var> lines can have comments and blank lines before, between and after them.</p>  
+
<p>
<p>As shown in the following examples, these rules governing parameter lines apply in all operating environments.</p>
+
As shown in the following examples, these rules governing parameter lines apply in all operating environments.</p>
+
 
 
===z/OS JCL===
 
===z/OS JCL===
 
   
 
   
Line 273: Line 303:
 
<p>A single-user IFDIAL EXEC procedure, SAMPDIAL, is supplied as part of the distributed material. Customize and install SAMPDIAL on an accessible minidisk. The M204 EXEC expects the IFDIAL EXEC to be named <code>SINGDIAL</code>. </p>
 
<p>A single-user IFDIAL EXEC procedure, SAMPDIAL, is supplied as part of the distributed material. Customize and install SAMPDIAL on an accessible minidisk. The M204 EXEC expects the IFDIAL EXEC to be named <code>SINGDIAL</code>. </p>
 
   
 
   
<p>For more information, refer to the <var class="book">Rocket Model&nbsp;204 Installation Guide for IBM z/VM</var>.</p></li>
+
<p>For more information, refer to the <var class="book">[http://docs.rocketsoftware.com/nxt/gateway.dll/RKBnew556%2Fmodel%20204%2Fprevious%20versions%2Fv7.4%2Fm204_installzvm_v74.pdf Rocket Model 204 Installation Guide for IBM z/VM, version 7.4]</var>.</p>
 +
</li>
 
   
 
   
 
<li><var class="term">exec1</var> specifies the name of the EXEC procedure that contains the ACCESS commands for the required minidisks and the file definition (FILEDEF or M204FDEF) commands for <var class="product">Model&nbsp;204</var> recovery purposes. You must create the EXEC  in accordance with the file requirements for the <var class="product">Model&nbsp;204</var> ONLINE environment to be recovered.</li>
 
<li><var class="term">exec1</var> specifies the name of the EXEC procedure that contains the ACCESS commands for the required minidisks and the file definition (FILEDEF or M204FDEF) commands for <var class="product">Model&nbsp;204</var> recovery purposes. You must create the EXEC  in accordance with the file requirements for the <var class="product">Model&nbsp;204</var> ONLINE environment to be recovered.</li>
Line 285: Line 316:
 
   
 
   
 
====Usage notes====
 
====Usage notes====
+
<p>
<p>The EXEC can also include the Dictionary and Access/204 file definitions, if they are installed.</p>
+
The EXEC can also include the Dictionary and Access/204 file definitions, if they are installed.</p>
 
   
 
   
 
<p>The following considerations apply to CMS online command processing:</p>
 
<p>The following considerations apply to CMS online command processing:</p>
 
   
 
   
 
<ul>
 
<ul>
<li> If no operands are specified on the ONLINE command, the default name of the restart EXEC procedure is M204REST.</li>
+
<li> If no operands are specified on the <var>ONLINE</var> command, the default name of the restart EXEC procedure is <code>M204REST</code>.</li>
 
   
 
   
<li> The default name of the Online EXEC procedure is M204DEF.</li>
+
<li> The default name of the Online EXEC procedure is <code>M204DEF</code>.</li>
 
   
 
   
 
<li> If one operand is specified, it is assumed to be the name of the Online EXEC procedure.</li>
 
<li> If one operand is specified, it is assumed to be the name of the Online EXEC procedure.</li>
 
   
 
   
<li> EXEC procedures invoked by ONLINE provide the necessary <var class="product">Model&nbsp;204</var> parameters.</li>
+
<li> EXEC procedures invoked by <var>ONLINE</var> provide the necessary <var class="product">Model&nbsp;204</var> parameters.</li>
 
   
 
   
 
<li> Required options must be placed in the stack (the &amp;STACK command) as keyword-value pairs, separated by blanks.</li>
 
<li> Required options must be placed in the stack (the &amp;STACK command) as keyword-value pairs, separated by blanks.</li>
 
   
 
   
<li> If IFDIAL is specified, the main (nonrecovery) EXEC must provide only one parameter, the user program name, in the stack. The program name must be placed in the CMS stack before returning to the ONLINE EXEC.
+
<li> If IFDIAL is specified, the main (nonrecovery) EXEC must provide only one parameter, the user program name, in the stack. The program name must be placed in the CMS stack before returning to the ONLINE EXEC.  
 +
<p>
 +
The <var>IFSETUP</var> function (see the <var class="book">[[Media:M204 HLIReference V75.pdf|Rocket Model 204 Host Language Interface Reference Manual]]</var>) is used to send the CCAIN parameters via the user program. Neither CCAIN nor CCAPRINT are used for IFDIAL connections. </p></li>
 
   
 
   
<p>The IFSETUP function (see the Rocket <var class="product">Model&nbsp;204</var> Host Language Interface Reference Manual) is used to send the CCAIN parameters via the user program. Neither CCAIN nor CCAPRINT are used for IFDIAL connections. </p></li>
+
<li> A single-user <var class="product">Model&nbsp;204</var> interactive Online environment uses an EXEC procedure, <code>SAMPSING</code>, which is supplied as part of the distributed material. An IODEV statement is not required.  (See [[#Server areas|Server areas]].)
 
   
 
   
<li> A single-user <var class="product">Model&nbsp;204</var> interactive Online environment uses an EXEC procedure, SAMPSING, which is supplied as part of the distributed material. An IODEV statement is not required.  (See [[Server areas]].)
+
<p>Customize and install SAMPSING and its companion, SAMPSING CCAIN, on a generally accessible CMS minidisk. Name the customized files <code>SINGLUSR EXEC</code> and <code>SINGLUSR CCAIN</code> to sustain compatibility with the standard  distributed user interfaces. </p></li>
 
<p>Customize and install SAMPSING and its companion, SAMPSING CCAIN, on a generally accessible CMS minidisk. Name the customized files SINGLUSR EXEC and SINGLUSR CCAIN to sustain compatibility with the standard  distributed user interfaces. </p></li>
 
 
</ul>
 
</ul>
 
   
 
   
Line 319: Line 350:
 
<li> Any other return code is considered an error and causes the ONLINE EXEC to terminate immediately. </li>
 
<li> Any other return code is considered an error and causes the ONLINE EXEC to terminate immediately. </li>
 
</ul>
 
</ul>
+
 
 
====Example====
 
====Example====
 
   
 
   
Line 332: Line 363:
 
   
 
   
 
<li> Execute a user-written EXEC (DOCONLN) that defines the ONLINE environment </li>
 
<li> Execute a user-written EXEC (DOCONLN) that defines the ONLINE environment </li>
</ul>  
+
</ul>
+
 
 
==CMS utilities and EXECs==
 
==CMS utilities and EXECs==
 
<p>
 
<p>
Line 502: Line 533:
 
</p>
 
</p>
 
   
 
   
===Using the M204MOUN EXEC to mount and dismount tapes===
+
===Using the M204MOUN EXEC to mount and dismount tapes===  
+
<p>
<p>When a tape must be mounted, the CMS interface to <var class="product">Model&nbsp;204</var> invokes the EXEC procedure M204MOUN, passing the DDname, device address, volume serial number, volume sequence, and access type (READ or WRITE) as arguments.</p>
+
When a tape must be mounted, the CMS interface to <var class="product">Model&nbsp;204</var> invokes the EXEC procedure M204MOUN, passing the DDname, device address, volume serial number, volume sequence, and access type (READ or WRITE) as arguments.</p>
 
   
 
   
 
<p>The M204MOUN EXEC determines the status of the tape device, issues appropriate Control Program and CMS commands, and sends a message to the system operator for a tape mount and drive attachment to the service  virtual machine, if necessary. </p>
 
<p>The M204MOUN EXEC determines the status of the tape device, issues appropriate Control Program and CMS commands, and sends a message to the system operator for a tape mount and drive attachment to the service  virtual machine, if necessary. </p>
Line 510: Line 541:
 
<p>Based on criteria at its disposal, the EXEC can reject the attempt to mount the tape. You can alter the M204MOUN EXEC defaults to meet site requirements.</p>
 
<p>Based on criteria at its disposal, the EXEC can reject the attempt to mount the tape. You can alter the M204MOUN EXEC defaults to meet site requirements.</p>
 
   
 
   
<p>When a tape volume is dismounted, the CMS interface to <var class="product">Model&nbsp;204</var> invokes the EXEC procedure M204UNLD, passing the DDname, device address, volume serial number, volume sequence, access type (READ or WRITE), and  file status (EOV or EOF) as arguments.               </p>
+
<p>When a tape volume is dismounted, the CMS interface to <var class="product">Model&nbsp;204</var> invokes the EXEC procedure M204UNLD, passing the DDname, device address, volume serial number, volume sequence, access type (READ or WRITE), and  file status (EOV or EOF) as arguments.  
 
 
<ul>
 
<ul>
 
<li> EOV (request another volume) indicates an entry at end-of-volume.</li>
 
<li> EOV (request another volume) indicates an entry at end-of-volume.</li>
</li>
+
 
 
<li> EOF (no further requests) indicates an entry due to end-of-file. </li>
 
<li> EOF (no further requests) indicates an entry due to end-of-file. </li>
</li>
+
</ul></p>
</ul>
+
 
 
 
==BATCH204 JCL with CCAIN==
 
==BATCH204 JCL with CCAIN==
 
   
 
   
===SAMPLE: z/OS JCL for invoking a BATCH204 run===
+
===Sample z/OS JCL for invoking a BATCH204 run===
 
   
 
   
<p class="code">//RUN      EXEC    PGM=BATCH204,REGION=1200K,
+
<p class="code"><nowiki>//RUN      EXEC    PGM=BATCH204,REGION=1200K,
 
//                TIME=10,PARM='SYSOPT=144'
 
//                TIME=10,PARM='SYSOPT=144'
 
   
 
   
Line 542: Line 571:
 
.
 
.
 
.
 
.
</p>
+
</nowiki></p>
 
<p>STEPLIB points to the load module library where the <var class="product">Model&nbsp;204</var> program is linked.</p>
 
<p>STEPLIB points to the load module library where the <var class="product">Model&nbsp;204</var> program is linked.</p>
 
   
 
   
 
<ul>
 
<ul>
 
<li> If the load module library is added to the LINKLIB concatenation, STEPLIB is not necessary.</li>
 
<li> If the load module library is added to the LINKLIB concatenation, STEPLIB is not necessary.</li>
</li>
+
 
 
<li> If EXCPVR under z/OS is used, STEPLIB must be authorized. </li>
 
<li> If EXCPVR under z/OS is used, STEPLIB must be authorized. </li>
</li>
 
 
</ul>
 
</ul>
+
 
 
==Runtime environment specifications==
 
==Runtime environment specifications==
 
   
 
   
Line 557: Line 585:
 
   
 
   
 
<p>The following sections explain how to set EXEC parameters, discuss the most commonly used User 0 parameters, and detail procedures specific to z/VSE and z/VM environments.</p>
 
<p>The following sections explain how to set EXEC parameters, discuss the most commonly used User 0 parameters, and detail procedures specific to z/VSE and z/VM environments.</p>
 
<p>For complete information on parameters, refer to the <var class="product">Model&nbsp;204</var> Parameter and Command Reference.</p>
 
 
   
 
   
 
===Specifying EXEC statement parameters===
 
===Specifying EXEC statement parameters===
+
<p>
<p>The JCL EXEC statement includes the following parameters that affect the runtime environment (see the sample in [[z/OS JCL]]). </p>
+
The JCL EXEC statement includes the following parameters that affect the runtime environment (see the sample in [[#z/OS JCL|z/OS JCL]]). </p>
 
   
 
   
 
<ul>
 
<ul>
<li> PGM specifies the <var class="product">Model&nbsp;204</var> configuration.</li>
+
<li>PGM specifies the <var class="product">Model&nbsp;204</var> configuration.</li>
 
   
 
   
 
<li> TIME specifies how long <var class="product">Model&nbsp;204</var> can run before being canceled by the operating system. Specify at least 10 seconds for system initialization and normal termination.
 
<li> TIME specifies how long <var class="product">Model&nbsp;204</var> can run before being canceled by the operating system. Specify at least 10 seconds for system initialization and normal termination.
Line 571: Line 597:
 
Under z/OS, if TIME is set to 1440, the operating system's automatic cancellation of the run is bypassed. If the <var class="product">Model&nbsp;204</var> automatic shutdown facility is also bypassed, then <var class="product">Model&nbsp;204</var> can run indefinitely until  brought down by other means.</p></li>
 
Under z/OS, if TIME is set to 1440, the operating system's automatic cancellation of the run is bypassed. If the <var class="product">Model&nbsp;204</var> automatic shutdown facility is also bypassed, then <var class="product">Model&nbsp;204</var> can run indefinitely until  brought down by other means.</p></li>
 
   
 
   
<li> PARM sets various <var class="product">Model&nbsp;204</var> parameters, including the LIBUFF parameter and SYSOPT parameter, which is described in [[SYSOPT parameter options]].
+
<li> PARM sets various <var class="product">Model&nbsp;204</var> parameters, including the <var>[[LIBUFF parameter|LIBUFF]]</var> parameter and the <var>[[SYSOPT parameter|SYSOPT]]</var> parameter, which is described in the [[#Setting the SYSOPT parameter|SYSOPT parameter options]] table.
 
   
 
   
<p class="note"><b>Note:</b> The value set for LIBUFF takes effect immediately, so you must set LIBUFF large enough to accommodate CCAIN.</p></li>
+
<p class="note"><b>Note:</b> The value set for <var>LIBUFF</var> takes effect immediately, so you must set <var>LIBUFF</var> large enough to accommodate CCAIN.</p></li>
 
   
 
   
 
<li> REGION specifies the size of the memory area allocated for the <var class="product">Model&nbsp;204</var> configuration. The next section explains how to estimate the value of this parameter.  </li>
 
<li> REGION specifies the size of the memory area allocated for the <var class="product">Model&nbsp;204</var> configuration. The next section explains how to estimate the value of this parameter.  </li>
 
</ul>
 
</ul>
+
 
 
===Calculating region size===
 
===Calculating region size===
+
<p>
<p>Consider the following factors when estimating region size for an Online system (z/OS) or z/VM machine size (CMS):</p>
+
Consider the following factors when estimating region size for an Online system (z/OS) or z/VM machine size (CMS):</p>
 
   
 
   
 
<ul>
 
<ul>
 
<li> Size of the load module, which varies depending on the use of optional modules </li>
 
<li> Size of the load module, which varies depending on the use of optional modules </li>
 
   
 
   
<li> Spare core (SPCORE) specification, the default is 8192 bytes
+
<li> Spare core (<var>SPCORE</var>) specification, the default is 8192 bytes
 
   
 
   
<p>Increase the default, if you use deferred update, the FLOD exit (FLODXT) feature, directed output, or active subsystems. Additional memory is also required to open sequential data sets. The requirements for  FLODXT are given under SPCORE in [[#Common runtime parameters|Common runtime parameters]].  </p></li>
+
<p>Increase the default, if you use deferred update, the FLOD exit (FLODXT) feature, directed output, or active subsystems. Additional memory is also required to open sequential data sets. The requirements for  FLODXT are given under <var>SPCORE</var> in the [[#User 0 parameters|"Common runtime parameters" table]].  </p></li>
 
   
 
   
 
<li> Number of buffers used for each server
 
<li> Number of buffers used for each server
 
   
 
   
<p>Four buffers for each server is the minimum requirement. Each buffer requires slightly more than one <var class="product">Model&nbsp;204</var> page. The main memory required is dependent upon the SERVSIZE parameter setting. </p>
+
<p>Four buffers for each server is the minimum requirement. Each buffer requires slightly more than one <var class="product">Model&nbsp;204</var> page. The main memory required is dependent upon the <var>SERVSIZE</var> parameter setting. </p>
 
   
 
   
 
<p>No work space is required. Under normal conditions, five active users or application threads can be serviced efficiently by one server.  </p></li>
 
<p>No work space is required. Under normal conditions, five active users or application threads can be serviced efficiently by one server.  </p></li>
Line 597: Line 623:
 
<li> Number of servers allocated
 
<li> Number of servers allocated
 
   
 
   
<p>The size of each user's area is dependent on the settings of the compiler table parameters governing the size and complexity of the User Language requests. The formula to calculate server area size is given  in [[#Sizing user server areas|Sizing user server areas]].</p>
+
<p>The size of each user's area is dependent on the settings of the compiler table parameters governing the size and complexity of the SOUL requests. The formula to calculate server area size is given  in [[#Sizing user server areas|Sizing user server areas]].</p>
 
   
 
   
 
<p>In exceptional cases, processing needs might require a distinct server for each user.</p>
 
<p>In exceptional cases, processing needs might require a distinct server for each user.</p>
Line 609: Line 635:
 
   
 
   
 
===Setting the SYSOPT parameter===
 
===Setting the SYSOPT parameter===
+
<p>
<p>SYSOPT values, which can be summed, define actions taken during a run. Individual SYSOPT options are shown in the "SYSOPT parameter options" table: </p>
+
<var>SYSOPT</var> values, which can be summed, define actions taken during a run. Individual <var>SYSOPT</var> options are shown in the following table: </p>
 
   
 
   
 
<table>
 
<table>
 
<caption>SYSOPT parameter options</caption>
 
<caption>SYSOPT parameter options</caption>
 
<tr class="head">
 
<tr class="head">
<th>
+
<th><p>Option</p> </th>
<p>Option</p>
+
<th><p>Specifies...</p> </th>
</th>
+
</tr>
<th>
+
   
<p>Specifies...</p>
 
</th>
 
</tr>
 
   
 
 
<tr>
 
<tr>
 
<td>
 
<td>
<p>128</p>
+
<p>128</p> </td>
</td>
 
 
<td>
 
<td>
<p>Log for the CCAJRNL and the CCAAUDIT data sets</p>
+
<p>Log for the CCAJRNL and the CCAAUDIT data sets</p> </td>
</td>
 
 
</tr>
 
</tr>
 
   
 
   
 
<tr>
 
<tr>
 
<td>
 
<td>
<p>64</p>
+
<p>64</p> </td>
</td>
 
 
<td>
 
<td>
<p>Abend without a dump when the return code is nonzero</p>
+
<p>Abend without a dump when the return code is nonzero</p> </td>
</td>
 
 
</tr>
 
</tr>
 
   
 
   
 
<tr>
 
<tr>
 
<td>
 
<td>
<p>32</p>
+
<p>32</p> </td>
</td>
 
 
<td>
 
<td>
<p>Print lines relating to system initialization or IFAM function calls (RK lines) on the audit trail or journal</p>
+
<p>Print lines relating to system initialization or IFAM function calls (RK lines) on the audit trail or journal</p> </td>
</td>
 
 
</tr>
 
</tr>
 
   
 
   
 
<tr>
 
<tr>
 
<td>
 
<td>
<p>16</p>
+
<p>16</p> </td>
</td>
 
 
<td>
 
<td>
<p>Login is required </p>
+
<p>Login is required </p> </td>
</td>
 
 
</tr>
 
</tr>
 
   
 
   
 
<tr>
 
<tr>
 
<td>
 
<td>
<p>8</p>
+
<p>8</p> </td>
</td>
 
 
<td>
 
<td>
<p>Automatic disconnect operation in response to the LOGOUT command</p>
+
<p>Automatic disconnect operation in response to the LOGOUT command</p> </td>
</td>
 
 
</tr>
 
</tr>
 
   
 
   
 
<tr>
 
<tr>
 
<td>
 
<td>
<p>4</p>
+
<p>4</p> </td>
</td>
 
 
<td>
 
<td>
<p>Execution of data definition commands within a particular run only through the File Management facility of Dictionary </p>
+
<p>Execution of data definition commands within a particular run only through the File Management facility of Dictionary </p></td>
</td>
 
 
</tr>
 
</tr>
 
   
 
   
 
<tr>
 
<tr>
 
<td>
 
<td>
<p>2</p>
+
<p>2</p> </td>
</td>
 
 
<td>
 
<td>
<p>Existing permanent group file (CCAGRP) is required</p>
+
<p>Existing permanent group file (CCAGRP) is required</p> </td>
</td>
 
 
</tr>
 
</tr>
 
   
 
   
 
<tr>
 
<tr>
 
<td>
 
<td>
<p>1</p>
+
<p>1</p> </td>
</td>
 
 
<td>
 
<td>
<p>CCASYS file, which is required for subsystem applications </p>
+
<p>CCASYS file, which is required for subsystem applications </p> </td>
</td>
 
 
</tr>
 
</tr>
 
</table>
 
</table>
Line 714: Line 720:
 
/&amp;
 
/&amp;
 
</p>
 
</p>
<p>For a full example, see [[z/VSE JCL]].</p></li>
+
<p>For a full example, see [[#z/VSE JCL|z/VSE JCL]].</p></li>
 
   
 
   
 
<li> A disk data set. Use any utility that takes card input and writes it to a file of 80-byte unblocked records. You must also supply a DLBL and EXTENT for either CCAIN or IJSYSIN:  </li>
 
<li> A disk data set. Use any utility that takes card input and writes it to a file of 80-byte unblocked records. You must also supply a DLBL and EXTENT for either CCAIN or IJSYSIN:  </li>
Line 722: Line 728:
 
<li> For IJSYSIN, the symbolic unit referenced on the EXTENT statement must be SYSIPT. </li>
 
<li> For IJSYSIN, the symbolic unit referenced on the EXTENT statement must be SYSIPT. </li>
 
   
 
   
<li> Procedure with the DATA=YES option on the CATALP statement.</li>
+
<li> Procedure with the <code>DATA=YES</code> option on the CATALP statement.</li>
 
</ul>
 
</ul>
 
   
 
   
 
===User 0 input file in the z/VM environment===
 
===User 0 input file in the z/VM environment===
+
<p>
<p>In z/VM, the User 0 output file is specified as a file stored on a minidisk. There are no restrictions on the choice of the CMS file identifier. For example:</p>
+
In z/VM, the User 0 output file is specified as a file stored on a minidisk. There are no restrictions on the choice of the CMS file identifier. For example:</p>
 
   
 
   
 
<p class="code">FILEDEF CCAIN DISK DOCONLN CCAIN A
 
<p class="code">FILEDEF CCAIN DISK DOCONLN CCAIN A
 
</p>
 
</p>
<p><var class="product">Model&nbsp;204</var> also runs within a user's virtual machine in a single-user mode. In this case the file is defined with a FILEDEF command, similar to the example shown above, in the single-user EXEC. Runtime parameters  are set up the same as for multiple users, except that the number of users is set to one (NUSERS=1).</p>
+
<p><var class="product">Model&nbsp;204</var> also runs within a user's virtual machine in a single-user mode. In this case the file is defined with a FILEDEF command, similar to the example shown above, in the single-user EXEC. Runtime parameters  are set up the same as for multiple users, except that the number of users is set to one (<code>NUSERS=1</code>).</p>
 
   
 
   
===Stacking z/VM runtime parameters===
+
===Stacking z/VM runtime parameters===  
+
<p>
<p>In a z/VM environment, the EXEC containing the FILEDEF commands can specify SYSOPT (and any other runtime parameters) before initialization by stacking the parameters:</p>
+
In a z/VM environment, the EXEC containing the FILEDEF commands can specify SYSOPT (and any other runtime parameters) before initialization by stacking the parameters:</p>
 
   
 
   
 
<p class="code">&amp;C FILEDEF CCAIN DISK DOCONLN CCAIN A
 
<p class="code">&amp;C FILEDEF CCAIN DISK DOCONLN CCAIN A
Line 756: Line 762:
 
<caption>Common runtime parameters</caption>
 
<caption>Common runtime parameters</caption>
 
<tr class="head">
 
<tr class="head">
<th>
+
<th><p>Parameter</p></th>
<p>Parameter</p>
+
<th><p>Specifies...</p></th>
</th>
 
<th>
 
<p>Specifies...</p>
 
</th>
 
 
</tr>
 
</tr>
 
   
 
   
Line 767: Line 769:
 
<td>
 
<td>
 
<p><var>[[CFRLOOK parameter|CFRLOOK]]</var></p>
 
<p><var>[[CFRLOOK parameter|CFRLOOK]]</var></p>
</td>
+
</td><td>
<td>
 
 
<p>Collect critical file resources conflict statistics.</p>
 
<p>Collect critical file resources conflict statistics.</p>
  </td>
+
</td></tr>
</tr>
+
   
 +
<tr><td>
 +
<p><var>[[CPMAX parameter|CPMAX]]</var></p></td>
 +
<td><p>Maximum number of checkpoints</p>
 +
</td></tr>
 
   
 
   
<tr>
+
<tr><td>
<td>
+
<p><var>[[CPTIME parameter|CPTIME]]</var></p></td>
<p><var>[[CPMAX parameter|CPMAX]]</var></p>
 
</td>
 
<td>
 
<p>Maximum number of checkpoints</p>
 
</td>
 
</tr>
 
 
<tr>
 
<td>
 
<p><var>[[CPTIME parameter|CPTIME]]</var></p>
 
</td>
 
 
<td>
 
<td>
 
<p>Checkpoint time intervals</p>
 
<p>Checkpoint time intervals</p>
</td>
+
</td></tr>
</tr>
 
 
   
 
   
<tr>
+
<tr><td>
<td>
+
<p><var>[[LENQTBL parameter|LENQTBL]]</var></p></td>
<p><var>[[LENQTBL parameter|LENQTBL]]</var></p>
 
</td>
 
 
<td>
 
<td>
<p>Number of entries in each user's resource enqueuing table. (See page 2-22 for sizing formulas.) The default is 6. </p>
+
<p>Number of entries in each user's resource enqueuing table. (See [[#Resource locking table|Resource locking table]] for sizing formulas.) The default is 6. </p>
</td>
+
</td></tr>
</tr>
 
 
   
 
   
<tr>
+
<tr><td>
<td>
 
 
<p><var>[[LIBUFF parameter|LIBUFF]]</var></p>
 
<p><var>[[LIBUFF parameter|LIBUFF]]</var></p>
</td>
+
</td>
 
<td>
 
<td>
<p>Length of the input buffer used for input lines from CCAIN or the user's terminal. LIBUFF must be three bytes longer than the longest line or record read into it. Longer lines are rejected with an error message.  The default is 255.</p>
+
<p>Length of the input buffer used for input lines from CCAIN or the user's terminal. <var>LIBUFF</var> must be three bytes longer than the longest line or record read into it. Longer lines are rejected with an error message.  The default is 255.</p>
 
   
 
   
<p>If an input line is continued with a nonblank character, the number of characters in the original line and all continuations (not including
+
<p>If an input line is continued with a nonblank character, the number of characters in the original line and all continuations (not including continuation characters) must fit in the <var>LIBUFF</var> specification. </p></td></tr>
continuation characters) must fit in the LIBUFF specification. </p>
 
</td>
 
</tr>
 
 
   
 
   
<tr>
+
<tr><td>
<td>
+
<p><var>[[LOBUFF parameter|LOBUFF]]</var></p></td>
<p><var>[[LOBUFF parameter|LOBUFF]]</var></p>
 
</td>
 
 
<td>
 
<td>
 
<p>Length of the output buffer used for output lines to
 
<p>Length of the output buffer used for output lines to
 
  CCAAUDIT, CCAPRINT, for a user's terminal, or for a directed output (USE) data set. LOBUFF can be reset on individual user parameter lines. The default is 256. The recommended value for SQL processing is 5000.</p>
 
  CCAAUDIT, CCAPRINT, for a user's terminal, or for a directed output (USE) data set. LOBUFF can be reset on individual user parameter lines. The default is 256. The recommended value for SQL processing is 5000.</p>
</td>
+
</td></tr>
</tr>
 
 
   
 
   
<tr>
+
<tr><td>
 +
<p><var>[[LOGADD parameter|LOGADD]]</var></p></td>
 
<td>
 
<td>
<p><var>[[LOGADD parameter|LOGADD]]</var></p>
+
<p>Number of slots reserved for adding new password (CCASTAT) entries. The default is 0. </p>
</td>
+
</td></tr>
 +
 +
<tr><td>
 +
<p><var>[[LOGFAIL parameter|LOGFAIL]]</var></p></td>
 
<td>
 
<td>
<p>Number of slots reserved for adding new password
+
<p>Action taken when the number of consecutive login failures exceeds the value of the <var>LOGTRY</var> parameter. Default is 0. </p>
(CCASTAT) entries. The default is 0. </p>
+
</td></tr>
</td>
 
</tr>
 
 
   
 
   
<tr>
+
<tr><td>
 +
<p><var>[[LOGONENQ parameter|LOGONENQ]]</var></p></td>
 
<td>
 
<td>
<p><var>[[LOGFAIL parameter|LOGFAIL]]</var></p>
+
<p>Use of unique user IDs for systemwide logons to a single ONLINE system. (See the <var>LOGONENQ</var> entry in the [[#userenvTable|"User environment control parameters" table]] to specify unique user IDs  for specific terminals.) The default is 0. </p>
  </td>
+
 +
<p>The Subsystem Management facility is not affected by LOGONENQ.</p>
 +
</td></tr>
 +
 +
<tr><td>
 +
<p><var>[[LOGTRY parameter|LOGTRY]]</var></p></td>
 +
<td>
 +
<p>Maximum number of login attempts allowed. The default is 0. </p>
 +
</td></tr>
 +
   
 +
<tr><td>
 +
<p><var>[[LRETBL parameter|LRETBL]]</var></p></td>
 
<td>
 
<td>
<p>Action taken when the number of consecutive login failures exceeds the value of the LOGTRY parameter. Default is 0. </p>
+
<p>Length of each user's part of the record enqueuing table. (See [[#Resource locking|Resource locking]].) Default is 200.</p>
</td>
+
</td></tr>
</tr>
 
 
   
 
   
<tr>
+
<tr><td>
 +
<p><var>[[LRUTIM parameter|LRUTIM]]</var></p></td>
 
<td>
 
<td>
<p><var>[[LOGONENQ parameter|LOGONENQ]]</var></p>
+
<p>Disk page reference interval for references considered obsolete. Use <var>LRUTIM</var> to calculate DKRR statistics. The default is 0.</p>
</td>
+
</td></tr>
 +
 +
<tr><td>
 +
<p><var>[[MAXBUF parameter|MAXBUF]]</var></p></td>
 
<td>
 
<td>
<p>Use of unique user IDs for systemwide logons to a single ONLINE system. (See the LOGONENQ entry in the [[Resource locking#userenvTable|"User environment control parameters" table]] to specify unique user IDs  for specific terminals.) The default is 0.             </p>
+
<p>Maximum number of file page buffers allocated below the bar during <var class="product">Model&nbsp;204</var> initialization. (See [[#Disk buffers and Model 204 storage|Disk buffers and Model 204 storage]].) The default is 256.</p>
 +
</td></tr>
 
   
 
   
<p>The Subsystem Management facility is not affected by LOGONENQ.</p>
+
<tr><td>
</td>
+
<p><var>[[MINBUF parameter|MINBUF]]</var></p></td>
</tr>
+
<td>
 +
<p>Minimum number of file page buffers allocated below the bar during <var class="product">Model&nbsp;204</var> initialization. (See [[#Disk buffers and Model 204 storage|Disk buffers and Model 204 storage]].) The default is 18.</p>
 +
</td></tr>
 
   
 
   
<tr>
+
<tr><td>
 +
<p><var>[[NDCBS parameter|NDCBS]]</var></p></td>
 
<td>
 
<td>
<p><var>[[LOGTRY parameter|LOGTRY]]</var></p>
+
<p>Number of <var class="product">Model&nbsp;204</var> file DCBs that can be used at any one time. The default is 10.</p>
</td>
+
</td></tr>
 +
 +
<tr><td>
 +
<p><var>[[NDIR parameter|NDIR]]</var></p></td>
 
<td>
 
<td>
<p>Maximum number of login attempts allowed. The default is 0. </p>
+
<p>Maximum number of <var class="product">Model&nbsp;204</var> files that can be opened during a run. The default is 5.</p>
</td>
+
</td></tr>
</tr>
 
 
   
 
   
<tr>
+
<tr><td>
 +
<p><var>[[NFILES parameter|NFILES]]</var></p></td>
 
<td>
 
<td>
<p><var>[[LRETBL parameter|LRETBL]]</var></p>
+
<p>Maximum number of <var class="product">Model&nbsp;204</var> files that can be open at any one time. Files remain open until an explicit CLOSE is issued or the session ends. The default is 2. </p>
</td>
+
 +
<p><var>NFILES</var>, <var>NDCBS</var>, and <var>NDIR</var> specifications are automatically incremented during system initialization if <code>SYSOPT=2</code> (permanent group file). With the <var>VIEW</var> command, you can view parameter values during a run.</p>
 +
</td></tr>
 +
 +
<tr><td>
 +
<p><var>[[NGROUP parameter|NGROUP]]</var></p>
 +
</td>
 
<td>
 
<td>
<p>Length of each user's part of the record enqueuing table. (See [[Resource locking]].) Default is 200.</p>
+
<p>Maximum number of file groups each user can have open at the same time. The default is 5.</p>
</td>
+
</td></tr>
</tr>
 
 
   
 
   
 
<tr>
 
<tr>
 
<td>
 
<td>
<p><var>[[LRUTIM parameter|LRUTIM]]</var></p>
+
<p><var>[[NSERVS parameter|NSERVS]]</var></p>
 
  </td>
 
  </td>
 
<td>
 
<td>
<p>Disk page reference interval for references considered obsolete. Use LRUTIM to calculate DKRR statistics. The default is 0.</p>
+
<p>Number of servers. The default is <var>NUSERS</var> (see below). </p>
  </td>
+
</td></tr>
</tr>
+
   
 +
<tr><td>
 +
<p><var>[[NSUBTKS parameter|NSUBTKS]]</var></p></td>
 +
<td>
 +
<p>Maximum number of pseudo subtasks that can be generated in a <var class="product">Model&nbsp;204</var> run. The default is 4.</p>
 +
</td></tr>
 
   
 
   
<tr>
+
<tr><td>
 +
<p><var>[[NUMBUFG parameter|NUMBUFG]]</var></p></td>
 
<td>
 
<td>
<p><var>[[MAXBUF parameter|MAXBUF]]</var></p>
+
<p>Number of file page buffers allocated above the bar during <var class="product">Model&nbsp;204</var> initialization. (See [[#Disk buffers and Model 204 storage|Disk buffers and Model 204 storage]].) The default is 0.</p>
</td>
+
</td></tr>
 +
 
 +
<tr><td>
 +
<p><var>[[NUSERS parameter|NUSERS]]</var></p></td>
 
<td>
 
<td>
<p>Maximum number of file page buffers allocated during <var class="product">Model&nbsp;204</var> initialization. (See [[Disk buffers and Model 204 storage]].) The default is 256.</p>
+
<p>Total number of SOUL users and IFAM2 or IFAM4 threads supported. The default is 1. The value of <var>NUSERS</var> consists of the total number of I/O device types (IODEVs) specified on the user parameter lines plus 1  for User 0. Online users are defined as terminal users with a particular type of terminal or as a host language thread, if IFAM is supported in the online region.</p>
</td>
+
</td></tr>
</tr>
 
 
   
 
   
<tr>
+
<tr><td>
 +
<p><var>[[PAGEFIX parameter|PAGEFIX]]</var></p></td>
 
<td>
 
<td>
<p><var>[[MINBUF parameter|MINBUF]]</var></p>
+
<p>Fixes areas in memory; can be useful in reducing paging traffic under z/OS or z/VSE. The default is X `0000000', which means nothing is page fixed.</p>
</td>
+
 +
<p>For z/VSE only: A PAGEFIX request is valid only if real pages have been assigned by the ALLOC command. If ALLOC is 0 or if the total number of pages to be fixed exceeds the number of real pages, the PAGEFIX request  fails. </p>
 +
</td></tr>
 +
 +
<tr><td>
 +
<p><var>[[RETRVKEY parameter|RETRVKEY]]</var></p></td>
 
<td>
 
<td>
<p>Minimum number of file page buffers allocated during <var class="product">Model&nbsp;204</var> initialization. (See [[Disk buffers and Model 204 storage]].) The default is 18.</p>
+
<p>PF key used to retrieve a previous terminal input line. 280 bytes of spare core is required for each user that has a defined retrieve key. The default is 0.</p>
</td>
+
</td></tr>
</tr>
 
 
   
 
   
<tr>
+
<tr><td>
 +
<p><var>[[SEQOPT parameter|SEQOPT]]</var></p>
 +
</td>
 
<td>
 
<td>
<p><var>[[NDCBS parameter|NDCBS]]</var></p>
+
<p>Activation of the prefetch (look-ahead) feature for SOUL applications requiring entry order retrieval. Values are 1 (on) or 0 (off). The default is 0. Activation of SEQOPT requires resizing the <var>[[MAXBUF parameter|MAXBUF]]</var> parameter by using the formula: </p>
  </td>
+
   
 +
<p class="code">MAXBUF = NUSERS * (4 + 2 * [maximum FOR EACH RECORD loop nest level])
 +
</p>
 +
<p>
 +
You can modify SEQOPT with the RESET command. </p>
 +
</td></tr>
 +
 +
<tr><td>
 +
<p><var>[[SERVSIZE parameter|SERVSIZE]]</var></p>
 +
</td>
 
<td>
 
<td>
<p>Number of <var class="product">Model&nbsp;204</var> file DCBs that can be used at any one time. The default is 10.</p>
+
<p>Size of each server area. The default, formerly 0, is 65536. (See [[#Server areas|Server areas]].) </p>
  </td>
+
  </td></tr>
</tr>
 
 
   
 
   
<tr>
+
<tr><td>
 +
<p><var>[[SPCORE parameter|SPCORE]]</var></p></td>
 
<td>
 
<td>
<p><var>[[NDIR parameter|NDIR]]</var></p>
+
<p>Minimum amount of storage within the <var class="product">Model&nbsp;204</var> address space to leave unallocated at the end of <var class="product">Model&nbsp;204</var> initialization. You can set <var>SPCORE</var> in the EXEC statement PARM field or on the User 0 parameter line.  The default is 8192. Spare core is used by:  </p>
</td>
+
<ul>
<td>
+
<li> IFAM4 application program storage. The default is 12288. </li>
<p>Maximum number of <var class="product">Model&nbsp;204</var> files that can be opened during a run. The default is 5.</p>
+
 
</td>
+
<li> Active subsystems. (See the formula given in [[System requirements for Application Subsystems#SPCORE size|SPCORE size]].)</li>
 +
 
 +
<li> <var>FILELOAD</var> or <var>FLOD</var> commands for tape input and deferred update output. When using the FLODXT feature, you must allocate 100 bytes for each FLODXT program.</li>
 +
 
 +
<li> Each defined retrieval key for previous terminal input (180 bytes per key). </li>
 +
</ul>
 +
 +
<p>In z/OS, a number of bytes of virtual storage equal to your <var>SPCORE</var> setting is reserved above the line, and the same number is reserved below the line. The BTB amount is ignored in Model&nbsp;204 7.7 and higher if the <var>[[NUMBUFG parameter|NUMBUFG]]</var> parameter setting is greater than 0.</p> </td>
 
</tr>
 
</tr>
 
   
 
   
<tr>
+
<tr><td>
<td>
+
<p><var>[[TIMESTOP parameter|TIMESTOP]]</var></p></td>
<p><var>[[NFILES parameter|NFILES]]</var></p>
 
</td>
 
 
<td>
 
<td>
<p>Maximum number of <var class="product">Model&nbsp;204</var> files that can be open at any one time. Files remain open until an explicit CLOSE is issued or the session ends. The default is 2. </p>
+
<p>Amount of time (CPU milliseconds) before automatic termination processing begins or before initiation of commands or SOUL requests stops. TIMESTOP cannot be reset. The default is 1500.</p>
 
   
 
   
<p>NFILES, NDCBS, and NDIR specifications are automatically incremented during system initialization if SYSOPT=2 (permanent group file). With the VIEW command, you can view parameter values during a run.</p>
+
<p>
</td>
+
If TIMESTOP is set to 0, the <var class="product">Model&nbsp;204</var> timing facility's automatic shutdown is bypassed. If, in addition, the JCL EXEC statement parameter TIME is set to 1440, the z/OS automatic shutdown is bypassed, and <var class="product">Model&nbsp;204</var> continues to run indefinitely  until brought down by other means.</p>
</tr>
+
</td></tr>
 
   
 
   
<tr>
+
<tr><td><p><var>[[XMEMOPT parameter|XMEMOPT]]</var></p></td>
 
<td>
 
<td>
<p><var>[[NGROUP parameter|NGROUP]]</var></p>
+
<p><var class="product">Model&nbsp;204</var> Cross-Memory Services facility used by Timer PC and IOS Branch Entry for z/OS systems, as well as using SUSPEND/RESUME instead of WAIT/POST for communication between <var class="product">Model&nbsp;204</var> real subtasks. Coordinates  with <var>XMEMSVC</var>.</p>
</td>
+
<p>
<td>
+
It is also required for:</p>
<p>Maximum number of file groups each user can have open at the same time. The default is 5.</p>
+
</td>
+
<ul>
</tr>
+
<li> [[IOS Branch Entry]]</li>
 +
 
 +
<li> [[UL/DB2]]</li>
 +
 
 +
<li> [[Defining the user environment (CCAIN)#CRAM options for z/OS|CRAM-XDM]]</li>
 +
 
 +
<li> CPUID check (product license verification; prior to Model&nbsp;204 7.5)</li>
 +
</ul>
 +
<p>
 +
VIO is incompatible with IOSB and EXCPVR.</p>
 +
</td></tr>
 
   
 
   
<tr>
+
<tr><td><p><var>[[XMEMSVC parameter|XMEMSVC]]</var></p></td>
 
<td>
 
<td>
<p><var>[[NSERVS parameter|NSERVS]]</var></p>
+
<p>SVC number of the <var class="product">Model&nbsp;204</var> Cross-Memory Services module ([[Cross-memory facilities CRAM and M204XSVC#M204XSVC|M204XSVC]]). Installation of this module with an SVC is deprecated as of Model&nbsp;204 7.5. <var>XMEMSVC</var> coordinates with <var>XMEMOPT</var>. The default is 0. </p>
  </td>
+
<p>
<td>
+
M204XSVC is also used by:</p>
<p>Number of servers. The default is NUSERS (see below). </p>
+
<ul>
  </td>
+
<li> IOS Branch Entry</li>
 +
 
 +
<li> UL/DB2</li>
 +
 
 +
<li> CRAM-XDM</li>
 +
 
 +
<li> CPUID check (product license verification; prior to Model&nbsp;204 7.5)</li>
 +
</ul>
 +
</td></tr>
 +
</table>
 +
 
 +
===z/VSE UPSI Job Control statement===
 +
<p>
 +
In a z/VSE environment:</p>
 +
<ul>
 +
<li> Use the <var>SYSPARM</var> parameter of the z/VSE OPTION Job Control statement to specify a limited number of parameters that are normally specified on User 0 or any user's parameter lines, if the maximum length of the data does not exceed eight characters. For example, you can set the <var>LIBUFF</var> parameter with the following statement:
 +
<p class="code">// OPTION SYSPARM='LIB=2048'
 +
</p> </li>
 +
 +
<li> Set the <var>SYSOPT</var> value before initialization by using the z/VSE UPSI Job Control statement. Specify the value as a series of weighted UPSI bit values.
 +
<p>
 +
For example, including RK lines on the audit trail can be specified with the following statement, which is the equivalent of SYSOPT=32:</p>
 +
 +
<p class="code">00100000
 +
</p>
 +
<p>The "UPSI/SYSOPT settings" table summarizes the UPSI bit settings and <var>SYSOPT</var> equivalents: </p>
 +
   
 +
<table>
 +
<caption>UPSI/SYSOPT settings</caption>
 +
<tr class="head">
 +
<th><p>UPSI setting</p></th>
 +
<th><p>SYSOPT value</p></th>
 +
<th><p>Meaning</p></th>
 
</tr>
 
</tr>
 
   
 
   
 
<tr>
 
<tr>
 
<td>
 
<td>
<p><var>[[NSUBTKS parameter|NSUBTKS]]</var></p>
+
<p>10000000</p></td>
</td>
+
<td>
 +
<p>128</p></td>
 
<td>
 
<td>
<p>Maximum number of pseudo subtasks that can be generated in a <var class="product">Model&nbsp;204</var> run. The default is 4.</p>
+
<p>Generate audit trail and/or journal</p></td>
</td>
 
 
</tr>
 
</tr>
 
   
 
   
 
<tr>
 
<tr>
 
<td>
 
<td>
<p><var>[[NUSERS parameter|NUSERS]]</var></p>
+
<p>01000000</p></td>
</td>
 
 
<td>
 
<td>
<p>Total number of User Language users and IFAM2 or IFAM4 threads supported. The default is 1. The value of NUSERS consists of the total number of I/O device types (IODEVs) specified on the user parameter lines plus 1  for User 0. Online users are defined as terminal users with a particular type of terminal or as a host language thread, if IFAM is supported in the online region.</p>
+
<p>64</p></td>
</td>
+
<td>
 +
<p>Abend without a dump when the return code is nonzero</p></td>
 
</tr>
 
</tr>
 
   
 
   
 
<tr>
 
<tr>
 
<td>
 
<td>
<p><var>[[PAGEFIX parameter|PAGEFIX]]</var></p>
+
<p>00100000</p></td>
</td>
+
<td>
 +
<p>32</p></td>
 
<td>
 
<td>
<p>Fixes areas in memory; can be useful in reducing paging traffic under z/OS or z/VSE. The default is X `0000000', which means nothing is page fixed.</p>
+
<p>Include RK lines on the audit trail</p></td>
 +
</tr>
 
   
 
   
<p>For z/VSE only: A PAGEFIX request is valid only if real pages have been assigned by the ALLOC command. If ALLOC is 0 or if the total number of pages to be fixed exceeds the number of real pages, the PAGEFIX request  fails. </p>
+
<tr>
</td>
+
<td>
 +
<p>00010000</p></td>
 +
<td>
 +
<p>16 </p></td>
 +
<td>
 +
<p>Login required</p></td>
 
</tr>
 
</tr>
 
   
 
   
 
<tr>
 
<tr>
 
<td>
 
<td>
<p><var>[[RETRVKEY parameter|RETRVKEY]]</var></p>
+
<p>00001000</p></td>
</td>
+
<td>
 +
<p>8</p></td>
 
<td>
 
<td>
<p>PF key used to retrieve a previous terminal input line. 280 bytes of spare core is required for each user that has a defined retrieve key. The default is 0.</p>
+
<p>Automatic disconnect in response to the LOGOUT command</p></td>
</td>
 
 
</tr>
 
</tr>
 
   
 
   
 
<tr>
 
<tr>
 
<td>
 
<td>
<p><var>[[SEQOPT parameter|SEQOPT]]</var></p>
+
<p>00000100</p>
 
  </td>
 
  </td>
 
<td>
 
<td>
<p>Activation of the prefetch (look-ahead) feature for SOUL applications requiring entry order retrieval. Values are 1 (on) or 0 (off). The default is 0. Activation of SEQOPT requires resizing the <var>MAXBUF|MAXBUF parameter]]</var> parameter by using the formula: </p>
+
<p>4</p></td>
+
<td>
<p class="code">MAXBUF = NUSERS * (4 + 2 * [maximum FOR EACH RECORD loop nest level])
+
<p>Restrict the use of data definition commands within a run</p></td>
</p>
 
<p>
 
You can modify SEQOPT with the RESET command. </p>
 
</td>
 
 
</tr>
 
</tr>
 
   
 
   
 
<tr>
 
<tr>
 
<td>
 
<td>
<p><var>[[SERVSIZE parameter|SERVSIZE]]</var></p>
+
<p>00000010</p></td>
</td>
+
<td>
 +
<p>2</p></td>
 
<td>
 
<td>
<p>Size of each server area. The default is 0. (See [[Server areas]].) </p>
+
<p>Open CCAGRP for use of permanent file group</p></td>
</td>
 
 
</tr>
 
</tr>
 
   
 
   
 
<tr>
 
<tr>
 
<td>
 
<td>
<p><var>[[SPCORE parameter|SPCORE]]</var></p>
+
<p>00000001</p></td>
</td>
+
<td>
 +
<p>1</p></td>
 
<td>
 
<td>
<p>Minimum amount of storage within the <var class="product">Model&nbsp;204</var> address space to leave unallocated at the end of <var class="product">Model&nbsp;204</var> initialization. You can set SPCORE in the EXEC statement PARM field or on the User 0  parameter line.  The default is 8192. Spare core is used by:  </p>
+
<p>Open CCASYS for use of application subsystem definitions</p></td>
 +
</tr>
 +
</table></li>
 +
</ul>
 
   
 
   
<ul>
+
==Resource locking==
<li> IFAM4 application program storage. The default is 12288.  </li>
 
</li>
 
<li> Active subsystems. (See the formula given in [[System Requirements for Application Subsystems#SPCORE size|SPCORE size]].)</li>
 
</li>
 
<li> FILELOAD or FLOD commands for tape input and deferred update output. When using the FLODXT feature, you must allocate 100 bytes for each FLODXT program.</li>
 
</li>
 
<li> Each defined retrieval key for previous terminal input (180 bytes per key). </li>
 
</li>
 
</ul>
 
 
   
 
   
<p>In z/OS, a number of bytes of virtual storage equal to your SPCORE setting is reserved above the line, and the same number is reserved below the line.</p>
+
<p>To maintain data integrity, resource locking requests and reserves system and file resources for share (SHR) and exclusive (EXCL) use with other users. Data corruption is prevented by using linked lists of system and file  resources. Conflict in the locking table results from attempts to lock exclusively on a file resource.   </p>
</td>
 
</tr>
 
 
   
 
   
<tr>
+
<p>Resource locking messages indicate a wait for a file, a conflict for a resource, or that the table is full and needs to be increased with the LENQTBL parameter.</p>
<td>
 
<p><var>[[TIMESTOP parameter|TIMESTOP]]</var></p>
 
</td>
 
<td>
 
<p>Amount of time (CPU milliseconds) before automatic termination processing begins or before initiation of commands or User Language requests stops. TIMESTOP cannot be reset. The default is 1500.</p>
 
 
   
 
   
<p>
+
<p>Locking occurs on:</p>
If TIMESTOP is set to 0, the <var class="product">Model&nbsp;204</var> timing facility's automatic shutdown is bypassed. If, in addition, the JCL EXEC statement parameter TIME is set to 1440, the z/OS automatic shutdown is bypassed, and <var class="product">Model&nbsp;204</var> continues to run indefinitely  until brought down by other means.</p>
 
</td>
 
</tr>
 
 
<tr>
 
<td>
 
<p><var>[[XMEMOPT parameter|XMEMOPT]]</var></p>
 
</td>
 
<td>
 
<p><var class="product">Model&nbsp;204</var> Cross-Memory Services Facility used by Timer PC and IOS BRANCH ENTRY for z/OS systems, as well as using SUSPEND/RESUME instead of WAIT/POST for communication between <var class="product">Model&nbsp;204</var> real subtasks. Coordinates  with XMEMSVC.</p>
 
 
<p>It is also required for:</p>
 
 
   
 
   
 
<ul>
 
<ul>
<li> IOS Branch Entry</li>
+
<li> File resources, which are usually locked in SHR mode, such as:
</li>
+
<ul>
<li> UL/DB2</li>
+
<li> File access</li>
</li>
+
 
<li> CRAM-XDM</li>
+
<li> Record locking table</li>
</li>
+
 
<li> CPUID check</li>
+
<li> Table B and Group index</li>
</li>
+
 
 +
<li> Tables C and D</li>
 +
 
 +
<li> Permanent procedures</li>
 +
 
 +
<li> Access Control Table </li>
 +
</ul></li>
 +
 
 +
<li> System resources, which are usually locked in EXCL mode, such as:
 +
<ul>
 +
<li> Access to the CCASTAT file</li>
 +
 
 +
<li> Group definition table in CCATEMP</li>
 +
 
 +
<li> Updates to CCAGRP</li>
 +
 
 +
<li> Names of a file and subsystem</li>
 +
 
 +
<li> User defined resources</li>
 +
</ul></li>
 +
 
 +
<li>  Records </li>
 
</ul>
 
</ul>
 
   
 
   
 +
<p>The following sections explain the resource locking tables and the details of resource locking on single and multiple CPUs.</p>
 +
 +
===Record locking table===
 +
<p>
 +
The record locking table (also called: record enqueuing table), whose length is the product of the number of users (<var>[[NUSERS parameter|NUSERS]]</var>) and the length in bytes of one user's part of the table (<var>[[LRETBL parameter|LRETBL]]</var>), contains control information necessary to detect conflicts between users trying to update records simultaneously. </p>
 
<p>
 
<p>
To choose the correct setting for your site, see the <var class="product">Model&nbsp;204</var> wiki page for XMEMOPT: http://m204wiki.rocketsoftware.com/index.php/XMEMOPT_parameter </p>
+
You can issue a <code>MONITOR ENQ</code> command to determine current usage in the record locking table.</p>
 
   
 
   
<p>VIO is incompatible with IOSB and EXCPVR.</p>
+
====Calculating allocated size of record locking table====
</td>
+
<p>
</tr>
+
The amount of space required by a request is roughly proportional to the number of lists and <var>FIND</var> statements contained in the request. Each <var>FIND</var> statement or list requires about 46 bytes per file for files less than or  equal to 300,000 records. Space requirements increase at the rate of 2.25 bytes per segment. The maximum value is 65,535.</p>
 
   
 
   
<tr>
+
====SYSOPT2=X'40'====
<td>
+
<p>
<p><var>[[XMEMSVC parameter|XMEMSVC]]</var></p>
+
Record sets &mdash; found sets, including <var>FDWOL</var> found sets, sorted sets, lists, and LPU lists &mdash; are traced through entries in the record locking table. One entry is required for each segment (49,152 records) in the record set. These entries are CCATEMP page numbers. </p>
</td>
+
<p>
<td>
+
When the <var>[[SYSOPT2 parameter|SYSOPT2]]</var> X'40' bit is set, the entries contain 4-byte CCATEMP page numbers. Setting the X'40' bit provides a substantial increase in the number of simultaneous record sets that can be concurrently active in a given <var class="product">Model&nbsp;204</var> run. Therefore, if you set the <var>SYSOPT2</var> X'40' bit, you should also at least double the <var>LRETBL</var> value.</p>
<p>SVC number of the <var class="product">Model&nbsp;204</var> Cross-Memory Services. Coordinates with XMEMOPT.   The default is 0.
 
It is also required for:</p>
 
 
   
 
   
 
<ul>
 
<ul>
<li> IOS Branch Entry</li>
+
<li> When the <var>SYSOPT2</var> setting does not include X'40', then at any given time the bit maps corresponding to all users holding found sets of any kind must fit into CCATEMP pages designated as the small model page pool no matter  how large CCATEMP has been allocated.</li>
</li>
+
 
<li> UL/DB2</li>
+
<li> When the <var>SYSOPT2</var> setting does include X'40', the CCATEMP page restriction is removed and user found sets can be placed anywhere within CCATEMP. This includes both the small model page pool and the CCATEMP expansion area,  allowing for the possibility of a greater number of concurrent found sets being held by all users.</li>
</li>
 
<li> CRAM V4.1 feature</li>
 
</li>
 
<li> CRAM-XDM</li>
 
</li>
 
<li> CPUID check</li>
 
</li>
 
 
</ul>
 
</ul>
</td>
+
 
</tr>
+
===Resource locking table===
</table>
 
 
   
 
   
===z/VSE UPSI Job Control statement===
+
<p>You can use the <var>[[$CenqCt]]</var> function to obtain information on the number of unused entries in the resource locking table (also called: resource enqueuing table).  </p>
 
   
 
   
<p>In a z/VSE environment:</p>
+
====Sizing the resource locking table====
 
   
 
   
<ul>
+
<p>For details on estimating the size of the resource locking table, see <var>[[LENQTBL parameter|LENQTBL]]</var>.</p>
<li> Use the SYSPARM parameter of the z/VSE OPTION Job Control statement to specify a limited number of parameters that are normally specified on User 0 or any user's parameter lines, if the maximum length of the data does not  exceed eight characters. For example, you can set the LIBUFF parameter with the following statement:
 
<p class="code">// OPTION SYSPARM='LIB=2048'
 
</p> </li>
 
 
   
 
   
<li> Set the SYSOPT value before initialization by using the z/VSE UPSI Job Control statement. Specify the value as a series of weighted UPSI bit values.
+
<p>For z/OS, <var class="product">Model&nbsp;204</var> allocates the resource locking table above the 16-megabyte line. </p>
<p>
 
For example, including RK lines on the audit trail can be specified with the following statement, which is the equivalent of SYSOPT=32:</p>
 
 
   
 
   
<p class="code">00100000
+
===Multiple jobs running on one CPU===
</p>
 
<p>The "UPSI/SYSOPT settings" table summarizes the UPSI bit settings and SYSOPT equivalents: </p>
 
 
   
 
   
<table>
+
<p>Locking occurs at the file level when application files are shared between multiple jobs. </p>
<caption>UPSI/SYSOPT settings</caption>
+
   
<tr class="head">
+
<p>File locking modes is EXCL when:</p>
<th>
 
<p>UPSI
 
setting</p>
 
  </th>
 
<th>
 
<p>SYSOPT value</p>
 
  </th>
 
<th>
 
<p>
 
Meaning</p>
 
</th>
 
</tr>
 
 
   
 
   
<tr>
+
<ul>
<td>
+
<li>Files are opened from a SOUL thread or an IFAM1 thread that has file update privileges.</li>
<p>10000000</p>
 
</td>
 
<td>
 
<p>128</p>
 
</td>
 
<td>
 
<p>Generate audit trail and/or journal</p>
 
</td>
 
</tr>
 
 
   
 
   
<tr>
+
<li>Files are opened from an IFAM2 thread or an IFAM4 thread that has allowed updates with thread update and file update privileges.</li>
<td>
 
<p>01000000</p>
 
</td>
 
<td>
 
<p>64</p>
 
</td>
 
<td>
 
<p>Abend without a dump when the return code is nonzero</p>
 
</td>
 
</tr>
 
 
   
 
   
<tr>
+
<li>Command is entered to create or delete a permanent group.</li>
<td>
+
</ul>
<p>00100000</p>
+
   
</td>
+
<p>File locking is SHR mode when:</p>
<td>
 
<p>32</p>
 
  </td>
 
<td>
 
<p>Include RK lines on the audit trail</p>
 
</td>
 
</tr>
 
 
   
 
   
<tr>
+
<ul>
<td>
+
<li>Files are opened under any other circumstances than those listed above.</li>
<p>00010000</p>
 
</td>
 
<td>
 
<p>16 </p>
 
</td>
 
<td>
 
<p>Login required</p>
 
</td>
 
</tr>
 
 
   
 
   
<tr>
+
<li>Files are opened in deferred update mode. Such files remain in SHR mode for the duration of the run.
<td>
+
<p class="note"><b>Note:</b>
<p>00001000</p>
+
Up to 192 files can be opened in deferred update mode.
</td>
+
An attempt to exceed 192 files results in an error message.</p></li>
<td>
 
<p>8</p>
 
</td>
 
<td>
 
<p>Automatic disconnect in response to the LOGOUT command</p>
 
</td>
 
</tr>
 
 
   
 
   
<tr>
+
<li>Files have the file recovery option (<var>FRCVOPT</var>) parameter set to include X'10'. Locking on an application file does not occur when it is closed, unless <var>FRCVOPT</var> is set to X'10'. <var>FRCVOPT</var> is discussed extensively in [[File integrity and recovery]]. </li>
<td>
 
<p>00000100</p>
 
</td>
 
<td>
 
<p>4 </p>
 
</td>
 
<td>
 
<p>Restrict the use of data definition commands within a run</p>
 
</td>
 
</tr>
 
 
   
 
   
<tr>
+
<li>The <var class="product">Model&nbsp;204</var> job uses the CCAGRP data set. </li>
<td>
 
<p>00000010</p>
 
</td>
 
<td>
 
<p>2 </p>
 
</td>
 
<td>
 
<p>Open CCAGRP for use of permanent file group</p>
 
</td>
 
</tr>
 
 
<tr>
 
<td>
 
<p>00000001</p>
 
</td>
 
<td>
 
<p>1</p>
 
</td>
 
<td>
 
<p>Open CCASYS for use of application subsystem definitions</p>
 
</td>
 
</tr>
 
</table></li>
 
 
</ul>
 
</ul>
 
   
 
   
==Resource locking==
+
<p>The following sections explain how locking conflicts are handled by <var class="product">Model&nbsp;204</var>, and how data integrity is ensured when multiple jobs run on one CPU.</p>
 +
 
 +
===Handling locking conflicts===
 
   
 
   
<p>To maintain data integrity, resource locking requests and reserves system and file resources for share (SHR) and exclusive (EXCL) use with other users. Data corruption is prevented by using linked lists of system and file  resources. Conflict in the locking table results from attempts to lock exclusively on a file resource.    </p>
+
<p>Locking conflicts for application files are handled first by the operating system and next by <var class="product">Model&nbsp;204</var>.    </p>
 
   
 
   
<p>Resource locking messages indicate a wait for a file, a conflict for a resource, or that the table is full and needs to be increased with the LENQTBL parameter.</p>
+
<p>The operating system initially examines the disposition for all application files, as specified in the JCL for a job. If two jobs specify SHR for the same application file, the operating system allows both jobs access  to the file. When the second job attempts to process the application file, <var class="product">Model&nbsp;204</var> determines that another job poses a locking conflict.</p>
 
   
 
   
<p>Locking occurs on:</p>
+
<p><var class="product">Model&nbsp;204</var> reads the first page of the file and examines the lock, which is located on that page. If a conflict is detected, <var class="product">Model&nbsp;204</var> waits until the job's time limit is reached for the file to become available. Then,  if the file is not available, <var class="product">Model&nbsp;204</var> sends error messages to the operator's console and to the output device of the user who attempted to open the file.</p>
 
   
 
   
<ul>
+
<p>Error messages are issued once every five minutes until the file becomes available, the job time limit for an online job is reached, or the maximum number of error messages for a batch job (<var>ERMX</var>) is reached.</p>
<li> File resources, which are usually locked in SHR mode, such as:</li>
 
</li>
 
<li> File access</li>
 
</li>
 
<li> Record locking table</li>
 
</li>
 
<li> Table B and Group index</li>
 
</li>
 
<li> Tables C and D</li>
 
</li>
 
<li> Permanent procedures</li>
 
</li>
 
<li> Access Control Table </li>
 
</li>
 
<li> System resources, which are usually locked in EXCL mode, such as:</li>
 
</li>
 
<li> Access to the CCASTAT file</li>
 
</li>
 
<li> Group definition table in CCATEMP</li>
 
</li>
 
<li> Updates to CCAGRP</li>
 
</li>
 
<li> Names of a file and subsystem</li>
 
</li>
 
<li> User defined resources</li>
 
</li>
 
<li>  Records </li>
 
</li>
 
</ul>
 
 
   
 
   
<p>The following sections explain the resource locking tables and the details of resource locking on single and multiple CPUs.</p>
+
<p>Messages sent to the operator's console are:</p>
 
   
 
   
===Record locking table===
+
<ul>
 +
<li> For an Online job:
 
   
 
   
<p>The record locking table, whose length is the product of the number of users (NUSERS) and the length in bytes of one user's part of the table (LRETBL), contains control information necessary  to detect conflicts between users trying to update records simultaneously. </p>
+
<p class="code"><b></b>*** M204.0582: ACCESS TO FILE <i>filename</i> PREVENTED BY: <i>jobname</i>
+
<b></b>*** M204.0584: FILE IS IN USE &mdash; <i>filename</i>
<p>You can issue a MONITOR ENQ command to determine current usage in the record locking table.</p>
+
</p> </li>
 
   
 
   
====Calculating allocated size of record locking table====
+
<li>For a batch job the message sent from <var class="product">Model&nbsp;204</var> to the operator:
 
   
 
   
<p>The amount of space required by a request is roughly proportional to the number of lists and FIND statements contained in the request. Each FIND statement or list requires about 46 bytes per file for files less than or  equal to 300,000 records. Space requirements increase at the rate of 2.25 bytes per segment. The maximum value is 65,535.</p>
+
<p class="code"><b></b>*** M204.0582: ACCESS TO FILE <i>filename</i> PREVENTED BY: <i>jobname</i>
 
   
 
   
====SYSOPT2=X'40'====
+
<b></b>*** M204.0581: ENQ'ING TO SHR FOR FILE <i>filename volname</i>
 
   
 
   
<p>Record sets &mdash; found sets, including FDWOL found sets, sorted sets, lists, and LPU lists &mdash; are traced through entries in the record locking table. One entry is required for each segment (49,152 records) in the record set.  These entries are CCATEMP page numbers. </p>
+
<b></b>*** M204.0582: ACCESS TO FILE <i>filename</i> PREVENTED BY: <i>jobname</i>
 
   
 
   
<p>When SYSOPT2=X'40', the entries contain 4-byte CCATEMP page numbers. Setting SYSOPT=X'40' provides a substantial increase in the number of simultaneous record sets that can be concurrently active in a given <var class="product">Model&nbsp;204</var> run. Therefore, if you set SYSOPT2=X'40', you should also at least double LRETBL.</p>
+
<b></b>*** M204.0583: ENQ'ING TO EXCL FOR FILE <i>filename volname</i>
 +
</p> </li>
 +
</ul>
 +
   
 +
===Data integrity===
 +
 +
<p>When multiple jobs run on the same CPU, data integrity is ensured by using:</p>
 
   
 
   
 
<ul>
 
<ul>
<li> When the SYSOPT2 setting does not include X'40', then at any given time the bit maps corresponding to all users holding found sets of any kind must fit into CCATEMP pages designated as the small model page pool no matter  how large CCATEMP has been allocated.</li>
+
<li> Operating system locking and unlocking facility for shared application files and the system file containing file group definitions (CCAGRP).</li>
</li>
+
<li> When the SYSOPT2 setting does include X'40', the CCATEMP page restriction is removed and user found sets can be placed anywhere within CCATEMP. This includes both the small model page pool and the CCATEMP expansion area,  allowing for the possibility of a greater number of concurrent found sets being held by all users.</li>
+
<li> Special lock stored in the system file containing user and file security information (CCASTAT).</li>
 +
 +
<li> Restriction on sharing the system file that provides space for user work tables (CCASERVR) and the system scratch file (CCATEMP) between jobs.
 
</li>
 
</li>
 
</ul>
 
</ul>
 
   
 
   
===Resource locking table===
+
===Multiple Model 204 versions running on separate CPUs===
 
   
 
   
<p>You can use the $CENQCT function to obtain information on the number of unused entries in the resource locking table.  </p>
+
<p>The operating system file locking mechanism prevents concurrent updating and retrieval of data sets by jobs that run on separate CPUs. The RESERVE/RELEASE hardware feature restricts use of a device to a single CPU  in the following ways:</p>
 
   
 
   
====Sizing the resource locking table====
+
<ul>
 +
<li> Device containing a file's first data set can be reserved when control of the file is gained on one CPU and one of the following conditions is true:</li>
 
   
 
   
<p>For details on estimating the size of the resource locking table, see <var>[[LENQTBL parameter|LENQTBL]]</var>.</p>
+
<li> File is opened in a <var class="product">Model&nbsp;204</var> job for the first time.</li>
 
   
 
   
<p>For z/OS, <var class="product">Model&nbsp;204</var> allocates the resource locking table above the 16-megabyte line. </p>
+
<li> File that was read-only is first opened for update.</li>
 
   
 
   
===Multiple jobs running on one CPU===
+
<li> Last updating user closes the file.</li>
 
   
 
   
<p>Locking occurs at the file level when application files are shared between multiple jobs. </p>
+
<li> File is completely closed. </li>
 
   
 
   
<p>File locking modes is EXCL when:</p>
+
<li> Device is released in each case after a single disk read and disk write have been performed.
 +
</li>
 +
</ul>
 +
 +
<p>Each file contains a list of jobs that have control of the file. The list is read and updated only while the device is reserved. If control of the file cannot be obtained, then the list is not updated, and the list of  jobs preventing access, with their system IDs, is sent to the operator.  </p>
 +
 +
<p>Each list entry contains the following information:</p>
 
   
 
   
 
<ul>
 
<ul>
<li>Files are opened from a User Language thread or an IFAM1 thread that has file update privileges.</li>
+
<li> SMF system ID lock type (SHR or EXCL)</li>
 
   
 
   
<li>Files are opened from an IFAM2 thread or an IFAM4 thread that has allowed updates with thread update and file update privileges.</li>
+
<li> Job and step names</li>
 
   
 
   
<li>Command is entered to create or delete a permanent group.</li>
+
<li> Date and time that the list entry was created</li>
 
</ul>
 
</ul>
 
   
 
   
<p>File locking is SHR mode when:</p>
+
===How Model 204 resolves locking conflicts===
 +
<p>
 +
Locking conflicts can be handled automatically or by issuing the <var>[[ENQCTL command|ENQCTL]]</var> command.  </p>
 
   
 
   
<ul>
+
<p>Conflicts are handled automatically in single CPU error cases where a
<li>Files are opened under any other circumstances than those listed above.</li>
+
<var class="product">Model&nbsp;204</var> job has a file open and either the operating system crashes or the <var class="product">Model&nbsp;204</var> job is canceled. In these instances, the locking list in the file still shows the file as locked and the following process occurs:  </p>
 
   
 
   
<li>Files are opened in deferred update mode. Such files remain in SHR mode for the duration of the run.
+
<ol>
<p class="note"><b>Note:</b>
+
<li> When a file is opened, the locking list is processed after the operating system enqueuing. If the operating system enqueuing succeeds, there is no conflicting job on the requesting job's system. Any conflicting list  entries for the same system are obsolete.</li>
Up to 192 files can be opened in deferred update mode.
 
An attempt to exceed 192 files results in an error message.</p></li>
 
 
   
 
   
<li>Files have the file recovery option (FRCVOPT) parameter set to include X'10'. Locking on an application file does not occur when it is closed, unless FRCVOPT is set to X'10'. FRCVOPT is discussed fully in [[File integrity and recovery]]. </li>
+
<li> If the locking request is exclusive, any list entries for the current system are eliminated as obsolete.</li>
 
   
 
   
<li>The <var class="product">Model&nbsp;204</var> job uses the CCAGRP data set. </li>
+
<li> If the request is shared, any exclusive entries for the current system and any shared entry having the same system ID, job, and step names are eliminated.</li>
</li>
+
</ol>
</ul>
 
 
   
 
   
<p>The following sections explain how locking conflicts are handled by <var class="product">Model&nbsp;204</var>, and how data integrity is ensured when multiple jobs run on one CPU.</p>
+
===Locking conflicts between CPUs===
 
   
 
   
===Handling locking conflicts===
+
<p>You can clear conflicts occurring between CPUs by issuing the <var>ENQCTL</var> command to interrogate or modify the status of a file's locking list. The following rules apply to the <var>ENQCTL</var> command: </p>
 
   
 
   
<p>Locking conflicts for application files are handled first by the operating system and next by <var class="product">Model&nbsp;204</var>.   </p>
+
<ul>
 +
<li> If an <var>ENQCTL</var> command is issued with only a file name, all list entries for the file are displayed.</li>
 
   
 
   
<p>The operating system initially examines the disposition for all application files, as specified in the JCL for a job. If two jobs specify SHR for the same application file, the operating system allows both jobs access  to the file. When the second job attempts to process the application file, <var class="product">Model&nbsp;204</var> determines that another job poses a locking conflict.</p>
+
<li> If an <var>ENQCTL</var> command is issued with arguments, all the entries satisfying the arguments are deleted.</li>
 +
</ul>
 +
 +
<p>For example, if a system crash occurs for system S133, the operator at another system can issue the following command to remove all the locking list entries from CENSUS that were added by jobs running on system S133:</p>
 
   
 
   
<p><var class="product">Model&nbsp;204</var> reads the first page of the file and examines the lock, which is located on that page. If a conflict is detected, <var class="product">Model&nbsp;204</var> waits until the job's time limit is reached for the file to become available. Then,  if the file is not available, <var class="product">Model&nbsp;204</var> sends error messages to the operator's console and to the output device of the user who attempted to open the file.</p>
+
<p class="code">ENQCTL CENSUS S133
 +
</p>
 +
<p>Indiscriminate use of the <var>ENQCTL</var> command can cause shared DASD integrity exposure through the removal of entries of active systems or jobs. </p>
 
   
 
   
<p>Error messages are issued once every five minutes until the file becomes available, the job time limit for an online job is reached, or the maximum number of error messages for a batch job (ERMX) is reached.</p>
+
===Shared DASD locking conflicts===
 
   
 
   
<p>Messages sent to the operator's console are:</p>
+
<p>If a shared DASD locking conflict occurs, <var class="product">Model&nbsp;204</var> sends an error message to the operator's console. Error messages are issued once every five minutes until the conflict is resolved and the file becomes available.</p>
 
   
 
   
 +
<p>Messages sent to the operator's console are:  </p>
 
<ul>
 
<ul>
<li> For an Online job:
+
<li> For a batch job:
 
 
<p class="code"><b></b>*** M204.0582: ACCESS TO FILE <i>filename</i> PREVENTED BY: <i>jobname</i>
 
<p class="code"><b></b>*** M204.0582: ACCESS TO FILE <i>filename</i> PREVENTED BY: <i>jobname</i>
<b></b>*** M204.0584: FILE IS IN USE &mdash; <i>filename</i>
+
<b></b>*** M204.0584: FILE IS IN USE -- <i>filename</i>
</p> </li>
+
</p>
 +
<p class="note"><b>Note:</b>
 +
Both of these messages increment the error count for the batch job. Because the batch OPEN command is aborted after the specified maximum number of errors (ERMX) is reached, <var class="product">Model&nbsp;204</var> does not wait indefinitely for the conflict to be resolved. </p></li>
 
   
 
   
<li>For a batch job the message sent from <var class="product">Model&nbsp;204</var> to the operator:
+
<li>For active system or job locking list entries deleted by using the ENQCTL command:
 +
<p class="code"><b></b>*** M204.0585: SHARED DASD ENQ LIST OVERLAID FOR
 +
<i>filename</i> AT <i>hh</i>:<i>mm</i>:<i>ss</i> ON <i>yy</i>.<i>ddd</i>
 +
</p>
 +
<p>
 +
The date and time identify the most recent update of the file. Used in conjunction with the operating system job logs, this information can determine the cause of the problem. </p>
 +
</li></ul>
 
   
 
   
<p class="code"><b></b>*** M204.0582: ACCESS TO FILE <i>filename</i> PREVENTED BY: <i>jobname</i>
+
===z/VSE considerations===
 +
<p>
 +
The following considerations apply to resource locking in a z/VSE environment:</p>
 +
<ul>
 +
<li> File locking is available for z/VSE releases that support LOCK and UNLOCK (SVC 110).</li>
 +
 
 +
<li> Multiple copies of <var class="product">Model&nbsp;204</var> running in separate z/VSE systems cannot share any <var class="product">Model&nbsp;204</var> database files.</li>
 +
</ul>
 
   
 
   
<b></b>*** M204.0581: ENQ'ING TO SHR FOR FILE <i>filename volname</i>
+
===Resource locking in z/VM===
 +
<p>
 +
The following considerations apply to resource locking in z/VM environments:</p>
 +
 +
<ul>
 +
<li>CMS-format disks cannot be shared in read/write mode by multiple virtual or real machines. Any attempt at SHR access destroys the data.
 +
<p>
 +
The file allocation techniques that are used and the lack of support in CMS for access serialization prevent effective read/write file sharing.</p>
 +
<p>
 +
Files on CMS-format disks do not require preallocation. The files are created automatically the first time they are referenced and continue to increase in size as more data is added. File size is restricted only by the  available space defined on the minidisk.</p></li>
 +
 +
<li> Several virtual machines can share variable-format disks by using virtual RESERVE/RELEASE facilities.
 +
<p>
 +
RESERVE/RELEASE permits access to a volume restricted to a particular (real or virtual) access path. Because allocations are static in nature, a file can be read and written without further reference to the allocation  information, unless secondary allocation functions are required.</p>
 +
<p>
 +
Files on variable-format disks require preallocation. A primary allocation must be provided. Secondary extents can be specified to permit limited extension of the file. The file allocation information is recorded on a  disk in the Volume Table of Contents (VTOC).</p>
 +
<p>
 +
Some files on variable-format disks can be read/write shared by multiple <var class="product">Model&nbsp;204</var> virtual machines while others cannot:</p>
 +
<ul>
 +
<li>Files that can be shared are CCAGRP, CCAIN, CCASTAT, CCASYS, and <var class="product">Model&nbsp;204</var> files. </li>
 
   
 
   
<b></b>*** M204.0582: ACCESS TO FILE <i>filename</i> PREVENTED BY: <i>jobname</i>
+
<li>Files that cannot be shared are CCAAUDIT, CCAJRNL, CCAPRINT, CCARF, CCASERVR, CCASNAP, CCATEMP, CHKPOINT, RESTART, USE data sets, and deferred update data sets. </li>
 +
</ul></li>
 
   
 
   
<b></b>*** M204.0583: ENQ'ING TO EXCL FOR FILE <i>filename volname</i>
+
<li>SHR mode access on a read-only device can cause data inconsistencies.
</p> </li>
+
<p>
 +
If a CMS user has SHR access to a <var class="product">Model&nbsp;204</var> file on a read-only minidisk, SHR does not prevent another user from upgrading to the EXCL mode. </p></li>
 
</ul>
 
</ul>
 +
 +
==Disk buffers and Model 204 storage==
 
   
 
   
===Data integrity===
+
<p>The disk buffer pool holds pages from database files and from CCATEMP and CCAGRP. CCATEMP pages consist of found sets, sorted sets, backpage images, temporary procedures and other  data structures. Database pages consist of pages from Tables FCT, A, B, C, D, E and X. Pages are read into and written from this buffer pool by the disk buffer manager which manages this resource using a least recently used algorithm. This pool  of buffers is shared by all users.</p>
 
   
 
   
<p>When multiple jobs run on the same CPU, data integrity is ensured by using:</p>
+
<p><var class="product">Model&nbsp;204</var> utilizes the following areas of storage, depending on the operating system architecture your site supports:</p>
 
   
 
   
 
<ul>
 
<ul>
<li> Operating system locking and unlocking facility for shared application files and the system file containing file group definitions (CCAGRP).</li>
+
<li> Below the line, for 24-bit storage for non-XA systems: z/OS, z/VM, and z/VSE</li>
+
 
<li> Special lock stored in the system file containing user and file security information (CCASTAT).</li>
+
<li> Above the line, for sites that support 31-bit storage for OS/390, XA, ESA, z/OS, z/VM, and z/VSE</li>
+
 
<li> Restriction on sharing the system file that provides space for user work tables (CCASERVR) and the system scratch file (CCATEMP) between jobs.
+
<li> Above the bar, for sites that support 64-bit storage for z/OS, z/VM, and z/VSE</li>
</li>
 
 
</ul>
 
</ul>
 
   
 
   
===Multiple Model 204 versions running on separate CPUs===
+
<p>The buffer pool consists of the following data structures: </p>
 +
<ul>
 +
<li> Disk Buffer Control Blocks: 160 bytes each, one per buffer</li>
 
   
 
   
<p>The operating system file locking mechanism prevents concurrent updating and retrieval of data sets by jobs that run on separate CPUs. The RESERVE/ RELEASE hardware feature restricts use of a device to a single CPU  in the following ways:</p>
+
<li> Hash cells: 16 bytes each. The number of hash cells allocated for each buffer is equal to the <var>[[HASHCELL parameter|HASHCELL]]</var> parameter value, which defaults to 3. </li>
 
   
 
   
<ul>
+
<li> Page fix lists: 16 bytes per buffer</li>
<li> Device containing a file's first data set can be reserved when control of the file is gained on one CPU and one of the following conditions is true:</li>
 
 
   
 
   
<li> File is opened in a <var class="product">Model&nbsp;204</var> job for the first time.</li>
+
<li> Buffers: 6184 bytes, plus 8-byte overrun detection area
 +
<p>
 +
The disk buffer overrun detection area, the space between each buffer in the disk buffer pool, is eight bytes of hexadecimal FF, so for each buffer, 6192 bytes is allocated. The total size  of the buffer pool is then:</p>
 
   
 
   
<li> File that was read-only is first opened for update.</li>
+
<p class="code">(NUMBUF + NUMBUFG) * (6192 + 160 + (16*HASHCELL) + 16)
+
</p>
<li> Last updating user closes the file.</li>
+
<p>
+
<var>[[NUMBUF parameter|NUMBUF]]</var> is a viewable parameter that is equal to the number of buffers allocated above the line. <var>NUMBUF</var> is equal to or less than <var>[[MAXBUF parameter|MAXBUF]]</var>, depending on the amount of virtual storage available to the job.</p>
<li> File is completely closed. </li>
+
<p>
+
<var>[[NUMBUFG parameter|NUMBUFG]]</var> is a settable and viewable parameter that is equal to the number of buffers allocated above the bar (ATB). If <var>NUMBUFG</var> buffers cannot be allocated in available above the bar storage, the run terminates.</p>
<li> Device is released in each case after a single disk read and disk write have been performed.
+
<p class="note"><b>Note:</b> As of version 7.7 of Model&nbsp;204, either
</li>
+
<var>NUMBUF</var> or <var>NUMBUFG</var> is 0: all disk buffer storage
 +
is allocated BTB, or all is allocated ATB, depending on the setting of <var>NUMBUFG</var>.</p></li>
 
</ul>
 
</ul>
 
   
 
   
<p>Each file contains a list of jobs that have control of the file. The list is read and updated only while the device is reserved. If control of the file cannot be obtained, then the list is not updated, and the list of jobs preventing access, with their system IDs, is sent to the operator. </p>
+
===Using 31-bit storage===
   
+
<p>
<p>Each list entry contains the following information:</p>
+
When BTB buffers are being used (that is, <var>NUMBUFG</var> is 0 under version 7.7 or higher, or <var>NUMBUFG</var> is any value under Model&nbsp;204 prior to 7.7) in systems that support 31-bit addressing, <var class="product">Model&nbsp;204</var> disk buffers are allocated above the 16-megabyte line. This frees virtual storage for other data that must remain below the line, and it allows for the allocation of a larger buffer pool, since there is more virtual storage above the line. As the number of buffers increases, database pages can remain in memory for longer periods of time, and repeated reads (I/O) for the same pages are reduced.</p>
 
   
 
   
 
<ul>
 
<ul>
<li> SMF system ID lock type (SHR or EXCL)</li>
+
<li> If [[IOS Branch Entry]] (<var>[[XMEMOPT parameter|XMEMOPT]]</var> X'02') is used, control blocks, hash cells, and page fix lists are allocated above the line. </li>
+
 
<li> Job and step names</li>
+
<li> If IOS Branch Entry is not used, the disk buffer control blocks and hash cells (and page fix lists if EXCPVR is used) are allocated below the line. The buffers themselves are allocated above the line.</li>
 
<li> Date and time that the list entry was created
 
</li>
 
 
</ul>
 
</ul>
 
   
 
   
===How Model 204 resolves locking conflicts===
+
<p class="note"><b>Note:</b>
+
For information about controlling the allocation of hash cells per buffer pool page, see the <var>[[HASHCELL parameter|HASHCELL]]</var> parameter. </p>
<p>Locking conflicts can be handled automatically or by issuing the ENQCTL command (see <var class="product">Model&nbsp;204</var> Parameter and Command Reference).   </p>
+
<p>
+
A minimum number of BTB buffers is required to bring up an Online configuration:</p>
<p>Conflicts are handled automatically in single CPU error cases where a
+
<ul>
<var class="product">Model&nbsp;204</var> job has a file open and either the operating system crashes or the <var class="product">Model&nbsp;204</var> job is canceled. In these instances, the locking list in the file still shows the file as locked and the following process occurs:  </p>
+
<li>Model&nbsp;204 7.6 or lower:
+
<p>
<ol>
+
The minimum number of buffers is equal to the result of the following calculation: </p>
<li> When a file is opened, the locking list is processed after the operating system enqueuing. If the operating system enqueuing succeeds, there is no conflicting job on the requesting job's system. Any conflicting list  entries for the same system are obsolete.</li>
+
<p class="code">NLRUQ * ((NSERVS + NSUBTKS) * MAXOBUF + 15)
+
</p>
<li> If the locking request is exclusive, any list entries for the current system are eliminated as obsolete.</li>
+
<p>
+
If <var>[[MINBUF parameter|MINBUF]]</var> is set smaller than the above result, Model&nbsp;204 resets <var>MINBUF</var> to the result value. </p>
<li> If the request is shared, any exclusive entries for the current system and any shared entry having the same system ID, job, and step names are eliminated.
+
<p>
 +
If <var>MAXBUF</var> is smaller than <var>MINBUF</var> after the previous calculation, <var>MAXBUF</var> is reset to the value of <var>MINBUF</var>. </p>
 +
<p>
 +
Rocket Software recommends that you start with a minimum setting of <code>MAXBUF=10000</code> and monitor performance statistics to determine if that number is adequate. Generally, performance will improve as the size of the buffer pool increases. That will not be the case, however, if real storage is limited and system paging increases. Many sites are running with <code>MAXBUF=50000</code>, <code>100000</code>, or more.</p></li>
 +
 
 +
<li>Model&nbsp;204 7.7 and higher:
 +
<p>
 +
If <var>NUMBUFG</var> is 0, only BTB buffers are used, and the minimum number of buffers calculation and the effects on <var>MINBUF</var> and <var>MAXBUF</var> are as described in the preceding item. </p>
 +
<p>
 +
If <var>NUMBUFG</var> is greater than 0, only ATB buffers are used, and the minimum number of ATB buffers is described in [[#Managing ATB storage with NUMBUFG|Managing ATB storage with NUMBUFG]].
 +
</p>
 
</li>
 
</li>
</ol>
+
</ul>
 +
 
 +
===Using 64-bit addressing and Above the Bar (ATB) storage===
 +
<p>
 +
In systems that support 64-bit virtual storage, you can place Table B and Table X pages (and other entities listed in [[Model 204 configurations and operating environments#Model 204 entities in above the bar storage|Model&nbsp;204 entities in above the bar storage]]) in the above-the-bar buffer pool, or above the two gigabyte (2GB) address line. Pages that are not stored above the bar reside in the buffer pool above the line.</p>
 +
 
 +
<blockquote class="note"><b>Important:</b>
 +
<ul>
 +
<li>For Model&nbsp;204 version 7.4, you should ensure that your user-written and third-party $functions can work with non-swappable server tables in 64-bit storage above the bar.</li>
 +
 
 +
<li>For Model&nbsp;204 version 7.5 and higher, any assembler language functions that you have written for use within Model&nbsp;204 version 7.5 <b>must</b> be 64-bit compliant. [[Contacting Rocket Software Technical Support|Contact Technical Support]] if you need help with conversion of your functions.</li>
 +
 
 +
<li>For Model&nbsp;204 version 7.7 and higher, activating usage of ATB buffers (setting <var>NUMBUFG</var> greater than 0) causes all buffer storage to be ATB and none to be BTB.
 +
<p>
 +
Prior to the gradual introduction of ATB storage for Model&nbsp;204, storage was rather limited, so Model&nbsp;204 took all the storage it could, returned <var>[[SPCORE parameter|SPCORE]]</var> bytes, and allocated the rest into the buffer pool.
 +
If the resulting number of buffers was not between <var>MINBUF</var> and <var>MAXBUF</var>, the run terminated.
 +
On more contemporary systems, virtual storage is abundant, making obsolete the concept of calculating the amount of storage (BTB) that will fit.  </p>
 +
<p>
 +
The following documentation retains many remarks that apply to versions preceding 7.7 where ATB and BTB buffers might both be used together. </p></li>
 +
</ul></blockquote>
 
   
 
   
===Locking conflicts between CPUs===
+
<ul>
 +
<li> In most cases, Table B pages constitute the biggest portion of all pages in the buffer pool. Moving Table B pages to an above-the-bar buffer pool lets <var class="product">Model&nbsp;204</var> place more pages from all other tables in the below-the-bar buffer pool and thereby reduce I/O and CPU time to read and write pages to and from disk. </li>
 
   
 
   
<p>You can clear conflicts occurring between CPUs by issuing the ENQCTL command to interrogate or modify the status of a file's locking list. The following rules apply to the ENQCTL command: </p>
+
<li> When a buffer is allocated above the bar, the corresponding disk buffer control blocks (one per buffer, 160 bytes each) and hash cells (three per buffer, 16 bytes each) are also allocated above the bar. This means there is no below the bar storage penalty for allocating above-the-bar buffers.</li>
 
   
 
   
<ul>
+
<li> Having these two buffer pools rather than one improves <var class="product">Model&nbsp;204</var> scalability by reducing MP collisions when using buffer pool resources. </li>
<li> If an ENQCTL command is issued with only a file name, all list entries for the file are displayed.</li>
 
 
   
 
   
<li> If an ENQCTL command is issued with arguments, all the entries satisfying the arguments are deleted.
+
<li> Eight bytes added to the end of every buffer, above and below the bar, detect buffer overruns. The buffer size per page is 6192 bytes (or 6184 plus 8).</li>
</li>
 
 
</ul>
 
</ul>
 +
 +
====Managing ATB storage with NUMBUFG====
 +
 +
<p class="note"><b>Note:</b> If you set <var>NUMBUFG</var> greater than zero to use storage above the bar, IBM requires that you set a limit on how much of that virtual storage each address space can use. This limit is called [[Model 204 configurations and operating environments#Set the IBM MEMLIMIT system option|MEMLIMIT]].</p>
 
   
 
   
<p>For example, if a system crash occurs for system S133, the operator at another system can issue the following command to remove all the locking list entries from CENSUS that were added by jobs running on system S133:</p>
+
<p>When <var>NUMBUFG</var> is set to a nonzero value, an above-the-bar buffer pool is allocated with <var>NUMBUFG</var> buffers. As of Model&nbsp;204 7.7, this ATB buffer pool handles all disk buffer storage, and you get the exact amount of storage you specify with <var>NUMBUFG</var>. Before version 7.7 of Model&nbsp;204, nonzero <var>NUMBUFG</var> activates an ATB buffer pool <i>in addition to</i> the BTB buffer pool.
 +
</p>
 +
<p>
 +
If ATB and BTB buffer pools are both being used: </p>
 +
<ul>
 +
<li>The ATB and the BTB buffer pool are allocated with at least a minimum number of buffers, and the calculations for those minimums are very similar:
 +
<p>
 +
The ATB minimum, calculated by <var class="product">Model&nbsp;204</var>, is:</p>
 +
<p class="code">[[NLRUQG parameter|NLRUQG]] * ((NSERVS + NSUBTKS) * MAXOBUF + 15)
 +
</p>
 +
<p>
 +
If you set <var>NUMBUFG</var> to a lower value, it is reset to the calculated value.</p>
 +
<p>
 +
The BTB minimum is:</p>
 +
<p class="code">[[NLRUQ parameter|NLRUQ]] * ((NSERVS + NSUBTKS) * MAXOBUF + 15)
 +
</p>
 +
<p>
 +
If you set <var>MINBUF</var> to a lower value, it is reset to the calculated value.</p></li>
 +
 
 +
<li>Table B and Table X pages (and other entities listed in [[Model 204 configurations and operating environments#Model 204 entities in above the bar storage|Model 204 entities in above the bar storage]]) use the above-the-bar buffer pool. Those pages are not read into the below-the-bar buffer pool. Consequently, most sites can reduce the size of the below-the-bar buffer pool by the highwater mark of Table B pages currently resident in that buffer pool.</li>
 +
 
 +
<li>To quickly implement the above-the-bar feature, initially set <var>NUMBUFG</var> equal to your <var>MAXBUF</var> setting and leave <var>MAXBUF</var> at its current setting.</li>
 +
 
 +
<li>If <var>NUMBUFG</var> is greater than zero, the buffer hash pool is allocated above the bar. In addition, control blocks associated with ATB buffers are also allocated above the bar. <var>NUMBUFG</var> is limited to buffer pools of 4.2 terabytes or fewer.</li>
 +
 
 +
<li>To use the above-the-bar buffer pool in z/OS, IOS Branch Entry is required. This means <var>[[XMEMOPT parameter|XMEMOPT]]</var> must be set to include X'02'. You can explicitly exclude allocating above-the-bar buffers by setting <code>NUMBUFG=0</code>.
 +
<p>
 +
If <var>NUMBUFG</var> is greater than zero and <var>XMEMOPT</var> does not include X'02', the following message is issued, <var>NUMBUFG</var> is not reset, and the job terminates.</p>
 
   
 
   
<p class="code">ENQCTL CENSUS S133
+
<p class="code">M204.2581: XMEMOPT=2 (IOS BRANCH) REQUIRED FOR NUMBUFG > 0
 
</p>
 
</p>
<p>Indiscriminate use of the ENQCTL command can cause shared DASD integrity exposure through the removal of entries of active systems or jobs. </p>
+
<p>
 +
If you cannot get the number of buffers you requested, the job fails. </p>
 +
</li>
 +
</ul>
 +
 
 +
====Determining the NUMBUFG setting====
 +
<p>
 +
The number of buffers you want to allocate above the bar and below the bar is dependent on the mix of work that is being done on your system. See [[#Model 204 entities in above the bar storage|Model 204 entities in above the bar storage]] for a list of entities that can go above the bar. </p>
 
   
 
   
===Shared DASD locking conflicts===
+
<ul>
 +
<li> The <var>[[LDKBMWNG parameter|LDKBMWNG]]</var> parameter, which applies to above-the-bar buffers, corresponds to the <var>[[LDKBMWND parameter|LDKBMWND]]</var> parameter, which applies to below-the-bar buffers.</li>
 
   
 
   
<p>If a shared DASD locking conflict occurs, <var class="product">Model&nbsp;204</var> sends an error message to the operator's console. Error messages are issued once every five minutes until the conflict is resolved and the file becomes available.</p>
+
<li> If <var>NLRUQG</var> is set greater than 1, the value of <var>LDKBMWNG</var> is rounded up to a multiple of <var>NLRUQ</var>. <var>LDKBMWND</var> has a minimum size of one (1).
 +
</li>
 +
</ul>
 
   
 
   
<p>Messages sent to the operator's console are:  </p>
+
<p>High values of <var>LDKBMWNG</var> might unnecessarily increase the number of writes done (measured by the DKWR statistic). Low values might cause excessive waiting for buffers (measured by the MAXIOX statistic). Rocket Software  recommends starting values for <var>LDKBMWND</var> and <var>LDKBMWNG</var> at 10% of <var>NUMBUF</var> and <var>NUMBUFG</var>, respectively.</p>
 
   
 
   
 +
<p>If you do not set <var>LDKBMWNG</var>, it is set to the same value as <var>LDKBMWND</var>.</p>
 +
 +
====Designating non-swappable and swappable server space====
 +
<p>
 +
You can allocate designated server tables for each user in storage above the bar that will not be subject to server swapping. This feature enables you to divide the server storage into two parts: swappable and non-swappable. This makes the swappable part of the server storage smaller and faster to swap.</p>
 +
 +
<p>The <var>[[SERVNSSZ parameter|SERVNSSZ]]</var> and <var>[[SERVNSA parameter|SERVNSA]]</var> parameters control non-swappable server areas.</p>
 
<ul>
 
<ul>
<li> For a batch job:
+
<li><var>SERVNSSZ</var> (server non-swappable size) is the amount of space in bytes required for the above the bar server tables per user.
+
</li>
<p class="code"><b></b>*** M204.0582: ACCESS TO FILE <i>filename</i> PREVENTED BY: <i>jobname</i>
+
 
<b></b>*** M204.0584: FILE IS IN USE -- <i>filename</i>
+
<li><var>SERVNSA</var> (server non-swappable areas) specifies the tables above the bar.</li>
</p>
+
</ul>
<p class="note"><b>Note:</b>
+
In order to store a table in ATB storage:
Both of these messages increment the error count for the batch job. Because the batch OPEN command is aborted after the specified maximum number of errors (ERMX) is reached, <var class="product">Model&nbsp;204</var> does not wait indefinitely for the conflict to be resolved. </p></li>
+
<ul>
+
<li>Increase the <var>SERVNSSZ</var> parameter by the corresponding table size.</li>  
<li>For active system or job locking list entries deleted by using the ENQCTL command:
+
 
<p class="code"><b></b>*** M204.0585: SHARED DASD ENQ LIST OVERLAID FOR
+
<li>Set the proper bit in <var>SERVNSA</var>; for example:  
<i>filename</i> AT <i>hh</i>:<i>mm</i>:<i>ss</i> ON <i>yy</i>.<i>ddd</i>
 
</p>
 
<p>The date and time identify the most recent update of the file. Used in conjunction with the operating system job logs, this information can determine the cause of the problem. </p>
 
</li></ul>
 
 
===z/VSE considerations===
 
 
<p>The following considerations apply to resource locking in a z/VSE environment:</p>
 
 
 
<ul>
 
<ul>
<li> File locking is available for z/VSE releases that support LOCK and UNLOCK (SVC 110).</li>
+
<li>For FTBL, set the first byte to X'02', so the value of <var>SERVNSA</var> is X'02000000'.</li>
</li>
+
 
<li> Multiple copies of <var class="product">Model&nbsp;204</var> running in separate z/VSE systems cannot share any <var class="product">Model&nbsp;204</var> database files.</li>
+
<li>For GTBL, set the second byte to X'80', so the value of <var>SERVNSA</var> is X'00800000'.</li>
</li>
+
 
 +
<li>For NTBL, set the third byte to X'40', so the value of <var>SERVNSA</var> is X'00004000'.</li>
 +
 
 +
<li>For QTBL, set the third byte to X'20', so the value of <var>SERVNSA</var> is X'00002000'.</li>
 +
</ul>
 
</ul>
 
</ul>
 +
<p class="note"><b>Note:</b> The settings for each server table above the bar are independent of each other. So if FTBL, GTBL, NTBL, and QTBL are all placed above the bar, <var>SERVNSA</var> should be set to X'02806000'.</p>
 +
<p>
 +
The non-swappable server part can be used with server swapping done in storage or on disk. It can also be used when there is no server swapping (<var>NUSERS</var>=<var>NSERVS</var>) to make servers below the bar smaller by using the non-swappable server part above the bar and saving storage below the bar.</p>
 +
<p>
 +
To obtain below-the-bar storage savings when the non-swappable server part is used, decrease the value of the <var>SERVSIZE</var> parameter by the <var>LFTBL</var> value used in calculating the server size.</p>
 +
<p class="note"><b>Note:</b> When a table such as FTBL is placed in the non-swappable server part above the bar, the <var>[[UTABLE command|UTABLE]]</var> command decreasing the table size will not free any storage in the regular server below the bar.</p>
 +
 +
When using non-swappable ATB server space, each user will get <var>SERVNSSZ</var> bytes of ATB space, even if the thread is logged out or running resident requests.
 +
 +
For greater efficiency, Model&nbsp;204 version 7.5 also provides swappable ATB server areas that can supplement or replace the non-swappable areas.
 +
 +
<p>The <var>[[SERVGA parameter|SERVGA]]</var> and <var>[[SERVGSZ parameter|SERVGSZ]]</var> parameters control swappable server areas.</p>
 +
<ul>
 +
<li><var>SERVGA</var> (server swappable areas) specifies the tables above the bar. Each server table is controlled by a bit in SERVGA.</li>
 +
 +
<li><var>SERVGSZ</var> (server non-swappable size) is the amount of space in bytes required for the swappable above-the-bar server tables per server. The total amount of storage allocated for swappable above-the-bar server areas equals <var>SERVGSZ</var> rounded to 4K and multiplied by <var>[[NSERVS parameter|NSERVS]]</var>.</li>
 +
</ul>
 +
 +
<blockquote class="note"><b>Note:</b> In Model&nbsp;204 V7.5 and higher, server tables can be in three different places:
 +
<ul>
 +
<li>The BTB swappable server area </li>
 +
<li>The ATB swappable server area </li>
 +
<li>The ATB non-swappable server area </li>
 +
</ul> 
 +
<p>
 +
But server tables cannot be in two places at the same time. For example, you cannot make servers swappable and non-swappable at the same time. If, for instance, you set the NTBL bit on for the <var>SERVNSA</var> parameter, and you also set it on for <var>SERVGA</var>, the result would be: </p>
 +
<p class="code">M204.1399: Same server area defined for server above the bar and non-swappable server</p>
 +
<p>
 +
However, you can make parts of your server swappable and other parts non-swappable: the non-swappable areas are like having <code>NUSERS=NSERVS</code>, but only for some tables. So if you had large STBLs and GTBLs, you might want to make them non-swappable to reduce server swap times. And if you had small TTBLs and ITBLs, you might want to put them in the swappable area. Any table in the above-the-bar SRVR (the swappable part of the server) is not taking up space in the below-the-bar server. The same is true for any table in the ATB-non-swappable part of the server. </p>
 +
<p>
 +
The goal is to reduce the requirement for below-the-bar server area so that you can increase <var>NSERVS</var> (as <var>NSERVS</var> increases, so does the need for below-the-bar virtual storage).  </p>
 +
</blockquote>
 +
 +
====ATB storage for APSY precompiled procedures====
 +
The <var>[[RESPAGE parameter|RESPAGE]]</var> parameter activates the APSY [[Performance monitoring and tuning#Resident Request feature for precompiled procedures|precompiled procedures in storage]] feature using above-the-bar pages by specifying a number of 4K-byte operating system pages.
 +
 +
Specifying <var>RESPAGE</var> stores precompiled procedures as resident requests above the bar in the <var>RESPAGE</var> area. Using <var>RESPAGE</var> allows you to substantially increase the resident request area and decrease server swapping of QTBL and NTBL pages.
 +
 +
Also, when <var>RESPAGE</var> is greater than 0, <var>RESSIZE</var> is reset to -1, and no storage is allocated for <var>RESSIZE</var>. 
 +
 +
<var>RESPAGE</var> is independent of <var>[[SERVNSA parameter|SERVNSA]]</var>. That is, if <var>RESPAGE</var> is greater than 0, NTBL and QTBL for resident requests will always be stored in the resident request area, outside of the non-swappable server areas, even if the <var>SERVNSA</var> bits specify NTBL or QTBL are to be stored in the non-swappable server areas.  This avoids the duplication of storing NTBL and QTBL in two different locations.  In other words, a resident request is only stored in the resident request area and nowhere else. 
 +
 +
Storing resident requests above the bar is independent of tables above the bar. You can use a combination of resident requests and swappable servers ATB to reduce BTB-server sizes and thus increase the number of servers.
 +
 +
====ATB storage for EBM pages====
 +
<p>
 +
Existence Bit Map (EBM) pages reside in above the bar storage. </p>
 
   
 
   
===Resource locking in z/VM===
+
<p>Each <var class="product">Model&nbsp;204</var> file contains one EBM page for each segment in a file. If a file has five segments, that means there are five EBM pages for that file. </p>
 
<p>The following considerations apply to resource locking in z/VM environments:</p>
 
 
<ul>
 
<li>CMS-format disks cannot be shared in read/write mode by multiple virtual or real machines. Any attempt at SHR access destroys the data.
 
 
<p>The file allocation techniques that are used and the lack of support in CMS for access serialization prevent effective read/write file sharing.</p>
 
 
<p>Files on CMS-format disks do not require preallocation. The files are created automatically the first time they are referenced and continue to increase in size as more data is added. File size is restricted only by the  available space defined on the minidisk.</p></li>
 
 
<li> Several virtual machines can share variable-format disks by using virtual RESERVE/RELEASE facilities.
 
 
   
 
   
<p>RESERVE/RELEASE permits access to a volume restricted to a particular (real or virtual) access path. Because allocations are static in nature, a file can be read and written without further reference to the allocation  information, unless secondary allocation functions are required.</p>
+
To allow more ATB buffers for the EBM pages, increase the <var>NUMBUFG</var> setting by a value that accommodates all the EBM pages for all files that might be open concurrently in your job. If in addition the version of Model&nbsp;204 is lower than 7.7, BTB buffers are also being used, and you can reduce the <var>MAXBUF</var> parameter by the same amount you increased <var>NUMBUFG</var> for EBM pages. 
 +
 
 +
====ATB storage for procedure pages====
 +
<p>
 +
Procedure text pages, located in Table D, are also eligible to reside in the ATB buffer pool. Each SOUL procedure is stored in one or more procedure text pages, the initial page of which is pointed to by the procedure dictionary. (Pages from the procedure dictionary, which is also stored in Table D, are read into the BTB buffer pool.)</p>
 
   
 
   
<p>Files on variable-format disks require preallocation. A primary allocation must be provided. Secondary extents can be specified to permit limited extension of the file. The file allocation information is recorded on a disk in the Volume Table of Contents (VTOC).</p>
+
<p>In a development environment where procedure page volume is high and where <var>NUMBUFG</var> is allocated, you might need to increase <var>NUMBUFG</var> to accommodate the procedure text pages. In this case, if BTB buffers are also being used (Model&nbsp;204 version less than 7.7), you can reduce the <var>MAXBUF</var> parameter by the same amount you increased <var>NUMBUFG</var>.</p>
 +
 
 +
====ATB storage for screens and images====
 +
<p>
 +
Pages used for <var class="product">Model&nbsp;204</var> <var>SCREEN</var> and <var>IMAGE</var> items reside in the buffer pool above the bar.</p>
 +
 
 +
====ATB storage for hash table cells====
 +
<p>
 +
The hash table is used to locate pages in the buffer pool based on the file and page number. You control the number of hash cells allocated in the hash table with the parameter <var>[[HASHCELL parameter|HASHCELL]]</var>. If <var>NUMBUFG</var> is also set to a value greater than zero to allocate buffers above the bar, the hash cells are also allocated above the bar. </p>
 +
 
 +
====ATB storage for XmlDoc object pages====
 +
As of Model&nbsp;204 version 7.5, the CCATEMP pages used for <var>XmlDoc</var> objects use the ATB buffer pool, which might allow the BTB buffer pool to be reduced, perhaps providing more storage for server areas. It also might provide a reduction in CPU utilization, especially when the <var>[[TEMPPAGE parameter|TEMPPAGE]]</var> parameter is used to allocate CCATEMP in memory.
 +
 
 +
===Monitoring disk buffers===
 +
<p>
 +
To get started using ATB buffers in an environment where both ATB and BTB buffers will be used, you might want to implement <var>NUMBUFG</var>, then do more analysis later. A suggested starting value for <var>NUMBUFG</var> in this case is equal to your <var>MAXBUF</var> setting (while leaving <var>MAXBUF</var> at its current setting). Then use the [[MONITOR command: Disk buffers|MONITOR DISKBUFF commands]] to analyze the buffer pool utilizations. </p>
 +
 
 +
==Managing delayed disk updates==
 +
<p>
 +
The disk update process allows delayed disk updates, which avoids duplicate database writes in certain situations.</p>
 
   
 
   
<p>Some files on variable-format disks can be read/write shared by multiple <var class="product">Model&nbsp;204</var> virtual machines while others cannot:</p></li>
+
<p>When a user completes an update unit for a file and there are no other update units active against that file, <var class="product">Model&nbsp;204</var> writes the buffer to disk with all of the file's modified pages, marks the file as physically  consistent, and issues a message stating that the disk update is complete. </p>
 
   
 
   
<li>Files that can be shared are CCAGRP, CCAIN, CCASTAT, CCASYS, and <var class="product">Model&nbsp;204</var> files. </li>
+
===Specifying delayed updates with the DKUPDTWT parameter===
 +
<p>
 +
The CCAIN parameter <var>[[DKUPDTWT parameter|DKUPDTWT]]</var> specifies delayed disk updates. The value of <var>DKUPDTWT</var> determines how many seconds a disk buffer containing a file's modified pages must have aged before it can be written to disk. </p>
 +
<p>
 +
When <var>DKUPDTWT</var> is zero, the default value, <var class="product">Model&nbsp;204</var> writes all of the file's modified pages to disk at the end of the last in-flight update of the file. The user who completed the last in-flight update waits for this disk  update process to complete and for the message stating that the disk update is complete. </p>
 
   
 
   
<li>Files that cannot be shared are CCAAUDIT, CCAJRNL, CCAPRINT, CCARF, CCASERVR, CCASNAP, CCATEMP, CHKPOINT, RESTART, USE data sets, and deferred update data sets. </li>
+
<p>If <var>DKUPDTWT</var> is not zero, <var class="product">Model&nbsp;204</var> delays the start of the disk update process for at least <var>DKUPDTWT</var> seconds, after which it may be the checkpoint pseudo subtask (CHKPPST) that performs the disk update. The user who  completed the last in-flight update does not have to wait for the disk update process to complete. </p>
 
   
 
   
<li>SHR mode access on a read-only device can cause data inconsistencies.
+
<p>When <var>DKUPDTWT</var> is not zero, the CHKPPST and CHKPTIMR pseudo subtasks are started automatically at <var class="product">Model&nbsp;204</var> initialization. An error message informs you if the <var>NSUBTKS</var> parameter is set too low to start these pseudo  subtasks.</p>
 
   
 
   
<p>If a CMS user has SHR access to a <var class="product">Model&nbsp;204</var> file on a read-only minidisk, SHR does not prevent another user from upgrading to the EXCL mode. </p>
+
<p>The maximum value of <var>DKUPDTWT</var> depends on the value of the <var>CPTIME</var> parameter. If <var>CPTIME</var> is nonzero, <var>DKUPDTWT</var> must be less than or equal to <code>CPTIME*30</code>. The absolute maximum value of <var>DKUPDTWT</var> is 60. </p>
</li>
 
</ul>
 
 
   
 
   
==Disk buffers and Model 204 storage==
+
<p>The system manager can reset <var>DKUPDTWT</var> to zero while the online is running. It can be reset to a nonzero value as long as the CHKPPST and CHKPTIMR pseudo subtasks were started during <var class="product">Model&nbsp;204</var> initialization.</p>
 
   
 
   
<p>The disk buffer pool holds pages from database files and from CCATEMP and CCAGRP. CCATEMP pages consist of found sets, sorted sets, backpage images, temporary procedures and other  data structures. Database pages consist of pages from Tables FCT, A, B, C, D, E and X. Pages are read into and written from this buffer pool by the disk buffer manager which manages this resource using a least recently used algorithm. This pool  of buffers is shared by all users.</p>
+
===Handling delayed updates and CHKPPST===
 +
<p>
 +
The CHKPPST pseudo subtask plays a central role in handling delayed disk updates. When <var>DKUPDTWT</var> is set to 0, CHKPPST does the following:</p>
 +
<ol>
 +
<li>Sleeps for <var>CPTIME</var> minutes.</li>
 
   
 
   
<p><var class="product">Model&nbsp;204</var> utilizes the following areas of storage, depending on the operating system architecture your site supports:</p>
+
<li>Tries to quiesce updates, for up to <var>CPTQ</var>, plus <var>CPTO</var> seconds.</li>
 
   
 
   
<ul>
+
<li>Takes the checkpoint, if all updates are quiesced.</li>
<li> Below the line, for 24-bit storage for non XA systems: VSE, VM, and OS</li>
+
</ol>
</li>
 
<li> Above the line, for sites that support 31-bit storage for z/OS, OS/390, XA, ESA, z/VSE, z/VM</li>
 
</li>
 
<li> Above the bar, for sites that support 64-bit storage for z/OS and z/VM</li>
 
</li>
 
</ul>
 
 
   
 
   
<p>The buffer pool consists of the following data structures: </p>
+
<p>If <var>DKUPDTW</var>T is greater than 0, CHKPPST has substantially more processing to perform: </p>
 
   
 
   
<ul>
+
<ol>
<li> Disk Buffer Control Blocks: 160 bytes each, one per buffer</li>
+
<li>Sleeps for <var>DKUPDTWT</var> divided by four seconds.</li>
 
   
 
   
<li> Hash cells: 16 bytes each. The number of hash cells allocated for each buffer is equal to the <var>[[HASHCELL parameter|HASHCELL]]</var> parameter value, which defaults to 3. </li>
+
<li>Further processing depends on the value, rounded to the nearest integer of:
 +
<p class="code">N = (CPTIME * 60) / (DKUPDTWT / 4)
 +
</p></li>
 +
</ol>
 
   
 
   
<li> Page fix lists: 16 bytes per buffer</li>
+
===Attempting a checkpoint===
 +
<p>
 +
If the number of wake-up calls since the last checkpoint is <var>N</var>, CHKPPST takes a new checkpoint, as follows:</p>
 
   
 
   
<li> Buffers: 6184 bytes, plus 8-byte overrun detection area
+
<table>
 +
<tr class="head">
 +
<th><p>Attempt </p> </th>
 +
<th><p>Purpose</p> </th></tr>
 
   
 
   
<p>The disk buffer overrun detection area, the space between each buffer in the disk buffer pool, is eight bytes of hexadecimal FF, so for each buffer, 6192 bytes is allocated. The total size  of the buffer pool is then:</p>
+
<tr>
   
+
<td>1.</td>
<p class="code">(NUMBUF + NUMBUFG) * (6192 + 160 + (16*HASHCELL) + 16)
+
<td>Performs the disk update process on all files that are not being updated, regardless of how long since they were marked disk-update-needed. </td></tr>
</p>
+
   
<p>
+
<tr>
<var>[[NUMBUF parameter|NUMBUF]]</var> is a viewable parameter that is equal to the number of buffers allocated above the line. <var>NUMBUF</var> may be equal to or less than <var>MAXBUF</var>, depending on the amount of virtual storage available to the job.</p>
+
<td>2. </td>
 +
<td>Attempts to deactivate Host Language Interface (HLI) updates for CPTQ seconds. Performs the disk update process on all files that are not being updated each time <var class="product">Model&nbsp;204</var> determines that there are more HLI  jobs to wait for.</td></tr>
 +
<tr>
 +
<td>3. </td>
 +
<td>Attempts to deactivate all other updates for CPTO seconds. Performs the disk update process on all files that are not being updated each time <var class="product">Model&nbsp;204</var> determines that there are more users to wait for. </td></tr>
 +
 +
<tr>
 +
<td>4. </td>
 +
<td>If all updates have been deactivated, performs the disk update process on all remaining files marked disk-update-needed. Otherwise, abandons the checkpoint attempt. </td></tr>
 
   
 
   
<p>
+
<tr>
<var>[[NUMBUFG parameter|NUMBUFG]]</var> is a settable and viewable parameter that is equal to the number of buffers allocated above the bar. If <var>NUMBUFG</var> buffers cannot be allocated in available above the bar storage, the run terminates.</p>
+
<td>5. </td>
</li>
+
<td>Performs the disk update process again. Then takes the checkpoint. </td></tr>
</ul>
 
 
   
 
   
===Buffers in an ONLINE configuration===
+
<tr>
 +
<td>6. </td>
 +
<td>If the number of wake-up calls since the last checkpoint is not <var>N</var>, CHKPPST performs the disk update process on all files that have aged sufficiently &mdash; that is, marked disk-update-needed for at least DKUPDTWT seconds. </td></tr>
 +
</table>
 
   
 
   
<p>The following considerations apply to the use of buffers above the line in an ONLINE configuration:</p>
+
===Factors affecting disk update and checkpoint processing===
 +
<p>
 +
Several important factors affect the processing of disk updates and checkpoints:</p>
 
   
 
   
 
<ul>
 
<ul>
<li>A minimum number of buffers is required for the run to come up. <var>MINBUF</var>, if set smaller than the result of the following calculation, is reset to this value:
+
<li> Some disk updates might be interrupted by another thread's request for the file's UPDATE resource. Attempts 1, 2, 3, 4, and 6 might be interrupted by an attempt to start a new update or by a user doing a disk  update as part of CLOSE FILE processing. In these cases, the following message is issued, and the next file is processed:
<p class="code">NLRUQ * ((NSERVS + NSUBTKS) * MAXOBUF + 15)
+
<p class="code">M204.0440: DISK UPDATED ABORTED
 
</p> </li>
 
</p> </li>
 
   
 
   
<li><var>MAXBUF</var>, if smaller than <var>MINBUF</var> after the previous calculation, is reset to the value of <var>MINBUF</var>.
+
<li> Attempts 2, 3, and 4 might be interrupted by the expiration of the waiting time set with <var class="product">Model&nbsp;204</var> parameters CPTQ and CPTO, respectively. In these cases, the M204.0440 message is issued, all remaining files are bypassed, and the checkpoint is timed out.</li>
</li>
 
</ul>
 
 
   
 
   
<p>Rocket Software recommends that you start with a minimum setting of <code>MAXBUF=10000</code> and monitor performance statistics to determine if that number is adequate. Generally, performance will improve as the size of the buffer pool increases. That will not be the case, however, if real storage is limited and system paging increases. Many sites are running with <code>MAXBUF=50000</code>, <code>100000</code>, or more.</p>
+
<li> If CPTQ and CPTO are zero (no time-out intervals specified) and the DKUPDTWT parameter is nonzero, updates are deactivated for as long as required to perform the disk update process for all available files. If you do not want checkpoint attempts to deactivate updates, set DKUPDTWT to zero.</li>
 
   
 
   
===Using 31-bit storage===
+
<li> If Attempts 2, 3, or 4 abort due to a CPTO or CPTQ time-out, the checkpoint time-out message indicates the name of the file being written at the time of the time-out:
 
   
 
   
<p>In systems that support 31-bit addressing, <var class="product">Model&nbsp;204</var> disk buffers are allocated above the 16-megabyte line. This frees virtual storage for other data that must remain below the line and  allows for the allocation of a larger buffer pool since there is more virtual storage above the line. As the number of buffers increases, database pages can remain in memory for longer periods of time and repeated reads (I/O) for the same pages  are reduced.</p>
+
<p class="code">M204.0843: CHECKPOINT TIMED OUT ON date/time UPDATING FILE file
 +
</p></li>
 
   
 
   
<ul>
+
<li> Attempt 5 cannot be interrupted once it begins. Therefore, CPTO and CPTQ intervals are not honored for a CLOSE FILE command that is blocking a checkpoint. This type of event is likely to be infrequent and of short  duration.</li>
<li> If IOS BRANCH ENTRY (XMEMOPT=2) is used, control blocks, hash cells, and page fix lists are allocated above the line. </li>
+
</li>
+
<li> The sleep intervals of CHKPPST are not adjusted by the amount of time required to perform Attempt 6. Therefore, checkpoints might be spaced out by more than CPTIME minutes. If this is a frequent problem, adjust  CPTIME downward.</li>
<li> If IOS BRANCH ENTRY is not used, the disk buffer control blocks and hash cells (and page fix lists if EXCPVR is used) are allocated below the line. The buffers themselves are allocated above the line.</li>
 
</li>
 
 
</ul>
 
</ul>
 
   
 
   
<p class="note"><b>Note:</b>
+
==Understanding file statistics==
For information about controlling the allocation of hash cells per buffer pool page, see the <var>[[HASHCELL parameter|HASHCELL]]</var> parameter. </p>
+
<p>
 +
For descriptions of the file statistics DKUPTIME, UPDTTIME, and PDNGTIME, see [[Performance monitoring and tuning#Disk buffer monitor statistics and parameters|Disk buffer monitor statistics and parameters]]. </p>
 
   
 
   
===Using 64-bit storage===
+
===Handling 64-bit statistics===
+
<p>
<p>In systems that support 64-bit virtual storage, you can place Table B and Table X pages (and other entities listed in [[Model 204 entities in above the bar storage]]) in the above-the-bar buffer pool, or above the two gigabyte (2GB) address line. Pages that are not stored above the bar reside in the buffer pool above the line.</p>
+
To support very long running <var class="product">Model&nbsp;204</var> regions, Model&nbsp;204 V7R1 included modifications to the capacity of statistical counters (by increasing the size of some statistics and also exploiting 64-bit processing where appropriate). For sites upgrading to V7R1 or later, in-house or third-party support applications that process statistical counters need to review the statistics generated:</p>
 
<p>64-bit features are not yet available on IBM z/VSE systems.</p>
 
 
   
 
   
 
<ul>
 
<ul>
<li> In most cases, Table B pages constitute the biggest portion of all pages in the buffer pool. Moving Table B pages to an above the bar buffer pool lets <var class="product">Model&nbsp;204</var> place more pages from all other tables in the below the bar  buffer pool and thereby reduce I/O and CPU time to read and write pages to and from disk. </li>
+
<li>As some of the statistics fields became double-words, check [[Using system statistics]] for a revised layout of the System, Final, and Partial statistics. Also, additional Disk Buffer Monitor, MP/204, and File statistics were updated.</li>
 
   
 
   
<li> When a buffer is allocated above the bar, the corresponding disk buffer control blocks (one per buffer, 160 bytes each) and hash cells (three per buffer, 16 bytes each) are also allocated above the bar. This means there  is no below the bar storage penalty for allocating above the bar buffers.</li>
+
<li>Examine your in-house or third-party support applications for changes you need to make because of the increased length of some of the statistics. Make any changes necessary to your applications, then reassemble with the release upgrade.</li>
 
   
 
   
<li> Having these two buffer pools rather than one improves <var class="product">Model&nbsp;204</var> scalability by reducing MP collisions when using buffer pool resources. </li>
+
<li>If your in-house or third party support applications don't reference any of these double word statistics, you only need to reassemble your program with the updated offsets.</li>
 +
</ul>
 
   
 
   
<li> Eight bytes have been added to the end of every buffer, above and below the bar, to detect buffer overruns. The new buffer size per page is 6192 bytes (or 6184 plus 8).</li>
+
==Server areas==
 +
<p>
 +
Server areas are the internal work areas allocated to each user. Each area is divided into a fixed and variable portion. The fixed portion, which includes logical I/O buffers and user  resettable parameters, is calculated by <var class="product">Model&nbsp;204</var> at initialization. The variable portion can be changed dynamically with the <var>[[UTABLE command|UTABLE]]</var> command or the <var>[[IFUTBL (HLI function)|IFUTBL]]</var> IFAM function. </p>
 
   
 
   
</ul>
+
===Sizing user server areas===
 +
<p>
 +
The default size of all user server areas is set on User 0's parameter line. If the default is used, the allocated server area is exactly large enough to contain the tables for each user specified on each user's  parameter line. If <var>[[SERVSIZE parameter|SERVSIZE]]</var> is also specified on a particular user's parameter line, the default is overridden for that user.</p>
 
   
 
   
===Managing above the bar storage===
+
<p>The value of <var>SERVSIZE</var> must be as large as, or larger than, the user's aggregate table size. It is calculated by examining the user's server area requirements and monitoring the system statistics  (described in [[ONLINE monitoring]]) that provide information about the installation work load. The following formula gives the approximate size:</p>
 
   
 
   
<p>When NUMBUFG is set to a nonzero value, an above the bar buffer pool is allocated with NUMBUFG buffers. This is in addition to the below the bar buffer pool which is always allocated with at  least the minimum number of buffers, calculated as follows:</p>
+
<p class="syntax">SERVSIZE = <span class="term">fixed-table-size</span> + <span class="term">variable-table-size</span>
 
<p class="code">NLRUQ * ((NSERVS + NSUBTKS) * MAXOBUF + 15)
 
 
</p>
 
</p>
<p>Table B and Table X pages, (and other entities listed in [[Model 204 entities in above the bar storage]]) use the above the bar buffer pool. Those pages are not read into  the below the bar buffer pool. Consequently, most sites can reduce the size of the below the bar buffer pool by the high water mark of Table B pages currently resident in that buffer pool.</p>
+
<p>Where:</p>
 
   
 
   
<p>To quickly implement the above the bar feature initially set NUMBUFG equal to your MAXBUF setting and leave MAXBUF at its current setting.</p>
+
<ul>
 +
<li><var class="term">fixed-table-size</var> represents settings, defined during initialization, that cannot be modified during the run. </li>
 
   
 
   
<p>The minimum number of above the bar buffers calculated by <var class="product">Model&nbsp;204</var> uses the following formula:</p>
+
<li><var class="term">variable-table-size</var> represents settings that can be varied using the <var>UTABLE</var> command or its IFAM equivalent, <var>IFUTBL</var>.
 +
</li>
 +
</ul>
 
   
 
   
<p class="code">NLRUQG * ((NSERVS + NSUBTKS) * MAXOBUF + 15)
+
====SERVSIZE and server page alignment====
</p>
+
<p>
<p>If you set NUMBUFG to a lower value, it is reset to the calculated value.</p>
+
Servers and some server tables are always aligned on a 4K page boundary. In pre-7.4 releases, server and tables alignment took place only when <var>[[DSPOPT parameter|DSPOPT]]</var> had settings of bits X'01' or X'02', or when the <var>[[APSYPAGE parameter|APSYPAGE]]</var> parameter was indicated. </p>
 
   
 
   
<p>If NUMBUFG is greater than zero, the buffer hash pool is allocated above the bar. In addition, control blocks associated with above the bar buffers are also allocated above the bar. NUMBUFG is limited to buffer pools  of 4.2 terabytes or fewer.</p>
+
<p>If you used server alignment previously, there is no change in your server size requirements.</p>
 
   
 
   
<p>To use above the bar buffer pool in z/OS, IOS Branch Entry is required. This means XMEMOPT must be set to include X'02'. You can explicitly exclude allocating above the bar buffers by setting NUMBUFG=0.</p>
+
<p>If you did not use server alignment previously, then you might notice an increase in server size that in the worst case could be up to 24528 bytes per server.</p>
 
   
 
   
<p>If NUMBUFG is greater than zero and XMEMOPT does not include X'02', the following message is issued, NUMBUFG is not reset, and the job terminates.</p>
+
<p>When you calculate server size, take into account that FSCB, HEAP, NTBL, QTBL, STBL, and VTBL are each rounded on a 4K page boundary, so in the worst case each area could require up to 4088 bytes of server space,  compared to servers with no alignment in previous releases.</p>
 
   
 
   
<p class="code">M204.2581: XMEMOPT=2 (IOS BRANCH) REQUIRED FOR NUMBUFG > 0
+
<p>The following sections explain how server area sizing parameters are processed, which parameters determine fixed and variable table sizes, and the ranges of values these parameters can take.</p>
</p>
+
 
<p>If you cannot get the number of buffers you requested, the job fails. </p>
+
===Initialization and error handling===
 +
<p>
 +
During initialization, each user, except User 0, is identified in the output before the user's parameter line is read. The aggregate size of each user's tables and the size of tables fixed during initialization are  printed after the user's parameters are read. </p>
 
   
 
   
====Determining NUMBUFG setting====
+
<p>If errors are detected, they are reported and initialization continues whenever possible. If errors are detected during initialization, the run is canceled at the end of initialization. Error conditions in initializing  the server cause the run to end immediately with a return code of 96. </p>
 
   
 
   
<p>The number of buffers you want to allocate above the bar and below the bar is dependent on the mix of work that is being done on your system. See [[Model 204 entities in above the bar storage]] for a list of entities that can go above the bar. </p>
+
<p>The results of user changes to the sizes of FTBL, GTBL, ITBL, and XTBL are discussed in the <var>UTABLE</var> command [[UTABLE command#Usage notes|Usage notes]]. </p>
 
   
 
   
<ul>
+
===Calculating fixed table size===
<li> The LDKBMWNG parameter, which applies to above the bar buffers, corresponds to the LDKBMWND parameter, which applies to below the bar buffers.</li>
+
<p>
 +
Use the following formula to calculate fixed table size, the <var>[[FIXSIZE parameter|FIXSIZE]]</var> parameter value:</p>
 
   
 
   
<li> If NLRUQG is set greater than 1, then the value of LDKBMWNG is rounded up to a multiple of NLRUQ. LDKBMWND has a minimum size of one (1).
+
<p class="code">Fixed table size = 2520
</li>
+
      + ((MAXINCL+6) * 80)dwr
</ul>
+
      + ((LAUDPROC + 9) * (MAXINCL-1))dwr
 +
      + (LIBUFF + 4)
 +
      + (LOBUFF + 5)dwr
 +
      + (LOUTPB)dwr
 +
      + (((NGROUP + 12) * (NRMTFILE + NFILES + 1)) + (NRMTFILE + 1))dwr
 +
      + ((NORQS*3) + 2)dwr
 +
      + (3 * ERRMSGL)
 +
</p>
 +
<p>
 +
Each term of this formula that is followed by <code>dwr</code> must be double word rounded to the next multiple of eight. For example, if the value of <var>LOBUFF</var> is 500, the term <code>(LOBUFF + 5)</code> equals 505, which must be rounded to 512, the next  multiple of 8. </p>
 
   
 
   
<p>High values of LDKBMWNG might unnecessarily increase the number of writes done (measured by the DKWR statistic). Low values might cause excessive waiting for buffers (measured by the MAXIOX statistic). Rocket Software  recommends starting values for LDKBMWND and LDKBMWNG at 10% of NUMBUF and NUMBUFG, respectively.</p>
+
<p>If <var>SYSOPT</var> is 1 or 2 (indicating CCASYS or CCAGRP), add 1 to the value of <var>NFILES</var> used in the formula. If <var>SYSOPT</var> is 3 (indicating both CCASYS and CCAGRP), add 2.</p>
 
   
 
   
<p>If you do not set LDKBMWNG, it is set to the same value as LDKBMWND.</p>
+
<p>If any SQL threads are specified in CCAIN (IODEVs 13, 17, or 19), add 6712 bytes for C language work areas.</p>
 
   
 
   
====Above the bar storage for EBM pages====
+
<p>The "Fixed server table values" table, below, shows the minimum, maximum, and default values for parameters that affect fixed server table sizing. The rightmost columns show the relevant  units of measure; for example, the maximum value of <var>NORQS</var> is 32767 entries (not bytes). The values of <var>LIBUFF</var> and <var>LOBUFF</var> may need to be increased for SQL processing. Recommended values are <code>LIBUFF=3000</code> and <code>LOBUFF=5000</code>.</p>
 
   
 
   
<p>Existence Bit Map (EBM) pages reside in above the bar storage. </p>
+
<table>
 +
<caption>Fixed server table values</caption>
 +
<tr class="head">
 +
<th><p>Parameter</p></th>
 +
<th><p>Default</p></th>
 +
<th><p>Max </p></th>
 +
<th><p>Bytes/entries</p></th>
 +
</tr>
 
   
 
   
<p>Each <var class="product">Model&nbsp;204</var> file contains one EBM page for each segment in a file. If a file has five segments, that means there are five EBM pages for that file. </p>
+
<tr>
 +
<td>
 +
<p>ERRMSGL</p></td>
 +
<td>
 +
<p>80</p></td>
 +
<td>
 +
<p>256</p></td>
 +
<td>
 +
<p>Bytes</p></td>
 +
</tr>
 
   
 
   
<ul>
+
<tr>
<li>The NUMBUFG parameter specifies the number of buffers allocated above the bar.  You can increase your NUMBUFG setting to allow more above the bar buffers for the EBM pages. Increase the allocation of NUMBUFG by a value  that accommodates all the EBM pages for all files that might be open concurrently in your job.</li>
+
<td>
+
<p>LAUDPROC</p></td>
<li>The MAXBUF parameter specifies the maximum number of buffers to be allocated below the bar. The NUMBUF parameter (view only) indicates how many buffers were actually allocated. You can reduce MAXBUF by the same value  you used to increase NUMBUFG for EBM pages.
+
<td>
</li>
+
<p>21</p></td>
</ul>
+
<td>
 +
<p>253</p></td>
 +
<td>
 +
<p>Bytes</p></td>
 +
</tr>
 
   
 
   
====Above the bar storage for procedure pages====
+
<tr>
 +
<td>
 +
<p>LIBUFF</p></td>
 +
<td>
 +
<p>255</p></td>
 +
<td>
 +
<p>32767</p></td>
 +
<td>
 +
<p>Bytes</p></td>
 +
</tr>
 
   
 
   
<p>Procedure text pages, located in Table D, are also eligible to reside in the above the bar buffer pool. Each User Language procedure is stored in one or more procedure text pages, the initial page being pointed to via  the procedure dictionary. (Pages from the procedure dictionary, which is also stored in Table D, are read into the below the bar buffer pool.)</p>
+
<tr>
 +
<td>
 +
<p>LOBUFF</p></td>
 +
<td>
 +
<p>256</p></td>
 +
<td>
 +
<p>32767</p></td>
 +
<td>
 +
<p>Bytes</p></td>
 +
</tr>
 
   
 
   
<p>This change is more likely to affect development environments than production environments, but in those development environments where NUMBUFG is allocated, you might still want to tune NUMBUFG up and NUMBUF down  accordingly.</p>
+
<tr>
 +
<td>
 +
<p>LOUTPB</p></td>
 +
<td>
 +
<p>0</p></td>
 +
<td>
 +
<p>3000</p></td>
 +
<td>
 +
<p>Bytes</p></td>
 +
</tr>
 +
 
 +
<tr>
 +
<td>
 +
<p>MAXINCL</p></td>
 +
<td>
 +
<p>5</p></td>
 +
<td>
 +
<p>40</p></td>
 +
<td>
 +
<p>90+LAUDPROC bytes per INCLUDE level</p></td>
 +
</tr>
 
   
 
   
====Screens and images above the bar====
+
<tr>
+
<td>
<p>Pages used for <var class="product">Model&nbsp;204</var> SCREEN and IMAGE items now reside in the buffer pool above the bar.</p>
+
<p>NFILES</p></td>
+
<td>
====Allocating the above the bar buffer pool====
+
<p>2</p></td>
 +
<td>
 +
<p>16383</p></td>
 +
<td>
 +
<p>Entries</p></td>
 +
</tr>
 
   
 
   
<p>If NUMBUFG is set to a nonzero value, an above the bar buffer pool is allocated with NUMBUFG buffers. This is in addition to the below the bar buffer pool which is always allocated using the MINBUF and MAXBUF  parameters previously discussed. </p>
+
<tr>
 +
<td>
 +
<p>NGROUP</p></td>
 +
<td>
 +
<p>5</p></td>
 +
<td>
 +
<p>16383</p></td>
 +
<td>
 +
<p>Entries</p></td>
 +
</tr>
 
   
 
   
<p>When the above the bar buffer pool is allocated, Table B and Table X pages use it exclusively. Those pages are no longer read into the above the line buffer pool. Consequently, you can reduce the size of the above  the line buffer pool by the high water mark of Table B pages previously resident in that buffer pool. </p>
+
<tr>
 +
<td>
 +
<p>NORQS</p></td>
 +
<td>
 +
<p>5</p></td>
 +
<td>
 +
<p>32767</p></td>
 +
<td>
 +
<p>Entries</p></td>
 +
</tr>
 
   
 
   
<p>IOS Branch Entry is required when NUMBUFG is greater than zero, so the XMEMOPT setting must include the x'02' bit. </p>
+
<tr>
 +
<td>
 +
<p>NRMTFILE</p></td>
 +
<td>
 +
<p>0</p></td>
 +
<td>
 +
<p>16383</p></td>
 +
<td>
 +
<p>Entries</p></td>
 +
</tr>
 +
</table>
 +
 
 +
===Calculating variable table size===
 
   
 
   
<p>In addition, the disk buffer control blocks associated with the above the bar buffers are also allocated above the bar. </p>
+
<p>Use the following formula to calculate variable table size:</p>
 
   
 
   
====Above the bar storage for hash table cells====
+
<p class="code">Variable table size = 96
+
      + ((HTLEN+5) * (MAXHDR + MAXTRL)) dwr
<p>The hash table is used to locate pages in the buffer pool based on the file and page number. You control the number of hash cells allocated in the hash table with the parameter <var>HASHCELL</var>. If <var>NUMBUFG</var> is also set to a value greater than zero to allocate buffers above the bar, the hash cells are also allocated above the bar. For more information about controlling the allocation of hash cells per buffer pool page, see <var>[[HASHCELL parameter|HASHCELL]]</var>. </p>
+
      + (LFSCB) dwr
+
      + (LFTBL) dwr
====Implementing above the bar use of storage====
+
      + (LGTBL) dwr
+
      + (LHEAP) dwr
<p>If you set NUMBUFG greater than zero to use storage above the bar, IBM requires that you set a limit on how much of that virtual storage each address space can use. This limit is called MEMLIMIT.  See [[Set the IBM MEMLIMIT system option]] for more information.</p>
+
      + (LITBL) dwr
+
      + (LNTBL * 12)
===Monitoring disk buffers===
+
      + (LPDLST +32) dwr
 +
      + (LQTBL * 16)
 +
      + (LSTBL) dwr
 +
      + (LTTBL * 4)dwr
 +
      + (LVTBL * 32)
 +
      + (LXTBL) dwr
 +
</p>
 
<p>
 
<p>
If you want to implement <var>NUMBUFG</var> and do more analysis later, you might start by setting <var>NUMBUFG</var> equal to your <var>MAXBUF</var> setting and leaving <var>MAXBUF</var> at its current setting. Then you could use the [[MONITOR command: Disk buffers|MONITOR DISKBUFF commands]] to analyze the buffer pool utilizations. </p>
+
Each term of this formula that is followed by <code>dwr</code> must be doubleword rounded to the next multiple of eight. The "Variable server table values" table shows minimum and maximum  values:</p>
 
   
 
   
==Managing delayed disk updates==
+
<table>
 +
<caption>Variable server table values</caption>
 +
<tr class="head">
 +
<th>
 +
<p>Parameter</p></th>
 +
<th>
 +
<p>Default</p></th>
 +
<th>
 +
<p>Max </p></th>
 +
<th>
 +
<p>Bytes/entries/lines</p></th>
 +
</tr>
 
   
 
   
<p>The disk update process allows delayed disk updates, which avoids duplicate database writes in certain situations.</p>
+
<tr>
 +
<td>
 +
<p>HTLEN</p></td>
 +
<td>
 +
<p>132</p></td>
 +
<td>
 +
<p>32767</p></td>
 +
<td>
 +
<p>Bytes</p></td>
 +
</tr>
 
   
 
   
<p>When a user completes an update unit for a file and there are no other update units active against that file, <var class="product">Model&nbsp;204</var> writes the buffer to disk with all of the file's modified pages, marks the file as physically  consistent, and issues a message stating that the disk update is complete. </p>
+
<tr>
 +
<td>
 +
<p>LFSCB</p></td>
 +
<td>
 +
<p>8 (as of V7.7) <br />
 +
0 (7.6 or earlier) </p></td>
 +
<td>
 +
<p>65528</p></td>
 +
<td>
 +
<p>Bytes</p></td>
 +
</tr>
 
   
 
   
===Specifying delayed updates with the DKUPDTWT parameter===
+
<tr>
<p>
+
<td>
The CCAIN parameter <var>[[DKUPDTWT parameter|DKUPDTWT]]</var> specifies delayed disk updates. The value of DKUPDTWT determines how many seconds a disk buffer containing a file's modified pages must have aged before it can be written to disk. </p>
+
<p>LFTBL</p></td>
 +
<td>
 +
<p>1000</p></td>
 +
<td>
 +
<p>30 million</p></td>
 +
<td>
 +
<p>Bytes</p></td>
 +
</tr>
 
   
 
   
<p>When DKUPDTWT is zero, the default value, <var class="product">Model&nbsp;204</var> writes all of the file's modified pages to disk at the end of the last in-flight update of the file. The user who completed the last in-flight update waits for this disk  update process to complete and for the message stating that the disk update is complete. </p>
+
<tr>
 +
<td>
 +
<p>LGTBL</p></td>
 +
<td>
 +
<p>288</p></td>
 +
<td>
 +
<p>2 billion</p></td>
 +
<td>
 +
<p>Bytes</p></td>
 +
</tr>
 
   
 
   
<p>If DKUPDTWT is not zero, <var class="product">Model&nbsp;204</var> delays the start of the disk update process for at least DKUPDTWT seconds, after which it may be the checkpoint pseudo subtask (CHKPPST) that performs the disk update. The user who  completed the last in-flight update does not have to wait for the disk update process to complete. </p>
+
<tr>
 +
<td>
 +
<p>LHEAP</p></td>
 +
<td>
 +
<p>0</p></td>
 +
<td>
 +
<p>2 million</p></td>
 +
<td>
 +
<p>Bytes</p></td>
 +
</tr>
 
   
 
   
<p>When DKUPDTWT is not zero, the CHKPPST and CHKPTIMR pseudo subtasks are started automatically at <var class="product">Model&nbsp;204</var> initialization. An error message informs you if the NSUBTKS parameter is set too low to start these pseudo  subtasks.</p>
+
<tr>
 +
<td>
 +
<p>LITBL</p></td>
 +
<td>
 +
<p>8 (as of V7.7) <br />
 +
0 (7.6 or earlier) </p></td>
 +
<td>
 +
<p>32760</p></td>
 +
<td>
 +
<p>Bytes</p></td>
 +
</tr>
 
   
 
   
<p>The maximum value of DKUPDTWT depends on the value of the CPTIME parameter. If CPTIME is nonzero, DKUPDTWT must be less than or equal to <code>CPTIME*30</code>. The absolute maximum value of DKUPDTWT is 60. </p>
+
<tr>
 +
<td>
 +
<p>LNTBL</p></td>
 +
<td>
 +
<p>50</p></td>
 +
<td>
 +
<p>32760</p></td>
 +
<td>
 +
<p>12-byte entries</p></td>
 +
</tr>
 
   
 
   
<p>The system manager can reset DKUPDTWT to zero while the online is running. It can be reset to a nonzero value as long as the CHKPPST and CHKPTIMR pseudo subtasks were started during <var class="product">Model&nbsp;204</var> initialization.</p>
+
<tr>
+
<td>
===Handling delayed updates and CHKPPST===
+
<p>LPDLST</p></td>
+
<td>
<p>The CHKPPST pseudo subtask plays a central role in handling delayed disk updates. When DKUPDTWT is set to 0, CHKPPST does the following:</p>
+
<p>2600</p></td>
 +
<td>
 +
<p>32760</p></td>
 +
<td>
 +
<p>Bytes</p></td>
 +
</tr>
 
   
 
   
<ol>
+
<tr>
<li> Sleeps for CPTIME minutes.</li>
+
<td>
 +
<p>LQTBL</p></td>
 +
<td>
 +
<p>400</p></td>
 +
<td>
 +
<p>262,143</p></td>
 +
<td>
 +
<p>16-byte entries</p></td>
 +
</tr>
 
   
 
   
<li> Tries to quiesce updates, for up to CPTQ, plus CPTO seconds.</li>
+
<tr>
 +
<td>
 +
<p>LSTBL</p></td>
 +
<td>
 +
<p>600</p></td>
 +
<td>
 +
<p>16M</p></td>
 +
<td>
 +
<p>Bytes</p></td>
 +
</tr>
 
   
 
   
<li> Takes the checkpoint, if all updates are quiesced.</li>
+
<tr>
</ol>
+
<td>
 +
<p>LTTBL</p></td>
 +
<td>
 +
<p>50</p></td>
 +
<td>
 +
<p>8190</p></td>
 +
<td>
 +
<p>4-byte entries</p></td>
 +
</tr>
 
   
 
   
<p>If DKUPDTWT is greater than 0, CHKPPST has substantially more processing to perform: </p>
+
<tr>
 +
<td>
 +
<p>LVTBL</p></td>
 +
<td>
 +
<p>50</p></td>
 +
<td>
 +
<p>524287</p></td>
 +
<td>
 +
<p>32-byte entries</p></td>
 +
</tr>
 
   
 
   
<ol>
+
<tr>
<li> Sleeps for DKUPDTWT divided by four seconds.</li>
+
<td>
+
<p>LXTBL</p></td>
<li> Further processing depends on the value, rounded to the nearest integer of:</li>
+
<td>
</ol>
+
<p>1000</p></td>
 +
<td>
 +
<p>32760</p></td>
 +
<td>
 +
<p>Bytes</p></td>
 +
</tr>
 
   
 
   
<p class="code">N = (CPTIME * 60) / (DKUPDTWT / 4)
+
<tr>
</p>
+
<td>
 +
<p>MAXHDR</p></td>
 +
<td>
 +
<p>5</p></td>
 +
<td>
 +
<p>32767</p></td>
 +
<td>
 +
<p>Lines</p></td>
 +
</tr>
 
   
 
   
===Attempting a checkpoint===
+
<tr>
 +
<td>
 +
<p>MAXTRL</p></td>
 +
<td>
 +
<p>5</p></td>
 +
<td>
 +
<p>32767</p></td>
 +
<td>
 +
<p>Lines</p></td>
 +
</tr>
 +
</table>
 +
 
 +
==Server tables==
 
<p>
 
<p>
If the number of wake-up calls since the last checkpoint is <var>N</var>, CHKPPST takes a new checkpoint, as follows:</p>
+
Server tables are sections of the server area used by the SOUL compiler and evaluator to store all the information necessary to run a request. Some server tables are also used by the editor and HLI functions.</p>
 +
 +
<p>Each user has a copy of the server tables in the server. Table sizes are controlled by the parameters shown in the [[#User 0 parameters|"Common runtime parameters" table]]. Parameter settings on the  user's parameter line affect the size of the servers and the region.</p>
 +
 +
<p>The "Summary of server tables" lists the server tables. Further information on individual tables is contained in the subsections that follow.</p>
 
   
 
   
 
<table>
 
<table>
 +
<caption>Summary of server tables</caption>
 
<tr class="head">
 
<tr class="head">
<th><p>Attempt </p> </th>
+
<th><p>Table</p></th>
<th><p>Purpose</p> </th></tr>
+
<th><p>Contents</p></th>
 +
</tr>
 
   
 
   
 
<tr>
 
<tr>
<td>1. </td>
+
<td><p>FSCB</p></td>
<td>Performs the disk update process on all files that are not being updated, regardless of how long since they were marked disk-update-needed. </td></tr>
+
<td><p>Menu, screen, and image information</p></td>
 +
</tr>
 
   
 
   
 
<tr>
 
<tr>
<td>2.  </td>
+
<td><p>FTBL</p></td>
<td>Attempts to deactivate Host Language Interface (HLI) updates for CPTQ seconds. Performs the disk update process on all files that are not being updated each time <var class="product">Model&nbsp;204</var> determines that there are more HLI  jobs to wait for.</td></tr>
+
<td><p>File groups</p></td>
 +
</tr>
 +
 
<tr>
 
<tr>
<td>3.  </td>
+
<td><p>GTBL</p></td>
<td>Attempts to deactivate all other updates for CPTO seconds. Performs the disk update process on all files that are not being updated each time <var class="product">Model&nbsp;204</var> determines that there are more users to wait for. </td></tr>
+
<td><p>Global variables</p></td>
 +
</tr>
 
   
 
   
 
<tr>
 
<tr>
<td>4.  </td>
+
<td><p>ITBL</p></td>
<td>If all updates have been deactivated, performs the disk update process on all remaining files marked disk-update-needed. Otherwise, abandons the checkpoint attempt. </td></tr>
+
<td><p>Dummy string and $READ responses</p></td>
 +
</tr>
 
   
 
   
 
<tr>
 
<tr>
<td>5. </td>
+
<td><p>NTBL</p></td>
<td>Performs the disk update process again. Then takes the checkpoint. </td></tr>
+
<td><p>Statement labels, list names, and variables</p></td>
 +
</tr>
 
   
 
   
 
<tr>
 
<tr>
<td>6. </td>
+
<td><p>QTBL</p></td>
<td>If the number of wake-up calls since the last checkpoint is not <var>N</var>, CHKPPST performs the disk update process on all files that have aged sufficiently &mdash; that is, marked disk-update-needed for at least DKUPDTWT seconds. </td></tr>
+
<td><p>Statements in internal form (quadruples)</p></td>
</table>
+
</tr>
 
   
 
   
===Factors affecting disk update and checkpoint processing===
+
<tr>
 +
<td><p>RTBL</p></td>
 +
<td><p>User privileges, class, and field level security information</p></td>
 +
</tr>
 
   
 
   
<p>Several important factors affect the processing of disk updates and checkpoints:</p>
+
<tr>
   
+
<td><p>STBL</p></td>
<ul>
+
<td><p>Character strings</p></td>
<li> Some disk updates might be interrupted by another thread's request for the file's UPDATE resource. Attempts 1, 2, 3, 4, and 6 might be interrupted by an attempt to start a new update or by a user doing a disk  update as part of CLOSE FILE processing. In these cases, the following message is issued, and the next file is processed:
+
</tr>
 +
   
 +
<tr>
 +
<td><p>TTBL</p></td>
 +
<td><p>Temporary work pages</p></td>
 +
</tr>
 
   
 
   
<p class="code">M204.0440: DISK UPDATED ABORTED
+
<tr>
</p> </li>
+
<td><p>VTBL</p></td>
 +
<td><p>Compiler variables</p></td>
 +
</tr>
 
   
 
   
<li> Attempts 2, 3, and 4 might be interrupted by the expiration of the waiting time set with <var class="product">Model&nbsp;204</var> parameters CPTQ and CPTO, respectively. In these cases, the M204.0440 message is issued, all remaining files are bypassed,  and the checkpoint is timed out.</li>
+
<tr>
 +
<td><p>XTBL</p></td>
 +
<td><p>Procedure security</p></td>
 +
</tr>
 +
</table>
 
   
 
   
<li> If CPTQ and CPTO are zero (no time-out intervals specified) and the DKUPDTWT parameter is nonzero, updates are deactivated for as long as required to perform the disk update process for all available files. If you do not want checkpoint attempts to deactivate updates, set DKUPDTWT to zero.</li>
+
===Full-screen buffer table (FSCB)===
 +
<p>
 +
The full-screen buffer table (FSCB) stores menu, screen, and image definitions, in addition to the values of screen variables and image data blocks. FSCB space is reused by each logical menu definition, logical screen definition, or block definition.</p>
 
   
 
   
<li> If Attempts 2, 3, or 4 abort due to a CPTO or CPTQ time-out, the checkpoint time-out message indicates the name of the file being written at the time of the time-out:
+
<p>The FSCB must be large enough to hold the largest screen, image, or menu definition. The following space is required:</p>
 
   
 
   
<p class="code">M204.0843: CHECKPOINT TIMED OUT ON date/time UPDATING FILE file
+
<ul>
</p>
+
<li>144 bytes of fixed overhead for every menu, including the menu title</li>
 
   
 
   
<li> Attempt 5 cannot be interrupted once it begins. Therefore, CPTO and CPTQ intervals are not honored for a CLOSE FILE command that is blocking a checkpoint. This type of event is likely to be infrequent and of short  duration.</li>
+
<li>144 bytes for each menu prompt</li>
 
   
 
   
<li> The sleep intervals of CHKPPST are not adjusted by the amount of time required to perform Attempt 6. Therefore, checkpoints might be spaced out by more than CPTIME minutes. If this is a frequent problem, adjust  CPTIME downward.
+
<li>432 bytes of fixed overhead for the first panel of every screen:</li>
</li>
 
</ul>
 
 
   
 
   
==Understanding file statistics==
+
<li>144 bytes for each subsequent panel, including the screen title</li>
 
   
 
   
<p>For descriptions of the file statistics DKUPTIME, UPDTTIME, and PDNGTIME, see [[Performance monitoring and tuning#Disk buffer monitor statistics and parameters|Disk buffer monitor statistics and parameters]]. </p>
+
<li>32 bytes for each screen prompt and input item</li>
 
   
 
   
===Handling 64-bit statistics===
+
<li>32 bytes for every screen line containing at least one input item</li>
<p>
+
To support very long running <var class="product">Model&nbsp;204</var> regions, Model&nbsp;204 V7R1 included modifications to the capacity of statistical counters (by increasing the size of some statistics and also exploiting 64-bit processing where appropriate). For sites upgrading to V7R1 or later, in-house or third-party support applications that process statistical counters need to review the statistics generated:</p>
+
<li>80 bytes for each defined screen line, including skipped lines</li>
 
   
 
   
<ul>
+
<li>Additional space for automatic validation, including:</li>
<li>As some of the statistics fields became double-words, check [[Using system statistics]] for a revised layout of the System, Final, and Partial statistics. Also, additional Disk Buffer Monitor, MP/204, and File statistics were updated.</li>
 
 
   
 
   
<li>Examine your in-house or third-party support applications for changes you need to make because of the increased length of some of the statistics. Make any changes necessary to your applications, then reassemble with the release upgrade.</li>
+
<li>2 or 4 bytes for each automatic validation option</li>
 
   
 
   
<li>If your in-house or third party support applications don't reference any of these double word statistics, you only need to reassemble your program with the updated offsets.</li>
+
<li>256 bytes for the VERIFY command when a particular character set is used in a compiled screen for the first time</li>
 
</ul>
 
</ul>
 
   
 
   
==Server areas==
+
<p>Additional occurrences of the same character set do not add extra space. ONEOF and character RANGE store each character string plus one byte for each string's length.</p>
 
   
 
   
<p>Server areas are the internal work areas allocated to each user. Each area is divided into a fixed and variable portion. The fixed portion, which includes logical I/O buffers and user  resettable parameters, is calculated by <var class="product">Model&nbsp;204</var> at initialization. The variable portion can be changed dynamically with the <var>[[UTABLE command]]</var> command or the <var>IFUTBL</var> IFAM function (see the  <var class="book">Rocket Model&nbsp;204 Host Language Interface Reference Manual</var>). </p>
+
<ul>
 +
<li>8 bytes for each number in a NUMERIC RANGE statement (16 bytes for each range pair)</li>
 
   
 
   
===Sizing user server areas===
+
<li>Space for every block used in image definition</li>
 +
</ul>
 
   
 
   
<p>The default size of all user server areas is set on User 0's parameter line. If the default is used, the allocated server area is exactly large enough to contain the tables for each user specified on each user's  parameter line. If SERVSIZE is also specified on a particular user's parameter line, the default is overridden for that user.</p>
+
<p>The amount of required space is computed as the sum of the specific [[SOUL]] statements, clauses, and items. For a complete list of these values, see [[Full-screen feature]]. </p>
 
   
 
   
<p>The value of SERVSIZE must be as large as, or larger than, the user's aggregate table size. It is calculated by examining the user's server area requirements and monitoring the system statistics  (described in [[ONLINE monitoring]]) that provide information about the installation work load. The following formula gives the approximate size:</p>
+
===File group table (FTBL)===
 +
<p>
 +
Data structures particular to file groups are stored in FTBL. FTBL entries are:</p>
 
   
 
   
<p class="syntax">SERVSIZE = <span class="term">fixed-table-size</span> + <span class="term">variable-table-size</span>
+
<ul>
</p>
+
<li> Sixty-two-byte fixed size entry plus six bytes for each file in the group definition.
<p>Where:</p>
 
 
   
 
   
<ul>
+
<p>This entry is allocated each time a group is opened (explicitly by the OPEN command or implicitly for an ad hoc group) and is released when the group is closed.</p></li>
<li><var class="term">fixed-table-size</var> represents settings, defined during initialization, that cannot be modified during the run. </li>
 
 
   
 
   
<li><var class="term">variable-table-size</var> represents settings that can be varied using the UTABLE command or its IFAM equivalent, IFUTBL.
+
<li> Variable entry, consisting of nine fixed-bytes plus a number of bytes equal to the length of the field name plus 11 bytes per file in the group
</li>
+
<p>
 +
This entry is created for collecting field-name codes and properties during a SOUL request. An entry is allocated each time a new field name is encountered in the request. The field entries are deleted at  every END statement (including END MORE). </p></li>
 
</ul>
 
</ul>
 
   
 
   
====SERVSIZE and server page alignment====
+
<p>When the Inverted File Access Method (IFAM) is used: </p>
 
   
 
   
<p>Servers and some server tables are always aligned on a 4K page boundary. In pre-7.4.0 releases, server and tables alignment took place only when DSPOPT had settings of bits X'01' or X'02' or the APSYPAGE parameter was indicated. </p>
+
<ul>
 +
<li>Host Language threads use FTBL under the same circumstances as SOUL.</li>
 
   
 
   
<p>If you used server alignment previously, there is no change in your server size requirements.</p>
+
<li>Field entries are not deleted until the group is closed or until IFFNSH is called. </li>
 
   
 
   
<p>If you did not use server alignment previously, then you might notice an increase in server size that in the worst case could be up to 24528 bytes per server. </p>
+
<li>Increase the total FTBL requirement by NGROUP times four bytes.
 +
</li>
 +
</ul>
 
   
 
   
<p>When you calculate server size, take into account that FSCB, HEAP, NTBL, QTBL, STBL, and VTBL are each rounded on a 4K page boundary, so in the worst case each area could require up to 4088 bytes of server space,  compared to servers with no alignment in previous releases. </p>
+
<p>For Parallel Query Option/204 server nodes, the required size of FTBL increases by eleven bytes times the total number of group members for temporary scattered groups opened at the  client and containing a member on the server node.</p>
 
   
 
   
<p>The following sections explain how server area sizing parameters are processed, which parameters determine fixed and variable table sizes, and the ranges of values these parameters can take.</p>
+
<p>For information on using FTBL in 64-bit storage, see [[#Using 64-bit addressing and Above the Bar (ATB) storage|Above the bar storage]].</p>
 +
 
 +
===Understanding the global variable table (GTBL)===
 +
<p>
 +
GTBL contains information about:</p>
 
   
 
   
===Initialization and error handling===
+
<ul>
 +
<li>Global variables </li>
 
   
 
   
<p>During initialization, each user, except User 0, is identified in the output before the user's parameter line is read. The aggregate size of each user's tables and the size of tables fixed during initialization are  printed after the user's parameters are read.    </p>
+
<li>Global images, screens, and menus</li>
 +
</ul>
 
   
 
   
<p>If errors are detected, they are reported and initialization continues whenever possible. If errors are detected during initialization, the run is canceled at the end of initialization. Error conditions in initializing  the server cause the run to end immediately with a return code of 96. </p>
+
<p>GTBL entries are created by the <var>$Incrg</var>, <var>$Getg</var>, and <var>$Setg</var> functions. When a global variable is redefined, its old entry is deleted from GTBL and a new entry is added. </p>
 
   
 
   
<p>The results of user changes to the sizes of FTBL, GTBL, ITBL, and XTBL are discussed in the <var class="product">Model&nbsp;204</var> Parameter and Command Reference.     </p>
+
<p>In addition, a 32-byte trailer stores information about offsets. </p>
 +
 
 +
<p>For information on using GTBL in 64-bit storage, see [[#Using_64-bit addressing and Above the Bar .28ATB.29 storage|Above the bar storage]].</p>
 
   
 
   
===Calculating fixed table size===
+
====Clearing GTBL entries====
 +
<p>
 +
The <var>CLEARGO</var> command deletes all images, screens, and menus. You can also use the <var>CLEAR GLOBALS</var> statement to delete selected types of GTBL entries. For details, see [[Global features]].</p>
 +
 +
====Space allocation====
 +
<p>
 +
The space allocation for a global variable includes:</p>
 
   
 
   
<p>Use the following formula to calculate fixed table size, the FIXSIZE parameter value:</p>
+
<ul>
 +
<li>4 bytes indicating the length of GTBL</li>
 
   
 
   
<p class="code">Fixed table size = 2520
+
<li>1 byte for the length of the variable name</li>
 
   
 
   
      + ((LAUDPROC + 9) * 4)dwr
+
<li>Variable name</li>
 
   
 
   
      + (LIBUFF + 4)
+
<li>1 byte for the length of the current name</li>
 
   
 
   
      + (LOBUFF + 5)dwr
+
<li>Current value  </li>
 +
</ul>
 
   
 
   
      + (LOUTPB)dwr
+
<p>
 +
Global images, screens, and menus require space for a 20-byte header in addition to the size of the object.</p>
 
   
 
   
      + ((NGROUP + 12) * (NRMTFILE + NFILES + 1))
+
<p>
 +
When allocating GTBL space, always remember to add 32 bytes for the trailer.</p>
 
   
 
   
      + (((NORQS*3) + 2)dwr + (NRMTFILE + 1))dwr
+
<p>
 +
The minimum length of GTBL is 40 bytes (X'28').</p>
 
   
 
   
      + (3 * (ERRMSGL - 80))
+
====Improving global variable processing====
</p>
+
<p>
<p>Each term of this formula that is followed by dwr must be double word rounded to the next multiple of eight. For example, if the value of LOBUFF is 500, the term (LOBUFF + 5) = 505, which must be rounded to 512, the next  multiple of 8. </p>
+
You can improve global variable processing by setting the <var>[[FASTGLOB parameter|FASTGLOB]]</var>, <var>[[GTBLPCT parameter|GTBLPCT]]</var>, and <var>[[GTBLHASH parameter|GTBLHASH]]</var> parameters. See [[Global features]] for a discussion of how these parameters affect performance. </p>
 +
 
 +
===Dummy string and $READ table (ITBL)===
 +
<p>
 +
ITBL holds dummy string and $READ responses that are entered as arguments to an INCLUDE statement or command.</p>
 
   
 
   
<p>If SYSOPT = 1 or 2 (indicating CCASYS or CCAGRP), add 1 to the value of NFILES used in the formula. If SYSOPT = 3 (indicating both CCASYS and CCAGRP), add 2.</p>
+
<p>The space allocation for an ITBL entry includes:</p>
 
   
 
   
<p>If any SQL threads are specified in CCAIN (IODEVs 13, 17, or 19), add 6712 bytes for C language work areas.</p>
+
<ul>
 +
<li>Argument strings, including delimiters, which are saved as they are entered</li>
 
   
 
   
<p>The "Fixed server table values" table, below, shows the minimum, maximum, and default values for parameters that affect fixed server table sizing. The rightmost columns show the relevant  units of measure; for example, the maximum value of NORQS is 32767 entries (not bytes). The values of LIBUFF and LOBUFF may need to be increased for SQL processing. Recommended values are <code>LIBUFF=3000</code> and <code>LOBUFF=5000</code>.</p>
+
<li>4 bytes of overhead for each saved string</li>
 +
</ul>
 
   
 
   
<table>
+
<p>Space taken by a string is released when the included procedure is executed.</p>
<caption>Fixed server table values</caption>
+
   
<tr class="head">
+
===Labels, names, and variables table (NTBL)===
<th><p>Parameter</p>
+
<p>
  </th>
+
NTBL holds labels, names, and variables. Each entry is allocated 12 bytes. NTBL has two entries for each first occurrence of a COMMON declaration.</p>
<th><p>Default</p>
+
   
</th>
+
<p>NTBL has one entry for each of the following elements: </p>
<th><p>Max </p>
 
  </th>
 
<th><p>Bytes/entries</p>
 
</th>
 
</tr>
 
 
   
 
   
<tr>
+
<ul>
<td>
+
<li>Statement label</li>
<p>ERRMSGL</p>
 
</td>
 
<td>
 
<p>80</p>
 
</td>
 
<td>
 
<p>256</p>
 
</td>
 
<td>
 
<p>Bytes</p>
 
</td>
 
</tr>
 
 
   
 
   
<tr>
+
<li>List name</li>
<td>
 
<p>LAUDPROC</p>
 
</td>
 
<td>
 
<p>21</p>
 
</td>
 
<td>
 
<p>253</p>
 
</td>
 
<td>
 
<p>Bytes</p>
 
</td>
 
</tr>
 
 
   
 
   
<tr>
+
<li>%variable</li>
<td>
+
   
<p>LIBUFF</p>
+
<li>Image, menu, and screen variable</li>
  </td>
+
   
<td>
+
<li>Partner process opened by a request</li>
<p>255</p>
+
   
  </td>
+
<li>Additional <var>COMMON</var> declaration</li>
<td>
 
<p>32767</p>
 
  </td>
 
<td>
 
<p>Bytes</p>
 
</td>
 
</tr>
 
 
   
 
   
<tr>
+
<li>Unlabeled <var>Find</var></li>
<td>
 
<p>LOBUFF</p>
 
</td>
 
<td>
 
<p>256</p>
 
</td>
 
<td>
 
<p>32767</p>
 
</td>
 
<td>
 
<p>Bytes</p>
 
</td>
 
</tr>
 
 
   
 
   
<tr>
+
<li><var>For Each Value</var> statement</li>
<td>
 
<p>LOUTPB</p>
 
</td>
 
<td>
 
<p>0</p>
 
</td>
 
<td>
 
<p>3000</p>
 
</td>
 
<td>
 
<p>Bytes</p>
 
</td>
 
</tr>
 
 
   
 
   
<tr>
+
<li><var>For</var> statement with the <var>In Order</var> clause</li>
<td>
+
<p>NFILES</p>
+
<li>Sequential or VSAM file opened simultaneously</li>
</td>
+
</ul>
<td>
+
<p>2</p>
+
<p>Most NTBL entries are preserved by the <var>MORE</var> command, except for the unlabeled <var>Find</var> and secondary <var>For</var> entries, which are deleted.</p>
</td>
 
<td>
 
<p>16383</p>
 
</td>
 
<td>
 
<p>Entries</p>
 
</td>
 
</tr>
 
 
   
 
   
<tr>
+
<p>A host language thread requires NTBL entries for list names, compilation names, and variables. </p>
<td>
 
<p>NGROUP</p>
 
</td>
 
<td>
 
<p>5</p>
 
</td>
 
<td>
 
<p>16383</p>
 
</td>
 
<td>
 
<p>Entries</p>
 
</td>
 
</tr>
 
 
   
 
   
<tr>
+
<p><var>FLOD</var> uses NTBL entries for tags and index registers. The size of NTBL determines the highest tag or index that can be specified. In this case, NTBL must be at least 12 bytes multiplied by the highest tag or index size desired. </p>
<td>
 
<p>NORQS</p>
 
</td>
 
<td>
 
<p>5</p>
 
</td>
 
<td>
 
<p>32767</p>
 
  </td>
 
<td>
 
<p>Entries</p>
 
</td>
 
</tr>
 
 
   
 
   
<tr>
+
<p>You need not allow extra space for runtime NTBL storage used during request evaluation of an <var>Open Dataset</var>, <var>Open External</var>, or <var>Open Terminal</var> statement. Use the compiler highwater mark to set LNTBL. </p>
<td>
+
 
<p>NRMTFILE</p>
+
<p>For information on using NTBL in 64-bit storage, see [[#Using 64-bit addressing and Above the Bar .28ATB.29 storage|Above the bar storage]].</p>
</td>
+
 
<td>
+
===Internal statement table (QTBL)===
<p>0</p>
 
</td>
 
<td>
 
<p>16383</p>
 
  </td>
 
<td>
 
<p>Entries</p>
 
</td>
 
</tr>
 
</table>
 
 
   
 
   
===Calculating variable table size===
+
<p>QTBL holds internal <var class="product">Model&nbsp;204</var> instructions that result from compilation of each internal statement. After compilation, the entries in QTBL drive the evaluator. QTBL is emptied by <var>End</var> and <var>End More</var> statements.</p>
 
   
 
   
<p>Use the following formula to calculate variable table size:</p>
+
<p>The Editor formats all of QTBL into 16-byte entries, which provide a map of text being edited. The number of entries used depends on the number and position of insertions and deletions, not on the amount of text.</p>
 
   
 
   
<p class="code">Variable table size = 96
+
<p>Quadruple (QTBL) entries generated by SOUL statements vary in number and size. The "Sample QTBL entries" table, below, shows typical values for each entry. For more QTBL information, see [[Large request considerations#QTBL (internal statement table)|QTBL (internal statement table)]]. </p>
 
   
 
   
      + ((HTLEN+5) * (MAXHDR + MAXTRL)) dwr
+
<p>You can reduce server I/O by allowing users executing shared precompiled procedures to use a shared copy of QTBL.</p>
 +
 
 +
<p>For information on using QTBL in 64-bit storage, see [[#Using 64-bit addressing and Above the Bar .28ATB.29 storage|Above the bar storage]].</p>
 +
 
 +
===QTBL and IFAM processing===
 +
<p>
 +
When using the Inverted File Access Method (IFAM):</p>
 
   
 
   
      + (LFSCB) dwr
+
<ul>
 +
<li><var>IFFIND</var>, <var>IFCOUNT</var>, and list manipulations build quadruples so that the SOUL evaluator routines can be used.</li>
 
   
 
   
      + (LFTBL) dwr
+
<li><var>IFGET</var>, <var>IFMORE</var>, and <var>IFPUT</var> build field name lists in QTBL.</li>
 
   
 
   
      + (LGTBL) dwr
+
<li>Other calls are evaluated directly.</li>
 +
</ul>
 +
<p>
 +
IFAM's use of QTBL and the effect of the compiled IFAM feature are discussed in detail in [[HLI: Model 204 tables#Internal statements.2Fquad table .28QTBL.29|Internal statements/quad table (QTBL)]] and [[HLI: IFSTRT processing#Using the compiled IFAM facility|Using the compiled IFAM facility]]. </p>
 +
 
 +
===QTBL and FLOD processing===
 +
<p>
 +
FLOD builds its own quadruples (flodruples) in QTBL. Flodruple sizes vary, but most are 20 bytes or less. </p>
 
   
 
   
      + (LHEAP) dwr
+
<p>Major exceptions are:</p>
 
   
 
   
      + (LITBL) dwr
+
<ul>
 +
<li>Read-and-load-field flodruple, which expands four bytes for each entry in a translation table</li>
 
   
 
   
      + (LNTBL * 12)
+
<li>CASE statement, which requires eight bytes for each comparison string
 +
</li>
 +
</ul>
 
   
 
   
      + (LPDLST +32) dwr
+
===Sample QTBL entries===
+
<p>"Sample QTBL entries" shows typical QTBL entry sizes for various SOUL statements and program structures: </p>
      + (LQTBL * 16)
 
 
      + (LSTBL) dwr
 
 
      + (LTTBL * 4)dwr
 
 
      + (LVTBL * 32)
 
 
      + (LXTBL) dwr
 
</p>
 
<p>
 
Each term of this formula that is followed by <code>dwr</code> must be doubleword rounded to the next multiple of eight. The "Variable server table values" table shows minimum and maximum  values:</p>
 
 
   
 
   
 
<table>
 
<table>
<caption>Variable server table values</caption>
+
<caption>Sample QTBL entries</caption>
 
<tr class="head">
 
<tr class="head">
 
<th>
 
<th>
<p>Parameter</p>
+
<p>SOUL statement</p></th>
</th>
 
 
<th>
 
<th>
<p>Default</p>
+
<p>QTBL entry size</p></th>
</th>
 
<th>
 
<p>Max </p>
 
</th>
 
<th>
 
<p>Bytes/entries/lines</p>
 
</th>
 
 
</tr>
 
</tr>
 
   
 
   
 
<tr>
 
<tr>
 
<td>
 
<td>
<p>HTLEN</p>
+
<p>$functions</p></td>
</td>
 
 
<td>
 
<td>
<p>132</p>
+
<p>16 + 3 per argument</p></td>
  </td>
+
</tr>
 +
   
 +
<tr>
 
<td>
 
<td>
<p>32767</p>
+
<p>%variable, subscripted (reference to)</p></td>
</td>
 
 
<td>
 
<td>
<p>Bytes</p>
+
<p>16 + expression evaluation</p></td>
</td>
 
 
</tr>
 
</tr>
 
   
 
   
 
<tr>
 
<tr>
 
<td>
 
<td>
<p>LFSCB</p>
+
<p>ADD</p></td>
</td>
 
 
<td>
 
<td>
<p>0</p>
+
<p>20</p></td>
  </td>
+
</tr>
 +
   
 +
<tr>
 
<td>
 
<td>
<p>65528</p>
+
<p>AFTER</p></td>
</td>
 
 
<td>
 
<td>
<p>Bytes</p>
+
<p>20</p></td>
</td>
 
 
</tr>
 
</tr>
 
   
 
   
 
<tr>
 
<tr>
 
<td>
 
<td>
<p>LFTBL</p>
+
<p>AND (except where AND is part of BETWEEN)</p></td>
</td>
 
 
<td>
 
<td>
<p>1000</p>
+
<p>16</p></td>
  </td>
+
</tr>
 +
   
 +
<tr>
 
<td>
 
<td>
<p>30 million</p>
+
<p>Conversion between a string and a number</p></td>
</td>
 
 
<td>
 
<td>
<p>Bytes</p>
+
<p>16</p></td>
</td>
 
 
</tr>
 
</tr>
 
   
 
   
 
<tr>
 
<tr>
 
<td>
 
<td>
<p>LGTBL</p>
+
<p>CALL</p></td>
</td>
 
 
<td>
 
<td>
<p>288</p>
+
<p>16</p></td>
  </td>
+
</tr>
 +
   
 +
<tr>
 
<td>
 
<td>
<p>2 billion</p>
+
<p>CHANGE</p></td>
</td>
 
 
<td>
 
<td>
<p>Bytes</p>
+
<p>44</p></td>
</td>
 
 
</tr>
 
</tr>
 
   
 
   
 
<tr>
 
<tr>
 
<td>
 
<td>
<p>LHEAP</p>
+
<p>CLEAR LIST</p></td>
</td>
 
 
<td>
 
<td>
<p>0</p>
+
<p>20</p></td>
  </td>
+
</tr>
 +
   
 +
<tr>
 
<td>
 
<td>
<p>2 million</p>
+
<p>CLEAR ON</p></td>
</td>
 
 
<td>
 
<td>
<p>Bytes</p>
+
<p>16</p></td>
</td>
 
 
</tr>
 
</tr>
 
   
 
   
 
<tr>
 
<tr>
 
<td>
 
<td>
<p>LITBL</p>
+
<p>CLEAR TAG</p></td>
</td>
 
 
<td>
 
<td>
<p>0</p>
+
<p>16</p></td>
  </td>
+
</tr>
 +
   
 +
<tr>
 
<td>
 
<td>
<p>32760</p>
+
<p>CLOSE</p></td>
</td>
 
 
<td>
 
<td>
<p>Bytes</p>
+
<p>16</p></td>
</td>
 
 
</tr>
 
</tr>
 
   
 
   
 
<tr>
 
<tr>
 
<td>
 
<td>
<p>LNTBL</p>
+
<p>CLOSE PROCESS</p></td>
</td>
 
 
<td>
 
<td>
<p>50</p>
+
<p>16</p></td>
  </td>
+
</tr>
 +
   
 +
<tr>
 
<td>
 
<td>
<p>32760</p>
+
<p>COMMIT</p></td>
</td>
 
 
<td>
 
<td>
<p>12-byte entries</p>
+
<p>4</p></td>
</td>
 
 
</tr>
 
</tr>
 
   
 
   
 
<tr>
 
<tr>
 
<td>
 
<td>
<p>LPDLST</p>
+
<p>COMMIT RELEASE</p></td>
</td>
 
 
<td>
 
<td>
<p>2600</p>
+
<p>20</p></td>
  </td>
+
</tr>
 +
   
 +
<tr>
 
<td>
 
<td>
<p>32760</p>
+
<p>COUNT RECORDS (with a group)</p></td>
</td>
 
 
<td>
 
<td>
<p>Bytes</p>
+
<p>52 + 20</p></td>
</td>
 
 
</tr>
 
</tr>
 
   
 
   
 
<tr>
 
<tr>
 
<td>
 
<td>
<p>LQTBL</p>
+
<p>DELETE</p></td>
</td>
 
 
<td>
 
<td>
<p>400</p>
+
<p>24</p></td>
  </td>
+
</tr>
 +
   
 +
<tr>
 
<td>
 
<td>
<p>262,143</p>
+
<p>DELETE RECORD</p></td>
</td>
 
 
<td>
 
<td>
<p>16-byte entries</p>
+
<p>16</p></td>
</td>
 
 
</tr>
 
</tr>
 
   
 
   
 
<tr>
 
<tr>
 
<td>
 
<td>
<p>LSTBL</p>
+
<p>ELSE</p></td>
</td>
 
 
<td>
 
<td>
<p>600</p>
+
<p>16 + body of the clause</p></td>
  </td>
+
</tr>
 +
   
 +
<tr>
 
<td>
 
<td>
<p>16M</p>
+
<p>ELSEIF</p></td>
</td>
 
 
<td>
 
<td>
<p>Bytes</p>
+
<p>16 + body of the clause END</p></td>
</td>
 
 
</tr>
 
</tr>
 
   
 
   
 
<tr>
 
<tr>
 
<td>
 
<td>
<p>LTTBL</p>
+
<p>END</p></td>
</td>
 
<td>
 
<p>50</p>
 
</td>
 
<td>
 
<p>8190</p>
 
</td>
 
 
<td>
 
<td>
<p>4-byte entries</p>
+
<p>4</p></td>
</td>
 
 
</tr>
 
</tr>
 
   
 
   
 
<tr>
 
<tr>
 
<td>
 
<td>
<p>LVTBL</p>
+
<p>Function call</p></td>
</td>
 
 
<td>
 
<td>
<p>50</p>
+
<p>16 + argument evaluation</p></td>
  </td>
+
</tr>
 +
   
 +
<tr>
 
<td>
 
<td>
<p>524287</p>
+
<p>FIND (with at least one direct condition)</p></td>
</td>
 
 
<td>
 
<td>
<p>32-byte entries</p>
+
<p>64 + 16</p></td>
</td>
 
 
</tr>
 
</tr>
 
   
 
   
 
<tr>
 
<tr>
 
<td>
 
<td>
<p>LXTBL</p>
+
<p>FIND (with inverted condition)</p></td>
</td>
 
 
<td>
 
<td>
<p>1000</p>
+
<p>64 + 36</p></td>
  </td>
+
</tr>
 +
   
 +
<tr>
 
<td>
 
<td>
<p>32760</p>
+
<p>FIND ALL RECORDS (no qualification)</p></td>
</td>
 
 
<td>
 
<td>
<p>Bytes</p>
+
<p>64</p></td>
</td>
 
 
</tr>
 
</tr>
 
   
 
   
 
<tr>
 
<tr>
 
<td>
 
<td>
<p>MAXHDR</p>
+
<p>FIND ALL RECORDS (with record  security and group)</p></td>
</td>
 
 
<td>
 
<td>
<p>5</p>
+
<p>64 + 52 + 20</p></td>
  </td>
+
</tr>
 +
   
 +
<tr>
 
<td>
 
<td>
<p>32767</p>
+
<p>FIND ALL RECORDS (with record  security)</p></td>
</td>
 
 
<td>
 
<td>
<p>Lines</p>
+
<p>64 + 52</p></td>
</td>
 
 
</tr>
 
</tr>
 
   
 
   
 
<tr>
 
<tr>
 
<td>
 
<td>
<p>MAXTRL</p>
+
<p>FIND ALL VALUES (FRV field)</p></td>
</td>
 
 
<td>
 
<td>
<p>5</p>
+
<p>74</p></td>
  </td>
+
</tr>
 +
   
 +
<tr>
 
<td>
 
<td>
<p>32767</p>
+
<p>FIND ALL VALUES (ORDERED field)</p></td>
</td>
 
 
<td>
 
<td>
<p>Lines</p>
+
<p>32</p></td>
</td>
 
 
</tr>
 
</tr>
</table>
 
 
   
 
   
==Server tables==
+
<tr>
 +
<td>
 +
<p>FOR EACH RECORD</p></td>
 +
<td>
 +
<p>24 + body of the loop</p></td>
 +
</tr>
 
   
 
   
<p>Server tables are sections of the server area used by the User Language compiler and evaluator to store all the information necessary to run a request. Some server tables are also used by the editor and HLI functions.</p>
+
<tr>
+
<td>
<p>Each user has a copy of the server tables in the server. Table sizes are controlled by the parameters shown in the [[#User 0 parameters|"Common runtime parameters" table]]. Parameter settings on the  user's parameter line affect the size of the servers and the region.</p>
+
<p>FOR EACH VALUE OF (with IN ORDER, a group)</p></td>
+
<td>
<p>The "Summary of server tables" lists the server tables. Further information on individual tables is contained in the subsections that follow.</p>
+
<p>88 + body of the loop + 68 + 24</p></td>
 
<table>
 
<caption>Summary of server tables</caption>
 
<tr class="head">
 
<th><p>Table</p></th>
 
<th><p>Contents</p></th>
 
 
</tr>
 
</tr>
 
   
 
   
 
<tr>
 
<tr>
<td><p>FSCB</p></td>
+
<td>
<td><p>Menu, screen, and image information</p></td>
+
<p>GREATER THAN</p></td>
 +
<td>
 +
<p>20</p></td>
 
</tr>
 
</tr>
 
   
 
   
 
<tr>
 
<tr>
<td><p>FTBL</p></td>
+
<td>
<td><p>File groups</p></td>
+
<p>IDENTIFY</p></td>
 +
<td>
 +
<p>16</p></td>
 
</tr>
 
</tr>
 
   
 
   
 
<tr>
 
<tr>
<td><p>GTBL</p></td>
+
<td>
<td><p>Global variables</p></td>
+
<p>IF</p></td>
 +
<td>
 +
<p>32</p></td>
 
</tr>
 
</tr>
 
   
 
   
 
<tr>
 
<tr>
<td><p>ITBL</p></td>
+
<td>
<td><p>Dummy string and $READ responses</p></td>
+
<p>IF (with operator)</p></td>
 +
<td>
 +
<p>32 + 16</p></td>
 
</tr>
 
</tr>
 
   
 
   
 
<tr>
 
<tr>
<td><p>NTBL</p></td>
+
<td>
<td><p>Statement labels, list names, and variables</p></td>
+
<p>Index loop</p></td>
 +
<td>
 +
<p>40 + expression evaluation + body of the loop</p></td>
 
</tr>
 
</tr>
 
   
 
   
 
<tr>
 
<tr>
<td><p>QTBL</p></td>
+
<td>
<td><p>Statements in internal form (quadruples)</p></td>
+
<p>IN RANGE FROM and TO, BETWEEN</p></td>
 +
<td>
 +
<p>28</p></td>
 
</tr>
 
</tr>
 
   
 
   
 
<tr>
 
<tr>
<td><p>RTBL</p></td>
+
<td>
<td><p>User privileges, class, and field level security information</p></td>
+
<p>INSERT</p></td>
 +
<td>
 +
<p>24</p></td>
 
</tr>
 
</tr>
 
   
 
   
 
<tr>
 
<tr>
<td><p>STBL</p></td>
+
<td>
<td><p>Character strings</p></td>
+
<p>MODIFY</p></td>
 +
<td>
 +
<p>16</p></td>
 
</tr>
 
</tr>
 
   
 
   
 
<tr>
 
<tr>
<td><p>TTBL</p></td>
+
<td>
<td><p>Temporary work pages</p></td>
+
<p>NOTE</p></td>
 +
<td>
 +
<p>20</p></td>
 
</tr>
 
</tr>
 
   
 
   
 
<tr>
 
<tr>
<td><p>VTBL</p></td>
+
<td>
<td><p>Compiler variables</p></td>
+
<p>ON</p></td>
 +
<td>
 +
<p>16 + included statements</p></td>
 
</tr>
 
</tr>
 
   
 
   
 
<tr>
 
<tr>
<td><p>XTBL</p></td>
+
<td>
<td><p>Procedure security</p></td>
+
<p>OPEN</p></td>
 +
<td>
 +
<p>20</p></td>
 
</tr>
 
</tr>
</table>
 
 
   
 
   
===Full-screen buffer table (FSCB)===
+
<tr>
 +
<td>
 +
<p>OPEN PROCESS</p></td>
 +
<td>
 +
<p>20</p></td>
 +
</tr>
 
   
 
   
<p>The full-screen buffer table (FSCB) stores menu, screen, and image definitions, in addition to the values of screen variables and image data blocks. FSCB space is reused by each logical menu definition, logical  screen definition, or block definition.</p>
+
<tr>
 +
<td>
 +
<p>OR</p></td>
 +
<td>
 +
<p>16</p></td>
 +
</tr>
 
   
 
   
<p>The FSCB must be large enough to hold the largest screen, image, or menu definition. The following space is required:</p>
+
<tr>
 +
<td>
 +
<p>PAUSE</p></td>
 +
<td>
 +
<p>16</p></td>
 +
</tr>
 
   
 
   
<ul>
+
<tr>
<li> 144 bytes of fixed overhead for every menu, including the menu title</li>
+
<td>
 +
<p>POSITION</p></td>
 +
<td>
 +
<p>20</p></td>
 +
</tr>
 
   
 
   
<li> 144 bytes for each menu prompt</li>
+
<tr>
 +
<td>
 +
<p>PREPARE IMAGE</p></td>
 +
<td>
 +
<p>8</p></td>
 +
</tr>
 
   
 
   
<li> 432 bytes of fixed overhead for the first panel of every screen:</li>
+
<tr>
 +
<td>
 +
<p>PREPARE MENU</p></td>
 +
<td>
 +
<p>8</p></td>
 +
</tr>
 
   
 
   
<li> 144 bytes for each subsequent panel, including the screen title</li>
+
<tr>
 +
<td>
 +
<p>PREPARE SCREEN</p></td>
 +
<td>
 +
<p>8</p></td>
 +
</tr>
 
   
 
   
<li> 32 bytes for each screen prompt and input item</li>
+
<tr>
 +
<td>
 +
<p>PRINT</p></td>
 +
<td>
 +
<p>16 for each term</p></td>
 +
</tr>
 
   
 
   
<li> 32 bytes for every screen line containing at least one input item</li>
+
<tr>
 +
<td>
 +
<p>PRINT (a field)</p></td>
 +
<td>
 +
<p>16 + 20</p></td>
 +
</tr>
 
   
 
   
<li> 80 bytes for each defined screen line, including skipped lines</li>
+
<tr>
 +
<td>
 +
<p>PRINT MENU</p></td>
 +
<td>
 +
<p>16</p></td>
 +
</tr>
 
   
 
   
<li> Additional space for automatic validation, including:</li>
+
<tr>
 +
<td>
 +
<p>PRINT SCREEN</p></td>
 +
<td>
 +
<p>16</p></td>
 +
</tr>
 
   
 
   
<li> 2 or 4 bytes for each automatic validation option</li>
+
<tr>
 +
<td>
 +
<p>READ IMAGE</p></td>
 +
<td>
 +
<p>16</p></td>
 +
</tr>
 
   
 
   
<li> 256 bytes for the VERIFY command when a particular character set is used in a compiled screen for the first time
+
<tr>
</li>
+
<td>
</ul>
+
<p>READ MENU</p></td>
 +
<td>
 +
<p>20</p></td>
 +
</tr>
 
   
 
   
<p>Additional occurrences of the same character set do not add extra space. ONEOF and character RANGE store each character string plus one byte for each string's length.</p>
+
<tr>
 +
<td>
 +
<p>READ SCREEN</p></td>
 +
<td>
 +
<p>20</p></td>
 +
</tr>
 
   
 
   
<ul>
+
<tr>
<li> 8 bytes for each number in a NUMERIC RANGE statement (16 bytes for each range pair)</li>
+
<td>
 +
<p>RECEIVE</p></td>
 +
<td>
 +
<p>16</p></td>
 +
</tr>
 
   
 
   
<li> Space for every block used in image definition
+
<tr>
</li>
+
<td>
</ul>
+
<p>RELEASE RECORD</p></td>
 +
<td>
 +
<p>20</p></td>
 +
</tr>
 
   
 
   
<p>The amount of required space is computed as the sum of the specific [[SOUL]] statements, clauses, and items. For a complete list of these values, see [[Full-screen feature]]. </p>
+
<tr>
 +
<td>
 +
<p>RELEASE POSITION</p></td>
 +
<td>
 +
<p>8</p></td>
 +
</tr>
 
   
 
   
===File group table (FTBL)===
+
<tr>
 +
<td>
 +
<p>REPEAT</p></td>
 +
<td>
 +
<p>16 + evaluation of WHILE clause</p></td>
 +
</tr>
 
   
 
   
<p>Data structures particular to file groups are stored in FTBL. FTBL entries are:</p>
+
<tr>
 +
<td>
 +
<p>REREAD SCREEN</p></td>
 +
<td>
 +
<p>20</p></td>
 +
</tr>
 
   
 
   
<ul>
+
<tr>
<li> Sixty-two-byte fixed size entry plus six bytes for each file in the group definition.
+
<td>
 +
<p>RETRY</p></td>
 +
<td>
 +
<p>16</p></td>
 +
</tr>
 
   
 
   
<p>This entry is allocated each time a group is opened (explicitly by the OPEN command or implicitly for an ad hoc group) and is released when the group is closed.</p></li>
+
<tr>
 +
<td>
 +
<p>RETURN</p></td>
 +
<td>
 +
<p>16</p></td>
 +
</tr>
 
   
 
   
<li> Variable entry, consisting of nine fixed-bytes plus a number of bytes equal to the length of the field name plus 11 bytes per file in the group
+
<tr>
<p>
+
<td>
This entry is created for collecting field-name codes and properties during a User Language request. An entry is allocated each time a new field name is encountered in the request. The field entries are deleted at  every END statement (including END MORE). </p></li>
+
<p>SEND</p></td>
</ul>
+
<td>
 +
<p>16</p></td>
 +
</tr>
 
   
 
   
<p>When the Inverted File Access Method (IFAM) is used: </p>
+
<tr>
 +
<td>
 +
<p>SIGNAL PROCESS</p></td>
 +
<td>
 +
<p>12</p></td>
 +
</tr>
 
   
 
   
<ul>
+
<tr>
<li> Host Language threads use FTBL under the same circumstances as User Language.</li>
+
<td>
 +
<p>STOP (automatically generated)</p></td>
 +
<td>
 +
<p>16</p></td>
 +
</tr>
 
   
 
   
<li> Field entries are not deleted until the group is closed or until IFFNSH is called. </li>
+
<tr>
 +
<td>
 +
<p>STORE RECORD (with each field)</p></td>
 +
<td>
 +
<p>16 + 16</p></td>
 +
</tr>
 
   
 
   
<li> Increase the total FTBL requirement by NGROUP times four bytes.
+
<tr>
</li>
+
<td>
</ul>
+
<p>TAB</p></td>
 +
<td>
 +
<p>4</p></td>
 +
</tr>
 
   
 
   
<p>For Parallel Query Option/204 server nodes, the required size of FTBL increases by eleven bytes times the total number of group members for temporary scattered groups opened at the  client and containing a member on the server node.</p>
+
<tr>
 +
<td>
 +
<p>TAG</p></td>
 +
<td>
 +
<p>16</p></td>
 +
</tr>
 
   
 
   
<p>For information on using FTBL in 64-bit storage, see [[FTBL and above the bar storage]].</p> <!-- JAl can't find this xref -->
+
<tr>
 +
<td>
 +
<p>THEN</p></td>
 +
<td>
 +
<p>16 + body of the clause</p></td>
 +
</tr>
 
   
 
   
===Understanding the global variable table (GTBL)===
+
<tr>
 +
<td>
 +
<p>TRANSFER</p></td>
 +
<td>
 +
<p>16</p></td>
 +
</tr>
 
   
 
   
<p>GTBL contains information about:</p>
+
<tr>
 +
<td>
 +
<p>WITH</p></td>
 +
<td>
 +
<p>0</p></td>
 +
</tr>
 
   
 
   
<ul>
+
<tr>
<li> Global variables </li>
+
<td>
 +
<p>WRITE IMAGE</p></td>
 +
<td>
 +
<p>12</p></td>
 +
</tr>
 +
</table>
 
   
 
   
<li> Global images, screens, and menus</li>
+
==User, field, group security table (RTBL)==
</ul>
+
<p>
 +
RTBL contains a user's privileges, class, field-level security (FLS) levels for each open file, and classes for open, permanent groups.</p>
 +
 +
<p>The size of RTBL is calculated from the formula:</p>
 +
 +
<p class="code">(((NGROUPS + 11) * (NFILES + 1)) + (NRMTFILE + 1))dwr
 +
</p>
 +
<p>
 +
For Parallel Query Option/204 client nodes, the required size of RTBL increases by <code>(NRMTFILE=1)</code> bytes.</p>
 
   
 
   
<p>GTBL entries are created by the $INCRG, $GETG, and $SETG functions. When a global variable is redefined, its old entry is deleted from GTBL and a new entry is added. </p>
+
===Character string table (STBL)===
 +
<p>
 +
STBL stores all character strings in counted form, with a 1-byte length preceding the string itself. The following considerations apply to space usage:</p>
 
   
 
   
<p>In addition, a 32-byte trailer stores information about offsets. </p>
+
<ul>
 +
<li> Space used to store intermediate results during an arithmetic expression evaluation is freed when the evaluation is completed.</li>
 
   
 
   
====Clearing GTBL entries====
+
<li>Space used by <var>FOR EACH OCCURRENCE</var>, <var>FOR EACH RECORD</var>, and <var>FOR EACH VALUE</var> loops is reused until the end of the loop.</li>
 
   
 
   
<p>The CLEARGO command deletes all images, screens, and menus. You can also use the CLEAR GLOBALS statement to delete selected types of GTBL entries. For details, see [[Global features]].</p>
+
<li>The last value of a <var>Note</var> statement remains in STBL.</li>
 
   
 
   
====Space allocation====
+
<li><var>FIXED</var> or <var>FLOAT</var> %variable array uses eight bytes for each element. </li>
 +
</ul>
 
   
 
   
<p>The space allocation for a global variable includes:</p>
+
<p>When the %variable is reassigned, the STBL space is reused.</p>
 
   
 
   
 
<ul>
 
<ul>
<li> 4 bytes indicating the length of GTBL</li>
+
<li>The FIELD SAVE option requires 10 bytes plus the maximum length of the string plus one byte for each element.</li>
 +
</ul>
 
   
 
   
<li> 1 byte for the length of the variable name</li>
+
<p>NO FIELD SAVE does not reserve the extra 10 bytes and results in significant saving when using a multidimensional array.</p>
 
   
 
   
<li>  Variable name</li>
+
<ul>
+
<li>MORE releases all but the space required by %variables and arrays. </li>
<li> 1 byte for the length of the current name</li>
 
 
   
 
   
<li> Current value  </li>
+
<li>If a user is using the pattern matcher in an IF statement with an IMAGE or SCREEN ITEM as the pattern and an IMAGE or SCREEN ITEM as the comparison string, then the value of the pattern is stored in STBL. The space is freed after each comparison, so the maximum increase is equal to the size of the largest pattern in a request that meets the above criteria.</li>
 
</ul>
 
</ul>
 
   
 
   
<p>
+
====When the Inverted File Access Method (IFAM) is used====
Global images, screens, and menus require space for a 20-byte header in addition to the size of the object.</p>
+
<ul>
 +
<li><var>IFDVAL</var> and <var>IFFILE</var> store the value string from the input parameter in STBL. </li>
 
   
 
   
<p>
+
<li>Strings enclosed in quotation marks or values specified for <var>IFFIND</var> that are stored in STBL are the same types as those stored in STBL by SOUL.</li>
When allocating GTBL space, always remember to add 32 bytes for the trailer.</p>
 
 
   
 
   
<p>
+
<li>EDIT form of <var>IFPUT</var> uses STBL for each value. Space from previous values is reused. </li>
The minimum length of GTBL is 40 bytes (X'28').</p>
 
 
   
 
   
====Improving global variable processing====
+
<li><var>FLOD</var> stores translation table values and <var>CASE</var> statement comparison values in STBL.
 +
</li>
 +
</ul>
 
   
 
   
 +
====Parallel Query Option/204 STBL requirements====
 
<p>
 
<p>
You can improve global variable processing by setting the <var>[[FASTGLOB parameter|FASTGLOB]]</var>, <var>[[GLBLPCT parameter|GLBLPCT]]</var>, and <var>[[GTBLHASH parameter|GTBLHASH]]</var> parameters. See [[Global features]] for a discussion of how these parameters affect performance. </p>
+
STBL requires an increase for Parallel Query Option/204 $functions used in remote file or scattered context and for SOUL pattern matching processes</p>
 
   
 
   
===Dummy string and $READ table (ITBL)===
+
<ul>
 +
<li>Using one of the following $functions in remote context requires 12 additional bytes in STBL:
 
   
 
   
<p>ITBL holds dummy string and $READ responses that are entered as arguments to an INCLUDE statement or command.</p>
+
<p><var>$Curfile</var></p>
 
   
 
   
<p>The space allocation for an ITBL entry includes:</p>
+
<p><var>$RlcFile</var></p>
 
   
 
   
<ul>
+
<p><var>$Update</var></p>
<li> Argument strings, including delimiters, which are saved as they are entered</li>
 
 
   
 
   
<li> 4 bytes of overhead for each saved string
+
<p><var>$UpdFile</var></p></li>
</li>
+
 
 +
<li>If you are using the pattern matcher in any SOUL statement, the full size of the pattern is used and stored in STBL. The space is freed after each statement block using the pattern  matcher, for example, <var>FIND</var> or <var>FOR</var>.</li>
 
</ul>
 
</ul>
 
   
 
   
<p>Space taken by a string is released when the included procedure is executed.</p>
+
===Temporary work page list table (TTBL)===  
+
<p>
===Labels, names, and variables table (NTBL)===
+
TTBL entries keep track of scratch file (CCATEMP) pages. The entries are four bytes each and used by the Editor and <var>FIND</var> (or <var>IFFIND</var>) evaluator routines.</p>
 
<p>NTBL holds labels, names, and variables. Each entry is allocated 12 bytes. NTBL has two entries for each first occurrence of a COMMON declaration.</p>
 
 
<p>NTBL has one entry for each of the following elements: </p>
 
 
   
 
   
 
<ul>
 
<ul>
<li> Statement label</li>
+
<li>The Editor uses scratch pages to make a private copy of the procedure being edited.</li>
 
   
 
   
<li> List name</li>
+
<li><var>FIND</var> uses scratch pages as work space for evaluating Boolean expressions.</li>
 +
</ul>
 
   
 
   
<li> %variable</li>
+
<p>The number of TTBL entries required by <var>FIND</var> depends on the complexity of the Boolean expression. Entries are released at the end of the <var>FIND</var> statement evaluation. </p>
 
   
 
   
<li> Image, menu, and screen variable</li>
+
===Compiler variable table (VTBL)===
 +
<p>
 +
VTBL stores values of simple variable types and refers to the String Table (STBL) in cases of more complex variables. The variables are local (%variables), internal, screen, and image variables. </p>
 
   
 
   
<li> Partner process opened by a request</li>
+
<p>
 +
Many SOUL statements and some constructs cause one or more compiler variables to be allocated in VTBL.</p>
 
   
 
   
<li> Additional COMMON declaration</li>
+
<p>Entries in VTBL vary in size. The "Sample VTBL entries" table shows typical values. For more information, refer to [[Large request considerations#VTBL (compiler variable table)|VTBL (compiler variable table)]].</p>
 
   
 
   
<li> Unlabeled FIND</li>
+
<table>
 +
<caption>Sample VTBL entries</caption>
 +
<tr class="head">
 +
<th>
 +
<p>SOUL statement  </p></th>
 +
<th>
 +
<p>VTBL entry size (bytes)</p></th>
 +
</tr>
 
   
 
   
<li> FOR EACH VALUE statement</li>
+
<tr>
 +
<td>
 +
<p>% variable:</p></td>
 +
<td>
 +
<p>&nbsp;</p></td>
 +
</tr>
 
   
 
   
<li> FOR statement with the IN ORDER clause</li>
+
<tr>
 +
<td>
 +
<p>FIXED</p></td>
 +
<td>
 +
<p>16</p></td>
 +
</tr>
 
   
 
   
<li> Sequential or VSAM file opened simultaneously</li>
+
<tr>
</ul>
+
<td>
 +
<p>FLOAT</p></td>
 +
<td>
 +
<p>12</p></td>
 +
</tr>
 
   
 
   
<p>Most NTBL entries are preserved by the MORE command except for the unlabeled FIND and secondary FOR entries, which are deleted.</p>
+
<tr>
 +
<td>
 +
<p>STRING</p></td>
 +
<td>
 +
<p>24</p></td>
 +
</tr>
 
   
 
   
<p>A host language thread requires NTBL entries for list names, compilation names, and variables. </p>
+
<tr>
 +
<td>
 +
<p>array</p></td>
 +
<td>
 +
<p>20</p></td>
 +
</tr>
 
   
 
   
<p>FLOD uses NTBL entries for tags and index registers. The size of NTBL determines the highest tag or index that can be specified. In this case, NTBL must be at least 12 bytes multiplied by the highest tag or  index size desired. </p>
+
<tr>
 +
<td>
 +
<p>array element reference</p></td>
 +
<td>
 +
<p>12</p></td>
 +
</tr>
 
   
 
   
<p>You need not allow extra space for runtime NTBL storage used during request evaluation of an OPEN DATASET, OPEN EXTERNAL, or OPEN TERMINAL statement. Use the compiler high-water mark to set  LNTBL. </p>
+
<tr>
 +
<td>
 +
<p>CALL</p></td>
 +
<td>
 +
<p>4 + (4 * arguments)</p></td>
 +
</tr>
 
   
 
   
===Internal statement table (QTBL)===
+
<tr>
 +
<td>
 +
<p>CALL statement evaluation</p></td>
 +
<td>
 +
<p>28</p></td>
 +
</tr>
 
   
 
   
<p>QTBL holds internal <var class="product">Model&nbsp;204</var> instructions that result from compilation of each internal statement. After compilation, the entries in QTBL drive the evaluator. QTBL is emptied by END and END MORE statements.</p>
+
<tr>
 +
<td>
 +
<p>COUNT</p></td>
 +
<td>
 +
<p>8</p></td>
 +
</tr>
 
   
 
   
<p>The Editor formats all of QTBL into 16-byte entries, which provide a map of text being edited. The number of entries used depends on the number and position of insertions and deletions, not on the amount of text.</p>
+
<tr>
+
<td>
<p>Quadruple (QTBL) entries generated by SOUL statements vary in number and size. The "Sample QTBL entries" table, below, shows typical values for each entry. For more QTBL information, see [[Large request considerations#QTBL (internal statement table)|QTBL (internal statement table)]]. </p>
+
<p>FIND (basic entry, single file)</p></td>
 +
<td>
 +
<p>8</p></td>
 +
</tr>
 
   
 
   
<p>You can reduce server I/O by allowing users executing shared precompiled procedures to use a shared copy of QTBL. </p>
+
<tr>
 +
<td>
 +
<p>workspace</p></td>
 +
<td>
 +
<p>20 + 20 + 28</p></td>
 +
</tr>
 
   
 
   
===QTBL and IFAM processing===
+
<tr>
 +
<td>
 +
<p>fieldname = value pair</p></td>
 +
<td>
 +
<p>20 or more</p></td>
 +
</tr>
 
   
 
   
<p>When using the Inverted File Access Method (IFAM):</p>
+
<tr>
 +
<td>
 +
<p>retrieval</p></td>
 +
<td>
 +
<p>28</p></td>
 +
</tr>
 
   
 
   
<ul>
+
<tr>
<li> IFFIND, IFCOUNT, and list manipulations build quadruples so that the SOUL evaluator routines can be used.</li>
+
<td>
 +
<p>Ordered Index retrieval</p></td>
 +
<td>
 +
<p>4 + 4 per segment</p></td>
 +
</tr>
 
   
 
   
<li> IFGET, IFMORE, and IFPUT build field name lists in QTBL.</li>
+
<tr>
 +
<td>
 +
<p>FIND (basic entry, group)</p></td>
 +
<td>
 +
<p>8 + (8 * files)</p></td>
 +
</tr>
 
   
 
   
<li> Other calls are evaluated directly.
+
<tr>
</li>
+
<td>
</ul>
+
<p>FOR EACH RECORD (no IN ORDER clause)</p></td>
 +
<td>
 +
<p>16</p></td>
 +
</tr>
 
   
 
   
<p>IFAM's use of QTBL and the effect of the compiled IFAM feature are discussed in detail in the <var class="book">Rocket Model&nbsp;204 Host Language Interface Reference Manual</var>. </p>
+
<tr>
 +
<td>
 +
<p>FOR EACH VALUE (with FROM, TO, LIKE, ORDERED</p></td>
 +
<td>
 +
<p>48</p></td>
 +
</tr>
 
   
 
   
===QTBL and FLOD processing===
+
<tr>
<p>
+
<td>
FLOD builds its own quadruples (flodruples) in QTBL. Flodruple sizes vary, but most are 20 bytes or less. </p>
+
<p>FOR EACH RECORD IN ORDER BY (with ORDERED field)</p></td>
+
<td>
<p>Major exceptions are:</p>
+
<p>48</p></td>
 
<ul>
 
<li>Read-and-load-field flodruple, which expands four bytes for each entry in a translation table</li>
 
 
<li>CASE statement, which requires eight bytes for each comparison string
 
</li>
 
</ul>
 
 
===Sample QTBL entries===
 
<p>"Sample QTBL entries" shows typical QTBL entry sizes for various SOUL statements and program structures: </p>
 
 
<table>
 
<caption>Sample QTBL entries</caption>
 
<tr class="head">
 
<th>
 
<p>SOUL statement</p>
 
</th>
 
<th>
 
<p>QTBL entry size</p>
 
</th>
 
 
</tr>
 
</tr>
 
   
 
   
 
<tr>
 
<tr>
 
<td>
 
<td>
<p>$functions</p>
+
<p>FOR EACH VALUE (with ORDERED field)</p></td>
</td>
 
 
<td>
 
<td>
<p>16 + 3 per argument</p>
+
<p>40</p></td>
</td>
 
 
</tr>
 
</tr>
 
   
 
   
 
<tr>
 
<tr>
 
<td>
 
<td>
<p>%variable, subscripted (reference to)</p>
+
<p>Function (SOUL)</p></td>
</td>
 
 
<td>
 
<td>
<p>16 + expression evaluation</p>
+
<p>4 + (4 * arguments)</p></td>
</td>
 
 
</tr>
 
</tr>
 
   
 
   
 
<tr>
 
<tr>
 
<td>
 
<td>
<p>ADD</p>
+
<p>Lists:</p></td>
</td>
 
 
<td>
 
<td>
<p>20</p>
+
<p>&nbsp;</p></td>
</td>
 
 
</tr>
 
</tr>
 
   
 
   
 
<tr>
 
<tr>
 
<td>
 
<td>
<p>AFTER</p>
+
<p>single files</p></td>
</td>
 
 
<td>
 
<td>
<p>20</p>
+
<p>8</p></td>
</td>
 
 
</tr>
 
</tr>
 
   
 
   
 
<tr>
 
<tr>
 
<td>
 
<td>
<p>AND (except where AND is part of BETWEEN)</p>
+
<p>groups</p></td>
</td>
 
 
<td>
 
<td>
<p>16</p>
+
<p>8 + (8 * files)</p></td>
</td>
 
 
</tr>
 
</tr>
 
   
 
   
 
<tr>
 
<tr>
 
<td>
 
<td>
<p>Conversion between a string and a number</p>
+
<p>Menu definition</p></td>
</td>
 
 
<td>
 
<td>
<p>16</p>
+
<p>48</p>
 
  </td>
 
  </td>
 
</tr>
 
</tr>
Line 2,628: Line 3,200:
 
<tr>
 
<tr>
 
<td>
 
<td>
<p>CALL</p>
+
<p>Numeric expression</p></td>
</td>
 
 
<td>
 
<td>
<p>16</p>
+
<p>16</p></td>
</td>
 
 
</tr>
 
</tr>
 
   
 
   
 
<tr>
 
<tr>
 
<td>
 
<td>
<p>CHANGE</p>
+
<p>ON</p></td>
</td>
 
 
<td>
 
<td>
<p>44</p>
+
<p>28</p></td>
</td>
 
 
</tr>
 
</tr>
 
   
 
   
 
<tr>
 
<tr>
 
<td>
 
<td>
<p>CLEAR LIST</p>
+
<p>Related image set</p></td>
</td>
 
 
<td>
 
<td>
<p>20</p>
+
<p>12 + 4 for every 256 items</p></td>
</td>
 
 
</tr>
 
</tr>
 
   
 
   
 
<tr>
 
<tr>
 
<td>
 
<td>
<p>CLEAR ON</p>
+
<p>Screen definition</p></td>
</td>
 
 
<td>
 
<td>
<p>16</p>
+
<p>68 + 4 for each panel</p></td>
</td>
 
 
</tr>
 
</tr>
 
   
 
   
 
<tr>
 
<tr>
 
<td>
 
<td>
<p>CLEAR TAG</p>
+
<p>Screen entry (one panel)</p></td>
</td>
 
 
<td>
 
<td>
<p>16</p>
+
<p>72</p></td>
</td>
 
 
</tr>
 
</tr>
 
   
 
   
 
<tr>
 
<tr>
 
<td>
 
<td>
<p>CLOSE</p>
+
<p>SORT</p></td>
</td>
 
 
<td>
 
<td>
<p>16</p>
+
<p>&nbsp;</p></td>
</td>
 
 
</tr>
 
</tr>
 
   
 
   
 
<tr>
 
<tr>
 
<td>
 
<td>
<p>CLOSE PROCESS</p>
+
<p>each referenced field</p></td>
</td>
 
 
<td>
 
<td>
<p>16</p>
+
<p>20</p></td>
</td>
 
 
</tr>
 
</tr>
 
   
 
   
 
<tr>
 
<tr>
 
<td>
 
<td>
<p>COMMIT</p>
+
<p>each sort key</p></td>
</td>
 
 
<td>
 
<td>
<p>4</p>
+
<p>32</p></td>
</td>
 
 
</tr>
 
</tr>
 
   
 
   
 
<tr>
 
<tr>
 
<td>
 
<td>
<p>COMMIT RELEASE</p>
+
<p>String expression</p></td>
</td>
 
 
<td>
 
<td>
<p>20</p>
+
<p>8</p></td>
</td>
 
 
</tr>
 
</tr>
 
   
 
   
 
<tr>
 
<tr>
 
<td>
 
<td>
<p>COUNT RECORDS (with a group)</p>
+
<p>Subroutine declaration</p></td>
</td>
 
 
<td>
 
<td>
<p>52 + 20</p>
+
<p>16 + parameters </p></td>
</td>
 
 
</tr>
 
</tr>
 +
</table>
 
   
 
   
<tr>
+
====Effect of the MORE parameter on VTBL====
<td>
+
<p>
<p>DELETE</p>
+
The MORE parameter deletes all VTBL entries except %variables, list entries, images, menus, screens, labeled SORT and sort key entries, labeled FIND entries, and labeled COUNT entries.</p>
</td>
 
<td>
 
<p>24</p>
 
</td>
 
</tr>
 
 
   
 
   
<tr>
+
====IFAM and FLOD considerations====
<td>
+
<p>
<p>DELETE RECORD</p>
+
The following considerations apply to VTBL: </p>
</td>
 
<td>
 
<p>16</p>
 
</td>
 
</tr>
 
 
<tr>
 
<td>
 
<p>ELSE</p>
 
</td>
 
<td>
 
<p>16 + body of the clause</p>
 
</td>
 
</tr>
 
 
<tr>
 
<td>
 
<p>ELSEIF</p>
 
</td>
 
<td>
 
<p>16 + body of the clause END</p>
 
</td>
 
</tr>
 
 
<tr>
 
<td>
 
<p>END</p>
 
</td>
 
<td>
 
<p>4</p>
 
</td>
 
</tr>
 
 
<tr>
 
<td>
 
<p>Function call</p>
 
</td>
 
<td>
 
<p>16 + argument evaluation</p>
 
</td>
 
</tr>
 
 
<tr>
 
<td>
 
<p>FIND (with at least one direct condition)</p>
 
</td>
 
<td>
 
<p>64 + 16</p>
 
</td>
 
</tr>
 
 
<tr>
 
<td>
 
<p>FIND (with inverted condition)</p>
 
</td>
 
<td>
 
<p>64 + 36</p>
 
</td>
 
</tr>
 
 
<tr>
 
<td>
 
<p>FIND ALL RECORDS (no qualification)</p>
 
</td>
 
<td>
 
<p>64</p>
 
</td>
 
</tr>
 
 
<tr>
 
<td>
 
<p>FIND ALL RECORDS (with record
 
  security and group)</p>
 
</td>
 
<td>
 
<p>64 + 52 + 20</p>
 
</td>
 
</tr>
 
 
<tr>
 
<td>
 
<p>FIND ALL RECORDS (with record
 
  security)</p>
 
</td>
 
<td>
 
<p>64 + 52</p>
 
</td>
 
</tr>
 
 
<tr>
 
<td>
 
<p>FIND ALL VALUES (FRV field)</p>
 
</td>
 
<td>
 
<p>74</p>
 
</td>
 
</tr>
 
 
<tr>
 
<td>
 
<p>FIND ALL VALUES (ORDERED field)</p>
 
</td>
 
<td>
 
<p>32</p>
 
</td>
 
</tr>
 
 
<tr>
 
<td>
 
<p>FOR EACH RECORD</p>
 
</td>
 
<td>
 
<p>24 + body of the loop</p>
 
</td>
 
</tr>
 
 
<tr>
 
<td>
 
<p>FOR EACH VALUE OF (with IN ORDER, a group)</p>
 
</td>
 
<td>
 
<p>88 + body of the loop + 68 + 24</p>
 
</td>
 
</tr>
 
 
<tr>
 
<td>
 
<p>GREATER THAN</p>
 
</td>
 
<td>
 
<p>20</p>
 
</td>
 
</tr>
 
 
<tr>
 
<td>
 
<p>IDENTIFY</p>
 
</td>
 
<td>
 
<p>16</p>
 
</td>
 
</tr>
 
 
<tr>
 
<td>
 
<p>IF</p>
 
</td>
 
<td>
 
<p>32</p>
 
</td>
 
</tr>
 
 
<tr>
 
<td>
 
<p>IF (with operator)</p>
 
</td>
 
<td>
 
<p>32 + 16</p>
 
</td>
 
</tr>
 
 
<tr>
 
<td>
 
<p>Index loop</p>
 
</td>
 
<td>
 
<p>40 + expression evaluation + body of the loop</p>
 
</td>
 
</tr>
 
 
<tr>
 
<td>
 
<p>IN RANGE FROM and TO, BETWEEN</p>
 
</td>
 
<td>
 
<p>28</p>
 
</td>
 
</tr>
 
 
<tr>
 
<td>
 
<p>INSERT</p>
 
</td>
 
<td>
 
<p>24</p>
 
</td>
 
</tr>
 
 
<tr>
 
<td>
 
<p>MODIFY</p>
 
</td>
 
<td>
 
<p>16</p>
 
</td>
 
</tr>
 
 
<tr>
 
<td>
 
<p>NOTE</p>
 
</td>
 
<td>
 
<p>20</p>
 
</td>
 
</tr>
 
 
<tr>
 
<td>
 
<p>ON</p>
 
</td>
 
<td>
 
<p>16 + included statements</p>
 
</td>
 
</tr>
 
 
<tr>
 
<td>
 
<p>OPEN</p>
 
</td>
 
<td>
 
<p>20</p>
 
</td>
 
</tr>
 
 
<tr>
 
<td>
 
<p>OPEN PROCESS</p>
 
</td>
 
<td>
 
<p>20</p>
 
</td>
 
</tr>
 
 
<tr>
 
<td>
 
<p>OR</p>
 
</td>
 
<td>
 
<p>16</p>
 
</td>
 
</tr>
 
 
<tr>
 
<td>
 
<p>PAUSE</p>
 
</td>
 
<td>
 
<p>16</p>
 
</td>
 
</tr>
 
 
<tr>
 
<td>
 
<p>POSITION</p>
 
</td>
 
<td>
 
<p>20</p>
 
</td>
 
</tr>
 
 
<tr>
 
<td>
 
<p>PREPARE IMAGE</p>
 
</td>
 
<td>
 
<p>8</p>
 
</td>
 
</tr>
 
 
<tr>
 
<td>
 
<p>PREPARE MENU</p>
 
</td>
 
<td>
 
<p>8</p>
 
</td>
 
</tr>
 
 
<tr>
 
<td>
 
<p>PREPARE SCREEN</p>
 
</td>
 
<td>
 
<p>8</p>
 
</td>
 
</tr>
 
 
<tr>
 
<td>
 
<p>PRINT</p>
 
</td>
 
<td>
 
<p>16 for each term</p>
 
</td>
 
</tr>
 
 
<tr>
 
<td>
 
<p>PRINT (a field)</p>
 
</td>
 
<td>
 
<p>16 + 20</p>
 
</td>
 
</tr>
 
 
<tr>
 
<td>
 
<p>PRINT MENU</p>
 
</td>
 
<td>
 
<p>16</p>
 
</td>
 
</tr>
 
 
<tr>
 
<td>
 
<p>PRINT SCREEN</p>
 
</td>
 
<td>
 
<p>16</p>
 
</td>
 
</tr>
 
 
<tr>
 
<td>
 
<p>READ IMAGE</p>
 
</td>
 
<td>
 
<p>16</p>
 
</td>
 
</tr>
 
 
<tr>
 
<td>
 
<p>READ MENU</p>
 
</td>
 
<td>
 
<p>20</p>
 
</td>
 
</tr>
 
 
<tr>
 
<td>
 
<p>READ SCREEN</p>
 
</td>
 
<td>
 
<p>20</p>
 
</td>
 
</tr>
 
 
<tr>
 
<td>
 
<p>RECEIVE</p>
 
</td>
 
<td>
 
<p>16</p>
 
</td>
 
</tr>
 
 
<tr>
 
<td>
 
<p>RELEASE RECORD</p>
 
</td>
 
<td>
 
<p>20</p>
 
</td>
 
</tr>
 
 
<tr>
 
<td>
 
<p>RELEASE POSITION</p>
 
</td>
 
<td>
 
<p>8</p>
 
</td>
 
</tr>
 
 
<tr>
 
<td>
 
<p>REPEAT</p>
 
</td>
 
<td>
 
<p>16 + evaluation of WHILE clause</p>
 
</td>
 
</tr>
 
 
<tr>
 
<td>
 
<p>REREAD SCREEN</p>
 
</td>
 
<td>
 
<p>20</p>
 
</td>
 
</tr>
 
 
<tr>
 
<td>
 
<p>RETRY</p>
 
</td>
 
<td>
 
<p>16</p>
 
</td>
 
</tr>
 
 
<tr>
 
<td>
 
<p>RETURN</p>
 
</td>
 
<td>
 
<p>16</p>
 
</td>
 
</tr>
 
 
<tr>
 
<td>
 
<p>SEND</p>
 
</td>
 
<td>
 
<p>16</p>
 
</td>
 
</tr>
 
 
<tr>
 
<td>
 
<p>SIGNAL PROCESS</p>
 
</td>
 
<td>
 
<p>12</p>
 
</td>
 
</tr>
 
 
<tr>
 
<td>
 
<p>STOP (automatically generated)</p>
 
</td>
 
<td>
 
<p>16</p>
 
</td>
 
</tr>
 
 
<tr>
 
<td>
 
<p>STORE RECORD (with each field)</p>
 
</td>
 
<td>
 
<p>16 + 16</p>
 
</td>
 
</tr>
 
 
<tr>
 
<td>
 
<p>TAB</p>
 
</td>
 
<td>
 
<p>4</p>
 
</td>
 
</tr>
 
 
<tr>
 
<td>
 
<p>TAG</p>
 
</td>
 
<td>
 
<p>16</p>
 
</td>
 
</tr>
 
 
<tr>
 
<td>
 
<p>THEN</p>
 
</td>
 
<td>
 
<p>16 + body of the clause</p>
 
</td>
 
</tr>
 
 
<tr>
 
<td>
 
<p>TRANSFER</p>
 
</td>
 
<td>
 
<p>16</p>
 
</td>
 
</tr>
 
 
<tr>
 
<td>
 
<p>WITH</p>
 
</td>
 
<td>
 
<p>0</p>
 
</td>
 
</tr>
 
 
<tr>
 
<td>
 
<p>WRITE IMAGE</p>
 
</td>
 
<td>
 
<p>12</p>
 
</td>
 
</tr>
 
</table>
 
 
==User, field, group security table (RTBL)==
 
 
<p>
 
RTBL contains a user's privileges, class, field-level security (FLS) levels for each open file, and classes for open, permanent groups.</p>
 
 
<p>The size of RTBL is calculated from the formula:</p>
 
 
<p class="code">((NGROUPS + 11) * (NFILES + 1)) + NRMTFILE + 1
 
</p>
 
<p>
 
For Parallel Query Option/204 client nodes, the required size of RTBL increases by (NRMTFILE=1) bytes.</p>
 
 
===Character string table (STBL)===
 
 
<p>STBL stores all character strings in counted form, with a 1-byte length preceding the string itself. The following considerations apply to space usage:</p>
 
 
<ul>
 
<li> Space used to store intermediate results during an arithmetic expression evaluation is freed when the evaluation is completed.</li>
 
 
<li> Space used by FOR EACH OCCURRENCE, FOR EACH RECORD, and FOR EACH VALUE loops is reused until the end of the loop.</li>
 
 
<li> The last value of a NOTE statement remains in STBL.</li>
 
 
<li> FIXED or FLOAT %variable array uses eight bytes for each element.
 
</li>
 
</ul>
 
 
<p>When the %variable is reassigned, the STBL space is reused.</p>
 
 
<ul>
 
<li> The FIELD SAVE option requires 10 bytes plus the maximum length of the string plus one byte for each element.</li>
 
</ul>
 
 
<p>NO FIELD SAVE does not reserve the extra 10 bytes and results in significant saving when using a multidimensional array.</p>
 
 
<ul>
 
<li> MORE releases all but the space required by %variables and arrays. </li>
 
 
<li> If a user is using the pattern matcher in an IF statement with an IMAGE or SCREEN ITEM as the pattern and an IMAGE or SCREEN ITEM as the comparison string, then the value of the pattern is stored in STBL. The space is  freed after each comparison, so the maximum increase is equal to the size of the largest pattern in a request that meets the above criteria.</li>
 
</ul>
 
 
====When the Inverted File Access Method (IFAM) is used====
 
 
<ul>
 
<li> IFDVAL and IFFILE store the value string from the input parameter in STBL. </li>
 
 
<li> Strings enclosed in quotation marks or values specified for IFFIND that are stored in STBL are the same types as those stored in STBL by User Language.</li>
 
 
<li> EDIT form of IFPUT uses STBL for each value. Space from previous values is reused. </li>
 
 
<li> FLOD stores translation table values and CASE statement comparison values in STBL.
 
</li>
 
</ul>
 
 
====Parallel Query Option/204 STBL requirements====
 
 
<p>STBL requires an increase for Parallel Query Option/204 $functions used in remote file or scattered context and for User Language pattern matching processes</p>
 
 
<ul>
 
<li> Using one of the following $functions in remote context requires 12 additional bytes in STBL:
 
 
<p>$CURFILE</p>
 
 
<p>$FLCFILE</p>
 
 
<p>$UPDATE</p>
 
 
<p>$UPDFILE</p></li>
 
 
 
<li> If you are using the pattern matcher in any User Language statement, the full size of the pattern is used and stored in STBL. The space is freed after each statement block using the pattern  matcher, for example, FIND or FOR.</li>
 
</ul>
 
 
===Temporary work page list table (TTBL)===
 
 
<p>TTBL entries keep track of scratch file (CCATEMP) pages. The entries are four bytes each and used by the Editor and FIND (or IFFIND) evaluator routines.</p>
 
 
<ul>
 
<li> The Editor uses scratch pages to make a private copy of the procedure being edited.</li>
 
 
<li> FIND uses scratch pages as work space for evaluating Boolean expressions.</li>
 
</ul>
 
 
<p>The number of TTBL entries required by FIND depends on the complexity of the Boolean expression. Entries are released at the end of the FIND statement evaluation. </p>
 
 
===Compiler variable table (VTBL)===
 
 
<p>
 
VTBL stores values of simple variable types and refers to the String Table (STBL) in cases of more complex variables. The variables are local (%variables), internal, screen, and image variables. </p>
 
 
<p>
 
Many SOUL statements and some constructs cause one or more compiler variables to be allocated in VTBL.</p>
 
 
<p>Entries in VTBL vary in size. The "Sample VTBL entries" table shows typical values. For more information, refer to [[Large request considerations#VTBL (compiler variable table)|VTBL (compiler variable table)]].</p>
 
 
<table>
 
<caption>Sample VTBL entries</caption>
 
<tr class="head">
 
<th>
 
<p>SOUL statement  </p>
 
</th>
 
<th>
 
<p>VTBL entry size (bytes)</p>
 
</th>
 
</tr>
 
 
<tr>
 
<td>
 
<p>% variable:</p>
 
</td>
 
<td>
 
<p>&nbsp;</p>
 
</td>
 
</tr>
 
 
<tr>
 
<td>
 
<p>FIXED</p>
 
</td>
 
<td>
 
<p>16</p>
 
</td>
 
</tr>
 
 
<tr>
 
<td>
 
<p>FLOAT</p>
 
</td>
 
<td>
 
<p>12</p>
 
</td>
 
</tr>
 
 
<tr>
 
<td>
 
<p>STRING</p>
 
</td>
 
<td>
 
<p>24</p>
 
</td>
 
</tr>
 
 
<tr>
 
<td>
 
<p>array</p>
 
</td>
 
<td>
 
<p>20</p>