z/TPF - Group home

Recoup on Fenced I-streams (PJ46401)

By Mark Lehrer posted Fri October 22, 2021 11:15 AM

  
Recoup is a utility that all customers run usually once a week. Its primary purpose is to validate the TPF database. To accomplish this task, Recoup searches all chains in the TPF database. Because customers can have billions of records in their database, it can take hours for Recoup to find all in use records. Not only does Recoup do a large amount of I/O, it also uses a significant amount of CPU processing time.

Recoup is a maintenance utility; it does not generate revenue. Today, Recoup runs on the same I-streams as transactional work. Recoup has some internal controls to allow transactional work to have a higher priority. Ultimately, because Recoup is sharing I-streams with transactional work, Recoup run time is elongated.

Customers typically have a specific time frame that they allocate for Recoup run time. For example, you might allocate 4 hours for Recoup. If Recoup takes longer than the allocated time, it will impact other work that you need to do.

As the size of your databases grow, it becomes difficult to keep Recoup within your allocated time frame because Recoup is competing with transactional work for CPU processing time. Either you need to increase capacity or change other work to accommodate a longer time for Recoup to run.

One source of additional capacity are fenced I-steams. Fenced I-streams are I-streams that are above the I-stream cap. As a result, transactional work is not routed to these I-streams. If you are using Dynamic CPU, you have fenced I-streams that are ready to accept additional work when needed.

What does PJ46401 provide?

PJ46401 leverages the processing power of these idle fenced I-streams in order to run Recoup. Recoup will use as many as four fenced I-streams for its processing:

  • If you have fewer than four fenced I-streams, all fenced I-streams are used.
  • If you have more than four fenced I-streams, the four fenced I-streams with the highest I-stream numbers are used. The reason that the highest I-stream numbers are used is to minimize the impact if the I-stream cap is increased because of an increase in transactional work.
Recoup must be run as low priority in order to use recoup on fenced I-streams. This attribute keeps fenced I-streams poised to be brought in-use at any time. Doing so maintains fenced I-streams primarily role to service transactional work, when needed, and then to service recoup.

What must I do to run recoup on fenced I-streams?

The following conditions must be met to run recoup on fenced I-streams:
  • Fenced I-streams are available on the LPAR.
  • Recoup must be run as a low priority.
  • The IGSHARED format-2 global record must be defined and initialized. This global record is required to run recoup, regardless of the priority chosen.

DASD interruptions

When a fenced I-stream’s low priority utility utilization (LPUU) crosses above 10%, z/TPF will enable all subclasses of DASD I/O interruptions on that fenced I-stream. Likewise, when the LPUU drops below 10% on a fenced I-stream, all subclasses of DASD I/O interruptions will be disabled on that fenced I-stream.

Overflowing recoup to in-use I-streams

Recoup processing is not exclusive to fenced I-streams. If the recoup fenced I-streams reach 100% busy and more recoup child ECBs are created, these new recoup child ECBs are processed on in-use I-streams. This overflow processing can be observed by noting LPUU reported for in-use I-streams. There are a couple of reasons why you might want overflow processing to happen:
  • If in-use I-streams are running at less than capacity, the user can get Recoup to run faster by overflowing to in-use I-streams. To do this, a user can increase the number of allowed Recoup ECBs so that the fenced I-streams run at 100% busy and child ECBs deliberately overflow to in-use I-streams.
  • Because Recoup is running as low priority, Recoup child ECBs that go to in-use I-streams will also run as low priority. As a result, there should be little to no impact on transactional ECBs.

ZSTAT updates and examples

The U and GPU parameter output on the ZSTAT command was updated. If the low-priority utility utilization of a fenced I-stream is greater than 1%, the system will identify the I-stream as a fenced I-stream in use by the system (SF1). Below is an example of the updated ZSTAT U command output. You can see the highest four fenced I-streams are in use by Recoup and their status is denoted as SF1.
 
CSMP0097I 09.48.04 CPU-B SS-BSS  SSU-HPN  IS-01
STAT0039I 09.48.04 SYSTEM UTILIZATION DISPLAY
STATIC POWER SAVE MODE - SYSTEM AT 100 PERCENT
SPEED BOOST IS NOT ACTIVE
I-STREAM BOOST IS NOT ACTIVE
NUM  ADR  UTIL/ ADJ  CROSS READY INPUT   VCT SUSPD DEFER ACT-ECB S   PSU  LPUU
IS- 1 00  72.8/ 72.5     0     0     0     0     0     0     31  U   72.6   .0
IS- 2 01  71.0/ 70.8     1     0     0     0     0     0     27  U   71.0   .0
IS- 3 02  45.1/ 44.9    12     0     0     0     0     0     22 CU   45.0   .0
IS- 4 03    .2/   .0     0     0     0     0     0     0      1  F2    .2   .0
IS- 5 04  94.3/ 94.1     0     0     0     0     0     1     11 SF1  95.1 93.4
IS- 6 05  95.0/ 94.8     0     0     0     0     0     0     15 SF1  95.4 94.2
IS- 7 06  95.0/ 94.8     0     0     0     0     0     4     10 SF1  95.0 94.0
IS- 8 07  94.9/ 94.7     1     0     0     0     0     0     16 SF1  95.3 94.0
END OF DISPLAY+

If you consider that these fenced I-streams would have been otherwise idle before, this is a significant benefit to your system. Not just to Recoup’s processing.

Here is a ZSTAT command output example of running recoup on fenced I-streams with some of the recoup workload overflowing to in-use I-streams:

CSMP0097I 11.55.25 CPU-B SS-BSS  SSU-HPN  IS-01
STAT0039I 11.55.25 SYSTEM UTILIZATION DISPLAY
STATIC POWER SAVE MODE - SYSTEM AT 100 PERCENT
SPEED BOOST IS NOT ACTIVE
I-STREAM BOOST IS NOT ACTIVE
NUM  ADR  UTIL/ ADJ  CROSS READY INPUT   VCT SUSPD DEFER ACT-ECB S   PSU  LPUU
IS- 1 00   1.7/  1.5     0     1     0     0     0     0     10  U    1.7   .6
IS- 2 01    .8/   .6     0     0     0     0     0     0      5  U     .6   .6
IS- 3 02    .7/   .5     0     0     0     0     0     0      5  U     .5   .5
IS- 4 03    .8/   .6     0     0     0     0     0     0      6  U     .6   .5
IS- 5 04    .9/   .7     0     0     0     0     0     0      6  U     .7   .6
IS- 6 05    .9/   .7     0     0     0     0     0     0      5  U     .6   .6
IS- 7 06    .9/   .7     0     0     0     0     0     0      5  U     .6   .6
IS- 8 07    .9/   .7     0     0     0     0     0     0      4  U    7.2   .6
IS- 9 08   1.0/   .8     0     0     0     0     0     0      3 CU     .7   .5
IS-10 09    .2/   .0     0     0     0     0     0     0      0  F2    .2   .0
IS-11 0A    .2/   .0     0     0     0     0     0     0      0  F2    .2   .0
IS-12 0B    .2/   .0     0     0     0     0     0     0      0  F2    .2   .0
IS-13 0C  95.4/ 95.2     1     0     0     0     0     1     10 SF1  95.6 94.6
IS-14 0D  94.8/ 94.6     0     0     0     0     0     3      4 SF1  95.0 94.0
IS-15 0E  94.6/ 94.4     8     0     0     0     0     0     10 SF1  95.0 93.6
IS-16 0F  94.8/ 94.6     0     0     0     0     0     8      9 SF1  95.2 94.0
END OF DISPLAY+

A couple items to note about this example:
  • The overflow processing uses the load balancer, so the additional recoup work is spread to all in-use I-streams.
  • The overflow processing does NOT queue work to other fenced I-streams. Note that the fenced I-streams other than the highest four fenced I-streams are idle.

See Fenced I-stream eligible support for more information on the above prerequisites and processing descriptions.

How do I benefit from this support?

Have or install fenced I-streams on your LPAR today and be ready to exploit this support!!

For more information on PJ46401 please see the APEDIT.
For more information on application support for throttling DASD IOPs, see this BLOG.
0 comments
10 views