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

From m204wiki
Jump to navigation Jump to search
 
(100 intermediate revisions by 7 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 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>
 
<th>
 
<p>Specifies...</p>
 
</th>
 
 
</tr>
 
</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>
+
<tr><td>
<td>
+
<p><var>[[CPMAX parameter|CPMAX]]</var></p></td>
<p><var>[[CPMAX parameter|CPMAX]]</var></p>
+
<td><p>Maximum number of checkpoints</p>
</td>
+
</td></tr>
<td>
 
<p>Maximum number of checkpoints</p>
 
</td>
 
</tr>
 
 
   
 
   
<tr>
+
<tr><td>
<td>
+
<p><var>[[CPTIME parameter|CPTIME]]</var></p></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>
 +
<p><var>[[LENQTBL parameter|LENQTBL]]</var></p></td>
 
<td>
 
<td>
<p><var>[[LENQTBL parameter|LENQTBL]]</var></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><td>
 +
<p><var>[[LIBUFF parameter|LIBUFF]]</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>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>
</td>
 
</tr>
 
 
   
 
   
<tr>
+
<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>
<td>
 
<p><var>[[LIBUFF parameter|LIBUFF]]</var></p>
 
</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>If an input line is continued with a nonblank character, the number of characters in the original line and all continuations (not including
+
<tr><td>
continuation characters) must fit in the LIBUFF specification. </p>
+
<p><var>[[LOBUFF parameter|LOBUFF]]</var></p></td>
</td>
 
</tr>
 
 
<tr>
 
<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>
<td>
+
<p><var>[[LOGADD parameter|LOGADD]]</var></p></td>
<p><var>[[LOGADD parameter|LOGADD]]</var></p>
 
</td>
 
 
<td>
 
<td>
<p>Number of slots reserved for adding new password
+
<p>Number of slots reserved for adding new password (CCASTAT) entries. The default is 0. </p>
(CCASTAT) entries. The default is 0. </p>
+
</td></tr>
</td>
 
</tr>
 
 
   
 
   
<tr>
+
<tr><td>
 +
<p><var>[[LOGFAIL parameter|LOGFAIL]]</var></p></td>
 
<td>
 
<td>
<p><var>[[LOGFAIL parameter|LOGFAIL]]</var></p>
+
<p>Action taken when the number of consecutive login failures exceeds the value of the <var>LOGTRY</var> parameter. Default is 0. </p>
</td>
+
</td></tr>
<td>
 
<p>Action taken when the number of consecutive login failures exceeds the value of the LOGTRY parameter. Default is 0. </p>
 
</td>
 
</tr>
 
 
   
 
   
<tr>
+
<tr><td>
<td>
+
<p><var>[[LOGONENQ parameter|LOGONENQ]]</var></p></td>
<p><var>[[LOGONENQ parameter|LOGONENQ]]</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>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>
 
   
 
   
 
<p>The Subsystem Management facility is not affected by LOGONENQ.</p>
 
<p>The Subsystem Management facility is not affected by LOGONENQ.</p>
</td>
+
</td></tr>
</tr>
 
 
   
 
   
<tr>
+
<tr><td>
<td>
+
<p><var>[[LOGTRY parameter|LOGTRY]]</var></p></td>
<p><var>[[LOGTRY parameter|LOGTRY]]</var></p>
 
</td>
 
 
<td>
 
<td>
 
<p>Maximum number of login attempts allowed. The default is 0. </p>
 
<p>Maximum number of login attempts allowed. The default is 0. </p>
</td>
+
</td></tr>
</tr>
 
 
   
 
   
<tr>
+
<tr><td>
 +
<p><var>[[LRETBL parameter|LRETBL]]</var></p></td>
 
<td>
 
<td>
<p><var>[[LRETBL parameter|LRETBL]]</var></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><td>
 +
<p><var>[[LRUTIM parameter|LRUTIM]]</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>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>
 
 
   
 
   
<tr>
+
<tr><td>
 +
<p><var>[[MAXBUF parameter|MAXBUF]]</var></p></td>
 
<td>
 
<td>
<p><var>[[LRUTIM parameter|LRUTIM]]</var></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>
+
</td></tr>
 +
 +
<tr><td>
 +
<p><var>[[MINBUF parameter|MINBUF]]</var></p></td>
 
<td>
 
<td>
<p>Disk page reference interval for references considered obsolete. Use LRUTIM to calculate DKRR statistics. The default is 0.</p>
+
<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>
+
</td></tr>
</tr>
 
 
   
 
   
<tr>
+
<tr><td>
 +
<p><var>[[NDCBS parameter|NDCBS]]</var></p></td>
 
<td>
 
<td>
<p><var>[[MAXBUF parameter|MAXBUF]]</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 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>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>[[MINBUF parameter|MINBUF]]</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>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>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>[[NDCBS parameter|NDCBS]]</var></p>
+
<p><var>[[NSERVS parameter|NSERVS]]</var></p>
 
  </td>
 
  </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>Number of servers. The default is <var>NUSERS</var> (see below). </p>
</td>
+
</td></tr>
</tr>
 
 
   
 
   
<tr>
+
<tr><td>
 +
<p><var>[[NSUBTKS parameter|NSUBTKS]]</var></p></td>
 
<td>
 
<td>
<p><var>[[NDIR parameter|NDIR]]</var></p>
+
<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>
+
</td></tr>
 +
 +
<tr><td>
 +
<p><var>[[NUMBUFG parameter|NUMBUFG]]</var></p></td>
 
<td>
 
<td>
<p>Maximum number of <var class="product">Model&nbsp;204</var> files that can be opened during a run. The default is 5.</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>
+
 
 +
<tr><td>
 +
<p><var>[[NUSERS parameter|NUSERS]]</var></p></td>
 +
<td>
 +
<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></tr>
 
   
 
   
<tr>
+
<tr><td>
 +
<p><var>[[PAGEFIX parameter|PAGEFIX]]</var></p></td>
 
<td>
 
<td>
<p><var>[[NFILES parameter|NFILES]]</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>
 
<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>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>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>
+
</td></tr>
</tr>
 
 
   
 
   
<tr>
+
<tr><td>
 +
<p><var>[[RETRVKEY parameter|RETRVKEY]]</var></p></td>
 
<td>
 
<td>
<p><var>[[NGROUP parameter|NGROUP]]</var></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><td>
 +
<p><var>[[SEQOPT parameter|SEQOPT]]</var></p>
 +
</td>
 
<td>
 
<td>
<p>Maximum number of file groups each user can have open at the same time. The default is 5.</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>
+
   
</tr>
+
<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>
+
<tr><td>
<td>
+
<p><var>[[SERVSIZE parameter|SERVSIZE]]</var></p>
<p><var>[[NSERVS parameter|NSERVS]]</var></p>
+
</td>
</td>
 
 
<td>
 
<td>
<p>Number of servers. The default is NUSERS (see below). </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>[[NSUBTKS parameter|NSUBTKS]]</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 pseudo subtasks that can be generated in a <var class="product">Model&nbsp;204</var> run. The default is 4.</p>
+
 
</td>
+
<li> Active subsystems. (See the formula given in [[System requirements for Application Subsystems#SPCORE size|SPCORE size]].)</li>
</tr>
+
 
 +
<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>
 
   
 
   
<tr>
+
<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>
<td>
 
<p><var>[[NUSERS parameter|NUSERS]]</var></p>
 
</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>
 
</td>
 
 
</tr>
 
</tr>
 
   
 
   
<tr>
+
<tr><td>
<td>
+
<p><var>[[TIMESTOP parameter|TIMESTOP]]</var></p></td>
<p><var>[[PAGEFIX parameter|PAGEFIX]]</var></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>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>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>
+
<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>[[RETRVKEY parameter|RETRVKEY]]</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>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>
 
</tr>
 
 
   
 
   
<tr>
+
<ul>
<td>
+
<li> [[IOS Branch Entry]]</li>
<p><var>[[SEQOPT parameter|SEQOPT]]</var></p>
+
 
</td>
+
<li> [[UL/DB2]]</li>
<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>
+
<li> [[Defining the user environment (CCAIN)#CRAM options for z/OS|CRAM-XDM]]</li>
+
 
<p class="code">MAXBUF = NUSERS * (4 + 2 * [maximum FOR EACH RECORD loop nest level])
+
<li> CPUID check (product license verification; prior to Model&nbsp;204 7.5)</li>
</p>
+
</ul>
 
<p>
 
<p>
You can modify SEQOPT with the RESET command. </p>
+
VIO is incompatible with IOSB and EXCPVR.</p>
</td>
+
</td></tr>
</tr>
 
 
   
 
   
<tr>
+
<tr><td><p><var>[[XMEMSVC parameter|XMEMSVC]]</var></p></td>
 
<td>
 
<td>
<p><var>[[SERVSIZE parameter|SERVSIZE]]</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>Size of each server area. The default is 0. (See [[Server areas]].) </p>
 
</td>
 
</tr>
 
 
<tr>
 
<td>
 
<p><var>[[SPCORE parameter|SPCORE]]</var></p>
 
</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>
 
 
 
<ul>
 
<ul>
<li> IFAM4 application program storage. The default is 12288.  </li>
+
<li> IOS Branch Entry</li>
</li>
+
 
<li> Active subsystems. (See the formula given in [[System Requirements for Application Subsystems#SPCORE size|SPCORE size]].)</li>
+
<li> UL/DB2</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> CRAM-XDM</li>
</li>
+
 
<li> Each defined retrieval key for previous terminal input (180 bytes per key). </li>
+
<li> CPUID check (product license verification; prior to Model&nbsp;204 7.5)</li>
</li>
 
 
</ul>
 
</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>
 
   
 
   
<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>
+
<table>
</td>
+
<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>[[TIMESTOP parameter|TIMESTOP]]</var></p>
+
<p>10000000</p></td>
</td>
+
<td>
 +
<p>128</p></td>
 
<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>Generate audit trail and/or journal</p></td>
 +
</tr>
 
   
 
   
<p>
+
<tr>
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>
</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>
 
   
 
   
 
<tr>
 
<tr>
 
<td>
 
<td>
<p><var>[[XMEMOPT parameter|XMEMOPT]]</var></p>
+
<p>00100000</p></td>
</td>
+
<td>
 +
<p>32</p></td>
 
<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>Include RK lines on the audit trail</p></td>
 +
</tr>
 
   
 
   
<p>It is also required for:</p>
+
<tr>
 +
<td>
 +
<p>00010000</p></td>
 +
<td>
 +
<p>16 </p></td>
 +
<td>
 +
<p>Login required</p></td>
 +
</tr>
 
   
 
   
<ul>
+
<tr>
<li> IOS Branch Entry</li>
+
<td>
</li>
+
<p>00001000</p></td>
<li> UL/DB2</li>
+
<td>
</li>
+
<p>8</p></td>
<li> CRAM-XDM</li>
+
<td>
</li>
+
<p>Automatic disconnect in response to the LOGOUT command</p></td>
<li> CPUID check</li>
+
</tr>
</li>
 
</ul>
 
 
   
 
   
<p>
+
<tr>
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>
+
<td>
+
<p>00000100</p>
<p>VIO is incompatible with IOSB and EXCPVR.</p>
 
 
  </td>
 
  </td>
 +
<td>
 +
<p>4</p></td>
 +
<td>
 +
<p>Restrict the use of data definition commands within a run</p></td>
 
</tr>
 
</tr>
 
   
 
   
 
<tr>
 
<tr>
 
<td>
 
<td>
<p><var>[[XMEMSVC parameter|XMEMSVC]]</var></p>
+
<p>00000010</p></td>
</td>
+
<td>
 +
<p>2</p></td>
 
<td>
 
<td>
<p>SVC number of the <var class="product">Model&nbsp;204</var> Cross-Memory Services. Coordinates with XMEMOPT.  The default is 0.
+
<p>Open CCAGRP for use of permanent file group</p></td>
It is also required for:</p>
+
</tr>
 
   
 
   
<ul>
+
<tr>
<li> IOS Branch Entry</li>
+
<td>
</li>
+
<p>00000001</p></td>
<li> UL/DB2</li>
+
<td>
</li>
+
<p>1</p></td>
<li> CRAM V4.1 feature</li>
+
<td>
</li>
+
<p>Open CCASYS for use of application subsystem definitions</p></td>
<li> CRAM-XDM</li>
+
</tr>
</li>
+
</table></li>
<li> CPUID check</li>
 
</li>
 
 
</ul>
 
</ul>
</td>
 
</tr>
 
</table>
 
 
   
 
   
===z/VSE UPSI Job Control statement===
+
==Resource locking==
 
   
 
   
<p>In a z/VSE environment:</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>
 
   
 
   
<ul>
+
<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>
<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>Locking occurs on:</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
+
<ul>
</p>
+
<li> File resources, which are usually locked in SHR mode, such as:
<p>The "UPSI/SYSOPT settings" table summarizes the UPSI bit settings and SYSOPT equivalents: </p>
+
<ul>
+
<li> File access</li>
<table>
+
 
<caption>UPSI/SYSOPT settings</caption>
+
<li> Record locking table</li>
<tr class="head">
+
 
<th>
+
<li> Table B and Group index</li>
<p>UPSI
+
 
setting</p>
+
<li> Tables C and D</li>
</th>
+
 
<th>
+
<li> Permanent procedures</li>
<p>SYSOPT value</p>
+
 
  </th>
+
<li> Access Control Table </li>
<th>
+
</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>
 +
 +
<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>
 
<p>
Meaning</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>
</th>
+
<p>
</tr>
+
You can issue a <code>MONITOR ENQ</code> command to determine current usage in the record locking table.</p>
 
   
 
   
<tr>
+
====Calculating allocated size of record locking table====
<td>
+
<p>
<p>10000000</p>
+
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>
</td>
 
<td>
 
<p>128</p>
 
  </td>
 
<td>
 
<p>Generate audit trail and/or journal</p>
 
</td>
 
</tr>
 
 
   
 
   
<tr>
+
====SYSOPT2=X'40'====
<td>
+
<p>
<p>01000000</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>64</p>
 
</td>
 
<td>
 
<p>Abend without a dump when the return code is nonzero</p>
 
</td>
 
</tr>
 
 
   
 
   
<tr>
+
<ul>
<td>
+
<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>
<p>00100000</p>
+
 
  </td>
+
<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>
<td>
+
</ul>
<p>32</p>
+
 
  </td>
+
===Resource locking table===
<td>
 
<p>Include RK lines on the audit trail</p>
 
</td>
 
</tr>
 
 
   
 
   
<tr>
+
<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>
<td>
+
   
<p>00010000</p>
+
====Sizing the resource locking table====
  </td>
+
   
<td>
+
<p>For details on estimating the size of the resource locking table, see <var>[[LENQTBL parameter|LENQTBL]]</var>.</p>
<p>16 </p>
 
  </td>
 
<td>
 
<p>Login required</p>
 
</td>
 
</tr>
 
 
   
 
   
<tr>
+
<p>For z/OS, <var class="product">Model&nbsp;204</var> allocates the resource locking table above the 16-megabyte line. </p>
<td>
 
<p>00001000</p>
 
</td>
 
<td>
 
<p>8</p>
 
</td>
 
<td>
 
<p>Automatic disconnect in response to the LOGOUT command</p>
 
</td>
 
</tr>
 
 
   
 
   
<tr>
+
===Multiple jobs running on one CPU===
<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>
+
<p>Locking occurs at the file level when application files are shared between multiple jobs. </p>
<td>
 
<p>00000010</p>
 
</td>
 
<td>
 
<p>2 </p>
 
  </td>
 
<td>
 
<p>Open CCAGRP for use of permanent file group</p>
 
</td>
 
</tr>
 
 
   
 
   
<tr>
+
<p>File locking modes is EXCL when:</p>
<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>
 
 
   
 
   
==Resource locking==
+
<ul>
 +
<li>Files are opened from a SOUL thread or an IFAM1 thread that has file update privileges.</li>
 
   
 
   
<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>
+
<li>Files are opened from an IFAM2 thread or an IFAM4 thread that has allowed updates with thread update and file update privileges.</li>
 
   
 
   
<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>
+
<li>Command is entered to create or delete a permanent group.</li>
 +
</ul>
 
   
 
   
<p>Locking occurs on:</p>
+
<p>File locking is SHR mode when:</p>
 
   
 
   
 
<ul>
 
<ul>
<li> File resources, which are usually locked in SHR mode, such as:</li>
+
<li>Files are opened under any other circumstances than those listed above.</li>
</li>
+
<li> File access</li>
+
<li>Files are opened in deferred update mode. Such files remain in SHR mode for the duration of the run.
</li>
+
<p class="note"><b>Note:</b>
<li> Record locking table</li>
+
Up to 192 files can be opened in deferred update mode.
</li>
+
An attempt to exceed 192 files results in an error message.</p></li>
<li> Table B and Group index</li>
+
</li>
+
<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>
<li> Tables C and D</li>
+
</li>
+
<li>The <var class="product">Model&nbsp;204</var> job uses the CCAGRP data set. </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>
 
</ul>
 
   
 
   
<p>The following sections explain the resource locking tables and the details of resource locking on single and multiple CPUs.</p>
+
<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===
 
   
 
   
===Record locking table===
+
<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>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>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>You can issue a MONITOR ENQ command to determine current usage in the record locking table.</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>
 
   
 
   
====Calculating allocated size of record locking table====
+
<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>
 
   
 
   
<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>Messages sent to the operator's console are:</p>
 
====SYSOPT2=X'40'====
 
 
<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>
 
 
<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>
 
 
   
 
   
 
<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> For an Online job:
</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>
 
</ul>
 
 
   
 
   
===Resource locking table===
+
<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> </li>
 
   
 
   
<p>You can use the $CENQCT function to obtain information on the number of unused entries in the resource locking table.  </p>
+
<li>For a batch job the message sent from <var class="product">Model&nbsp;204</var> to the operator:
 
   
 
   
====Sizing the resource locking table====
+
<p class="code"><b></b>*** M204.0582: ACCESS TO FILE <i>filename</i> PREVENTED BY: <i>jobname</i>
 
   
 
   
<p>For details on estimating the size of the resource locking table, see <var>[[LENQTBL parameter|LENQTBL]]</var>.</p>
+
<b></b>*** M204.0581: ENQ'ING TO SHR FOR FILE <i>filename volname</i>
 
   
 
   
<p>For z/OS, <var class="product">Model&nbsp;204</var> allocates the resource locking table above the 16-megabyte line. </p>
+
<b></b>*** M204.0582: ACCESS TO FILE <i>filename</i> PREVENTED BY: <i>jobname</i>
 
   
 
   
===Multiple jobs running on one CPU===
+
<b></b>*** M204.0583: ENQ'ING TO EXCL FOR FILE <i>filename volname</i>
 +
</p> </li>
 +
</ul>
 
   
 
   
<p>Locking occurs at the file level when application files are shared between multiple jobs.  </p>
+
===Data integrity===
 
   
 
   
<p>File locking modes is EXCL when:</p>
+
<p>When multiple jobs run on the same CPU, data integrity is ensured by using:</p>
 
   
 
   
 
<ul>
 
<ul>
<li>Files are opened from a User Language thread or an IFAM1 thread that has file update privileges.</li>
+
<li> Operating system locking and unlocking facility for shared application files and the system file containing file group definitions (CCAGRP).</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> Special lock stored in the system file containing user and file security information (CCASTAT).</li>
 
   
 
   
<li>Command is entered to create or delete a permanent group.</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>
 
</ul>
 
</ul>
 
   
 
   
<p>File locking is SHR mode when:</p>
+
===Multiple Model 204 versions running on separate CPUs===
 +
 +
<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>
 
   
 
   
 
<ul>
 
<ul>
<li>Files are opened under any other circumstances than those listed above.</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> File that was read-only is first opened for update.</li>
 
   
 
   
<li>Files are opened in deferred update mode. Such files remain in SHR mode for the duration of the run.
+
<li> Last updating user closes the file.</li>
<p class="note"><b>Note:</b>
 
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> File is completely closed. </li>
 
   
 
   
<li>The <var class="product">Model&nbsp;204</var> job uses the CCAGRP data set. </li>
+
<li> Device is released in each case after a single disk read and disk write have been performed.
 
</li>
 
</li>
 
</ul>
 
</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>
+
<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>
 
   
 
   
===Handling locking conflicts===
+
<p>Each list entry contains the following information:</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> SMF system ID lock type (SHR or EXCL)</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> Job and step names</li>
 
   
 
   
<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>
+
<li> Date and time that the list entry was created</li>
 +
</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 (ERMX) is reached.</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>
 
   
 
   
<p>Messages sent to the operator's console are:</p>
+
<p>Conflicts are handled automatically in single CPU error cases where a
 +
<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>
 
   
 
   
<ul>
+
<ol>
<li> For an Online job:
+
<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"><b></b>*** M204.0582: ACCESS TO FILE <i>filename</i> PREVENTED BY: <i>jobname</i>
+
<li> If the locking request is exclusive, any list entries for the current system are eliminated as obsolete.</li>
<b></b>*** M204.0584: FILE IS IN USE &mdash; <i>filename</i>
 
</p> </li>
 
 
   
 
   
<li>For a batch job the message sent from <var class="product">Model&nbsp;204</var> to the operator:
+
<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>
 +
</ol>
 
   
 
   
<p class="code"><b></b>*** M204.0582: ACCESS TO FILE <i>filename</i> PREVENTED BY: <i>jobname</i>
+
===Locking conflicts between CPUs===
 
   
 
   
<b></b>*** M204.0581: ENQ'ING TO SHR FOR FILE <i>filename volname</i>
+
<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>
 
   
 
   
<b></b>*** M204.0582: ACCESS TO FILE <i>filename</i> PREVENTED BY: <i>jobname</i>
+
<ul>
 +
<li> If an <var>ENQCTL</var> command is issued with only a file name, all list entries for the file are displayed.</li>
 
   
 
   
<b></b>*** M204.0583: ENQ'ING TO EXCL FOR FILE <i>filename volname</i>
+
<li> If an <var>ENQCTL</var> command is issued with arguments, all the entries satisfying the arguments are deleted.</li>
</p> </li>
 
 
</ul>
 
</ul>
 
   
 
   
===Data integrity===
+
<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 multiple jobs run on the same CPU, data integrity is ensured by using:</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>
 
   
 
   
<ul>
+
===Shared DASD locking conflicts===
<li> Operating system locking and unlocking facility for shared application files and the system file containing file group definitions (CCAGRP).</li>
 
 
   
 
   
<li> Special lock stored in the system file containing user and file security information (CCASTAT).</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> Restriction on sharing the system file that provides space for user work tables (CCASERVR) and the system scratch file (CCATEMP) between jobs.
 
</li>
 
</ul>
 
 
===Multiple Model 204 versions running on separate CPUs===
 
 
<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>
 
 
   
 
   
 +
<p>Messages sent to the operator's console are:  </p>
 
<ul>
 
<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>
+
<li> For a batch job:
 +
<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>
 +
</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> File is opened in a <var class="product">Model&nbsp;204</var> job for the first time.</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
 +
<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>
 
   
 
   
<li> File that was read-only is first opened for update.</li>
+
===z/VSE considerations===
+
<p>
<li> Last updating user closes the file.</li>
+
The following considerations apply to resource locking in a z/VSE environment:</p>  
+
<ul>
<li> File is completely closed. </li>
+
<li> File locking is available for z/VSE releases that support LOCK and UNLOCK (SVC 110).</li>
+
 
<li> Device is released in each case after a single disk read and disk write have been performed.
+
<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>
 
 
</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>
+
===Resource locking in z/VM===
+
<p>
<p>Each list entry contains the following information:</p>
+
The following considerations apply to resource locking in z/VM environments:</p>
 
   
 
   
 
<ul>
 
<ul>
<li> SMF system ID lock type (SHR or EXCL)</li>
+
<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> Job and step names</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>
 +
 +
<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>
 
   
 
   
<li> Date and time that the list entry was created
+
<li>SHR mode access on a read-only device can cause data inconsistencies.
</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==
 
   
 
   
===How Model 204 resolves locking conflicts===
+
<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>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><var class="product">Model&nbsp;204</var> utilizes the following areas of storage, depending on the operating system architecture your site supports:</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> Below the line, for 24-bit storage for non-XA systems: z/OS, z/VM, and z/VSE</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> Above the bar, for sites that support 64-bit storage for z/OS, z/VM, and z/VSE</li>
 +
</ul>
 
   
 
   
<ol>
+
<p>The buffer pool consists of the following data structures: </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>
+
<ul>
 +
<li> Disk Buffer Control Blocks: 160 bytes each, one per buffer</li>
 
   
 
   
<li> If the locking request is exclusive, any list entries for the current system are eliminated as obsolete.</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> 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> Page fix lists: 16 bytes per buffer</li>
</li>
 
</ol>
 
 
   
 
   
===Locking conflicts between CPUs===
+
<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>
 
   
 
   
<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>
+
<p class="code">(NUMBUF + NUMBUFG) * (6192 + 160 + (16*HASHCELL) + 16)
 +
</p>
 +
<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>
 +
<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>
 +
<p class="note"><b>Note:</b> As of version 7.7 of Model&nbsp;204, either
 +
<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>
 +
 +
===Using 31-bit storage===
 +
<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> If an ENQCTL command is issued with only a file name, all list entries for the file are displayed.</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> 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>
 +
</ul>
 
   
 
   
<li> If an ENQCTL command is issued with arguments, all the entries satisfying the arguments are deleted.
+
<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>
 +
A minimum number of BTB buffers is required to bring up an Online configuration:</p>
 +
<ul>
 +
<li>Model&nbsp;204 7.6 or lower:
 +
<p>
 +
The minimum number of buffers is equal to the result of the following calculation: </p>
 +
<p class="code">NLRUQ * ((NSERVS + NSUBTKS) * MAXOBUF + 15)
 +
</p>
 +
<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>
 +
<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>
 
</ul>
 
</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>
 
   
 
   
<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>
+
<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 class="code">ENQCTL CENSUS S133
+
<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>
</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>
 
 
   
 
   
===Shared DASD locking conflicts===
+
<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>
 
   
 
   
<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> 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>
 +
</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>Messages sent to the operator's console are:   </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>
 
   
 
   
<ul>
+
<p class="code">M204.2581: XMEMOPT=2 (IOS BRANCH) REQUIRED FOR NUMBUFG > 0
<li> For a batch job:
 
 
<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>
 
 
</p>
 
</p>
<p class="note"><b>Note:</b>
+
<p>
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>
+
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>
 
   
 
   
<li>For active system or job locking list entries deleted by using the ENQCTL command:
+
<ul>
<p class="code"><b></b>*** M204.0585: SHARED DASD ENQ LIST OVERLAID FOR
+
<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>
<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===
+
<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).
 
<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>
 
<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>
 
</li>
 
</ul>
 
</ul>
 
   
 
   
===Resource locking in z/VM===
+
<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>The following considerations apply to resource locking in z/VM environments:</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>CMS-format disks cannot be shared in read/write mode by multiple virtual or real machines. Any attempt at SHR access destroys the data.
+
<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.
 
<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></li>
 
 
<li>Files that can be shared are CCAGRP, CCAIN, CCASTAT, CCASYS, and <var class="product">Model&nbsp;204</var> files. </li>
 
 
<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>
 
 
<li>SHR mode access on a read-only device can cause data inconsistencies.
 
 
<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>
 
</li>
 +
 +
<li><var>SERVNSA</var> (server non-swappable areas) specifies the tables above the bar.</li>
 
</ul>
 
</ul>
+
In order to store a table in ATB storage:
==Disk buffers and Model 204 storage==
+
<ul>
+
<li>Increase the <var>SERVNSSZ</var> parameter by the corresponding table size.</li>
<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>
+
 
+
<li>Set the proper bit in <var>SERVNSA</var>; for example:
<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>
+
<li>For FTBL, set the first byte to X'02', so the value of <var>SERVNSA</var> is X'02000000'.</li>
 +
 
 +
<li>For GTBL, set the second byte to X'80', so the value of <var>SERVNSA</var> is X'00800000'.</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>
 +
<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>
 
<ul>
<li> Below the line, for 24-bit storage for non XA systems: VSE, VM, and OS</li>
+
<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>
+
 
<li> Above the line, for sites that support 31-bit storage for z/OS, OS/390, XA, ESA, z/VSE, z/VM</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>
</li>
 
<li> Above the bar, for sites that support 64-bit storage for z/OS and z/VM</li>
 
</li>
 
 
</ul>
 
</ul>
+
 
<p>The buffer pool consists of the following data structures: </p>
+
<blockquote class="note"><b>Note:</b> In Model&nbsp;204 V7.5 and higher, server tables can be in three different places:
 
 
<ul>
 
<ul>
<li> Disk Buffer Control Blocks: 160 bytes each, one per buffer</li>
+
<li>The BTB swappable server area </li>
+
<li>The ATB swappable server area </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>The ATB non-swappable server area </li>
+
</ul>   
<li> Page fix lists: 16 bytes per buffer</li>
+
<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>
<li> Buffers: 6184 bytes, plus 8-byte overrun detection area
+
<p class="code">M204.1399: Same server area defined for server above the bar and non-swappable server</p>
   
 
<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>
 
 
<p class="code">(NUMBUF + NUMBUFG) * (6192 + 160 + (16*HASHCELL) + 16)
 
</p>
 
 
<p>
 
<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> may be equal to or less than <var>MAXBUF</var>, depending on the amount of virtual storage available to the job.</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>
 
<p>
<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>
+
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>
</li>
+
</blockquote>
</ul>
+
 
 +
====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>
 +
 +
<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>
 
   
 
   
===Buffers in an ONLINE configuration===
+
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>The following considerations apply to the use of buffers above the line in an ONLINE configuration:</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>
 
   
 
   
<ul>
+
<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>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:
 
<p class="code">NLRUQ * ((NSERVS + NSUBTKS) * MAXOBUF + 15)
 
</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>.
+
===Specifying delayed updates with the DKUPDTWT parameter===
</li>
+
<p>
</ul>
+
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>
 
   
 
   
<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>
+
<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>
 
   
 
   
===Using 31-bit storage===
+
<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>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>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>
 
   
 
   
<ul>
+
<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>
<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> 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>
 
 
   
 
   
<p class="note"><b>Note:</b>
+
===Handling delayed updates and CHKPPST===
For information about controlling the allocation of hash cells per buffer pool page, see the <var>[[HASHCELL parameter|HASHCELL]]</var> parameter. </p>
+
<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>
 
   
 
   
===Using 64-bit storage===
+
<li>Tries to quiesce updates, for up to <var>CPTQ</var>, plus <var>CPTO</var> seconds.</li>
 
   
 
   
<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>
+
<li>Takes the checkpoint, if all updates are quiesced.</li>
 +
</ol>
 
   
 
   
<p>64-bit features are not yet available on IBM z/VSE systems.</p>
+
<p>If <var>DKUPDTW</var>T is greater than 0, CHKPPST has substantially more processing to perform: </p>
 
   
 
   
<ul>
+
<ol>
<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>Sleeps for <var>DKUPDTWT</var> divided by four seconds.</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>Further processing depends on the value, rounded to the nearest integer of:
 +
<p class="code">N = (CPTIME * 60) / (DKUPDTWT / 4)
 +
</p></li>
 +
</ol>
 
   
 
   
<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>
+
===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> 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>
+
<table>
 +
<tr class="head">
 +
<th><p>Attempt </p> </th>
 +
<th><p>Purpose</p> </th></tr>
 
   
 
   
</ul>
+
<tr>
 +
<td>1.</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>
 
   
 
   
===Managing above the bar storage===
+
<tr>
 +
<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>
 
   
 
   
<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>
+
<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 class="code">NLRUQ * ((NSERVS + NSUBTKS) * MAXOBUF + 15)
+
<tr>
</p>
+
<td>5. </td>
<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>
+
<td>Performs the disk update process again. Then takes the checkpoint. </td></tr>
 
   
 
   
<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>
+
<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 minimum number of above the bar buffers calculated by <var class="product">Model&nbsp;204</var> uses the following formula:</p>
+
===Factors affecting disk update and checkpoint processing===
 +
<p>
 +
Several important factors affect the processing of disk updates and checkpoints:</p>
 
   
 
   
<p class="code">NLRUQG * ((NSERVS + NSUBTKS) * MAXOBUF + 15)
+
<ul>
</p>
+
<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>If you set NUMBUFG to a lower value, it is reset to the calculated value.</p>
+
<p class="code">M204.0440: DISK UPDATED ABORTED
 +
</p> </li>
 +
 +
<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> 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>
 
   
 
   
<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>
+
<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>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 class="code">M204.0843: CHECKPOINT TIMED OUT ON date/time UPDATING FILE file
 +
</p></li>
 
   
 
   
<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>
+
<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>
 
   
 
   
<p class="code">M204.2581: XMEMOPT=2 (IOS BRANCH) REQUIRED FOR NUMBUFG > 0
+
<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>
</p>
+
</ul>
<p>If you cannot get the number of buffers you requested, the job fails. </p>
 
 
   
 
   
====Determining NUMBUFG setting====
+
==Understanding file statistics==  
 +
<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>
 
   
 
   
<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>
+
===Handling 64-bit statistics===
 +
<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>
 
   
 
   
 
<ul>
 
<ul>
<li> The LDKBMWNG parameter, which applies to above the bar buffers, corresponds to the LDKBMWND parameter, which applies to below the bar buffers.</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> 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).
+
<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>
+
 +
<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>
 
</ul>
 
   
 
   
<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>
+
==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>
 
   
 
   
<p>If you do not set LDKBMWNG, it is set to the same value as LDKBMWND.</p>
+
===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>
 
   
 
   
====Above the bar storage for EBM pages====
+
<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>Existence Bit Map (EBM) pages reside in above the bar storage. </p>
+
<p class="syntax">SERVSIZE = <span class="term">fixed-table-size</span> + <span class="term">variable-table-size</span>
+
</p>
<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>Where:</p>
 
   
 
   
 
<ul>
 
<ul>
<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>
+
<li><var class="term">fixed-table-size</var> represents settings, defined during initialization, that cannot be modified during the run. </li>
 
   
 
   
<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.
+
<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>
 
</li>
 
</ul>
 
</ul>
 
   
 
   
====Above the bar storage for procedure pages====
+
====SERVSIZE and server page alignment====  
 +
<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>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>
+
<p>If you used server alignment previously, there is no change in your server size requirements.</p>
 
   
 
   
<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>
+
<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>
 
   
 
   
====Screens and images above the bar====
+
<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>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>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>
 +
 
 +
===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>
 
   
 
   
====Allocating the above the bar buffer pool====
+
<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>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>
+
<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>
 
   
 
   
<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>
+
===Calculating fixed table size===
 +
<p>
 +
Use the following formula to calculate fixed table size, the <var>[[FIXSIZE parameter|FIXSIZE]]</var> parameter value:</p>
 
   
 
   
<p>IOS Branch Entry is required when NUMBUFG is greater than zero, so the XMEMOPT setting must include the x'02' bit. </p>
+
<p class="code">Fixed table size = 2520
 +
      + ((MAXINCL+6) * 80)dwr
 +
      + ((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>In addition, the disk buffer control blocks associated with the above the bar buffers are also allocated above the bar. </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>
 
   
 
   
====Above the bar storage for hash table cells====
+
<p>If any SQL threads are specified in CCAIN (IODEVs 13, 17, or 19), add 6712 bytes for C language work areas.</p>
 
   
 
   
<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>
+
<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>
 
   
 
   
====Implementing above the bar use of storage====
+
<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>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>
+
<tr>
+
<td>
===Monitoring disk buffers===
+
<p>ERRMSGL</p></td>
<p>
+
<td>
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>
+
<p>80</p></td>
+
<td>
==Managing delayed disk updates==
+
<p>256</p></td>
 +
<td>
 +
<p>Bytes</p></td>
 +
</tr>
 
   
 
   
<p>The disk update process allows delayed disk updates, which avoids duplicate database writes in certain situations.</p>
+
<tr>
 +
<td>
 +
<p>LAUDPROC</p></td>
 +
<td>
 +
<p>21</p></td>
 +
<td>
 +
<p>253</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>LIBUFF</p></td>
 +
<td>
 +
<p>255</p></td>
 +
<td>
 +
<p>32767</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>LOBUFF</p></td>
 +
<td>
 +
<p>256</p></td>
 +
<td>
 +
<p>32767</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>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>
 
   
 
   
<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>NFILES</p></td>
 +
<td>
 +
<p>2</p></td>
 +
<td>
 +
<p>16383</p></td>
 +
<td>
 +
<p>Entries</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>NGROUP</p></td>
 +
<td>
 +
<p>5</p></td>
 +
<td>
 +
<p>16383</p></td>
 +
<td>
 +
<p>Entries</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>NORQS</p></td>
 +
<td>
 +
<p>5</p></td>
 +
<td>
 +
<p>32767</p></td>
 +
<td>
 +
<p>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>
 +
<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===
 
   
 
   
===Handling delayed updates and CHKPPST===
+
<p>Use the following formula to calculate variable table size:</p>
 
   
 
   
<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 class="code">Variable table size = 96
+
      + ((HTLEN+5) * (MAXHDR + MAXTRL)) dwr
<ol>
+
      + (LFSCB) dwr
<li> Sleeps for CPTIME minutes.</li>
+
      + (LFTBL) dwr
+
      + (LGTBL) dwr
<li> Tries to quiesce updates, for up to CPTQ, plus CPTO seconds.</li>
+
      + (LHEAP) dwr
+
      + (LITBL) dwr
<li> Takes the checkpoint, if all updates are quiesced.</li>
+
      + (LNTBL * 12)
</ol>
+
      + (LPDLST +32) dwr
+
      + (LQTBL * 16)
<p>If DKUPDTWT is greater than 0, CHKPPST has substantially more processing to perform: </p>
+
      + (LSTBL) dwr
+
      + (LTTBL * 4)dwr
<ol>
+
      + (LVTBL * 32)
<li> Sleeps for DKUPDTWT divided by four seconds.</li>
+
      + (LXTBL) dwr
 
<li> Further processing depends on the value, rounded to the nearest integer of:</li>
 
</ol>
 
 
<p class="code">N = (CPTIME * 60) / (DKUPDTWT / 4)
 
 
</p>
 
</p>
 
===Attempting a checkpoint===
 
 
<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>
+
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>
 
<tr class="head">
 
<tr class="head">
<th><p>Attempt </p> </th>
+
<th>
<th><p>Purpose</p> </th></tr>
+
<p>Parameter</p></th>
 +
<th>
 +
<p>Default</p></th>
 +
<th>
 +
<p>Max </p></th>
 +
<th>
 +
<p>Bytes/entries/lines</p></th>
 +
</tr>
 
   
 
   
 
<tr>
 
<tr>
<td>1. </td>
+
<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>
+
<p>HTLEN</p></td>
   
+
<td>
 +
<p>132</p></td>
 +
<td>
 +
<p>32767</p></td>
 +
<td>
 +
<p>Bytes</p></td>
 +
</tr>
 +
   
 
<tr>
 
<tr>
<td>2.  </td>
+
<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>
+
<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>
 +
 
<tr>
 
<tr>
<td>3.  </td>
+
<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>
+
<p>LFTBL</p></td>
 +
<td>
 +
<p>1000</p></td>
 +
<td>
 +
<p>30 million</p></td>
 +
<td>
 +
<p>Bytes</p></td>
 +
</tr>
 
   
 
   
 
<tr>
 
<tr>
<td>4.  </td>
+
<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>LGTBL</p></td>
 +
<td>
 +
<p>288</p></td>
 +
<td>
 +
<p>2 billion</p></td>
 +
<td>
 +
<p>Bytes</p></td>
 +
</tr>
 
   
 
   
 
<tr>
 
<tr>
<td>5. </td>
+
<td>
<td>Performs the disk update process again. Then takes the checkpoint. </td></tr>
+
<p>LHEAP</p></td>
 +
<td>
 +
<p>0</p></td>
 +
<td>
 +
<p>2 million</p></td>
 +
<td>
 +
<p>Bytes</p></td>
 +
</tr>
 
   
 
   
 
<tr>
 
<tr>
<td>6. </td>
+
<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>
+
<p>LITBL</p></td>
</table>
+
<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>
 
   
 
   
===Factors affecting disk update and checkpoint processing===
+
<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>Several important factors affect the processing of disk updates and checkpoints:</p>
+
<tr>
 +
<td>
 +
<p>LPDLST</p></td>
 +
<td>
 +
<p>2600</p></td>
 +
<td>
 +
<p>32760</p></td>
 +
<td>
 +
<p>Bytes</p></td>
 +
</tr>
 
   
 
   
<ul>
+
<tr>
<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:
+
<td>
 +
<p>LQTBL</p></td>
 +
<td>
 +
<p>400</p></td>
 +
<td>
 +
<p>262,143</p></td>
 +
<td>
 +
<p>16-byte entries</p></td>
 +
</tr>
 
   
 
   
<p class="code">M204.0440: DISK UPDATED ABORTED
+
<tr>
</p> </li>
+
<td>
 +
<p>LSTBL</p></td>
 +
<td>
 +
<p>600</p></td>
 +
<td>
 +
<p>16M</p></td>
 +
<td>
 +
<p>Bytes</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>LTTBL</p></td>
 +
<td>
 +
<p>50</p></td>
 +
<td>
 +
<p>8190</p></td>
 +
<td>
 +
<p>4-byte entries</p></td>
 +
</tr>
 
   
 
   
<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>
+
<tr>
 +
<td>
 +
<p>LVTBL</p></td>
 +
<td>
 +
<p>50</p></td>
 +
<td>
 +
<p>524287</p></td>
 +
<td>
 +
<p>32-byte entries</p></td>
 +
</tr>
 
   
 
   
<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:
+
<tr>
 +
<td>
 +
<p>LXTBL</p></td>
 +
<td>
 +
<p>1000</p></td>
 +
<td>
 +
<p>32760</p></td>
 +
<td>
 +
<p>Bytes</p></td>
 +
</tr>
 
   
 
   
<p class="code">M204.0843: CHECKPOINT TIMED OUT ON date/time UPDATING FILE file
+
<tr>
</p>
+
<td>
 +
<p>MAXHDR</p></td>
 +
<td>
 +
<p>5</p></td>
 +
<td>
 +
<p>32767</p></td>
 +
<td>
 +
<p>Lines</p></td>
 +
</tr>
 
   
 
   
<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>
+
<tr>
+
<td>
<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.
+
<p>MAXTRL</p></td>
</li>
+
<td>
</ul>
+
<p>5</p></td>
+
<td>
==Understanding file statistics==
+
<p>32767</p></td>
+
<td>
<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>
+
<p>Lines</p></td>
+
</tr>
===Handling 64-bit statistics===
+
</table>
 +
 
 +
==Server tables==
 
<p>
 
<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>
+
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>
 
   
 
   
<ul>
+
<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>
<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>
+
<p>The "Summary of server tables" lists the server tables. Further information on individual tables is contained in the subsections that follow.</p>
 
   
 
   
<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>
+
<table>
</ul>
+
<caption>Summary of server tables</caption>
 +
<tr class="head">
 +
<th><p>Table</p></th>
 +
<th><p>Contents</p></th>
 +
</tr>
 
   
 
   
==Server areas==
+
<tr>
 +
<td><p>FSCB</p></td>
 +
<td><p>Menu, screen, and image information</p></td>
 +
</tr>
 
   
 
   
<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>
+
<tr>
 +
<td><p>FTBL</p></td>
 +
<td><p>File groups</p></td>
 +
</tr>
 
   
 
   
===Sizing user server areas===
+
<tr>
 +
<td><p>GTBL</p></td>
 +
<td><p>Global variables</p></td>
 +
</tr>
 
   
 
   
<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>
+
<tr>
 +
<td><p>ITBL</p></td>
 +
<td><p>Dummy string and $READ responses</p></td>
 +
</tr>
 
   
 
   
<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>
+
<tr>
 +
<td><p>NTBL</p></td>
 +
<td><p>Statement labels, list names, and variables</p></td>
 +
</tr>
 
   
 
   
<p class="syntax">SERVSIZE = <span class="term">fixed-table-size</span> + <span class="term">variable-table-size</span>
+
<tr>
</p>
+
<td><p>QTBL</p></td>
<p>Where:</p>
+
<td><p>Statements in internal form (quadruples)</p></td>
 +
</tr>
 
   
 
   
<ul>
+
<tr>
<li><var class="term">fixed-table-size</var> represents settings, defined during initialization, that cannot be modified during the run. </li>
+
<td><p>RTBL</p></td>
 +
<td><p>User privileges, class, and field level security information</p></td>
 +
</tr>
 
   
 
   
<li><var class="term">variable-table-size</var> represents settings that can be varied using the UTABLE command or its IFAM equivalent, IFUTBL.
+
<tr>
</li>
+
<td><p>STBL</p></td>
</ul>
+
<td><p>Character strings</p></td>
 +
</tr>
 
   
 
   
====SERVSIZE and server page alignment====
+
<tr>
+
<td><p>TTBL</p></td>
<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>
+
<td><p>Temporary work pages</p></td>
 +
</tr>
 
   
 
   
<p>If you used server alignment previously, there is no change in your server size requirements.</p>
+
<tr>
 +
<td><p>VTBL</p></td>
 +
<td><p>Compiler variables</p></td>
 +
</tr>
 
   
 
   
<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>
+
<tr>
 +
<td><p>XTBL</p></td>
 +
<td><p>Procedure security</p></td>
 +
</tr>
 +
</table>
 
   
 
   
<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>
+
===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>
 
   
 
   
<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>The FSCB must be large enough to hold the largest screen, image, or menu definition. The following space is required:</p>
 
   
 
   
===Initialization and error handling===
+
<ul>
 +
<li>144 bytes of fixed overhead for every menu, including the menu title</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>144 bytes for each menu prompt</li>
 
   
 
   
<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>
+
<li>432 bytes of fixed overhead for the first panel of every screen:</li>
 
   
 
   
<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>
+
<li>144 bytes for each subsequent panel, including the screen title</li>
 
   
 
   
===Calculating fixed table size===
+
<li>32 bytes for each screen prompt and input item</li>
 
   
 
   
<p>Use the following formula to calculate fixed table size, the FIXSIZE parameter value:</p>
+
<li>32 bytes for every screen line containing at least one input item</li>
 
   
 
   
<p class="code">Fixed table size = 2520
+
<li>80 bytes for each defined screen line, including skipped lines</li>
 
   
 
   
      + ((LAUDPROC + 9) * 4)dwr
+
<li>Additional space for automatic validation, including:</li>
 
   
 
   
      + (LIBUFF + 4)
+
<li>2 or 4 bytes for each automatic validation option</li>
 
   
 
   
      + (LOBUFF + 5)dwr
+
<li>256 bytes for the VERIFY command when a particular character set is used in a compiled screen for the first time</li>
 +
</ul>
 
   
 
   
      + (LOUTPB)dwr
+
<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>
 
   
 
   
      + ((NGROUP + 12) * (NRMTFILE + NFILES + 1))
+
<ul>
 +
<li>8 bytes for each number in a NUMERIC RANGE statement (16 bytes for each range pair)</li>
 
   
 
   
      + (((NORQS*3) + 2)dwr + (NRMTFILE + 1))dwr
+
<li>Space for every block used in image definition</li>
 +
</ul>
 
   
 
   
      + (3 * (ERRMSGL - 80))
+
<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>
 
<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>
 
 
   
 
   
<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>
+
===File group table (FTBL)===
 +
<p>
 +
Data structures particular to file groups are stored in FTBL. FTBL entries are:</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> Sixty-two-byte fixed size entry plus six bytes for each file in the group definition.
 
   
 
   
<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>
+
<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>
 
   
 
   
<table>
+
<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
<caption>Fixed server table values</caption>
+
<p>
<tr class="head">
+
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>
<th><p>Parameter</p>
+
</ul>
  </th>
+
   
<th><p>Default</p>
+
<p>When the Inverted File Access Method (IFAM) is used: </p>
</th>
 
<th><p>Max </p>
 
  </th>
 
<th><p>Bytes/entries</p>
 
</th>
 
</tr>
 
 
   
 
   
<tr>
+
<ul>
<td>
+
<li>Host Language threads use FTBL under the same circumstances as SOUL.</li>
<p>ERRMSGL</p>
 
</td>
 
<td>
 
<p>80</p>
 
</td>
 
<td>
 
<p>256</p>
 
</td>
 
<td>
 
<p>Bytes</p>
 
</td>
 
</tr>
 
 
   
 
   
<tr>
+
<li>Field entries are not deleted until the group is closed or until IFFNSH is called. </li>
<td>
 
<p>LAUDPROC</p>
 
</td>
 
<td>
 
<p>21</p>
 
</td>
 
<td>
 
<p>253</p>
 
</td>
 
<td>
 
<p>Bytes</p>
 
</td>
 
</tr>
 
 
   
 
   
<tr>
+
<li>Increase the total FTBL requirement by NGROUP times four bytes.
<td>
+
</li>
<p>LIBUFF</p>
+
</ul>
  </td>
+
   
<td>
+
<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>255</p>
+
   
  </td>
+
<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>
<td>
+
 
<p>32767</p>
+
===Understanding the global variable table (GTBL)===
</td>
+
<p>
<td>
+
GTBL contains information about:</p>
<p>Bytes</p>
 
</td>
 
</tr>
 
 
   
 
   
<tr>
+
<ul>
<td>
+
<li>Global variables </li>
<p>LOBUFF</p>
 
</td>
 
<td>
 
<p>256</p>
 
</td>
 
<td>
 
<p>32767</p>
 
</td>
 
<td>
 
<p>Bytes</p>
 
</td>
 
</tr>
 
 
   
 
   
<tr>
+
<li>Global images, screens, and menus</li>
<td>
+
</ul>
<p>LOUTPB</p>
+
   
  </td>
+
<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>
<td>
 
<p>0</p>
 
</td>
 
<td>
 
<p>3000</p>
 
</td>
 
<td>
 
<p>Bytes</p>
 
</td>
 
</tr>
 
 
   
 
   
<tr>
+
<p>In addition, a 32-byte trailer stores information about offsets. </p>
<td>
+
 
<p>NFILES</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>
</td>
 
<td>
 
<p>2</p>
 
</td>
 
<td>
 
<p>16383</p>
 
</td>
 
<td>
 
<p>Entries</p>
 
</td>
 
</tr>
 
 
   
 
   
<tr>
+
====Clearing GTBL entries====
<td>
+
<p>
<p>NGROUP</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>
</td>
 
<td>
 
<p>5</p>
 
</td>
 
<td>
 
<p>16383</p>
 
</td>
 
<td>
 
<p>Entries</p>
 
</td>
 
</tr>
 
 
   
 
   
<tr>
+
====Space allocation====
<td>
+
<p>
<p>NORQS</p>
+
The space allocation for a global variable includes:</p>
</td>
 
<td>
 
<p>5</p>
 
</td>
 
<td>
 
<p>32767</p>
 
</td>
 
<td>
 
<p>Entries</p>
 
</td>
 
</tr>
 
 
   
 
   
<tr>
+
<ul>
<td>
+
<li>4 bytes indicating the length of GTBL</li>
<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===
+
<li>1 byte for the length of the variable name</li>
 
   
 
   
<p>Use the following formula to calculate variable table size:</p>
+
<li>Variable name</li>
 
   
 
   
<p class="code">Variable table size = 96
+
<li>1 byte for the length of the current name</li>
 
   
 
   
      + ((HTLEN+5) * (MAXHDR + MAXTRL)) dwr
+
<li>Current value  </li>
 +
</ul>
 
   
 
   
      + (LFSCB) dwr
+
<p>
 +
Global images, screens, and menus require space for a 20-byte header in addition to the size of the object.</p>
 
   
 
   
      + (LFTBL) dwr
+
<p>
 +
When allocating GTBL space, always remember to add 32 bytes for the trailer.</p>
 
   
 
   
      + (LGTBL) dwr
+
<p>
 +
The minimum length of GTBL is 40 bytes (X'28').</p>
 
   
 
   
      + (LHEAP) dwr
+
====Improving global variable processing====
   
+
<p>
      + (LITBL) dwr
+
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>The space allocation for an ITBL entry includes:</p>
 
   
 
   
      + (LNTBL * 12)
+
<ul>
 +
<li>Argument strings, including delimiters, which are saved as they are entered</li>
 
   
 
   
      + (LPDLST +32) dwr
+
<li>4 bytes of overhead for each saved string</li>
 +
</ul>
 
   
 
   
      + (LQTBL * 16)
+
<p>Space taken by a string is released when the included procedure is executed.</p>
 
   
 
   
      + (LSTBL) dwr
+
===Labels, names, and variables table (NTBL)===
 +
<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>
 
   
 
   
      + (LTTBL * 4)dwr
+
<p>NTBL has one entry for each of the following elements: </p>
 
   
 
   
      + (LVTBL * 32)
+
<ul>
 +
<li>Statement label</li>
 
   
 
   
      + (LXTBL) dwr
+
<li>List name</li>
</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>
+
<li>%variable</li>
<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>
 
 
   
 
   
<tr>
+
<li>Image, menu, and screen variable</li>
<td>
+
   
<p>HTLEN</p>
+
<li>Partner process opened by a request</li>
</td>
+
   
<td>
+
<li>Additional <var>COMMON</var> declaration</li>
<p>132</p>
 
  </td>
 
<td>
 
<p>32767</p>
 
  </td>
 
<td>
 
<p>Bytes</p>
 
</td>
 
</tr>
 
 
   
 
   
<tr>
+
<li>Unlabeled <var>Find</var></li>
<td>
 
<p>LFSCB</p>
 
</td>
 
<td>
 
<p>0</p>
 
</td>
 
<td>
 
<p>65528</p>
 
</td>
 
<td>
 
<p>Bytes</p>
 
</td>
 
</tr>
 
 
   
 
   
<tr>
+
<li><var>For Each Value</var> statement</li>
<td>
 
<p>LFTBL</p>
 
</td>
 
<td>
 
<p>1000</p>
 
</td>
 
<td>
 
<p>30 million</p>
 
</td>
 
<td>
 
<p>Bytes</p>
 
</td>
 
</tr>
 
 
   
 
   
<tr>
+
<li><var>For</var> statement with the <var>In Order</var> clause</li>
<td>
+
<p>LGTBL</p>
+
<li>Sequential or VSAM file opened simultaneously</li>
</td>
+
</ul>
<td>
+
<p>288</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>2 billion</p>
 
</td>
 
<td>
 
<p>Bytes</p>
 
</td>
 
</tr>
 
 
   
 
   
<tr>
+
<p>A host language thread requires NTBL entries for list names, compilation names, and variables. </p>
<td>
 
<p>LHEAP</p>
 
</td>
 
<td>
 
<p>0</p>
 
</td>
 
<td>
 
<p>2 million</p>
 
</td>
 
<td>
 
<p>Bytes</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>LITBL</p>
 
</td>
 
<td>
 
<p>0</p>
 
</td>
 
<td>
 
<p>32760</p>
 
  </td>
 
<td>
 
<p>Bytes</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>LNTBL</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>50</p>
 
</td>
 
<td>
 
<p>32760</p>
 
  </td>
 
<td>
 
<p>12-byte entries</p>
 
</td>
 
</tr>
 
 
   
 
   
<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 <var>End</var> and <var>End More</var> statements.</p>
<td>
 
<p>LPDLST</p>
 
</td>
 
<td>
 
<p>2600</p>
 
</td>
 
<td>
 
<p>32760</p>
 
</td>
 
<td>
 
<p>Bytes</p>
 
</td>
 
</tr>
 
 
   
 
   
<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>
<td>
 
<p>LQTBL</p>
 
</td>
 
<td>
 
<p>400</p>
 
</td>
 
<td>
 
<p>262,143</p>
 
</td>
 
<td>
 
<p>16-byte entries</p>
 
</td>
 
</tr>
 
 
   
 
   
<tr>
+
<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>
<td>
+
   
<p>LSTBL</p>
+
<p>You can reduce server I/O by allowing users executing shared precompiled procedures to use a shared copy of QTBL.</p>
  </td>
+
 
<td>
+
<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>
<p>600</p>
+
 
</td>
+
===QTBL and IFAM processing===
<td>
+
<p>
<p>16M</p>
+
When using the Inverted File Access Method (IFAM):</p>
</td>
 
<td>
 
<p>Bytes</p>
 
</td>
 
</tr>
 
 
   
 
   
<tr>
+
<ul>
<td>
+
<li><var>IFFIND</var>, <var>IFCOUNT</var>, and list manipulations build quadruples so that the SOUL evaluator routines can be used.</li>
<p>LTTBL</p>
 
</td>
 
<td>
 
<p>50</p>
 
</td>
 
<td>
 
<p>8190</p>
 
</td>
 
<td>
 
<p>4-byte entries</p>
 
</td>
 
</tr>
 
 
   
 
   
<tr>
+
<li><var>IFGET</var>, <var>IFMORE</var>, and <var>IFPUT</var> build field name lists in QTBL.</li>
<td>
+
<p>LVTBL</p>
+
<li>Other calls are evaluated directly.</li>
  </td>
+
</ul>
<td>
+
<p>
<p>50</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>
  </td>
+
 
<td>
+
===QTBL and FLOD processing===
<p>524287</p>
+
<p>
  </td>
+
FLOD builds its own quadruples (flodruples) in QTBL. Flodruple sizes vary, but most are 20 bytes or less. </p>
<td>
+
   
<p>32-byte entries</p>
+
<p>Major exceptions are:</p>
</td>
+
</tr>
+
<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>
 
<td>
 
<td>
<p>LXTBL</p>
+
<p>$functions</p></td>
</td>
 
 
<td>
 
<td>
<p>1000</p>
+
<p>16 + 3 per argument</p></td>
  </td>
+
</tr>
 +
   
 +
<tr>
 
<td>
 
<td>
<p>32760</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>MAXHDR</p>
+
<p>ADD</p></td>
</td>
 
 
<td>
 
<td>
<p>5</p>
+
<p>20</p></td>
  </td>
+
</tr>
 +
   
 +
<tr>
 
<td>
 
<td>
<p>32767</p>
+
<p>AFTER</p></td>
</td>
 
 
<td>
 
<td>
<p>Lines</p>
+
<p>20</p></td>
</td>
 
 
</tr>
 
</tr>
 
   
 
   
 
<tr>
 
<tr>
 
<td>
 
<td>
<p>MAXTRL</p>
+
<p>AND (except where AND is part of BETWEEN)</p></td>
</td>
 
 
<td>
 
<td>
<p>5</p>
+
<p>16</p></td>
  </td>
+
</tr>
 +
   
 +
<tr>
 
<td>
 
<td>
<p>32767</p>
+
<p>Conversion between a string and a number</p></td>
</td>
 
 
<td>
 
<td>
<p>Lines</p>
+
<p>16</p></td>
</td>
 
 
</tr>
 
</tr>
</table>
 
 
   
 
   
==Server tables==
+
<tr>
+
<td>
<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>
+
<p>CALL</p></td>
+
<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>16</p></td>
 
<p>The "Summary of server tables" lists the server tables. Further information on individual tables is contained in the subsections that follow.</p>
 
 
<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>CHANGE</p></td>
 +
<td>
 +
<p>44</p></td>
 
</tr>
 
</tr>
 
   
 
   
 
<tr>
 
<tr>
<td><p>FTBL</p></td>
+
<td>
<td><p>File groups</p></td>
+
<p>CLEAR LIST</p></td>
 +
<td>
 +
<p>20</p></td>
 
</tr>
 
</tr>
 
   
 
   
 
<tr>
 
<tr>
<td><p>GTBL</p></td>
+
<td>
<td><p>Global variables</p></td>
+
<p>CLEAR ON</p></td>
 +
<td>
 +
<p>16</p></td>
 
</tr>
 
</tr>
 
   
 
   
 
<tr>
 
<tr>
<td><p>ITBL</p></td>
+
<td>
<td><p>Dummy string and $READ responses</p></td>
+
<p>CLEAR TAG</p></td>
 +
<td>
 +
<p>16</p></td>
 
</tr>
 
</tr>
 
   
 
   
 
<tr>
 
<tr>
<td><p>NTBL</p></td>
+
<td>
<td><p>Statement labels, list names, and variables</p></td>
+
<p>CLOSE</p></td>
 +
<td>
 +
<p>16</p></td>
 
</tr>
 
</tr>
 
   
 
   
 
<tr>
 
<tr>
<td><p>QTBL</p></td>
+
<td>
<td><p>Statements in internal form (quadruples)</p></td>
+
<p>CLOSE PROCESS</p></td>
 +
<td>
 +
<p>16</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>COMMIT</p></td>
 +
<td>
 +
<p>4</p></td>
 
</tr>
 
</tr>
 
   
 
   
 
<tr>
 
<tr>
<td><p>STBL</p></td>
+
<td>
<td><p>Character strings</p></td>
+
<p>COMMIT RELEASE</p></td>
 +
<td>
 +
<p>20</p></td>
 
</tr>
 
</tr>
 
   
 
   
 
<tr>
 
<tr>
<td><p>TTBL</p></td>
+
<td>
<td><p>Temporary work pages</p></td>
+
<p>COUNT RECORDS (with a group)</p></td>
 +
<td>
 +
<p>52 + 20</p></td>
 
</tr>
 
</tr>
 
   
 
   
 
<tr>
 
<tr>
<td><p>VTBL</p></td>
+
<td>
<td><p>Compiler variables</p></td>
+
<p>DELETE</p></td>
 +
<td>
 +
<p>24</p></td>
 
</tr>
 
</tr>
 
   
 
   
 
<tr>
 
<tr>
<td><p>XTBL</p></td>
+
<td>
<td><p>Procedure security</p></td>
+
<p>DELETE RECORD</p></td>
 +
<td>
 +
<p>16</p></td>
 
</tr>
 
</tr>
</table>
 
 
   
 
   
===Full-screen buffer table (FSCB)===
+
<tr>
 +
<td>
 +
<p>ELSE</p></td>
 +
<td>
 +
<p>16 + body of the clause</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>ELSEIF</p></td>
 +
<td>
 +
<p>16 + body of the clause END</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>END</p></td>
 +
<td>
 +
<p>4</p></td>
 +
</tr>
 
   
 
   
<ul>
+
<tr>
<li> 144 bytes of fixed overhead for every menu, including the menu title</li>
+
<td>
 +
<p>Function call</p></td>
 +
<td>
 +
<p>16 + argument evaluation</p></td>
 +
</tr>
 
   
 
   
<li> 144 bytes for each menu prompt</li>
+
<tr>
 +
<td>
 +
<p>FIND (with at least one direct condition)</p></td>
 +
<td>
 +
<p>64 + 16</p></td>
 +
</tr>
 
   
 
   
<li> 432 bytes of fixed overhead for the first panel of every screen:</li>
+
<tr>
 +
<td>
 +
<p>FIND (with inverted condition)</p></td>
 +
<td>
 +
<p>64 + 36</p></td>
 +
</tr>
 
   
 
   
<li> 144 bytes for each subsequent panel, including the screen title</li>
+
<tr>
 +
<td>
 +
<p>FIND ALL RECORDS (no qualification)</p></td>
 +
<td>
 +
<p>64</p></td>
 +
</tr>
 
   
 
   
<li> 32 bytes for each screen prompt and input item</li>
+
<tr>
 +
<td>
 +
<p>FIND ALL RECORDS (with record  security and group)</p></td>
 +
<td>
 +
<p>64 + 52 + 20</p></td>
 +
</tr>
 
   
 
   
<li> 32 bytes for every screen line containing at least one input item</li>
+
<tr>
 +
<td>
 +
<p>FIND ALL RECORDS (with record  security)</p></td>
 +
<td>
 +
<p>64 + 52</p></td>
 +
</tr>
 
   
 
   
<li> 80 bytes for each defined screen line, including skipped lines</li>
+
<tr>
 +
<td>
 +
<p>FIND ALL VALUES (FRV field)</p></td>
 +
<td>
 +
<p>74</p></td>
 +
</tr>
 
   
 
   
<li> Additional space for automatic validation, including:</li>
+
<tr>
 +
<td>
 +
<p>FIND ALL VALUES (ORDERED field)</p></td>
 +
<td>
 +
<p>32</p></td>
 +
</tr>
 
   
 
   
<li> 2 or 4 bytes for each automatic validation option</li>
+
<tr>
 +
<td>
 +
<p>FOR EACH RECORD</p></td>
 +
<td>
 +
<p>24 + body of the loop</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>FOR EACH VALUE OF (with IN ORDER, a group)</p></td>
 +
<td>
 +
<p>88 + body of the loop + 68 + 24</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>GREATER THAN</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>IDENTIFY</p></td>
 +
<td>
 +
<p>16</p></td>
 +
</tr>
 
   
 
   
<li> Space for every block used in image definition
+
<tr>
</li>
+
<td>
</ul>
+
<p>IF</p></td>
 +
<td>
 +
<p>32</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>IF (with operator)</p></td>
 +
<td>
 +
<p>32 + 16</p></td>
 +
</tr>
 
   
 
   
===File group table (FTBL)===
+
<tr>
 +
<td>
 +
<p>Index loop</p></td>
 +
<td>
 +
<p>40 + expression evaluation + body of the loop</p></td>
 +
</tr>
 
   
 
   
<p>Data structures particular to file groups are stored in FTBL. FTBL entries are:</p>
+
<tr>
 +
<td>
 +
<p>IN RANGE FROM and TO, BETWEEN</p></td>
 +
<td>
 +
<p>28</p></td>
 +
</tr>
 
   
 
   
<ul>
+
<tr>
<li> Sixty-two-byte fixed size entry plus six bytes for each file in the group definition.
+
<td>
 +
<p>INSERT</p></td>
 +
<td>
 +
<p>24</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>MODIFY</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>NOTE</p></td>
</ul>
+
<td>
 +
<p>20</p></td>
 +
</tr>
 
   
 
   
<p>When the Inverted File Access Method (IFAM) is used: </p>
+
<tr>
 +
<td>
 +
<p>ON</p></td>
 +
<td>
 +
<p>16 + included statements</p></td>
 +
</tr>
 
   
 
   
<ul>
+
<tr>
<li> Host Language threads use FTBL under the same circumstances as User Language.</li>
+
<td>
 +
<p>OPEN</p></td>
 +
<td>
 +
<p>20</p></td>
 +
</tr>
 
   
 
   
<li> Field entries are not deleted until the group is closed or until IFFNSH is called. </li>
+
<tr>
 +
<td>
 +
<p>OPEN PROCESS</p></td>
 +
<td>
 +
<p>20</p></td>
 +
</tr>
 
   
 
   
<li> Increase the total FTBL requirement by NGROUP times four bytes.
+
<tr>
</li>
+
<td>
</ul>
+
<p>OR</p></td>
 +
<td>
 +
<p>16</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>PAUSE</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>POSITION</p></td>
 +
<td>
 +
<p>20</p></td>
 +
</tr>
 
   
 
   
===Understanding the global variable table (GTBL)===
+
<tr>
 +
<td>
 +
<p>PREPARE IMAGE</p></td>
 +
<td>
 +
<p>8</p></td>
 +
</tr>
 
   
 
   
<p>GTBL contains information about:</p>
+
<tr>
 +
<td>
 +
<p>PREPARE MENU</p></td>
 +
<td>
 +
<p>8</p></td>
 +
</tr>
 
   
 
   
<ul>
+
<tr>
<li> Global variables </li>
+
<td>
 +
<p>PREPARE SCREEN</p></td>
 +
<td>
 +
<p>8</p></td>
 +
</tr>
 
   
 
   
<li> Global images, screens, and menus</li>
+
<tr>
</ul>
+
<td>
 +
<p>PRINT</p></td>
 +
<td>
 +
<p>16 for each term</p></td>
 +
</tr>
 
   
 
   
<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>
+
<tr>
 +
<td>
 +
<p>PRINT (a field)</p></td>
 +
<td>
 +
<p>16 + 20</p></td>
 +
</tr>
 
   
 
   
<p>In addition, a 32-byte trailer stores information about offsets. </p>
+
<tr>
 +
<td>
 +
<p>PRINT MENU</p></td>
 +
<td>
 +
<p>16</p></td>
 +
</tr>
 
   
 
   
====Clearing GTBL entries====
+
<tr>
 +
<td>
 +
<p>PRINT SCREEN</p></td>
 +
<td>
 +
<p>16</p></td>
 +
</tr>
 
   
 
   
<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>
+
<tr>
 +
<td>
 +
<p>READ IMAGE</p></td>
 +
<td>
 +
<p>16</p></td>
 +
</tr>
 
   
 
   
====Space allocation====
+
<tr>
 +
<td>
 +
<p>READ MENU</p></td>
 +
<td>
 +
<p>20</p></td>
 +
</tr>
 
   
 
   
<p>The space allocation for a global variable includes:</p>
+
<tr>
 +
<td>
 +
<p>READ SCREEN</p></td>
 +
<td>
 +
<p>20</p></td>
 +
</tr>
 
   
 
   
<ul>
+
<tr>
<li> 4 bytes indicating the length of GTBL</li>
+
<td>
 +
<p>RECEIVE</p></td>
 +
<td>
 +
<p>16</p></td>
 +
</tr>
 
   
 
   
<li> 1 byte for the length of the variable name</li>
+
<tr>
 +
<td>
 +
<p>RELEASE RECORD</p></td>
 +
<td>
 +
<p>20</p></td>
 +
</tr>
 
   
 
   
<li> Variable name</li>
+
<tr>
 +
<td>
 +
<p>RELEASE POSITION</p></td>
 +
<td>
 +
<p>8</p></td>
 +
</tr>
 
   
 
   
<li> 1 byte for the length of the current name</li>
+
<tr>
 +
<td>
 +
<p>REPEAT</p></td>
 +
<td>
 +
<p>16 + evaluation of WHILE clause</p></td>
 +
</tr>
 
   
 
   
<li> Current value  </li>
+
<tr>
</ul>
+
<td>
 +
<p>REREAD SCREEN</p></td>
 +
<td>
 +
<p>20</p></td>
 +
</tr>
 
   
 
   
<p>
+
<tr>
Global images, screens, and menus require space for a 20-byte header in addition to the size of the object.</p>
+
<td>
 +
<p>RETRY</p></td>
 +
<td>
 +
<p>16</p></td>
 +
</tr>
 
   
 
   
<p>
+
<tr>
When allocating GTBL space, always remember to add 32 bytes for the trailer.</p>
+
<td>
 +
<p>RETURN</p></td>
 +
<td>
 +
<p>16</p></td>
 +
</tr>
 
   
 
   
<p>
+
<tr>
The minimum length of GTBL is 40 bytes (X'28').</p>
+
<td>
 +
<p>SEND</p></td>
 +
<td>
 +
<p>16</p></td>
 +
</tr>
 
   
 
   
====Improving global variable processing====
+
<tr>
 +
<td>
 +
<p>SIGNAL PROCESS</p></td>
 +
<td>
 +
<p>12</p></td>
 +
</tr>
 
   
 
   
<p>
+
<tr>
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>
+
<td>
 +
<p>STOP (automatically generated)</p></td>
 +
<td>
 +
<p>16</p></td>
 +
</tr>
 
   
 
   
===Dummy string and $READ table (ITBL)===
+
<tr>
+
<td>
<p>ITBL holds dummy string and $READ responses that are entered as arguments to an INCLUDE statement or command.</p>
+
<p>STORE RECORD (with each field)</p></td>
 +
<td>
 +
<p>16 + 16</p></td>
 +
</tr>
 
   
 
   
<p>The space allocation for an ITBL entry includes:</p>
+
<tr>
 +
<td>
 +
<p>TAB</p></td>
 +
<td>
 +
<p>4</p></td>
 +
</tr>
 
   
 
   
<ul>
+
<tr>
<li> Argument strings, including delimiters, which are saved as they are entered</li>
+
<td>
 +
<p>TAG</p></td>
 +
<td>
 +
<p>16</p></td>
 +
</tr>
 
   
 
   
<li> 4 bytes of overhead for each saved string
+
<tr>
</li>
+
<td>
</ul>
+
<p>THEN</p></td>
 +
<td>
 +
<p>16 + body of the clause</p></td>
 +
</tr>
 
   
 
   
<p>Space taken by a string is released when the included procedure is executed.</p>
+
<tr>
 +
<td>
 +
<p>TRANSFER</p></td>
 +
<td>
 +
<p>16</p></td>
 +
</tr>
 
   
 
   
===Labels, names, and variables table (NTBL)===
+
<tr>
 +
<td>
 +
<p>WITH</p></td>
 +
<td>
 +
<p>0</p></td>
 +
</tr>
 
   
 
   
<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>
+
<tr>
 +
<td>
 +
<p>WRITE IMAGE</p></td>
 +
<td>
 +
<p>12</p></td>
 +
</tr>
 +
</table>
 
   
 
   
<p>NTBL has one entry for each of the following elements: </p>
+
==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))dwr
 +
</p>
 +
<p>
 +
For Parallel Query Option/204 client nodes, the required size of RTBL increases by <code>(NRMTFILE=1)</code> 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>
 
<ul>
<li> Statement label</li>
+
<li> Space used to store intermediate results during an arithmetic expression evaluation is freed when the evaluation is completed.</li>
 
   
 
   
<li> List name</li>
+
<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>
 
   
 
   
<li> %variable</li>
+
<li>The last value of a <var>Note</var> statement remains in STBL.</li>
 
   
 
   
<li> Image, menu, and screen variable</li>
+
<li><var>FIXED</var> or <var>FLOAT</var> %variable array uses eight bytes for each element. </li>
 +
</ul>
 
   
 
   
<li> Partner process opened by a request</li>
+
<p>When the %variable is reassigned, the STBL space is reused.</p>
 
   
 
   
<li> Additional COMMON declaration</li>
+
<ul>
 +
<li>The FIELD SAVE option requires 10 bytes plus the maximum length of the string plus one byte for each element.</li>
 +
</ul>
 
   
 
   
<li> Unlabeled FIND</li>
+
<p>NO FIELD SAVE does not reserve the extra 10 bytes and results in significant saving when using a multidimensional array.</p>
 
   
 
   
<li> FOR EACH VALUE statement</li>
+
<ul>
 +
<li>MORE releases all but the space required by %variables and arrays. </li>
 
   
 
   
<li> FOR statement with the IN ORDER clause</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>
   
 
<li> Sequential or VSAM file opened simultaneously</li>
 
 
</ul>
 
</ul>
 
   
 
   
<p>Most NTBL entries are preserved by the MORE command except for the unlabeled FIND and secondary FOR entries, which are deleted.</p>
+
====When the Inverted File Access Method (IFAM) is used====
 +
<ul>
 +
<li><var>IFDVAL</var> and <var>IFFILE</var> store the value string from the input parameter in STBL. </li>
 
   
 
   
<p>A host language thread requires NTBL entries for list names, compilation names, and variables. </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>
 
   
 
   
<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>
+
<li>EDIT form of <var>IFPUT</var> uses STBL for each value. Space from previous values is reused. </li>
 
   
 
   
<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>
+
<li><var>FLOD</var> stores translation table values and <var>CASE</var> statement comparison values in STBL.  
 +
</li>
 +
</ul>
 
   
 
   
===Internal statement table (QTBL)===
+
====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 SOUL pattern matching processes</p>
 
   
 
   
<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>
+
<ul>
 +
<li>Using one of the following $functions in remote context requires 12 additional bytes in STBL:
 
   
 
   
<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><var>$Curfile</var></p>
 
   
 
   
<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><var>$RlcFile</var></p>
 
   
 
   
<p>You can reduce server I/O by allowing users executing shared precompiled procedures to use a shared copy of QTBL. </p>
+
<p><var>$Update</var></p>
 
   
 
   
===QTBL and IFAM processing===
+
<p><var>$UpdFile</var></p></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>
 
   
 
   
<p>When using the Inverted File Access Method (IFAM):</p>
+
===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 <var>FIND</var> (or <var>IFFIND</var>) evaluator routines.</p>
 
   
 
   
 
<ul>
 
<ul>
<li> IFFIND, IFCOUNT, and list manipulations build quadruples so that the SOUL evaluator routines can be used.</li>
+
<li>The Editor uses scratch pages to make a private copy of the procedure being edited.</li>
 
<li> IFGET, IFMORE, and IFPUT build field name lists in QTBL.</li>
 
 
   
 
   
<li> Other calls are evaluated directly.
+
<li><var>FIND</var> uses scratch pages as work space for evaluating Boolean expressions.</li>
</li>
 
 
</ul>
 
</ul>
 
   
 
   
<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>
+
<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>
 
   
 
   
===QTBL and FLOD processing===
+
===Compiler variable table (VTBL)===  
 
<p>
 
<p>
FLOD builds its own quadruples (flodruples) in QTBL. Flodruple sizes vary, but most are 20 bytes or less. </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>Major exceptions are:</p>
+
<p>
 +
Many SOUL statements and some constructs cause one or more compiler variables to be allocated in VTBL.</p>
 
   
 
   
<ul>
+
<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>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>
 
<table>
<caption>Sample QTBL entries</caption>
+
<caption>Sample VTBL entries</caption>
 
<tr class="head">
 
<tr class="head">
 
<th>
 
<th>
<p>SOUL statement</p>
+
<p>SOUL statement </p></th>
</th>
 
 
<th>
 
<th>
<p>QTBL entry size</p>
+
<p>VTBL entry size (bytes)</p></th>
</th>
 
 
</tr>
 
</tr>
 
   
 
   
 
<tr>
 
<tr>
 
<td>
 
<td>
<p>$functions</p>
+
<p>% variable:</p></td>
</td>
 
 
<td>
 
<td>
<p>16 + 3 per argument</p>
+
<p>&nbsp;</p></td>
</td>
 
 
</tr>
 
</tr>
 
   
 
   
 
<tr>
 
<tr>
 
<td>
 
<td>
<p>%variable, subscripted (reference to)</p>
+
<p>FIXED</p></td>
</td>
 
 
<td>
 
<td>
<p>16 + expression evaluation</p>
+
<p>16</p></td>
</td>
 
 
</tr>
 
</tr>
 
   
 
   
 
<tr>
 
<tr>
 
<td>
 
<td>
<p>ADD</p>
+
<p>FLOAT</p></td>
</td>
 
 
<td>
 
<td>
<p>20</p>
+
<p>12</p></td>
</td>
 
 
</tr>
 
</tr>
 
   
 
   
 
<tr>
 
<tr>
 
<td>
 
<td>
<p>AFTER</p>
+
<p>STRING</p></td>
</td>
 
 
<td>
 
<td>
<p>20</p>
+
<p>24</p></td>
</td>
 
 
</tr>
 
</tr>
 
   
 
   
 
<tr>
 
<tr>
 
<td>
 
<td>
<p>AND (except where AND is part of BETWEEN)</p>
+
<p>array</p></td>
</td>
 
 
<td>
 
<td>
<p>16</p>
+
<p>20</p></td>
</td>
 
 
</tr>
 
</tr>
 
   
 
   
 
<tr>
 
<tr>
 
<td>
 
<td>
<p>Conversion between a string and a number</p>
+
<p>array element reference</p></td>
</td>
 
 
<td>
 
<td>
<p>16</p>
+
<p>12</p></td>
</td>
 
 
</tr>
 
</tr>
 
   
 
   
 
<tr>
 
<tr>
 
<td>
 
<td>
<p>CALL</p>
+
<p>CALL</p></td>
</td>
 
 
<td>
 
<td>
<p>16</p>
+
<p>4 + (4 * arguments)</p></td>
</td>
 
 
</tr>
 
</tr>
 
   
 
   
 
<tr>
 
<tr>
 
<td>
 
<td>
<p>CHANGE</p>
+
<p>CALL statement evaluation</p></td>
</td>
 
 
<td>
 
<td>
<p>44</p>
+
<p>28</p></td>
</td>
 
 
</tr>
 
</tr>
 
   
 
   
 
<tr>
 
<tr>
 
<td>
 
<td>
<p>CLEAR LIST</p>
+
<p>COUNT</p></td>
</td>
 
 
<td>
 
<td>
<p>20</p>
+
<p>8</p></td>
</td>
 
 
</tr>
 
</tr>
 
   
 
   
 
<tr>
 
<tr>
 
<td>
 
<td>
<p>CLEAR ON</p>
+
<p>FIND (basic entry, single file)</p></td>
</td>
 
 
<td>
 
<td>
<p>16</p>
+
<p>8</p></td>
</td>
 
 
</tr>
 
</tr>
 
   
 
   
 
<tr>
 
<tr>
 
<td>
 
<td>
<p>CLEAR TAG</p>
+
<p>workspace</p></td>
</td>
 
 
<td>
 
<td>
<p>16</p>
+
<p>20 + 20 + 28</p></td>
</td>
 
 
</tr>
 
</tr>
 
   
 
   
 
<tr>
 
<tr>
 
<td>
 
<td>
<p>CLOSE</p>
+
<p>fieldname = value pair</p></td>
</td>
 
 
<td>
 
<td>
<p>16</p>
+
<p>20 or more</p></td>
</td>
 
 
</tr>
 
</tr>
 
   
 
   
 
<tr>
 
<tr>
 
<td>
 
<td>
<p>CLOSE PROCESS</p>
+
<p>retrieval</p></td>
</td>
 
 
<td>
 
<td>
<p>16</p>
+
<p>28</p></td>
</td>
 
 
</tr>
 
</tr>
 
   
 
   
 
<tr>
 
<tr>
 
<td>
 
<td>
<p>COMMIT</p>
+
<p>Ordered Index retrieval</p></td>
</td>
 
 
<td>
 
<td>
<p>4</p>
+
<p>4 + 4 per segment</p></td>
</td>
 
 
</tr>
 
</tr>
 
   
 
   
 
<tr>
 
<tr>
 
<td>
 
<td>
<p>COMMIT RELEASE</p>
+
<p>FIND (basic entry, group)</p></td>
</td>
 
 
<td>
 
<td>
<p>20</p>
+
<p>8 + (8 * files)</p></td>
</td>
 
 
</tr>
 
</tr>
 
   
 
   
 
<tr>
 
<tr>
 
<td>
 
<td>
<p>COUNT RECORDS (with a group)</p>
+
<p>FOR EACH RECORD (no IN ORDER clause)</p></td>
</td>
 
 
<td>
 
<td>
<p>52 + 20</p>
+
<p>16</p></td>
</td>
 
 
</tr>
 
</tr>
 
   
 
   
 
<tr>
 
<tr>
 
<td>
 
<td>
<p>DELETE</p>
+
<p>FOR EACH VALUE (with FROM, TO, LIKE, ORDERED</p></td>
</td>
 
 
<td>
 
<td>
<p>24</p>
+
<p>48</p></td>
</td>
 
 
</tr>
 
</tr>
 
   
 
   
 
<tr>
 
<tr>
 
<td>
 
<td>
<p>DELETE RECORD</p>
+
<p>FOR EACH RECORD IN ORDER BY (with ORDERED field)</p></td>
</td>
 
 
<td>
 
<td>
<p>16</p>
+
<p>48</p></td>
</td>
 
 
</tr>
 
</tr>
 
   
 
   
 
<tr>
 
<tr>
 
<td>
 
<td>
<p>ELSE</p>
+
<p>FOR EACH VALUE (with ORDERED field)</p></td>
</td>
 
 
<td>
 
<td>
<p>16 + body of the clause</p>
+
<p>40</p></td>
</td>
 
 
</tr>
 
</tr>
 
   
 
   
 
<tr>
 
<tr>
 
<td>
 
<td>
<p>ELSEIF</p>
+
<p>Function (SOUL)</p></td>
</td>
 
 
<td>
 
<td>
<p>16 + body of the clause END</p>
+
<p>4 + (4 * arguments)</p></td>
</td>
 
 
</tr>
 
</tr>
 
   
 
   
 
<tr>
 
<tr>
 
<td>
 
<td>
<p>END</p>
+
<p>Lists:</p></td>
</td>
 
 
<td>
 
<td>
<p>4</p>
+
<p>&nbsp;</p></td>
</td>
 
 
</tr>
 
</tr>
 
   
 
   
 
<tr>
 
<tr>
 
<td>
 
<td>
<p>Function call</p>
+
<p>single files</p></td>
</td>
 
 
<td>
 
<td>
<p>16 + argument evaluation</p>
+
<p>8</p></td>
</td>
 
 
</tr>
 
</tr>
 
   
 
   
 
<tr>
 
<tr>
 
<td>
 
<td>
<p>FIND (with at least one direct condition)</p>
+
<p>groups</p></td>
</td>
 
 
<td>
 
<td>
<p>64 + 16</p>
+
<p>8 + (8 * files)</p></td>
</td>
 
 
</tr>
 
</tr>
 
   
 
   
 
<tr>
 
<tr>
 
<td>
 
<td>
<p>FIND (with inverted condition)</p>
+
<p>Menu definition</p></td>
</td>
 
 
<td>
 
<td>
<p>64 + 36</p>
+
<p>48</p>
 
  </td>
 
  </td>
 
</tr>
 
</tr>
Line 2,790: Line 3,200:
 
<tr>
 
<tr>
 
<td>
 
<td>
<p>FIND ALL RECORDS (no qualification)</p>
+
<p>Numeric expression</p></td>
</td>
 
 
<td>
 
<td>
<p>64</p>
+
<p>16</p></td>
</td>
 
 
</tr>
 
</tr>
 
   
 
   
 
<tr>
 
<tr>
 
<td>
 
<td>
<p>FIND ALL RECORDS (with record
+
<p>ON</p></td>
  security and group)</p>
 
</td>
 
 
<td>
 
<td>
<p>64 + 52 + 20</p>
+
<p>28</p></td>
</td>
 
 
</tr>
 
</tr>
 
   
 
   
 
<tr>
 
<tr>
 
<td>
 
<td>
<p>FIND ALL RECORDS (with record
+
<p>Related image set</p></td>
  security)</p>
 
</td>
 
 
<td>
 
<td>
<p>64 + 52</p>
+
<p>12 + 4 for every 256 items</p></td>
</td>
 
 
</tr>
 
</tr>
 
   
 
   
 
<tr>
 
<tr>
 
<td>
 
<td>
<p>FIND ALL VALUES (FRV field)</p>
+
<p>Screen definition</p></td>
</td>
 
 
<td>
 
<td>
<p>74</p>
+
<p>68 + 4 for each panel</p></td>
</td>
 
 
</tr>
 
</tr>
 
   
 
   
 
<tr>
 
<tr>
 
<td>
 
<td>
<p>FIND ALL VALUES (ORDERED field)</p>
+
<p>Screen entry (one panel)</p></td>
</td>
 
 
<td>
 
<td>
<p>32</p>
+
<p>72</p></td>
</td>
 
 
</tr>
 
</tr>
 
   
 
   
 
<tr>
 
<tr>
 
<td>
 
<td>
<p>FOR EACH RECORD</p>
+
<p>SORT</p></td>
</td>
 
 
<td>
 
<td>
<p>24 + body of the loop</p>
+
<p>&nbsp;</p></td>
</td>
 
 
</tr>
 
</tr>
 
   
 
   
 
<tr>
 
<tr>
 
<td>
 
<td>
<p>FOR EACH VALUE OF (with IN ORDER, a group)</p>
+
<p>each referenced field</p></td>
</td>
 
 
<td>
 
<td>
<p>88 + body of the loop + 68 + 24</p>
+
<p>20</p></td>
</td>
 
 
</tr>
 
</tr>
 
   
 
   
 
<tr>
 
<tr>
 
<td>
 
<td>
<p>GREATER THAN</p>
+
<p>each sort key</p></td>
</td>
 
 
<td>
 
<td>
<p>20</p>
+
<p>32</p></td>
</td>
 
 
</tr>
 
</tr>
 
   
 
   
 
<tr>
 
<tr>
 
<td>
 
<td>
<p>IDENTIFY</p>
+
<p>String expression</p></td>
</td>
 
 
<td>
 
<td>
<p>16</p>
+
<p>8</p></td>
</td>
 
 
</tr>
 
</tr>
 
   
 
   
 
<tr>
 
<tr>
 
<td>
 
<td>
<p>IF</p>
+
<p>Subroutine declaration</p></td>
</td>
 
 
<td>
 
<td>
<p>32</p>
+
<p>16 + parameters </p></td>
</td>
 
 
</tr>
 
</tr>
 +
</table>
 
   
 
   
<tr>
+
====Effect of the MORE parameter on VTBL====
<td>
+
<p>
<p>IF (with operator)</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>
+
====IFAM and FLOD considerations====
<p>32 + 16</p>
+
<p>
</td>
+
The following considerations apply to VTBL: </p>
</tr>
 
 
   
 
   
<tr>
+
<p>IFAM requires VTBL space for <var>IFFIND</var>, <var>IFCOUNT</var>, and lists (matching SOUL requirements), and a few extra bytes for temporary work space. </p>
<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>
 
</td>
 
</tr>
 
 
<tr>
 
<td>
 
<p>array element reference</p>
 
</td>