RESPAGE parameter: Difference between revisions

From m204wiki
Jump to navigation Jump to search
No edit summary
m (minor formatting)
 
(7 intermediate revisions by 4 users not shown)
Line 13: Line 13:
<dd><var class="product">Model 204</var> version 7.5
<dd><var class="product">Model 204</var> version 7.5
</dl>
</dl>
==Description==
==Description==
<p>Activates the APSY Precompiled Procedures in storage feature using above the bar pages by specifying a number of 4K operating system pages.</p>
<p>
<p>If specified, the value will be rounded to the next 1 megabyte page boundary (256 4K pages).</p>
This parameter applies to IBM z/OS systems only. It activates the [[Performance monitoring and tuning#Resident Request feature for precompiled procedures|Resident Request feature]] for [[Application_Subsystem_development|APSY]] precompiled procedures in storage. <var>RESPAGE</var> specifies the maximum number of 4K-byte operating system pages to be allocated, above the bar, for procedures that are made resident. </p>
<p>If specified, RESSIZE, RESLTHR and RESTHRSH are ignored; RESSIZE is reset to -1; RESLTHR and RESTHRSH are reset to zero.</p>
<p>
<p>For IBM z/OS systems only.</p>
Whenever a procedure is made resident, a minimum of 16 4K-byte pages are allocated for that procedure. If more pages are required, another chunk of 16 4K-byte pages is allocated. These chunks facilitate more efficient management of ATB storage, which the operating system allocates in 1-megabyte increments. </p>
<p>
The actual storage "used" by resident requests can be displayed with a <code>MONITOR SUBSYS (PROCCT) <i>subsysname</i></code> command. Given this allocation algorithm, if you have 1000 procedures that you want to become resident, you will need to set <var>RESPAGE</var> to 16000, at a minimum.</p>
<p>
When you specify a non-zero <var>RESPAGE</var> value:
<ul>
<li>The actual number of 4K-byte pages allocated is rounded up to the next 1-megabyte page boundary (the next multiple of 256 4K-byte pages).</li>
 
<li>Existing settings of <var>[[RESSIZE_parameter|RESSIZE]]</var>, <var>[[RESLTHR parameter|RESLTHR]]</var>, and <var>[[RESTHRSH parameter|RESTHRSH]]</var> are changed: <var>RESSIZE</var> is reset to -1; <var>RESLTHR</var> and <var>RESTHRSH</var> are reset to zero. </li>  
 
<li><code>VIEW [[RESCURR parameter|RESCURR]]</code>, and <code>VIEW [[RESHIGH parameter|RESHIGH]]</code> show, respectively, the current and the high-water mark of ATB storage allocated (even multiples of <code>16*4K</code> bytes) for resident requests. </li>
</ul>
 
[[Category:Parameters]]
[[Category:Parameters]]
[[Category:System parameters]]
[[Category:System parameters]]

Latest revision as of 16:31, 23 May 2017

Number of resident N/QTBL ATB pages

Summary

Default value
0
Parameter type
System
Where set
User 0 parameter line
Related products
All
Introduced
Model 204 version 7.5

Description

This parameter applies to IBM z/OS systems only. It activates the Resident Request feature for APSY precompiled procedures in storage. RESPAGE specifies the maximum number of 4K-byte operating system pages to be allocated, above the bar, for procedures that are made resident.

Whenever a procedure is made resident, a minimum of 16 4K-byte pages are allocated for that procedure. If more pages are required, another chunk of 16 4K-byte pages is allocated. These chunks facilitate more efficient management of ATB storage, which the operating system allocates in 1-megabyte increments.

The actual storage "used" by resident requests can be displayed with a MONITOR SUBSYS (PROCCT) subsysname command. Given this allocation algorithm, if you have 1000 procedures that you want to become resident, you will need to set RESPAGE to 16000, at a minimum.

When you specify a non-zero RESPAGE value:

  • The actual number of 4K-byte pages allocated is rounded up to the next 1-megabyte page boundary (the next multiple of 256 4K-byte pages).
  • Existing settings of RESSIZE, RESLTHR, and RESTHRSH are changed: RESSIZE is reset to -1; RESLTHR and RESTHRSH are reset to zero.
  • VIEW RESCURR, and VIEW RESHIGH show, respectively, the current and the high-water mark of ATB storage allocated (even multiples of 16*4K bytes) for resident requests.