SQLBSCAN parameter: Difference between revisions
Jump to navigation
Jump to search
(Automatically generated page update) |
|||
| (One intermediate revision by one other user not shown) | |||
| Line 1: | Line 1: | ||
{{Template:SQLBSCAN parameter subtitle}} | |||
==Summary== | ==Summary== | ||
<dl> | <dl> | ||
| Line 10: | Line 11: | ||
<dd>All | <dd>All | ||
<dt>Introduced | <dt>Introduced | ||
<dd><var class="product">Model 204 | <dd><var class="product">Model 204 V3.1</var> | ||
</dl> | </dl> | ||
==Description== | ==Description== | ||
<p>The limit on the number of significant internal operations that a user can execute without causing a user restart</p> | <p>The limit on the number of significant internal operations that a user can execute without causing a user restart</p> | ||
Latest revision as of 14:53, 6 September 2017
Max RSQL read/writes
Summary
- Default value
- -1
- Parameter type
- User
- Where set
- On user's parameter line (CCAIN)
- Related products
- All
- Introduced
- Model 204 V3.1
Description
The limit on the number of significant internal operations that a user can execute without causing a user restart
Model 204 issues a user restart when an SQL request reaches SQLBSCAN internal operations, which include indexed finds, fetching from files and intermediate result tables, and writing to files and intermediate result tables. The SQLBSCAN counter is not affected by user swapping.
SQLBSCAN is an integer whose minimum is -1, maximum is 2147483647, and default is -1. Setting SQLBSCAN to 0 allows the value of SQLLPLIM to determine when a user is restarted. (See SQLLPLIM: Internal loop limit.) Setting SQLBSCAN to -1 places no limit on the total number of operations executed in a user's request.